metodologia de pesquisa -...
Post on 11-Nov-2018
224 Views
Preview:
TRANSCRIPT
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
JOSÉ OMAR ABDO FILHO
PROPOSTA DE UM SISTEMA DE TELEMETRIA PARA
APLICAÇÃO EM PROCESSO INDUSTRIAL
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
JOSÉ OMAR ABDO FILHO
PROPOSTA DE UM SISTEMA DE TELEMETRIA PARA
APLICAÇÃO EM PROCESSO INDUSTRIAL
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
Universidade Tecnológica Federal do
Paraná
Prof. Dr. Flávio Neves Junior
Universidade Tecnológica Federal do
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.
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
FONTE: Autoria própria
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
FONTE: Autoria própria
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
FONTE: Autoria própria
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.
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
FONTE: Autoria própria
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
FONTE: Autoria própria
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)
FONTE: Autoria própria
RP <cmd> = <p1> , <p2> , <pn> #
QUADRO 3 - PROTOCOLO DE COMUNICAÇÃO (RESPOSTA AO COMANDO)
FONTE: Autoria própria
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
FONTE: Autoria própria
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
FONTE: Autoria própria
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
FONTE: Autoria própria
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)
FONTE: Autoria própria
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
Módulo GPRS Módulo GPRS
12
34
56
FIGURA 13 - OBJETOS ACESSADOS NA LEITURA/ESCRITA DE ITENS OPC DA
FONTE: Autoria própria
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
Módulo GPRS Módulo GPRS
1
23
45
6
Thread
FIGURA 14 - OBJETOS ACESSADOS NA LEITURA AUTOMÁTICA DE ITENS OPC DA
FONTE: Autoria própria
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
FONTE: Autoria própria
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)
FONTE: Autoria própria
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
FONTE: Autoria própria
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
FONTE: Autoria própria
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.
top related