UNIVERSIDADE DO ESTADO DO RIO DE JANEIRO
         UNIVERSIDADE PETROBRAS
    CURSO DE ESPECIALIZAÇÃO EM AUTOMAÇÃO
        ...
CURSO DE ESPECIALIZAÇÃO
               EM AUTOMAÇÃO INDUSTRIAL


          PROTOCOLO OPC: Introdução e
       Aplicações n...
Resumo



O protocolo OPC foi desenvolvido primariamente para solucionar problemas de
interoperabilidade em sistemas de au...
Abstract



The OPC protocol was primarily developed to solve the interoperability problem in industrial
automation system...
Índice de Figuras
Figura 2.1 Hierarquia de um sistema de automação industrial (DJIEV, 2003)           15
Figura 2.2 Topolo...
Lista de Abreviaturas


CATID     Category Identifier
CIM       Computer Integrated Manufacturing
CLP       Controlador Ló...
OPC-DX      OPC Data Exchange
OPC-HDA     OPC Historical Data Access
OPC-UA      OPC Unified Architecture
OPC-XMLDA   OPC ...
Sumário

1     Introdução....................................................................................................
3.1.1        Programação Orientada a Objetos ....................................................................27
      ...
10


1 Introdução

O emprego de redes de supervisão e controle baseadas em protocolos de comunicação digital
tem crescido ...
11

Vencida tal etapa, o próximo passo seria o desenvolvimento de um padrão de comunicação
capaz de integrar verticalmente...
12

   •   Conflitos de acesso: dois drivers independentes não podem (geralmente) acessar um
       mesmo dispositivo simu...
13

No Capítulo 4 são apresentadas algumas aplicações do protocolo OPC em ambiente
industrial, discutindo-se vantagens e d...
14



2 Automação Industrial: Redes de
    Comunicação

Os sistemas de controle de processo e manufatura surgiram no iníci...
15


A seguir são apresentados os níveis hierárquicos que normalmente compõem um sistema
industrial de automação e ressalt...
16


Tradicionalmente, a comunicação no nível do campo utiliza largamente cabos paralelos,
multi-fios e interfaces seriais...
17


2.1.3 Nível de Gerência


Consiste no nível mais elevado da automação industrial de uma planta. Suas estratégias de
o...
18


2.3 Métodos de Transmissão

A transmissão de dados pode ser analógica ou digital, dependendo do tipo do dado a ser
tr...
19




                    Figura 2.3 Topologia em Barramento (TANENBAUM, 2003)




                       Figura 2.4 Topo...
20


2.5 Aspectos de Projeto de Redes Industriais

O projeto de uma rede de comunicação envolve o planejamento e a avaliaç...
21


   •   Utilização - comprometimento da capacidade da rede, sendo usualmente representada
       como a razão do seu u...
22


   •   Conexão Host-Terminal;


   •   Comunicação peer-to-peer;


   •   Download ou Upload de Programas;


   •   D...
23


2.5.8 Manutenção


Todas as redes devem ser mantidas e atualizadas. Um bom projeto de rede deve permitir
manutenção p...
24


   •   Tolerância a atmosferas explosivas - Geralmente requerem invólucros à prova de
       explosão ou meios de seg...
25


   •   Backup de alimentação - Na ocorrência de falha de alimentação elétrica, o backup é
       normalmente provido ...
26

                      Error!

                   Início

              Projeto Básico


         Projeto de Detalhamen...
27



3 Fundamentos do OPC

3.1 A Tecnologia que Compõe o OPC

Nas próximas seções são apresentadas algumas das tecnologia...
28


3.1.2 RPC e DCE


Na década de 80, com o intuito de tornar possível a computação distribuída num ambiente
multi-plata...
29




                      Figura 3.1 Arquitetura do DCOM (MICROSOFT, 1996)


3.1.3 DCOM


O DCOM nasceu a partir da tec...
30


Como um modelo orientado a objetos, que também herda funcionalidades do RPC, o DCOM
se constitui basicamente de (IWAN...
31


A partir desta seção, são descritas as principais especificações do OPC nas suas versões
vigentes atualmente (Dezembr...
32


distribuição assíncrona ou coleta síncrona por vários clientes OPC. Para escritas, o servidor
OPC atualiza os dados n...
33


       heterogêneas, incluindo serviços de configuração, diagnóstico, monitoração e
       gerenciamento remotos (ver...
34


   •   Interoperabilidade entre sistemas de gestão empresarial (Enterprise Resource
       Planning - ERP), de execuç...
35


       gerenciamento (ex: criação/destruição), pelo cliente, de objetos OPCGroup, entre
       outros;


   •   OPCGr...
36




                    Figura 3.3 Namespace e Hierarquia de Objetos (IWANITZ, 2002)


Principais Funcionalidades (OPC ...
37


       um dispositivo; e dois bytes que representam a qualidade associada ao dado (ex:
       “Bom”,”Ruim” e “Indefin...
38


obrigatórios e definidos na especificação. Os demais são chamados de “específicos de
fabricante”.


Nesse contexto, a...
39




                         Figura 3.4 Atributos de Eventos (IWANITZ, 2002)


Um último conceito na OPC-AE é o de filt...
40


A Figura 3.5 mostra o exemplo de um servidor com seus objetos associados a uma área de
eventos.




                 ...
41


   •   Pesquisa através de filtros: Permite que o cliente pesquise os atributos de evento e
       restrinja o recebi...
42


tendência), sendo registrada sua variação numa determinada faixa de tempo, e permitindo seu
acesso posterior pelos us...
43


   •   Valores de limite (Bounding Values). São os valores requeridos pelo cliente para
       determinar os pontos i...
44


   •   OPCHDA_Browser. Fornece a interface para navegação (pelo cliente) no espaço de
       endereços do servidor (a...
45


O modelo de arquitetura dos sistemas OPC-UA trata os clientes e servidores OPC-UA como
parceiros que interagem de div...
46


O OPC-UA Server Application é o código que executa a função de servidor, utiliza o OPC-
UA Server API para enviar e r...
47


•   Interações Servidor-Servidor: Interações entre servidores na qual um servidor
    comporta-se como um cliente de ...
48


   •   Modelo de segurança personalizado: Os procedimentos de segurança podem ser
       selecionadas e configuradas ...
49


troca de mensagens, e as conexões HTTP para tornar as informações disponíveis na Internet,
independente de protocolos...
50


3.2.3.2 OPC Compliance Test


As especificações OPC são regras eficazes que garantem a interoperabilidade. Para asseg...
51


fornecedores, desenvolvedores, fabricantes de equipamentos e usuários finais conectarem
dispositivos novos e intelige...
52


   •   Um cliente para permitir a definição, configuração, visualização e monitoração das
       conexões entre os se...
53


   •     O OPCServerBrowser, que fornece uma interface para informar aos clientes OPC a
         existência de servid...
54


         acesso para ligações do cliente. Entretanto, o servidor OPC não controla o acesso de
         qualquer objet...
55


   •   Um namespace bem definido, seguindo a hierarquia e conceitos previstos na norma
       IEC 61512. Vale ressalt...
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Opc4
Upcoming SlideShare
Loading in …5
×

Opc4

2,200 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,200
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
50
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Opc4

  1. 1. UNIVERSIDADE DO ESTADO DO RIO DE JANEIRO UNIVERSIDADE PETROBRAS CURSO DE ESPECIALIZAÇÃO EM AUTOMAÇÃO INDUSTRIAL PROTOCOLO OPC: Introdução e Aplicações na Automação Industrial CHRISTIAN FARIAS DA SILVA FLÁVIO ANDRÉ BRAYNER LOPES JEAN DE ALMEIDA NÓBREGA ROGÉRIO PRAZERES COSTA Rio de Janeiro – 2007
  2. 2. CURSO DE ESPECIALIZAÇÃO EM AUTOMAÇÃO INDUSTRIAL PROTOCOLO OPC: Introdução e Aplicações na Automação Industrial CHRISTIAN FARIAS DA SILVA FLÁVIO ANDRÉ BRAYNER LOPES JEAN DE ALMEIDA NÓBREGA ROGÉRIO PRAZERES COSTA Monografia submetida ao corpo docente da Universidade do Estado do Rio de Janeiro como requisito final para a obtenção do certificado de Especialização em Automação Industrial ______________________________________________________________________________ Prof. Gil R. V. Pinheiro (DETEL/FEN/UERJ – Orientador) ______________________________________________________________________________ Profa. Maria Clícia Stelling de Castro (DICC/IME/ UERJ) ______________________________________________________________________________ Prof. Alexandre Sztajnberg (DICC/IME/ UERJ) Rio de Janeiro – 2007
  3. 3. Resumo O protocolo OPC foi desenvolvido primariamente para solucionar problemas de interoperabilidade em sistemas de automação industrial, integrando dados entre os diversos níveis de suas redes. Basicamente, consiste em um protocolo aberto, composto por diversas especificações em constante desenvolvimento, tecnologicamente bastante ligado à tecnologia DCOM da Microsoft™. Neste trabalho é apresentada uma introdução aos principais aspectos das comunicações em ambiente industrial, descrevem-se as características fundamentais do protocolo OPC e apresentam-se estudos, teóricos e práticos, do seu emprego em situações diversas. Os resultados encontrados nesses estudos são analisados e comparados. Espera-se dessa forma disponibilizar uma fonte de consulta para profissionais de automação e controle que necessitem entender o protocolo, suas funcionalidades e a viabilidade do seu emprego no problema que se busca solucionar. Palavras-chave: protocolo OPC, automação industrial, redes de comunicação, redes industriais.
  4. 4. Abstract The OPC protocol was primarily developed to solve the interoperability problem in industrial automation systems by integrating data between their network levels. Basically, it is an open protocol composed by many specifications that are constantly updated, technologically heavily connected to Microsoft™’s DCOM technology. This work presents an introduction to main aspects of communication in industrial environment, describes the fundamental characteristics of OPC protocol and also presents case studies, both practical and theoretical, of it use in many situations. The results collected from these cases are analyzed and compared among them. We expect this work may help automation professionals to understand the protocol, it functionalities and the viability of it use in the problem that they may have to solve. Keywords: OPC protocol, industrial automation, communication networks, industrial networks.
  5. 5. Índice de Figuras Figura 2.1 Hierarquia de um sistema de automação industrial (DJIEV, 2003) 15 Figura 2.2 Topologia em Estrela (TANENBAUM, 2003) 18 Figura 2.3 Topologia em Barramento (TANENBAUM, 2003) 19 Figura 2.5 Fluxograma de Projeto 26 Figura 3.1 Arquitetura do DCOM (MICROSOFT, 1996) 29 Figura 3.2 Arquitetura Básica do OPC (OPC FOUNDATION, 2003a) 31 Figura 3.3 Namespace e Hierarquia de Objetos (IWANITZ, 2002) 36 Figura 3.4 Atributos de Eventos (IWANITZ, 2002) 39 Figura 3.5 Servidor OPC-AE e Área de Eventos (IWANITZ, 2002) 40 Figura 3.6 Cliente OPC-UA (OPC FOUNDATION, 2006b) 45 Figura 3.7 Servidor OPC-UA (OPC FOUNDATION, 2006b) 46 Figura 3.8 Interação entre Servidores OPC-UA (OPC FOUNDATION, 2006b) 47 Figura 3.9 Servidores OPC-UA entre Níveis Hierárquicos (OPC FOUNDATION, 2006b) 47 Figura 4.1 Sistema de controle com realimentação (KEW, 2001) 60 Figura 4.2 Tempo de loop num sistema com realimentação (KEW, 2001) 60 Figura 4.3 Tempo de loop de um sistema de realimentação utilizando o OPC (KEW, 2001) 60 Figura 4.4 Fluxo de informações num sistema de controle avançado ou otimização 63 Figura 4.5 Sistema de automação da aciaria da Açominas (FONSECA, 2002) 73 Índice de Tabelas Tabela 4.1 Desempenho do OPC por estação (FONSECA, 2002) 75 Tabela 4.2 Resultados do teste (BURKE, 1998) 77 Tabela 4.3 Resultados do teste (BURKE, 1998) 78 Tabela 4.4 Resultados do teste (BURKE, 1998) 78
  6. 6. Lista de Abreviaturas CATID Category Identifier CIM Computer Integrated Manufacturing CLP Controlador Lógico Programável CLSID Class Identifier COM Component Object Model DCE Distributed Computing Environment DCOM Distributed Component Object Model DCS Distributed Control System DLL Dinamic Link Library ERP Enterprise Resource Planning FCC Fluid Catalytic Cracking GUID Globally Unique Identifiers IDL Interface Definition Language IHM Interface Homem Máquina IID Interface Identifier IP Internet Protocol LAN Local Area Network MES Manufacturing Execution System MPC Model Predictive Control MTBF Mean Time Between Failure MTTR Mean Time To Repair OLE Object Linking and Embedding OPC OLE for Process Control OPC-AE OPC Alarms & Events OPC-DA OPC Data Access
  7. 7. OPC-DX OPC Data Exchange OPC-HDA OPC Historical Data Access OPC-UA OPC Unified Architecture OPC-XMLDA OPC XML Data Access ORB OPC Redundancy Broker ORPC Object RPC OSF Open Software Foundation PID Controlador Proporcional Integral e Derivativo POO Programação Orientada a Objetos RPC Remote Procedure Call SCADA Supervisory Control and Data Acquisition SDCD Sistema Digital de Controle Distribuído TCP Transmission Control Protocol WAN Wide Area Network
  8. 8. Sumário 1 Introdução.........................................................................................................................10 1.1 Plataforma Windows em Plantas Industriais..............................................................10 1.2 OPC: Surgimento e Evolução.....................................................................................11 1.3 Objetivo e Estrutura da Monografia ...........................................................................12 2 Automação Industrial: Redes de Comunicação................................................................14 2.1 Níveis Hierárquicos em Sistemas Industriais de Automação.....................................15 2.1.1 Nível de Campo ................................................................................................15 2.1.2 Nível de Controle..............................................................................................16 2.1.3 Nível de Gerência .............................................................................................17 2.2 Meio de Transmissão..................................................................................................17 2.3 Métodos de Transmissão ............................................................................................18 2.4 Topologias de Rede ....................................................................................................18 2.4.1 Estrela ...............................................................................................................18 2.4.2 Barramento........................................................................................................19 2.4.3 Anel...................................................................................................................19 2.5 Aspectos de Projeto de Redes Industriais...................................................................20 2.5.1 Custo .................................................................................................................20 2.5.2 Desempenho......................................................................................................20 2.5.3 Confiabilidade e disponibilidade ......................................................................21 2.5.4 Funcionalidade..................................................................................................21 2.5.5 Tolerância ao meio-ambiente............................................................................22 2.5.6 Meio físico empregado .....................................................................................22 2.5.7 Escalabilidade ...................................................................................................22 2.5.8 Manutenção.......................................................................................................23 2.5.9 Segurança ..........................................................................................................23 2.6 Requisitos de Comunicação para Sistemas de Automação Industrial........................23 2.6.1 Comunicação no Nível de Campo ....................................................................23 2.6.2 Comunicação no Nível de Controle..................................................................24 2.7 Projeto de uma Rede de Comunicação.......................................................................25 3 Fundamentos do OPC.......................................................................................................27 3.1 A Tecnologia que Compõe o OPC .............................................................................27
  9. 9. 3.1.1 Programação Orientada a Objetos ....................................................................27 3.1.2 RPC e DCE .......................................................................................................28 3.1.3 DCOM...............................................................................................................29 3.2 O OPC ........................................................................................................................30 3.2.1 Arquitetura Básica ............................................................................................31 3.2.2 Principais Especificações..................................................................................32 3.2.3 Outras Especificações .......................................................................................48 4 Aplicações e características do OPC - Estudos de casos..................................................56 4.1 Principais conceitos ....................................................................................................57 4.1.1 Aplicações em tempo real e características de desempenho.............................57 4.1.2 Otimização, controle avançado e interoperabilidade de redes heterogêneas ....58 4.1.3 Confiabilidade e Disponibilidade no OPC........................................................58 4.2 Sumário dos casos - Teóricos.....................................................................................59 4.2.1 OPC em sistemas de controle em tempo real....................................................59 4.2.2 Casos teóricos - OPC em controle avançado e otimização...............................62 4.2.3 Casos teóricos - OPC como ferramenta de integração de redes industriais......65 4.3 Sumário dos casos - OPC em situações reais .............................................................69 4.3.1 Testes da Intellution: DCOM, OPC and Performance Issues ...........................69 4.3.2 Testes da Rockwell: The Performance and Throughput of OPC......................70 4.3.3 OPC para o sistema de automação da Aciaria da Açominas ............................72 4.4 Testes de desempenho – Alguns números..................................................................76 4.4.1 Testes da Rockwell: The Performance and Throughput of OPC .....................76 5 Considerações Finais ........................................................................................................80 6 Referências Bibliográficas................................................................................................82
  10. 10. 10 1 Introdução O emprego de redes de supervisão e controle baseadas em protocolos de comunicação digital tem crescido nas mais variadas plantas industriais (CHEN; MOK, 2001). A diversidade desses protocolos e dos equipamentos baseados nos mesmos (OPC FOUNDATION, 1998; PROFIBUS STANDARD, 2006; DEVICENET, 2006), bem como a evolução de suas aplicações na indústria, acabou por gerar sistemas de automação de grande complexidade, compostas por sub-redes heterogêneas de difícil interoperabilidade. A dificuldade de se especificar todo um sistema empregando equipamentos de um único fabricante, comunicando-se através de um mesmo protocolo, também tem contribuído nesse sentido. Além de ser virtualmente impossível em alguns casos, tal abordagem não é desejável do ponto de vista de mercado, pela dependência que se cria de um mesmo fornecedor. Diante dessa realidade, o emprego de um sistema global de controle passa necessariamente por ter-se um mecanismo de comunicação que guarde certa independência do protocolo empregado pelos elementos finais de supervisão e controle, ou seja, dos instrumentos de campo. O OPC (OLE for Process Control) surge como um protocolo de comunicação padronizado e aberto, desenvolvido por um grupo de fabricantes de equipamentos em cooperação com a Microsoft, criadora do Windows, dedicado à promoção da integração de redes industriais heterogêneas. Seu objetivo primário é permitir a troca transparente de dados entre diversos tipos de aplicações, tanto gerenciais quanto de chão de fábrica (OPC FOUNDATION, 1998). 1.1 Plataforma Windows em Plantas Industriais A crescente popularização do sistema operacional Windows e sua maciça presença em sistemas de informática empresariais, acabaram por motivar os principais fabricantes de equipamentos e softwares para controle industrial a desenvolverem sistemas baseados nessa plataforma. Tal fato contribuiu para diminuir o abismo até então existente, sobretudo no aspecto interface homem-máquina (FARENGA, 2006), entre os sistemas de automação e administração das indústrias. Pelo fato de aplicativos Windows já serem bastante utilizados nas tarefas coorporativas (correio eletrônico, editores de texto, planilhas etc.), a própria operação dos sistemas do ponto de vista do usuário médio foi facilitada.
  11. 11. 11 Vencida tal etapa, o próximo passo seria o desenvolvimento de um padrão de comunicação capaz de integrar verticalmente todos os níveis hierárquicos relacionados ao controle da produção (gerenciamento, supervisão de processos, controle e equipamentos no chão de fábrica), facilitando o acesso à informação de forma a acelerar tomadas de decisão (SANTOS, 2006). A solução aparentemente mais adequada consistia em adaptar-se para controle de processos a tecnologia OLE/DCOM (Object Linking and Embedding/Distributed Component Object Model), nativa do Windows, orientada a objeto e já bastante difundida em seus aplicativos (OPC FOUNDATION, 1998). Basicamente, a tecnologia OLE/DCOM permite encapsular componentes escritos em C/C++ (por exemplo, drivers de comunicação) como interfaces padronizadas para serem utilizadas em programas de outras linguagens de programação, eventualmente mais simples de serem utilizadas (FONSECA, 2002). A presença dessa facilidade como interface entre programas motivou o desenvolvimento do padrão OPC fortemente baseado no ambiente Windows. Nele especifica-se como uma aplicação pode acessar dados de um processo independente de sua origem, o que permite que uma mesma aplicação atue em diferentes barramentos de campo sem modificações (RÜPING et al., 1999). 1.2 OPC: Surgimento e Evolução Antes do OPC, caso uma aplicação-cliente (sistema supervisório, por exemplo) requeresse acesso a uma determinada fonte de dados do sistema, o próprio fabricante deveria desenvolver o driver necessário, o que gerava os seguintes problemas (OPC FOUNDATION, 1998): • Duplicação de esforços: fabricantes de software desenvolvendo drivers distintos para o mesmo hardware; • Inconsistências entre drivers: funcionalidade do hardware indisponível da mesma forma por drivers de fabricantes diferentes; • Suporte a mudanças de funcionalidades de hardware: mudança de funcionalidade do hardware levando drivers antigos à incompatibilidade;
  12. 12. 12 • Conflitos de acesso: dois drivers independentes não podem (geralmente) acessar um mesmo dispositivo simultaneamente. Atentos a esses problemas, em 1995 alguns fabricantes de softwares de automação reuniram- se e desenvolveram, com o suporte da Microsoft, o OPC. Sua primeira especificação (OPC Specification Version 1.0) foi apresentada em agosto de 1996. Nos anos seguintes, vários fabricantes aderiram ao padrão, o que gerou a necessidade de modificações e acréscimos de funcionalidades cada vez maiores. Para que isso ocorresse de forma coordenada, foi criada a OPC Foundation, uma entidade sem fins lucrativos destinada exclusivamente à manutenção e divulgação do padrão OPC (FONSECA, 2002). A estratégia adotada pela fundação para adição de novas especificações, atualizações, modificações e manutenção da compatibilidade com versões anteriores, foi a de criar extensões à especificação original. Em 1997 a primeira atualização da especificação foi liberada. Denominada OPC Data Access Specification 1.0A, tal especificação já refletia o novo modelo de extensões adotado (FONSECA, 2002). Por conta do modelo de extensões, o OPC é hoje entendido não como uma especificação, mas sim como um conjunto delas. 1.3 Objetivo e Estrutura da Monografia Este trabalho tem por objetivo apresentar um panorama da aplicação do protocolo OPC em redes industriais como alternativa para integração e interoperabilidade de plantas heterogêneas. No Capítulo 2 são apresentados conceitos de redes industriais relativos a ações supervisão e controle, discutindo-se alguns dos seus aspectos e requisitos mais relevantes. No Capítulo 3 é apresentada uma descrição mais detalhada do protocolo OPC, sendo aprofundados alguns conceitos computacionais envolvidos na sua criação. São também apresentadas e discutidas as motivações e características de suas principais especificações.
  13. 13. 13 No Capítulo 4 são apresentadas algumas aplicações do protocolo OPC em ambiente industrial, discutindo-se vantagens e desvantagens observadas por seus realizadores nas situações descritas. O Capítulo 5 traz algumas considerações sobre o trabalho realizado e perspectivas futuras para o emprego do protocolo OPC em ambiente industrial.
  14. 14. 14 2 Automação Industrial: Redes de Comunicação Os sistemas de controle de processo e manufatura surgiram no início do século passado, baseados primariamente em tecnologia mecânica e em dispositivos analógicos. Passado algum tempo, a introdução da tecnologia de controle pneumático permitiu que sistemas fossem comandados de forma remota, através de sistemas centralizados de controle. Tal abordagem ganhou grande impulso nos anos 1950, com o surgimento dos controladores eletrônicos, que permitiam maiores distâncias de transmissão (DJIEV, 2003). No começo dos anos 1960, com o emprego efetivo de um computador digital como controlador de um sistema, iniciou-se o chamado “controle digital direto”. Porém, o uso de um computador ainda era uma solução cara e distante para a maioria dos problemas de controle existentes. Apenas em meados de 1970 foram anunciados os primeiros sistemas computadorizados de controle distribuído: TDC2000 da Honeywell e CENTUM da Yokogawa (DCS, 2006). Desde a sua introdução, o conceito de DCS (Distributed Control System) se espalhou em muitos sistemas de automação industrial (DJIEV, 2003). Nos anos 1980, o uso de redes locais para interconectar computadores e dispositivos de automação tornou-se popular pela alta capacidade de comunicação a baixo custo oferecidas pelas LANs (Local Area Network). É comum hoje em dia, para usuários de uma rede local, comunicar-se com computadores ou dispositivos de outras redes através de gateways ligados por uma WAN (Wide Area Network). O aumento da dimensão dos sistemas criou a necessidade de se interconectar dispositivos diferentes de forma padronizada, o que levou a consideráveis esforços internacionais de padronização (TANENBAUM, 2003) (MAP, 2006). Para a rede de comunicação de mais baixo nível, soluções de redes locais industriais são demasiado caras e/ou, dependendo da aplicação, não alcançam os curtos tempos de resposta requeridos. Para atender tais exigências, foram desenvolvidos os barramentos de campo (fieldbuses) (DJIEV, 2003).
  15. 15. 15 A seguir são apresentados os níveis hierárquicos que normalmente compõem um sistema industrial de automação e ressaltadas suas principais características. 2.1 Níveis Hierárquicos em Sistemas Industriais de Automação Sistemas industriais de automação podem ser muito complexos e estruturá-los em níveis hierárquicos pode melhorar bastante sua compreensão (Figura 2.1). Cada nível hierárquico tem associado um nível de comunicação com exigências próprias na rede (DJIEV, 2003). Figura 2.1 Hierarquia de um sistema de automação industrial (DJIEV, 2003) 2.1.1 Nível de Campo O nível mais baixo da hierarquia da automação é o nível do campo, no qual estão presentes atuadores e sensores. Os dados transmitidos nesse nível podem ser binários ou analógicos, com tempos de transmissão compatíveis com os tempos de resposta do processo.
  16. 16. 16 Tradicionalmente, a comunicação no nível do campo utiliza largamente cabos paralelos, multi-fios e interfaces seriais. Tais métodos de comunicação (ponto-a-ponto) evoluíram para a rede de comunicação em barramento para lidar com o custo de cabeamento e a necessidade de comunicações de maior capacidade. Devido às exigências de sincronismo que precisam ser estritamente observadas em processos de automação, as aplicações nos controladores do campo requerem funções cíclicas de transporte que transmitam a informação da fonte em intervalos regulares. Além disso, a representação dos dados deve ser tão reduzida quanto possível a fim reduzir o tempo de transferência da mensagem no barramento, tornando-o adequado à aplicação (DJIEV, 2003). 2.1.2 Nível de Controle As funções de controle e intervenção são realizadas neste nível pelos controladores ou operadores de processo. Tais funções incluem o ajuste manual dos set-points de malhas, configuração remota, comandos de válvulas, partidas e paradas programadas da planta etc. As redes de nível de controle devem possuir características de robustez e velocidade próximas do nível de campo. Porém, com recursos para trafegar dados mais complexos, com tempo de transmissão um pouco menos críticos, tais como informações de alarmes, comandos remotos e mensagens de configuração. Além de desempenho compatível com os tipos de dados transmitidos, a rede de controle possui algumas características básicas (DJIEV, 2003): Confiabilidade – Geralmente associada ao uso de meios redundantes. Em caso de falhas no meio físico, como curtos ou rompimento de parte dos cabos, ainda deve ser possível mantê-la operando de forma plena; Segurança para atmosferas explosivas – Apesar de estarem logicamente acima das redes de campo, muitas vezes partes das redes de controle ficam em áreas classificadas e necessitam de esquemas de segurança para minimizar o risco de explosão.
  17. 17. 17 2.1.3 Nível de Gerência Consiste no nível mais elevado da automação industrial de uma planta. Suas estratégias de otimização são responsáveis por recolher informações dos níveis inferiores, integrando-as outros dados tais como estoque, financeiro e programação de produção. Os requisitos para esse tipo de aplicação são bem menos severos. Em geral, permite-se o uso de redes tipicamente não industriais como ethernet e TCP/IP sem maiores problemas. 2.2 Meio de Transmissão Um fator relevante na escolha de uma rede de comunicação industrial é o tipo do sistema de cabeamento físico ou meio de transmissão empregado. O meio mais utilizado em comunicações industriais tem sido o fio de cobre, na forma coaxial ou em par-trançado, mas também são encontradas fibras óticas e tecnologias sem-fio. O cabo coaxial é usado para a transmissão de dados de alta velocidade sobre distâncias de alguns quilômetros, sendo amplamente disponível, relativamente barato e capaz de ser instalado e mantido facilmente. O par-trançado pode ser usado para transmitir dados em banda base a diversos Megabit/s sobre distâncias de 1km ou mais. No entanto, quanto maior a velocidade, menor o comprimento do cabo. Em geral, o par é mais barato que o cabo coaxial. Porém, oferece menor capacidade de transmissão e de proteção eletromagnética. O cabo de fibra ótica oferece capacidade de transmissão acima de GigaBits/s e não sofre com interferências eletromagnéticas. Entretanto, o equipamento associado requerido é mais caro e a realização de conexões multidrop mais complexa. Soluções sem-fio têm-se mostrado, em situações de medição móvel ou provisória, uma opção bastante interessante por sua natureza portátil (DJIEV, 2003).
  18. 18. 18 2.3 Métodos de Transmissão A transmissão de dados pode ser analógica ou digital, dependendo do tipo do dado a ser transmitido (valores contínuos ou binários, respectivamente). Além disso, pode ser assíncrona ou síncrona. No modo assíncrono, cada caractere pode ser enviado independentemente, numa taxa não-uniforme. Já no modo síncrono os dados são transmitidos em blocos e em instantes previsíveis, pela sincronização dos relógios de transmissão e recepção. Os métodos de transmissão em redes industriais incluem banda-base, banda de portadora e fibra ótica. Transmissões em banda base consistem em conjuntos de sinais aplicados ao meio de transmissão sem modulação. Transmissões em portadora empregam apenas uma freqüência para transmitir e receber informações. Transmissões digitais em fibras óticas baseiam-se na representação de 0’s e 1’s por pulsos de luz (DJIEV, 2003). 2.4 Topologias de Rede As principais topologias para redes industriais são mostradas a seguir (TANENBAUM, 2003). 2.4.1 Estrela Uma configuração em estrela (Figura 2.2) contém uma unidade central de conexão a qual todos os nós são conectados diretamente. Isto facilita a conexão para redes pequenas, mas os controladores adicionais devem ser adicionados quando o número máximo dos nós é alcançado. A falha de um nó não afeta os demais. No entanto, caso ocorra uma falha na unidade central, o funcionamento de toda a rede é comprometido. Figura 2.2 Topologia em Estrela (TANENBAUM, 2003)
  19. 19. 19 Figura 2.3 Topologia em Barramento (TANENBAUM, 2003) Figura 2.4 Topologia em Anel (TANENBAUM, 2003) 2.4.2 Barramento Na topologia em barramento (Figura 2.3), cada nó é unido diretamente ao ramo de comunicação comum. As mensagens transmitidas no barramento são recebidas por todos os nós. Se um deles falhar, o restante da rede continua operando, desde que sua falha não afete o meio. 2.4.3 Anel Na topologia em anel (Figura 2.4) o cabo forma um laço e os nós são unidos em intervalos em torno do mesmo. As mensagens são transmitidas em torno do anel, passando pelos nós unidos por ele. Se um único nó falhar, a rede inteira pode parar. Uma forma de evitar isso é ter um fluxo de informações bidirecional através do anel, provendo redundância de caminhos para a rede.
  20. 20. 20 2.5 Aspectos de Projeto de Redes Industriais O projeto de uma rede de comunicação envolve o planejamento e a avaliação criteriosa de diferentes alternativas. O projetista tenta conseguir, por um preço razoável, o desempenho máximo da rede, ou seja, a melhor relação custo-benefício que atenda às especificações do projeto. Para alcançar este objetivo, os requisitos de comunicação e as considerações para um sistema específico da automação devem ser investigados. A definição da estratégia e do planejamento global é a etapa mais crítica de um projeto de rede de comunicação. Os fatores do planejamento que devem ser considerados são (MOON, 1999): custo; desempenho; confiabilidade e disponibilidade; funcionalidade; tolerância ao meio-ambiente; meio físico empregado; escalabilidade; manutenção e segurança. Cada um desses fatores está tratado a seguir. 2.5.1 Custo O custo da rede compreende custos iniciais e custos em operação (DJIEV, 2003). Os custos iniciais incluem: compra de hardware e software; projeto; instalação e partida. Os custos em operação incluem: manutenção de hardware e software; pagamento de pessoal de operação e manutenção; expansão e configuração da rede. 2.5.2 Desempenho O planejamento eficaz de uma rede deve incluir uma estimativa de exigências mínimas de desempenho. A velocidade e a carga da rede são fatores primordiais nesse sentido. Medidas típicas empregadas para isso são: • Taxa de Transmissão – Razão de bits transmitidos por unidade de tempo; • Tempo de Resposta – tempo gasto para que uma ação seja executada após um usuário ou aplicação realizar um pedido. Isso inclui o tempo de processamento gasto nos sistemas de envio e recebimento, tanto no pedido quanto na resposta, além do atraso de transmissão na rede;
  21. 21. 21 • Utilização - comprometimento da capacidade da rede, sendo usualmente representada como a razão do seu uso por sua capacidade; • Throughput - pode ser definido como a capacidade total de um canal em processar e transmitir dados durante um determinado período de tempo. 2.5.3 Confiabilidade e disponibilidade A confiabilidade do equipamento é definida como a probabilidade de que ele operará dentro de sua especificação por um período de tempo definido. Para sistemas capazes de serem reparados, a maneira usual de se avaliar confiabilidade é através do tempo médio entre falhas (MTBF – Mean Time Between Failure). A disponibilidade do equipamento é a proporção de tempo no qual se espera que o equipamento esteja inteiramente operacional. Pode ser representada a partir do MTBF e do tempo médio para reparo (MTTR – Mean Time To MTBF Repair) do sistema da seguinte forma: A = . Para priorizar a disponibilidade MTBF + MTTR de uma rede de comunicação pode-se considerar as seguintes regras (MOON, 1999): • Processos críticos devem ser isolados em áreas de sub-redes que possam executar independentemente da falha do backbone; • Configurações de rede devem ser tão simples quanto possíveis. Quanto maior e mais complexa a rede ou tecnologia, mais itens estarão sujeitos a falhas; • Dispositivos de grande confiabilidade devem ser empregados sempre que possível, além de redundância de equipamentos e meios físicos de rede. 2.5.4 Funcionalidade O projetista da rede deve saber o tipo de dados que ela manipula e qual funcionalidade requer para alcançar seus objetivos. Tipicamente, as funcionalidades requeridas em redes industriais de comunicação incluem: • Transferência de Arquivos;
  22. 22. 22 • Conexão Host-Terminal; • Comunicação peer-to-peer; • Download ou Upload de Programas; • Download ou Upload de Conjuntos de Dados; • Chamada de Programa; • Envio e Recebimento de Dados; • Suporte a Aplicações Distribuídas; 2.5.5 Tolerância ao meio-ambiente Redes de comunicação podem ser montadas em áreas perigosas e expostas à ambientes nocivos. Assim, devem ser projetadas para lidar com interferência eletromagnética, atmosferas ou fluidos corrosivos, temperaturas e climas extremos. Num ambiente industrial, interferência eletromagnética pode corromper pacotes de dados numa rede, causar retransmissões freqüentes, alta carga e redução de throughtput. 2.5.6 Meio físico empregado A escolha dos meios físicos é uma decisão técnica e econômica importante e deve se basear nas exigências estabelecidas para a rede. 2.5.7 Escalabilidade Poucas redes permanecem estáticas diante da expansão de plantas de produção e do desenvolvimento tecnológico. O projeto da rede deve sempre incorporar um fator de flexibilidade para expansão e atualização tecnológica.
  23. 23. 23 2.5.8 Manutenção Todas as redes devem ser mantidas e atualizadas. Um bom projeto de rede deve permitir manutenção preventiva, atualizações e reconfigurações com o mínimo ou sem interrupções de operação. 2.5.9 Segurança Os principais objetivos das medidas contra ataques à segurança são (MOON, 1999): • Minimizar a probabilidade de intrusão e corrupção de informação, fornecendo dispositivos de proteção e procedimentos de segurança; • Detectar qualquer intrusão o quanto antes; • Ser capaz de identificar a informação que tem sido alvo de ataque e identificar a informação de controle/status necessária para recuperar-se do mesmo. 2.6 Requisitos de Comunicação para Sistemas de Automação Industrial Os requisitos de comunicação, em geral, dependem do nível hierárquico na qual se processa (vide Figura 2.1). 2.6.1 Comunicação no Nível de Campo No nível de campo da hierarquia dos sistemas de automação, as comunicações realizadas são para a troca de dados de/para sensores individuais e atuadores empilhados ou muito próximos dos equipamentos de controle. Os requisitos de comunicação nesse nível incluem os seguintes (DJIEV, 2003): • Tempos de resposta muito baixos - Tempos de resposta de microssegundos a milissegundos são necessários para controle de malhas rápidas, sistemas de intertravamento, alarme e segurança;
  24. 24. 24 • Tolerância a atmosferas explosivas - Geralmente requerem invólucros à prova de explosão ou meios de segurança intrínseca; • Longas distâncias - Deve ser possível conectar dispositivos localizados ao longo de uma ampla faixa de distâncias a partir dos racks de terminação: de dezenas de metros (área industrial) a quilômetros (estações remotas de bombeio); • Alimentação Elétrica - Normalmente é distribuída para a maioria dos dispositivos de campo através de dois fios de cabo de sinal. A alimentação dos instrumentos é separada das outras alimentações empregadas na planta, e deve haver backup para operação emergencial. 2.6.2 Comunicação no Nível de Controle No nível de controle da hierarquia dos sistemas de automação, dispositivos de controle, terminais do operador, nós de campo, entre outros, se comunicam entre si. Os requisitos de comunicação para esse nível são os seguintes (MOON, 1999): • Baixo tempo de resposta - Tempos de resposta de milissegundos a segundos são requeridos para comunicação de controle entre um nó e outro, para alarme e para comunicações do operador, onde um grande número de dados pode ser requisitado ao mesmo tempo; • Compatibilidade eletromagnética - Com a migração de nós da rede para o campo, o hardware do sistema precisa ser projetado para lidar com interferência eletromagnética e de radiofreqüência; • Disponibilidade muito alta - A disponibilidade do sistema deve ser muito próxima de 100%, o que requer um MTBF de muitos anos. Em muitos casos isso requer o uso de hardware e meios de comunicação redundantes; • Segurança – O acesso ao sistema de controle deve ser projetado para prevenir acidentes e uso não autorizado que venha a interromper a operação da planta, colocar pessoas ou equipamentos em risco e obter informações sensíveis da operação;
  25. 25. 25 • Backup de alimentação - Na ocorrência de falha de alimentação elétrica, o backup é normalmente provido por fontes redundantes, baterias e/ou unidades moto-geradoras. O sistema precisa lidar com a troca automática entre as fontes; • Gerenciamento de rede - O gerenciamento da rede precisa fornecer (para erros especificados pelo usuário) métodos de recuperação, reconfiguração do sistema durante a operação, segurança, avaliação de desempenho, diagnóstico de falhas, manutenção e treinamento de pessoal operacional. 2.7 Projeto de uma Rede de Comunicação Na Figura 2.5 é apresentado um fluxograma típico de projeto de engenharia. Na fase inicial é realizado um estudo de viabilidade, o qual deve definir o escopo do problema e levantar as opções de rede para o sistema de automação industrial que se pretende interligar. Nesta etapa o projetista precisa entender os problemas e os requisitos para se integrar o sistema de automação, de modo a gerar um documento contendo diretrizes (ainda genéricas) a serem seguidas na etapa seguinte, de projeto básico. Ao longo das etapas de projeto básico e de detalhamento, o nível de abstração com relação à rede vai diminuindo até obter-se a lista completa de material necessário para construí-la. Gerada essa lista, passa-se à etapa de compra desse material, seguida pela montagem e teste da rede pelo seu fornecedor ou integrador. Sendo detectada alguma falha nessa etapa, as modificações necessárias devem ser realizadas e os testes repetidos. Se o teste for concluído sem falhas, passa-se à etapa seguinte, o teste de aceitação em fábrica. O cliente que requisitou a rede vai até o local de teste do fornecedor (fábrica) para acompanhar sua última validação antes dos equipamentos partirem para o campo. Caso seja detectado algum problema, modificações devem ser realizadas e o processo retomado a partir de um novo teste de integração. Caso contrário, os equipamentos são instalados na planta do cliente, sendo realizada a chamada integração com o campo. Na seqüência são realizados pré- testes, os quais verificam a necessidade de retrabalhos. Não sendo detectadas falhas, é realizado o teste de aceitação pelo cliente, na própria planta, pelo qual a rede é entregue para a operação e manutenção.
  26. 26. 26 Error! Início Projeto Básico Projeto de Detalhamento Requisições de Materiais (Compras) Teste de Integração Não Reparametrização/ Passou Modificação do Sistema Sim Teste de Aceitação em Fábrica Não Passou Sim Instalação na planta do cliente Pré-testes Não Passou Re-trabalho Sim Teste de Aceitação pelo Cliente Fim Figura 2.4 Fluxograma de Projeto
  27. 27. 27 3 Fundamentos do OPC 3.1 A Tecnologia que Compõe o OPC Nas próximas seções são apresentadas algumas das tecnologias utilizadas na implementação do OPC, de forma a deixar mais claros alguns conceitos bastante empregados neste e nos próximos capítulos. 3.1.1 Programação Orientada a Objetos Segundo (MONTENEGRO; PACHECO, 1994), a Programação Orientada a Objetos (POO) é um modelo de programação que procura descrever entidades, reais ou abstratas, da forma como as vemos e percebemos, dentro de um determinado contexto ou problema a ser resolvido. Na POO, para cada entidade, os dados (também chamados de atributos) e procedimentos (também chamados de métodos ou serviços) são agrupados (ou encapsulados) em um só elemento básico, chamado de classe ou objeto1. As várias classes/objetos pertencentes a um mesmo sistema, se relacionam entre si através de interfaces. Para (IWANITZ, 2002), uma interface é uma convenção precisa entre um cliente e um servidor, que dita como os métodos devem ser chamados. Assim, um determinado objeto que necessite dos serviços de outro, não precisa saber como este último implementa o código para realizar tal tarefa (como ele faz), apenas deve conhecer a sua interface (o que ele faz). Esta última propriedade é também conhecida como encapsulamento, e leva a uma das principais vantagens da POO: a reusabilidade de código, que permite reduzir o tempo de desenvolvimento do software, e, conseqüentemente, aumentar a produtividade. 1 Apesar dos conceitos de classe e objeto serem conceitos similares (mas não idênticos), utilizaremos estes conceitos, neste trabalho, como sinônimos.
  28. 28. 28 3.1.2 RPC e DCE Na década de 80, com o intuito de tornar possível a computação distribuída num ambiente multi-plataforma para diversos aplicativos, um consórcio de companhias criou a OSF (Open Software Foundation), que acabou por gerar um conjunto de especificações reunidas sob o termo DCE (Distributed Computing Environment), em uso até os dias de hoje (IWANITZ, 2002). Os mecanismos de comunicação definidos pela OSF, também chamados de RPC (Remote Procedure Call) ou Chamada de Procedimento Remoto, definem como os aplicativos podem se comunicar e como cada um pode chamar funções ou métodos de outro, empregando para isso serialização (marshalling) e desserialização (demarshalling). Tais procedimentos consistem basicamente na codificação e decodificação, respectivamente, de parâmetros dependentes de um processo e sistema operacional específicos, em parâmetros independentes dos mesmos, de forma que possam ser transportados em diferentes tipos de rede (IWANITZ, 2002). O proxy é o componente deste sistema responsável pela serialização, enquanto o stub realiza a operação inversa (desserialização). O cliente não chama um procedimento remoto no servidor, mas interage diretamente com o proxy, que realiza a serialização e repassa a chamada ao stub. Este por sua vez desserializa a chamada e a repassa diretamente ao servidor, onde o procedimento é realmente implementado. A resposta do servidor (callback) é feita da mesma forma, na direção oposta. Isto permite que toda a operação de chamada e resposta seja transparente ao cliente/servidor. Assim, através do RPC é garantida ao usuário a flexibilidade para implementar-se procedimentos onde seja mais conveniente na rede, de forma a atingir determinados objetivos de desempenho e/ou confiabilidade (IWANITZ, 2002). Na época do surgimento do RPC, a POO ainda não era o modelo de programação mais utilizado, o que levou a Microsoft a adaptar esta tecnologia para o conceito de POO, já com interesse no desenvolvimento do DCOM. O resultado desta adaptação resultou na designação ORPC (Object RPC) (IWANITZ, 2002).
  29. 29. 29 Figura 3.1 Arquitetura do DCOM (MICROSOFT, 1996) 3.1.3 DCOM O DCOM nasceu a partir da tecnologia OLE (Object Linking and Embedding), que surgiu no início da década de 90, para permitir a integração de dados entre aplicações no Windows. Isto permitia, por exemplo, inserir uma planilha Excel em um documento do Word e, a partir deste último, acessar e editar de forma dinâmica, todos os dados da primeira (IWANITZ, 2002). A abordagem do OLE foi estendida para outros tipos de aplicativos, na forma de um modelo orientado a objetos disponível a todas estas aplicações, através dos chamados componentes. Esta tecnologia foi batizada de Component Object Model (COM), em 1995 (IWANITZ, 2002). A necessidade de compartilhar estes componentes através da rede levou ao desenvolvimento do DCOM, resultado da união das tecnologias COM e DCE RPC (mais especificamente, o ORPC) (IWANITZ, 2002). Surgido em 1996, o DCOM utiliza o formato cliente-servidor (Figura 3.1) e permite o acesso, através de conexões e serviços, tanto de um servidor por vários clientes, quanto de um cliente por vários servidores. Como no RPC, é transparente aos clientes a localidade de execução do componente do qual se utilizam os serviços (MICROSOFT, 1996).
  30. 30. 30 Como um modelo orientado a objetos, que também herda funcionalidades do RPC, o DCOM se constitui basicamente de (IWANITZ,2002): • Classes, Métodos e Interfaces. Com a IDL (Interface Definition Language) todas as classes (objetos DCOM), métodos e interfaces são descritos e convertidos em bibliotecas C, que por sua vez são compiladas e associadas a uma DLL do sistema Windows; • Proxy/Stub. É a DLL resultante da compilação, responsável pela serialização e desserialização, utilizada pelos clientes e servidores DCOM em tempo de execução; • Identificadores. Também chamados de GUIDs (Globally Unique Identifiers), são valores de 128 bits que identificam unicamente as partes de um sistema baseado no DCOM. Podem aparecer na forma de: CLSID (Class Identifier), para identificar unicamente uma classe ou objeto DCOM; IID (Interface Identifier), para identificar unicamente uma interface; ou CATID2 (Category Identifier), para identificar categorias específicas de um mesmo componente. Todos estes identificadores são cadastrados no registro (registry) do sistema operacional. Através da IDL e do GUID, as interfaces são protegidas contra modificação e identificadas unicamente, garantindo a compatibilidade dos objetos (mesmo no caso de modificações de versão), independente do ambiente em que foram criados (FONSECA, 2002). 3.2 O OPC Herdando todas as características das tecnologias descritas anteriormente, o OPC utiliza um modelo cliente-servidor, onde o servidor oferece interfaces para os objetos OPC e os gerencia (OPC FOUNDATION, 2003a). Dessa forma, existem interfaces, métodos e classes especialmente voltadas para as necessidades de controle de processos, reunidas na forma de especificações, cada uma delas implementando um conjunto específico de funcionalidades. Conforme estas necessidades evoluem, as especificações também o fazem, sendo este um dos principais motivos da constante atualização de versões das especificações. 2 É o CATID que identifica unicamente as diferentes especificações e versões das mesmas no OPC
  31. 31. 31 A partir desta seção, são descritas as principais especificações do OPC nas suas versões vigentes atualmente (Dezembro 2006), com o objetivo de fundamentar a análise de aplicabilidade feita mais adiante. 3.2.1 Arquitetura Básica O OPC é uma especificação para dois conjuntos de interfaces: as interfaces OPC Custom e OPC Automation. Apenas a OPC Custom deve ser implementada obrigatoriamente em todos servidores, sendo a OPC Automation um conjunto de interfaces de implementação opcional. As interfaces OPC Custom são projetadas para serem utilizadas com linguagens de programação que empregam ponteiros, como C/C++, enquanto que, para linguagens mais simples, como Visual Basic, Delphi e VBA, devem ser utilizadas as interfaces OPC Automation. Nestas últimas existe um componente a mais no servidor OPC, chamado Automation Wrapper, que encapsula e gerencia as chamadas entre as linguagens sem ponteiros e a interface OPC Custom, conforme apresentado na Figura 3.2(OPC FOUNDATION, 2003a). Figura 3.2 Arquitetura Básica do OPC (OPC FOUNDATION, 2003a) Também é esperado que o servidor consolide e otimize as requisições de acesso a dados de vários clientes, promovendo comunicações eficientes com os dispositivos de campo. Para leitura, os dados retornados pelos dispositivos são armazenados em um buffer para
  32. 32. 32 distribuição assíncrona ou coleta síncrona por vários clientes OPC. Para escritas, o servidor OPC atualiza os dados nos dispositivos físicos, independente dos clientes OPC. Entre a memória cache do servidor OPC e o dispositivo de campo pode existir qualquer meio físico e/ou protocolo de comunicação, e a comunicação é feita por protocolos que podem ser proprietários ou não. Desta forma, é transparente ao cliente OPC qual protocolo está sendo utilizado num nível mais baixo, já que o mesmo só se comunica através do servidor, o que padroniza a comunicação no nível superior. 3.2.2 Principais Especificações A seguir estão listadas as especificações atualmente disponíveis (OPC FOUNDATION, 2006c): • OPC Common Definitions and Interfaces. Fornece e descreve definições, interfaces e serviços comuns a todas especificações (versão 1.00); • OPC Data Access (DA). Principal especificação do OPC, fornece a funcionalidade de transferência de dados de tempo real e contínua de CLPs, SDCDs e outros, para IHMs, sistemas supervisórios e similares (versão 3.00); • OPC Alarms & Events (AE). Fornece notificações de alarmes e eventos sob demanda, como alarmes de processo, ações do operador, auditagem etc (versão 1.10); • OPC Historical Data Access (HDA). Fornece mecanismos consistentes e uniformes de acesso a dados de histórico já armazenados (versão 1.20); • OPC Batch. Traz a filosofia do OPC às aplicações de processamento em batelada processamento em batelada (batch processing), permitindo mecanismos de troca de informações e condições operacionais atuais em equipamentos que implementam este tipo de controle. É uma extensão da OPC-DA (versão 2.00); • OPC Data eXchange (DX). É uma extensão do OPC-DA, e fornece mecanismos para troca de dados entre diferentes servidores OPC-DA através de redes de campo
  33. 33. 33 heterogêneas, incluindo serviços de configuração, diagnóstico, monitoração e gerenciamento remotos (versão 1.00); • OPC Security. Fornece mecanismos de controle de acesso a informações de processo e proteção contra modificações não autorizadas de parâmetros do mesmo (versão 1.00); • OPC XML-DA (XMLDA). Extensão da OPC-DA, fornece mecanismos consistentes e flexíveis para apresentação dos dados de chão de fábrica usando a linguagem XML, permitindo sua apresentação em navegadores Web via Internet/Intranet (versão 1.01); • OPC Complex Data: Outra extensão da OPC-DA, permite aos servidores a descrição e representação de formatos de dados mais complexos, tais como estruturas binárias, arrays e outros. Vem sempre associada à DA ou à XMLDA (versão 1.00). Vale ressaltar que estão atualmente em desenvolvimento novas especificações que permitem incorporar novas funcionalidades, motivadas por tendências de mercado e necessidades de muitos usuários do padrão OPC. Das especificações, merece destaque especial um novo conjunto, nomeado de OPC Unified Architecture (UA). Este conjunto visa, entre outros objetivos, tornar todas as especificações atuais melhor adaptadas aos serviços Web, além de tornar o OPC independente do DCOM e, portanto, suportado em outras plataformas não- Windows, como GNU/Linux, Unix e outros (MATRIKON, 2006). Com todas estas funcionalidades disponíveis no padrão OPC, os fornecedores de diversos produtos hoje disponíveis no mercado introduzem as seguintes vantagens (FONSECA, 2002): • Padronização das interfaces de comunicação entre os servidores e clientes de dados de tempo real, facilitando a integração e manutenção dos sistemas; • Eliminação da necessidade de drivers de comunicação específicos (proprietários); • Melhoria do desempenho e otimização da comunicação entre dispositivos de automação;
  34. 34. 34 • Interoperabilidade entre sistemas de gestão empresarial (Enterprise Resource Planning - ERP), de execução de manufatura (Manufacturing Execution System - MES) e aplicações Windows (Excel, etc.); • Redução dos custos e tempo para desenvolvimento de interfaces e drivers de comunicação, com conseqüente redução do custo de integração de sistemas; • Facilidade de desenvolvimento e manutenção de sistemas e produtos para comunicação em tempo real; • Facilidade de treinamento. Nas próximas seções é realizada uma descrição mais detalhada das especificações mais utilizadas na prática (OPC-DA, OPC-AE e a OPC-HDA) e da nova especificação (OPC-UA). As demais são agrupadas em só uma seção e descritas de forma sucinta. São abordadas somente as interfaces do tipo Custom, já que as do tipo Automation são baseadas nelas. 3.2.2.1 OPC Data Access Specification (DA) Conceitos, Modelos e Objetos Atualmente na versão 3.0, a OPC Data Access Specification, ou OPC-DA, foi a primeira das especificações a ser lançada, em 1996. Naquela época, em sua versão 1.0, era chamada simplesmente de OPC Specification. Pelo novo conceito de extensões adotado, foi renomeada em 1997 para OPC Data Access Specification e a versão atualizada para 1.0A. Basicamente, a OPC-DA fornece interfaces, objetos e métodos que permitem o acesso a dados de chão de fábrica em tempo real. É a principal e mais básica entre as especificações. Qualquer sistema que necessite monitorar dados de campo em tempo real deve, no mínimo, dispor de um servidor e um cliente que implemente a OPC-DA. Nela existe uma hierarquia com três objetos principais no servidor: • OPCServer. Realiza todo o gerenciamento de conexão com o cliente e retorno dos dados, fornece navegação pelos objetos disponíveis no servidor, métodos para
  35. 35. 35 gerenciamento (ex: criação/destruição), pelo cliente, de objetos OPCGroup, entre outros; • OPCGroup. Realiza o agrupamento lógico e gerenciamento de objetos OPCItem, gerenciamento de estado dos grupos (groups), disponibiliza métodos de escrita/leitura nos itens, etc; • OPCItem. Representa o dado de campo propriamente dito, também chamado de item, e é totalmente gerenciado pelo objeto OPCGroup. Segundo (IWANITZ, 2002), o objeto OPCItem não é um objeto “real”, pois não possui métodos e interfaces próprias para seu gerenciamento. Isto ocorre porque, na prática, existem muitos itens a serem lidos/escritos ao mesmo tempo e o gerenciamento feito através dos grupos é mais eficiente, pois permite que a operação seja feita em apenas uma chamada. A hierarquia de objetos mostrada permite flexibilidade aos clientes, pois cada um deles pode criar seu conjunto de itens e grupos, definindo sua própria visão do processo. Outro conceito utilizado pelos servidores OPC-DA é o de espaço de nomes (namespace), que nada mais é do que outra hierarquia criada e configurada no servidor para representar a topologia de todos os dispositivos monitorados pelo servidor. Ela é composta por itens com identificadores chamados ItemIDs, que identificam unicamente um dispositivo de campo. Diferentemente da hierarquia de objetos, o namespace é único para cada servidor, e pode se associar com várias hierarquias de objeto ao mesmo tempo. A Figura 3.3 mostra um exemplo desta associação: à esquerda está o namespace e à direita os objetos do servidor. Nota-se que dois objetos OPCItem podem estar associados a um mesmo item do namespace, através de seu ItemID, ilustrando a flexibilidade da hierarquia de objetos, já comentada. Para finalizar, vê-se também, no namespace, duas informações associadas ao item Raiz.Andar_2.Temp. Estas são chamadas de propriedades e representam informações relativamente estáticas relacionadas ao item do namespace, que também podem ser cadastradas no mesmo, durante a configuração do servidor.
  36. 36. 36 Figura 3.3 Namespace e Hierarquia de Objetos (IWANITZ, 2002) Principais Funcionalidades (OPC FOUNDATION , 2003a) • Escrita/Leitura Síncrona e Assíncrona: Na escrita/leitura síncrona, o cliente requisita os dados e os recursos de sistema só são liberados quando os valores são retornados pelo servidor. É mais simples de implementar, mas pouco eficiente, ocupando muitos recursos de rede quando existem muitos dados a trafegar. No modo assíncrono, o cliente se “cadastra” (subscribe) no servidor para receber determinada quantidade de dados e libera os recursos logo após a chamada. Após esta etapa, os dados solicitados são enviados ao cliente à medida que o servidor os tiver disponíveis. É mais eficiente para grandes quantidades de dados. Adicionalmente, a leitura/escrita pode ser feita tanto através da memória cache do servidor, quanto diretamente no dispositivo. Alguns exemplos de interface são: OPCGroup::IOPCSyncIO, OPCGroup::IOPCAsyncIO entre outras (OPC FOUNDATION, 2003a); • Banda Morta: Por banda morta (deadband), entende-se uma faixa de valores (relativa ao range de leitura) na qual variações não causam envio de dados para o servidor. Isto permite economia de recursos de rede, já que o servidor não precisa enviar os valores a cada mudança, somente quando violarem a banda morta. A configuração deste parâmetro torna possível o envio por exceção de valores analógicos. A interface disponível na OPC-DA para gerenciamento da banda morta é OPCGroup::IOPCDeadBandMgt; • Formato de Dados: Na OPC-DA, cada item de dado tem três componentes básicos: o valor propriamente dito, do tipo VARIANT (com subtipos Float, Integer etc); a rótulo de tempo (timestamp) no formato UTC (Universal Time Code), que representa a informação do tempo (com resolução de 100ns) em que o servidor recebeu o dado de
  37. 37. 37 um dispositivo; e dois bytes que representam a qualidade associada ao dado (ex: “Bom”,”Ruim” e “Indefinido”); • Envio por Exceção: Permite o envio de dados ao cliente assim que há mudança de valores (acima da banda morta configurada) ou qualidade dos mesmos. Implementado pelo método (do cliente) IOPCDataCallback::OnDataChange; • Ativação/Desativação de Itens e Grupos: Permite ativar/desativar a monitoração dos grupos e itens, para realizar a manutenção em algum dispositivo, por exemplo. Implementado por métodos como: IOPCGroupStateMgt::SetState e IOPCItemMgt:: SetActiveState. 3.2.2.2 OPC Alarms and Events Specification (AE) Conceitos, Modelos e Objetos A Alarms and Events Specification, ou OPC-AE, descreve objetos e interfaces que são implementadas por servidores OPC-AE que fornecem mecanismos para os clientes OPC serem notificados de condições de alarme e eventos específicos, além de serviços que permitem ao cliente saber os tipos de eventos e condições suportadas pelo servidor, bem como seus estados atuais. Para serem notificados, os clientes se “cadastram” (subscribe) no servidor para receber os eventos que atendam a um determinado critério (OPC FOUNDATION, 2002). Existem dois conceitos importantes: o de condição e o de subcondição. Uma condição basicamente reflete um estado do servidor OPC-AE, ou dos objetos que o compõem, que é de interesse de um determinado cliente. Por exemplo, um alarme de nível associado a um determinado equipamento de campo é uma condição. A subcondição representa um detalhe maior da condição. No nosso exemplo, o estado “Nível Alto” representaria uma subcondição da condição “Alarme de nível”. Assim, uma condição pode ter várias subcondições associadas, como “Baixo”, “Alto”, “Muito Baixo”, “Muito Alto”. A cada condição e subcondição estão associados atributos que fornecem um detalhamento maior do estado atual e outras informações. Para manter uma padronização mínima, existem atributos que são
  38. 38. 38 obrigatórios e definidos na especificação. Os demais são chamados de “específicos de fabricante”. Nesse contexto, a especificação define um alarme como um caso especial de uma condição, ou seja, uma condição anormal, enquanto que um evento é definido como uma ocorrência detectável que seja significativa para o servidor, o dispositivo que o representa, e os clientes associados. Não necessariamente todos os eventos estão associados a condições: ações do operador, mudanças de configuração, entre outros (OPC FOUNDATION, 2002). A especificação prevê três tipos de eventos: • Eventos Simples: São eventos mais básicos, que não exigem ações de reconhecimento pelo operador (ex: “bomba ligada”); • Eventos Relacionados a Rastreamento (auditoria): Possuem os mesmos atributos dos eventos simples, com um atributo adicional, chamado ActorId, para permitir rastreabilidade dos dados (ex: identificação de que operador realizou uma ação); • Eventos Relacionados à Condição: São os eventos mais complexos, que estão associados com condições e subcondições da planta, têm mais atributos, e exigem uma ação de reconhecimento, pelo operador, da ativação de uma subcondição (alarme). A Figura 3.4 ilustra os três tipos de evento com alguns dos atributos mais comuns. Vale ressaltar o atributo Severity, representado por um número de 1 a 1000, que indica o nível de severidade (urgência) de uma subcondição. Conforme a especificação, cada fabricante de servidor é responsável por mapear os valores de severidade (caso existam) específicos dos seus protocolos proprietários naquela faixa de valores. Como na OPC-DA, os servidores da OPC-AE também implementam uma hierarquia para representar como estão dispostos os eventos no campo ou chão de fábrica. Esta hierarquia é chamada de área de eventos ou EventArea. Nela existem as fontes de evento, associadas geralmente aos dispositivos de campo que os geram, agrupadas em áreas, que representam as áreas físicas reais da planta. Como vemos adiante, o servidor OPC-AE implementa interfaces e métodos específicos para navegação na área de eventos.
  39. 39. 39 Figura 3.4 Atributos de Eventos (IWANITZ, 2002) Um último conceito na OPC-AE é o de filtragem, que permite que os clientes se cadastrem no servidor para receber os eventos atendendo a determinados critérios de interesse, como por exemplo, eventos com uma severidade específica, de uma área específica. Também são vistas adiante algumas interfaces que o servidor fornece para possibilitar a filtragem. Os objetos que compõem um servidor OPC-AE são três: • OPCEventServer. Gerencia as conexões com clientes, cria e gerencia os objetos OPCEventSubscription, ativa/desativa determinadas condições/subcondições, fornecem os mecanismos para filtragem e filtros disponíveis no servidor entre outros; • OPCEventSubscription. Representa o cadastramento (subscription) dos clientes para receber os eventos e fornece os métodos para realizar a filtragem dos mesmos. Cada objeto deste tipo está associado somente a um filtro; • OPCEventAreaBrowser. Fornece mecanismos para navegação do cliente na área de eventos, possibilitando que ele conheça quais eventos estão disponíveis no servidor.
  40. 40. 40 A Figura 3.5 mostra o exemplo de um servidor com seus objetos associados a uma área de eventos. Figura 3.5 Servidor OPC-AE e Área de Eventos (IWANITZ, 2002) Principais Funcionalidades (OPC FOUNDATION, 2002) • Envio através de cadastramento (subscription) e notificações: Conforme já mencionado, esta funcionalidade permite que os clientes se cadastrem no servidor para o recebimento de notificações de todos os tipos de evento. Exemplos de interfaces e métodos são: IOPCEventServer::CreateEventSubscription para realizar o cadastramento no servidor e IOPCEventSink::OnEvent (método do cliente) para permitir o recebimento de notificações pelo cliente; • Reconhecimento de alarmes: Permite que o cliente reconheça as condições anormais classificadas como alarme durante a configuração do servidor. O método para esta funcionalidade é o IOPCEventServer::AckCondition; • Auditoria: Fornece o rastreamento necessário para determinados eventos, armazenando o identificador do cliente OPC-AE que iniciou um evento relacionado a rastreamento. Implementada pelo atributo ActorId dos eventos relacionados a rastreamento;
  41. 41. 41 • Pesquisa através de filtros: Permite que o cliente pesquise os atributos de evento e restrinja o recebimento de notificações para um subconjunto que atenda a determinados critérios desejados. Exemplos de métodos: IOPCEventServer::QueryAvailableFilters, IOPCEventSubscriptionMgt::SetFilter/Get Filter; • Ligação de eventos com itens da OPC-DA: Os servidores OPC-AE podem existir isolados ou em conjunto com servidores OPC-DA. Neste último caso, pode ser desejável para a aplicação-cliente saber, além do estado de alarme de uma condição, o valor de tempo real associado à mesma, que pode estar disponível em um servidor OPC-DA. Para isso, existe no servidor OPC-AE o método IOPCEventServer::TranslateToItemIDs; • Ativação/Desativação de Eventos e/ou Áreas: Pode ser desejável a ativação/desativação das notificações de um ou mais eventos, para fins de manutenção. Para este caso, existem, por exemplo, os seguintes métodos: IOPCEventServer::Enable/DisableConditionByArea e IOPCEventServer::Enable/ DisableConditionBySource. 3.2.2.3 OPC Historical Data Access (HDA) Conceitos, Modelos e Objetos A Historical Data Access Specification, ou OPC-HDA, descreve objetos e interfaces necessários ao acesso (escrita e leitura) a bases de dados históricas. Ao implementar estas interfaces, os fabricantes de servidores OPC-HDA tornam este acesso transparente aos clientes, permitindo a integração deste tipo de dados em todos os níveis de uma empresa, independente do mecanismo (engine) de armazenamento que se utilize em níveis mais baixos de camada de software. As bases de dados históricas são ferramentas poderosas utilizadas por especialistas ou até gerentes para análise dos dados de uma planta, auxiliando nas decisões. Nelas, cada variável fica armazenada como uma série de valores (também chamada de vetor, array ou dado de
  42. 42. 42 tendência), sendo registrada sua variação numa determinada faixa de tempo, e permitindo seu acesso posterior pelos usuários. Os principais tipos de servidores suportados por esta especificação são (OPC FOUNDATION, 2003b): • Servidores simples de tendência. Armazenam os dados de forma bruta (raw data), na forma de uma tupla, cada um com informações de tempo, valor e qualidade (similar ao formato utilizado na OPC-DA); • Servidores complexos de compressão e análise de dados. Fornecem compressão de dados, bem como armazenamento bruto. Os mesmos são capazes de fornecer dados sumarizados (também chamados de agregados ou funções de análise dos dados) como médias, mínimos ou máximos etc. Além disso, podem suportar atualização dos dados (e o histórico destas atualizações) e anotações do usuário. Vale ressaltar que algumas das funcionalidades desses servidores são implementadas através de interfaces opcionais (apesar de previstas na especificação), ou seja, os fabricantes de servidores podem não implementá-las por conveniência. Isso exige do usuário uma observação mais atenta na hora da aquisição de um servidor histórico que satisfaça as suas necessidades. Alguns termos e conceitos utilizados freqüentemente na especificação são (OPC FOUNDATION, 2003b): • Atributos. Qualificadores adicionais que um item em particular tem associado com ele. Ex: o tipo de dados, flags para identificar se o mesmo suporta interpolação ou se o dado está sendo gravado, etc; • Agregados (Aggregates). Métodos que sumarizam os dados, como médias, mínimos e máximos (todos sobre intervalos de tempo). Estes métodos são executados sempre durante a recuperação dos dados; • Anotações. Comentários inseridos por um operador ou usuário em relação ao um determinado item, geralmente em uma determinada instância de tempo;
  43. 43. 43 • Valores de limite (Bounding Values). São os valores requeridos pelo cliente para determinar os pontos inicial e final de um determinado período de tempo. Se um valor de dado existe em um destes pontos, o mesmo é considerado o valor de limite. Se o valor não existe, o próximo valor fora da faixa de tempo especificada é considerado o limite; • Dados Interpolados. Dado derivado dos dados arquivados, para o qual não há valor armazenado. Geralmente, é derivado linearmente de dois pontos adjacentes ao rótulo de tempo solicitado, que não está armazenado. Também, pode ser derivado da extrapolação dos dados arquivados, por um método mais complexo; • ItemID. Uma string que referencia unicamente o item de dados no endereçamento do servidor. É similar ao ItemID da OPC-DA; • Valor Modificado. Valor que foi alterado após o seu armazenamento no servidor; • Dados brutos (Raw Data). Dados efetivamente armazenados no servidor. Podem ser comprimidos ou não, dependendo das regras de armazenamento definidas durante a gravação; • Domínio de tempo. Intervalo de tempo definido pelos tempos inicial e final. Os dados dentro deste domínio podem estar na ordem direta ou inversa, dependendo se o tempo inicial é menor ou maior do que o final, respectivamente. Vale ressaltar que, em relação aos agregados, a especificação define requisitos comuns e específicos de cada tipo de agregado, de forma a uniformizar a recuperação deste tipo de dados no caso de utilização de servidores de diferentes fabricantes. A seguir estão listados os dois objetos de um servidor OPC-HDA: • OPCHDA_Server. Fornece as interfaces de gerenciamento da conexão com os clientes, escrita, leitura e atualização dos dados históricos, anotações e playback;
  44. 44. 44 • OPCHDA_Browser. Fornece a interface para navegação (pelo cliente) no espaço de endereços do servidor (address space). Este espaço é semelhante ao namespace descrito na OPC-DA. A diferença é que, na OPC-HDA, a interface para navegação é obrigatória. Principais Funcionalidades (OPC FOUNDATION, 2003b) • Leitura (Read) e atualização (Insert. Delete, Replace) Síncrona e Assíncrona: Existem interfaces para leitura e atualização (inserção, exclusão e reescrita) síncrona e assíncrona dos dados históricos. Todas as interfaces assíncronas e a interface de atualização síncrona são opcionais. Exemplos de interface: IOPCHDA_SyncRead, IOPCHDA_SyncUpdate, IOPCHDA_AsyncRead, IOPCHDA_AsyncUpdate; • Anotações: As interfaces, a seguir, fornecem mecanismos para criação e gerenciamento de anotações no servidor. Vale ressaltar que esta funcionalidade é opcional. IOPCHDA_SyncAnnotations, IOPCHDA_AsyncAnnotations; • Playback: O mecanismo de playback permite que se retorne um conjunto inicial de dados e, posteriormente, este conjunto seja atualizado continuamente. IOPCHDA_Playback (opcional) ; • Agregados: O método IOPCHDA_Server::GetAggregates permite ao cliente saber quais agregados são suportados pelo servidor. 3.2.2.4 OPC Unified Architecture (OPC-UA) Conceitos, Modelos e Objetos Atualmente em draft, a OPC Unified Architecture Specification, ou simplesmente OPC-UA, é uma implementação multi-plataforma, onde vários tipos de sistemas e dispositivos podem se comunicar através de mensagens entre clientes e servidores em vários tipos de redes, suportando uma comunicação robusta e segura que garante a identidade dos clientes e dos servidores (OPC FOUNDATION, 2006b).
  45. 45. 45 O modelo de arquitetura dos sistemas OPC-UA trata os clientes e servidores OPC-UA como parceiros que interagem de diversas formas, cada sistema pode conter diversos clientes e servidores. Cada cliente OPC-UA pode interagir com um ou mais servidores OPC-UA e cada servidor OPC-UA pode interagir com um ou mais clientes OPC-UA. Uma aplicação possível consiste em combinar componentes de servidor e de cliente para permitir interação entre servidores por exemplo (OPC FOUNDATION, 2006b). A aplicação cliente é um código que implementa a função de cliente , utilizando o OPC-UA Client API para enviar e receber solicitações do OPC-UA Service ao OPC-UA Server como mostra a Figura 3.6. Figura 3.6 Cliente OPC-UA (OPC FOUNDATION, 2006b) O OPC-UA Client API é uma interface interna que isola o código da aplicação cliente da pilha de comunicação – OPC-UA Communication Stack. As requisições da aplicação cliente são feitas ao OPC-UA Client API, sendo que a OPC- Communication Stack converte estas chamadas em mensagens que são enviadas ao servidor OPC-UA via rede de comunicação. Da mesma forma ocorre, no sentido inverso, o recebimento das mensagens originadas no servidor OPC-UA, é realizado pela OPC-UA Communication Stack e enviadas via OPC-UA Client API para a aplicação cliente (OPC FOUNDATION, 2006b). A arquitetura do servidor OPC-UA modela as fronteiras da aplicação servidor e as interações servidor/cliente. A Figura 3.7 ilustra a aplicação servidor OPC-UA. Os Real Objects são objetos, físicos ou de software, que são acessíveis da aplicação servidor ou mantidas internamente, um dispositivo físico ou contadores de diagnóstico, por exemplo.
  46. 46. 46 O OPC-UA Server Application é o código que executa a função de servidor, utiliza o OPC- UA Server API para enviar e receber mensagens, OPC-UA Messages, para o cliente OPC-UA (OPC FOUNDATION, 2006b). Figura 3.7 Servidor OPC-UA (OPC FOUNDATION, 2006b) O OPC-UA Server API é uma interface que isola o código da aplicação servidor da pilha de comunicação – OPC-UA Communication Stack, esta pode ser uma implementação padrão fornecida pela OPC Foundation ou uma implementação específica de um fornecedor. O espaço de endereço – OPC-UA AdressSpace, ou simplesmente AdressSpace, é definido como um conjunto de nós (Nodes) acessíveis pelo cliente usando o OPC-UA Services (interfaces e métodos). Os nós no AdressSpace são usados para representar objetos reais, suas definições e suas referências entre si. Principais Funcionalidades (OPC FOUNDATION, 2006b) • Envio de Notificações: Esta funcionalidade, solicitada via OPC-UA Service Interface, consiste no envio de notificações periódicas aos clientes, incluindo eventos, alarmes e troca de dados;
  47. 47. 47 • Interações Servidor-Servidor: Interações entre servidores na qual um servidor comporta-se como um cliente de outro servidor. Estas interações entre servidores permitem a implementação de servidores que trocam informações com outros servidores (Figura 3.8), incluindo redundância ou servidores remotos e envio de dados de chão de fábrica para aplicações no nível de planta (Figura 3.9); Figura 3.8 Interação entre Servidores OPC-UA (OPC FOUNDATION, 2006b) Figura 3.9 Servidores OPC-UA entre Níveis Hierárquicos (OPC FOUNDATION, 2006b) • Disponibilidade dos dados em vários formatos: Os dados podem ser disponibilizados em diversos formatos, incluindo estruturas binárias e documentos XML. Com o AddressSpace, o cliente pode requisitar ao servidor o Metadata que descreve o formato dos dados. Em muitos casos, os clientes mesmo sem conhecer o formato dos dados, podem determinar o formato e utilizar corretamente os dados disponíveis no servidor. Isto permite a utilização do OPC-UA tanto em ambientes Web (modelo XML) quanto em redes industriais locais (modelo binário), em que o requisito de tempo de resposta é mais exigente;
  48. 48. 48 • Modelo de segurança personalizado: Os procedimentos de segurança podem ser selecionadas e configuradas para cada aplicação, incluindo mecanismos e parâmetros de segurança padronizados, é definido um número mínimo de perfis de segurança que todos servidor OPC-UA deve implementar. Quando uma seção é estabelecida, as aplicações do cliente e do servidor negociam um canal de comunicação seguro e seus softwares de certificação – Software Certificates – identificam o cliente e o servidor em questão, bem como sua capacidade disponível, utilizando este canal de comunicação seguro, os usuários precisam ser autenticados uma única vez, quando a aplicação é estabelecida; • Unificação de modelos: Cada uma das especificações anteriores do OPC (DA, HDA e AE) definiu seu próprio modelo de espaço de endereço e seu próprio conjunto de serviços. A OPC-UA unifica todos os modelos em um único espaço de endereço com um único conjunto de serviços. Com a compatibilidade entre servidores OPC-UA e servidores OPC que utilizam tecnologia Microsoft (COM/DCOM), os dados existentes em servidores OPC (DA, HDA e AE) podem ser facilmente utilizados por servidores OPC-UA. Assim os fornecedores podem escolher migrar seus produtos nativos para o OPC-UA ou usar encapsuladores externos para converter o OPC DCOM para a OPC- UA e vice-versa; • Soluções para redundância: Esta especificação permite que os fornecedores desenvolvam clientes e servidores redundantes de forma consistente, esta redundância pode ser utilizada para obter: alta disponibilidade, tolerância falhas e distribuição de processamento. 3.2.3 Outras Especificações 3.2.3.1 OPC XML-DA A XML-DA oferece métodos e interfaces para mapeamento dos serviços disponíveis na OPC- DA através do protocolo SOAP (Service Oriented Access Protocol), tornando as interfaces e métodos de acesso a dados do OPC disponíveis em ambiente Web. Segundo o (W3C, 2003), o SOAP é um protocolo destinado à troca de informações estruturadas em um ambiente distribuído e descentralizado. Ele utiliza a tecnologia XML para definir uma estrutura de
  49. 49. 49 troca de mensagens, e as conexões HTTP para tornar as informações disponíveis na Internet, independente de protocolos de nível mais baixo. O SOAP é um protocolo aberto, gerenciado pelo W3C (World Wide Web Consortium). Assim, a adoção do SOAP como tecnologia de base para a XML-DA, mantém a filosofia de abertura adotada pela OPC Foundation. A linguagem XML (abreviatura de Extensible Markup Language) utiliza uma estrutura de tags parecida com a HTML para definir estruturas hierárquicas de dados, objetos e atributos. Diferentemente da HTML, na XML, as tags podem ser livremente criadas pelo usuário, o que torna esta linguagem ideal para descrever estruturas de dados, num formato simples e de fácil entendimento. As conexões HTTP são um padrão utilizado já há bastante tempo na World Wide Web e permitem que sejam utilizados os serviços da XML-DA por qualquer computador que tenha acesso à Internet, inclusive através de firewalls. Com isso, a OPC-DA vem atender uma necessidade já pleiteada há algum tempo por muitos usuários, permitindo a monitoração de dados de uma planta externamente à empresa e até num contexto mundial. Outra vantagem é que este padrão de conexão, por ser praticamente universal, permite a utilização de clientes rodando em outros sistemas operacionais. Como a XML-DA está associada aos serviços da OPC-DA, é natural concluir que ela também é utilizada para acesso a dados em tempo real. Alguns exemplos de métodos (serviços) implementados pela XML-DA são descritos a seguir (IWANITZ, 200?): • GetStatus: para verificar a disponibilidade e estado do serviço; • Browse: para navegar no namespace do servidor; • Read/Write: Escrita/Leitura; • Subscribe: definir inscrição para recepção de dados do servidor; • SubscriptionPolledRefresh: polling iniciado pelo cliente para os dados já inscritos.
  50. 50. 50 3.2.3.2 OPC Compliance Test As especificações OPC são regras eficazes que garantem a interoperabilidade. Para assegurar que estas regras sejam seguidas, a OPC Foundation fornece ferramentas próprias de certificação e workshops de interoperabilidade. Estas ferramentas de certificação incluem um processo, completo e específico, para teste de conformidade com o padrão (OPC FOUNDATION, 2006a). A OPC Foundation também realiza workshops, onde os fornecedores podem verificar, por longos períodos, a interoperabilidade entre seus produtos e entre produtos de outros fornecedores. Este método disponibiliza um sólido processo para assegurar que as especificações OPC sejam soluções para interoperabilidade. O ponto essencial para interoperabilidade é a conformidade com as interfaces dos servidores. As aplicações clientes só podem verdadeiramente confiar na interoperabilidade entre fornecedores distintos se estes servidores implementam interfaces e métodos conforme as especificações. Este processo de verificação de compatibilidade pode ser realizado de várias formas. Porém, necessitam de extensiva intervenção humana. A OPC Foundation produz ferramentas para simplificar esta tarefa. Estas ferramentas de conformidade, as chamadas Compliance Test Tools, são um conjunto de testes definidos e reproduzíveis executado para assegurar a correta implementação das interfaces e métodos (OPC FOUNDATION, 2006a). Os membros da OPC Foundation utilizam as Compliance Test Tools para testar, depurar e certificar seus servidores. Estes testes são realizados, por duas vezes, em diversas condições e caso todos sejam aprovados, as informações são armazenados em uma base de dados criptografada. São gerados relatórios automaticamente, em seguida são enviados para a OPC Foundation para publicação, em seu site, na lista de todos os servidores certificados – Compliant Server (OPC FOUNDATION, 2006a). 3.2.3.3 OPC Complex Data A especificação OPC Complex Data, disponibilizada em dezembro de 2003, descreve uma nova forma de transmitir dados de um servidor OPC-DA para outro, tornando fácil para
  51. 51. 51 fornecedores, desenvolvedores, fabricantes de equipamentos e usuários finais conectarem dispositivos novos e inteligentes (ICONICS, 2004). A especificação atual do OPC-DA requer dados simples ou matrizes de dados simples. Assim, os servidores OPC-DA representam os dados como uma seqüência de bytes, atualmente não há como descrever a estrutura destes bytes. Os clientes não são capazes de interpretar os dados estruturados recebidos sem que o servidor forneça os itens de dados ou matrizes de dados simples. Complex Data são itens de dados de um servidor OPC-DA que têm uma estrutura definida. Esta especificação define uma forma para descrever estruturas de dados complexas contidas dentro do NameSpace de um servidor OPC-DA, fornecendo um mecanismo para representar estruturas complexas como itens simples de servidores OPC-DA (ICONICS, 2004). Os itens Complex Data podem incluir, por exemplo, itens estruturados e não estruturados, elementos e itens abstratos, strings, inteiros, seqüências dos bytes (BLOB’s) e dados XML. Cada item de dados é acompanhado de uma descrição do tipo de dado, que define a estrutura deste item, e um dicionário contendo todas as informações que o cliente OPC-DA necessita para entender o Complex Data recebido (ICONICS, 2004). 3.2.3.4 OPC Data Exchange (DX) A OPC Data Exchange (OPC-DX) permite troca horizontal de dados entre servidores, sem a necessidade de clientes no meio do caminho. Como uma extensão da OPC-DA, a OPC-DX utiliza e implementa (IWANITZ, 2002): • O conceito de conexão DX (DX Connection), para permitir a conexão e troca de dados entre os servidores; • O conceito de item de origem/destino (Source/Target Item), que consistem nos fontes/destino de dados de uma conexão; • O conceito de configuração DX (DX Configuration), que representa o conjunto de conexões disponíveis em um servidor;
  52. 52. 52 • Um cliente para permitir a definição, configuração, visualização e monitoração das conexões entre os servidores; • Funcionalidades de cliente e servidor OPC-DA, para permitir a visualização dos dados em tempo real entre os vários servidores (DA ou DX); • Um namespace similar ao da OPC-DA, acrescido de nós para representar as conexões, com atributos de configuração, status e itens de fonte/destino de dados. No que se refere à transferência de dados, a mesma pode ser feita de duas formas: • Utilizando a OPC-DA, ou seja, pelo mecanismo tradicional do DCOM, de criação de objetos e itens em um servidor OPC-DA, e comunicação por conexões de callback para resposta; • Utilizando a XML-DA, através dos mecanismos de comunicação definidos nesta última especificação (SOAP). 3.2.3.5 OPC Common Definitions and Interfaces Esta especificação compila definições, indicações e interfaces comuns a todas as outras especificações, de forma a criar um padrão mínimo para o desenvolvimento das mesmas, incluindo (IWANITZ, 2002): • A interface IOPCCommon, que gerencia a utilização de diferentes idiomas nas mensagens e mensagens de erro; • A interface IOPCShutDown (no lado do cliente), que possibilita a notificação (aos clientes) e o gerenciamento de shutdown do servidor; • Definições de instalação dos servidores e componentes, e descrição de seus identificadores (CLSID, CATIDs etc) e configurações no registro do sistema operacional (registry);
  53. 53. 53 • O OPCServerBrowser, que fornece uma interface para informar aos clientes OPC a existência de servidores OPC em computadores remotos. Esta interface deve ser obrigatoriamente disponibilizada pelo servidor OPC; • Os arquivos proxy/stub, para serialização/desserialização; • O Automation Wrapper; • A definição de interfaces obrigatórias e opcionais. 3.2.3.6 OPC Security Esta especificação está focada na identificação do cliente, que troca credenciais confiáveis, sendo utilizadas pelo servidor OPC para autorização de acesso. Entender esta especificação é útil para analisar, inicialmente, o modelo de referência da segurança (OPC FOUNDATION, 2000). A Especificação OPC Security diz respeito ao método de implementação de recursos de segurança. Sua principal desvantagem é uma possível ocorrência de problemas de interoperabilidade caso utilize-se uma forma não especificada (IWANITZ, 2002). Compatível com o modelo de segurança do Windows NT, o OPC Security permite vários níveis de segurança para manter compatibilidade com o conjunto de aplicações OPC e disponibilizar capacidade de segurança maximizada (IWANITZ, 2002). Um servidor OPC pode implementar um dos seguintes níveis de segurança (OPC FOUNDATION, 2000): • Disable Security: Nenhum item de segurança é reforçado, todos os servidores OPC possuem permissões de acesso, todos os clientes possuem as mesmas permissões acesso. O servidor OPC não controla o acesso de objetos de segurança individualmente para cada desenvolvedor; • DCOM Security: Somente a segurança do NT DCOM é reforçada, permissões de início e acesso são limitados a clientes selecionados, assim como as permissões de
  54. 54. 54 acesso para ligações do cliente. Entretanto, o servidor OPC não controla o acesso de qualquer objeto de segurança de fornecedores específicos. Este é o nível padrão de segurança do DCOM; • OPC Security: O Servidor OPC serve como um monitor de referência para o controle de acesso para objetos de segurança de fornecedores específicos que são disponibilizados pelo servidor OPC. Um servidor OPC pode implementar o OPC Security de forma complementar ao DCOM Security ou implementá-lo sozinho. Os Servidores OPC que disponibilizam o OPC Security devem implementar ao menos uma das interfaces IOPCSecurityNT e IOPCSecurityPrivate. Estas interfaces permitem aos clientes OPC determinarem se o OPC Security está implementado no servidor OPC em questão e quais tipos de certificados de acesso são suportados com segurança (OPC FOUNDATION, 2000). 3.2.3.7 OPC Batch A especificação OPC-Batch é uma extensão do modelo da OPC-DA para o caso de processamento em batelada (batch processing). Segundo (IWANITZ, 2002), uma batelada (ou batch) consiste em diferentes procedimentos que descrevem a manufatura de um determinado produto. Na execução de uma batelada, uma troca de dados é realizada com os dispositivos envolvidos no processo. Os dados dos procedimentos são enviados e dados de relatório são recebidos em resposta. Todos os mecanismos do processamento em batelada são padronizados pela norma IEC 61512, e os produtos de mercado que fornecem esta solução seguem a mesma. Desta forma, a OPC-Batch não descreve a solução para os problemas de controle da batelada, mas a possibilidade de operar simultaneamente as soluções dos diferentes fabricantes, trazendo a interoperabilidade para este meio. Para possibilitar o atendimento à norma IEC 61512, a OPC-Batch utiliza as interfaces obrigatórias definidas na OPC-DA (incluindo a interface de navegação), acrescidas basicamente de (IWANITZ, 2002): • Suporte a interfaces OPC adicionais (IOPCBatchServer), para implementar algumas funcionalidades necessárias;
  55. 55. 55 • Um namespace bem definido, seguindo a hierarquia e conceitos previstos na norma IEC 61512. Vale ressaltar que este namespace pode ser bastante grande, dada a natureza das informações criadas e trocadas no processamento em batelada. A norma IEC 61512 define quatro tipos de informação de batelada: características de equipamento (que descrevem os dispositivos que executam a batelada), condições de operação atuais, conteúdo histórico e conteúdo dos procedimentos. No caso da OPC-Batch, estão definidos objetos e interfaces para permitir a troca de informações dos dois primeiros tipos de informação de batelada citados anteriormente. Para descrever o primeiro, utiliza-se o modelo físico (physical model) definido na norma, e, para o segundo tipo, são utilizados a lista de batelada (batch list) e o modelo de batelada (batch model), também definidos na norma IEC 61512. O modelo físico representa a subdivisão de uma determinada planta em diferentes níveis, incluindo áreas, células, unidades, módulos de dispositivo e módulos de controle procedural (procedural control modules). Este último descreve o módulo que realiza um determinado procedimento automatizado, incluindo: informações de procedimento, procedimento da unidade, operação e fase. O modelo de batelada segue uma hierarquia similar aos módulos de controle procedural, e descreve as informações das ações que compõem a batelada, incluindo: unidade, procedimentos, operações e fases. As listas de batelada (batch lists) permitem saber informações sobre quais processos estão sendo executados, quais estão em espera e quais estão terminados. Todos estes modelos são mapeados no namespace do servidor OPC-Batch, através dos nós, ramos e suas propriedades.

×