tem que ler

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ

DEPARTAMENTO ACADÊMICO DE ELETRÔNICA

ESPECIALIZAÇÃO EM AUTOMAÇÃO INDUSTRIAL

JOSÉ OMAR ABDO FILHO

PROPOSTA DE UM SISTEMA DE TELEMETRIA PARA

APLICAÇÃO EM PROCESSO INDUSTRIAL

MONOGRAFIA - ESPECIALIZAÇÃO

CURITIBA

2009




Monografia de conclusão do curso de

Especialização em Automação Industrial do

Departamento Acadêmico de Eletrônica da

Universidade Tecnológica Federal do Paraná

apresentada como requisito parcial para

obtenção do grau de Especialista em

Automação Industrial.

Prof. MSc. Guilherme Alceu Schneider

CURITIBA

2009




Esta Monografia foi julgada e aprovada como requisito parcial para a obtenção do grau de

Especialista em Automação Industrial no Curso de Especialização em Automação

Industrial da Universidade Tecnológica Federal do Paraná.

Curitiba, 08 de Setembro de 2009.

Prof. MSc. Guilherme Alceu Schneider

Coordenador do Curso

BANCA EXAMINADORA

Prof. M.Sc. Guilherme Alceu Schneider

Universidade Tecnológica Federal do

Paraná

Orientador

Prof. Dr. Augusto Foronda


Paraná

Prof. Dr. Flávio Neves Junior


Paraná

AGRADECIMENTOS

A meus pais pela oportunidade da vida, amor e dedicação.

Ao meu amor, Raielyz, cuja companhia torna a minha vida mais doce e os dias mais

ensolarados.

A empresa Zylix Sistemas Inteligentes pelo apoio técnico e fornecimento das

ferramentas necessárias para o desenvolvimento deste trabalho.

A todos os mestres da UTFPR que contribuíram para expandir os meus conhecimentos.

Todo pensamento, se repetido, passa a exercer domínio.

RESUMO

ABDO FILHO, José Omar. Proposta de um Sistema de Telemetria para Aplicação em

Processo Industrial. 2009. 49 p. Monografia (Especialização em Automação Industrial) ?

Departamento Acadêmico de Eletrônica, Universidade Tecnológica Federal do Paraná -

UTFPR, Curitiba, 2009.

Este trabalho tem por objetivo mostrar o desenvolvimento de um sistema de telemetria que

tem a função de coletar os dados de um processo industrial qualquer, encaminhá-lo para um

servidor remoto utilizando comunicação GPRS, e por fim, disponibilizá-lo para um software

supervisório qualquer, através do padrão OPC DA 3.0. No trabalho são apresentadas a

topologia do sistema de supervisão utilizando comunicação sem fio e as ferramentas

utilizadas para o desenvolvimento do sistema (softwares e equipamentos). Ao final são

apresentadas as vantagens deste tipo de sistema para aplicações industriais e também as idéias

de implementações futuras.

Palavras-chave: SCADA; GPRS; Processo Industrial.

ABSTRACT

ABDO FILHO, José Omar. Proposal of a SCADA with GPRS Communication for

Application in Industrial Process. 2009. 49 p. Monografia (Especialização em Automação

Industrial) ? Departamento Acadêmico de Eletrônica, Universidade Tecnológica Federal do

Paraná - UTFPR, Curitiba, 2009.

This work propose the developed of a SCADA with GPRS communication. This system is

proposed with GPRS communication and with OPC DA 3.0 pattern for the supervisory

system. In this work is described the topology of the system and is presented tools that were

used (software and equipments). After that it is present the conclusion with comments about

advantages of the system for industrial applications and with ideas for future applications.

Keywords: SCADA; GPRS; Industrial Process.

LISTA DE FIGURAS

FIGURA 1 - SISTEMA DE SUPERVISÃO E CONTROLE .................................................. 15

FIGURA 2 - ARQUITETURA COM DRIVERS DE COMUNICAÇÃO ............................... 17

FIGURA 3 - ARQUITETURA OPC ........................................................................................ 17

FIGURA 4 - ELEMENTOS BÁSICOS DA ESPECIFICAÇÃO OPC DA 3.0 ....................... 19

FIGURA 5 - MENSAGEM MODBUS UNICAST .................................................................. 23

FIGURA 6 - MENSAGEM MODBUS BROADCAST ........................................................... 24

FIGURA 7 - ESTRUTURA DO PROTOCOLO MODBUS ................................................... 24

FIGURA 8 - ARQUITETURA DO SISTEMA ........................................................................ 26

FIGURA 9 - MÓDULO TC65T (VISTA TRASEIRA) ........................................................... 28

FIGURA 10 - MÓDULO TC65T (VISTA FRONTAL) .......................................................... 29

FIGURA 11 - FLUXOGRAMA DO SOFTWARE DO MÓDULO GPRS ............................. 30

FIGURA 12 - ESTRUTURA DO SERVIDOR OPC DA (ORIGINAL) ................................. 37

FIGURA 13 - OBJETOS ACESSADOS NA LEITURA/ESCRITA DE ITENS OPC DA ..... 39

FIGURA 14 - OBJETOS ACESSADOS NA LEITURA AUTOMÁTICA DE ITENS OPC

DA .................................................................................................................................... 41

FIGURA 15 - ESTRUTURA DO SERVIDOR OPC DA (MODIFICADO) ........................... 43

FIGURA 16 - ESTRUTURA PARA REALIZAÇÃO DE TESTES ........................................ 45

FIGURA 17 – SOFTWARE MODBUS MOD_RSSIM .......................................................... 46

LISTA DE QUADROS

QUADRO 1 - PARÂMETROS DE CONFIGURAÇÃO DA REDE GPRS ........................... 31

QUADRO 2 - PROTOCOLO DE COMUNICAÇÃO (COMANDO) ..................................... 33

QUADRO 3 - PROTOCOLO DE COMUNICAÇÃO (RESPOSTA AO COMANDO) ......... 33

QUADRO 4 - DESCRIÇÃO DOS CARACTERES DA MENSAGEM DE COMANDO ..... 33

QUADRO 5 - DESCRIÇÃO DOS CARACTERES DA MENSAGEM DE RESPOSTA ...... 34

QUADRO 6 - COMANDOS DISPONÍVEIS NO SISTEMA ................................................. 34

LISTA DE SIGLAS E ABREVIATURAS

API – Application Programming Interface

ASCII – American Standard Code for Information Interchange

DA – Data Access

CLP – Controlador Lógico Programável

COM – Component Object Model

DCOM – Distributed Component Object Model

GPRS – General Packet Radio Service

GSM – Global System for Mobile Communications

HMI – Human-Machine Interface

HTML – Hypertext Markup Language

HTTP – Hypertext Transfer Protocol

I/O – Input / Output

I2C – Inter-Integrated Circuit

IDE – Integrated Development Environment

J2ME – Java 2 Micro Edition

kbps – Kilobit por Segundo

ME – Mobile Equipment

OLE – Object Linking and Embedding

OPC – OLE for Process Control

PC – Personal Computer

RS232 – Padrão Para Transmissão de Dados Seriais

RS485 – Padrão Para Transmissão de Dados Seriais

SCADA – Supervisory Control and Data Acquisition

SDCD – Sistema Digital de Controle Distribuído

SIM – Subscriber Identity Module

TCP/IP – Transmission Control Protocol/Internet Protocol

SUMÁRIO

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

1.1 TEMA .......................................................................................................................... 11 1.1.1 Delimitação do tema ....................................................................................................... 11 1.2 PROBLEMA E PREMISSAS ......................................................................................... 12 1.3 OBJETIVOS ................................................................................................................... 12 1.3.1 Objetivo geral .................................................................................................................. 12

1.3.2 Objetivo específico.......................................................................................................... 12 1.4 JUSTIFICATIVA ............................................................................................................ 13

1.5 METODOLOGIA DE PESQUISA ................................................................................. 13

1.6 ESTRUTURA DO TRABALHO .................................................................................... 13

2 FUNDAMENTAÇÃO TEÓRICA .................................................................................. 15

2.1 SISTEMA SCADA ......................................................................................................... 15

2.2 OLE FOR PROCESS CONTROL (OPC) ....................................................................... 16 2.2.1 Especificação OPC DA 3.0 ............................................................................................. 18 2.3 COMUNICAÇÃO GPRS ................................................................................................ 22

2.4 PROTOCOLO MODBUS SERIAL ................................................................................ 23

3 DESENVOLVIMENTO DO TRABALHO ................................................................... 26

3.1 MÓDULO GPRS ............................................................................................................ 27 3.1.1 Escolha do módulo GPRS ............................................................................................... 27

3.1.2 Programação do módulo GPRS ...................................................................................... 29 3.2 PROTOCOLO DE COMUNICAÇÃO DO MÓDULO GPRS E SERVIDOR OPC ....... 32

3.3 SERVIDOR OPC DA 3.0 ................................................................................................ 36

4 TESTES REALIZADOS ................................................................................................ 45

5 CONCLUSÃO ................................................................................................................. 47

5.1 TRABALHOS FUTUROS .............................................................................................. 47

REFERÊNCIAS ..................................................................................................................... 49

11

1 INTRODUÇÃO

1.1 TEMA

De acordo com Santos e Zamberlan (1995), os primeiros equipamentos regulatórios

utilizados no processo industrial eram de grande dimensão, espalhavam-se na arquitetura do

ambiente fabril, operavam através de sistemas mecânicos pneumáticos, possibilitando o

controle e operação de um limitado número de variáveis do processo. Para monitorar o

funcionamento dos equipamentos os trabalhadores percorriam as unidades produtivas e

observavam ruídos, vibrações e fumaça. Assim, o operador conseguia identificar

anormalidades no processo, contando com sua experiência e conhecimento.

A necessidade de melhorar a produção e de controlar grandes ambientes fabris fez com

que os equipamentos regulatórios fossem agrupados em um único local e controlados a

distância. Surgiram então as primeiras salas de controle, providas com um grande número de

equipamentos que informavam o estado do processo industrial através de painéis com

lâmpadas e indicadores. Eram instalações complexas com grande dimensão, que exigiam o

controle por vários operadores. Segundo Silva e Salvador (2008), estes foram os primeiros

sistemas SCADA (Supervisory Control and Data Aquisition).

A partir do surgimento dos microprocessadores e dos Controladores Lógicos

Programáveis (CLP), as salas de controle diminuíram drasticamente de tamanho e passaram a

gerenciar um número muito maior de dados do processo.

Atualmente, os sistemas SCADA ou também chamados de sistemas supervisórios,

utilizam tecnologias de computação e comunicação para automatizar a monitoração e controle

dos processos industriais, efetuando coleta de dados em ambientes complexos, eventualmente

dispersos geograficamente, e a respectiva apresentação de modo amigável para o operador,

com recursos gráficos elaborados (interfaces homem-máquina) e conteúdo multimídia

(SILVA e SALVADOR, 2008).

1.1.1 Delimitação do tema

Um sistema de telemetria pode ser definido como um sistema SCADA em que o

processo industrial e os equipamentos que controlam este processo estão distantes da sala de

controle onde se encontram os softwares supervisórios. A telemetria geralmente refere-se a

12

comunicações sem fio, porém pode-se também transmitir dados através de telefone, redes de

computadores ou enlace ótico.

Este trabalho refere-se a um sistema de telemetria com comunicação sem fio GPRS

(General Packet Radio Service), que é um serviço disponibilizado pelas operadoras de

telefonia móvel.

1.2 PROBLEMA E PREMISSAS

Empresas que possuem equipamentos que controlam processos de automação, e estes se

encontram dispersos geograficamente, e em certos casos mudam com freqüência sua

localização geográfica, teriam um custo muito alto e uma solução demasiadamente complexa

para monitorar seus processos com algum tipo de cabeamento entre os equipamentos e a sala

de controle.

1.3 OBJETIVOS

1.3.1 Objetivo geral

Propor um sistema de telemetria, para um processo industrial qualquer, utilizando

comunicação GPRS e servidor OPC DA 3.0.

1.3.2 Objetivo específico

Especificar o módulo de comunicação GPRS;

Estudar as funcionalidades do módulo GPRS;

Desenvolver a comunicação do módulo GPRS com os equipamentos do processo

industrial;

Estudar o padrão OPC DA 3.0;

Desenvolver um servidor OPC DA 3.0 para o módulo GPRS;

13

Desenvolver o protocolo de comunicação do módulo GPRS com o servidor OPC DA

3.0.

1.4 JUSTIFICATIVA

O uso da infra-estrutura de comunicação das operadoras de telefonia móvel para a

transmissão de dados tem se tornado cada vez mais freqüente, conforme relata Macário

(2005), “as aplicações de telemetria Wireless, usadas para o controle e monitoramento remoto

de processos, vem ganhando muito destaque devido à queda constante dos preços dos

equipamentos e das tarifas. A alta confiabilidade da rede é também um fator fundamental”.

Neste panorama, muitas aplicações que eram conectadas a sala de controle através de

algum tipo de cabeamento, estão migrando para Wireless.

1.5 METODOLOGIA DE PESQUISA

Esta é uma pesquisa de natureza científica aplicada, devido ao fato de existir um

objetivo prático específico.

Em relação ao objetivo macro a pesquisa enquadra-se como sendo uma pesquisa

explicativa, pois esta se propondo o desenvolvimento de um sistema.

As técnicas e procedimentos empregados foram a pesquisa bibliográfica, experimental e

de campo. A pesquisa bibliográfica decorre da necessidade do embasamento teórico

necessário para o desenvolvimento do sistema. A pesquisa experimental justifica-se pela

necessidade de simulações durante o desenvolvimento do sistema. E a pesquisa de campo,

como forma de validação, para verificação se o sistema está funcionando conforme esperado.

1.6 ESTRUTURA DO TRABALHO

Este trabalho compõe-se de 5 (cinco) partes, com 5 (cinco) capítulos, sendo:

Parte 1 – Capítulo introdutório: Capítulo 1;

Parte 2 – Fundamentação teórica: Capítulo 2;

14

Parte 3 – Desenvolvimento do trabalho: Capítulo 3 e testes realizados: Capítulo 4;

Parte 4 – Conclusões: Capítulo 5;

Parte 5 – Referências.

O Capítulo 1 apresenta o tema do trabalho, o problema de pesquisa, o objetivo proposto,

as justificativas para a elaboração do trabalho e a metodologia de pesquisa.

No Capítulo 2 é apresentada a fundamentação teórica de todas as tecnologias envolvidas

no trabalho. Com relação ao padrão OPC, somente será descrito com detalhes a especificação

OPC DA 3.0, pois somente esta especificação faz parte do objetivo do trabalho.

O Capítulo 3 demonstra todo o processo de desenvolvimento do trabalho que foi

proposto.

O Capítulo 4 mostra a estrutura que foi montada para realização dos testes.

As conclusões do trabalho são apresentadas no Capítulo 5, seguido das referências

bibliográficas utilizadas para a fundamentação teórica do mesmo.

15

2 FUNDAMENTAÇÃO TEÓRICA

2.1 SISTEMA SCADA

Sistemas SCADA (Supervisory Control and Data Aquisition), também chamados de

sistemas supervisórios, permitem que sejam monitoradas e rastreadas informações,

comumente chamadas de “tags”, de um processo produtivo ou instalação física. Essas

informações são coletadas através de equipamentos de aquisição de dados e, em seguida,

manipuladas, analisadas, armazenadas e, posteriormente, apresentadas ao usuário (SILVA e

SALVADOR, 2008).

Segundo Seixas Filho (1999), os sistemas SCADA, são baseados em estações de

monitoramento central interligados, através de algum tipo de comunicação, a controladores

programáveis, estações remotas ou outros equipamentos de aquisição de dados.

Rede de Comunicação

Estação de Monitoramento CentralS

en

so

res

e

Atu

ad

ore

s

Estaçao Remota,

Aquisição Remota, etc

FIGURA 1 - SISTEMA DE SUPERVISÃO E CONTROLE

FONTE: Autoria própria

Observa-se na Figura 1 que o processo de aquisição das informações se inicia nos

equipamentos de aquisição de dados, com a leitura dos valores dos dispositivos que estão

conectados a ele.

A rede de comunicação faz com que as informações coletadas pelos equipamentos de

aquisição de dados cheguem a estação de monitoramento central. Levando em consideração

os requisitos do sistema e a distância a cobrir, a comunicação pode ser através de cabos

ethernet, fibras ópticas, linhas dial-up, linhas dedicadas, rádio modems, etc.

16

A estação de monitoração central é um microcomputador com um software supervisório

instalado, e este é o responsável por recolher as informações geradas pelos equipamentos de

aquisição de dados e agir em conformidade com o que foi previamente configurado nele.

O caminho contrário também é possível, ou seja, a estação de monitoração central pode

enviar comandos para os equipamentos de controle/aquisição.

As funções básicas de um software supervisório são as de supervisão e operação. Na

supervisão estão todas as funções de monitoramento do processo tais como: sinóticos

animados, gráficos de tendência de variáveis analógicas e digitais, relatórios em vídeo e

impressos, entre outros. Na operação, os softwares supervisórios substituíram com vantagens

as funções da mesa de controle. As funções de operação incluem: ligar e desligar

equipamentos e seqüência de equipamentos, operação de malhas PID (Proporcional integral

derivativo), mudança de modo de operação de equipamentos, etc.

2.2 OLE FOR PROCESS CONTROL (OPC)

O padrão OPC é composto por um conjunto de especificações para comunicação no

ambiente industrial, criado com a colaboração de vários fornecedores de hardware e software

para automação, em conjunto com a Microsoft. O padrão permite que aplicações de software

troquem dados entre si de forma aberta e simplificada, assim como aplicações gerenciais e

dados do chão-de-fábrica (OPC FOUNDATION, 1998).

Até o padrão OPC ser criado, o que possibilitava a integração entre os equipamentos no

processo e as aplicações de software era os drivers de comunicação, como pode ser observado

na Figura 2. Porém, essa solução não é a ideal, pois demanda um grande esforço para

desenvolvimento de drivers para uma grande variedade de equipamentos e de aplicativos, e

difícil manutenção frente à rápida evolução desses elementos.

17

Software CSoftware A Software B

Equipamento

X

Equipamento

Y

Equipamento

Z

Pro

toco

lo d

e

Co

mu

nic

açã

o

Driver

A.X

Driver

A.X Driver

A.Y

Driver

A.Y Driver

A.Z

Driver

A.Z Driver

B.X

Driver

B.X Driver

B.Y

Driver

B.Y Driver

B.Z

Driver

B.Z Driver

C.X

Driver

C.X Driver

C.Y

Driver

C.Y Driver

C.Z

Driver

C.Z

FIGURA 2 - ARQUITETURA COM DRIVERS DE COMUNICAÇÃO


Com o padrão OPC, é possível desenvolver um software servidor que forneça dados, de

uma fonte de dados qualquer, para outro software cliente que suporte o padrão OPC, como

por exemplo, um software supervisório. Com isto, o desenvolvimento do servidor OPC

acontece uma única vez, e utilizado por vários clientes OPC, como pode ser observado na

Figura 3. A união do servidor OPC com os clientes OPC com o objetivo de compartilhar a

execução de tarefas é conhecida como sistema distribuído.

Software CSoftware A Software B

Servidor OPC

X

Servidor OPC

Y

Servidor OPC

Z

COM / DCOM

So

ftw

are

Su

pe

rvis

ório

Cliente OPC

Cliente OPC

Cliente OPC

Cliente OPC

Cliente OPC

Cliente OPC

Equipamento

X

Equipamento

Y

Equipamento

Z

FIGURA 3 - ARQUITETURA OPC


18

Nos sistemas operacionais, os softwares ou também chamados de processos, quando

necessitam se comunicar entre si, não conseguem fazer diretamente, pois os processos são

protegidos uns dos outros. A tecnologia que o padrão OPC utiliza para padronizar esta

comunicação é a COM (Component Object Model) e a DCOM (Distributed Component

Object Model), ambas da Microsoft. A COM é usada quando os processos estão em um

mesmo microcomputador. A DCOM estende a COM para suportar comunicação entre

processos em microcomputadores diferentes, seja em uma rede local (LAN), uma rede de

grandes distâncias (WAN) ou Internet, podendo usar qualquer protocolo de transporte,

incluindo TCP e UDP. Os processos podem se comunicar independente da linguagem de

programação em que foram desenvolvidos, e é por este motivo que qualquer tipo de software

supervisório, que suporte o padrão OPC, pode acessar qualquer tipo de servidor OPC. Os

processos também podem estar abrigados em estações utilizando diferentes sistemas

operacionais, dentro da abrangência da tecnologia.

As primeiras especificações criadas pela OPC Foundation foram aquelas que são

comuns a todos os fabricantes de equipamentos e desenvolvedores de aplicações de software

para processos industriais. As principais são listadas abaixo:

OPC DA: Fornece a funcionalidade de transferência de dados de tempo real e contínua

de CLPs, SDCDs e outros, para IHMs, sistemas supervisórios e similares;

OPC AE: Fornece notificações de alarmes e eventos sob demanda, como alarmes de

processo, ações do operador, auditagem etc;

OPC HDA: Fornece mecanismos consistentes e uniformes de acesso a dados de

histórico já armazenados.

2.2.1 Especificação OPC DA 3.0

Nesta especificação existe uma hierarquia com três objetos principais: servidor, grupo e

item (Figura 4).

19

Servidor

Grupo

Item

Item

Item

FIGURA 4 - ELEMENTOS BÁSICOS DA ESPECIFICAÇÃO OPC DA 3.0


O servidor além de manter as informações sobre o servidor OPC é uma estrutura de

armazenamento de grupos, e o grupo além de manter informações sobre ele mesmo é uma

estrutura de armazenamento de itens.

Os itens representam conexões a registros da fonte de dados, ou seja, o item não é um

valor, ele apenas sabe como chegar até determinado registro da fonte de dados. No caso da

fonte de dados ser um CLP, um item contem o endereço de um determinado registro do CLP.

Este registro pode ser uma variável interna no CLP, uma entrada ou saída física. Como um

item é apenas uma conexão, um único registro da fonte de dados pode ser representado por

itens diferentes, com propriedades distintas.

Associado a um item existem três propriedades:

Valor: Último valor lido da fonte de dados;

Qualidade: Define a qualidade do item;

Data e hora: Quando o item foi atualizado.

Os grupos presentes em um servidor são definidos pelos clientes, e somente o cliente

criador do grupo pode acessá-lo. Eles fornecem uma maneira para os clientes OPC

organizarem-se, por exemplo, um determinado grupo pode conter itens de uma tela de

operação ou relatório. Eles também têm o papel principal na interação cliente-servidor. Tal

20

interação é feita através de interfaces, que possuem uma coleção de funções. São interfaces de

um grupo OPC:

IOPCGroupStateMgt

IOPCGroupStateMgt2 (nova 3.0)

IOPCASyncIO2

IOPCAsyncIO3 (nova 3.0)

IOPCItemMgt

IOPCItemDeadbandMgt (nova 3.0)

IOPCItemSamplingMgt (nova 3.0, opcional)

IConnectionPointContainer

IOPCSyncIO

IOPCSyncIO2 (nova 3.0)

EnumOPCItemAttributes

IEnumOPCItemAttributes

Através dos grupos os clientes realizam os pedidos de leitura e escrita dos itens. Três

tipos de acesso aos valores da fonte de dados são definidos na especificação OPC DA:

Leitura e escrita síncronas: São executadas imediatamente pelo servidor, e só retornam

para o cliente depois de completada a operação. O cliente fica inoperante até receber a

resposta;

Leitura e escrita assíncronas: Estas são mais eficientes que as síncronas, pois o cliente é

imediatamente liberado após fazer a requisição, assim, o servidor pode processar o pedido da

forma mais conveniente. Satisfeito o pedido, o servidor envia de volta ao cliente os resultados

em uma única chamada de retorno;

Atualização enviada pelo servidor: O servidor lê os valores da fonte de dados,

periodicamente, em função de uma taxa de atualização estabelecida pelo cliente. Os valores

são enviados para o cliente toda vez que houver mudança do valor lido com relação ao valor

da leitura anterior. O cliente também pode definir uma zona morta para o item, ou seja, uma

faixa de valores na qual, variações não são enviadas para os clientes. Mudanças na qualidade

dos itens também geram notificações aos clientes. Essas atualizações podem ser ativadas ou

desativadas, pelo cliente, no nível dos grupos ou diretamente nos itens.

21

Nas leituras síncronas e assíncronas existem dois tipos de acesso diferentes:

Cache: Cada um dos itens do servidor armazena o último valor lido da fonte de dados.

Este valor armazenado é o cache;

Device: Diretamente na fonte de dados. Neste acesso, as operações síncronas podem

comprometer seriamente o desempenho do sistema, pois cliente e servidor ficam bloqueados

enquanto o dispositivo físico é acessado. Operações de escrita são sempre neste tipo de

acesso.

As interfaces suportadas pelo objeto servidor são:

IOPCServer

IOPCBrowse (nova 3.0)

IOPCItemIO (nova 3.0)

IConnectionPointContainer

IOPCCommon

Outro conceito utilizado na especificação OPC DA é o ITEMID, que é um identificador

único dentro do servidor e deve conter a informação necessária para o servidor conseguir

ler/escrever em um determinado endereço do dispositivo físico que é monitorado por ele.

Todo item do servidor tem associado a ele um ITEMID, e vários itens podem estar associados

a um mesmo ITEMID.

Segue alguns exemplos de ITEMID:

CLP:2.REG:200

CLP:5.REG:100

CLP:3.REG:250

Neste exemplo, existe um servidor OPC que monitora CLPs através da comunicação

MODBUS. A sintaxe utilizada foi CLP:<p1>.REG:<p2>, onde p1 é a identificação do CLP

na rede MODBUS, e p2 é o endereço do valor no CLP. Quando for necessário realizar a

leitura de um item, o servidor irá tratar o ITEMID associado ao item. No 1º caso o servidor irá

22

buscar o valor do endereço 200 do CLP com identificação 2 na rede MODBUS. No 2º caso o

servidor irá buscar o valor do endereço 100 do CLP com identificação 5 na rede MODBUS, e

assim por diante. Esta foi uma sintaxe criada para este exemplo. O padrão OPC não especifica

a sintaxe do ITEMID, apenas determina que ele deve ser uma seqüência de caracteres

imprimíveis.

2.3 COMUNICAÇÃO GPRS

O GPRS (General Packet Radio Service) é um serviço, baseado em protocolos de

Internet, que permite o envio e recepção de dados através de uma rede de telefonia móvel

GSM.

Qualquer serviço atualmente utilizado na Internet - FTP, HTTP, etc - estará disponível

através da rede de telefonia móvel com o GPRS. As redes GPRS podem ser encaradas como

sub-redes da Internet e os clientes GPRS podem ser vistos como nós móveis dessa rede. Isso

significa que cada cliente GPRS pode potencialmente ter seu próprio endereço IP e ser

endereçável por isso.

A tecnologia utilizada pelo GPRS é o transporte de dados por pacotes ou também

chamado de comutação por pacotes. Diferente das tecnologias de comutação de circuitos,

onde uma conexão ou circuito é estabelecido do ponto de origem da transferência de dados ao

destino e os recursos da rede são dedicados por toda a duração da chamada ou até que o

usuário interrompa a conexão. Sem a necessidade de conexão, no GPRS a informação pode

ser enviada ou recebida imediatamente conforme a necessidade do usuário, pois o serviço está

“sempre ativo”. Esta disponibilidade imediata é uma das grandes vantagens do GPRS.

Os recursos do GPRS somente são utilizados quando um usuário enviar ou receber

dados, e por isto, a cobrança é feita pela quantidade de pacotes de dados transmitidos e não

pelo tempo de conexão à rede. Esta característica também permite que vários usuários

compartilhem os mesmos recursos, aumentando assim a capacidade da rede e permitindo uma

gerência razoavelmente eficiente dos recursos.

As taxas de transferência de dados do GPRS são muito mais elevadas que as taxas de

transferência das tecnologias anteriores, que usavam comutação por circuito, que eram em

torno de 12 kbps. O GPRS, em situações ideais, pode ultrapassar 170 kbps. No entanto na

prática, essa taxa está em torno dos 40 kbps.

http://pt.wikipedia.org/wiki/IP

23

Para usar o serviço GPRS, os usuários precisam de um telefone móvel ou terminal que

suporte GPRS e uma assinatura em uma rede de telefonia móvel que suporte GPRS.

2.4 PROTOCOLO MODBUS SERIAL

O protocolo MODBUS SERIAL é amplamente utilizado na indústria para a

comunicação entre equipamentos de automação. A comunicação se dá normalmente nos

meios físicos RS232 e RS485.

A técnica utilizada por este protocolo é a cliente-servidor, onde um equipamento

denominado mestre é o único habilitado a iniciar a comunicação com os demais equipamentos

da rede, denominados escravo. O protocolo permite apenas 1 (um) equipamento mestre e os

equipamentos escravo são diferenciados entre si por endereços próprios. O equipamento

mestre pode endereçar cada equipamento escravo individualmente através de uma mensagem

do tipo Unicast, ou pode endereçar todos simultaneamente, mandando uma mensagem do tipo

Broadcast, entendida por todos, independente do endereço próprio.

O equipamento escravo retorna uma mensagem somente quando a mensagem recebida

do mestre é do tipo Unicast. As mensagens do tipo Broadcast não geram respostas, e por isto,

são necessariamente mensagens de escrita. Isto pode ser observado na Figura 5 e Figura 6.

EscravoEscravoEscravo

Mestre

Solicitação

Resposta

FIGURA 5 - MENSAGEM MODBUS UNICAST


24

EscravoEscravoEscravo

Mestre

Solicitação

Solicita

ção

Sol

icita

ção

FIGURA 6 - MENSAGEM MODBUS BROADCAST

FONTE: AUTORIA PRÓPRIA

A estrutura do pacote de comunicação do protocolo MODBUS SERIAL é mostrada na

Figura 7. A estrutura é a mesma para mensagens de solicitação e mensagens de resposta.

Endereço

Código da Função

Dados

(1 byte = 8 bits)

Verificação de Erro

Endereço

Código da Função

Dados

(1 byte = 8 bits)

Verificação de Erro

Mensagem de

Resposta do Escravo

Mensagem de

Solicitação do Mestre

FIGURA 7 - ESTRUTURA DO PROTOCOLO MODBUS

FONTE: AUTORIA PRÓPRIA

Como pode ser observado na Figura 7, na mensagem de solicitação, o endereço

identifica o equipamento escravo que receberá a mensagem. O código da função informa ao

equipamento escravo, qual a ação a ser executada. Os bytes de dados contêm informações

para o escravo, por exemplo, qual o registrador inicial e a quantidade de registros a serem

lidos. O campo de verificação de erro permite ao escravo validar os dados recebidos.

25

Na mensagem de resposta, o endereço e o código de função são repetidos. Os bytes de

dados contêm os dados coletados pelo escravo ou o seu estado. Se um erro ocorre, o código de

função é modificado para indicar que a resposta é uma resposta de erro e os bytes de dados

conterão um código que descreverá o erro. A verificação de erro permite o mestre validar os

dados recebidos.

O espaço de endereçamento compreende 256 diferentes endereços. O endereço 0 (zero)

é reservado para a mensagem do tipo Broadcast. Os equipamentos escravos estão na faixa de

endereço 1 a 247, e os endereços 248 a 255 são reservados pelo protocolo. O equipamento

mestre não tem endereço específico, somente os nós escravos devem ter um endereço, e estes,

devem ser únicos em uma rede.

No protocolo MODBUS SERIAL, podem ser adotadas duas formas de transmissão de

bytes, ASCII ou RTU (Remote Terminal Unit). Na opção ASCII, cada byte (8 bits) é

transmitido como dois caracteres da tabela ASCII, ou seja, o número 109 decimal, que é

representado como 6D hexadecimal, é transmitido em duas etapas. Primeiro o “6” na tabela

ASCII e em seguida “D”. No formato RTU, o número 109 decimal é transmitido da forma

binária “01101101”. O modo de transmissão, e o padrão da porta serial, devem ser o mesmo

em todos os dispositivos conectados a linha serial.

26

3 DESENVOLVIMENTO DO TRABALHO

O desenvolvimento do trabalho foi realizado em diferentes etapas. As etapas foram

construídas e testadas separadamente. Inicialmente, a etapa envolvendo o módulo GPRS foi

desenvolvida. Em seguida foi desenvolvida a etapa envolvendo o protocolo de comunicação

entre o módulo GPRS e o servidor OPC. E por fim, foi desenvolvida a etapa envolvendo o

servidor OPC.

A Figura 8 mostra a arquitetura do sistema, e em seguida, são detalhadas as etapas do

trabalho.

DCOM

Cliente OPC DA

INTERNET

CLP

RS232

CLP

RS485 RS232

Entrada Analógica

Entrada Digital

Operadora Telefonia

Móvel GSM

CLPCLP

Conversor

Cliente OPC DA

Servidor OPC DA

Módulo GPRS

Módulo GPRS

Protocolo MODBUS

RTU, etc

Protocolo MODBUS

RTU, etc

Saída Digital

Módulo GPRS

Se

nso

res

Atu

ad

ore

s

FIGURA 8 - ARQUITETURA DO SISTEMA


27

O sistema de supervisão deste trabalho pode ser dividido em três partes:

Dispositivos, localizados no processo produtivo ou instalação física, conectados ao

módulo GPRS;

Servidor OPC localizado em uma sala de controle;

Comunicação GPRS para interligação do módulo GPRS com o servidor OPC.

Os dispositivos poderão ser conectados ao módulo GPRS através de comunicação serial

RS232. Caso o dispositivo não possua comunicação serial RS232, pode-se utilizar um

conversor que mude o meio físico disponibilizado no dispositivo para a RS232. Além da

comunicação RS232, o módulo GPRS também possui algumas entradas e saídas digitais e

analógicas que podem ser conectadas diretamente aos dispositivos.

O módulo GPRS será o responsável pelo envio dos dados dos dispositivos ao servidor

OPC. Isto será realizado através de comunicação por polling, onde o módulo GPRS apenas

responde após receber um pedido do servidor OPC.

O servidor OPC suportará as especificações apenas do padrão OPC DA. Ele é instalado

em apenas um microcomputador, e este deverá ter acesso a internet, pois é através da internet

que o servidor OPC DA trocará dados com os módulos GPRS. A internet disponibilizada para

o microcomputador poderá ser de qualquer tipo (Cabo, wireless, radio, etc). O servidor OPC

poderá conectar-se a vários módulos GPRS, e vários clientes OPC poderão se conectar ao

servidor OPC.

Este sistema está estruturado de tal forma, que é possível conectá-lo a qualquer

dispositivo que disponibilize a comunicação serial RS232. Quando o protocolo de

comunicação do dispositivo não for reconhecido pelo módulo GPRS, bastará desenvolver o

protocolo no módulo GPRS. O restante do sistema não sofrerá alteração em razão disto.

3.1 MÓDULO GPRS

3.1.1 Escolha do módulo GPRS

O módulo (ou modem) GPRS utilizado no trabalho foi o TC65T da Siemens. O módulo

TC65T foi escolhido porque possui todas as características necessárias para integração com o

sistema. As características são as seguintes:

28

Conecta-se ao serviço GPRS disponibilizado pelas operadoras de telefonia móvel;

Diversas interfaces de comunicação. São 10 pinos de uso geral para entrada e saída,

interface serial, I2C, SPI, dois canais A/D, além de interfaces de áudio para transmissão de

voz.

Outras características do módulo são:

Fácil aquisição no mercado e produzido por uma empresa conhecida;

Pilha TCP/IP integrada, o que permite a programação sem se preocupar com detalhes

das camadas de internet mais baixas;

Linguagem de programação Java J2ME (Java Micro Edition), que possui diversas

bibliotecas para módulos GPRS, facilitando o desenvolvimento do software para o módulo;

Uma entrada para antena de sinal GSM e uma entrada para o cartão SIM (chip de

celular). Aceita chips de qualquer operadora, o usuário deve se preocupar apenas em definir

os atributos de comunicação GPRS de acordo com a operadora utilizada;

Processador ARM7®10 com uma memória que se divide em memória Flash e memória

RAM. A memória Flash para aplicações Java é de 1,73MB e a RAM é de apenas 400KB;

Suporta os protocolos de transporte TCP e UDP, e os serviços de internet HTTP, FTP,

SMTP e POP3.

Seguem imagens do módulo TC65T (Figura 9 e Figura 10):

FIGURA 9 - MÓDULO TC65T (VISTA TRASEIRA)

FONTE: Siemens, 2009

29

FIGURA 10 - MÓDULO TC65T (VISTA FRONTAL)

FONTE: Siemens, 2009

1. Pinos de I/O de uso geral;

2. Entrada para comunicação serial RS232;

3. Entrada para antena de sinal GSM;

4. Botão liga/desliga;

5. Interface de áudio para transmissão de voz;

6. Entrada para o cartão SIM (chip de celular);

7. Entrada para alimentação do módulo.

3.1.2 Programação do módulo GPRS

A programação do módulo GPRS foi realizada na linguagem de programação Java

J2ME (Java Micro Edition) e o ambiente de desenvolvimento utilizado foi o Borland JBuilder

2006 Enterprise, um ambiente desenvolvido pela Borland. O JBuilder foi utilizado por ser

uma ferramenta robusta e ser compatível com as bibliotecas do módulo GPRS fornecidos pela

Siemens.

O software desenvolvido para o módulo GPRS é ilustrado no fluxograma da Figura 11:

30

Início

Abrir TCP na

porta 1000

Grava IP do

módulo

Servidor OPC

conectou na porta

1000 ?

N

Cria thread para o

Servidor OPC

N

Servidor OPC

enviou comando?

N

Executa comando

S

Envia resposta para o

Servidor OPC

Thread

Início

Número de

conexões > 8 ?

S

Recusa conexãoS

FIGURA 11 - FLUXOGRAMA DO SOFTWARE DO MÓDULO GPRS

Fonte: Autoria própria

Quando o módulo GPRS é iniciado abre-se um socket TCP na porta 1000, o que torna o

módulo GPRS um servidor. Com isto, o servidor OPC poderá se conectar ao módulo GPRS

na porta 1000 e trocar dados com ele.

Para abrir um socket no módulo GPRS, de forma similar a um telefone celular, é

necessário passar ao módulo GPRS os parâmetros de configuração da rede GPRS: APN

(Access Point Name), usuário e senha. Esses parâmetros são fornecidos nos sites das

operadoras. Na tabela abaixo são mostradas os parâmetros de algumas operadoras:

31

APN Usuário Senha

claro.com.br Claro claro

brt.br BrT BrT

tim.br tim tim

gprs.oi.com.br oiwap oioioi

QUADRO 1 - PARÂMETROS DE CONFIGURAÇÃO DA REDE GPRS

Fonte: Autoria própria

Quando o módulo GPRS torna-se um servidor, ele adquiri um IP único na internet.

Quem fornece este IP para o módulo GPRS é a operadora do cartão SIM (chip de celular) que

esta sendo usado no módulo GPRS. Em seguida, o módulo GPRS grava o IP recém adquirido

no banco de dados do servidor do site www.zylix.com.br. Para tal, uma conexão HTTP é

aberta e as informações são postadas na página PHP abaixo:

www.zylix.com.br/gprs.php?idModulo=<p1>&ipModulo=<p2>, onde:

<p1> = Identificação única que cada módulo GPRS possui

<p2> = IP recém adquirido pelo módulo GPRS.

Ao se abrir uma conexão HTTP, pode-se também ler o conteúdo da página. Desta

forma, o módulo GPRS acessa a página e faz uma verificação se os dados foram postados

com sucesso através de mensagens que o próprio servidor gera para serem lidas pelo módulo

GPRS. É possível saber se os dados foram incluídos corretamente no banco de dados.

Com estes dados gravados no banco de dados do servidor, o servidor OPC poderá

acessar a página www.zylix.com.br/gprs.php?idModulo=<p1>, passando como parâmetro a

identificação do módulo GPRS, e resgatar o IP do módulo.

No momento que o servidor OPC conecta-se ao módulo GPRS na porta 1000, uma

thread exclusiva para esta conexão é criada. Uma thread nada mais é do que um fluxo de

controle seqüencial isolado dentro de um programa, ou seja, várias tarefas diferentes são

executadas ao mesmo tempo, independentemente uma das outras. Isto permite que o módulo

GPRS tenha várias conexões TCP, e consiga trocar dados ao mesmo tempo com todas elas.

Após a thread ter sido criada, o módulo GPRS volta a esperar um nova conexão na porta 1000

e a thread recém criada aguarda o envio de comandos do servidor OPC. Quando o servidor

OPC envia um comando para o módulo GPRS, este comando é recebido, executado, e após a

execução é enviada a resposta do comando para o servidor OPC. O módulo GPRS suporta

32

apenas oito conexões TCP simultâneas, e por isto, as demais solicitações de conexão são

recusadas.

As seguintes rotinas foram desenvolvidas e disponibilizadas para execução:

Comunicação MODBUS RTU pela serial RS232 do módulo GPRS:

As rotinas da comunicação MODBUS RTU que foram utilizadas no módulo GPRS são

do projeto Jamod. O projeto Jamod é gratuito e de código aberto. As rotinas do projeto são

todas escritas em Java. Porém a versão do Java utilizada no projeto possui funcionalidades

que não são suportadas pelo módulo GPRS, e por isto foram necessárias mudanças

principalmente nas rotinas de acesso a porta serial RS232 do módulo GPRS.

Leitura das entradas digitais e analógicas, e escrita nas saídas digitais do módulo

GPRS:

As leituras e escritas nas entradas e saídas do módulo GPRS são realizadas através de

comandos AT enviados para o modem do módulo GPRS. AT Command Set é uma linguagem

de pequenos comandos de texto criada para fazer a comunicação com modems. O Java possui

uma função que repassa para o modem do módulo GPRS o comando AT. O modem recebe

este comando AT, executa o comando, e retorna a resposta.

3.2 PROTOCOLO DE COMUNICAÇÃO DO MÓDULO GPRS E SERVIDOR OPC

Este protocolo não segue nenhum padrão de protocolo existente no mercado, ou seja,

ele foi criado especificamente para este trabalho. Neste protocolo, tanto o servidor OPC como

o módulo GPRS podem iniciar uma comunicação. Esta comunicação é sempre realizada

através de mensagens de comando que podem ou não gerar uma mensagem de resposta,

dependendo apenas do tipo do comando. Os comandos não se limitam apenas a ações de

leitura ou escrita, ou seja, um comando pode ter qualquer tipo de ação no módulo GPRS,

como no servidor OPC.

A troca de dados no protocolo é através de caracteres da tabela ASCII, ou seja, o

número 109 decimal, é transmitido através dos caracteres “1”, “0” e “9” da tabela ASCII.

33

A estrutura do pacote de comunicação do protocolo é mostrada nas tabelas abaixo. A

estrutura é diferente para mensagens de comando e mensagens de resposta ao comando.

RQ <cmd> = <p1> , <pn> #

QUADRO 2 - PROTOCOLO DE COMUNICAÇÃO (COMANDO)


RP <cmd> = <p1> , <p2> , <pn> #

QUADRO 3 - PROTOCOLO DE COMUNICAÇÃO (RESPOSTA AO COMANDO)


Os caracteres que estão entre < > são caracteres editáveis que caracterizam o comando

ou a resposta ao comando, e o restante dos caracteres são caracteres delimitadores. Abaixo

estão descritos cada um dos caracteres da mensagem de comando, e em seguida, a descrição

de cada um dos caracteres da mensagem de resposta ao comando:

RQ Sinaliza o início do comando

<cmd> Código do comando

= Separa o código do comando dos parâmetros do comando

<p1 - pn> Parâmetros do comando

, Separa um parâmetro do outro

# Sinaliza o fim do comando

QUADRO 4 - DESCRIÇÃO DOS CARACTERES DA MENSAGEM DE COMANDO


Um exemplo de mensagem de comando é RQ800=100,4#. Onde 800 é o código do

comando, e 100 e 4 são os parâmetros deste comando.

Os parâmetros podem não existir em um determinado comando, e neste caso o caractere

“=” também não é colocado. Por exemplo: RQ400#.

34

RP Sinaliza o início da resposta

<cmd> Repete o código do comando que foi executado

= Separa o código do comando dos parâmetros da resposta

<p1> Resultado do comando (1 = sucesso / 0 = erro)

<p2 - pn> Parâmetros de resposta referentes ao comando executado

, Separa um parâmetro do outro

# Sinaliza o fim do comando

QUADRO 5 - DESCRIÇÃO DOS CARACTERES DA MENSAGEM DE RESPOSTA


A mensagem de resposta para o comando RQ800=100,4# é RP800=1,10#. Onde 800 é o

código do comando que foi executado, 1 indica que o comando foi executado com sucesso e

10 é um parâmetro de resposta.

Quando a resposta não possui parâmetros, a mensagem de resposta apenas sinaliza se o

comando foi executado com sucesso ou ocorreu algum erro. Por exemplo: RP400=1#.

As mensagens de comando do tipo leitura podem assumir a ação de escrita bastando

adicionar mais um parâmetro no final do comando, com o valor a ser escrito. Por exemplo, o

comando RQ500=10# tem a ação de ler o endereço 10 de um dispositivo qualquer. Para

escrever o valor 456 neste endereço 10 o comando seria RQ500=10,456#.

A estrutura adotada para o protocolo visa tornar o sistema flexível as diversas situações

que podem ser encontradas com o decorrer do tempo. Encontrando uma situação que o

sistema não atenda, basta criar um novo código de comando e desenvolver as rotinas

necessárias.

Para este trabalho estão disponíveis os comandos:

Comando Descrição do comando

RQ200 Comunicação MODBUS RTU pela serial RS232 do módulo GPRS

RQ300 Leitura das entradas digitais e analógicas, e escrita nas saídas digitais do módulo

GPRS

QUADRO 6 - COMANDOS DISPONÍVEIS NO SISTEMA


35

Segue detalhes dos comandos:

RQ200 - Comunicação MODBUS RTU pela serial RS232 do módulo GPRS:

Com este comando é possível comunicar o módulo GPRS com qualquer dispositivo que

disponibilize a comunicação MODBUS RTU através de uma serial RS232. O módulo GPRS é

o mestre e o dispositivo é o escravo na rede MODBUS.

A mensagem de comando é RQ200=<p1>,<p2>,<p3>,<p4>#, onde:

<p1> = Endereço do dispositivo escravo

<p2> = Tipo de leitura/escrita (0 = Digital output coil / 1 = Digital input coil / 2 =

Analog input register / 3 = Analog output register)

<p3> = Endereço do registro para leitura/escrita

<p4> = (Parâmetro opcional) Valor a ser escrito no registro. Se for colocado, o

comando será de escrita

A mensagem de resposta ao comando é RP200=<p1>,<p2>#, onde:

<p1> = Resultado do comando (1 = sucesso / 0 = erro)

<p2> = Valor do registro (Quando p1 = 1 e o comando for de leitura) ou descrição do

erro (Quando p1 = 0)

RQ300 - Leitura das entradas digitais e analógicas, e escrita nas saídas digitais do

módulo GPRS:

Com este comando é possível ler e escrever nas entradas e saídas do módulo.

A mensagem de comando é RQ300=<p1>,<p2>#, onde:

<p1> = Endereço da entrada ou saída do módulo GPRS

<p2> = (Parâmetro opcional) Valor a ser escrito na saída do módulo. Se for colocado, o

comando será de escrita

A mensagem de resposta ao comando é RP300=<p1>,<p2>#, onde:

<p1> = Resultado do comando (1 = sucesso / 0 = erro)

<p2> = Valor do registro (Quando p1 = 1 e o comando for de leitura) ou descrição do

erro (Quando p1 = 0)

36

3.3 SERVIDOR OPC DA 3.0

A OPC Foundation além de fornecer toda documentação referente a especificação OPC

DA 3.0, também fornece um projeto de servidor OPC chamado OPC DA Sample Server. O

projeto utiliza a linguagem de programação C++ e o ambiente de desenvolvimento é o Visual

Studio 2005, da Microsoft. Nesse projeto já estão desenvolvidas as funções requeridas pela

tecnologia COM/DCOM, interfaces e funções da especificação, e um sistema de cache

também já está desenvolvido. O trabalho em questão foi adaptar o projeto de servidor OPC

fornecido pela OPC Foundation, para o módulo GPRS.

Para se entender as adaptações realizadas no projeto, primeiramente será mostrada a

estrutura original do projeto e como ela funciona.

37

Cliente OPC DA

Servidor

Grupo Grupo

Item

‘A’

Item

‘B’

Item

‘B’

Item

‘A’

Item

‘C’

Cliente OPC DA

Servidor

Grupo

Item

‘A’

Item

‘B’

Cache

SERVIDOR OPC DA

ITEMID

‘A’

ITEMID

‘B’

ITEMID

‘C’

Dispositivo

Módulo GPRS Módulo GPRS

FIGURA 12 - ESTRUTURA DO SERVIDOR OPC DA (ORIGINAL)


Quando um cliente OPC conecta-se no servidor OPC, é criado um objeto servidor para

cada cliente conectado. O objeto cache e o objeto dispositivo também são criados quando um

cliente conecta-se ao servidor, porém eles são criados uma única vez no servidor OPC,

independente do número de clientes conectados. O objeto cache será o responsável em manter

o ITEMID com o último valor lido da fonte de dados, e o objeto dispositivo será o

responsável pela leitura/escrita dos valores no dispositivo físico conectado ao servidor OPC.

38

Quando o cliente cria um grupo, através do objeto servidor, e adiciona itens a este

grupo, no objeto cache é verificado se o ITEMID relacionado ao item já esta criado no cache.

Caso ainda não exista este ITEMID no cache, neste momento ele é criado.

Na Figura 12, nota-se, que os objetos servidor, grupo e item são acessíveis apenas ao

cliente que os criou, e o objeto cache é acessível a todos os clientes.

Após toda esta estrutura montada, os clientes poderão ler/escrever nos itens. Nestas

operações os seguintes acessos a objetos são realizados (Figura 13):

39

Cliente OPC DA

Servidor

Grupo Grupo

Item

‘A’

Item

‘B’

Item

‘B’

Item

‘A’

Item

‘C’

Cliente OPC DA

Servidor

Grupo

Item

‘A’

Item

‘B’

Cache

SERVIDOR OPC DA

ITEMID

‘A’

ITEMID

‘B’

ITEMID

‘C’

Dispositivo


12

34

56

FIGURA 13 - OBJETOS ACESSADOS NA LEITURA/ESCRITA DE ITENS OPC DA


1. Cliente requisita leitura/escrita dos itens através de alguma função da interface do objeto

Grupo;

2. Objeto Grupo acessa o objeto Item;

3. Objeto Item acessa o objeto Cache;

4. Objeto Cache acessa o objeto ITEMID;

5. Objeto ITEMID acessa o objeto Dispositivo;

40

6. Objeto Dispositivo faz o acesso físico a fonte de dados.

Os acessos mostrados acima ocorrem tanto nas operações síncronas como nas

assíncronas. A diferença é que na síncrona o cliente fica esperando acontecer todos estes

acessos aos objetos, e na assíncrona o cliente faz a requisição e é imediatamente liberado, e

após o servidor acessar os objetos, ele retorna os valores para o cliente.

No objeto ITEMID ocorre a decisão se o valor que será retornado para o cliente será o

que está armazenado no cache, ou se o valor será lido da fonte dados. Esta decisão é baseada

em parâmetros que o cliente passa através das funções de leitura disponíveis na interface.

E a terceira forma de leitura, que são as atualizações enviadas pelo servidor para o

cliente, ocorre através de uma thread que verifica somente grupos e itens ativos, através de

uma taxa de atualização determinada pelo cliente. A taxa de atualização é determinada para o

grupo, ou seja, o cliente define que determinado grupo o atualizará, por exemplo, de 10 em

10s. E quando a thread constata que o grupo deve ser atualizado, ela percorre todos os itens

do grupo e utiliza a função de leitura síncrona disponível no próprio grupo para atualização

dos itens. Os seguintes acessos a objetos ocorrem neste tipo de leitura:

41

Cliente OPC DA

Servidor

Grupo Grupo

Item

‘A’

Item

‘B’

Item

‘B’

Item

‘A’

Item

‘C’

Cliente OPC DA

Servidor

Grupo

Item

‘A’

Item

‘B’

Cache

SERVIDOR OPC DA

ITEMID

‘A’

ITEMID

‘B’

ITEMID

‘C’

Dispositivo


1

23

45

6

Thread

FIGURA 14 - OBJETOS ACESSADOS NA LEITURA AUTOMÁTICA DE ITENS OPC DA


1. A thread requisita leitura síncrona dos itens através do objeto Grupo;

2. Objeto Grupo acessa o objeto Item;

3. Objeto Item acessa o objeto Cache;

4. Objeto Cache acessa o objeto ITEMID;

5. Objeto ITEMID acessa o objeto Dispositivo;

6. Objeto Dispositivo faz o acesso físico a fonte de dados.

42

Para este caso, no objeto ITEMID o valor sempre será lido da fonte dados. No objeto

item verifica-se se o valor lido está dentro da banda morta, definida pelo cliente. Para isto

compara-se o valor lido com o valor armazenado no objeto ITEMID. O objeto ITEMID é

sempre atualizado com o valor lido, porém o item não será sinalizado, para posterior envio,

caso o valor lido esteja dentro da banda morta. Após terem sido atualizados todos os itens

com os valores da fonte de dados, aqueles itens que possuem as sinalizações de atualização,

mencionadas acima, são enviados de uma única vez para o cliente.

Após o estudo, descrito acima, do funcionamento do projeto servidor OPC fornecido

pela OPC Foundation, a 1ª tarefa realizada para adaptação do servidor OPC para o módulo

GPRS foi definir como seria a sintaxe do ITEMID. A sintaxe definida foi a seguinte:

<identificação do módulo GPRS> / <mensagem de comando para o módulo GPRS>

QUADRO 7 - SINTAXE DO ITEMID


Através do texto do 1º parâmentro, o servidor sabe para qual módulo GPRS ele deve

enviar a mensagem de comando. A mensagem de comando defini o que o módulo GPRS deve

fazer para obter um determinado valor da fonte de dados. E o caractere “/” separa um

parâmetro do outro. Por exemplo, o ITEMID abaixo:

GPRS_A/RQ200=5,2,10

Quando o servidor OPC precisar que este ITEMID seja atualizado, ele enviará uma

mensagem de comando RQ200=5,2,10 para o módulo GPRS_A. O comando será executado

no módulo, e uma resposta será enviada para o servidor OPC, que terá o valor lido da fonte de

dados. E quando for necessário escrever um valor na fonte dados, o servidor OPC apenas

colocará na mensagem de comando mais um parâmetro, que é o valor a ser escrito. Por

exemplo, o ITEMID abaixo, onde o valor 200 será escrito na fonte de dados:

GPRS_A/RQ200=5,2,10,200

Depois de definida a sintaxe do ITEMID, as rotinas de comunicação TCP com o

módulo GPRS foram desenvolvidas no objeto dispositivo. Em seguida a estrutura do projeto

43

original foi modifica, de modo que cada módulo GPRS conectado ao servidor OPC terá seu

próprio objeto dispositivo. Para isto, foi retirada a criação do objeto dispositivo quando o

cliente conecta-se ao servidor OPC, e desenvolvida uma rotina que cria o objeto dispositivo

somente quando o objeto ITEMID requisitar leitura/escrita em um módulo GPRS que ainda

não tenha o objeto dispositivo criado para ele.

Com a modificação, a estrutura do servidor OPC ficou da seguinte forma:

Cliente OPC DA

Servidor

Grupo Grupo

Item

‘A’

Item

‘B’

Item

‘B’

Item

‘A’

Item

‘C’

Cliente OPC DA

Servidor

Grupo

Item

‘A’

Item

‘D’

Cache

SERVIDOR OPC DA

ITEMID

‘A’

ITEMID

‘B’

ITEMID

‘C’

Dispositivo

Módulo GPRS A Módulo GPRS B

ITEMID

‘D’

Dispositivo

‘A’ = GPRS_A/RQ200=5,2,10

‘B’ = GPRS_A/RQ200=5,2,25

‘C’ = GPRS_B/RQ200=5,2,5

‘D’ = GPRS_B/RQ200=5,2,10

FIGURA 15 - ESTRUTURA DO SERVIDOR OPC DA (MODIFICADO)


44

Mudou-se também o modo de funcionamento da thread que atualiza de forma periódica

os clientes. No projeto original existe uma rotina dentro da thread que varre todos os grupos e

todos os itens do servidor OPC de 100 em 100ms, ou seja, o servidor OPC possui resolução

de 100ms para atualizações realizadas por ele. Assim, a cada 100ms o contador que define a

base de tempo do servidor OPC é incrementado. Quando a thread constata que o grupo deve

ser atualizado, ela percorre todos os itens do grupo e utiliza a função de leitura síncrona para

atualização dos itens. Com isto, a rotina dentro da thread fica travada até que todos os itens

do grupo sejam atualizados. Caso a leitura de um grupo ocorra em mais de 100ms, a base de

tempo do servidor OPC começa a ficar defasada no tempo, pois ela não é incrementada no

tempo certo, que é de 100 em 100ms. O projeto original funciona bem quando a comunicação

com a fonte de dados é rápida, e este não é o caso da comunicação GPRS.

Com a mudança, a thread não ficará mais travada quando for necessário ler itens de um

grupo. Ela apenas informará o respectivo objeto dispositivo que o item deve ser atualizado.

No objeto dispositivo foi desenvolvido um buffer que armazena os ITEMID que devem ser

lidos da fonte de dados. A cada um dos ITEMID, no buffer, estão associados itens que

requisitaram leitura. O buffer é do tipo FIFO (Primeiro a entrar primeiro a sair), e assim, o

primeiro ITEMID que foi adicionado no buffer, será o primeiro a ser lido da fonte de dados.

Quando o objeto dispositivo receber o valor da fonte de dados, o objeto ITEMID e os objetos

itens serão atualizados e os clientes serão notificados caso necessário.

Além de resolver o problema da defasagem da base de tempo do servidor OPC, esta

modificação também melhorou o desempenho do servidor, pois enquanto um ITEMID está no

buffer aguardando acesso a fonte de dados, a thread que monitora os grupos e itens está em

pleno funcionamento. E caso, seja necessário atualização de um item que já possua o ITEMID

no buffer do objeto dispositivo, o item é apenas associado a este ITEMID. Não sendo

necessário mais que um acesso a fonte de dados para o mesmo ITEMID.

45

4 TESTES REALIZADOS

A seguinte estrutura foi montada para realização dos testes (Figura 16):

Módulo GPRS

RS232

Escravo MODBUS

INTERNET

Operadora Telefonia

Móvel GSM

Servidor e Cliente OPC DA

FIGURA 16 - ESTRUTURA PARA REALIZAÇÃO DE TESTES


Foram colocados dois computadores na Figura 16 apenas para fins didáticos, mas na

verdade, foi utilizado apenas um computador que exerceu as funções de escravo MODBUS,

servidor OPC DA e cliente OPC DA.

Para a simulação de um CLP conectado ao módulo GPRS, foi utilizado o software

MOD_RSsim, disponível no site www.plcsimulator.org. Este software exerceu a função de

escravo MODBUS, e com ele foi possível testar as funções do protocolo MODBUS

desenvolvidas no módulo GPRS. Na Figura 17 é mostrada a tela deste software.

46

FIGURA 17 – SOFTWARE MODBUS MOD_RSSIM


O servidor OPC DA foi desenvolvido neste trabalho, e o cliente OPC DA utilizado foi o

MatrikonOPC Explorer da empresa Matrikon. Através deste software foi possível conectar-se

ao servidor OPC DA, criar grupos, adicionar itens aos grupos e em seguida ler os registros do

simulador MOD_RSsim, bem como escrever nos seus registros.

47

5 CONCLUSÃO

O padrão OPC DA ajudou em muito o desenvolvimento deste trabalho, pois quando o

padrão foi criado, buscou-se a melhor forma de comunicação de uma aplicação de software,

como por exemplo, um software supervisório, com um equipamento no processo industrial.

Com isto, grande parte do trabalho esteve em entender o padrão OPC DA e criar um servidor

OPC para o módulo GPRS.

O objetivo geral foi atingido, bem como, os objetivos específicos. Porém cabe ressaltar

que apenas o protocolo de comunicação MODBUS RTU foi desenvolvido para a

comunicação do módulo GPRS com os equipamentos do processo industrial. Porém, pela

maneira que foi desenvolvido o sistema, qualquer protocolo de comunicação poderá ser

desenvolvido no módulo GPRS, sem a necessidade de alterações no restante do sistema.

Algumas dificuldades poderão ser encontradas na implantação deste sistema em um

processo industrial. O módulo GPRS poderá não ser compatível com a interface do

equipamento, porém, isto poderá ser resolvido através de um conversor de interface. O

módulo GPRS poderá também não suportar o protocolo disponível no equipamento, e com

isto, será necessário o desenvolvimento do protocolo no módulo GPRS. Outro fator

determinante é que o processo industrial tem que estar dentro da área de abrangência do sinal

de telefonia celular utilizado pelo módulo GPRS.

Uma das vantagens em se utilizar um sistema de telemetria para supervisão de um

processo industrial, ao invés de utilizar algum tipo de cabeamento, é com relação a fácil

implantação do sistema, pois a estrutura da comunicação utilizada no sistema, e que no caso é

a comunicação GPRS fornecida pelas operadoras de telefonia celular, já esta toda montada e

em pleno funcionamento. Outra vantagem é a mobilidade necessária em algumas situações, e

que seria impraticável utilizando-se de cabos.

5.1 TRABALHOS FUTUROS

Algumas alterações poderão ser feitas no sistema para melhorar seu funcionamento e

torná-lo mais robusto. Seguem elas:

48

O comando RQ200 (Comunicação MODBUS RTU pela serial RS232 do módulo

GPRS) lê apenas um registro por vez do dispositivo escravo MODBUS. O protocolo

MODBUS permite que sejam feitas n leituras de uma única vez. Bastando para isto, informar

o registro inicial e a quantidade de registros que deverão ser lidos. O módulo GPRS já possui

as rotinas com esta funcionalidade do protocolo MODBUS, porém é necessário ajustar o

servidor OPC para que ele opte por usar esta funcionalidade quando vários registros devem

ser lidos em um determinado tempo e eles estão próximos uns dos outros. Esta modificação

melhorará bastante o desempenho do comando, e conseqüentemente do sistema como um

todo.

Um novo comando pode ser criado para reduzir o volume de dados trafegados entre o

módulo GPRS e o servidor OPC. Ao invés da comunicação ser realizada por polling, pode-se

criar um novo comando que a comunicação seja realizada por interrupção. Onde, o módulo

GPRS irá monitorar os valores de entrada de dados e quando ocorrer alterações significativas

ou valores que ultrapassem limites predefinidos, o servidor OPC é atualizado com o novo

valor.

Terá que ser criada algum tipo de segurança para troca de mensagens entre o servidor

OPC com o módulo GPRS, pois esta comunicação é baseada na internet, e com isto, poderá

ser manipulada por pessoas má intencionadas.

49

REFERÊNCIAS

MACÁRIO, Adriano. Monitoramento e comunicação via satélite, wireless e RFID. Intech

Brasil. n. 76, p. 21-27, nov. 2005.

OPC Foundation. OPC Overview Version 1.0, October 27, 1998.

SANTOS, V.; ZAMBERLAN, M. C. - Projeto Ergonômico de Salas de Controle. Ed.

Fundación Mapfre/ Sucursal Brasil, 1995

SEIXAS FILHO, Constantino. A produção em foco. In: Scantech News, Rio de Janeiro,

set.99, p. 26-30.

SILVA, Ana Paula da; SALVADOR, Marcelo. O que são sistemas Supervisórios? Artigo

atualizado em 13/10/2008. Disponível em: <http://kb.elipse.com.br/pt-br>. Acesso em 08 set.

2009.

tem que ler

Documents