Você está na página 1de 60

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

U NIVERSIDADE F EDERAL DO R IO G RANDE DO N ORTE


C ENTRO DE T ECNOLOGIA
P ROGRAMA DE P S -G RADUAO EM E NGENHARIA E LTRICA

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 Computao.
1. Redao tcnica - Tese. 2. LATEX- 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 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

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 confivel 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 filtragem 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 refinaria de petrleo e gs.
Palavras-chave: sistema especialista, sistema baseado em regras, 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 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

Lista de Smbolos e Abreviaturas


1

Introduo

1.1

Objetivo da Dissertao . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fundamentao Terica

2.1

Sistemas de Apoio Deciso . . . . . . . . . . . . . . . . . . . . . . . .

2.2

Sistemas Especialistas . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1

Sistemas Baseados em Regras de Produo . . . . . . . . . . . .

Sistemas de Alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.3.1

16

2.3

vii

Estratgias de Inibio de Alarmes . . . . . . . . . . . . . . . . .

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

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

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

Crescimento da quantidade de alarmes controlados por operador ao longo


dos anos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1

Subgrupos da Inteligncia Artificial (IA). . . . . . . . . . . . . . . . . .

2.2

Arquitetura tpica de um sistema especialista. . . . . . . . . . . . . . . .

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 configurao do bloco de alarmes e eventos. . . . . . . . . . . .

24

3.7

Painel de configurao do bloco de varivel de processo. . . . . . . . . .

25

3.8

Painel de configurao 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 grfica 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 grfica da interface de visualizao de alarmes. . . . . . . . . .

31

4.1

Grfico dos resultados obtidos no Teste I. . . . . . . . . . . . . . . . . .

35

4.2

Grfico dos resultados obtidos no Teste II. . . . . . . . . . . . . . . . . .

36

4.3

Grfico 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
4.7

Estrutura das regras modeladas para o estudo de caso. . . . . . . . . . . .


Exemplo da tela de visualizao de alarmes sem ( esquerda) e com (
direita) o sistema de regras em execuo. . . . . . . . . . . . . . . . . . .

40
41

Lista de Tabelas

2.1

Valores ideais e mximos de alarmes por operador por unidades de tempo.

15

4.1
4.2
4.3
4.4
4.5
4.6

Informaes dos testes de desempenho realizados.


Resultados do Teste I (em milisegundos). . . . .
Resultados do Teste II (em milisegundos). . . . .
Resultados do Teste III (em milisegundos). . . . .
Resultado da supresso em um intervalo de 1h. .
Resultado da supresso em um dado instante. . .

34
35
35
36
40
41

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

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

informao em pequenos intervalos de tempo, o mesmo se torna passvel de erros, como


o caso da no identificao de um alarme crtico. Como mostra o estudo feito por Habibi
& Hollifield (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 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.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 eficazes que priorizem informaes importantes e minimizem informaes redundantes durante a operao acabam
resultando em aes falhas e/ou lentas por parte dos operadores. No entanto, a incorporao 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 confivel e segura ao priorizar informaes e
filtrar notificaes 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, fundamentado 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 especfico de programao. Desta
forma, diferentes aplicaes podem ser definidas 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 filtragem 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 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

apresentar a rea de atuao da aplicao proposta.


O Captulo 3 consiste na apresentao do sistema proposto. Este captulo contempla 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 fim de se validar a ferramenta.
Por fim, 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 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

Sistemas de Apoio Deciso

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

CAPTULO 2. FUNDAMENTAO TERICA

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

A rea da computao chamada de inteligncia artificial bastante ampla e pode ser


dividida em subgrupos, como exemplificado 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 especialista(s) em uma determinada rea, visando resolver problemas relativos a um domnio
especfico [Passos 1989].

2.2. SISTEMAS ESPECIALISTAS

Figura 2.1: Subgrupos da Inteligncia Artificial (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 definidos como ferramentas computacionais
que modelam o raciocnio e as aes de um humano ou grupo especialista em uma determinada rea de conhecimento. Desse modo, sistemas especialistas, assim como humanos especialistas, agem de acordo com seu domnio em um conhecimento especfico
[Flores 2003].
Fazendo uma analogia aos sistemas de apoio deciso, um sistema especialista pode
ser definido como um sistema computacional que emula a habilidade de tomada de deciso de um humano especialista.
A arquitetura tpica de um sistema especialista composta de trs componentes principais: a base de conhecimento, o motor de inferncia e a interface de usurio [Momoh

CAPTULO 2. FUNDAMENTAO TERICA

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 especfico. Esse conhecimento extrado a partir de fatos, heursticas (experincias, 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 especialista. 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. Normalmente 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 influenciam a sua grande utilizao. Entre eles podemos citar:
Versatilidade: Um sistema especialista pode ser executado em quase qualquer sistema computacional.
Custo reduzido: O custo de prover conhecimento por usurio reduzido.

2.2. SISTEMAS ESPECIALISTAS

Perigo reduzido: Os sistemas especialistas podem ser utilizados em ambientes


nocivos a um humano.
Permanncia: O conhecimento permanente, diferentemente dos especialistas humanos onde o conhecimento no armazenado indefinidamente.
Conhecimento mltiplo: O conhecimento de mltiplos especialistas pode ser armazenado 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 emergncia, quando um humano pode no operar com sua total eficincia 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 especialista 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 fundamental em quase todo sistema computacional, evitando que o sistema trave e consequentemente aumentando sua confiabilidade. Por fim, 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 conhecimento 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 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

CAPTULO 2. FUNDAMENTAO TERICA

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.

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 conhecimento 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

2.2. SISTEMAS ESPECIALISTAS

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

CAPTULO 2. FUNDAMENTAO TERICA

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

Figura 2.4: Rede de Rete obtida do exemplo dado.

2.2. SISTEMAS ESPECIALISTAS

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

r u l e " Nova R e g r a " / / I n i c i o da r e g r a


when
/ / Condicoes
then
/ / Acoes
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

14

CAPTULO 2. FUNDAMENTAO TERICA

== "dezembro") em uma instncia da classe Feriado e executa o cdigo Java caso essa
condio seja satisfeita.

1
2
3
4
5
6

r u l e " F e r i a d o s do Ms de Dezembro "


when
f : F e r i a d o ( mes == " dezembro " )
then
System . o u t . p r i n t l n ( f . nome + " : " + f . d i a + " / " + f . mes ) ;
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 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

Alarmes so sinais de notificao ao operador, tipicamente apresentados atravs de


efeitos sonoros, indicao visual, mensagens ou outro tipo de identificador. 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 considerados inseguros [ANSI/ISA 2009].
Tradicionalmente os alarmes eram baseados em painis com lmpadas indicativas,
limitando a quantidade de notificaes disponveis e dificultando 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 grficas normalmente 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 funcionamento da planta. Dessa forma, tais sinalizaes, ou melhor chamados alarmes, auxiliam
os operadores na efetiva identificao 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 reconhecimentos 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 refinarias de petrleo. Seu principal
objetivo receber as notificaes 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, configurao e gerenciamento de alarmes. Desta forma,
a redundncia e a baixa relevncia de determinados alarmes atribui uma carga de informao adicional aos operadores, que acaba por tornar muitas vezes a interpretao de
mltiplas notificaes uma tarefa humanamente impossvel. Consequentemente, a tardia
ou a no correta identificao de uma anormalidade colabora na ocorrncia de incidentes
na indstria.
Uma pesquisa realizada pela HSE (Health and Safety Executive) em 15 plantas industriais identificou a ocorrncia de diversos incidentes diretamente envolvidos com a m
configurao 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 Automation) 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 notificaes 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 [Hollifield & 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

16

Alarmes Anunciados por Tempo


Alarmes Anunciados por Dia por
Operador
Alarmes Anunciados por Hora por
Operador
Alarmes Anunciados por 10 Minutos por Operador

CAPTULO 2. FUNDAMENTAO TERICA

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

Para o desenvolvimento da ferramenta apresentada nesta dissertao, foram utilizadas


quatro principais tecnologias. Estas so: a plataforma de comunicao de dados BRTools, a linguagem de programao Java, a biblioteca grfica 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 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

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 Specification, 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 Specification, 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 em execuo sem plug-ins carregados, primeiramente, 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 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.

3.1.3 Visual Library


A biblioteca Visual Library foi criada pela Netbeans a fim permitir uma maior variedade de formatos de visualizao e modelagem grfica 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.

20

3.1.4

CAPTULO 3. SISTEMA DESENVOLVIDO

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 ferramenta apresentada nesta dissertao esto a compatibilidade com a linguagem de programao 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
modificados.
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, combinando 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 grfica de regras que sero posteriormente
carregadas na base de conhecimento do sistema especialista.
A fim 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 filtrar alarmes que sejam considerados desnecessrios 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 detalhadamente.

3.2. ARQUITETURA E APLICAO PROPOSTA

21

A arquitetura proposta est ilustrada na Figura 3.3. As indicaes numricas demonstram o fluxo de dados do sistema.

Figura 3.3: Arquitetura proposta do BR-PlantExpert.

O fluxo 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 fluxo caracterizado pela indicao 1.
A indicao 2 demonstra o fluxo de dados que representa o carregamento da base
de regras do sistema especialista pelas regras modeladas no ambiente de construo de
regras.
Por fim, a indicao 3 representa o fluxo de alarmes repassados para a interface de
visualizao de alarmes devidamente filtrados 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 grfica e
transparente ao usurio, sendo executado em background.
Este mdulo funciona independente dos demais, porm necessrio que o mesmo seja

22

CAPTULO 3. SISTEMA DESENVOLVIDO

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

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 configurados 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 finalidade de tornar mais claro seus objetivos e funcionalidades. 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 definio de sistemas, estruturas que representam


um conjunto ou parte de uma planta industrial. Estes sistemas so formados por estados,
responsveis por refletir o funcionamento atual do sistema em questo. Cada estado
ento definido 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

3.2. ARQUITETURA E APLICAO PROPOSTA

23

estados de outros sistemas.


Estas regras so construdas ento para definir a ativao ou no de um estado, determinando 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 dificultando seu entendimento e compreenso por um usurio sem experincia. Desta forma, a programao 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 funcionais configurveis, assim como operadores lgicos, para a lgica da regra em questo
ser ento elaborada.
Os blocos funcionais disponveis na ferramenta so organizados em trs 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 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

CAPTULO 3. SISTEMA DESENVOLVIDO

Figura 3.6: Painel de configurao do bloco de alarmes e eventos.

de Expirao, habilitada somente para eventos, invalida a condio aps este tempo prconfigurado 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 configurao 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
definido 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 definido atravs de uma
consulta ao servidor (Figura 3.7b).
Mtodo por busca com mscara: Este mtodo permite ao usurio inserir uma
mscara responsvel por filtrar as tags disponveis no servidor, facilitando a escolha

3.2. ARQUITETURA E APLICAO PROPOSTA

(a)

(b)

25

(c)

Figura 3.7: Painel de configurao do bloco de varivel de processo.

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:

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

CAPTULO 3. SISTEMA DESENVOLVIDO

Figura 3.8: Painel de configurao do bloco de estado.

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)

Figura 3.9: Operadores disponveis na construo de regras.

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

3.2. ARQUITETURA E APLICAO PROPOSTA

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:

Figura 3.10: Exemplo de modelagem hierrquica de uma planta industrial.

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

CAPTULO 3. SISTEMA DESENVOLVIDO

Figura 3.11: Interface grfica do ambiente de construo de regras.

renomear um sistema/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 modeladas 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 final do
estado, caracterizado pela borda cinza.
Por fim, 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 configurar 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

3.2. ARQUITETURA E APLICAO PROPOSTA

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.

A fim de serem processadas pelo sistema especialista baseado em regras, necessrio


que as regras modeladas pelo usurio no ambiente de construo de regras sejam traduzidas 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 configuraes 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, podendo assim ser processada pelo Drools.

Figura 3.13: Exemplo de uma regra modelada utilizando programao visual.

30

CAPTULO 3. SISTEMA DESENVOLVIDO


r
ul
e"
Bom ba 1A -Par
ado"sal
i
ence0
when
(
Al
ar
m Event
(
t
ag == "
XA55556"
)f
r
om ent
r
ypoi
ntAl
ar
m Event
or
(
Pr
oc
essDat
aFac
t
(
t
ag == "
VX1A"
,val
ue == f
al
se)f
r
om ent
r
ypoi
ntVar
i
abl
e
and
Pr
oc
essDat
aFac
t
(
t
ag == "
VX1B"
,val
ue == f
al
se)f
r
om ent
r
ypoi
ntVar
i
abl
e)
)
t
hen
Onl
i
neSt
at
eDat
aBase.
get
I
nst
anc
e(
)
.
set
St
at
eTr
ue(
"
SubSi
st
em a 10"
,"
Par
ado"
)
;
end

Figura 3.14: A mesma regra da Figura 3.13 traduzida para linguagem DRL.

3.2.3

Tela de Monitoramento de Alarmes

A fim 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 identificao de possveis causas-raiz de anormalidades a partir
de alarmes se torna uma tarefa mais eficiente, resultando em aes imediatas mais eficazes
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, permitindo assim verificar seu comportamento nos ltimos minutos;
Disponibilizao de informaes de racionalizao do alarme provenientes de outras fontes de dados.
A interface (Figura 3.15), desenvolvida visando disponibilizar uma tela agradvel a
fim de evitar o cansao visual por parte do operador, dispe de uma lista de alarmes ativos
(Indicao 1) - j devidamente filtrados pelas regras do sistema especialista - com suas
prioridades indicadas por diferentes cores pr-configuradas 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 empregado em diversos setores industriais [Leito 2008].

3.2. ARQUITETURA E APLICAO PROPOSTA

31

Figura 3.15: Interface grfica 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 intuitiva a identificao da causa raiz da anormalidade sinalizada pelo alarme por parte do
operador.
Por fim, na indicao 4 mostrada um grfico com a leitura das ltimas horas da
varivel de processo relacionada diretamente a ocorrncia de alarme. Esse grfico 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 disponibilizar online ao operador as ocorrncias de alarmes (identificados como relevantes pelo
sistema de supresso), alm de todas as informaes necessrias para uma melhor e mais
rpida identificao 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.

32

CAPTULO 3. SISTEMA DESENVOLVIDO

Captulo 4
Resultados

Este captulo rene testes e experimentos realizados a fim de se quantificar e qualificar


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

Tabela 4.1: Informaes dos testes de desempenho realizados.

4.1.1

Teste I: Incremento de Fatos

O primeiro 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
fixados.
As informaes do primeiro teste podem ser vistas na Tabela 4.1. Os resultados obtidos esto contidos na Tabela 4.2 e seu respectivo grfico pode ser visto na Figura 4.1

4.1. DESEMPENHO DO SISTEMA

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

Tabela 4.2: Resultados do Teste I (em milisegundos).

Figura 4.1: Grfico dos resultados obtidos no Teste I.

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

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

Tabela 4.3: Resultados do Teste II (em milisegundos).

36

CAPTULO 4. RESULTADOS

Figura 4.2: Grfico dos resultados obtidos no Teste II.

Assim como no primeiro teste de desempenho, o incremento de regras no interfere


significativamente 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

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

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 monitoramento online de processos industriais.

4.2. ESTUDO DE CASO

37

Figura 4.3: Grfico 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 estudo de caso possvel verificar a experincia do usurio desde a modelagem das regras
no ambiente proposto at a validao das mesmas atravs da observao das sadas indicadas 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 refinarias 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 significativa de
alarmes, porm nem todos trazendo informaes relevantes para aquela situao.
Uma grande parte dos alarmes ativados durante este processo de trip no trazem informaes adequadas ao estado atual da planta, pois, aps o acionamento do sistema
intertravamento do forno, grande parte dos subsistemas do mesmo no estaro em funcionamento. 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-

38

CAPTULO 4. RESULTADOS

sistema novamente relevantes ao operador.


A fim de ilustrar a avalanche de notificaes em que o operador se torna sujeito durante
a ocorrncia de um trip do forno industrial em questo, uma representao grfica 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 profissionais experientes no processo em estudo revelaram que


na ocorrncia de uma parada total do forno, 78 diferentes alarmes configurados 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 crticos ao processo. Uma menor carga de informaes entregues ao operador resulta em uma
deteco mais rpida e consequentemente em uma tomada de deciso mais eficaz.
Porm, a fim de se tornar um sistema seguro e eficiente necessrio tambm incorporar 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

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.

4.2. ESTUDO DE CASO

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.

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)

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.

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 fim de se obter uma anlise comparativa da quantidade de
notificaes 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

4.2. ESTUDO DE CASO

41

# 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 operao 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.

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

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 fim, a incorporao de um formalismo de checagem das
regras, a fim de se verificar a consistncia das mesmas, evitando assim, por exemplo,
regras conflitantes.
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 Industriais).
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 usabilidade assim como para coleta e anlise de resultados a fim de aprimorar a ferramenta.
Futuras instalaes esto agendadas para incorporar mais credibilidade a ferramenta, assim como gerar retornos necessrios para atualizaes e correo de problemas.

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

Flores, C. D. (2003), Fundamentos dos sistemas especialistas, em Sociedades Artificiais:


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, Manning Publications.
Gachet, A. & P. Haettenschwiler (2003), Developing intelligent decision support systems:
A bipartite approach, em Knowledge-Based Intelligent Information and Engineering 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 grfica.
Giarratano, J. & G. Riley (1994), Expert Systems Principles and Programming, PWS
Publishing Company, Boston.
Habibi, Eddie & Bill Hollifield (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 .
Hollifield, B.R. & E. Habibi (2010), Alarm Management: A Comprehensive Guide, Second 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 Implementation of Rule-based Expert Systems, McGraw-Hill, New York.
Keen, P. G. W. & M. S. Scott Morton (1978), Decision support systems : an organizational 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 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.

Você também pode gostar