implementando comunicação opc ua determinísca · exemplo, a tecnologia opc ... da linguagem de...
TRANSCRIPT
Implementando ComunicaçãoOPC UA Determinís�ca
Sumário
Nos úl�mos anos, o OPC UA provou ser o principal padrão independente de troca de dados entre diferentes disposi�vos, capaz de suportar vários sistemas operacionais e integrar diferentes níveis de automação.
No entanto, ao analisarmos detalhadamente os requisitos para implementar a IIoT (Industrial Internet of Things) e "Industria 4.0", descobrimos que o padrão OPC UA baseado numa arquitetura Cliente/Servidor não é o modelo ideal. Como consequência, a OPC Founda�on está em processo de padronização do OPC UA Publisher/Subscriber como modelo adicional de comunicação.
Do ponto de vista teórico, o modelo de comunicação OPC UA Publisher/Subscriber é ideal para atender às necessidades de uma aplicação de IIoT. Até agora, no entanto, ainda não havia sido realizada uma avaliação prá�ca das capacidades e recursos do OPC UA Publisher/Subscriber.
Este documento fornece uma visão geral de um protó�po de implementação da pilha (stack) OPC UA Publisher/Subscriber e mostra em detalhes os resultados das medições de tempo que foram realizadas com base neste demonstrador.
Distribuidor Autorizado
Autores:Cris�an Pogacean (Product Manager OPC - So�ing Industrial Automa�on GmbH )
Sebas�an Broschei (Development OPC - So�ing Industrial Automa�on GmbH )
Georg Süss (Opera�onal Marke�ng - So�ing Industrial Automa�on GmbH )
Tradução: Paolo Capecchi (Westcon Instrumentação Industrial Ltda)
Índice
1. Introdução ao OPC UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Do OPC Classic ao OPC UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Visão Geral do OPC UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Implementando a Internet Industrial das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Implementando a Internet Industrial das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Casos de Aplicações que Requerem Recursos de Comunicação do Publisher/Subscriber. . . . . . . . . . . . . . . . . . . 5
2.1.2 Casos de Aplicações que Requerem Recursos de Comunicação Determinís�ca Publisher/Subscriber . . . . . . . . . 8
2.2 OPC UA Publisher/Subscriber Communica�on Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Time-Sensi�ve Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Prova de Conceito do Ambiente de Internet Industrial das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Infraestrutura do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Medições usando o Demonstrador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Resultados das Medições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Sobre a So�ing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 2
1 Introdução ao OPC UA
1.1 Do OPC Classic ao OPC UA
O padrão OPC para a troca de dados foi inicialmente baseado no uso de plataformas PC com sistemas
operacionais Windows.
O modelo COM/DCOM (Distributed) Component Object Model da Microso� foi usado como a tecnologia
base para o padrão OPC. Este laço estreito impôs uma série de restrições ao uso da tecnologia OPC. Por
exemplo, a tecnologia OPC baseada em DCOM não é adequada para comunicação pela Internet, para o
uso de firewalls ou para operação em plataformas não-Windows.
Em par�cular, a configuração da troca de dados entre PCs requer vasta experiência em configurações de
segurança DCOM. Como o COM / DCOM foi descon�nuado pela Microso�, esta tecnologia não está mais
sendo desenvolvida e já não conta mais com suporte.
Além disso, novas demandas relacionadas à troca de dados OPC surgiram na indústria no que diz
respeito a suporte à segurança, proteção contra perda de dados, recursos de redundância e suporte para
conexões de dados complexas, por exemplo.
Em resposta a esta situação, a OPC Founda�on desenvolveu uma versão totalmente revisada e
expandida do padrão OPC que elimina os pontos fracos da tecnologia OPC clássica. Esta versão
independe do sistema operacional empregado, da linguagem de programação e de tecnologias
proprietárias. É independente do fabricante e suporta escalabilidade, alta disponibilidade e capacidade
de Internet. Esta nova geração de tecnologia OPC foi lançada sob o nome de OPC UA (Unified
Architecture), enquanto a clássica tecnologia OPC é agora conhecida como OPC Classic.
As figuras 1 e 2 ilustram as principais diferenças entre OPC Classic e OPC UA.
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 3
Artigo Técnico
Figura 1: Arquitetura do OPC Classic u�lizando Windows PCs e tecnologia Microso� DCOM para Troca de Dados
Figura 2: Arquitetura de Troca de Dados Simplificada u�lizando OPC UA
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 4
MES/ERP
MES Interface
Windows PC
OPC UA Client
PLC
OPC Server
Internet
OPC Server
Windows PC
OPC Client
Tunnel Tunnel
Windows PC
OPC Server
Driver
PLC
Internet
MES/ERP
MES Interface
Windows PC
OPC Client
1.2 Visão geral do OPC UA
OPC UA é um padrão aberto e gratuito especificado na norma IEC62541. Ao contrário do OPC Classic, o
OPC UA u�liza um modelo de informação orientado a objetos, que suporta estruturas, objetos,
máquinas de estado, base legada, etc. Além disso, u�liza a recém-lançada arquitetura orientada a
serviços (SOA) que permite a fácil personalização do OPC UA. O OPC UA possibilita a troca de dados
brutos e informações pré-processadas entre os sistemas incorporados nos sensores e nos disposi�vos de
campo e os sistemas de ERP, MES e de visualização de processos (IHM), assegurando que todos os dados
estejam disponíveis para qualquer aplicação e para quaisquer pessoas autorizadas em qualquer lugar e a
qualquer hora. Para trocar dados, o OPC UA usa um protocolo binário o�mizado baseado em TCP. Basta
abrir uma única porta no firewall.
O OPC UA incorpora conceitos de segurança da Internet comprovados, como o Secure Sockets Layer
(SSL), TLS (Transport Layer Security) e Advanced Encryp�on Standard (AES), que protegem contra o
acesso não autorizado, modificações de valores de processo, sabotagem e falhas causadas por uso
negligente. Os recursos de segurança são uma parte obrigatória do padrão e incluem auten�cação de
usuário e de aplica�vo, assinaturas digitais de mensagem e criptografia de dados transmi�dos. Os
usuários podem combinar livremente os diferentes recursos de segurança de acordo com suas
necessidades específicas, para que possam criar soluções escaláveis.
OPC UA u�liza uma arquitetura robusta com mecanismos de comunicação confiáveis, monitoramento de
tempo configurável e detecção automá�ca de falhas. Os mecanismos de correção de falha restabelecem
automa�camente o link de comunicação entre o OPC UA Client e o OPC UA Server sem perda de dados.
O OPC UA fornece funcionalidade de redundância que pode ser integrada a aplicações Client e Server a
fim de proporcionar alta disponibilidade do sistema e máxima confiabilidade.
OPC UA representa processos de automação usando um espaço de endereçamento integrado e um
modelo de informação comum baseado em objetos e variáveis, requisições metódicas de dados de
processo, alarmes e status e a exibição de dados históricos. Além de cobrir toda a funcionalidade do OPC
Classic, o OPC UA fornece recursos para descrever procedimentos e sistemas complexos em
componentes padronizados orientados a objetos. Os consumidores de informações que só suportam as
regras básicas podem processar os dados mesmo sem conhecer as inter-relações das estruturas
complexas de um server. A aplicabilidade universal da tecnologia OPC UA possibilita a implementação de
conceitos completamente novos de integração ver�cal. Ao conectar em cascata os componentes OPC
UA, as informações podem ser transportadas de forma segura e confiável desde o nível da produção
para os sistemas ERP e MES. Isso é conseguido estabelecendo uma conexão direta entre os OPC UA
servers incorporados no nível de campo e os OPC UA clientes integrados em sistemas de nível
corpora�vo. Os componentes individuais do OPC UA podem ser distribuídos geograficamente e
separados uns dos outros por firewalls. Isto torna o OPC UA ideal para uso em sistemas distribuídos.
Como resultado, a OPC UA ocupa uma posição importante na visão de futuro da produção industrial
como parte de um ambiente totalmente inteligente (ver Figura 3). Além disso, o OPC UA permite que
outros organismos de padronização u�lizem os serviços do OPC UA como transportes para seus próprios
modelos de informação.
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 5
Figura 3: Visão da Produção Industrial do Futuro como parte de um ambiente totalmente inteligente
Em resumo, o OPC UA u�liza uma tecnologia muito poderosa e padronizada para a troca de dados
industriais. Ele é baseado em um modelo de comunicação Cliente/Servidor que requer uma conexão
estabelecida.
Vantagens do OPC UA:
Ÿ Fornece os meios para troca segura de dados entre plataformas.
Ÿ Oferece interoperabilidade entre plataformas de vários fabricantes.
Ÿ É mais do que um protocolo de comunicação pura. Também aborda semân�ca e capacidades de
modelagem para representar sistemas �sicos complexos em modo digitalizado.
Ÿ Pode ser u�lizado para implementar interoperabilidade entre diferentes protocolos de comunicação
padronizados.
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 6
2 Implementando a Internet Industrial das Coisas (IIoT)
Por oferecer a solução ideal para as necessidades e exigências específicas da indústria, o padrão do OPC
UA tem grande potencial para o futuro. Afinal, OPC UA é considerada como sendo a tecnologia de troca
de dados para a futura implementação da Internet Industrial das Coisas (IIoT) e "Industria 4.0". ¹
2.1 Implementando da Internet Industrial das Coisas
Examinando em detalhes os vários cenários para implementações IIoT, logo se torna claro que os
requisitos de comunicação relacionados não se adequam perfeitamente às capacidades de comunicação
tais como definidas até agora pelo padrão OPC UA. Para entender esta questão discu�remos,
inicialmente, vários casos de implementações do IIoT, conforme definido pela Fundação OPC. Estes casos
de aplicações podem ser categorizados como comunicações de grande escala de um para muitos, de
muitos para um ou de muitos para muitos. A comunicação configurada de controlador para controlador
também se encontra incluída aqui.
2.1.1 Exemplos de Aplicações que Requerem Recursos de Comunicação Publisher/Subscriber
Ao discu�r possíveis implementações de IIoT, encontramos diferentes cenários que não se encaixam
bem numa arquitetura Client/Server conforme definido pelo padrão OPC UA. Nesses casos o modelo
Publisher/Subscriber é mais apropriado. A Tabela 1 apresenta um resumo desses casos de aplicação. ²
¹ Indústria 4.0 é uma inicia�va liderada pelo governo alemão para a implementação da Internet Industrial das Coisas.² Os casos de aplicações apresentados nesta seção forma extraídos do documento da OPC Founda�on Use Cases-OpcUa-PubSub, version 0.09.
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 7
Exemplo de Aplicação Descrição
Public Subscrip�on Muitos Clients demandam informações sobre mudanças de configuração de uma
lista de variáveis. A troca de dados ocorre após a configuração inicial do sistema ou
sempre que houver alteração de configuração.
O modelo Client/Server não é muito eficiente para lidar com esta situação pelas
seguintes razões:
Ÿ Precisa estabelecer uma grande quan�dade de conexões Client/Server.
Ÿ Cada Client precisa disponibilizar memória para armazenamento das
informações da conexão assim como os valores individuais das variáveis.
Ÿ A codificação das mensagens individualmente para cada conexão estabelecida
gera uma elevada carga para o processador do Server. A carga será ainda maior
se os Clients possuírem intervalos de amostragem diferentes (sampling rates)
para as variáveis.
Secure Mul�cast O Server precisa enviar valores de dados para muitos Clients. A troca de dados pode
ocorrer de forma cíclica ou sempre que houver uma mudança de valor.
Many-to-One Publishing Um ou mais Client(s) situados na Cloud precisam de dados de grande quan�dade
(milhares) de disposi�vos situados atrás do firewall. A troca de dados pode ocorrer
de forma cíclica ou quando disparada por um trigger (que pode ser a mudança de
valor, qualidade ou um alarme).
Não se consegue lidar com este cenário visto que a quan�dade de conexões abertas
é grande demais para poderem ser processadas em paralelo.
Machine-to-MachineCommunica�on
Máquinas da planta precisam trocar dados de processo tanto “downstream” com
outros equipamentos quanto “upstream” com sistemas SCADA, assegurando o
tempo de entrega dos dados end-to-end na faixa de 2 a 100 ms. Dados de processo
podem conter informações de status e controle como, por exemplo,
PackML/PackTags segundo definição do ISA Technical Report TR88.00.02. A troca de
dados ocorre de forma cíclica.
Dynamic Network Rela�ons Disposi�vos móveis, tais como robôs, equipamentos de medição ou partes
opcionais de maquinário podem ser facilmente adicionados ou removidos de uma
máquina (por exemplo, um robô juntamente com seu disposi�vo portá�l de
configuração ou acesso remoto). A máquina e os disposi�vos móveis possuem
controladores separados que precisam se comunicar em modo determinís�co.
Disposi�vos móveis, dependendo do �po, podem executar diferentes tarefas (por
exemplo, um robô móvel pode aplicar cola em uma estação de trabalho, soldar em
outra estação e manipular peças numa terceira estação, etc...). Quando um
disposi�vo móvel é conectado a uma máquina, é preciso estabelecer uma relação
de comunicação apropriada, que inclua todas as variáveis e funções específicas
daquele disposi�vo em questão. A troca dos dados de processo ocorre de forma
cíclica. Também ocorre a troca de dados das funções de acesso remoto.
Tabela 1: Casos de aplicações que demandam troca de dados que estão além dos recursos de escopo do OPC UA Client/Server
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 8
Exemplo de Aplicação Descrição
OPC UA Mul�-HMI Sistemas de controle complexos demandam dados servidos simultaneamente para
muitos Clients. Por exemplo, várias IHMs podem exibir informações idên�cas
espalhadas por toda a planta a fim de proporcionar ao operadores acesso às
informações onde quer que estejam. Além disso, para suportar IHMs específicas é
preciso também suportar conjuntos de configurações pré-definidas que precisarão
ser comunicados também. Uma estrutura �pica para troca de dados compreende
até 30.000 pontos de dados servidos para 50 a 100 Clients a uma taxa de
atualização dejada de 200 ms.
A troca de dados ocorre de forma cíclica, mas eventos assíncronos também
precisam ser comunicados para múl�plas IHMs simultaneamente para que possam
ser acessados em qualquer lugar da planta. Assim que um usuário efetua o
reconhecimento de um alarme ou executa outra interação através de uma IHM, esta
IHM passa a controlar o status do evento correspondente.
Controller-to-ControllerCommunica�on
Comunicação Controller-to-Controller pode ser executada tanto com base em
blocos de programação do PLC (Programmed Controller-to-Controller
Communica�on) quanto através de uma ferramenta central de configuração
(Configured Controller-to-Controller Communica�on).
Para estabelecer ou modificar a Programmed Controller-to-Controller
Communica�on é preciso efetuar alterações no programa do PLC, enquanto que
para a�ngir o mesmo obje�vo com a Configured Controller-to-Controller
Communica�on basta uma interface de configuração padronizada, sem que haja
necessidade de alterar o programa do PLC.
Data Streaming Um Server fornece um “stream” de valores medidos muito rápido, mas não se exige
o transporte confiavel. Esse “stream” de dados pode ser transferido em alta
velocidade tanto con�nuamente quanto por um determinado período de tempo. A
troca de dados pode ocorrer tanto em modo permanente quanto sob demanda.
Video/Audio StreamingManagement(Audio Streaming)
Um Server fornece accesso a um sistema com fontes de vídeo e/ou áudio
disponíveis. Este �po de Server suporta ações de controle tais como zoom de
câmeras ou alterações de ajustes para “streams” de vídeo e áudio por meio dos
serviços e protocolos padronizados OPC UA, enquanto o “stream” de vídeo e áudio
é transferido através de outro canal u�lizando protocolos padronizados de
streaming de vídeo e áudio.
Tabela 1: Casos de aplicações que demandam troca de dados que estão além dos recursos de escopo do OPC UA Client/Server (con�nuação)
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 9
2.1.2 Casos de Aplicação que Requerem Recursos de Comunicação Determinís�ca Publisher/Subscriber
Além dos casos de aplicação descritos na Seção 2.1.1, existem casos adicionais que, além do suporte de
um modelo de comunicação Publisher/Subscriber, também requerem um comportamento de
comunicação determinís�ca. A Tabela 2 fornece uma visão geral desses casos de aplicações.³
Exemplo de Aplicação Descrição
Cyclic Controller-to-ControllerCommunica�on
Máquinas de corte a laser demandam comunicação cíclica entre controladores
(PLCs, CNCs, Laser Controllers) com tempo de ciclo de 1 ms.
Como essa comunicação é u�lizada para funções de controle, latência e Ji�er têm
que ser mínimos. Além da comunicação crí�ca, existe também a comunicação cíclica
não-crí�ca e a comunicação baseada em eventos como, por exemplo, para a
visualização de dados (IHM) ou para a troca de dados com sistemas MES/ERP.
Event-based Controller-to-ControllerCommunica�on
Sistemas de iden�ficação e manuseio de pacotes/encomendas precisam trocar
dados com sistemas de câmeras e RFID, e também com PLCs, para funções de
triagem e classificação durante a operação normal. A troca de dados é baseada em
eventos (até 18 eventos por segundo) e é definida pela presença do objeto (pacote).
Como essa comunicação é u�lizada para funções de controle, a latência mínima
desejada é de 100 ms. São executadas também as comunicações cíclica Não-crí�ca e
a baseada em eventos.
Cyclic Communica�onBetween Smart Sensor and Controller
Para aplicações de medição de distâncias, os sensores laser trocam dados de forma
cíclica com um controlador central ou atuador. Neste caso, o tempo de ciclo
desejado é de 10 ms, resultando em um volume de dados de 15 MB por segundo. O
sincronismo de tempo é necessário para coordenar as medições dos diversos
sensores.
Cyclic Communica�onBetween Robot and Tool Controller
Para a coordenação de ferramentas robó�cas é preciso uma troca de dados cíclica
com tempo de ciclo de 1 a 5 ms. Como essa comunicação é u�lizada para funções
de controle, é preciso que a latência seja a menor possível. Além disso, outras
comunicações não-crí�cas ocorrem entre o robô e o controlador de ferramentas a
também para troca de dados com sistemas MES systems e databases, por exemplo.
Cyclic Communica�onBetween Machine Controller and Transporter/Carrier
Para movimentação de materiais através da área de produção é preciso uma
comunicação cíclica entre o controlador e os disposi�vos móveis, com um tempo de
ciclo entre 1 e 5 ms. A latência precisa ser mínima a fim de não prejudicar o controle
dos disposi�vos móveis. Além disso, ocorre a comunicação não-crí�ca entre o
controlador de ferramentas e o transportador.
Safety-Related Communica�on A troca de dados de intertravamentos de segurança é realizada através de um
protocolo seguro. Esse protocolo faz uso de uma camada de comunicação �po
“black channel”, o que significa que há componentes ao longo do link de
comunicação que não são inerentemente seguros. Portanto, a mensagem de
resposta do device na outra ponta tem que ser recebida dentro de um intervalo de
tempo definido. Caso se a�nja o limite máximo de tempo de resposta, a máquina irá
para um estado seguro. A troca de dados bi-direcional ocorre de forma cíclica
baseada em temporização determinís�ca.
Tabela 2: Casos de Aplicações que Demandam Troca de Dados Determinís�ca OPC UA Publisher/Subscriber.
³ Os casos de aplicações apresentados nesta seção foram extraídos do documento OPC Founda�on Use Cases-OpcUa-PubSub-TSN, version 0.04.
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 10
2.2 Modelo de Comunicação OPC UA Publisher/Subscriber
Como as mensagens individuais são enviadas de um remetente para um des�natário neste caso, a troca
de dados OPC via client/server não é muito eficiente para implementar os casos de aplicações descritos
na Seção 2.1. Em vez disso, as mensagens mul�cast e broadcast caberiam nas situações descritas. Como
consequência, a OPC Founda�on começou a trabalhar em um novo modelo de comunicação OPC UA
Publisher/Subscriber que atende a esses requisitos. Uma visão geral dos componentes usados para
comunicação OPC UA Client/Server Subscriber e para comunicação OPC UA Publisher/Subscriber pode
ser encontrada na Figura 4.
Figura 4: Comparação dos modelos de comunicação OPC UA Client/Server e OPC UA Publisher/Subscriber
O modelo de comunicação do OPC UA Publisher/Subscriber define a troca de mensagens entre um editor
(Publisher) e uma lista de assinantes (Subscribers) dentro de uma arquitetura distribuída. Para que essa
troca ocorra, é necessária uma infraestrutura apropriada que permita que os editores enviem mensagens
sem saber se existem assinantes e quem são estes. Da mesma forma, os assinantes se comunicam com
esta infraestrutura para expressar seu interesse em certos �pos de mensagens, recebendo apenas
mensagens que são de interesse sem saber quem são, se houver, os editores. Como resultado, o modelo
de comunicação OPC UA Publisher/Subscriber reduz a carga no lado do provedor de informações
coletando e enviando os dados necessários apenas uma vez para vários des�natários (aplicações) a uma
taxa definida individualmente. A estrutura geral da comunicação OPC UA Publisher/Subscriber é
mostrada na figura 5.
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 11
Dependendo do caso de aplicação específico, o modelo de comunicação OPC UA Publisher/Subscriber
pode ser implementado de diferentes formas. A opção ideal para implementação dos casos de aplicação
IIoT descritos na Secção 2.1, que requerem uma rede local rápida, baseia-se no protocolo Secure
Datagram Protocol (UDP) Secure Mul�cast. Ele permite a implementação de “stacks” de protocolo
pequenos e eficientes para o tratamento de mensagens e também suporta a troca cíclica de dados. A
comunicação é caracterizada por uma pequena carga e uma troca rápida e confiável de dados, enquanto
que o modelo de informação de OPC UA especificado não precisa ser modificado.
Além do protocolo UDP Secure Message, outros protocolos são definidos para o modelo de comunicação
OPC UA Publisher/Subscriber, como o Advanced Message Queuing Protocol (AMQP), que é indicado para
a entrega de mensagens a assinantes dentro de uma rede global, por exemplo, em nuvem.
Dentro do escopo deste documento, o modelo de comunicação OPC UA Publisher/Subscriber é discu�do
com base no protocolo UDP Secure Mul�cast.
Figura 5: Aplicações OPC UA Publisher e Subscriber (Fonte: OPC Founda�on)
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 12
2.3 Redes Sensíveis ao Tempo (Time-Sensi�ve Networking – TSN)
Ao comparar os requisitos dos casos de aplicação apresentados na Seção 2.1 e, em especial, na Seção
2.1.2, com os recursos oferecidos pelo modelo de comunicação OPC UA Publisher/Subscriber, fica
evidente que a maioria dos requisitos é atendida, mas a necessária troca de dados determinís�ca não
pode ser assegurada. Por conseguinte, uma abordagem adicional se faz necessária.
Os detalhes dos requisitos a serem tratados incluem:
Ÿ Os nós individuais da rede têm que trabalhar com base em sincronismo de tempo. Logo, é preciso
haver um relógio comum a todo o sistema, por exemplo, para agendar a transmissão de dados ou
executar uma entrada e saída correlacionadas de dados.
Ÿ Redundância de caminhos é necessária para garan�r a troca de dados mesmo em caso de falhas de
componentes específicos dentro da rede. Isso aumenta a confiabilidade da comunicação e
estabelece um sistema tolerante a falhas.
Ÿ Para loops de controle determinís�cos, a comunicação entre nós individuais deve ocorrer dentro de
um tempo de latência predefinido.
Ÿ Deve poder reservar uma determinada largura de banda para troca de dados entre aplicações
crí�cas, a fim de garan�r a confiabilidade da operação mesmo em presença de alta carga de tráfego
e conges�onamento de rede.
O comportamento de comunicação determinís�ca em um ambiente Ethernet Industrial que atenda aos
requisitos descritos acima pode ser ob�do usando o padrão TSN (Time-Sensi�ve Networking). Este é
baseado no padrão Audio-Visual Bridging (AVB) lançado em 2011 e é considerado como um bom ponto
de par�da para a implementação de aplicações industriais.
O padrão TSN resultante fornece alguns aprimoramentos em comparação com o padrão AVB, que são
definidos por um conjunto de sub-normas Ethernet IEEE 802. Estas permitem recursos de agendamento
de horário (�me-scheduling) e, como resultado, uma comunicação totalmente determinís�ca em tempo
real. Isso é ob�do usando sincronismo de tempo global juntamente com um cronograma que é
compar�lhado entre os vários componentes de rede.
Este cronograma oferece intervalos de tempo reservados (�me slots) dentro de um ciclo de tempo TSN
completo que pode ser usado para transferir mensagens prioritárias, resultando em um limite máximo
de latência para o tráfego agendado em uma rede comutada.
3 Prova de Conceito do Ambiente da Industrial Internet das Coisas
Em teoria, tanto o modelo OPC UA Publisher/Subscriber como as tecnologias Time-Sensi�ve Networking
descritas no Capítulo 2 são capazes de permi�r uma troca de dados determinís�ca como exigido para
implementações IIoT. Antes de u�lizar estas tecnologias em aplicações reais, no entanto, é necessário
verificar a adaptabilidade desta abordagem. Este capítulo aborda, portanto, o protó�po de instalação de 4
um ambiente que incorpora essas tecnologias.
⁴ A instalação deste protó�po foi desenvolvida e configurada pela So�ing
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 13
3.1 Infraestrutura do Teste
A configuração da infraestrutura de teste incluiu a implementação da pilha OPC UA Publisher/Subscriber
em conjunto com uma interface OPC UA Client e Server. Esta interface fornece um meio genérico para
estabelecer um aplica�vo de comunicação para troca de dados baseado em OPC UA Client e Servers
existentes. Esta implementação foi realizada para um disposi�vo que inclui uma matriz de portas
programáveis e m campo (Field Programmable Gate Array - FPGA). A arquitetura do FPGA do disposi�vo é
mostrada na Figura 6.
Figura 6: Arquitetura do Disposi�vo Suportando o Modelo de Comunicação OPC UA Publisher/Subscriber
Para inves�gar o comportamento temporal da comunicação baseada em OPC UA Publisher/Subscriber
numa rede TSN, um demonstrador foi configurado u�lizando os disposi�vos OPC UA
Publisher/Subscriber como principais componentes.
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 14
OPC UAPublisher/Subscriber
TSN (Ethernet) Network
Frame Generator
Embedded Embedded
• 2 disposi�vos
Executam um aplica�vo de exemplo com base em uma configuração está�ca OPC UA
Publisher/Subscriber
A troca de dados é realizada com base no modelo de comunicação OPC UA Publisher/Subscriber usando
a pilha (stack) OPC UA Publisher/Subscriber.
Estes disposi�vos são switches Ethernet Industriais ⁵ e proporcionam uma interface Ethernet padrão.
• 2 Switches Ethernet
Suportam o padrão TSN, permi�ndo assim o tráfego Ethernet baseado em um cronograma TSN
• Frame Generator
Usado para gerar carga adicional na rede Ethernet
• Ferramenta de Análise
U�lizado para gravar e analisar o tráfego de rede
Nota:
Como a infraestrutura de teste inclui apenas dois disposi�vos habilitados para TSN, nenhuma
sincronização de horário geral ainda está configurada. A Fig. 7 exibe a arquitetura deste demonstrador.
Figura 7: Arquitetura básica do Demonstrador OPC UA Publisher/Subscriber
⁵ Os switches aqui aplicados u�lizam o Switch IP Core da So�ing, que foi desenvolvido especialmente para suportar funcionalidades de Ethernet Industrial específicas (PROFINET IRT, por exemplo) em ambiente FPGA.
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 15
3.2 Medições usando o demonstrador
O demonstrador introduzido na Seção 3.1 foi usado para medir o Ji�er (intervalo entre frames
individuais enviados). Esta medição é realizada com e sem suporte de comunicação de rede TSN.
O obje�vo desta medição foi o de determinar a variação do Ji�er ao enviar frames OPC UA
Publisher/Subscriber.
A medição de Ji�er é realizada da seguinte forma:
1. Inserir a ferramenta de análise entre o disposi�vo de recepção e o Switch Ethernet
2. Iniciar a troca de dados OPC UA Publisher/Subscriber u�lizando um intervalo de envio configurado
de 10 mseg.
3. Registrar o Ji�er com e sem suporte à comunicação de rede TSN usando um tempo de ciclo TSN
configurado de 0,5 mseg.
4. Gerar tráfego de fundo com base em 70.000 pacotes por segundo.
5. Registrar o Ji�er com e sem suporte à comunicação de rede TSN usando um tempo de ciclo TSN
configurado de 0,5 mseg.
3.3 Resultados das medições
As figuras 8 e 9 fornecem uma visão geral do Ji�er medido para a comunicação OPC UA
Publisher/Subscriber.
Em redes Ethernet padrão, os resultados de Ji�er mostram uma certa faixa, mesmo quando não se
adiciona nenhum tráfego. Com tráfego em segundo plano (Background Traffic) adicional, a largura de
banda cresce ainda mais (ver Figura 8).
Usando TSN - Time-Sensi�ve Networking, o trigger medido está in�mamente ligado ao intervalo de
tempo configurado de 10 ms. Apenas uma pequena parte da comunicação é realizada no próximo ciclo
TSN, resultando em um intervalo de tempo adequadamente reduzido para a troca de dados
subsequente. Esse efeito é decorrente do fato de que não há sincronização de horário geral entre os
vários disposi�vos de rede. Em geral, esse comportamento não sofre alteração quando se adiciona
“Background Traffic” à rede (veja a Figura 9).
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 16
Figura 8: Resultados da medição de Ji�er com e sem Background Traffic, sem o uso de TSN-enabled Networks
Figura 9: Resultados da medição de Ji�er com e sem Background Traffic usando TSN-enabled Networks
4 Resumo
Em combinação com Time-Sensi�ve Networking, o modelo de comunicação OPC UA
Publisher/Subscriber melhora significa�vamente o comportamento determinís�co de tempo quando
comparado com a comunicação OPC UA Client/Server tradicional. Em par�cular, verificou-se que carga
adicional na rede não resulta em qualquer deterioração das a�vidades de comunicação e, paralelamente
a isto, a largura de banda disponível não é desperdiçada por restrições das mensagens transferidas. Esta
abordagem, portanto, atende os requisitos de comunicação específicos de aplicações IIoT como
apresentado na Seção 2.1.
Para implementar a solução aqui discu�da, que consiste no modelo de comunicação do OPC UA
Publisher/Subscriber e Time-Sensi�ve Networking, são necessários so�ware e hardware apropriados. É
fundamental, portanto, não basear implementações de IIoT apenas no so�ware disponível. O uso de
hardware adequado é também essencial. ⁶
⁶ Esta constatação alinha-se perfeitamente com a linha de produtos da So�ing, que combina componentes de hardware e so�ware em um FPGA (Field Programmable Field Array)
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 17
5 Sobre a So�ing
A Divisão So�ing Industrial Automa�on faz parte do So�ing Group, fundado em 1979.
A So�ing Industrial Automa�on é uma empresa com atuação global especializada em tecnologias de
comunicação industrial, como redes de automação de campo e Ethernet industrial.
Com mais de 35 anos de experiência, as unidades de negócios de Automação Industrial da So�ing
fornecem conec�vidade, produtos e serviços de diagnós�co a clientes nos segmentos industriais de
manufatura e automação de processos.
Com um histórico de mais de 20 anos de experiência em tecnologia OPC, a So�ing foi escolhida como
parceira para OPC por um grande número de empresas. A So�ing oferece um conjunto completo de
ferramentas de desenvolvimento OPC UA e OPC Classic e produtos para usuários finais. Estes fornecem
um conjunto abrangente de funcionalidades para a implementação de soluções de úl�ma geração para
troca de dados, abordando todos os possíveis problemas de conec�vidade. O por�ólio é complementado
com treinamentos e serviços de desenvolvimento, bem como o livro sobre OPC que é referência
mundial.
A So�ing também desenvolveu um disposi�vo que é uma plataforma genérica baseada na tecnologia
FPGA. Esta plataforma pode ser adaptada a necessidades específicas através de implementação de
hardware e so�ware apropriados no FPGA. Por exemplo, ele é usado para implementar diversos �pos de
disposi�vos Fieldbus e Industrial Ethernet.
Os produtos So�ing são customizados para atender às exigências de integradores de sistemas,
fabricantes de máquinas e equipamentos ou usuários finais, e são conhecidos por sua facilidade de uso e
vantagens funcionais.
6 Referências
Expert Interview: OPC UA Publisher/Subscriber Model und IEEE TSN Standard (November 2015)Disponível em: h�p://blog.so�ing.com/wp-content/uploads/2015/11/Interview_So�ing_TTTech_EN.pdf(April 7, 2016)
Artigo Técnico
www.wii.com.br Implementando Comunicação OPC UA Determinís�ca 18