Escolar Documentos
Profissional Documentos
Cultura Documentos
UNIVERSIDADE PETROBRAS
CURSO 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)
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.
Í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
Lista de Abreviaturas
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
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
1 Introduçã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):
Por conta do modelo de extensões, o OPC é hoje entendido não como uma especificação, mas
sim como um conjunto delas.
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 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 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
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
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.
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
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.
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.
2.4.2 Barramento
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
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:
• 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
• 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;
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
• Conexão Host-Terminal;
• Comunicação peer-to-peer;
• Chamada de Programa;
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
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):
• 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.
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
Error!
Início
Projeto Básico
Projeto de Detalhamento
Teste de Integração
Não Reparametrização/
Passou
Modificação do Sistema
Sim
Não
Passou
Sim
Instalação na planta do cliente
Pré-testes
Não
Passou Re-trabalho
Sim
Fim
3 Fundamentos do 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.
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
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).
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
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).
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
Como um modelo orientado a objetos, que também herda funcionalidades do RPC, o DCOM
se constitui basicamente de (IWANITZ,2002):
3.2 O OPC
2
É o CATID que identifica unicamente as diferentes especificações e versões das mesmas no OPC
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.
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).
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.
• 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 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
• 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).
• 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.
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.
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.
• 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
• 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;
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).
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).
• Eventos Simples: São eventos mais básicos, que não exigem ações de reconhecimento
pelo operador (ex: “bomba ligada”);
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.
A Figura 3.5 mostra o exemplo de um servidor com seus objetos associados a uma área de
eventos.
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
tendência), sendo registrada sua variação numa determinada faixa de tempo, e permitindo seu
acesso posterior pelos usuários.
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.
• 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;
• 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;
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.
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).
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).
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
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).
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.
Figura 3.9 Servidores OPC-UA entre Níveis Hierárquicos (OPC FOUNDATION, 2006b)
• 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;
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
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?):
• Read/Write: Escrita/Leitura;
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.
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).
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).
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):
No que se refere à transferência de dados, a mesma pode ser feita de duas formas:
• 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;
• O Automation Wrapper;
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).
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).
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).
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.
56
Grande parte da literatura sobre OPC trata-o como uma solução para se obter dados de redes
heterogêneas de modo uniforme, ou seja, como um protocolo desenvolvido num contexto
onde os processos são controlados individualmente por sistemas especializados e baseados em
comunicação digital. No entanto, sua aplicação tem se mostrado mais ampla, como
demonstram os estudos de casos apresentados neste capítulo.
A concentração de dados de um sistema no seu nível de controle mais elevado tem sido
bastante desejada. A forma mais simples de se obter tal concentração é alocar em uma mesma
sala de controle as estações de trabalho relativas aos subsistemas, permitindo aos operadores
uma visão geral do processo. Quando tal solução não é viável, sistemas auxiliares de
comunicação (telefones, rádio, intranet ou internet) são usados.
O OPC tem se mostrado desde o início uma solução para esse problema, disponibilizando
dados para camadas mais elevadas de aplicação de forma integrada, permitindo assim um
maior aproveitamento das informações na forma de relatórios de produção, estatísticas de
falhas etc.
Para um sistema de controle industrial, uma rede veloz é aquela na qual o tempo gasto para as
informações transitarem entre suas diversas partes é suficientemente menor que as constantes
de tempo envolvidas no processo (KEW, 2001). Em sistemas de controle em tempo real, a
presença de um atraso significativo entre quaisquer dos elementos de uma malha pode
inviabilizar sua sintonia. Nesses casos o desempenho da comunicação em termos de tempo de
atraso é um item fundamental a ser avaliado. Além disso, a rede também deve ser capaz de
suportar todo o fluxo de dados sem que nenhum dos seus elementos seja sobrecarregado,
impedindo a comunicação efetiva.
• Tempos variáveis pela característica estatística das redes ethernet (SONG et al, 2002).
• Latência ou tempo de atraso – tempo que uma informação solicitada ou enviada por
um dispositivo leva para ficar completamente disponível para uso;
• Fluxo de dados – quantidade de dados que pode ser transmitida por segundo entre os
servidores e clientes. A unidade utilizada é itens/s por representar melhor os diversos
tipos de dados geralmente disponíveis nos sistemas.
A utilização do OPC para esse propósito parece ser extremamente viável. Seu propósito é
permitir que, através de um sistema cliente-servidor, todos os equipamentos distintos possam
se comunicar utilizando uma mesma interface. É como se o OPC criasse uma linguagem
universal, permitindo que os equipamentos troquem informações de maneira simples, barata e
eficiente.
Um ponto fraco apontado no OPC é a sua dependência do Windows e do DCOM. Nas suas
primeiras versões, o protocolo está intimamente associado ao sistema operacional da
Microsoft, sistema que historicamente tem características de confiabilidade e disponibilidade
discutíveis.
Nos casos estudados adiante são apresentadas soluções que contornam algumas dessas
limitações, como a redundância de servidores (BARILLÈRE et al, 1999; FONSECA, 2002) e
59
4.2.1.1 Objetivo
Discutir a viabilidade de se utilizar o OPC em sistemas de controle em tempo real como parte
da malha de controle, fazendo o papel das redes do nível de campo. Neste caso, o protocolo
provê a comunicação direta entre sensores, controladores e atuadores.
4.2.1.2 Metodologia
Revisão bibliográfica. Esta seção está fortemente norteada por (KEW, 2001). Nele discutem-
se qualitativamente os sistemas de controle em tempo real e como os atrasos impostos pelas
redes podem influenciar no seu desempenho. Analisando as características do OPC-DA, é
possível estabelecer alguns limites para sua aplicação em sistemas de controle em tempo real.
O problema
Em (KEW, 2001) tem-se uma boa descrição de como seria um sistema de controle em tempo
real. Nele é discutida a viabilidade do OPC em sistemas de controle distribuído tomando
como base um sistema simples com realimentação. Trata-se de um modelo de controle
realimentado típico, onde um set-point é comparado com o valor medido pela variável e essa
diferença alimenta o controlador, que envia o sinal de controle para o dispositivo de atuação.
O sistema é representado pela Figura 4.1.
Por outro lado, na Figura 4.2, têm-se um diagrama que ilustra o modo como seria o fluxo das
informações num sistema de controle por computador. De acordo com a figura, pode-se
definir o tempo de loop como o tempo necessário para que a informação seja gerada pelo
60
Figura 4.2 Tempo de loop num sistema com realimentação (KEW, 2001)
Utilizando o OPC como via de informação, tem-se uma situação um pouco mais complexa
(Figura 4.3). Nesse caso, o tempo de loop é incrementado de todo o tempo necessário para o
estabelecimento da comunicação entre o servidor OPC e o cliente.
Figura 4.3 Tempo de loop de um sistema de realimentação utilizando o OPC (KEW, 2001)
61
Como conseqüência dessa estrutura, o OPC passa a ser uma importante fonte de atraso de
informação entre sensor, controlador e atuador. Dependendo da dinâmica do sistema a ser
controlado, esse tempo de atraso pode ser significativo ou não.
Dois fatores influenciam diretamente nos tempos de comunicação quando utiliza-se o OPC
(KEW, 2001):
De acordo com (KEW, 2001), um tempo típico de acesso entre um servidor OPC e um
dispositivo de campo gira em torno de 15,6ms. Portanto, o tempo mínimo de um sistema de
controle com um servidor OPC seria de duas vezes esse valor, ou seja, 31,2ms.
No entanto, dependendo de como são agrupados os dados no servidor OPC, uma requisição
pode transferir um lote de valores de uma única vez, o que geralmente é feito por representar
uma estratégia de otimização da utilização do servidor.
Sistemas de controle da indústria química são bastante lentos. Trocadores de calor, caldeiras e
reatores nucleares tipicamente têm constantes de tempo maiores que 10s (POLONYI, 2006).
Tomando-se por base a indústria de petróleo, por exemplo, salvo alguns equipamentos
especiais, as constantes de tempo dos processos não são muito menores que isso.
62
Outro ponto importante a favor do OPC diz respeito aos avanços nos programas associados ao
mesmo. Como o avanço do sistema operacional espera-se melhor desempenho por parte dos
servidores e clientes. Em alguns testes o Windows 2000 mostrou ser capaz de rodar
aplicações 16% a 122% mais rápido que o seu antecessor NT (POLONYI, 2006). O COM+
também tem sofrido importantes modificações em seus recursos, o que promete melhorar
bastante seu desempenho frente ao seu antecessor. No entanto, na prática, os testes com as
novas tecnologias são poucos e ainda não muito conclusivos.
4.2.1.6 Conclusões
A conclusão é parcial, visto que em (KEW, 2001) não se discute com profundidade alguns
itens bastante relevantes em plantas industriais, como disponibilidade e segurança.
Em relação ao desempenho chega-se à conclusão que para a maioria das aplicações industriais
o protocolo é uma solução bastante viável. As conclusões em (KEW, 2001) são de que o OPC
ainda é bastante lento, com tempos de conexão e transmissão de dados bastante limitados.
Porém, como os tempos envolvidos nas plantas industriais são longos, o OPC seria uma opção
viável para controle em tempo real. Especificamente na indústria de petróleo, a maior parte
dos equipamentos enquadra-se no exemplo. A exceção fica por conta de alguns sistemas
específicos como turbinas, compressores e reatores de unidades de FCC (Fluid Catalytic
Cracking), cujos tempos de resposta podem ser da ordem de décimos de segundos.
4.2.2.1 Objetivo
4.2.2.2 Metodologia
4.2.2.3 Discussão
Uma aplicação bastante viável para o OPC parece ser na área de otimização ou controle
avançado. Em geral, esses sistemas possuem duas camadas de controle:
A Figura 4.4 ilustra o funcionamento de um sistema desse tipo, mostrando o fluxo de dados e
a função do OPC como elemento mediador de informações.
O principal argumento em favor do OPC está no fato da primeira camada ser composta por
malhas independentes entre si. Em casos práticos essas malhas de controle podem utilizar
tecnologias completamente distintas, de fabricantes diferentes e empregando modelos de rede
específicos. O OPC se enquadra muito bem nesse propósito.
64
Outro ponto é a velocidade na qual acontece esse tipo de intervenção. Como citado
anteriormente, o principal argumento contra o OPC está na sua velocidade de transmissão de
dados. Neste tipo de aplicação essa restrição não é tão relevante, visto que as mudanças são
bastante lentas, da ordem de minutos. Essa característica deve-se aos seguintes fatores:
• É regra comum nos sistemas de otimização evitar mudanças bruscas nos set-points.
Parte-se sempre do pressuposto que a planta está em operação, com supervisão dos
operadores e, portanto, toda mudança no ponto de operação da planta deve ser feita
muito lentamente. O tempo entre duas atuações é da ordem de dezenas de minutos.
4.2.2.4 Conclusões
Pode-se concluir que para sistemas de otimização o OPC é de grande utilidade. O protocolo
não só oferece funcionalidade e desempenho suficientes para aplicações desse tipo como
também já está bastante difundido entre os fabricantes de diversos equipamentos.
Os problemas de atraso não são relevantes nesses casos, pois as mudanças provocadas nos
set-points da planta são feita de forma muito lenta.
Por se tratar de aplicações de nível mais alto, os requisitos de confiabilidade são muito menos
severos. Em geral, se a aplicação de controle de alto nível perder sua comunicação com os
controladores é perfeitamente possível manter a planta operando normalmente.
Espera-se que muitas das aplicações futuras de otimização e controle avançado tenham como
tecnologia de comunicação entre redes o protocolo OPC.
65
4.2.2.5 Observações
O termo "controle avançado" pode induzir a idéia de sistemas de controle muito rápidos ou
muito específicos. Nesse estudo considera-se como controle avançado3 os sistemas que fazem
o controle da planta (toda ou em parte) utilizando modelos dos processos em controle, os
quais são, em geral, sistemas bastante lentos.
4.2.3.1 Objetivo
4.2.3.2 Metodologia
Revisão bibliográfica. Com base nos conceitos de redes industriais discutidos no Capítulo 2,
das características do OPC e de outros trabalhos (SANTOS et al, 2005; BARILLÈRE et al,
1999; FONSECA, 2002; KEW, 2001) foi possível chegar a uma conclusão sobre a viabilidade
do OPC neste tipo de aplicação.
4.2.3.3 Discussão
No exemplo da Seção 4.2.2 (OPC em controle avançado e otimização), temos uma abordagem
oposta. O OPC não suporta a carga de responsabilidade da transmissão de dados das malhas
3
Controle Avançado: controle multivariável baseado em modelo dos processos em controle (MPC).
Apresenta dinâmica da ordem de dezenas de segundos a alguns minutos.
66
de controle. Sua função é fornecer subsídios para uma aplicação de controle de nível mais
alto.
Em (BARILLÈRE, 1999) é apresentado um exemplo que seria um misto dos dois anteriores.
Apesar de bastante resumido, este trabalho avalia sob vários ângulos a aplicação do protocolo
num sistema completo de controle formado por diversos subsistemas, incluindo: instrumentos
de campo, controladores, redes fieldbus e sensores diversos, bem como várias aplicações de
um mesmo laboratório.
Recursos
Um fator apontado como negativo é o fato do DCOM não prever em sua especificação
original um mecanismo de localização dos servidores dispostos na rede. O autor cita a
necessidade de manter, nos clientes, a configuração com o mapeamento dos servidores.
Em (OPC FOUNDATION, 1998) temos uma descrição de uma aplicação denominada “OPC
Server Browser”, fornecida como parte das especificações do protocolo. Esta aplicação
permite a visualização dos servidores instalados em máquinas remotas, porém ainda é
necessário o conhecimento prévio do nó de rede que contém os servidores.
Mercado
A disponibilidade no mercado parece ser um grande avanço do OPC. Uma grande quantidade
de servidores já está disponível para diversos equipamentos fieldbus e PLCs. A maioria dos
sistemas SCADA disponibiliza drivers para operar como clientes, assim como muitos deles já
possuem também servidores OPC. Quando o servidor não está disponível para um dispositivo
67
Compatibilidade
Abertura e flexibilidade
Abertura e flexibilidade são características fundamentais no OPC. Neste item são descritos
alguns detalhes observados no desenvolvimento das aplicações em (BARILLÈRE, 1999).
O primeiro ponto importante é que para integrar dispositivos muito específicos controlados
por plataformas não-Windows (ex.: VME ou PC com Linux), foi necessário desenvolver
servidores OPC próprios. Como conseqüência da ligação entre OPC e DCOM, foi preciso o
Windows NT para executar os componentes necessários ao desenvolvimento dos servidores.
Disponibilidade
Ainda segundo (FONSECA, 2002), poucos produtos do mercado dispõem desse tipo de
funcionalidade, citando o ORB (OPC Redundancy Broker) da Matrikon, que permite que
clientes comuns possam fazer chaveamento entre servidores redundantes. A dificuldade
encontrada por (BARILLÈRE, 1999) em relação aos altos tempos de timeout não foram
mencionadas por (FONSECA, 2002).
Outro problema secundário estaria associado ao modo como é feito o acesso ao espaço de
memória nos servidores, na versão do OPC/DCOM estudada (2.0, outubro de 1998). Nesta
versão espaços de memória são criados e liberados pelos clientes, podendo gerar lacunas nos
servidores em eventuais falhas nos clientes.
Uma conclusão que pode-se tirar desses exemplos é que o item confiabilidade não está num
bom estado de desenvolvimento no OPC pelos seguintes fatos: a) falta de referência nas
especificações da própria OPC Foundation; b) pouca quantidade de trabalhos publicados
tratando desse item; c) soluções adotadas dependem fortemente do desenvolvimento dos
usuários.
4
Watchdog: mecanismo responsável pelo monitoramento do canal de comunicação, verificando falhas e queda
da qualidade, informando-as ao cliente.
69
Desempenho
Para o estudo de viabilidade proposto por (BARILLÈRE, 1999) também foram executados
alguns testes de desempenho. Para execução dos mesmos foram desenvolvidos servidores que
geravam valores e clientes que criavam a demanda de comunicação. Basicamente, foram
testadas a escrita e leitura síncrona de grupos de valores nos servidores OPC. Os resultados
obtidos ficaram muito próximos de outros publicados na Internet. Os valores encontrados
foram:
4.2.3.4 Conclusões
4.3.1.1 Objetivo
Mostrar que o desempenho do OPC é compatível com a maioria das aplicações, dedicadas ou
distribuídas (CHISHOLM, 1998).
70
4.3.1.2 Metodologia
• Experimentação prática;
4.3.1.3 Conclusões
• No caso mais complexo, um servidor (P233) é capaz de prover dados para 4 clientes
(P233, P266, P120 e P120). A marca alcançada foi de 18.775 Itens/s;
• Não foi possível concluir nada sobre os tempos de atraso, pois a avaliação apresenta
valores médios, em janelas de tempo mínimas de 9 segundos.
4.3.1.4 Observações
4.3.2.1 Objetivo
Gerar valores concretos de desempenho para o OPC-DA utilizando servidores e clientes OPC
desenvolvidos pela Rockwell, de forma a demonstrar que o desempenho dos seus produtos
excede as necessidades dos seus usuários (BURKE, 1998).
71
4.3.2.2 Metodologia
• Experimentação prática;
• O tipo de transmissão escolhida para o teste foi síncrona por representar o pior caso.
4.3.2.3 Conclusões
• Como exemplo, pode ser citado o teste em que um servidor foi capaz de prover
200.000 itens/s a cinco clientes em máquinas distintas, continuamente e sem
apresentar problemas. Os itens foram agrupados em grupos de 10.000 itens, com 4
mudanças/s;
• Em outro exemplo, com grupos menores (100 itens) e taxa de mudança maior (14
mudanças/s), foi alcançada a marca de 1.400.000 itens/s.
4.3.2.4 Observações
A latência da comunicação foi discutida no trabalho, porém, na forma como os números estão
apresentados, os valores de tempo de atraso não ficam claros.
72
4.3.3.1 Objetivo
4.3.3.2 Metodologia.
• Desgaseificação a vácuo;
• Convertedores (1 e 2);
• Adição de Fundentes;
• Adição de Ferro-Ligas;
• Ventilação secundária;
• Pesagem de Gusa;
• Pesagem de Sucata;
73
• Sistemas auxiliares;
O sistema está ilustrado na Figura 4.5 e foi desenvolvido utilizando os seguintes produtos e
tecnologias:
• Muitas funcionalidades do padrão OPC não estavam disponíveis nas primeiras versões
dos produtos;
• Os clientes OPC não permitiam que fossem configurados os itens OPC de forma a
otimizar a configuração, tais como agrupamento de itens, leitura em blocos etc;
4.3.3.5 Desempenho
4.3.3.6 Redundância
Como discutido em seções anteriores, especificações do padrão OPC não fazem menção à
utilização de servidores redundantes. Entretanto, o autor (FONSECA, 2002) cita o uso de
conexão simultânea a mais de um servidor, a verificação do estado do servidor e
ativação/desativação dos grupos para o servidor que estiver funcionando. Ainda segundo o
autor, essa solução seria encontrada apenas em alguns produtos disponíveis no mercado. O
ORB da Matrikon, por exemplo, permite que clientes comuns façam o chaveamento para
servidores redundantes.
4.3.3.7 Conclusões
• O autor conclui que o OPC é uma ferramenta bastante poderosa e tende a alcançar
maturidade suficiente para se tornar um padrão de fato na indústria;
• Indica uma tendência dos servidores OPC serem implementados diretamente nos
dispositivos de campo. Pode-se notar na Figura 4.5 que foram utilizados computadores
individuais para tal função, o que não seria necessário se os dispositivos já possuíssem
servidores OPC embutidos;
76
Nessa parte do trabalho é feita uma descrição mais detalhadas de um dos casos anteriores,
reforçando os argumentos que levaram às conclusões apresentadas. Nos casos de testes de
desempenho, são mostrados os números completos apresentados no trabalho.
O objetivo deste teste é prover uma base para avaliação do desempenho entre clientes e
servidores OPC. A Rockwell, como desenvolvedora de produtos, pretende mostrar que os
valores típicos de comunicação entre seus produtos, utilizando o protocolo, ultrapassam as
necessidades e expectativas de seus usuários (BURKE, 1998).
O foco deste teste está na funcionalidade da comunicação entre clientes e servidores OPC
desenvolvidos pela Rockwell. Foram executados testes com clientes simples e múltiplos,
comunicando-se com servidores locais e remotos.
O teste parte do princípio que pode existir uma latência entre a comunicação dos servidores
OPC e os dispositivos de campo e procura gerar mais valores do que um equipamento típico
de campo para contornar o problema. O autor destaca ainda que não foram utilizados recursos
extras além dos previstos nas especificações do protocolo.
No seu uso típico, um servidor OPC atualiza múltiplos itens simultaneamente para múltiplos
clientes. O autor assume que numa aplicação real da tecnologia, o servidor raramente
mandaria um único item para a aplicação cliente. De forma mais apropriada, um grupo de
valores são enviados de uma única vez através de um OPCGroup. O teste visa descobrir a
77
quantidade de dados que pode ser enviada por segundo, assim como quanto tempo este dado
demora até estar disponível no cliente.
Alguns testes foram feitos de forma local, com ambos os servidores e clientes rodando na
mesma máquina, enquanto outros foram executados em um ambiente distribuído, com
servidores e clientes rodando em máquinas distintas. Para os testes em ambiente distribuídos
foram utilizados seis computadores Pentium 266, cinco deles rodando aplicações clientes
enquanto o sexto rodava a aplicação de servidor.
4.4.1.1 Números
• Teste 1 - Seis computadores Pentium 266, cinco deles rodando a aplicação cliente e o
sexto rodando a aplicação de servidor. Cada cliente definiu e adicionou 10.000 Itens
com 4 bytes de tamanho (tags) ao servidor e solicitou atualização dos dados numa taxa
de 250ms por item. Os resultados podem ser visto na Tabela 4.2.
• Teste 2 - Seis computadores Pentium 266, cinco deles rodando a aplicação cliente e o
sexto rodando a aplicação de servidor. Cada cliente definiu e adicionou 100 Itens com
200 words de tamanho ao servidor e solicitou atualização dos dados numa taxa de
70ms por item. Os resultados podem ser visto na Tabela 4.3.
Os resultados permitem concluir que a totalidade de dados que um servidor OPC pode
disponibilizar para um cliente, excede a totalidade de dados que uma aplicação real típica
pode processar. O teste conclui ainda que em casos reais, usando notificações de exceção, a
quantidade de dados é tipicamente uma pequena porcentagem da massa de dados
monitorados. Ainda de acordo com o autor, os testes foram feitos para garantir que esse
79
desempenho possa ser considerado determinístico, ou seja, os servidores possam operar com
esse tipo de tráfego por longos períodos de tempo sem que haja variações significativas dos
resultados.
80
5 Considerações Finais
No texto foi apresentada uma introdução ao protocolo OPC no ambiente industrial iniciando-
se pela sua motivação e conseqüente surgimento. Na seqüência foram tratados alguns
aspectos das redes de comunicação, com foco naqueles mais relevantes dentro de sistemas de
automação.
Podemos observar também que no mercado, grande parte dos servidores OPC disponíveis
seguem a especificação OPC-DA. Baseados nela, alguns fornecedores desenvolveram
soluções próprias para implementar conceitos como redundância de servidores ou para tornar
seu servidor portável para plataformas não-Windows, características previstas apenas na
especificação OPC-UA.
Nos estudos de casos analisados percebeu-se que, apesar de quase sempre ressaltar-se que o
protocolo em termos absolutos é lento, os tempos longos envolvidos nos processos industriais
torna o OPC uma alternativa viável para controle em tempo real. Quanto ao emprego em
sistemas de controle avançado, destaca-se que o protocolo oferece funcionalidade e
desempenho suficientes, pois o tipo de mudança provocada na planta nesse caso (ajuste de
set-points) é feita de forma muito lenta. Outro ponto destacado nos trabalhos é que muitas das
limitações associadas ao OPC são heranças da sua dependência da tecnologia DCOM, que se
espera ser bastante reduzida a partir do lançamento da especificação OPC-UA.
6 Referências Bibliográficas
BARILLÈRE R. et al. Results of the OPC evaluation done within JCOP for the control of
the LHC experiments. In: International Conference on Accelerator and Large Experimental
Physics Control Systems, Trieste, Italy, 1999.
CHEN, D.; MOK, A. K. Developing New Generation of Process Control Systems. In:
IEEE Real-Time Embedded System Workshop, 2001, San Diego, USA.
CHISHOLM, AL. DCOM, OPC and Performance Issues, Intellution Inc., 1998.
DJIEV, S. N. Industrial Networks for Communication and Control, Reading for Elements
for Industrial Automation, Technical University, Sofia, Bulgaria, 2003.
IWANITZ, F. XML-DA Opens Windows Beyond the Firewall, [200?]. The Industrial
Ethernet Book. Disponível em <http://ethernet.industrial-networking.com/articles/article
display.asp?id=21>. Acesso em 12 de dezembro de 2006.
OPC FOUNDATION. OPC Alarms and Events Custom Interface Standard Specification
v.1.10, 2002. Disponível em: <http://www.opcfoundation.org>. Acesso em 17 de novembro
de 2006.
84
OPC FOUNDATION. OPC Data Access Specification v.3.00, 2003. Disponível em:
<http://www.opcfoundation.org>. Acesso em 17 de novembro de 2006.
OPC FOUNDATION. OPC Historical Data Access v.1.20, 2003. Disponível em:
<http://www. opcfoundation.org>. Acesso em 17 de novembro de 2006.
SANTOS R. A. et al. OPC based distributed real time simulation of complex continuos
process. Simulation Modelling Practice and Theory, Março de 2005.
W3C, SOAP Version 1.2 Part 1: Messaging Framework, 2003. Disponível em:
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. Acesso em 26 de janeiro de
2007.