Vous êtes sur la page 1sur 87

UNIVERSIDADE FEDERAL DE ITAJUB

PROGRAMA DE PS-GRADUAO EM
ENGENHARIA ELTRICA

Robson Neves Gonalves

Desenvolvimento de Servidores OPC DA,


OPC UA e Wrappers para aplicao em
Automao.

Dissertao submetida ao Programa de Ps-Graduao em


Engenharia Eltrica como parte dos requisitos para
obteno do Ttulo de Mestre em Cincias em
Engenharia Eltrica

rea de Concentrao: Automao e Sistemas Eltricos


Industriais.

Orientador(a): Prof. Lcia R. H. Franco, Dra.

Fevereiro de 2012

Itajub - MG
UNIVERSIDADE FEDERAL DE ITAJUB
PROGRAMA DE PS-GRADUAO EM
ENGENHARIA ELTRICA

Robson Neves Gonalves

Desenvolvimento de Servidores OPC DA,


OPC UA e Wrappers para aplicao em
Automao.

Dissertao aprovada por banca examinadora em 29/02/2012 , conferindo ao


autor o ttulo de Mestre em Cincias em Engenharia Eltrica

Banca Examinadora
Prof. Lcia R. H. Franco, Dra. (Orientadora)
Prof. Luiz Gabriel Lenarth, Dr.
Profa. Itana Stiubiener, Dra.

Fevereiro de 2012
Itajub - MG
Robson Neves Gonalves

Desenvolvimento de Servidores OPC DA, OPC UA e Wrappers para


aplicao em Automao.

Dissertao submetida ao Programa de Ps-Graduao em Engenharia Eltrica como


parte dos requisitos para obteno do Ttulo de Mestre em Cincias em Engenharia
Eltrica

Aprovada em 29 de Fevereiro de 2012.

COMISSO EXAMINADORA

______________________________________________
Prof. Lcia R. H. Franco, Dra. (Orientadora)

______________________________________________
Prof. Luiz Gabriel Lenarth, Dr.

______________________________________________
Profa. Itana Stiubiener, Dra.
RESUMO

Este trabalho apresenta as informaes relevantes para o

desenvolvimento de servidores OPC DA, UA e Wrappers. Aborda o conceito

terico sobre a tecnologia e as ferramentas utilizadas para o desenvolvimento,

proporcionando a sntese para a elaborao desse tipo de sistema. O estudo

contextualizado em uma situao real de aquisio de dados usando o

sistema supervisrio Elipse E3, para supervisionar os resultados provenientes

do servidor OPC DA/UA e o Elipse Plant Manager - EPM para aquisitar os

resultados provenientes do servidor OPC DA (Elipse E3), e ser entendido por

um OPC UA Cliente atravs do OPC Wrapper. Para o Ambiente de Teste foi

configurada uma rede MODBUS TCP, com os mdulos de Automao da

empresa Advantech ADAM. Para garantir a conformidade dos servidores

criados so realizados os testes de conformidade, utilizando o Compliance

Test Tool CTT da OPC Foundation, demonstrando a capacidade de

interoperabilidade fornecida pelas solues desenvolvidas. Aps os testes so

apresentadas os principais pontos de falhas ocorridas e as respectivas

solues.

Palavras-chave: OPC UA, OPC DA, Wrappers OPC, Elipse E3, Elipse Plant

Manager, Sistemas Supervisrios, SCADA, CTT.


ABSTRACT

This work presents relevant information to the development of OPC servers (DA

and UA) and OPC Wrappers. It provides the concepts needed to develop this

type of system. The study is realized in a real time data acquisition by the E3

software, supervising the results from the OPC DA server / UA and Elipse Plant

Manager EPM to give the results from the OPC DA (E3), and be understood

by an OPC Client through the Wrapper OPC. For the test environment was set

up a Modbus TCP network with modules from Advantech - ADAM Automation

Company. To ensure the compliance of servers created are performed

compliance testing using the Compliance Test Tool - CTT of the OPC

Foundation, demonstrating the ability of interoperability provided by the

solutions developed- Also are presented the results of Compliance tests,

demonstrating the ability to interoperability provided by the implemented

solutions. After the tests are presented the main points of failure that occurred

and their solutions.

Key-words: OPC UA, OPC DA, Wrappers OPC, Elipse E3, Elipse Plant

Manager, Supervisory Systems SCADA.


LISTA DE SIGLAS E ABREVIATURAS

OPC OLE for Process Control


SCADA Supervisory Control and Data Acquisition
COM Component Object Model
DCOM Distributed Component Object Model
CLP Controladores Lgico Programveis
DCS Distributed Control Systems
MES Manufacturing Execution Systems
RTS Real Time Systems
PC Personal Computer
OSI Open Systems Interconnection
TCP Transmission Control Protocol
IP Internet Protocol
IHM Interface Homem Mquina
DOS Disk Operating System
UA Unified Architecture
ERP Enterprise Resource Planning
PC Personal Computer
OSF Open Software Foundation
DCE Distributed Computing Environment
RPC Remote Procedure Call
EJB Enterprise Java Bean
HMI Human Machine Interface
DA Data Access
A&E Alarms & Events
HDA Historical Data Access
EPM Elipse Plant Manager
AC Alarm and Condition
FDI Field Device Integration
EDDL Eletronic Device Description Language
FDT Field Device Tool
HA Historical Access
PROG Programs
CTT Compliance Test Tool
IEDs Intelligent Electronic Devices
SDK Software Developing kit
IETF Internet Engeneering Task Force
ADAM Advantech Data Acquisition Modules
4

LISTA DE FIGURAS

Figura 1 - Caso Tpico comunicao Clientes e Servidores OPC ....................... 15

Figura 2 - Objetos Criados por um OPC Cliente para Acesso aos Dados ......... 17

Figura 3 - Objetos criados pelo Cliente OPC para receber eventos ................... 18

Figura 4 - Pgina de Configurao para o DA Compliance Test Tool ................ 22

Figura 5 - Sumrio de resultados de teste servidores DA..................................... 23

Figura 6 - A Fundao do OPC UA........................................................................... 26

Figura 7 - Camadas Arquitetura OPC UA................................................................ 27

Figura 8 - Especificaes OPC UA ........................................................................... 29

Figura 9 - Camadas Arquitetura de Comunicao do OPC UA ........................... 30

Figura 10 - OPC UA Camadas de Software ............................................................ 32

Figura 11 - Camadas de Comunicao UA Stack definidas no UA Part 6......... 33

Figura 12 - Servidor OPC UA CTT............................................................................ 35

Figura 13 - Wrapper UA fornencendo acesso ao Servidor OPC DA................... 37

Figura 14 - Proxy DA COM fornecendo acesso para um Servidor OPC UA ..... 38

Figura 15 - Exemplo de IHM com viso de Processo............................................ 39

Figura 16 - Exemplo de uma tela de supervisrio para controle e monitorao40

Figura 17 - PC para CLP ou DCS com um Barramento de Comunicao e

sensores ........................................................................................................................ 41

Figura 18 - PC para IED usando barramento de comunicao .......................... 42

Figura 19 - Exemplo de arquitetura de uma aplicao E3 .................................... 44

Figura 20 - Exemplo de Rede Industrial................................................................... 46

Figura 21 Modbus sobre TCP/IP............................................................................ 47

Figura 22 Criao de um novo Projeto ................................................................. 51


5

Figura 23 Seleo de Itens para o toolbox........................................................... 51

Figura 24 Seleo do driver .................................................................................... 52

Figura 25 Seleo do driver Toolbox Items ...................................................... 53

Figura 26 Insero do Icone SLIK-DA na Form ............................................. 53

Figura 27 Identificao do CLSID .......................................................................... 54

Figura 28 Exemplo de linha de comando ............................................................. 55

Figura 29 Busca do arquivo executavel criado.................................................... 56

Figura 30 Resgistro do Servidor............................................................................. 56

Figura 31 Criao de Tags...................................................................................... 57

Figura 32 Criando um procedimento para leitura das tags................................ 58

Figura 33 - Ambiente de Testes ................................................................................ 60

Figura 34 - Ambiente de Testes - Real..................................................................... 60

Figura 35 Configurao Aba General CTT ........................................................ 62

Figura 36 Configurao Aba OPC Server CTT................................................. 63

Figura 37 Configurao Aba OPC Group CTT ................................................. 63

Figura 38 Configurao Aba Stresss CTT ......................................................... 64

Figura 39 Configurao Aba Performance CTT ............................................... 65

Figura 40 - CTT Servidor OPC DA Desenvolvido................................................... 66

Figura 41 - CTT Servidor OPC UA Desenvolvido................................................... 68

Figura 42 - Exemplo Cliente OPC Softing ............................................................ 69

Figura 43 - Servidor OPC UA e OPC DA............................................................... 70

Figura 44 - Interface desenvolvida ............................................................................ 71

Figura 45 - Elipse E3 - Configurao OPC............................................................. 71

Figura 46 - Ambiente de Testes com EPM .............................................................. 72

Figura 47 - EPM Configurao OPC .................................................................... 73


6

Figura 48 - EPM Configurao Interface OPC ................................................... 74

Figura 49 - EPM Desenvolvido.............................................................................. 75


7

SUMRIO
1. INTRODUO ------------------------------------------------------------------------------------- 9

1.1 CONSIDERAES INICIAIS ------------------------------------------------------------------ 9

1.2 MOTIVAO --------------------------------------------------------------------------------------11

1.3 OBJETIVOS ---------------------------------------------------------------------------------------12

1.3.1 OBJETIVO GERAL------------------------------------------------------------------------12

1.3.2 OBJETIVOS ESPECFICOS------------------------------------------------------------12

1.4 ORGANIZAO DO DOCUMENTO -------------------------------------------------------12

2. OPC --------------------------------------------------------------------------------------------------14

2.1. OPC FOUNDATION -----------------------------------------------------------------------------14

2.2. OPC CLSSICO ---------------------------------------------------------------------------------15

2.3. OPC DATA ACCESS ---------------------------------------------------------------------------16

2.4. OPC ALARM & EVENTS ----------------------------------------------------------------------18

2.5. OPC HISTORICAL DATA ACCESS--------------------------------------------------------19

2.6. COMPLIANCE TEST TOOL (OPC CLSSICO) ----------------------------------------20

2.7. AUTO CERTIFICAO ------------------------------------------------------------------------20

2.8. SERVIDOR COMPLIANCE TEST TOOL--------------------------------------------------20

3. OPC UA---------------------------------------------------------------------------------------------24

3.1. MOTIVAO OPC UA -------------------------------------------------------------------------24

3.2. OPC UA VISO GERAL --------------------------------------------------------------------25

3.3. OPC UA ESPECIFICAES -----------------------------------------------------------------28

3.4. OPC UA SOFTWARE LAYERS -------------------------------------------------------------31

3.5. COMPLIANCE TEST TOOL OPC UA------------------------------------------------------34

3.5.1. SERVIDOR OPC UA CTT ---------------------------------------------------------------34

4. MIGRAO OPC UA ---------------------------------------------------------------------------36

4.1. VISO GERAL------------------------------------------------------------------------------------36


8

4.2. WRAPPERS ---------------------------------------------------------------------------------------36

4.3. PROXIES -------------------------------------------------------------------------------------------37

5. SISTEMAS SUPERVISRIOS ---------------------------------------------------------------39

5.1. INTRODUO ------------------------------------------------------------------------------------39

5.2. SCADA----------------------------------------------------------------------------------------------40

5.2.1. LIMITES DOS SISTEMAS SCADA ---------------------------------------------------43

5.3. ELIPSE E3 -----------------------------------------------------------------------------------------43

5.4. E3 SERVER ---------------------------------------------------------------------------------------44

5.5. ELIPSE PLANT MANAGER ------------------------------------------------------------------45

6. REDES INDUSTRIAIS--------------------------------------------------------------------------46

6.1. MODBUS -------------------------------------------------------------------------------------------47

7. DESENVOLVIMENTO SERVIDOR OPC DA E UA-------------------------------------49

7.1. AMBIENTE DE DESENVOLVIMENTO ----------------------------------------------------49

7.2. TOOLKIT DE CRIAO DE INTERFACES ----------------------------------------------49

7.3. TESTES DOS SERVIDORES -----------------------------------------------------------------58

7.4. AMBIENTE DE TESTES -----------------------------------------------------------------------59

7.5. TESTES DE CONFORMIDADE--------------------------------------------------------------61

7.6. TESTES COM CLIENTES ---------------------------------------------------------------------68

8. DESENVOLVIMENTO WRAPPER OPC --------------------------------------------------72

8.1. AMBIENTE DE DESENVOLVIMENTO ----------------------------------------------------72

8.2. AMBIENTE DE TESTES -----------------------------------------------------------------------72

8.3. TESTES WRAPPER OPC ---------------------------------------------------------------------73

9. CONCLUSES -----------------------------------------------------------------------------------75

REFERNCIAS-----------------------------------------------------------------------------------------78
9

1. INTRODUO

1.1 Consideraes Iniciais

As regras de comunicao entre componentes distribudos possuem

papel fundamental na evoluo tecnolgica, otimizando o processo produtivo.

Essa otimizao realizada atravs da consistncia do fluxo de dados,

qualidade e disponibilidade destes dados em nvel de campo.

A utilizao de interfaces padronizadas por diversos fabricantes um

pr-requisito para flexibilidade e integrao de softwares e componentes.

Segundo (MAHNKE;LEITNER;DAMM,2009) o OPC (OLE for Process

Control) tem sido aceito como uma interface padro entre clientes e servidores,

para diferentes campos de aplicao, se tornando o padro mais popular entre

usurios e desenvolvedores. A maioria dos fabricantes tanto de IHMs (Interface

Homem Mquina), SCADA (Supervisory Control and Data Acquisition), e DCS

(Distributed Control System) quanto servios de controle, MES (Manufacturing

Execution Systems) e ERP (Enterprise Resource Planning) oferecem interfaces

OPC Cliente e/ou Servidor.

O Padro OPC surgiu da necessidade de se ter uma interface de

comunicao nica entre um incontvel nmero de redes, protocolos

proprietrios e interfaces usadas. Esse padro reuni uma srie de vantagens

aos sistemas industriais, que os diferenciam dos demais, como: o

isolamento de trfego, a facilidade de integrao entre sistemas e a

interoperabilidade (NASCIMENTO FILHO,2005).

Com isto, a aquisio de informaes no fica dependente de um driver

especfico, desenvolvido por um fornecedor de uma determinada soluo. O


10

uso de um padro nico para a execuo da comunicao entre o campo e os

sistemas de superviso e gerenciamento faz com que os custos de

desenvolvimento e manuteno de sistemas caiam substancialmente. O

conhecimento necessrio para se trabalhar com as tecnologias envolvidas no

desenvolvimento de solues em um padro nico no

demasiadamente grande, e sua expanso no depende de novas curvas de

aquisio de conhecimento (RIEDL,2001).

Atualmente, uma nova verso do Padro OPC, o OPC UA (Unified

Architecture), est sendo comercializada no mercado. Este novo padro foi

desenvolvido com base na experincia adquirida desde a implantao da

Tecnologia OPC, mais de treze anos desde o seu incio, e mudanas

tecnolgicas ocorridas durante esse perodo.

Segundo, (BURKE;IWANITZ;LANGE,2010), algumas razes motivaram

o desenvolvimento dessa nova gerao, citando: descontinuao do

COM/DCOM (Component Object Model / Distributed COM), limitaes DCOM,

utilizao do OPC em plataformas No-Windows, necessidade de Alta

Performance em comunicao via Web Services e a integrao de todas as

ferramentas em um modelo unificado.

OPC UA fornece estratgias de migrao para o OPC UA. Ferramentas

como Wrappers and Proxies fornecidos pela OPC Foundation esto disponveis

para traduzir diferentes interfaces do OPC Clssico para o OPC UA e vice-

versa.
11

1.2 Motivao

A principal motivao de se trabalhar com o OPC a capacidade e

possibilidade de se trabalhar com informaes entre diversas tecnologias e

plataformas.

Com a implantao do OPC UA, novas caractersticas so adicionadas

ao padro OPC, porm o OPC UA pode coexistir com o padro clssico. Isso

permite o acesso s novas propriedades sem alterar ou modificar a tecnologia

j implantada, reduzindo o perodo de comissionamento e start-up,

possibilitando uma migrao suave entre as duas tecnologias.

Atualmente, milhares de produtos utilizam o OPC Clssico, e podem

tambm utilizar as vantagens do OPC UA. Esta migrao pode ser realizada

atravs do desenvolvimento de Wrappers (Acesso Servidor COM de um Cliente

UA) e Proxies (Acesso Servidor UA de um Cliente COM). Neste ponto, o

desenvolvimento dessas ferramentas torna-se um diferencial no mercado de

Automao e Redes Industriais.

Segundo (NASCIMENTO FILHO,2005), este padro por ser

Internacionalmente conhecido e desenvolvido por grandes empresas

desenvolvedoras de sistemas de automao industrial, tornou-se

realmente um padro de baixa mutabilidade e fcil conformidade.


12

1.3 Objetivos

1.3.1 Objetivo Geral

Desenvolver dois servidores OPC DA e OPC UA baseado nas

especificaes da OPC Foundation e um Wrapper para realizao de Acesso a

um Servidor COM atravs de um Cliente UA.

1.3.2 Objetivos Especficos

Realizar um estudo sobre a tecnologia do OPC Clssico e OPC

UA.

Apresentar informaes relevantes para o desenvolvimento de

servidores OPC DA e UA.

Apresentar um sistema de comunicao confivel para aquisio

de informaes disponibilizando-as de forma padronizada.

Desenvolver um Wrapper que seja capaz de intermediar a

comunicao entre as duas tecnologias.

1.4 Organizao do documento

O captulo 1 responsvel por toda parte introdutria do trabalho,

incluindo a motivao, o objetivo geral e os objetivos especficos.

O captulo 2 abrange toda a reviso de literatura relacionada OPC

Foundation, o OPC Clssico (OPC DA, OPC A&E, OPC HDA), includo tambm

a ferramenta para anlise de conformidade dos Servidores, o Compliance test

Tool - CTT.

O captulo 3 compreende toda a reviso de literatura relacionada ao


13

OPC UA, includo uma viso geral sobre a tecnologia, as especificaes e

tambm a ferramenta para anlise de conformidade do Servidores UA, o

Compliance test Tool OPC UA CTT UA.

O captulo 4 responsvel pela reviso de literatura relacionada

Migrao do OPC Clssico para o OPC UA e vice-versa, focando

principalmente nos Wrappers e Proxies.

O captulo 5 abrange todo o contedo tcnico relacionado aos sistemas

supervisrios, indo do conceito terico at os softwares utilizados no trabalho

(E3 e EPM), dando uma viso geral sobre o desenvolvimento de projetos nesta

rea.

O captulo 6 compreende o conceito de redes industriais, com um foco

maior no MODBUS TCP, sendo a rede utilizada no trabalho.

O captulo 7 responsvel por toda a parte prtica e desenvolvimento

do trabalho, focando no desenvolvimento dos servidores atravs dos toolkits, o

ambiente de desenvolvimento, os testes dos servidores, testes de

conformidade e com clientes.

O captulo 8 abrange o desenvolvimento do Wrapper OPC,

principalmente com relao ao ambiente de desenvolvimento, de testes e os

resultados, alm de compreender a utilizao do Elipse Plant Manager EPM.

O captulo 9 apresenta a concluso do trabalho, com todos importantes

relacionados ao trabalho.
14

2. OPC
2.1. OPC Foundation

O uso do PC e softwares em sistemas de automao industrial

rapidamente cresceu desde os anos 90, especialmente PCs com sistemas

operacionais Windows, usados para visualizao e controle de processos. Nos

ltimos anos um dos maiores esforos para o desenvolvimento de uma

padronizao de softwares de automao, foi a padronizao do acesso aos

dados em equipamentos onde diversos sistemas, protocolos, e interfaces eram

usados.

Problemas para aplicaes de software j existiam para o acesso a

impressoras em ambiente DOS. Todas as aplicaes precisavam inserir seus

prprios drivers de impressora para todas as impressoras suportadas, um

trabalho rduo e complicado na poca. O Windows resolveu o problema dos

drivers, incorporando o suporte a impressoras no sistema operacional. Uma

interface com os drivers de impressora servia todas as aplicaes que

precisavam de acesso impressora.

Os vendedores de softwares de IHMs e SCADA tinham problemas

similares, e uma fora tarefa foi iniciada com o objetivo de definir um padro de

drivers para o Plug&Play de equipamentos, permitindo um acesso padronizado

aos dados de Automao sobre plataforma Windows.

O resultado foi criao de uma especificao para o OPC Data

Access, em Agosto de 1996. Neste mesmo perodo foi criada a OPC

Foundation, uma organizao sem fins lucrativos que tem como objetivo

manter e desenvolver este padro (MAHNKE;LEITNER;DAMM,2009).


15

2.2. OPC Clssico

Nos ltimos anos, a OPC Foundation tem definido interfaces de

softwares para padronizar o fluxo de informao no nvel de campo at o nvel

de gerenciamento. De acordo com a OPC COMMON DEFINITIONS AND

INTERFACES (1998), com as diferentes necessidades dentro das aplicaes

industriais, trs principais especificaes OPC foram desenvolvidas

inicialmente: Data Access (DA), Alarm & Events (AE) e Historical Data Access

(HDA).

O OPC usa uma arquitetura cliente-servidor para a troca de

informaes. Um Servidor OPC encapsula as informaes de processo e

disponibiliza na sua interface. Um OPC Cliente conecta no Servidor OPC e

pode acessar e consumir os dados oferecidos. As aplicaes consomem e

fornecem dados que podem ser tanto do cliente quanto do servidor (Figura 1).

Figura 1 - Caso Tpico comunicao Clientes e Servidores OPC

Fonte: MAHNKE;LEITNER;DAMM,2009
16

Interfaces de OPC Clssico so baseadas na tecnologia COM e DCOM

da Microsoft. A vantagem dessa parceria foi reduo do trabalho inicial de

especificao para definio de diferentes APIs para diferentes necessidades

de cada especialidade, sem a necessidade de definir um protocolo de rede ou

um mecanismo para comunicao entre os processos.

O COM e DCOM fornecem um mecanismo transparente para um cliente

chamar mtodos sobre um objeto COM, em um servidor rodando em um

mesmo processo, em outro processo, ou em outro n na rede.

(MAHNKE;LEITNER;DAMM,2009)

Usando esta tecnologia disponvel em todos os PCs com sistema

operacional Windows reduziu-se o tempo de desenvolvimento das

especificaes e produtos, alm de reduzir o tempo de chegada do OPC ao

mercado. Esta vantagem foi importante para o sucesso do OPC.

As duas principais desvantagens so a dependncia do OPC em uma

plataforma Windows e os problemas da tecnologia DCOM na utilizao de

comunicao remota com o OPC.

A tecnologia DCOM de difcil configurao, tem perodos longos e no

configurveis de timeouts, e no podem ser usados para comunicao internet

(BURKE;IWANITZ;LANGE,2010).

2.3. OPC Data Access

A interface do OPC Data Access permite leitura, escrita e monitoramento

das variveis dispostas no processo. O seu principal uso mover em tempo

real dados de CLPs, DCSs e outros equipamentos de controle para IHMs e


17

outros supervisrios (OPC DATA ACCESS CUSTOM INTERFACE

STANDARD, 2002).

O OPC DA a mais importante interface OPC, implantada em 99% dos

produtos que utilizam a tecnologia OPC atualmente

(MAHNKE;LEITNER;DAMM,2009).

O Cliente OPC DA seleciona as variveis (OPC Items) que quer ler,

escrever ou monitorar no Servidor. O Cliente OPC estabelece a comunicao

com o Servidor pela criao do objeto OPCServer. O Objeto OPCServer

oferece mtodos para navegar atravs de espaos de endereo e encontrar

itens e suas propriedades, como: tipo de dados e direitos de acesso.

Para acessar os dados, os OPC Items possuem a mesma configurao,

inclusive tempo de atualizao no objeto OPC Group. A Figura 2 mostra os

diferentes objetos que o OPC Cliente cria no servidor.

Figura 2 - Objetos Criados por um OPC Cliente para Acesso aos Dados
Fonte: MAHNKE;LEITNER;DAMM,2009

Quando adicionados a um grupo, os items podem ser lidos ou escritos

pelo cliente. O caminho preferido para a leitura cclica de dados pelo cliente

monitorando as mudanas de estado no servidor. O cliente define uma taxa de

atualizao do grupo, contendo os items de interesse. A taxa de atualizao

usada no servidor para o check cclico de mudana de valores/estado. Depois

de cada ciclo, o servidor apenas atualiza os valores do cliente.


18

O timestamp e a qualidade na entrega dos dados so fornecidos pelo

OPC Clssico. A qualidade na entrega avalia se o dado preciso, se no est

disponvel (mal) ou no conhecido (Incerto) (OPC DATA ACCESS CUSTOM

INTERFACE STANDARD, 2002).

2.4. OPC Alarm & Events

O OPC A&E habilita a recepo de notificaes de eventos e alarmes.

Eventos so simples notificaes informando o cliente sobre alguma

ocorrncia. Os Alarmes so notificaes que informam os clientes sobre as

mudanas das condies de processo (OPC COMMON DEFINITIONS AND

INTERFACES,1998).

Muitos alarmes incluem um ACK e este ACK tambm pode ser includo

na interface OPC A&E. Para receber notificaes, o Cliente OPC A&E conecta-

se ao servidor, subsescreve a notificao, e ento recebe todas as notificaes

acionadas no servidor.

O Cliente OPC conecta-se ao Servidor A&E pela criao do objeto

OPCEventServer, e posteriormente pelo OPC EventSubscription, usado para

receber as mensagens de evento.

Figura 3 - Objetos criados pelo Cliente OPC para receber eventos


Fonte: MAHNKE;LEITNER;DAMM,2009
19

2.5. OPC Historical Data Access

Como o OPC DA fornece dados em tempo real, continuamente ocorrem

atualizaes de dados, segundo (MAHNKE;LEITNER;DAMM,2009), o OPC

Historical Data Access d acesso aos dados armazenados. De um simples

login a complexos sistemas SCADA, arquivos histricos podem ser

recuperados de maneira uniforme.

O Cliente OPC conecta ao Servidor HDA pela criao do objeto

OPCHDAServer. Este objeto oferece todas as interfaces e mtodos para leitura

e atualizao dos dados histricos. Um segundo objeto, OPCHDABrowser,

definido para navegao nos endereos do Servidor HDA.

A principal funcionalidade do HDA a leitura de dados histricos de trs

diferentes maneiras, a primeira realizao a leitura das linhas de dados do

arquivo, onde o cliente define um ou mais variveis e o tempo que ele quer ler.

O servidor retorna todos os valores arquivados conforme especificado pelo

cliente.

A segunda maneira a leitura dos valores de uma ou mais variveis

conforme timestamps especificados.

A terceira forma computa valores de dados agregados em uma base de

dados para um especificado domnio para uma ou mais variveis. Os valores

arquivados sempre possuem associado qualidade e timestamp. Alm disso,

nos mtodos de leitura, o OPC HDA tambm define mtodos para insero,

troca, e excluso de dados em uma base de dados

(MAHNKE;LEITNER;DAMM,2009).
20

2.6. Compliance Test Tool (OPC Clssico)

Um padro aberto tal como o OPC criado com o objetivo de permitir a

interoperabilidade entre produtos de diferentes fabricantes. Para assegurar

que o produto cumpriu com as especificaes deve-se realizar uma srie de

testes que certificam o produto.

A no conformidade de um produto tipicamente decorre de uma

interpretao incorreta da especificao. O Teste de Conformidade projetado

para auxiliar o fabricante a encontrar e corrigir no conformidades antes de

encontr-los no campo.

2.7. Auto Certificao

A auto certificao separada em dois grupos, um para a certificao

de servidores e outra para clientes. Para servidores, a OPC Foundation criou e

tem mantido um conjunto de testes de auto certificaes, o chamado

Compliance Test Tool, e o disponibiliza para membros.

Os Auto Testes so projetados para verificar se um servidor segue as

varias especificaes que compreendem o Padro OPC. Para clientes, a OPC

Foundation fornece o OPC Analyser Client Test Tool, ferramenta que avalia o

nvel de certificao dos clientes.

2.8. Servidor Compliance Test Tool

A OPC Foundation fornece o Compliance Test Tool para servidores.

Fabricantes de servidores realizam o download e executam estes testes para

verificarem a conformidade de seus produtos. Os Testes so realizados na


21

forma de uma aplicao Cliente OPC que foi projetada para executar uma srie

de verificaes pela interoperabilidade com o servidor.

Os testes so desenvolvidos para verificar o comportamento do servidor,

usando parmetros vlidos quando fazem chamadas, e tambm parmetros

invlidos. importante no apenas verificar se o servidor conforme em

condies normais, mas tambm quando o cliente no est se comportando

bem.

O Compliance Test Tool suporta as seguintes especificaes OPC:

OPC Alarm and Events 1.1

OPC Data Access 2.05a

OPC Data Access 3.0

OPC Historical Data Access 1.2

OPC XML Data Access 1.01

Para cada especificao disponvel o Compliance Test Tool suporta as

seguintes possibilidades de testes OPC (OPC TEST LAB SPECIFICATION:

PART 1 CONCEPTS, 2008):

Testes Lgicos Esses testes checam se o Proxy/Stub-DLLs esto

instalados corretamente.

Interface de Testes Esses testes checam os mtodos que fazem parte

das interfaces definidas pela especificao.

Teste de Stress Para algumas especificaes o teste de stress

includo.

A pgina de dilogo que corresponde ao Compliance Test Tool Servidor

pode ser visto na Figura 4:


22

Figura 4 - Pgina de Configurao para o DA Compliance Test Tool


Fonte: OPC FOUNDATION, 2011

Como primeiro passo necessrio selecionar um Servidor DA, este

pode estar localizado em um computador local ou remoto. O servidor

selecionado usado nos testes de interface e stress.

A aba Test Items habilita a definio de identificar um namespace para

cada objeto OPCItem que adicionado durante o teste.

Sob a aba OPCServer esto os itens que so selecionados para os

testes da interface IOPCItemMgt.

Sob a aba OPCGroup, as propriedades do objeto OPCGroup que

sero criadas e o monitoramento de quantidade de vezes para realizao dos

testes so definidas.
23

A aba Stress permite o usurio estabelecer valores padres para o

teste de stress. Esta aba permite determinar quantos objetos OPCServers

podem ser criadas no componente para ser testado.

Os resultados so gravados em um arquivo que pode ser emitido como

um sumrio.

A Figura 5 mostra as informaes fornecidas pelo CTT quando finalizado

os testes.

Figura 5 - Sumrio de resultados de teste servidores DA


Fonte: BURKE;IWANITZ;LANGE,2010
24

3. OPC UA
3.1. Motivao OPC UA

Com a adoo do OPC em milhares de produtos, ele utilizado

atualmente como uma interface padro entre sistemas de automao em

diferentes nveis da pirmide de automao.

Segundo (MAHNKE;LEITNER;DAMM,2009), o OPC Unified Architecture

nasceu do desejo de se criar um verdadeiro substituto para tudo que era

baseado nas especificaes COM, sem perder alguma caracterstica ou

desempenho.

Adicionalmente o OPC deve abranger todos os requisitos para um

sistema de interfaces para plataforma independente, com uma rica e extensa

capacidade de modelamento, sendo hbil para descrever sistemas complexos.

Uma larga srie de aplicaes onde o OPC usado requer escalabilidade,

partindo de sistemas embarcados atravs de SCADA e DCS at sistemas MES

e ERP. A tabela 1 resume os principais requisitos para o OPC UA.

Tabela 1 - Requisitos para o OPC UA

Comunicao entre sistemas


Modelamento de dados
distribuidos
Confiabilidade pela:
Robustez e tolerncia a falhas Modelo comum para todos OPC Data
Redundncia
Plataforma Independente Orientado Objeto
Escalabilidade Tipo de Sistemas Extensivos
Alta performance Dados Complexos e mtodos
Internet e Firewalls Escalabilidade de um modelo simples
25

at um complexo.
Segurana e controle de acesso
Interoperabilidade

Fonte: MAHNKE;LEITNER;DAMM,2009

Segundo, (BURKE;IWANITZ;LANGE,2010), algumas razes motivaram

o desenvolvimento dessa nova gerao, como:

A descontinuao do COM/DCOM.

Limitaes do DCOM.

A necessidade de utilizao do OPC em plataformas No-Windows.

A necessidade de Alto Desempenho em comunicao via Web Services.

A integrao de todas as ferramentas em um modelo unificado.

Suporte a estruturas complexas de dados

Comunicao de dados de processo sem perda

Aumento da proteo contra acessos no autorizados

3.2. OPC UA Viso Geral

Para atingir os objetivos definidos, o OPC Unified Architecture construiu

diversas camadas, como mostra a Figura 6:


26

Figura 6 - A Fundao do OPC UA


Fonte: MAHNKE;LEITNER;DAMM,2009

Os alicerces do OPC UA so o mecanismo de transporte e modelamento

de dados.

O transporte define diferentes mecanismos otimizados para diferentes

casos. A primeira verso do OPC UA possui como definio a utilizao do

protocolo TCP para alto desempenho em comunicao intranet to bem quanto

um mapeamento para aceitar padres internet, como Web Services, XML e

HTTP (OPC UA PART 1 - OVERVIEW AND CONCEPTS 1.01

SPECIFICATION, 2009).

A modelagem de dados define as regras e a base de blocos de

construo necessrios para expor um modelo de informao com o OPC UA,

alm determinar os pontos de entrada no espao de endereos e tipos de

bases usadas para construir uma hierarquia.

Os Servios UA so a interface entre servidores, como fornecedores de

informao, e clientes, como consumidores desta informao. Eles so usados

no mecanismo para troca de dados entre cliente e servidor.


27

Este conceito bsico do OPC UA possibilita que um Cliente OPC UA

acesse as menores partes possveis dos dados, sem a necessidade de

entender integralmente o modelo exposto por um sistema complexo.

A figura 7 apresenta as diferentes camadas dos modelos de informao

definidas pela OPC.

Figura 7 - Camadas Arquitetura OPC UA


Fonte: MAHNKE;LEITNER;DAMM,2009

Para cobrir com sucesso todas as caractersticas conhecidas no OPC Clssico,

modelos de informao para as informaes do processo foram

definidas em cima da base do OPC UA.

Segundo OPC UA PART 1 - OVERVIEW AND CONCEPTS 1.01

SPECIFICATION (2009), os modelos de informao so definidos como:

O DA(Data Access) define os dados especficos de automao, tais como

modelagem de dados analgicos ou discretos e a qualidade do servio.

Todas outras caractersticas do DA so cobertas pela OPC UA base.

Alarm & Conditions (AC) especfica um modelo avanado de gerenciamento

de alarmes e condies de monitoramento.


28

Historical Access (HA) define o mecanismo para acessar dados histricos e

eventos. Programs (Prog) especfica um mecanismo para iniciar, manipular

e monitorar a execuo de programas.

Outras organizaes construram seus modelos em cima da base UA ou do

modelo de informao OPC, expondo suas especficas informaes via

OPC UA. Alguns exemplos podem ser citados, como: o Field Device

Integration (FDI) combinado ao Eletronic Device Description Language

(EDDL), e o Field Device Tool (FDT), ambos usados para descrever,

configurar e monitorar equipamentos, e o CLPopen, como um padro para

linguagens de programao para PLC (MAHNKE;LEITNER;DAMM,2009).

3.3. OPC UA Especificaes

As especificaes do OPC UA so divididas em diferentes partes,

conforme exigido pelo padro IEC. O OPC UA conhecido como o padro IEC

62541. A figura 8 mostra uma viso geral de todas as especificaes, divididas

em Core Specifications e OPC UA Information Models, definindo

respectivamente a base para o OPC UA e o tipo especfico de acesso.


29

Figura 8 - Especificaes OPC UA


Fonte: MAHNKE;LEITNER;DAMM,2009

Segundo (MAHNKE, WOLFGANG; 2009), as duas primeiras partes no

so normativas. O UA Part 1 corresponde ao conceito do OPC UA e o UA

Part 2 descreve as necessidades e os modelos de segurana do OPC UA.

As partes 3 e 4 so as mais importantes para projeto e desenvolvimento

de aplicaes UA, explicando como modelar e acessar as informaes. O

Address Space Model UA Part 3 especfica as construes dos blocos

com as instncias e o tipo de informao para construir o OPC UA Server

Address Space.

Para o Abstract UA Services definido no UA Part 4, representa as

possveis interaes entre os Clientes UA e as aplicaes dos Servidores UA.

O cliente usa o servio para encontrar e acessar as informaes fornecidas

pelo servidor. A Figura 9 apresenta as camadas de comunicao da arquitetura

do OPC UA.
30

Figura 9 - Camadas Arquitetura de Comunicao do OPC UA


Fonte: MAHNKE;LEITNER;DAMM,2009

O Mapeamento do servio de mensagens para o OPC UA, os

mecanismo de segurana aplicados nas mensagens, e o confivel meio de

transporte da mensagem so definidas no UA Part 6. Apenas os

implementadores dos UA Stacks necessitam entender completamente esta

especificao.

A base do Information Model especificado no UA Part 5 fornece o

framework para todos Information Models usando OPC UA.

Os Profiles so definidos como teis subconjuntos de caractersticas

do OPC UA no UA Part 7. Um subconjunto deve ser implantado

completamente pela aplicao UA para garantir a interoperabilidade do

subconjunto definido.

A Especificao define os subconjuntos em dois nveis. O primeiro nvel

so unidades de conformidade definindo um pequeno conjunto de

funcionalidades que so sempre utilizadas juntas e podem ser testadas com o

CTT e verificadas como unidade.

O segundo nvel so perfis compostos por uma lista de unidades de

conformidade. Um perfil deve ser implantado completamente e ser verificado

como um conjunto completo durante a certificao dos produtos OPC UA. A


31

lista de perfis suportados e usados trocada durante o estabelecimento da

conexo entre cliente e servidor, permitindo a aplicao determinar se as

caractersticas necessrias so suportadas pelo parceiro de comunicao.

O modelo de informao DA define como representar e usar dados de

automao e caractersticas especificas como unidade de engenharia no UA

Part 8.

O modelo de informao AC especifica o processo de alarmes e

condio de monitoramento de estados das mquinas e tios de eventos no UA

Part 9.

O modelo de informao Prog define a base do estado da mquina para

a execuo, manipulao, e monitoramento de programas no UA Part 10.

O modelo de informao HA (Historical Access) no UA Part 11

especifica o uso do histrico de servios de acesso e como apresentar

informaes sobre a configurao dos dados e histrico de eventos.

Os valores agregados de dados amostrados so especificados no UA

Part 13 e UA Part 12, definindo como encontrar servidores na rede e como

um cliente pode obter a informao necessria para habilitar e estabelecer a

comunicao para um certo servidor.

3.4. OPC UA Software Layers

O OPC UA usa o conceito similar de cliente-servidor como o OPC

Clssico. Uma aplicao que quer expor sua prpria informao para outras

aplicaes chamada de Servidor UA e uma aplicao que quer consumir

informao de outra aplicao so chamadas de Cliente UA.


32

Uma tpica aplicao OPC UA composta de trs camadas de software

apresentadas na Figura 10.

Figura 10 - OPC UA Camadas de Software


Fonte: MAHNKE;LEITNER;DAMM,2009

O software completo pode ser desenvolvido com C/C++, NET, ou JAVA.

O OPC UA no limitado nestas linguagens de programao e plataformas de

desenvolvimento, mas apenas estes ambientes so usualmente utilizados para

desenvolvimento do OPC Foundation UA.

Uma aplicao um sistema que quer fornecer ou consumir dados via

OPC UA. Contm a funcionalidade especfica para a aplicao e o

mapeamento para o OPC UA, utilizando um OPC Stack e um OPC UA

Software Developing Kit (SDK).

Um Cliente ou Servidor UA SDK desenvolve funcionalidades comuns

que esto na parte da camada de aplicao, assim UA Stacks implementa

apenas o canais de comunicao. Um OPC UA SDK reduz o esforo e facilita o

desenvolvimento da interoperabilidade para uma aplicao do OPC UA.


33

Um OPC UA Stack implanta os Service Mappings definidos no UA

Part 6. Uma Stack usada para realizar Servios UA em limites de processo

ou de rede. O OPC UA define trs camadas de Stack e diferentes perfis para

cada camada.

A camada de codificao da mensagem (Message Serialization) define

a serializao dos parmetros de Servio em formato binrio ou XML. A

camada de Segurana da mensagem (Messsage Security) define como as

mensagens devem estar seguras usando o padro de segurana Web Service

ou uma verso binria do UA padro Web Service.

A camada de transporte (Message Transport) define o protocolo de rede

usado, que pode ser UA TCP ou HTTP e SOAP para Web Servies.

(MAHNKE;LEITNER;DAMM,2009).

A Figura 11 ilustra as camadas de comunicao Stack. O

desenvolvimento das camadas em UA Stack e o API resultante para aplicao

no faz parte da especificao OPC UA.

Figura 11 - Camadas de Comunicao UA Stack definidas no UA Part 6


Fonte: MAHNKE;LEITNER;DAMM,2009
34

Com as implementaes em ANSI C/C#, NET, e JAVA , os principais

ambientes de desenvolvimento e linguagens de programao so cobertas

pelos UA Stacks desenvolvidos e mantidos pela OPC Foundation.

3.5. Compliance Test Tool OPC UA

O OPC UA CTT fornece perfis de testes com base em uma ferramenta

de teste em uma plataforma indepedente (BURKE;IWANITZ;LANGE,2010). O

OPC UA CTT suporta a gerao de resultado de certificao, e tambm

oferece suporte a depurao pelo desenvolvedor. Essa simples ferramenta

pode operar em modo Cliente ou Servidor.

3.5.1. Servidor OPC UA CTT

Quando o projeto de um servidor selecionado, o usurio deve fornecer

algumas informaes de configurao a respeito do servidor, como a URL do

Servidor. Uma vez iniciadas as ferramentas de testes, o usurio apresentado

a uma lista de Perfis. Por padro os Perfis expostos pelo servidor so

checados e a ferramenta pode adicionar perfis adicionais para a lista de testes.

Quando a ferramenta est operando em modo depurao, testes

individuais podem ser selecionados e executados. A ferramenta tambm

permite a realizao do teste passo a passo, permitindo a depurao das

falhas conforme elas ocorrem.

Com a operao em modo certificao todos os perfis configurados

sero automaticamente testados (Figura 12).


35

Figura 12 - Servidor OPC UA CTT


Fonte: BURKE;IWANITZ;LANGE,2010
36

4. Migrao OPC UA
4.1. Viso Geral

OPC UA fornece estratgias de migrao para diferentes necessidades

e nveis de adoo do OPC UA. O primeiro nvel no requer mudanas nos

produtos existentes. Wrappers and Proxies fornecidos pela OPC Foundation

esto disponveis para traduzir diferentes interfaces do OPC Clssico para o

OPC UA e vice-versa. Este nvel apropriado para integrao com a base

instalada de Produtos OPC.

Para Vendedores de Produtos OPC, os outros nveis de migrao so

mais importantes. O segundo nvel usa os mappings, j descritos na seo

3.4, para exibir algumas caractersticas dos produtos existentes com OPC UA.

Isto no requer qualquer mudana sobre as interfaces internas para

informao de acesso a um sistema apresentado como OPC Clssico hoje.

A vantagem sobre os Wrappers a mais alta performance, poucos

limitaes, e menos esforos de manuteno por evitar mais uma camada

adicional de software para o Wrapper. Do ponto de vista do produto, o esforo

no muito mais do que utilizando a integrao de wrappers, considerando

apenas o trabalho de desenvolvimento.

4.2. Wrappers

O OPC UA Wrapper usado para permitir o Cliente OPC UA acessar

Servidores do OPC Clssico. Assim um componente wrapper um Cliente

OPC para um padro OPC Clssico acessando um servidor e ao mesmo


37

tempo o wrapper um Servidor OPC UA permitindo Clientes UA conversem

com o servidor wrapper.

A Figura 13 mostra os componentes de um wrapper UA fornecendo

acesso para um Servidor OPC DA para clientes UA.

Figura 13 - Wrapper UA fornencendo acesso ao Servidor OPC DA


Fonte: MAHNKE;LEITNER;DAMM,2009

O UA DA wrapper desenvolve um servidor UA exibindo UA Endpoints,

permitindo clientes UA acessar os dados de qualquer fornecedor em uma

interface conforme do OPC DA. Uma sesso criada por um cliente UA resulta

na criao de um objeto OPCServer no servidor OPC DA e uma subscrio

items monitorados so mapeados para um OPCGroup com OPCItems.

4.3. Proxies

OPC UA Proxies so usados para permitir clientes OPC Clssico

acessar Servidores OPC UA. Assim um componente Proxy um cliente OPC

UA acessando um Servidor UA e ao mesmo tempo o Proxy o Servidor


38

clssico OPC exposto com uma interface COM, permitindo clientes usar um

padro do OPC Clssico para acessar Servidores OPC UA.

A Figura 14 apresenta os componentes de um Proxy fornecendo acesso

de um Servidor OPC UA para um cliente OPC DA.

Figura 14 - Proxy DA COM fornecendo acesso para um Servidor OPC UA


Fonte: MAHNKE;LEITNER;DAMM,2009
39

5. Sistemas Supervisrios

5.1. Introduo

Segundo (MORAES;CASTRUCCI,2007), Sistemas Supervisrios so

sistemas digitais de monitorao e operao da planta que gerenciam variveis

de processo. Podem ser caracterizados e classificados pela complexidade,

robustez e nmero de pontos (Entrada e Sadas) monitorados. So divididos

basicamente em IHM/HMI(Interface Homem Mquina / Human Machine

Interface) e SCADA(Supervisor Control and Data Acquisition). A IHM situada

normalmente prxima linha de produo, instalada nas mquinas, traduzindo

os sinais vindos dos PLCs para sinais grficos (Figura 15).

Figura 15 - Exemplo de IHM com viso de Processo


Fonte: DIYTRADE,2011

O SCADA foi criado para superviso e controle de quantidades elevadas

de variveis de entrada e sadas digitais e analgicas distribudas (Figura 16).


40

Figura 16 - Exemplo de uma tela de supervisrio para controle e monitorao


Fonte: LIMA,2011

5.2. SCADA

Segundo (ALBUQUERGUE,2007), o sistema SCADA responsvel pela

coleta e transferncia de informaes lgicas e analgicas sobre o estado do

sistema, por sua exibio na sala de controle e pelo comando remoto de

dispositivos.

O SCADA coleta as informaes de processo atravs de uma RTU

(Remote Terminal Unit), transferindo-o de volta para o sistema central,

realizando a anlise necessria e controle e, em seguida, apresentando a

informao sobre uma srie de telas para a operao.

As aes de controle necessrias so levadas de volta para o processo.

Embora inicialmente a RTU seja muitas vezes um dispositivo dedicado, CLPs

so usados frequentemente como RTUs atuais. CLPs e/ou DCS (Distributed


41

Control Systems) so utilizados como mostra Figura 17.

Figura 17 - PC para CLP ou DCS com um Barramento de Comunicao e


sensores
Fonte: BAILEY;WRIGHT,2003

Com a exigncia crescente de sistemas menores e mais inteligentes,

atualmente alguns sensores esto sendo projetados com a inteligncia de

CLPs e DCSs. Esses dispositivos so conhecidos como IEDs (Intelligent

Electronic Devices). Os IEDs so conectados em um fieldbus, tais como

Profibus, DeviceNet ou Fieldbus Foundation para o PC (Figura 18).

Segundo (CLARKE;REYNDERS;WRIGHT,2004) estes sensores incluem

a inteligncia suficiente para adquirir dados, comunicar com outros dispositivos

e realizar controle. Normalmente, um IED pode combinar um sensor de entrada

analgica, sada analgica, controle PID, sistema de comunicao e memria

de programa em um nico dispositivo.


42

Figura 18 - PC para IED usando barramento de comunicao


Fonte: BAILEY;WRIGHT,2003

A comunicao de qualquer sistema SCADA, que a sua principal

funcionalidade, ocorre principalmente com:

Equipamentos de campo

PLCs/RTUs

Outras estaes SCADA

Outros sistemas

Segundo (SILVA;SALVADOR, 2010) os sistemas SCADA geralmente

dividem suas principais tarefas em blocos ou mdulos, que vo permitir maior

ou menor flexibilidade e robustez, de acordo com a soluo desejada. De forma

geral, essas tarefas podem se divididos em:

Ncleo de processamento.

Comunicao com PLCs/RTUs.

Gerenciamento de Alarmes.

Histricos e Banco de Dados.

Lgicas de programao interna (Scripts) ou controle.

Interface grfica.
43

Relatrios.

Comunicao com outras estaes SCADA.

Comunicao com Sistemas Externos / Corporativos.

Outros.

5.2.1. Limites dos sistemas SCADA

As diversas operaes realizadas pelos sistemas SCADA causam a

necessidade de agregao de recursos aos sistemas computacionais.

Segundo NASCIMENTO FILHO (2005), um dos grandes problemas de

relao de custo x benefcio das solues para superviso de sistemas

industriais a utilizao de drivers especficos e proprietrios para

comunicao, pois aumenta o custo de desenvolvimento(Software e

Hardware) e dificulta futuras ampliaes do sistema SCADA.

Essa uma das situaes mais crticas combatidas pelos

sistemas SCADA e que motivaram o desenvolvimento de padres de

interoperabilidade (OPC COMMON DEFINITIONS AND INTERFACES, 1998).

5.3. Elipse E3

Dentre os Sistemas SCADA, o Elipse E3 foi utilizado no trabalho por

suportar as tecnologias COM, DCOM, ActiveX e OPC,e possuir recursos que

facilitam a configurao de servidores OPC, alm de ser uma ferramenta que

possui uma grande quantidade de informaes (Manuais e Tutoriais)

disponveis gratuitamente, auxiliando o rpido entedimento da ferramenta.

De acordo com KICHALOWSKY(2010), o E3 a terceira gerao de

sistemas HMI/SCADA da Elipse Software e representa a evoluo dos


44

tradicionais sistemas cliente/servidor (de duas camadas) para um modelo de

mltiplas camadas (composto de servidores, regras de aplicao ou de negcio

e estaes clientes). O E3 possui interoperabilidade com centenas de

dispositivos atravs da utilizao de drivers proprietrios, desenvolvidos pela

prpria Elipse Software, e OPC (Figura 19).

Figura 19 - Exemplo de arquitetura de uma aplicao E3


Fonte: KICHALOWSKY,2010

O E3 composto por trs aplicativos principais: E3Server, E3Viewer e

E3Studio. Neste trabalho vamos dar um enfoque principalmente no E3 Server.

5.4. E3 Server

Segundo (KICHALOWSKY,2010) e (ALBUQUERGUE,2007) o E3 Server

um servidor de aplicaes, onde so gerenciados os processos de execuo

do software e processada a comunicao entre eles. Dentre as aes operadas

por este componente esto:


45

Envio das informaes grficas e dados para os clientes.

Gerncia dos processos de E/S, comunicao com os diversos pontos de

aquisio.

Controle de licenas.

Cliente e servidor OPC.

Sincronismo de alarmes e bases de dados.

5.5. Elipse Plant Manager

O Elipse Plant Manager (EPM) um software desenvolvido com a

tecnologia OPC UA, e por esse motivo foi escolhido para realizar os testes

com o Wrapper OPC, permitndo o Cliente OPC UA(EPM) acessar Servidores

do OPC Clssico(E3).

De acordo com a ELIPSE SOFTWARE (2011), o EPM uma ferramenta

que atua na coleta de informaes de tempo real ou histricas, como tambm

em sua contextualizao, compactao, disponibilizao e anlise, provendo

uma camada de dados entre o universo de tempo-real e o mundo orientado a

transaes de negcios, finanas e sistemas no campo corporativo.

Com o EPM, os dados obtidos de vrias fontes como controladores de

processo, medidores, SCADAs e SDCDs, podem ser armazenados, por

longos perodos de tempo, de forma compacta, centralizada, segura e tolerante

a interrupes na comunicao, possibilitando que sejam consultados de forma

rpida por diversos tipos de aplicaes.


46

6. REDES INDUSTRIAIS

Segundo (FRANCO;LENARTH,2010), por definio, uma rede industrial

(Figura 20) um sistema de comunicao bi-direcional em tempo real que

permite a troca de informao digital entre os dispositivos de nvel de campo e

os dispositivos de monitoramento e controle.

Figura 20 - Exemplo de Rede Industrial


Fonte: FRANCO;LENARTH,2010

Essas redes so mais robustas se comparadas com redes de

computadores, tanto com relao ao cabeamento, devido necessidade de se

ter uma maior proteo a rudos, quanto conectores mais forte e resistente.

Em sua maioria, as redes industriais so determinsticas, ou seja,

realizam a comunicao em tempos pr-estabelecidos, e requerem as

respostas e atualizaes em tempo real.

Um exemplo de rede industrial protocolo Modbus, que ser descrito no

prximo sub item.


47

6.1. MODBUS

O Modbus foi originalmente desenvolvido pela Modicon, e hoje,

gerenciado pela Modbus-IDA User Organization. um protocolo aberto,

baseado no modelo Mestre/Escravo. Neste modelo os escravos no podem

dialogar entre si, e todo controle e informao devero ocorrer no mestre,

sendo possvel o mestre requisitar apenas uma mensagem particular a algum

escravo ou para todos os escravos da rede.

O Modbus pode ser utilizado com diversas camadas fsicas, e est

situado na camada de apresentao e aplicao do Nvel do modelo OSI. Ele

permite uma comunicao cliente/servidor de equipamentos conectados entre

diferentes tipos de barramentos ou redes.

O Modbus-TCP siginifica que o protocol Modbus usado sobre a

camada Ethernet-TCP/IP (Figura 21). O Modbus-TCP uma Rede Industrial

Ethernet aberta, que foi especificada pela Modbus-IDA User Organization com

a cooperao da Internet Engeneering Task Force (IETF).

Figura 21 Modbus sobre TCP/IP


Fonte: HMS ANYBUS,2011

O Modbus possui uma gama de produtos adicionais, que agora


48

consistem no clssico Modbus-RTU (via RS-232 or RS-485), Modbus-Plus

(Comunicao Alta Velocidade via Token Passing) e o Modbus-TCP (Ethernet-

TCP/IP- baseado na comunicao cliente/servidor). Todas estas verses

compartilham o mesmo protocolo de aplicao, que especifica um mdulo

universal para dados do usurio e servios de comunicao.


49

7. DESENVOLVIMENTO SERVIDOR OPC DA E UA


7.1. Ambiente de desenvolvimento

Para desenvolver os servidores OPC DA e UA foi necessrio o uso de

ferramentas de programao de alto nvel. No caso do desenvolvimento

das classes modularizadas nos subsistemas de comunicao e

tratamento de protocolo, assim como no acesso ao banco de dados foi

utilizado o MS Visual Studio. Essa ferramenta oferece possibilidade de

programao na linguagem C#, essencial para o desenvolvimento de cada

mdulo utilizado nos servidores, alm de se integrar com a ferramenta

automatizada de gerao de interfaces OPC. O banco de dados utilizado para

o armazenamento e a definio do Address Space foi o MySQL 5.0.

7.2. Toolkit de criao de interfaces

Sistemas que seguem o padro OPC podem ser criados tanto

diretamente por programadores experientes nas tecnologias adotadas por

esses padres quanto atravs de ferramentas que automatizam parte da

codificao.

Vrios toolkits foram utilizados, sem perda da generalizao dos

passos definidos para o desenvolvimento de servidores OPC, dentre os quais

o da empresa Softing, da Northern Dynamic (SLIK-DA) e da prpria OPC

Foundation.

Assim como os demais, esses toolkits devem ser instalados sobre o

sistema operacional Microsoft Windows, onde j se encontre instalado


50

anteriormente o MS Visual Studio. Aps sua instalao, adicionada a opo

de criao de servidores OPC entre as solues possveis para

desenvolvimento. Caso essa opo seja escolhida, o toolkit apresenta um

wizard para a definio de algumas caractersticas relevantes na

implementao de um servidor OPC. Essas telas requerem que algumas

decises sejam tomadas sobre o tipo de servidor OPC que se deseja

desenvolver. Todo o cdigo de interfaces gerado automaticamente, com

seus mtodos vazios. Dessa forma, pode-se partir para o passo de

escolha de componentes existentes com o foco na remoo daqueles que

no se mostrarem necessrios.

A seguir ser apresentado um passo a passo para o desenvolvimento de

Servidores OPC baseados em Toolkits, o mtodo apresentado foi utilizado para

o desenvolvimento do servidor com o toolkit da empresa MatrikonOPC(SLIK-

DA), porm este mtodo pode ser estendido aos toolkits da empresa Softing

OPC e da prpria OPC Foundation.

Para o desenvolvimento do OPC Server, aps instalao do toolkit deve-

se iniciar um novo Projeto no Visual Studio.


51

OPC Server

Figura 22 Criao de um novo Projeto


Fonte: SLIKDA Tutorial

Com o novo projeto aberto deve-se inserir o toolkit do OPC Server ao

programa, para isso o desenvolvedor selecionar o local onde gostaria de

adicionar o componente(toolkit) e criar a sua Categoria, por exemplo OPC

Server. Posteriormente necessrio selecionar os itens que integram

ferramenta (Figura 25).

OPC Server

Figura 23 Seleo de Itens para o toolbox


Fonte: SLIKDA Tutorial

Para seleo dos itens, abra a pasta onde o toolkit foi instalado,

direcione-se a pasta Redistributables e selecione o driver ligado a


52

interoperabilidade do servidor, neste caso o arquivo Interop.NDISLIKDA.dll

(Figura 24). Se houver alguma dvida com relao escolha do driver correto,

verifique o tutorial/manual do desenvolvedor do toolkit.

Figura 24 Seleo do driver


Fonte: SLIKDA Tutorial

Posteriormente, selecione o toolkit instalado para compor o toolbox do

Visual Studio(Figura 25).


53

Figura 25 Seleo do driver Toolbox Items


Fonte: SLIKDA Tutorial

Aps a correta insero do toolkit como um componente/toolbox do

Visual Studio deve-se abrir uma Form do programa e adicionar o cone do

referente ao toolkit no novo projeto.

Figura 26 Insero do Icone SLIK-DA na Form


Fonte: SLIKDA Tutorial

Neste momento necessrio ajustar as propriedades do toolkit,

identificando OPC Server atravs do Class ID (CLSID), que por sua vez um

nome alfanumrico nico que identificara o OPC Server. Para obter esta

identificao necessrio apenas localizar a propriedade CLSID e escolher

AutoGenerate.
54

Figura 27 Identificao do CLSID


Fonte: SLIKDA Tutorial

Aps selecionar AutoGenerate ser gerado um nmero alfanumrico

nico para identificao do servidor. O mesmo procedimento dever ser

executado para criar uma identificao para Aplicao, o Application ID -

AppID.

Para finalizar a identificao do OPC Server necessrio abrir o cdigo

fonte Form e definir a identificao de algumas propriedades, como as citadas

abaixo:

ProgID = Este o nome do servidor que os usurios vero

quando se navega uma lista de servidores disponveis OPC em

seu computador.

AppName = Este o nome do OPC Server

Description = Descrio bsica do Servidor

VendorName = Nome do desenvolvedor ou companhia

Posteriormente necessrio registrar o Servidor no Windows,

justamente para ele ser visto pelos Clientes OPC, fazendo isso atravs de um
55

parmetro de linha de comando.

Esse mtodo de registro escolhido para evitar o registro/cancelamento

do servidor OPC cada vez que o software aberto ou fechado. Isso impede

que o servidor seja usado por clientes OPC enquanto o servidor no est

funcionando. Portanto, necessrio registrar o servidor atravs de um

parmetro de linha de comando uma vez. Da mesma forma, o servidor pode

cancelar seu registro atravs do parmetro de linha de comando.

Um exemplo da linha de comando utilizada apresentado na figura 28.

Figura 28 Exemplo de linha de comando


Fonte: SLIKDA Tutorial

Neste momento realizada a compilao do programa para gerar um

arquivo executvel. Aps essa etapa deve-se atualizar o registro do servidor,

para isso deve-se ir para o menu iniciar do Windows e clique em executar,


56

navegue e selecione o arquivo executvel que acabou de ser criado, como

exemplificado na figura 29.

Figura 29 Busca do arquivo executavel criado


Fonte: SLIKDA Tutorial

Para registrar o servidor necessrio adicionar uma linha de comando

para registra-lo, neste caso utiliza-se regsserver(Figura 30), se for necessrio

retirar o registro pode-se utilizar unregserver. Para finalizar este processo

clique em OK.

Figura 30 Resgistro do Servidor


Fonte: SLIKDA Tutorial

Para verificar se o Servidor OPC est instalado no servidor pode-se

testar utilizando um OPC Cliente e buscar pelos servidores disponveis no

computador.

Aps instalao do Servidor necessrio configurar as tags que o

servidor OPC vai expor ao pblico, para isso criada uma linha de comando
57

para Criar as tags. Um exemplo da linha de comando que pode ser utilizada

para criar as tags apresentado na figura 31.

Figura 31 Criao de Tags


Fonte: SLIKDA Tutorial

Da mesma forma utilizada anteriormente, para verificar se as tags foram

realmente criadas pode-se testar utilizando um OPC Cliente e buscar pelas

tags criadas.

Neste ponto no podemos escrever ou ler as tags, elas esto

simplesmente sendo expostas, para ser possvel a realizao da leitura das

tags necessrio adicionar uma linha de comando adicionando um script de

tratamento(Figura 32). Este evento disparado quando um cliente OPC solicita

ler algum dispositivo (IOPSyncIO :: Read ()) com qualquer nmero de Tags.

Portanto, este evento abriga uma coleo de tags que sero passados de volta

diretamente para o cliente. Da mesma forma necessrio criar um script para

realizar a escrita nas tags.


58

Figura 32 Criando um procedimento para leitura das tags


Fonte: SLIKDA Tutorial

Apesar de fornecidos por empresas que se esmeram na confeco de

seus sistemas, os toolkits no oferecem garantia de conformidade com o

padro OPC. Dessa forma, necessrio que se usem ferramentas de teste

de conformidade independente do uso ou no de toolkits na gerao de um

servidor OPC.

7.3. Testes dos servidores

Para garantir que os servidores realizem as funes propostas no

padro OPC, necessrio verificar sua correta adequao s especificaes.

necessrio realizar testes que validem as interfaces de comunicao

atravs de ferramentas especficas, desenvolvidas pelo OPC Foundation.

Tambm necessrio garantir a qualidade do desenvolvimento realizado

com o fim de recuperar dados e enviar comandos para os equipamentos de

campo. Nesse caso, no suficiente o uso de ferramentas automatizadas,

mas sim o uso de sistemas supervisrios comerciais junto soluo, de

forma a verificar se a os resultados alcanados podem ser utilizados em

ambiente industrial. Neste trabalho foi utilizado o Elipse E3.


59

Para aquisio de dados em campo e interfaceamento com o sistema

supervisrio foram utilizados mdulos de aquisio de dados da Advantech -

ADAM (Advantech Acquisition Modules). A escolha desses mdulos foi

baseado nas seguintes caractersticas (FRANCO;LENARTH,2010):

Compatveis com o Padro OPC.

Comunicam-se com padres abertos RS 485, Ethernet,

Modbus ou sem fio.

Compatveis com softwares abertos de desenvolvimento

(Visual Basic, Visual C,..).

Compatveis com softwares proprietrios (Intouch, Elipse, FIX,

...)

7.4. Ambiente de testes

Os testes foram realizados utilizando-se um computador ligado em

rede, MODBUS TCP, com os mdulos de Automao da empresa Advantech

ADAM. Foram utilizados os mdulos ADAM 5510/TCP (Controlador

Programvel), ADAM 6018 (Mdulo de Entrada Termopar com 8 sadas

digitais) e o ADAM 5055S (Mdulo de 16 I/O Digitais), alm de um Termopar

Tipo J (0 a 200C). O banco de dados, o supervisrio Elipse E3 e as

ferramentas de checagem de conformidade foram instalados no

computador (Figura 33 e 34). O Elipse E3 foi utilizado para supervisionar os

resultados provenientes do servidor OPC DA. e OPC UA.


60

HMI - SCADA

Elipse E3

ADAM-5510/TCP
ADAM-6018
4-slot PC-based Controller
with Ethernet 8-ch Isolated
Thermocouple Input
Modbus TCP Module with
8-ch DO
.
Figura 33 - Ambiente de Testes
Fonte: Elaborado pelo Autor

Figura 34 - Ambiente de Testes - Real


Fonte: Elaborado pelo Autor
61

7.5. Testes de conformidade

Os testes de conformidade (Compliance Test) fornecem a segurana

sobre a adeso do servidor desenvolvido ao padro OPC. Isso garante

que o sistema se comunicar adequadamente com sistemas supervisrios

que ofeream clientes no padro OPC. O objetivo averiguar se as

interfaces criadas so adequadas para o fim proposto.

Para realizao desses testes necessria uma srie de ferramentas

fornecidas pela OPC Foundation. Essas ferramentas trabalham sobre o

servidor criado, permitindo averiguar quais interfaces no responderam de

acordo com o padro definido de respostas.

Para configurar o CTT necessrio definir os parmetros de teste que

devero ser utilizados, de forma geral o CTT j possui alguns parmetros

default que podem ser alterados conforme necessidade do desenvolvedor.

Neste trabalho foram utilizados todos os parmetros default.

Na aba General alm de buscar o servidor, defini-se tambm o nmero

de testes que devem ser realizados, o nmero de testes em paralelo em cada

operao e a frequncia em que os casos de teste sero executados. Neste

trabalho foram utilizadas as configuraes apresentadas na Figura 35.


62

Figura 35 Configurao Aba General CTT


Fonte: Elaborado pelo Autor

Na aba OPC Server defini-se os itens que devem ser usados no teste

da interface do IOPCItemProperties, o nmero mnimo de LocaleIDs

suportados, se o servidor no suporta o nmero de LocaleIDs so

apresentadas falhas durante a execuo, alm disso definido tambm o

nmero de grupos criados para o teste. Neste trabalho foram utilizadas as

configuraes apresentadas na Figura 36.


63

Figura 36 Configurao Aba OPC Server CTT


Fonte: Elaborado pelo Autor
Na aba OPC Group defini-se os ItemID invlidos para o testes de erro,

e o nmero de segundos de espera para o Callback. Neste trabalho foram

utilizadas as configuraes apresentadas na Figura 37.

Figura 37 Configurao Aba OPC Group CTT


Fonte: Elaborado pelo Autor
64

Na aba Stress so definidos o nmero de objetos que so criados para

o testes de Stress, o nmero de grupos que so adicionados em cada objeto e

o nmero de itens que so adicionados em cada objeto. Neste trabalho foram

utilizadas as configuraes apresentadas na Figura 38.

Figura 38 Configurao Aba Stresss CTT


Fonte: Elaborado pelo Autor

Na aba Performance so definidos o nmero de itens que so usadas

para o mtodo de chamadas, a base de tempo em que os mtodos especiais

devem ser chamados e o nmero de chamadas que cada mtodo deve ser

chamado. Neste trabalho foram utilizadas as configuraes apresentadas na

Figura 39.
65

Figura 39 Configurao Aba Performance CTT


Fonte: Elaborado pelo Autor

Durante os testes realizados com o Servidor OPC DA (Figura 40),

verificou-se que trs funcionalidades da interface gerada apresentaram falhas

durante os testes. As funcionalidades com problemas foram o

IOPCBrowseServerAddressSpace e o IOPCItemProperties do

OPCServerObject e o IOPCGroupStateMgt, do OPCGroupObject.

O IOPCBrowseServerAddressSpace uma interface opcional que

fornece uma maneira para os clientes procurarem os itens de dados

disponveis no servidor, dando ao usurio uma lista de definies vlidas para

um Id Item. Ela fornece um espaos de endereos (Lista ou com hierarquia) .

A apresentao hierrquica do espao de endereo do servidor se comporta

como um sistema de arquivos, onde os diretrios so os ramos ou caminhos, e

os arquivos representam os itens. Um exemplo, seria um servidor apresentar

um sistema de controle, mostrando todas as redes de controle, posteriormente

todos os dispositivos na rede selecionada e todas as classes de dados dentro


66

de um dispositivo, em seguida, todos os itens de dados da classe. A falha

estava na lgica de movimentao desses espaos de endereos

hierrquicos, o que provocava travamentos no servidor.

O IOPCItemProperties uma interface utilizada por clientes para

verificar as propriedades disponveis (atributos ou parmetros) associada a um

ItemID e ler os valores atuais dessas propriedades, Esta interface baseada

no pressuposto que um ItemID muitas vezes est associado com outros

ITEMIDs , que representam os valores relacionados, unidades de Engenharia

(controladores PID, temporizadores,...) ou descrio de alarme (Alarme

deLimite Baixo ou Alto, ...), a falha estava na adio de Items, o que causava

falha do servidor.

O IOPCItemMgt permite que um cliente adicione, remova e controle o

comportamento de itens em um grupo, a falha na lgica ocorria quando um

cliente tentava adicionar um novo item ao grupo.

Figura 40 - CTT Servidor OPC DA Desenvolvido


Fonte: Elaborado pelo Autor
67

Para o CTT OPC UA um "container" de livrarias de scripts de teste. Cada

scripts de teste pode ser individualmente executado para uma funcionalidade

especfica do OPC UA. A importncia dos testes provar que o produto

(Cliente ou Servidor) atende as especificaes do OPC UA. Principalmente as

seguintes especificaes:

OPC UA specifications (Parte 4)

o Especfica os Servios fornecidos pelos servidores do OPCUA.

OPC UA Profile (Partes 7 e 8)

o Parte 7 Introduz o conceito de perfil e define perfis disponveis

que so grupos de servio ou funcionalidade.

o Parte 8 Especfica o uso do OPC UA para Data Access.

Durante os testes realizados com o Servidor OPC UA (Figura 41), foram

verificadas vrias falhas inicialmente, desde endereamento da url at

travamento no servidor. Porm, a grande vantagem do CTT UA a

apresentao clara das falhas no prprio cdigo realizado, auxiliando a

correo.
68

Figura 41 - CTT Servidor OPC UA Desenvolvido


Fonte: Elaborado pelo Autor

7.6. Testes com clientes

Os testes com os servidores foram feitos inicialmente a partir da

simulao de comunicaes cliente/servidor, realizada por aplicaes clientes

fornecida para testes pela Softing e OPC Foundation (Figura 42).


69

Figura 42 - Exemplo Cliente OPC Softing


Fonte: Elaborado pelo Autor

Os clientes foram instalados no PC para verificar a funcionalidade

de identificao do servidor OPC DA e OPC UA (Figura 43). No foram

encontrados problemas relacionados a essas funcionalidades, pois j haviam

sido realizados os testes de conformidade.


70

Figura 43 - Servidor OPC UA e OPC DA


Fonte: Elaborado pelo Autor

Posteriormente foi criada uma interface de superviso e controle no

Elipse E3 (Figura 44), realizada a configurao do Elipse E3 para

comunicao com o Servidor OPC (Figura 45) desenvolvido, e posteriormente

realizado os testes da aplicao em tempo real.


71

Figura 44 - Interface desenvolvida


Fonte: Elaborado pelo Autor

Figura 45 - Elipse E3 - Configurao OPC


Fonte: Elaborado pelo Autor
72

8. DESENVOLVIMENTO WRAPPER OPC


8.1. Ambiente de desenvolvimento

Para desenvolver os sistemas foi necessrio o uso de ferramentas de

programao de alto nvel como descrito no capitulo anterior. Da mesma forma

foi utilizado o MS Visual Studio, essencial para o desenvolvimento de cada

mdulo utilizado nos Wrappers, Para o desenvolvimento do Wrapper OPC foi

utilizado um toolkit padro, fornecido pela OPC Foundation.

8.2. Ambiente de testes

Os testes foram realizados acrescentando-se o software Elipse Plant

Manager EPM ao conjunto apresentado no capitulo 8.4 (Figura 46).

Elipse Plant Manager

Elipse E3

ADAM-5510/TCP
ADAM-6018

Figura 46 - Ambiente de Testes com EPM


Fonte: Elaborado pelo Autor

O EPM foi utilizado para aquisitar os resultados provenientes do servidor


73

OPC DA (Desenvolvido), proveniente da ELIPSE E3, e ser entendido por um

OPC UA Cliente que representado pela EPM. Para isso foi desenvolvido o

OPC Wrapper, permitindo clientes UA acessar os dados de qualquer

fornecedor em uma interface padro de OPC DA Clssico.

8.3. Testes Wrapper OPC

Com o desenvolvimento do Wrapper OPC foi criada uma interface de

superviso no Elipse EPM (Figura 49), realizada a configurao do Elipse EPM

para comunicao com o Servidor OPC DA Wrapper (Figura 47) desenvolvido,

e posteriormente realizado os testes da aplicao em tempo real.

Figura 47 - EPM Configurao OPC


Fonte: Elaborado pelo Autor

Na caixa de seleo Type, deve-se selecionar o tipo de Interface de

Comunicao OPCDA, o campo Publishing Interval corresponde ao intervalo

de tempo antes do qual no sero recebidos dados do Servidor OPC-DA.

Finalizando essa configurao deve-se clicar em Next (Tutorial Elipse Plant

Manager, 2011). Na Janela Interface, mas especificamente na caixa de


74

listagem aparecero todos os Servidores disponveis no computador local.

Wrapper.OPCSvr

Figura 48 - EPM Configurao Interface OPC


Fonte: Elaborado pelo Autor

Uma vez instalada e configurada a Interface de Comunicao com um

Servidor, preciso definir as Tags que estaro vinculados a ela. Aps criada a

Interface, necessrio tambm selecionar o servidor ou servidores E3 ou

Elipse Power que sero monitorados.


75

Figura 49 - EPM Desenvolvido


Fonte: Elaborado pelo Autor

Algumas falhas ocorreram durante os testes, uma delas foi o travamento

do servidor OPC Wrapper, devido principalmente a uma falha na lgica do OPC

Wrapper, na comunicao entre o Monitored Items e OPC Items.

Outro ponto de falha foi o atraso na aquisio de dados e monitoramento

de dados devido s falhas de configurao do EPM. Porm, a grande

vantagem do CTT UA a apresentao clara das falhas no prprio cdigo

realizado, auxiliando a correo das falhas presentes no Wrapper.

9. CONCLUSES

Inicialmente foi realizado um estudo sobre a tecnologia do OPC Clssico

e UA, alm de esclarecer conceitos relevantes para o desenvolvimento de

servidores, bem como os testes necessrios.

Foram desenvolvidos Servidores OPC DA e UA com uma comunicao

confivel para aquisio de informaes, disponibilizando-as de forma

padronizada, conforme especificaes da OPC foundation, garantida pelos


76

testes realizados utilizando o CTT. Para uma aplicao comercial os servidores

desenvolvidos devero passar por uma homologao da OPC Foundation, em

seus laboratrios.

Durante o desenvolvimento do servidor OPC DA fica ntido uma

facilidade, devido grande quantidade de toolkits disponveis para o

desenvolvimento e a maturidade da tecnologia utilizada. Os toolkits possuem

a caracterstica de um toolbox, possuindo um conjunto de funes/blocos que

facilitam a o desenvolvimento das linhas de comando.

A ampliao do OPC UA entre os servidores de dados, as vantagens

associadas interoperabilidade UA junto com a criao de novas

ferramentas de apoio ao desenvolvimento, e uma melhor definio das

questes de segurana, item que no foi abordado nesse trabalho, mas que

de grande relevncia far desse padro a melhor soluo para uso na

indstria.

Foi desenvolvido um Servidor Wrapper capaz de intermediar a

comunicao entre as duas tecnologias OPC, realizando o acesso a um

Servidor COM atravs de um Cliente UA, Porm a interface apresentou

inicialmente um funcionamento instvel, devido a falhas na configurao e

implantao, principalmente no incio dos testes. Porm, utilizando o CTT UA

foi possvel corrigir o cdigo, auxiliando a correo das falhas presentes no

Wrapper.

Com este trabalho foi realizado uma integrao em todos os nveis da

pirmide da Automao, deste do nvel de campo at o nvel de controle e

superviso. Visualizando na prtica todos os conceitos tericos envolvidos,

bem como dificuldades inerentes a atividades prticas, onde novos caminhos e


77

desafios so trilhados a cada novo passo do projeto, e que por muitas vezes

ultrapassa o meio acadmico, principalmente na aquisio de hardwares

(Instrumentao, Contralador e Mdulos de Aquisio de Dados),e pedidos de

doao de softwares(OPC Foundation).

Este trabalho permitiu unir todo o conhecimento tcnico adquirido

durante o curso experincia prtica, visualizando claramente as dificuldades

enfrentadas durante o cotidiano no desenvolvimento de projetos, desde o

desafio tcnico at as questes financeiras e burocrticas.

Para trabalhos futuros aprimoramentos sero realizados na interface

OPC Wrapper e tem-se como sugesto o desenvolvimento de um Servidor UA

Hbrido, com o objetivo de incorporar o Wrapper e Proxy no prprio Servidor

UA, retirando um componente adicional entre um cliente OPC (UA or DCOM) e

um Servidor OPC (DCOM ou UA). Esta adio eliminaria um possvel ponto de

falha, que a transio do cliente/servidor com o Wrapper/Proxy, aumentando

a segurana, reduzindo as fontes de erro alm de garantir a interoperabilidade

da tecnologia OPC.
78

REFERNCIAS

ABDMOULEH, A.; SPADONI, M.; VERNADAT, Franois; Distributed


client/server architecture for CIMOSA-based enterprise components,
Computers in Industry, 2004.

ALBUQUERGUE, Pedro Urbano Braga de; Redes industriais: Aplicaes em


Sistemas Digitais de Controle Distribuido, Edies Livro Tcnico, Fortaleza,
2007.

BAILEY, David; WRIGHT, Edwin; Practical SCADA for Industry, Newnes an


imprint of Elsevier, Great Britain, 2003.

BOYER, S. A., SCADA: Supervisory Control and Data Acquisition, ISA


Books, 2004.

BURKE, J. Thomas; IWANITZ, Frank; LANGE, Jurgen; OPC From Data


Access to Unified Architecture, 4 Rev. Ed., VDE VERLAG GMBH, Berlin
Offenbach, 2010.

CLARKE, Gordon; REYNDERS, Deon; WRIGHT, Edwin; Practical Modern


SCADA Protocols: DNP3, 60870.5 and Related Systems, Newnes An imprint
of Elsevier, Great Britain, 2004.

DIYTRADE, Global B2B Trading Platform. Disponvel em:


<http://www.diytrade.com/china/4/products/7471320/Allen_Bradley_Panel_View
_1000.html>. Acesso em: 11 dez. 2011.
79

ELIPSE SOFTWARE, Elipse Plant Manager Descrio,,


http://www.elipse.com.br/produto_texto.aspx?id=22&opcao=101&idioma=1 ,
acessado em novembro de 2011.

FRANCO, Lcia R. H.; LENARTH, Luiz; Curso de Redes Industriais FUPAI


Fundao de Pesquisa e Assessoramento Indstria de Itajub. Itajub
MG - Brasil, Setembro de 2010.

HMS ANYBUS, Modbus-IDA Ethernet TCP/IP Protocol. Disponvel em: <


http://www.hms.se/technologies/modbustcp.shtml>. Acesso em: 11 dez. 2011.

IWANITZ, F.; Lange, J.; OPC Fundamentals, Implementation, and


Application, 2 Ed., Hthig Verlag Heidelberg, 2002
KICHALOWSKY, Marco Andrei, E3 - Uma viso geral, Elipse Software,
http://kb.elipse.com.br/pt-br/questions/40/E3+-+Uma+vis%C3%A3o+geral, 17th
of December, 2010.

LIMA,Samir; Arquitetura de Sistemas de Superviso, Elipse Software


Disponvel em: <www2.fc.unesp.br/wes/materias/IV/elipse.ppt>, Acesso em: 11
dez. 2011.

MAHNKE, Wolfgang; LEITNER, Stefan-Helmut; DAMM, Matthias; OPC Unified


Architecture, Ed. Springer - Verlag, Berlin Heidelberg, 2009.

MORAES, Ccero Couto De; CASTRUCCI, Plnio De Lauro; Engenharia De


Automao Industrial, LTC - Livros Tcnicos e Cientficos Editora, 2 Ed, Rio
de Janeiro, 2007.

NASCIMENTO FILHO, Osmar A., Desenvolvimento de Servidores OPC DA


e OPC XML DA para Sistemas de Aquisio de Dados via Telefonia
Celular, Vitria, 2005.
80

OPC COMMON DEFINITIONS AND INTERFACES, Version 1.0,OPC


Foundation, October 1998.

OPC DATA ACCESS CUSTOM INTERFACE STANDARD ,Version 2.05A,


OPC Foundation, June 2002.

OPC DATA ACCESS CUSTOM INTERFACE STANDARD, Version 3.00, OPC


Foundation, March 2003.

OPC TEST LAB SPECIFICATION: PART 1 CONCEPTS, OPC Foundation,


January 2008.

OPC TEST LAB SPECIFICATION: PART 2 ABSTRACT TEST SUITE, OPC


Foundation, January 2008.

OPC TEST LAB SPECIFICATION: PART 3 TEST LAB REALIZATION, OPC


Foundation, January 2008.

OPC TEST LAB SPECIFICATION: PART 4 CERTIFICATION PROCESS,


OPC Foundation, January 2008.

OPC UA PART 1 - OVERVIEW AND CONCEPTS 1.01 SPECIFICATION, OPC


Foundation, February 2009.

OPC UA PART 2 SECURITY MODEL 1.01 SPECIFICATION, OPC


Foundation, February 2009.

OPC UA PART 3 ADDRESS SPACE MODEL 1.01 SPECIFICATION, OPC


Foundation, February 2009.
81

OPC UA PART 4 SERVICES 1.01 SPECIFICATION, OPC Foundation,


February 2009.

OPC UA PART 8 DATA ACCESS 1.01 SPECIFICATION, OPC Foundation,


February 2009.

OPC FOUNDATION; Compliance Test Tool CTT; GUI Verso: 2.15.0.1152,


CTT Data Control Verso: 2.00.15.1152, OPC Data Access 2.05a Compliance
Test Verso 2: Test Control Verso: 2.00.20.1156 e Test Settings Verso:
2.20.0.1156, 2011.

RIEDL, M.; THRON, M.; HADLICH, T., DriveServer - Significantly


reduce in engineering expense, IECON'01: The 27th Annual Conference
of the IEEE Industrial Electronics Society, 2001.

SLIK-DA Tutorial, Creating a simple server in Visual Studio, Software Toolbox.


Disponvel:<http://support.softwaretoolbox.com/ci/fattach/get/34384/130512224
4/redirect/1/session/L2F2LzEvdGltZS8xMzM1MjMzMzcyL3NpZC9DZDdvY3BX
aw==/filename/SLIK-DA%20VS2008.pdf>. Acesso em: 23 abril. 2012.

PLSIL, F., STAL, M., An architecture view of distributed objects and


components in CORBA, Java RMI and COM/DCOM, Software Concepts &
Tools, n. 19, p. 14 28, 1998.

SILVA, Ana Paula Gonalves da; SALVADOR, Marcelo; O que so sistemas


supervisrios?,, 21st of December, 2010.

TANENBAUM, A. S., Computer Networks, Prentice Hall, 4 Ed., 2003.


82

TUTORIAL ELIPSE PLANT MANAGER, Elipse Software, Ver. 1.0 ,05 de


Outubro de 2011.

Vous aimerez peut-être aussi