PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA “Desenvolvimento de um Nó de Rede com Diferentes Interfaces de Acordo com o Padrão IEEE 1451 Utilizando o Processador Nios II e o Sistema Operacional Embarcado μClinux” TÉRCIO ALBERTO DOS SANTOS FILHO Orientador: Prof. Dr. Alexandre César Rodrigues da Silva Tese apresentada à Faculdade de Engenharia - UNESP – Campus de Ilha Solteira, para obtenção do t́ıtulo de Doutor em Engenharia Elétrica. Área de Conhecimento: Automação. Ilha Solteira - SP Maio de 2012 Alberto dosDesenvolvimento de u Ilha Solteira21/08/2012182 Sim Tese (doutoEngenhariaInstrument Sim . . . FICHA CATALOGRÁFICA Desenvolvido pela Seção Técnica de Aquisição e Tratamento da Informação Santos Filho, Tércio Alberto dos. Desenvolvimento de um nó de rede com diferentes interfaces de acordo com o padrão ieee 1451 utilizando o processador nios ii e o sistema operacional embarcado uclinux / Tércio Alberto dos Santos Filho. -- Ilha Solteira: [s.n.], 2012 182 f. : il. Tese (doutorado) - Universidade Estadual Paulista. Faculdade de Engenharia de Ilha Solteira. Àrea de conhecimento: Automação, 2012 Orientador: Alexandre César Rodrigues da Silva Inclui bibliografia 1. Redes de transdutores inteligentes. 2. Sistemas embarcados. 3. Padrão IEEE 1451. 4. Sistema operacional embarcado. 5. Rede de sensores sem fio Zigbee. 6. Rede de sensores cabeada. S237d Aos meus pais, Tercio e Eridam, à meu irmão Carlos e a minha querida esposa Denise. DEDICO Agradecimentos Agradeço a Deus por ter dado forças em todos os momentos de minha vida. Agradeço aos meus pais Tércio Alberto dos Santos e Eridam Pereira da Silva Santos, por toda a dedicação na minha formação como pessoa e profissional, pelo carinho, paciência e amor. Ao meu irmão, Carlos Eduardo da Silva Santos, que sempre me apoiou nos diversos momentos da minha vida, pelos conselhos, pela amizade e confiança. Agradeço em especial a minha querida esposa, Denise Rodrigues Dias dos Santos que durante todo o peŕıodo dos meus estudos, me apoiou, deu forças, incentivou nas minhas escolhas e pelo amor. Agradeço ao meu professor, orientador e amigo Alexandre César Rodrigues da Silva por ter me ensinado e pelo apoio nessa fase de minha vida contribuindo não só como orientador, mais sendo um grande amigo também. Agradeço aos meus avós, Açodio e Isaura. Agradeço ao meu sogro e minha sogra, José Rodrigues Dias e Alice Rodrigues Dias, pela ajuda, confiança e pelo apoio. Agradeço a minha cunhada Mirelle e minha sobrinha Lav́ınia. Agradeço as minhas cunhadas, concunhados, sobrinhos e sobrinhas Daniela, Joyce, Denildo, Valdir, João Vitor, Guilherme, Gabriela, Maria Heloisa e Manuela. Aos meus familiares: Olivar, Patricia, André, Leandro, Oĺıvio, Carmen Luzia, Marcelo Azevedo, Lara, Elma, Ernesta, Iara, Maria do Rosário, Agustinho, Neide, Keila, Flávio, Marina, minha madrinha Cristiane, Luciano e Pedro Henrique. Aos meus amigos de infância, Rafael Ratke e sua esposa Bruna, Rodrigo Mendonça de Souza e noiva Jáına, Vińıcius da Cunha e Heverton Barros de Macêdo e sua esposa Isabelle. Aos meus amigos Marcos Antônio Estremote e esposa Elaine, Tiago da Silva Almeida, Marcelo Estremote e noiva Andressa, Rafael (Ilha Solteira), Marcelo Sanches, Mateus, Marcos Vińıcius e Alex. Agradeço aos meus amigos que estiveram comigo durante minhas pesquisas realizadas no laboratório dividindo minhas elegrias e conquistas. Aos meus professores de pós-graduação e técnicos de laboratório. Ao Conselho Nacional de Desenvolvimento Cient́ıfico e Tecnológico (CNPq), processos: (140261/2008-7) e (307255/2009-3). Ao Programa de Pós-Graduação em Engenharia Elétrica - PPGEE, Faculdade de Engenharia Elétrica de Ilha Solteira - FEIS. Resumo Os sistemas operacionais possuem um papel fundamental nos microcomputadores, realizando o interfaceamento entre os aplicativos e o hardware. Além dos microcomputadores, atualmente, os sistemas operacionais são empregados em ambiente com arquitetura restrita, como os microcontroladores, denominando-os como sistemas operacionais embarcados. Algumas das aplicações para os sistemas operacionais embarcados são voltadas para as redes de transdutores inteligentes, realizando o gerenciamento e controle do sistema em que atua. Neste trabalho apresenta-se o desenvolvimento de um nó de rede denominado NCAP, utilizando o kit DE2 e o sistema operacional embarcado μClinux para o monitoramento e controle dos TIMs com diferentes interfaces conforme a norma IEEE 1451. O NCAP desenvolvido possui como caracteŕıstica a conexão de diferentes TIMs com recursos de controle e monitoramento com distintas interfaces de comunicação, com fio (RS-232) e sem fio (ZigBee). Para realização dos testes, foram desenvolvidos 4 TIMs com diferentes caracteŕısticas, sendo: 2 STIMs (IEEE P1451.2) e 2 WTIMs (IEEE 1451.5). Os testes foram realizados utilizando uma interface de rede externa, a Ethernet, que, por meio do microcomputador, é posśıvel acessar a página web em um servidor embarcado instalado no nó de rede NCAP. Com isso, é posśıvel realizar o controle e o monitoramento dos transdutores conectados ao TIM independente da interface de comunicação sem fio ou com fio. Além do acesso aos transdutores, o nó possui caracteŕısticas que facilitam o gerenciamento, como: servidor de FTP e acesso remoto. O desenvolvimento do nó de rede embarcado, padronizado pela norma IEEE 1451, possibilita maior flexibilidade de implantação em locais remotos e facilita a ampliação do sistema sem efetuar grandes modificações na rede. Uma caracteŕıstica importante é a dinâmica de desenvolvimento em relação ao hardware implementado no FPGA com o processador Nios II, sendo posśıvel desenvolver sistemas utilizando apenas os recursos necessários para cada aplicação. Além das caracteŕısticas de hardware, outro aspecto foi a implementação do sistema operacional embarcado em uma arquitetura dinâmica, disponibilizando uma flexibilidade ao sistema, ampliando a área de pesquisa e apresentando uma nova metodologia de desenvolvimento do padrão IEEE 1451. Palavras chave: IEEE 1451. Interfaces. NCAP. Nios II. RS-232. Sistema operacional embarcado. TIM. Transdutores inteligentes, μClinux, ZigBee. Abstract The operating systems have a key role in microcomputers, performing interfacing between applications and the hardware. In addition to computers, currently embedded operating systems are employed in an environment with restricted architecture, such as microcontrollers, terming them as embedded operating systems. Some of the applications for embedded operating systems are geared for smart transducer networks, making the management and control system in which it operates. This work presents the development of a network node denominated NCAP using the DE2 kit and embedded operating system μClinux for monitoring and control of TIMs with different interfaces based on IEEE 1451. The NCAP has developed the characteristic connection of different TIMs with monitoring and control capabilities with different communication interfaces, wired (RS-232) and wireless (ZigBee). The testing, four TIMs were developed with different characteristics, as follows: 2 STIMs (IEEE P1451.2) and two WTIMs (IEEE 1451.5). The tests were performed using an external network interface, Ethernet, that through the PC, you can access the web page in an embedded server installed on the network node NCAP. This makes it possible to perform control and monitoring of transducers connected to the TIM interface regardless of wireless or wired. In addition to access to the transducers, the node has features that facilitate the management, such as FTP server and remote access. The development of embedded network node, standardized by IEEE 1451, allows for greater flexibility of deployment in remote locations and facilitates the expansion of the system without making major changes in the network. An important feature is the dynamic development in relation to the hardware implemented in FPGA with Nios II processor, it is possible to develop systems using only the resources required for each application. Another important work was the implementation of embedded operating system in a dynamic architecture, providing flexibility to the system, expanding the search area and presenting a new methodology for the development of IEEE 1451. Keywords: Embedded operating system. IEEE 1451. Interfaces. NCAP. Nios II. RS-232. Smart transducers. TIM. μClinux. ZigBee. Lista de Figuras 1 Evolução das redes de transdutores inteligentes. . . . . . . . . . . . . . . . 29 2 Diagrama da famı́lia do padrão IEEE 1451. . . . . . . . . . . . . . . . . . . 47 3 Bloco NCAP genérico com as principais descrições. . . . . . . . . . . . . . 49 4 Hierarquia de classes do padrão IEEE 1451. . . . . . . . . . . . . . . . . . 50 5 Modelo do padrão IEEE P1451.2. . . . . . . . . . . . . . . . . . . . . . . . 52 6 Modelo do padrão IEEE 1451.3. . . . . . . . . . . . . . . . . . . . . . . . . 53 7 Modelo do padrão IEEE 1451.4. . . . . . . . . . . . . . . . . . . . . . . . . 53 8 Camada de enlace e camada f́ısica. . . . . . . . . . . . . . . . . . . . . . . 54 9 Modelo do padrão IEEE 1451.5. . . . . . . . . . . . . . . . . . . . . . . . . 55 10 Modelo do padrão IEEE P1451.6. . . . . . . . . . . . . . . . . . . . . . . . 56 11 Modelo do padrão IEEE 1451.7. . . . . . . . . . . . . . . . . . . . . . . . . 56 12 Transmissão serial śıncrona. . . . . . . . . . . . . . . . . . . . . . . . . . . 59 13 Transmissão serial asśıncrona. . . . . . . . . . . . . . . . . . . . . . . . . . 59 14 Nı́vel de tensão utilizado pelo padrão RS-232. . . . . . . . . . . . . . . . . 61 15 Mestre/escravo utilizando barramento SPI. . . . . . . . . . . . . . . . . . . 62 16 Camadas utilizadas pelo padrão ZigBee baseado no modelo OSI. . . . . . . 63 17 Topologia estrela utilizada nas redes ZigBee. . . . . . . . . . . . . . . . . . 65 18 Topologia mesh utilizada nas redes sem fio ZigBee. . . . . . . . . . . . . . 66 19 Topologia estrela utilizada nas redes Ethernet. . . . . . . . . . . . . . . . . 67 20 Quadro Ethernet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 21 Interface do ambiente SoPC Builder. . . . . . . . . . . . . . . . . . . . . . 72 22 Exemplo de código em Verilog no ambiente Quartus II. . . . . . . . . . . . 74 23 Definição dos processadores no ambiente de desenvolvimento SoPC Builder. 75 24 Etapas de desenvolvimento em ambiente EDA. . . . . . . . . . . . . . . . . 78 25 Kit DE1 Altera. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 26 Kit DE2 Altera. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 27 Mecanismo de execução do CGI. . . . . . . . . . . . . . . . . . . . . . . . . 80 28 Ambiente de desenvolvimento Nios II. . . . . . . . . . . . . . . . . . . . . . 82 29 Exemplo de código em C para acesso aos periféricos no ambiente μClinux. 83 30 Exemplo de TIM baseado no padrão IEEE P1451.2. . . . . . . . . . . . . . 85 31 Diagrama de estado de operação do TIM. . . . . . . . . . . . . . . . . . . . 86 32 Diagrama de estado de operação do TransducerChannel. . . . . . . . . . . 86 33 Diagrama de bloco do STIM 1. . . . . . . . . . . . . . . . . . . . . . . . . 87 34 STIM 1 desenvolvido em laboratório. . . . . . . . . . . . . . . . . . . . . . 88 35 Diagrama de bloco do STIM 2. . . . . . . . . . . . . . . . . . . . . . . . . 88 36 STIM 2 desenvolvido em laboratório. . . . . . . . . . . . . . . . . . . . . . 89 37 Diagrama de bloco do WTIM 1. . . . . . . . . . . . . . . . . . . . . . . . . 90 38 WTIM 1 desenvolvido em laboratório. . . . . . . . . . . . . . . . . . . . . 90 39 Diagrama de bloco do WTIM 2. . . . . . . . . . . . . . . . . . . . . . . . . 91 40 WTIM 2 desenvolvido em laboratório. . . . . . . . . . . . . . . . . . . . . 91 41 Protocolo de requisição de controle do motor de passo. . . . . . . . . . . . 92 42 Protocolo de resposta de controle do motor de passo. . . . . . . . . . . . . 92 43 Protocolo de requisição da temperatura. . . . . . . . . . . . . . . . . . . . 92 44 Protocolo de resposta da temperatura referente ao WTIM 1. . . . . . . . . 93 45 Protocolo de requisição de controle do motor CC. . . . . . . . . . . . . . . 93 46 Protocolo de resposta do controle do motor CC referente ao WTIM 1. . . . 93 47 Sistema baseado na estrutura de camadas do modelo OSI. . . . . . . . . . 96 48 Esquemático do sistema implementado em laboratório. . . . . . . . . . . . 96 49 Estrutura para o desenvolvimento do hardware do nó de rede IEEE 1451.1. 98 50 Ambiente SoPC Builder com os módulos definidos para o desenvolvimento do nó de rede embarcado. . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 51 Interface de configuração do módulo UART. . . . . . . . . . . . . . . . . . 100 52 Mapa do endereçamento do projeto. . . . . . . . . . . . . . . . . . . . . . . 100 53 Bloco dos módulos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 54 Ambiente Quartus II com código verilog. . . . . . . . . . . . . . . . . . . . 102 55 Configurações das variáveis dos pinos de entrada e sáıda da interface UART.103 56 Funções de entrada e sáıda da interface UART. . . . . . . . . . . . . . . . 103 57 Funções das interfaces SPI e Ethnernet. . . . . . . . . . . . . . . . . . . . . 103 58 Configurações das variáveis dos pinos de entrada e sáıda. . . . . . . . . . . 104 59 Funções de acesso aos pinos de entrada e sáıda. . . . . . . . . . . . . . . . 104 60 Configuração dos pinos da FPGA referente ao controlador Ethernet. . . . . 104 61 Configuração dos pinos dos controladores UART 0, UART 1 e UART 2. . 105 62 Configuração dos pinos do controlador SPI. . . . . . . . . . . . . . . . . . . 105 63 Análise dos componentes utilizados no projeto. . . . . . . . . . . . . . . . . 105 64 Interface principal de configuração. . . . . . . . . . . . . . . . . . . . . . . 106 65 Interface de definição do hardware. . . . . . . . . . . . . . . . . . . . . . . 107 66 Exemplo de suporte oferecido pelo μClinux aos diversos fabricantes. . . . . 107 67 Opções de configuração do μClinux. . . . . . . . . . . . . . . . . . . . . . . 107 68 Bibliotecas de configuração dos periféricos. . . . . . . . . . . . . . . . . . . 108 69 Configuração dos aplicativos do μClinux. . . . . . . . . . . . . . . . . . . . 108 70 Sub-blocos do componente BusyBox. . . . . . . . . . . . . . . . . . . . . . 109 71 Componentes dispońıveis no sub-bloco Coreutils. . . . . . . . . . . . . . . . 109 72 Opção de seleção do processador e memória de armazenamento. . . . . . . 111 73 Interface usuário para programação do projeto na FPGA. . . . . . . . . . . 111 74 Definição da interface de comunicação entre o microcomputador e o kit DE2.112 75 Interface usuário da licença do ambiente Quartus II. . . . . . . . . . . . . . 112 76 Mensagem apresentada pelo Quartus II referente à licença. . . . . . . . . . 113 77 Exemplo de transferência do arquivo sof. . . . . . . . . . . . . . . . . . . . 113 78 Transferência da imagem do μClinux para o kit Nios II. . . . . . . . . . . . 113 79 Sistema operacional μClinux sendo inicializado. . . . . . . . . . . . . . . . 114 80 Sistema operacional μClinux em modo de comando. . . . . . . . . . . . . . 115 81 Informações da CPU visualizadas através do ambiente μClinux. . . . . . . 115 82 Interrupções visualizadas através do ambiente μClinux. . . . . . . . . . . . 115 83 Versão do sistema operacional μClinux. . . . . . . . . . . . . . . . . . . . . 116 84 Dispositivos do nó de rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 85 Configuração da rede Ethernet. . . . . . . . . . . . . . . . . . . . . . . . . 117 86 Comandos para manipulação do servidor FTP. . . . . . . . . . . . . . . . . 117 87 Transferência de arquivo para o servidor FTP. . . . . . . . . . . . . . . . . 117 88 Arquivos de configuração do ambiente μClinux. . . . . . . . . . . . . . . . 118 89 Diretório de armazenamento das páginas web no ambiente μClinux. . . . . 118 90 Página web armazenada no μClinux. . . . . . . . . . . . . . . . . . . . . . 119 91 Interface principal do software NCAP. . . . . . . . . . . . . . . . . . . . . 120 92 Interface de descrição dos comitês do padrão IEEE 1451. . . . . . . . . . . 120 93 Fluxograma da leitura dos TEDS. . . . . . . . . . . . . . . . . . . . . . . . 121 94 Interface de seleção da leitura dos TEDS. . . . . . . . . . . . . . . . . . . . 121 95 Exemplo de leitura dos TEDS armazendas em arquivo no NCAP. . . . . . 122 96 Descrição dos TEDS referente ao módulo STIM1 RS232. . . . . . . . . . . 123 97 Campos para controle ou monitoramento dos transdutores conectados ao TIM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 98 Fluxograma do software de acesso aos transdutores inteligentes. . . . . . . 124 99 Forma de onda do comando enviado do NCAP para o STIM1 RS232. . . . 124 100 Forma de onda do comando enviado do STIM1 RS232 para o NCAP. . . . 124 101 Resposta do módulo STIM1 RS232 referente a temperatura. . . . . . . . . 125 102 Forma de onda do comando enviado do NCAP para o STIM1 RS232. . . . 125 103 Forma de onda do comando enviado do STIM1 RS232 para o NCAP. . . . 125 104 Resposta do módulo STIM1 RS232 referente ao motor de passo. . . . . . . 126 105 Forma de onda do comando enviado do NCAP para o WTIM1 ZigBee. . . 126 106 Forma de onda do comando enviado do WTIM1 ZigBee para o NCAP. . . 126 107 Resposta do módulo WTIM1 ZigBee referente ao controle do motor CC. . 127 108 Foto do sistema desenvolvido em laboratório. . . . . . . . . . . . . . . . . . 127 D.1 Sensor LM35 visualizado de cima. . . . . . . . . . . . . . . . . . . . . . . . 171 D.2 Foto do motor de passo utilizado em laboratório. . . . . . . . . . . . . . . 172 E.1 Circuito STIM 1 desenvolvido em laboratório. . . . . . . . . . . . . . . . . 174 E.2 Circuito STIM 2 desenvolvido em laboratório. . . . . . . . . . . . . . . . . 175 E.3 Circuito WTIM 1 desenvolvido em laboratório. . . . . . . . . . . . . . . . 176 E.4 Circuito WTIM 2 desenvolvido em laboratório. . . . . . . . . . . . . . . . 177 F.1 Módulo XBee-Pro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 F.2 Módulo CON-USBee. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 F.3 Módulo CON-USBee com XBee-Pro conectado ao microcomputador. . . . 179 F.4 Interface usuário apresentada pelo ambiente X-CTU. . . . . . . . . . . . . 179 F.5 Teste de comunicação com módulo CON-USBee. . . . . . . . . . . . . . . . 180 F.6 Interface usuário de configuração do módulo XBee-Pro. . . . . . . . . . . . 180 F.7 Definição do nome do módulo XBee-Pro. . . . . . . . . . . . . . . . . . . . 181 F.8 Configuração da velocidade de transmissão do módulo XBee-Pro. . . . . . 181 F.9 Configuração do buffer de caracteres. . . . . . . . . . . . . . . . . . . . . . 182 Lista de Tabelas 1 Formato padrão dos TEDS. . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2 Ordem de transmissão dos dados. . . . . . . . . . . . . . . . . . . . . . . . 44 3 Exemplo de bit mais significante e menos significante. . . . . . . . . . . . . 44 4 Estrutura de uma mensagem de comando . . . . . . . . . . . . . . . . . . . 45 5 Classe de comando. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6 Comando de operação do transdutor. . . . . . . . . . . . . . . . . . . . . . 46 7 Mensagem de comando de resposta. . . . . . . . . . . . . . . . . . . . . . . 46 8 Relação de frequência máxima em MHz entre os processadores Nios II. . . 75 9 Relação das MIPS de acordo com cada processador Nios II. . . . . . . . . . 76 10 Caracteŕıstica de cada kit DE. . . . . . . . . . . . . . . . . . . . . . . . . . 79 C.1 Meta-TEDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 C.2 TransducerChannel TEDS - LM35. . . . . . . . . . . . . . . . . . . . . . . 157 C.3 TransducerChannel TEDS - Motor de passo 1. . . . . . . . . . . . . . . . . 161 C.4 User’s Transducer Name TEDS. . . . . . . . . . . . . . . . . . . . . . . . . 162 C.5 PHY TEDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 C.6 Meta-TEDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 C.7 TransducerChannel TEDS - Ventilador 1. . . . . . . . . . . . . . . . . . . . 165 C.8 User’s Transducer Name TEDS. . . . . . . . . . . . . . . . . . . . . . . . . 166 C.9 Meta-TEDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 C.10 User’s Transducer Name TEDS. . . . . . . . . . . . . . . . . . . . . . . . . 167 C.11 PHY TEDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 C.12 Meta-TEDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 C.13 User’s Transducer Name TEDS. . . . . . . . . . . . . . . . . . . . . . . . . 170 D.1 Passo completo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 D.2 Meio passo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Lista de Abreviaturas e Siglas A/D Analogic/Digital ABS Antilock Braking System ADC Aanalogic-to-Digital Converter AGC Apollo Guidance Computer ATM Asynchronous Transfer Mode BCPL Basic Combined Programming Language bps Bits por segundo CAN Controller Area Network CC Corrente Cont́ınua CGI Common Gateway Interface CI Circuito Integrado CiA DS 404 CAN in Automation – Device Specification 404 CMOS Complementary Metal-Oxide Semiconductor CPLD Complex Programmable Logic Device CPU Central Processing Unit CRC Cyclic Redundancy Code CSMA/CD Carrier Sense Multiple Access with Collision Detection D/A Digital/Analogic DDR DRAM Double Data Rate Dynamic Random-Access Memory DE1 Development Education 1 DE2 Development and Education 2 DMA Direct Memory Access DMC Distributed Measurement and Control DSSS Direct-Sequence Spread Spectrum eCos Embedded Configurable Operating System EDA Environmental Development Association EIA Electronic Industries Alliance EPCS Embedded Programming the Serial Configuration Chip EPOS Embedded Parallel Operating System FDDI Fiber Distributed Data Interface FFDs Full Function Devices FHSS Frequency-Hopping Spread Spectrum FPGA Field-Programmable Gate Array FTP File Transfer Protocol GHz Giga-Hertz GPS Global Positioning System HCPLD High Complex Programmable Devices HTML HyperText Markup Language HTTP HyperText Transfer Protocol I/O Input/Output – Entrada/Sáıda I2C Inter-Integrated Circuit ID Identification IEEE Institute Of Electrical And Electronics Engineers - Instituto de Engenheiros Eletricistas e Eletrônicos IP Internet Protocol IR Infrared IrDa Infrared Data Association IRQ Interrupt Request ISM Industrial, Scientific and Medica ISO/IEC Organização Internacional para Padronização / Comissão Eletrotécnico Internacional JTAG Joint Test Action Group Kbps Kilobits Per Second LAN Local Area Network LCD Liquid Crystal Display LLC Logical Link Control mA Miliampère MAC Medium Access Control MB Mega Bytes MCI Module Communications Interface MCU Micro Controler Unit MHz Mega-Hertz MIMOSA Machinery Information Management Open Systems Alliance MIPS Millions of Instructions Per Second MISO Master In / Slave Out Pin MIT Massachusetts Institute of Technology MMI Mixed-Mode Interface MMU Memory Management Unit MOSI Master Out / Slave In Pin Mpbs Megabit Per Second NCAP Network Capable Application Processor NIST National Institute of Standards and Technology NTP Network Time Protocol OEMs Original Equipment Manufacturer OGC-SWE Open Geospatial Consortium Sensor Web Enablement OSA-CBM Open System Architecture for Condition Based Maintenance OSI Open Systems Interconnection OVI Open Verilog International PAN Personal Area Network PDAs Personal Assistant Digital PIC Programmable Interface Controller PID Process Identification PPP Point-to-Point Protocol PSRS Parallel Sorting by Regular Sampling PTP Precision Time Protocol PWM Pulse-Width Modulation RAM Random Access Memory RFDs Reduced Function Devices RFID Radio-Frequency Identification RISC Reduced Instructions Computer ROM Read Only Memory rpm Rotação por minuto RS-232 Recommended Standard-232 RTL Register Transfer Level SCADA Supervisory Control and Data Acquisition SCK Serial Clock Pin SD Card Secure Digital Card SDRAM Synchronous Dynamic Random Access Memory SNAP Scalable Node Address Protocol SOA Service-Oriented Architecture SoC Security Operations Center SoPC System on a Programmable Chip SPI Serial Peripheral. Interface SPIV3 Serial Peripheral Interface Bus Version 3 SRAM Static Random Access Memory SS Slave Select Pin STIM Smart Transducer Interface Module T/L/V Type/Length/Value TBC Transducer Bus Controller TBIM Transducer Bus Interface Module TCP/IP Transfer Control Protocol / Internet Protocol TEDS Transducer Electronic Data Sheet Telnet Telecommunications Network TII Transducer Independent Interface TIM Transducer Interface Module UART Universal Asynchronous Receiver/Transmitter UART-STIM Universal Asynchronous Receiver/Transmitter-Smart Tranducer Interface Module UFM User Flash Memory UML Unified Modeling Language USB Universal Serial Bus UUID Universal Unique Identifier Verilog HDL Verilog Hardware Description Language Verilog LRM Verilog Language Reference Manual VGA Video Graphics Array VHDL VHSIC Hardware Description Language Wi-Fi Wireless Fidelity WLAN Wireless Local Area Network WTIM Wireless Transducer Interface Module Sumário 1 Introdução 26 1.1 Redes Industriais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 1.2 Objetivos e Estratégias de Desenvolvimento . . . . . . . . . . . . . . . . . . . 29 1.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 1.4 Trabalhos Relacionados à Área . . . . . . . . . . . . . . . . . . . . . . . . . . 31 1.5 Organização do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2 O Padrão IEEE 1451 41 2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.2 O Padrão IEEE 1451.0 - 2007 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.2.1 Formato padrão dos TEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.2.2 Estrutura das Mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.2.3 Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.3 O Padrão IEEE 1451.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.3.1 Processador de Aplicação com Capacidade de Operar em Rede (NCAP) - IEEE 1451.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.3.1.1 Modelo de Informação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.3.1.2 Modelo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.3.1.3 Modelos de Comunicação em Rede . . . . . . . . . . . . . . . . . . . . . . 51 2.4 O Padrão IEEE P1451.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.5 O Padrão IEEE 1451.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.6 O padrão IEEE 1451.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.7 O padrão IEEE 1451.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.8 O padrão IEEE P1451.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 2.9 O padrão IEEE 1451.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.10 Considerações Finais Sobre o Caṕıtulo 2 . . . . . . . . . . . . . . . . . . . . . 56 3 Interfaces de Comunicação Utilizadas no Nó de Rede IEEE 1451 58 3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.2 Comunicação Serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.2.1 Bit Rate e Baud Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.2.2 O Padrão RS-232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.3 Serial Peripheral Interface Bus - SPI . . . . . . . . . . . . . . . . . . . . . . . 61 3.4 ZigBee - Padrão IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.4.1 Relação entre o ZigBee e o IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . 63 3.4.2 Tipos de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.4.3 Topologia de Rede ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.5 O Padrão IEEE 802.3 e a Ethernet . . . . . . . . . . . . . . . . . . . . . . . . 66 3.5.1 Estrutura do quadro Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.5.2 CSMA/CD:Carrier Sense Multiple Access with Collision Detection . . . . . 68 3.6 Considerações Finais Sobre o Caṕıtulo 3 . . . . . . . . . . . . . . . . . . . . . 69 4 Ferramentas Utilizadas no Desenvolvimento do Nó de Rede NCAP e dos TIMs 70 4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.2 Sistema Operacional Embarcado μClinux . . . . . . . . . . . . . . . . . . . . . 70 4.3 Ambiente SoPC Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.4 Verilog HDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.5 Processador Nios II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.6 Dispositivo Lógico Programável e a plataforma de Desenvolvimento DE2 . . . 77 4.7 O Servidor Boa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.8 Commom Gateway Interface - CGI . . . . . . . . . . . . . . . . . . . . . . . . 80 4.9 BusyBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.10 Os Microcontroladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.11 Linguagem C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.12 Considerações Finais Sobre o Caṕıtulo 4 . . . . . . . . . . . . . . . . . . . . . 83 5 Descrição dos TIMs Desenvolvidos para Testes com o Nó de Rede Embarcado NCAP 84 5.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.2 Descrição Geral de Desenvolvimento dos TIMs - IEEE 1451 . . . . . . . . . . 84 5.3 Smart Transducer Interface Module - STIM . . . . . . . . . . . . . . . . . . . 87 5.4 Wireless Transducer Interface Module - WTIM . . . . . . . . . . . . . . . . . 89 5.5 Testes realizados com os STIMs e WTIMs . . . . . . . . . . . . . . . . . . . . 91 5.6 Considerações Finais Sobre o Caṕıtulo 5 . . . . . . . . . . . . . . . . . . . . . 94 6 Desenvolvimento do Nó de Rede IEEE 1451.1 95 6.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.2 O Nó IEEE 1451.1 Embarcado . . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.3 Descrição do Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 6.3.1 Definição e Configuração do Hardware . . . . . . . . . . . . . . . . . . . . . 98 6.4 Sistema Operacional Embarcado . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.4.1 Interface de Configuração (make menuconfig) . . . . . . . . . . . . . . . . . 106 6.4.2 Transferência do Hardware e da Imagem para Kit de Desenvolvimento DE 2 110 6.5 Ambiente μClinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 6.6 Software NCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 7 Conclusões Gerais 128 7.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 7.2 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 7.3 Sugestões de Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Referências 132 A μClinux-dist 137 A.1 Instalação do μClinux-dist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 A.2 Configuração da imagem do μClinux . . . . . . . . . . . . . . . . . . . . . . . 139 A.2.1 Configuração das Interfaces UART no Ambiente uClinux-dist . . . . . . . . 140 A.2.2 Configuração da Interface SPI no Ambiente uClinux-dist . . . . . . . . . . . 141 A.2.3 Configuração do Servidor Web, FTP e Acesso Remoto Telnet . . . . . . . . 142 A.2.4 Compilação de arquivos em linguagem C para ambiente μClinux . . . . . . . 143 B Comandos de Leitura e Controle 144 B.1 Comando para Monitoramento e Controle do Módulo STIM 1 . . . . . . . . . 144 B.2 Comando para Monitoramento e Controle do Módulo STIM 2 . . . . . . . . . 146 B.3 Comando para Monitoramento e Controle do Módulo WTIM 1 . . . . . . . . 148 B.4 Comando para Monitoramento e Controle do Módulo WTIM 2 . . . . . . . . 149 B.5 Comandos de Requisição e Resposta dos TEDS . . . . . . . . . . . . . . . . . 150 C Transducer Eletronic Data Sheet 153 C.1 STIM 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 C.1.1 Meta-TEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 C.1.2 TransducerChanel TEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 C.1.2.1 Sensor LM35 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 C.1.2.2 Motor de passo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 C.1.2.3 Motor de passo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 C.1.3 User’s Transducer Name TEDS . . . . . . . . . . . . . . . . . . . . . . . . . 160 C.1.4 PHY TEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 C.2 STIM 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 C.2.1 Meta-TEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 C.2.2 TransducerChanel TEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 C.2.2.1 Ventilador 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 C.2.2.2 Ventilador 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 C.2.2.3 Ventilador 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 C.2.3 User’s Transducer Name TEDS . . . . . . . . . . . . . . . . . . . . . . . . . 164 C.2.4 PHY TEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 C.3 WTIM 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 C.3.1 Meta-TEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 C.3.2 TransducerChanel TEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 C.3.2.1 Sensor LM35 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 C.3.3 User’s Transducer Name TEDS . . . . . . . . . . . . . . . . . . . . . . . . . 166 C.3.4 PHY TEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 C.4 WTIM 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 C.4.1 Meta-TEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 C.4.2 TransducerChanel TEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 C.4.2.1 Sensor LM35 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 C.4.2.2 Motor CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 C.4.3 User’s Transducer Name TEDS . . . . . . . . . . . . . . . . . . . . . . . . . 170 C.4.4 PHY TEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 D Descrição dos Transdutores 171 D.1 LM35 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 D.2 Motor de Passo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 D.3 Ventiladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 D.4 Motor CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 E Cricuitos 174 E.1 Circuito STIM 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 E.2 Circuito STIM 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 E.3 Circuito WTIM 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 E.4 Circuito WTIM 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 F Configurações do Módulo XBee-Pro 178 26 Capı́tulo 1 Introdução Num microcomputador, para realizar o interfaceamento do usuário com o hardware, utiliza-se um software denominado sistema operacional, que é responsável pelo gerenciamento dos aplicativos no acesso ao hardware. Tais sistemas operacionais são desenvolvidos e aplicados em diferentes arquiteturas de microcomputadores, sem a necessidade de se preocupar com as caracteŕısticas de hardware. Diferentes dos microcomputadores, os dispositivos embarcados possuem uma arquitetura restrita, tal como de memória, interface com usuário (displays), I/O (Input/Output - entrada/sáıda) e ao processamento. Os softwares desenvolvidos para a implementação nesses dispositivos é dedicado e encapsulados no dispositivo realizando um conjunto de tarefas pré-definidas, geralmente com requisitos espećıficos. Os sistemas embarcados, muitas vezes, são utilizados para realizar o interfaceamento de transdutores (sensor/atuador) e microcomputadores, ou simplesmente para a manipulação de um dispositivo ou a realização da aquisição de dados. Como exemplo de aplicações utilizando sistemas embarcados, têm-se: • Medicina: – Máquinas de hemodiálise, monitores card́ıacos e máquinas de Raio-X. • Aparelhos domésticos: – Televisores analógicos e digitais, PDAs (Personal Digital Assistent), celulares, VOIP (Voice Over Internet Protocol), jogos, brinquedos, câmeras e GPS (Global Position System). • Periféricos de computadores: 27 – Roteadores, switches, gateways, impressoras, scanners. • Automotivo: – Ignição, sistema de freio ABS (Antiblockier-Bremssystem). • Instrumento Musical: – Sintetizadores, pianos. • Aeroespacial: – Sistema de navegação. • Agricultura: – Tratores e implementos agŕıcolas. O gerenciamento e o acesso ao hardware dos dispositivos embarcados podem ser realizados utilizando um sistema operacional embarcado, que é empregado utilizando microcontrolador, microprocessadores ou FPGA (Field Programmable Gate Array), tecnologia denominada SoC (System-on-Chip). Os sistemas operacionais embarcados são responsáveis por realizar o gerenciamento de I/O, memórias, processadores, entre outros, além de oferecerem uma máquina virtual que tem como objetivo mascarar as rotinas de acesso ao hardware. Como exemplos de sistemas operacionais embarcados, têm- se: μClinux (JUNQUEIRA, 2007), eCos(Embedded Configurable Operating System) (ECOS, 2002), Windows XP embedded (STADZISZ, 2003), e C Executive (SYSTEMS, 1998). Atualmente, os sensores e atuadores são utilizados em conjunto com os sistemas embarcados, denominando-os como transdutores inteligentes, e são utilizados no controle ou/e na aquisição dos dados em sistemas DMC (Distributed Measurement and Control). O desenvolvimento de sistemas DMC demanda um grande esforço por parte de engenheiros e projetistas da área de instrumentação, sendo que alguns desses sistemas são desenvolvidos para uma determinada aplicação, utilizando ferramentas de alto custo e softwares proprietários. Uma caracteŕıstica de sistema que surgiu no ińıcio da década de 80, com a evolução das comunicações digitais na área de automação industrial. Tais sistemas de interconexão possibilitaram a comunicação digital bidirecional trabalhando com um determinado protocolo, permitindo troca de informação entre os módulos de transdutores inteligentes. Este fato facilitou o avanço na automação industrial, porém, surgiram inúmeros problemas, como, por exemplo, o interfaceamento dos transdutores e as diferentes tecnologias de rede (SONG et al., 2011). 28 Ao analisar os esforços no desenvolvimento de sistemas DMC, no ińıcio da década de 90, foram aprovadas as primeiras diretrizes para o padrão IEEE (Institute of Electrical and Electronic Engineers) 1451, um padrão de interfaceamento para transdutores inteligentes. As diretrizes foram desenvolvidas pelo IEEE em parceria com o NIST (National Institute of Standards and Technology), para a conexão de transdutores inteligentes em rede. Após essa parceria entre a NIST e a IEEE, diversos Workshops e congressos foram realizados definindo, assim, conceitos no padrão IEEE 1451. Hoje, o padrão IEEE 1451 possui diversos conceitos de como conectar transduores em rede e é dividido nos seguintes comitês: IEEE 1451.0, IEEE 1451.1, IEEE P1451.2, IEEE 1451.3, IEEE 1451.4, IEEE 1451.5, IEEE P1451.6 e IEEE 1451.7 (SONG et al., 2011). O estudo da tecnologia dos dispositivos embarcados e o gerenciamento de hardware através dos sistemas operacionais embarcados norteou o desenvolvimento do NCAP (Network Capable Application Processor), com diferentes caracteŕısticas e funcionalidades. Tal NCAP foi capaz de obter dados de uma rede externa e interagir com módulos de transdutores inteligentes utilizando diferentes interfaces de comunicação de acordo com os comitês IEEE P1451.2 e IEEE 1451.5. O hardware e o sistema operacional embarcado implementado para o desenvolvimento do no nó de rede foram definidos de forma dinâmica baseando-se na norma definida pelo padrão IEEE 1451 e nas caracteŕısticas das interfaces de comunicação. Na Seção 1.1 apresenta-se um breve historico das redes industriais e sua evolução. 1.1 Redes Industriais A competitividade e a busca constante de minimização de custos nas fábricas demonstram o constante e acelerado desenvolvimento na área de automação industrial. Durante a década de 40, a instrumentação dos processos industriais era realizada utilizando ar-comprimido trabalhando com faixas de valores analógicos entre 3-15 psi1, para realizar o controle e o monitoramento dos equipamentos (LIMA, 2004). Com a evolução dos sistemas eletrônicos, a década de 60 ficou marcada pelo surgimento de sinais analógicos elétricos, trabalhando com uma faixa de valores de 4-20 mA (miliampère). Na década de 70, os microcomputadores foram introduzidos nas fábricas de forma centralizada, realizando a aquisição de dados e controlando dispositivos. A partir desta década, também começaram a surgir os primeiros softwares SCADA (Supervisory Control and Data Acquisition), possuindo diversas funcionalidades e podendo ser aplicados 1psi - libra por polegada quadrada, unidade de medida americana. 29 em diferentes sistemas operacionais (LIMA, 2004). No decorrer dos anos, com o avanço da tecnologia de integração de componentes eletrônicos, foram surgindo microprocessadores cada vez mais poderosos e com menor custo financeiro. Com isso, cada transdutor passou a ser implementado com processador dedicado, dando origem a um novo conceito de transdutores, denominado de transdutores inteligentes. Implementar diversos tipos de transdutores em uma rede buscando melhorar o desempenho, com maior quantidade e qualidade dos dados, tornou-se posśıvel, dando origem ao barramento de campo (LIMA, 2004). Com o avanço da tecnologia do barramento de campo, muitas empresas passaram a desenvolver sua própria rede de transdutores baseando-se apenas nos seus interesses, acarretando, assim, outros problemas, como o interfaceamento dos transdutores e as diferentes tecnologias de rede (LIMA, 2004). Na Figura 1, é ilustrada a evolução das redes de transdutores demonstrando a década, o protocolo utilizado e a caracteŕıstica do sistema. Figura 1 – Evolução das redes de transdutores inteligentes. Fonte: Lima (2004) 1.2 Objetivos e Estratégias de Desenvolvimento O objetivo principal do presente trabalho é o desenvolvimento de um nó de rede capaz de obter dados de uma rede externa, independente de tecnologia ou protocolo de comunicação, processar esses dados e enviar para uma de suas interfaces de comunicação com TIM (Transducer Interface Module), para realizar a leitura ou o controle dos transdutores inteligentes, de acordo com o padrão IEEE 1451. 30 No desenvolvimento do nó de rede, foi utilizado o ambiente SoPC Builder (System on a Programmable Chip), permitindo ao projetista definir a arquitetura do nó, de acordo com as caracteŕısticas do sistema, utilizando componentes pré-definidos. Para a implementação e testes do sistema foi utilizado o kit DE2 que possui interfaces de comunicação para outros dispositivos, pinos de I/O, dispositivo lógico programável e memórias. Além das caracteŕısticas de hardware dinâmico, o nó de rede foi desenvolvido utilizando o sistema operacional μClinux, que possui código aberto, gratuito e dinâmico, tendo sido gerado baseado nas caracteŕısticas de hardware e de acordo com a necessidade da aplicação em que será utilizado. O sistema operacional possui caracteŕısticas semelhantes a um sistema operacional Linux voltado para microcomputadores, porém, todos os seus comandos básicos devem ser definidos na compilação do kernel do sistema. Tais caracteŕısticas de hardware e do sistema operacional embarcado, oferecem suporte ao desenvolvimento de um nó de rede baseado na norma IEEE 1451 com diferentes interfaces de forma dinâmica e que possa ser aplicada em diversos ambientes em condições adversas. Para os testes do nó de rede, foram desenvolvidos módulos TIMs, utilizando interface com fio baseado no padrão IEEE P1451.2 e sem fio baseado no padrão IEEE 1451.5. O objetivo foi verificar a integridade dos dados e do nó de rede utilizando diferentes interfaces de comunicação. Outro aspecto avaliado foi a capacidade de plug and play, em que, ao conectar o TIM no nó de rede NCAP, as informações dos TEDS (Transducer Electronic Data Sheet) são transferidas para o NCAP realizando o reconhecimento dos transdutores. Para o controle e monitoramento de transdutores inteligentes, o usuário pode acessar o sistema através de páginas web, pois, através do servidor Boa, foi posśıvel disponibilizar páginas web no nó de rede embarcado. Para realizar as configurações do sistema, o administrador da rede pode acessar o nó de rede através do acesso remoto, utilizando o protocolo Telnet (Telecommunications Network) disponibilizando acesso independente do ponto da rede. 1.3 Justificativa Um sistema de instrumentação e controle distribúıdo, utilizando o padrão de comunicação (IEEE 1451) e a filosofia de sistemas abertos, tem caracteŕısticas como flexibilidade, interoperabilidade, plug and play e reutilização de códigos. Utilizando o padrão IEEE 1451, as indústrias poderão obter inúmeros benef́ıcios como a redução de custos de sistemas de instrumentação, maior flexibilidade e facilidade na implementação de novos módulos. Além das indústrias, o nó de rede pode ser aplicado em diversas outras 31 áreas como a biomédica, telemedicina e automação residencial. As diferentes formas de conexões entre o NCAP e TIMs para os sistemas de instrumentação e controle distribúıdo norteiam o desenvolvimento de um nó NCAP com capacidade de interligar com diferentes blocos TIMs através de diferentes interfaces de comunicação. Para o nó de rede NCAP, a descrição de um hardware dinâmico e a instalação de um sistema operacional μClinux minimizam os custos de desenvolvimento e facilitam o gerenciamento dos processos, além de realizar o controle dos dados enviados através de uma rede externa. A criação de diferentes TIMs, para realizar a comunicação com um único NCAP através de diferentes interfaces (padrão IEEE 1451), facilita a implantação do sistema para realização de diferentes funcionalidades, por exemplo, o controle de um motor de passo, utilizando rede cabeada, padrão IEEE P1451.2 e o monitoramento da temperatura de uma estufa utilizando rede sem fio padrão IEEE 1451.5. Outro fator que viabiliza o sistema é a caracteŕıstica plug and play dos TIMs, sendo que, para cada ambiente, pode ser adicionado um novo módulo (IEEE P1451.2 e IEEE 1451.5) no NCAP embarcado, independente da interface de comunicação, para que possa realizar o controle ou o monitoramento dos transdutores, de acordo com o padrão IEEE 1451. 1.4 Trabalhos Relacionados à Área Na área dos sistemas operacionais embarcados, um trabalho que teve contribuição relevante foi o de Bueno, Brasil e Marques (2007). Trata-se da implementação de um sistema operacional embarcado eCos no kit Nios II Altera, para avaliação do desempenho do processador Nios II, operando com processamento paralelo. Para analisar o desempenho do processador Nios II, foram utilizados três algoritmos, sendo dois de ordenação, o PSRS (Parallel Sorting by Regular Sampling) e Quicksort e um algoritmo de multiplicação de matrizes. Os experimentos que foram realizados demonstraram as caracteŕısticas em relação à eficiência e speedup, sendo que foram obtidos os melhores resultados no algoritmo de ordenação PRSR. O trabalho apresentou também a facilidade de se implementar processamento paralelo em ambiente embarcado, como por exemplo, em sistema de robótica embarcada, cujos algoritmos necessitam de uma grande quantidade de processamento. Junqueira (2007) apresentou a implementação do sistema operacional μClinux, utilizando o kit de desenvolvimento Nios II como proposta de desenvolvimento de um PDA (Personal Digital Assistant). Como primeiro passo, foi definida a arquitetura do 32 hardware no ambiente SoPC Builder. Após a definição da arquitetura, realizou-se a compilação do kernel do μClinux, com a arquitetura de descrição de hardware gerada pelo SoPC Builder, através de um arquivo que contém a descrição do hardware. Ao gerar a imagem do μClinux, os arquivos foram transferidos para o kit de desenvolvimento Nios II através do modo de comando disponibilizado pelo software Nios IDE (Integrated Drive Electronics). Ao finalizar a transferência do hardware e da imagem para a placa, foram realizados testes de visualização do ambiente gráfico através da sáıda VGA (Video Graphics Adapter) e de um monitor de microcomputador, conexão com a rede Ethernet, utilizando o microcontrolador DM9000A, apresentação do servidor web e transferência de arquivo através do protocolo FTP (File Transfer Protocol). No trabalho de Lutz e Faerber (2009), foi apresentada a arquitetura do dispositivo Nios II, suas caracteŕısticas, como montar um processador Nios II com periféricos, instalação das ferramentas de compilação do sistema operacional embarcado μClinux. No trabalho, apresentaram-se as interfaces UART (Universal Asynchronous Receiver/Transmitter) e Ethernet. Os autores também descreveram a implementação do compilador do sistema operacional μClinux em ambiente Linux, ferramentas como Toolchain, bibliotecas necessárias para a compilação e escolha dos comandos e software para o ambiente de trabalho. Descreveram testes desenvolvidos no kit de desenvolvimento Nios II com sistema operacional μClinux, testes de acesso aos periféricos, serviços de rede e configurações dos periféricos. Wiedenhoft, Hoeller e Frohlich (2007) apresentaram o desenvolvimento de um gerenciador de energia, utilizando o sistema operacional embarcado EPOS (Embedded Parallel Operating System). O trabalho também abordou as caracteŕısticas do sistema EPOS e a importância do gerenciamento de energia em sistemas embarcados. Apesar de utilizar o sistema EPOS, o gerente é um software à parte para controle de energia. Os testes foram realizados utilizando um microcontrolador ATMega16 da Atmel e vários testes foram realizados como, equipamento desligado, aplicação sem gerência de energia, com gerência de energia dirigida pela aplicação, disponibilizada pela infraestrutura de gerência EPOS e com o gerente de energia desenvolvida no trabalho. Os testes foram realizados utilizando aplicações determińısticas e não determińısticas. Com os resultados dos testes, o trabalho resultou em ummelhor resultado com aplicações não determińısticas. No trabalho de Thorne (2007) implementou-se o sistema operacional embarcado μClinux em uma placa com uma FPGA modelo 2c35 (Altera). O trabalho teve como objetivo desenvolver um driver para um teclado de 16 teclas para μClinux e realizar a análise de performance que o soft-core traz para os sistemas embarcados. O trabalho 33 apresentou as camadas de software e hardware, que foram implementadas, os comandos de compilação do kernel do μClinux e como adicionar módulos no sistema operacional. Para testes do sistema, ao desenvolver o driver para placa 2c35, foi instalado o sistema operacional μClinux em uma outra placa com uma FPGA modelo 1c12 e foi realizada a instalação do driver e reconhecido o dispositivo pelo sistema operacional. No trabalho de Sigla e Morris (2008), foram apresentados testes de comunicação entre dois NCAPs distintos, de acordo com as normas do padrão IEEE 1451. Os autores fizeram uma breve descrição do padrão IEEE 1451.1, padrão IEEE P1451.2 e apresentaram uma proposta de implementação entre dois blocos NCAPs conectados entre si em rede. No trabalho, foi apresentado o mecanismo utilizado para realizar a comunicação entre os dois NCAPs, na qual a mensagem é codificada e transmitida para o nó de destino, que decodifica essa informação localmente. Os autores fizeram também uma abordagem da quantidade de pacotes que são enviados por todas as operações na rede de transdutores e ressaltaram que os pacotes que são enviados entre nós devem conter um cabeçalho único e padronizado. O trabalho fez referência a três principais tipos de cabeçalho: pacote público, cliente/servidor e servidor/cliente. Os testes de comunicação entre os dois NCAPs foram apresentados através de relatórios, informando o que houve em cada pacote de comunicação como, por exemplo, identificação do endereço IP (Internet Protocol) e endereço MAC (Medium Access Control). Wobschall e Mupparaju (2008) desenvolveram em seu trabalho o protocolo SNAP (Scaleable Node Address Protocol) para transferência de dados entre o módulo NCAP e TIM, utilizando a interface RFID (Radio-Frequency Identification) de acordo com o padrão IEEE 1451. Para realização do trabalho, utilizaram um módulo PIC (Programmable Interface Controller) 12F675F, trabalhando com uma frequência de 433 MHz, um módulo Chipcon/TI CC1100 operando em 433 MHz e com interface serial RS-232 (Recommended Standard-232 ). No trabalho apresentado, os autores abordaram sobre as caracteŕısticas do protocolo SNAP, apresentaram o formato dos campos e as suas especificações. Os autores também relataram que, se dois sensores transmitem simultaneamente, os dados são perdidos. Se houver problemas com rúıdos resultando em erro no CRC, haverá perda de dados. Para testes do sistema, foram realizadas aquisições da temperatura em um intervalo de 5 minutos com uma bateria de 3 V, o tempo de permanência do sistema foi de 2 meses. Com os testes realizados, os autores puderam concluir que o consumo energia é 10 vezes menor, utilizando o protocolo SNAP. Wobschall (2008) apresentou em seu trabalho um NCAP desenvolvido em um microcomputador, realizando a comunicação entre o NCAP e o TIM através da interface 34 serial. O módulo de comunicação entre o NCAP e o microcomputador foi realizado utilizando a rede Ethernet e visualizando os dados através da Internet, usando um navegador web. Para esse modelo de rede de transdutores inteligentes, utilizou-se um sensor de temperatura e um fotodiodo (sensores) e um relê como atuador. Em outro exemplo disponibilizado pelo autor, implementou-se o padrão IEEE 1451.5, para realizar a comunicação entre o NCAP e WTIM (Wireless Transducer Interface Module), utilizando os mesmos módulos e os mesmos protocolos. Além dos testes realizados, o autor fez uma abordagem sobre as TEDS e sobre os softwares desenvolvidos no projeto. Song et al. (2011) desenvolveram um NCAP em um notebook capaz de realizar a comunicação com dois WTIMs, utilizando o padrão IEEE 1451.5-802.11 e o padrão IEEE 1451.0 para especificação dos TEDS e protocolos. No trabalho, os autores apresentaram testes realizados entre os dois blocos NCAP e WTIM, como reconhecimento dos módulos na rede, definindo um ID (Identification) e endereço IP para cada WTIM e o reconhecimento de todos os transdutores conectados nos módulos. Ao demonstrar os transdutores ativos, foram gerados gráficos das leituras dos sensores e apresentados os gráficos dos dados colhidos. Na conclusão os autores abordam as limitações da placa utilizada para o desenvolvimento dos WTIMs como o tamanho do buffer dispońıvel para o socket. Viegas, Pereira e Girao (2008) descreveram o padrão IEEE 1451 e suas principais caracteŕısticas, como o modelo de informação no qual é composto de uma hierarquia de classes dividido em três categorias principais: Block, Component e Service. No trabalho, foi descrito o modelo de dados, sendo: Boolean, Octet, Integer, Float, String e vetor de tipo de dados prévio, além da forma de comunicação em rede, sendo: um para um e um para muitos. Ao descrever as principais caracteŕısticas do padrão IEEE 1451.1, os autores descreveram os principais blocos dentro de cada classe (Block, Component e, Service) e para testes do sistema, foi feito um software de controle de ńıvel de água em um tanque. Os autores também descreveram que, apesar das vantagens do padrão IEEE 1451.1, ainda não existem NCAPs comerciais dispońıveis em mercado. Em Ramos (2008), a autora apresenta o desenvolvimento de um NCAP com duas interfaces USB (Universal Serial Bus) implementado em um microcomputador. Como primeiro passo do trabalho, a autora realiza uma breve descrição do padrão IEEE 1451, cada comitê e quando as normas foram aprovadas. A segunda parte do trabalho apresentou o desenvolvimento do sistema em que cada TIM foi implementado usando o microcontrolador Freescale (HC9S12DT256) e uma memória (AT24C64A). Para a realização da comunicação entre o NCAP e o TIM, foi necessário a instalação dos drivers 35 USB para o nó de interface do FTDI (FT232BL) e o software LabView. O protocolo utilizado para a comunicação entre o NCAP e o TIM foi PTP (Precision Time Protocol) descrito pelo padrão IEEE 1588 no qual a autora descreve as caracteŕısticas das mensagens e o tamanho. Na conclusão é apresentada as vantagens do uso da interface USB na comunicação entre o NCAP e o TIM e a possibilidade de desenvolvimento de interfaces multi-point no mesmo NCAP. No trabalho de Song e Lee (2010) apresentaram a comunicação entre o NCAP e o WTIM, utilizando o padrão IEEE 1451.5, utilizando a interface sem fio baseada no padrão IEEE 802.11. Os autores descreveram as mensagens, comandos padrões de controle do TIM, comandos comuns, como por exemplo: leitura dos TEDS, escrita dos TEDS, requisição dos comandos dos TEDS etc., e comandos de resposta para o NCAP, todos representados por diagrama de classe. Como caso de estudo, os autores apresentaram o reconhecimento dos módulos WTIMs e apresentaram cada passo para reconhecimento dos PHY TEDS em uma interface gráfica feita em Java, validando o reconhecimento dos módulos. Eccles (2008) apresentou um breve resumo de como são realizados os testes em aeronaves e como são obtidas essas medidas. Como parte da implementação do sistema para teste da estrutura e da reação destas estruturas para estas cargas, foram implementados 8000 sensores strain gauge. A prinćıpio eram utilizados cabos do sensor da aeronave até as sala de testes, realizando, assim, o condicionamento de sinal, armazenamento dos dados e análises. Para sanar o problema de instalação dos cabos em aeronaves, foram utilizados pequenos multiplexadores, em que os sensores são conectados nesses multiplexadores em que foi realizado o condicionamento do sinal e a digitalização. O autor ressalta também que o problema dos cabos geralmente é mais uma função de números de horas de trabalho requeridas no laboratório e instalação do que uma função de materiais, então, o custo de cabos curtos não é significantemente menor do que de um cabo longo. Entretanto, o custo da instalação de cabos curtos é menor do que em cabos longos. O autor descreve uma solução para resolver a problemática dos cabos, utilizando redes de sensores inteligentes, porém, outra questão é levantada: o caso de que as redes de comunicação não são determińısticas. Como resposta em relação ao tempo de resposta da rede, o autor sugere dois tipos de protocolo: NTP (Network Time Protocol) e PTP. Para o desenvolvimento da rede, o autor descreve como uma solução a implementação do padrão IEEE 1451, porém, apresenta também os aspectos que impedem a implementação da norma na indústria de véıculos e aerospacial e a dif́ıcil aceitação da indústria devido a custos e às grandes mudanças que devem ser realizadas. Como conclusão, o autor descreve que alguns testes e avaliações em aeroplanos utilizando redes de transdutores inteligentes já 36 estão sendo realizado, porém, são desenvolvido utilizando padrões proprietários. O autor também descreve que o uso do padrão IEEE 1451 pode sanar os problemas utilizando PTP padrão IEEE 1588 para realização de testes utilizando redes de transdutores inteligentes em aeroplanos. Tu (2009) apresentou um NCAP em linguagem C/C++ desenvolvido no ambiente C/C++ Builder 6.0. O TIM foi desenvolvido baseado no padrão IEEE P1451.2, utilizando FPGA Altera Max II Start Kit CPLD (Complex Programmable Logic Device). O foco do trabalho foi desenvolver uma interface UART com suporte a comunicação TII (Transducer Independent Interface), que é definida pelo padrão IEEE P1451.2. No trabalho, o autor definiu um novo nome para a interface, denominando-a UART-STIM (Universal Asynchronous Receiver/Transmitter - Smart Tranducer Interface Module). Para o suporte de diferentes tipos de frequência, como por exemplo: UART, controlador, UFM (User Flash Memory) e conversor A/D (Analogic/Digital), foi utilizado um divisor de frequência. O MAX II Start Kit utilizado possui um oscilador de 18.432MHz e, com os divisores de 10 e 2560, foi posśıvel obter 1.8432MHz para comunicação UART e 7.2KHz para UFM e conversores A/D. Para a comunicação do MAX II Starter Kit e o microcomputador, foi utilizado um circuito integrado denominado ICL3232 o qual possui as caracteŕısticas do padrão RS-232. O conversor utilizado foi MCP3001 que, a partir de um conjunto de dados digitais, é passado para o STIM, utilizando uma interface SPI (Serial Peripheral Interface Bus). Como apresentação dos resultados, foi realizada uma comparação com a temperatura real e a medida pelo sistema, obtendo uma variação máxima de erro de 0.5 graus, porém, a taxa de bytes perdidos na transferência foi de zero porcento em 96 Bytes. Higuera, Polo e Gasulla (2009) apresentaram em seu trabalho um NCAP (IEEE 1451.1) e um WTIM (IEEE 1451.5) utilizando a interface ZigBee. Os autores descreveram o módulo ZigBee (CC2420) utilizado para a comunicação e, de forma esquemática, a implementação do WTIM. Como parte do NCAP, foi descrita a interface desenvolvida em LabView, a qual inclui comandos de escrita e leitura para os transdutores, para os TEDS comandos de leitura, requisição e atualização. No trabalho de Higuera, Polo e Gasulla (2009), é importante ressaltar a descrição das PHY TEDS para a interface sem fio ZigBee em que apresentaram todas as caracteŕısticas relevantes da comunicação entre NCAP e WTIM, como por exemplo: protocolo de comunicação, frequência, distância máxima entre os módulos, tipo de antena, canais, quantidade de canais usados, especificação da bateria e modulação. Em Manda e Gurkan (2009) apresentaram um software desenvolvido em .Net Framework para a descrição das TEDS. Os autores descreveram os campos dos TEDS, 37 as obrigatórias e as opcionais e o fluxograma do processo de conversão dos dados dos sensores em valores hexadecimal. Finalizando as caracteŕısticas teóricas do sistema, os autores apresentaram o software e suas principais caracteŕısticas, como o cadastro dos transdutores baseado na norma IEEE 1451.0-2007 e a conversão dos dados para hexadecimal. Uma caracteŕıstica que o autor descreve é a facilidade de conversão das informações em dados hexadecimais para armazenamento em memória. Um trabalho que teve relevância para o desenvolvimento do nó de rede NCAP foi o de Lee e Song (2003) que desenvolveram uns dos primeiros modelos em UML (Unified Modeling Language) para o desenvolvimento do padrão IEEE 1451.1. Os autores descreveram as classes, modelo de objeto, a definição da classe NCAPBlock e a máquina de estado do NCAPBlock. Os autores descrevem também a facilidade de integração com outros modelos como: MIMOSA (Machinery Information Management Open Systems Alliance) e OSA-CBM (Open System Architecture for Condition Based Maintenance), sendo que, tais modelos, desde seu desenvolvimento foram baseados em diagrama de UML. No trabalho de Stepanenko et al. (2006) apresentaram a hierarquia de classe do padrão IEEE 1451.1 através de diagrama. Além do diagrama de classe de todo o padrão IEEE 1451.1, os autores apresentaram também as quantidade de classes minimas para o desenvolvimento do nó de rede NCAP através de diagrama e quais foram retirada do projeto do nó de rede. Para validação do modelo descrito, foi desenvolvido uma rede de sensores contendo vários NCAPs utilizando o microcontrolador Atmel AT89C51RC2 e a interface RS-232 para comunicação com o servidor. Uma contribuição do trabalho realizado, foi mostrar que é posśıvel adaptar para qualquer interesse o padrão IEEE 1451.1 para os benef́ıcios em redes distribúıdas. Um outro fator, foi o desenvolvimento de um sistema utilizando dispositivos de baixo custo. Cheng e Qin (2005) apresentaram o desenvolvimento de um NCAP e um STIM utilizando tecnologia Nios Soft-Core Processor. Os autores utilizaram o processador Nios para o desenvolvimento do NCAP e o STIM, o módulo LAN9IC111 para comunicação com a rede Ethernet e linguagem C para realização da programação. A comunicação entre o nó de rede NCAP e o STIM foi utilizada a interface TII, no qual os autores descrevem passo a passo a comunicação entre os módulos. Como conclusão, os autores destacam a flexibilidade, a configuração personalizada a reconfiguração e reprogramação. Lee e Song (2007) apresentaram o desenvolvimento do nó de rede NCAP e o TIM utilizando notebooks. Para realizar a comunicação foi utilizada a interface sem fio padrão IEEE 802.11 e dois casos de estudos, o primeiro realizando a requisição de um sensor e 38 o segundo a leitura das TEDS. O WTIM realiza a comunicação com o microcontrolador utilizando a interface serial padrão RS-232 para que seja realizada a leitura do sensor. Para a demonstração dos testes, foram apresentados as interface usuários com as requisições e resposta do módulo WTIM, apresentando a leitura do sensor e a leitura das TEDS. Nemeth-Johannes, Sweetser e Sweetser (2007) apresentaram o desenvolvimento do NCAP utilizando o microcomputador e o WTIM utilizando um processador ARM-32 bits. A comunicação entre os dispositivos foi feita utilizando o padrão IEEE 802.15.1 através do módulo de comunicação MCI Module Communications Interface. O TIM desenvolvido é denominado de TinyTIM e possui 6 canais de transdutores podendo ser expandido para mais canais. O’Reilly et al. (2009) apresentaram as vantagens de utilizar um padrão aberto para redes de transdutores, aumentando a flexibilidade e aumentando a escabilidade da rede. Apresentam-se também as camadas de protocolo, sendo que a camada mais alta encontra- se a Internet utilizada para aplicações remotas. Os autores fazem uma abordagem do padrão IEEE 1451 e especifica quais são as TEDS obrigatórias e as opcionais. O serviço web é baseado em SOA (Service-Oriented Architecture) e IEEE 1451.0. Os autores descrevem também a integração entre o padrão IEEE 1451 e OGC-SWE (Open Geospatial Consortium - Sensor Web Enablement), as especificações e os transdutores implementados pelo grupo para realização dos testes. Os autores também descrevem sobre a rede CAN (Controller Area Network), suas aplicações e a paralização do projeto em relação a integração com o padrão IEEE 1451. Larrauri et al. (2010) apresentaram uma rede de transdutores para apoio em carros utilizando a interface Bluetooth e o padrão IEEE 1451. Para o desenvolvimento do nó de rede NCAP foi utilizado um microcomputador denominado mini-PC (alix 3c3) com o hardware: AMD Geode LX800, processador 500 MHz e 256 MB DDR DRAM (Double Data Rate Dynamic Random-Access Memory) com sistema operacional Linux implementado e o TIM foi utilizado microcontroladores da famı́lia Freescale HCS08. Os TIMs realiza a requisição dos dados e envia para NCAP, que processas os dados e envia através da rede Ethernet utilizando o protocolo HTTP (Hypertext Transfer Protocol). Os autores descrevem algumas desvantagens sobre o trabalho como, por exemplo, a implementação de apenas 2 canais TIMs no bloco NCAP e outra limitação que descrita é o limite máximo de TIMs, devido as caracteŕısticas da rede Bluetooth. Bodson (2010) apresentou uma breve descrição dos novos padrões definido pela IEEE, como por exemplo: WLAN 802.11P para comunicação em ambiente veicular, IEEE P1901 para indústria, IEEE 802.3BA para especificação de duas novas velocidades com novas 39 larguras de bandas para transmissão de dados em redes Ethernet e IEEE 1451.7, que faz parte da norma IEEE 1451 e utiliza interface e metódos para interfaceamento de transdutores para tags RFID. Wang et al. (2005) apresentaram um sistema utilizando sensor de umidade e temperatura baseado no padrão IEEE P1451.2. Os dados são enviados para o NCAP utilizando o padrão IEEE P1451.2, que recebe a informação, processa e envia para um barramento local. O servidor recebe os dados e transmite para o cliente utilizando a Internet. Uma caracteŕıstica importante do trabalho, é a descrição das “CalibrationTEDS”, no qual os autores descrevem como foi feito a tabela do TEDS e como foi feito os cálculos baseados na tabela de calibração dos transdutores. Song e Lee (2008a) descreveram as caracteŕısticas do padrão IEEE 1451, quais os TEDS principais e uma pequena descrição de cada comitê. É importante destacar que, os autores descrevem o padrão IEEE P1451.6, porém, atualmente o projeto encontra-se parado. Os autores apresentam exemplo de projeto utilizando o padrão IEEE 1451.5 utilizando rede sem fio padrão IEEE 802.11. Os autores destacam também as aplicações do padrão, como, por exemplo: monitoramento e controle de forma remota, sistema de controle e medida distribuida e aplicações web. Lee e Song (2005) apresentaram uma aplicação orientada a objetos utilizando camadas para o padrão IEEE 1451.4. Os autores dividiram o trabalho em 4 camadas: sistema operacional, utilitários, ferramentas, NCAP e aplicações. De forma sucinta, os autores descrevem sobre o padrão IEEE 1451, da arquitetura em camada do projeto desenvolvido e em que contexto se encaixa a estrutura de orientação a objetos. Foram apresentados também os diagramas em UML: hierarquia de classe do padrão IEEE 1451.1 e diagrama de agregação em relação as classes do padrão IEEE 1451.1. Como exemplo, foi utilizado sistema de tratamento de água para personalizar as camadas orientado a objeto. Muitos trabalhos vêm sendo desenvolvidos baseado na norma IEEE 1451 utilizando diferentes arquiteturas e topologias de desenvolvimento. Os trabalhos relacionados nesta seção, apresentaram diferentes formas de desenvolvimento do NCAP e do TIMs, porém, neste trabalho apresenta-se um modelo novo de implementação do nó de rede NCAP, diferente dos modelos apresentados. O NCAP desenvolvido, possui arquitetura e sistema operacional embarcado dinâmico utilizando dispositivos reconfiguráveis (FPGA) baseando nas caracteŕısticas do sistema em que será aplicado. O nó de rede NCAP é flex́ıvel e pode ser aplicado em diferentes ambientes, pois, a utilização da rede Ethernet como rede externa permite uma configuração simples e semelhante às utilizadas nos microcomputadores com sistema operacional Linux. Outra caracteŕıstica importante que facilita sua flexibilidade, 40 é a utilização de diferentes interfaces internas cabeada ou sem fio, baseada na norma IEEE 1451, ampliando o campo de aplicação. 1.5 Organização do Texto Inclúıda a introdução geral no Caṕıtulo 1 que contém a contextualização do projeto, um breve histórico dos sistemas operacionais embarcados e das redes de transdutores e os trabalhos mais relevantes na área, o texto foi organizado em 6 caṕıtulos. No Caṕıtulo 2 são introduzidos os principais conceitos da famı́lia do padrão IEEE 1451 e a descrição de cada comitê, as tecnologias de transmissão de dados e como desenvolver os módulos NCAP e os TIMs. No Caṕıtulo 3 é apresentada uma descrição das interfaces de comunicação utilizadas para o desenvolvimento do nó de rede NCAP. No Caṕıtulo 4 são apresentadas as ferramentas de desenvolvimento e utilizadas como suporte, suas caracteŕısticas, análise de desempenho e onde se enquadra dentro do contexto do projeto. No Caṕıtulo 5 são apresentadas as caracteŕısticas de implementação dos TIMs e a descrição dos módulos desenvolvidos neste trabalho. No Caṕıtulo 6 é apresentado o desenvolvimento da parte lógica do hardware utilizando o processador Nios II, as configurações do sistema operacional μClinux e a inicialização do sistema e o softwares NCAP. Além das caracteŕısticas de implementação são apresentados os testes e resultados obtidos pelo sistema. No Caṕıtulo 7 são apresentadas as conclusões gerais do trabalho e os trabalhos futuros a serem desenvolvidos. 41 Capı́tulo 2 O Padrão IEEE 1451 2.1 Introdução O padrão IEEE 1451 tem como objetivo definir o interfaceamento do nó NCAP (IEEE 1451.1) e os diferentes módulos definidos de acordo com cada comitê: IEEE P1451.2, IEEE 1451.3, IEEE 1451.4, IEEE 1451.5, IEEE P1451.6 e IEEE 1451.7. Através do emprego do padrão IEEE 1451, é posśıvel atingir interoperabilidade e o modo de funcionamento plug and play entre o NCAP e as diferentes tecnologias de interfaceamento, caracteŕısticas definidas pelo padrão IEEE 1451.0. Nas Seções 2.2 a 2.9, serão apresentadas as definições estabelecidas em cada padrão da famı́lia IEEE 1451 e suas caracteŕısticas. 2.2 O Padrão IEEE 1451.0 - 2007 O padrão IEEE 1451.0 - 2007 é um projeto que aponta uma funcionalidade comum, comandos e TEDS da famı́lia do padrão de transdutores inteligentes. Esta funcionalidade é independente do meio f́ısico de comunicação. Isto inclui as funções básicas requeridas para controle e gerenciamento de transdutores inteligentes, protocolos de comando e independência do formato de mı́dia. O padrão IEEE 1451.0 especifica o formato dos TEDS que são “tabelas”de dados que contêm informações dos transdutores (sensores/atuadores) armazenadas em memória não volátil dentro do TIM. No entanto, há aplicações em que o armazenamento em uma memória não volátil não é prático para aplicação, então, o padrão IEEE 1451.0 permite o armazenamento em outros locais de forma remota denominando-as de TEDS Virtuais. Os TEDS Virtuais são arquivos eletrônicos que fornecem as mesmas funcionalidades das implementadas em memória no TIM, porém, não estão no TIM (IEEE, 2007c). 42 Uma técnica para atingir a caracteŕıstica plug-and-play foi a definição de um conjunto mı́nimo de informações dos transdutores e outros recursos opcionais para funções mais avançadas. Os TIMs, ao serem conectados ao NCAP, transmitem as informações dos TEDS ao gerenciador de protocolo, que faz o reconhecimento da rede de transdutores de forma automática, ou seja, plug and play (IEEE, 2007c). Para descrever os TEDS, o padrão IEEE 1451.0 - 2007 apresenta um formato denominado de TLV (Type/Length/Value) que é descrito na Seção 2.2.1. A caracteŕıstica plug and play dos transdutores inteligentes aos seus usuários e desenvolvedores faz surgir algumas vantagens como: redução do tempo para parametrização do sistema, diagnósticos avançados, redução do tempo para reparo e reposição, gerenciamento avançado do hardware e automatização da calibração (IEEE, 2007c). Para a implementação dos TEDS, quatro blocos são obrigatórios, Meta-TEDS, TransducerChannel TEDS, User´s Transducer Name TEDS e PHY TEDS. As demais tabelas, Calibration TEDS, Frequency Response TEDS, Transfer Function TEDS, Text- based TEDS, Commands TEDS, Identification TEDS, Geographic location TEDS, Units extension TEDS, End User Application Specific TEDS e Manufacturer defined TEDS são opcionais. Neste trabalho, foram utilizadas os TEDS obrigatórias para testes do sistema e implementação do padrão IEEE 1451.0-2007. A Meta-TEDS fornece uma identificação única denominada UUID (Universal Unique Identifier) e alguns parâmetros de tempo que são dispońıveis para serem usadas pelo NCAP, como por exemplo, o tempo excedido na comunicação de um determinado software quando o TIM não está respondendo. O restante dos campos dos TEDS descreve o relacionamento entre o TransducerChannel que possui o TIM. No Apêndice C, apresentam-se exemplos das Meta-TEDS descritos nos TIMS desenvolvidos neste trabalho. O TransducerChannel TEDS deve conter as informações detalhadas sobre as especificações do transdutor, fornecendo parâmetro f́ısico que está sendo medido ou controlado, a faixa no qual o transdutor opera, as caracteŕısticas de I/O digital, modo de operação da unidade e especificações de tempo. No Apêndice C, apresentam-se exemplos das TransducerChannel TEDS descritos nos TIMS desenvolvidos neste trabalho. O User´s Transducer Name TEDS contém o nome do TIM ou canal do transdutor para que seja reconhecido no nó de rede NCAP. A estrutura desta TEDS é recomendada no padrão, mas o tamanho do conteúdo é definido pelo usuário. No Apêndice C apresentam-se exemplos das User´s Transducer TEDS descritos nos TIMS desenvolvidos neste trabalho. 43 A PHY TEDS é dependente do meio de comunicação f́ısico usado para conectar o NCAP e o TIM. No Apêndice C, apresentam-se exemplos das PHY TEDS descritos nos TIMS desenvolvidos neste trabalho. O padrão IEEE 1451.0, além de definir padrões para armazenamento das informações dos transdutores inteligentes, também fornece normas para mensagens (Message structures) e comando (Command). Message structures definem a estrutura das mensagens enviadas através da interface de comunicação. Command define as tarefas que serão executadas como estado ou operação que será realizada (IEEE, 2007c). Nas Seções 2.2.2 e 2.2.3 apresentam-se exemplos de estrutura de mensagems e comandos enviados pela interface entre o NCAP e o TIM. 2.2.1 Formato padrão dos TEDS Os TEDS possuem um formato padrão apresentado na Tabela 1. O primeiro campo em quaisquer TEDS é o tamanho e é representado por 4 octetos sem sinal inteiro. O próximo bloco representa o conteúdo dos TEDS, podendo ser representado por informações binárias ou baseadas em texto. O último campo em quaisquer TEDS é o checksum, que é usado para verificar a integridade dos dados dos TEDS. Tabela 1 – Formato padrão dos TEDS. Campo Descrição Tipo Octeto — Tamanho dos TEDS UInt 4 1 para N Bloco de dados Variável Variável — Checksum UInt16 2 Fonte: IEEE (2007c) Os campos da tabela TEDS são descritos como: • Tamanho dos TEDS - é o número total de octetos no bloco de dados mais os dois octetos do checksum. • Bloco de dados - campo que contém informações espećıficas de acordo com cada tabela TEDS. Os campos que compõem esta estrutura são diferentes para cada tipo de TEDS e a sua estrutura é baseada em TLV, exceto o padrão IEEE 1451.2-1997 e IEEE 1451.3-2003 (IEEE, 2007c). A construção de cada linha dentro da tabela TEDS utiliza a estrutura TLV definida como: – Type - campo definido por 1 octeto, representa a identificação da linha TLV; – Length - especifica o número de octetos no campo Value; 44 – Value - contém as informações do campo TEDS; • Checksum - é o complemento da soma de todos os octetos precedidos incluindo o campo inicial tamanho dos TEDS. 2.2.2 Estrutura das Mensagens Os dados utilizados na transmissão entre o NCAP e o TIM são descritos em ńıvel de octeto. Na Tabela 2, apresenta-se um grupo de octetos e a ordem de transmissão em que é definido pelo padrão IEEE 1451.0. Tabela 2 – Ordem de transmissão dos dados. 1-Octeto 1-Octeto 1-Octeto 1-Octeto 8o bit ... 1o bit 8o bit ... 1o bit 8o bit ... 1o bit 8o bit ... 1o bit 1o octeto transmitido 2o 3o 4o 5o 6o 7o 8o Fonte: IEEE (2007c) Para representar uma quantidade numérica, o bit mais à esquerda é representado como sendo o mais significante e, o mais à direita, como sendo o menos significante. Na Tabela 3 apresenta-se o valor numérico e a ordem de transmissão de dados, de acordo com o bit mais significativo e o menos significativo. Tabela 3 – Exemplo de bit mais significante e menos significante. Ordem Valor = 170 7 6 5 4 3 2 1 0 1 0 1 0 1 0 1 0 Fonte: IEEE (2007c) A estrutura de uma mensagem de comando de requisição é definida de acordo com a Tabela 4 e é descrita como: • Número do canal do transdutor - campo representado por 16 bits e define o canal do transdutor de destino; • Classe de comando - campo representado por 8 bits e define a classe do comando de acordo com a Tabela 5; • Função do comando - campo representado por 8 bits que define a função do comando de acordo com o que foi atribuido na classe de comando. Na Tabela 6 apresentam-se as funções de operação do transdutor baseado na classe de comando representado pelo atributo: XdcrOperate utilizada neste projeto; 45 • Tamanho - campo representado por 16 bits em que define o tamanho do campo de dados. O tamanho de uma mensagem recebida, se não relacionar com o campo tamanho da mensagem, esta é descartada e uma mensagem de erro é retornada; • Campo de dados - contém as informações a serem transmitidas. Tabela 4 – Estrutura de uma mensagem de comando 1 - Octeto 7 6 5 4 3 2 1 0 Número do canal do transdutor (octeto mais significativo) Número do canal do transdutor (octeto menos significativo) Classe de comando Função do comando Tamanho (octeto mais significativo) Tamanho (octeto menos significativo) Campo de dados Fonte: IEEE (2007c) Tabela 5 – Classe de comando. Identificação do comando Nome do atributo Categoria 0 Reserved Reservado 1 CommonCmd Comando comum para o TIM e o canal do transdutor 2 XdcrIdle Estado ocioso do transdutor 3 XdcrOperate Estado de operação do transdutor 4 XdcrEither Transdutor em estado ocioso ou operando 5 TIMsleep Estado de dormência 6 TIMActive Comando de estado ativo do TIM 7 AnyState Qualquer estado 8-127 ReservedClass Reservada 127-255 ClassN Aberto para os fabricantes Fonte: IEEE (2007c) A estrutura de uma mensagem de comando de resposta é definida de acordo com a Tabela 7 e é descrita como: • Sucesso/Falha - campo representado por 8 bits e define se os dados foram enviados com sucesso ou não. Caso o valor do campo for diferente de zero, a mensagem foi enviada com sucesso, senão, é considerada uma mensagem falha e o sistema pode verificar a mensagem para identificar o problema; • Tamanho - campo representado por 16 bits e define o tamanho do campo de dados. O tamanho de uma mensagem recebida, se não relacionar com o campo tamanho da mensagem, a mensagem é descartada; 46 Tabela 6 – Comando de operação do transdutor. Identificação Comando Canal de transdutor Global/Grupo 0 Reservado X — 1 Ler um canal de transdutor X — 2 Escrever um canal de transdutor X — 3 Comando Trigger X X 4 Abortar Trigger X X 5-127 Reservado — — 127-255 Aberto para fabricantes — — Fonte: IEEE (2007c) • Campo de dados - contém as informações a serem transmitidas. Tabela 7 – Mensagem de comando de resposta. 1 - Octeto 7 6 5 4 3 2 1 0 Sucesso/Falha Tamanho (octeto mais significativo) Tamanho (octeto menos significativo) Campo de dados Fonte: IEEE (2007c) 2.2.3 Comandos Os comandos definidos pelo padrão IEEE 1451.0 são divididos em duas categorias: padrão (definido pelo padrão) e fabricante (definido pelo fabricante). Independente da categoria, o comando é dividido em dois octetos, o mais significativo que identifica a classe de comando e o menos significativo que identifica a função do comando, como apresentado na Tabela 4. Na categoria padrão, a classe e as funções são definidas de acordo com a norma IEEE 1451.0. Um exemplo é que se o octeto mais significativo que especifica a classe definir estado de operação do transdutor (atributo: XdcrOperate) apresentado na Tabela 5, o octeto menos significativo que especifica a função deve ser definido de acordo com uma das especificações definidas na Tabela 6. Na categoria fabricante, as especificações do comando não são definidas pelo padrão IEEE 1451.0, mas pelo usuário que está desenvolvendo o sistema, tornando-se a responsabilidade do usuário de desenvolver um software para interpretar os comandos. No Apêndice B apresenta-se exemplos de comandos utilizados para testes do sistema. 47 2.3 O Padrão IEEE 1451.1 A fabricação tradicional de transdutores tem evidenciado um grande esforço no desenvolvimento do interfaceamento de sensores e atuadores para as redes de controle. Usualmente, o resultado do esforço do desenvolvimento de uma rede pode não ser fácil transportar para outras redes. O principal objetivo da NIST/IEEE é o desenvolvimento de métodos de conexão padronizado entre transdutores inteligentes e redes de controle utilizando tecnologias já existentes. O padrão IEEE 1451.1 especifica a interface com a rede de tal maneira que a aplicação independa do protocolo utilizado pela rede ou barramento de campo (IEEE, 1999). Um NCAP em conformidade com o padrão IEEE 1451.1 pode funcionar com TIMs utilizando diferentes interfaces baseando-se nas normas de interfaceamento do padrão IEEE 1451. Na Figura 2 é ilustrada a famı́lia do padrão IEEE 1451 e suas posśıveis conexões. O padrão IEEE 1451.0 é representado através do bloco TEDS. Figura 2 – Diagrama da famı́lia do padrão IEEE 1451. Fonte: Santos Filho (2012) Na Seção 2.3.1 apresenta-se as especificações do nó de rede NCAP baseadas na norma IEEE 1451.1. 48 2.3.1 Processador de Aplicação com Capacidade de Operar em Rede (NCAP) - IEEE 1451.1 O NCAP é um nó com capacidade de processamento local, capaz de receber dados de uma rede externa através de um determinado protocolo, converter essas informações para outro tipo de protocolo baseado na norma IEEE 1451 para realizar a comunicação com a rede de transdutores, serviço semelhante a um gateway 1. Para isto, o nó NCAP tem como caracteŕıstica identificar o tipo de rede no qual está conectado, dando assim o conceito de interoperabilidade, além de abstrair informações do tipo de transdutor conectado, facilitando a introdução do modo de operação plug and play (IEEE, 1999). Para o seu desenvolvimento, o nó de rede NCAP é subdividido em 2 partes, f́ısica e lógica. A parte f́ısica é composta por microprocessador e seus circuitos associados, hardware de comunicação com a rede e as interfaces de acesso I/O. As caracteŕısticas f́ısicas do hardware não são definidas pelo padrão IEEE 1451. A parte lógica compreende os componentes lógicos que podem ser agrupados em componentes de aplicação e suporte. Os componentes de suporte são o sistema operacional, o protocolo da rede e a firmware2 dos transdutores inteligentes. O sistema operacional tem como objetivo realizar o interfaceamento entre as aplicações e o hardware, facilitando a manipulação dos dados e o acesso às interfaces (IEEE, 1999). Na Figura 3 apresenta-se um modelo de nó de rede contendo um processador, driver para a comunicação do sistema operacional com os periféricos, o sistema operacional realizando o gerenciamento dos arquivos e o interfaceamento dos aplicativos com o hardware. Em ńıvel de abstração mais alto, apresentado na Figura 3, o nó de rede é responsável por realizar a aquisição dos dados de uma rede de comunicação externa, processar esses dados e realizar o controle ou o monitoramento de acordo com umas das normas da famı́lia do padrão IEEE 1451. Um NCAP, em conformidade com o padrão IEEE 1451.1, pode operar com o STIM através de uma interface TII, RS-232, USB, SPI e I2C (IEEE P1451.2), o TBIM (Transducer Bus Interface Module) através de um barramento (IEEE 1451.3), o MMI (Mixed-Mode Interface) através de uma interface com sinais mistos (IEEE 1451.4), o WTIM através da comunicação sem fio (IEEE 1451.5), o TBC (Transducer Bus Controller) utilizando um barramento CAN (IEEE P1451.6) ou RFID (Radio-Frequency Identification) através de sinais de rádio frequência (IEEE 1451.7). 1Gateway- é um dispositivo intermediário geralmente destinado a interligar redes, separar domı́nios de colisão, ou mesmo traduzir protocolos. 2Software responsável pela inicialização de um processador e seus circuitos de interface 49 Figura 3 – Bloco NCAP genérico com as principais descrições. Fonte: Santos Filho (2012) O padrão IEEE 1451.1 especifica-se uma arquitetura de software aplicável em sistemas distribúıdos, podendo ter um ou mais NCAPs se comunicando em rede. A especificação da arquitetura de software é apresentada na documentação do padrão IEEE 1451.1 como sendo orientada a objetos. Entretanto, não há a exigência do uso de técnicas de implementação orientado a objetos (IEEE, 1999). A arquitetura do software do NCAP é baseada em: modelo de informação, modelos de dados e modelos de comunicação em rede. Nas Seções 2.3.1.1, 2.3.1.2 e 2.3.1.3 apresentam-se a descrição de cada modelo. 2.3.1.1 Modelo de Informação O modelo de informação é composto de uma hierarquia de classes de objetos dividido em três principais categorias: • Classes Block - realiza o processamento; • Classes Component - encapsula os dados; • Classes Service - comunicação do NCAP e sicronização das interfaces de comunicação. Na Figura 4 apresenta-se a hierarquia de classes do padrão IEEE 1451.1. Uma importante caracteŕıstica na implementação do NCAP é a forma de descrição dos nomes das classes, métodos e declaração das variáveis, como por exemplo: • Nome das classes - IEEE1451 FunctionBlock (sem separação da palavra inicial 50 Figura 4 – Hierarquia de classes do padrão IEEE 1451. Fonte: IEEE (1999) e cada letra inicial da palavra em maiúsculo, prefixo IEEE1451 NomeDaClasse se especificada pelo padrão IEEE 1451.1, fonte do computador); • Métodos - TemperatureSensor (sem separação da palavra, inicial de cada palavra em maiúsculo e fonte do computador); • Variáveis - read, read status (separação com sublinhado, sem letra maiúscula, fonte do computador). 2.3.1.2 Modelo de Dados O modelo de dados define o tipo de dados usado para trocar informação entre as entidades dentro de um processo do NCAP e através da rede. O modelo de dados suporta os seguintes tipos de dados: • Boolean - True ou False; • Octet - 8 bits não interpretado como um número; • Integer - número com sinal ou sem sinal de 8 bits a 64 bits; 51 • Float - numérico baseado no padrão IEEE 754; • String - Array de octetos contendo texto de leitura humana. 2.3.1.3 Modelos de Comunicação em Rede O padrão IEEE 1451 provê dois modelos de comunicação entre os objetos em um sistema distribúıdo: cliente/servidor e editor/subscritor (IEEE, 1999). No modelo cliente/servidor, os usuários denominados clientes realizam uma solicitação através de mensagens para o servidor e de acordo com a mensagem, é executado um determinado processo. Ao finalizar o processo, o servidor envia uma mensagem de resposta ao cliente. No modelo editor/subscritor, o emissor (editor) não necessita de enumerar explicitamente os receptores (subscritor) das mensagens. Quando o editor envia uma mensagem, o sistema de editor/subscritor é responsável pelo correto encaminhamento dos dados até todos os subscritores que desejam receber. De modo a receber a mensagem o subscritor pode expressar que categoria de mensagem deseja receber, ou definir o conjunto de caracteŕısticas que a mensagem deve possuir para que possa estar recebendo. Um exemplo de sistema distribúıdo editor/subscritor bem conhecido é BitTorrent, no qual várias pessoas estão interligadas através de um sistema de rastreio que coordena o encaminhamento das informações (IEEE, 1999). É importante destacar que neste trabalho foi implementado o modelo cliente/servidor para o desenvolvimento do nó de rede NCAP. Nas Seções 2.4 a 2.9, apresentam-se as normas de interfaceamento entre o NCAP e os TIMs definidas pelo padrão IEEE 1451. 2.4 O Padrão IEEE P1451.2 O padrão IEEE P1451.2 introduz o conceito de STIM (Smart Transducer Interface Module). O STIM é um módulo que contém um ou mais transdutores conectados, constituindo uma aplicação de transdutores que tem como objetivo fornecer capacidade plug and play para conectar transdutores em rede, facilitar o suporte aos clientes, fornecer um conjunto mı́nimo de ferramentas que possibilite a identificação dos transdutores e fazer com que os sistemas implementados sejam escaláveis. Um STIM pode ser composto de 1 até 255 transdutores por módulo e cada módulo pode conter circuitos de condicionamento de sinal, conversores A/D (analógico/digital) e D/A (digital/analógico), uma memória não volátil para o armazenamento dos TEDS 52 e lógica necessária para realizar a comunicação através de uma de suas interfaces padronizadas: TII, RS-232, SPI, I2C ou USB. É importante destacar que o padrão IEEE P1451.2-1997 não é compat́ıvel com o padrão IEEE 1451.0 - 2007, mas o grupo de trabalho do IEEE P1451.2 está realizando as revisões e fazendo com que a norma torne compat́ıvel com o padrão IEEE 1451.0 (SONG; LEE, 2008b) . Em Song e Lee (2008b) apresenta-se uma proposta de desenvolvimento do padrão IEEE 1451.0 com IEEE P1451.2 que foi utilizado como referência para o desenvolvimento do STIM neste trabalho. Na Figura 5 é ilustrado um modelo de STIM, suas interfaces e um exemplo de configuração de hardware para o seu desenvolvimento. Figura 5 – Modelo do padrão IEEE P1451.2. Fonte: Santos Filho (2012) 2.5 O Padrão IEEE 1451.3 O padrão IEEE 1451.3 foi desenvolvido com o objetivo de criar uma norma padrão de interfaceamento de transdutores em rede distribúıda, utilizando o barramento multdrop. O padrão introduz o conceito de TBIM (Transducer Bus Interface Module) e um TBC conectado por um barramento de transdutores. Um TBIM é um módulo que contém o barramento de interface, condicionamento de sinal, conversor A/D ou D/A e os transdutores necessários. O TBC é um bloco que contém elementos de hardware e software no NCAP ou um host que provê o interfaceamento para o barramento de transdutores. O barramento de transdutores provê uma comunicação entre um NCAP, host ou mais TBIMs (LEE, 2009). Como apresentado na Figura 6, uma única linha de transmissão é utilizada para fornecer energia aos transdutores e fornecer a comunicação entre o controlador e os TBIMs. Em um único barramento, espera-se controlar no máximo 255 módulos TBIMs e, em cada módulo TBIM, um total de 255 sensores ou atuadores, chegando a um total de 65025 transdutores em cada barramento (NIST, 2011). 53 Figura 6 – Modelo do padrão IEEE 1451.3. Fonte: Santos Filho (2012) 2.6 O padrão IEEE 1451.4 O padrão IEEE 1451.4 tem como principal foco prover a compatibilidade com o MMI de forma analógico e digital. A interface transmite os dados das TEDS através de um canal digital e as informações dos sensores utilizando o canal analógico, dando, assim, a capacidade de plug and play aos módulos MMI. Para realizar a comunicação entre o MMI e NCAP, é realizada a comutação entre a memória de amazenamento dos TEDS e a sáıda do transdutor, sendo que ambos compartilham um único meio f́ısico. Na Figura 7 apresenta-se o modelo de interfaceamento de acordo com a norma IEEE 1451.4 que tem por objetivo realizar o interfaceamento de transdutores analógicos e transformá-los em módulos de transdutores plug and play, tornar o mais simples posśıvel a implementação de transdutores inteligentes e garantir a flexibilidade dos MMI, podendo conectá-los com outras redes (IEEE, 2004). Figura 7 – Modelo do padrão IEEE 1451.4. Fonte: Santos Filho (2012) 54 2.7 O padrão IEEE 1451.5 O padrão IEEE 1451.5 tem como objetivo especificar o interfaceamento do nó NCAP com o módulo WTIM (Wireless Transducer Interface Module), de acordo com uma das tecnologias de rede sem fio: Wi-Fi (Wireless Fidelity) (padrão IEEE 802.11) (TANENBAUM; WETHERALL, 2011), ZigBee (padrão IEEE 802.15.4) (FARAHANI, 2008) ou Bluetooth (padrão IEEE 802.15.1) (TANENBAUM; WETHERALL, 2011). O IEEE 802.11 é um padrão que foi desenvolvido em 1997 por um grupo de trabalho do IEEE para definir o conceito de redes locais sem fio, a WLAN (Wireless Local Area Network). A famı́lia 802.11 é subdividida em outras 4 especificações: IEEE 802.11, 802.11b, 802.11a, 802.11g. Além disso, existe previsão para um novo padrão definido como IEEE 802.11i. O padrão IEEE 802.11 cobre as especificações técnicas das camadas de enlace e f́ısica, tendo como referência a hierarquia das camadas do modelo OSI (Open Systems Interconnection). Os três meios de transmissão de dados da camada f́ısica são FHSS (Frequency-Hopping Spread Spectrum), DSSS (Direct-Sequence Spread Spectrum) e o IR (Infra Red - Infravermelho). Os padrões FHSS e DSSS trabalham com Spread Spectrum de sinal e operam em uma frequência de 2,4 MHz, sendo que ambas trabalham com faixa de transmissão de 1 a 2 Mbps. A comunicação serial