Implementando Comunicação OPC UA Determinísca · exemplo, a tecnologia OPC ... da linguagem de programação e de tecnologias ... OPC UA uliza um modelo de informação orientado

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.


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


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


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


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


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



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


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.³


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


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


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


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


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


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


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


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


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


http://blog.softing.com/wp-content/uploads/2015/11/Interview_Softing_TTTech_EN.pdf

Documents

Implementando Comunicação OPC UA Determinísca · exemplo, a tecnologia OPC ... da linguagem de programação e de tecnologias ... OPC UA uliza um modelo de informação orientado