Relatório Técnico Final

Transcrição

1 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II SignalBee Supervisão e controle semafórico sem fio Relatório Técnico Final Alex Soletti Fabiano Reino Beraldo Lourival Lippmann Júnior 4º Bimestre Visto: Alex Soletti Fabiano Reino Beraldo Curitiba 2010

2 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II 1.0 Resumo O projeto visou criar uma solução que tornasse mais fácil o controle dos semáforos instalados nas grandes metrópoles, de forma simples e prática, utilizando a tecnologia de wireless ZigBee (conjunto de especificações para comunicação sem-fio, que define camadas do modelo OSI, de acordo com o padrão IEEE ). Em conjunto, foi desenvolvido um software em C++, utilizando o framework Qt produzido pela empresa norueguesa Trolltech, em licença LGPL (Lesser General Public License). Obteve-se um resultado satisfatório, com os semáforos funcionando com comunicação sem fio, em duas configurações: Simples, especificada no item 4.3, e em grupo (simulação de um cruzamento), descrita no item 4.4, ambas as formas funcionam com uma lógica semafórica previamente definida nos itens referentes a cada configuração. A implementação também proporciona ao usuário um controle e supervisão, através do software desenvolvido pelo grupo, o SignalBee UI. Alex Soletti Fabiano Reino Beraldo Curitiba

3 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II 2.0 Introdução Devido à carência de um sistema que proporcione de forma sólida, o controle e supervisão de semáforos, foi desenvolvido então, o SignalBee, que tem como objetivo geral, um sistema que permite ao usuário modificar o tempo da luz verde, amarela e vermelha - assim como a supervisão de erros (lâmpada queimada, semáforo desligado, grupo do cruzamento mal formado, elemento do grupo desligado (todos entram em alerta luz amarelo piscando), perda de comunicação com os demais elementos da rede Mesh (item 4.0), entre outros problemas em potencial), sem a necessidade de se utilizar cabos e permitindo que o administrador do sistema possa se conectar a rede Mesh, independente de sua localização, sendo somente necessário estar próximo a rede. Desta forma o projeto teve como objetivo específico, criar uma alternativa mais econômica para a supervisão e controle dos semáforos de trânsito, o qual é de extrema importância e largamente utilizado em cruzamentos das vias de tráfegos de veículos de grandes cidades. Neste projeto não foi incluído o sistema de monitoramento do tráfego, que se define pela utilização de sensores para estimativa do fluxo de veículos no cruzamento ou avenida, a sincronização de semáforos em cruzamentos distintos (com o objetivo de evitar a parada dos veículos entre um cruzamento e outro). Este documento intitulado relatório técnico final, foi revisado a partir das modificações feitas após o protótipo e está estruturado da seguinte forma: Detalhamento do projeto: nessa seção será especificado o diagrama de bloco geral do projeto assim como a descrição em detalhes dos blocos que envolveram hardware (diagrama elétrico/lógico dos circuitos, etc.) e detalhes dos blocos que envolveram software (DFD s, UML, fluxogramas, etc.) e para completar será especificado o procedimento de integração de cada bloco; Testes e resultados (detalhamento dos testes realizados) assim como seus resultados esperados e os obtidos; Conclusão, indicando se o trabalho atingiu os objetivos propostos e indicando possíveis melhorias para projetos futuros; Referências Bibliográficas e a fim de ilustrar e complementar as informações do projeto tem-se o conjunto de anexos. Alex Soletti Fabiano Reino Beraldo Curitiba

4 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II 3.0 Detalhamento do projeto O projeto está separado em 4 (quatro) módulos, cada um com uma função em específico, como mostra a figura 1: Figura 1 - Diagrama de bloco da visão geral do projeto. 4.0 Semáforos Constituído do bloco geral mostrado na figura 2, ele tem como responsabilidade atuar como os semáforos de um cruzamento do dia a dia. A comunicação entre os semáforos é realizada pelo CC2530EM, que é um módulo ZigBee de comunicação wireless (padrão IEEE ) de baixo consumo. Figura 2 Representação do bloco dos semáforos Alex Soletti Fabiano Reino Beraldo Curitiba

5 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II De acordo com o modelo proposto pela TI, os módulos ZigBee podem ser configurados de três formas: Coordenador, Roteador e Dispositivo Final. Todas as três configurações podem ser implementadas em qualquer um dos dois módulos ZigBee s (CC2530 E CC2531, explicados nos itens 4.1 e 5.0, respectivamente). Estes por si utilizam o formato de rede estruturada denominada Mesh. Ela é composta de APs (Access point = Ponto de acesso) e clientes, os quais necessariamente devem utilizar aquele AP para trafegarem em uma rede. Uma rede mesh (figura 3) é composta de vários nós/roteadores, que passam a se comportar como uma única e grande rede, possibilitando que o cliente se conecte em qualquer um destes nós. Os nós têm a função de repetidores e cada nó está conectado a um ou mais nós. Desta maneira é possível transmitir mensagens de um nó a outro por diferentes caminhos. Figura 3 Simbolização de uma rede mesh Em preto (coordenador), vermelho (roteador) e branco (dispositivo final) Foi escolhida a seguinte configuração para os módulos CC2530EM: Tabela 1 - Configuração escolhida para os módulos CC2530EM Nome do Módulo ZigBee Configuração Dispositivo ZigBee_EM_1 Roteador Semáforo 1 ZigBee_EM_2 Roteador Semáforo 2 ZigBee_EM_3 Roteador Semáforo 3 ZigBee_EM_4 Roteador Semáforo 4 Alex Soletti Fabiano Reino Beraldo Curitiba

6 4.1 ZigBee O semáforo possuí um módulo ZigBee CC2530EM (Figura 4) utilizado para comunicação wireless, contendo um chip CC2530, que foi baseado na arquitetura 8051 da Intel. O chip CC2530 é um circuito de baixo consumo alimentado com 2,5-3.8 Volts, dotado de dois cristais osciladores, sendo um de 32Mhz e outro de 32Khz, assim como um controladora de I/O que Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II aceita dados mixados (Digitais/Analógicos). Uma representação esquemática do chip e suas portas podem ser vista na figura 5. O consumo varia entre 3,4 ma a 0,4 ua, dependendo de sua configuração. No modo sleep (modo em que o chip desliga parte de seus componentes quando não estão sendo utilizados) seu consumo é de aproximadamente 0,6 ua. Para a utilização da memória flash, em operações de erase (apagar) este consome aproximadamente 1 ma e em modo de write (gravação) os picos de corrente podem ser de até 6 ma. É dotado de 21 portas lógicas de I/O, das quais serão utilizados os pinos P0.6, P0.7 e P1.1, para receber os sinais das lâmpadas (Detector de corrente). Já os pinos P0.2 até P0.4, serão utilizados para sinalizar qual lâmpada deverá ser acessa. Por fim, um último pino, o P0.1, sinalizará se o módulo ZigBee se encontra funcional ou não. Figura 4 - Chip CC2530EM Figura 5 - Diagrama do chip CC2530 Alex Soletti Fabiano Reino Beraldo Curitiba

7 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II 4.2 Lógica semafórica Sabe-se que um semáforo possui 3 (três) cores, e que sua sequência de transições é simples: Primeiramente se tem a luz vermelha a qual sinaliza PARE, seguida da luz verde que significa SIGA, e por fim a luz amarelo que sinaliza ATENÇÃO. Seguindo este conceito, foi implementado neste projeto uma lógica semafórica semelhante, no qual os tempos de verde, tempo de amarelo e tempo de vermelho (períodos de tempo nos quais cada lâmpada fica acesa respectivamente) possam ser alterados pelo administrador do sistema. 4.3 Configuração Simples Partindo da existência de vias as quais exigem a necessidade de um semáforo, para auxiliar na travessia de pedestres, foi elaborado o semáforo com configuração simples. Seu fluxo de funcionamento é descrito na figura 6. Considerando que o sistema acabou de ser ligado, este no inicio estará sem nenhuma configuração inicial e deve-se configurá-lo de acordo com a lógica pretendida (ver item 4.5). Sendo feita a configuração do semáforo como simples, o software irá iniciar a execução do algoritmo semafórico único. Vale ressaltar que no processo de inicialização do sistema, o safe driver estará ativado, que se caracteriza pela luz amarelo pulsante, e irá ser desligado a partir do momento que o sistema esteja iniciado por completo. O algoritmo semafórico consiste no seguinte: seu estado inicial é o vermelho, ou seja, a luz vermelha está acesa. Considerando que os tempos de verde, de amarelo e de vermelho são configuráveis, o tempo que as lâmpadas ficaram acessas são os seus respectivos tempos configurados pelo usuário do software SignalBeeUI. Figura 6 - Fluxograma de Configuração Simples Tvermelho -> Tverde ->Tamarelo¹ 1. (A condição acima não reflete os modelos semafóricos atuais, e foi utilizada somente a critério acadêmico.) Alex Soletti Fabiano Reino Beraldo Curitiba

8 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II Sendo assim, quando o tempo de vermelho expira, muda-se para o estado verde, acendendo a lâmpada verde, e apagando-se a lâmpada vermelha. Por vez, o tempo de verde não depende de nenhuma outra variável, desta forma o tempo que a luz verde permanecerá acesa será o valor especificado em Tverde. Por fim, quando o tempo expirar, muda-se para o estado amarelo, que assim como o estado verde, possui um tempo determinado - TAmarelo, que não depende de nenhuma outra variável. Expirando este tempo, muda-se para o estado vermelho novamente que terminará quando o TVermelho expirar, reiniciando o ciclo. 4.4 Configuração em Grupo Para que o sistema suporte a sincronização de dois ou mais semáforos, condição esta necessária para o funcionamento correto em cruzamentos é necessário que os semáforos sejam agrupados, o que irá gerar uma dependência entre os mesmos, de forma a se representar um determinado cruzamento. Desta forma é possível estabelecer uma sincronia entre os semáforos de um grupo específico, e determinar quais são o fluxo de transição de estados. A partir da dependência criada, os semáforos irão se comunicar entre si, possibilitando uma troca síncrona de estados (cores), justamente para evitar que aconteça de dois ou mais semáforos estejam com a luz verde ligada ao mesmo tempo. Partindo do princípio que a rede esteja funcionando, o fluxograma descrito na figura 7, demonstra como deve ser os passos para a mudança de estados. Dado um determinado semáforo, o qual está com a luz verde ligada, este é chamado de Semáforo Líder. A token descrita a seguir, nada mais é que a habilidade de se ligar a luz verde. Desta forma, a comunicação entre os dois Figura 7 - Fluxograma de Transição de Token semáforos é necessária, para que a token seja repassada com segurança. Com a luz verde ligada no semáforo líder, ao término do tempo de verde, este irá enviar uma mensagem, do tipo TOKENCHANGING, para o próximo semáforo pertencente ao Alex Soletti Fabiano Reino Beraldo Curitiba

9 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II grupo, seguindo a ordem pré-programada, que foi especificada quando o grupo foi formado. O semáforo alvo, ao receber esta mensagem, irá responder com a mensagem CHANGINGACCEPTED. Quando o semáforo líder receber a mensagem de resposta, seu estado atual deve ser a cor amarela. Por fim, este irá responder com a mensagem TOKENSENT, e irá mudar para o estado Vermelho. O semáforo alvo, recebendo esta mensagem, irá se tornar o novo semáforo líder, e terá seu estado alterado para verde. No processo de mudança do semáforo líder, este somente terá seu estado alterado da luz amarela, para a luz vermelha, se e somente se, o semáforo alvo responder com a mensagem CHANGINGACCEPTED. Caso aconteça de a mensagem não chegar antes do tempo de amarelo do semáforo líder expirar, este irá notificar os demais membros do grupo que o sistema está fora de sincronia, e consequentemente irá ativar o safe driver. Desta forma, todos os demais semáforos terão os seus respectivos safe driver s ativados também. 1. (Para configurações que exijam que dois ou mais semáforos estejam ligados ao mesmo tempo, seria necessário criar uma nova lógica semafórica para estes. Deste modo, somente será coberto neste projeto, a configuração que permita que um semáforo esteja com a luz verde ligada, enquanto os demais estejam com a luz vermelha ativa.) 4.5 Processo de configuração dos dispositivos Para efetuar a configuração dos dispositivos, via SignalBeeUI, o software irá enviar uma struct preenchida com todas as configurações especificadas, desta forma, sempre que um pedido de configuração é feito o dispositivo é totalmente reconfigurado, tendo somente como exceção seu ID, que é único e é gravado juntamente com o firmware. As structs enviadas podem ser vistas nas figuras 8 e 9 respectivamente. E o código completo pode ser vistos no Anexo XXIII. Alex Soletti Fabiano Reino Beraldo Curitiba

10 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II Figura 8 Primeiro tipo de struct de configuração dos semáforos Figura 9 - Segundo tipo de struct de configuração dos semáforos Alex Soletti Fabiano Reino Beraldo Curitiba

11 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II 4.6 Comunicação entre dispositivos Os módulos zigbee s se comunicam através de mensagens denominadas clusters, os clusters são provenientes dos profiles, os quais são definidos pelo consórcio Zigbee Alliance. Para o desenvolvimento foram especificados os clusters da tabela 2 Tabela 2 - Tabela de clusters usados para comunicação entre dispositivos Cluster ID Table CLUSTER_NAME CLUSTER_ID CLUSTER_DESCRIPTION SEMAPHORE_STATUS 5 Utilizado para reportar os dados ao software do PC CMD_SET_CONFIG 6 Cluster bidirecional, para uso de publicação de novas configurações. MEMBER_SEARCH_REQUEST 7 Quando em grupo, para efetuar a busca dos membros que não se encontram online. MEMBER_SEARCH_RESPONSE 8 MEMBER_PING 9 MEMBER_PONG 10 GROUP_STATUS_OFFLINE 11 GROUP_STATUS_ONLINE 12 TOKEN_ACQUIRE 13 TOKEN_RELEASE 14 LIGHT_STATUS_RESPONSE 15 LIGHT_STATUS_REQUEST 16 LIGHT_FAILURE 17 Resposta de um membro, ao líder, quando este recebe uma mensagem de código 7 Ping direcionado a um membro em específico, para manter certa integridade do grupo. Resposta de um membro, ao líder, quando este recebe uma mensagem de código 10 O leader notifica o restante dos membros do grupo, que o grupo se encontra em estado 'STANDBY' O leader notifica o restante dos membros do grupo, que o grupo se encontra em estado 'PRONTO'. O leader envia ao membro a token de acesso, a qual dá direito ao mesmo de trocar as lâmpadas para verde e amarelo. O membro devolve a token de acesso ao líder, e aguarda p/ a próxima token. Resposta de um membro, ao líder, quando este recebe uma mensagem de código 16 O leader pergunta qual o estado das lâmpadas a um membro específico. Quando uma lâmpada falha em algum semáforo membro, o mesmo dispara uma mensagem com esse cluster ID. Alex Soletti Fabiano Reino Beraldo Curitiba

12 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II 4.7 Safe Driver O Safe Driver é um conjunto de ações que foram determinadas a partir da necessidade de se proteger os motoristas de falhas adversas no semáforo. Sua principal função é pulsar a lâmpada amarela (que significa atenção ) quando algum problema ocorre no sistema. Para configurações em grupo, quando um membro, independente se este seja o líder ou não, se desconectar da rede Mesh, ou, não conseguir verificar se os demais membros estão online, o safe driver irá entrar em ação. Esta proteção também será utilizada se o módulo ZigBee venha a travar ou até mesmo queimar. Por fim, caso alguma lâmpada esteja queimada, um sinal será emitido pelo detector de corrente para o módulo ZigBee, o qual irá identificar esse sinal, e consequentemente ativar o safe driver. Para entrar em ação, o safe driver deverá verificar o sinal do pino P0.1 (figura 5), o qual foi chamado de alive, e monitorar o sinal de entrada. Quando o sinal de alive estiver em nível lógico 1 (um) (5 volts), passando pela porta NAND (U14A, da figura 10), o safe driver estará desativado, o que representa que o circuito está em funcionamento normal. Para o nível lógico 0 (zero) (0 volts), o safe driver entrará em ação visto que algum erro ocorreu, os quais podem ser: Configuração em Grupo: Membro desconectado; ZigBee Travado ou Queimado; Perda de conexão com a rede Mesh; Queima de alguma lâmpada do semáforo; Configuração Simples Alex Soletti Fabiano Reino Beraldo Curitiba

13 ZigBee Travado ou Queimado; Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II Queima de alguma lâmpada do semáforo; Como parte integrante do safe driver, foi elaborado uma lógica inicial utilizando portas AND, OR e NOT. Porém devidos a alguns testes descritos no item Testes e Resultados, foi necessário algumas alterações no SafeDriver para a implementação definitiva do projeto, pois notamos divergências quando a lâmpada está em alta impedância (sem sinal de ligada ou desligada). Para tal reparo foi necessária à inserção de resistores de 10k Ohms na entrada dos sinais que ligam as lâmpadas, caracterizando um resistor de pull-down Também foi incluída no circuito, representado pela figura 10, uma porta AND (U15A) para comparar o sinal do circuito pisca com o sinal de alive, deste modo o circuito NAND não alimenta diretamente o astavél, pois após testes do protótipo percebeu-se que o astável consome muita tensão em seus pulsos. Para criar o sinal pulsante, que ativa a luz amarela do semáforo a cada 1s aproximadamente, a qual é a principal característica do safe driver, foi projetado um multivibrador astável que gera pulsos de 1Hz.No circuito do multivibrador e nos demais circuitos integrados (U1 até U13) foi adicionado um capacitor no valor de 100nF entre o VCC e o GND, fazendo o papel de armazenar tensão para os pulsos do astável e para os CI s o papel de estabilizar a tensão de alimentação. As lâmpadas na figura são indicadas pelos LED s, na sequência Vermelha(LED2), Verde(LED3) e Amarela(LED1). Mais detalhes do circuito serão descritos nos próximos tópicos. Alex Soletti Fabiano Reino Beraldo Curitiba

14 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II Figura 10 - Circuito Lógico Seletor de Estado e Multivibrador Astável 4.8 Detector de corrente O detector de corrente sofreu apenas uma alteração referente ao começo e ao fim do projeto, referente ao circuito inicial, foi incluído em sua saída um opto acoplador parecido com o MOC3023, o 4N25 que se utiliza de um opto transistor e sua função na saída do detector é isolar a entrada do CC2530EM (descrito como sendo nosso semáforo.), já que este admite uma entrada de no máximo 3V e visto que antes do 4N25 (U1) temos uma saída 5V.Para que seja então, detectado quando uma lâmpada queima (circuito aberto), foi elaborado o circuito descrito na figura 11. Sua principal função é notificar o módulo ZigBee de que a lâmpada em questão está queimada, o qual será feito através dos pinos P0.6(Detector da lâmpada vermelha), P0.7(Detector da lâmpada verde), e P1.1(Detector da lâmpada amarela),. De forma a exemplificar o funcionamento do circuito, considera-se que a lâmpada esteja funcionando normalmente. Primeiramente foi colocado um resistor de potência de 10Ω/1W em série com a lâmpada alvo do detector, para gerar uma queda de tensão mínima. Seguindo, se tem os diodos zener, que estarão ceifando o sinal para, aproximadamente, +5v e -5v, juntamente de um retificador de onda completa (ponte de wien) e um filtro RC, o qual irá eliminar/diminuir o efeito ripple do Alex Soletti Fabiano Reino Beraldo Curitiba

15 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II sinal. Caso o valor de saída antes do U1 seja 0, então a lâmpada estará queimada, e o LED do U1 não acenderá, isso faz com que o opto-transistor não feche e por uma especificação técnica do módulo CC2530EM, que possui um resistor interno de pull-up, temos um resistor de 10kΩ em série com a alimentação do próprio módulo para termos um efeito, de quando a lâmpada estar queimada, termos uma entrada em um dos pinos designados aos detectores, de no máximo 3V, ou nunca maior que a própria alimentação do CC2530EM. Entretanto, se o valor de saída antes do U1 for 5V, a lâmpada estará funcionando, caracterizando por o LED do U1 acesso e o opto-transistor fechado, forçando, por assim dizer, um nível de 0V na entrada de um dos pinos designados ao detector. A tabela 3 resume o resultado obtido para o detector. Foi necessária a existência de um circuito deste para cada lâmpada do semáforo. Tabela 3 - Funcionamento do Detector de corrente Valores de saída do 4n25 Estado da lâmpada Funcionando Queimada Saída do circuito detector entrada em um dos pinos (P0.6, P0.7 ou P1.1) 0V 3V ou valor aproximado da alimentação do zigbee Figura 11 - Circuito detector de corrente Alex Soletti Fabiano Reino Beraldo Curitiba

16 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II 4.9 OptoAcoplador Para garantir que o circuito de alta potência - utilizado para ativar as lâmpadas - esteja isolado do circuito digital, foi criado um circuito auxiliar utilizando um opto acoplador da Motorola, modelo MOC3023. Utilizando os pinos de saída das portas AND s (figura 10) U4, U5 e U6 de cada uma das lâmpadas - estes são conectados ao seu respectivo MOC3023. Desta forma a ativação o circuito digital ficará isolado do circuito de alta potência. Para acionar a lâmpada, que está em 110V/127V, será utilizado um TRIAC (BTA12), do outro lado do MOC3023. O diagrama elétrico do opto acoplador pode ser visto na figura 12. Figura 12 Diagrama Elétrico Opto acoplador Alex Soletti Fabiano Reino Beraldo Curitiba

17 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II 4.10 Fonte de alimentação Inicialmente a fonte de alimentação seria feita pela equipe, mais visando à economia e a praticidade, decidimos utilizar uma fonte de computador. Os cabos de saída da fonte foram adaptados, pois não precisaríamos da saída que normalmente as fontes de PC possuem, sendo assim adaptamos um conjunto de conectores DC, de acordo com a figura 13. Tal mudança na parte da fonte não teve impacto grande no projeto, pois a fonte é independente dos módulos e ela apenas precisaria cumprir o requisito de nos entregar 5 volts e com um divisor de tensão, formado por diodos e resistores, podemos tirar as demais tensões necessárias para o projeto (3V e 2V). O esquemático final da fonte é representado pela figura 14. Além de termos as pequenas tensões a fonte de computador também nos permitiu retirar os 127V para ativação das lâmpadas, resumindo, o projeto tem apenas uma entrada de alimentação. O circuito final com a integração da alimentação + safedriver + optoacoplador + detector, caracterizando-se pela placa de circuito impresso (PCI ou do inglês PCB printed circuit board) pode ser visto no Anexo VIII. Figura 13 - Fonte de Tensão e conectores DC Alex Soletti Fabiano Reino Beraldo Curitiba

18 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II Figura 14 - Esquemático da Alimentação 4.11 Fluxograma do Software Para o software do chip CC2530, que roda nos semáforos, foi desenvolvido o fluxograma representado na figura 15. O seu funcionamento será baseado em tarefas, e o próprio sistema operacional chamado de OSAL - do módulo ZigBee contido na Z-STACK, irá gerenciar a execução das mesmas. A tarefa ZNP (ZigBee Network Protocol), é responsável pela leitura e transmissão dos pacotes via wireless, de acordo com o protocolo IEEE Esta já esta incluída no sistema operacional por padrão, e não será alterada neste projeto. O software será codificado e programado no chip CC2530 utilizando o aplicativo IAR Embedded Workbench for MSC-51, na linguagem C. Alex Soletti Fabiano Reino Beraldo Curitiba

19 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II Figura 15 - Fluxograma do software do semáforo (CC2530EM) 4.12 Materiais Utilizados Para desenvolver o firmware dos semáforos, foram utilizados os seguintes materiais/softwares: DIA Diagram Editor (LINUX): Software para elaboração de fluxogramas. Licença: GNU/Open Source. National Instruments Circuit Design Suite v10.0 (WINDOWS): Software utilizado para elaboração e teste dos diagrama elétricos. Licença: Trial. Adobe Photoshop CS3 (WINDOWS): Software utilizado para elaboração de imagens 2D. Licença: Trial. IAR Embedded Workbench for MCS A (WINDOWS): Software utilizado para programar os módulos CC2530EM e CC2531. Licença: Trial. Alex Soletti Fabiano Reino Beraldo Curitiba

20 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II 5.0 Coordenador Para que uma rede mesh possa ser iniciada, é necessário que exista um módulo ZigBee, podendo este ser o CC2530 ou CC2531, configurado como coordenador. Neste projeto, foi escolhido que o módulo CC2531EMK (Evalution Module Kit EMK), aqui caracterizado de dongle, irá efetuar o papel de coordenador. Esse módulo ao ser conectado ao computador, irá realizar a interface Figura 16 - Módulo CC2531EMK entre a rede mesh, composta pelos semáforos, e o framework desenvolvido para formatação dos dados. O módulo CC2531EMK contém um chip CC2531, baseado na arquitetura 8051 da Intel. Assim como o CC2530EM, este módulo também foi desenvolvido pela Texas Instruments e é essencial para efetuar o monitoramento de redes mesh formada por dispositivos ZigBee, através do computador. 5.1 Gerenciador da Rede Para a correta inicialização do coordenador, ele foi configurado com um valor fixo de PAN (Personal Area Network), o qual serve como forma de alias (apelido) para a rede mesh. Quando um semáforo se conectar ao coordenador, seu PAN será verificado, e deverá coincidir com o do coordenador, para que um endereço IPv4 possa ser atribuído ao novo dispositivo. Uma camada de dados chamada Z-STACK, disponibilizada pela Texas Instruments, proporciona a conexão automática do módulo na rede mesh, quando esta possuir um coordenador ativo, de forma que os passos necessários para se estabelecer uma conexão na rede, fiquem transparentes ao desenvolvedor. Alex Soletti Fabiano Reino Beraldo Curitiba

21 5.2 Interface de Dados da Rede Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II Para que o dongle possa trocar informações com o software desenvolvido para computador, será utilizada a interface USB. Para o correto funcionamento da porta USB, deverá ser feito a inicialização da mesma no software contido no chip, e configurado os valores para a comunicação serial, especificados a seguir: Baud Rate: Bit Numbers: 8 Stop Bit: 1 Parity: No 1. (Os valores de configuração da porta serial virtual devem ser os mesmos que foram especificados no framework). 2. (É necessária a instalação de um driver, desenvolvido pela TI, que efetua a conversão dos dados enviados ao USB para o formato serial. Este pode ser encontrado no site do fabricante, no pacote Com isso, quando uma mensagem é recebida pela rede, o software contido no dongle irá enviar os dados para a USB, os quais serão serializados pelo driver. Posteriormente o framework fará a leitura dos dados e irá encapsular as informações em forma de uma struct descrita no item Framework - para que o software de computador SignalBeeUI possa interpretar de maneira correta. Da mesma forma, o SignalBeeUI poderá enviar informações aos dispositivos, que obrigatoriamente terá que seguir o caminho inverso, ou seja, os dados serão enviados ao framework em forma de uma struct, e enviados ao dongle através da comunicação serial. Este por fim irá ler as informações e repassar a um ou mais dispositivos alvos. Todo o código pode ser visto no anexo XXX. Alex Soletti Fabiano Reino Beraldo Curitiba

22 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II 5.3 Fluxograma de Software Para o software do chip CC2531, que roda no dongle, foi desenvolvido o fluxograma representado na figura 17. Assim como o software do semáforo, seu funcionamento também será baseado em tarefas, e o próprio sistema operacional OSAL irá gerenciar a execução das mesmas. A tarefa ZNP (ZigBee Network Protocol), também é responsável pela leitura e transmissão dos pacotes via wireless, de acordo com o protocolo IEEE Esta já esta incluída no OSAL por padrão, e não será alterada neste projeto. O software será codificado e programado no chip CC2531 utilizando o aplicativo IAR Embedded Workbench for MSC-51, na linguagem C. Figura 17 - Fluxograma do software do coordenador (CC2531EMK) Alex Soletti Fabiano Reino Beraldo Curitiba

23 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II 5.4 Z-STACK A Z-STACK¹ é a pilha dos módulos CC2530EM/CC2531EMK desenvolvida pela TI, específica para a plataforma ZigBee, para ser utilizada pelos desenvolvedores criarem suas aplicações. Ela é composta do sistema operacional OSAL, e implementada utilizando um modelo OSI (Open System Interconnection), o qual possibilita que a rede mesh trabalhe com o protocolo IPv4. Possui ainda, garantia de entrega de pacotes, encriptação de mensagens utilizando AES-256bits (Advanced Encryption Standard) e controle de erros. 1. (O link que contém o detalhamento completo da Z-STACK, pode ser encontrado nas referências bibliográficas.) 6.0 Framework O Framework tem como principal função serializar os dados recebidos do software de computador para posterior envio ao dongle, assim como efetuar a leitura dos dados enviados pelo dongle, e estruturar os mesmos para que possam ser lidos pelo SignalBeeUI, figuras 18 e 19. Para a comunicação dos semáforos com o software o framework utiliza-se da seguinte struct: Alex Soletti Fabiano Reino Beraldo Curitiba

24 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II Figura 18 - Estrutura de comunicação entre os semáforos e o software E para a comunicação no caminho inverso, ou seja, do software para os semáforos, o framework se utiliza da seguinte struct: Figura 19 -Estrutura de comunicação entre os software e os semáforos Alex Soletti Fabiano Reino Beraldo Curitiba

25 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II Todo o framework foi programado utilizando a linguagem C/C++, e empacotado em forma de biblioteca dinâmica (.dll para Windows e.so para Linux), o qual poderá ser carregado dinamicamente no sistema operacional pelo software SignalBeeUI. Para a criação do framework será utilizado o software Qt Creator, e a biblioteca Qt, ambos disponibilizados pela Nokia, e que estão sob licença LGPL (Lesser General Public License). Abaixo uma breve descrição do significado de serialização, retirada do site Wikipédia: A serialização de dados consiste no processo de salvar um objeto em um meio de armazenamento (como um arquivo de computador ou um buffer de memória) ou transmiti-lo por uma conexão de rede, seja em forma binária ou em formato de texto como o XML. Esta série de bytes pode ser usada para recriar um objeto com o mesmo estado interno que o original. Alex Soletti Fabiano Reino Beraldo Curitiba

26 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II 7.0 SignalBee UI Para que seja intuitivo o controle e supervisão dos semáforos conectados a rede mesh, foi desenvolvido um software chamado SignalBeeUI. Este foi codificado na linguagem C++, utilizando à biblioteca Qt. A versão final da interface do software pode ser visto na figura 20. Com o software o usuário pode efetuar o controle dos tempos de verde, amarelo e vermelho de cada semáforo, verificar se o semáforo se encontra conectado à rede mesh e funcionando normalmente, ou se possui alguma lâmpada queimada. Figura 20 Representação do software de supervisão e controle do SignalBee - SignalBeeUI Alex Soletti Fabiano Reino Beraldo Curitiba

27 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II 7.1 Supervisão Para que o processo de supervisão pudesse ficar visível, o software possui em sua interface o estado das lâmpadas de cada semáforo, assim como, se o semáforo se encontra conectado na rede ou não, e para configurações em grupo, se o grupo se encontra funcional ou não. Estas informações estão acessíveis ao usuário, quando se selecionar o semáforo desejado, assim como, quando algum evento ocorrer no sistema: Queima de uma lâmpada do semáforo, ou perca de conexão com a rede mesh. Também foi desenvolvidos códigos para identificação dos eventos, eles podem ser vistos na tabela 4 e podem ser visto com o restante do código no anexo XXXVIII. Tabela 4 - Códigos de identificação de eventos Código Nome Descrição 1 EVENT_NWK_CLUSTER_DISCOVERY Código utilizado quando um 2 EVENT_ROUTER_SEMAPHORE_STATE dispositivo se conecta na rede mesh. Código utilizado quando o semáforo reporta ao software do às configurações e o status atual do dele como: tempo de cada lâmpada, quem é o líder (se tiver), id do grupo, qual lâmpada está acesa, safe driver, etc. 3 EVENT_ROUTER_SEMAPHORE_CMD_REQ 4 EVENT_ROUTER_SEMAPHORE_CMD_RESP 5 EVENT_ROUTER_SEMAPHORE_CMD_ERROR Código utilizado para troca de mensagem do PC (SignalBeeUI) para o semáforo Código utilizado para troca de mensagem do semáforo para o PC (SignalBeeUI) Código utilizado para troca de mensagem quando há erro de transmissão do PC para o semáforo. Alex Soletti Fabiano Reino Beraldo Curitiba

28 Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II 7.2 Controle Assim como o processo de supervisão, o software conta com comandos para efetuar o controle dos semáforos. Os comandos disponíveis serão: Alterar o tempo de Verde, Amarelo e Vermelho: Caso o semáforo alvo seja membro de algum grupo, a alteração feita no tempo de qualquer lâmpada irá refletir em todos os outros semáforos pertencentes ao grupo em questão. Se o semáforo alvo não for membro de nenhum grupo, o tempo será atualizado normalmente. Remover um grupo: Dado um grupo formado previamente, o mesmo poderá ter sua formação desfeita, caso necessário. Criar um grupo: O usuário irá selecionar os semáforos desejados que estejam disponíveis na tela, conhecendo a localização física de cada um, e poderá efetuar a criação de um grupo. Remover semáforo: Dado um determinado semáforo, previamente cadastrado, o mesmo poderá ser removido do sistema, caso este não faça parte de um grupo qualquer. Caso o semáforo continue ativo fisicamente, este ainda irá aparecer na interface do usuário. Cadastrar semáforo: Sabendo que cada semáforo possui um número respectivo de identificação, que foi especificado no processo de gravação do chip, o usuário do sistema poderá efetuar o cadastro do semáforo de duas maneiras: o Conhecendo o número de identificação do semáforo, o usuário do sistema poderá efetuar o cadastro deste, caso o semáforo não se encontre conectado na rede mesh; o Caso o semáforo esteja conectado na rede mesh, e ainda não se encontre cadastrado no sistema, o seu cadastro poderá ser feito através da interface visual do sistema; Alex Soletti Fabiano Reino Beraldo Curitiba

29 7.3 Núcleo de funcionamento Pontifícia Universidade Católica do Paraná Centro de Ciências Exatas e de Tecnologia Engenharia de Computação Projeto Final II Para guardar o registro de cada semáforo, e seus respectivos grupos, foi elaborado um modelo de banco de dados, que pode ser visto na figura 21. Para implementação do banco de dados foi utilizado a tecnologia sqlite biblioteca desenvolvida na linguagem C, que implementa um banco de dados SQL embutido. Figura 21 - Diagrama do Banco de Dados do SignalBeeUI A tabela CONFIG, é utilizada para guardar configurações pertinentes a interface do software, como a localização do arquivo do banco de dados sqlite, e a configuração da porta serial virtual que será utilizada pelo framework. 1. (Outras configurações podem vir a ser incluídas no processo de codificação do software, se necessárias) As tabelas, EM_CONFIG e EM_GROUP, são utilizadas para guardar as configurações pertinentes aos semáforos. Em EM_CONFIG, é armazenado o número de identificação do semáforo, o qual é especificado no processo de gravação do chip, assim como o número do grupo a qual ele é membro, que referencia uma entrada na tabela EM_GROUP, podendo ser nulo, se não for pertencer a nenhum grupo. Para se manipular os dados recebidos dos semáforos, assim como os dados das tabelas, é utilizada a estrutura de dados representada na figura 22. Com ela será foi possível montar o diagrama que representa as conexões entre os semáforos na rede mesh, assim como sua topologia. Figura 22 - Diagrama UML da classe Semáforo Alex Soletti Fabiano Reino Beraldo Curitiba