O Padrão de Comunicação OPC e Suas Características

Transcrição

1 O Padrão de Comunicação OPC e Suas Características Ana Clara Ratunde, Matheus Costa Santos e Yago Oliveira Cruz Resumo As diferenças que existem entre os padrões dos protocolos de comunicação sempre impediram a interoperabilidade de sistemas de supervisão, automação e controle, entre equipamentos de diferentes fabricantes. O padrão OPC surgiu para estabelecer regras para que sejam desenvolvidos sistemas com interfaces padrões que possibilitem uma conexão entre plataformas que utilizam diferentes protocolos. Neste trabalho falaremos sobre as características e especificações do padrão OPC. I. INTRODUÇÃO 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, 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, para que isso ocorresse, membros da Microsoft para que dessem suporte técnico a esse desenvolvimento. Surgiu, então, a OPC Foundation, um grupo sem fins lucrativos que é responsável pelo desenvolvimento e manutenção das normas desse padrão. 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. OPC é a sigla para OLE for Process Control, onde OLE significa Object Linking and Embedding. Quando foi lançado pela primeira vez em 1996, o seu objetivo era transformar protocolos específicos de CLP (como Modbus, Profibus, etc.) em uma interface padronizada permitindo que os sistemas HM/SCADA fizessem a interface "homem-máquina" que iria converter pedidos de leitura e de gravação em solicitações específicas do dispositivo. Como resultado, uma indústria inteira de produtos surgiu, permitindo aos usuários finais implementar sistemas usando os melhores produtos interagindo perfeitamente via OPC. Esse padrão nada mais é que um conjunto comum de interfaces, métodos e propriedades de comunicação, agregados dentro de uma especificação padronizada e aberta para acesso público. Teoricamente qualquer pessoa com conhecimentos de programação pode desenvolver seus aplicativos OPC, basta acessar as especificações contidas no site da OPC Foundation e desenvolver uma interface compatível. 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 escrever 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 1. 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, etc. Figura 1 Comunicação entre equipamentos de um único fabricante Estas especificações que, agora são conhecidas como sendo do OPC Clássico, têm 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. 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 OPC Foundation desenvolveu, então, o OPC UA (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 Clássico. 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. A intermediação da comunicação entre aplicação cliente e equipamento é realizada por um servidor OPC (OPC Server). Este servidor possui os drivers referentes aos equipamentos suportados, e de acordo com o modelo

2 configurado, disponibiliza 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. O OPC DA define o acesso de dados, incluindo valores, tempo e informação de qualidade. O OPC AE define o acesso de informações à alarmes e eventos, bem como o tipo de evento, os estados das variáveis e o gerenciamento de estado. O OPC HDA define o acesso aos dados históricos hora datada, bem como seus métodos de consulta e análises. II. LINHA DO TEMPO Em 1990, os sistemas operacionais da Microsoft dominaram a paisagem de automação industrial. Fornecedores de automação começaram a usar COM e DCOM em suas ofertas de produtos. Em 1995, os fornecedores de automação Fisher- Rosemount, Intellution, Opto 22 e Rockwell Software formaram uma força-tarefa para desenvolver um padrão de acesso a dados com base em COM e DCOM, e deram o nome de OPC. Em 1996, a força-tarefa lança a versão 1.0 de uma especificação OPC simplificado para acesso a dados (DA) em Agosto. Já no primeiro ano, vários outros fornecedores de software e hardware começaram a usar OPC como seu mecanismo de interoperabilidade. Logo fica claro que uma organização mais formal de conformidade, interoperabilidade, certificação e validação é necessária. A Fundação OPC é criada no Chicago ISA Show, em Setembro. Em 1998, a OPC Foundation começa a conversão de sua especificação existente para serviços web. Em 1999, a especificação OPC Alarmes e Eventos (OPC AE) é liberada. Em 2001, o lote e a especificação de segurança OPC Historical Data Access (OPC HDA), são liberados. Em 2003, as especificações Dados OPC Complex, dados do Exchange e XML-DA especificações são lançadas e a Arquitetura unificada (OPC UA), composta por 13 partes separadas, é criada pela especificação original. O OPC original agora é referido como "Classic OPC" ou OPC Clássico. Em 2004, a especificação de Comandos OPC é liberada. Em 2006, a versão 1.0 do OPC UA se torna disponível. Em 2007, Programa de Certificação OPC e Teste Labs são introduzidos. A automação começar a oferecer os primeiros produtos baseados em OPC UA. Em 2009, a versão 1.01 do OPC UA torna-se disponível. Lançam OPC UA para dispositivos Analyzer (DDA) como uma especificação adjunta, impulsionada pelas indústrias de fabricação farmacêutica e química. Em 2010, os primeiros dispositivos OPC UA embutidos são lançados. OPC UA para IEC é liberado como uma especificação. Em 2013, OPC UA 1,02 é lançado juntamente com OPC UA para o ISA-95. A Fundação OPC dá suporte para mais de 480 membros em toda a China, Europa, Japão e América do Norte. III. FUNCIONAMENTO A tecnologia OPC faz parte do.net Framework, da Microsoft, e baseia-se na especificação COM (Component Object Model), a mesma tecnologia usada na plataforma ActiveX, que provêm conectividade e interoperabilidade entre diferentes aplicações de forma plug-and-play. 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. 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 2. 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

3 específico para cada um dos diferentes protocolos de comunicação existentes. A interconexão ocorre em função dos respectivos dados dos equipamentos de campo serem reconhecidos através dos drives instalados nos computadores, drive esse que descreve os componentes do software desenvolvidos para um produto específico e que são implementados pelo fabricante de um produto a fim de permitir que seu software se comunique com determinado produto por meio de uma comunicação de rede. V. ASPECTOS PRÁTICOS PARA UTILIZAÇÃO Figura 2 Arquitetura cliente-servidor do OPC IV. INTERCONEXÃO 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, a Figura 3 mostra um pouco disto. Figura 3 Interconexão da comunicação OPC O padrão OPC surgiu para simplificar a maneira como os dados dos equipamentos de chão de fábrica são disponibilizados às suas aplicações sem que estas precisem do drive e do protocolo utilizado no processo de automação. O OPC, atualmente, vem sendo usado até mesmo no fornecimento de dados para os sistemas de controle situados nos escritórios, que tem por função disponibilizar informações para a administração sobre os processos de produção de uma indústria. 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. Para simplificar o entendimento do padrão OPC, estes pontos são apresentados a seguir. A. Cliente ou Servidor OPC? Os produtos para monitoração de dados, como IHMs, sistemas supervisórios e etc, normalmente são clientes OPC. Por outro lado, os produtos que fazem a comunicação direta com os dispositivos de campo utilizando protocolos proprietários são servidores OPC. Cada produto pode incorporar as duas funcionalidades, sendo o mais comum em aplicações normalmente onde o cliente possa ser servidor, e não o contrário. B. Número ideal de clientes e servidores O número de servidores necessários para uma determinada aplicação irá depender do produto a ser utilizado. Os fabricantes de dispositivos de campo normalmente fornecem um servidor OPC capaz de comunicar com todos os protocolos dos seus produtos de linha. Este servidor é um software para o ambiente Windows que é executado em um microcomputador, normalmente PC. Ou seja, um servidor OPC da Rockwell, o RSLinx por exemplo, permite que diversos drivers de comunicação sejam configurados para as diversas redes (ControlNet, DeviceNet, Ethernet, DH+, etc.). Neste caso, o RSLinx funciona como um único servidor OPC, capaz de comunicar com diversos clientes OPC sendo executados na mesma máquina ou em máquinas remotas. Existem servidores OPC de terceiros que permitem que sejam configurados drivers de comunicação para diversas redes e protocolos de diferentes fabricantes, neste caso, um único produto poderá servir dados de diferentes fabricantes. Cada cliente OPC pode conectar-se a diferentes servidores, os quais podem estar processando na mesma máquina ou remotamente em máquinas diferentes, portanto, qualquer produto que funcione como cliente OPC poderá se comunicar com quaisquer servidores OPC de quaisquer fabricantes.

4 C. Formato de dados Pela especificação do padrão, todo servidor de dados deve enviar o dado OPC no seguinte formato: todos os tipos de dados VARIANT definidos pela interface DCOM são suportados; a informação Time Stamp é fornecida pelo servidor através da leitura do time stamp dos dispositivos de campo ou por geração interna, é utilizada a estrutura padrão do Windows para o UTC (Universal Time Coordinated); são reservados 2 bytes para codificação do estado do dado fornecido pelo servidor (por enquanto, apenas o uso do byte menos significativo foi definido; dois bits definem a qualidade do dado que pode ser: ßGood dado válido, ßBad no caso de perda do link de comunicação com o dispositivo de campo, ßUncertain no caso de existir o link de comunicação mas o dispositivo de campo estiver fora de operação; quatro bits fornecem um detalhamento do estado apresentado e os últimos dois bits podem conter dados de diagnóstico no caso de falha de um sensor, por exemplo). D. Configuração dos dados no Cliente Os produtos de mercado, normalmente não permitem muita flexibilidade para a configuração dos dados solicitados pelo cliente. Isto se deve basicamente à preservação da cultura anterior para os drivers de comunicação específicos. Entretanto, isto pode ser uma armadilha para os usuários. Considerando o caso mais comum que consiste nos servidores de dados OPC (OPC Data Access), os clientes podem definir basicamente as seguintes configurações: 1) Criação de grupos e itens OPC Basicamente, todos os dados OPC são chamados de itens. Cada item pode ser de um tipo diferente de dado compatível com a especificação OPC. Os diversos itens são organizados em grupos OPC, os quais definem as principais características de leitura dos itens (Taxa de Atualização, Estado Ativo/Inativo, Banda Morta, Leitura Síncrona/Assíncrona). 2) Leitura Síncrona ou Assíncrona Para um determinado grupo OPC pode ser definido se a leitura dos dados é feita de forma síncrona, a qual depende de uma confirmação de execução antes de uma nova leitura, ou assíncrona, a qual não depende da confirmação. Normalmente é utilizada a leitura assíncrona, a qual garante um melhor desempenho. 3) Leitura de dados direto do dispositivo A partir da versão 2.0 da especificação para o servidor de dados, é possível fazer a seleção no cliente OPC para leitura dos dados da memória cache do servidor ou diretamente do dispositivo de campo. 4) Estado Ativo/Inativo Cada item ou grupo pode ter o seu estado alterado pelo cliente para Ativo, habilitando a comunicação do mesmo, ou Inativo. 5)Leitura Cíclica ou por Mudança de Estado O cliente OPC pode definir se os dados do servidor serão lidos de forma cíclica ou por mudança (transição) de estado. Na leitura cíclica, o cliente faz a requisição de leitura regularmente, independentemente se os dados sofreram alteração de valor ou não. No caso de leitura por mudança de estado, o servidor fica responsável por enviar para os clientes os itens que sofrerem alteração de seu estado (Qualidade do dado) ou quando os valores dos itens de um determinado grupo ultrapassarem o valor da banda morta. 6) Banda morta É utilizada para definir os valores limites de transição para os itens de um determinado grupo, para os quais o servidor fará o envio para os clientes quando a alteração dos valores dos itens estiver fora da banda especificada. E. Escrita de dados A escrita de dados OPC funciona de forma independente da leitura. Assim como na leitura, a escrita pode ser síncrona ou assíncrona. Entretanto, os comandos de escrita são executados imediatamente pelo servidor, sendo enviados diretamente para os dispositivos de campo. A partir da versão 3.0 do servidor, foi possível fazer a escrita de dados na memória cache do servidor e depois a transferência cíclica dos dados para os dispositivos de campo. Este recurso é muito útil para os dispositivos que dependem de comandos igualmente espaçados no tempo, tal como os sistemas de controle de movimento. F. Comunicação de Blocos de Dados O padrão OPC permite a comunicação de blocos de dados (vetores) entre o servidor e os clientes. Isto representa uma grande otimização, pois as informações de time stamp e estado do dado são tratados e fornecidos apenas uma vez para um conjunto de dados, reduzindo assim o overhead da comunicação. Neste caso, cada item é configurado como um bloco de dados. G. Redundância com OPC As especificações do padrão OPC não fazem menção à utilização de servidores redundantes. Entretanto, cada cliente OPC pode implementar facilmente um mecanismo para conexão simultânea em mais de um servidor, verificação do estado do servidor e ativação/desativação dos grupos para o servidor que estiver funcionando. Esta solução é encontrada apenas em alguns produtos, não sendo regra geral a disponibilização deste recurso para a maioria dos produtos de mercado. H. Desempenho da comunicação OPC Em linhas gerais, o desempenho da comunicação OPC se aproxima do desempenho apresentado por sistemas que utilizam drivers de comunicação específicos e otimizados. Normalmente, os drivers específicos

5 possuem um ótimo desempenho após serem devidamente depurados e otimizados, o que via de regra não acontece em muitos casos. Como um servidor OPC nada mais é do que uma camada de software a mais para implementar as interfaces padrões e os mecanismos de comunicação com o cliente, é de se esperar que o desempenho do mesmo só seja afetado em relação a comunicação com o cliente e não com o dispositivo de campo. No caso da comunicação com o dispositivo de campo, cada fornecedor pode implementar o driver e o protocolo que melhor se ajustem às necessidades do dispositivo e da rede de comunicação. Desta forma, o desempenho do servidor OPC está mais relacionado à capacidade dos recursos de hardware da máquina que executa a aplicação do servidor do que propriamente do driver específico. Como os recursos de hardware estão cada vez mais poderosos em relação à capacidade de processamento, isto não tem se mostrado como um problema real. Entretanto, o que se tem verificado na prática é que muitos clientes e servidores OPC não implementam a comunicação de blocos de dados, fazendo a leitura de itens separadamente, o que ocasiona um grande overhead devido ao tratamento separado de time stamp e estado do dado para cada item OPC. Outro ponto importante que muitos clientes OPC não implementam, consiste no agrupamento de dados que precisam ser lidos sob demanda, tais como animações de telas sinópticas, janelas de operação de equipamentos, relatórios, etc. Os dados necessários para estes elementos (objetos) de monitoração, normalmente podem ser lidos sob demanda, de forma que somente quando o objeto estiver selecionado, será ativado o grupo OPC no servidor para leitura dos dados. Quando o objeto não estiver selecionado, o grupo OPC ficará desativado, fazendo com que os dados não sejam lidos e com isso, melhora-se o desempenho da comunicação. A principal desvantagem vem quando pensamos que o padrão OPC está passando por constante avanço ao longo dos anos, preenchendo cada vez mais espaço nas indústrias e, no entanto, algumas de suas características principais que facilitaram seu surgimento e evolução ironicamente hoje também são fatores limitantes ao seu pleno funcionamento, fazendo com que alguns desenvolvedores acabem por criar soluções que complementam o OPC, possibilitando ultrapassar algumas barreiras inerentes à sua tecnologia. Isto se dá devido ao acelerado processo de evolução tecnologica em que vivemos, onde precisaríamos de equipes grandiosas para atualizar quase que constantemente as funções e topologias do sistema OPC. REFERÊNCIAS [1] P. P. Adriano. Padronização da comunicação através da tecnologia OPC. [Online]. Disponível em: Comunicacao-atraves-da-Tecnologia-OPC.pdf [2] F.R. Denise, A. Reinaldo. Utilização do drive OPC na integração de sistemas de automação industrial. Apresentado no 3º Seminário Nacional de Sistemas Industriais e Automação. [Online]. Disponível em: [3] O. F. Marcos. Comunicação OPC Uma abordagem prática. [Online]. Disponível em: DownloadFiles/OPCMarcosFonseca.PDF [4] Site da OPC Foundation: I. Segurança para acesso ao sistema Para a implementação do controle de acesso ao servidor OPC podem ser utilizados dois métodos. O método normalmente usado consiste nos mecanismos proporcionados pelo próprio DCOM, os quais são configurados no Windows NT executando-se o comando DCOMCNFG. Outra forma menos usual consiste em se utilizar mecanismos implementados pelo cliente e servidor conforme a especificação do padrão OPC. O controle de acesso é fundamental para o caso de acesso remoto e para a comunicação via Internet prevista com a especificação do OPC com XML. VI. VANTAGENS E DESVANTAGENS As principais vantagens do emprego de uma comunicação OPC são: a redução do tempo de desenvolvimento; implementar uma comunicação confiável entre diferentes equipamentos; a topologia é simplificada e o controle do fluxo de informações fica sob responsabilidade apenas dos servidores OPC.