Entenda o que é OPC UA, cliente e servidor, Address Space, nodes, PubSub, certificados, segurança e integração com SCADA, Modbus, MQTT e subestações.
Confira!
OPC UA é uma arquitetura de interoperabilidade industrial usada para expor dados, estados, eventos, alarmes, métodos e modelos de informação entre dispositivos e aplicações. Ela não se limita a transportar valores: também descreve o significado, a qualidade, o tipo, a unidade, a hierarquia e as permissões associadas a cada informação.
Na prática, um servidor OPC UA pode disponibilizar informações de um CLP, gateway, sistema supervisório, historiador ou aplicação. Um cliente OPC UA navega nessa estrutura, lê e escreve variáveis autorizadas, cria assinaturas, recebe eventos ou executa métodos. A arquitetura também possui um modelo Publish-Subscribe para distribuição de dados a múltiplos consumidores.
Em subestações de distribuição, OPC UA costuma atuar na integração entre gateways, sistemas SCADA, historiadores, plataformas de manutenção e aplicações corporativas. Ele complementa tecnologias como Modbus, MQTT e IEC 61850, mas não substitui automaticamente protocolos de proteção, automação ou telecontrole. O papel correto depende de requisitos funcionais, criticidade, latência, segurança e interoperabilidade.
O que é OPC UA
OPC UA significa Open Platform Communications Unified Architecture. A arquitetura foi desenvolvida pela OPC Foundation como sucessora do OPC Classic, eliminando a dependência estrutural de COM/DCOM e permitindo implementação em diferentes sistemas operacionais e classes de hardware.
Seu diferencial central é combinar serviços de comunicação com um modelo de informação extensível. Em vez de fornecer apenas uma lista plana de tags, o servidor pode representar instalações, sistemas, equipamentos, componentes, variáveis, alarmes e relações entre objetos. Essa estrutura permite que aplicações consumidoras descubram e interpretem os dados com menos dependência de planilhas externas.
OPC UA pode operar em computadores industriais, servidores, gateways, CLPs e dispositivos embarcados. O fato de a arquitetura ser independente de plataforma não significa que qualquer equipamento suporte todas as funções. Cada implementação pode oferecer um subconjunto de serviços, transportes, políticas de segurança, perfis e modelos de informação.
Como funciona o OPC UA
Na comunicação cliente-servidor, o servidor publica um ou mais endpoints. O cliente identifica o endpoint, verifica as políticas disponíveis, estabelece um canal seguro, cria uma sessão e autentica o usuário quando necessário. Depois disso, ele acessa somente os nós e serviços permitidos.
A comunicação pode envolver leitura sob demanda, escrita, navegação, assinaturas, eventos, alarmes e métodos. A sessão mantém contexto entre cliente e servidor, enquanto o canal seguro protege a troca de mensagens conforme a política selecionada.
A disponibilidade de um endpoint não deve ser confundida com autorização irrestrita. A identidade da aplicação, a identidade do usuário e as permissões sobre os dados são controles distintos. Um cliente pode possuir certificado confiável e, ainda assim, receber apenas acesso de leitura a uma parte do Address Space.
Cliente, servidor e gateways
Um OPC UA Server disponibiliza informações e serviços. Um OPC UA Client inicia conexões, realiza solicitações ou mantém assinaturas. Um sistema SCADA pode atuar como cliente de vários equipamentos; um gateway pode atuar simultaneamente como cliente de dispositivos de campo e servidor para aplicações de nível superior.
Essa função dupla é comum em projetos de integração. Um gateway pode ler registradores Modbus, interpretar escalas e disponibilizar objetos OPC UA com nomes, unidades e qualidade. Também pode consolidar dados de equipamentos proprietários e publicar uma interface padronizada para o SCADA ou historiador.
A concentração facilita a interoperabilidade, mas transforma o gateway em componente crítico. Seu dimensionamento deve considerar quantidade de dispositivos, sessões, itens monitorados, taxa de atualização, eventos, armazenamento temporário, redundância e recuperação. O artigo sobre redes industriais e SCADA ajuda a contextualizar essa relação entre protocolo, infraestrutura e aplicação.
Address Space, nodes e namespaces
O Address Space é a estrutura de informações exposta pelo servidor. Ele é formado por nós conectados por referências. Entre as classes de nós estão objetos, variáveis, métodos, tipos de objetos, tipos de variáveis, tipos de dados, referências e views.
Uma variável pode conter valor, tipo de dado, qualidade, timestamp e regras de acesso. Um objeto pode representar um equipamento e reunir medições, estados, parâmetros, alarmes e métodos. As referências indicam relações de composição, organização, tipo e dependência.
Cada nó possui um NodeId. Esse identificador deve ser interpretado dentro de um namespace. Como o índice numérico de um namespace pode mudar entre instalações ou reinicializações, integrações robustas utilizam a URI do namespace e os mecanismos de resolução suportados pelo cliente.
BrowseName, DisplayName e NodeId não são equivalentes. O BrowseName participa da navegação e está associado a um namespace; o DisplayName é voltado à apresentação ao usuário; o NodeId identifica o nó. Uma lista de pontos deve registrar esses campos de maneira explícita para evitar dependência de nomes visuais que podem ser alterados.
Modelo de informação e semântica
A modelagem de informação é a principal diferença entre OPC UA e protocolos baseados apenas em endereços. Um equipamento pode ser representado como instância de um tipo que define estrutura, variáveis, métodos e eventos. Equipamentos equivalentes podem compartilhar o mesmo tipo, tornando a integração mais consistente.
O modelo deve representar a realidade operacional, e não apenas reproduzir a organização interna do software do fabricante. Uma boa estrutura diferencia instalação, sistema, bay, equipamento, função e ponto. Também registra unidades de engenharia, limites, estados enumerados, severidades e qualidade.
Companion Specifications permitem que setores e organizações definam modelos comuns sobre a base OPC UA. Elas podem melhorar a interoperabilidade, mas precisam ser adotadas de maneira consistente. Utilizar o nome de uma especificação sem implementar os tipos, referências e regras correspondentes cria uma compatibilidade apenas nominal.
A governança do modelo inclui versionamento. Alterações de NodeId, estrutura ou tipo de dado podem interromper clientes. Por isso, mudanças precisam ser avaliadas, documentadas e testadas antes de chegar ao ambiente de produção.
Leitura, escrita, métodos e assinaturas
A leitura consulta atributos atuais de um ou mais nós. A escrita altera valores quando o servidor e as permissões permitem. Métodos representam operações definidas pelo servidor e podem receber argumentos de entrada e retornar resultados.
Em ambientes críticos, escrita e métodos exigem controles adicionais. A aplicação deve validar tipo, faixa e contexto; o servidor deve limitar usuários e clientes; e o processo deve manter intertravamentos locais. Uma interface destinada a relatórios ou analytics normalmente não precisa de capacidade de comando.
Subscriptions reduzem a necessidade de polling contínuo. O cliente cria itens monitorados e define parâmetros como intervalo de amostragem, intervalo de publicação, fila e deadband. O servidor envia notificações quando as condições são atendidas.
Configurações muito agressivas podem sobrecarregar dispositivos, gateways e rede. Configurações lentas podem atrasar alarmes ou mudanças relevantes. O projeto deve separar medições contínuas, estados, alarmes e eventos de maior criticidade, definindo critérios compatíveis com cada classe de informação.
Arquitetura de integração em subestações
Em uma subestação, OPC UA deve ser posicionado de acordo com as zonas funcionais. A automação local pode utilizar IEC 61850 entre IEDs, enquanto gateways ou servidores disponibilizam informações consolidadas para o SCADA, historiadores e sistemas de manutenção. Essa separação preserva a função dos protocolos especializados e reduz a exposição direta dos ativos de campo.
A subestação digital baseada em IEC 61850 utiliza modelos e serviços específicos para proteção, controle e supervisão. OPC UA pode consumir ou republicar parte dessas informações em uma camada de integração, mas não deve substituir GOOSE, Sampled Values ou mecanismos que possuam requisitos determinísticos próprios.
Uma arquitetura típica pode incluir IEDs e controladores no nível de processo, gateways no nível de bay ou estação, servidores SCADA e historiadores no nível de operação e interfaces controladas com a rede corporativa. O fluxo entre esses níveis deve ser registrado em uma matriz de comunicação.
A lista de pontos precisa identificar origem, transformação e destino. Quando um dado é calculado no gateway, essa condição deve ser distinguida de uma medição originada no equipamento. Qualidade e timestamp também precisam preservar a origem; atribuir horário somente no servidor de integração pode ocultar atrasos ou indisponibilidades.
A interoperabilidade precisa ser projetada como arquitetura, não como simples conversão de tags.
Modelo de informação, qualidade, timestamps, permissões, gateways, fluxos e redundância devem ser definidos antes da implantação.
OPC UA PubSub
OPC UA PubSub utiliza publishers e subscribers. O publisher produz DataSets, e os subscribers processam as mensagens de interesse. Eles não precisam manter a mesma relação direta de solicitação e resposta do modelo cliente-servidor.
A arquitetura pode utilizar diferentes transportes e codificações. MQTT pode atuar como transporte em determinadas implementações, mas OPC UA PubSub não é sinônimo de MQTT. O artigo sobre MQTT industrial explica o funcionamento de brokers, tópicos, QoS e sessões; no OPC UA PubSub, o contrato dos DataSets e a semântica permanecem vinculados à arquitetura OPC UA.
O projeto deve definir PublisherId, DataSetWriter, campos publicados, codificação, intervalo, segurança, gerenciamento de chaves, comportamento diante de perda de mensagens e monitoramento dos subscribers. Também precisa determinar quem mantém o contrato de dados quando versões diferentes de aplicações coexistem.
PubSub é útil para distribuição a múltiplos consumidores e para arquiteturas desacopladas. Entretanto, não elimina a necessidade de diagnóstico. É preciso conseguir identificar ausência de publicação, perda de sequência, versão incompatível do DataSet e falhas no middleware.
OPC UA, Modbus e MQTT
Modbus organiza a comunicação em coils e registradores. O significado dos dados depende do mapa do fabricante. OPC UA pode transformar esses endereços em objetos e variáveis com nomes, tipos, unidades e relações. A conversão deve preservar escala, endianness, qualidade, timestamp e permissões.
MQTT fornece transporte leve de mensagens por broker e tópicos. A semântica do payload é definida pela aplicação. OPC UA oferece um modelo de informação e serviços mais amplos. As tecnologias podem coexistir: um gateway pode adquirir dados por Modbus, modelá-los em OPC UA e disponibilizar parte deles em uma arquitetura de publicação baseada em MQTT.
A escolha não deve ser feita apenas pela popularidade do protocolo. Modbus é adequado para integração simples com muitos equipamentos; MQTT favorece distribuição desacoplada; OPC UA favorece interoperabilidade semântica e serviços industriais. O projeto precisa definir responsabilidades e limites entre as camadas.
Integração com SCADA e historiadores
O SCADA pode utilizar OPC UA para receber valores, estados, eventos e alarmes, além de enviar comandos autorizados. O historiador pode consumir assinaturas e armazenar séries temporais. Em ambos os casos, a integração deve preservar qualidade e timestamps.
O SCADA no setor elétrico não deve apresentar um valor como válido quando o servidor perdeu a fonte de dados. O cliente precisa interpretar códigos de qualidade, tempo da origem, tempo do servidor e estado da sessão.
Deadband, sampling interval e publishing interval têm funções diferentes. O intervalo de amostragem define a frequência com que o servidor observa a variável; o publishing interval organiza a entrega de notificações; a deadband evita notificar mudanças pequenas. Esses parâmetros precisam ser ajustados com base na dinâmica do processo.
Eventos e alarmes exigem modelagem própria. Severidade, reconhecimento, retorno ao normal, supressão e manutenção devem ser consistentes entre a origem e a aplicação. Transformar qualquer mudança em alarme aumenta ruído operacional e reduz a capacidade de priorização.
Segurança, certificados e confiança
OPC UA oferece identificação de aplicações por certificados, canais seguros, autenticação de usuários, autorização, assinatura, criptografia e auditoria. Esses recursos não tornam a instalação automaticamente segura. Uma configuração permissiva pode neutralizar grande parte do modelo.
Clientes e servidores mantêm listas de certificados confiáveis e rejeitados. O processo de confiança precisa registrar quem aprovou cada aplicação, em qual ambiente e com qual finalidade. Aceitar automaticamente certificados rejeitados transforma uma decisão de segurança em rotina sem controle.
Certificados possuem validade e chaves privadas. A operação deve prever emissão, distribuição, armazenamento, renovação, revogação e recuperação. O sincronismo por servidor NTP é relevante porque diferenças de horário podem afetar validação, logs e correlação de eventos.
Security Policy e Message Security Mode precisam ser definidos por endpoint. Modos sem assinatura ou criptografia podem existir para diagnóstico ou compatibilidade, mas não devem permanecer disponíveis sem justificativa. Políticas e algoritmos obsoletos precisam ser removidos quando a interoperabilidade permitir.
A autenticação do usuário é diferente da confiança da aplicação. Um cliente autorizado pode exigir usuário, certificado de usuário ou token emitido por provedor de identidade. Depois da autenticação, permissões devem limitar leitura, escrita, métodos e partes do Address Space.
Certificados e políticas só protegem quando existe governança operacional.
A A3A Engenharia estrutura confiança entre aplicações, segmentação, regras de firewall, hardening, logs e procedimentos de renovação para ambientes críticos.
Rede, firewall e DMZ industrial
TCP 4840 é comum em OPC UA TCP, mas não é a única possibilidade. O firewall deve permitir apenas os endpoints efetivamente utilizados, entre clientes e servidores específicos. Regras amplas entre sub-redes não são justificadas apenas pelo uso de uma porta conhecida.
Quando aplicações corporativas precisam consumir dados da automação, a arquitetura pode utilizar um gateway, servidor intermediário, historiador ou agregador na DMZ entre redes TI e OT. O objetivo é impedir que consumidores corporativos iniciem conexões indiscriminadas com ativos de campo.
A matriz de fluxos deve registrar origem, destino, direção, porta, transporte, função, responsável e criticidade. Descoberta, gerenciamento de certificados, DNS e sincronismo também devem ser considerados quando fazem parte da implementação.
O hardening não se limita ao protocolo. Sistemas operacionais, serviços, contas, bibliotecas, logs, backups e interfaces administrativas precisam seguir uma baseline. O guia de hardening para servidores e ambientes OT complementa essa camada.
Disponibilidade, redundância e recuperação
A disponibilidade depende de toda a cadeia: dispositivo de origem, gateway, rede, servidor, certificado, serviço de nomes, sincronismo e cliente consumidor. Redundância apenas no servidor não elimina falhas de enlace ou de origem.
Algumas implementações oferecem servidores redundantes e mecanismos de failover; outras exigem que o cliente conheça vários endpoints. O projeto deve definir detecção de falha, tempo de recuperação, preservação de assinaturas, comportamento das filas, qualidade durante a transição e reconexão.
A recuperação precisa ser testada. Reiniciar um servidor, interromper um enlace e expirar controladamente um certificado revelam dependências que não aparecem em testes normais de leitura. O sistema deve retornar sem duplicar comandos, perder eventos críticos ou manter valores antigos como válidos.
Gateways e desempenho
Gateways OPC UA podem concentrar centenas ou milhares de pontos provenientes de vários protocolos. O dimensionamento deve considerar número de dispositivos, taxa de aquisição, sessões, subscriptions, monitored items, eventos e clientes simultâneos.
Caching pode melhorar desempenho, mas precisa ser transparente. O cliente deve saber se o valor é atual, armazenado ou inválido. Quando a comunicação com a origem falha, o gateway deve alterar a qualidade em vez de manter indefinidamente o último valor como se fosse atual.
Limites de licença e de implementação também precisam ser analisados. Um software pode limitar quantidade de tags, conexões ou recursos de redundância. O projeto deve registrar esses limites e prever margem para expansão.
Projeto, documentação e governança
Um projeto OPC UA precisa produzir arquitetura lógica e física, inventário de clientes e servidores, matriz de fluxos, endpoints, políticas de segurança, modelo de confiança, lista de pontos, parâmetros de subscriptions, regras de firewall e estratégia de redundância.
A lista de pontos deve incluir namespace URI, NodeId, BrowseName, tipo, unidade, escala, origem, qualidade, timestamp, deadband e permissão. Também precisa identificar variáveis calculadas, comandos e métodos.
A governança define responsáveis por certificados, modelos, mudanças e backups. Sem essa definição, a integração funciona durante a implantação, mas se degrada à medida que aplicações são atualizadas e novas conexões são adicionadas.
Comissionamento e critérios de aceite
O comissionamento deve testar a cadeia ponta a ponta, não apenas a capacidade de um cliente de diagnóstico navegar no servidor. É necessário verificar o valor apresentado ao operador, sua unidade, qualidade, timestamp e comportamento durante falhas.
Os ensaios mínimos incluem:
- conexão com políticas e certificados esperados;
- rejeição de clientes e usuários não autorizados;
- leitura, escrita e métodos conforme a matriz de permissões;
- subscriptions, filas, deadbands, eventos e alarmes;
- perda de origem, perda de rede, reinicialização e failover;
- renovação de certificado, logs, auditoria e recuperação;
- integração final com SCADA, historiador e aplicações consumidoras.
Os resultados devem ser registrados com evidências e critérios de aceite. A Integração de Sistemas precisa comprovar não apenas conectividade, mas coerência funcional entre origem e destino.
O aceite deve comprovar o dado até a aplicação final.
Qualidade, timestamp, escala, permissões, eventos, perda de comunicação, failover e recuperação precisam ser testados entre dispositivo, gateway, servidor e SCADA.
Diagnóstico de falhas
Falhas de conexão exigem verificar endpoint, rota, firewall, política, certificado e horário. Falhas após a criação da sessão podem estar relacionadas a autenticação, permissões ou limites do servidor.
Valores incorretos normalmente indicam tipo de dado, escala, transformação ou mapeamento inadequado. Valores congelados podem decorrer de perda da origem sem atualização da qualidade. Eventos ausentes podem estar ligados a filtros, filas, publishing interval ou capacidade do servidor.
Uma ferramenta como UAExpert pode auxiliar no diagnóstico, mas deve ser utilizada com credenciais apropriadas e em condições controladas. O resultado precisa ser comparado com logs do servidor, gateway e aplicação final.
Erros comuns
Tratar OPC UA como uma lista de tags elimina grande parte do valor da modelagem. Outro erro é depender apenas de DisplayName ou de índices numéricos de namespace, tornando a integração frágil diante de mudanças.
Também são frequentes a aceitação automática de certificados, a manutenção de acesso anônimo, a exposição ampla da porta 4840 e a disponibilização de escrita em interfaces destinadas a consulta.
Por fim, é inadequado presumir que OPC UA substitui IEC 61850, Modbus ou MQTT em qualquer situação. Cada tecnologia possui função, requisitos e limitações próprios.
Conclusão
OPC UA combina comunicação, serviços, modelagem de informação e controles de segurança em uma arquitetura independente de plataforma. Em subestações, seu principal valor está na integração controlada entre automação, gateways, SCADA, historiadores e aplicações de nível superior.
Uma implementação confiável exige modelo de dados consistente, gestão de certificados, menor privilégio, segmentação, qualidade, timestamps, redundância e testes de falha. Quando esses elementos são tratados como parte do projeto, OPC UA complementa os protocolos especializados sem criar uma interface genérica e não controlada para o processo.
Referências técnicas
[1] OPC FOUNDATION. Unified Architecture — Landingpage. Disponível em: https://opcfoundation.org/about/opc-technologies/opc-ua/. Acesso em: 13 jul. 2026.
[2] OPC FOUNDATION. OPC Unified Architecture — Part 2: Security Model. Release 1.05.06. Disponível em: https://reference.opcfoundation.org/specs/OPC-10000-2. Acesso em: 13 jul. 2026.
[3] OPC FOUNDATION. OPC Unified Architecture — Part 4: Services. Release 1.05.07. Disponível em: https://reference.opcfoundation.org/specs/OPC-10000-4. Acesso em: 13 jul. 2026.
[4] OPC FOUNDATION. OPC Unified Architecture — Part 5: Information Model. Disponível em: https://reference.opcfoundation.org/specs/OPC-10000-5. Acesso em: 13 jul. 2026.
[5] OPC FOUNDATION. OPC Unified Architecture — Part 14: PubSub. Release 1.05.06. Disponível em: https://reference.opcfoundation.org/specs/OPC-10000-14. Acesso em: 13 jul. 2026.
[6] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security. Gaithersburg, 2023.
[7] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 62443 series — Security for industrial automation and control systems.
Perguntas frequentes
OPC UA é uma arquitetura de interoperabilidade industrial que disponibiliza dados, eventos, métodos e modelos de informação entre dispositivos e aplicações de diferentes plataformas.
Um servidor publica endpoints e um Address Space. Clientes autorizados estabelecem canais seguros, criam sessões e utilizam serviços de navegação, leitura, escrita, assinatura, eventos ou métodos.
OPC DA pertence ao OPC Classic e depende de COM/DCOM. OPC UA é independente de plataforma, possui modelo de informação extensível e mecanismos próprios de segurança.
Não necessariamente. Modbus continua comum na aquisição de dados de dispositivos. Gateways podem converter registradores Modbus em objetos e variáveis OPC UA.
Não de forma geral. IEC 61850 foi criada para automação de sistemas elétricos. OPC UA costuma atuar na integração com SCADA, historiadores, manutenção e aplicações de nível superior.
Sim. MQTT pode ser utilizado como transporte em determinadas arquiteturas OPC UA PubSub, ou uma aplicação pode converter dados OPC UA em tópicos MQTT convencionais.
TCP 4840 é comum para OPC UA TCP, mas endpoints e transportes podem utilizar outras portas. O projeto deve confirmar os fluxos reais.
A arquitetura oferece certificados, autenticação, assinatura, criptografia, autorização e auditoria. A segurança depende da configuração, gestão de certificados, segmentação e hardening.
NodeId identifica um nó dentro do Address Space e deve ser interpretado junto com o namespace correspondente.
Devem ser testados endpoints, certificados, políticas, usuários, permissões, tipos, qualidade, timestamps, subscriptions, eventos, falhas, redundância, logs e integração ponta a ponta.
Materiais técnicos complementares
Soluções relacionadas
- Redes Industriais
- Sistemas SCADA
- Sistemas Digitais de Supervisão e Controle
- Zabbix — Monitoramento de Infraestrutura
Serviços relacionados
Artigos e materiais técnicos relacionados
