Você está na página 1de 12

VI Seminrio de Automao de Processos

Comunicao OPC Uma abordagem prtica

Marcos de Oliveira Fonseca 1


Resumo
A comunicao entre os dispositivos de cho de fbrica e os sistemas de automao e
informao j podem se beneficiar do padro OPC (OLE for Process Control). Este foi
desenvolvido para permitir que os sistemas de controle possam fazer uso das tecnologias
desenvolvidas pela Microsoft para a plataforma WINTEL. Entretanto, a utilizao do
padro apresenta algumas caractersticas que devem ser observadas para a sua
aplicao prtica. Estas caractersticas so fundamentais para a sua perfeita utilizao e
para garantir o desempenho da comunicao. Este trabalho descreve o padro OPC sob
o ponto de vista prtico e apresenta algumas orientaes para a utilizao dos recursos
proporcionados pelo mesmo. So apresentados tambm, os resultados obtidos pela
comunicao OPC para o sistema de automao da Aciaria da Aominas, em Ouro
Branco MG, desenvolvido pela ATAN Sistemas.
Palavras-chave: Padro OPC, Comunicao, Automao.

VI Seminrio de Automao de Processos, Associao Brasileira de Metalurgia e


Materiais, 9-10 de outubro de 2002 Vitria ES, Brasil.
1
Engenheiro Eletricista, M.Sc, Gerente do Departamento de Automao Industrial da
ATAN Sistemas, Belo Horizonte MG, Brasil.

41

VI Seminrio de Automao de Processos

1.

Introduo ao Padro OPC

Em 1995, algumas empresas se reuniram com o objetivo de desenvolver um padro


baseado na tecnologia OLE/DCOM para acesso dados de tempo real dentro do sistema
operacional Windows. Neste trabalho foram envolvidos membros da Microsoft para
suporte tcnico soluo a ser adotada. Este grupo sem fins lucrativos formado por
diversas empresas e gerenciado pela organizao OPC Foundation, a qual possui um
site na Internet (www.opcfoundation.org). Basicamente, o padro OPC estabelece as
regras para que sejam desenvolvidos sistemas com interfaces padres para comunicao
dos dispositivos de campo (CLPs, sensores, balanas, etc.) com sistemas de
monitorao, superviso e gerenciamento (SCADA, MES, ERP, etc.). A Figura 1
apresenta uma resumo das tecnologias OLE e DCOM.
OLE
A tecnologia OLE (Object Linking and Embedding) foi desenvolvida pela Microsoft em
meados de 1990, para suprir a necessidade de se integrar diferentes aplic aes dentro da
plataforma Windows, de forma a solucionar os problemas de desempenho e confiabilidade do
at ento utilizado padro DDE (Dynamic Data E xchange).
DCOM
Como uma continuao da tecnologia OLE, o DCOM (Distribuited Component Object Model)
surgiu junto com o sistema operacional Windows NT e foi logo aceito pela indstria.
Basicamente, o DCOM um conjunto de definies para permitir a implementao de
aplicaes distribudas em uma arquitetura clente-servidor. Desta forma, um cliente pode
acessar diferentes serv idores ao mesmo tempo e um servidor pode disponibilizar suas
funcionalidades para diferentes clientes ao mesmo tempo.
Atravs da definio de interfaces, o DCOM permite que objetos sejam instanciados de forma
distribuda e seus servios e mtodos (fu nes) sejam acessveis por diferentes programas.
Para isso necessrio a utilizao de uma linguagem especial, a IDL (Interface Definition
Language). Isto significa que cada cliente pode chamar os mtodos de qua lquer objeto DCOM
em um determinado servidor, independentemente do ambiente de programao (linguagem,
compilador, verso, etc.) que os mesmos foram criados. Atravs de um identificador nico
(GUID, Global Unique Identifier), as interfaces so pr otegidas contra modificaes aps a sua
public ao e a compatibilidade dos objetos DCOM ento garantida.
Os objetos DCOM existem nos servidores DCOM. A forma de implementao dos servidores
(DLL EXE, InProcess e OutProcess) determina como os objetos so carregados e gerenciados
pelo servidor. Os objetos DCOM so acessveis atravs de uma identific ao CLSID (Class
Identifier) mantida pela Registry do sistema operacional. Atravs da CLSID os clientes podem
lanar os componentes, solicitar as interfaces dos objetos e chamar os mtodos desta interface.
O ciclo de vida de um objeto DCOM controlado pelo prprio componente, de forma que o
mesmo se auto-deleta quando nenhum cliente est utilizando o mesmo, fazendo a liberao
dos recursos do sistema.
Figura 1 Tecnologias Microsoft OLE e DCOM.

A primeira especificao produzida pelo grupo foi publicada em agosto de 1996,


chamada OPC Specification Version 1.0. O principal objetivo do grupo atender s
necessidades da indstria, atravs do aprimoramento e ampliao da especificao OPC.
A estratgia adotada foi a criao de extenses especificao existente, definio da
adio de novas especificaes e a realizao de modificaes para manter a
compatibilidade mxima com as verses existentes. Em setembro de 1997 foi liberada a
primeira atualizao da especificao OPC que passou a ser chamada de OPC Data
Access Specification Version 1.0A.

42

VI Seminrio de Automao de Processos

Atualmente existem as seguintes especificaes publicadas ou em processo de


aprovao:

OPC Overview (Verso 1.00) Descrio geral dos campos de aplicao das
especificaes OPC.
OPC Common Definitions and Interfaces (Verso 1.00) Definio das
funcionalidades bsicas para as demais especificaes.
OPC Data Access Specification (Verso 2.05) Definio da interface para leitura e
escrita de dados de tempo real.
OPC Alarms and Events Specification (Verso 1.02) Definio da interface para
monitorao de eventos.
OPC Historical Data Access Specification (Verso 1.01) Definio da interface
para acesso a dados histricos.
OPC Batch Specification (Verso 2.00) Definio da interface para acesso aos
dados de processos por batelada (batch). Esta especificao uma extenso da OPC
Data Access Specification .
OPC Security Specification (Verso 1.00) Definio da interface para utilizao de
polticas de segurana.
OPC and XML (Verso candidata 1.05) Integrao entre OPC e XML para
aplicaes via Internet (web).
A Figura 2 apresenta uma viso das especificaes do padro.

Figura 2 Especificaes do padro OPC.

As especificaes apresentadas esto em constante desenvolvimento e atualizao,


sendo que as ltimas verses podem ser conseguidas atravs do site da OPC
Foundation. Estas especificaes tm a finalidade de orientar os desenvolvedores para a
implementao das aplicaes cliente e servidor. Em princpio, os usurios finais no
precisam conhecer a fundo as especificaes, sendo suficiente conhecer os aspectos
prticos para utilizao do padro, os quais so abordados neste trabalho.
Est em fase de elaborao a especificao OPC DX Data Exchange for Ethernet. Esta
especificao tem a finalidade de definir a comunicao entre diferentes servidores
conectados atravs de uma rede Ethernet TCP/IP. At ento, esta comunicao no
possvel sem a utilizao de um cliente e uma aplicao para intermediar a troca de
dados.

43

VI Seminrio de Automao de Processos

As especificaes apresentadas neste trabalho se referem s interfaces do tipo custom.


Estas interfaces definem o acesso aos servidores OPC por aplicaes clientes
desenvolvidas atravs de linguagens que suportam as chamadas das funes por
ponteiros, tais como C/C++, Delphi, etc.
Entretanto, existem linguagens tais como Visual Basic e VBA que no suportam ponteiros
para funes. Neste caso foi introduzido o conceito da interface tipo automation. Atravs
da interface tipo automation, os clientes desenvolvidos nestas linguagens podem fazer
uso de uma interface padro onde os mtodos so chamados pelo nome e no por
ponteiros. Existem portanto, especificaes OPC separadas para interfaces do tipo
custom e automation. A Figura 3 apresenta estas interfaces.

Figura 3 Interfaces Custom e Automation.

A publicao das especificaes para o padro OPC possibilitou o desenvolvimento de


diversos produtos para automao industrial, os quais se beneficiam das vantagens
proporcionadas pelo padro:
Padronizao das interfaces de comunicao entre os servidores e clientes de dados
de tempo real, facilitando a integrao e manuteno dos sistemas.
Eliminao da necessidade de drivers de comunicao especficos (proprietrios);
Melhoria do desempenho e otimizao da comunicao entre dispositivos de
autom ao.
Interoperabilidade entre sistemas de diversos fabricantes;
Integrao com sistemas MES, ERP e aplicaes windows (Excel, etc.);
Reduo dos custos e tempo para desenvolvimento de interfaces e drivers de
comunicao, com conseqente reduo do custo de integrao de sistemas.
Facilidade de desenvolvimento e manuteno de sistemas e produtos para
comunicao em tempo real;
Facilidade de treinamento.
Atualmente existem diversos produtos no mercado que utilizam o OPC para
comunicao com dispositivos de cho de fbrica. O OPC est se tornando rapidamente
o padro de comunicao adotado pelo mercado de automao industrial e pela indstria.
2.

Aspectos prticos para utilizao do p adro OPC

Para a especificao e utilizao do padro OPC, o usurio precisa estar ciente de


alguns pontos chaves para o perfeito entendimento de como se beneficiar do uso da
comunicao OPC. Para isso, o estudo das especificaes torna-se um processo difcil,
uma vez que as mesmas so direcionadas para desenvolvedores e programadores,
sendo necessrio o conhecimento prvio de linguagens e ambientes de desenvolvimento.
Para simplificar o entendimento do padro OPC, estes pontos so apresentados a seguir.

44

VI Seminrio de Automao de Processos

Plataforma Windows ou no ?
Basicamente, o padro OPC nativo da plataforma Windows. Dentro desta plataforma,
existem variaes para as verses do Windows (CE, 9X, NT, 2000 e XP), mas para todas
estas possvel a comunicao OPC. Para plataformas no-Windows, existem alguma
solues que consistem em portar o DCOM para estas plataformas. No futuro, a
especificao OPC para XML dever facilitar a integrao de plataformas no-Windows
para a comunicao OPC.
Cliente ou Servidor OPC ?
As aplicaes e produtos existentes no mercado podem ser somente um cliente, um
servidor ou ambos, isto varia de caso a caso. Normalmente, os produtos para
monitorao de dados (IHMs; sistemas supervisrios, etc.) so clientes OPC. J os
produtos que fazem a comunicao direta com os dispositivos de campo utilizando
protocolos proprietrios so servidores OPC. Cada produto pode incorporar as duas
funcionalidades, sendo o mais comum que uma aplicao normalmente cliente possa ser
servidor, e no o contrrio.
Nmero de Clientes x Nmero de Servidores
O nmero de servidores OPC necessrios para uma determinada aplicao ir
depender do produto a ser utilizado. Normalmente, os fabricantes de dispositivos de
campo (CLPs; dispositivos inteligentes, etc.) fornecem um servidor OPC capaz de
comunicar com todos os protocolos dos seus produtos de linha. Este servidor um
software para o ambiente Windows que executado em um microcomputador,
normalmente PC. Ou seja, um servidor OPC da Rockwell, o RSLinx por exemplo, permite
que diversos drivers de comunicao sejam configurados para as diversas redes
(ControlNet, DeviceNet, Ethernet, DH+, etc.). Neste caso, o RSLinx funciona como um
nico servidor OPC, capaz de comunicar com diversos clientes OPC sendo executados
na mesma mquina ou em mquinas remotas.
Existem servidores OPC de terceiros que permitem que sejam configurados drivers de
comunicao para diversas redes e protocolos de diferentes fabricantes. Como exemplo
podemos citar os servidores da Kepware e da Matrikon. Neste caso, um nico produto
poder servir dados de diferentes fabricantes.
Cada cliente OPC pode conectar-se diferentes servidores, os quais podem estar
processando na mesma mquina ou remotamente em mquinas diferentes. Portanto,
qualquer produto que funcione como cliente OPC poder se comunicar com quaisquer
servidores OPC de quaisquer fabricantes.
Formato de Dados OPC (Time Stamp e Qualidade)
Pela especificao do padro, todo servidor de dados deve enviar o dado OPC no
formato apresentado a seguir:
- Valor do dado: Todos os tipos de dados VARIANT definidos pela interface DCOM so
suportados.
- Time Stamp: Esta informao fornecida pelo servidor atravs da leitura do time
stamp dos dispositivos de campo ou por gerao interna. utilizada a estrutura padro do
Windows para o UTC (Universal Time Coordinated ).

45

VI Seminrio de Automao de Processos

- Informao de estado: So reservados 2 bytes para codificao do estado do dado


fornecido pelo servidor. Por enquanto, apenas o uso do byte menos significativo foi
definido. Dois bits definem a qualidade do dado que pode ser:
Good Dado vlido;
Bad No caso de perda do link de comunicao com o dispositivo de campo, por
exemplo;
Uncertain

No caso de existir o link de comunicao mas o dispositivo de campo


estiver fora de operao.
Quatro bits fornecem um detalhamento do estado apresentado, tais como Not
Connected e Last Usable Value . Os ltimos dois bits podem conter dados de diagnstico
no caso de falha de um sensor, por exemplo.
Configurao dos dados OPC no Cliente
Normalmente, os produtos de mercado no permitem muita flexibilidade para a
configurao dos dados solicitados pelo cliente. Isto se deve basicamente preservao
da cultura anterior para os drivers de comunicao especficos. Entretanto, isto pode ser
uma armadilha para os usurios.
Considerando o caso mais comum que consiste nos servidores de dados OPC (OPC
Data Access), os clientes podem definir basicamente as seguintes configuraes:
Criao de grupos e itens OPC: Basicamente, todos os dados OPC so chamados de
itens. Cada item pode ser de um tipo diferente de dado compatvel com a especificao
OPC. Os diversos itens so organizados em grupos OPC, os quais definem as principais
caractersticas de leitura dos itens (Taxa de Atualizao, Estado Ativo/Inativo, Banda
Morta, Leitura Sncrona/Assncrona).
Leitura Sncrona ou Assncrona: Para um determinado grupo OPC pode ser definido
se a leitura dos dados feita de forma sncrona, a qual depende de uma confirmao de
execuo antes de uma nova leitura, ou assncrona, a qual no depende da confirmao.
Normalmente utilizada a leitura assncrona, a qual garante um melhor desempenho.
Leitura de dados direto do dispositivo: A partir da verso 2.0 da especificao para o
servidor de dados, possvel fazer a seleo no cliente OPC para leitura dos dados da
memria cache do servidor ou diretamente do dispositivo de campo.
Estado Ativo/Inativo: Cada item ou grupo pode ter o seu estado alterado pelo cliente
para Ativo, habilitando a comunicao do mesmo, ou Inativo.
Leitura Cclica ou por Mudana de Estado: O cliente OPC pode definir se os dados
do servidor sero lidos de forma cclica ou por mudana (transio) de estado. Na leitura
cclica, o cliente faz a requisio de leitura regularmente, independentemente se os dados
sofreram alterao de valor ou no. No caso de leitura por mudana de estado, o servidor
fica responsvel por enviar para os clientes os itens que sofrerem alterao de seu
estado (Qualidade do dado) ou quando os valores dos itens de um determinado grupo
ultrapassarem o valor da banda morta.
Banda Morta: utilizada para definir os valores limites de transio para os itens de
um determinado grupo, para os quais o servidor far o envio para os clientes quando a
alterao dos valores dos itens estiver fora da banda especificada.
A Figura 4 apresenta a estrutura dos objetos para a comunicao OPC.

46

VI Seminrio de Automao de Processos

Figura 4 Estrutura interna dos objetos do padro OPC.

Escrita de dados OPC


A escrita de dados OPC funciona de forma independente da leitura. Assim como na
leitura, a escrita pode ser sncrona ou assncrona. Entretanto, os comandos de escrita so
executados imediatamente pelo servidor, sendo enviados diretamente para os dispositivos
de campo. Est previsto para a verso 3.0 do servidor de dados, a possibilidade de se
fazer a escrita de dados na memria cache do servidor e depois a transferncia cclica
dos dados para os dispositivos de campo. Este recurso ser muito til para os dispositivos
que dependem de comandos igualmente espaados no tempo, tal como os sistemas de
controle de movimento.
Comunicao de Blocos de Dados
O padro OPC permite a comunicao de blocos de dados (vetores) entre o servidor e
os clientes. Isto representa uma grande otimizao, pois as informaes de time stamp e
estado do dado so tratados e fornecidos apenas uma vez para um conjunto de dados,
reduzindo assim o overhead da comunicao. Neste caso, cada item configurado como
um bloco de dados.
Redundncia com OPC
As especificaes do padro OPC no fazem meno utilizao de servidores
redundantes. Entretanto, cada cliente OPC pode implementar facilmente um mecanismo
para conexo simultnea em mais de um servidor, verificao do estado do servidor e
ativao/desativao dos grupos para o servidor que estiver funcionando. Esta soluo
encontrada apenas em alguns produtos, no sendo regra geral a disponibilizao deste
recurso para a maioria dos produtos de mercado. O produto ORB (OPC Redundancy
Broker) da Matrikon permite que clientes comuns possam fazer o chaveamento para
servidores redundantes.
Desempenho da comunicao OPC
Em linhas gerais, o desempenho da comunicao OPC se aproxima do desempenho
apresentado por sistemas que utilizam drivers de comunicao especficos e otimizados.

47

VI Seminrio de Automao de Processos

Normalmente, os drivers especficos possuem um timo desempenho aps serem


devidamente depurados e otimizados, o que via de regra no acontece em muitos casos.
Como um servidor OPC nada mais do que uma camada de software a mais para
implementar as interfaces padres e os mecanismos de comunicao com o cliente, de
se esperar que o desempenho do mesmo s seja afetado em relao a comunicao com
o cliente e no com o dispositivo de campo. No caso da comunicao com o dispositivo
de campo, cada fornecedor pode implementar o driver e o protocolo que melhor se
ajustem s necessidades do dispositivo e da rede de comunicao. Desta forma, o
desempenho do servidor OPC est mais relacionado capacidade dos recursos de
hardware da mquina que executa a aplicao do servidor do que propriamente do driver
especfico. Como os recursos de hardware esto cada vez mais poderosos em relao
capacidade de processamento, isto no tem se mostrado como um problema real.
Entretanto, o que se tem verificado na prtica que muitos clientes e servidores OPC
no implementam a comunicao de blocos de dados, fazendo a leitura de itens
separadamente, o que ocasiona um grande overhead devido ao tratamento separado de
time stamp e estado do dado para cada item OPC.
Outro ponto importante que muitos clientes OPC no implementam, consiste no
agrupamento de dados que precisam ser lidos sob demanda, tais como animaes de
telas sinpticas, janelas de operao de equipamentos, relatrios, etc. Os dados
necessrios para estes elementos (objetos) de monitorao, normalmente podem ser
lidos sob demanda, de forma que somente quando o objeto estiver selecionado, ser
ativado o grupo OPC no servidor para leitura dos dados. Quando o objeto no estiver
selecionado, o grupo OPC ficar desativado, fazendo com os dados no sejam lidos e
melhorando o desempenho da comunicao.
Segurana para acesso ao sistema
Para a implementao do controle de acesso ao servidor OPC podem ser utilizados
dois mtodos. O mtodo normalmente usado consiste nos mecanismos proporcionados
pelo prprio DCOM, os quais so configurados no Windows NT executando-se o
comando DCOMCNFG. Outra forma menos usual consiste em se utilizar mecanismos
implementados pelo cliente e servidor conforme a especificao do padro OPC.
O controle de acesso fundamental para o caso de acesso remoto e para a
comunicao via Internet prevista com a especificao do OPC com XML.
3.

Resultados obtidos para o Sistema de


Aominas

Automao da Aciaria da

A ATAN Sistemas desenvolveu em parceria com a equipe tcnica da Aominas, todo o


sistema de automao para a Aciaria da Usina Intendente Cmara, localizada em Ouro
Branco M.G.
O sistema de Automao contempla as seguintes reas de processo:
Transporte de matrias primas;
Desgaseificao vcuo (RH);
Convertedores 1 e 2;
Adio de Fundentes;
Adio de Ferro-Ligas;
Ventilao Secundria;
Sistema de gases (BAUMCO);
Pesagem de Gusa;

48

VI Seminrio de Automao de Processos

Pesagem de Sucata;
Sistemas Auxiliares;
Controle de Panelas de Ao e Gusa.
O sistema foi desenvolvido utilizando-se os seguintes produtos e tecnologias:
CLPs Rockwell: ControlLogix, PLC5 e SLC500;
Redes de Controle: ControlNet e DH+;
Rede de aquisio e comunicao: Ethernet 10/100 Mbits/s com protocolo TCP/IP;
Microcomputadores Compaq Pentium III, 500 Mhz, 192 MB RAM;
Sistema operacional Windows NT 4.0;
Servidor OPC RSLinx da Rockwell;
Sistema Supervisrio Wizcon;
Acesso de dados via web utilizando o Wizcon for Internet;
Estao de Clculos desenvolvida em Delphi para o ambiente Windows NT.
Toda a comunicao entre os CLPs e as estaes de superviso e de clculos foi feita
utilizando-se o padro OPC. Para a implementao da comunicao OPC foram
enfrentados algumas dificuldades, tais como:
As primeiras verses dos produtos para comunicao OPC no apresentavam
desempenho satisfatrio e alguns bugs .
Muitas funcionalidades do padro OPC no estavam disponveis nas primeiras
verses dos produtos.
Os clientes OPC no permitiam que fossem configurados os itens OPC de forma a
otimizar a configurao, tais como agrupamento de itens, leitura em blocos, etc.
Os tcnicos envolvidos no projeto possuam pouca experincia com os produtos e
com o padro OPC.
As primeiras verses do servidor e do cliente OPC no faziam uso adequado dos
recursos de hardware, causando principalmente o consumo excessivo de CPU.
Os problemas apresentados acima se deveram principalmente poca de incio do
desenvolvimento, janeiro de 2001. Naquela poca, a comunicao OPC estava
comeando a ser utilizada, sendo poucos os casos prticos e os sistemas de grande porte
que utilizavam produtos comunicando neste padro.
Aps serem identificados os problemas apresentados pela comunicao OPC, os quais
resumiam-se principalmente a bugs de software, consumo de CPU elevado e
incapacidade da leitura de dados em blocos, os fornecedores dos produtos juntamente
com as equipes de desenvolvimento das empresas envolvidas fizeram as correes
necessrias para viabilizar a comunicao OPC.
O sistema foi implantado em julho de 2001, encontrando-se em operao plena desde
ento. Atualmente, a comunicao OPC apresenta os dados de desempenho mostrados a
seguir.
Estao
Convertedor
RH
Transporte
Gusa
Clculos
Sucata

Nmero de Tags por


Taxa de Leitura
500
1s
2s
ms
706
5241
973
901
1080
1053
103
1030
338
712
0
0
0
991
0
26
263
14

Consumo
CPU (%)
10
5
4
1
3
<1

Tabela 1 Desempenho da comunicao OPC por estao.

49

VI Seminrio de Automao de Processos

Conforme pode ser observado na Tabela 1, o volume de dados de cada estao foi
organizado em funo das necessidade de atualizao de cada dado, definindo-se as
taxas de leitura para atender s exigncias da aplicao. O total de dados e as taxas de
leituras apresentados correspondem situao atual da aplicao. Os dados so
enviados pelo servidor por mudana de estado. Basicamente, todos os servidores esto
executando na mesma mquina do cliente. Somente algumas estaes de monitorao
do sistema de superviso fazem o acesso remoto, atravs do servidor OPC RSLinx. O
consumo de CPU apresentado para o servidor OPC corresponde condio normal de
operao. Estes resultados poderiam ser ainda melhores, caso fosse possvel
implementar todas as otimizaes citadas neste trabalho.

Figura 5 Arquitetura bsica do Sistema de Automao da Aciaria da Aominas.

4.

Concluses

A comunicao OPC est adquirindo a maturidade e a estabilidade necessrias para a


sua adoo plena na automao industrial. A constante atualizao e evoluo das
especificaes do padro, juntamente com a aderncia dos fabricantes de produtos,
garantem a adequao do padro s necessidades das indstrias.
Muitas solues de automao que dependem das informaes do cho de fbrica j
utilizam o padro OPC como condio inicial para comunicao de dados. Dentre estas
solues podemos citar os Sistemas SCADA, PIMS (Process Information Management
System), Sistemas Especialistas, Sistemas MES (Manufactoring Execution Systems),
ERP (Enterprise Resource Planning), etc.
O desempenho da comunicao OPC muito dependente da forma como so
implementados os clientes e os servidores, os quais devem permitir que sejam utilizados
todos os recursos proporcionados pelo padro para otimizao da comunicao.
esperado que em pouco tempo a comunicao OPC tenha o seu desempenho muito
prximo ao dos melhores drivers especficos, com a adoo plena do padro e com o
amadurecimento dos produtos disponveis no mercado.
As informaes de time stamp e qualidade de dado agregam valor para a comunicao
OPC, uma vez que muitos sistemas de gerenciamento dependem destas informaes
para a tomada de deciso. Alm disso, existem outras facilidades que contribuem para o
uso do OPC, tal como o recurso de Tag Browser.

50

VI Seminrio de Automao de Processos

As demais especificaes do padro OPC, principalmente as que tratam da


comunicao de alarmes e eventos e dos dados histricos, juntamente com o padro
XML, devem cada vez mais serem utilizadas para agregar funcionalidade s solues de
mercado. Alguns produtos j incorporam estas funcionalidades.
Existe uma tendncia do servidor OPC ser implementado diretamente nos dispositivos
de campo, tais como CLPs e instrumentao inteligente. Alguns produtos da Schneider j
possuem o servidor OPC no prprio mdulo de comunicao do CLP. Esta tendncia
acompanha tambm o crescimento do uso da rede Ethernet no cho de fbrica, fato que
dever acelerar este processo. Os controladores SoftPLC ou SoftLogic e os controladores
hbridos, normalmente j utilizam o padro OPC para comunicao com outros sistemas.
O autor quer agradecer as contribuies dadas pelos profissionais da ATAN Sistemas e
da Aominas, as quais foram importantes para enriquecer o contedo e abrangncia
deste trabalho.
Referncias Bibliogrficas
[1] Iwanitz, Frank and Lange, Jrgen. OLE for Process Control Fundamentals,
Implementation and Application, Hthig Verlag Heidelberg, 2001, 200 p.
[2] Fonseca, Marcos. Relatrio sobre Desempenho da Comunicao OPC, documento
de projeto da ATAN Sistemas, 2002.
[3] Chisholm, Al. DCOM, OPC and Performance Issues , Intellution Inc., 1998.
[4] Burke, Thomas J. The Performance and Throughput of OPC A Rockwell Software
Perspective, Rockwell Software Inc., 1998.
[5] Help On-line do software RSLinx OPC Server, verso 2.30.01, Rockwell Software.
[6] Help On-line do software Matrikon OPC Explorer, verso 3.0.4.56, Matrikon
Consulting Inc.
[7] Documentao do site da OPC Foundation: www.opcfoundation.org

51

VI Seminrio de Automao de Processos

OPC Communication Practical issues


Marcos de Oliveira Fonseca 1

Abstract
Data communication between plant floor and automation and information levels is now
under the benefits of OPC (OLE for Process Control) standard. This standard was
developed to provide the advantages of Microsoft technologies under WINTEL platform to
control systems. Nevertheless, the OPC standard needs to be understood correctly to
assure that its main characteristics are used in practical applications. Those characteristics
are fundamental for the correct usage of the standard and to achieve the best performance
for data communication. This paper describes the OPC standard under the practical point
of view and presents some guidelines for the usage of the resources provided for the end
user. Some practical results of the use of OPC communication in the automation system
for the Steel Making Plant in Aominas, Ouro Branco MG are also presented. This
system was developed by ATAN Sistemas.
Keywords: OPC Standard, Communication, Automation.

VI Process Automation Seminar, Associao Brasileira de Metalurgia e Materiais,


October 9-10th, 2002 Vitria ES, Brazil.
1
Electrical Engineer, M.Sc, Industrial Automation Department Manager, ATAN Sistemas,
Belo Horizonte MG, Brazil.

52