Opc4

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

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

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.

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.

Í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

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

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

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

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

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

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

• 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

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

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

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

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

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

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

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

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

• 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

• 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

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

• 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

• 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

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

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

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

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

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

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

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

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

• 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

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

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

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)


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

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

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

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

• 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)


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

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

• 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

• 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)


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

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

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

• 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

• 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

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

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

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

• 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

• 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

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

• 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.

56

4 Aplicações e características do OPC -
Estudos de casos

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.

Apesar de se desviarem do seu objetivo primário (OPC FOUNDATION, 1998), diversas
funções um pouco mais elaboradas surgiram para o OPC. O protocolo poderia ser usado como
elo entre equipamentos de fabricantes distintos em malhas de controle, como meio de
comunicação para sistemas de controle avançado ou mesmo como camada base para sistemas
de supervisão mais amigáveis. É nesse contexto que se inicia a discussão sobre os requisitos
necessários ao correto funcionamento do protocolo em comparação às redes industriais
típicas.

Este capítulo trata de alguns casos de aplicação, de testes de fabricantes e também de
trabalhos teóricos, sob o ponto de vista dos requisitos tratados no Capítulo 2.

57

4.1 Principais conceitos

4.1.1 Aplicações em tempo real e características de desempenho

Como citado no Capítulo 2, o bom desempenho da rede é essencial. Requisitos básicos de
uma rede industrial de controle são boa velocidade e bom fluxo de dados. No entanto, o que
define se um sistema de comunicação é veloz o suficiente é sua aplicação.

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.

A principal desvantagem do OPC em termos de desempenho está na criação de outra camada
de comunicação no sistema, utilizando um modelo cliente-servidor. Outro ponto relevante é a
utilização de redes estatísticas (ethernet) como meio de comunicação (SONG et al, 2002), o
que pode gerar alguns inconvenientes (KEW, 2001):

• Atrasos de comunicação devido ao processamento das mensagens pelo servidor;

• Tempos de comunicação variáveis devido à utilização do sistema operacional
Windows, que não foi desenvolvido para aplicações true real-time;

• Diminuição da robustez pela centralização do tráfego de informações em servidores;

• Tempos variáveis pela característica estatística das redes ethernet (SONG et al, 2002).

Os exemplos mostram argumentos qualitativos e quantitativos sobre o desempenho e
aplicabilidade do OPC em casos específicos. Nos estudos, são focadas duas características
principais:

58

• 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.

4.1.2 Otimização, controle avançado e interoperabilidade de redes heterogêneas

Interconectar malhas de controle de diferentes fabricantes muitas vezes é indispensável para
otimizar uma planta e torná-la lucrativa. No entanto, essa integração pode tornar-se uma tarefa
árdua e custosa. Utilizar o OPC como ferramenta de integração pode viabilizar a
interoperabilidade de modo simples e sem prejuízo significativo de desempenho.

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.

4.1.3 Confiabilidade e Disponibilidade no OPC

A confiabilidade e disponibilidade das redes de comunicação industrial são itens muito
importantes. Na maioria dos casos os sistemas de controle industrial tratam de equipamentos e
processos com grande acúmulo de energia, que em caso de falha podem causar grandes perdas
materiais e humanas. Apesar do protocolo ter sido desenvolvido para controle industrial, as
primeiras especificações do OPC não discutem esses itens.

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

o emprego de programas para monitoramento da qualidade da comunicação (BARILLÈRE et
al, 1999).

4.2 Sumário dos casos - Teóricos

4.2.1 OPC em sistemas de controle em tempo real

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.

4.2.1.3 Latência (tempo de atraso)

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.1 Sistema de controle com realimentação (KEW, 2001)

sensor, transmitida para o computador, processada pelo software de controle e reenviada
através da rede de volta para o dispositivo atuador (KEW, 2001).

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.

4.2.1.4 Tempos típicos de atraso

Dois fatores influenciam diretamente nos tempos de comunicação quando utiliza-se o OPC
(KEW, 2001):

• O sistema de aquisição de dados (representado na Figura 4.3 pelo PLC) não se
comunica com o computador por meio de uma rede proprietária. Ao invés disso, tem-
se uma comunicação por meio de uma rede estatística (ethernet);

• O sistema agora possui quatro elementos a mais na cadeia de comunicação: O servidor
OPC, o cliente OPC, as chamadas entre o PLC e o servidor OPC, e as chamadas de
processo entre o cliente OPC e o sistema de controle.

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.

Quando a complexidade da planta aumenta, a situação pode agravar-se significativamente. Se
tivermos 450 valores para serem transferidos em uma única requisição, o tempo de
transferência pode ser 450 vezes maior que o citado (KEW, 2001).

4.2.1.5 Argumentos a favor do OPC

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 Casos teóricos - OPC em controle avançado e otimização

4.2.2.1 Objetivo

Discutir a aplicabilidade do OPC como ferramenta de suporte às aplicações de controle de
alto nível, provendo comunicação entre os dispositivos de campo e o sistema (software) de
controle avançado ou otimização.

4.2.2.2 Metodologia

Revisão bibliográfica. Baseando-se em trabalhos teóricos, foi possível definir as
características necessárias a esse tipo de aplicação e como o OPC se enquadra nesse tipo de
sistema.

63

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 primeira, responsável pelo controle das variáveis de processo (nível, temperatura,
pressão etc), é composta por sensores e controladores atuando diretamente nos
elementos finais de controle. Esses conjuntos formam malhas de controle individuais;

• A segunda, executada por algoritmos especializados, muitas vezes rodando em
computadores independentes e responsáveis por fazer análises mais detalhadas dos
dados do processo. O sistema de otimização enxerga a planta como um todo e na
maioria dos casos é bastante comum o uso de analisadores em linha para obter dados
mais precisos do processo. Como resultado de um cálculo, novos set-points são
gerados para os controladores da primeira camada.

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.

Figura 4.4 Fluxo de informações num sistema de controle avançado ou otimização

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:

• A presença dos analisadores limita os tempos de atuação do sistema. Analisadores
possuem tempo de análise da ordem de dezenas de segundos, alguns mais avançados
possuem tempos de resposta um pouco menores, mais ainda assim, consideráveis;

• É 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.

O protocolo oferece também outras funcionalidades importantes para sistemas de otimização,
como flags de rótulo de tempo e qualidade, além de permitir diversas formas de acesso aos
dispositivos (BARILLÈRE, 1999) com tempos de acesso e freqüências de atualização
distintas.

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 Casos teóricos - OPC como ferramenta de integração de redes industriais

4.2.3.1 Objetivo

Discutir a aplicabilidade do OPC como ferramenta de integração de redes industriais distintas,
provendo comunicação entre dispositivos de campo, controladores e sistema de supervisão,
exercendo também a função da rede de campo.

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 primeiro exemplo da Seção 4.2.1 (OPC em sistemas de controle em tempo real) o
protocolo está disposto “em série” na malha de controle. Pode-se ver nessa situação que,
mesmo em sistemas bastante simples, os tempos de atraso de comunicação entre elementos
ligados pelo OPC podem tornar a estratégia de controle da malha inviável para sistemas muito
rápidos.

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.

Foram considerados na avaliação os seguintes itens: recursos; mercado; compatibilidade;
abertura e flexibilidade; disponibilidade; desempenho.

Recursos

De acordo com (BARILLÈRE, 1999) os recursos de comunicação são um destaque do OPC.
Os quatro modos de comunicação (syncronous, asyncronous, refresh e subscription)
permitem, além de flexibilidade, adequar os diferentes tempos de acesso dos dispositivos.
Outro recurso em destaque são os flags de rótulo de tempo e qualidade, úteis em sistemas de
controle distribuído.

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

específico, é comum ter-se o kit de desenvolvimento necessário para implementá-lo
(BARILLÈRE, 1999). Esse ponto é reconhecido como destaque em favor do OPC, visto que
outros protocolos de unificação de redes falharam neste quesito.

Compatibilidade

Segundo (BARILLÈRE, 1999) não foram encontrados graves problemas de compatibilidade
entre versões. De acordo com o autor, os pequenos problemas encontrados devem-se as
diferentes interpretações das especificações. A OPC Foundation já estaria atenta ao problema,
tendo definido um grupo de certificação para evitar esse tipo de discordância.

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.

Um grande número de ferramentas estava disponível para o desenvolvimento destes
servidores, algumas delas sob forma de versões para avaliação. Em (BARILLÈRE, 1999)
destaca-se a relativa simplicidade para se desenvolver servidores para acesso às fontes de
alimentação CAEN e Lecroy, bem como para o acesso aos dispositivos através do CORBA.

Outro ponto importante é que a utilização dessas ferramentas geralmente requer o
conhecimento da linguagem C++. No entanto, os kits mais avançados possuem a vantagem de
tornar o processo de desenvolvimento independente do nível de detalhamento do DCOM.

Disponibilidade

Os problemas de confiabilidade do OPC podem ser resumidos em dois pontos: a dependência
do DCOM e a falta de uma estratégia específica de redundância de servidores.

68

Segundo (BARILLÈRE, 1999) grande parte da confiabilidade do OPC depende do DCOM,
por ser a tecnologia que suporta sua comunicação. Os tempos de timeout do DCOM são muito
longos (alguns minutos), fazendo com que os clientes OPC sejam avisados tardiamente sobre
possíveis falhas no sistema de comunicação com seus servidores. Um modo de contornar esse
problema seria a implantação de watchdog4 para manter o controle da qualidade da
comunicação.

Em outro trabalho (FONSECA, 2002), trata-se da utilização de servidores redundantes para
melhorar a confiabilidade do OPC. Segundo o autor, apesar das especificações do protocolo
não fazerem menção à utilização de servidores redundantes, seria simples utilizar um
mecanismo para conexão simultânea do cliente a mais de um servidor, verificando seu estado
e fazendo ativações e desativações de grupos que estejam ou não funcionando.

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:

• Para ler n (medidos de 1 a 10.000) itens, um cliente necessitaria de 515+(85 x n) s em
modo síncrono;

• Quando todos os n itens de um grupo fossem alterados (foram medidos de n=500 a
20.000 itens), a taxa mínima de atualização encontrada podia ser aproximada por (80 x
n) s.

4.2.3.4 Conclusões

Em (BARILLÈRE, 1999) conclui-se que as limitações do OPC estão bastante associadas à
utilização do DCOM, conclusão também presente em outros trabalhos (FONSECA, 2002;
KEW, 2001; SANTOS et al, 2005). Acredita-se que esse será um dos principais focos de
desenvolvimento da OPC Foundation. A especificação OPC-UA, atualmente em draft, deve
contornar algumas das limitações levantadas. Nela serão utilizadas pilhas mais simples para
diminuir os tempos de atraso e são previstas redundâncias para aumentar a confiabilidade
(MATRIKON, 2006).

4.3 Sumário dos casos - OPC em situações reais

4.3.1 Testes da Intellution: DCOM, OPC and Performance Issues

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;

• Servidores e clientes gerando tráfego de dados para avaliação de desempenho;

• Testes em ambientes locais e em redes remotas utilizando computadores ligados por
rede ethernet. Foram feitas combinações entre computadores Pentium120 a
Pentium266, rodando Windows NT 4.0 Workstation;

• Computadores ligados em diversas configurações através de uma rede ethernet
10BaseT.

4.3.1.3 Conclusões

• Números de desempenho de acordo com o esperado;

• 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.


A latência da comunicação (tempo entre a solicitação e a disponibilidade de um dado), item
bastante importante, não foi discutida no trabalho.

4.3.2 Testes da Rockwell: The Performance and Throughput of OPC

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;

• Servidores e clientes gerando tráfego de dados para avaliação de desempenho;

• Testes em ambientes locais e em redes remotas utilizando computadores ligados por
rede ethernet. Empregados 6 computadores Pentium266 em diversas configurações,
incluindo clientes e servidores tanto locais quanto remotos;

• O tipo de transmissão escolhida para o teste foi síncrona por representar o pior caso.

4.3.2.3 Conclusões

• O autor conclui que os resultados de desempenho obtidos excedem as necessidades da
grande maioria das aplicaçõ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.


Por se tratar de um teste de fabricante, o texto é bastante tendencioso em favor do OPC.

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 OPC para o sistema de automação da Aciaria da Açominas

4.3.3.1 Objetivo

Discutir diversos aspectos práticos do OPC e apresentar um estudo experimental consistente
(FONSECA, 2002).

4.3.3.2 Metodologia.

Revisão bibliográfica e avaliação prática do desenvolvimento e desempenho de uma aplicação
real.

4.3.3.3 Avaliação prática – Cenário

A ATAN sistemas desenvolveu, em parceria com a Açominas, todo o sistema de automação
para a Aciaria da Usina Intendente Câmara, Localizada em Ouro Branco – MG. O sistema de
automação contempla as seguintes áreas de processo:

• Transporte de matérias primas;

• Desgaseificação a vácuo;

• Convertedores (1 e 2);

• Adição de Fundentes;

• Adição de Ferro-Ligas;

• Ventilação secundária;

• Sistemas de gases (BAUMCO);

• Pesagem de Gusa;

• Pesagem de Sucata;

73

• Sistemas auxiliares;

• Controle de Panelas de Aço e Gusa.

O sistema está ilustrado na Figura 4.5 e foi desenvolvido utilizando os seguintes produtos e
tecnologias:

• CLPs Rockwell: ControlLogix, PLC5 e SLC500;

• Redes de Controle: ControlNet e DH+;

• Rede de aquisição e comunicação: ethernet 10/100 Mbits/s com protocolo TCP/IP;

• Computadores Compaq Pentium III, 500 MHz, 192 MB RAM;

• Sistema operacional Windows NT 4.0;

• Servidor OPC RSLinx da Rockwell;

• Sistema Supervisório Wizcon;

• Acesso de dados via Web utilizando o Wizcon for Internet;

• Estação de cálculos desenvolvida em Delphi para o ambiente Windows NT.

Figura 4.5 Sistema de automação da aciaria da Açominas (FONSECA, 2002)

74

4.3.3.4 Principais dificuldades encontradas

• As primeiras versões dos produtos para comunicação OPC não apresentavam
desempenho satisfatório, além de alguns bugs;

• 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;

• Os técnicos envolvidos no projeto possuíam pouca experiência com os produtos e com
o padrão OPC.

4.3.3.5 Desempenho

Os valores de desempenho foram monitorados no seguinte contexto:

• O volume de dados de cada estação foi organizado em função das necessidades de
atualização de cada dado, definindo-se as taxas de leitura para atender às exigências da
aplicação;

• O total de dados e as taxas de leituras apresentados correspondem à situação atual da
aplicação. Os dados são enviados pelo servidor por transição de estado (exceção);

• Basicamente, todos os servidores estão executando na mesma máquina do cliente.
Somente algumas estações de monitoração do sistema de supervisão fazem o acesso
remoto, através do servidor OPC RSLinx;

• O consumo de CPU apresentado para o servidor OPC corresponde à condição normal
de operação.

75

Tabela 4.1 Desempenho do OPC por estação (FONSECA, 2002)

Estação Número de Tags por Consumo
Taxa de Leitura CPU (%)
500 ms 1s 2s
Convertedor 706 5.241 973 10
RH 901 1.080 1.053 5
Transporte 103 1.030 338 4
Gusa 712 0 0 1
Cálculos 0 991 0 3
Sucata 26 263 14 <1

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

• São comentadas as dificuldades de se obter confiabilidade, item apontado em outros
trabalhos (BARILÈRE, 1999). A solução adotada depende de um produto
independente, o que fere os objetivos iniciais do OPC;

• O desempenho é avaliado como próximo ou superior aos protocolos e drivers
específicos com função similar.

4.4 Testes de desempenho – Alguns números

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.

4.4.1 Testes da Rockwell: The Performance and Throughput of OPC

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.

Tabela 4.2 Resultados do teste (BURKE, 1998)

Itens Mudanças / s Itens / s
Cliente 1 10.000 4 40.000
Cliente 2 10.000 4 40.000
Cliente 3 10.000 4 40.000
Cliente 4 10.000 4 40.000
Cliente 5 10.000 4 40.000
Total do servidor 200.000

78


Itens Words/Itens Mudanças / s Itens / s
Cliente 1 100 200 14 280.000
Cliente 2 100 200 14 280.000
Cliente 3 100 200 14 280.000
Cliente 4 100 200 14 280.000
Cliente 5 100 200 14 280.000
Total do servidor 7.000 1.400.000

• Teste 3 - Cliente e servidor rodando localmente na mesma máquina utilizando Itens
do tipo tags, com 4 bytes cada e taxa de atualização de 200ms. Os resultados podem
ser visto na Tabela 4.4.


Itens Mudanças / s Itens / s
Cliente 1 10000 5 50000

• Teste 4: Cliente e servidor rodando localmente na mesma máquina utilizando Itens
com 500 words de tamanho cada e taxa de atualização de 60ms por item. Os
resultados podem ser visto na Tabela 4.5.

Tabela 4.5 - Resultados do teste (BURKE, 1998)

Itens Words / Itens Mudanças / s Itens / s Words / s
Cliente 1 100 500 16 1.600 800.000

4.4.1.2 Análise dos resultados

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

A necessidade de interoperabilidade entre sub-redes heterogêneas de um mesmo sistema de
automação industrial motivou o desenvolvimento do protocolo OPC, alvo do nosso trabalho.

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.

A apresentação do protocolo teve foco nas especificações mais empregadas atualmente.
Outras que não foram completamente detalhadas no texto estão disponíveis apenas para
membros da OPC Foundation. Algumas especificações estão em versão draft, como a OPC-
UA, fato que pode gerar pequenas discrepâncias entre as características descritas e as que
sejam publicadas oficialmente.

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.

Analisando-se as perspectivas expostas nas referências consultadas, é possível dizer que,
mantendo-se a idéia de se tornar o protocolo independente de um sistema operacional

81

específico, no caso o Windows, o emprego do OPC na indústria crescerá tornando-o um
padrão bastante difundido, que permeará não apenas os níveis mais elevados das redes, mas
também os mais baixos, no campo. Esse último aspecto fruto do emprego cada vez maior de
poder computacional embutido nos elementos finais de controle das plantas industriais, ou
seja, na instrumentação de campo.

82

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.

BURKE, T. J. The Performance and Throughput of OPC – A Rockwell Software
Perspective, Rockwell Software Inc., 1998

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.

DCS. Disponível em: <http://en.wikipedia.org/wiki/Distributed_Control_System>. Acesso em
15 de dezembro de 2006.

DEVICENET. Disponível em: <http://www.odva.org>. Acesso em 01 dezembro de 2006.

DJIEV, S. N. Industrial Networks for Communication and Control, Reading for Elements
for Industrial Automation, Technical University, Sofia, Bulgaria, 2003.

FARENGA, P. The Windows Human-Machine Interface gets an industrial face lift,
Industrial Embedded Systems Magazine, maio de 2006.

FONSECA, M. O. Comunicação OPC – Uma abordagem prática. In: SEMINÁRIO DE
AUTOMAÇÃO DE PROCESSOS DA ABM, 6., 2002, Vitória, Brasil. Anais... Vitória, 2002.

FOUNDATION FIELDBUS. Disponível em: <http://www.foundationfieldbus. org>. Acesso
em 01 dezembro de 2006.

83

ICONICS, OPC Complex Data: New Capabilities Maximize Object-Oriented Systems,
2004. Disponível em <http://www.iconics.com/news/article_display.asp?
Article=Ctrl1204_1.htm>. Acesso em 15 de dezembro de 2006.

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.

IWANITZ, F.; LANGE, J. OPC: Fundamentals, implementation and applications. 2ª
Edição Revisada, Editora Heidelberg-Huthig, Alemanha, 2002.

KEW S.; DWOLATZKY B. Real-time performance of OPC, In: SAICSIT 2001
Conference. Disponível em: <http://osprey.unisa.ac.za/saicsit2001/Electronic/paper 45.PDF>.
Acesso em 12 de outubro de 2006.

MAP. Disponível em: <http://javvin.com/protocol/ MAP.html>. Acesso em 15 de dezembro
de 2006.

MATRIKON. OPC Unified Architecture (OPC UA) Part 1 - Concepts RC 1.00.
Disponível em <www.matrikonopc.com/downloads/58/specifications/ index.aspx>. Acesso
em 17 de novembro de 2006.

Microsoft. DCOM Technical Overview – 1996. Disponível em: <http://msdn.microsoft.com
/library/default.asp?url=/library/en-us/dndcom/html/ msdn_dcomtec.asp>. Acesso em 20 de
novembro de 2006.

MONTENEGRO, F.; PACHECO, R. Orientação a Objetos em C++, 1ª. Edição, Editora
Ciência Moderna,1994.

MOON, H. An Introduction to Industrial Networks, Seoul National University, Korea,
1999.

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, Compliance Test, 2006. Disponível em <http://www.
opcfoundation.org/Default.aspx/04_tech/04_compliance.asp?MID=AboutOPC>. Acesso em
20 de dezembro de 2006.

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.

OPC FOUNDATION. OPC Overview v1.0, 1998. Disponível em: <http://www.opcfoundatio
n.org/Archive/72e9fbfa-6a89-4ef2-9b6d-3f746fd7eb05 /General/OPC%20Overview%201.00.
pdf> . Acesso em 01 dezembro de 2006.

OPC FOUNDATION, OPC Security Custom Interface v1.0, 2000. Disponível em
<www.opcfoundation.org>. Acesso em 17 de dezembro de 2006.

OPC FOUNDATION. OPC Unified Architecture v1.0, 2006. Disponível em:
<http://www.opcfoundation.org>.Acesso em 17 de novembro de 2006.

OPC FOUNDATION. What is OPC?, 2006. Disponível em: <http://www.opc
foundation.org/Defa-ult.aspx/01_about/01_whatis.asp?MID=AboutOPC>. Acesso em 17 de
novembro de 2006.

POLONYI, M. J. G. PID Controller Tuning Using Standard. Optimisation Control
Engineering Online. Disponível em: <http://www.controleng.com /webexcl/features/pid/
control.htm>. Acesso em 03 de outubro de 2006.

PROFIBUS STANDARD. Disponível em: <http://www.profibus.org>. Acesso em 01
dezembro de 2006.

RÜPING, S.; KLUGMANN, H.; GERDES, K.; MIRBACH, S. A modular OPC-server
connecting different fieldbussystems and internet Java applets. In: Dietrich, D.;
Neumann, P.; Schweinzer, H. (ed.). FIELDBUS CONFERENCE (FeT 99): FIELDBUS

85

TECHNOLOGY: SYSTEMS INTEGRATION, NETWORKING, AND ENGINEERING,
1999, Magdeburg, Germany. Proceedings… Magdeburg: Springer-Verlag, 1999. p. 240-246.

SANTOS R. A. et al. OPC based distributed real time simulation of complex continuos
process. Simulation Modelling Practice and Theory, Março de 2005.

SANTOS, B. M. Estudo do OPC Aplicado em Plataformas. Monografia (Especialização
em Engenharia Mecatrônica) – Faculdade de Engenharia,UERJ, Rio de Janeiro, maio de
2006.

TANENBAUM, A. S. Redes de Computadores, 4ª. Edição, Editora Campus, 2003.

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.

Opc4

Mais conteúdo relacionado

Semelhante a Opc4

Mais de redesinforma

Último

Opc4