Escolar Documentos
Profissional Documentos
Cultura Documentos
CDU 004.932(043.2)
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 fornecidos 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 financeiro.
Resumo
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 filtering 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 refinery.
Keywords: expert system, rule-based system, inference engine, rules, alarm management, alarm filtering.
Sumrio
Sumrio
Lista de Figuras
iii
Lista de Tabelas
Introduo
1.1
Objetivo da Dissertao . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fundamentao Terica
2.1
2.2
Sistemas Especialistas . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1
Sistemas de Alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3.1
16
2.3
vii
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
20
3.2.1
21
3.2.2
22
3.2.3
30
3.2
Resultados
4.1 Desempenho do Sistema . . . . . . . . .
4.1.1 Teste I: Incremento de Fatos . . .
4.1.2 Teste II: Incremento de Regras . .
4.1.3 Teste III: Incremento de Disparos
4.2 Estudo de Caso . . . . . . . . . . . . . .
4.2.1 Problema . . . . . . . . . . . . .
4.2.2 Soluo Proposta . . . . . . . . .
4.2.3 Anlise de Resultados . . . . . .
Consideraes Finais e Perspectivas Futuras
Referncias bibliogrficas
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
33
34
35
36
37
37
38
40
43
45
Lista de Figuras
1.1
2.1
2.2
2.3
10
2.4
12
3.1
Arquitetura do BRTools. . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2
18
3.3
21
3.4
22
3.5
23
3.6
24
3.7
25
3.8
26
3.9
26
27
28
29
29
30
31
4.1
35
4.2
36
4.3
37
4.4
38
4.5
39
iii
4.6
4.7
40
41
Lista de Tabelas
2.1
15
4.1
4.2
4.3
4.4
4.5
4.6
34
35
35
36
40
41
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
API:
DRL:
DSS:
ECA:
Evento - Condio - Ao
HSE:
ISA:
JVM:
PES:
SAD:
SGRN:
SI:
Sistema de Informao
vii
Captulo 1
Introduo
O aumento da complexidade dos processos industriais e das novas tecnologias empregadas no setor petroqumico torna pertinente a adoo de novos sistemas auxiliares
de apoio operao e ao processo de tomada de deciso. Diversos elementos concorrem 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 desafios tecnolgicos, 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 eficincia, 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 processos, 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 envolvidos no ramo industrial normalmente so monitorados por um grande conjunto de
alarmes que so usualmente projetados e implantados sem uma filosofia formal de gerenciamento [Devries 2010]. A no utilizao de uma metodologia formal, normalmente
baseada na intuio e no conhecimento prvio dos operadores envolvidos nos processos, 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
CAPTULO 1. INTRODUO
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 operador, solues que visam o problema da sobrecarga de informaes ganharam bastante importncia 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 processos industriais so cada vez mais requisitados pelas empresas do ramo, e a fim 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
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 entendimento do sistema apresentado nesta dissertao. Em uma primeira seo os sistemas de
apoio deciso so apresentados, seguidos de uma explicao da ferramenta computacional chamada de sistema especialista. Por fim, a ltima seo deste captulo contempla
um estudo terico do cenrio atual dos chamados sistemas de alarmes, objetivando-se
CAPTULO 1. INTRODUO
Captulo 2
Fundamentao Terica
Este captulo introduz os conceitos tericos em que o sistema apresentado nesta dissertao est inserido. Esta ferramenta classificada como um sistema de apoio deciso
em processos industriais, e seu principal processamento realizado pela ferramenta computacional chamada de sistema especialista. Tais definies sero apresentadas nas sees
seguintes, separadas em sistemas de apoio deciso e sistemas especialistas, respectivamente. No mbito da aplicao escolhida, a supresso de alarmes, conceitos acerca de
sistemas de alarmes so apresentadas na sequncia.
2.1
A tomada de decises em sistemas complexos, como o caso dos processos industriais, 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 sistema 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 qualidade das decises importante, tornando assim o auxlio s deficincias 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 tm desenvolvido vrios
mtodos para fazer escolhas racionais. Mais recentemente, estes mtodos, muitas vezes
alimentados por uma variedade de tcnicas provenientes da cincia da informao, psicologia cognitiva e inteligncia artificial, tem sido implementados na forma de programas
de computador, seja como ferramentas autnomas ou como ambientes de computao integrados para a tomada de decises complexas [Power 1997]. Tais ambientes so muitas
vezes chamados de sistemas de apoio deciso (SAD), ou tambm decision support systems (DSS).
O conceito de sistemas de apoio deciso bastante amplo, e existem diferentes
definies dependendo do ponto de vista do autor [Druzdzel & Flynn 2002].
Finlay define um SAD como um sistema computacional que auxilia o processo de
tomada de deciso [Finlay 1994]. De uma maneira mais especfica, Turban a define como
um sistema de informao interativo, flexvel 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 fim de melhorar a qualidade das decises [Keen &
Morton 1978].
Reunindo as diversas definies presentes na literatura, possvel chegar a um conceito 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 dados e modelos para a soluo de problemas focando a tomada de deciso. necessrio
enfatizar o fato de esses sistemas serem utilizados para auxiliar o operador, e no substitulo.
Assim como as diferentes definies, existem tambm diferentes nomenclaturas para
diferenciar os vrios tipos de SADs. Uma das nomenclaturas definidas na literatura apresenta 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 modificar, complementar e ajustar a deciso apresentada pelo sistema, para que estas sugestes sejam validadas. Este processo repetido
at que uma soluo consolidada seja gerada.
2.2
Sistemas Especialistas
2.2.1
O sistema baseado em regras o mtodo mais popular para representao de conhecimento dentre os sistemas especialistas [Carrico et al. 1989]. Nessa abordagem, a construo 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
10
da programao declarativa, a separao entre a lgica e os dados, a velocidade e escalabilidade 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 define restries especficas na criao, modificao 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 fim
de se validar a regra. Por fim 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.
11
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 situao. 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, significa 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 algum 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 em sua 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 definido 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 algoritmo de casamento de padres chamado de Rete [Forgy 1982]. O algoritmo Rete um
eficiente 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-
12
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, significa
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 fluxo 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 final 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
13
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 significa 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 utilizado 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 refinado para sistemas orientados
a objeto [Bali 2009]. Ainda, o Drools utiliza o modo de raciocnio baseado no encadeamento progressivo (forward-chaining).
Um exemplo da sintaxe do Drools pode ser vista no cdigo abaixo, com comentrios
em cada linha.
1
2
3
4
5
6
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
14
== "dezembro") em uma instncia da classe Feriado e executa o cdigo Java caso essa
condio seja satisfeita.
1
2
3
4
5
6
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 grficas para o gerenciamento de regras. O
Drools Flow (ou jBM5) prov ferramentas para construo de fluxogramas de processos
de negcio. O componente Drools Planner auxilia a resoluo de problemas de planejamento atravs de meta-heursticas. O mdulo Drools Expert o motor de regras, fundamental para a utilizao desse SGRN. E por fim 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
15
2.3.1
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
16
Valores Recomendados
150 alarmes por dia
Valores Mximos
300 alarmes por dia
6 (em mdia)
12 (em mdia)
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 entrevistas 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 aproximadamente 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 necessidade de se incorporar lgicas e estratgias de supresso de alarmes em diferentes situaes. Em alguns cenrios, como na parada e na partida de uma planta, na ocorrncia de
distrbios, ou durante uma manuteno, determinadas notificaes podem ter suas prioridades degradadas.
Porm a identificao destes cenrios pode no ser uma tarefa trivial e requer a utilizao de tcnicas modernas e eficientes 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 notificaes 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 entendimento do sistema desenvolvido, chamado de BR-PlantExpert. Deste modo, as duas
subsees seguintes esto organizadas da seguinte maneira. Primeiro a Subseo 3.1 apresenta 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
3.1.1 BR-Tools
Tendo em mente uma aplicao inteligente na rea de automao industrial, a ferramenta 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 desenvolvimento de mdulos (chamados plug-ins) que executam sobre este framework, e o
mesmo oferece um ambiente confivel, robusto e eficiente. 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
19
3.1.2
Linguagem Java
A linguagem Java, criada pela Sun Microsystems em 1991, tem como principais caractersticas o fato de ser segura, independente de plataforma e de ser uma linguagem de
programao orientada a objetos.
Programas Java consistem em partes chamadas classes, que por sua vez incluem partes
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 especfico. O tradutor de
bytecodes chamado de Mquina Virtual Java (JVM), sendo o responsvel pela flexibilidade 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 utilizadas no desenvolvimento, a biblioteca visual Visual Library e o sistema de regras JBoss
Drools, e que sero explicadas nos tpicos seguintes.
20
3.1.4
JBoss Drools
3.2
21
A arquitetura proposta est ilustrada na Figura 3.3. As indicaes numricas demonstram o fluxo de dados do sistema.
3.2.1
22
alimentado com regras em linguagem Drools, de difcil compreenso para usurios inexperientes. Por este motivo foi desenvolvido o ambiente de construo de regras, escopo
do segundo mdulo do sistema.
3.2.2
23
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 configurao a tela apresentada na Figura 3.6.
A partir desta tela possvel optar por alarme ou evento e configurar a sua respectiva
tag. A opo delay funciona como um operador temporal, possibilitando somente a validade da condio aps este tempo pr-configurado pelo usurio. Por fim, a opo Tempo
24
de Expirao, habilitada somente para eventos, invalida a condio aps este tempo prconfigurado pelo usurio.
(a)
(b)
25
(c)
da tag. A tag escolhida tem o seu tipo automaticamente definido atravs de uma
consulta ao servidor (Figura 3.7c).
Definida a tag da varivel de processo, a condio do bloco configurada a partir
de uma expresso que define 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:
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 configurao 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.
26
Desta maneira possvel associar o estado de um sistema a partir dos estados de outros
sistemas. O painel de configurao 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 oferecidos 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)
Modelagem Hierrquica
Uma das grandes inovaes do sistema proposto consiste em permitir que as regras sejam modeladas utilizando-se uma arquitetura hierrquica, o que torna possvel uma estruturao 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 filho 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 supresso 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
27
for bem modelado, todo sistema/subsistema pertencente a ele ter apenas dois estados:
Operando e Parado. Sempre que um terceiro estado precisa ser definido para caracterizar
o subsistema, isto ser indicativo de que este dever ser subdividido em outros subsistemas.
A Figura 3.10 demonstra um exemplo de modelagem hierrquica de uma planta didtica:
No entanto, a ferramenta permite tambm a modelagem de regras de um modo tradicional, ou, linear. Desta maneira, possvel simplesmente traduzir regras j estrategicamente elaboradas e traduzi-las de forma visual no ambiente de construo de regras.
Essa possibilidade torna o sistema mais flexvel, permitindo ao usurio diferentes
metodologias de modelagem de regras, tanto a mais tradicional quanto uma mais sofisticada.
Interface Grfica
A interface grfica (GUI) do ambiente de construo de regras foi desenvolvida com
o objetivo de simplificar 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 ferramentas temos: criar novo sistema/subsistema; remover o sistema/subsistema selecionado;
28
29
repassada ao sistema especialista atravs de uma linguagem e sintaxe compatveis. Fazse 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 sistema especialista.
30
Figura 3.14: A mesma regra da Figura 3.13 traduzida para linguagem DRL.
3.2.3
31
32
Captulo 4
Resultados
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 um limite 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 especificaes necessrias para a
categoria em que ele est inserido.
Diferentes experimentos foram estudados e analisados a objetivando-se quantificar o
desempenho do sistema desenvolvido. Aps uma anlise do tempo de execuo do sistema, foram selecionados trs principais fatores que poderiam refletir significativamente
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 controlados, 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 fim de se obter resultados mais precisos
e confiveis, cada teste foi repetido dez vezes e sua respectiva mdia aritmtica foi calculada.
Para um melhor entendimento dos experimentos realizados, trs conceitos devem ser
revisados:
Regra: Regra na linguagem DRL, previamente modelada no ambiente de construo 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 especialista. 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 casamento 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
Teste I
10-100000
Teste II 5000
Teste III 5000
# de regras
# de disparos
5000
500-5000
5000
500
500
10-5000
4.1.1
35
Quant. de fatos
10
100
1000
10000
100000
Tempo Mnimo
Tempo Mximo
Tempo Mdio
Desvio Padro
30
31
30.3
0.48
30
32
31
0.67
34
37
35
1.15
37
38
37.1
0.32
38
40
39.5
0.70
Como pode ser concludo analisando os resultados obtidos nesse experimento, o incremento de fatos no impactou significativamente o tempo de execuo do sistema.
4.1.2
1000
1500
2000
2500
3000
3500
4000
4500
5000
Tempo Mnimo
Tempo Mximo
Tempo Mdio
Desvio Padro
33
35
33.8
0.63
33
35
33.9
0.57
34
35
34.3
0.48
34
36
34.4
0.70
34
36
35.2
0.63
34
36
35.2
0.79
34
36
35.3
0.82
35
37
35.8
0.63
35
37
36.3
0.67
30
35
32.4
1.84
36
CAPTULO 4. RESULTADOS
4.1.3
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
Tempo Mnimo
Tempo Mximo
Tempo Mdio
Desvio Padro
3
4
3.5
0.53
7
9
7.8
0.63
18
30
65
20
37
70
18.9 34.6 67.2
0.74 2.22 1.68
1
1
1
0
500
1000
2000
3000
4000
5000
167
277
463
594
171
289
475
607
169.4 282.8 471.5 600.3
1.35 3.73 3.66 3.97
37
4.2
Estudo de Caso
4.2.1
Problema
38
CAPTULO 4. RESULTADOS
4.2.2
Soluo Proposta
A soluo proposta buscou adotar uma estratgia de supresso de alarmes e de suas habilitaes automticas de acordo com as condies operacionais do forno. Tais estratgias
e lgicas envolvidas foram elaboradas por uma equipe multidisciplinar envolvida diretamente ao processo de estudo, com conhecimento de seu comportamento em condies
normais e anormais de operao.
39
A regra de supresso utilizada baseada na observao de um evento de trip, acarretando na ao de supresso de um total de 78 alarmes. Isto significa 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 exemplifica bem o processo de supresso e respectiva habilitao gradativa dos alarmes envolvidos nas estratgias elaboradas durante diferentes etapas.
40
CAPTULO 4. RESULTADOS
A Figura 4.6 demonstra a organizao utilizada para elaborao das regras de supresso e habilito de alarmes para o estudo de caso em questo.
4.2.3
Anlise de Resultados
# de Alarmes Suprimidos
Reduo (%)
259
154
59,4%
41
# de Alarmes
# de Alarmes Suprimidos
Reduo (%)
15
10
66,7%
Figura 4.7: Exemplo da tela de visualizao de alarmes sem ( esquerda) e com ( direita)
o sistema de regras em execuo.
42
CAPTULO 4. RESULTADOS
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, resultando 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 confivel.
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 flexvel, 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
Referncias Bibliogrficas
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: Developing 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, Encontro 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, Oxford, UK.
45
46
REFERNCIAS BIBLIOGRFICAS
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 planning 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 Specification, Alarm and Events Custom Interface (2002), Relatrio tcnico, OPC Foundation.
OPC DA 3.00 Specification, Data Acess Automation Interface Standard (2003), Relatrio
tcnico, OPC Foundation.
Passos, E. L. (1989), Inteligncia Artificial 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 efficient algorithm for production
systems with linear-time match, em Tools with Artificial 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.