Sistema Integrado de Monitoreo Fieldbus para Procesos de Medición en La Industria Petrolera

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA QUMICA
PROGRAMA DE RECURSOS HUMANOS DA AGNCIA NACIONAL DO PETRLEO
Sistema Integrado de Monitoramento de Instrumentos

em Rede Foundation Fieldbus para Melhoria dos
Processos de Medio e Controle na Indstria do
Petrleo
Jeferson Ribeiro dos Santos Jnior - GRA

Orientador(a): Jorge Dantas de Melo
Co-Orientador(a): Adrio Duarte Dria Neto
Maro/2008
U NIVERSIDADE F EDERAL DO R IO G RANDE DO N ORTE
C ENTRO DE T ECNOLOGIA
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE P ROGRAMA DE G RADUAO EM E NGENHARIA DE C OMPUTAO
Sistema Integrado de Monitoramento de

Instrumentos em Rede Foundation Fieldbus
para Melhoria dos Processos de Medio e
Controle na Indstria do Petrleo
Jeferson Ribeiro dos Santos Jnior
Orientador: Prof. Dr. Jorge Dantas de Melo
Co-orientador: Prof. Dr. Adrio Duarte Dria Neto
Relatrio de Estgio Supervisionado apre-

sentado ao Programa de Graduao em En-
genharia de Computao da UFRN (rea de
concentrao: Automao e Sistemas) como
parte dos requisitos para obteno do ttulo
de Engenheiro de Computao.
Natal/RN, 14 dezembro de 2007

Resumo
O presente trabalho tem o objetivo de apresentar o projeto e a implementao de um

mdulo adicionado ao sistema supervisrio da planta LAMP, o qual permitir o armazena-
mento, anlise e gerao de relatrios das variveis monitoradas, no qual sero utilizadas
em projetos do prprio laboratrio, cuja comunicao tem como base o protocolo Foun-
dation Fieldbus . So descritos os procedimentos utilizados para o desenvolvimento de
aplicaes industriais em tempo real na rea de monitoramento de processos. Toda apli-
cao foi validada a partir da execuo de testes reais e observao do funcionamento da
aplicao, sendo analisado seu desempenho tanto para o problema de armazenamento de
dados quanto para o de comunicao.
Sumrio
Sumrio i
Lista de Figuras iii
Lista de Tabelas iv
1 Introduo 1
1.1 Sistemas de Automao Industrial . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Breve Retrospecto . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Nveis de Hierarquia em Sistemas de Automao . . . . . . . . . 3
1.2 Objetivos e Localizao do Trabalho . . . . . . . . . . . . . . . . . . . . 4
1.3 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Fundamentao Terica 6
2.1 Comunicao entre Processos Industriais Protocolo Foundation Field-
bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Caractersticas da Tecnologia . . . . . . . . . . . . . . . . . . . 6
2.1.2 Camada Fsica . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Camada de Comunicao . . . . . . . . . . . . . . . . . . . . . . 8
2.1.4 Camada do Usurio . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 OLE For Process Control - OPC . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Histrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Interfaces de Acesso ao Servidor . . . . . . . . . . . . . . . . . . 11
2.2.3 Aspectos Prticos para Utilizao do Padro OPC . . . . . . . . . 12
2.3 Sistemas Supervisrios . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Componentes Fsicos de um Sistema de Superviso . . . . . . . . 17
2.3.2 Componentes Lgicos de um Sistema SCADA . . . . . . . . . . 18
2.3.3 Modos de Comunicao . . . . . . . . . . . . . . . . . . . . . . 19
2.3.4 Sistema Supervisrio Elipse SCADA . . . . . . . . . . . . . . . 19
2.4 Sistema Gerenciador de Base de Dados Relacional PostgreSQL . . . . . 22
i
3 Proposta de Implementao 24
3.1 Problemtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 Estrutura Disponvel . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Projeto e Implementao do Banco de Dados . . . . . . . . . . . . . . . 25
3.3 Criao do Sistema Supervisrio . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Telas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2 Funcionamento em Background . . . . . . . . . . . . . . . . . . 30
3.3.3 Comunicao Supervisrio X Banco de Dados . . . . . . . . . . 34
3.4 Validao do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.1 Configurao de Rede Foundation Fieldbus . . . . . . . . . . . . 36
3.4.2 Comunicao rede Foundation Fieldbus X Supervisrio . . . . . 38
3.4.3 Dados Inseridos no Banco . . . . . . . . . . . . . . . . . . . . . 41
4 Concluses 43
5 Cronograma de Execuo 45
Referncias bibliogrficas 46
Lista de Figuras
1.1 Pirmide hierrquica dos sistemas de automao . . . . . . . . . . . . . . 3
2.1 Modelo OSI X Foundation Fieldbus . . . . . . . . . . . . . . . . . . . . 7

2.2 Sistema de superviso e controle . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Ligao entre a rede e os instrumentos do Laboratrio A . . . . . . . . . 25

3.2 Estrutura projetada do Banco de Dados . . . . . . . . . . . . . . . . . . . 26
3.3 Tela principal do Supervisrio Laboratrio B . . . . . . . . . . . . . . 28
3.4 processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 Configurao do Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6 Tela Detalhes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.7 Telas de Informaes dos dispositivos TT302 . . . . . . . . . . . . . . 31
3.8 Telas de Informaes dos dispositivos LD302 . . . . . . . . . . . . . . 32
3.9 Janela de Edio de Scripts da Aplicao . . . . . . . . . . . . . . . . . . 33
3.10 Administrador de Fonte de Dados do MS Windows XP . . . . . . . . . . 35
3.11 Janela de configurao da nova fonte de dados PostgreSQL ANSI ODBC
Driver criada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.12 Config Syscon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.13 Bloco Funcional de Diagnstico . . . . . . . . . . . . . . . . . . . . . . 38
3.14 Bloco Funcional Transdutor . . . . . . . . . . . . . . . . . . . . . . . . 38
3.15 Bloco Funcional AI(Entrada Analgica) . . . . . . . . . . . . . . . . . . 39
3.16 Bloco Funcional de Recursos . . . . . . . . . . . . . . . . . . . . . . . . 39
3.17 Cliente OPC do Elipse SCADA . . . . . . . . . . . . . . . . . . . . . . . 40
3.18 Tabela BufferEntrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.19 Tabela Recentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.20 Tabela Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
iii
Lista de Tabelas
2.1 Nomenclatura dos principais blocos funcionais do padro Foundation Fi-

eldbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Tabela de Converso Inteiro X Unidade de Temperatura. . . . . . . . . . 33

3.2 Tabela de Converso Inteiro X Unidade de Presso. . . . . . . . . . . . . 34
iv
Captulo 1
Introduo
1.1 Sistemas de Automao Industrial

O conceito da automao industrial est relacionado utilizao de vrias tcnicas
destinadas a tornar automticos diversos processos da indstria. Conseqentemente, o
trabalho braal do ser humano acaba sendo substitudo por equipamentos diversos. O
conceito de automao varia com o ambiente e experincia da pessoa envolvida. So
exemplos de automao [Maitelli 2003]:
Para uma dona de casa, a mquina de lavar roupa ou lavar loua.

Para um empregado da indstria automobilstica, pode ser um rob.
Para uma pessoa comum, pode ser a capacidade de tirar dinheiro do caixa eletr-
nico.
Esse conceito envolve ainda a idia de se utilizar potncia eltrica ou mecnica para
acionar algum tipo de mquina, podendo ser agregada inteligncia a tal dispositivo, com
o objetivo de proporcionar maior eficincia e segurana na execuo de sua tarefa.
A justificativa bsica para automatizar um processo industrial, ou uma parte dele, pode
se basear nas vantagens apontadas abaixo [Maitelli 2003]:
1. Qualidade: ao se produzir em uma faixa de tolerncia falhas estreita atravs de

um controle de qualidade eficiente, de uma compensao automtica de deficincias
do processo, ou do uso de tecnologias mais sofisticadas, obtm-se uma qualidade
maior na produo;
2. Produtividade: obtida a partir do uso mais eficiente da matria prima, energia, equi-
pamentos e instalaes atravs, por exemplo, da produo de refugo zero, como
conseqncia de uma superviso da qualidade, na qual o mnimo de matria prima
desperdiado;
CAPTULO 1. INTRODUO 2
3. Flexibilidade: consiste na capacidade de admitir com facilidade e rapidez, altera-

es nos parmetros do processo de fabricao, em funo de inovaes freqentes
no produto, do atendimento a especificidades do cliente, ou da produo de peque-
nos lotes;
4. Viabilidade Tcnica: permite que o sistema execute operaes impossveis de reali-
zar por mtodos convencionais, como manipulao de componentes extremamente
sensveis e minsculos.
1.1.1 Breve Retrospecto

O advento da Automao Industrial, por razes etimolgicas da expresso, est associ-
ado diretamente necessidade de existir indstria e processos industriais autocontrolveis
[Silveira e Lima 2003]. Portanto, pode-se marcar como incio da Automao Industrial
o sculo XVIII, com a criao inglesa da mquina a vapor, aumentando a produo de
artigos manufaturados, poca correspondente Revoluo Industrial. No sculo seguinte
a indstria cresceu e tomou forma, novas fontes de energia e a substituio do ferro pelo
ao impulsionaram o desenvolvimento das indstrias na Europa e Estados Unidos. Nesse
contexto, nos anos que se seguiram, foram criados dispositivos eletromecnicos chamados
rels que, em breve, tomariam as fabricas.
No incio do sculo XX, embora o conceito de indstria j estivesse bastante estabe-
lecido, os ambientes fabris ainda desfrutavam de processos de automao muito rudimen-
tares. At que Henry Ford teve a grande idia, a qual mudou o pensamento da indstria
contempornea, propagando-se at os dias de hoje. A idia revolucionria consistia numa
linha de produo, possibilitando uma produo em massa, tornando-se o real gatilho para
o grande desenvolvimento industrial do sculo.
Outro fato marcante na histria da automao ocorreu cerca de 40 anos depois com o
advento dos Controladores Lgicos Programveis, cuja criao foi incentivada pela Ge-
neral Motors, empresa norte-americana que enfrentava dificuldades com a programao
de sua linha de produo. At ento, a programao era toda feita atravs da utilizao
de rels e a complexidade de alguns processos produtivos exigia, no raro, instalaes em
painis com centenas desses dispositivos. O surgimento dos CLPs ocasionou uma maior
flexibilidade, economia e eficincia em tais sistemas, tendo em vista que proporcionavam
grandes facilidades na manuteno e uma maior operacionalidade.
Para Constantino Seixas [Filho 2000], o conceito embutido na palavra automao est
diretamente ligado a revoluo do processo de produo. Primeiro devido a uma especi-
alizao causada pela melhor compreenso dos diversos tipos de processo. A automao
de processos contnuos, em batelada e de manufatura requer normas e produtos diferen-

tes, que melhor atendam a identidade de cada setor. A segunda revoluo corresponde
ao aumento do escopo das atividades. A automao rompeu as barreiras do cho de f-
brica e buscou fronteiras mais amplas, se abrangendo a automao do negcio, ao invs
da simples automao dos processos e equipamentos.
Com o tempo, os painis sinpticos e as mesas de controle foram dando lugar ao PC
(Personal Computer), o qual passou a reinar como a plataforma preferida de superviso
e operao de processos. Os softwares SCADA (Supervisory Control And Data Acqui-
sition) surgiram em diversos tamanhos, diversos sistemas operacionais e com diversas
funcionalidades englobadas. Na rea de instrumentao, fez-se necessrio uma adequa-
o dos instrumentos para torn-los mais inteligentes. Logo, o padro para transmisso de
sinais analgicos de 4-20mA cedeu espao para a transmisso digital de dados. Exemplos
de alteraes que comprovam integralmente o avano associado a automao industrial.
1.1.2 Nveis de Hierarquia em Sistemas de Automao

A quantidade de nveis hierrquicos dentro de um sistema depende fundamentalmente
do tamanho do processo e das necessidades relacionadas planta industrial [Lima 2004].
Um sistema de automao industrial genrico pode ser caracterizado em seis nveis hie-
rrquicos (Figura 1.1), sendo que em algumas plantas no h a presena de todos.
Figura 1.1: Pirmide hierrquica dos sistemas de automao

Processos Fsicos: Consiste na base da pirmide, estando presente em todos os siste-

mas de automao. Aqui esto inclusos todos os processos a serem automatizados.
Neste nvel encontramos o conjunto do conhecimento das tcnicas e materiais de
produo de uma fbrica: tanques, bombas, caldeiras, robs, esteiras, motores, en-
tre outros.
Sensores e Atuadores: Camada que contm os dispositivos encarregados de manipular
o processo produtivo, tomando as medidas necessrias a partir das informaes en-
viadas pelo nvel superior. Por ser a camada mais prxima do processo controlado,
tambm possui a responsabilidade de fazer a aquisio dos dados.
Controle Regulatrio: Os sensores e atuadores do nvel inferior esto diretamente co-
nectados aos dispositivos desta camada. Os controladores de malha, CLPs, Sis-
temas Digitais de Controle Distribudo (SDCD), so exemplos de dispositivos que
implementam o controle regulatrio.
Alarme e Intertravamento: Nvel responsvel pela segurana do processo como um
todo. No momento em que os circuitos de segurana detectam falhas no sistema, os
equipamento so levados a um estado seguro (intertravamento), no qual a produo
preservada. Logo em seguida, alarmes so acionados para que os engenheiros de
processo e automao possam tomar aes corretivas.
Superviso: Camada responsvel pela emisso de relatrios de operao e exibio de
informaes. Sua configurao varia desde sistemas mais simples, apenas com
interfaces homem-mquina (IHM) locais, at ilhas de superviso equipadas com
computadores poderosos e com os sistemas SCADA.
Gerncia: Consiste no nvel mais elevado da hierarquia, sendo realizadas anlises de
dados por um corpo administrativo, o qual articula decises de carter econmico e
de marketing.
1.2 Objetivos e Localizao do Trabalho

O objetivo principal do projeto aproveitar os recursos do Laboratrio de Avalia-
o de Medio em Petrleo (LAMP), para desenvolver um sistema de monitoramento e
armazenamento de dados coletados a partir da planta implementada no mesmo.
A planta industrial do LAMP implementada em escala laboratorial possuindo 6 tan-
ques sendo eles de leo, gua, misturador, auditor, resduos alm de um tanque tratador
para separao gua/leo, que possibilita a reutilizao da gua e do leo em seguidos
testes, sem necessidade de descartes a cada teste. A automao feita com avanada tec-
nologia de barramento de campo. A principal caracterstica do laboratrio a integrao
de trs destas tecnologias: Foundation Fieldbus , MODBus RTU e ponto-a-ponto(Serial).

Utilizando tais recursos dever ser criada uma arquitetura unindo software e hardware
visando monitorar no somente as caractersticas do processo mas tambm dos dispositi-
vos, de modo a criar uma base de dados completa sobre diversas variveis intrnsecas aos
dispositivos para estudo do seu comportamento passado, presente e futuro.
1.3 Estrutura do Trabalho

Este documento foi dividido em quatro Captulos, os quais apresentam desde uma
viso geral dos Sistemas de Automao Industrial at a proposta e os resultados obtidos
no trabalho.
Dessa forma, no segundo captulo construda toda a fundamentao terica para o
desenvolvimento do trabalho. Em primeiro lugar, faz-se uma anlise da comunicao
entre processos industriais enfatizando a explicao do protocolo Foundation Fieldbus
de comunicao, em seguida explica-se o protocolo OPC, sistemas supervisrios, e por
fim, so apresentados os conceitos bsicos do Sistema Gerenciador de Base de Dados
Relacional.
O terceiro captulo apresenta toda a proposta de trabalho, com sua implementao e
resultados.
No ltimo captulo so discutidos os resultados alcanados com a implementao e
uma opinio sobre o funcionamento do sistema como um todo.
Captulo 2
Fundamentao Terica
Neste captulo sero descritos os conhecimentos tericos levados em conta para o

desenvolvimento deste trabalho, sendo eles: Comunicao entre Processos Industriais
Protocolo Foundation Fieldbus , Padro OPC, Sistemas Supervisrios Elipse Software
e Sistemas de Gerenciamento de Banco de Dados PostgreSQL .
2.1 Comunicao entre Processos Industriais Protocolo

Foundation Fieldbus
A rede Foundation Fieldbus (FF) um sistema de comunicao digital, serial e bi-
direcional, que funciona como uma rede local para instrumentos usados em processos e
automao industrial, com capacidade embutida para distribuir o controle de aplicao
atravs da rede industrial. Ela tambm pode ser interligada a redes TCP/IP/Ethernet, com
o intuito de configurao remota de dispositivos. A estratgia de controle distribudo ao
longo dos dispositivos de campo possvel porque todos os dispositivos possuem micro-
processadores e memria com vrias funes, inclusive a estratgia de controle PID, e al-
guns fabricantes j disponibilizam controle fuzzy e outros tipos de estratgias de controle.
Graas a todas essas novas possibilidades, o conceito de gerenciamento de processos atu-
almente permite novas tarefas de automao, como: novas configuraes, diagnsticos de
desempenho em tempo real e manuteno de registros e ferramentas.
2.1.1 Caractersticas da Tecnologia

A Foundation Fieldbus possui um protocolo confivel e determinstico para comu-
nicao em instrumentao e controle de processos, interligando equipamentos, como:
sensores, atuadores e controladores, com a habilidade de operar dispositivos mltiplos,
CAPTULO 2. FUNDAMENTAO TERICA 7
independentemente do fabricante, no mesmo sistema sem a mnima perda de funcionali-

dade e interoperabilidade, desde que no sejam utilizados funcionalidades especficas de
um fabricante.[Lima 2004]
O modelo de referncia de comunicao em camadas (modelo OSI) utilizado para
modelar os componentes fundamentais da tecnologia Foundation Fieldbus (Figura 2.1)
nos trs seguintes componentes:
Camada fsica;
Camada de comunicao, e;
Camada de aplicao ao usurio.
Os nveis 3 ao 6 do modelo OSI no so implementados na tecnologia Foundation

Fieldbus pois se trata de nveis utilizados na rede local.
Figura 2.1: Modelo OSI X Foundation Fieldbus
2.1.2 Camada Fsica

A camada fsica equivale ao nvel fsico do modelo OSI. No nvel fsico, os sinais
Foundation Fieldbus , padronizados pelo IEC (International Engineering Consortium) e
pela ISA (The Instrumentation, Systems and Automation Society), so codificados usando
a codificao Manchester Biphase-L. Este tipo de sinal carrega junto com os dados a
informao de clock para sincronizao.
Os dados da tecnologia Foundation Fieldbus podem trafegar junto da energia que

alimenta os dispositivos, necessitando, o instrumento, ento apenas de um par de fios,
que pode ser o mesmo usado em dispositivos 4-20mA. O dispositivo transmissor entrega
+10mA a 31.25Kbps para uma carga de at 50 para criar uma tenso de 1V pico-a-pico
modulada acima da corrente direta da fonte de tenso. Para algumas aplicaes, a tenso
pode variar de 9 a 32V. O comprimento do cabo determinado pela taxa de comunicao,
tipo e tamanho deste e potncia da linha.[Lima 2004]
2.1.3 Camada de Comunicao

A camada de comunicao possui basicamente trs subcamadas: a subcamada inferior
de enlace de dados (controle de erro e poltica de acesso ao meio), que faz interface com
a camada fsica; a subcamada intermediria de acesso a servios fieldbus(FAS Fieldbus
Access Sublayer) e a subcamada superior de montagem de mensagens (FMS -Fieldbus
Message Specification).
A tecnologia Foundation Fieldbus define dois tipos bsicos de equipamentos dispon-
veis na camada de comunicao:
Dispositivos bsicos, que so os sensores, atuadores, entre outros;

Dispositivos de Link Mestre, que preferencialmente ser um LAS (Link Active
Scheduler).
Um LAS um dispositivo que controla de forma determinstica os tempos que os dis-

positivos transmitem (publicao) os dados dos buffers para a rede. Quem estiver configu-
rado para receber (assinante) copia estes dados. Geralmente o LAS implementado num
dispositivo especial denominado de Linking Device. Porm, na sua ausncia, qualquer
outro dispositivo pode desempenhar o papel do LAS, de modo a no parar o funciona-
mento da rede. Entre as transmisses de mensagens agendadas tambm podem transitar
mensagens de forma no agendada.
O LAS concede permisso para um dispositivo usar o barramento emitindo um sinal
de passagem de token (PT). Ao receber este sinal, o dispositivo transmite, se necessi-
tar. Isso significa que esta tecnologia funciona como o protocolo passagem do token de
barramento.[Lima 2004]
2.1.4 Camada do Usurio

Uma caracterstica nica da Foundation Fieldbus , que assegura interoperabilidade de
dispositivos, o uso de uma Camada de Usurio, padronizada e completamente especifi-
cada, baseada em blocos e tecnologia de descrio de dispositivos. A Camada de Usurio

define um processo de aplicao de blocos de funo usando blocos de recursos, blocos de
funo, blocos transdutores, gerenciamento de sistema e de rede e tecnologia de descrio
de dispositivos.
Blocos de Recursos: Definem parmetros que so necessrios a qualquer aplica-
o.(Exemplo: Nmero serial de fabricao.)
Blocos de Funo: Encapsulam funes de controle. (Exemplos: Controlador PID,
Entrada Analgica, etc.)
Blocos Transdutores: Representam uma interface para sensores, tais como: de tem-
peratura, presso e fluxo.
Blocos Transdutores
Analog Input (AI) Bloco de entrada de dados analgico.
Analog Output (AO) Bloco de sada de dados analgico.
Transducer Bloco conversor de grandezas fsicas.
Bloco de Funo
PID Bloco controlador de ao proporcional, integrativa e derivativa.
Blocos de Recursos
Resource Bloco de recursos dos instrumentos.
Display Bloco de apresentao de informaes no display.
Tabela 2.1: Nomenclatura dos principais blocos funcionais do padro Foundation Field-
bus .
A Tabela 2.1 apresenta a nomenclatura de alguns dos principais blocos funcionais

padronizados pela FF. Os blocos de funo so incorporados dentro de equipamentos
Foundation Fieldbus para conseguir a funcionalidade desejada do dispositivo, bem como
definir uma vasta faixa de caractersticas e comportamentos que devem trabalhar de ma-
neira padro para que os dispositivos possam interoperarem.
2.2 OLE For Process Control - OPC

Em 1995, algumas empresas, Fisher-Rosemount, Rockwell Software, Opto 22, Intel-
lution, e Intuitive Technology, se reuniram com o objetivo de desenvolver um padro
baseado na tecnologia OLE/DCOM para acesso dados de tempo real dentro do sistema
operacional Windows. Neste trabalho foram envolvidos membros da Microsoft para su-
porte tcnico soluo a ser adotada. Este grupo sem fins lucrativos formado por diver-
sas empresas e gerenciado pela organizao OPC Foundation. Basicamente, o padro
OPC estabelece as regras para que sejam desenvolvidos sistemas com interfaces padres
para comunicao dos dispositivos de campo (CLPs, sensores, balanas, etc.) com sis-
temas de monitorao, superviso e gerenciamento (SCADA Supervisory Control and
Data Aquisition, Sistemas de Controle e Aquisio de Dados, MES Manufacturing
Execution Systems, Sistemas de Execuo da Manufatura, ERP Enterprise Resource
Planning, SIGE - Sistemas Integrados de Gesto Empresarial, etc.).
2.2.1 Histrico
A primeira especificao produzida pelo grupo foi publicada em agosto de 1996, cha-
mada OPC Specification Version 1.0. O principal objetivo do grupo atender s neces-
sidades da indstria, atravs do aprimoramento e ampliao da especificao OPC. A
estratgia adotada foi a criao de extenses especificao existente, definio da adi-
o de novas especificaes e a realizao de modificaes para manter a compatibilidade
mxima com as verses existentes. Em setembro de 1997 foi liberada a primeira atuali-
zao da especificao OPC que passou a ser chamada de OPC Data Access Specification
Version 1.0A. Atualmente existem as seguintes especificaes publicadas ou em processo
de aprovao:
OPC Overview (Verso 1.00) - Descrio geral dos campos de aplicao das espe-
cificaes OPC;
OPC Common Definitions and Interfaces (Verso 1.00) - Definio das funciona-
lidades bsicas para as demais especificaes;
OPC Data Access Specification (Verso 2.05) - Definio da interface para leitura
e escrita de dados de tempo real;
OPC Alarms and Events Specification (Verso 1.02) - Definio da interface para
monitorao de eventos;
OPC Historical Data Access Specification (Verso 1.01) - Definio da interface
para acesso a dados histricos;
OPC Batch Specification (Verso 2.00) - Definio da interface para acesso aos
dados de processos por batelada (batch).Esta especificao uma extenso da OPC
Data Access Specification;
OPC Security Specification (Verso 1.00) - Definio da interface para utilizao
de polticas de segurana;
OPC and XML (Verso candidata 1.05) - Integrao entre OPC e XML para aplica-
es via Internet (web). Est em fase de elaborao a especificao OPC DX Data
Exchange for Ethernet. Esta especificao tem a finalidade de definir a comunica-

o entre diferentes servidores conectados atravs de uma rede Ethernet TCP/IP.
At ento, esta comunicao no possvel sem a utilizao de um cliente e uma

aplicao para intermediar a troca de dados, o servidor.
2.2.2 Interfaces de Acesso ao Servidor

Existem duas possveis interfaces de acesso aos servidores OPC, interfaces do tipo
custom e interfaces do tipo automation. A interface custom define o acesso aos servi-
dores OPC por aplicaes clientes desenvolvidas atravs de linguagens que suportam as
chamadas das funes por ponteiros, tais como C/C++, Delphi, etc. Entretanto, existem
linguagens tais como VisualBasic e VBA que no suportam ponteiros para funes. Neste
caso foi introduzido o conceito da interface tipo automation. Atravs da interface tipo au-
tomation, os clientes desenvolvidos nestas linguagens podem fazer uso de uma interface
padro onde os mtodos so chamados pelo nome e no por ponteiros. Existem portanto,
especificaes OPC separadas para interfaces do tipo custom e automation.
A publicao das especificaes para o padro OPC possibilitou o desenvolvimento
de diversos produtos para automao industrial, os quais se beneficiam das vantagens
proporcionadas pelo padro:
Padronizao das interfaces de comunicao entre os servidores e clientes de dados

de tempo real, facilitando a integrao e manuteno dos sistemas;
Eliminao da necessidade de drivers de comunicao Especficos (proprietrios);
Melhoria do desempenho e otimizao da comunicao entre dispositivos de auto-
mao;
Interoperabilidade entre sistemas de diversos fabricantes;
Integrao com sistemas MES, ERP e aplicaes Windows (Excel, etc.);
Facilidade de desenvolvimento e manuteno de sistemas e produtos para comuni-
cao em tempo real;
Facilidade de treinamento.
Atualmente existem diversos produtos no mercado que utilizam o OPC para comuni-
cao com dispositivos de cho de fbrica. O OPC est se tornando rapidamente o padro
de comunicao adotado pelo mercado de automao industrial e pela indstria.
2.2.3 Aspectos Prticos para Utilizao do Padro OPC

Para a especificao e utilizao do padro OPC, necessita-se estar ciente de alguns
pontos chaves para o perfeito entendimento de como se beneficiar do uso da comunicao
OPC. Por isso, o estudo das especificaes torna-se um processo difcil, uma vez que
as mesmas so direcionadas para desenvolvedores e programadores, sendo necessrio o
conhecimento prvio de linguagens e ambientes de desenvolvimento. Para simplificar o
entendimento do padro OPC, estes pontos so apresentados a seguir.
Plataforma Windows ou no?
Basicamente, o padro OPC nativo da plataforma Windows. Dentro desta plata-

forma, existem variaes para as verses do Windows (CE, 9X, NT, 2000 e XP), mas
para todas estas possvel a comunicao OPC. Para plataformas no-Windows, existem
algumas solues que consistem em portar o DCOM para estas plataformas. No futuro, a
especificao OPC para XML dever facilitar a integrao de plataformas no-Windows
para a comunicao OPC.
Cliente ou Servidor OPC?
As aplicaes e produtos existentes no mercado podem ser somente um cliente, um

servidor ou ambos, isto varia de caso a caso. Normalmente, os produtos para monitorao
de dados (IHMs; sistemas supervisrios, etc.) so clientes OPC. J os produtos que fazem
a comunicao direta com os dispositivos de campo utilizando protocolos proprietrios
so servidores OPC. Cada produto pode incorporar as duas funcionalidades, sendo o mais
comum que uma aplicao normalmente cliente possa ser servidor, e no o contrrio.
Nmero de Clientes x Nmero de Servidores
O nmero de servidores OPC necessrios para uma determinada aplicao ir depen-

der do produto a ser utilizado. Normalmente, os fabricantes de dispositivos de campo
(CLPs; dispositivos inteligentes, etc.) fornecem um servidor OPC capaz de comunicar
com todos os protocolos dos sua linha produtos . Este servidor um software para o
ambiente Windows que executado em um microcomputador, normalmente PC. Ou seja,
um servidor OPC da Rockwell, o RSLinx por exemplo, permite que diversos drivers de
comunicao sejam configurados para as diversas redes (ControlNet, DeviceNet, Ether-
net, DH+, etc.), algumas para as aplicaes clientes, outras para as fontes de dados. Neste
caso, o RSLinx funciona como um nico servidor OPC, capaz de comunicar com diver-
sos clientes OPC sendo executados na mesma mquina ou em mquinas remotas. Existem
servidores OPC de terceiros que permitem que sejam configurados drivers de comunica-
o para diversas redes e protocolos de diferentes fabricantes. Como exemplo podemos
citar os servidores da Kepware e da Matrikon. Neste caso, um nico produto poder for-
necer dados de diferentes fabricantes. Cada cliente OPC pode conectar-se diferentes
servidores, os quais podem estar processando na mesma mquina ou remotamente em
mquinas diferentes. Portanto, qualquer produto que funcione como cliente OPC poder
se comunicar com quaisquer servidores OPC de quaisquer fabricantes.
Formato de Dados OPC (Time Stamp e Qualidade)
Pela especificao do padro, todo servidor de dados deve enviar o dado OPC no
formato apresentado a seguir:
Valor do dado: Todos os tipos de dados VARIANT definidos pela interface DCOM
so suportados;
Time Stamp: Esta informao fornecida pelo servidor atravs da leitura do time
stamp dos dispositivos de campo ou por gerao interna. utilizada a estrutura
padro do Windows para o UTC (Universal Time Coordinated).
Informao de estado: So reservados 2 bytes para codificao do estado do dado
fornecido pelo servidor. Por enquanto, apenas o uso do byte menos significativo foi
definido. Dois bits definem a qualidade do dado que pode ser:
Good: Dado vlido;
Bad: No caso de perda do link de comunicao com o dispositivo de campo,
sem comunicao, por exemplo;
Uncertain: No caso de existir o link de comunicao mas o dispositivo de
campo estiver fora de operao.
Quatro bits fornecem um detalhamento do estado apresentado, tais como NotConnec-

ted e Last Usable Value. Os ltimos dois bits podem conter dados de diagnstico no caso
de falha de um sensor, por exemplo.
Configurao dos dados OPC no Cliente
Normalmente, os produtos de mercado no permitem muita flexibilidade para a con-

figurao dos dados solicitados pelo cliente. Isto se deve basicamente preservao da
cultura anterior para os drivers de comunicao especficos. Considerando o caso mais
comum que consiste nos servidores de dados OPC(OPC Data Access), os clientes podem
definir basicamente as seguintes configuraes:
Criao de grupos e itens OPC: Basicamente, todos os dados OPC so chama-

dos de itens. Cada item pode ser de um tipo diferente de dado compatvel com a
especificao OPC. Os diversos itens so organizados em grupos OPC, os quais de-
finem as principais caractersticas de leitura dos itens (Taxa de Atualizao, Estado
Ativo/Inativo, Banda Morta, Leitura Sncrona/Assncrona).
Leitura Sncrona ou Assncrona: Para um determinado grupo OPC pode ser de-
finido se a leitura dos dados feita de forma sncrona, a qual depende de uma
confirmao de execuo antes de uma nova leitura, ou assncrona, a qual no de-
pende da confirmao. Normalmente utilizada a leitura assncrona, a qual garante
um melhor desempenho.
Leitura de dados direto do dispositivo: A partir da verso 2.0 da especificao
para o servidor de dados, possvel fazer a seleo no cliente OPC para leitura dos
dados da memria cache do servidor ou diretamente do dispositivo de campo.
Estado Ativo/Inativo: Cada item ou grupo pode ter o seu estado alterado pelo
cliente para Ativo, habilitando a comunicao do mesmo, ou Inativo.
Leitura Cclica ou por Mudana de Estado: O cliente OPC pode definir se os da-
dos do servidor sero lidos de forma cclica ou por mudana (transio) de estado.
Na leitura cclica, o cliente faz a requisio de leitura regularmente, independen-
temente se os dados sofreram alterao de valor ou no. No caso de leitura por
mudana de estado, o servidor fica responsvel por enviar para os clientes os itens
que sofrerem alterao de seu estado (Qualidade do dado) ou quando os valores dos
itens de um determinado grupo ultrapassarem o valor da banda morta.
Banda Morta: utilizada para definir os valores limites de transio para os itens
de um determinado grupo, para os quais o servidor far o envio para os clientes
quando a alterao dos valores dos itens estiver fora da banda especificada.
Escrita de dados OPC: A escrita de dados OPC funciona de forma independente
da leitura. Assim como na leitura, a escrita pode ser sncrona ou assncrona. Entre-
tanto, os comandos de escrita so executados imediatamente pelo servidor, sendo
enviados diretamente para os dispositivos de campo. Est prevista para a verso
3.0 do servidor de dados, a possibilidade de se fazer a escrita de dados na mem-
ria cache do servidor e depois a transferncia cclica dos dados para os disposi-
tivos de campo. Este recurso ser muito til para os dispositivos que dependem
de comandos igualmente espaados no tempo, tal como os sistemas de controle de
movimento.
Comunicao de Blocos de Dados: O padro OPC permite a comunicao de
blocos de dados (vetores) entre o servidor e os clientes. Isto representa uma grande
otimizao, pois as informaes de time stamp e estado do dado so tratados e
fornecidos apenas uma vez para um conjunto de dados, reduzindo assim o overhead
da comunicao. Neste caso, cada item configurado como um bloco de dados.
Redundncia com OPC: As especificaes do padro OPC no fazem meno
utilizao de servidores redundantes. Entretanto, cada cliente OPC pode implemen-
tar facilmente um mecanismo para conexo simultnea em mais de um servidor,
verificao do estado do servidor e ativao/desativao dos grupos para o servidor
que estiver funcionando. Esta soluo encontrada apenas em alguns produtos,
no sendo regra geral a disponibilizao deste recurso para a maioria dos produtos
de mercado. O produto ORB (OPC Redundancy Broker) da Matrikon permite que
clientes comuns possam fazer o chaveamento para servidores redundantes.
Desempenho da comunicao OPC: Em linhas gerais, o desempenho da comu-
nicao OPC se aproxima do desempenho apresentado por sistemas que utilizam
drivers de comunicao especficos e otimizados. Normalmente, os drivers espec-
ficos possuem um timo desempenho aps serem devidamente depurados e otimi-
zados, o que via de regra no acontece em muitos casos. Como um servidor OPC
nada mais do que uma camada de software a mais para implementar as interfa-
ces padres e os mecanismos de comunicao com o cliente, de se esperar que
o desempenho do mesmo s seja afetado em relao comunicao com o cliente
e no com o dispositivo de campo. No caso da comunicao com o dispositivo de
campo, cada fornecedor pode implementar o driver e o protocolo que melhor se
ajustem s necessidades do dispositivo e da rede de comunicao. Desta forma, o
desempenho do servidor OPC est mais relacionado capacidade dos recursos de
hardware da mquina que executa a aplicao do servidor do que propriamente do
driver especfico. Como os recursos de hardware esto cada vez mais poderosos
em relao capacidade de processamento, isto no tem se mostrado como um pro-
blema real. Entretanto, o que se tem verificado na prtica que muitos clientes e
servidores OPC no implementam a comunicao de blocos de dados, fazendo a
leitura de itens separadamente, o que ocasiona um grande overhead devido ao tra-
tamento separado de time stamp e estado do dado para cada item OPC. Outro ponto
importante que muitos clientes OPC no implementam, consiste no agrupamento
de dados que precisam ser lidos sob demanda, tais como animaes de telas sinp-
ticas, janelas de operao de equipamentos, relatrios, etc. Os dados necessrios
para estes elementos (objetos) de monitorao, normalmente podem ser lidos sob
demanda, de forma que somente quando o objeto estiver selecionado, ser ativado
o grupo OPC no servidor para leitura dos dados. Quando o objeto no estiver sele-
cionado, o grupo OPC ficar desativado, fazendo com os dados no sejam lidos e
melhorando o desempenho da comunicao.
Segurana para acesso ao sistema: Para a implementao do controle de acesso
ao servidor OPC podem ser utilizados dois mtodos. O mtodo normalmente usado
consiste nos mecanismos proporcionados pelo prprio DCOM, os quais so con-
figurados no Windows NT executando-se o comando DCOMCNFG. Outra forma
menos usual consiste em se utilizar mecanismos implementados pelo cliente e ser-
vidor conforme a especificao do padro OPC. O controle de acesso fundamental
para o caso de acesso remoto e para a comunicao via Internet prevista com a es-
pecificao do OPC com XML.[LAMP 2003]
2.3 Sistemas Supervisrios

Os sistemas supervisrios so softwares que permitem o monitoramento de informa-
es e variveis de um processo produtivo ou instalaes fsicas, por exemplo. Essas
informaes podem ser obtidas atravs de equipamentos de aquisio de dados e, poste-
riormente, podem ser manipuladas, analisadas, armazenadas e, em seguida, apresentadas
ao usurio atravs de uma interface amigvel, condicionando a superviso e o controle de
uma planta automatizada. Os sistemas supervisrios so tambm conhecidos como siste-
mas SCADA(Sistemas de Controle e Aquisio de Dados), ou ainda, Interface Homem-
Mquina.
Inicialmente, os sistemas SCADA permitiam o monitoramento de sinais representa-
tivos de medidas e estados de dispositivos. Tais informaes eram apresentadas em um
painel de lmpadas e indicadores, sendo permitido o controle desses estados pelo opera-
dor apenas com uso de botoeiras.
Hoje em dia, os sistemas de automao industrial so beneficiados por vrias tecno-
logias de computao e comunicao, permitindo que o monitoramento e controle dos
processos industriais complexos sejam realizados de locais distantes, e sua apresentao
mostrada de forma amigvel para os operadores com recursos grficos e multimdia.
Para obteno desses resultados, o sistema SCADA faz a identificao das variveis
da aplicao atravs de tags, as quais podem exercer vrias funes computacionais, ou
ainda, fazer a representao de entradas/sadas de dados do processo industrial controlado,
correspondendo s variveis do processo real, como temperatura, nvel e vazo. Dessa
forma, cria-se o elo entre o controlador e o sistema. A apresentao dos dados adquiridos
s possvel a partir da leitura dos valores associados s tags. Os sistemas SCADA podem
verificar o estado das variveis e fazer com que sejam obtidas condies de alarmes, nas
quais o valor da tag ultrapassa um limite ou condio pr-estabelecida, podendo ainda,
fazer a gravao destes registros em Bancos de Dados, ativao de som, mensagem ou
mudana de cores dos indicadores nas telas.
2.3.1 Componentes Fsicos de um Sistema de Superviso

Os Componentes fsicos de um sistema de superviso, de forma simplificada, so:
sensores e atuadores, redes de comunicao, estaes remotas (aquisio/controle) e de
monitorao central (sistema SCADA) [Silva e Salvador 2005].
Os sensores so elementos que sentem a varivel a ser medida. Os transmissores
condicionam o sinal do sensor e o convertem para um sinal adequado para a transmisso
aos controladores. Esses sinais de transmisso so normalmente eltricos e podem ser
classificados em digitais e analgicos. J os atuadores so responsveis por executar as
tarefas enviadas pelo controlador e permitem o controle da varivel de processo [Souza
2005].
O controle e aquisio de dados esto presentes nas estaes remotas, CLPs(Controladores
Lgico Programveis) e RTUs (Remote Terminal Units), nas quais os dados so lidos
atravs da instrumentao do nvel inferior e procedimentos so executados atravs dos
atuadores [Lima 2004]. Os CLPs e RTUs so equipamentos utilizados, por exemplo, nas
fbricas com o objetivo de obter entradas, realizar clculos ou controles, e atualizar suas
sadas.
Na rede de comunicao, temos a camada por onde as informaes fluem dos CLPs/RTUs
para o sistema SCADA.
Nas estaes de monitoramento central encontram-se as principais partes dos sistemas
SCADA, as quais so responsveis por todo o monitoramento e apresentao dos dados
gerados nas estaes remotas e realizar as aes conforme os alarmes detectados, e ainda,
podem permitir o compartilhamento de informaes coletadas, optando por uma arquite-
tura distribuda em uma rede de computadores ou centralizada em um nico computador
[Silva e Salvador 2005].
Um exemplo dos componentes fsicos de um Sistema de Superviso podem ser obser-
vados na figura 2.2.
Figura 2.2: Sistema de superviso e controle
2.3.2 Componentes Lgicos de um Sistema SCADA

Os sistemas SCADA, normalmente, tm suas principais funes organizadas em blo-
cos ou mdulos que iro permitir uma alta ou baixa flexibilidade e robustez, dependendo
do tipo de atividade que venha a ser utilizada.
Resumindo, podemos descrever essas funes como [Silva e Salvador 2005]:
Ncleo de processamento;
Comunicao com CLPs/RTUs;
Gerenciamento de Alarmes;
Histricos e Banco de Dados;
Lgicas de programao interna (Scripts) ou controle;
Interface grfica;
Relatrios;
Comunicao com outras estaes SCADA;
Comunicao com Sistemas Externos/Corporativos;
Outros.
O funcionamento de um sistema SCADA feito basicamente atravs da comunica-

o dos equipamentos de campo com o ncleo de processamento principal do software
SCADA. A partir da, este ncleo principal fica responsvel pela disseminao e coorde-
nao das informaes para os demais sistemas integrados. Essas informaes chegam ao
sistema e so mostrados na forma de grficos, animaes, relatrios, facilitando ao ope-
rador do sistema o acompanhamento das operaes. Alm disso, podem ser exibidos a
evoluo do estado de certos dispositivos e do processo supervisionado, podendo mostrar
alarmes e indicar aes a serem tomadas, ou ainda, interferir no processo por medida de
segurana.
Novas tecnologias computacionais esto surgindo e permitindo o desenvolvimento de

sistemas SCADA cada vez mais confiveis e flexveis, incluindo a diminuio do tempo
gasto na configurao dos sistemas s necessidades do processo.
2.3.3 Modos de Comunicao

A funo principal de um sistema SCADA consiste na troca de informaes, podendo
ser sintetizada das seguintes formas [Silva e Salvador 2005]:
Comunicao com os CLPs/RTUs;

Comunicao com outras estaes SCADA;
Comunicao com outros sistemas.
Os dispositivos de campo podem se comunicar com o supervisrio atravs de um

protocolos comum, cuja metodologia pode ser tanto de carter aberto quanto de carter
fechado.
A comunicao entre sistemas SCADA pode ocorrer entre protocolos criados pelos
prprios fabricantes destes sistemas ou por protocolos j desenvolvidos como, por exem-
plo, rede Ethernet TCP/IP, ou linhas discadas.
O meio de comunicao cada vez mais usado para sistemas SCADA a Internet.
A Internet utilizada atravs de tecnologias e padres como Ethernet, TCP/IP, HTTP,
HTML, sendo possvel a comunicao e compartilhamento de informaes entre a rea
de produo e a rea de superviso e controle das estaes (sistemas). Essa comunicao
provida atravs de um browser de Internet, no qual pode-se controlar em tempo real,
uma mquina localizada em qualquer parte do mundo. O browser faz uma solicitao de
uma operao, atravs do protocolo HTTP, ao servidor web, e logo depois recebe uma
resposta em forma de uma pgina HTML. A grande vantagem do browser como interface
de visualizao SCADA o modo simples de interao, ao qual a maioria das pessoas j
est habituada [Silva e Salvador 2005].
2.3.4 Sistema Supervisrio Elipse SCADA

O Elipse Scada um software utilizado no desenvolvimento de sistemas de superviso
e controle de processos. Atravs da coleta de informaes de qualquer tipo de equipa-
mento, os operadores podem monitorar e controlar com preciso todos os processos do
cho de fbrica, bem como mquinas e recursos, gerenciando de forma rpida e eficiente
toda a produo. Dados em tempo real so apresentados de forma grfica, permitindo o
tratamento das informaes de vrias maneiras, como o armazenamento histrico, a gera-

o de relatrios e a conexo remota, entre outras possibilidades. Anlises precisas e um
rpido tempo de resposta resultam em menos perdas e altos nveis de qualidade.
Utilizando o Organizer (rvore do Aplicativo) pode-se, no modo off-line, criar, orga-
nizar e documentar uma aplicao de maneira muito simples e fcil. Com ele possvel
acessar todos os elementos de sistema e suas propriedades, tendo-se assim uma viso ge-
ral do aplicativo. Atravs da ferramenta de configurao on-line possvel, por exemplo,
alterar a cor, tamanho e posio de uma janela.
O usurio ainda pode escolher entre utilizar o mouse, teclado ou touchscreen para
operar o sistema de superviso.
Verses
O Elipse Scada constitudo por quatro verses distintas indicadas segundo as ne-
cessidades do usurio: Elipse Scada VIEW, Elipse Scada MMI, Elipse Scada PRO (Pro-
fessional) e Elipse Scada CE. Abaixo so descritas as principais caractersticas de cada
uma.
A primeira delas a verso View, indicada para aplicaes simples, de interface com
o operador para monitorao e acionamentos. As informaes recebidas pelo View es-
to disponveis tambm para outras aplicaes que possam trabalhar com NetDDE (troca
dinmica de dados em rede) trabalhando como servidor DDE(Dynamic Data Exchange).
Nesta verso esto disponveis funes que permite o monitoramento e controle, comuni-
cao com CLP via drivers DLL(Dynamic-link library), objetos de tela para a produo de
interfaces, como por exemplo, boto, medidores (gauges), caixa de texto, grfico de barra
e tendncia, imagem, animaes e alarmes, importao de imagens de editores grficos,
controle de acesso atravs de lista de usurios (autenticao), comunicao em bloco, uso
de scripts (ferramenta fundamental em um software supervisrio), servidores e cliente
DDE, nmero ilimitado de tags e servidor de aplicaes remotas.
A segunda delas a verso MMI (Man Machine Interface) indicada para aplicaes
de mdio porte, onde necessrio o armazenamento de dados, tratamento de informaes
e criao de relatrios complexos. Alm das funcionalidades incorporadas na verso
View, esta verso conta ainda com: histricos, receitas, relatrios, suporte a CEP (controle
estatstico de processos), alarmes tipo histrico e browser (que so objetos de tela) e
funo de gerar log de alarmes em disco.
J a verso Professional indicada para aplicaes de qualquer porte, que envolvam
comunicao em rede, local ou remota, ou ainda que necessite a troca de informaes
entre banco de dados via ODBC(Open Database Connectivity). Alm das funcionalidades
incorporadas na verso MMI, esta verso inclui ainda ODBC, suporte a DAO (Data acess
objects), cliente e servidor de rede. Neste trabalho essa ser a verso utilizada, por termos
a disposio um hardkey.
Por fim, a verso CE permite executar aplicaes Elipse SCADA em dispositivos base-
ados no sistema operacional Windows CE, como IHMs, dispositivos sem disco em geral e
outros dispositivos mveis. O Elipse SCADA CE no comporta todas as funcionalidades
dos pacotes anteriores.
Mdulos de Operao
O Elipse Scada possui trs mdulos para sua operao: Configurador, Runtime e Mas-
ter. O mdulo ativo definido a partir de um dispositivo de proteo(hardkey) que
acoplado ao computador. Enquanto que os mdulos Configurador e Master foram es-
pecialmente desenvolvidos para a criao e o desenvolvimento de aplicativos, o mdulo
Runtime permite apenas a execuo destes. Neste mdulo, no possvel qualquer alte-
rao no aplicativo por parte do usurio.
Na ausncia do hardkey, o software pode ainda ser executado em modo Demostrao.
Como no necessita de hardkey, o modo Demo pode ser utilizado para a avaliao de soft-
ware. Ele possui todos os recursos existentes no mdulo Configurador, com exceo de
que trabalha com um mximo de 20 tags (variveis de processo) e permite a comunicao
com equipamentos de aquisio de dados por at 2 horas. Neste modo, o software pode
ser livremente reproduzido e distribudo.
Os mdulos Runtime e Master esto tambm disponveis em verses Lite que possuem
as mesmas caractersticas, porm so limitadas em nmero de tags: Lite 75 com 75 tags
e Lite 300 com 300 tags.
Recursos
Os principais recursos do Elipse Scada, so: Gerao de Histricos, Relatrios, Su-

perviso e controle de estaes distncia, Cross-Reference, acesso a Banco de Dados,
Drivers de comunicao e OPC, Conexo remota com CLPs, Alarmes, Lgicas (Scripts)
e Ferramentas de depurao.[Elipse 2007]
2.4 Sistema Gerenciador de Base de Dados Relacional

PostgreSQL
Um SGBDR (Sistema Gerenciador de Base de Dados Relacional), permite que ban-
cos de dados sejam concorrentemente partilhados por inmeros usurios e aplicaes.
sustentado pelo modelo relacional, que completo e consistente[Neves 2002].
O SGBDR PostgreSQL Open Source e implementa os padres SQL ANSI 92, 96
e 99. Permite a utilizao de gatilhos, vises, procedimentos armazendos, e muitas ou-
tras funcionalidades dos bancos de dados mais conhecidos do mercado, alm de possuir
drivers ODBC e JDBC para interface com linguagens de programao.
Stored Procedures (Procedimentos Armazenados)
Procedimento armazenado ou Stored Procedure uma coleo de comandos em SQL

para gerenciamento de Banco de dados. Encapsula tarefas repetitivas, aceita parmetros
de entrada e retorna um valor de status (para indicar aceitao ou falha na execuo). O
procedimento armazenado pode reduzir o trfego na rede, melhorar a performance, criar
mecanismos de segurana, etc.
Triggers (Gatilhos)
Gatilho ou trigger um recurso de programao presente na maioria dos sistemas de

gerenciamento de banco de dados, utilizado para associar um procedimento armazenado
a um evento do banco de dados (incluso, excluso, atualizao de registro, por exemplo)
de modo que o procedimento armazenado seja executado automaticamente sempre que o
evento associado ocorrer. muito utilizada para ajudar a manter a consistncia dos dados
ou para propagar alteraes em um determinado dado de uma tabela para outras[Neves
2002].
SQL
O SQL (Structured Query Language) a linguagem estruturada para acessar dados

num SGBD relacional. Essa linguagem foi criada pela IBM no incio dos anos 80 e
utilizada at hoje, com algumas modificaes ao longo do tempo.
As declaraes da linguagem SQL esto divididas em duas categorias funcionais:
DDL (Data Definition Language) e DML (Data Manipulation Language). A DDL
responsvel pelas instrues de criao e manipulao de entidades estruturais, como,
por exemplo, as tabelas, enquanto a DML responsvel pelas instrues de manipulao

de dados contidas no SGBDR[Neto 2003].
Da DDL fazem parte declaraes como, por exemplo:
ALTER TABLE: Modifica a estrutura de uma tabela. Esse comando tem como
principais funes adicionar novas colunas ou renomear colunas j existentes e tam-
bm o seu prprio nome;
CREATE TABLE: Esse comando cria uma nova tabela no banco de dados cor-
rente. Uma observao a ser feita que no podemos criar uma tabela com o
mesmo nome de outra tabela j existente no banco de dados;
DROP TABLE: Esse comando apaga uma determinada tabela do banco de dados
corrente.
Existem muitas outras declaraes que fazem parte da DDL. Os mesmos comandos
de alterar, criar e apagar, podem ser utilizados tambm para usurios do banco de dados,
grupos e banco de dados. Essas declaraes so poderosas, e podem mudar toda a carac-
terstica do banco de dados, por isso elas so de acesso apenas de usurios com alto nvel
de permisses[Neves 2002][Neto 2003].
Da DML fazem parte declaraes como, por exemplo:
SELECT: Esse comando realiza a consulta ao banco de dados, retomando as tabe-

las, colunas, campos e registros especificados. Podem ser inseridos, em conjunto
com esse comando, comandos de condio, agrupamento, ordenao, funes, den-
tre outros;
INSERT: Esse comando insere novos registros na tabela especificada. Em seu uso,
podemos citar, ou no, a ordem dos campos a serem inseridos;
DELETE: Esse comando apaga registros de uma tabela especificada;
UPDATE: Esse comando altera os dados existentes nos registros de uma tabela
especificada. Pode adicionar novos dados, ou apenas modificar os j existentes.
Dentro de cada comando desses, o usurio pode fazer inmeras combinaes obter
exatamente o que deseja. Para o funcionamento desses comandos necessria a utiliza-
o de algumas palavras reservadas da linguagem, como, por exemplo, o FROM[Neves
2002][Neto 2003].
Captulo 3
Proposta de Implementao
Como citado anteriormente no captulo 1, o principal objetivo do trabalho consiste

desenvolvimento de um sistema de monitoramento e armazenamento de dados coletados
da planta LAMP, abrangendo diversos nveis hierrquicos presentes na pirmide da auto-
mao industrial. Logo, sero apresentadas, neste captulo, as implementaes relativas
a cada mdulo do sistema, para que, em seguida, estas sejam relacionadas aos nveis j
discutidos.
3.1 Problemtica
Desenvolver um Sistema Supervisrio capaz de capturar as variveis disponveis da
Rede de Sensores Foundation Fieldbus do Laboratrio A na Planta LAMP, e permitir a
visualizao, modificao de valores quando couber , e armazenamento em um banco
de dados, para posterior consulta e uso.
O sistema dever ser robusto o suficiente para armazenar todos os dados coletados
pelos transmissores de temperatura, perceber quando os dados dos sensores de presso
devero ser armazenados momento em que ocorrem ensaio em campo , gerar relatrio
dos dados armazenados para uso em outros sistemas, permitir configurao de tempo de
amostragem de forma arbitrria, ter interface didtica e intuitiva e oferecer informaes
teis ao usurio.
3.1.1 Estrutura Disponvel

A Rede de Sensores do Laboratrio A na Planta LAMP, composta pelos seguintes
dispositivos:
Trs Sensores/Transmissores de Presso Diferencial LD302 , ligados em srie

no duto que conecta o Tanque Misturador ao Tanque Tratador;
CAPTULO 3. PROPOSTA DE IMPLEMENTAO 25
Figura 3.1: Ligao entre a rede e os instrumentos do Laboratrio A
Quatro Transmissores de Temperatura TT302 todos eles com elemento sensor

PT 100 IEC de trs fios, sendo que dois deles ligados ao Tanque de gua e outros
dois ligados ao Tanque de leo;
Uma DFI 302 (Gateway) modularizada:
Backplane DF1 Rack com 4 Slots;
Fonte DF50 Power Supply for backplane 90264VAC;
Mdulo Processador DF51 DFI302 Processor 1x10 Mbps, 4xH1;
Fonte FieldBus DF52 Power Supply for Fieldbus;
Impedncia DF53 Power Supply Impedance for Fieldbus (4 portas);
Terminador DF2 Terminador para o ltimo rack;
Cabo padro Ethernet DF54 Twisted-Pair (10 base T) Cable Comprimento
2 m.
3.2 Projeto e Implementao do Banco de Dados

O projeto do banco de dados foi realizado no Software DBDesigner (Data Base De-
signer), para permitir uma visualizao da estrutura a ser construda e em seguida imple-
mentado no SGBDR PostgresSQL.

Na figura 3.2 v-se o conjunto de tabelas e relacionamentos previstos para existirem
entre os dados.
Figura 3.2: Estrutura projetada do Banco de Dados
A tabela BufferEntrada utilizada para fazer a comunicao entre o programa super-

visrio e o banco de dados. O programa supervisrio s enxerga essa tabela no banco,
os dados vindos da planta so inseridos nessa tabela pelo programa. Os dados so distri-
budos para as outras tabelas do banco atravs de triggers e procedures. Foi desenvolvida
uma trigger no banco, que quando houvesse insero na tabela BufferEntrada, esse dado,
caso seja relevante, seja inserido na tabela Recentes, que responsvel por armazenar to-
dos os dados vindos dos sensores em um determinado intervalo de tempo, definido como
sendo 10 dias, mas que pode ser facilmente modificado. Essa trigger tambm verifica se
o sensor j est cadastrado no banco, se no tiver, o banco o cadastra automaticamente,
armazenando sua tag, que determinar que sensor seja, e a data da sua ltima calibrao.
Caso um sensor seja retirado da rede, calibrado e colocado novamente na rede, o sistema o
cadastra automaticamente como um novo sensor, isso til porque a data de calibrao
um parmetro importante para avaliar a eficincia do sensor e de um possvel algoritmo
inteligente que esteja implementado no sensor.
Na tabela Recentes, tambm fica armazenado o dia e a hora da coleta do dado, para
ser possvel traar grficos em funo do tempo dessa varivel e fazer comparaes.
As tabelas Antigos e AntigosDia so responsveis por fazer uma espcie de com-
presso dos dados. Quando passa o intervalo de tempo determinado uma trigger res-
ponsvel por transferir os dados da tabela Recentes para as tabelas Antigos e AntigosDia,
a tabela AntigosDia guarda informaes sobre cada dia dos sensores armazenados, e a
tabela Antigos agrupa esses dias em perodos de tempo, com data inicial e data final. A
tabela AntigosDia guarda atributos como mdia, mnimo, mximo e varincia da varivel.
Temos tambm as tabelas EnsaioSensor e Ensaio, na nossa planta existem ensaios,
que acontecem em intervalos de tempo diferentes, e duram intervalos de tempo distintos
tambm e os valores de presso s so relevantes para serem armazenados se estiver ocor-
rendo um ensaio de separao. Quando ocorre ensaios, a presso sai de um determinado
intervalo, e usa-se essa premissa para determinar se est havendo ensaios ou no. Os valo-
res de temperatura e presso durante o ensaio so armazenados na tabela EnsaioSensor e a
tabela Ensaio responsvel por armazenar os diferentes ensaios ocorridos com o mesmo
sensor em momentos distintos. O local que verifica se os valores de presso esto fora
do intervalo normal a trigger que transfere os dados da tabela de BufferEntrada para a
tabela Recentes.
3.3 Criao do Sistema Supervisrio

Definida a ferramenta de trabalho para o desenvolvimento do Sistema Supervisrio
Elipse SCADA foi levantado os trabalhos j relacionados feitos na rea e no laboratrio
para que pudessem servir de base para desenvolvimento.
Um supervisrio j existente da planta LAMP desenvolvido com a tecnologia Elipse
SCADA, mas para outra rede de sensores, serviu como modelo. Na Figura 3.3 tem-se a
tela principal do supervisrio do Laboratrio B trabalha em pesquisas na rea de medi-
es de vazo, BSW e deteco de vazamento em dutos , onde podemos visualizar tags
de sensores nas quais a rede de industrial do Laboratrio A trabalha em pesquisas na
rea de algoritmos inteligentes em rede de sensores Foundation Fieldbus e desenvolvi-
mento de softwares de gerencia de informaes , no incorpora.
Figura 3.3: Tela principal do Supervisrio Laboratrio B
3.3.1 Telas
O desenvolvimento das telas teve como princpio manter o padro de telas j existente
mas adicionando algumas caractersticas que promovessem uma interatividade, fazendo
uso apenas dos componentes visuais Bitmap, Button, Text, e Set Point.
Na Tela Principal, figura 3.4, ilustrado todo o processo capaz de ser monitorado pela
rede de sensores do Laboratrio A, visualizam-se componentes Displays que exibem in-
formaes sobre a varivel monitorada. O ttulo atribudo a cada Tag obedeceu ao nmero
srie do dispositivo, tal critrio foi adotado pois a cada vez que adotamos uma nova con-
figurao na rede Foundation Fieldbus o nome dos dispositivos podem mudar deixando
assim confuso a identificao do sensor que realmente est monitorando as variveis de
temperatura de gua, leo e Presso no duto.
No menu inferior da Tela Principal, se clicarmos no boto Intervalo de Amostra-
gem, aberta uma a janela (Figura 3.5) onde permitida a configurao de qual o inter-
valo desejado, em segundos, que ocorra o armazenamento dos dados coletados no banco
de dados, o sistema s iniciar o armazenamento aps o acionamento do boto Iniciar
Figura 3.4: processo
Captura, e esta captura pode ser parada clicando novamente sobre o mesmo boto, agora
identificado por Finalizar Captura.
Clicando sobre cada um desses Displays ou sobre a imagem do dispositivo, no caso do
sensor de presso, uma tela com informaes detalhadas e opo de gerao de Relatrios,
do sensor selecionado, ser aberta (Figura 3.6).
Nesta tela possvel visualizar valores de alguns campos principais, e at mesmo setar
novos valores para algumas tags que permitam escrita.
Tambm h a possibilidade de gerao de um relatrio com dados j coletados pelo
sensor, obedecendo alguns padres de formatao j definidos, assim como de extenso de
arquivo. Aps definidas as configuraes do relatrio, se clicarmos em Gerar Relatrio,
no menu inferior, uma Tela solicita o local a ser salvo e qual o nome do arquivo.
Outra opo existente no menu inferior Descrio do Dispositivo que mostra in-
formaes resumidas colhidas do manual do dispositivo, figuras3.7,3.8.
Figura 3.5: Configurao do Clock
3.3.2 Funcionamento em Background

O Elipse SCADA, possui uma linguagem de Script linguagem de computador inter-
pretada; linguagens de programao executadas em um interpretador que permitem a
execuo de aes conforme algum procedimento ocorra.
Em cada componente inserido, uma aba script(Figura 3.9), permite a insero desses
comandos, obedecendo a uma sintaxe padronizada pela ferramenta.
Neste contexto, alguns scripts foram desenvolvidos buscando otimizar o uso dos re-
cursos disponveis. A seguir ser descrito os scripts desenvolvido dentro de cada parte da
Aplicao.
Aplicao Principal
Ao ser iniciada a aplicao, um script carrega as ltimas informaes coletadas do

sistema para que no ocorra erros na primeira insero de novos registros no Banco de
Figura 3.6: Tela Detalhes
Figura 3.7: Telas de Informaes dos dispositivos TT302
Dados. No mesmo instante o sistema configura em cada Display, da Tela Principal, as

unidades matemticas utilizadas nas configuraes dos dispositivos de campo, atualiza
Figura 3.8: Telas de Informaes dos dispositivos LD302
os valor do nmero de registros armazenados no Banco de Dados, e fica em espera de

alguma interrupo solicitando o fechamento do sistema, seja ela a tecla Esc, Alt +
F4, ou boto Sair, quando isso ocorre, ele salva em uma Receita(conjunto de valores
pr-definidos que podem ser carregados para um grupo de tags a fim de configurar um
processo especfico) os ltimos valores armazenados e finaliza todo o sistema.
Componente Clock Relgio do Sistema
Este componente, no visual, foi inserido visando permitir, de forma independente, a

configurao do intervalo de amostragem de dados a ser armazenado no Banco de Dados.
Em seu script a cada vez que o contador estoura sua contagem ele executa o procedimento
de capturar o valor atual de cada tag selecionada para armazenamento e envia para o
banco. Este o primeiro gargalo do sistema, pois o tempo que cada registro demora
para ser confirmada a insero da ordem de dcimos de segundo, tornando o sistema
inoperante durante a realizao deste script.
Figura 3.9: Janela de Edio de Scripts da Aplicao
Variveis Locais
Como o Elipse SCADA no permite a criao de novas funes, criamos duas tags
no prprio sistema e com elas fizemos a converso de unidades utilizada nos sensores
baseada na configurao do campo. Para esta converso, de nmero inteiro para smbolo
matemtico, usamos a tabela de cdigo de unidades dos blocos funcionais, como podemos
ver nas tabelas 3.1 e 3.2.[Fieldbus 20 05]
Cdigo (Inteiro) Unidade de Tempreatura

1000 Kelvin
1001 Celsius
1002 Fahrenheit
1003 Rankine
Tabela 3.1: Tabela de Converso Inteiro X Unidade de Temperatura.

Cdigo (Inteiro) Unidade de Presso

1130 Pa
1132 Mpa
1133 kPa
1137 bar
1138 mbar
1139 torr
1140 atm
1141 psi
1144 gcm2
1145 kgfcm2
1147 inH2O 4 C
1148 inH2O 68 F
1150 mmH2O 4 C
1151 mmH2O 68 F
1154 ftH2O 68 F
Tabela 3.2: Tabela de Converso Inteiro X Unidade de Presso.
Boto Gerar Relatrio
Em seu script uma varivel temporria para armazenamento da string do caminho de

salvamento do arquivo criada, e o resultado de uma consulta ao banco armazenada
no arquivo selecionado pelo usurio. Aqui encontramos o segundo gargalo do sistema, a
gerao do relatrio, pois aps realizada a consulta devemos percorrer registro a registro
e concatenando-os para posteriormente serem armazenados no arquivo, isto pode levar
cerca de alguns segundos, podendo at travar o sistema caso existam muitos registros no
banco referentes a tal sensor.
3.3.3 Comunicao Supervisrio X Banco de Dados

Criao de Fonte de Dados ODBC
Para que houvesse a comunicao Supervisrio X Banco de Dados, se faz necess-

ria a criao de um driver ODBC, sendo criado da seguinte forma: A partir do Painel
de Controle do MS Windows XP, que pode ser acessado atravs da opo Configuraes
do Menu Iniciar do Windows, escolhe-se Ferramentas Administrativas e depois Fontes
de Dados ODBC(Figura 3.10); Na aba Fonte de Dados de Sistema, opta-se por Adicionar
uma nova fonte; Selecionando o driver PostgreSQL ANSI por ser o padro de driver re-
conhecido pelo Software Elipse; Preenche-se os campos respectivos da tela (Figura 3.11)
com os dados necessrio e assim finalizada a criao da conexo ODBC.
Figura 3.10: Administrador de Fonte de Dados do MS Windows XP
Figura 3.11: Janela de configurao da nova fonte de dados PostgreSQL ANSI ODBC
Driver criada
3.4 Validao do Sistema

Para o desenvolvimento de um Projeto Funcional de uma rede Foundation Fieldbus
deve-se seguir uma seqncia de passos, a qual se inicia com a criao de um esquema
lgico e em seguida sua implementao.
Um esquema lgico definido o planejamento de como sero utilizados os recursos
disponveis em sua rede industrial, dispositivos fsicos, sensores e atuadores, e o modo de
configur-los para atingir o objetivo pretendido.
Na implementao h a alocao, onde ns unimos as duas bases do esquema lgico,
ou seja, colocamos dentro dos sensores e atuadores, a configurao projetada.
Para validar o sistema, levantamos primeiramente os dispositivos disponveis na rede,
como visto na seo 3.1, e projetamos uma configurao simples na qual disponibilizaria
na rede a varivel analgica monitorada por cada sensor, alm das informaes sempre
existentes em cada dispositivo inserido.
3.4.1 Configurao de Rede Foundation Fieldbus

Atravs do Software Syscon que faz parte do Pacote System302 da SMAR possivel
realizar a configurao de uma Rede Foundation Fieldbus . Para tal deve-se inicialmente
realizar a conexo com a DFI302 e identificar quais instrumentos esto associados aos
canais da mesma.
No caso da Planta LAMP trabalhamos com dois canais da DFI302, sendo no primeiro
inserida a rede de sensores transmissores de presso e no canal dois a rede de transmisso-
res de temperatura, esta configurao pode ser vista na figura 3.12.
Em seguida associamos cada dispositivo a configurao do canal correspondente, e
em cada um deles instnciamos e parametrizamos cada bloco funcional.
Pode-se observar abaixo a parametrizao de alguns blocos disponveis para os dispo-
sitivos supra citados.
Em um Bloco Funcional de Diagnstico deve ser configurado obrigatoriamente o pa-
rmetro TARGET do grupo MODE_BLOCK, em nosso caso configuramos como AUTO,
indicando que o funcionamento do bloco ser feito maneira automtica.
Em um Bloco Funcional Tranducer (Transdutor) deve ser configurado obrigatoria-
mente o parmetro TARGET do grupo MODE_BLOCK, em nosso caso configuramos
como AUTO, indicando que o ser realizada a converso da varivel para um padro
interpretvel na rede.
Em um Bloco Funcional AI (Analog Input) deve ser configurado obrigatoriamente os
Figura 3.12: Config Syscon
parmetros:
TARGET do grupo MODE_BLOCK, em nosso caso configuramos como AUTO;

L_Type como DIRECT, o qual repassar para a rede o padro da converso reali-
zada pelo TRANSDUCER;
CHANNEL que indicar qual canal do sensor ser utilizado.
Em um Bloco Funcional Resource (Recursos) deve ser configurado obrigatoriamente

o parmetro TARGET do grupo MODE_BLOCK, em nosso caso configuramos como
AUTO, apenas para indicar de maneira automtica caractersticas do dispositivo.
Aps a configurao de cada dispositivo necessria a Ativao da Configurao,
onde ser criado o Servidor OPC, denominado Smar.DFIOLESerfver.0, e o mapeamento
de cada configurao criada ser feito.
Figura 3.13: Bloco Funcional de Diagnstico
Figura 3.14: Bloco Funcional Transdutor
3.4.2 Comunicao rede Foundation Fieldbus X Supervisrio

No Elipse Scada, inseriu-se um objeto OPCServer um cliente OPC que possibilita
a comunicao com um determinado equipamento ou dispositivo, utilizando o protocolo
OPC o que permitiu o envio e recebimento de dados de tags em tempo real, a comuni-
Figura 3.15: Bloco Funcional AI(Entrada Analgica)
Figura 3.16: Bloco Funcional de Recursos
cao ocorre com o servidor OPC configurado no computador que que instncia a lgica
do sistema, sendo que este captura as tags disponveis pela DFI 302.
Na figura 3.17 visualizamos o cliente OPC criado. Para sua configurao inicialmente
localiza-se um servidor, no caso deste trabalho Smar.DFIOLESerfver.0, em seguida im-
portamos as tags disponveis e relevantes para o sistema. Aqui importamos as seguintes
tags:
DIAG-1.DEV_SN o nmero serial do dispositivo acessado;

BLK-1.PRIMARY_VALUE_RANGE.EU_100 limite mximo possvel de ser me-
dido pelo sensor, sem danific-lo;

BLK-1.PRIMARY_VALUE_RANGE.EU_0 limite mnimo possvel de ser me-
dido pelo sensor, sem danific-lo;
BLK-1.PRIMARY_VALUE.VALUE valor atual da varivel medida;
BLK-1.PRIMARY_VALUE_RANGE.UNITS_INDEX unidade utilizada na para
quantificar o valor da varivel medida.
Figura 3.17: Cliente OPC do Elipse SCADA
Cada uma dessas tags sero manipuladas de forma transparente ao usurio como j
explicado na seo 3.3.2, fechando assim a comunicao cho de fbrica sistema super-
visrio.
3.4.3 Dados Inseridos no Banco

Nas imagens 3.18,3.19,3.20 visualiza-se parte dos dados que foram armazenados a
partir dos ensaio de testes realizados.
Figura 3.18: Tabela BufferEntrada

Figura 3.19: Tabela Recentes
Figura 3.20: Tabela Sensores

Captulo 4
Concluses
O trabalho desenvolvido permitiu uma interao direta com trs nveis da pirmide da
Autmomao, sendo eles: Nvel de sensores e atuadores, Controle Supervisrio e Geren-
ciamento. J os demais nveis, Controle Regulatrio, Alarme e Intertravamento, foram
estudados, apesar de no terem sido utilizados diretamente no trabalho.
Este trabalho permitiu a percepo de que o uso do software Supervisrio Elipse
SCADA, representa uma boa opo para o monitoramento das variveis do processo,
comunicao via OPC, Gerao de Histricos e Alarmes, entretanto no ponto armazena-
mento de dados em um BDR (Banco de Dados Relacional) deixa a desejar em velocidade,
por no ter a robustez suficiente funes mais rpidas de Insero, Remoo, Consultas,
Captura de dados armazenados, entre outras para trabalhar em conjunto com um BDR.
Essa crtica foi levada ao conhecimento dos desenvolvedores do Software durante o de-
senvolvimento deste trabalho, via contatos ocorridos com o Suporte Tcnico do Software
Elipse SCADA, e obteve-se a resposta de que realmente h esta deficincia, e um outro
software tambm desenvolvido pela Elipse, o Elipse E3, possui a robustez e o desempe-
nho desejado no armazenamento e manipulao de dados, alm de possuir um Banco de
Dados prprio incorporado ao sistema.
Considerando a falta de velocidade dos resultados na manipulao de dados junto
ao BDR, o supervisrio desenvolvido permitir validar trabalhos como [Silva 2005],
[Lima 2004], entre outros futuros, que fazem uso de qualidades intrnsecas a dispositi-
vos Foundation Fieldbus podendo ratificar tais teses.
Outro ganho para comunidade acadmica ser o banco de informaes comportamen-
tais de sensores no cho de fbrica, que ficar acessvel para futuros projetos na rea de
controle, previso de sries temporais, auto-calibrao de dispositivos sensores, infern-
cia de outras grandezas, estudo de padres de falhas, entre outras aplicaes.
Pode-se dizer ento para que se tenha um desempenho satisfatrio deve-se criar um
outro sistema que gere relatrios dos dados armazenados, e no armazenamento de dados
CAPTULO 4. CONCLUSES 44
criar um armazenamento de dados temporrio em arquivos e posteriormente repassar para

o banco de dados em momentos de finalizao do sistema, ou dentro de um intervalo de
tempo maior.
Captulo 5
Cronograma de Execuo
1. Integrao do software supervisrio do laboratrio, com o sistema desenvolvido;

2. Estudo e projeto do software de gerar relatrios;
3. Instalao da DFI e dos sensores da planta;
4. Instanciao de estratgias de controle nos sensores Foundation Fieldbus da rede;
5. Coleta de dados dos sensores;
6. Anlise de resultados;
7. Elaborao da monografia.
Atividades 3 Trimestre - 2007 4 Trimestre - 2007 1 Trimestre - 2008

1 X X
2 X X
3 X X
4 X
5 X
6 X
7 X X
Referncias Bibliogrficas
Elipse, Software (2007), Elipse scada - hmi/scada software - manual do usurio. Manual
do Usurio.
Fieldbus, Foundation (20 05), Manual de instrues dos blocos funcionais Foundation
Fieldbus.
Filho, Constantino Seixas (2000), A automao nos anos 2000 - uma anlise das novas
fronteiras da automao, Relatrio tcnico, ATAN Sistemas de Automao.
LAMP (2003), Manual terico - lamp - laboratrio de avaliao de medio em petrleo.

REde 10/01.
Lima, Fbio S. (2004), Estratgia de escalonamento de controladores pid baseado em

regras fuzzy para redes industriais foundation fieldbus usando blocos padres, Dis-
sertao de mestrado, Universidade Federal do Rio Grande do Norte.
Maitelli, Andr Laurindo (2003), Controladores lgicos programveis. Notas de aula da

disciplina Controladores Lgicos Programveis.
Neto, Alvaro Pereira (2003), Postgresql, tcnicas avanadas verso open source 7.x.
Neves, Denise Lemes Fernandes (2002), Postgresql, conceitos e aplicaes.
Silva, Ana Paula G. e Marcelo Salvador (2005), O que so sistemas supervisrios?

http://www.elipse.com.br/. Visitada em Novembro de 2007.
Silva, Diego Rodrigo Cabral (2005), Redes neurais artificiais no ambiente de redes indus-
triais Foundation Fieldbus usando blocos funcionais padres, Dissertao de mes-
trado, Universidade Federal do Rio Grande do Norte.
Silveira, Leonardo e Weldson Q. Lima (2003), Um breve histrico conceitual da automa-

o industrial e redes para automao industrial. Redes para Automao Industrial.
Universidade Federal do Rio Grande do Norte.
46
REFERNCIAS BIBLIOGRFICAS 47
Souza, Alessandro J. (2005), Sistema de gerncia de informao de processos industriais

via web, Dissertao de mestrado, Universidade Federal do Rio Grande do Norte.
Referncias Bibliogrficas
Elipse, Software (2007), Elipse scada - hmi/scada software - manual do usurio. Manual
do Usurio.
Fieldbus, Foundation (20 05), Manual de instrues dos blocos funcionais Foundation
Fieldbus.
Filho, Constantino Seixas (2000), A automao nos anos 2000 - uma anlise das novas
fronteiras da automao, Relatrio tcnico, ATAN Sistemas de Automao.
LAMP (2003), Manual terico - lamp - laboratrio de avaliao de medio em petrleo.

REde 10/01.
Lima, Fbio S. (2004), Estratgia de escalonamento de controladores pid baseado em

regras fuzzy para redes industriais foundation fieldbus usando blocos padres, Dis-
sertao de mestrado, Universidade Federal do Rio Grande do Norte.
Maitelli, Andr Laurindo (2003), Controladores lgicos programveis. Notas de aula da

disciplina Controladores Lgicos Programveis.
Neto, Alvaro Pereira (2003), Postgresql, tcnicas avanadas verso open source 7.x.
Neves, Denise Lemes Fernandes (2002), Postgresql, conceitos e aplicaes.
Silva, Ana Paula G. e Marcelo Salvador (2005), O que so sistemas supervisrios?

http://www.elipse.com.br/. Visitada em Novembro de 2007.
Silva, Diego Rodrigo Cabral (2005), Redes neurais artificiais no ambiente de redes indus-
triais Foundation Fieldbus usando blocos funcionais padres, Dissertao de mes-
trado, Universidade Federal do Rio Grande do Norte.
Silveira, Leonardo e Weldson Q. Lima (2003), Um breve histrico conceitual da automa-

o industrial e redes para automao industrial. Redes para Automao Industrial.
Universidade Federal do Rio Grande do Norte.
46
REFERNCIAS BIBLIOGRFICAS 47
Souza, Alessandro J. (2005), Sistema de gerncia de informao de processos industriais

via web, Dissertao de mestrado, Universidade Federal do Rio Grande do Norte.
ANEXO II
HISTRICO ESCOLAR
SIGAA - Sistema Integrado de Gesto de Atividades Acadmicas
UFRN - Universidade Federal do Rio Grande do Norte
PROGRAD - Pro-Reitoria de Graduao
DAE - Departamento de Administrao Escolar
Campus Universitrio Lagoa Nova - CEP 59072-970 - Natal - RN - Brasil
Histrico Escolar - Emitido em: 18/02/2008 s 15:19h

Dados Pessoais
Nome: JEFERSON RIBEIRO DOS SANTOS JUNIOR Matrcula 200320017
Data de Nascimento: 15/10/1984 Local de Nascimento: RIO GRANDE DO NORTE
Nome do Pai: JEFERSON RIBEIRO DOS SANTOS
Nome da Me: VALQUIRIA APARECIDA DOS SANTOS
Endereo: RUA MANOEL DE PININHA, 145 Bairro: PONTA NEGRA
Municpio: NATAL UF: RN
Dados do Curso
Curso: ENGENHARIA DE COMPUTACAO - NATAL - PRESENCIAL - FORMAO - AUTOMACAO INDUSTRIAL - MTN
Currculo: 02 Status: ATIVO - GRADUANDO IRA: 7,8188

Reconhecimento do Curso: PORTARIA N 1.515
Data do Decreto: 16/07/2001 D.O.U.: 18/07/2001
Ano/Perodo Letivo Inicial: 2003.2
Forma de Ingresso: VESTIBULAR
Perodo Letivo Atual: 10 Prazo para Concluso: 20121
Trancamentos: Nenhum Perfil Inicial: 0
Prorrogaes: 0 perodos letivos
Ano/Perodo Letivo de Sada: Participou do ENADE:
Tipo Sada: Data da Colao de Grau:
Trabalho de Concluso de Curso:
Componentes Curriculares Cursadas/Cursando

Ano/Per Componente Curricular CH Turma Freq % Nota Situao
2003.2 DIM0322 INTRODUCAO A ENGENHARIA DE SOFTWARE 60 01 100.0 8.8 APROVADO
2003.2 DIM0323 MATEMATICA DISCRETA PARA COMPUTACAO 60 01 100.0 8.2 APROVADO
2003.2 DIM0324 CONCEITOS E TECNICAS DE PROGRAMACAO 60 01 100.0 9.8 APROVADO
2003.2 DIM0325 LABORATORIO DE CONCEITOS E TECNICAS DE PROGRAMACAO 45 02 100.0 9.5 APROVADO
2003.2 ELE0425 CIRCUITOS LOGICOS COMBINACIONAIS 60 01 95.0 8.4 APROVADO
2003.2 ELE0426 LABORATORIO DE CIRCUITOS LOGICOS COMBINACIONAIS 45 01 93.33 8.9 APROVADO
2003.2 MAT0228 CALCULO DIFERENCIAL E INTEGRAL I 90 01 100.0 7.7 APROVADO
2004.1 DIM0326 ALGORITMOS E ESTRUTURAS DE DADOS I 60 01 100.0 7.5 APROVADO
2004.1 DIM0327 LABORATORIO DE ALGORITMOS E ESTRUTURAS DE DADOS I 45 02 100.0 9.6 APROVADO
2004.1 ELE0427 CIRCUITOS LOGICOS SEQUENCIAIS 60 01 100.0 9.1 APROVADO
2004.1 ELE0428 LABORATORIO DE CIRCUITOS LOGICOS SEQUENCIAIS 45 01 100.0 9.0 APROVADO
2004.1 MAT0005 CALCULO DIFERENCIAL E INTEGRAL II 90 01 100.0 7.5 APROVADO
2004.1 MAT0230 GEOMETRIA ANALITICA E ALGEBRA LINEAR 90 01 96.66 7.0 APROVADO
2004.2 DCA0404 ARQUITETURA DE COMPUTADORES 60 01 100.0 7.3 APROVADO
2004.2 DCA0429 ANALISE DE SISTEMAS LINEARES 90 01 95.55 5.2 APROVADO
2004.2 DCA0430 CONTEXTO SOCIAL E PROFISSIONAL DA ENGENHARIA 30 01 100.0 6.3 APROVADO
2004.2 DIM0050 LOGICA APLICADA A COMPUTACAO 60 01 100.0 8.7 APROVADO
2004.2 DIM0328 ALGORITMOS E ESTRUTURAS DE DADOS II 60 01 100.0 5.1 APROVADO
2004.2 DIM0329 LABORATORIO DE ALGORITMOS E ESTRUTURAS DE DADOS II 45 02 100.0 9.0 APROVADO
2004.2 FIS0317 ELEMENTOS DE ELETRICIDADE E MAGNETISMO 60 01 80.0 3.1 REPROVADO
2005.1 DCA0451 COMPUTACAO NUMERICA 60 01 93.33 7.3 APROVADO
2005.1 e DIM0049 TEORIA DA COMPUTACAO 60 01 93.33 7.2 APROVADO
2005.1 DIM0056 SOFTWARE BASICO 60 01 96.66 9.2 APROVADO
2005.1 EST0322 ESTATISTICA APLICADA A INFORMATICA 60 01 96.66 9.1 APROVADO
2005.1 FIS0317 ELEMENTOS DE ELETRICIDADE E MAGNETISMO 60 01 90.0 7.8 APROVADO
2005.1 MEC0404 MECANICA DOS SOLIDOS 90 01 97.77 7.0 APROVADO
2005.2 DCA0403 SISTEMAS DE TRANSMISSAO DE DADOS 60 01 100.0 8.2 APROVADO
2005.2 DCA0431 TEORIA DE CIRCUITOS 60 01 100.0 7.1 APROVADO
2005.2 DIM0338 SISTEMAS OPERACIONAIS 90 01 91.11 9.0 APROVADO
2005.2 DIM0339 COMPILADORES 90 01 100.0 4.5 REPROVADO
Para verificar a autenticidade deste documento entre em http://www.sigaa.ufrn.br/documentos/ informando a Pgina 1 de 2

matrcula, data de emisso e o cdigo de verificao: f11b375c15
SIGAA - Sistema Integrado de Gesto de Atividades Acadmicas
UFRN - Universidade Federal do Rio Grande do Norte
PROGRAD - Pro-Reitoria de Graduao
DAE - Departamento de Administrao Escolar
Campus Universitrio Lagoa Nova - CEP 59072-970 - Natal - RN - Brasil
Histrico Escolar - Emitido em: 18/02/2008 s 15:19h

Nome: JEFERSON RIBEIRO DOS SANTOS JUNIOR Matrcula: 200320017
Componentes Curriculares Cursadas/Cursando

Ano/Per Componente Curricular CH Turma Freq % Nota Situao
2005.2 DIM0340 FORMACAO HUMANISTICA EM COMPUTACAO 30 01 83.33 8.5 APROVADO
2005.2 FIS0316 FISICA EXPERIMENTAL II 45 11 93.33 8.2 APROVADO
2005.2 FIS0318 ELEMENTOS DE OTICA E ONDAS 60 01 100.0 7.3 APROVADO
2006.1 # CON0002 CONTABILIDADE APLICADA A ADMINISTRACAO 60 02 100.0 6.5 APROVADO
2006.1 DCA0409 PROGRAMACAO EM TEMPO REAL 60 01 96.66 10.0 APROVADO
2006.1 DCA0433 MODELAGEM E ANALISE DE SISTEMAS DINAMICOS 60 01 93.33 6.5 APROVADO
2006.1 DCA0450 REDES DE COMPUTADORES 60 01 100.0 7.0 APROVADO
2006.1 DCA0900 INTELIGENCIA ARTIFICIAL APLICADA 60 01 100.0 7.5 APROVADO
2006.1 DIM0342 ALGORITMOS E ESTRUTURAS DE DADOS III 60 01 83.33 5.0 APROVADO
2006.1 ELE0401 ELETRONICA BASICA 60 01 96.66 5.9 APROVADO
2006.1 ELE0434 LABORATORIO DE ELETRONICA BASICA 30 02 100.0 8.4 APROVADO
2006.1 # EST0220 ESTATISTICA APLICADA A ADMINISTRACAO I 60 02 100.0 9.3 APROVADO
2006.2 DCA0435 COMPUTACAO GRAFICA 60 01 93.33 8.0 APROVADO
2006.2 DCA0436 SISTEMAS DE CONTROLE 60 01 93.33 6.6 APROVADO
2006.2 DCA0437 LABORATORIO DE SISTEMAS DE CONTROLE 30 02 100.0 9.1 APROVADO
2006.2 * DCA0444 PROJETO DE SISTEMAS MICROCONTROLADOS 60 01 90.0 8.9 APROVADO
2006.2 * DIM0095 TOPICOS ESPECIAIS EM COMPUTACAO VI 60 01 100.0 5.6 APROVADO
2006.2 * DIM0096 TOPICOS ESPECIAIS EM COMPUTACAO VII 60 01 100.0 7.4 APROVADO
2006.2 DIM0339 COMPILADORES 90 01 100.0 7.9 APROVADO
2007.1 * DCA0406 REDES DE COMPUTADORES II 90 01 100.0 8.9 APROVADO
2007.1 * DCA0407 INSTRUMENTACAO PARA CONTROLE E AUTOMACAO 60 01 100.0 9.4 APROVADO
2007.1 * DCA0420 LINGUAGEM DE DESCRICAO DE HARDWARE 60 01 96.66 9.6 APROVADO
2007.1 * DCA0449 TOPICOS ESPECIAIS EM REDES DE COMPUTADORES 60 01 93.33 7.0 APROVADO
2007.1 * DCA0453 PROCESSAMENTO DIGITAL DE SINAIS 60 01 100.0 7.7 APROVADO
2007.1 * DCA0454 REDES NEURAIS ARTIFICIAIS 60 01 100.0 8.0 APROVADO
2007.1 DIM0345 EMPREENDEDORISMO 60 01 98.33 8.9 APROVADO
2007.2 # DCA0401 REDES DE SENSORES SEM FIO 60 01 -- -- TRANCADO
2007.2 * DCA0443 CONTROLADORES LOGICOS PROGRAMAVEIS 60 01 100.0 9.3 APROVADO
2007.2 @ DCA0990 ESTAGIO SUPERVISIONADO 165 -- 100.0 10.0 APROVADO
2007.2 * DEF0650 ATIVIDADE FISICA, SAUDE E QUALIDADE DE VIDA 60 06 90.0 7.6 APROVADO
2007.2 * DEQ0376 INTRODUCAO A ENGENHARIA DE PETROLEO 60 01 100.0 8.9 APROVADO
2007.2 & MEC0015 METROLOGIA 60 01 93.33 7.3 APROVADO
Legenda:
* Comp. Optativo e Comp. Equivalente a Obrig. & Comp. Equivalente a Optativo # Comp. Eletivo @ Ativ. Obrigatria Ativ. Optativa
Obrigatrias Complementares
Total
Comp. Curricular Atividade Comp.Curricular/Atividade
CR CH CH CH CR CH
Exigido 171 2565 165 900 171 3630
Integralizado 171 2565 165 975 171 3705
Pendente 0 0 0 0 0 0
Componentes Curriculares Obrigatrios Pendentes: 0

No h componentes curriculares obrigatrios pendentes
Equivalncias:
Cumpriu DIM0337 - COMPUTABILIDADE (45h) atravs de DIM0049 - TEORIA DA COMPUTACAO (60h)
Ateno, agora o histrico possui uma verificao automtica de autenticidade e consistncia, sendo portanto
dispensvel a assinatura do coordenador ou do DAE. Favor, ler instrues no rodap.
Para verificar a autenticidade deste documento entre em http://www.sigaa.ufrn.br/documentos/ informando a Pgina 2 de 2

matrcula, data de emisso e o cdigo de verificao: f11b375c15
ANEXO III
PUBLICAES
Sem Publicaes

Sistema Integrado de Monitoreo Fieldbus para Procesos de Medición en La Industria Petrolera

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Sistema Integrado de Monitoreo Fieldbus para Procesos de Medición en La Industria Petrolera

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

Sistema Integrado de Monitoramento de Instrumentos

Jeferson Ribeiro dos Santos Jnior - GRA

Sistema Integrado de Monitoramento de

Jeferson Ribeiro dos Santos Jnior

Orientador: Prof. Dr. Jorge Dantas de Melo

Co-orientador: Prof. Dr. Adrio Duarte Dria Neto

Relatrio de Estgio Supervisionado apre-

Natal/RN, 14 dezembro de 2007

O presente trabalho tem o objetivo de apresentar o projeto e a implementao de um

Lista de Figuras iii

1.1 Pirmide hierrquica dos sistemas de automao . . . . . . . . . . . . . . 3

2.1 Modelo OSI X Foundation Fieldbus . . . . . . . . . . . . . . . . . . . . 7

3.1 Ligao entre a rede e os instrumentos do Laboratrio A . . . . . . . . . 25

2.1 Nomenclatura dos principais blocos funcionais do padro Foundation Fi-

3.1 Tabela de Converso Inteiro X Unidade de Temperatura. . . . . . . . . . 33

1.1 Sistemas de Automao Industrial

Para uma dona de casa, a mquina de lavar roupa ou lavar loua.

1. Qualidade: ao se produzir em uma faixa de tolerncia falhas estreita atravs de

3. Flexibilidade: consiste na capacidade de admitir com facilidade e rapidez, altera-

1.1.1 Breve Retrospecto

de processos contnuos, em batelada e de manufatura requer normas e produtos diferen-

1.1.2 Nveis de Hierarquia em Sistemas de Automao

Figura 1.1: Pirmide hierrquica dos sistemas de automao

Processos Fsicos: Consiste na base da pirmide, estando presente em todos os siste-

1.2 Objetivos e Localizao do Trabalho

de trs destas tecnologias: Foundation Fieldbus , MODBus RTU e ponto-a-ponto(Serial).

1.3 Estrutura do Trabalho

Neste captulo sero descritos os conhecimentos tericos levados em conta para o

2.1 Comunicao entre Processos Industriais Protocolo

2.1.1 Caractersticas da Tecnologia

independentemente do fabricante, no mesmo sistema sem a mnima perda de funcionali-

Os nveis 3 ao 6 do modelo OSI no so implementados na tecnologia Foundation

Figura 2.1: Modelo OSI X Foundation Fieldbus

2.1.2 Camada Fsica

Os dados da tecnologia Foundation Fieldbus podem trafegar junto da energia que

2.1.3 Camada de Comunicao

Dispositivos bsicos, que so os sensores, atuadores, entre outros;

Um LAS um dispositivo que controla de forma determinstica os tempos que os dis-

2.1.4 Camada do Usurio

cada, baseada em blocos e tecnologia de descrio de dispositivos. A Camada de Usurio

A Tabela 2.1 apresenta a nomenclatura de alguns dos principais blocos funcionais

2.2 OLE For Process Control - OPC

Exchange for Ethernet. Esta especificao tem a finalidade de definir a comunica-

At ento, esta comunicao no possvel sem a utilizao de um cliente e uma

2.2.2 Interfaces de Acesso ao Servidor

Padronizao das interfaces de comunicao entre os servidores e clientes de dados

2.2.3 Aspectos Prticos para Utilizao do Padro OPC

Plataforma Windows ou no?

Basicamente, o padro OPC nativo da plataforma Windows. Dentro desta plata-

Cliente ou Servidor OPC?

As aplicaes e produtos existentes no mercado podem ser somente um cliente, um

Nmero de Clientes x Nmero de Servidores

O nmero de servidores OPC necessrios para uma determinada aplicao ir depen-

Formato de Dados OPC (Time Stamp e Qualidade)

Quatro bits fornecem um detalhamento do estado apresentado, tais como NotConnec-

Configurao dos dados OPC no Cliente

Normalmente, os produtos de mercado no permitem muita flexibilidade para a con-

Criao de grupos e itens OPC: Basicamente, todos os dados OPC so chama-

2.3 Sistemas Supervisrios

2.3.1 Componentes Fsicos de um Sistema de Superviso

Figura 2.2: Sistema de superviso e controle

2.3.2 Componentes Lgicos de um Sistema SCADA