Você está na página 1de 58

FUNDAÇÃO CENTRO DE ANÁLISE, PESQUISA E INOVAÇÃO TECNOLÓGICA INSTITUTO DE ENSINO SUPERIOR FUCAPI – FACULDADE FUCAPI COORDENAÇÃO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

UM MEDIDOR DE ENERGIA ELÉTRICA WEB COM PROTOCOLO MODBUS TCP/IP

MANUEL GOMES ANDRADE JUNIOR

MANAUS

2010

MANUEL GOMES ANDRADE JUNIOR

UM MEDIDOR DE ENERGIA ELÉTRICA WEB COM PROTOCOLO MODBUS TCP/IP

Monografia apresentada ao curso de graduação em Ciência da Computação do Instituto de Ensino Superior Fucapi – Faculdade Fucapi como requisito parcial para obtenção do Título de Bacharel em Ciência da Computação. Área de concentração: Engenharia Elétrica, medição de energia elétrica bem como consumo de energia.

Orientador: Ricardo José Menezes Maia, M.Sc. Co-Orientador: Claudiomar Alves da Silva, Esp.

MANAUS

2010

MANUEL GOMES ANDRADE JUNIOR

UM MEDIDOR DE ENERGIA ELÉTRICA WEB COM PROTOCOLO MODBUS TCP/IP

Monografia apresentada ao curso de graduação em Ciência da Computação do Instituto de Ensino Superior Fucapi – Faculdade Fucapi como requisito parcial para obtenção do Título de Bacharel em Ciência da Computação. Área de concentração: Engenharia Elétrica medição de energia elétrica, consumo de energia.

Aprovada em 11 /12/2010, por:

Prof. Ricardo José Menezes Maia, M.Sc. Orientador

Prof. David Alves Junior, Esp. Examinador

Prof. Ricardo dos Santos Câmara, M.Sc. Examinador

MANAUS

2010

DEDICATÓRIA

In Memorian:

A meu pai, que trabalhou desde sua infância e mostrou para mim e meus irmãos o valor do

trabalho e da honestidade. Às pessoas mais legais e bondosas deste mundo, Maria do Carmo da Silva (minha mãe), Marinês Andrade Ayres (minha irmã) e Luiz Roberto Ayres (cunhado) que sempre tiveram paciência e sempre me ajudaram quando morávamos juntos. Dedico também a toda minha família e amigos, tanto do trabalho quanto da faculdade que direta ou indiretamente contribuíram para o meu crescimento ao meio acadêmico.

AGRADECIMENTOS

Agradeço inicialmente a DEUS, a quem devo minha vida e me motiva todos os dias quando sinto a batida do meu coração. Aos meus pais, minha mãe Maria do Carmo da Silva e meu pai, Manuel Gomes Andrade que hoje está em minha memória como um exemplo de vida e de bons valores.

Aos meus irmãos principalmente a minha irmã Marinês e meu cunhado Luiz os quais devo um muito obrigado por terem me acolhido quase sete anos em sua casa. Ao meu orientador, Professor Ricardo José Menezes Maia, pela paciência, sugestões, por ter acreditado na realização desta pesquisa e confiado em meus ideais e principalmente no título do meu trabalho.

A Minha irmã Marcilene, pela excelente ajuda com a correção deste.

A coordenação do Curso de Graduação em Ciência da Computação, em especial ao professor

Claudio de Oliveira Santos, entendeu nossas dificuldades em cumprir na íntegra, os prazos pré

estabelecidos no decorrer do trabalho.

Aos professores, colegas e a todos os colaboradores do CESF, pela oportunidade de realização da pesquisa e pela colaboração na coleta de informações. Ao Claudiomar Alves da Silva, pelo incentivo e participação na avaliação do meu trabalho.

O meu muito obrigado!

"Há homens que lutam um dia e são bons. Há outros que lutam um ano e são melhores. Há os que lutam muitos anos e são muito bons. Porém, há os que lutam toda a vida. Esses são os imprescindíveis."

Bertolt Brecht.

RESUMO

Esta monografia abordará o desenvolvimento de um sistema que atenda aos requisitos básicos de um software para viabilizar a coleta de dados a partir da medição de grandezas elétricas em uma indústria. Para coletar os dados este sistema fará uso de um medidor digital, já instalado no local, que utiliza um protocolo de comunicação chamado Modbus TCP/IP integrado nesse equipamento digital para troca de mensagens com dispositivos externos que irá tratar essas informações coletadas e as exibir em um formato Web.

Palavras chave: Medição de grandezas elétricas, Web Site e comunicação Modbus TCP/IP.

ABSTRACT

This monograph will address the development of a system that meets the basic requirements of a software to enable data collection from the measurement of electrical quantities in an industry. To collect the data this system will use a digital meter, already installed, using a communication protocol called Modbus TCP / IP built-in digital equipment to exchange messages with external devices that will treat this information collected and show in Web format.

Key Words: Measurement of electrical, Web Site and Modbus TCP / IP.

LISTA DE FIGURAS

Figura 1 – Uma comparação das arquiteturas de protocolos OSI e TCP/IP

22

Figura 2 – Unidade de dados do protocolo (PDUs) na arquitetura TCP/IP

23

Figura 3 – Pilha de comunicação Modbus TCP/IP

25

Figura 4 – Comunicação Cliente/Servidor em Modbus TCP/IP

25

Figura 5 – Modbus solicitação/resposta sobre o TCP/IP

27

Figura 6 – Comunicação Cliente/Servidor com código de erro

30

Figura 7 – Medidor de Energia Elétrica, NEXUS 1252 da EIG

31

Figura 8 – Mapeamento dos Bytes para o tipo F1

34

Figura 9 – Mapeamento dos Bytes para o tipo F2

35

Figura 10 – Mapeamento dos Bytes para o tipo F3

35

Figura 11 – Mapeamento dos Bytes para o tipo F4

35

Figura 12 – Mapeamento dos Bytes para o tipo F5

36

Figura 13 – Mapeamento dos Bytes para o tipo F6

36

Figura 14 – Mapeamento dos Bytes para o tipo F7

37

Figura 15 – Opção de comunicação em Rede Interna

37

Figura 16 – Tela de configuração de comunicação do NX programmer

38

Figura 17 – Opção de comunicação em Rede Interna

39

Figura 18 – Códigos de erro Modbus implementados pelo medidor NEXUS

39

Figura 19 – Projeto MVC do Sistema Web Medidor

41

Figura 20 – Projeto de do Sistema Web Medidor

42

Figura 21 – Diagrama de caso de uso do sistema Web

46

Figura 22 – Diagrama de Sequência (Consultar Leituras Gravadas)

47

Figura 23 – Arquitetura do padrão

49

Figura 24 – Arquitetura do sistema utilizando padrão de

50

Figura 25 – Diagrama de Classe Modbus

51

Figura 26 – Tabelas do Banco de Dados medidor

52

Figura 27 – Diagrama ER do Banco de Dados

52

LISTA DE QUADROS

Quadro 1 – Arquitetura OSI padrão da

20

Quadro 2 – A arquitetura de Internet TCP/IP

22

Quadro 3 – Código de Função Pública

27

Quadro 4 – MBAP Header (Cabeçalho ADU)

28

Quadro 5 – Frame de comunicação Modbus TCP/IP

28

Quadro 6 – Código de Exceção Modbus

29

Quadro 7 – Mapa de registros Modbus

34

Quadro 8 – Itens testados no Web

53

LISTA DE TABELAS

Tabela 1 – Opinião dos usuários sobre protocolos de Internet industriais

30

SUMÁRIO

1

INTRODUÇÃO

13

1.1 JUSTIFICATIVA

14

1.2 ESPECIFICAÇÃO DO PROBLEMA

15

1.3 OBJETIVOS

15

1.3.1 Objetivo Geral

15

1.3.2 Objetivos Específicos

16

1.5 METODOLOGIA

17

1.6 LIMITAÇÃO DO ESTUDO

17

1.7 ESTRUTURAÇÃO DO TRABALHO

18

2

REFERENCIAL TEÓRICO

19

2.1

COMUNICAÇÃO E PROTOCOLO MODBUS TCP/IP

20

2.1.1 Arquitetura TCP/IP Internet

20

2.1.2 Protocolo MODBUS TCP/IP

24

 

2.2

MEDIDOR DIGITAL DE ENERGIA ELÉTRICA (MDEE)

31

2.2.1 Especificação

32

2.2.2 Registros de Memória

32

2.2.3 Formato dos Tipos de Dados

34

2.2.4 Comunicação, Código de Função e Código de Exceção

37

3

MODELAGEM E PROJETO DO SISTEMA

40

3.1

REQUISITOS FUNCIONAIS

43

3.1.1 Acesso aos Dados do Medidor Digital de Energia Elétrica

44

3.1.2 Sincronismo, Controle e Aquisição dos Dados

44

3.1.3 Monitoramento do Medidor por Meio da Página

45

3.1.4 Outros

45

 

3.2

CASO DE USO

45

3.2.1

Diagrama Caso de Uso

45

3.3

ESPECIFICAÇÃO DO CASO DE USO

46

3.3.1

Caso de uso “ Consultar Leituras Gravadas”

46

3.3

REALIZAÇÃO DO CASO DE USO

47

3.3

REQUISITOS NÃO FUNCIONAIS

47

3.3.1 Usabilidade

48

3.3.2 Confiabilidade

48

3.3.3 Desempenho

48

3.3.4 Sistema Base

49

 

3.5

ESTRUTURA GERAL

49

3.4.1 Arquitetura

50

3.4.2 Camadas

50

3.5 IMPLEMENTAÇÃO

50

3.6 TESTES

53

4

CONCLUSÃO

54

4.1 Considerações Finais

54

4.2 Trabalhos Futuros

54

ANEXO

57

13

1 INTRODUÇÃO

Cada vez mais os sistemas existentes nas indústrias são adaptados para funcionarem em uma rede corporativa como aplicação Web. O uso da mesma possibilita aos novos e aos antigos sistemas trabalharem de forma distribuída sem que haja um custo maior nesta distribuição de recurso, já que na maioria dos ambientes industriais existe uma estrutura de rede local instalada. Uma rede pode ser definida como um conjunto de dispositivos conectados por links de comunicação (denominados freqüentemente de nós)(sic) (FOROUZAN, 2006, p. 37). Com a evolução das técnicas e os modelos de comunicação, após a definição de rede, é possível se ter um idéia, não só a rede é importante para comunicação entre dispositivos, eles devem seguir um padrão único para se comunicar. Utilizando uma rede corporativa com o protocolo Modbus incorporado no medidor digital, haverá possibilidade em reproduzir a estatística do consumo de energia elétrica on line, de onde ele foi instalado. A produção de gráficos de demanda, tabelas de rateio e outras formas de controle estatístico estão inseridas nas vantagens de quando as informações coletadas do medidor são armazenadas. Este trabalho ficará limitado ao estudo de como pesquisar requisitos, as modelagens, regras de negócios e o uso de padrão do protocolo Modbus TCP/IP em medidor de energia elétrica. Com isso ele poderá ter suas informações de engenharia coletadas por um sistema assíncrono, armazenadas em um banco de dados e publicadas por meio de uma página Web. Silva e Felgueiras (2008) explicam que Modbus é um protocolo de código aberto e dos mais simples utilizados na automação industrial (Industrial Automation System) ISA. A idéia central será apresentar as informações coletadas de forma organizada em diagramas unifilares, tabela e relatórios por meio de uma página Web, possibilitando consulta das informações em um tempo conveniente e predefinido. Existem no mercado diversas empresas especializadas em Automação Industrial, entre elas a Schneider Electric, a proprietária do protocolo industrial citado, o Site pode ser consultado 1 . Esta empresa possui uma aplicação com funcionalidade semelhante às propostas que é o ION Enterprise, um software voltado para gerenciamento de energia elétrica. Portanto, um software proprietário sendo para fins industriais, tem seu custo relativamente

1 Empresa proprietária do protocolo Modbus < http://www.schneider-electric.com.br/>

14

alto, em comparativo às aplicações de uso geral, como sistemas operacionais que tem muito mais funcionalidades e menor custo.

A elaboração deste trabalho é importante pela evolução dos sistemas que utilizam

softwares livres. Contribuirá com o aumento da produção de aplicações voltadas às indústrias

que poderá também contar com mais aplicações trabalhando em sistemas distribuídos e funcionará em qualquer computador independente de Sistema Operacional SO instalado, bastando apenas de um browser e algumas bibliotecas Java.

1.1 JUSTIFICATIVA

O consumo de energia elétrica para os consumidores finais, como são chamados os

clientes das concessionárias de energia elétrica são diferenciados de acordo com a classe consumidora em uma tabela da Agência Nacional de Energia Elétrica ANEEL. Esta tabela foi criada pelo Departamento de Atendimento ao Consumidor (DCA) e se chama “Evolução das Tarifas de Energia Elétrica do Grupo “A” e “B” Demanda em R$/kW e Consumo em R$/kWh” 2 . Mensalmente em sua casa o usuário recebe uma conta de energia que consta a cobrança de consumo de energia elétrica em kWh e o valor da tarifa R$/kWh dependendo do seu consumo ela é maio ou menor (somente para consumidores de baixa renda). Logo quem consome mais, paga mais. Da mesma forma como na instalação residencial, as indústrias pagam os custos com energia elétrica, porém nesses consumidores industriais a energia é paga em Demanda contratada que envolve uma série de cálculos em função do horário de consumo. Geralmente, as empresas adotam planilhas eletrônicas para ratear os custos aos seus diversos departamentos, isso demanda tempo para coletar os dados em cada painel local das subestações. Um sistema de medição de energia em conformidade com as tabelas de tarifas e horários registrados de consumo de Ponta e Fora de Ponta consegue reduzir a margem de erro tanto da leitura local por parte dos operadores quanto de alteração e preenchimento incorreto

2 Mais detalhes no Site:

<http://www.amazonasenergia.gov.br/portal/atendimento/arquivos/TABELA_FORNECIMENTO.pdf >.

15

em planilhas. Possibilita também o calculo em tempo real da demanda contratada com os acréscimos do consumo na moeda corrente antes que a conta seja enviada pelo setor de cobrança da concessionária.

1.2 ESPECIFICAÇÃO DO PROBLEMA

Uma indústria possui em suas instalações um Medidor Digital de Energia Elétrica (MDEE) e este permite comunicação por meio de um protocolo especifico chamado Modbus TCP/IP. Por desconhecimento ou por falta de recursos esta empresa não possui um sistema que providencie a coleta dos dados desse MDEE. Além disso, os operadores para fazerem a coleta de dados direto no display do medidor utilizam check lists de leitura, que são preenchidos a cada seis horas para o rateio de demanda e consumo de energia aos diversos setores da empresa mensalmente.

1.3 OBJETIVOS

1.3.1 Objetivo Geral

O objetivo geral deste trabalho é projetar um modelo de sistema que possa coletar dados de um Medidor de Energia Elétrica e permitir que o usuário do sistema tenha acesso às informações do consumo no seu ramal de distribuição de energia por meio de um Medidor Digital (MD) e uma página Web.

16

1.3.2 Objetivos Específicos

Para alcançar o objetivo geral deste trabalho, serão desenvolvidas as seguintes atividades:

Realizar uma pesquisa de Referencial Teórico; Desenvolver um protótipo de sistema funcional para o modelo teórico; Monitorar o consumo e a demanda de energia elétrica Possibilitar gerar e visualizar as informações por meio da Web.

1.4 TRABALHOS RELACIONADOS

Os trabalhos relacionados a esta proposta são aqueles que tratam de protocolos industriais. Sistemas baseados na Web com acesso a dispositivos externos e até manuais como o próprio guia de desenvolvimento Modbus, são documentos triviais para auxiliarem na elaboração e desenvolvimento desses projetos. Para mais detalhes é recomendado consultar o manual Modbus 3 , já que ele traz alguns diagramas, com atividade dos eventos, informações necessárias ao projeto Web e uso do protocolo. Existe um artigo da Universidade Federal de Santa Catarina, publicado em 2002, produzido por: Dr. Gilberto Grandi da Universidade do Vale do Itajaí (UNIVALI) e o Dr. Fernando O. Gauthier da Universidade Federal de SC (UFSC), sob o título:

UNIFORMIZAÇÃO DE DADOS DE SUBESTAÇÕES DA ELETROSUL. Este artigo trata da integração de informação das grandezas elétricas, devido à distância dos vários pontos de medição espalhados pela planta de uma concessionária de energia que expõe a idéia de como criar um software de controle e monitoramento dessas grandezas para essa empresa. Há também uma pesquisa dos alunos da Universidade Regional do Noroeste do Estado do Rio Grande do Sul, UNIJUÍ, Ijuí, Ancelmo Grinke Trojan e Edson Luiz Padoin, publicado em 2008, intitulado:

“Utilização de dispositivos móveis e Web Services no monitoramento remoto de Servidores em Subestações de Energia”. Essa providencia coleta das grandezas da subestação e salva em

3 Modbus-IDA. Modbus Messaging on TCP/IP Implementation Guide V1.0b. 2006. Disponível em:

<http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf>

17

um banco de dados, por meio de um servidor local, caso um evento de anomalia ocorra, uma mensagem seria enviada a um determinado celular através de outro instalado fixo no local.

1.5 METODOLOGIA

Este projeto por conveniência lógica seguirá algumas etapas preliminares de acordo com os tópicos:

Pesquisa bibliográfica – Pesquisa sobre o tema abordado nos idiomas português e principalmente em inglês, onde se encontra uma vasta lista de material na internet sobre os protocolos e o tipo de medidor utilizado neste trabalho. Reuniões semanais – Nas reuniões há uma interação com o professor orientador, tanto com relação à direção da escrita do contexto da monografia quanto nas formas e paradigmas utilizados à modelagem do sistema. Levantamentos de Requisitos – Para o protótipo de um modelo do sistema são levantados os requisitos com base nas informações adquiridas em reuniões e nas pesquisas realizadas, principalmente com os parâmetros de leitura nos medidores utilizados em uma indústria a as frustrações com relação tipo controle em papel. Modelagem e Projeto do Sistema – Na etapa de modelagem e projeto são considerados os requisitos levantados e assim elaborado o protótipo funcional do sistema. Testes do Protótipo – São realizados os testes funcionais do sistema como o teste de unidade, para checar a solução modelada do sistema de suprir os objetivos propostos. Escrita da Monografia – É escrita em paralelo com o protótipo do sistema em conformidade com o modelo encontrado na analise do projeto.

1.6 LIMITAÇÃO DO ESTUDO

A implementação do protótipo deste sistema está limitada à coleta de dados dos registros do Medidor Digital de Energia Elétrica, por meio de um cabo UTP CAT. 5, conectado ao computador onde a aplicação funciona. Os parâmetros que definem as limitações deste trabalho são:

18

Comunicação Modbus TCP/IP entre o MDEE e o protótipo deste sistema funcionado em um computador em rede; Visualização das informações do medidor online; Armazenamento dessas informações em uma base de dados.

1.7 ESTRUTURAÇÃO DO TRABALHO

Este trabalho foi organizado de forma a contemplar as especificações do GUIA PARA ELEBORAÇÃO DE MONOGRAFIAS, o guia do CESF, em sua terceira edição, elaborado pelo professor Francisco de Assis da Silva Medeiros. Foi estruturado em seu 5 capítulos conforme os tópicos a seguir:

Capítulo 1 – Introdução: Este capítulo demonstra uma das formas de como as empresas fazem o rateio de energia elétrica e explica os principais problemas com esta forma de controle; Capítulo 2 – Referencial Teórico: Neste são apresentados os protocolos de comunicação, um deles muito utilizado atualmente nas redes corporativas e Internet e o outro um protocolo industrial que integra a maioria dos instrumentos comercialmente ofertados no âmbito industrial. É apresentado também um MDEE com suas características e dispositivos utilizados nestes equipamentos para promover a leitura das grandezas elétricas; Capítulo 3 – Modelagem e Projeto do Sistema: Este capítulo contem analise das teorias referenciadas no capítulo anterior e o modelo de um protótipo para promover a coleta e exibição das informações necessárias como nos requisitos deste trabalho; Capítulo 4 – Conclusão: Na conclusão são apresentadas as considerações finais e perspectiva de trabalhos futuros.

19

2 REFERENCIAL TEÓRICO

Com o avanço das tecnologias criação de dispositivos portáteis e desktops aumenta a fabricação de componentes eletrônicos e muitos equipamentos industriais se tornam mais acessíveis às pequenas empresas que podem investir na automação de muitas tarefas nas suas subestações de energia elétrica. Em comparativo aos softwares voltados para clientes industriais que tem um custo mais elevado por exclusividade de aplicação, há uma generalização no desenvolvimento destas aplicações para atender diversos ramos da área industrial, esses sistemas são geralmente chamados de Interface Homem Máquina (IHM). Eles possuem muitas funcionalidades que não são utilizadas no monitoramento de subestações. Um Medidor

Digital Web vai permitir o uso do protocolo livre, em meio à automação o chamam de protocolo aberto, o Modbus que é implementado junto à aplicação e utiliza os protocolos TCP

e IP, por isso denominado Modbus TCP/IP 4 . No contexto de aplicação, surge a necessidade de utilizar este protocolo por ser nativo

do equipamento e a única forma de comunicação. Quando se fala de protocolos faz referência

à maneira ou às regras para ocorrer efetivamente a comunicação de dados. Segundo Loomis (1983, p.154), em uma comunicação de dados, um protocolo é uma configuração de regras e procedimentos estabelecidos para controlar a transmissão entre pontos 5 . Em uma reunião formal ou até mesmo informal com um grupo de pessoas, uma deve iniciar a conversa e em seguida dá oportunidade à outra, caso contrário ninguém consegue entender nada. Protocolo tem este significado nas operações de comunicação de dados. Neste capitulo, serão discutidos os protocolos de comunicação envolvendo Modbus TCP/IP e algumas técnicas modeladas para comunicação e formatação de dados que serão utilizados neste trabalho.

4 Mais detalhes no subitem 2.1 e no site: http://www.modbus.org/faq.php 5 Tradução nossa.

20

2.1 COMUNICAÇÃO E PROTOCOLO MODBUS TCP/IP

2.1.1 Arquitetura TCP/IP Internet

A arquitetura TCP/IP teve suas pesquisas iniciadas pela Defense Advanced Research

Projects Agency (DARPA) e foi baseado no padrão da International Standards Organization (ISO) o Open Systems Interconnection (OSI), conforme quadro 1.

Gasparini e Barrella (1993, p. 04), explicam que com as pesquisas desta Internet, surgiu o desenvolvimento de um conjunto de protocolos para o tratamento das informações transportadas, que promoveu transparência às aplicações sem dependências de Hardware. Esta independência é um dos pontos importantes do modelo criado que promoveu

flexibilidade em permitir que se utilize Hardware de qualquer fabricante, onde antes era um problema aos pesquisadores. Essa particularidade não chega a interferir mais na comunicação por existir no conjunto de protocolos responsáveis para amenizar e promover um modelo a este problema.

O padrão OSI é dividido em sete camadas, cada uma com funções diferentes e

específicas. O quadro 1 ilustra com mais detalhes como ficou estabelecido o padrão ISO/OSI.

#

Descrição das camadas OSI

7

Aplicação

6

Apresentação

5

Sessão

4

Transporte

3

Rede

2

Enlace de dados

1

Física

Quadro 1 – Arquitetura OSI padrão da ISO. Fonte: Adaptado de STALLINGS, 2005, p. 98.

21

O modelo de protocolos TCP/IP é um pouco diferente com relação às sete camadas da OSI. Este padrão não é executado na íntegra no modelo de comunicação TCP/IP. Para Stallings (2005, p. 83), não existe um modelo de protocolo TCP/IP oficial, com exceção, no caso da OSI, com base nos modelos já desenvolvidos é possível organizar a tarefa de comunicação para este modelo em cinco camadas, sendo estas:

Camada de Aplicação: é a interface do usuário com o meio de interação com o protocolo; Camada de host a host, ou Transporte (TCP): É a camada que entre outras funções, verifica a ordem dos pacotes que chegam se necessário os organiza; Camada de Inter Rede (IP): Tem uma das funções de fazer o encaminhamento por várias redes são também executadas em Roteadores; Camada de Acesso à Rede (Frame Relay, Ethernet): Trata-se da troca de dados entre um sistema final e rede a qual está conectado e comutação de pacotes; Camada Física: a camada que envolve a interface física, um Work Station (WS) é um meio de transmissão, geralmente a rede. Envolve a menor unidade de informação lógica, o bit, tempo de duração de pulso, pinagem dos conectores, nível de hardware entre outros detalhes em nível lógico. Do conjunto de protocolos que compõe o modelo TCP/IP, estes últimos que terão um foco maior neste trabalho o Transmission Control Protocol (TCP) e o Internet Protocol (IP), eles promovem flexibilidade na tratativa das transmissões e vistos como mais aceitos nas pesquisas realizadas ao longo deste trabalho. No quadro 2 se pode ver como estão divididas as cinco camadas do conjunto de protocolos TCP/IP. No nível de aplicação estão alguns exemplos da implementação de protocolos como Telnet, FTP e SMTP, para os serviços de acesso remoto, troca de arquivos, serviço de correio eletrônico entre outros promovidos pelo modelo TCP/IP.

22

 

Camadas

 

Conjunto de Protocolos TCP/IP

1

2

3

4

5

(exemplo)

(exemplo)

Física

Enlace

Rede

Transporte

Aplicações

FTP SMTP

TFTP

de dados

   
 

Fluxo

Datagrama

 

confiável

de usuário

(TCP)

(UDP)

   

Protocolo de Internet (IP)

 

Protocolo de Acesso à rede

 

Física

Quadro 2 – A arquitetura de Internet TCP/IP Fonte: Adaptado de STALLINGS, 2005, p. 98.

A idéia é utilizar esta camada para promover a comunicação entre o MDEE e a

aplicação do sistema da coleta de dados que será discutida no subitem 2.1.2.

Para facilitar o entendimento entre o padrão OSI e o protocolo TCP/IP é apresentado

um comparativo entre as duas arquiteturas na figura 1.

Aplicação Aplicação Apresentação Sessão Transporte Transporte (host a host) Inter-rede Rede Acesso a
Aplicação
Aplicação
Apresentação
Sessão
Transporte
Transporte
(host a host)
Inter-rede
Rede
Acesso a
Enlace de
Rede
dados
Física
Física

Figura 1 – Uma comparação das arquiteturas de protocolos OSI e TCP/IP Fonte: Adaptado de STALLINGS, 2005, p. 98.

Numa forma simplificada de comunicação TCP/IP é possível ter-se uma visão geral

sobre o funcionamento da arquitetura, conforme os tópicos a seguir:

Para iniciar uma comunicação simples, a camada de aplicação recebe

solicitação do

usuário para o envio de uma informação ABC de um host A para um host B;

23

A camada de transporte TCP desses dois hosts possui um serviço chamado Service Access Points (SAP), conhecido como porta, as portas identificam o serviço ao qual uma aplicação deseja utilizar. Neste exemplo, a porta 502 no host A e porta 503 no host B. Configuradas as portas o TCP envia a mensagem à camada IP. Na camada IP possui o endereçamento da origem e do destino da mensagem com 32 bits que seguirão para a camada de acesso a rede juntamente com o Protocol Data Unit (PUD) do TCP. Por sua vez, a camada de acesso a rede recebe instruções de encaminhamento daquela imediatamente superior e realiza o primeiro salto até o caminho do hoste B em conjunto com a camada física. Na figura 2, é apresentado o fluxo de dados para a comunicação utilizando os protocolos TCP/IP, vistos em cada camada na sucessora como uma unidade de protocolo, PDUs de dado, que são as partes dos protocolos com os dados e cabeçalhos encapsulados uns nos outros para envio da mensagem.

encapsulados uns nos outros para envio da mensagem. Dados do usuário Fluxo de bytes da aplicação

Dados do usuário

Fluxo de bytes da aplicação

Fluxo de bytes da aplicação Segmento TCP Datagrama IP Pacote do nível de Rede

Segmento TCP

Fluxo de bytes da aplicação Segmento TCP Datagrama IP Pacote do nível de Rede

Datagrama IP

Fluxo de bytes da aplicação Segmento TCP Datagrama IP Pacote do nível de Rede

Pacote do nível de Rede

Cabeçalho

TCP

Cabeçalho TCP
Cabeçalho TCP

Cabeçalho

IP

Cabeçalho IP
Cabeçalho IP

Cabeçalho

IP

Cabeçalho IP
Cabeçalho IP
Cabeçalho IP
Cabeçalho IP
Cabeçalho IP
Cabeçalho IP

Figura 2 – Unidade de dados do protocolo (PDUs) na arquitetura TCP/IP Fonte: Adaptação, STALLINGS, 2005, p. 87.

24

2.1.2 Protocolo MODBUS TCP/IP

O protocolo Modbus é um modelo que foi desenvolvido no início para comunicação serial em ambiente industrial, existe desde 1979, bem na época da criação do padrão ISO/OSI, mas só lembrando que este último não tinha a época concatenação de informação com o Modbus. Modbus sempre foi um protocolo aberto 6 , propagado ao longo do tempo com uso da Internet tornou-se comum seu emprego por milhões de usuários pelo mundo. A fama de protocolo simples de implementação e usabilidade se deu graças sua divulgação, com a criação de uma organização sem fins lucrativo, responsável por essa divulgação e manutenção do protocolo na rede mundial de computadores 7 , juntamente com muitas empresas que utilizam e patrocinam o protocolo. No Site da comunidade Modbus, contém projetos desenvolvidos em diversas linguagens de programação incluindo Java que facilita a portabilidade sendo a linguagem adotada neste trabalho. Modbus TCP/IP está posicionado no nível sete do padrão OSI, quadro 1, que oferece comunicação Cliente/Servidor entre dispositivos conectados em diferentes tipos de barramentos ou redes, ou seja, Modbus permite fácil comunicação em todos os tipos de arquitetura de rede, MODBUS-IDA(2004, p. 02 e p. 03). É nesta sétima camada que deverão ser manipulados os Bytes de configuração da troca de mensagem entre o medidor e o sistema. No padrão TCP/IP, Modbus obedece à sequência de camada como da figura 3:

6 Significa dizer: sem fins lucrativos.

7 Modbus.org. Disponível em: < http://www.modbus.org >

25

25 Figura 3 – Pilha de comunicação Modbus TCP/IP Fonte: MODBUS-IDA, 2006, p. 02. Modbus TCP/IP

Figura 3 – Pilha de comunicação Modbus TCP/IP Fonte: MODBUS-IDA, 2006, p. 02.

Modbus TCP/IP é executado no modelo Cliente/Servidor para rede Ethernet comunicando dois dispositivos conectados à rede, esse modelo é baseado em quatro tipos de mensagem, MODBUS-IDA (2006, pg. 02):

MODBUS Solicitação – É uma mensagem enviada na rede do Cliente ao Servidor para iniciar uma Transação; MODBUS Indicação – A mensagem que chega ao Servidor; MODBUS Resposta – A resposta envida pelo servidor ao Cliente; MODBUS Confirmação – A resposta do servidor quando chega ao Cliente. Na figura 4 é apresentado o diagrama da comunicação Cliente/Servidor presente nos tópicos relacionados.

Cliente/Servidor presente nos tópicos relacionados. Figura 4 – Comunicação Cliente/Servidor em Modbus TCP/IP

Figura 4 – Comunicação Cliente/Servidor em Modbus TCP/IP Fonte: Adaptado de MODBUS-IDA, 2006, pg. 02.

Para iniciar uma comunicação é necessário enviar códigos ao servidor (Medidor de Energia Elétrica). Modbus permite uma faixa de 1 a 255 códigos definidos para escrever ou ler informações de um dispositivo remoto, incluindo ler exceções ou gerar pelo próprio cliente.

26

Estes códigos que deverão ser enviados ao servidor são chamados de código de função que estão distribuídos, segundo o manual de programação do protocolo 8 , em três categorias:

Código de Função Pública – São códigos bem definidos, garantidamente únicos, validados pela comunidade MODBUS.ORG, documentação publicada e tem teste de conformidade disponível. Código de Função Definida pelo Usuário – Estes códigos estão disponíveis entre duas faixas de valores de 65 a 72 e de 100 a 110 em decimal, não possuem especificação, uma vez que são de plena responsabilidade do usuário pode ser escolhido e executado por ele. Não possui garantia de que o código será único. Código de Função Reservada – São funções desenvolvidas e utilizadas por algumas empresas em seus produtos para fins específicos que não são disponibilizados aos usuários finais, códigos que não serão objetos de estudo deste trabalho. As funções públicas disponibilizadas pela comunidade do protocolo são basicamente como as mostradas no quadro 3. Modbus é um protocolo de solicitação (Request) / resposta (Response), como já fora dito, oferece serviços especificados por códigos de função. Possui também uma porta de comunicação exclusiva na pilha TCP/IP a porta 502. Como a comunicação TCP/IP é baseada em pacotes ou frames, para enviar uma mensagem de solicitação a um dispositivo remoto é necessário configurar o cabeçalho da mensagem, o código de função e os dados que serão solicitados para escrita ou leitura vêm logo após o cabeçalho.

 

Código de Função

 
       

Sub

Valor

Local de Acesso

Descrição da Função

Código

em

Código

(hex)

   

Entrada física

       

Discreta

Read Discrete Inputs

02

-

02

Bit de

Bits internos ou Bobinas físicas

Read Coils

01

-

0x01

acesso

Write Single Coils

05

-

0x05

Dados

Write Multiple Coils

15

 

0x0F

de

 

-

   

Read Holding Registers

03

 

0x03

Acesso

-

16 bits

Registros Internos ou Registros Físicos

Write Single Registers

06

-

0x06

 

de

Write Multiple Registers

16

-

0x10

acesso

Read/Write Multiple Registers

23

-

0x17

 

Mask Write Register

22

-

0x16

8 Tradução nossa. Disponível em site: < http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1a.pdf

>

27

   

Read FIFO queue

24

-

0x18

Acesso a arquivos de gravação

Read File Record

20

6

0x14

Write File Record

21

6

0x15

 

Read Exception Status

07

-

0x07

Diagnostic

08

00-18, 20

0x08

Diagnósticos

Get Com Event Countet

11

-

0x0B

Get Com Event Log

12

-

0x0C

 

Report Slave ID

17

-

0x11

Read Device Identification

43

14

0x2B

Outros

Encapsulated Interface Transport

43

13, 14

0x2B

Quadro 3 – Código de Função Pública Fonte: Adaptado de MODBUS-IDA, 2004, pg. 11

A comunicação sempre é iniciada pelo cliente através da Unidade de Dado da Aplicação (ADU) e respondida com uma Unidade de Dado do Protocolo (PDU). A identificação da ADU no protocolo Modbus¸ é feita por meio do Protocolo de Aplicação de Cabeçalho, na figura 5 é mostrado o escopo do cliente com a ADU e do Servidor com PDU.

o escopo do cliente com a ADU e do Servidor com PDU. Figura 5 – Modbus

Figura 5 – Modbus solicitação/resposta sobre o TCP/IP. Fonte: MODBUS-IDA.ORG, 2006, p. 04.

Na Figura 5, o cabeçalho é identificado com MBAP Header isto significa Cabeçalho do Protocolo de Aplicação Modbus. Este é composto por 56 bits de dados, 7 Bytes, onde são passados cinco parâmetros para identificação da transação que, identificação do protocolo, tamanho do registro ou número de Bytes da sequência e a unidade remota de identificação, ID do dispositivo escravo. Mais detalhe do cabeçalho pode ser visto no quadro 4.

 

Cabeçalho da ADU MODBUS

Campos

Tamanho (Byte)

Descrição

Cliente

Servidor

Identificação de

2

Bytes

Identificação da transação

Modbus de Requisição/Resposta.

Inicializada pelo

Reenviada pelo

servidor da

Transação

cliente

(Requisição)

 

recebida.

Identificador de

2

Bytes

Protocolo Modbus =0

Inicializado pelo

Reenviado pelo

Protocolo

cliente

servidor da

28

       

(Requisição)

recebida.

   

Número de Bytes abaixo na sequência.

Inicializada pelo

Inicializado pelo

Tamanho

2 Bytes

cliente

servidor

(Requisição)

(Resposta).

   

Identifica o dispositivo escravo remoto conectado ao barramento pode assumir: Broadcast =0 ou 1 a 255 dispositivos.

 

Reenviada pelo

Identificador de

1 Byte

Inicializado pelo

servidor da

Unidade

cliente

(Requisição)

 

recebida.

Quadro 4 – MBAP Header (Cabeçalho ADU) Fonte: Adaptado de MODBUS-IDA.ORG, 2006, p. 05.

Com o MBAP Header pronto, fica faltando definir o pacote MODBUS Requisição (MB Requisição) que contém o código de função e a divisão DATA. Neste último que é informado ao servidor qual o registro da pilha de memória que será acessado e a quantidade de registros a partir do endereço passado que farão parte deste acesso. Por exemplo, no Quadro 5, um frame com o MBAP Header é detalhado inclusive com o número total de bits.

   

Tamanho

Pedaço

Descrição

(Byte)

 

Identificador de Transação MSB

1

Identificador de Transação LSB

1

MBAP Header

Identificador do Protocolo

2

Tamanho (Header)

2

Identificador de Unidade (ID)

1

 

Código de Função

1

 

D

Início do endereço de acesso MSB

1

MB

A

Início do endereço de acesso LSB

1

Requisição

T

Número de registro a ser acessado MSB

1

A

Número de registro a ser acessado LSB

1

Quadro 5 – Frame de comunicação Modbus TCP/IP Fonte: Adaptado de MODBUS-IDA.ORG, 2006, p. 05.

Com o Frame criado a transmissão dos dados pode ocorrer bem sucedida quando coincidir o código de função da resposta ao código de função da requisição ou mal sucedida, quando ocorrer uma Exceção de Resposta Modbus. Neste caso o código de função de resposta é igual ao código de função Requisitado mais oitenta em hexadecimal (0x80) sucedido de um código de exceção como no quadro 6, da lista de Exceções Modbus.

29

 

Código de Exceção MODBUS

Código

Nome

 

Significado

(hex)

0x01

FUNÇÃO ILEGAL

Um código de função passado ao servidor (Escravo), não é suportado por ele.

0x02

ENDEREÇO DE DADO ILEGAL

Quando se tenta acessar um registro de tamanho quatro com tamanho cinco, por exemplo, o servidor devolve este tipo de erro.

0x03

VALOR DE DADO ILEGAL

Quando um valor contido na consulta ao servidor (Escravo) não é reconhecido.

0x04

FALHA DO DISPOSITIVO ESCRAVO

Ocorre irrecuperavelmente enquanto o servidor tenta responder a requisição do cliente.

   

O

servidor reconheceu a

0x05

DISPOSITIVO RECONHECIDO

solicitação do cliente, porém poderá levar um tempo maior que o timeout para responder

   

O

cliente deve retransmitir a

0x06

DISPOSITIVO ESCRAVO OCUPADO

solicitação quando o servidor

estiver livre.

0x08

ERRO DE PARIDADE DE MEMÓRIA

Ocorrem em solicitações do tipo 20 e 21 (Código de Função) quando se trabalha com arquivo

0x0A

CAMINHO DO GATEWAY INACESSÍVEL

Ocorre quando uma Gatway, ligado a rede está com a porta de entrada ao dispositivo inacessível para responder a uma Solicitação.

0x0B

FALHA DE RESPOSTA DO GATEWAY

O

Gatway ou dispositivo ligado a

ele não está presente na rede.

Quadro 6 – Código de Exceção Modbus Fonte: Adaptado de MODBUS-IDA, 2004, p. 49.

Quando uma Exceção é gerada o PDU da Resposta é alterado resumindo o que já fora comentado. No diagrama de sequência a seguir, figura 6, mostra os passos de um erro gerado quando um código errado de função é enviado na PDU da mensagem ao servidor. Como o código de função zero não existe o servidor devolve um erro com o código e exceção (um), informando que esta função não é reconhecida.

30

30 Figura 6 – Comunicação Cliente/Servidor com código de erro Fonte: Adaptado de EIG (2008, p.

Figura 6 – Comunicação Cliente/Servidor com código de erro Fonte: Adaptado de EIG (2008, p. 01-96)

Uma pesquisa realizada pela Sociedade Internacional de Automação (ISA) com seus membros e usuários globais, sobre a aceitação, aspecto positivo e negativo dos protocolos industriais com o uso da Ethernet. O protocolo Modbus TCP/IP aparece em segundo lugar com aspecto positivo, como pode ser visto na tabela 1, GILSINN e FREEMON (2009). Um dos protocolos mais utilizados, confirmando a história de trajetória do Modbus ao longo dos anos.

Protocolo

Positivo

Negativo

Não

Conhecido

CC-Link IE

10%

7%

84%

EthernetCAT

25%

8%

68%

EtherNet/IP

86%

4%

9%

FF-HSE

39%

14%

47%

Modbus TCP/IP

84%

11%

5%

Profinet

54%

20%

26%

SERCOS III

16%

12%

73%

Tabela 1 – Opinião dos usuários sobre protocolos de Internet industriais Fonte: Gilsinn e Freemon (2009).

Este projeto implementa Modbus principalmente pelo fato do instrumento de medição de energia elétrica fazer uso deste e pela praticidade e transparências nas informações de especificação do manual. Modbus é programado em diversas plataformas e linguagens de programação, possui um fórum oficial no site da Organização que pode ajudar nas dúvidas que surgirem para quem desejar utilizar o protocolo em seus projetos.

31

2.2 MEDIDOR DIGITAL DE ENERGIA ELÉTRICA (MDEE)

É um dispositivo ou equipamento eletrônico capaz de mensurar o consumo de energia elétrica. A unidade mais usada é o kWh. Pode ser ligado diretamente entre a rede elétrica e a carga ou através de transformadores de tensão ou de corrente, WIKIPEDIA (2010). Neste projeto será utilizado um medidor digital chamado NEXUS 1252 da empresa Electro Industries GaugeTech (EIG), esse medidor oferece leitura de todas as grandezas elétricas envolvidas em qualidade de energia e monitoramento. Possui 5 portas de comunicação Modbus serial e uma porta Ethernet para comunicação em Modbus TCP/IP. O NEXUS 1252 permite a leitura de qualquer variável interna de sua pilha de memória

e leitura das entradas de corrente elétrica e tensão nos tempos de 50 e 1000ms através dos seus conversores Analógico/Digital (AD) de 16 bits. Uma ilustração física do medidor pode ser vista na figura 7.

ilustração física do medidor pode ser vista na figura 7. Figura 7 – Medidor de Energia

Figura 7 – Medidor de Energia Elétrica, NEXUS 1252 da EIG Fonte: Próprio autor.

Conhecer o princípio de medição de energia elétrica em dispositivos eletrônicos é hoje uma visão de futuro. Para a Agência Nacional de Energia Elétrica, ANEEL (2010), com esses dispositivos eletrônicos de medição instalados será possível fazer cobrança diferenciada por horário de consumo, o que possibilitará ao consumidor administrar seu consumo, a exemplo da telefonia.

32

2.2.1 Especificação

O medidor NEXUS 1252 foi projetada para fazer leituras em sistemas trifásicos, das

seguintes grandezas primárias:

Ler voltagem em corrente alternada até 600V diretamente nos seus conectores específicos (Fase a fase, fase a neutro) ; Ler corrente elétrica das linhas fase e neutro até 5A e; Ler a frequência da rede elétrica 50 ou 60Hz. De acordo com o manual da EIG(2010, p. 11), a utilização do sistema trifásico de potência é mais eficiente porque promove uma equilibrada entrega (Delivery) de energia ao consumidor final. Para maiores detalhes recomenda-se ler o anexo.

2.2.2 Registros de Memória

O NEXUS 1252 possui 65536 endereços de memórias ou registros com todas as

grandezas mensuráveis calculadas de um sistema trifásico, porém neste projeto só serão utilizadas as grandezas referente a faturamento de energia elétrica. Como, por exemplo,

tensão em volts (V) bem como mínima e máxima nas três fases, corrente em Ampères (A) e máxima nas três fases, demanda em quilo watts hora (kWh), demanda máxima, energia acumulada em (kW), fator de potência (%) e frequência em Hertz (Hz). Os registros são identificados da seguinte forma:

Hexadecimal de 0000H a FFFFH Decimal de 0001DEC a 65536DEC

É preciso prestar bastante atenção, pois estas informações causam confusão, logo é

fácil confundir o endereço 0001DEC com o endereço 0001H que na verdade 0001DEC corresponde ao endereço 0000H. Na memória do MDEE as informações estão gravadas em pares de bytes, cada par corresponde a um registro (16 bits) e os dados sempre são enviados com o byte mais significativo primeiro, EIG (2008, p. 21). Por exemplo, no quadro 7, as grandezas que serão

33

utilizadas neste trabalho são representadas em decimal e em hexadecimal do mapa de registro do NEXUS 1252 e em grupos ou blocos. Para cada tipo de registro diferente é necessário criar uma função de conversão diferente. Por exemplo, o acumulado de energia deve ser tratado como um Double em sua conversão, os valores de registro de um segundo pode ser convertido em ponto flutuante, Float. A conversão do tipo de dados será vista com mais detalhes na especificação do medidor neste capítulo. Está incluído no mapa Modbus, quadro 7, um endereço de 8 entradas discretas (digitais) que são agregadas ao NEXUS 1252. Essas entradas podem ser utilizadas par verificação chaves acionadas, geradores ligados, relé ativado e outros status que o usuário desejar. Para este trabalho algumas das 8 entradas simbolizarão um grupo gerador de energia elétrica ligado às chaves principais de uma subestação. Estas entradas para serem compreendidas pelo usuário, o registro referente a elas de ser passado pela função correspondente, no quadro 7.

 

Mapa de endereços e registros Modbus do MDEE NEXUS 1252

 

Endereço

Descrição

Faixa

Unidade

Tipo

Acesso

Decimal

Hexadecimal

L/E

 

Bloco de identificação do dispositivo

 

0001-0008

0000-0007

Nome do

   

F1

L

dispositivo

 

Bloco de tempo real (10ms)

 
     

12/31/9999

     

0085-0088

0054-0057

Data e hora atual

23:59:59.99

10ms

F2

L/E

0089

0059

Dia da semana atual

Domingo a sábado

 

F3

L/E

 

Bloco de leitura de um segundo (seg.)

 

0180-0181

00B3-00B4

Voltagem A-N

+32767 V / 0 V

1/65536 V

F4

L

0182-0183

00B5-00B6

Voltagem B-N

+32767 V / 0 V

1/65536 V

F4

L

0184-0185

00B7-00B8

Voltagem C-N

+32767 V / 0 V

1/65536 V

F4

L

0188-0189

00BB-00BC

Corrente em A

+32767 A / 0 A

1/65536 A

F4

L

0190-0191

00BD-00BE

Corrente em B

+32767 A / 0 A

1/65536 A

F4

L

0192-0193

00BF-00BC

Corrente em C

+32767 A / 0 A

1/65536 A

F4

L

0198-0199

00C5-00C6

Voltagem A-B

+32767 V / 0 V

1/65536 V

F4

L

0200-0201

00C7-00C8

Voltagem B-C

+32767 V / 0 V

1/65536 V

F4

L

0202-0203

00C9-00CA

Voltagem C-A

+32767 V / 0 V

1/65536 V

F4

L

0210-0211

00D1-00D2

Potência VA

+32767 V A / 0 VA

1/65536 VA

F4

L

       

1/65536

   

0218-0219

00D9-00DA

Potência VAR

+32767 VAR/ 0 VAR

VAR

F4

L

0226-0227

00E1-00E2

Potência Watts

+32767 W / 0 W

1/65536 W

F4

L

0228-0229

00E3-00E4

Frequência Hz

+32767 Hz / 0 Hz

1/65536 Hz

F4

L

00233

00E9

Fator de Potência

999 / 0

1/1000 PF

F5

L

34

 

Bloco de entrada de alta velocidade

 

2773

0AD4

Entrada Digital

   

F6

L

8bis

 

Bloco de acumulação primário

 

2886-2889

0B45-0B48

Wh

+9.999999999999999

1 Wh

F7

L

 

Bloco adicional de energia

 

6381-6384

18EC-18EF

Potência VAh

+9.999999999999999

1 VAh

F7

L

6385-6388

18F0-18F3

Potência VAh

+9.999999999999999

1 VARh

F7

L

Quadro 7 – Mapa de registros Modbus Fonte: Adaptado de EIG (2008, p. 01-96)

O quadro 7 também representa a faixa ou o range do registro, unidade de informação,

o tipo de dado que deverá ser convertido e a permissão de acesso ao registro que pode ser para leitura (L) ou escrita (E).

2.2.3 Formato dos Tipos de Dados

No quadro 7, foram definidos sete tipos de dados diferentes, há para cada um, uma função de conversão também diferente. Desta forma ficarão definidos os seguintes topos:

F1 corresponde às informações do medidor, como código e nome. Estas informações

possuem oito registros (16 Bytes) que deverão ser convertidos em um tipo String. O quadro de distribuição dos Bytes pode ser visto a seguir na figura 8.

dos Bytes pode ser visto a seguir na figura 8. Figura 8 – Mapeamento dos Bytes

Figura 8 – Mapeamento dos Bytes para o tipo F1 Fonte: EIG (2008, p. 221)

F2 é do tipo Data. Possui quatro registros (8 Bytes) que representam respectivamente na linha Unidade (Unit), os registros representam século, ano, mês, dia, hora, minuto, segundo

35

35 Figura 9 – Mapeamento dos Bytes para o tipo F2 Fonte: EIG (2008, p. 222)

Figura 9 – Mapeamento dos Bytes para o tipo F2 Fonte: EIG (2008, p. 222)

F3 este tipo corresponde aos dias da semana de domingo a sábado, possui o tamanho de um registro 2 Bytes. A figura 10 mostra os detalhes da representação da semana em formado hexadecimal.

da representação da semana em formado hexadecimal. Figura 10 – Mapeamento dos Bytes para o tipo

Figura 10 – Mapeamento dos Bytes para o tipo F3 Fonte: EIG (2008, p. 223).

F4 representa as leituras de um segundo, possui tamanho de dois registros (4 Bystes),

estas leituras são V, A, W, VAR, VA e Hz. Varia na faixa de +32767 a -32768 em Inteiro decimal e para cada grandeza pode ser representado da seguinte, como na figura 11.

pode ser representado da seguinte, como na figura 11. Figura 11 – Mapeamento dos Bytes para

Figura 11 – Mapeamento dos Bytes para o tipo F4 Fonte: EIG (2008, p. 226)

36

F5 representa a leitura do Fator de potência (PF) e varia na faixa e 0.001 a 0.999. O órgão regulamentador de energia elétrica ANEEL, determina que o fator de potência permaneça na faixa de 0,92PF. Este valor é registrado em dois Bytes, um registro. A figura 12 mostra como calcular o PF.

Bytes, um registro. A figura 12 mostra como calcular o PF. Figura 12 – Mapeamento dos

Figura 12 – Mapeamento dos Bytes para o tipo F5 Fonte: Baseado em: EIG (2008, p. 227)

F6 faz referência às entradas digitais agregadas ao NEXUS 1252, corresponde a um registro de 16 bits, mas só são utilizados os oito mais significativos os demais ficam indefinidos, a figura 13 exemplifica a forma de leitura dos bits.

a figura 13 exemplifica a forma de leitura dos bits. Figura 13 – Mapeamento dos Bytes

Figura 13 – Mapeamento dos Bytes para o tipo F6 Fonte: EIG (2008, p. 233)

F7 neste tipo o tamanho é de quatro registros, esses registros contém um inteiro não

negativo de oito Bytes representando as leituras de energia acumulada VAh, VARh e Wh. A

figura 14 ilustra um exemplo da leitura de VAh.

37

37 Figura 14 – Mapeamento dos Bytes para o tipo F7 Fonte: EIG (2008, p. 236)

Figura 14 – Mapeamento dos Bytes para o tipo F7 Fonte: EIG (2008, p. 236)

2.2.4 Comunicação, Código de Função e Código de Exceção

a) Comunicação A conexão com medidor pode ser feita por meio de um cabo normal de rede UTP CAT-5, como ponto a ponto, por meio de uma rede local ou até pela Internet. Uma ilustração de conexão sugerida pela EIG(2010, p. 63), pode ser vista na figura 10.

sugerida pela EIG(2010, p. 63), pode ser vista na figura 10. Figura 15 – Opção de

Figura 15 – Opção de comunicação em Rede Interna Fonte: EIG (2010, p. 63)

38

A EIG fornece junto ao equipamento um programa de parametrização de tensão, corrente elétrica, frequência e das portas de comunicação. No momento em que é escrito este trabalho está sendo utilizado o NX Programmer que já não está mais disponível no Site 9 . No NX Programmer a comunicação é bastante simples:

Primeiro é preciso selecionar na caixa de opção para Network, uma rede Local; Em seguida o endereço do dispositivo Slave (Escravo), neste caso o endereço é 1. Obs.: se o endereço for configurado como zero será enviada uma mensagem em broadcast (para todos os dispositivos presentes na rede). Todos irão reconhecer o pacote enviado mais não irá respondê-lo, este endereço é utilizado apenas para fazer configuração de um grupo de medidores uma vez com uma simples mensagem de reset dos acumuladores de energia pode ser feito de uma vez só. Os demais campos são Host que é o endereço IP do escravo, Network Port a porta padrão do Modbus e o protocolo. Todos esses parâmetros são ilustrados na figura 16 do NX Programmer.

parâmetros são ilustrados na figura 16 do NX Programmer. Figura 16 – Tela de configuração de

Figura 16 – Tela de configuração de comunicação do NX programmer. Fonte: Próprio autor

b) Código de Função

Segundo o manual da EIG (2008, p. 20), para aquisição dos dados no NEXUS 1252 são suportadas três funções públicas do protocolo Modbus. Sendo destas, duas de escrita e uma de leitura, conforme figura 17.

9 EIG, página de Download: < http://www.electroind.com/dl_page.html#>, acessado em 25 nov. 2010.

39

39 Figura 17 – Opção de comunicação em Rede Interna Fonte: EIG (2008, p. 20) c)

Figura 17 – Opção de comunicação em Rede Interna Fonte: EIG (2008, p. 20)

c) Código de exceção

O NEXUS 1252 irá enviar ao Máster um pacote com resposta de exceção se ele encontrar um comando inválido ou ocorrer problema enquanto ele estiver consultando uma

saída de instrução do Máster. Os códigos de erro implementados por este modelo de medidor são os mostrados na figura 18. Inclui:

Função ilegal; Endereço de dado ilegal; Valor de dado ilegal e; Pacote rejeitado, Dispositivo ocupado.

de dado ilegal e; Pacote rejeitado, Dispositivo ocupado. Figura 18 – Códigos de erro Modbus implementados

Figura 18 – Códigos de erro Modbus implementados pelo medidor NEXUS 1252. Fonte: EIG (2008, p. 23)

40

3 MODELAGEM E PROJETO DO SISTEMA

Neste capítulo, serão abordados os aspectos estruturais, o modelo utilizado para o desenvolvimento do sistema e todos os detalhes referentes à comunicação Ethernet sobre o TCP/IP no protocolo Modbus bem como a interfaces do sistema, o modelo relacional do banco de dados e os fluxos de eventos relacionados ao sistema. A partir da seleção do material teórico feito da pesquisa e das reuniões realizadas se observa uma variedade de requisitos que pode ter neste sistema. Os tópicos a seguir, farão o leitor ter uma visão geral do sistema. Requisitos do Sistema – Os tipos de gráficos utilizados para o controle estatístico do consumo de energia elétrica (tipo Trands para demanda de energia), o meio de comunicação e protocolos utilizados (rede com Modbus TCP/IP), as plataformas utilizadas para desenvolvimento do sistema (Windows e Linux), SGBD utilizado e ferramenta de desenvolvimento para o projeto e implementação. Analise dos Requisitos – Com o levantamento dos Requisitos o sistema será modelado com o uso da ferramenta de especificação Unified Modeling Language (UML), para criação das Classes e os Diagramas do sistema. As ferramentas que serão utilizadas são ASTAH Community 10 e ArgoUML v0.30 11 para modelagem UML, ambas aplicações freeware e podem ser baixadas direto dos respectivos Site. Projeto do Sistema – A comunicação do sistema com o medidor deverá ocorrer no inicio para teste, por meio de um protótipo que será desenvolvido, pelo fato de necessitar de um estudo aprofundado do protocolo Modbus TCP/IP e do módulo de sincronização com a base de dados. A Oracle não possui uma Interface de Programação de Aplicação (API) para o protocolo Modbus, o Site pode ser consultado 12 . Através de pesquisas no Site da MODBUS-IDA, verificou-se um modelo de protocolo Modbus implementado em Java o Jamod (Java Modbus implementation) 13 , o qual seguirá de guia para o desenvolvimento deste trabalho.

10 Ferramenta UML, Astah Community, necessário se cadastrar para download no link:

<https://members.change-vision.com/members/files/astah_community>

11 Pode ser baixado do Site: <http://argouml-downloads.tigris.org/>, atualmente encontra-se na versão 0.30.2

12 Organização com as versões atualizadas dos pacotes de desenvolvimento Java <http://www.sun.com/java/>

13 Link do sistema modelo, Modbus em Java: <http://www.modbus.org/tech.php>, acesso em: 05 nov. 2010.

41

Quase em paralelo, um módulo Web com algumas operações de consulta, inserção, alteração e exclusão ao SGBD e acesso direto aos dados da memória do medidor deverão estar modelados e em fase de teste. Este projeto será desenvolvido de acordo com o padrão Modelo Visualização e Controle (MVC), por conveniência de manutenção do sistema e se chamará Web Medidor. Na figura 19 é apresentado um modelo do sistema de acordo com o padrão MVC, onde constam a visualização, controle e manipulação da comunicação e dados separadamente.

e manipulação da comunicação e dados separadamente. Figura 19 – Projeto MVC do Sistema Web Medidor.

Figura 19 – Projeto MVC do Sistema Web Medidor. Fonte: Adaptado de GONÇALVES (2008, p. 144).

O modelo da figura 19, mostra como deverá ser construído o protótipo de sistema para aquisição de dados do Medidor utilizando MVC. A diferença básica de uma aplicação Web normal é que existe um módulo integrado, o Modbus. Desenvolvimento – Para desenvolver este projeto serão utilizados pacotes, ferramentas e APIs de softwares livres como a linguagem de programação Java com o pacote

J2EE.

42

Na estatística do controle de consumo de energia elétrica será necessário gerar relatórios o que se torna impossível sem que dados estejam armazenados em alguma base de dados. O SGBD possibilitará este recurso com muitos usuários ao mesmo tempo. O problema é a sincronização do SGBD com o Medidor, já que o sistema precisa atender também às solicitações dos usuários por meio do servidor de páginas. A criação dos relatórios automáticos, acessos diretos à memória do medidor, atualização automática de páginas, relatórios de consumo de energia elétrica diário, mensal, anual e gráficos contínuos usará mecanismos de programação de processos concorrente para interatividade com o usuário e comunicação com o MDEE e com o SGBD. AJAX (Asynchronous JavaScript and XML) será utilizado nas interações do usuário

com a interface gráfica do sistema. As páginas Web não se atualiza sozinhas, a menos que um comando de atualização seja ativado. Isto significa que o sistema deverá ter um modelo de visualização com atualização dinâmica de forma automática, tanto para os valores de grandezas elétricas mostrados como tabelas quanto para os gráficos do controle estatístico on line. Por meio de pesquisa descobriu-se que AJAX modela este problema.

O GlassFish, será o servidor de aplicação utilizado. Como IDE para programação em JAVA, NetBeans possui muitos componentes prontos e por isso será utilizado no desenvolvimento do projeto Web. O NetBeans agrega na sua instalação o GlassFish e uma interface para gerenciamento de banco de dados. Na figura 20, a arquitetura do sistema macro pode ser visualizada onde o módulo de sincronismo com o SGBD e medidor fica implícito dentro da aplicação no padrão MVC do sistema Web Medidor.

da aplicação no padrão MVC do sistema Web Medidor . Figura 20 – Projeto de do

Figura 20 – Projeto de do Sistema Web Medidor. Fonte: Adaptado de GONÇALVES (2008, p. 143).

43

No modelo de aplicação da figura 20, podemos observar que o usuário interage diretamente com o servidor de aplicação por meio do Browser em que o sistema está hospedado. Teste Para testar o sistema será criado um check list de Teste, onde serão colocados os pontos importantes do sistema, como: (1) Teste de Unidade, para testar trechos de comunicação com o banco e comunicação com Medidor de energia. (2) Juntamente com o primeiro teste deverá ser realizado o Teste de Integração dos métodos do sistema para encontrar possíveis discrepâncias nos resultados dos métodos. (3) Teste de Sistema, com todos os módulos em normal funcionamento. Resultados – O resultado que se espera alcançar com os testes realizados é que o tempo de resposta do sistema atenda às especificações anotadas de 15 segundos para todas as leituras. O tempo de resposta do sistema para o usuário também será considerado nos resultados dos testes.

3.1 REQUISITOS FUNCIONAIS

Para disponibilizar os dados no futuro, formatados, para o acesso dos administradores e operadores remotamente por uma página Web, são gravados em uma base de dados para geração de relatórios e gráficos.

Neste sentido funcional no sistema, deverão constar todos os requisitos especificados nesta etapa do projeto. Na modelagem do sistema os requisitos serão vistos da seguinte ordem, Acesso ao medir, Sincronismo, Monitoramento e Outros. Como será criado um protótipo de comunicação esta ordem deverá ser obedecida. Todos os requisitos serão descritos de acordo com o modelo UML e identificados da seguinte forma:

Identificação: <Nome do caso de uso>, e; Descrição: <Descrição do caso de uso>.

44

3.1.1 Acesso aos Dados do Medidor Digital de Energia Elétrica.

Identificação: Gerenciamento de conexão. Descrição: O sistema deverá permitir ao usuário configurar os parâmetros de comunicação em rede Ethernet TCP/IP, porta e o endereço do dispositivo escravo. Identificação: Armazenamento de informação. Descrição: O sistema deverá salvar todas as informações coletadas do MDEE no SGBD MySql, por meio de persistência. Identificação: Recuperação de dados. Descrição: O sistema deverá permitir a recuperação dos dados no SGBD, caso o usuário solicite. Identificação: Gerenciamento de informação. Descrição: O sistema terá que permitir a exclusão dos dados no SGBD, mas não sua alteração, com exceção de informação de usuário ou endereçamento de dispositivo. Identificação: Diagnostico de Comunicação. Descrição: O sistema terá que permitir que o usuário envie comandos ao medidor por meio da interface padrão.

3.1.2 Sincronismo, Controle e Aquisição dos Dados.

Identificação: Sincronização de informação. Descrição: O sistema deverá permitir a sincronização de dados armazenados no SGBD com os dados em memória do MDEE. Identificação: Atualização dinâmica. Descrição: O sistema deverá manter a tela do usuário atualizada, sempre que uma nova requisição ao medidor tenha terminado com sucesso. Identificação: Cálculo de consumo de energia. Descrição: O sistema deverá calcular o consumo de energia por meio dos dados armazenados no SGBD bem como a multa relativa ao fator de potência baixo.

45

3.1.3 Monitoramento do Medidor por Meio da Página Web.

Identificação: visualização de informação. Descrição: O sistema deverá permitir a visualização das informações requisitadas em forma de tabela ou gráfico por data e horários e Diagrama Unifilar definidos pelo usuário.

3.1.4 Outros Requisitos.

Identificação: Gerenciamento de tarifas de energia. Descrição: O sistema deverá permitir ao usuário configurar os parâmetros de tarifas de energia praticados pelas concessionárias.

3.2 CASO DE USO

3.2.1 Diagrama Caso de Uso

A figura 21 apresenta o diagrama de Caso de Uso do Web Medidor, onde o ator Administrador herda as funcionalidades do ator Operador, como: “Efetuar Login”, “Consultar Leituras Gravadas” e “Atualizar Leitura na Tela”. A generalização destas tarefas é importante na reutilização de códigos e manutenção do sistema. Neste diagrama é apresentado um caso de uso “Login Padrão”, onde o Administrador da aplicação pode efetuar a autenticação inicial assim que instalado todo o sistema. O Login e senha padrão são solicitados e o sistema permitirá a alteração dos dados.

46

46 Figura 21 – Diagrama de caso de uso do sistema Web Medidor. Fonte: Próprio autor.

Figura 21 – Diagrama de caso de uso do sistema Web Medidor. Fonte: Próprio autor.

3.3 ESPECIFICAÇÃO DO CASO DE USO

3.3.1 Caso de uso “ Consultar Leituras Gravadas” Identificador: [CDU001] Descrição: Uma vez autenticado no sistema, o usuário poderá fazer uma solicitação de um dos serviços disponíveis, selecionando as informações necessárias para a solicitação escolhida, neste caso: Consultar leituras gravadas em uma base de dados. Atores: Operador Fluxo de eventos principal:

1. O operador seleciona a opção “Consultar Leituras Gravadas”.

2. O sistema disponibilizará um formulário para o usuário informar data de inicio e de data final da consulta. a. Se a opção do usuário for “Cancelar” o sistema cancela a operação e redireciona a tela principal do sistema.

47

3. O operador informa as datas e pressiona no botão “Submeter Consulta” no formulário.

4. O sistema exibe as informações solicitadas com cálculo de consumo de energia com base nas datas de início e fim.

5. O sistema mostra uma mensagem indicando que a operação foi realizada com sucesso.

3.3 REALIZAÇÃO DO CASO DE USO

3.3.1 Diagrama de Sequência(Consultar Leituras Gravadas)

3.3.1 Diagrama de Sequência(Consultar Leituras Gravadas) Figura 22 – Diagrama de Sequência (Consultar Leituras

Figura 22 – Diagrama de Sequência (Consultar Leituras Gravadas) . Fonte: Próprio autor.

3.3 REQUISITOS NÃO FUNCIONAIS

Os requisitos não funcionais serão listados em quatro categorias:

48

3.3.1 Usabilidade

Identificação: Suporte a múltipos browsers.

Descrição:

O sistema deverá dar suporte aos browsers:

Internet Explorer 6 em diante e; Mozilla FireFox 2 em diante. Identificação: Interface. Descrição: O design das telas deve ser baseado em formulários, caixa de texto, caixa de seleção sem movimentos e animações, com exceção da atualização dinâmica das informações na tela que deverá ter a cor de fundo branca.

3.3.2 Confiabilidade

Identificação: Segurança. Descrição: O sistema deverá promover segurança no acesso às informações do MDEE e as que estão gravadas no SGBD, solicitando autenticação do usuário para a utilização. Identificação: Status de operações. Descrição: O sistema deverá mostrar o estado das operações de comunicação com o MDEE para garantir que o mesmo está conectado.

3.3.3 Desempenho

Identificação: Tempo de resposta. Descrição: O sistema deverá ter um tempo de resposta menor que 15 segundos, entre requisitar dados do MDEE, guardar no SGBD e mostrar na tela do usuário.

49

3.3.4 Sistema Base

Identificação: Plataforma. Descrição: O sistema deverá ser desenvolvido para funcionar em sistemas operacionais diferentes e ferramentas OpenSource: MySql, GlassFich, JavaScript, Applet, utilizando a linguagem de programação Java.

3.5 ESTRUTURA GERAL

Este trabalho faz uso de padrão de projeto para facilitar manutenção, bem como valorizar as boas práticas de desenvolvimento inseridas no âmbito acadêmico. O uso de padrões se dá quando, por exemplo, em uma página JSP contém o mínimo possível de scriplets, GONÇALVES (2008, p. 141). E, segundo Gonçalves, um padrão muito praticado no desenvolvimento de aplicações Web em Java é o Model 2, baseado no paradigma MVC. Quanto ao acesso a banco de dados temos um padrão popularmente usado, chamado de DAO (Data Access Object). Antes de apresentar a arquitetura Model 2, é ilustrada na figura 23 uma estruturação geral do sistema no MVC.

na figura 23 uma estruturação geral do sistema no MVC. Figura 23 – Arquitetura do padrão

Figura 23 – Arquitetura do padrão MVC. Fonte: Adaptado de GONÇALVES (2008, p. 144).

50

3.4.1 Arquitetura

O Model 2 é apresentado como arquitetura de referência para este trabalho e seus

componentes internos. Na figura 24, é mostrada a arquitetura baseada no MVC para a linguagem Java.

mostrada a arquitetura baseada no MVC para a linguagem Java. Figura 24 – Arquitetura do sistema

Figura 24 – Arquitetura do sistema utilizando padrão de projeto. Fonte: Adaptado de GONÇALVES (2008, p. 143).

3.4.2 Camadas

A implementação foi dividida em três camadas, a camada de visualização dos dados, a

camada de controle, gerenciamento dos usuários e informações e a camada de persistência.

3.5 IMPLEMENTAÇÃO

Nesta sessão são apresentadas as técnicas e os diagramas de funcionamento do sistema. Isso inclui diagrama de classes e outras formas apresentadas, para facilitar a compreensão da modelagem do sistema.

51

3.5.1 Diagramas do Modu lo do Protocolo Modbus e Funcionamento

Existe uma variáve l distribuição do protocolo Modbus TCP em Java, este modelo foi

adaptado de uma lib chama da de jamod e encontra-se o original dispon ível no site da Modbus

IDA, para dowload o diagr ama de classe da adaptação pode ser visto na

figura 25.

ama de classe da adaptação pode ser visto na figura 25. Figura 25 – Diagrama de

Figura 25 – Diagrama de Classe Modbus. Fonte: Próprio autor.

52

3.5.2 Projeto do Banco de Dados

Para o SGBD foi criado um Banco de Dados DB chamado de ‘medidor’ e foram criadas quatro tabelas neste banco, sendo estas conforme figura 26.

quatro tabelas neste banco, sendo estas conforme figura 26. Figura 26 – Tabelas do Banco de

Figura 26 – Tabelas do Banco de Dados medidor. Fonte: Próprio autor.

O modelo do diagrama é bastante simples por se tratar de poucas tabelas e sem muita relação entre elas, pode ser visto na figura 27.

sem muita relação entre elas, pode ser visto na figura 27. Figura 27 – Diagrama ER

Figura 27 – Diagrama ER do Banco de Dados medidor. Fonte: Próprio autor.

53

3.6 TESTES

O teste utilizado no projeto foi o teste de unidade para testar cada parte do modelo

DAO e verificar se todos os métodos estavam de acordo como foram projetados. Existe para o Java livrarias que tem esta função de teste como o JUnit. No quadro 8, são apresentados alguns itens testados do projeto para verificação de erro e desempenho da coleta de dados. No item um do quadro, foi verificado que o tempo de resposta é variável quando o medidor físico é instalado em outra rede externa (Internet), portanto, não se pode garantir a entrega dos pacotes em um tempo pré determinado, isso é uma característica comum de entrega assíncrona deste tipo de comunicação. No item dois foi feito o teste de inserção, exclusão, atualização e pesquisa em todos as tabelas do sistema.

Itens Testados

Número de

ordem

Item

Comentários

1

DAO medidor

- Verificar o tempo de resposta máximo

em 24h de teste 28800 amostras (uma a

cada 3 segundos), resultado 2,88 s/amostra.

2

DAO Banco de Dados

- Testar as inclusões e consultas das tabelas não houve problema com desempenho.

3

Interface

- Testar a visualização dos dados enviados pelo controlador Servlet.

4

Comunicação

- Enviar e receber dados do medidor

Quadro 8 – Itens testados no Web Medidor. Fonte: Próprio autor.

A comunicação foi a parte mais trabalhosa do sistema, por envolver bytes e registros,

pois esses precisão de conversão para serem armazenados no banco de dados uma tarefa de conversão de tipo errada pode levar a incerteza das informações. Talvez o sistema possua erros mais é perfeitamente humano, por isso neste sistema, para reduzir o risco de erro, todos os gets e sets foram automatizados pelas IDEs de aplicação.

54

4 CONCLUSÃO

4.1 Considerações Finais

Em muitas aplicações são utilizadas protocolos para comunicação entre sistemas e dispositivos, Modbus é um protocolo simples, porém difícil na codificação das funções é preciso sempre ter uma tabela de referência, no momento em que se utiliza o protocolo na criação de aplicações. Contudo, boas práticas de programação alinhadas ao conhecimento de

padrões de projetos foi possível desenvolver um modelo do sistema que coleta as informações necessárias do Medidor de Energia gerando automaticamente, com poucos códigos muita coesão e baixo acoplamento, uma base de informações referentes ao consumo do local de instalação do medidor.

O projeto Web Medidor é uma tentativa de aprimoramento do sistema de leitura do

consumo de energia elétrica nas empresas para sistemas mais aquém da realidade brasileira

para mensurar energia e entender as informações apresentadas em uma tela de computador.

O objetivo de coletar e apresentar o consumo de energia elétrica em uma simples

tabela foi alcançado, no memento em que todos os dados oriundos do medidor estão guardados em uma fonte segura e persistente para possibilitar possíveis visualizações em uma

página Web.

4.2 Trabalhos Futuros

Aprimorando este projeto será possível ligar, desligar contatos elétricos a distância e até controlar nível de tanques dos geradores de energia. Isso é possível porque há módulos que podem ser conectados à rede Modbus com essas funções. Incrementar outros protocolos no projeto também é viável, como Profibus, CAN que também são protocolos livres para uso, já que não só existem dispositivos em Modbus. Isto irá tornar o projeto mais portável e independente de tecnologia.

55

REFERÊNCIAS

ANEEL. Agência aprova em reunião de diretoria audiência pública para definir novo padrão de medidor de energia. Boletim Energia, n. 435, ano 8, ANEEL, 2010. Disponível em:

<http://www.aneel.gov.br/aplicacoes/noticias_boletim/?fuseaction=boletim.detalharNoticia&i dNoticia=796>, Acessado em: 10 nov. 2010.

EIG. Installation & Operation Manual Version 1.31. 2010. Disponível em:

<http://www.electroind.com/pdf/Nexus_New/E107706_Nexus1250_1252_Manual.pdf>,

Acessado em: 10 nov. 2010.

EIG. Modbus Protocol & Register Map for Nexus 1262/1272 MetersVersion 1.24. 2008. Disponível em: < http://www.electroind.com/pdf/modbus2.pdf >, Acessado em: 10 nov. 2010.

FOROUZAN, Behrouz A. Comunicação de dados e rede de computadores. 3. ed. Porto Alegre: Bookman, 2006.

GASPARINI, Anteu F. Lúcio; BARRELLA, F. Eugênio. TCP/IP - Solução para conectividade. 3. ed. São Paulo: Erica,1993.

GILSINN, James; FREEMON, Johnson. Ethernet continua tendência de crescimento global. ISA, 2009. Disponível em:

<http://www.isa.org/InTechTemplate.cfm?Section=Archives4&template=/ContentManageme

nt/ContentDisplay.cfm&ContentID=78545>, Acessado em : 10 nov. 2010.

GONÇALVES, Edson. Desenvolvendo Aplicações Web com NetBeans IDE 6. Rio de Janeiro: ed. Ciência Moderna Ltda., 2008.

GRANDI, Gilberto; GAUTHIER, Fernando O. Uniformização de dados de subestações da Eletrosul. Santa Catariana: UFSC, 2002. Disponível em:

<http://producaoonline.org.br/index.php/rpo/article/view/601/641 >, Acesso em: 20 ago.

2010.

LOOMIS, Mary E.S. Data communications. Printice-Hall, INC Porto Alegre: 1983.

Modbus-IDA. Modbus Messaging on TCP/IP Implementation Guide V1.0b. 2006. Disponível em:

<http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf>,

Acesso em: 03 set. 2010.

56

Modbus-IDA. Modbus application protocol Guide V1.1a. 2004. Disponível em:

<http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1a.pdf>, Acesso em: 03 nov. 2010.

SILVA, Adelino; FELGUEIRAS, Mário. Protocolo de comunicação modbus. Portugal:

FEUP, 2008. Disponível em:

<http://paginas.fe.up.pt/~pportuga/comi_0809/praticas/trabalho_1/RECIN_Modbus.pdf>,

Acesso em: 20 ago. 2010.

STALLINGS, William. Redes e sistemas de comunicação de dados: Teoria e aplicações

corporativas. 5. ed. Tradução: Business data communications. Rio de Janeiro: Elsevier,

2005.

TROJAN, Ancelmo Grinke; PADOIN, Edson Luiz. Utilização de dispositivos móveis e Web Services no monitoramento remoto de Servidores em Subestações de Energia. (2008), Disponível em: <http://www.usp.br/siicusp/Resumos/16Siicusp/5749.pdf>, Acesso em: 13 set. 2010.

WIKIPEDIA, Medidor de Energia Elétrica. 2010. Disponível em:

<http://pt.wikipedia.org/wiki/Medidor_de_energia_el%C3%A9trica>, Acessado em: 10 nov.

2010.

57

ANEXO

ESPECIFICAÇÃO DO MEDIDOR NEXUS 1252

57 ANEXO ESPECIFICAÇÃO DO MEDIDOR NEXUS 1252 Fonte: EIG (2010, p. 12)

Fonte: EIG (2010, p. 12)