DaniloCS DISSERT - Unlocked

UNIVERSIDADE DO RIO GRANDE DO NORTE FEDERAL
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE TECNOLOGIA
PROGRAMA DE PS-GRADUAO EM ENGENHARIA ELTRICA
Sistema Especialista para Supresso Online de
Alarmes em Processos Industriais
Danilo Curvelo de Souza
Orientador: Prof. Dr. Adrio Duarte Dria Neto
Co-orientador: Prof. Dr. Jorge Dantas de Melo
Dissertao de Mestrado apresentada ao
Programa de Ps-Graduao em Engenharia
Eltrica e de Computao da UFRN (rea de
concentrao: Engenharia de Computao)
como parte dos requisitos para obteno do
ttulo de Mestre em Cincias.
Natal, RN, fevereiro de 2013
Diviso de Servios Tcnicos
Catalogao da publicao na fonte. UFRN / Biblioteca Central Zila Mamede
Souza, Danilo Curvelo de.
Sobre a Preparao de Propostas de Tema, Dissertaes e Teses no Programa
de Ps-Graduao em Engenharia Eltrica da UFRN / Danilo Curvelo de Souza
- Natal, RN, 2013
23 p.
Orientador: Adrio Duarte Dria Neto
Co-orientador: Jorge Dantas de Melo
Tese (doutorado) - Universidade Federal do Rio Grande do Norte. Centro
de Tecnologia. Programa de Ps-Graduao em Engenharia Eltrica e de Com-
putao.
1. Redao tcnica - Tese. 2. L
A
T
E
X- Tese. I. Melo, Sicrano Matosinho de. II.
Amaral, Beltrano Catandura do. III. Ttulo.
RN/UF/BCZM CDU 004.932(043.2)
Sistema Especialista para Supresso Online de
Alarmes em Processos Industriais
Danilo Curvelo de Souza
Dissertao de Mestrado aprovada em 01 de fevereiro de 2013 pela banca examinadora
composta pelos seguintes membros:
Prof. Dr. Adrio Duarte Dria Neto (orientador) . . . . . . . . . . . . . . . . DCA/UFRN
Prof. Dr. Jorge Dantas de Melo (co-orientador) . . . . . . . . . . . . . . . . . . DCA/UFFN
Prof. Dr. Luiz Affonso Henderson Guedes de Oliveira . . . . . . . . . . DCA/UFRN
Prof. Dr. Diego Rodrigo Cabral Silva . . . . . . . . . . . . . . . . . . . . . . . . . . ECT/UFRN
Prof. Dr. Mrio Cesar Mello Massa de Campos . . . . . . CENPES/PETROBRAS
Agradecimentos
Ao meu orientador e ao meu co-orientador, Dr. Adrio Duarte Dria Neto e Dr. Jorge
Dantas de Melo, sou grato pela orientao.
Ao professores Dr. Luiz Affonso Henderson Guedes e Dr. Diego Rodrigo Cabral Silva
pelas crticas e sugestes.
s sugestes do Dr. Mrio Campos quanto a defesa da dissertao.
Ao apoio tcnico de Kaku Saito e a equipe do CENPES-PETROBRAS.
Aos amigos do Laboratrio de Informtica Industrial, pela assistncia e incentivos forneci-
dos durante o planejamento e desenvolvimento desse trabalho.
minha famlia pelo apoio durante esta jornada.
minha namorada, Carla, por sempre me proporcionar momentos felizes.
Aos Top & Amigos pelos momentos de diverso e descontrao.
CAPES, pelo apoio nanceiro.
Resumo
A operao de processos industriais vem se tornando mais complexa ao longo dos
anos, e um dos elementos que possibilitam este aumento de complexidade a integrao
de novas tecnologias e solues inteligentes empregadas no setor, como o caso dos
sistemas de apoio deciso.
Neste sentido, esta dissertao visa o desenvolvimento de um sistema de auxlio
operao baseado em uma ferramenta computacional chamada de sistema especialista. O
objetivo principal tornar a operao mais convel e segura ao maximizar a quantidade
de informaes relevantes a cada situao atravs da utilizao de um sistema especialista
baseado em regras pr-moldadas para uma determinada rea de conhecimento. Para a
modelagem de tais regras foi proposto um ambiente de alto-nvel, que permite a criao e
manipulao de regras de forma facilitada atravs de programao visual.
A despeito de sua ampla gama de possveis aplicaes, esta dissertao tem como
foco o contexto de ltragem em tempo real de alarmes durante a operao, devidamente
validada em um estudo de caso baseado em um cenrio real ocorrido em uma planta
industrial de uma renaria de petrleo e gs.
Palavras-chave: sistema especialista, sistema baseado emregras, motor de inferncia,
regras, gerenciamento de alarmes, supresso de alarmes.
Abstract
Operating industrial processes is becoming more complex each day, and one of the
factors that contribute to this growth in complexity is the integration of new technologies
and smart solutions employed in the industry, such as the decision support systems.
In this regard, this dissertation aims to develop a decision support system based on an
computational tool called expert system. The main goal is to turn operation more reliable
and secure while maximizing the amount of relevant information to each situation by
using an expert system based on rules designed for a particular area of expertise. For
the modeling of such rules has been proposed a high-level environment, which allows the
creation and manipulation of rules in an easier way through visual programming.
Despite its wide range of possible applications, this dissertation focuses only in the
context of real-time ltering of alarms during the operation, properly validated in a case
study based on a real scenario occurred in an industrial plant of an oil and gas renery.
Keywords: expert system, rule-based system, inference engine, rules, alarm manage-
ment, alarm ltering.
Sumrio
Sumrio i
Lista de Figuras iii
Lista de Tabelas v
Lista de Smbolos e Abreviaturas vii
1 Introduo 1
1.1 Objetivo da Dissertao . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Fundamentao Terica 5
2.1 Sistemas de Apoio Deciso . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Sistemas Especialistas . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Sistemas Baseados em Regras de Produo . . . . . . . . . . . . 9
2.3 Sistemas de Alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 Estratgias de Inibio de Alarmes . . . . . . . . . . . . . . . . . 16
3 Sistema Desenvolvido 17
3.1 Tecnologias Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1 BR-Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.2 Linguagem Java . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.3 Visual Library . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.4 JBoss Drools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Arquitetura e Aplicao Proposta . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 Sistema Especialista Baseado em Regras . . . . . . . . . . . . . 21
3.2.2 Ambiente de Construo de Regras . . . . . . . . . . . . . . . . 22
3.2.3 Tela de Monitoramento de Alarmes . . . . . . . . . . . . . . . . 30
i
4 Resultados 33
4.1 Desempenho do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.1 Teste I: Incremento de Fatos . . . . . . . . . . . . . . . . . . . . 34
4.1.2 Teste II: Incremento de Regras . . . . . . . . . . . . . . . . . . . 35
4.1.3 Teste III: Incremento de Disparos . . . . . . . . . . . . . . . . . 36
4.2 Estudo de Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.1 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2 Soluo Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.3 Anlise de Resultados . . . . . . . . . . . . . . . . . . . . . . . 40
5 Consideraes Finais e Perspectivas Futuras 43
Referncias bibliogrcas 45
Lista de Figuras
1.1 Crescimento da quantidade de alarmes controlados por operador ao longo
dos anos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Subgrupos da Inteligncia Articial (IA). . . . . . . . . . . . . . . . . . 7
2.2 Arquitetura tpica de um sistema especialista. . . . . . . . . . . . . . . . 8
2.3 Arquitetura tpica de um sistema especialista baseado em regras. . . . . . 10
2.4 Rede de Rete obtida do exemplo dado. . . . . . . . . . . . . . . . . . . . 12
3.1 Arquitetura do BRTools. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Tela do BRTools sem plug-ins e com plug-ins executando. . . . . . . . . . 18
3.3 Arquitetura proposta do BR-PlantExpert. . . . . . . . . . . . . . . . . . . 21
3.4 Organizao das regras no contexto da aplicao. . . . . . . . . . . . . . 22
3.5 Blocos funcionais disponveis na aplicao. . . . . . . . . . . . . . . . . 23
3.6 Painel de congurao do bloco de alarmes e eventos. . . . . . . . . . . . 24
3.7 Painel de congurao do bloco de varivel de processo. . . . . . . . . . 25
3.8 Painel de congurao do bloco de estado. . . . . . . . . . . . . . . . . . 26
3.9 Operadores disponveis na construo de regras. . . . . . . . . . . . . . . 26
3.10 Exemplo de modelagem hierrquica de uma planta industrial. . . . . . . . 27
3.11 Interface grca do ambiente de construo de regras. . . . . . . . . . . . 28
3.12 Interface de traduo acoplando o ambiente de construo de regras ao
sistema especialista. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.13 Exemplo de uma regra modelada utilizando programao visual. . . . . . 29
3.14 A mesma regra da Figura 3.13 traduzida para linguagem DRL. . . . . . . 30
3.15 Interface grca da interface de visualizao de alarmes. . . . . . . . . . 31
4.1 Grco dos resultados obtidos no Teste I. . . . . . . . . . . . . . . . . . 35
4.2 Grco dos resultados obtidos no Teste II. . . . . . . . . . . . . . . . . . 36
4.3 Grco dos resultados obtidos no Teste III. . . . . . . . . . . . . . . . . 37
4.4 Histrico de real de Alarmes/Hora na ocorrncia de um trip no forno. . . 38
4.5 Representao temporal dos alarmes e eventos do cenrio estudado. . . . 39
iii
4.6 Estrutura das regras modeladas para o estudo de caso. . . . . . . . . . . . 40
4.7 Exemplo da tela de visualizao de alarmes sem ( esquerda) e com (
direita) o sistema de regras em execuo. . . . . . . . . . . . . . . . . . . 41
Lista de Tabelas
2.1 Valores ideais e mximos de alarmes por operador por unidades de tempo. 15
4.1 Informaes dos testes de desempenho realizados. . . . . . . . . . . . . . 34
4.2 Resultados do Teste I (em milisegundos). . . . . . . . . . . . . . . . . . 35
4.3 Resultados do Teste II (em milisegundos). . . . . . . . . . . . . . . . . . 35
4.4 Resultados do Teste III (em milisegundos). . . . . . . . . . . . . . . . . . 36
4.5 Resultado da supresso em um intervalo de 1h. . . . . . . . . . . . . . . 40
4.6 Resultado da supresso em um dado instante. . . . . . . . . . . . . . . . 41
v
Lista de Smbolos e Abreviaturas
API: Application Programming Interface
DRL: Drools Rule Language
DSS: Decision Support System
ECA: Evento - Condio - Ao
EEMUA: Engineering Equipment and Materials Users Association
GUI: Graphical User Interface
HSE: Health and Safety Executive
ISA: International Society of Automation
JVM: Java Virtual Machine
PES: Programmable Electronic System
SAD: Sistema de Apoio Deciso
SGRN: Sistema de Gerenciamento de Regras de Negcio
SI: Sistema de Informao
vii
Captulo 1
Introduo
O aumento da complexidade dos processos industriais e das novas tecnologias em-
pregadas no setor petroqumico torna pertinente a adoo de novos sistemas auxiliares
de apoio operao e ao processo de tomada de deciso. Diversos elementos concor-
rem para este aumento de complexidade, desde a incorporao de padres mais restritivos
para emisso de poluentes, menor desperdcio de matria-prima e de consumo de energia,
busca por acrscimo de produtividade e at mesmo o aparecimento de novos desaos tec-
nolgicos, tais como os existentes para a explorao e produo de leo e gs na camada
pr-sal.
Assim, empresas do ramo industrial cada vez mais investem em novas tecnologias
objetivando a melhoria do desempenho, da produtividade, da ecincia, da qualidade e da
segurana operacional de seus processos. Dentre estas novas tecnologias esto os sistemas
computacionais auxiliares, permitindo assim uma reduo nos ndices de falhas humanas.
Neste contexto, o processo de tomada de deciso dos setores ttico e estratgico de
uma organizao industrial passou por vrias mudanas no decorrer das ltimas dcadas,
mudana que est diretamente relacionada incorporao da informtica em seus proces-
sos, permitindo, assim, atender a necessidade de se obter respostas rpidas e at mesmo
inteligentes a partir dos sistemas utilizados.
Visando ainda um acrscimo relacionado a segurana operacional, os processos en-
volvidos no ramo industrial normalmente so monitorados por um grande conjunto de
alarmes que so usualmente projetados e implantados sem uma losoa formal de geren-
ciamento [Devries 2010]. A no utilizao de uma metodologia formal, normalmente
baseada na intuio e no conhecimento prvio dos operadores envolvidos nos proces-
sos, somada a adoo dos PES (sistemas eletrnicos programveis) que torna a adio de
novos alarmes uma tarefa de baixo custo, acaba por promover a gerao simultnea de
mltiplos alarmes na ocorrncia de determinados eventos.
Deste modo, ao expor o operador ao processamento de uma grande quantidade de
2 CAPTULO 1. INTRODUO
informao em pequenos intervalos de tempo, o mesmo se torna passvel de erros, como
o caso da no identicao de um alarme crtico. Como mostra o estudo feito por Habibi
& Hollield (2006) (Figura 1.1), existe um crescente aumento na quantidade de alarmes
controlados por operador ao longo dos anos, fato que pode vir a promover a ocorrncia
de diferentes incidentes, tais como danos ao meio ambiente ou perda de produo.
Figura 1.1: Crescimento da quantidade de alarmes controlados por operador ao longo dos
anos.
Devido a esse rpido crescimento na quantidade de alarmes controlados por um opera-
dor, solues que visam o problema da sobrecarga de informaes ganharam bastante im-
portncia no ambiente industrial. Uma das solues voltadas a resoluo deste problema
so as estratgias de inibio de alarmes, onde, a partir da deteco de certos cenrios,
determinados alarmes so suprimidos.
Desta maneira, sistemas que possam auxiliar o monitoramento e a operao de proces-
sos industriais so cada vez mais requisitados pelas empresas do ramo, e a m de atender
essa demanda o trabalho realizado nesta dissertao visa aplicar solues computacionais
inteligentes ao problema da supresso online de alarmes em processos industriais.
1.1. OBJETIVO DA DISSERTAO 3
1.1 Objetivo da Dissertao
O objetivo principal do desenvolvimento deste tema de dissertao apresentar uma
ferramenta responsvel por auxiliar o monitoramento e a tomada de deciso em processos
industriais. No cenrio industrial atual, a ausncia de sistemas ecazes que priorizem in-
formaes importantes e minimizem informaes redundantes durante a operao acabam
resultando em aes falhas e/ou lentas por parte dos operadores. No entanto, a incorpo-
rao de sistemas auxiliares de operao no uma tarefa fcil, no sentido em que o
funcionamento de sistemas onlines durante a operao considerada crtica, e seu mau
funcionamento pode acarretar graves consequncias.
Neste sentido, esta dissertao visa o desenvolvimento de um sistema de auxlio
operao baseado em uma soluo computacional chamada de sistema especialista. O
objetivo principal tornar a operao mais convel e segura ao priorizar informaes e
ltrar noticaes irrelevantes durante a operao a partir do conhecimento armazenado
de especialistas no processo. Este conhecimento armazenado atravs da utilizao de
regras de produo, e o sistema proposto com o intuito de minimizar o custo de prover
esse conhecimento oferece um ambiente de programao de regras de alto nvel, funda-
mentado na utilizao da programao visual. Essa abordagem objetiva viabilizar o seu
emprego em ambientes industriais, onde os especialistas no problema podem desenvolver
as suas regras sem a necessidade de conhecimento especco de programao. Desta
forma, diferentes aplicaes podem ser denidas para este sistema, tais como a deteco
de falhas, o diagnstico automatizado e a supresso de alarmes.
A despeito de sua ampla gama de possveis aplicaes, esta dissertao tem como foco
o contexto de ltragem seletiva em tempo real de alarmes de acordo com o estado atual
do processo. Essa abordagem caracteriza-se como uma grande inovao tecnolgica na
rea de automao industrial e de segurana operacional de processos.
1.2 Estrutura do Trabalho
Alm deste captulo introdutrio, que buscou apresentar o escopo no qual o tema desta
dissertao est inserido, este trabalho apresenta mais quatro captulos.
O Captulo 2 apresenta o embasamento terico necessrio para o completo entendi-
mento do sistema apresentado nesta dissertao. Em uma primeira seo os sistemas de
apoio deciso so apresentados, seguidos de uma explicao da ferramenta computa-
cional chamada de sistema especialista. Por m, a ltima seo deste captulo contempla
um estudo terico do cenrio atual dos chamados sistemas de alarmes, objetivando-se
4 CAPTULO 1. INTRODUO
apresentar a rea de atuao da aplicao proposta.
O Captulo 3 consiste na apresentao do sistema proposto. Este captulo contem-
pla todos os aspectos da ferramenta, como as tecnologias utilizadas, a arquitetura, e a
aplicao proposta.
O Captulo 4 rene os resultados obtidos atravs de testes e experimentos realizados
utilizando-se a ferramenta desenvolvida. So apresentados os resultados de trs testes
de desempenho do sistema, destacando suas principais caractersticas positivas e tambm
suas limitaes. Alm disso tambm apresenta um estudo de caso com dados de um
processo industrial real a m de se validar a ferramenta.
Por m, o Captulo 5 resume as principais concluses sobre o trabalho desenvolvido.
As contribuies desta dissertao so apresentadas, bem como sugestes para trabalhos
que poderiam dar continuidade a ela.
Captulo 2
Fundamentao Terica
Este captulo introduz os conceitos tericos em que o sistema apresentado nesta dis-
sertao est inserido. Esta ferramenta classicada como um sistema de apoio deciso
em processos industriais, e seu principal processamento realizado pela ferramenta com-
putacional chamada de sistema especialista. Tais denies sero apresentadas nas sees
seguintes, separadas em sistemas de apoio deciso e sistemas especialistas, respectiva-
mente. No mbito da aplicao escolhida, a supresso de alarmes, conceitos acerca de
sistemas de alarmes so apresentadas na sequncia.
2.1 Sistemas de Apoio Deciso
A tomada de decises em sistemas complexos, como o caso dos processos industri-
ais, muitas vezes supera a capacidade cognitiva humana. Apesar de interaes individuais
entre as variveis de um sistema normalmente bem entendido, a previso de como o sis-
tema vai reagir a uma manipulao externa muitas vezes difcil.
H uma quantidade substancial de evidncias empricas de que o julgamento intuitivo
humano e sua tomada de deciso esto longe de ser ideal, e se deteriora ainda mais com
a complexidade e estresse [Druzdzel & Flynn 2002]. Como em muitas situaes, a qua-
lidade das decises importante, tornando assim o auxlio s decincias de julgamento
humano e a tomada de decises um foco importante no mbito da automao industrial
ao longo dos anos.
Disciplinas como estatstica, economia e pesquisa operacional tmdesenvolvido vrios
mtodos para fazer escolhas racionais. Mais recentemente, estes mtodos, muitas vezes
alimentados por uma variedade de tcnicas provenientes da cincia da informao, psi-
cologia cognitiva e inteligncia articial, tem sido implementados na forma de programas
de computador, seja como ferramentas autnomas ou como ambientes de computao in-
tegrados para a tomada de decises complexas [Power 1997]. Tais ambientes so muitas
6 CAPTULO 2. FUNDAMENTAO TERICA
vezes chamados de sistemas de apoio deciso (SAD), ou tambm decision support sys-
tems (DSS).
O conceito de sistemas de apoio deciso bastante amplo, e existem diferentes
denies dependendo do ponto de vista do autor [Druzdzel & Flynn 2002].
Finlay dene um SAD como um sistema computacional que auxilia o processo de
tomada de deciso [Finlay 1994]. De uma maneira mais especca, Turban a dene como
um sistema de informao interativo, exvel e adaptvel especialmente desenvolvido
para suporte a soluo de problemas gerenciais no estruturados [Turban 1994]. Para
Keen e Morton, os SADs se baseiam no casamento dos recursos intelectuais individuais
com os recursos de um computador a m de melhorar a qualidade das decises [Keen &
Morton 1978].
Reunindo as diversas denies presentes na literatura, possvel chegar a um con-
ceito mais geral e tecnolgico a respeito dos SADs. Um SAD , de maneira geral, um
sistema computacional que possui interatividade com as aes do usurio, oferecendo da-
dos e modelos para a soluo de problemas focando a tomada de deciso. necessrio
enfatizar o fato de esses sistemas seremutilizados para auxiliar o operador, e no substitu-
lo.
Assim como as diferentes denies, existem tambm diferentes nomenclaturas para
diferenciar os vrios tipos de SADs. Uma das nomenclaturas denidas na literatura apre-
senta o termo de sistema de apoio deciso passivo, ativo e cooperativo [Gachet &
Haettenschwiler 2003]. Um SAD passivo um sistema que auxilia o processo de tomada
de deciso, mas no apresenta sugestes e/ou solues do problema explicitamente. Um
SAD ativo trabalha de forma semelhante, porm apresenta as sugestes e solues. J um
SAD cooperativo permite ao operador modicar, complementar e ajustar a deciso apre-
sentada pelo sistema, para que estas sugestes sejam validadas. Este processo repetido
at que uma soluo consolidada seja gerada.
2.2 Sistemas Especialistas
A rea da computao chamada de inteligncia articial bastante ampla e pode ser
dividida em subgrupos, como exemplicado na Figura 2.1. Entre eles, a rea de sistemas
especialistas tambm conhecidos como expert systems uma soluo amplamente
utilizada em diferentes problemas [Giarratano & Riley 1994].
Os sistemas especialistas so denominados assim por modelarem conhecimento de es-
pecialista(s) emuma determinada rea, visando resolver problemas relativos a umdomnio
especco [Passos 1989].
2.2. SISTEMAS ESPECIALISTAS 7
Figura 2.1: Subgrupos da Inteligncia Articial (IA).
O objetivo ao se desenvolver um sistema especialista transferir o conhecimento de
um especialista para um sistema computacional e ento para o usurio [Turban 1989].
Assim, sistemas especialistas podem ser denidos como ferramentas computacionais
que modelam o raciocnio e as aes de um humano ou grupo especialista em uma de-
terminada rea de conhecimento. Desse modo, sistemas especialistas, assim como hu-
manos especialistas, agem de acordo com seu domnio em um conhecimento especco
[Flores 2003].
Fazendo uma analogia aos sistemas de apoio deciso, um sistema especialista pode
ser denido como um sistema computacional que emula a habilidade de tomada de de-
ciso de um humano especialista.
A arquitetura tpica de um sistema especialista composta de trs componentes prin-
cipais: a base de conhecimento, o motor de inferncia e a interface de usurio [Momoh
et al. 2000]. Esta arquitetura pode ser vista na Figura 2.2.
O usurio fornece fatos / informaes ao sistema especialista e recebe sugestes /
conhecimento em resposta.
Figura 2.2: Arquitetura tpica de um sistema especialista.
A base de conhecimento o conjunto de conhecimento necessrio para resolver um
problema especco. Esse conhecimento extrado a partir de fatos, heursticas (experi-
ncias, opinies, julgamentos, predies, algoritmos) e relaes que normalmente foram
formalizadas por especialistas em um determinado domnio. O conhecimento pode ser
representado utilizando-se uma gama de tcnicas, como as redes semnticas e a lgica
predicativa, porm a mais comumente utilizada a conhecida como regras de produo
[Metaxiotis et al. 2002, Ignizio 1991].
O motor de inferncia um elemento essencial para a existncia de um sistema espe-
cialista. Ele considerado o ncleo do sistema, uma vez que por intermdio dele que
os fatos, heursticas e relaes que compem a base de conhecimento so aplicados no
processo de resoluo do problema [Ignizio 1991].
A interface do usurio responsvel pela interao do usurio com o sistema. Nor-
malmente ela composta de interfaces de visualizao e diagnstico, e pode tambm
prover interfaces de comunicao para ferramentas externas, como bancos de dados.
Sistemas especialistas apresentam diversos recursos e funcionalidades que inuen-
ciam a sua grande utilizao. Entre eles podemos citar:
Versatilidade: Um sistema especialista pode ser executado em quase qualquer sis-
tema computacional.
Custo reduzido: O custo de prover conhecimento por usurio reduzido.
Perigo reduzido: Os sistemas especialistas podem ser utilizados em ambientes
nocivos a um humano.
Permanncia: O conhecimento permanente, diferentemente dos especialistas hu-
manos onde o conhecimento no armazenado indenidamente.
Conhecimento mltiplo: O conhecimento de mltiplos especialistas pode ser ar-
mazenado simultaneamente em um sistema especialista.
Resposta rpida: A resposta rpida ou em tempo real pode ser necessria em
algumas aplicaes.
Resposta completa e estvel: Esse recurso importante em situaes de emergn-
cia, quando um humano pode no operar com sua total ecincia devido a estresse
ou fadiga.
Todo sistema especialista desenvolvido seguindo certas caractersticas gerais [Giarratano
& Riley 1994]. O desempenho uma caracterstica fundamental que permite ao sistema
a capacidade de responder a um nvel de competncia igual, ou melhor, a de um espe-
cialista no domnio em questo. Um tempo de resposta adequado outra caracterstica
importante, fator que possibilita o sistema operar em um intervalo de tempo menor que
o necessrio para um especialista no domnio em questo. A robustez um quesito fun-
damental em quase todo sistema computacional, evitando que o sistema trave e conse-
quentemente aumentando sua conabilidade. Por m, outra caracterstica de um sistema
especialista que ele seja compreensvel, semelhantemente a um humano especialista que
capaz de explicar o seu raciocnio.
Existe uma gama de formalismos que podem ser utilizados para modelar o conheci-
mento de sistemas especialistas, tais como, regras de produo, raciocnio baseado em
casos, redes neurais, redes probabilsticas, entre outros [Py 2002]. O sistema especialista
utilizado para a aplicao apresentada nesta dissertao foi o sistema baseado em regras
de produo.
2.2.1 Sistemas Baseados em Regras de Produo
O sistema baseado em regras o mtodo mais popular para representao de conhe-
cimento dentre os sistemas especialistas [Carrico et al. 1989]. Nessa abordagem, a cons-
truo de regras realizada de forma procedural, no formato se-ento ou situao-ao.
Alm disto, regras so facilmente desenvolvidas a partir de tabelas e rvores de deciso
[Hopgood 2000].
Dentre as vantagens em se utilizar um sistema de regras possvel citar a utilizao
da programao declarativa, a separao entre a lgica e os dados, a velocidade e escala-
bilidade e a centralizao do conhecimento [Sasikumar et al. 1993].
Por outro lado, sistemas baseados em regras no so aconselhados quando o problema
em questo no complexo, pois existe a possibilidade do sistema baseado em regras se
tornar mais lento do que as resolues usuais [Browne 2009].
O conceito de regra de produo amplo, mas no contexto de sistemas de informaes
uma regra dene restries especcas na criao, modicao e remoo de dados em
um sistema de informao (SI) [Hay & Healy 1997].
A literatura sugere que uma regra de produo deve ser representada utilizando trs
componentes bsicos: Evento, Condio e Ao (ECA). O evento determina quando a
regra ser processada. A condio expressa as hipteses que devem ser processadas a m
de se validar a regra. Por m a ao determina o que deve ser feito caso a condio seja
validada [Dallavalle & Cazarini 2000, Zimbro 2001].
Nos sistemas baseados em regras, a base de conhecimento subdividida em dois
mdulos: a base de regras e memria de trabalho (ou base de fatos), como ilustrado
na Figura 2.3.
Figura 2.3: Arquitetura tpica de um sistema especialista baseado em regras.
A base de regras responsvel por armazenar o conhecimento abstrato, ou seja, o
conjunto de regras de produo previamente elaboradas por um especialista.
A memria de trabalho (working memory) o elemento que armazena o conheci-
mento concreto, ou seja, o conhecimento que pode ser considerado fato antes do processo
de inferncia. Por este motivo, o conhecimento armazenado na memria de trabalho
chamado de fato. Essa base contm todas as informaes sobre o problema que so
fornecidas pelo usurio ou por outra fonte de informao. A memria de trabalho de
carter transitrio, pois, novos fatos esto sendo acrescentados continuamente ou fatos
existentes so apagados.
O motor de inferncia, j explanado anteriormente, associa o conhecimento abstrato
contido na base de regras com o conhecimento concreto armazenado na base de fatos,
inferindo concluses e gerando novos fatos.
Nos sistemas baseados em regras, a inferncia o processo de desenvolvimento de
uma concluso a partir de um conjunto de regras e fatos para uma determinada situ-
ao. Existem dois modos de raciocnio incorporados ao motor de inferncia que so
consideradas principais na resoluo de problemas e busca de solues: o encadeamento
progressivo e o encadeamento regressivo [Py 2002].
No encadeamento progressivo (forward chaining), a condio da regra comparada
com a descrio da situao atual contida na memria de trabalho (fatos). As regras
que satisfazem a esta descrio tem suas aes executadas, o que, em geral, signica na
introduo de novos fatos na memria de trabalho.
No encadeamento regressivo (backward chaining), o comportamento do sistema
controlado por uma lista de objetivos. Um objetivo pode ser satisfeito diretamente por
um elemento da memria de trabalho, ou podem existir regras que permitam inferir al-
gum dos objetivos correntes, isto , que contenham uma descrio deste objetivo em suas
condies. As regras que satisfazem esta condio tm as instncias correspondentes s
suas aes adicionadas lista de objetivos correntes. Caso uma dessas regras tenha todas
as suas condies satisfeitas diretamente pela memria de trabalho, o objetivo emsua ao
tambm adicionado memria de trabalho. Um objetivo que no possa ser satisfeito
diretamente pela memria de trabalho, nem inferido atravs de uma regra, abandonado.
Quando o objetivo inicial satisfeito, ou no h mais objetivos, o processamento termina.
O motor de inferncia tambm requer que seja denido o algoritmo responsvel por
guiar a busca e casamento entre o conhecimento da memria de trabalho e da base de
regras.
Charles L. Forgy, na Carnegie-Mellon University, em 1979, desenvolveu um algo-
ritmo de casamento de padres chamado de Rete [Forgy 1982]. O algoritmo Rete um
eciente algoritmo de casamento de padres e a escolha mais comumente encontrada
em motores de inferncia comerciais. Os sistemas que utilizam este algoritmo incluem o
CLIPS, Jess, Drools e o Soar [Ding et al. 2009, Friedman-Hill 2003, Browne 2009, Nayak
et al. 1988].
O algoritmo Rete implementado com o objetivo de construir uma rede de ns, com
cada um desses ns representando uma ou mais premissas encontradas na condio de
uma regra. Fatos que so inseridos ou removidos da base de conhecimento so proces-
sados por esta rede de ns. Os ns terminais da rede representam regras individuais.
Quando um conjunto de fatos atinge todo o caminho da rede at um n terminal, signica
que todas as premissas da condio de uma regra particular foram satisfeitas. Ento, a
ao desta determinada regra executada [Tambe et al. 1992, Doorenbos 1995].
Existem dois tipos de ns em uma rede de Rete. Os ns alpha, tambm conhecidos
como ns de uma entrada, e os ns beta, ou ns de duas entradas. O uxo realizado pelo
algoritmo Rete inicialmente constri um n alpha para cada teste direto de um fato na
condio de uma regra. Consequentemente, a entrada dos ns um conjunto de fatos, e a
sada somente os fatos que tiveram a premissa considerada verdadeira. Posteriormente,
os dois primeiros ns alpha so combinados em um n de duas entradas, ou seja, um n
beta, que, tem como sada somente os fatos que passam nos dois testes. Ento, outro n
beta construdo com as entradas sendo a sada do n beta anterior e o prximo n alpha.
Este passo repetido at todas as premissas da condio da regra sejam unidas, uma a
uma, em uma cadeia de ns beta. A sada deste n beta nal ento o conjunto de fatos
(que pode ser vazio), que casam com a regra.
Como exemplo, para a regra abaixo a rede Rete obtida seria a ilustrada na Figura 2.4.
Se C1, C2, C3, C4 ento Ao
Figura 2.4: Rede de Rete obtida do exemplo dado.
Considerando uma segunda regra, o algoritmo Rete reutiliza os ns alpha e cria novos
ns alpha somente se um teste direto de fato no existente anteriormente. Similarmente,
se a condio desta nova regra aparecer na mesma ordem da condio da primeira regra,
o algoritmo Rete reutiliza tambm os ns beta. Isso signica que a reordenao das
premissas da condio de uma regra pode resultar em uma rede de Rete maior ou menor,
e consequentemente, mais lenta ou mais rpida.
O algoritmo Rete j conta com diversas variaes, como o Rete-II, Rete-III, TREAT,
LEAPS, Rete-OO, entre outros. Cada um deles contam com ajustes buscando otimizao
para cada situao. De uma maneira geral, o nome Rete se torna genrico para se referir
a quase toda rede de casamento de um conjunto de regras.
Dentre a gama de sistemas baseado em regras existentes no mercado, o sistema uti-
lizado no desenvolvimento da aplicao apresentada nesta dissertao foi o JBoss Drools.
JBoss Drools
O Drools um sistema de gerenciamento de regras de negcio (SGRN) desenvolvido
pela JBoss. Atualmente se encontra na verso 5.5 e distribudo gratuitamente pelo site
da desenvolvedora.
O Drools utiliza o algoritmo Rete-OO para casar os padres entre fatos e regras, que
trata-se de uma verso do algoritmo Rete otimizado e renado para sistemas orientados
a objeto [Bali 2009]. Ainda, o Drools utiliza o modo de raciocnio baseado no encadea-
mento progressivo (forward-chaining).
Um exemplo da sintaxe do Drools pode ser vista no cdigo abaixo, com comentrios
em cada linha.
1 r ul e " Nova Regr a " / / I n i c i o da r e g r a
2 when
3 / / Condi coes
4 t hen
5 / / Acoes
6 end / / Fim da r e g r a
O exemplo abaixo ilustra uma regra que tem como objetivo imprimir na tela todos
os feriados que ocorrem no ms de dezembro. Esta regra confere uma condio (mes
== "dezembro") em uma instncia da classe Feriado e executa o cdigo Java caso essa
condio seja satisfeita.
1 r ul e " Fe r i a d o s do Ms de Dezembro "
2 when
3 f : Fe r i a do ( mes == " dezembro " )
4 t hen
5 Syst em . out . p r i n t l n ( f . nome + " : " + f . di a + " / " + f . mes ) ;
6 end
Nas suas verses mais recentes, o Drools foi subdividido em cinco componentes: o
Drools Guvnor, o Drools Flow, o Drools Planner, o Drools Expert e o Drools Fusion.
O Drools Guvnor consiste em ferramentas grcas para o gerenciamento de regras. O
Drools Flow (ou jBM5) prov ferramentas para construo de uxogramas de processos
de negcio. O componente Drools Planner auxilia a resoluo de problemas de planeja-
mento atravs de meta-heursticas. O mdulo Drools Expert o motor de regras, funda-
mental para a utilizao desse SGRN. E por m o Drools Fusion adiciona a capacidade
de processamento de eventos complexos ao sistema, tornando possvel a utilizao de
elementos temporais.
Para o desenvolvimento do sistema apresentando nesta dissertao foram utilizados
os mdulos Drools Expert e Drools Fusion.
2.3 Sistemas de Alarmes
Alarmes so sinais de noticao ao operador, tipicamente apresentados atravs de
efeitos sonoros, indicao visual, mensagens ou outro tipo de identicador. Um alarme
indica a ocorrncia de uma anormalidade que requer ateno do operador, e geralmente
esto associadas medies no processo que atingem valores indesejveis ou considera-
dos inseguros [ANSI/ISA 2009].
Tradicionalmente os alarmes eram baseados em painis com lmpadas indicativas,
limitando a quantidade de noticaes disponveis e dicultando novas implementaes.
Hoje em dia, a utilizao de sistemas computacionais, conhecidos como sistemas de
alarmes, permite uma fcil adio de novos alarmes e suas representaes grcas nor-
malmente so baseadas em uma lista ordenada cronologicamente.
2.3. SISTEMAS DE ALARMES 15
Os responsveis pela gerao de alarmes so os sistemas supervisrios, programados
para gerarem sinalizaes quando detectado algum comportamento anormal no funciona-
mento da planta. Dessa forma, tais sinalizaes, ou melhor chamados alarmes, auxiliam
os operadores na efetiva identicao e resoluo dos possveis problemas [Leito 2008].
Dessa maneira, tornou-se necessria a implantao de sistemas capazes de indicar as
sinalizaes provenientes dos sistemas supervisrios, de modo a facilitar seus reconheci-
mentos pelo operador. Tais sistemas so chamados de sistemas de alarmes.
Os sistemas de alarmes fazem parte do ncleo operacional de quase todas as modernas
centrais de operao, incluindo as plataformas e renarias de petrleo. Seu principal
objetivo receber as noticaes provenientes do processo e apresent-las ao operador
utilizando alguma representao visual.
Porm, nem todo sistema de monitoramento de alarmes estabelece uma poltica bem
difundida de adio, remoo, congurao e gerenciamento de alarmes. Desta forma,
a redundncia e a baixa relevncia de determinados alarmes atribui uma carga de infor-
mao adicional aos operadores, que acaba por tornar muitas vezes a interpretao de
mltiplas noticaes uma tarefa humanamente impossvel. Consequentemente, a tardia
ou a no correta identicao de uma anormalidade colabora na ocorrncia de incidentes
na indstria.
Uma pesquisa realizada pela HSE (Health and Safety Executive) em 15 plantas in-
dustriais identicou a ocorrncia de diversos incidentes diretamente envolvidos com a m
congurao dos sistemas de alarmes empregados. Dentre eles esto quatro incidentes
resultando em danos a equipamento, trs incidentes resultando em perda de produo e
trs incidentes causadores de massivos danos ambientais [EEMUA191 2007].
Em termos quantitativos, as recomendaes da ISA-18.2 (International Society of Au-
tomation) e da EEMUA 191 (Engineering Equipment and Materials Users Association)
indicam que a quantidade mxima de alarmes a serem gerenciados por dia por operador
de 300 alarmes [ANSI/ISA 2009, EEMUA191 2007]. Taxas de noticaes acima deste
limite foram o operador a ignorar certos alarmes. Porm estudos relatam a ocorrncia
tpica de uma quantidade de alarmes muitas vezes acima deste limite aceitvel, longe
das habilidades de avaliao e resposta do operador [Hollield & Habibi 2010]. Outros
valores recomendados pela organizao podem ser vistos na Tabela 2.1.
2.3.1 Estratgias de Inibio de Alarmes
A literatura relata que os atuais sistemas de alarmes no esto preparados para lidar
com situaes anormais de operao, onde uma nica falha pode resultar na gerao de
Alarmes Anunciados por Tempo Valores Recomendados Valores Mximos
Alarmes Anunciados por Dia por
Operador
150 alarmes por dia 300 alarmes por dia
Alarmes Anunciados por Hora por
Operador
6 (em mdia) 12 (em mdia)
Alarmes Anunciados por 10 Minu-
tos por Operador
1 (em mdia) 2 (em mdia)
Tabela 2.1: Valores ideais e mximos de alarmes por operador por unidades de tempo.
at centenas de alarmes. Um estudo publicado na EEMUA 191 realizado atravs de en-
trevistas mostrou que um operador recebe em mdia um nico alarme a cada 2 minutos
sob operao normal. Durante uma operao atpica, relatada a ocorrncia de aproxi-
madamente 90 alarmes no primeiro minuto aps o distrbio, e mais 70 nos 10 minutos
subsequentes [EEMUA191 2007]. Isto se deve ao fato que alarmes so projetados para a
operao normal do processo [Mattiasson 1999].
Esta excessiva quantidade de alarmes em curtos intervalos de tempo leva a necessi-
dade de se incorporar lgicas e estratgias de supresso de alarmes em diferentes situ-
aes. Em alguns cenrios, como na parada e na partida de uma planta, na ocorrncia de
distrbios, ou durante uma manuteno, determinadas noticaes podem ter suas priori-
dades degradadas.
Porm a identicao destes cenrios pode no ser uma tarefa trivial e requer a uti-
lizao de tcnicas modernas e ecientes incorporadas aos sistemas de gerenciamento
de alarmes, visto que utilizao de supresses inapropriadas pode resultar em problemas
relativos a segurana operacional.
A supresso em tempo real de alarmes na operao de processos uma tarefa de
alta complexidade. A criticidade desta operao se deve no somente ao fato de ser um
sistema online, mas tambm por envolver a inibio de noticaes que, em tese, trazem
informaes relacionadas a algum equipamento ou estado do processo. Por este motivo,
as estratgias escolhidas para realizarem a etapa de supresso devem ser de preferncia
elaboradas e validadas a priori por uma equipe de especialistas no processo em questo.
Captulo 3
Sistema Desenvolvido
Neste captulo so apresentados os componentes fundamentais para o completo en-
tendimento do sistema desenvolvido, chamado de BR-PlantExpert. Deste modo, as duas
subsees seguintes esto organizadas da seguinte maneira. Primeiro a Subseo 3.1 apre-
senta uma breve explanao das tecnologias utilizadas no desenvolvimento da aplicao.
Em seguida a Subseo 3.2 apresenta a arquitetura e a aplicao da ferramenta prosposta.
3.1 Tecnologias Utilizadas
Para o desenvolvimento da ferramenta apresentada nesta dissertao, foram utilizadas
quatro principais tecnologias. Estas so: a plataforma de comunicao de dados BR-
Tools, a linguagem de programao Java, a biblioteca grca Visual Library e o sistema
de regras JBoss Drools.
3.1.1 BR-Tools
Tendo em mente uma aplicao inteligente na rea de automao industrial, a ferra-
menta proposta neste trabalho teve seu desenvolvimento realizado em formato de plug-in
para o framework BR-Tools.
O BR-Tools um sistema responsvel por integrar e permitir a visualizao em alto
nvel de abstrao das vrias fontes de dados presentes em um processo industrial, como
variveis de processo, alarmes e eventos [Lima 2010]. Ele prov facilidades para o de-
senvolvimento de mdulos (chamados plug-ins) que executam sobre este framework, e o
mesmo oferece um ambiente convel, robusto e eciente. A arquitetura geral do sistema
BR-Tools pode ser visualizada na Figura 3.1.
O framework pode conectar-se a diversas fontes de dados e ter vrios plug-ins sendo
executados, logo, age como um ponto central gerenciando pedidos de acesso aos dados e
18 CAPTULO 3. SISTEMA DESENVOLVIDO
Figura 3.1: Arquitetura do BRTools.
otimizando-os. Dentre as fontes de dados disponveis para aquisio de dados possvel
destacar os servidores OPC-DA [OPC DA 3.00 Specication, Data Acess Automation
Interface Standard 2003], relativos a informaes de variveis de processo em tempo
real, e os servidores OPC-A&E [OPC A&E 1.10 Specication, Alarm and Events Custom
Interface 2002], relativos a informaes de alarmes e eventos em tempo real. Esses so
protocolos de comunicao amplamente utilizados em instalaes industriais da rea de
petrleo e gs.
Na Figura 3.2 possvel ver o software emexecuo semplug-ins carregados, primeira-
mente, e com plug-ins carregados e executando.
Figura 3.2: Tela do BRTools sem plug-ins e com plug-ins executando.
3.1. TECNOLOGIAS UTILIZADAS 19
Assim, diante do exposto acima, a concepo e implementao do sistema de apoio
deciso apresentado nesta dissertao encapsulado em formato de plug-in do sistema
BR-Tools.
3.1.2 Linguagem Java
A linguagem Java, criada pela Sun Microsystems em 1991, tem como principais ca-
ractersticas o fato de ser segura, independente de plataforma e de ser uma linguagem de
programao orientada a objetos.
Programas Java consistemempartes chamadas classes, que por sua vez incluempartes
chamadas mtodos que realizam tarefas e retornam informaes quando as tarefas so
concludas. Com sua ampla utilizao, existem ricas colees de classes j desenvolvidas,
chamadas bibliotecas de classes. O prprio Java j oferece diversas bibliotecas, chamadas
tambm de Java APIs (Application Programming Language) [Deitel & Deitel 2009].
A compilao da linguagem resulta em uma forma intermediria de cdigo binrio
chamado bytecodes. Esse cdigo ento submetido a um processo de traduo para um
cdigo binrio que possa ser reconhecido por cada processador especco. O tradutor de
bytecodes chamado de Mquina Virtual Java (JVM), sendo o responsvel pela exibi-
lidade dessa linguagem em ser executada por diferentes sistemas operacionais [Mecenas
2008].
A opo da linguagem Java para o desenvolvimento da aplicao desta dissertao
se deve em grande parte a portabilidade da linguagem. Essa caracterstica fundamental
para aplicaes de escopo industrial, devido diversidade de plataformas presentes nos
ambientes industriais. Alm disso essa linguagem compatvel com as bibliotecas uti-
lizadas no desenvolvimento, a biblioteca visual Visual Library e o sistema de regras JBoss
Drools, e que sero explicadas nos tpicos seguintes.
3.1.3 Visual Library
A biblioteca Visual Library foi criada pela Netbeans a m permitir uma maior vari-
edade de formatos de visualizao e modelagem grca de objetos, como por exemplo,
grafos. Grande parte de sua utilizao se deve ao fato de prover uma arquitetura que
objetiva e facilita a programao visual [Gameleira et al. 2008].
Incorporada ao NetBeans Plataform desde o JDK (Java Development Kit) 5.0, essa
API vem sendo bastante utilizada por sua versatilidade e diversidade.
A escolha dessa biblioteca se deve a sua grande utilizao em sistemas semelhantes,
que se baseiam em programao visual de alto nvel.
3.1.4 JBoss Drools
O sistema Drools, desenvolvido pela JBoss, j foi anteriormente explanado na Seo
2.2.1.
Dentre as razes do sistema da JBoss ter sido utilizado no desenvolvimento da fer-
ramenta apresentada nesta dissertao esto a compatibilidade com a linguagem de pro-
gramao Java e o fato de ser distribuda gratuitamente e de ter seu cdigo-fonte aberto
(open-source).
3.2 Arquitetura e Aplicao Proposta
Com o intuito de permitir a adoo de diferentes aplicaes utilizando-se o mesmo
mdulo de processamento o sistema foi desenvolvido uma arquitetura de caracterstica
modular. Desta maneira, com mdulos independentes e desacoplados, o desenvolvimento
de novas aplicaes se torna uma tarefa simples e rpida, permitindo que os mdulos
responsveis pelo sistema especialista e pela construo de regras sejam minimamente
modicados.
Seguindo este modelo, a arquitetura do BR-PlantExpert se encontra subdividida em
trs mdulos: o sistema especialista baseado em regras, o ambiente de construo de
regras, e um terceiro mdulo diretamente ligado a visualizao dos resultados obtidos no
processo de inferncia.
O primeiro mdulo o responsvel por gerenciar o sistema baseado em regras, combi-
nando o conhecimento armazenado atravs de regras de produo com os fatos adquiridos
durante sua execuo.
O ambiente de construo de regras um segundo mdulo que tem como objetivo
prover ao usurio ferramentas de modelagem grca de regras que sero posteriormente
carregadas na base de conhecimento do sistema especialista.
A m de validar a usabilidade e funcionalidade do sistema o problema da supresso
online de alarmes foi escolhida como a aplicao da ferramenta para realizao deste
trabalho de dissertao. Com o objetivo de ltrar alarmes que sejam considerados des-
necessrios ou irrelevantes em uma determinada situao possvel auxiliar o operador
a tomar decises de maneira mais gil. Deste modo, o terceiro mdulo desenvolvido foi
a tela de monitoramento de alarmes, responsvel por disponibilizar as noticicaes de
alarmes juntamente com informaes relevantes de um processo industrial.
Nas Sees 3.2.1, 3.2.2 e 3.2.3 esses trs mdulos sero explanados mais detalhada-
mente.
3.2. ARQUITETURA E APLICAO PROPOSTA 21
A arquitetura proposta est ilustrada na Figura 3.3. As indicaes numricas demons-
tram o uxo de dados do sistema.
Figura 3.3: Arquitetura proposta do BR-PlantExpert.
O uxo de dados da arquitetura dado a partir de assinaturas realizadas pelo plug-in
e o BR-Tools, tornando assim possvel o recebimento sncrono e assncrono de dados de
variveis de processo e de alarmes e eventos. Esse uxo caracterizado pela indicao 1.
A indicao 2 demonstra o uxo de dados que representa o carregamento da base
de regras do sistema especialista pelas regras modeladas no ambiente de construo de
regras.
Por m, a indicao 3 representa o uxo de alarmes repassados para a interface de
visualizao de alarmes devidamente ltrados pelas regras do sistema especialista.
3.2.1 Sistema Especialista Baseado em Regras
Este mdulo responsvel pelo processamento de grande parte das funcionalidades
do sistema. Como exemplo de funcionalidades, pode-se citar a associao entre regras
e fatos. Como citado anteriormente, o sistema utilizado nesta ferramenta o Drools,
resultando em uma compatibilidade com os demais recursos deste mdulo.
Por ser um mdulo exclusivo de processamento, ele no apresenta interface grca e
transparente ao usurio, sendo executado em background.
Este mdulo funciona independente dos demais, porm necessrio que o mesmo seja
alimentado com regras em linguagem Drools, de difcil compreenso para usurios inex-
perientes. Por este motivo foi desenvolvido o ambiente de construo de regras, escopo
do segundo mdulo do sistema.
3.2.2 Ambiente de Construo de Regras
O ambiente de construo de regras o mdulo responsvel por prover ao usurio
acesso modelagem de regras, que posteriormente sero carregadas e executadas na base
de conhecimento do sistema especialista.
Esta modelagem feita a partir de programao visual atravs de blocos funcionais
existentes e congurados pelo usurio. Fazendo uso desses blocos e de operadores lgicos
tambm disponveis, possvel a construo de uma lgica mais complexa que representa
a condio de uma regra.
Nas subsees seguintes, quatro aspectos importantes do ambiente de construo de
regras so abordados com a nalidade de tornar mais claro seus objetivos e funcionali-
dades. Um quinto aspecto introduzido com o objetivo de demonstrar uma das aplicaes
possibilitadas pela ferramenta.
Estrutura e Organizao das Regras
A organizao das regras no contexto da aplicao formada seguindo a estrutura
ilustrada na Figura 3.4.
Figura 3.4: Organizao das regras no contexto da aplicao.
A modelagem realizada a partir da denio de sistemas, estruturas que representam
um conjunto ou parte de uma planta industrial. Estes sistemas so formados por estados,
responsveis por reetir o funcionamento atual do sistema em questo. Cada estado
ento denido por uma regra, que ser posteriormente includa na base de conhecimento
do sistema especialista.
A formulao de regras realizada utilizando-se informaes provenientes de fontes
de dados, tais como de variveis de processo, alarmes e eventos, e tambm de valores de
estados de outros sistemas.
Estas regras so construdas ento para denir a ativao ou no de um estado, deter-
minando assim o estado atual do sistema em questo. Ento, a partir de blocos funcionais,
o usurio constri em forma de programao visual as condies necessrias para que o
estado seja ativado e que determinadas aes sejam tomadas.
Tais aes dependem do escopo da aplicao em que o BR-PlantExpert est inserido,
e para o caso desta dissertao esta aplicao foi a de supresso de alarmes.
Programao Visual Utilizando Blocos Funcionais
A disponibilidade de modelagem de regras utilizando-se programao visual uma
funcionalidade de extrema importncia, visto que sistemas especialistas normalmente
utilizam-se de linguagem de programao com diferentes sintaxes dicultando seu en-
tendimento e compreenso por um usurio sem experincia. Desta forma, a progra-
mao visual auxilia oferecendo uma linguagem de alto nvel, rpida, fcil e intuitiva
para usurios de diferentes nveis de conhecimento.
A ferramenta apresentada nesta dissertao tem a proposta de oferecer blocos fun-
cionais congurveis, assim como operadores lgicos, para a lgica da regra em questo
ser ento elaborada.
Os blocos funcionais disponveis na ferramenta so organizados emtrs classes, alarme
/ evento, varivel de processo e estado. A Figura 3.5 ilustra a visualizao dos blocos
dessas trs classes.
Figura 3.5: Blocos funcionais disponveis na aplicao.
I. Alarme/Evento
So blocos ativados caso um determinado alarme ou evento ocorra. Por exemplo, a
ocorrncia do alarme XA-4321. Este bloco, caracterizado pela cor amarela, tem como
painel de congurao a tela apresentada na Figura 3.6.
A partir desta tela possvel optar por alarme ou evento e congurar a sua respectiva
tag. A opo delay funciona como um operador temporal, possibilitando somente a vali-
dade da condio aps este tempo pr-congurado pelo usurio. Por m, a opo Tempo
Figura 3.6: Painel de congurao do bloco de alarmes e eventos.
de Expirao, habilitada somente para eventos, invalida a condio aps este tempo pr-
congurado pelo usurio.
II. Varivel de Processo
So blocos ativados caso uma varivel de processo satisfaa uma condio. Essa
condio depende do tipo de varivel a ser tratada. Por exemplo, uma varivel contnua de
processo, como temperatura, ultrapassar um determinado valor, ou uma varivel discreta
de processo, como o estado de uma vlvula estar ativado.
O painel de congurao deste bloco permite a escolha da tag a partir de trs mtodos
diferentes:
Mtodo manual: Este mtodo permite inserir a tag manualmente, sem quaisquer
busca no servidor de dados. Desta maneira o tipo da varivel tambm deve ser
denido pelo usurio (Figura 3.7a).
Mtodo hierrquico: Este mtodo permite listar todas as tags do servidor de forma
hierrquica, caso o mesmo suporte esta funcionalidade. Desta maneira, as tags
so visualizadas de uma forma mais simples e organizada, facilitando a escolha da
mesma. A tag escolhida tem o seu tipo automaticamente denido atravs de uma
consulta ao servidor (Figura 3.7b).
Mtodo por busca com mscara: Este mtodo permite ao usurio inserir uma
mscara responsvel por ltrar as tags disponveis no servidor, facilitando a escolha
(a) (b) (c)
Figura 3.7: Painel de congurao do bloco de varivel de processo.
da tag. A tag escolhida tem o seu tipo automaticamente denido atravs de uma
consulta ao servidor (Figura 3.7c).
Denida a tag da varivel de processo, a condio do bloco congurada a partir
de uma expresso que dene uma comparao matemtica. Tal expresso ter uma sada
verdadeira (true) ou falsa (false). Os operadores disponveis para formulao da expresso
variam de acordo com o tipo de varivel associada. A lista abaixo indica os operadores
disponveis para cada tipo de varivel de processo:
Inteiro: >, >=, <, <=, ==
Double: >, >=, <, <=, ==
Booleano: true, false
String: equals, startWith, endsWith
Esta expresso de comparao matemtica permite ainda a opo por comparar uma
varivel a um valor constante (comparao esttica) ou ainda a outra varivel de processo,
permitindo assim a congurao demonstrada na Figura 3.7c, que compara os valores de
duas variveis disponveis no servidor (pid1.OUT > pid1.SP).
III. Estado
So blocos ativados quando um determinado estado de um sistema se encontra ativo.
Figura 3.8: Painel de congurao do bloco de estado.
Desta maneira possvel associar o estado de um sistema a partir dos estados de outros
sistemas. O painel de congurao deste bloco pode ser visualizado na Figura 3.8.
Para auxiliar a construo das condies das regras so oferecidos tambm operadores
lgicos, permitindo-se assim a criao de lgicas mais complexas. Os operadores ofere-
cidos pela ferramenta so: E lgico (a), OU lgico (b), negao lgica (c) e operador
votao (n de m) (d). Estes operadores podem ser visualizados na Figura 3.9.
(a) (b) (c) (d)
Figura 3.9: Operadores disponveis na construo de regras.
Modelagem Hierrquica
Uma das grandes inovaes do sistema proposto consiste em permitir que as regras se-
jam modeladas utilizando-se uma arquitetura hierrquica, o que torna possvel uma estru-
turao mais simples e organizada das informaes sobre a planta industrial em questo.
Essa hierarquia visualizada a partir de uma estrutura do tipo rvore, permitindo assim
que seja criado um sistema lho de um outro sistema, introduzindo assim o conceito de
sistema e subsistema.
Associando esta forma de modelagem com o objetivo da aplicao, no caso, a su-
presso de alarmes, essa estruturao parte do princpio de que toda vez que por algum
motivo um sistema no esteja em funcionamento normal os alarmes associados a este
sistema devem estar suprimidos.
No entanto, muitas vezes um sistema composto por vrios subsistemas que podem
estar em funcionamento mesmo quando o sistema encontra-se parado. Nesse caso, os
alarmes associados aos subsistemas em funcionamento no podem, de maneira alguma,
estarem suprimidos.
Seguindo esta prtica de modelagem, acredita-se que se o processo como um todo
for bem modelado, todo sistema/subsistema pertencente a ele ter apenas dois estados:
Operando e Parado. Sempre que um terceiro estado precisa ser denido para caracterizar
o subsistema, isto ser indicativo de que este dever ser subdividido em outros subsis-
temas.
AFigura 3.10 demonstra umexemplo de modelagemhierrquica de uma planta didtica:
Figura 3.10: Exemplo de modelagem hierrquica de uma planta industrial.
No entanto, a ferramenta permite tambm a modelagem de regras de um modo tradi-
cional, ou, linear. Desta maneira, possvel simplesmente traduzir regras j estrategica-
mente elaboradas e traduzi-las de forma visual no ambiente de construo de regras.
Essa possibilidade torna o sistema mais exvel, permitindo ao usurio diferentes
metodologias de modelagem de regras, tanto a mais tradicional quanto uma mais sosti-
cada.
Interface Grca
A interface grca (GUI) do ambiente de construo de regras foi desenvolvida com
o objetivo de simplicar a maneira como regras so modeladas, oferecendo facilidades e
tornando a sua utilizao o mais intuitiva possvel. Esta interface pode ser visualizada na
Figura 3.11.
O painel responsvel pela visualizao dos sistemas pode ser visto na indicao 1.
possvel visualizar a hierarquia dos sitemas e selecionar o sistema em que se deseja
observar/editar os estados.
A indicao 2 representa a barra de ferramentas da aplicao. Entre as ferramen-
tas temos: criar novo sistema/subsistema; remover o sistema/subsistema selecionado;
Figura 3.11: Interface grca do ambiente de construo de regras.
renomear umsistema/subsistema; criar novo estado para o sistema/subsistema selecionado;
salvar o trabalho atual; e carregar um trabalho anteriormente salvo.
O indicado em 3 chamado de painel de descrio. Nele possvel visualizar ou
editar a descrio de um determinado estado de um sistema.
Na indicao 4 temos o painel de edio de regras. Neste painel as regras so mo-
deladas de modo visual utilizando os blocos de condio e de operadores anteriormente
descritos. A lgica da regra deve ser construda e sua sada conectada ao bloco nal do
estado, caracterizado pela borda cinza.
Por m, a indicao 5 representa o painel de aes, onde se possvel determinar quais
alarmes sero suprimidos e/ou habilitados caso o referente estado seja ativado. Tambm
possvel congurar uma mensagem de alerta caso seja de interesse do operador. Este
painel se adapta com a aplicao em que o sistema est inserido.
Traduo Visual-Funcional
Uma vez que as regras tenham sido modeladas, necessrio realizar um processo
de traduo tornando as mesmas conciliveis com o sistema especialista. A linguagem
utilizada no ambiente de construo de regras, essencialmente visual, necessita que aquela
mesma informao inserida pelo usurio atravs da modelagem via blocos funcionais seja
repassada ao sistema especialista atravs de uma linguagem e sintaxe compatveis. Faz-
se necessrio a utilizao de uma interface de traduo entre o sistema especialista e o
ambiente de construo de regras, como ilustrado na Figura 3.12.
Figura 3.12: Interface de traduo acoplando o ambiente de construo de regras ao sis-
tema especialista.
A m de serem processadas pelo sistema especialista baseado em regras, necessrio
que as regras modeladas pelo usurio no ambiente de construo de regras sejam traduzi-
das para uma linguagem compatvel com o sistema. Essa traduo realizada de forma
transparente ao usurio, e no requer nenhum conhecimento acerca da sintaxe utilizada
pelo sistema especialista.
O sistema especialista utilizado, o Drools, faz uso da linguagem nativa DRL (Drools
Rule Language) [Bali 2009]. O ambiente de construo de regras ento responsvel
por processar os blocos funcionais modelados e conguraes realizadas pelo usurio e
traduzi-la em uma regra na linguagem DRL.
A Figura 3.13 ilustra um exemplo de uma regra modelada utilizando programao
visual e a Figura 3.14 demonstra sua respectiva regra traduzida em linguagem DRL, po-
dendo assim ser processada pelo Drools.
Figura 3.13: Exemplo de uma regra modelada utilizando programao visual.
Figura 3.14: A mesma regra da Figura 3.13 traduzida para linguagem DRL.
3.2.3 Tela de Monitoramento de Alarmes
A m de monitorar as ativaes de alarmes de um processo e validar as regras de
supresso e habilitao elaboradas, uma tela auxiliar de operao foi desenvolvida visando
a integrao de mltiplas informaes consideradas relevantes em uma interface simples
e objetiva. Deste modo, a identicao de possveis causas-raiz de anormalidades a partir
de alarmes se torna uma tarefa mais eciente, resultando em aes imediatas mais ecazes
por parte do operador.
Dentre os recursos adotados no desenvolvimento do mdulo de monitoramento de
alarmes, esto:
Melhor aproveitamento da interface utilizando resolues widescreen;
Utilizao de diferentes cores para representar a prioridade dos alarmes;
Acesso ao histrico das principais variveis de processo associadas ao alarme, per-
mitindo assim vericar seu comportamento nos ltimos minutos;
Disponibilizao de informaes de racionalizao do alarme provenientes de ou-
tras fontes de dados.
A interface (Figura 3.15), desenvolvida visando disponibilizar uma tela agradvel a
m de evitar o cansao visual por parte do operador, dispe de uma lista de alarmes ativos
(Indicao 1) - j devidamente ltrados pelas regras do sistema especialista - com suas
prioridades indicadas por diferentes cores pr-conguradas pelo operador. A partir desta
tela tambm possvel realizar o processo de reconhecimento do alarme.
Uma srie de informaes de racionalizao do alarme (previamente selecionados na
lista de alarmes ativos) mostrada ao usurio atravs de um painel lateral (Indicao
2). Tais informaes so dados de documentao do alarme provenientes de sistemas de
gerenciamento de alarmes, tais como o BR-AlarmExpert, sistema j amplamente empre-
gado em diversos setores industriais [Leito 2008].
Figura 3.15: Interface grca da interface de visualizao de alarmes.
A indicao 3 representa dados de leitura, em tempo real, de variveis de processo
relacionadas diretamente ao alarme pr-selecionado. Dessa forma, se torna mais intu-
itiva a identicao da causa raiz da anormalidade sinalizada pelo alarme por parte do
operador.
Por m, na indicao 4 mostrada um grco com a leitura das ltimas horas da
varivel de processo relacionada diretamente a ocorrncia de alarme. Esse grco tem
a inteno de mostrar a curva de tendncia da varivel de processo que gerou o desvio
sinalizado pelo alarme.
Diante do apresentado, a tela de monitoramento proposta tem como intuito disponi-
bilizar online ao operador as ocorrncias de alarmes (identicados como relevantes pelo
sistema de supresso), alm de todas as informaes necessrias para uma melhor e mais
rpida identicao da anormalidade. Essa interface no tem o intuito de substituir as
atuais telas de monitoramento de alarmes dos sistemas de superviso, mas sim servir
como mais uma fonte de informao integrada e disponvel ao operador como um sistema
auxiliar.
Captulo 4
Resultados
Este captulo rene testes e experimentos realizados a m de se quanticar e qualicar
o desempenho e a usabilidade do sistema desenvolvido. A Seo 4.1 apresenta trs testes
de desempenho (benchmarks), responsveis por determinar e analisar os fatores limitantes
da ferramenta, visto que se trata de um sistema online. A Seo 4.2 busca apresentar
a usabilidade da ferramenta atravs de um estudo de caso com dados de um processo
industrial real.
4.1 Desempenho do Sistema
Tendo em mente que o presente sistema executado em tempo real, o mesmo tem a
responsabilidade de responder de forma rpida, dentro de umlimite considerado aceitvel.
Ainda, espera-se que um sistema relacionado a supresso de alarmes um problema
considerado crtico responda em tempo hbil mesmo nos piores cenrios.
A utilizao de testes de desempenho e de tempo de execuo importante para a
anlise do comportamento de um sistema em operao. A partir do estudo dos resultados
obtidos ento possvel concluir se o sistema atende as especicaes necessrias para a
categoria em que ele est inserido.
Diferentes experimentos foram estudados e analisados a objetivando-se quanticar o
desempenho do sistema desenvolvido. Aps uma anlise do tempo de execuo do sis-
tema, foram selecionados trs principais fatores que poderiam reetir signicativamente
no desempenho do sistema. So eles:
Incremento de fatos
Incremento de regras
Incremento de disparos
34 CAPTULO 4. RESULTADOS
Os trs fatores selecionados foram testados a partir de experimentos e cenrios con-
trolados, observando os tempos de resposta para posterior anlise.
Os testes de desempenho foram realizados medindo-se o tempo de execuo de uma
iterao do sistema especialista em um computador com processados quad-core AMD
Phenom II 2.8GHz e 4GB de memria RAM. A m de se obter resultados mais precisos
e conveis, cada teste foi repetido dez vezes e sua respectiva mdia aritmtica foi calcu-
lada.
Para um melhor entendimento dos experimentos realizados, trs conceitos devem ser
revisados:
Regra: Regra na linguagem DRL, previamente modelada no ambiente de cons-
truo de regras, formada por condio e ao. Se VX-001 est ABERTA ento
Suprimir PI-22 um exemplo de regra.
Fato: o conhecimento armazenado na memria de trabalho do sistema especi-
alista. uma informao concreta, um dado que de fato ocorreu. VX-001 est
ABERTA um exemplo de fato.
Disparo: o casamento um ou mais fatos com uma regra, resultando na execuo
da ao da mesma. Utilizando-se os exemplos anteriores, o disparo seria o casa-
mento entre o fato e a regra e a sua respectiva ao (Suprimir PI-22).
As informaes de cada um dos testes podem ser vistas na Tabela 4.1. Cada teste
detalhadamente explicado nas subsees seguintes.
# de fatos # de regras # de disparos
Teste I 10-100000 5000 500
Teste II 5000 500-5000 500
Teste III 5000 5000 10-5000
Tabela 4.1: Informaes dos testes de desempenho realizados.
4.1.1 Teste I: Incremento de Fatos
Oprimeiro teste foi baseado no incremento gradual da quantidade de fatos na memria
de trabalho do sistema especialista. A quantidade de regras e o nmero de disparos foram
xados.
As informaes do primeiro teste podem ser vistas na Tabela 4.1. Os resultados obti-
dos esto contidos na Tabela 4.2 e seu respectivo grco pode ser visto na Figura 4.1
4.1. DESEMPENHO DO SISTEMA 35
Quant. de fatos 10 100 1000 10000 100000
Tempo Mnimo 30 30 34 37 38
Tempo Mximo 31 32 37 38 40
Tempo Mdio 30.3 31 35 37.1 39.5
Desvio Padro 0.48 0.67 1.15 0.32 0.70
Tabela 4.2: Resultados do Teste I (em milisegundos).
Figura 4.1: Grco dos resultados obtidos no Teste I.
Como pode ser concludo analisando os resultados obtidos nesse experimento, o in-
cremento de fatos no impactou signicativamente o tempo de execuo do sistema.
4.1.2 Teste II: Incremento de Regras
O segundo teste realizado teve como base o incremento gradual da quantidade de
regras na base de regras do sistema especialista. A quantidade de fatos e o nmero de
disparos foram mantidas constantes. As informaes deste teste podem ser vistas na
Tabela 4.1. Os resultados podem ser observados na Tabela 4.3 e na Figura 4.2.
Quant. de regras 500 1000 1500 2000 2500 3000 3500 4000 4500 5000
Tempo Mnimo 30 33 33 34 34 34 34 34 35 35
Tempo Mximo 35 35 35 35 36 36 36 36 37 37
Tempo Mdio 32.4 33.8 33.9 34.3 34.4 35.2 35.2 35.3 35.8 36.3
Desvio Padro 1.84 0.63 0.57 0.48 0.70 0.63 0.79 0.82 0.63 0.67
Tabela 4.3: Resultados do Teste II (em milisegundos).
Figura 4.2: Grco dos resultados obtidos no Teste II.
Assim como no primeiro teste de desempenho, o incremento de regras no interfere
signicativamente no tempo de execuo do sistema.
4.1.3 Teste III: Incremento de Disparos
O terceiro e ltimo teste de desempenho foi o que trouxe o maior impacto ao tempo de
execuo. O teste consistiu no incremento no nmero de regras disparadas durante uma
iterao de execuo das regras.
As informaes deste teste de desempenho esto contidas na Tabela 4.1. Os resultados
so visualizados na Tabela 4.4 e na Figura 4.3.
Quant. de disparos 10 50 100 250 500 1000 2000 3000 4000 5000
Tempo Mnimo 1 3 7 18 30 65 167 277 463 594
Tempo Mximo 1 4 9 20 37 70 171 289 475 607
Tempo Mdio 1 3.5 7.8 18.9 34.6 67.2 169.4 282.8 471.5 600.3
Desvio Padro 0 0.53 0.63 0.74 2.22 1.68 1.35 3.73 3.66 3.97
Tabela 4.4: Resultados do Teste III (em milisegundos).
Analisando este teste conclui-se que o fator limitante de desempenho do sistema a
quantidade de regras satisfeitas em uma mesma iterao. Porm, mesmo em um cenrio
improvvel de 5000 regras sendo satisfeitas na mesma iterao, o sistema respondeu em
um tempo mdio de 600ms, o que considerado satisfatrio para o propsito de moni-
toramento online de processos industriais.
4.2. ESTUDO DE CASO 37
Figura 4.3: Grco dos resultados obtidos no Teste III.
4.2 Estudo de Caso
A utilizao de estudos de caso incorpora credibilidade a um sistema desenvolvido,
principalmente por testar diferentes aspectos relativos a usabilidade. A partir de um es-
tudo de caso possvel vericar a experincia do usurio desde a modelagem das regras
no ambiente proposto at a validao das mesmas atravs da observao das sadas indi-
cadas na tela de monitoramento de alarmes.
4.2.1 Problema
O problema referente ao estudo de caso analisado neste trabalho baseado em uma
planta industrial real comumente encontrada em renarias de petrleo. Trata-se de um
forno de uma Unidade de Coqueamento Retardado, unidade responsvel pelo processo
severo de craqueamento trmico bastante utilizado na converso de uma frao bastante
depreciada em outras de maior valor comercial.
Este problema foi selecionado por se encaixar no contexto em que o sistema est
aplicado, pois os cenrios escolhidos a ocorrncia de uma parada do forno (trip) e seu
retorno a operao (start-up) acarreta na ativao de uma quantidade signicativa de
alarmes, porm nem todos trazendo informaes relevantes para aquela situao.
Uma grande parte dos alarmes ativados durante este processo de trip no trazem in-
formaes adequadas ao estado atual da planta, pois, aps o acionamento do sistema
intertravamento do forno, grande parte dos subsistemas do mesmo no estaro em fun-
cionamento. Ainda, durante o processo de recolocar o forno em operao, os subsistemas
do forno vo retornando aos poucos, tornando assim os alarmes relacionados a cada sub-
sistema novamente relevantes ao operador.
Amde ilustrar a avalanche de noticaes emque o operador se torna sujeito durante
a ocorrncia de um trip do forno industrial em questo, uma representao grca de um
histrico de um dia desta planta pode ser visualizada na Figura 4.4, onde o eixo das
abscissas representa o tempo e o eixo das ordenadas indicam a razo alarmes/hora.
notvel o grande aumento desta razo aps a deteco da parada do forno.
Figura 4.4: Histrico de real de Alarmes/Hora na ocorrncia de um trip no forno.
Anlises realizadas por prossionais experientes no processo em estudo revelaramque
na ocorrncia de uma parada total do forno, 78 diferentes alarmes congurados se tornam
passveis de supresso, pois, as suas ativaes se devem exatamente ao evento de parada
do forno, j previamente detectada pelo operador.
Desta forma, importante que durante a parada e a partida do forno, os alarmes
que no tragam informaes importantes sejam suprimidos (ou tenham suas prioridades
degradas) de forma a no mascarar a ocorrncia de alarmes relevantes ou at mesmo crti-
cos ao processo. Uma menor carga de informaes entregues ao operador resulta em uma
deteco mais rpida e consequentemente em uma tomada de deciso mais ecaz.
Porm, a m de se tornar um sistema seguro e eciente necessrio tambm incorpo-
rar lgicas de habilitao de alarmes durante a partida da planta, resultando na habilitao
de todos os alarmes previamente suprimidos aps o retorno operacional da planta.
4.2.2 Soluo Proposta
Asoluo proposta buscou adotar uma estratgia de supresso de alarmes e de suas ha-
bilitaes automticas de acordo com as condies operacionais do forno. Tais estratgias
e lgicas envolvidas foram elaboradas por uma equipe multidisciplinar envolvida direta-
mente ao processo de estudo, com conhecimento de seu comportamento em condies
normais e anormais de operao.
A regra de supresso utilizada baseada na observao de um evento de trip, acar-
retando na ao de supresso de um total de 78 alarmes. Isto signica que, na parada
do forno, a ocorrncia de um alarme contido nestes 78 no ser visualizada na tela de
monitoramento de alarmes. A ativao de alarmes no contidos nesta lista visualizada
normalmente.
Durante o retorno do forno a operao, os subsistemas componentes desta planta vo
retornando gradativamente, uns antes de outros. Deste modo, necessria a utilizao
de regras para habilitao de diferentes grupos de alarmes. Por exemplo, os alarmes
indicativos de presso baixa do sistema de alimentao de gs combustvel para os pilotos
devem ser habilitados aps a obteno da permisso de purga e quando as vlvulas dos
pilotos forem reabertas.
A Figura 4.5 exemplica bem o processo de supresso e respectiva habilitao grada-
tiva dos alarmes envolvidos nas estratgias elaboradas durante diferentes etapas.
Figura 4.5: Representao temporal dos alarmes e eventos do cenrio estudado.
Como citado na Subseo 3.2.2, o sistema permite a modelagem de regras tanto da
maneira tradicional (linear), quanto utilizando o modelo hierrquico. Para este estudo de
caso, como se trata de estratgias de supresso de alarmes previamente elaboradas por
uma equipe sem o intuito de torn-las hierrquicas, o exerccio foi realizado modelando
as regras de forma linear, utilizando a funcionalidade de se utilizar subsistemas com o
nico objetivo de melhor organizao das regras.
Diante de tais estratgias, um total de treze regras foram modeladas:
1 regra para supresso de alarmes (na ocorrncia de um trip no forno)
12 regras para habilitao de alarmes (no start-up do forno)
A Figura 4.6 demonstra a organizao utilizada para elaborao das regras de su-
presso e habilito de alarmes para o estudo de caso em questo.
Figura 4.6: Estrutura das regras modeladas para o estudo de caso.
4.2.3 Anlise de Resultados
A partir de dados reais obtidos provenientes de histricos de operao do forno, foi
possvel realizar uma simulao do processo de parada e de partida da planta, conforme
ocorreria em uma situao real. Manipulando-se os valores das variveis do processo, os
cenrios foram explorados a m de se obter uma anlise comparativa da quantidade de
noticaes indicativas na tela de operador.
Foi determinado o espao de tempo de 1h a partir do momento da deteco do evento
de trip do forno para obteno de dados estatsticos, e os resultados podem ser vistos na
Tabela 4.5.
# de Alarmes # de Alarmes Suprimidos Reduo (%)
259 154 59,4%
Tabela 4.5: Resultado da supresso em um intervalo de 1h.
Outra estatstica foi extrada ao se analisar um nico instante aps a parada da planta,
e os resultados esto contidos na Tabela 4.6.
Como mostrado na Tabela 4.5, os resultados obtidos se mostraram satisfatrios, ao
ponto de que uma reduo de 59,4% na quantidade de alarmes a serem monitorados em
# de Alarmes # de Alarmes Suprimidos Reduo (%)
15 10 66,7%
Tabela 4.6: Resultado da supresso em um dado instante.
um intervalo de tempo de uma hora acarreta em diversos benefcios no processo de opera-
o de uma planta industrial. Ao se evitar os eventos chamados de avalanche de alarmes,
o tempo de deteco de alarmes crticos por parte do operador se torna menor, resultando
em rpida aes corretivas. A Figura 4.7 demonstra o estado da tela de monitoramento
de alarmes com e sem o sistema de supresso em execuo durante um certo momento da
operao aps a parada do forno (reduo de 66,7% na quantidade de alarmes).
Figura 4.7: Exemplo da tela de visualizao de alarmes sem ( esquerda) e com ( direita)
o sistema de regras em execuo.
Captulo 5
Consideraes Finais e Perspectivas
Futuras
A aplicao apresentada nesta dissertao tem como objetivo suprir uma demanda
que vem sendo requisitada por grandes corporaes do ramo de processos industriais: o
auxlio tomada de decises, pois aes imediatas e precisas so necessrias para evitar
decrscimo de produo e at mesmo evitar incidentes com consequncias graves.
Neste escopo, a soluo proposta mostrou atender bem esse objetivo ao fornecer ao
operador uma tela de monitoramento de alarmes com menos informaes redundantes
ou consideradas desnecessrias atravs de um processamento por um sistema especialista
baseado em regras modeladas para aquela situao. Desta maneira o operador foca sua
ateno em alarmes que so de extrema importncia naquele determinado momento, re-
sultando possivelmente em uma deciso mais rpida e com maior acurcia. importante
frisar que se faz necessria a validao das regras (simulaes, tabelas-verdade, etc.) antes
de torn-las operacionais, visto que a supresso de alarmes um processo de alto nvel de
criticidade.
Esta aplicao incorpora uma importante inovao na rea de processos industriais,
que carece de tais ferramentas que visam evitar a sobrecarga de alarmes em um nico
operador em curtos intervalos de tempo. Tais contribuies, se utilizadas corretamente,
impactam diretamente a operao, tornando-a mais segura e convel.
A funcionalidade desta ferramenta a leva a ter uma ampla gama de aplicaes que
devem ser incorporadas em trabalhos futuros. Devido a sua concepo modular (Figura
3.3), a soluo proposta altamente exvel, permitindo ser utilizada como base para
diversas solues baseadas em regras, como por exemplo, anlise, diagnstico e deteco
de falhas.
Outras perspectivas esto voltadas a adoo de lgica fuzzy nas regras modeladas,
incorporando assim a possibilidade de no se obter uma nica resposta do sistema de
44 CAPTULO 5. CONSIDERAES FINAIS E PERSPECTIVAS FUTURAS
inferncia, e sim um conjunto de solues devidamente ordenadas pela sua probabilidade
de ser a mais correta. E por m, a incorporao de um formalismo de checagem das
regras, a m de se vericar a consistncia das mesmas, evitando assim, por exemplo,
regras conitantes.
Este sistema vem sendo desenvolvido, aprimorado e testado no LII/DCA/UFRN em
parceria com o CENPES/PETROBRAS dentro do projeto de pesquisa denominado SIST
(Sistema Inteligente para Suporte a Deciso para Anlise e Operao de Plantas Industri-
ais).
A soluo apresentada neste trabalho j conta com uma instalao-piloto no Centro de
Pesquisas Petrobras (CENPES), objetivando-se a realizao de testes de validao e usa-
bilidade assim como para coleta e anlise de resultados a m de aprimorar a ferramenta.
Futuras instalaes esto agendadas para incorporar mais credibilidade a ferramenta, as-
sim como gerar retornos necessrios para atualizaes e correo de problemas.
Referncias Bibliogrcas
ANSI/ISA (2009), Isa 18.2 - management of alarm systems for the process industries,
International Society of Automation .
Bali, Michal (2009), Drools JBoss Rules 5.0 Developers Guide, Packt Publishing.
Browne, Paul (2009), JBoss Drools Business Rules, Packt Publishing.
Carrico, M. A., J. E. Girard & J. P. Jones (1989), Building Knowledge Systems: Develop-
ing and Managing Rule-Based Applications, McGraw-Hill, New York.
Dallavalle, Silvia Ins & Edson Walmir Cazarini (2000), Regras do negcio, um fator
chave de sucesso no processo de desenvolvimento de sistemas de informao, En-
contro Nacional de Engenharia de Produo (ENEGEP) .
Deitel, H. M. & P. J. Deitel (2009), Java How to Program, 8 edio, Prentice Hall, New
Jersey.
Devries, Stan (2010), Why is alarm management required in modern plants?, Invensys .
Ding, Yuxin, Qing Wang & Jiahua Huang (2009), The performance optimization of
CLIPS, Ninth International Conference on Hybrid Intelligent Systems (1).
Doorenbos, Robert B. (1995), Production matching for large learning systems, Tese de
doutorado, Pittsburgh, PA, USA. UMI Order No. GAX95-22942.
Druzdzel, M. J. & R. R. Flynn (2002), Decision Support Systems, 2 edio, Marcel
Dekker, Inc, New York.
EEMUA191 (2007), Alarm systems - a guide to design, management and procurement.
publication no 191, Equipment, Engineering & Materials Users Association .
Finlay, P. N. (1994), Introducing Decision Support Systems, Blackwell Publishers, Ox-
ford, UK.
45
46 REFERNCIAS BIBLIOGRFICAS
Flores, C. D. (2003), Fundamentos dos sistemas especialistas, em Sociedades Articiais:
a nova fronteira da inteligncia nas mquinas, p. 332.
Forgy, C. (1982), What is a DSS?, Rete: A Fast Algorithm for the Many Patterns/Many
Objects Match Problem 19(1), 1737.
Friedman-Hill, Ernest (2003), Jess in action: rule-based systems in Java, 2 edio, Man-
ning Publications.
Gachet, A. & P. Haettenschwiler (2003), Developing intelligent decision support systems:
A bipartite approach, em Knowledge-Based Intelligent Information and Engineer-
ing Systems, 7th KES Conference, pp. 8793.
Gameleira, Tiago A., Raimundo Santos Moura & Luiz Affonso H. Guedes (2008), Visual
library: Uma biblioteca para criao de ferramentas de modelagem grca.
Giarratano, J. & G. Riley (1994), Expert Systems Principles and Programming, PWS
Publishing Company, Boston.
Habibi, Eddie & Bill Hollield (2006), Alarm systems greatly affect offshore facilities
amid high oil prices, World Oil Magazine 227 pp. 101105.
Hay, David & Keri Anderson Healy (1997), Guide business rules project: Final report,
Revision 1.2 .
Hollield, B.R. & E. Habibi (2010), Alarm Management: A Comprehensive Guide, Sec-
ond Edition, Isa.
Hopgood, A. (2000), Intelligent Systems for Engineers and Scientists, 2 edio, CRC
Press, New York.
Ignizio, J. P. (1991), Introduction to Expert Systems - The Development and Implementa-
tion of Rule-based Expert Systems, McGraw-Hill, New York.
Keen, P. G. W. & M. S. Scott Morton (1978), Decision support systems : an organiza-
tional perspective, Addison-Wesley.
Leito, Gustavo Bezerra Paz (2008), Algoritmos para anlise de alarmes em processos
petroqumicos, Dissertao de mestrado, Universidade Federal do Rio Grande do
Norte.
REFERNCIAS BIBLIOGRFICAS 47
Lima, Marcelo (2010), Sistema integrado para auxlio anlise de incidentes, Prmio
Petrobras de Tecnologia - 5 Edio .
Mattiasson, C. (1999), The alarm system from the operators perspective, em Human
Interfaces in Control Rooms, Cockpits and Command Centres, 1999. International
Conference on, pp. 217 221.
Mecenas, Ivan (2008), Java 6: Fundamentos, Swing, BlueJ e JDBC, Alta Books.
Metaxiotis, K., D. Askounis & J. Psarras (2002), Expert systems in production plan-
ning and scheduling: a state-of-the-art survey, Journal of Intelligent Manufacturing
13, 253260.
Momoh, J., D. Srinivasan, K. Tomsovic & D. Baer (2000), Chapter 5: Expert systems
applications, em Tutorial on Fuzzy Logic Applications in Power Systems.
Nayak, P. Pandurang, Anoop Gupta & Paul S. Rosenbloom (1988), Comparison of the
rete and treat production matchers for soar, em AAAI88, pp. 693698.
OPC A&E 1.10 Specication, Alarm and Events Custom Interface (2002), Relatrio tc-
nico, OPC Foundation.
OPC DA 3.00 Specication, Data Acess Automation Interface Standard (2003), Relatrio
tcnico, OPC Foundation.
Passos, E. L. (1989), Inteligncia Articial e Sistemas Especialistas ao Alcance de Todos,
LCT, Rio de Janeiro.
Power, D. J. (1997), What is a DSS?, The On-Line Executive Journal for Data-Intensive
Decision Support (1).
Py, M. X. (2002), Sistemas especialistas: Uma introduo.
Sasikumar, M., S. Ramani, S. Muthu Raman, K. S. R. Anjaneyulu & R. Chandrasekar
(1993), Rule Based Expert Systems: A Practical Introduction, Narosa Publishing
House.
Tambe, M., D. Kalp & P.S. Rosenbloom (1992), An efcient algorithm for production
systems with linear-time match, em Tools with Articial Intelligence, 1992. TAI
92, Proceedings., Fourth International Conference on, pp. 3643.
Turban, E. (1989), Decision Support Systems and Expert Systems, MacMillan, New York.
48 REFERNCIAS BIBLIOGRFICAS
Turban, E. (1994), Decision support and expert systems : management support systems,
Prentice Hall, Englewood Cliffs, NJ.
Zimbro, Geraldo (2001), Atenas: Um sistema gerenciador de regras de negcio, XV
Simpsio Brasileiro de Engenharia de Software (SBES) pp. 338343.

DaniloCS DISSERT - Unlocked

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

DaniloCS DISSERT - Unlocked

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE DO RIO GRANDE DO NORTE FEDERAL

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

Você também pode gostar