30 anos do OPC: como o padrão resolveu a conversa entre sistemas industriais

Quem integrava sistemas industriais no início dos anos 1990 conhecia bem o problema dos drivers. Cada software de supervisão precisava de um driver específico para cada marca e modelo de CLP, e cada fabricante de controlador precisava convencer os fornecedores de supervisórios a escrever esse driver. Com dez supervisórios e dez famílias de controladores, eram potencialmente cem drivers diferentes, cada um com seus erros, suas versões e seus limites. A história do OPC UA começa com a tentativa de acabar com esse quebra-cabeça.

Em 1996, uma força-tarefa de empresas de automação publicou a primeira especificação OPC e, na sequência, criou a OPC Foundation para mantê-la. Trinta anos depois, o padrão passou por uma reformulação completa e se tornou uma das bases da indústria conectada.

A ideia original: um driver para todos

A proposta do OPC era simples. Em vez de cada supervisório conversar diretamente com cada controlador, haveria uma interface padronizada no meio. O fabricante do controlador, ou um desenvolvedor especializado, escreveria um único servidor OPC para o seu equipamento. Qualquer aplicação cliente compatível, fosse um supervisório, um historiador ou uma planilha, poderia ler e escrever dados nesse servidor sem saber nada sobre o protocolo do controlador.

A primeira especificação se chamava OLE for Process Control, e o nome dizia muito sobre a tecnologia escolhida. Ela se apoiava nas tecnologias OLE, COM e DCOM da Microsoft, que dominavam o desenvolvimento de software para Windows na época. Os computadores de supervisão rodavam Windows, os fornecedores já dominavam essas ferramentas, e o padrão pôde ser implementado rapidamente.

O OPC clássico

A especificação inicial, conhecida como OPC Data Access (OPC DA), tratava da leitura e escrita de valores em tempo real: cada variável era um item com valor, qualidade e carimbo de tempo. Com o sucesso da proposta, a família cresceu:

• OPC DA (Data Access), para dados em tempo real, a mais usada.
• OPC HDA (Historical Data Access), para consulta a dados históricos.
• OPC A&E (Alarms and Events), para alarmes e eventos.
• Outras especificações para lotes, segurança de acesso e troca de dados entre servidores.

O conjunto, atualmente chamado de OPC Classic, resolveu o problema dos drivers e se espalhou por supervisórios, historiadores de processo, sistemas de gestão da produção e ferramentas de análise. Por muitos anos, "ter servidor OPC" virou requisito comum em especificações de sistemas de automação.

Os limites do modelo baseado em DCOM

O sucesso também expôs as fraquezas da arquitetura:

• Dependência do Windows. O OPC Classic só funcionava em plataformas Microsoft, o que excluía sistemas embarcados, Linux e controladores com sistemas operacionais próprios.
• Configuração difícil do DCOM. Comunicar entre computadores diferentes exigia ajustes de permissões e contas de usuário que se tornaram fonte frequente de falhas e de chamados de suporte.
• Problemas com firewalls. O DCOM usa portas dinâmicas, o que complica a segmentação de redes e conflita com boas práticas de segurança.
• Modelo de dados pobre. Os dados eram essencialmente uma lista de variáveis com nomes livres. O significado, a unidade e a relação entre elas ficavam fora do padrão.

À medida que a segurança cibernética ganhou importância e os dados de chão de fábrica passaram a interessar a sistemas corporativos, ficou claro que era preciso outro caminho. Como o padrão já não se limitava ao controle de processos, a OPC Foundation passou a usar o nome Open Platform Communications.

A virada: OPC Unified Architecture

A resposta foi o OPC UA, sigla de Unified Architecture. Depois de mais de três anos de trabalho de especificação e mais um ano de implementação de protótipo, a primeira versão foi publicada em 2006. O padrão foi depois adotado pela IEC como a série de normas IEC 62541.

As diferenças em relação ao OPC Classic são profundas:

• Independência de plataforma. O OPC UA não depende do DCOM nem do Windows. Pode rodar em servidores, computadores industriais, sistemas embarcados e diretamente em controladores e dispositivos de campo.
• Segurança integrada. Autenticação de aplicações e usuários com certificados, assinatura e criptografia de mensagens fazem parte da especificação.
• Modelagem de informação. Além de valores, o OPC UA descreve objetos, tipos, relações e métodos. Uma máquina pode expor não só a temperatura, mas o fato de que aquela temperatura pertence a um determinado equipamento, tem certa unidade e faixa e se relaciona com outras variáveis.
• Unificação. Dados em tempo real, históricos, alarmes e métodos, antes espalhados em especificações separadas, convivem em um único modelo.

Especificações complementares e a linguagem comum das máquinas

A modelagem de informação abriu espaço para as especificações complementares (companion specifications), desenvolvidas pela OPC Foundation em conjunto com associações setoriais. Elas definem como um tipo de equipamento deve se apresentar em OPC UA: quais dados, com que nomes, em que estrutura. Há modelos padronizados para dezenas de tipos de equipamento, como robôs, máquinas-ferramenta, injetoras, máquinas de embalagem, instrumentos de campo e sistemas de visão.

O efeito prático é que um sistema de gestão da produção pode ler o estado, os contadores e os alarmes de máquinas de fabricantes diferentes da mesma forma, sem mapeamento manual de cada variável. É a mesma promessa de 1996, levada do nível do protocolo ao nível do significado dos dados.

O papel do OPC UA na indústria conectada

Nas arquiteturas de Indústria 4.0, o OPC UA ocupa a posição de ligação entre o chão de fábrica e os sistemas de informação. Algumas aplicações comuns:

• Integração vertical, conectando CLPs e máquinas a supervisórios, sistemas de execução da manufatura, historiadores e ERP, alinhados a modelos como os da série ISA-95.
• Integração entre máquinas de fabricantes diferentes em uma mesma linha.
• Envio de dados para a nuvem e plataformas de análise, com o modelo de publicação e assinatura (PubSub) acrescentado às versões mais recentes da especificação.
• Comunicação no nível de campo, com iniciativas da OPC Foundation para levar o OPC UA até a troca determinística entre controladores e dispositivos.

Muitos CLPs e controladores já saem de fábrica com servidor OPC UA embarcado, dispensando computadores intermediários. Onde há equipamentos antigos, gateways convertem OPC Classic ou protocolos proprietários para OPC UA, permitindo modernizar a integração sem trocar tudo.

Cuidados ao adotar OPC UA na planta

A adoção do padrão traz benefícios, mas exige alguns cuidados que costumam ser esquecidos na pressa de conectar as máquinas:

• Gestão de certificados. A segurança do OPC UA depende de certificados digitais trocados entre clientes e servidores. Eles vencem, precisam ser renovados e devem ser aceitos de forma controlada, não com a opção de confiar em todos.
• Modo de segurança. Muitos servidores aceitam conexões sem criptografia para facilitar testes. Em produção, o modo com assinatura e criptografia deve ser o padrão.
• Desempenho do controlador. Um servidor embarcado no CLP consome recursos. Assinaturas demais, com taxas de amostragem muito altas, podem afetar o tempo de ciclo.
• Segmentação de rede. O OPC UA facilita atravessar firewalls, mas isso não dispensa separar as redes de automação e corporativa, conforme as práticas da série IEC 62443.

Lições de três décadas

A trajetória do OPC mostra alguns padrões que se repetem na automação:

• Padrões abertos vencem soluções ponto a ponto quando o número de fabricantes e sistemas cresce.
• Escolhas de tecnologia envelhecem. Apoiar-se no DCOM foi decisivo para a adoção rápida, mas depois se tornou o principal obstáculo.
• Segurança precisa estar no projeto. O OPC UA nasceu com segurança integrada porque o mundo industrial conectado já não tolerava redes abertas.
• O valor está no significado dos dados. Transportar bits é só o começo; o que integra de fato é saber o que cada dado representa.