Arquitetura Unificada OPC - OPC Unified Architecture

OPC Unified Architecture ( OPC UA ) é um protocolo de comunicação máquina a máquina para automação industrial desenvolvido pela OPC Foundation . As características distintivas são:

  • Com base em uma comunicação cliente-servidor
  • Foco na comunicação com equipamentos e sistemas industriais para coleta e controle de dados
  • Aberto - disponível gratuitamente e implementável sob licença GPL 2.0
  • Plataforma cruzada - não vinculado a um sistema operacional ou linguagem de programação
  • Arquitetura orientada a serviços (SOA)
  • Complexidade inerente - em setembro de 2020, a especificação consistia em 3.151 páginas em 15 documentos
  • Oferece funcionalidade de segurança para autenticação, autorização, integridade e confidencialidade
  • Modelo de informação integral , que é a base da infraestrutura necessária para integração de informações onde fornecedores e organizações podem modelar seus dados complexos em um namespace OPC UA para tirar proveito da rica arquitetura orientada a serviços do OPC UA. Existem mais de 35 colaborações com a Fundação OPC atualmente. As principais indústrias incluem farmacêutica , petróleo e gás , automação predial , robótica industrial , segurança, manufatura e controle de processos .

História

Embora desenvolvido pela mesma organização, OPC UA difere significativamente de seu antecessor, Open Platform Communications (OPC). O objetivo da Fundação para o OPC UA era fornecer um caminho a partir do modelo de comunicação OPC original (ou seja, o Microsoft Windows - somente troca de processos COM / DCOM ) que atenderia melhor às necessidades emergentes de automação industrial .

Após mais de três anos de trabalho de especificação e outro ano para a implementação de um protótipo, a primeira versão da Arquitetura Unificada foi lançada em 2006.

A versão atual da especificação é 1.04 (22 de novembro de 2017). A nova versão do OPC UA agora adicionou publicar / assinar, além da infraestrutura de comunicação cliente / servidor.

Inovações

Embora o vínculo original com COM / DCOM ajudasse o OPC a distribuir bem, ele tinha várias desvantagens:

  • Problemas de configuração frequentes com DCOM;
  • Sem tempos limite configuráveis;
  • Apenas Microsoft Windows ;
  • Segurança mais baixa;
  • Sem controle sobre DCOM (COM / DCOM é uma espécie de caixa preta, os desenvolvedores não têm acesso às fontes e, portanto, precisam lidar com bugs ou implementações insuficientes).

Essas desvantagens, juntamente com uma série de outras considerações, levaram à decisão de desenvolver uma pilha nova e independente para OPC UA, que substitui COM / DCOM. As principais características desta pilha de comunicação foram:

  • Implementação multiplataforma, incluindo implementações ANSI C , Java e .NET portáteis ;
  • Escalabilidade: de sensores e atuadores inteligentes a mainframes;
  • Operação multi-threaded, bem como single-threaded / tarefa única - necessária para portar a pilha para dispositivos incorporados;
  • Segurança, baseada em novos padrões;
  • Tempos limite configuráveis ​​para cada serviço;
  • Fragmentação de grandes datagramas.

Essa pilha de comunicação reflete o início de várias inovações. A arquitetura OPC UA é uma arquitetura orientada a serviços (SOA) e é baseada em diferentes níveis lógicos.

Os OPC Base Services são descrições de métodos abstratos, que são independentes de protocolo e fornecem a base para a funcionalidade do OPC UA. A camada de transporte coloca esses métodos em um protocolo, o que significa que serializa / desserializa os dados e os transmite pela rede. Dois protocolos são especificados para este propósito. Um é um protocolo TCP binário , otimizado para alto desempenho e o segundo é orientado para serviços da Web .

O modelo de informação OPC é uma rede Mesh baseada em nós . Esses nós podem incluir qualquer tipo de meta informação e são semelhantes aos objetos de programação orientada a objetos (OOP). Um nó pode ter atributos para acesso de leitura (DA, HDA), métodos que podem ser chamados (comandos) e eventos disparados que podem ser transmitidos (AE, DataAccess, DataChange). Os nós mantêm os dados do processo, bem como todos os outros tipos de metadados . O namespace OPC contém o modelo de tipo.

O software cliente pode verificar quais perfis um servidor suporta. Isso é necessário para obter informações, se um servidor suporta apenas a funcionalidade DA ou adicionalmente AE, HDA, etc. Além disso, podem ser obtidas informações sobre se um servidor suporta um determinado perfil. Os novos e importantes recursos do OPC UA são:

  • Suporte de redundância
  • Pulsação para conexões em ambas as direções (para indicar se a outra extremidade está "viva"). Isso significa que o servidor e o cliente reconhecem as interrupções.
  • Buffer de dados e confirmações de dados transmitidos. Conexões perdidas não levam mais à perda de dados. Os datagramas perdidos podem ser recuperados.

No OPC UA DevCon em outubro de 2006, em Munique, os primeiros protótipos foram apresentados ao vivo. Vários servidores UA foram mostrados em um controlador lógico programável Beckhoff e uma placa de teste integrada da Euros. O PLC Beckhoff é baseado no Windows XP Embedded e o controlador embutido é baseado no sistema operacional de tempo real Euros. A empresa Embedded Labs Ltd demonstrou um servidor OPC UA baseado em sua própria pilha C ++ UA executando em um microcontrolador ARM de chip único com 64kB de RAM . Em outubro de 2012, o Fraunhofer-Application Center alemão IOSB-INA e o Institute for industrial Information Technologies (inIT) mostraram que um servidor OPC UA é escalonável até 15 kB RAM e 10 kB ROM e, portanto, utilizável no nível do chip.

Protocolos

OPC UA oferece suporte a dois protocolos. Isso é visível para os programadores de aplicativos apenas por meio de alterações na URL. O protocolo binário é opc.tcp: // Server e http: // Server é para Web Service. Caso contrário, o OPC UA funciona de forma totalmente transparente para a API .

O protocolo binário oferece o melhor desempenho / menor sobrecarga, consome recursos mínimos (sem XML Parser, SOAP e HTTP necessários, o que é importante para dispositivos incorporados), oferece melhor interoperabilidade (o binário é explicitamente especificado e permite menos graus de liberdade durante a implementação) e usa uma única porta TCP escolhida arbitrariamente para facilitar o encapsulamento de comunicação ou a ativação por meio de um firewall.

O protocolo de serviço da Web (SOAP) é melhor suportado por ferramentas disponíveis, por exemplo, de ambientes Java ou .NET, e é compatível com firewall, usando portas HTTP (S) padrão.

O binário é compatível com todas as implementações, enquanto apenas a implementação do .NET oferece suporte a SOAP.

Especificações

A especificação OPC UA é uma especificação de várias partes e consiste nas seguintes partes:

  1. Conceitos
  2. Modelo de Segurança
  3. Modelo de Espaço de Endereço
  4. Serviços
  5. Modelo de Informação
  6. Mapeamentos
  7. Perfis
  8. Acesso de dados
  9. Alarmes e Condições
  10. Programas
  11. Acesso Histórico
  12. Descoberta e Serviços Globais
  13. Agregados
  14. PubSub
  15. Segurança
  16. Máquinas de estado (ainda não publicado)
  17. Nomes de alias
  18. Autorização do usuário (ainda não publicado)
  19. Referências de dicionário

Além disso, a parte 100 Dispositivos e a parte 200 Automação Industrial também estão disponíveis. Elas se baseiam no conjunto básico de especificações e adicionam novas definições comuns que são usadas em diferentes especificações complementares. Por exemplo, tanto OPC UA para dispositivos analisadores quanto OPC UA para máquinas são construídos diretamente na parte 100.

Em contraste com as especificações baseadas em COM, as especificações UA não são puras especificações de aplicativo. Eles descrevem os mecanismos internos típicos do UA, que são tratados por meio da pilha de comunicação e normalmente são de interesse apenas para aqueles que transferem uma pilha para um destino específico ou para aqueles que desejam implementar sua própria pilha de UA.

Os desenvolvedores de aplicativos OPC UA codificam contra a API OPC UA e, portanto, usam principalmente a documentação da API. No entanto, as partes 3, 4 e 5 podem ser de interesse para desenvolvedores de aplicativos.

Discussão

A especificação do protocolo OPC UA consiste em 14 documentos para um total de 1250 páginas. Devido a essa complexidade, as implementações existentes geralmente são incompletas. Além disso, a existência de vários formatos de serialização, bem como a possibilidade de implementação seletiva de determinados serviços como o PubSub, acabam por levar a uma grande heterogeneidade dos pontos de conexão OPC UA. Nessas condições, é finalmente difícil desenvolver aplicativos cliente que sejam independentes da implementação específica de cada servidor. Nesse sentido, OPC UA não cumpre sua promessa de garantir uma boa interoperabilidade dos sistemas. Isso pode ser visto tipicamente em projetos de fábrica e infraestrutura que integram várias tecnologias de PLC, cada uma entregue com uma implementação diferente e limitada do protocolo OPC UA.

A especificação ainda está em evolução, o último volume do documento de especificação 14 é datado de 6 de fevereiro de 2018, enquanto a primeira publicação do padrão OPC UA data de 2006.

Como resultado, apesar dos esforços consideráveis ​​de marketing para apoiar sua adoção, o OPC UA pode ser considerado, neste estágio, uma tentativa de padronização em vez de um padrão estabelecido.

Pilha de comunicação UA

A arquitetura de um aplicativo UA, independentemente de ser a parte do servidor ou do cliente, é estruturada em níveis.

Algumas partes se equiparam ao antigo COM Proxy / Stubs e são fornecidas pela OPC Foundation. O nível de portabilidade é novo; ele simplifica a portabilidade da pilha UA ANSI C para outras plataformas de destino. Uma camada de porta para Windows e Linux também é fornecida pela OPC Foundation.

Segurança UA

UA Security consiste em autenticação e autorização, criptografia e integridade de dados por meio de assinaturas. Para Web Services, o WS-SecureConversation é usado e, portanto, compatível com .NET e outras implementações SOAP . Para a variante binária, os algoritmos de WS-SecureConversation foram seguidos e também convertidos em um equivalente binário. Isso é denominado UA Secure Conversation.

Também existe uma versão mista em que o código é binário, mas a camada de transporte é SOAP. Este é um meio-termo entre a codificação binária eficiente e a transmissão amigável ao firewall. A codificação binária sempre requer o UA Secure Conversation. A autenticação usa certificados X.509 exclusivamente. Ele depende do desenvolvedor do aplicativo para escolher a qual armazenamento de certificado o aplicativo UA será vinculado. Por exemplo, é possível usar a infraestrutura de chave pública (PKI) de um Active Directory .

Tipos de dados integrados

O padrão OPC UA define 25 tipos de dados integrados:

Tipos de dados integrados OPC UA
Tipo integrado C / C ++ equivalente Detalhes Tipo NodeId
boleano bool 0/1 (verdadeiro ou falso) 0 (numérico)
SByte int8_t -128 a 127
Byte uint8_t 0 a 255
Int16 int16_t -32768 a 32767
UInt16 uint16_t 0 a 65535
Int32 int32_t -2147483648 a 2147483647
UInt32 uint32_t 0 a 4294967295
Int64 int64_t -9223372036854775808 a 9223372036854775807
UInt64 uint64_t 0 a 18446744073709551615
Flutuador flutuador Valor de ponto flutuante de precisão única IEEE (32 bits)
Dobro Duplo Valor de ponto flutuante de precisão dupla IEEE (64 bits)
StatusCode uint32_t
Fragmento uint8_t * / std :: string 3 (corda)
Data hora int64_t número de intervalos de 100 nanossegundos desde 01/01/1601 (UTC)
GUID dependente de implementação Número de 16 bytes usado como um identificador único 4 (GUID)
ByteString (igual a String) 5 (string de bytes)
XmlElement (igual a String)
NodeId índice de namespace e tipo de NodeId
ExpandedNodeId (semelhante a NodeId)
QualifiedName índice e string de namespace
LocalizedText string e um indicador de localidade
NumericRange string (por exemplo, "0: 4,1: 5" para a matriz [0..4] [1..5])
Variante (apenas tipos de dados integrados)
ExtensionObject escalares de qualquer tipo
DataValue um composto de um valor, carimbos de data / hora e código de status
DiagnosticInfo informações detalhadas de erro / diagnóstico

APIs OPC UA

UA APIs estão disponíveis em várias linguagens de programação. SDK comercial está disponível para C, C ++, Java e .NET. Pilhas de código aberto estão disponíveis pelo menos para C, C ++, Java, Javascript (nó), Tcl e Python [1] .

Implementação C ++ / C

  • O projeto open62541 fornece uma implementação de código aberto para o servidor OPC UA e clientes e está licenciado sob a Mozilla Public License v2.0. Além de Linux e Windows, ele também suporta OS X, QNX e diferentes sistemas embarcados como alvo de compilação.
  • O projeto S2OPC fornece uma implementação segura de código aberto e é licenciado sob a licença Apache 2.0 . Suporta Linux, Windows, FreeRTOS, Zephyr, VxWorks e tem como objetivo ser seguro, seguro e rápido. O núcleo do software é formalmente projetado com a ajuda do B-Method .
  • O projeto ASNeG fornece um C ++ open source (Apache License 2.0) OPC UA Application Server e um OPC UA Web Server (estado beta, atualmente apenas funções básicas).
  • O projeto FreeOpcUa fornece um servidor de código aberto ( LGPL ) e implementação de cliente em C ++.
  • O projeto UAF oferece uma implementação C ++ / Python de código aberto (LGPL).

Implementação .NET

A implementação .NET usa ANSI C para os níveis inferiores e implementa o resto nativamente em .NET. Isso significa que apenas o manuseio do soquete e do Message-Chunking é integrado a partir da pilha ANSI C. A desserialização ocorre diretamente no .NET e, portanto, é convertida diretamente em estruturas e objetos .NET. Isso fornece melhor desempenho do que a desserialização em uma estrutura C primeiro e, em seguida, copiar os dados para uma estrutura .NET.

Implementação Java

Várias pilhas para Java estavam sendo desenvolvidas. Semelhante ao .NET, existem principalmente três variantes:

  1. Encapsule a pilha ANSI C completa via JNI , o que complica a portabilidade. Embora a pilha possa ser transferida para diferentes sistemas operacionais, ela precisa ser compilada individualmente. Além disso, os dados precisam ser copiados para o limite JNI, mas se beneficiam do desempenho de C durante a desserialização.
  2. Codifique diretamente na camada de rede (semelhante à implementação atual .Net) e desserialize em Java. Isso salva uma execução de cópia de dados, mas ainda depende da pilha C.
  3. Escreva uma pilha Java OPC UA nativa. Observou-se que este é o mais portátil, mas estima-se que exige o maior esforço de engenharia para ser implementado. O projeto Eclipse Milo fornece uma implementação em Java puro e de código aberto da especificação de cliente e servidor UA 1.03.

Como alternativa, existe a variante simples para suportar apenas o protocolo WebService. Para isso, é necessário um SOAP Toolkit que suporte WS-Security .

Implementação de JavaScript e Typescript

node-opcua é uma implementação completa da OPC UA para cliente e servidor inteiramente escrita à máquina para Node.js .

Implementação Python

  • O projeto FreeOpcUa fornece duas implementações em linguagem de programação Python pura - opcua-asyncio (requer Python> = 3.7) e python-opcua (compatível com Python 2, 3 e pypy; requer Cython para a biblioteca lxml, mas está em modo de manutenção e opcua-asyncio é recomendado). Ambos fornecem abstrações de alto nível de um cliente e servidor OPC UA que podem ser usados ​​como estão ou prontamente estendidos para aplicativos personalizados.
  • A implementação S2OPC C fornece um wrapper PyS2OPC para Python .

Implementação de ferrugem

O Rust for OPC UA fornece uma API e exemplos para a implementação de clientes e servidores OPC UA até o nível de perfil integrado. Isso inclui suporte para criptografia, assinaturas e o conjunto de nós padrão.

Implementação de TypeScript / JavaScript

O cliente OPC UA TypeScript / JavaScript para o navegador é um cliente OPC UA que funciona no navegador. Ele é totalmente escrito em TypeScript e compilado em JavaScript. O código-fonte está disponível publicamente e possui uma licença do MIT. Inclui codificação de dados binários OPC UA e usa WebSockets como protocolo de transporte.

Implementação Tcl

Topcua é uma ligação Tcl ao cliente e servidor OPC UA. Ele fornece várias operações para gerenciar e se comunicar usando a implementação OPC UA. Ele está disponível em plataformas POSIX e Windows comuns.

IEC 62541

IEC 62541 é um padrão para Arquitetura Unificada OPC.

Visão geral do IEC 62541
EU IRIA data de lançamento título
IEC / TR 62541-1 2016 Arquitetura Unificada OPC - Parte 1: Visão Geral e Conceitos
IEC / TR 62541-2 2016 Arquitetura Unificada OPC - Parte 2: Modelo de Segurança
IEC 62541-3 2020 Arquitetura Unificada OPC - Parte 3: Modelo de Espaço de Endereço
IEC 62541-4 2020 Arquitetura Unificada OPC - Parte 4: Serviços
IEC 62541-5 2020 Arquitetura Unificada OPC - Parte 5: Modelo de Informação
IEC 62541-6 2020 Arquitetura Unificada OPC - Parte 6: Mapeamentos
IEC 62541-7 2020 Arquitetura Unificada OPC - Parte 7: Perfis
IEC 62541-8 2020 Arquitetura Unificada OPC - Parte 8: Acesso a Dados
IEC 62541-9 2020 Arquitetura Unificada OPC - Parte 9: Alarmes e Condições
IEC 62541-10 2020 Arquitetura Unificada OPC - Parte 10: Programas
IEC 62541-11 2020 Arquitetura Unificada OPC - Parte 11: Acesso Histórico
IEC 62541-12 2020 Arquitetura unificada OPC - Parte 12: Descoberta e serviços globais
IEC 62541-13 2020 Arquitetura Unificada OPC - Parte 13: Agregados
IEC 62541-14 2020 Arquitetura unificada OPC - Parte 14: PubSub
IEC 62541-100 2015 Arquitetura Unificada OPC - Parte 100: Interface do Dispositivo

Veja também

Referências

Literatura

  • Wolfgang Mahnke, Stefan-Helmut Leitner, Matthias Damm: Arquitetura Unificada OPC. Springer Verlag 2009; ISBN  978-3-540-68898-3
  • Lange, J., Iwanitz, F., Burke, T. OPC From Data Access to Unified Architecture 2010; ISBN  978-3-8007-3242-5

links externos