Após a criação da OPC Foundation a organização trabalhou no sentido de definir interfaces de software para padronizar o fluxo de informações no nível de campo até o nível de gerenciamento. Com isso, três importantes especificações OPC foram inicialmente desenvolvidas, baseado nas diferentes necessidades dentro das aplicações industrais: Data Access (DA), Alarm & Events (AE) e Historical Data Access (HDA). O OPC usa uma arquitetura cliente-servidor para a troca de informações. Um Servidor OPC encapsula as informações de processo e disponibiliza na sua interface. Um Cliente OPC conecta-se ao Servidor OPC e pode acessar e consumir os dados oferecidos. As aplicações consomem e fornecem dados que podem ser tanto do cliente quanto do servidor (GONÇALVES, 2012) (Figura 3.9).
O protocolo OPC clássico é baseado na tecnologia COM (Component Object Model) e DCOM (Distri- buted Component Object Model) da Microsoft. Esses modelos fornecem um mecanismo transparente para
Figura 3.8: Soluções proprietárias, adaptado de (KONDOR, 2008)
um cliente chamar métodos sobre um objeto COM, em um servidor rodando em um mesmo processo, em outro processo, ou em outro nó na rede (MAHNKE; LEITNER; DAMM, 2009). Essa tecnologia está dis- ponível nos computadores executando sistema operacional Windows, fato que fez reduzir o esforço inicial da especificação do padrão, do tempo de desenvolvimento das especificações e produtos, além de reduzir o tempo de chegada do OPC ao mercado. Essa característica inicial foi fundamental para o sucesso do OPC. Segundo Burke et al. (BURKE; IWANITZ; LANGE, 2010), as duas principais desvantagens do OPC clássico são a dependência da plataforma Windows e os problemas da tecnologia DCOM na utilização de comunicação remota com o OPC. A tecnologia DCOM é de difícil configuração, tem períodos longos e não configuráveis de timeout, e não podem ser usados para comunicação através da Internet.
Algumas das últimas especificações OPC clássico publicadas são apresentadas na lista abaixo:
• OPC Overview (v1.00.1.00) - Descrição geral das finalidades de cada especificação OPC;
• OPC Common Definitions and Interfaces (v1.10) - Definição das funcionalidades básicas para as demais especificações.
• OPC Data Access Specification (v3.00.1.00) - Definição da interface para leitura e escrita de dados em tempo real.
• OPC Historical Data Access Specification (v1.20.1.00) - Definição da interface para acesso a dados históricos.
• OPC Alarms and Events Specification (v1.10.1.00) - Descreve a interface para o monitorar áreas e notificar os clientes sobre as condições de alarme.
• OPC XML-DA Specification (v1.01.1.00) - Integração entre OPC e XML para aplicações via Internet (Web).
• OPC Data eXchange Specification (v1.00.1.00) - Descreve o comportamento do das comunicações Servidor/Servidor ou as comunicações Dispositivo/Dispositivo.
• OPC Complex Data Specification (v1.00.1.00) - É uma extensão das especificações existentes do OPC DA, adicionando uma camada de dados complexos/estruturados, como XML, etc.
• OPC Security Specification (v1.00.1.00) - É uma extensão das especificações OPC existentes adici- onando uma camada pra controle de acesso seguro a aplicações e dados.
• OPC Batch Specification (v2.00.1.00) - Esta especificação é uma extensão da OPC Data Access Specification, e define a interface de acesso aos dados de processos por batelada (batch).
• OPC Commands (v1.00.0.29) - Define os meios para descobrir, entender e controlar os comandos (métodos) que um servidor fornece.
A Figura 3.10 mostra o conjunto da família de especificações OPC e o relacionamento entre elas. São interfaces que atendem a diferentes finalidades nas aplicações de campo. Elas podem ser utilizadas de forma independente uma das outras ou combinadas.
Figura 3.10: Visão geral das especificações OPC e seus relacionamentos (HONG; JIANHUA, 2006)
As aplicações que utilizam o protocolo OPC são classificadas de acordo com sua funcionalidade: Cli- ente OPC ou Servidor OPC. O servidor OPC Data Access compreende objetos e interfaces de servidor, uma área de armazenamento de dados, uma interface gráfica de usuário (GUI) e um driver de hardware (LING; CHEN; YU, 2004) (Fig. 3.11).
Figura 3.11: Arquitetura geral de um servidor OPC (LING; CHEN; YU, 2004)
Os dados extraídos do dispositivo são usados por aplicações de software especiais (por exemplo, SCADA, DCS e ERP) e software de terceiros (por exemplo, Delphi e Visual Basic) com os servidores OPC. Objetos OLE ou componentes OPC tem que usar funções OPC padrão ao implementar procedimen- tos de comunicação. Essas funções OPC diferem para cada dispositivo, mas eles empregam os mesmos padrões. Independentemente do servidor OPC em que essas funções são implementadas e os dados são solicitados, a resposta deve ser a mesma.
Os clientes OPC normalmente são produtos para controle e monitoramento de dados. Aplicações cliente OPC podem ser desenvolvidas em diversas linguagens de programação, como Java, C++, .NET framework, linguagem script, etc. A aplicação cliente pode acessar o servidor OPC através de duas in- terfaces: OPC Custom Interface e OPC Automation Interface. Aplicações desenvolvidas em linguagens de programação que suportam chamadas de funções por ponteiro (C,C++, Delphi, etc.) podem acessar o servidor através de interface Custom. Os casos em que as aplicações são programadas em linguagens que não suportam ponteiros (Visual Basic, .Net, etc.), o acesso ao servidor é feito por interface OPC Automa- tion, que atuam como um proxy entre as aplicações clientes e a interface Custom (Figura 3.12) (IWANITS; LANGE, 2002).
Figura 3.12: Acesso ao servidor OPC através de interfaces Custom e Automation, adaptado de (IWANITS; LANGE, 2002)
Um Cliente OPC pode se conectar a Servidores OPC produzidos por um ou mais fornecedores. O có- digo fornecido pelo fornecedor determina os dispositivos e dados aos quais cada servidor tem acesso, os no- mes dos dados e os detalhes sobre como o servidor acessa fisicamente esses dados (OPC-FOUNDATION, 2003).
Em alto nível de software, um servidor OPC é composto de vários objetos: servidor, grupo e os itens. O objeto Servidor OPC mantém informações sobre o servidor e serve como um recipiente para objetos de Grupo OPC (OPC Group). O objeto de OPC Group mantém informações sobre si próprio e fornece o mecanismo para conter e organizar logicamente Itens OPC (OPC Item).
Os Grupos OPC proporcionam aos clientes uma maneira de organizar os dados. Por exemplo, o grupo pode representar itens em uma amostra ou relatório de um operador específico. Os dados podem ser lidos e escritos. Conexões com exceção também podem ser criadas entre o cliente e os itens do grupo e podem ser habilitadas e desabilitadas quando necessário. Um cliente OPC pode configurar a frequência que um servidor OPC deve fornecer as atualizações de dados para o cliente OPC (OPC-FOUNDATION, 2003).
Dentro de cada Grupo o cliente pode definir um ou mais itens OPC (Figura 3.13).
Os itens OPC representam conexões com fontes de dados dentro do servidor. Um item OPC, a partir da perspectiva da interface personalizada, não está acessível como um objecto por um cliente OPC. Portanto, não há nenhuma interface externa definida para um item OPC. Todo acesso a itens OPC é feito através de um objeto de grupo OPC que "contém"o item OPC ou simplesmente onde o item OPC é definido. Associado a cada item há um Valor (Value), Qualidade do sinal (Quality) e Tempo de captura do dado (Time Stamp) (OPC-FOUNDATION, 2003).
Figura 3.13: Relacionamento Grupo/Item (OPC-FOUNDATION, 2003)
Os itens não são as fontes de dados - eles são apenas conexões com eles. Por exemplo, as tags em um sistema DCS existem, independentemente de um cliente OPC estar acessando elas ou não. O Item OPC representa o endereço dos dados, e não a fonte física real dos dados que o endereço faz referência.