O Padrão de Comunicação OPC e Suas
Características
Ana Clara Ratunde, Matheus Costa Santos e Yago Oliveira Cruz
Resumo – As diferenças que existem entre os
padrões dos protocolos de comunicação sempre
impediram a interoperabilidade de sistemas de
supervisão, automação e controle, entre equipamentos
de diferentes fabricantes. O padrão OPC surgiu para
estabelecer regras para que sejam desenvolvidos
sistemas com interfaces padrões que possibilitem uma
conexão entre plataformas que utilizam diferentes
protocolos. Neste trabalho falaremos sobre as
características e especificações do padrão OPC.
I.
INTRODUÇÃO
Alguns
fornecedores
da
indústria,
desenvolvedores de software e consumidores finais, em
1995, se reuniram com o objetivo de desenvolver um
padrão de comunicação baseado na tecnologia
OLE/DCOM, na tentativa de minimizar os problemas
relacionados à inconsistência dos “drivers” de
equipamentos industriais de diferentes fabricantes,
inicialmente dentro do sistema operacional Windows.
Foram convidados, para que isso ocorresse, membros da
Microsoft para que dessem suporte técnico a esse
desenvolvimento. Surgiu, então, a OPC Foundation, um
grupo sem fins lucrativos que é responsável pelo
desenvolvimento e manutenção das normas desse padrão.
O OPC é um padrão de comunicação aberto, que
tem por principal objetivo permitir a interoperabilidade
vertical entre sistemas dentro de uma organização. OPC é
a sigla para “OLE for Process Control”, onde OLE
significa “Object Linking and Embedding”. Quando foi
lançado pela primeira vez em 1996, o seu objetivo era
transformar protocolos específicos de CLP (como
Modbus, Profibus, etc.) em uma interface padronizada
permitindo que os sistemas HM/SCADA fizessem a
interface "homem-máquina" que iria converter pedidos de
leitura e de gravação em solicitações específicas do
dispositivo. Como resultado, uma indústria inteira de
produtos surgiu, permitindo aos usuários finais
implementar sistemas usando os melhores produtos
interagindo perfeitamente via OPC.
Esse padrão nada mais é que um conjunto
comum de interfaces, métodos e propriedades de
comunicação, agregados dentro de uma especificação
padronizada e aberta para acesso público. Teoricamente
qualquer pessoa com conhecimentos de programação
pode desenvolver seus aplicativos OPC, basta acessar as
especificações contidas no site da OPC Foundation e
desenvolver uma interface compatível.
Ao basear o OPC na tecnologia OLE, nativa do
Windows, este mesmo benefício chegou à área industrial.
Com o surgimento desse padrão os desenvolvedores de
sistemas de automação puderam escrever servidores OPC
para seus equipamentos, e os demais softwares, como
supervisórios, passaram a ser clientes OPC. Desapareceu,
então, a necessidade de se desenvolver inúmeros drivers
de comunicação para integrar os sistemas tradicionais, ou
ainda a necessidade de se usar os equipamentos de um
único fabricante, como mostra a Figura 1. Os
equipamentos dotados de comunicação via OPC
disponibilizam dados internos em uma interface
simplificada, onde aplicações externas podem interagir
com a leitura e/ou escrita de valores em parâmetros,
registradores de programas, resultados, etc.
Figura 1 – Comunicação entre equipamentos de um único fabricante
Estas especificações que, agora são conhecidas
como sendo do “OPC Clássico”, têm desfrutado de uma
grande adoção em vários setores, incluindo automação
predial, petróleo, gás, energia renovável, serviços
públicos, entre outros. Com a introdução de arquiteturas
orientadas a serviços em sistemas de manufatura, vieram
novos desafios em relação à segurança e modelagem de
dados. A OPC Foundation desenvolveu, então, o “OPC
UA (Arquitetura Unificada)” para atender essas
necessidades com uma tecnologia rica em recursos em
uma plataforma de arquitetura aberta, e que é compatível
com o “OPC Clássico”. Dois fatores importantes que
contribuíram para que essa atualização fosse criada foi a
necessidade de manter a competitividade, já que os
usuários OPC precisavam implementar o mesmo em
sistemas que não fossem da Microsoft, e o fato de que
outras organizações colaboradoras precisavam de uma
maneira confiável e eficiente para o transporte de alto
nível de dados estruturados.
A intermediação da comunicação entre aplicação
cliente e equipamento é realizada por um servidor OPC
(OPC Server). Este servidor possui os “drivers” referentes
aos equipamentos suportados, e de acordo com o modelo
configurado, disponibiliza a região de dados específica.
Em uma comunicação com um CLP, por exemplo, é
possível ler ou escrever valores de memórias internas,
utilizadas no programa do usuário, ou até mesmo ler
estado de entradas e saídas. Em câmeras industriais é
possível obter o resultado da aplicação de análise de
imagens, ou mesmo carregar as imagens.
O padrão define distintas formas para se acessar
dados do processo, alarmes e dados históricos. O “OPC
DA” define o acesso de dados, incluindo valores, tempo e
informação de qualidade. O “OPC AE” define o acesso
de informações à alarmes e eventos, bem como o tipo de
evento, os estados das variáveis e o gerenciamento de
estado. O “OPC HDA” define o acesso aos dados
históricos hora datada, bem como seus métodos de
consulta e análises.
II.
LINHA DO TEMPO
Em 1990, os sistemas operacionais da Microsoft
dominaram
a
paisagem
de
automação
industrial. Fornecedores de automação começaram a usar
COM e DCOM em suas ofertas de produtos.
Em 1995, os fornecedores de automação FisherRosemount, Intellution, Opto 22 e Rockwell Software
formaram uma “força-tarefa” para desenvolver um padrão
de acesso a dados com base em COM e DCOM, e deram
o nome de OPC.
Em 1996, a “força-tarefa” lança a versão 1.0 de uma
especificação OPC simplificado para acesso a dados (DA)
em Agosto. Já no primeiro ano, vários outros
fornecedores de software e hardware começaram a usar
OPC como seu mecanismo de interoperabilidade. Logo
fica claro que uma organização mais formal de
conformidade, interoperabilidade, certificação e validação
é necessária. A Fundação OPC é criada no Chicago ISA
Show, em Setembro.
Em 1998, a OPC Foundation começa a conversão de
sua especificação existente para serviços web.
Em 1999, a especificação “OPC Alarmes e Eventos
(OPC AE)” é liberada.
Em 2001, o lote e a especificação de segurança “OPC
Historical Data Access (OPC HDA)”, são liberados.
Em 2003, as especificações “Dados OPC Complex”,
dados do Exchange e “XML-DA” especificações são
lançadas e a “Arquitetura unificada (OPC UA)”,
composta por 13 partes separadas, é criada pela
especificação original. O OPC original agora é referido
como "Classic OPC" ou OPC Clássico.
Em 2004, a especificação de Comandos OPC é
liberada.
Em 2006, a versão 1.0 do “OPC UA “se torna
disponível.
Em 2007, “Programa de Certificação OPC” e “Teste
Labs” são introduzidos. A automação começar a oferecer
os primeiros produtos baseados em “OPC UA”.
Em 2009, a versão 1.01 do “OPC UA” torna-se
disponível. Lançam “OPC UA” para dispositivos
Analyzer (DDA) como uma especificação adjunta,
impulsionada pelas indústrias de fabricação farmacêutica
e química.
Em 2010, os primeiros dispositivos “OPC UA”
embutidos são lançados. “OPC UA” para IEC 61131 é
liberado como uma especificação.
Em 2013, “OPC UA 1,02” é lançado juntamente com
“OPC UA” para o ISA-95. A Fundação OPC dá suporte
para mais de 480 membros em toda a China, Europa,
Japão e América do Norte.
III.
FUNCIONAMENTO
A tecnologia OPC faz parte do “.NET Framework”,
da Microsoft, e baseia-se na especificação COM
(Component Object Model), a mesma tecnologia usada na
plataforma ActiveX, que provêm conectividade e
interoperabilidade entre diferentes aplicações de forma
“plug-and-play”. Estes componentes determinam a
infraestrutura das aplicações compartilhadas sob sistemas
operacionais da Microsoft, como o Windows, abstraindo
as funcionalidades dos sistemas de software e expondo-as
de forma interativa, através de propriedades, métodos e
eventos dos objetos da aplicação.
O servidor OPC é divido em três partes: server
(contém todos os objetos do grupo), group (é a camada de
organização dos itens OPC) e item (objeto que carrega a
informação desejada). O “OPC Item” representa uma
variável específica do sistema, além do valor da variável,
possui informações sobre a qualidade da informação. O
“OPC Group” fica em uma camada superior, é onde os
itens são organizados e onde ocorre o controle de
atualização dos valores. Na camada mais externa fica o
“OPC Server”, onde são executadas as interfaces entre as
aplicações e onde ocorre o controle de eventos e alarmes.
Os computadores que possuem os drives dos
equipamentos de campo, que constituirão os “servidores
OPC”, reconhecem os dados provenientes da rede de
comunicação dos equipamentos da planta industrial e os
traduzem para o padrão OPC. Os servidores são softwares
que fornecem dados no padrão OPC e o computador é o
hardware convergente e que disponibiliza os dados. As
aplicações que recebem esses dados são os “clientes
OPC” e podem estar em quaisquer computadores
conectados à rede do servidor OPC.
O funcionamento do OPC é baseado na tradicional
arquitetura cliente-servidor onde um ou mais servidores
fornecem dados para uma ou mais aplicações cliente,
conforme mostra Figura 2. Basicamente, uma aplicação
cliente, como um software de supervisão, solicita um
dado ao servidor OPC que lhe atende e retorna com o
dado solicitado. Um diferencial do OPC é que uma
aplicação cliente pode solicitar dados a um ou mais
servidores OPC, e vice-versa. Fica claro, portanto, que o
OPC possibilita uma variedade enorme de comunicações,
basta que os aplicativos sejam compatíveis com o mesmo.
É importante ressaltar que o OPC não elimina o
protocolo proprietário nativo do CLP ou equipamento de
campo. O que acontece é que o servidor OPC “traduz”
este protocolo proprietário para o padrão OPC. Portanto é
necessário o desenvolvimento de um servidor OPC
específico para cada um dos diferentes protocolos de
comunicação existentes.
A interconexão ocorre em função dos
respectivos dados dos equipamentos de campo serem
reconhecidos através dos drives instalados nos
computadores, drive esse que descreve os componentes
do software desenvolvidos para um produto específico e
que são implementados pelo fabricante de um produto a
fim de permitir que seu software se comunique com
determinado produto por meio de uma comunicação de
rede.
V.
ASPECTOS PRÁTICOS PARA UTILIZAÇÃO
Para a especificação e utilização do padrão OPC,
o usuário precisa estar ciente de alguns pontos chaves
para o perfeito entendimento de como se beneficiar do
uso desse tipo de comunicação. Para isso, o estudo das
especificações torna-se um processo difícil, uma vez que
as mesmas são direcionadas para desenvolvedores e
programadores, sendo necessário o conhecimento prévio
de linguagens e ambientes de desenvolvimento. Para
simplificar o entendimento do padrão OPC, estes pontos
são apresentados a seguir.
Figura 2 – Arquitetura cliente-servidor do OPC
IV.
INTERCONEXÃO
A interconexão de sistemas e equipamentos por meio
da integração de drives de comunicação é, muitas vezes,
de difícil implementação e implica em alto custo de
desenvolvimento e instalação, lembrando, é claro, da
dificuldade por parte dos profissionais de realizar essa
integração entre os protocolos e sendo essencial para as
industrias o seu perfeito funcionamento, torna o trabalho
ainda mais elaborado e complicado para instalações, a
Figura 3 mostra um pouco disto.
Figura 3 – Interconexão da comunicação OPC
O padrão OPC surgiu para simplificar a maneira
como os dados dos equipamentos de chão de fábrica são
disponibilizados às suas aplicações sem que estas
precisem do drive e do protocolo utilizado no processo de
automação. O OPC, atualmente, vem sendo usado até
mesmo no fornecimento de dados para os sistemas de
controle situados nos escritórios, que tem por função
disponibilizar informações para a administração sobre os
processos de produção de uma indústria.
A. Cliente ou Servidor OPC?
Os produtos para monitoração de dados, como
IHMs, sistemas supervisórios e etc, normalmente são
clientes OPC. Por outro lado, os produtos que fazem a
comunicação direta com os dispositivos de campo
utilizando protocolos proprietários são servidores OPC.
Cada produto pode incorporar as duas funcionalidades,
sendo o mais comum em aplicações normalmente onde o
cliente possa ser servidor, e não o contrário.
B. Número ideal de clientes e servidores
O número de servidores necessários para uma
determinada aplicação irá depender do produto a ser
utilizado. Os fabricantes de dispositivos de campo
normalmente 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
comunicação 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 máquina ou em máquinas remotas.
Existem servidores OPC de terceiros que
permitem que sejam configurados drivers de
comunicação para diversas redes e protocolos de
diferentes fabricantes, neste caso, um único produto
poderá servir dados de diferentes fabricantes. Cada
cliente OPC pode conectar-se a diferentes servidores, os
quais podem estar processando na mesma máquina ou
remotamente em máquinas diferentes, portanto, qualquer
produto que funcione como cliente OPC poderá se
comunicar com quaisquer servidores OPC de quaisquer
fabricantes.
C. Formato de dados
Pela especificação do padrão, todo servidor de
dados deve enviar o dado OPC no seguinte formato: todos
os tipos de dados VARIANT definidos pela interface
DCOM são suportados; a informação “Time Stamp” é
fornecida pelo servidor através da leitura do time stamp
dos dispositivos de campo ou por geração interna, é
utilizada a estrutura padrão do Windows para o UTC
(Universal Time Coordinated); são reservados 2 bytes
para codificação 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 válido, ßBad – no
caso de perda do link de comunicação com o dispositivo
de campo, ßUncertain – no caso de existir o link de
comunicação mas o dispositivo de campo estiver fora de
operação; quatro bits fornecem um detalhamento do
estado apresentado e os últimos dois bits podem conter
dados de diagnóstico no caso de falha de um sensor, por
exemplo).
D. Configuração dos dados no “Cliente”
Os produtos de mercado, normalmente não
permitem muita flexibilidade para a configuração dos
dados solicitados pelo cliente. Isto se deve basicamente à
preservação da cultura anterior para os drivers de
comunicação específicos. Entretanto, isto pode ser uma
armadilha para os usuários. Considerando o caso mais
comum que consiste nos servidores de dados OPC (OPC
Data Access), os clientes podem definir basicamente as
seguintes configurações:
1) Criação de grupos e itens OPC
Basicamente, todos os dados OPC são chamados
de itens. Cada item pode ser de um tipo diferente de dado
compatível com a especificação OPC. Os diversos itens
são organizados em grupos OPC, os quais definem as
principais características de leitura dos itens (Taxa de
Atualização, Estado Ativo/Inativo, Banda Morta, Leitura
Síncrona/Assíncrona).
2) Leitura Síncrona ou Assíncrona
Para um determinado grupo OPC pode ser
definido se a leitura dos dados é feita de forma síncrona, a
qual depende de uma confirmação de execução antes de
uma nova leitura, ou assíncrona, a qual não depende da
confirmação. Normalmente é utilizada a leitura
assíncrona, a qual garante um melhor desempenho.
3) Leitura de dados direto do dispositivo
A partir da versão 2.0 da especificação para o
servidor de dados, é possível fazer a seleção no cliente
OPC para leitura dos dados da memória cache do servidor
ou diretamente do dispositivo de campo.
4) Estado Ativo/Inativo
Cada item ou grupo pode ter o seu estado
alterado pelo cliente para Ativo, habilitando a
comunicação do mesmo, ou Inativo.
5)Leitura Cíclica ou por Mudança de Estado
O cliente OPC pode definir se os dados do
servidor serão lidos de forma cíclica ou por mudança
(transição) de estado. Na leitura cíclica, o cliente faz a
requisição de leitura regularmente, independentemente se
os dados sofreram alteração de valor ou não. No caso de
leitura por mudança de estado, o servidor fica responsável
por enviar para os clientes os itens que sofrerem alteração
de seu estado (Qualidade do dado) ou quando os valores
dos itens de um determinado grupo ultrapassarem o valor
da banda morta.
6) Banda morta
É utilizada para definir os valores limites de
transição para os itens de um determinado grupo, para os
quais o servidor fará o envio para os clientes quando a
alteração dos valores dos itens estiver fora da banda
especificada.
E. Escrita de dados
A escrita de dados OPC funciona de forma
independente da leitura. Assim como na leitura, a escrita
pode ser síncrona ou assíncrona. Entretanto, os comandos
de escrita são executados imediatamente pelo servidor,
sendo enviados diretamente para os dispositivos de
campo. A partir da versão 3.0 do servidor, foi possível
fazer a escrita de dados na memória cache do servidor e
depois a transferência cíclica dos dados para os
dispositivos de campo. Este recurso é muito útil para os
dispositivos que dependem de comandos igualmente
espaçados no tempo, tal como os sistemas de controle de
movimento.
F. Comunicação de Blocos de Dados
O padrão OPC permite a comunicação de blocos
de dados (vetores) entre o servidor e os clientes. Isto
representa uma grande otimização, pois as informações
de “time stamp” e estado do dado são tratados e
fornecidos apenas uma vez para um conjunto de dados,
reduzindo assim o “overhead” da comunicação. Neste
caso, cada item é configurado como um bloco de dados.
G. Redundância com OPC
As especificações do padrão OPC não fazem
menção à utilização de servidores redundantes.
Entretanto, cada cliente OPC pode implementar
facilmente um mecanismo para conexão simultânea em
mais de um servidor, verificação do estado do servidor e
ativação/desativação dos grupos para o servidor que
estiver funcionando. Esta solução é encontrada apenas em
alguns produtos, não sendo regra geral a disponibilização
deste recurso para a maioria dos produtos de mercado.
H. Desempenho da comunicação OPC
Em linhas gerais, o desempenho da comunicação
OPC se aproxima do desempenho apresentado por
sistemas que utilizam drivers de comunicação específicos
e otimizados. Normalmente, os drivers específicos
possuem um ótimo desempenho após serem devidamente
depurados e otimizados, o que via de regra não acontece
em muitos casos. Como um servidor OPC nada mais é do
que uma camada de software a mais para implementar as
interfaces padrões e os mecanismos de comunicação com
o cliente, é de se esperar que o desempenho do mesmo só
seja afetado em relação a comunicação com o cliente e
não com o dispositivo de campo. No caso da
comunicação 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 comunicação.
Desta forma, o desempenho do servidor OPC
está mais relacionado à capacidade dos recursos de
hardware da máquina que executa a aplicação do servidor
do que propriamente do driver específico.
Como os recursos de hardware estão cada vez
mais poderosos em relação à capacidade de
processamento, isto não tem se mostrado como um
problema real. Entretanto, o que se tem verificado na
prática é que muitos clientes e servidores OPC não
implementam a comunicação 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
não implementam, consiste no agrupamento de dados que
precisam ser lidos sob demanda, tais como animações de
telas sinópticas, janelas de operação de equipamentos,
relatórios, etc.
Os dados necessários para estes elementos
(objetos) de monitoração, 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 não estiver
selecionado, o grupo OPC ficará desativado, fazendo com
que os dados não sejam lidos e com isso, melhora-se o
desempenho da comunicação.
I. Segurança para acesso ao sistema
Para a implementação do controle de acesso ao
servidor OPC podem ser utilizados dois métodos. O
método normalmente usado consiste nos mecanismos
proporcionados pelo próprio DCOM, os quais são
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 especificação do padrão OPC.
O controle de acesso é fundamental para o caso
de acesso remoto e para a comunicação via Internet
prevista com a especificação do OPC com XML.
VI.
VANTAGENS E DESVANTAGENS
As principais vantagens do emprego de uma
comunicação OPC são: a redução do tempo de
desenvolvimento; implementar uma comunicação
confiável entre diferentes equipamentos; a topologia é
simplificada e o controle do fluxo de informações fica sob
responsabilidade apenas dos servidores OPC.
A principal desvantagem vem quando pensamos
que o padrão OPC está passando por constante avanço ao
longo dos anos, preenchendo cada vez mais espaço nas
indústrias e, no entanto, algumas de suas características
principais que facilitaram seu surgimento e evolução
ironicamente hoje também são fatores limitantes ao seu
pleno funcionamento, fazendo com que alguns
desenvolvedores acabem por criar soluções que
complementam o OPC, possibilitando ultrapassar
algumas barreiras inerentes à sua tecnologia.
Isto se dá devido ao acelerado processo de
evolução tecnologica em que vivemos, onde
precisaríamos de equipes grandiosas para atualizar quase
que constantemente as funções e topologias do sistema
OPC.
REFERÊNCIAS
[1] P. P. Adriano. “Padronização da comunicação através da
tecnologia
OPC”.
[Online].
Disponível
em:
http://www.isarj.org.br/pdf/artigos/Padronizacao-daComunicacao-atraves-da-Tecnologia-OPC.pdf
[2] F.R. Denise, A. Reinaldo. “Utilização do drive OPC na
integração de sistemas de automação industrial”.
Apresentado no 3º Seminário Nacional de Sistemas
Industriais e Automação. [Online]. Disponível em:
http://www.cck.com.br/artigos/palestras/drive_opc.pdf
[3] O. F. Marcos. “Comunicação OPC – Uma abordagem
prática”.
[Online].
Disponível
em:
http://www.cpdee.ufmg.br/~seixas/PaginaSDA/Download/
DownloadFiles/OPCMarcosFonseca.PDF
[4] Site
da
OPC
Foundation:
https://opcfoundation.org/about/what-is-opc/