Características e Aplicações do OPC UA

Diego de Souza Faria & John Anderson Silva

Com o grande aumento da automação industrial, variáveis inclusas nesse processo e diversos protocolos de redes se fez necessário a criação de um padrão de comunicação entre os diversos níveis de comunicação dentro da indústria que vem continuamente evoluindo. Juntamente foram criados sistemas para a supervisão, controle e atuação nesse processo que se tornou tão complexo e impossível de ser acompanhado sem a inclusão de novas tecnologias em automação. Nesse artigo será abordado os principais conceitos dessas tecnologias.

fig17

Clique para assistir ao vídeo: What is OPC? UA in a Minute

I. INTRODUÇÃO
Atualmente a indústria está caminhando para a conectividade entre todos os setores dentro da empresa, bem como a comunicação direta entre a diretoria e o chão de fábrica. Diversas tecnologias têm surgido para facilitar essa integração, e uma delas que vem se destacando é a comunicação via OPC (OLE for Process Control), definido como um protocolo que busca e independência de driver específico para comunicação entre equipamentos de fabricantes de diferentes marcas.
Uma das principais aplicações do protocolo OPC é na comunicação entre um sistema supervisório e um CLP (Controlador Lógico Programável). Esse trabalho aborda de forma objetiva as principais características de um supervisório, bem como dos protocolos de redes utilizados no ambiente industrial, com foco especial nos protocolos OPC DA (Data Access) e OPC UA (Unified Architecture), mostrando suas principais diferenças e aplicações. O objetivo desse estudo é demonstrar a evolução e a grande utilização do OPC e suas vantagens nas redes industriais atuais e futuras, como a indústria 4.0.

II. SUPERVISÃO DE SISTEMAS DE AUTOMAÇÃO
Os sistemas supervisórios são usados para monitorar e controlar uma planta fabril, um processo ou um equipamento. Trata-se de um pacote do software posicionado no topo da camada de hardware ao qual é conectado por meio de PLCs (Programables Logic Controllers) ou outro equipamento similar. Esse sistema gerencia variáveis de processo de forma remota. Estas são atualizadas continuamente e podem ser guardadas em bancos de dados locais ou remotos para fins de registro histórico. [1]
O SCADA (Supervisory Control And Data Acquisition) é um sistema supervisório de monitoramento e controle de uma planta ou equipamento de indústria de ramos como telecomunicações, água e esgoto, energia, óleo e gás e transporte.
Redes SCADA são formadas por um MTU (Master Terminal Unit), que funciona como o cérebro, e diversas unidades remotas, que são responsáveis pelo recolhimento de dados localmente para posterior envio para a MTU. Por fim um software fica responsável por correlacionar os dados, interpretá-los e gerenciá-los. O principal atrativo dos sistemas SCADA é a redução significativa dos custos operacionais e de manutenção, enquanto ao mesmo tempo, aumenta a confiança e melhora o desempenho dos processos supervisionados. [1]

III. REDES INDUSTRIAIS
As redes industriais para automação industrial estão se tornando cada vez mais presentes nos meios industriais. Essa presença em relação aos sistemas tradicionais, do tipo ponto a ponto, com CLP centralizado, deve-se, principalmente, aos fatores técnicos e econômicos que os tornam uma tecnologia extremamente vantajosa e atraente. As redes industriais surgiram, de fato, no mercado industrial brasileiro há cerca de dez anos. Muitas indústrias ainda utilizam sistemas como CLP’s (ou PLC’s), chamados sistemas ponto a ponto, ou tradicionais, onde nesse caso cada ponto de I/O (entrada e saída) devem ser conectados ao CLP. O problema desse tipo de sistema é o alto custo de implementação, devido a grande quantidade de hardware (cabos) e a dificuldade para encontrar problemas relativos ao sistema. Assim as redes industriais surgiram para resolver esses dois grandes problemas. [2]
A seguir serão descritos alguns protocolos de rede utilizados no meio industrial.

 Modbus

Modbus foi um dos primeiros protocolos de comunicação industrial desenvolvido. Sua utilização ainda é bem usual no mundo, tendo milhões de dispositivos instalados em diversas aplicações, principalmente no meio industrial. Sua forma de comunicação pode ser dividida em dois subgrupos: Modbus RTU e Modbus TCP/IP.

Modbus RTU

Sua forma de comunicação é feita de forma serial, através de frames com pacotes de códigos binários e de verificação de erro. Seu meio físico está dividido em RS232, RS485 e RS422. Com o meio físico RS232 a comunicação entre mestre e escravo é feita ponto a ponto, com uma distância máxima de 15 metros. Com o RS422 e RS485 é possível fazer uma comunicação entre um mestre e vários escravos utilizando a topologia de rede em linha. A distância máxima pode chegar a 1200 metros. A diferença entre os dois é que a versão RS485 é superior em capacidade de números de escravos na rede.[3]

Modbus TCP/IP O Modbus TCP/IP

é uma variação do Modbus, com ele podemos trafegar dados industriais via intranet. Seu modelo padrão de comunicação é servidor-cliente, uma aplicação comum é utilizar um switch para conectar vários clientes em um servidor. Seu frame é em pacote binário onde se dispensa os bits de endereço e verificação de erro. Ele utiliza do meio físico Ethernet (IEEE 802.3) e sua velocidade pode chegar a até 10Gbps com distância física entre 100 e 200 metros. [3]

Profinet

O PROFINET é o padrão aberto e inovador para Ethernet industrial. Satisfaz todos os requisitos da tecnologia de automação. Independente de a aplicação envolver automação de manufatura, automação de processos ou acionamentos (com ou sem segurança funcional), PROFINET é a melhor opção em todos os níveis. O PROFINET estabeleceu-se em todos os mercados industriais, é o padrão na indústria automotiva, está amplamente disseminado na fabricação de máquinas, indústria de alimentos, bebidas, embalagens e logística industrial. Além disso, os aprimoramentos contínuos do PROFINET trazem benefícios aos usuários, como o perfil PROFIenergy que possibilita o monitoramento de energia nos processos de produção. [4] O PROFINET está padronizado segundo as normas IEC 61158 e IEC 61784. O desenvolvimento contínuo do PROFINET oferece aos usuários uma visão de longo prazo na execução de suas tarefas de automação. Para os fabricantes de máquinas e plantas industriais, o uso do PROFINET minimiza os custos de instalação, engenharia e startup. Para os usuários, o PROFINET oferece facilidade de expansão da fábrica e alta disponibilidade do sistema devido ao funcionamento autônomo de cada unidade fabril e aos baixos requisitos de manutenção. [4]

A Figura 1 apresenta alguns dos tipos de protocolos de comunicação entre os níveis da pirâmide da automação.

fig1

Figura 1. Pirâmide da automação industrial. [5]

IV. OPC

O Padrão OPC (OLE for Process Control, onde OLE significa Object Linking and Embedding “Vinculação e Incorporação de Objetos” e for Process Control “para Controle de Processo”) surgiu da necessidade de se ter uma interface de comunicação única entre um incontável número de redes, protocolos proprietários e interfaces. Esse padrão possibilitou uma série de vantagens aos sistemas industriais, que os diferenciam dos demais, como: o isolamento de tráfego, a facilidade de integração entre sistemas e a interoperabilidade. Com a adoção do OPC em milhares de produtos, ele é utilizado atualmente como uma interface padrão entre sistemas de automação em diferentes níveis da pirâmide da automação. [6]
Alguns fornecedores da indústria, desenvolvedores de software e consumidores finais, em 1995, se reuniram com o objetivo de desenvolver um padrão de comunicação baseado na tecnologia OLE/DCOM (Distributed Component Object Model), na tentativa de minimizar os problemas relacionados à inconsistência dos “drivers” de equipamentos industriais de diferentes fabricantes, inicialmente dentro do sistema operacional Windows. Foram convidados membros da Microsoft para que dessem suporte técnico a esse desenvolvimento. Surgiu, então, a OPC Foundation (Fundação OPC). O OPC é um padrão de comunicação aberto, que tem por principal objetivo permitir a interoperabilidade vertical entre sistemas dentro de uma organização (Figura 1). Ao basear o OPC na tecnologia OLE, nativa do Windows, este mesmo benefício chegou à área industrial. Com o surgimento desse padrão os desenvolvedores de sistemas de automação puderam implementar servidores OPC para seus equipamentos, e os demais softwares, como supervisórios, passaram a ser clientes OPC. Desapareceu, então, a necessidade de se desenvolver inúmeros drivers de comunicação para integrar os sistemas tradicionais, ou ainda a necessidade de se usar os equipamentos de um único fabricante, como mostra a Figura 2. [7]

fig2

Figura 2. Comunicação entre equipamentos de um mesmo fabricante. [7]

Os equipamentos dotados de comunicação via OPC disponibilizam dados internos em uma interface simplificada, onde aplicações externas podem interagir com a leitura e/ou escrita de valores em parâmetros, registradores de programas, resultados, dentre outros. Este padrão tem desfrutado de uma grande adoção em vários setores, incluindo automação predial, petróleo, gás, energia renovável, serviços públicos, entre outros. [7]
A interconexão de sistemas e equipamentos por meio da integração de drives de comunicação é, muitas vezes, de difícil implementação e implica em alto custo de desenvolvimento e instalação, lembrando, é claro, da dificuldade por parte dos profissionais de realizar essa integração entre os protocolos e sendo essencial para as industrias o seu perfeito funcionamento, torna o trabalho ainda mais elaborado e complicado para instalações. Daí então uma grande vantagem em se utilizar o padrão OPC.

V. FUNCIONAMENTO DO OPC
A tecnologia OPC baseia-se na especificação COM (Component Object Model) da Microsoft. Estes componentes determinam a infraestrutura das aplicações compartilhadas sob sistemas operacionais da Microsoft, como o Windows, abstraindo as funcionalidades dos sistemas de software e expondo-as de forma interativa, através de propriedades, métodos e eventos dos objetos da aplicação. A intermediação da comunicação entre aplicação cliente e equipamento é realizada por um OPC Server (servidor OPC). Este servidor possui os “drivers” referentes aos equipamentos suportados, e de acordo com o modelo configurado, disponibilizando a região de dados específica. Em uma comunicação com um CLP, por exemplo, é possível ler ou escrever valores de memórias internas, utilizadas no programa do usuário, ou até mesmo ler estado de entradas e saídas. Em câmeras industriais é possível obter o resultado da aplicação de análise de imagens, ou mesmo carregar as imagens. O padrão define distintas formas para se acessar dados do processo, alarmes e dados históricos. [8]

O servidor OPC é divido em três partes: server (contém todos os objetos do grupo), group (é a camada de organização dos itens OPC) e Item (objeto que carrega a informação desejada). O “OPC Item” representa uma variável específica do sistema, além do valor da variável, possui informações sobre a qualidade da informação. O OPC Group fica em uma camada superior, é onde os itens são organizados e onde ocorre o controle de atualização dos valores. Na camada mais externa fica o OPC Server, onde são executadas as interfaces entre as aplicações e onde ocorre o controle de eventos e alarmes. Os computadores que possuem os drives dos equipamentos de campo, que constituirão os “servidores OPC”, reconhecem os dados provenientes da rede de comunicação dos equipamentos da planta industrial e os traduzem para o padrão OPC. Os servidores são softwares que fornecem dados no padrão OPC e o computador é o hardware convergente e que disponibiliza os dados. As aplicações que recebem esses dados são os “clientes OPC” e podem estar em quaisquer computadores conectados à rede do servidor OPC. O funcionamento do OPC é baseado na tradicional arquitetura cliente-servidor onde um ou mais servidores fornecem dados para uma ou mais aplicações cliente, conforme mostra Figura 3. [8]

fig3

Figura 3. Arquitetura cliente-servidor do OPC

Basicamente, uma aplicação cliente, como um software de supervisão, solicita um dado ao servidor OPC que lhe atende e retorna com o dado solicitado. Um diferencial do OPC é que uma aplicação cliente pode solicitar dados a um ou mais servidores OPC, e vice-versa. Fica claro, portanto, que o OPC possibilita uma variedade enorme de comunicações, basta que os aplicativos sejam compatíveis com o mesmo.
É importante ressaltar que o OPC não elimina o protocolo proprietário nativo do CLP ou equipamento de campo. O que acontece é que o servidor OPC “traduz” este protocolo proprietário para o padrão OPC. Portanto é necessário o desenvolvimento de um servidor OPC específico para cada um dos diferentes protocolos de comunicação existentes.
Podemos dividir a evolução do OPC em dois principais tipos: OPC Clássico e OPC UA.

VI. OPC CLÁSSICO
A arquitetura OPC DA Cliente / Servidor foi a primeira arquitetura definida pela Fundação OPC. Antes do OPC DA, os produtos dos fornecedores de dispositivos, CLP’s e IHM’s(Interface Homem Máquina), exigiam que quaisquer dispositivos ou aplicações de conexões tivessem um “driver personalizado”. Haviam muitos problemas associados a comunicações baseadas em driver personalizado; alguns destes mais comuns foram: alto custo, tecnologia proprietária que amarrou os usuários a um determinado fornecedor, dificuldade em configurar e manter suas atualizações por causa do constante lançamento de novos dispositivos e aplicações. Em contraste, com o desenvolvimento do OPC DA tornou-se possível conectar a qualquer fonte de dados em tempo real, sem um driver personalizado escrito especificamente para o par de dados código-fonte / dissipador de dados. Com isso para ler e escrever os dados já poderia ser executado sem o dissipador de dados ter que saber protocolo nativo do código-fonte ou estrutura de dados interno. O OPC DA (Data Access) é um grupo de normas cliente-servidor que fornece especificações para a comunicação de dados em tempo real de equipamentos de aquisição de dados, tais como PLCs, e dispositivos de interface como IHM, sistemas SCADA e ERP (Enterprise Resource Planning, ou Sistema de Gestão Empresarial). Essas especificações se concentram na divulgação contínua de dados. O grande benefício e objetivo de se usar o padrão OPC na comunicação industrial é que controladores (CLP’s, RTU’s, dentre outros) de diferentes fornecedores usam seus próprios protocolos, e o OPC elimina a necessidade da IHM (Interface Homem Máquina), sistemas SCADA e ERP de terem um driver específico para cada controlador em questão. [9]

VII. ESPECIFICAÇÕES DO OPC CLÁSSICO
O OPC Clássico utiliza camadas de comunicação sobre vários componentes do sistema operacional da Microsoft, comumente chamado de DCOM. Estes componentes funcionam muito bem em escritórios com rede local (banda larga e conexões confiáveis), mas em condições menos favoráveis, seu comportamento frequentemente leva ao fornecimento de dados não confiáveis e até mesmo à perda de informações. Há diversas especificações de OPC Classico adequadas às diferentes situações de uso de dados: OPC DA (Data Access, ou Acesso a Dados) para dados instantâneos, OPC A&E (Alarms and Events, ou Alarmes e Eventos) para dados baseados em eventos e o OPC HDA (Historical Data Access, ou Acesso a Dados Históricos) para dados históricos. [9]

OPC DA
A especificação OPC DA se trata apenas de dados em tempo real e não os dados históricos ou eventos. Existem três atributos associados com dados OPC DA. Esses são: valor, qualidade do valor e data-hora. Sendo que assim quando um cliente faz um pedido a um servidor DA esses dados têm que serem entregues. Portanto, se a fonte de dados não é capaz de proporcionar um marcador de tempo, por exemplo, o servidor de OPC DA deve criar uma marca de data-hora.

OPC A&E
Hoje, com o nível de automação que está sendo aplicado nas industrias, as empresas estão lidando com quantidades cada vez mais elevadas de informações. Subsistemas alarmante e eventos estão sendo usados para indicar as áreas do processo que necessitam de atenção imediata. A especificação OPC AE tem essa funcionalidade específica, pois trata dos Alarmes e Eventos em sua configuração e fornece essa informação aos diferentes níveis de comunicação na supervisão da empresa.

OPC HDA
Esta especificação descreve o comportamento de um servidor OPC que armazena os dados no banco de dados para que os clientes possam recuperá-lo pelo OPC cliente para a geração de gráficos e acompanhamento da produção.
Este grupo de normas, criado pela Fundação OPC, fornece especificações COM para a comunicação de dados a partir de dispositivos e aplicativos que fornecem dados históricos, tais como bancos de dados. As especificações prevê o acesso a dados brutos, interpolados e agregados (dados com cálculos). É usado para trocar dados do processo arquivado. Está em contraste com a especificação do OPC DA que trata de dados em tempo real. A operação em conjunto do OPC DA, AE e HDA é conhecida como OPC Clássico (Figura 4).

fig4

Figura 4. Configurações do OPC Clássico.

Para a especificação e utilização do padrão OPC, o usuário precisa estar ciente de alguns pontos chaves para o perfeito entendimento de como se beneficiar do uso desse tipo de comunicação. Para isso, o estudo das especificações torna-se um processo difícil, uma vez que as mesmas são direcionadas para desenvolvedores e programadores, sendo necessário o conhecimento prévio de linguagens e ambientes de desenvolvimento.

VIII. OPC UA
Com a introdução de arquiteturas orientadas a serviços em sistemas de manufatura, vieram novos desafios em relação à segurança e modelagem de dados. A Fundação OPC desenvolveu, então, o “OPC UA (Unified Architecture, ou Arquitetura Unificada)” para atender essas necessidades com uma tecnologia rica em recursos em uma plataforma de arquitetura aberta, e que é compatível com o OPC Classic (Clássico) dependendo da versão e fornecedor do cliente/servidor. Dois fatores importantes que contribuíram para que essa atualização fosse criada foi a necessidade de manter a competitividade, já que os usuários OPC precisavam implementar o mesmo em sistemas que não fossem da Microsoft, e o fato de que outras organizações colaboradoras precisavam de uma maneira confiável e eficiente para o transporte de alto nível de dados estruturados. [10]

OPC UA é um protocolo de comunicação independente de fornecedor para aplicações de automação industrial. Baseia-se também no princípio de cliente-servidor e permite uma comunicação contínua dos sensores individuais e atuadores até o sistema de ERP ou a nuvem (Figura 5.). O protocolo é independente de plataforma e possui recursos embutidos para melhorar os mecanismos de segurança. Também incorpora um modelo orientado a serviços, o que aumenta a interoperabilidade com outras plataformas. Esta camada de interoperabilidade unifica a troca de informações e fornece uma interface comum para o controle de processos. [11]

OPC UA faz a ponte entre o mundo baseado em IP da TI e do chão de fábrica. Interfaces, gateways e a perda associada de informação são uma coisa do passado porque todos os dados do processo de produção são transferidos através de um único protocolo dentro de uma máquina, entre máquinas ou entre uma máquina e um banco de dados em nuvem. O OPC UA está eliminando a necessidade de sistemas tradicionais de aquisição de dados em tempo real a nível chão de fábrica.

OPC-UA fornece uma maneira de conectar clientes e servidores de uma maneira segura, sem depender de DCOM (Distributed Component Object Model) da Microsoft. Esta é uma grande vantagem, porque isso significa que você já não é confrontado com as dores de cabeça associadas com a necessidade de configurar DCOM. Isto é porque DCOM não desempenha nenhum papel no transporte de dados. OPC UA também pode permitir que os usuários façam conexões seguras através de firewalls e conexões VPN (Virtual Private Network). Além disso, ele expande a capacidade para fornecer informações de chão de fábrica a outros sistemas de negócios EPR/MES, como resultado do modelo orientado a objeto descrito acima. [10]

fig5

Figura 5. Exemplo de uma comunicação OPC UA.

Com o OPC UA, toda a informação desejada é disponível para cada aplicação e pessoa autorizada a qualquer momento e em qualquer lugar. Esta função é independente do fabricante do qual as aplicações originam, da linguagem de programação em que foram desenvolvidos ou do sistema operacional.

Algumas vantagens do OPC UA sobre o OPC Clássico:
– O OPC UA não está limitado a COM/DCOM da Microsoft.
– Utilização do OPC UA em plataformas não-Windows como: Linux, Android e Mac OS (Macintosh Operating System).
– Alto Desempenho em comunicação via Web Services.
– A integração de todas as ferramentas em um modelo unificado.
– Suporte a estruturas complexas de dados.
– Comunicação de dados de processo sem perda dos dados.
– Aumento da proteção contra acessos não autorizados.
– Compatibilidade com o Firewall (política de segurança).

O OPC UA fornece estratégias de migração para diferentes necessidades e níveis de adoção do OPC UA, e não requer mudanças nos produtos existentes. Wrappers e Proxies fornecidos pela Fundação OPC estão disponíveis para traduzir diferentes interfaces do OPC Clássico para o OPC UA e vice-versa, onde todas as especificações DCOM do OPC Clássico são mapeados para UA. [11]

OPC UA é um passo importante para integrar novas tecnologias. A padronizada arquitetura de serviços orientados e a capacidade de tipos diferentes de unificador de servidores OPC abre a porta para novas áreas de aplicação, especialmente no campo da automação de processos. Isso vai ajudar a simplificar a integração de outras aplicações, como EPR/MES, sistemas IHM ou SCADA. Sendo assim o OPC UA se tornou o protocolo de comunicação ideal para nossa atual indústria (Indústria 4.0) que vem evoluindo constantemente.

IX. APLICAÇÃO E RESULTADOS
O objetivo desta aplicação é validar os conceitos estudados e pesquisados e descrever as aplicações e características do protocolo OPC UA. Para a realização da parte prática criou-se um programa simulando uma planta para controle de temperatura de água em uma torre de resfriamento, onde a rotação do motor do ventilador varia proporcionalmente à temperatura da agua medida por um sensor PT100.

Supervisório
O software supervisório utilizado no experimento foi o Elipse E3 da Elipse Software, empresa nacional pioneira no desenvolvimento de software supervisório e softwares para automação industrial. A Figura 6 apresenta um diagrama do sistema supervisório desenvolvido:

fig6

Figura 6. Sistema Supervisório.

Todas as configurações e características das variáveis utilizadas estão armazenadas em um computador central chamado servidor. Assim, mais de um computador pode acessar a essas informações atuando como clientes de rede (Figura7). Em um sistema supervisório há a possibilidade de um servidor disponibilizar informações a vários clientes.

fig7

Figura 7. Sistema supervisório no modelo cliente-servidor.

Para desenvolver a tela do supervisório, foi utilizado três componentes do software: E3 Studio, E3 Server e E3 Viewer. O E3 Studio é o ambiente de desenvolvimento do programa, lá é criado as telas e escrita do programa através das funções de scripts. O E3 Server é o servidor propriamente dito, nele é armazenado toda a configuração, históricos, alarmes e eventos do sistema, com ele podemos utilizar vários clientes para acessar de forma compartilhada essas informações. O E3 Viewer é a tela de visualização das informações entre operador e sistema supervisório, com ele podemos acessar o sistema de qualquer lugar utilizando um navegador de internet, também há a opção de gerar um runtime para instalação do programa.

Comunicação OPC DA
Para a comunicação DA criou-se um programa em linguagem Ladder no CLP e utilizamos o Elipse E3 como supervisório para monitorar e controlar a planta. Na Figura 8 podemos ver a tela criada no supervisório.

fig8

Figura 8. Tela utilizada no supervisório E3.

Para a comunicação via OPC DA entre o CLP e supervisório utilizamos o programa Automation Studio 3.09, onde dentro do programa do CLP o primeiro passo foi criar uma New OPC Tag Declaration para inserir as variáveis criadas no programa. Depois habilitou-se o servidor OPC e a criação de um New OPC AR Server Mapping. Dentro dele foram inseridas as variáveis criadas no New OPC Tag Declaration, como apresentado na Figura 9. Após a criação desses dois itens foi necessário a configuração da DCOM no windows para que pudesse ocorrer a comunicação OPC.

fig9

Figura 9. Declaração das variáveis OPC.

Dentro do software da Elipse criou-se um driver de comunicação OPC para que operassem como cliente OPC, dentro desse driver foi inserido as tag’s do servidor criado no CLP, na Figura 10 podemos observar esse driver.

fig10

Figura 10. Driver de comunicação OPC.

Após a criação desse driver e a associação das tag’s criadas no CLP com as variáveis no programa supervisório conseguimos a comunicação via OPC DA.

Comunicação OPC UA
A comunicação OPC UA foi entre um CLP, como servidor, e um computador (Sistema Operacional Windows) como cliente.
Para a comunicação utilizou-se os seguintes componentes: software UaExpert v1.4.2 da Unified-Automation, CLP X20CP1583 e software Automation Studio V4, ambos da B&R e um notebook com sistema operacional Windows 10.
Nossa prática será um monitoramento de temperatura composto por um sensor PT-100 em conjunto com transmissor de temperatura Tx-Block e acionamento de uma lâmpada (alarme). Na Figura 11 pode-se verificar a montagem dos componentes descritos acima.

fig11

Figura 11. Montagem prática da comunicação UA.

O primeiro passo foi configurar o IP do computador para comunicar com o CLP, no nosso caso utilizou-se o IP: 192.168.0.100 e mascara de rede: 255.255.255.0 dentro do Windows, e para o CLP utilizamos o IP: 192.168.0.70 e mascara de rede: 255.255.255.0. Com o software Automation Studio V4, desenvolveu-se o programa lógico e a configuração do servidor OPC UA. Uma das grandes vantagens da comunicação OPC UA é não ser necessário configurar a DCOM do computador, mantendo assim a segurança padrão sem desabilitar o firewall.
Estruturado, contendo três variáveis de processo, duas analógicas e uma digital. Depois de ter criado o programa o próximo passo foi criar o servidor OPC UA dentro do CLP. Para isso temos que configurar um mapa de variáveis dentro do Automation Studio V4 e adicionar as variáveis a serem utilizadas, como mostra a Figura 12 e 13.

fig12

Figura 12. Configurando o Automation Studio V4.

fig13

Figura 13. Configuração do servidor OPC UA.

Com o servidor OPC UA configurado no Automation Studio, utilizou-se o software UaExpert como cliente OPC UA. Para habilitar a comunicação foi adicionado o servidor OPC UA no UaExpert para leitura e controle das variáveis, como mostra a Figura 14.

fig14

Figura 14. Servidor OPC UA no UaExpert.

Para essa comunicação funcionar inseriu-se o endereço de IP do CLP. Ao adicionar o IP o software identificará o CLP automaticamente, como pode-se observar na Figura 15.

fig15

Figura 15. Reconhecimento do IP do CLP pelo UAExpert.

Após adicionar o servidor, basta abrir a pasta Data Access View (Exibição de Acesso a Dado) dentro de documentos, lá estará as variáveis do processo. Data Access View é um plugin do software UaExpert onde ficam as variáveis do processo, também podem ser adicionados vários plugins, como: UA Alarms&Conditions View (Exibição de Alarmes e Condições), UA Historical Trend View (Visualização de Tendências Histórica), DI Information Model Plugin (Plugin de Informação Modelo) e UA Performance Plugin (Plugin de Desempenho).

fig16

Figura 16. Variáveis no Servidor UA.

Com essa validação pode-se monitorar e acionar as variáveis do processo, validando a comunicação OPC UA com um cliente virtual.

X. CONCLUSÕES
Com o grande avanço das tecnologias microprocessadas as indústrias estão tendo que acompanhar e incluir essa evolução em seu processo fabril para não ficarem para trás e perderem a competividade. O padrão OPC está se encaixando como uma luva nesse mercado da comunicação industrial, pois está possibilitando a interoperabilidade entre os diversos produtos e protocolos existentes.
Com a evolução industrial rumo a indústria 4.0 será imprescindível essa interconectividade entre os níveis de comunicação dentro da empresa, sendo do chão de fábrica até o MSP e Nuvem.

XI. BIBLIOGRAFIA
[1] M. A. Branquinho, J. Seidl, L. C. Moraes, T. B. Branquinho, and J. A. Junior, Segurança de Automação Indudtrial e SCADA, 1st ed. São Paulo: Elsevier, 2014.
[2] A. B. Lugli and M.M. D. Santos, Redes Industriais para Automação Indudtrial, 1st ed. São Paulo: Érica Ltda, 2012.
[3] J. M. Nascimento and P. B. Lucena, “Protocolo Modbus,” Universidade Federal do Rio Grande do Norte.
[4] PI Brasil. [Online]. Disponível em: <http://www.profibus.org.br/> Acesso em 1 de novembro de 2016.
[5] Automação Industrial. [Online]. Disponível em: <http://www.automacaoindustrial.info/a-piramide-da-automacao-industrial/> Acesso em 11 de outubro de 2016.
[6] M. O. Fonseca, “Comunicação OPC, uma abordagem prática,” Seminário de Automação de Processos, Vitória, 2002.
[7] A. C. Ratunde, M. C. Santos, and Y. O. Cruz, “O Padrão de Comunicação OPC e Suas Características,” Universidade Federal de Minas Gerais, 2016.
[8] R. N. Gonçalves, “Desenvolvimento de Servidores OPC DA, OPC UA e Wrappers para aplicação em Automação,” Universidade Federal de Itajubá, Dissertação 2012.
[9] Matrikon.com. [Online]. Disponível em: < https://www.matrikonopc.com/opc-server/opc-data-access-versions.aspx> Acesso em 21 de setembro de 2016.
[10] B&R Automation. [Online]. Disponível em: <https://www.br-automation.com/pt-br/tecnologia/opc-ua/ > Acesso em 1 de outubro de 2016.
[11] Unified Automation. [Online]. Disponível em: <https://www.unified-automation.com/downloads/opc-ua-clients.html> Acesso em 2 de outubro de 2016.

 

 

um comentário

Deixe uma resposta