Proposta de um sistema de instrumentação inteligente baseado em CAN e TCP/IP by Antonio M. Moreiras

ANTONIO MARCOS MOREIRAS

PROPOSTA DE UM SISTEMA DE INSTRUMENTAÇÃO INTELIGENTE BASEADO EM CAN E TCP/IP PARA APLICAÇÃO EM UM LABORATÓRIO DE ABELHAS

Dissertação apresentada à Escola Politécnica da Universidade de São Paulo para obtenção do título de Mestre em Engenharia

São Paulo 2004

ANTONIO MARCOS MOREIRAS

PROPOSTA DE UM SISTEMA DE INSTRUMENTAÇÃO INTELIGENTE BASEADO EM CAN E TCP/IP PARA APLICAÇÃO EM UM LABORATÓRIO DE ABELHAS

Dissertação apresentada à Escola Politécnica da Universidade de São Paulo para obtenção do título de Mestre em Engenharia Área de Concentração: Sistemas Digitais Orientador: Professor Livre Docente Carlos Eduardo Cugnasca

São Paulo 2004

FICHA CATALOGRÁFICA Moreiras, Antonio Marcos Proposta de um Sistema de Instrumentação Inteligente Baseado em CAN e TCP/IP para Aplicação em um Laboratório de Estudo de Abelhas. São Paulo, 2002. 68p. Dissertação (Mestrado) – Escola Politécnica da Universidade de São Paulo. Departamento de Engenharia de Computação e Sistemas Digitais. 1. Sistema de Aquisição de Dados Distribuído 2. Redes para Automação 3. CAN 4. TCP/IP 5. Laboratório de Estudo de Meliponíneos. I. Universidade de São Paulo. Escola Politécnica. Departamento de Engenharia de Computação e Sistemas Digitais. II. t

À minha esposa Viviane e aos meus pais pela compreensão, incentivo e apoio à realização deste trabalho.

AGRADECIMENTOS Ao meu orientador, Prof. Dr. Carlos Eduardo Cugnasca, pela amizade, dedicação, calma e paciência, além das valiosas sugestões e colaborações ao longo da elaboração deste trabalho. À Profa. Dra. Vera Lucia Imperatriz Fonseca e ao Prof. Dr. Antonio Mauro Saraiva pelo apoio oferecido. Ao Prof. Dr. Sérgio Miranda Paz, pelo incentivo. Aos pesquisadores e colaboradores do Laboratório de Automação Agrícola, em especial a Cesar Strauss, Alexandre de Almeida Guimarães, Katia Mara Rabelo da Silva e Renato Souza da Cunha, com os quais as pesquisas associadas a este trabalho vêm sendo realizadas. A todos os professores, pesquisadores e funcionários do Departamento de Engenharia de Computação e Sistemas Digitais da Escola Politécnica da USP, que direta ou indiretamente colaboraram para a realização deste trabalho. Aos meus colegas de trabalho e superiores na Agência Estado, em especial a Oripide Cilento Filho, gerente de engenharia, e ao Prof. Dr. Demi Getschko, diretor de tecnologia, pelo apoio oferecido. E aos meus familiares, não só pela ajuda, mas também pela compreensão e paciência.

RESUMO O estudo das Abelhas Indígenas Sem Ferrão, ou Meliponíneos, tem sido foco de diversas pesquisas ao redor do mundo. Contudo, alguns pesquisadores têm reportado problemas na coleta de dados experimentais de forma precisa e confiável. No presente trabalho é apresentada uma proposta de um sistema de instrumentação inteligente, para uso no Laboratório de Abelhas do Instituto de Biociências da USP, que visa suprir principalmente as necessidades de se efetuar medidas em colméias situadas no mesmo. O sistema é dividido em dois níveis: o de instrumentação e o supervisório. O nível de instrumentação é baseado no protocolo CAN e o nível supervisório é composto por módulos com interfaces CAN e Ethernet, usa TCP/IP e implementa um servidor web, permitindo a visualização dos dados coletados através de um microcomputador convencional com um web browser nele instalado O sistema proposto possui como principais características a modularidade, o baixo custo e a adesão a padrões abertos, atendendo às necessidades de aquisição de dados dentro de um laboratório e possibilitando ainda sua expansão para realização de medidas em ambiente natural.

ABSTRACT The study of bees has attracted the attention of several researchers worldwide. However, some of them have reported difficulties in collecting experimental data with the necessary reliability and accuracy. This work presents a proposal for an intelligent instrumentation system to be used at the Beelab of Instituto de BiociĂŞncias of University of SĂŁo Paulo that will allow researchers to do the necessary measurements inside the laboratory. The system is subdivided in two levels: instrumentation level and supervisory level. The instrumentation level is based on CAN protocol and the supervisory level has modules with CAN and Ethernet interfaces embedded, uses TCP/IP and implements an embedded web server, allowing the bee colonies data to be viewed by anyone with a PC and a web browser if desired. The proposed system has characteristics as modularity, low cost and compliance with open standards, allowing its use in the study of stingless bees at a laboratory and scaling up to be possible the research on bees at their native environment.

SUMÁRIO

LISTA DE FIGURAS LISTA DE TABELAS LISTA DE ABREVIATURAS E SIGLAS

INTRODUÇÃO ....................................................................................... 1

1.1

Objetivo........................................................................................................... 1

1.2

Motivação........................................................................................................ 1

1.3

Conteúdo e Organização ............................................................................... 2

O ESTUDO DOS MELIPONÍNEOS........................................................ 4

2.1

Os Meliponíneos, sua Importância e seu Estudo......................................... 4

2.2

Importância dos Meliponíneos...................................................................... 5

2.3

Estudos sobre os Meliponíneos ..................................................................... 6

2.4

O Laboratório de Abelhas do Instituto de Biociências da USP. ................ 7

2.5

O WebBee e os Estudos Sobre o Nível de Instrumentação......................... 8

CONCEITOS DE AUTOMAÇÃO:INSTRUMENTAÇÃO, BARRAMENTOS DE CAMPO E PADRÕES ABERTOS..................... 10

3.1

Histórico da Automação Industrial e do Desenvolvimento dos Barramentos de Campo............................................................................... 10

3.2

Os Barramentos de Campo e os Sistemas Distribuídos, Baseados em Instrumentos Inteligentes ............................................................................ 15

3.3

O Problema da Padronização da Área de Automação ............................. 17

3.4

Novas Perspectivas para o Problema da Interoperabilidade................... 19

3.5

Conclusão ...................................................................................................... 20

O PROTOCOLO TCP/IP E A ETHERNET ........................................... 21

4.1

Breve histórico da Internet e do TCP/IP ................................................... 21

4.2

O TCP/IP e o Modelo ISO/OSI ................................................................... 23

4.3

A Ethernet..................................................................................................... 26

4.4

Ethernet e TCP/IP em Aplicações Dedicadas............................................ 28

4.5

Ethernet e TCP/IP em Aplicações de Automação..................................... 31

4.6

Conclusão ...................................................................................................... 34

O PROTOCOLO CAN .......................................................................... 35

5.1

Características do CAN ............................................................................... 36

5.2

Conclusão ...................................................................................................... 40

PROPOSTA DE UM SISTEMA DE INSTRUMENTAÇÃO INTELIGENTE, BASEADO EM CAN E TCP/IP ................................... 41

6.1

Considerações Preliminares ........................................................................ 41

6.2

Projeto dos módulos de aquisição e controle ............................................. 42

6.3

Projeto da Rede CAN................................................................................... 46

6.4

Projeto dos módulos de Supervisão e da Interface TCP/IP. .................... 49

6.5

Considerações finais..................................................................................... 55

CONSIDERAÇÕES FINAIS ................................................................. 58

7.1

Contribuições do trabalho........................................................................... 58

7.2

Possíveis melhorias....................................................................................... 58

7.3

Perspectivas de continuidade. ..................................................................... 59

7.4

Conclusão. ..................................................................................................... 60

LISTA DE REFERÊNCIAS .......................................................................... 62 APÊNDICE: Diagramas do Módulo eZ80 .................................................. A1

LISTA DE FIGURAS

Figura 1: Fotos ilustrativas de abelhas da subfamília Meliponinae............................ 5 Figura 2: Esquema do templo egípcio automatizado por Heron de Alexandria....... 11 Figura 4: Controle centralizado com links (HEFFERNAN, 1997). ......................... 13 Figura 5: Controle distribuído (HEFFERNAN, 1997). ............................................ 14 Figura 6: Controle distribuído com Barramento de Campo (HEFFERNAN, 1997).14 Figura 7: Modelo CIM.............................................................................................. 15 Figura 8: Comparação entre TCP/IP e modelo ISO/OSI.......................................... 24 Figura 9: Comparação entre CAN e modelo ISO/OSI.............................................. 36 Figura 10: Formato das mensagens CAN 2.0A e 2.0B............................................. 38 Figura 11: Diagrama da rede de instrumentação proposta. ...................................... 42 Figura 12: Protótipo do módulo CAN....................................................................... 44 Figura 13: Diagrama em blocos do módulo de aquisição e controle........................ 44 Figura 14: Formato do Identificador CAN. .............................................................. 47 Figura 15: Módulo eZ80F91..................................................................................... 51 Figura 16: Kit de desenvolvimento eZ80 Acclaim! .................................................. 51 Figura 17: Página inicial da interface com o usuário do módulo de supervisão. ..... 53 Figura 18: Página mostrando a lista dos módulos conectados à rede....................... 53 Figura 19: Página mostrando os valores dos sensores conectados ao módulo 1. ..... 54 Figura 20: Interface Shell, mostrando configurações de rede................................... 55 Figura 21: Interface Shell, mostrando os processos ................................................. 55 Figura 22: Quadro resumo da proposta para o Sistema de Instrumentação.............. 56

LISTA DE TABELAS Tabela 1: Mensagens CAN. ....................................................................................... 48 Tabela 2: Mensagens CAN com valores do campo de dados .................................... 49

LISTA DE ABREVIATURAS ABNT – Associação Brasileira de Normas Técnicas ABS – Antilock Braking System ACK – Acknowledged A/D – Analógico / Digital ANSI –American N ational Standards Institute ANSP – Academic Network at São Paulo ARP – Address Resolution Protocol ARPANET – Advanced Research Project Agency Network ASCII – American Standard Code for Information Interchange BSD – Berkley Software Distribution CAD – Computer Aided Design CAP – Computer Aided Planing/Production CAM – Computer Aided Manufacturing CAN – Controller Area Network CEA – Consumer Eletronics Association CENELEC – Comité Européen de Normalisation Electrotechnique CIA – CAN in Automation CIM – Computer Integrated Manufacturing CLP – Controlador Lógico Programável CPF – Communication Profile Families CPU – Central Processing Unit CRC – Cyclic Redundance Code CSMA/CD – Carrier Sense Multiple Access with Collision Detection CSMA/CA – Carrier Sense Multiple Access / Collision Avoidance

CSMA/CD+AMP – Carrier Sense Multiple Access / Collision Detection with Arbitration on Message Priority CSMA/CD+NDA – Carrier Sense Multiple Access / Collision Detection with Non Destrutive Arbitration CSNET – Communication Security Net D/A – Digital Analógico DHCP –Dinamyc Host Configuration Protocol DLC – Data Length Code DMA – Direct Memory Access DNS – Domain Name Service DOS – Disk Operational System EEPROM – Electric Erasable Programable Read Only Memory EIA – Electronic Industries Alliance EMAC – Ethernet Media Access Controller EN – EuroNorm EPUSP – Escola Politécnica da Universidade de São Paulo EOF – End of Frame EPROM –Erasable Programable Read Only Memory EUA – Estados Unidos da América FTP – File Transfer Protocol Gbps – Gigabits per second GPL – General Public License GPS – Global Positioning System HDLC – High-level Data Link Control HSE – High Speed Ethernet

HTTP – HyperText Transfer ProtocolIB-USP - Instituto de Biociências da Universidade de São Paulo IAONA – The Independent Platform Organization for Industrial Ethernet IB – USP – Instituto de Biociências – Universidade de São Paulo IBM – International Business Machine I2C – Inter-Integrated Circuit ICMP – Internet Control Message Protocol IDA - Interface for Distributed Automation IDE – Identifier Extension IEC – International Electrotechnical Commission IEEE – Institute of Electrical and Electronics Engineers, Inc.ISO – International Organization for Standardization IETF – Internet Engineering Task Force IFS – Interframe Space IGMP – Internet Group Management Protocol INT – Interframe Space IP – Internet Protocol ISO – International Organization for Standardization IPX – Internetwork Packet Exchange JVM – Java Virtual Machine Km – Kilômetros LAN – Local Area Network LAA – Laboratório de Automação Agrícola do Departamento de Engenharia de Computação e Sistemas Digitais escola Politécnica da Universidade de São Paulo LLC – Logic Link Control mA – mili Ampéres

MAC – Media Access Control Mbps – Megabits por segundo Mbytes – Megabytes Mhz – Megahertz Milnet – Military Network MMU – Memory Management Unit NMEA – National Marine Electronics Association NSF – The U.S National Science Foundation NSFNET – National Science Foundation Network OSI – Open Systems Interconnection PC – Personal Computer (Computador Pessoal) PCS – Departamento de Engenharia de Computação e Sistemas Digitais da Escola Politécnica da Universidade de São Paulo PDA – Personal Digital Assistant PLC – Programmable Logic Controller PPP – Point-to-Point Protocol PSI – Pounds per Square Inch QoS – Quality of Service RAM – Random Access Memory RARP – Reverse Address Resolution Protocol RNP – Rede Nacional de Ensino e Pesquisa ROM – Read Only Memory RTOS – Real Time Operational System RTR – Request for Transmission SAE – Society of Automotive Engineers

SDCC – Small Device C Compiler SLIP – Serial Line Internet Protocol SMTP – Simple Mail Transfer Protocol SNMP – Simple Network Management Protocol SPX – Sequenced Packet Exchange SRAM– Static Random Access Memory SRR – Substitute Remote Request TCP/IP - Transmission Control Protocol/Internet Protocol TIMEP – Time Protocol TTL – Transistor Transistor Lógic UDP – User Datagram Protocol USP – Universidade de São Paulo WAN – Wide Area Network WLAN – Wireless Local Area Network ZPAK II – Zilog Debug Tool ZTP – Zilog TCP/IP Protocol Suite

1. INTRODUÇÃO 1.1 Objetivo Esta dissertação tem como objetivo discutir e propor um sistema constituído por uma rede de dispositivos inteligentes, destinado ao monitoramento e controle de um ambiente de estudo de meliponíneos, situado no Laboratório de Abelhas do Instituto de Biociências da Universidade de São Paulo (LABORATÓRIO DE ABELHAS IB USP, 2004) (CUNHA, 2001a). 1.2 Motivação Participando do Laboratório de Automação Agrícola (LABORATÓRIO DE AUTOMAÇÃO AGRÍCOLA, 2004) desde 1997, o autor vem tomando contato com as oportunidades de aplicação da Tecnologia da Informação em várias áreas associadas à agricultura e ao meio ambiente, em particular com o estudo dos Meliponíneos, tema de muita importância especialmente para um país como o Brasil, rico em biodiversidade. O estudo das abelhas, em particular dos Meliponíneos, ou Abelhas Indígenas sem Ferrão, tem chamado a atenção de diversos pesquisadores no Brasil e no mundo, devido à sua importância como polinizadores para a agricultura regional e para as áreas naturais. Algumas espécies são utilizadas também para a produção de mel e há um crescente interesse em sua utilização para a polinização em estufas. Seu estudo tem grande importância ecológica também porque há espécies com risco de extinção, por exemplo as que habitam a Mata Atlântica (CUNHA, 2001a) (AIDAR, 1997). Dentre os estudos realizados estão os de classificação, que procuram identificar as várias espécies e sua distribuição geográfica e os de atividade de vôo, que procuram relacionar as variáveis climáticas às atividades externas nas abelhas. Para os diversos estudos é necessário que existam formas de se coletar dados como: temperatura, umidade relativa do ar, luminosidade, atividade das abelhas, dentre outros, e armazená-los organizadamente (CUNHA, 2001a). Por se tratar de um tema que requer muita experimentação, há uma contínua ne-

cessidade de se desenvolver recursos de apoio destinados a cada situação, por nem sempre se encontrar soluções adequadas comercialmente disponíveis, quer por razões técnicas, quer por razões de custo. Pesquisadores têm reportado dificuldades nesse sentido (CUNHA, 2001a). Este trabalho tem por objetivo contribuir para as pesquisas nesse setor, propondo uma rede flexível, confiável, tecnicamente adequada e de custo acessível, proporcionando aos pesquisadores condições para que os experimentos possam ser facilmente configurados e reconfigurados e os dados acessados localmente ou à distância, além da possibilidade de controle automático de algumas condições. 1.3 Conteúdo e Organização Compõem este trabalho sete capítulos, uma lista de referências bibliográficas e um apêndice. Neste capítulo foi apresentado resumidamente o tema do trabalho, bem como o objetivo e a motivação para a sua realização. É apresentada também a organização da dissertação. O capítulo 2, O Estudo dos Meliponíneos, apresenta a importância do estudo dos meliponíneos e a importância de se dispor de ferramentas para facilitar esse estudo. O capítulo 3, Conceitos de Automação: Instrumentação, Barramentos de Campo e Padrões Abertos, apresenta e discute os principais conceitos relacionados com automação, instrumentação, barramentos de campo e padrões abertos, utilizados na implementação de sistemas de supervisão e controle. Os capítulos 4, O Protocolo TCP/IP e a Ethernet, e 5, O Protocolo CAN, são destinados à discussão de dois protocolos de muita relevância atualmente na implementação de sistemas de supervisão e controle: o primeiro discute o uso do protocolo TCP/IP em conjunto com o padrão Ethernet, conhecidos pela utilização nas redes locais e na Internet, enquanto o segundo, o protocolo CAN, muito utilizado em aplicações embarcadas. No capítulo 6, Proposta de um Sistema de Instrumentação Inteligente, é apresentada a proposta de um sistema de aquisição de dados com arquitetura distribuída, baseado em CAN e TCP/IP, aplicado a um laboratório de pesquisa de abelhas.

Os resultados, conclusões e considerações finais desta Dissertação encontram-se no capítulo 7, propondo-se também atividades de continuidade e evolução do trabalho desenvolvido. Sucedendo-o tem-se a lista de referências bibliográficas, organizada em ordem alfabética. Um apêndice finaliza esta Dissertação, apresentando os principais detalhes do sistema experimental implementado.

2. O ESTUDO DOS MELIPONÍNEOS Neste capítulo discutem-se as justificativas e motivações deste trabalho, introduzindo os Meliponíneos e a importância e em estudá-los. Apresentam-se também as necessidades de ferramentas de auxílio à pesquisa, situando este trabalho nesse contexto.

2.1 Os Meliponíneos, sua Importância e seu Estudo Dentre as espécies de abelhas presentes no Brasil, pode-se destacar as da subfamília Meliponinae (Hymenoptera, Apidae) ou Meliponíneos (Figura 1). Elas são conhecidas também como abelhas indígenas sem ferrão, por possuírem apenas um ferrão vestigial, sendo incapazes, portanto, de ferroar (CAMPOS; PERUQUETTI, 2000). São abelhas nativas, sendo encontradas nas Américas do Sul e Central, Ásia, Ilhas do Pacífico, Austrália, Nova Guiné e África. Pode-se dividi-las, taxonomicamente, em duas tribos: Meliponini, habitando exclusivamente a América do Sul, Central e Ilhas do Caribe e Trigonini, distribuída por toda a área onde se encontra a subfamília (CAMPOS; PERUQUETTI, 2000). No Brasil existem cerca de 300 espécies identificadas de Meliponíneos e algo mais que 30 estudadas (CUNHA, 2001a). Todos os Meliponíneos são eu-sociais, ou seja, vivem em colônias constituídas por centenas ou milhares de indivíduos com funções diferenciadas. Geralmente a colônia possui uma rainha mãe, várias gerações de operárias e alguns machos (CAMPOS; PERUQUETTI, 2000). A rainha é a responsável pela postura de ovos, que dão origem às operárias, rainhas e a pelo menos uma parte dos machos. Geralmente há apenas uma rainha na colônia, mas há espécies em que podem ser encontradas até cinco. As operárias são responsáveis por diversas tarefas no ninho: são faxineiras, nutrizes, arquitetas, ventiladoras, guardas e campeiras. Geralmente vivem de 30 a 40 dias. Os machos são encontrados nas épocas em que existe bastante alimento e a presença de células reais no ninho. Sua função é fecundar as rainhas virgens. Eles não possuem corbícula (existente nas patas traseiras das operárias, responsável pela coleta de pólen). Geralmente, após a fecundação da

rainha e iniciada a postura de ovos, eles são expulsos da colméia (CAMPOS; PERUQUETTI, 2000) (LUNA, 2000).

Da esquerda para a direita: Melipona Bicolor (Guaraipo), Tetragonisca angustula (Jataí) e Friesella schrottkyi (Mirim preguiça) Fonte: http://www.ib.usp.br/beelife

Figura 1: Fotos ilustrativas de abelhas da subfamília Meliponinae

2.2 Importância dos Meliponíneos Os vegetais são os produtores da cadeia alimentar humana e a base da pirâmide de energia, tendo imensa importância na alimentação. As abelhas são importantes agentes polinizadores, sendo responsáveis pela reprodução de 40 a 90% dos vegetais de fecundação cruzada através deste mecanismo. O cruzamento consangüíneo desenvolve a uniformidade genética, numa determinada cultura, e acaba por torná-la mais sensível às variações ambientais, tais quais epidemias, pragas, clima, etc. A polinização realizada pelas abelhas é um dos mecanismos que promove a variabilidade genética, aumentando a produtividade das plantas cultivadas e a fertilidade dos vegetais que dependem da polinização cruzada (AIDAR, 1997). A importância de se conhecer a relação das abelhas nativas com o ambiente e as flores de um determinado local é grande. Elas são os polinizadores potenciais das áreas naturais e da agricultura regional (IMPERATRIZ-FONSECA, 2000). Há estudos mostrando que a extinção de espécies de abelhas implica na extinção de espécies vegetais e desequilíbrio do ecossistema (AIDAR, 1997). As diversas espécies de abelhas nativas estão hoje ameaçadas por fatores como o desmatamento e a atividade de extrativismo dos chamados Meleiros (indivíduos que exploram as colônias silvestres para a extração de mel ou venda das próprias abelhas) (AIDAR, 1997). Para a sobrevivência das espécies sociais, é importante que seus

hábitos de vida sejam conhecidos, como por exemplo, local em que fazem o ninho, o que necessitam para construí-lo, preferências climáticas, preferências florais, etc. Uma vez que haja esse conhecimento, pode-se trabalhar na restauração do ambiente ou criação destas abelhas em ambiente artificial, salvando-as, ao menos, da extinção (IMPERATRIZ-FONSECA, 2000) (AIDAR, 1997). Comercialmente os Meliponíneos têm importância tanto em sua criação para a produção de mel como para o uso como agentes polinizadores na produção agrícola. Uma característica interessante dessas abelhas é que, na colônia, a área de cria é separada dos potes de alimento, possibilitando o desenvolvimento de vários tipos de caixas racionais para a sua criação, de forma que o mel pode ser coletado sem expor a área da cria. Outra vantagem é que o Meliponicultor precisa de poucas ferramentas para usar no dia a dia da criação (LUNA, 2000). Quanto à utilização para a polinização na agricultura, existem regiões onde é comum o aluguel de colméias para a polinização de frutas como uvas, morangos, leguminosas e girassol. O uso de espécies estrangeiras, mesmo que de comprovado sucesso nessa área, não é recomendável, pois gera problemas devido à introdução da espécie em ambientes onde ela não existia originalmente. Portanto, é de grande importância o estudo de Meliponíneos também para sua utilização como polinizadores em estufas e outros ambientes agrícolas.

2.3 Estudos sobre os Meliponíneos Vários estudos têm sido realizados sobre os Meliponíneos, tanto para tentar garantir a sobrevivência dessas espécies quanto para procurar formas de explorá-las comercialmente na agricultura (CUNHA, 2001a). Um dos campos de estudo é o de sua classificação, envolvendo a identificação das espécies encontradas na natureza. Também são estudadas a distribuição geográfica das espécies e suas preferências florais. Essas informações são essenciais para que possam existir programas de criação de abelhas ou restauração ambiental (CUNHA, 2001a). Outra linha de pesquisa é a que estuda a atividade de vôo das abelhas. Conhecendo-se os padrões de atividade e os fatores bióticos e abióticos que influenciam esse padrão é possível determinar se uma espécie é ou não adequada para ser utiliza-

da como polinizadora em uma cultura específica (CORBET et al., 1993). Estudos desse tipo podem ainda ajudar a prever quais espécies pode-se esperar encontrar numa dada região, de acordo com o clima local (GIOVANNINI; IMPERATRIZFONSECA, 1986). A atividade de vôo das abelhas é regulada por fatores bióticos e abióticos. Dentre os fatores abióticos, pode-se citar: temperatura, umidade relativa do ar, intensidade da

luz,

etc

(IMPERATRIZ-FONSECA;

GIOVANNINI;

PIRES,

1985)

(GIOVANNINI; IMPERATRIZ-FONSECA, 1986). Para os diversos estudos sobre o comportamento das abelhas face às variações ambientais é necessário que existam formas de se coletar dados como: temperatura, umidade relativa do ar, luminosidade, dentre outros, dentro e fora da colônia, e armazená-los organizadamente. Geralmente os pesquisadores têm tido dificuldades em encontrar uma forma de coletar esses dados de forma precisa e confiável (BICUDO; FRANÇOSO Jr., 1999).

2.4 O Laboratório de Abelhas do Instituto de Biociências da USP. Estabelecido há mais de 30 anos, o Laboratório de Abelhas do Instituto de Biociências da USP tem se dedicado principalmente ao estudo das abelhas sociais nativas no Brasil, da família Meliponinae (LABORATÓRIO DE ABELHAS IB USP, 2004) (CUNHA, 2001a). No laboratório há cerca de 150 colônias de abelhas da subfamília Meliponinae, envolvendo aproximadamente 30 espécies, que têm por objetivo servir de objeto para vários tipos de estudo. Parte destas colônias está ao ar livre, nos arredores do Laboratório e parte se situa em sua parte interna. As colônias internas estão alojadas em caixas duplas, feitas de madeira (uma caixa dentro da outra) próximas à parede do edifício. A caixa mais interna é onde se situa de fato a colônia. A mais externa serve como isolação térmica, permitindo também o controle artificial da temperatura externa à caixa onde está a colônia, através de um aquecedor controlado por um termostato, de forma a simular uma variação da temperatura do ambiente. Em ambas as caixas a parte superior é confeccionada de vidro, tornando possível observar o interior da colônia. Normalmente há uma manta sobre o vidro, de forma que a luz não interfira nas atividades das abelhas, essa é removida quando o pesquisador precisa observar

a colônia. Para suportar as diversas pesquisas efetuadas no laboratório, seria de grande valia um sistema automatizado de coleta de dados que fosse capaz de medir, para cada colônia, variáveis como: temperatura interna, umidade relativa do ar e número de abelhas que entram e saem. O aquecedor presente nas colméias deveria ser também controlado por esse sistema. Além disso são necessárias medidas externas de temperatura, umidade, luminosidade, entre outras. Além das colméias internas e dos arredores do laboratório também são realizadas pesquisas em campo, no ambiente natural das abelhas. Hoje, usa-se DataLoggers para a realização dos experimentos externos, mas estes não atendem plenamente aos requisitos. 2.5 O WebBee e os Estudos Sobre o Nível de Instrumentação Em virtude da dificuldade já abordada dos pesquisadores em coletar e organizar os dados necessários às pesquisas de forma adequada iniciou-se a cooperação entre o Laboratório de Automação Agrícola da Escola Politécnica da USP e o Laboratório de Abelhas, do Instituto de Biociências, da qual surgiram alguns projetos bastante interessantes. O primeiro deles resultou no trabalho de mestrado do Engenheiro Renato S. Cunha, que desenvolveu um protótipo de um Sistema de Informação para apoiar o estudo dos Meliponíneos, o WebBee (CUNHA, 2001a). O sistema continua sendo aperfeiçoado e está sendo utilizado efetivamente pelos pesquisadores (WEBBEE, 2003). O WebBee pode ser utilizado para pelo menos três atividades principais: •

Organização das publicações e documentos produzidos.

•

Criação de uma base de dados para a classificação das espécies.

•

Coleta e armazenamento de informações de medidas efetuadas pelos equipamentos do laboratório.

Com o WebBee, dessa forma, tem-se conseguido amenizar a dificuldade da organização das informações. Outro projeto consistiu no desenvolvimento de um sistema de coleta de dados para as colméias do laboratório. Este possui uma interface com o WebBee e é basea-

do num PC com uma placa de aquisição, ou seja, é um sistema de arquitetura centralizada. Ele tem servido bem tanto para os pesquisadores do LAA, que buscam aperfeiçoar os sensores e métodos de medida, quanto para as próprias pesquisas do Laboratório de Abelhas. Contudo, o uso do sistema é limitado, devido a sua arquitetura que limita o seu uso a poucas colméias, sendo de difícil expansão (CUNHA, 2001b) (CUNHA, 2002). Um resultado interessante da experimentação com esse sistema foi o desenvolvimento também de alguns sensores e métodos para a contagem das abelhas, permitindo contabilizar os indivíduos que entram e saem de uma colônia (OLIVEIRA; SARAIVA, 2002), além do estudo dos outros sensores envolvidos, como os de temperatura e umidade ambiente. A proposta deste trabalho é complementar as pesquisas já realizadas, fazendo uso dos estudos sobre o nível de instrumentação para propor uma rede de sensores inteligentes e que ofereça uma arquitetura flexível e descentralizada para automatizar as medidas nas colméias, integrando-se facilmente ao sistema de informação em uso.

3. CONCEITOS DE AUTOMAÇÃO:INSTRUMENTAÇÃO, BARRAMENTOS DE CAMPO E PADRÕES ABERTOS A Enciclopédia Britânica descreve o verbete automação da seguinte forma: "The application of machines to tasks once performed by human beings or, increasingly, to tasks that would otherwise be impossible. Although the term mechanization is often used to refer to the simple replacement of human labour by machines, automation generally implies the integration of machines into a self-governing system. Automation has revolutionized those areas in which it has been introduced, and there is scarcely an aspect of modern life that has been unaffected by it (BRITANNICA, 2001)."

Este capítulo tem por objetivo apresentar alguns conceitos básicos sobre automação. Muitos conceitos e termos aqui abordados serão emprestados da área de automação industrial, por ser este o campo em que primeiro a automação como se conhece hoje se desenvolveu. Mesmo assim esses conceitos são genéricos o suficiente para serem aplicados em outras áreas, como automação predial, agrícola, comercial, etc, como a própria aplicação descrita como tema central deste texto vem demonstrar.

3.1 Histórico da Automação Industrial e do Desenvolvimento dos Barramentos de Campo Desde a Antigüidade há relatos da utilização de máquinas e de alguns sistemas automáticos, como por exemplo o caso de Heron da Alexandria, que criou um dispositivo para abrir automaticamente as portas de um templo egípcio sempre que o fogo do templo fosse aceso (o calor do fogo pressurizava um recipiente com água e parte desta escoava para um balde, cujo peso fazia funcionar o dispositivo para abrir as portas (Figura 2) (ANCIENTE, 2004).

Figura 2: Esquema do templo egípcio automatizado por Heron de Alexandria Foi, no entanto, no século XVIII, com a Revolução Industrial, que o trabalho braçal passou a ser substituído pelo trabalho de máquinas de forma sistemática, causando um grande impacto na sociedade. Obviamente o grau de dependência destas em relação ao controle humano era enorme, se comparado aos padrões atuais; no entanto, pode se considerar a introdução do maquinário na produção industrial como a pré-história da automação. Automatizar a produção naqueles dias, com o auxílio das máquinas, era sinônimo de aumento de produtividade e este foi o paradigma que veio a nortear o desenvolvimento da automação em suas fases iniciais (PEREIRA, 2002a). Em meados do século XX os sistemas utilizados na automação industrial passaram a ter características mais próximas às dos utilizados atualmente. Um sistema automático geralmente tem elementos sensores, que extraem informações do processo a ser controlado e elementos atuadores, que conseguem agir sobre o processo, exercendo dessa forma o controle. Atualmente a informação que é extraída pelos sensores e utilizada para acionar os controladores geralmente é alguma forma de um sinal elétrico, seja ele analógico ou digital. Por um bom tempo, em especial antes da utilização dos transistores, foi mais comum a utilização de sistemas hidráulicos ou pneumáticos para realizar as mesmas tarefas. Um padrão bastante comum então, era o que utilizava pressões entre 3 e 15 psi (pounds per square inch) para representar as grandezas

físicas

processo

(PEREIRA,

2002a)

(PEREIRA,

2002b)

(HEFFERNAN, 1997). Nas décadas de 1960 e 70 conviviam lado a lado sistemas pneumáticos e elétricos. O padrão denominado loop de corrente 4-20mA predominou nessa época para a transmissão de sinais analógicos entre os dispositivos a longas distâncias. O controle propriamente dito era feito, no caso dos sistemas elétricos e mistos, predominantemente via lógica baseada em relés (HEFFERNAN, 1997) (MEYZIN, 2000). Datam já deste mesmo período os primeiros CLPs (Controladores Lógicos Programáveis - em inglês: PLCs). Estes controladores visavam inicialmente substituir a lógica baseada em relês, que poderia ser complexa, sob os pontos de vista de configuração inicial, manutenção e resolução de problemas, além de pouco flexível. O fato de novos controladores serem programáveis trazia grandes vantagens para os casos em que mudanças na produção e na planta industrial eram relativamente freqüentes (MEYZIN, 2000). Ainda nesta época, minicomputadores eram empregados em vários sistemas de automação industrial. Toda inteligência do sistema era então centralizada no minicomputador: tipicamente sensores e atuadores eram a ele interligados por loops de corrente de 4-20mA com um mínimo de circuitos eletrônicos, sem qualquer capacidade de processamento, servindo como interface (Figura 3). Posteriormente os loops de corrente analógicos foram substituídos por sinais digitais, como por exemplo, o padrão RS-232 ou mesmo o protocolo HART (VERHAPPEN, 2000), que funciona sobreposto ao sinal analógico de 4-20mA. Os dispositivos sensores e atuadores foram então providos de interfaces adequadas: conversores analógico-digitais, por exemplo, mas ainda sem nenhuma capacidade de processamento (Figura 4) (HEFFERNAN, 1997).

Figura 3: Controle centralizado com links analógicos (HEFFERNAN, 1997).

Figura 4: Controle centralizado com links (HEFFERNAN, 1997). Na década de 1970 foram fabricados os primeiros microprocessadores. Logo se percebeu o grande impacto que os novos componentes poderiam exercer sobre a automação, tornando possível dotar sensores e atuadores de capacidade de processamento. No início da década de 1980 os primeiros sensores e atuadores inteligentes surgiram, tornando realidade o conceito de instrumentação inteligente (PEREIRA, 2002a) (HEFFERNAN, 1997). Na década de 1980 observou-se o aumento da competição a nível mundial e alguns requisitos como qualidade, custo e uso racional de energia e matéria-prima foram ganhando importância em lugar do antigo paradigma de simples aumento de produtividade. Os computadores, nessa época, tiveram seu campo de atuação expandido e encontraram lugar em todos os setores da corporação, desde o chão de fábrica até o nível gerencial. Sistemas como CAP (Computer Aided Planing/Production), CAD (Computer Aided Design) e CAM (Computer Aided Manufacturing) foram tornando-se cada vez mais populares (PEREIRA, 2002a). Com o surgimento dos instrumentos inteligentes começou a mudar também o paradigma de programação. A utilização de softwares centralizados foi dando lugar à utilização de arquiteturas distribuídas, com o software local de cada dispositivo, inclusive dos sensores e atuadores, agora com capacidade de processamento, contribuindo com os outros para o funcionamento global do sistema (Figura 5). Conforme a capacidade de processamento dos instrumentos inteligentes foi crescendo, eles foram tornando-se capazes de comunicar-se através de meios multiplexados, usando um protocolo adequado, ou seja, através de algum tipo de rede de comunicação. O termo comumente utilizado para descrever esse tipo de rede é Barramento de Campo ou, em inglês, Fieldbus (Figura 6) (HEFFERNAN, 1997).

Figura 5: Controle distribuído (HEFFERNAN, 1997).

Figura 6: Controle distribuído com Barramento de Campo (HEFFERNAN, 1997). É importante entender que, ao menos nesse campo, as novas tecnologias não eliminaram as antigas. Ou seja, apesar da disponibilidade dos barramentos de campo, dos instrumentos inteligentes e de outros avanços e tecnologias de vanguarda, as tecnologias antigas continuam sendo utilizadas. Links com loops de corrente 4-20mA ainda são usados, o mesmo ocorrendo para sistemas centralizados em detrimento dos distribuídos. Sistemas hidráulicos e pneumáticos ainda têm seu lugar. E mesmo a total ausência de automação na produção, a utilização do simples trabalho braçal, ainda existe e é até bastante comum. Novas tecnologias sempre carregam uma promessa de um futuro melhor, são uma resposta a novas necessidades ou uma forma de atender de uma maneira melhor às necessidades antigas. Nem sempre, no entanto, essa promessa é cumprida. Experiências e resultados iniciais podem, por vezes, apontar a direção errada. Ou simples-

mente uma dada aplicação não apresenta requisitos novos ou necessidades que justifiquem o custo da adoção de uma nova tecnologia. As tecnologias antigas já estão bem testadas e estabelecidas. Conhece-se seu custo, sabe-se calcular muito bem seus reais benefícios e contornar seus pontos fracos. Por isso perduram, convivem e mesmo competem com o mais novo.

3.2 Os Barramentos de Campo e os Sistemas Distribuídos, Baseados em Instrumentos Inteligentes Para melhor entender-se o papel dos barramentos de campo no sistema de automação pode-se tomar o modelo CIM Computer Integrated Manufacturing esquematizado na Figura 7 (SHICKHUBER, 2002) (HEFFERNAN, 1997).

Figura 7: Modelo CIM Este modelo representa o fluxo de informações dentro de um ambiente industrial. Os níveis mais altos indicam um maior nível de responsabilidade, informações mais complexas e tempos de resposta mais longos, não críticos. O nível mais alto representa o nível gerencial, dentro de um escopo corporativo; pensando-se em tecnologias utilizadas aí estaria, por exemplo, a WAN da empresa, interligando as diversas plantas. Os níveis mais baixos estão mais próximos ao chão de fábrica. Neles os tempos de resposta são cada vez mais críticos, mas as decisões cada vez mais simples. O nível mais baixo representa o dos dispositivos, sensores e atuadores que influenciam diretamente os processos produtivos (HEFFERNAN, 1997). Os barramentos de campo desempenham seu papel geralmente nos dois níveis

inferiores, mas dependendo do sistema podem assumir funções também de outros níveis. Há duas principais visões sobre o papel dos barramentos no sistema de automação (THOMESSE, 1999): •

os barramentos de campo são simplesmente uma rede que tem por função principal simplificar as ligações entre os dispositivos, ou

•

os barramentos são parte fundamental de um sistema distribuído com capacidade para aplicações de tempo real. Existem hoje muitos tipos diferentes de barramentos de campo. Mais que 50 ti-

pos diferentes de barramentos, entre nomes de produtos e de padrões, haviam sido citados em congressos, exposições ou revistas, até 1997 (THOMESSE, 1999). Provavelmente esse número hoje é ainda maior. Obviamente os barramentos diferem entre si. Uma das razões de existirem tantos é justamente a divergência de opiniões entre os projetistas e fabricantes sobre quais funções os barramentos têm de assumir. No contexto deste trabalho optou-se por ignorar a maior parte das diferenças e tratar de forma genérica o assunto. Comparando-se os sistemas de automação baseados em barramentos de campo e instrumentos inteligentes aos sistemas considerados mais tradicionais, ou seja, aqueles baseados em controladores centrais com links, digitais ou analógicos, até os sensores ou atuadores; podem-se enumerar algumas vantagens dos primeiros sobre os últimos. Essas vantagens atualmente vêm ao encontro das principais expectativas dos usuários dos sistemas de automação, sendo discutidas por (HEFFERNAN, 1997) (VERHAPPEN,

2000)

(TIAN;

ZHAO;

BAINES,

2000)

(SHICKHUBER;

MCCARTHY, 2002). São elas: Custos: Mesmo que em alguns casos o custo inicial do equipamento possa ser maior que o das soluções tradicionais, existem estudos que demonstram que o custo total de uma solução baseada em barramento de campo é menor. Um bom exemplo é dado por Verhappen (2000) que fez um estudo comparativo entre três tipos de sistemas, um centralizado com links analógicos, outro centralizado com links digitais e outro distribuído, apontando o último com a solução mais econômica.

Facilidade de instalação e configuração: A topologia em forma de barramento contribui para reduzir a fiação necessária para o sistema. Instrumentos inteligentes com características como autocalibração, autocompensação e autovalidação podem também contribuir para que o setup inicial do sistema seja facilitado. Facilidade de manutenção e flexibilidade: Eventuais expansões ou atualizações do sistema são facilitadas por não haver necessidade de se passar novos fios até um ponto central para cada dispositivo a ser instalado, bastando em geral conectá-los ao barramento no ponto conveniente. As ferramentas de software e de gerenciamento disponíveis facilitam esse tipo de tarefa, oferecendo em geral recursos também para encontrar problemas e realizar diagnósticos online dos dispositivos. Determinismo e tempo de resposta: Com a divisão das tarefas de software entre os diversos dispositivos do sistema, é possível alcançar tempos de resposta menores do que com um sistema centralizado. Confiabilidade: Uma maior confiabilidade talvez não seja uma característica intrínseca dos sistemas que são baseados em barramentos de campo, no entanto ter um sistema confiável é um requisito importante em praticamente todas as aplicações. Foram então incluídas nos principais sistemas baseados em barramento características visando suprir essa necessidade, como redundância de hardware e software. O próprio fato dos sistemas serem distribuídos e não apresentarem um ponto central de falha já contribui também neste aspecto. Padronização: Apesar de existir um número enorme de padrões de barramento de campo, ao se escolher um adequado é possível construir-se soluções onde dispositivos de diversos fabricantes diferentes são utilizados, dando maior liberdade de escolha ao usuário final. 3.3 O Problema da Padronização da Área de Automação A interoperabilidade entre soluções de diferentes fabricantes é uma característica desejável em praticamente todas as áreas onde há tecnologia envolvida e a de automação não foge à regra. Os equipamentos deveriam ser compatíveis entre si, oferecendo os mesmos protocolos, opções, características, de forma a haver maior liber-

dade de projeto e que um equipamento defeituoso, por exemplo, pudesse ser substituído por outro, mesmo de um fabricante diferente (THOMESSE, 1999). Para atingir esses objetivos, os sistemas de automação devem ser sistemas abertos. Por definição sistemas abertos são os que implementam um número suficiente de especificações ou padrões abertos de forma a garantir a interoperabilidade entre os dispositivos e outros sistemas, com um mínimo de esforço. Estes são os que são definidos por entidades oficiais ou de alta reputação junto à comunidade técnica, como por exemplo IEC, CENELEC, ANSI, ISO, IEEE ou ABNT. (IEEE, 2004) (FUNDAO, 2004) (CANSADO, 2001) (MOREIRAS, 2001). Muitas vezes a velocidade da evolução tecnológica, a falta de consenso entre as partes interessadas ou outros fatores impedem que normas abertas sejam criadas. Nesse caso geralmente o mercado adota alguns padrões proprietários, definidos por empresas para uso próprio. Se um desses padrões é bem sucedido e acaba por ser adotado também por outros fabricantes se torna um padrão de mercado ou de fato. Em geral foi o que ocorreu na área de automação. Primeiro surgiram os barramentos, como produtos, e foram implementadas soluções. Nessa época a tecnologia era muito recente e não se chegou a um consenso quanto a padronizações. Posteriormente surgiram padrões nacionais, ou regionais, baseados nos produtos que já eram padrão de fato naqueles mercados. As tentativas de criação de um padrão internacional não se desenvolveram com a velocidade necessária e chegou-se a um ponto em que há produtos fortes demais no mercado para que se possa abandoná-los em detrimento de um novo padrão universal, incompatível com os utilizados. Tentativas de convergência ocorreram e ainda ocorrem, mas sem êxitos significativos. Foge ao escopo deste texto uma análise detalhada do histórico dos diferentes barramentos de campo, que é feita por Heffernan (1997) , Thomesse (1999), Felser (2002) e Shickhuber e McCarthy (2002). Seguem alguns dos barramentos e padrões existentes, analisados nas referências citadas: WorldFIP: Barramento de origem francesa, empregado em automação industrial (controle de produção e de processos) e de edifícios. Padronizado pelas normas EN-50170-3, IEC61158 Type 1 e 7, e IEC61784 CPF 5/1, 5/2 e 5/3. ProfiBUS: Barramento de origem alemã Padronizado pelas normas EN 50254-3, EN

50170-A2, IEC 61158 Type 1 e 3, IEC 61784 CPF 3/1 e 3/3 CAN: Desenvolvido para uso na indústria automobilística pela Bosch e padronizado pelas normas ISO 11898 e ISO 11519, além de outras normas para fins específicos. Hoje é utilizado nas mais diversas áreas. LonWorks: Barramento desenvolvido pela empresa americana Echelon, designado para automação de edifícios. Padronizado pela norma ANSI EIA/CEA-709.1A-1999. A padronização das soluções ainda é um dos principais desafios no campo da automação. 3.4 Novas Perspectivas para o Problema da Interoperabilidade Embora o problema de se encontrar um padrão universalmente aceito para a área de automação seja de difícil solução, pelo menos duas novas tecnologias empregadas na área são promissoras nesse sentido: •

o uso de Ethernet e TCP/IP como barramento de campo e

•

o padrão IEEE 1451 para instrumentos inteligentes.

O uso da Ethernet e TCP/IP no lugar dos barramentos de campo tradicionais tem ganhado força e, embora não sendo a melhor solução do ponto de vista técnico na atualidade, tem boas chances de ser a solução para o dilema da padronização. Esse assunto é de grande interesse e será discutido mais aprofundadamente no próximo capítulo. O padrão IEEE 1451 (IEEE, 1999) (IEEE, 1997) traz uma abordagem completamente diferente para o problema. Ele não é mais um barramento de campo, nem outra tentativa de convergência entre os existentes. A idéia é se criar uma camada a mais entre os barramentos de campo existentes e os instrumentos inteligentes, ou antes, é um padrão de interface para os instrumentos inteligentes. Ao se padronizar a interface com os sensores e atuadores, cada barramento de campo pode dispor de interfaces adequadas para no padrão IEEE 1451, de forma que os usuários podem escolher o barramento e os sensores que mais lhe forem convenientes.

O padrão ainda assegura algumas características adicionais para a instrumentação, como identificação e configuração automáticas dos dispositivos, facilidade para a atualização e manutenção dos mesmos, entre outras (CONWAY et al., 2002) (BRYZEK, 1997) (CONWAY; HEFFERNAN, 2002). 3.5 Conclusão Pôde-se discutir neste capítulo as vantagens de uma arquitetura descentralizada, baseada num barramento de campo, para construírem-se sistemas de medição e controle. Discutiu-se também a importância da padronização e as dificuldades encontradas nesta área. Uma arquitetura baseada em barramento de campo será utilizada para prover o laboratório de abelhas de um sistema de medida adequado, dados os benefícios estudados, substituindo o sistema atual, centralizado. O projeto levará em conta as preocupações com padronização, fazendo uso de Ethernet - TCP/IP e CAN, que serão discutidos em mais detalhes nos próximos capítulos.

4. O PROTOCOLO TCP/IP E A ETHERNET Atualmente a utilização das redes de computadores tornou-se corriqueira, fazendo parte da vida da maioria das pessoas e empresas, tornando-se muitas vezes imprescindível. Os computadores e outros equipamentos interconectados tornaram possível muito mais do que compartilhar recursos, trocar dados e arquivos, tornando-se a base de novas e poderosas formas de comunicação e de organização, modificando o jeito de ser dos indivíduos, organizações e da própria sociedade. O TCP/IP, nesse contexto, já é familiar por ser o conjunto de protocolos nos quais se baseia a Internet, a grande rede de alcance mundial. Já foi e ainda é também assunto de diversos trabalhos acadêmicos, livros e sites especializados. Foge ao escopo deste texto um estudo profundo sobre o que é o TCP/IP e sobre o seu uso na Internet e nas redes de computadores em geral. Procurar-se-á discutir aqui, após uma breve introdução, algumas aplicações emergentes para este conjunto de protocolos como o seu uso na automação industrial, como barramento de campo, e em aplicações dedicadas, onde os dispositivos que se comunicam na rede não são computadores pessoais, mas equipamentos de outro gênero ao qual foram adicionados um certo grau de inteligência e a capacidade de comunicação. A parte introdutória deste capítulo se baseia principalmente em IETF (2003), Tanenbaum (1996) e Torres (2001).

4.1 Breve histórico da Internet e do TCP/IP A história do TCP/IP confunde-se com a história da Internet. O protocolo foi projetado inicialmente para ser usado na ARPANET, uma rede de comando e controle, criada na década de 60 a partir da necessidade do Departamento de Defesa norte americano, que almejava por uma estrutura que pudesse sobreviver a uma guerra nuclear. Especificamente, ele foi criado para facilitar a interligação de múltiplas redes, diferentes entre si, ao projeto. As redes existentes antes da ARPANET, baseadas em redes telefônicas, funcionavam por comutação de circuitos e eram consideradas muito vulneráveis, pois com a perda de uma única linha, toda a comunicação dependente dela estaria com certeza

perdida e a rede poderia mesmo ser divida em partes incomunicáveis entre si. Decidiu-se então investir numa idéia até então nova: a comutação de pacotes. Nesse processo não há necessidade de se ter um caminho único reservado fim a fim, mas a informação é dividida em pequenos blocos, chamados pacotes, e cada um deles segue independentemente até o seu destino, onde os blocos são remontados e pode-se recuperar a informação original. Dessa forma pode haver diversos caminhos entre dois pontos que estão se comunicando. Se há problema num deles, os pacotes simplesmente são desviados para outro e a comunicação mantém-se íntegra. O TCP/IP teve, então, desde seu início, o objetivo de poder se conectar transparentemente a um grande número de redes diferentes, além de oferecer uma arquitetura flexível e resistente a falhas, baseada no novo paradigma da comutação de pacotes, podendo ser usada para as mais diversas aplicações. Durante o processo de pesquisa e criação da ARPANET, várias universidades e centros de pesquisa que tinham contratos com o Departamento de Defesa foram também interligados ao sistema. A adoção do TCP/IP e a interligação das universidades a ARPANET foram incentivadas também pelo suporte nativo ao protocolo incluído no sistema UNIX de Berkeley, o 4.2BSD. Em 1983 a ARPANET foi dividida, separando-se os pontos que pertenciam aos militares do restante da rede. Criou-se então a MILNET. Alguns anos antes disso a Fundação nacional de ciência norte americana, a NSF percebendo o enorme impacto favorável às pesquisas que a ARPANET havia criado nas universidades a ela conectadas, resolveu criar a CSNET, uma rede virtual bastante simples, mas que provia acesso à ARPANET e outras redes, permitindo aos pesquisadores trocar emails. A experiência da CSNET foi bem sucedida e em 1984 começou o projeto da NSFNET, que viria ser a sucessora da ARPANET, permitindo o livre acesso de todas as universidades. Em algum ponto da década de 1980, essa junção entre a ARPANET, NSFNET e outras redes começaram a ser vista como uma internet (internet=interconexão entre redes) e mais tarde como a Internet (com "I" maiúsculo, indicando a rede de alcance mundial hoje é conhecida). Seu sucesso e crescimento contínuo permitiram que o governo norte americano deixasse de financiá-la, deixando isso a cargo de empresas privadas. Em outros paí-

ses houve iniciativas parecidas com a construção da NSFNET. No Brasil, pode-se citar dentro dessa linha a criação da RNP e da rede ANSP. A liberação para uso comercial da Internet nos EUA se deu no final da década de 1980, mas foi no início da década de 1990 que seu uso começou a se popularizar nos meios não acadêmicos, com o advento da WEB. As empresas passaram pouco a pouco a conectar suas redes à Internet, usando o protocolo TCP/IP. O TCP/IP passou a ser usado ao lado de outros protocolos, como o IPX/SPX, por exemplo, e pouco a pouco passou a substituí-los, tornando-se um padrão de fato para as redes corporativas em geral.

4.2 O TCP/IP e o Modelo ISO/OSI O TCP/IP, como já citado, não é exatamente um protocolo, mas sim um conjunto de protocolos, batizado em função dos dois primeiros: o TCP e o IP. É bastante comum no entanto, referir-se a todo conjunto simplesmente como o protocolo TCP/IP e este texto não fugirá à regra. Para melhor se entender o funcionamento de um protocolo qualquer se costuma compará-lo a um modelo de referência, chamado modelo ISO/OSI. Esse modelo é composto de 7 camadas, cada qual com sua função específica. Essa divisão facilita tanto o entendimento quanto a implementação do protocolo. O TCP/IP na verdade é dividido em apenas 4 camadas, que podem ser vistas em comparação com as camadas do modelo ISO/OSI na Figura 8. Para cada uma das camadas pode-se imaginar que ela interage diretamente com a camada correspondente no computador com o qual está se comunicando, através da rede. Cada qual tem suas funções e se comunica com as camadas superiores, mas próximas à aplicação, e com as inferiores, mais próximas aos meios físicos de transmissão de dados.

Figura 8: Comparação entre TCP/IP e modelo ISO/OSI Segue um resumo das principais funções de cada uma delas. Camada de Aplicação: As funções dessa camada equivalem as das camadas 5, 6 e 7 do modelo ISO/OSI. Ela faz a interface entre os aplicativos e a camada de transporte. É nessa camada que estão os protocolos como o HTTP (usado na Web), o SMTP (para transporte de emails), o FTP (para envio e recebimento de arquivos), dentre outros. A comunicação dessa camada com a inferior é feita através de abstrações chamadas portas. De forma simplificada: o protocolo HTTP geralmente usa a porta 80 para se comunicar, então, se chegarem pacotes de dados na Camada de Transporte direcionados à porta 80, eles serão entregues ao protocolo HTTP nesta camada. Assim, cada tipo de dado que trafega na rede consegue chegar à aplicação correta que dele faz uso. Camada de Transporte: Esta camada corresponde à camada 4 do modelo ISO/OSI. Sua função é receber os dados da camada superior e formar pacotes que serão enviados pela rede, através da camada de internet. Da mesma forma deve receber pacotes da camada inferior, organizá-los da forma correta e repassá-los à camada seguinte.

Destacam-se dois protocolos nesta camada: •

TCP: Um dos protocolos que empresta o nome ao conjunto todo TCP/IP. Este protocolo consegue garantir a entrega dos dados na ponta remota, através de funções como numeração dos pacotes, confirmação de recebimento, retransmissão, ordenamento dos pacotes que chegam fora de ordem, dentre outras. Dessa forma, mesmo que haja erros nas camadas inferiores, os dados chegam corretamente na outra ponta.

•

UDP: É um protocolo mais simples, que não consegue garantir que os dados cheguem ao destinatário. Ele simplesmente monta os pacotes e os envia. Não há verificação de erros nem reordenamento.

O TCP deve ser usado em aplicações onde a integridade dos dados é importante, como por exemplo, a transferência de arquivos. Há aplicações em que a velocidade de transmissão é mais importante que a integridade dos dados, por exemplo, na transmissão em tempo real de voz ou vídeo; nesses casos o UDP é mais aconselhável. Camada de Internet: Nesta camada está o protocolo IP, o segundo protocolo que empresta o nome à suite TCP/IP. A todo equipamento conectado a uma rede TCP/IP é atribuído um endereço, chamado endereço IP, que identifica o host inequivocamente na rede. Há também alguns tipos de endereços especiais, como para broadcast e multicast, ou seja, para o envio de uma mensagem a todos os equipamentos da rede ou para um grupo, respectivamente. O objetivo da camada IP é fazer com que os pacotes cheguem ao destinatário, ou aos destinatários. Para isso cada mensagem tem de ser direcionada à interface física correta e pode mesmo ter de atravessar vários equipamentos e redes diferentes, durante o trajeto. A camada IP corresponde à camada 3 no modelo ISO/OSI. Camada de Interface com a Rede: Esta camada corresponde às camadas 2 e 1 do modelo ISO/OSI e é mais fácil de ser entendida se for subdividida segundo esse modelo. A primeira subcamada é, então, a camada de Link de Dados ou Enlace. Ela tem por função receber os dados da camada superior e montar pacotes adicionando dados pertinentes ao meio físico como, por exemplo, endereço físico da placa de rede, CRC e dados de controle. A segunda subcamada é a que

vai transformar esses pacotes (ou quadros, como mais comumente chamados nesse contexto) em sinais elétricos ou de outra natureza, conforme o meio físico utilizado, e vai enviá-los através deste. Há diversos meios físicos que podem ser utilizados com o protocolo TCP/IP. Por exemplo, a Ethernet (cabo coaxial, par trançado, fibras ópticas), as interfaces seriais (RS232, V.35), sinais de rádio (Bluetooth, 802.11b), dentre outros. Cabe ressaltar que foram considerados os aspectos mais relevantes e de interesse a este trabalho, existindo outros protocolos e características que foram intencionalmente omitidos.

4.3 A Ethernet A interface Ethernet é uma das possibilidades a serem utilizadas no meio físico para o protocolo TCP/IP. É um padrão para rede local amplamente utilizado e se tornou um padrão de mercado. Faz-se importante deixar claro que é possível a utilização do TCP/IP sem a Ethernet, e da Ethernet sem o TCP/IP; no entanto, para as redes locais o par Ethernet -TCP/IP tornou-se o padrão de fato do mercado. São as placas padrão Ethernet, nas suas diversas versões, que conectam hoje a maioria dos microcomputadores a algum tipo de rede. E são os chips desse tipo de interface que sofreram um grande barateamento nos últimos anos, devido à fabricação em massa. Quando se fala então da utilização do TCP/IP em automação ou em aplicações dedicadas, geralmente pensa-se na utilização da Ethernet para o meio físico, embora outras possibilidades como o padrão 802.11b (Ethernet sem fio) ou Bluetooth tenham cada vez mais aplicações. O padrão Ethernet surgiu na década de 1970, a partir de um experimento da Xerox, que interligava 100 estações de trabalho através de uma rede utilizando CSMA/CD (Carrier Sense Multiple Access with Collision Detection), num cabo de 1km de comprimento. O experimento funcionou tão bem que Xerox, DEC e Intel escreveram um padrão para a Ethernet a 10Mbps. Esse texto acabou servindo como base para o IEEE 802.3, que padroniza redes do tipo CSMA/CD. O padrão Ethernet corresponde às duas primeiras camadas do modelo ISO/OSI, mas a camada de Enlace de Dados é dividida em duas partes: Camada de Controle do Link Lógico (LLC) e Camada de Controle de Acesso ao Meio (MAC). A primeira

tem por função entregar e receber os dados para o protocolo de alto nível adequado. A segunda de controlar o acesso ao meio físico, para isso utiliza-se de um endereço chamado endereço físico, ou MAC address; este endereço é composto de 6 bytes, 3 definindo o fabricante e 3 definindo a numeração da placa, dada pelo mesmo, dessa forma cada placa Ethernet no mundo tem um endereço único. Na camada física é usado o esquema CSMA/CD: numa rede Ethernet todas as interfaces dividem o mesmo meio físico e não há nenhum tipo de prioridade, de forma que existe a possibilidade de duas ou mais delas perceberem que o meio está livre e enviarem um quadro de dados simultaneamente, o que é chamado de colisão. Quando ocorre uma colisão as placas a detectam, param a transmissão e tentam retomá-la após esperar um tempo aleatório. Há diversas versões para o padrão Ethernet, cada qual com velocidade e tipo de cabeamento específico: 10Base2: 10Mbps, cabo coaxial fino. Topologia tipo barramento. Hoje é um padrão obsoleto. 10Base5: 10Mbps, cabo coaxial grosso. Topologia tipo barramento, Hoje é um padrão obsoleto. 10BaseT: 10Mbps, par trançado. Topologia em estrela (que exige um elemento concentrador: um hub ou switch). É um padrão ainda utilizado. 10BaseFL: 10Mbps, fibra óptica. Topologia em estrela. 100BaseT: 100Mbps (Fast Ethernet), par trançado. Topologia em estrela. É o padrão atual de mercado para redes corporativas, lentamente dando lugar à Gigabit Ehternet. 100BaseFX: 100Mbps (Fast Ethernet), fibra óptica. Topologia em estrela. 1000BaseT: 1Gbps (Gigabit Ethernet), par trançado. Topologia em estrela. 1000BaseSX: 1Gbps (Gigabit Ethernet), fibra óptica. Topologia em estrela. 1000BaseLX: 1Gbps (Gigabit Ethernet), fibra óptica. Topologia em estrela

4.4 Ethernet e TCP/IP em Aplicações Dedicadas Aplicações dedicadas são aquelas em que há um sistema computacional dedicado a uma tarefa específica. Geralmente esse sistema é mais simples e tem menos capacidade de processamento do que os encontrados em microcomputadores domésticos, por exemplo. Seu hardware é costumeiramente baseado em componentes chamados microcontroladores, que incluem praticamente todos os blocos necessários a um sistema do gênero num único chip (MITRE, 1999) (WIKIPEDIA, 2004). Os sistemas dedicados podem ser e são utilizados nas mais diversas áreas. Seguem alguns exemplos de sistemas que se encaixam nessa definição: •

Sistemas de controle de eletrodomésticos, como geladeiras, máquinas de lavar, televisores, etc.

•

Sistemas de controle utilizados em automóveis, como o do ABS, injeção eletrônica, etc.

•

Sistemas de controle utilizados na indústria, para controlar robôs e outros equipamentos.

•

Sistemas utilizados para controlar os diversos periféricos dos microcomputadores, como impressoras, scanners, webcams, etc

•

Sistemas de medida, monitoração ou aquisição de dados.

Na verdade, com a popularização, queda de preço e aumento de performance dos microprocessadores e microcontroladores ao longo do tempo, os sistemas dedicados têm sido usados em lugares onde antes eram aplicadas outras soluções para controle ou monitoração e a tendência é de que novas aplicações continuem surgindo e tornando-se viáveis com o passar do tempo. O TCP/IP é bastante complexo, formado por um grande número de protocolos diferentes, cada qual cumprindo sua função específica. Há pouco tempo considerarse-ia seu uso em sistemas dedicados inviável, devido a seu custo e à capacidade de processamento necessária para implementá-lo. Dois fatores principais têm mudado esse quadro nos últimos anos:

•

A popularização das redes de computadores fez com que o custo das interfaces utilizadas, especialmente a Ethernet, caísse consideravelmente.

•

A evolução dos microprocessadores e microcontroladores permitiram que novos modelos, com capacidade de processamento suficiente para a implementação do TCP/IP e custo baixo, surgissem no mercado. O uso do TCP/IP em dispositivos dedicados permite que eles se conectem a uma

rede e à Internet. É possível imaginar cenários não muito distantes onde pessoas irão acessar o endereço IP de sua geladeira e regular, via Internet, sua temperatura, ou obter estatísticas de consumo de energia. Ou talvez acessar o endereço de seu microondas e começar a preparar o assado 20 minutos antes de chegar em casa. Controlar luzes e visualizar o status de equipamentos da casa remotamente podem se tornar comportamentos comuns. Em aplicações no ambiente comercial ou industrial, cada equipamento poderia ter o seu próprio servidor web, a partir do qual seriam feitas as suas configurações, calibração, leitura de dados e estatísticas, etc. Vários fabricantes de microcontroladores oferecem soluções para a implementação de sistemas utilizando TCP/IP com interface Ethernet baseadas em seus processadores: A Atmel, por exemplo, oferece um kit chamado Web - TCP/IP com duas opções de processadores, ambos baseados no 8051, com 32Kbytes de memória flash, um deles com interface CAN integrada e o outro não. Os kits possuem porta serial RS232 e um modem padrão V.34. A empresa desenvolveu uma biblioteca TCP/IP que implementa protocolos como HTTP, FTP, SMTP, PPP, TCP, UDP, ICMP, entre outros. Dentre as aplicações sugeridas estão: controles industriais, automação de edifícios, controle remoto, leitores de smart cards, sistemas de alarme, servidores de aplicação e máquinas de venda (ATMEL, 2002). A Microchip oferece um kit que usa o processador PIC 16F877 ou PIC 18C452. Possui interfaces Ethernet e RS-232. A biblioteca TCP/IP, nesse caso, é fornecida por uma segunda empresa, a Iosoft Ltda (MICROCHIP, 2001). Há processadores PIC extremamente baratos e é fácil encontrar vários sites na Internet com projetos que deles se utilizam para implementar pequenos webservers,

alguns usando apenas interface serial e um protocolo como SLIP ou PPP com custos próximos a US$10,00. São projetos que funcionam muito mais como prova de conceito e talvez tenham pouca utilidade prática atualmente, no entanto, ilustram bem a tendência de barateamento desse tipo de solução e são indícios de um futuro promissor nessa área (SANDERS, 2003) (SHRIKUMAR, 2003). A Dallas/Maxxim oferece um modelo de processador, o DS80C400, baseado no 8051, o processador possui integradas interface Ethernet e CAN 2.0B. Um grande diferencial é que a biblioteca TCP/IP e um sistema operacional multithread estão gravados na ROM do chip. Além disso está disponível uma JVM (Java Virtual Machine) para a plataforma, permitindo a programação em Java, além das linguagens C e assembly do 8051 (DALLAS/MAXIM, 2003). A Zilog trabalha com uma linha de processadores chamada de eZ80, baseados nos antigos Z80, designada para aplicações desse gênero. Alguns modelos do processador vêm com a interface Ethernet já integrada. Juntamente com o kit de desenvolvimento é disponibilizada também a biblioteca TCP/IP, que contém uma implementação bastante completa do protocolo. Dentre as aplicações sugeridas é enfatizada a de webserver embarcado (ZILOG, 2001b) (ZILOG, 2001a) (GIOVINO, 2000). Para aplicações que demandem uma capacidade de processamento maior uma solução possível é utilizar-se uma versão adaptada do sistema operacional Linux, chamada de uCLinux, capaz de rodar em processadores sem MMU (Memory Management Unit). O Linux tem uma boa implementação do TCP/IP, além de ser um sistema robusto e de código fonte aberto. O sistema foi portado para diversos tipos de processadores, como os derivados do 68000 (Dragon-Ball, por exemplo), os ARM, H8, Intel i960, entre outros. Há empresas que vendem plataformas de desenvolvimento e existem vários produtos comerciais baseados no uCLinux. A Arcturus Networks (ARCTURUS NETWORKS, 2003), por exemplo, disponibiliza módulos chamados de uCDIMM. Há módulos em várias versões, eles diferem entre si nos processadores utilizados, capacidade computacional e de memória. Um dos kits de desenvolvimento, por exemplo, é um projeto de referência para um roteador residencial, com possibilidade de trabalhar com Ethernet 10baseT, 100baseT, RS232 e HDLC. Outro dos produtos disponíveis, um módulo com o processador Motorola Coldfire, 8Mbytes de memória flash, duas portas Ethernet e duas portas seriais, custa em torno de US$90.00 para quantidades acima de 500 peças. Um preço alto se com-

parado com os US$10.00 da solução minimalista baseada em PIC, mas ainda assim bastante razoável se levadas em consideração as capacidades do módulo (UCLINUX, 2003) (LINEO, 1999) (ARCTURUS NETWORKS, 2003). Outra possibilidade para aplicações que demandem uma capacidade de processamento maior, é a de utilizar-se um hardware padrão PC, com processadores x86. Há a possibilidade de utilizarem-se placas padrão PC-104, por exemplo, ou outros modelos baseados nos processadores x86. Pode-se então utilizar uma instalação Linux customizada para a aplicação em questão; ou mesmo DOS ou Windows, conforme o caso. Provavelmente essa é a solução mais fácil de ser implementada, porém também a mais cara. Há que se considerar alguns fatores para a escolha dentre as diversas possibilidades existentes, como por exemplo: •

Adequação ao problema, em termos de capacidade de processamento e recursos como interfaces de entrada e saída.

•

Custo final do equipamento.

•

Tempo e custo de desenvolvimento, ferramentas e documentação disponíveis.

4.5 Ethernet e TCP/IP em Aplicações de Automação A Ethernet e o TCP/IP têm sido usados com freqüência crescente e m aplicações de automação, especialmente de automação industrial. Dentre os fatores que colaboram para este quadro, pode-se citar: •

A utilização cada vez mais freqüente de microcomputadores no lugar de PLCs no chão de fábrica. Como PCs, Ethernet e TCP/IP têm sido utilizados conjuntamente com sucesso em outros ambientes, torna-se natural pensar em utilizá-los dessa mesma forma também em automação (MURRAY, 2002).

•

Os padrões Ethernet e TCP/IP são uma alternativa aos inúmeros padrões de barramento de campo que existem, incompatíveis entre si. São uma promessa de compatibilidade futura e de durabilidade (JOUGA, 2001). E, enquanto es-

tes padrões concorrentes parecem ter chegado a seus limites, há um claro caminho para o aumento de banda e outros recursos utilizando-se Ethernet e TCP/IP (DECOTIGNIE, 2001). •

É possível com Ethernet e TCP/IP a utilização de um só tipo de rede, desde o escritório até o chão de fábrica. Isso pode facilitar o tráfego de informações, facilita o gerenciamento da rede e restringe o conhecimento técnico necessário (JOUGA, 2001) (DECOTIGNIE, 2001).

•

Queda de preços do hardware necessário (DECOTIGNIE, 2001).

•

Fácil integração com a Internet, o que facilita o gerenciamento à distância da rede (DECOTIGNIE, 2001).

Ao se pensar na utilização da Ethernet e do TCP/IP na automação industrial uma das primeiras questões a ser colocada é se a solução atende aos requisitos da área. Há alguns pontos a serem observados nesse sentido: •

Há problemas em relação às aplicações de tempo real, pois com a Ethernet não há garantias em relação a quesitos temporais. Na prática, no entanto, com o correto dimensionamento da rede, com o uso de chaveadores (switches) e de recursos de QoS (Quality of Service) é possível atender também a pelo menos algumas dessas aplicações. Já foi demonstrado, por exemplo, que com uma rede adequadamente projetada consegue-se trabalhar com tempos de latência para o pior caso da ordem de poucas centenas de microssegundos (JOUGA, 2001). Há algumas tentativas de estender-se ou modificar-se o padrão Ethernet ou o protocolo TCP/IP para lidar com aplicações de tempo real, como a descrita em (PARK; YOON, 1998). Os padrões IEEE 802.1D e 802.1q devem contribuir também para que seja possível utilizar a Ethernet nessas aplicações (KINSELLA, 1999).

•

O custo da solução Ethernet e TCP/IP não é menor que o das outras soluções. Os sistemas computacionais necessários para implementar essa solução também têm de ser mais potentes que para implementar outras, como CAN, por exemplo. Isso faz com que seja inviável implementar em cada dispositivo essa solução, mas é perfeitamente possível concentrar vários sensores ou atuadores numa única interface Ethernet. Além do mais, como já colocado anteri-

ormente, os custos dos sistemas capazes de implementar a solução têm caído sistematicamente (FONDL, 2000). •

Há problemas relacionados à redundância dos links e de segurança dos dados (DECOTIGNIE, 2001) (JOUGA, 2001).

•

O cabeamento é mais complexo e caro do que os dos barramentos convencionais de campo, além do que os conectores e cabos utilizados nos escritórios podem não ser adequados a alguns ambientes industriais (DECOTIGNIE, 2001).

•

A Ethernet e o TCP/IP não oferecem soluções completas em termos de protocolos. São necessários protocolos suplementares. Há várias tentativas de padronização, por exemplo: Fieldbus Foundation HSE, Profibus ProfiNet, EtherNet/IP, IAONA, MODBUS TCP e IDA.

Para a maioria desses problemas há soluções, se não ainda definitivas, mas que permitem a utilização da Ethernet e TCP/IP na maioria dos casos. Já que é possível utilizar Ethernet e TCP/IP, uma segunda questão sobre o tema deve ser colocada e diz respeito à real possibilidade de se ter ganho nesta escolha. Não há, em geral, consenso nessa questão e a resposta depende de que lugares a Ethernet e TCP/IP assumem no sistema de automação. Os diversos fabricantes têm soluções diferentes, que refletem de certa forma sua resposta específica a essa questão. Podem-se dividir as soluções Ethernet e TCP/IP propostas atualmente para automação industrial em três tipos básicos (JOUGA, 2001): •

Soluções para interconectar o barramento de campo tradicional e a Ethernet.

•

Soluções para empacotar o protocolo tradicional usando Ethernet e TCP/IP.

•

Proposta IDA (Interface for Distributed Automation)

No primeiro bloco podem ser enquadradas soluções como: Profinet (Siemens) e WorldFIP. No segundo bloco podem ser enquadradas soluções como: Modbus/TCP, Ethernet/IP e HSE. A proposta IDA se baseia na filosofia de sistemas distribuídos, onde a inteligência é distribuída por diversos controladores descentralizados, que são conectados via Ethernet; contempla tanto ferramentas para aplicações de tempo real

como para as não críticas. Mesmo com a falta de padronização, há o fato de que o meio físico Ethernet é comum para as diversas soluções É possível rodar mais de um protocolo de alto nível baseado em TCP/IP sobre a mesma rede Ethernet, mesmo que eles não interoperem. Mesmo que nos dias atuais a vantagem do uso das soluções Ethernet e TCP/IP em detrimento das tradicionais seja discutível, é provável, com o avanço na padronização, com a queda de preço, com o aumento do poder de processamento dos microcontroladores e conforme são solucionados os problemas relacionados às aplicações de tempo real, segurança, e outros, que a Ethernet e o TCP/IP venham a substituir em grande parte os padrões e protocolos tradicionais usados em automação, mesmo no nível de instrumentação

4.6 Conclusão Pôde-se discutir neste capítulo questões relacionadas com a utilização dos padrões Ethernet e TCP/IP e como eles têm gradativamente ocupado nichos em aplicações dedicadas e de automação e colaborado para minimizar os problemas relacionados à interoperabilidade entre os sistemas. Infelizmente o custo financeiro envolvido em implementar-se um sistema baseado somente em Ethernet e TCP/IP ainda é alto, obrigando a busca de uma alternativa para a aplicação no Laboratório de Abelhas, Optou-se então por utilizar-se o TCP/IP apenas num nível destinado à supervisão, enquanto para a instrumentação em si será utilizado o padrão CAN, mais adequado do ponto de vista financeiro. O protocolo CAN é discutido no capítulo seguinte.

5. O PROTOCOLO CAN O protocolo CAN foi criado pela Bosch, em parceria com a Intel, em 1991, com a finalidade de ser utilizado na industria automobilística (STRAUSS, 2001). A quantidade de eletrônica embarcada em veículos havia aumentado consideravelmente e as ligações entre os diversos elementos se tornavam cada vez mais complicadas. Havia necessidade de uma nova forma de interligar os diversos módulos, com características como (GUIMARÃES, 2003): •

cabeamento reduzido e flexível, de fácil instalação;

•

capacidade para aplicações em tempo real, altas taxas de transmissão de informação;

•

arquitetura descentralizada, sem a necessidade de um módulo de gerenciamento;

•

facilidade de expansão;

•

capacidade de funcionar em ambiente hostil, como o dos automóveis e demais veículos;

•

confiabilidade, resistência a falhas.

Nesse contexto surgiu o CAN que, por atender todos os requisitos apresentados, em pouco tempo ganhou a aceitação do mercado (GUIMARAES, 2003). Ele foi padronizado pela SAE (Society of Automotive Engineers) e depois pela ISO (ISO 11898 e ISO 11519) (STRAUSS, 2001). Existem no mercado diversos chips controladores disponíveis, como por exemplo o Intel 82527 (INTEL, 1993), o Philips SJA 1000 (MARSH, 2002), além de diversos processadores com controladores CAN integrados, de fabricantes como Atmel, Infineon, Microchip e Motorola (MARSH, 2002) (KEITH PAZUL, 1999). Devido às suas características técnicas, aliadas ao baixo preço e facilidade de uso dos chips controladores, logo se encontrou uso para o CAN em diversas áreas, além da indústria automobilística (SHOFIELD, 1999) (SILVA; CUGNASCA; SARAIVA; 2002) (STRAUSS; CUGNASCA; SARAIVA, 1998) (STRAUSS; CUGNASCA; SARAIVA, 1996) (THOMPSON et al., 1999) (STAFFORD, 1993) (CAN-CIA, 2002) (MARSH, 2002) (DUNNE et al., 2002). Há aplicações para o protocolo, por exemplo, nas áreas de:

•

automação agrícola e (GUIMARAES, 2003);

•

automação predial (DUNNE et al., 2002) (CAN-CIA, 2002);

•

automação industrial (CAN-CIA, 2002) (PORT, 2002);

•

equipamento médico (CAN-CIA, 2002);

•

industria aeronáutica (THOMPSON et al., 1999).

maquinário

agrícola

(STRAUSS,

2001)

5.1 Características do CAN O CAN é um protocolo serial síncrono, cuja especificação abrange apenas as duas camadas inferiores do modelo ISO/OSI, como visto na Figura 9 (INTEL, 1993).

Modelo ISO/OSI

CAN

Aplicação

Apresentação

Sessão

Transporte

Rede

Enlace de dados

Física

Figura 9: Comparação entre CAN e modelo ISO/OSI Na camada física geralmente é usado um cabo com dois fios, denominados CAN_H e CAN_LO. A sinalização é do tipo diferencial, que garante uma ótima imunidade a ruídos. Há dois estados possíveis (GUIMARAES, 2003) (MARSH, 2002):

Bit 0 ou Dominante: Corresponde à tensão de 2V entre os fios (em termos absolutos CAN_H=3.5V e CAN_L=1.5V) Bit 1 ou Recessivo: Corresponde à diferença de potencial de 0V entre os fios (em termos absolutos ambos fixos em 2.5V). Este é o estado normal da rede quando nenhum dos módulos a esta acessando. A maior taxa de transmissão é de 1Mbps, para um barramento de 40m, sendo inversamente proporcional ao comprimento do barramento. Para um barramento de 1Km, a taxa máxima é de 50kbps (GUIMARAES, 2003). O método utilizado para acesso ao meio físico é o CSMA/CD+AMP (Carrier Sense Multiple Access/Collision Detection with Arbitration on Message Priority) (STRAUSS, 2001), também chamado de CSMA/CD+NDA (Carrier Sense Multiple Access/Collision Detection with Non Destrutive Arbitration) (GUIMARAES, 2003) ou CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance) (MARSH, 2002). Todos os módulos verificam o estado da rede antes de iniciar uma transmissão, se ela estiver livre, o módulo começa a transmitir; porém, a cada bit colocado na rede, o módulo verifica novamente o estado desta: se ele enviou um bit Recessivo, mas leu da rede um bit Dominante, ele interrompe a transmissão e torna-se um receptor. No caso inverso o módulo continua a transmitir, pois tem prioridade sobre os outros. Dessa forma, os primeiros bits da mensagem, que são denominados Identificador, determinam sua prioridade (STRAUSS, 2001) (GUIMARAES, 2003). Há mecanismos para detecção de erros como bit Stuffing/Destuffing, que consiste em detectar-se 6 bits sucessivos de mesmo valor (com exceção dos campos fixos). CRC, que é enviado pelo transmissor e checado pelos receptores. Bit monitoring, que consiste no módulo transmissor verificar se os bits Dominantes estão sendo transmitidos corretamente. Frame check, que é a verificação de alguns bits com valores fixos, determinados pelo padrão CAN. E Acknowledgment Error Check, que consiste num bit Dominante escrito pelos receptores a cada mensagem recebida corretamente, a ser verificado pelo transmissor (STRAUSS, 2001) (GUIMARAES, 2003). Há um método sofisticado de tratamento de erros, que não cabe analisar neste texto. Contudo, deve-se saber que os módulos CAN podem se encontrar em três estados, em caso de detecção de erros (STRAUSS, 2001) (GUIMARAES, 2003):

Error Active: Em caso de detecção de erros o módulo responde enviando 6 bits Dominantes, causando ele próprio um erro de Stuff nos demais módulos. Error Passive: Para um número alto de erros detectados, isso pode significar problemas no próprio nó, que passa a responder aos erros colocando 6 bits Recessivos na rede, não estragando a mensagem atual, a menos que o próprio módulo seja o transmissor. Bus Off: Se o número de erros é muito elevado o nó desliga-se da rede. Há dois formatos possíveis para as mensagens CAN, denominados CAN 2.0A e CAN 2.0B, conforme visto na Figura 10 (STRAUSS, 2001) (GUIMARAES, 2003). CAN 2.0A Start bit

(R) (D)

ACK

RTR Identificador 11 bits

(D) (D)

Dados 0 a 64 bits

DLC 4 bits

CRC 15 bits

(R)

EOF+IFS 10 bits (R)

IDE

CAN 2.0B Start bit

(R) (D)

SRR Identificador 11 bits

(R) (R)

RTR Identificador 18 bits

(D) (D)

ACK DLC 4 bits

Dados 0 a 64 bits

CRC 15 bits

(R)

EOF+IFS 10 bits (R)

IDE

Figura 10: Formato das mensagens CAN 2.0A e 2.0B Segue

explicação

significado

dos

campos

(STRAUSS,

2001)

(GUIMARAES, 2003) (MARSH, 2002) (KEITH PAZUL, 1999): Start Bit: É o primeiro bit Dominante, após um período de inatividade da rede no estado recessivo, indicando o início de uma transmissão de mensagem. Identificador: Identifica a mensagem que está sendo transmitida. Conforme explicado quando da explanação sobre o método de acesso ao meio CSMA/CD+AMP, estes bits servem também para arbitração, indicando a prioridade das mensagens. É importante ter-se em mente que o CAN é um protocolo orientado a mensagens, e não a equipamentos. As mensagens são enviadas em broadcast e todos os nós da rede as recebem, decidindo se vão tratá-las ou descartá-las. Não há, a princípio, um identificador para cada e-

quipamento na rede, apenas identificadores de tipos de mensagens. Poderiam ser especificados, no entanto, mensagens específicas de ou para um determinado módulo, caso necessário para a aplicação. Com o formato 2.0A é possível até 2048 tipos de mensagem diferentes na rede, pois o identificador tem somente 11 bits. Isso pode ser pouco para algumas aplicações. Já com o formato 2.0B, com identificador de 29 bits são possíveis cerca de 537 milhões de mensagens diferentes o que, na prática, significa o fim dessa limitação. No entanto, os bits adicionais do formato 2.0B significam um tempo maior de transmissão o que pode ocasionar problemas em determinadas aplicações de tempo real. RTR (Request for Transmission): Quando dominante indica que a mensagem é de envio de informações, caso contrário, indica uma requisição. Também faz parte de arbitração. SRR (Substitute Remote Request): Presente apenas na versão 2.0B é sempre Recessivo, de forma a garantir que mensagens no formato 2.0A tenham prioridade numa rede mista. IDE (Identifier Extension): Permite diferenciar entre as versões de protocolo, sendo Dominante no CAN 2.0A, de forma que numa rede mista as mensagens neste formato têm maior prioridade. DLC (Data Length Code): Campo com 4 bits, indica o tamanho do campo de dados, que pode ter de 0 a 8 bytes. Dados: Campo com os dados. CRC (Cyclic redundance Code): Campo com 15 bits, para checagem de erros. EOF (End of Frame): Fim da mensagem, 7 bits Recessivos. INT (Interframe Space): Espaço entre frames.

5.2 Conclusão Pôde-se, neste capítulo, introduzir o protocolo CAN, cujas características o tornaram de grande aceitação nas mais diversas áreas de automação. Por ele ser facilmente implementado através de componentes eletrônicos de baixo custo, torna-se também uma excelente escolha para a rede de instrumentação inteligente do Laboratório de Abelhas. Uma característica negativa, no entanto, que deve ser comentada, é que o fato da especificação do CAN envolver apenas as duas camadas inferiores do modelo ISO/OSI, o que torna necessário o desenvolvimento de software para desempenhar as funções das demais camadas. Além do que, mesmo nas camadas inferiores há decisões a serem tomadas no projeto da rede que não fazem parte das especificações, como por exemplo, a velocidade do barramento. Existem alguns padrões utilizados em áreas específicas, que definem estes pontos que a norma deixa em aberto, como o CANOpen e o DeviceNet na automação industrial, ou o ISO 11783 na automação agrícola (GUIMARAES, 2003) (MARSH, 2002). No entanto, decidiu-se não utilizá-los nesta aplicação. Isso tornou necessária a análise do protocolo num nível um pouco mais baixo do que o do TCP/IP e Ethernet, chegando-se aos bits e níveis elétricos da rede, para que certas decisões de projeto possam ser tomadas adequadamente. No próximo capítulo serão discutidos os detalhes da implementação, com ênfase no caso do CAN para o Dicionário de Dados que é a definição de todas as mensagens possíveis na rede, com indicação de que módulos transmitem e recebem cada uma delas.

6. PROPOSTA DE UM SISTEMA DE INSTRUMENTAÇÃO INTELIGENTE, BASEADO EM CAN E TCP/IP Neste capítulo será apresentada uma proposta de um sistema de instrumentação para o Laboratório de Abelhas do Instituto de Biociências, baseada nos requisitos iniciais de: flexibilidade, expansibilidade, confiabilidade, adequação ao problema, aderência a padrões abertos e custo acessível, complementando os trabalhos anteriores. 6.1 Considerações Preliminares No capítulo dois deste trabalho pôde-se discutir a importância da pesquisa sobre os Meliponíneos, bem como a necessidade de instrumentação adequada para que ela possa ser realizada. Tomou-se contato com trabalhos anteriores relacionados ao tema (CUNHA, 2001) (WEBBEE, 2004) (OLIVEIRA; SARAIVA, 2002) e observou-se a necessidade de sua complementação. No capítulo três, foram estudados conceitos de automação. Pôde-se concluir que arquiteturas distribuídas, baseadas em barramentos de campo, ou redes de instrumentos inteligentes, apresentam vantagens em relação a outras possibilidades, como menor custo, maior facilidade de instalação e configuração, maior flexibilidade e facilidade de manutenção, características essas desejáveis para a aplicação em questão, pelo que se decidiu pelo projeto do sistema na forma de uma rede de instrumentos inteligentes. Ainda no capítulo três discutiu-se a importância da padronização e dos padrões abertos na automação, pôde-se estudar a importância do TCP/IP nesse contexto. O TCP/IP e a Ethernet, estudados com maiores detalhes no capítulo quatro, representariam uma boa escolha para a aplicação no Laboratório de Abelhas, dada a importância que têm atualmente em aplicações de automação e outras aplicações dedicadas. A decisão de se utilizar esses protocolos esbarra nos custos de implementação, ainda considerados inviáveis nesse caso. Optou-se então por uma solução de compromisso (representada na Figura 11), utilizando-os no nível de supervisão do sistema, responsável pelo armazenamento de parte das informações da rede e pela interface com os usuários e outros sistemas, enquanto para o nível mais baixo, da

instrumentação em si, optou-se pelo padrão CAN discutido no capítulo 5. Ele foi escolhido pelas suas características técnicas, que o tornam adequado para a aplicação, além da facilidade de implementação, através de componentes eletrônicos de baixo custo. Esse protocolo foi objeto de estudo de outras pesquisas no Laboratório de Automação Agrícola (STRAUSS, 2001) (GUIMARÃES, 2003) (SILVA, 2002), algumas das quais incluíram o projeto e montagem de módulos experimentais, que puderam em parte, ser reutilizados na avaliação desta proposta.

Rede Ethernet / TCP/IP (pode ser ligada à intranet ou à Internet) Módulo de Supervisão

Módulo de Supervisão (opcional)

........

Rede CAN

Módulo de aquisição e controle

........

Módulo de aquisição e controle

Nível dos Sensores e Atuadores Figura 11: Diagrama da rede de instrumentação proposta. O projeto pode ser dividido em três partes: •

Projeto dos módulos de aquisição e controle.

•

Projeto da rede CAN.

•

Projeto dos módulos de supervisão e da interface TCP/IP.

6.2 Projeto dos módulos de aquisição e controle 6.2.1. Projeto de hardware Para cada colônia de abelhas são necessárias, no mínimo, medidas de:

•

Temperatura da colônia.

•

Temperatura da caixa (temperatura externa da colônia).

•

Umidade relativa do ar interna.

•

Contagem de entrada e saída de abelhas.

Outras medidas que podem ser utilizadas em algumas experiências são: •

Temperatura ambiente.

•

Umidade ambiente.

•

Luminosidade.

•

etc.

Prevê-se ao menos um atuador, do tipo liga e desliga, para controle do aquecedor que tem influência sobre a temperatura da caixa. O hardware dos módulos foi baseado no protótipo desenvolvido por Guimarães (2003), mostrado na Figura 12, que foi gentilmente cedido para a realização deste trabalho. O projeto é baseado em uma variante do microcontrolador 8051, o P87C591, da Philips, operando com um sinal de relógio de 11.0592Mhz (PHILIPS, 2000a) (PHILIPS, 2000b). Este microcontrolador, além dos recursos básicos da família 8051, como temporizadores, interface serial e portas de entrada e saída digitais, possui internamente também os seguintes recursos, de interesse para este projeto: •

Interface CAN 2.0B.

•

Conversor Analógico/Digital de 10 bits, com 6 entradas multiplexadas.

•

Interface I2C.

O projeto resultante, cujo diagrama em blocos pode ser observado na Figura 13, prevê oito pinos para interface de entrada e saída, suficientes para as necessidades da aplicação. Quatro deles podem ser configurados tanto como entradas analógicas (para uso com sensores de temperatura, umidade e luminosidade, por exemplo), como entradas digitais (para uso com o sensor de contagem de abelhas ou outros) ou como saídas digitais (para acionar atuadores, como o aquecedor, por exemplo). Os quatro restantes podem ser configurados como entradas ou saídas digitais. Dois deles podem também ser configurados para acionar os temporizadores internos e dois para acionar interrupções.

Figura 12: Protótipo do módulo CAN.

PCA82C250 CAN CAN

MAX 232C serial

Philips P87C591 EPROM 27256 32Kbytes

RAM 62256 32Kbytes

serial

Entrada e Saída EEPROM

I 2C Interface Analógica ou Digital

Interface Digital + Timer ou Int.

Figura 13: Diagrama em blocos do módulo de aquisição e controle. Há um circuito integrado de memória EPROM, com capacidade de 32Kbytes, destinado na fase de prototipagem a armazenar um programa monitor, que possibilita a carga do programa a ser executado na memória RAM. Na versão final do módulo a memória EPROM será destinada a armazenar o software do mesmo e não mais um programa monitor.

A memória RAM, também com capacidade de 32Kbytes tem por objetivo o armazenamento de dados e variáveis do programa. No protótipo ela é mapeada simultaneamente como memória de dados e de programa, permitindo que sejam nela carregadas versões do software para testes, através do programa monitor. Conectada à interface I2C há uma memória serial EEPROM, 24LC08, que mantém os dados armazenados mesmo na ausência de alimentação para o circuito. Esta memória tem por objetivo o armazenamento de informações sobre os sensores, como labels, valores máximos e mínimos e unidade da grandeza medida, dentre outras. Isso possibilita a reconfiguração dos módulos, no tocante aos tipos e finalidades dos sensores e atuadores instalados, sem a necessidade de mudança de software. Há também circuitos conversores de nível de sinal, chamados transceivers, para as interfaces serial e CAN. O transceiver serial é o MAX232C, enquanto o CAN é o PCA82C250 (PHILIPS, 1996) (PHILIPS, 1997). Além dos circuitos TTL 74LS373 e 74LS00, destinados à interface entre o microcontrolador e os circuitos integrados de memória. 6.2.2. Projeto de software Para o desenvolvimento do software do protótipo foi utilizado o compilador SDCC (Small Device C Compiler) (SOURCEFORGE, 2001). É um compilador que segue a filosofia do software livre, sendo licenciado nos termos da GPL (General Public License) da Free Software Foundation. Permite a geração de código para os processadores da família 8051, bem como para HC08, Z80 e PIC. Foi utilizado no protótipo o programa monitor PAULMON, de domínio público (STOFFREGEN, 2001). Este programa é gravado em ROM, permitindo que programas a serem testados sejam enviados ao protótipo via interface serial, com auxílio de um PC com um emulador de terminal qualquer (como o HyperTerminal do Window ou o minicom do Linux, por exemplo). Os programas são carregados e executados na RAM do sistema, facilitando os testes, por tornar desnecessárias sucessivas gravações da memória EPROM. O programa desenvolvido realiza as seguintes tarefas: •

Inicialização do hardware.

•

Leitura e tratamento dos valores dos sensores.

•

Controle de temperatura, através do acionamento e desligamento alternados de um aquecedor. Ou controle de outras variáveis, bastando especificar a qual sensor o atuador deve estar ligado e os valores máximo e mínimo para o algoritmo.

•

Envio das mensagens CAN periódicas.

•

Envio de mensagens CAN em função de alterações no estado dos sensores.

•

Recebimento de requisições de dados via CAN e envio das respostas adequadas.

6.3 Projeto da Rede CAN Como observado no capítulo 5, o protocolo CAN define apenas as duas camadas inferiores do modelo ISO/OSI, e mesmo nesses níveis há alguns parâmetros em aberto, como a velocidade da rede, o tipo de cabeamento e os conectores. Como a aplicação em questão não é crítica do ponto de vista temporal nem da quantidade de mensagens geradas, optou-se por se utilizar uma velocidade baixa na rede CAN, de 100Kbps. Isso torna possível utilizar a rede a distâncias grandes e torna menos crítico o cabeamento. Também facilita a interface com o módulo supervisor, que pode ser feita através de uma interface serial RS232 ou I2C, por exemplo. Optou-se por cabeamento do tipo par trançado e conectores RJ45, ambos utilizados em redes Ethernet, a exemplo do que fizeram Guimarães (2003) e Strauss (2001). Deve ser definido também o conjunto de mensagens utilizados na rede, ou seja, o dicionário de dados da aplicação. Optou-se por utilizar o CAN 2.0b por haver um número maior de mensagens possíveis e, conseqüentemente, uma maior liberdade na definição do protocolo, com possibilidades de expansão futura. O campo identificador foi dividido como indicado na Figura 14, de forma a se poder endereçar cada módulo da rede, além dos sensores e de origem e destino de cada uma das mensagens.

Identificador 29 bits (CAN 2.0B) 28

0 4

0 7 Mensagem

0 7 Destino

Origem

Dispositivo

Figura 14: Formato do Identificador CAN. A divisão escolhida permite que haja: •

254 módulos com endereços distintos na rede. Os endereços 00h e FFh são reservados.

•

15 sensores e 15 atuadores (campo Dispositivo) com endereços distintos em cada módulo. O bit mais significativo em 1 indica atuador, caso contrário, sensor. O endereço 0 é reservado.

•

256 tipos diferentes de mensagens.

Por definição, o endereço 00h será o do módulo de supervisão. Se houver mais de um módulo de supervisão, eles compartilharão o mesmo endereço. O endereço FFh será o endereço de broadcast. Com base nas necessidades da aplicação, foi construída a Tabela 1, relacionando as mensagens necessárias à rede CAN proposta, com os valores presentes no Identificador, o tipo das mensagens e as responsabilidades de cada módulo:

Tabela 1: Mensagens CAN. Mens agem

RTR

Nome

Dispositivo

30h

Sensor.valor

ID do sensor.

31h 32h 33h 34h 35h 36h 37h 38h 39h

0 0 0 0 0 0 0 0 0

Sensor.Max Sensor.min Sensor.label Sensor.unidade Atuador.sensor Atuador.max Atuador.min Atuador.label Atuador.estado

ID do sensor.. ID do sensor. ID do sensor. ID do sensor. ID do atuador. ID do atuador. ID do atuador. ID do atuador. ID do atuador.

30h 31h 32h 33h 34h 35h 36h 37h 38h 39h 3Ah 3Ah FFh

1 1 1 1 1 1 1 1 1 1 0 1 0

Sensor.valor.req Sensor.max.req Sensor.min.req Sensor.label.req Sensor.unidade.req Atuador.sensor.req Atuador.max.req Atuador.min.req Atuador.label.req Atuador.estado.req Modulo.label Modulo.label.req Keep.alive

ID do sensor. ID do sensor. ID do sensor. ID do sensor. ID do sensor. ID do atuador. ID do atuador. ID do atuador. ID do atuador. ID do atuador. 11111b 11111b 11111b

Taxa de Transmissão No evento ou na requisição Na requisição Na requisição Na requisição Na requisição No evento No evento No evento Na requisição No evento ou na requisição No evento No evento No evento No evento No evento No evento No evento No evento No evento No evento Na requisição No evento A cada 5s

Modulo Supervisor RX

Modulo de aquisição TX

RX RX RX RX TX TX TX RX RX

TX TX TX TX RX RX RX TX TX

TX TX TX TX TX TX TX TX TX TX RX TX RX

RX RX RX RX RX RX RX RX RX RX TX RX TX

Foi previsto um método de auto-identificação para os módulos de aquisição e controle, que ao serem ligados na rede anunciam sua presença através de mensagens do tipo Keep.alive. O módulo supervisor, ao receber uma mensagem Keep.alive de um módulo não identificado, automaticamente envia mensagens do tipo Modulo.label.req, Sensor.label.req, Sensor.max.req, etc, requisitando dados sobre todos os sensores e atuadores existentes no módulo. Se um módulo previamente identificado deixa de enviar mensagens por um tempo maior que 30s ele é considerado pelo módulo supervisor como com problemas, sendo que o processo de identificação é repetido caso o módulo volte a funcionar. Optou-se por transmitir os valores, características e estado dos sensores e atuadores através de strings formadas por caracteres ASCII, facilitando a tarefa de visualização no módulo supervisor, ficando as conversões necessárias a cargo dos módulos de aquisição e controle. A Tabela 2 mostra os valores do campo de dados para cada mensagem especificada.

Tabela 2: Mensagens CAN com valores do campo de dados Nome Sensor.valor Sensor.max Sensor.min Sensor.label Sensor.unidade Atuador.sensor Atuador.max Atuador.min Atuador.label Atuador.estado Sensor.valor.req Sensor.max.req Sensor.min.req Sensor.label.req Sensor.unidade.req Atuador.sensor.req Atuador.max.req Atuador.min.req Atuador.label.req Atuador.estado.req Modulo.label Modulo.label.req Keep.alive

Campo de dados String com o valor correspondente. String com o valor correspondente. String com o valor correspondente. String com o valor correspondente. Vazio corresponde a sensor não existente. String com o valor correspondente. ID do sensor. String com o valor correspondente. String com o valor correspondente. String com o valor correspondente. Vazio corresponde a atuador não existente. String com o valor correspondente. Vazio. Vazio. Vazio. Vazio. Vazio. Vazio. Vazio. Vazio. Vazio. Vazio. String com valor correspondente. Vazio. Vazio.

Obs Ex.: 100.0 (em caracters ASCII) Ex.: 150.0 Ex.: 0.0 Ex.: Temp01 (máximo de 8 caracteres) Ex.: graus C, %. ID do sensor que estará ligado a este atuador, para fins de controle. O campo vazio indica que o atuador deve permanecer desabilitado. Valor para o algoritmo de controle. Ex.: 33.5 Valor para o algoritmo de controle. Ex.: 32.5 Ex.: Aquec01 (máximo de 8 caracteres) Ex.: Ligado, Deslig.

Ex.: Colonia2

6.4 Projeto dos módulos de Supervisão e da Interface TCP/IP. O módulo de supervisão, na rede proposta, tem por função principal servir como interface entre os módulos de aquisição e controle e os usuários, ou outros sistemas que necessitem acessar os dados. Utilizando TCP/IP há muitas opções para construir esta interface, como a construção de um servidor de dados proprietário, através da interface sockets e de uma aplicação remota. Poderia ser utilizado um serviço de emails, usando um servidor SMTP, que enviaria os dados relevantes diretamente aos emails dos usuários. Os dados poderiam ser transmitidos na forma de arquivos, pelo serviço TFTP. Poderiam ser usados também webservices. Entre outras possibilidades (ZILOG, 2001a), (ZILOG, 2003d) (ZILOG, 2003e). A solução escolhida foi construir a interface através de páginas web, disponibilizadas por um servidor dedicado no módulo de supervisão e controle. Dessa forma,

priorizou-se a interface com os usuários, que podem acessar os dados de medições nas colônias a partir de um PC convencional com um webbrowser nele instalado, ligado à mesma rede TCP/IP que o módulo, sem necessidade de softwares dedicados ou outros sistemas. Para a implementação do protótipo escolheu-se a solução oferecida pela Zilog (ZILOG, 2001a) (ZILOG, 2001b), pelas seguintes razões: •

Baixo custo e facilidade de acesso ao kit de desenvolvimento.

•

Boas ferramentas de desenvolvimento, como montador, compilador C e debuger, satisfatoriamente documentadas.

•

Disponibilidade de um RTOS e de uma biblioteca de software implementando o protocolo TCP/IP para utilização livre de royalts.

•

Adequação ao problema.

Um dos pontos negativos dessa escolha é que essa solução não possui interface CAN nativa. Isso foi contornado acrescentando-se uma interface CAN ao sistema, através de um gateway CAN – RS232, o que foi viável dada à velocidade baixa escolhida para a rede CAN. O gateway foi construído com o mesmo hardware dos módulos de aquisição e controle e seu software gerencia a transferência de mensagens entre as diferentes interfaces. No caso de ser necessário o aumento de velocidade na rede CAN, a interface do módulo supervisor não poderá mais funcionar através da porta serial, devendo-se implementá-la através de outros meios, como por exemplo utilizando a interface I2C, ou acrescentando-se diretamente um controlador CAN ao circuito. O módulo da Zilog é chamado eZ80 Acclaim! e é baseado num processador da família eZ80, o eZ80F91. Os processadores dessa família são derivados dos antigos processadores Z80 e Z180, mas no entanto possuem características que os tornam adequados para esse tipo de aplicação, como: endereçamento linear de 24 bits (16 Mbytes), relógio de 50Mhz, interface Ethernet (EMAC) 10/100, 256 Kbytes de memória Flash, 8 Kbytes de SRAM, 44 interrupções vetorizadas, DMA, multiplicador de 16bits, portas seriais e de uso geral, entre outras (ZILOG,. 2003a) (ZILOG, 2003c) (ZILOG, 2004). O hardware da plataforma de desenvolvimento é dividido duas placas. Uma de-

las, vista na Figura 15, é o módulo eZ80F91, que contém o processador, a interface Ethernet, 512Kbytes de memória SRAM, 1Mbyte de memória Flash, uma interface IRD e um circuito de relógio de tempo real, com bateria. Esse módulo possui dimensões reduzidas (6cm x 8cm) e pode ser comprado em quantidades suficientes para produção, a fim de ser integrado em dispositivos dedicados. A segunda placa, que funciona como uma base, na qual a primeira se encaixa, tem mais 512Kbytes de SRAM e disponibiliza duas interfaces seriais RS232, interface RS485, interface para depuração, interfaces genéricas de I/O, entre outras (ZILOG, 2003b). A Figura 16 mostra o kit completo.

Figura 15: Módulo eZ80F91

Figura 16: Kit de desenvolvimento eZ80 Acclaim!

Além das placas descritas, acompanham o kit as seguintes ferramentas: Módulo ZPAK: É um módulo para auxiliar na depuração do software. Conecta-se ao PC através da rede e ao módulo através de uma interface específica, chamada ZDI debug interface. Este módulo permite que os programas a serem testados sejam carregados diretamente na memória RAM do sistema, agilizando o processo de desenvolvimento por evitar sucessivas gravações da memória Flash. Permite também a execução do programa passo a passo, ou que sejam definidos breakpoints, e a visualização de posições de memória ou mesmo de registradores da CPU. Zilog Development Studio (ZDS): É um ambiente integrado de desenvolvimento, com editor de texto, montador e compilador C, o qual conecta-se também à interface de depuração. Zilog TCP/IP Software Suite (ZTP): É uma biblioteca de software contendo uma implementação do protocolo TCP/IP que inclui: HTTP, TFTP, SMTP, Telnet, IP, PPP, DHCP, DNS, TIMEP, SNMP, TCP, UDP, ICMP, IGMP, ARP e RARP. Inclui também um sistema operacional multitarefa preemptivo, baseado no sistema XINU. A ZTP é fornecida livre de royalts, porém o código fonte da mesma não é disponibilizado. O programa desenvolvido realiza as seguintes tarefas: •

Recebe as mensagens CAN dos módulos, atualizando variáveis internas com os valores dos sensores.

•

Procede à identificação de novos módulos CAN conectados à rede, através do envio de mensagens solicitando informações sobre os sensores instalados.

•

Disponibiliza as informações sobre os módulos, os valores dos sensores e o estado dos atuadores através de páginas web, visualizáveis à partir de um webbrowser.

Nas Figuras 16, 17 e 18, pode-se observar a interface com o usuário implementada no protótipo, através de páginas HTML dinâmicas. Essas páginas são criadas a cada requisição, com base nas variáveis internas do sistema, as quais são modificadas de acordo com o estado dos módulos de aquisição e controle.

Figura 17: Página inicial da interface com o usuário do módulo de supervisão.

Figura 18: Página mostrando a lista dos módulos conectados à rede.

Figura 19: Página mostrando os valores dos sensores conectados ao módulo 1. O sistema também oferece uma interface do tipo Shell, através de uma das portas seriais RS232, através da qual é possível verificar o funcionamento da rede, com comandos similares aos do Unix, como netstat e ping, e do próprio sistema, utilizando comandos administrativos, como ps e kill, por exemplo. A interface pode ser vista nas Figuras 20 e 21, que mostram o acesso através do programa HyperTerminal do Windows. O fato de se poder utilizar um sistema operacional multitarefa como base para o software facilita bastante o projeto do sistema e a tarefa de programação. Diferentes funcionalidades, como por exemplo a de construir as páginas dinâmicas e a de atualizar as informações sobre os módulos na rede CAN, podem ser realizadas por processos diferentes, rodando simultaneamente. Na Figura 21, podem ser distinguidos, por exemplo, os processos httpd e atualiza_modulos responsáveis, respectivamente por essas tarefas.

Figura 20: Interface Shell, mostrando configurações de rede.

Figura 21: Interface Shell, mostrando os processos .

6.5 Considerações finais. Na Figura 22 pode ser visto um quadro com um resumo da proposta apresentada neste trabalho. Ela possui as características desejadas para a aplicação, tendo várias vantagens em relação ao sistema centralizado, baseado em placa de aquisição, em uso no laboratório.

Figura 22: Quadro resumo da proposta para o Sistema de Instrumentação.

Módulo de Aquisição e Controle Os módulos de aquisição são baseados numa variante do processador 8051, possuindo interface CAN, entradas e saídas analógicas e digitais. Eles têm informações sobre os sensores e atuadores a eles conectados, como por exemplo o tipo dos sensores, valores máximo e mínimos que podem assumir, etc. As informações ficam gravadas na memória EEPROM e podem ser alteradas sem a necessidade de alteração no programa do módulo.

Periodicamente (a cada 5 segundos) os módulos enviam a mensagem Keep.alive

Ao receber as requisições do supervisor, o módulo de aquisição envia as respostas adequadas. Caso o atuador ou sensor não esteja configurado (não esteja presente), é enviada Xxxx.label com campo de dados vazio.

Periodicamente (a cada 5 segundos) os módulos enviam a mensagem Keep.alive

O módulo recebe os comandos do supervisor e configura seus algoritmos internos de controle de acordo com os mesmos. Esses algoritmos são executados autonomamente pelo módulo, procurando manter a variável selecionada dentro da faixa de valores especificada.

Periodicamente ou em virtude eventos determinados, conforme for conveniente para cada tipo de sensor ou atuador, são geradas mensagens com atualização de valores, para os sensores e atuadores presentes. Os valores são transmitidos na forma de caracteres ASCII (strings).

Módulo de Supervisão Mensagens na rede CAN

Keep.alive Sensor.label.req Atuador.label.req .... Sensor.label Atuador.label ....

Keep.alive

Atuador.sensor Atuador.max ....

O módulo de supervisão é baseado na plataforma eZ80 e implementa um servidor web, que é responsável pela interface com o usuário. Ao ser inicializado o supervisor desconhece os demais módulos presentes na rede. Ao receber a mensagem Keep.alive de qualquer módulo desconhecido na rede é iniciado o processo de identificação do mesmo, onde o supervisor requisita dele informações que não são enviadas automaticamente, como nomes dos sensores, sua faixa de atuação, unidades, etc. Para cada um dos 15 sensores do módulo, o supervisor enviará: Sensor.label.req, se a resposta for diferente de um campo de dados vazio, significa que o sensor está de fato presente e o supervisor enviará: Sensor.max.req, Sensor.min.req, Sensor.unidade.req. Um processo análogo ocorre para os 15 possíveis atuadores. Recebendo os dados, o supervisor registra as informações e passa a incluir o módulo com os sensores e atuadores identificados nas páginas web dinâmicas geradas. O supervisor é responsável por pedir retransmissão em caso de não recebimento. Caso a mensagem Keep.alive dos módulos identificados não seja recebida num período de 30 segundos, .o módulo é considerado como tendo sido desligado da rede. Se a mensagem voltar a ser recebida, é feita uma nova identificação. O usuário pode configurar algumas opções dos módulos através da interface web, como por exemplo, se os atuadores estão ou não ativos, e qual o sensor que o controla.

Sensor.valor Atuador.estado ....

O supervisor recebe os dados através das mensagens e os armazena em variáveis, apresentando-os na forma de web pages dinâmicas quando requisitado através do serviço http.

Figura 22: Quadro resumo da proposta para o Sistema de Instrumentação.

A proposta é baseada em dois padrões abertos e de bastante aceitação no mercado: o CAN e o TCP/IP, o que facilita a interoperabilidade. Tem uma arquitetura distribuída, sendo expansível e reconfigurável. O protocolo proposto para a rede CAN é simples e funcional, embora robusto, permitindo que novos módulos ao serem adicionados à rede sejam automaticamente identificados. Os módulos de aquisição e controle são baseados em componentes eletrônicos comuns e de baixo custo. O módulo de supervisão com interface web permite independência em relação a outros sistemas e dispensa softwares proprietários para a visualização dos dados. A interface do módulo de supervisão foi construída inicialmente para usuários humanos, em detrimento de outros sistemas computacionais, como o sistema de informações do WebBee, que dela também podem fazer uso. Isto, no entanto, não é um fator limitante, sendo simples a construção de um pequeno programa de computador, geralmente apelidado de robô, capaz de navegar através da interface existente e extrair os dados necessários.

7. CONSIDERAÇÕES FINAIS 7.1 Contribuições do trabalho. Foi proposta uma rede de instrumentação inteligente, com características como baixo custo, adesão a padrões abertos, flexibilidade e expansibilidade, aplicada ao laboratório de abelhas do IB – USP. Devido à generalidade da solução adotada, essa mesma proposta pode utilizada em outros domínios de aplicação. Foram discutidos os barramentos de campo, em especial a problemática da interoperabilidade na área, apontando o uso da Ethernet e do TCP/IP como possível solução. Este trabalho é o primeiro a estudar o TCP/IP como barramento de campo e em sistemas dedicados em geral no Laboratório de Automação Agrícola, abrindo várias possibilidades para continuidade das pesquisas. Foi estudada a plataforma eZ80 que pode ser utilizada em outros trabalhos nessa linha de pesquisa. Foi proposto um protocolo de comunicação simples e funcional, utilizando CAN, com possibilidades para ser expandido e que pode ser utilizado em outras aplicações. 7.2

Possíveis melhorias. O módulo de supervisão proposto tem sua interface CAN baseada num gateway

através da porta serial. Embora na aplicação proposta isso não cause qualquer tipo de problema, o fato de se utilizar a porta serial, que funciona a velocidades de no máximo 115200bps, impede que sejam utilizadas velocidades maiores na rede CAN, o que pode ser um fator limitante em outras aplicações. A melhor solução seria integrar-se um Controlador CAN diretamente ao módulo. Outros aperfeiçoamentos sugeridos são os seguintes: •

Aprimoramento do sistema de armazenamento de dados dos módulos de aquisição e do módulo de supervisão, para que se possa ter uma série histórica de valores, de acordo com a capacidade de memória já instalada nos mesmos, sem a necessidade de se recorrer a um sistema de banco de dados externo.

•

Melhoria da interface com outros sistemas, acrescentando-se um método

alternativo de acesso, como um serviço TCP, por exemplo. •

Melhoria da interface com o usuário, feita pelo módulo de supervisão.

7.3 Perspectivas de continuidade. No capítulo 3 discutiu-se o problema da padronização e da interoperabilidade no contexto dos barramentos de campo. Foram então apresentadas duas tecnologias promissoras que podem minimizar os problemas nessa área: a utilização da Ethernet e do TCP/IP, que foi explorada neste trabalho; e o padrão IEEE 1451. Embora a proposta deste trabalho atenda às necessidades do Laboratório de Abelhas, seria interessante, visando à melhoria das características de interoperabilidade e expansibilidade dessa rede, ou novas aplicações, um estudo aprofundado da norma IEEE 1451, bem como a implementação de uma rede experimental de instrumentos inteligentes que dela fizesse uso. A utilização do TCP/IP por si só traz várias possibilidades para a continuidade do trabalho, como por exemplo: •

A implementação de uma interface para o sistema baseada em webservices, que são basicamente chamadas de funções remotas, baseadas no serviço http. Facilitando assim o acesso de outras aplicações aos dados do sistema.

•

A melhoria da interface com o usuário, fazendo uso de tecnologias como applets Java, por exemplo, para a construção de gráficos que permitam a visualização dos dados em função do tempo.

•

A incorporação de outras subredes, baseadas em tecnologias diferentes do CAN ao sistema. Por exemplo, redes baseadas em tecnologias sem fio, como Bluetooth, permitindo o monitoramento de colônias de abelhas ao ar livre.

•

A construção de redes similares em outros locais e a integração das mesmas através da Internet em um único sistema, formando um laboratório distribuído para o estudo de abelhas.

A construção de dispositivos dedicados com TCP/IP poderia também ser explo-

rada: •

Poderiam ser buscadas soluções para o problema de custo, tornando viável a aplicação dessa tecnologia em novos campos, ou de novas formas.

•

Poderiam ser estudadas outras plataformas para implementação de soluções.

Outra possibilidade interessante é a conexão de PDAs à rede, para facilitar a coleta de dados pelos pesquisadores, o que poderia ser feito com uma tecnologia de acesso TCP/IP sem fio, como 802.11b, ou através de infra-vermelho, interface que já está disponível no módulo eZ80. A solução proposta neste trabalho, a exemplo do que vêm ocorrendo com as pesquisas associadas à tecnologia CAN, pode ser aplicada a outros trabalhos de pesquisadores do LAA, bem como pode contribuir como base ao desenvolvimento de projetos de formatura do PCS/EPUSP. Outra possibilidade que sugere-se que seja explorada é a utilização de outros padrões de comunicação como alternativa ao CAN: embora este tenha atendido de forma satisfatória às necessidades deste trabalho, outras aplicações associadas ao Laboratório de Abelhas que futuramente poderão ser exploradas, envolvendo, por exemplo, colméias montadas fora do laboratório, irão esbarrar em uma limitação do padrão CAN, que apenas prevê o uso de fios como meio de comunicação. Um padrão como o LON (Local Operating Network) aparenta ser uma solução interessante de ser investigada, por permitir uma boa variedade de meios de comunicação, como por exemplo, rede elétrica e rádio, além de fios. 7.4 Conclusão. Este trabalho é uma contribuição para melhorar as condições de pesquisa do Laboratório de Abelhas do IB da USP, em consonância com o WebBee, e demais trabalhos resultantes da cooperação entre o LAA e o Laboratório de Abelhas. Buscando complementar contribuições já feitas e abrindo caminho para novos trabalhos de pesquisa. As redes de instrumentação inteligente são em geral a melhor escolha para os problemas de automação. O padrão CAN, que já havia sido estudado anteriormente

por pesquisadores do LAA, foi definido como padrão para novos projetos no grupo (Strauss, 2001), devido à suas vantagens. A utilização do TCP/IP no entanto, foi de grande importância pelo papel que o protocolo vem assumindo no campo da automação e das aplicações dedicadas em geral. Espera-se que a importância do TCP/IP continue aumentando nesse campo e que seja utilizado também em novos desenvolvimentos do grupo.

LISTA DE REFERÊNCIAS AIDAR, D. S. Meliponíneos e ecossistema: Importância da preservação das espécies (hymenoptera, apidae, meliponinae). Informativo Ambiental, 1997. Disponível em: <http://www.ufes.br/~dbio/davi1.htm>. Acesso em: 30 nov. 2000. ANCIENTE Technology Web Page – Página apresentando os trabalhos de Heron de Alexandria. 2004. Disponível em: <http://www.geocities.com/sfetel/en/heron.htm>. Acesso em: 01 jan. 2004. ARCTURUS NETWORKS. Página web da Arcturus Networks. 2003.. Disponível em: <https://shop.arcturusnetworks.com/about.shtml>. Acesso em: 01 dez. 2003. ATMEL. Web TCP/IP Evaluation kit. 2002. Folheto explicativo que descreve o kit de demonstração TCP/IP do processador Atmel C51. Disponível em: <http://www.atmel.com>. BICUDO, J. E. P. W.; Françoso Jr., O. de A. Sub-projeto: Estudo comparativo do metabolismo aeróbico e da sua correlação com algumas atividades biológicas do complexo plebéia (Apidae: Meliponinae). Relatório de Atividades. Relatório submetido ao Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq). 1999. BRITANNICA, E. Automation. 2001. Britannica 2001 Deluxe Edition CD-ROM. BRYZEK, J. Introduction to IEEE-P1451, the emerging hardware-independent communication standard for smart transducers. Sensors and Actuators A, v. 62, p. 711– 723, 1997. CAMPOS, L. A. de O.; PERUQUETTI, R. C. Biologia e criação de abelhas sem ferrão. 2000. Disponível em: <ftp://ftp.ufv.br/dbg/apiario/meliponini.pdf>. Acesso em: 02 dez. 2000. CAN-CIA. CAN Aplications. 2002. Página web - CAN in automation. Disponível em: <http://www.can-cia.de/can/application>. Acesso em: 09 mar. 2002. CANSADO, J. C. A. Conectividade entre telecomunicações e informática. São Paulo. Monografia de conclusão da disciplina Sistemas Abertos do programa de pós graduação da Escola Politécnica da USP. 2001. CONWAY, P.; HEFFERNAN, D. Can and the new ieee 1451 smart transducer interface standard. 2002. Disponível em: <http://www.ul.ie/~pei/pdf_files/fp15.pdf>. Acesso em: 25 set. 2002.

CONWAY, P. et al. Ieee 1451.2: An interpretation and example implementation. 2002. Disponível em: <http://www.ul.ie/~pei/pdf_files/fp17.pdf>. Acesso em: 25 set. 2002. CORBET, S. et al. Temperature and the pollinating activity of social bees. Ecological Entomology, v. 18, p. 17–30, 1993. CUNHA, R. S. da. WebBee - Um Sistema de Informação de Apoio aos Estudos de Meliponíneos via Internet. Dissertação (Mestrado) — Escola Politécnica da Universidade de São Paulo, São Paulo, 2001. CUNHA, R. S.; SARAIVA, A. M.; CUGNASCA, C. E.; HIRAKAWA, A. R.; IMPERATRIZ-FONSECA, V. L.; HILÁRIO, S. D. An Internet-Based Monitoring System For Behaviour Studies Of Stingless Bees. In: 3rd EUROPEAN CONFERENCE OF THE EUROPEAN FEDERATION FOR INFORMATION TECHNOLOGY IN AGRICULTURE, FOOD AND THE ENVIRONMENT EFITA 2001, 2001, Montpellier. 2001. CUNHA, R.S.; SARAIVA, A.M.; CUGNASCA, C.E.; IMPERATRIZ-FONSECA, V.L.; HILÁRIO, S.D. WebBee-based Information System for Resource on Stingless Bees. In: THE WORLD CONGRESS OF COMPUTERS IN AGRICULTURE AND NATURAL RESOURCES, 2001, Foz de Iguaçú. 2002. DALLAS/MAXIM. DS80C400 (DSTINIm400)-Networked Microcontroller Evaluation Kit. 2003. Manual e esquema elétrico da placa de desenvolvimento. Disponível em: <http://pdfserv.maxim-ic.com/en/ds/DSTINIM400.pdf>. Acesso em: 01 dez. 2003. DECOTIGNIE, J. D. A perspective on ethernet tcp/ip as a fieldbus. In: CERNEuropean Organization for Nuclear Research, 2001. DUNNE, A. et al. A can based emergency light test network. 2002 Disponível em: <http://www.ul.ie/~pei/pdf_files/fp9.pdf>. Acesso em: 25 set. 2002. FELSER, M. The fieldbus standards: History and structures. Technology Leadership Day 2002, Organised by MICROSWISS Network, 2002. Disponível em: <http://www.htabe.bfh.ch/ felser/download/FETR0205.pdf>. Acesso em: 01 jan. 2004. FONDL, L. L. M. The future of sensor networks. Sensors, 2000. Disponível em: <http://www.sensormag.com/articles/1200/29/index.htm>. Acesso em: 23 mar. 2001. FUNDAO. Sistemas Abertos. 2004. Definição de sistemas abertos. Disponível em: <http://www2.fundao.pro.br/articles.asp?cod=148>. Acesso em: 10 fev. 2004.

IMPERATRIZ-FONSECA, V. L. I. As abelhas sociais sem ferrão. 2000. Página Web do Instituto de Biociências da USP. Disponível em: <http://www.ib.usp.br/beelife>. Acesso em: 30 nov. 2000. IMPERATRIZ-FONSECA, V. L. I.; GIOVANNINI, A. K.; PIRES, J. T. Climate variations influence on the flight activity of Plebeia Remota Holmberg (Hymenoptera, Apidae, Meliponinae). Revista Brasileira de Ent., v. 29, p. 427–434, 1985. GIOVANNINI, A. K.; IMPERATRIZ-FONSECA, V. L. Flight activity and responses to climatic conditions of two subspecies of melipona marginata lepeletier (Apidae, Meliponinae). Journal of Apicultural Research, v. 25, n. 1, 1986. GIOVINO, B. Zilog and the enbedded internet - a white paper. Microcontroler.com, 2000. Disponível em: <http://www.microcontroller.com/wp/Zilog/eZ80.htm>. Acesso em: 20 mar. 2003. GUIMARÃES, A. de A. Análise da norma ISO 11783 e sua utilização na implementação do barramento do implemento de um monitor de semeadura. Dissertação (Mestrado) — Escola Politécnica da Universidade de São Paulo, São Paulo, 2003. HEFFERNAN, D. A technical overview of fieldbus developments from origins to present day standards. 1997. Disponível em: <http://www.ul.ie/ pei/pdf_files/fp6.pdf>. Acesso em: 25 set. 2002. IEEE. IEEE Standard for a Smart Transducer Interface for Sensors and Actuators -Transducer to Microprocessor Communication Protocols and Transducer Electronic Data Sheet (TEDS) Formats. 1997. IEEE Standard 1451.2-1997 ISBN 0-7381-1386-7. IEEE. IEEE Standard for a Smart Transducer Interface for Sensors and Actuators - Network Capable Application Processor Information Model. 1999. IEEE Standard 1451.1-1999 ISBN 0-7381-1768-4. IEEE. The Portable Application Standards Committee. 2004. Definição de sistemas abertos - POSIX. Disponível em: <http://www.pasc.org/POSIX>. Acesso em: 05 fev. 2004. IETF. Internet Engineering Task Force. 2003. Página web. Disponível em: <http://www.ietf.org>. Acesso em: 01 nov. 2003. INTEL Introduction to the controller area network (can) protocol. 1993. JOUGA, B. How ethernet becomes industrial. In: CERN -European Organization for Nuclear Research, 2001.

KEITH PAZUL. AN 713 -Controller Area Network (CAN) Basics. 1999. Application Note Microchip. Disponível em: <http://www.microchip.com>. Acesso em: 10 fev. 2004. KINSELLA, T. Ethernet in industrial automation - today and tomorrow. Industrial Ethernet Book, 1999. Disponível em: <http://ethernet.industrialnetworking.com/articles/i02_tonykinsella.asp>. Acesso em: 09 out. 2003. LABORATÓRIO DE ABELHAS -IB -USP. Laboratório de Abelhas. 2004. Página web do Laboratório de Abelhas. Disponível em: <http://eco.ib.usp.br/beelab/>. Acesso em: 01 jan. 2004. LABORATÓRIO DE AUTOMAÇÃO AGRÍCOLA. Laboratório de Automação Agrícola. 2004. Página web do Laboratório de Automação Agrícola. Disponível em <http://www.pcs.usp.br/~laa> . Acesso em 05 jan 2004. LINEO. UCSimm -Embedded Microcontroller Systems Running uCLinux. 1999. Folheto explicativo que descreve uma placa com processador DragonBall rodando uCLinux. LUNA, M. de. Meliponicultura -criação de abelhas sem ferrão. 2000. Página Web descrevendo a criação racional de abelhas indígenas. Disponível em: <www.brasil.terravista.pt/Claridade/3630/bee>. Acesso em: 01 dez. 2000. MARSH, D. Canbus networks break into mainstream use. EDN, p. 53–60, August 2002. MEYZIN, L. Introduction to Industrial Automation. 2000. Material de aula. Disponível em: <http://www.hait.ac.il/staff/leonidM/1F99L1.htm>. Acesso em: 01 jan. 2004. MICROCHIP. PICDEM.net Internet/Ethernet Demonstration Board DM 163004. 2001. Folheto explicativo que descreve o kit de demonstração TCP/IP dos processadores PIC. Disponível em: <http://www.microchip.com>. Acesso em: 01 dez. 2003. MITRE. The Y2K problem in embedded Systems. 2000. Definição de sistemas dedicados. 1999 Disponível em: <http://www.mitre.org/tech/y2k/docs/EMBEDDED_SYSTEMS.html>. Acesso em: 05 jan. 2004. MOREIRAS, A. M. A problemática dos Sistemas Abertos na Automação de Escritórios. Monografia apresentada na de Sistemas Abertos do curso de mestrado da Escola Politécnica da USP. São Paulo. 2001.

MURRAY, C. J. Pcs, ethernet occupy factory floor. Electronic Engineering Times, p. 26, Jan 2002. OLIVEIRA, R. C. R. de; SARAIVA, A. M. Um sistema de monitoração aplicado ao estudo de termirregulação em meliponíneos. Revista de Iniciação Científica, p. 99– 103, 2002. PARK, J.; YOON, Y. An extended tcp/ip protocol for real-time local area networks. Control Engineering Practice, v. 6, p. 111–118, 1998. PEREIRA, C. E. Automação Industrial. 2002. Transparências utilizadas no curso de pós graduação em Sistemas de Automação. Disponível em: <http://www.eletro.ufrgs.br/~cpereira/sist_automacao_2002_1/sist_aut.htm>. Acesso em: 24 dez. 2003. PEREIRA, C. E. Evolução das Arquiteturas dos Sistemas de Automação. 2002. Transparências utilizadas no curso de pós graduação em Sistemas de Automação. Disponível em: <http://www.eletro.ufrgs.br/~cpereira/sist_automacao_2002_1/sist_aut.htm>. Acesso em: 24 dez. 2003. PHILIPS. P8xC591 – Microcontroller in CAN Applications. Nota de Aplicação – AN 00043, 2000. ______. P8xC591 – single Chip 8-bit Micro controller with CAN Controller. Especificação Técnica, 2000. ______. PCA 82C250/251 CAN Transceiver. Nota de Aplicação – NA 96116, 1996. ______. CAN Controller Interface. Especificação Preliminar, 1997. PORT. Data Sheet Ether CAN. 2002. Disponível em: <http://www.port.de/engel/canprod/content/hw_ethercan.html>. Acesso em: 24 set. 2002. SANDERS, V. WWWpic2 - A web server in a PIC. 2003. Página web. Disponível em: <http://www.kyllikki.org/hardware/wwwpic2/>. Acesso em: 01 dez. 2003. SHICKHUBER, G.; MCCARTHY, O. Distributed fieldbus and control network systems. 2002. Disponível em: <http://www.ul.ie/~pei/pdf_files/fp13.pdf>. Acesso em: 25 set. 2002. SHOFIELD, M. J. Controller area network - background information. 1999. Disponível em: <http://www.omegas.co.uk/CAN/history.htm>. Acesso em: 27 ago. 1999.

SHRIKUMAR, H IPic -A Match Head Sized Web-Server. 2003. Página web. Disponível em: <http://wwwccs.cs.umass.edu/ shri/iPic.html>. Acesso em: 01 dez. 2003. SILVA, K. M. R.; CUGNASCA, C. E; SARAIVA, A. M.. Agrican -simulador de rede baseada no protocolo iso 11783 para ambiente web. Viçosa, 2002. SOURCEFORGE. SDCC – Small Device C Compiler. 2001. Página web. Disponível em <http://sdcc.sourceforge.net>. Acesso em: 15 dez. 2001. STAFFORD, J. V. A can data bus application on a patch sprayer. In: . Chicago: ASAE, 1993. Paper no. 95-1534. STRAUSS, C. Implementação e Avaliação de uma Rede Experimental Baseada em CAN Para Aplicações Agrícolas. Dissertação (Mestrado) — Escola Politécnica da Universidade de São Paulo, São Paulo, 2001. STRAUSS, C.; CUGNASCA, C. E.; SARAIVA, A. M. Protocolos de comunicação para equipamentos agrícolas. 1996. Documento disponível internamente no Laboratório de Automação Agrícola da Escola Politécnica da USP. STRAUSS, C.; CUGNASCA, C. E.; SARAIVA, A. M. Padrões de comunicação em automação agrícola. 1998. Documento disponível internamente no Laboratório de Automação Agrícola da Escola Politécnica da USP. TANENBAUM, A. Computer Networks. 3rd. ed. New Jersey: Prentice Hall PTR, 1996. ISBN 85-7323-144-0. THOMESSE, J. P. Fieldbuses and interoperability. Control Engineering Practice, v. 7, p. 81–94, 1999. THOMPSON, H. A. et al. A canbus-based safety-critical distributed aeroengine control systems architecture demonstrator Microprocessors and Microsystems, v. 23, p. 345–355, 1999. TIAN, G. Y.; ZHAO, Z. X.; BAINES, R. W. A Fieldbus-based intelligent sensor. Mechatronics, v. 10, p. 835–849, 2000. TORRES, G. Redes de computadores - Curso Completo. 1st. ed. Rio de Janeiro RJ: Axcel Books do Brasil Editora, 2001. ISBN 0133499456. UCLINUX - Embedded Linux/Microcontroller Project. 2003. Página web do projeto uCLinux. Disponível em: <http://www.uclinux.com>. Acesso em: 01 dez. 2003.

VERHAPPEN, I. Foundation fieldbus economics comparison. ISA Transactions, v. 29, p. 281–285, 2000. WEBBEE. WebBee. 2003. Página web do WebBee. Disponível em: <http://www.webbee.org.br>. Acesso em: 15 dez. 2003. WIKIPEDIA. Embedded Systems. 2004. Disponível em: <http://en.wikipedia.org/wiki/Embedded_system>. Definição de sistemas abertos. Acesso em: 05 jan 2004. ZILOG. Extreme Connectivity. 2001. Transparência da apresentação no EZ80 Webserver Workshop. ______. eZ80 Acclaim! Development kist – Quick Start Guide. 2004. ______. eZ80 CPU – User Manual. 2003. ______. eZ80F91 Module – Product Specification. 2003. ______. eZ80 Webserver Evaluation Board - User Manual. 2001. ______. Thermostat Demo Using eZ80 Acclaim! – Application Note. 2003. ______. Zilog TCP/IP Sorftware Suite Programmers’s Guide – Reference Manual. 2003.