Sistema Especialista para Supressão Alarmes em …...sistemas de apoio à decisão. Neste sentido,...

UNIVERSIDADE DO RIO GRANDE DO NORTEFEDERAL

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE TECNOLOGIA

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA

Sistema Especialista para Supressão Online deAlarmes em Processos Industriais

Danilo Curvelo de Souza

Orientador: Prof. Dr. Adrião Duarte Dória Neto

Co-orientador: Prof. Dr. Jorge Dantas de Melo

Dissertação de Mestrado apresentada aoPrograma de Pós-Graduação em EngenhariaElétrica e de Computação da UFRN (área deconcentração: Engenharia de Computação)como parte dos requisitos para obtenção dotítulo de Mestre em Ciências.

Natal, RN, fevereiro de 2013

Divisão de Serviços Técnicos

Catalogação da publicação na fonte. UFRN / Biblioteca Central Zila Mamede

Souza, Danilo Curvelo de.Sobre a Preparação de Propostas de Tema, Dissertações e Teses no Programa

de Pós-Graduação em Engenharia Elétrica da UFRN / Danilo Curvelo de Souza- Natal, RN, 2013

23 p.

Orientador: Adrião Duarte Dória NetoCo-orientador: Jorge Dantas de Melo

Tese (doutorado) - Universidade Federal do Rio Grande do Norte. Centrode Tecnologia. Programa de Pós-Graduação em Engenharia Elétrica e de Com-putação.

1. Redação técnica - Tese. 2. LATEX- Tese. I. Melo, Sicrano Matosinho de. II.Amaral, Beltrano Catandura do. III. Título.

RN/UF/BCZM CDU 004.932(043.2)

Sistema Especialista para Supressão Online deAlarmes em Processos Industriais

Danilo Curvelo de Souza

Dissertação de Mestrado aprovada em 01 de fevereiro de 2013 pela banca examinadoracomposta pelos seguintes membros:

Prof. Dr. Adrião Duarte Dória 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. Mário Cesar Mello Massa de Campos . . . . . . CENPES/PETROBRAS

Agradecimentos

Ao meu orientador e ao meu co-orientador, Dr. Adrião Duarte Dória Neto e Dr. JorgeDantas de Melo, sou grato pela orientação.

Ao professores Dr. Luiz Affonso Henderson Guedes e Dr. Diego Rodrigo Cabral Silvapelas críticas e sugestões.

Às sugestões do Dr. Mário Campos quanto a defesa da dissertação.

Ao apoio técnico de Kaku Saito e a equipe do CENPES-PETROBRAS.

Aos amigos do Laboratório de Informática Industrial, pela assistência e incentivos forneci-dos durante o planejamento e desenvolvimento desse trabalho.

À minha família pelo apoio durante esta jornada.

À minha namorada, Carla, por sempre me proporcionar momentos felizes.

Aos Top & Amigos pelos momentos de diversão e descontração.

À CAPES, pelo apoio financeiro.

Resumo

A operação de processos industriais vem se tornando mais complexa ao longo dosanos, e um dos elementos que possibilitam este aumento de complexidade é a integraçãode novas tecnologias e soluções inteligentes empregadas no setor, como é o caso dossistemas de apoio à decisão.

Neste sentido, esta dissertação visa o desenvolvimento de um sistema de auxílio àoperação baseado em uma ferramenta computacional chamada de sistema especialista. Oobjetivo principal é tornar a operação mais confiável e segura ao maximizar a quantidadede informações relevantes a cada situação através da utilização de um sistema especialistabaseado em regras pré-moldadas para uma determinada área de conhecimento. Para amodelagem de tais regras foi proposto um ambiente de alto-nível, que permite a criação emanipulação de regras de forma facilitada através de programação visual.

A despeito de sua ampla gama de possíveis aplicações, esta dissertação tem comofoco o contexto de filtragem em tempo real de alarmes durante a operação, devidamentevalidada em um estudo de caso baseado em um cenário real ocorrido em uma plantaindustrial de uma refinaria de petróleo e gás.

Palavras-chave: sistema especialista, sistema baseado em regras, motor de inferência,regras, gerenciamento de alarmes, supressão de alarmes.

Abstract

Operating industrial processes is becoming more complex each day, and one of thefactors that contribute to this growth in complexity is the integration of new technologiesand 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 ancomputational tool called expert system. The main goal is to turn operation more reliableand secure while maximizing the amount of relevant information to each situation byusing an expert system based on rules designed for a particular area of expertise. Forthe modeling of such rules has been proposed a high-level environment, which allows thecreation and manipulation of rules in an easier way through visual programming.

Despite its wide range of possible applications, this dissertation focuses only in thecontext of real-time filtering of alarms during the operation, properly validated in a casestudy 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 manage-ment, alarm filtering.

Sumário

Sumário i

Lista de Figuras iii

Lista de Tabelas v

Lista de Símbolos e Abreviaturas vii

1 Introdução 11.1 Objetivo da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Fundamentação Teórica 52.1 Sistemas de Apoio à Decisão . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Sistemas Especialistas . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Sistemas Baseados em Regras de Produção . . . . . . . . . . . . 9

2.3 Sistemas de Alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.1 Estratégias de Inibição de Alarmes . . . . . . . . . . . . . . . . . 16

3 Sistema Desenvolvido 173.1 Tecnologias Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1 BR-Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.2 Linguagem Java . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.3 Visual Library . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.4 JBoss Drools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Arquitetura e Aplicação Proposta . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 Sistema Especialista Baseado em Regras . . . . . . . . . . . . . 21

3.2.2 Ambiente de Construção de Regras . . . . . . . . . . . . . . . . 22

3.2.3 Tela de Monitoramento de Alarmes . . . . . . . . . . . . . . . . 30

i

4 Resultados 334.1 Desempenho do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.1 Teste I: Incremento de Fatos . . . . . . . . . . . . . . . . . . . . 344.1.2 Teste II: Incremento de Regras . . . . . . . . . . . . . . . . . . . 354.1.3 Teste III: Incremento de Disparos . . . . . . . . . . . . . . . . . 36

4.2 Estudo de Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2.1 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2.2 Solução Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.3 Análise de Resultados . . . . . . . . . . . . . . . . . . . . . . . 40

5 Considerações Finais e Perspectivas Futuras 43

Referências bibliográficas 45

Lista de Figuras

1.1 Crescimento da quantidade de alarmes controlados por operador ao longodos anos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Subgrupos da Inteligência Artificial (IA). . . . . . . . . . . . . . . . . . 7

2.2 Arquitetura típica de um sistema especialista. . . . . . . . . . . . . . . . 8

2.3 Arquitetura típica 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 Organização das regras no contexto da aplicação. . . . . . . . . . . . . . 22

3.5 Blocos funcionais disponíveis na aplicação. . . . . . . . . . . . . . . . . 23

3.6 Painel de configuração do bloco de alarmes e eventos. . . . . . . . . . . . 24

3.7 Painel de configuração do bloco de variável de processo. . . . . . . . . . 25

3.8 Painel de configuração do bloco de estado. . . . . . . . . . . . . . . . . . 26

3.9 Operadores disponíveis na construção de regras. . . . . . . . . . . . . . . 26

3.10 Exemplo de modelagem hierárquica de uma planta industrial. . . . . . . . 27

3.11 Interface gráfica do ambiente de construção de regras. . . . . . . . . . . . 28

3.12 Interface de tradução acoplando o ambiente de construção de regras aosistema especialista. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.13 Exemplo de uma regra modelada utilizando programação visual. . . . . . 29

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

3.15 Interface gráfica da interface de visualização de alarmes. . . . . . . . . . 31

4.1 Gráfico dos resultados obtidos no Teste I. . . . . . . . . . . . . . . . . . 35

4.2 Gráfico dos resultados obtidos no Teste II. . . . . . . . . . . . . . . . . . 36

4.3 Gráfico dos resultados obtidos no Teste III. . . . . . . . . . . . . . . . . 37

4.4 Histórico de real de Alarmes/Hora na ocorrência de um trip no forno. . . 38

4.5 Representação temporal dos alarmes e eventos do cenário estudado. . . . 39

iii

4.6 Estrutura das regras modeladas para o estudo de caso. . . . . . . . . . . . 404.7 Exemplo da tela de visualização de alarmes sem (à esquerda) e com (à

direita) o sistema de regras em execução. . . . . . . . . . . . . . . . . . . 41

Lista de Tabelas

2.1 Valores ideais e máximos de alarmes por operador por unidades de tempo. 15

4.1 Informações dos testes de desempenho realizados. . . . . . . . . . . . . . 344.2 Resultados do Teste I (em milisegundos). . . . . . . . . . . . . . . . . . 354.3 Resultados do Teste II (em milisegundos). . . . . . . . . . . . . . . . . . 354.4 Resultados do Teste III (em milisegundos). . . . . . . . . . . . . . . . . . 364.5 Resultado da supressão em um intervalo de 1h. . . . . . . . . . . . . . . 404.6 Resultado da supressão em um dado instante. . . . . . . . . . . . . . . . 41

v

Lista de Símbolos e Abreviaturas

API: Application Programming Interface

DRL: Drools Rule Language

DSS: Decision Support System

ECA: Evento - Condição - Ação

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 à Decisão

SGRN: Sistema de Gerenciamento de Regras de Negócio

SI: Sistema de Informação

vii

Capítulo 1

Introdução

O aumento da complexidade dos processos industriais e das novas tecnologias em-pregadas no setor petroquímico torna pertinente a adoção de novos sistemas auxiliaresde apoio à operação e ao processo de tomada de decisão. Diversos elementos concor-rem para este aumento de complexidade, desde a incorporação de padrões mais restritivospara emissão de poluentes, menor desperdício de matéria-prima e de consumo de energia,busca por acréscimo de produtividade e até mesmo o aparecimento de novos desafios tec-nológicos, tais como os existentes para a exploração e produção de óleo e gás na camadapré-sal.

Assim, empresas do ramo industrial cada vez mais investem em novas tecnologiasobjetivando a melhoria do desempenho, da produtividade, da eficiência, da qualidade e dasegurança operacional de seus processos. Dentre estas novas tecnologias estão os sistemascomputacionais auxiliares, permitindo assim uma redução nos índices de falhas humanas.

Neste contexto, o processo de tomada de decisão dos setores tático e estratégico deuma organização industrial passou por várias mudanças no decorrer das últimas décadas,mudança que está diretamente relacionada à incorporação da informática em seus proces-sos, permitindo, assim, atender a necessidade de se obter respostas rápidas e até mesmointeligentes a partir dos sistemas utilizados.

Visando ainda um acréscimo relacionado a segurança operacional, os processos en-volvidos no ramo industrial normalmente são monitorados por um grande conjunto dealarmes que são usualmente projetados e implantados sem uma filosofia formal de geren-ciamento [Devries 2010]. A não utilização de uma metodologia formal, normalmentebaseada na intuição e no conhecimento prévio dos operadores envolvidos nos proces-sos, somada a adoção dos PES (sistemas eletrônicos programáveis) que torna a adição denovos alarmes uma tarefa de baixo custo, acaba por promover a geração simultânea demúltiplos alarmes na ocorrência de determinados eventos.

Deste modo, ao expor o operador ao processamento de uma grande quantidade de

2 CAPÍTULO 1. INTRODUÇÃO

informação em pequenos intervalos de tempo, o mesmo se torna passível de erros, comoé o caso da não identificação de um alarme crítico. Como mostra o estudo feito por Habibi& Hollifield (2006) (Figura 1.1), existe um crescente aumento na quantidade de alarmescontrolados por operador ao longo dos anos, fato que pode vir a promover a ocorrênciade diferentes incidentes, tais como danos ao meio ambiente ou perda de produção.

Figura 1.1: Crescimento da quantidade de alarmes controlados por operador ao longo dosanos.

Devido a esse rápido crescimento na quantidade de alarmes controlados por um opera-dor, soluções que visam o problema da sobrecarga de informações ganharam bastante im-portância no ambiente industrial. Uma das soluções voltadas a resolução deste problemasão as estratégias de inibição de alarmes, onde, a partir da detecção de certos cenários,determinados alarmes são suprimidos.

Desta maneira, sistemas que possam auxiliar o monitoramento e a operação de proces-sos industriais são cada vez mais requisitados pelas empresas do ramo, e a fim de atenderessa demanda o trabalho realizado nesta dissertação visa aplicar soluções computacionaisinteligentes ao problema da supressão online de alarmes em processos industriais.

1.1. OBJETIVO DA DISSERTAÇÃO 3

1.1 Objetivo da Dissertação

O objetivo principal do desenvolvimento deste tema de dissertação é apresentar umaferramenta responsável por auxiliar o monitoramento e a tomada de decisão em processosindustriais. No cenário industrial atual, a ausência de sistemas eficazes que priorizem in-formações importantes e minimizem informações redundantes durante a operação acabamresultando em ações falhas e/ou lentas por parte dos operadores. No entanto, a incorpo-ração de sistemas auxiliares de operação não é uma tarefa fácil, no sentido em que ofuncionamento de sistemas onlines durante a operação é considerada crítica, e seu maufuncionamento pode acarretar graves consequências.

Neste sentido, esta dissertação visa o desenvolvimento de um sistema de auxílio àoperação baseado em uma solução computacional chamada de sistema especialista. Oobjetivo principal é tornar a operação mais confiável e segura ao priorizar informações efiltrar notificações irrelevantes durante a operação a partir do conhecimento armazenadode especialistas no processo. Este conhecimento é armazenado através da utilização deregras de produção, e o sistema proposto com o intuito de minimizar o custo de proveresse conhecimento oferece um ambiente de programação de regras de alto nível, funda-mentado na utilização da programação visual. Essa abordagem objetiva viabilizar o seuemprego em ambientes industriais, onde os especialistas no problema podem desenvolveras suas regras sem a necessidade de conhecimento específico de programação. Destaforma, diferentes aplicações podem ser definidas para este sistema, tais como a detecçãode falhas, o diagnóstico automatizado e a supressão de alarmes.

A despeito de sua ampla gama de possíveis aplicações, esta dissertação tem como focoo contexto de filtragem seletiva em tempo real de alarmes de acordo com o estado atualdo processo. Essa abordagem caracteriza-se como uma grande inovação tecnológica naárea de automação industrial e de segurança operacional de processos.

1.2 Estrutura do Trabalho

Além deste capítulo introdutório, que buscou apresentar o escopo no qual o tema destadissertação está inserido, este trabalho apresenta mais quatro capítulos.

O Capítulo 2 apresenta o embasamento teórico necessário para o completo entendi-mento do sistema apresentado nesta dissertação. Em uma primeira seção os sistemas deapoio à decisão são apresentados, seguidos de uma explicação da ferramenta computa-cional chamada de sistema especialista. Por fim, a última seção deste capítulo contemplaum estudo teórico do cenário atual dos chamados sistemas de alarmes, objetivando-se

4 CAPÍTULO 1. INTRODUÇÃO

apresentar a área de atuação da aplicação proposta.O Capítulo 3 consiste na apresentação do sistema proposto. Este capítulo contem-

pla todos os aspectos da ferramenta, como as tecnologias utilizadas, a arquitetura, e aaplicação proposta.

O Capítulo 4 reúne os resultados obtidos através de testes e experimentos realizadosutilizando-se a ferramenta desenvolvida. São apresentados os resultados de três testesde desempenho do sistema, destacando suas principais características positivas e tambémsuas limitações. Além disso também apresenta um estudo de caso com dados de umprocesso industrial real a fim de se validar a ferramenta.

Por fim, o Capítulo 5 resume as principais conclusões sobre o trabalho desenvolvido.As contribuições desta dissertação são apresentadas, bem como sugestões para trabalhosque poderiam dar continuidade a ela.

Capítulo 2

Fundamentação Teórica

Este capítulo introduz os conceitos teóricos em que o sistema apresentado nesta dis-sertação está inserido. Esta ferramenta é classificada como um sistema de apoio à decisãoem processos industriais, e seu principal processamento é realizado pela ferramenta com-putacional chamada de sistema especialista. Tais definições serão apresentadas nas seçõesseguintes, separadas em sistemas de apoio à decisão e sistemas especialistas, respectiva-mente. No âmbito da aplicação escolhida, a supressão de alarmes, conceitos acerca desistemas de alarmes são apresentadas na sequência.

2.1 Sistemas de Apoio à Decisão

A tomada de decisões em sistemas complexos, como é o caso dos processos industri-ais, muitas vezes supera a capacidade cognitiva humana. Apesar de interações individuaisentre as variáveis de um sistema é normalmente bem entendido, a previsão de como o sis-tema vai reagir a uma manipulação externa é muitas vezes difícil.

Há uma quantidade substancial de evidências empíricas de que o julgamento intuitivohumano e sua tomada de decisão estão longe de ser ideal, e se deteriora ainda mais coma complexidade e estresse [Druzdzel & Flynn 2002]. Como em muitas situações, a qua-lidade das decisões é importante, tornando assim o auxílio às deficiências de julgamentohumano e a tomada de decisões um foco importante no âmbito da automação industrialao longo dos anos.

Disciplinas como estatística, economia e pesquisa operacional têm desenvolvido váriosmétodos para fazer escolhas racionais. Mais recentemente, estes métodos, muitas vezesalimentados por uma variedade de técnicas provenientes da ciência da informação, psi-cologia cognitiva e inteligência artificial, tem sido implementados na forma de programasde computador, seja como ferramentas autônomas ou como ambientes de computação in-tegrados para a tomada de decisões complexas [Power 1997]. Tais ambientes são muitas

6 CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA

vezes chamados de sistemas de apoio à decisão (SAD), ou também decision support sys-

tems (DSS).O conceito de sistemas de apoio à decisão é bastante amplo, e existem diferentes

definições 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 decisão [Finlay 1994]. De uma maneira mais específica, Turban a define comoum sistema de informação interativo, flexível e adaptável especialmente desenvolvidopara suporte a solução de problemas gerenciais não estruturados [Turban 1994]. ParaKeen e Morton, os SADs se baseiam no casamento dos recursos intelectuais individuaiscom os recursos de um computador a fim de melhorar a qualidade das decisões [Keen &Morton 1978].

Reunindo as diversas definições presentes na literatura, é possível chegar a um con-ceito mais geral e tecnológico a respeito dos SADs. Um SAD é, de maneira geral, umsistema computacional que possui interatividade com as ações do usuário, oferecendo da-dos e modelos para a solução de problemas focando a tomada de decisão. É necessárioenfatizar o fato de esses sistemas serem utilizados para auxiliar o operador, e não substituí-lo.

Assim como as diferentes definições, existem também diferentes nomenclaturas paradiferenciar os vários tipos de SADs. Uma das nomenclaturas definidas na literatura apre-senta o termo de sistema de apoio à decisão passivo, ativo e cooperativo [Gachet &Haettenschwiler 2003]. Um SAD passivo é um sistema que auxilia o processo de tomadade decisão, mas não apresenta sugestões e/ou soluções do problema explicitamente. UmSAD ativo trabalha de forma semelhante, porém apresenta as sugestões e soluções. Já umSAD cooperativo permite ao operador modificar, complementar e ajustar a decisão apre-sentada pelo sistema, para que estas sugestões sejam validadas. Este processo é repetidoaté que uma solução consolidada seja gerada.

2.2 Sistemas Especialistas

A área da computação chamada de inteligência artificial é bastante ampla e pode serdividida em subgrupos, como exemplificado na Figura 2.1. Entre eles, a área de sistemasespecialistas — também conhecidos como expert systems — é uma solução amplamenteutilizada em diferentes problemas [Giarratano & Riley 1994].

Os sistemas especialistas são denominados assim por modelarem conhecimento de es-pecialista(s) em uma determinada área, visando resolver problemas relativos a um domínioespecífico [Passos 1989].

2.2. SISTEMAS ESPECIALISTAS 7

Figura 2.1: Subgrupos da Inteligência Artificial (IA).

O objetivo ao se desenvolver um sistema especialista é transferir o conhecimento deum especialista para um sistema computacional e então para o usuário [Turban 1989].

Assim, sistemas especialistas podem ser definidos como ferramentas computacionaisque modelam o raciocínio e as ações de um humano ou grupo especialista em uma de-terminada área de conhecimento. Desse modo, sistemas especialistas, assim como hu-manos especialistas, agem de acordo com seu domínio em um conhecimento específico[Flores 2003].

Fazendo uma analogia aos sistemas de apoio à decisão, um sistema especialista podeser definido como um sistema computacional que emula a habilidade de tomada de de-cisão de um humano especialista.

A arquitetura típica de um sistema especialista é composta de três componentes prin-cipais: a base de conhecimento, o motor de inferência e a interface de usuário [Momoh


et al. 2000]. Esta arquitetura pode ser vista na Figura 2.2.

O usuário fornece fatos / informações ao sistema especialista e recebe sugestões /conhecimento em resposta.

Figura 2.2: Arquitetura típica de um sistema especialista.

A base de conhecimento é o conjunto de conhecimento necessário para resolver umproblema específico. Esse conhecimento é extraído a partir de fatos, heurísticas (experi-ências, opiniões, julgamentos, predições, algoritmos) e relações que normalmente foramformalizadas por especialistas em um determinado domínio. O conhecimento pode serrepresentado utilizando-se uma gama de técnicas, como as redes semânticas e a lógicapredicativa, porém a mais comumente utilizada é a conhecida como regras de produção[Metaxiotis et al. 2002, Ignizio 1991].

O motor de inferência é um elemento essencial para a existência de um sistema espe-cialista. Ele é considerado o núcleo do sistema, uma vez que é por intermédio dele queos fatos, heurísticas e relações que compõem a base de conhecimento são aplicados noprocesso de resolução do problema [Ignizio 1991].

A interface do usuário é responsável pela interação do usuário com o sistema. Nor-malmente ela é composta de interfaces de visualização e diagnóstico, e pode tambémprover interfaces de comunicação para ferramentas externas, como bancos de dados.

Sistemas especialistas apresentam diversos recursos e funcionalidades que influen-ciam a sua grande utilização. Entre eles podemos citar:

• Versatilidade: Um sistema especialista pode ser executado em quase qualquer sis-tema computacional.

• Custo reduzido: O custo de prover conhecimento por usuário é reduzido.


• Perigo reduzido: Os sistemas especialistas podem ser utilizados em ambientesnocivos a um humano.

• Permanência: O conhecimento é permanente, diferentemente dos especialistas hu-manos onde o conhecimento não é armazenado indefinidamente.

• Conhecimento múltiplo: O conhecimento de múltiplos especialistas pode ser ar-mazenado simultaneamente em um sistema especialista.

• Resposta rápida: A resposta rápida ou em tempo real pode ser necessária emalgumas aplicações.

• Resposta completa e estável: Esse recurso é importante em situações de emergên-cia, quando um humano pode não operar com sua total eficiência devido a estresseou fadiga.

Todo sistema especialista é desenvolvido seguindo certas características gerais [Giarratano& Riley 1994]. O desempenho é uma característica fundamental que permite ao sistemaa capacidade de responder a um nível de competência igual, ou melhor, a de um espe-cialista no domínio em questão. Um tempo de resposta adequado é outra característicaimportante, fator que possibilita o sistema operar em um intervalo de tempo menor queo necessário para um especialista no domínio em questão. A robustez é um quesito fun-damental em quase todo sistema computacional, evitando que o sistema trave e conse-quentemente aumentando sua confiabilidade. Por fim, outra característica de um sistemaespecialista é que ele seja compreensível, semelhantemente a um humano especialista queé capaz de explicar o seu raciocínio.

Existe uma gama de formalismos que podem ser utilizados para modelar o conheci-mento de sistemas especialistas, tais como, regras de produção, raciocínio baseado emcasos, redes neurais, redes probabilísticas, entre outros [Py 2002]. O sistema especialistautilizado para a aplicação apresentada nesta dissertação foi o sistema baseado em regrasde produção.

2.2.1 Sistemas Baseados em Regras de Produção

O sistema baseado em regras é o método mais popular para representação de conhe-cimento dentre os sistemas especialistas [Carrico et al. 1989]. Nessa abordagem, a cons-trução de regras é realizada de forma procedural, no formato se-então ou situação-ação.Além disto, regras são facilmente desenvolvidas a partir de tabelas e árvores de decisão[Hopgood 2000].

Dentre as vantagens em se utilizar um sistema de regras é possível citar a utilização


da programação declarativa, a separação entre a lógica e os dados, a velocidade e escala-bilidade e a centralização do conhecimento [Sasikumar et al. 1993].

Por outro lado, sistemas baseados em regras não são aconselhados quando o problemaem questão não é complexo, pois existe a possibilidade do sistema baseado em regras setornar mais lento do que as resoluções usuais [Browne 2009].

O conceito de regra de produção é amplo, mas no contexto de sistemas de informaçõesuma regra define restrições específicas na criação, modificação e remoção de dados emum sistema de informação (SI) [Hay & Healy 1997].

A literatura sugere que uma regra de produção deve ser representada utilizando trêscomponentes básicos: Evento, Condição e Ação (ECA). O evento determina quando aregra será processada. A condição expressa as hipóteses que devem ser processadas a fimde se validar a regra. Por fim a ação determina o que deve ser feito caso a condição sejavalidada [Dallavalle & Cazarini 2000, Zimbrão 2001].

Nos sistemas baseados em regras, a base de conhecimento é subdividida em doismódulos: a base de regras e memória de trabalho (ou base de fatos), como ilustradona Figura 2.3.

Figura 2.3: Arquitetura típica de um sistema especialista baseado em regras.

A base de regras é responsável por armazenar o conhecimento abstrato, ou seja, oconjunto de regras de produção previamente elaboradas por um especialista.

A memória de trabalho (working memory) é o elemento que armazena o conheci-mento concreto, ou seja, o conhecimento que pode ser considerado fato antes do processode inferência. Por este motivo, o conhecimento armazenado na memória de trabalhoé chamado de fato. Essa base contém todas as informações sobre o problema que sãofornecidas pelo usuário ou por outra fonte de informação. A memória de trabalho é de


caráter transitório, pois, novos fatos estão sendo acrescentados continuamente ou fatosexistentes são apagados.

O motor de inferência, já explanado anteriormente, associa o conhecimento abstratocontido na base de regras com o conhecimento concreto armazenado na base de fatos,inferindo conclusões e gerando novos fatos.

Nos sistemas baseados em regras, a inferência é o processo de desenvolvimento deuma conclusão a partir de um conjunto de regras e fatos para uma determinada situ-ação. Existem dois modos de raciocínio incorporados ao motor de inferência que sãoconsideradas principais na resolução de problemas e busca de soluções: o encadeamentoprogressivo e o encadeamento regressivo [Py 2002].

No encadeamento progressivo (forward chaining), a condição da regra é comparadacom a descrição da situação atual contida na memória de trabalho (fatos). As regrasque satisfazem a esta descrição tem suas ações executadas, o que, em geral, significa naintrodução de novos fatos na memória de trabalho.

No encadeamento regressivo (backward chaining), o comportamento do sistema écontrolado por uma lista de objetivos. Um objetivo pode ser satisfeito diretamente porum elemento da memória de trabalho, ou podem existir regras que permitam inferir al-gum dos objetivos correntes, isto é, que contenham uma descrição deste objetivo em suascondições. As regras que satisfazem esta condição têm as instâncias correspondentes àssuas ações adicionadas à lista de objetivos correntes. Caso uma dessas regras tenha todasas suas condições satisfeitas diretamente pela memória de trabalho, o objetivo em sua açãoé também adicionado à memória de trabalho. Um objetivo que não possa ser satisfeitodiretamente pela memória de trabalho, nem inferido através de uma regra, é abandonado.Quando o objetivo inicial é satisfeito, ou não há mais objetivos, o processamento termina.

O motor de inferência também requer que seja definido o algoritmo responsável porguiar a busca e casamento entre o conhecimento da memória de trabalho e da base deregras.

Charles L. Forgy, na Carnegie-Mellon University, em 1979, desenvolveu um algo-ritmo de casamento de padrões chamado de Rete [Forgy 1982]. O algoritmo Rete é umeficiente algoritmo de casamento de padrões e é a escolha mais comumente encontradaem motores de inferência comerciais. Os sistemas que utilizam este algoritmo incluem oCLIPS, Jess, Drools e o Soar [Ding et al. 2009, Friedman-Hill 2003, Browne 2009, Nayaket al. 1988].

O algoritmo Rete é implementado com o objetivo de construir uma rede de nós, comcada um desses nós representando uma ou mais premissas encontradas na condição deuma regra. Fatos que são inseridos ou removidos da base de conhecimento são proces-


sados por esta rede de nós. Os nós terminais da rede representam regras individuais.Quando um conjunto de fatos atinge todo o caminho da rede até um nó terminal, significaque todas as premissas da condição de uma regra particular foram satisfeitas. Então, aação desta determinada regra é executada [Tambe et al. 1992, Doorenbos 1995].

Existem dois tipos de nós em uma rede de Rete. Os nós alpha, também conhecidoscomo nós de uma entrada, e os nós beta, ou nós de duas entradas. O fluxo realizado peloalgoritmo Rete inicialmente constrói um nó alpha para cada teste direto de um fato nacondição de uma regra. Consequentemente, a entrada dos nós é um conjunto de fatos, e asaída é somente os fatos que tiveram a premissa considerada verdadeira. Posteriormente,os dois primeiros nós alpha são combinados em um nó de duas entradas, ou seja, um nóbeta, que, tem como saída somente os fatos que passam nos dois testes. Então, outro nóbeta é construído com as entradas sendo a saída do nó beta anterior e o próximo nó alpha.Este passo é repetido até todas as premissas da condição da regra sejam unidas, uma auma, em uma cadeia de nós beta. A saída deste nó beta final é então 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 então Ação

Figura 2.4: Rede de Rete obtida do exemplo dado.


Considerando uma segunda regra, o algoritmo Rete reutiliza os nós alpha e cria novosnós alpha somente se é um teste direto de fato não existente anteriormente. Similarmente,se a condição desta nova regra aparecer na mesma ordem da condição da primeira regra,o algoritmo Rete reutiliza também os nós beta. Isso significa que a reordenação daspremissas da condição de uma regra pode resultar em uma rede de Rete maior ou menor,e consequentemente, mais lenta ou mais rápida.

O algoritmo Rete já conta com diversas variações, como o Rete-II, Rete-III, TREAT,LEAPS, Rete-OO, entre outros. Cada um deles contam com ajustes buscando otimizaçãopara cada situação. De uma maneira geral, o nome Rete se torna genérico para se referira quase toda rede de casamento de um conjunto de regras.

Dentre a gama de sistemas baseado em regras existentes no mercado, o sistema uti-lizado no desenvolvimento da aplicação apresentada nesta dissertação foi o JBoss Drools.

JBoss Drools

O Drools é um sistema de gerenciamento de regras de negócio (SGRN) desenvolvidopela JBoss. Atualmente se encontra na versão 5.5 e é distribuído gratuitamente pelo siteda desenvolvedora.

O Drools utiliza o algoritmo Rete-OO para casar os padrões entre fatos e regras, quetrata-se de uma versão do algoritmo Rete otimizado e refinado para sistemas orientadosa objeto [Bali 2009]. Ainda, o Drools utiliza o modo de raciocínio baseado no encadea-mento progressivo (forward-chaining).

Um exemplo da sintaxe do Drools pode ser vista no código abaixo, com comentáriosem cada linha.

1 r u l e " Nova Regra " / / I n i c i o da r e g r a2 when3 / / Cond icoes4 then5 / / Acoes6 end / / Fim da r e g r a

O exemplo abaixo ilustra uma regra que tem como objetivo imprimir na tela todosos feriados que ocorrem no mês de dezembro. Esta regra confere uma condição (mes


== "dezembro") em uma instância da classe Feriado e executa o código Java caso essacondição seja satisfeita.

1 r u l e " F e r i a d o s do Mês de Dezembro "2 when3 f : F e r i a d o ( mes == " dezembro " )4 then5 System . o u t . p r i n t l n ( f . nome + " : " + f . d i a + " / " + f . mes ) ;6 end

Nas suas versões mais recentes, o Drools foi subdividido em cinco componentes: oDrools Guvnor, o Drools Flow, o Drools Planner, o Drools Expert e o Drools Fusion.O Drools Guvnor consiste em ferramentas gráficas para o gerenciamento de regras. ODrools Flow (ou jBM5) provê ferramentas para construção de fluxogramas de processosde negócio. O componente Drools Planner auxilia a resolução de problemas de planeja-mento através de meta-heurísticas. O módulo Drools Expert é o motor de regras, funda-mental para a utilização desse SGRN. E por fim o Drools Fusion adiciona a capacidadede processamento de eventos complexos ao sistema, tornando possível a utilização deelementos temporais.

Para o desenvolvimento do sistema apresentando nesta dissertação foram utilizadosos módulos Drools Expert e Drools Fusion.

2.3 Sistemas de Alarmes

Alarmes são sinais de notificação ao operador, tipicamente apresentados através deefeitos sonoros, indicação visual, mensagens ou outro tipo de identificador. Um alarmeindica a ocorrência de uma anormalidade que requer atenção do operador, e geralmenteestão associadas à medições no processo que atingem valores indesejáveis ou considera-dos inseguros [ANSI/ISA 2009].

Tradicionalmente os alarmes eram baseados em painéis com lâmpadas indicativas,limitando a quantidade de notificações disponíveis e dificultando novas implementações.Hoje em dia, a utilização de sistemas computacionais, conhecidos como sistemas dealarmes, permite uma fácil adição de novos alarmes e suas representações gráficas nor-malmente são baseadas em uma lista ordenada cronologicamente.

2.3. SISTEMAS DE ALARMES 15

Os responsáveis pela geração de alarmes são os sistemas supervisórios, programadospara gerarem sinalizações quando detectado algum comportamento anormal no funciona-mento da planta. Dessa forma, tais sinalizações, ou melhor chamados alarmes, auxiliamos operadores na efetiva identificação e resolução dos possíveis problemas [Leitão 2008].

Dessa maneira, tornou-se necessária a implantação de sistemas capazes de indicar assinalizações provenientes dos sistemas supervisórios, de modo a facilitar seus reconheci-mentos pelo operador. Tais sistemas são chamados de sistemas de alarmes.

Os sistemas de alarmes fazem parte do núcleo operacional de quase todas as modernascentrais de operação, incluindo as plataformas e refinarias de petróleo. Seu principalobjetivo é receber as notificações provenientes do processo e apresentá-las ao operadorutilizando alguma representação visual.

Porém, nem todo sistema de monitoramento de alarmes estabelece uma política bemdifundida de adição, remoção, configuração e gerenciamento de alarmes. Desta forma,a redundância e a baixa relevância de determinados alarmes atribui uma carga de infor-mação adicional aos operadores, que acaba por tornar muitas vezes a interpretação demúltiplas notificações uma tarefa humanamente impossível. Consequentemente, a tardiaou a não correta identificação de uma anormalidade colabora na ocorrência de incidentesna indústria.

Uma pesquisa realizada pela HSE (Health and Safety Executive) em 15 plantas in-dustriais identificou a ocorrência de diversos incidentes diretamente envolvidos com a máconfiguração dos sistemas de alarmes empregados. Dentre eles estão quatro incidentesresultando em danos a equipamento, três incidentes resultando em perda de produção etrês incidentes causadores de massivos danos ambientais [EEMUA191 2007].

Em termos quantitativos, as recomendações da ISA-18.2 (International Society of Au-

tomation) e da EEMUA 191 (Engineering Equipment and Materials Users’ Association)indicam que a quantidade máxima de alarmes a serem gerenciados por dia por operador éde 300 alarmes [ANSI/ISA 2009, EEMUA191 2007]. Taxas de notificações acima destelimite forçam o operador a ignorar certos alarmes. Porém estudos relatam a ocorrênciatípica de uma quantidade de alarmes muitas vezes acima deste limite aceitável, longedas habilidades de avaliação e resposta do operador [Hollifield & Habibi 2010]. Outrosvalores recomendados pela organização podem ser vistos na Tabela 2.1.

2.3.1 Estratégias de Inibição de Alarmes

A literatura relata que os atuais sistemas de alarmes não estão preparados para lidarcom situações anormais de operação, onde uma única falha pode resultar na geração de


Alarmes Anunciados por Tempo Valores Recomendados Valores MáximosAlarmes Anunciados por Dia porOperador

∼ 150 alarmes por dia ∼ 300 alarmes por dia

Alarmes Anunciados por Hora porOperador

∼ 6 (em média) ∼ 12 (em média)

Alarmes Anunciados por 10 Minu-tos por Operador

∼ 1 (em média) ∼ 2 (em média)

Tabela 2.1: Valores ideais e máximos de alarmes por operador por unidades de tempo.

até centenas de alarmes. Um estudo publicado na EEMUA 191 realizado através de en-trevistas mostrou que um operador recebe em média um único alarme a cada 2 minutossob operação normal. Durante uma operação atípica, é relatada a ocorrência de aproxi-madamente 90 alarmes no primeiro minuto após o distúrbio, e mais 70 nos 10 minutossubsequentes [EEMUA191 2007]. Isto se deve ao fato que alarmes são projetados para aoperação normal do processo [Mattiasson 1999].

Esta excessiva quantidade de alarmes em curtos intervalos de tempo leva a necessi-dade de se incorporar lógicas e estratégias de supressão de alarmes em diferentes situ-ações. Em alguns cenários, como na parada e na partida de uma planta, na ocorrência dedistúrbios, ou durante uma manutenção, determinadas notificações podem ter suas priori-dades degradadas.

Porém a identificação destes cenários pode não ser uma tarefa trivial e requer a uti-lização de técnicas modernas e eficientes incorporadas aos sistemas de gerenciamentode alarmes, visto que utilização de supressões inapropriadas pode resultar em problemasrelativos a segurança operacional.

A supressão em tempo real de alarmes na operação de processos é uma tarefa dealta complexidade. A criticidade desta operação se deve não somente ao fato de ser umsistema online, mas também por envolver a inibição de notificações que, em tese, trazeminformações relacionadas a algum equipamento ou estado do processo. Por este motivo,as estratégias escolhidas para realizarem a etapa de supressão devem ser de preferênciaelaboradas e validadas a priori por uma equipe de especialistas no processo em questão.

Capítulo 3

Sistema Desenvolvido

Neste capítulo são apresentados os componentes fundamentais para o completo en-tendimento do sistema desenvolvido, chamado de BR-PlantExpert. Deste modo, as duassubseções seguintes estão organizadas da seguinte maneira. Primeiro a Subseção 3.1 apre-senta uma breve explanação das tecnologias utilizadas no desenvolvimento da aplicação.Em seguida a Subseção 3.2 apresenta a arquitetura e a aplicação da ferramenta prosposta.

3.1 Tecnologias Utilizadas

Para o desenvolvimento da ferramenta apresentada nesta dissertação, foram utilizadasquatro principais tecnologias. Estas são: a plataforma de comunicação de dados BR-

Tools, a linguagem de programação Java, a biblioteca gráfica Visual Library e o sistemade regras JBoss Drools.

3.1.1 BR-Tools

Tendo em mente uma aplicação inteligente na área de automação industrial, a ferra-menta proposta neste trabalho teve seu desenvolvimento realizado em formato de plug-in

para o framework BR-Tools.

O BR-Tools é um sistema responsável por integrar e permitir a visualização em altonível de abstração das várias fontes de dados presentes em um processo industrial, comovariáveis de processo, alarmes e eventos [Lima 2010]. Ele provê facilidades para o de-senvolvimento de módulos (chamados plug-ins) que executam sobre este framework, e omesmo oferece um ambiente confiável, robusto e eficiente. A arquitetura geral do sistemaBR-Tools pode ser visualizada na Figura 3.1.

O framework pode conectar-se a diversas fontes de dados e ter vários plug-ins sendoexecutados, logo, age como um ponto central gerenciando pedidos de acesso aos dados e

18 CAPÍTULO 3. SISTEMA DESENVOLVIDO

Figura 3.1: Arquitetura do BRTools.

otimizando-os. Dentre as fontes de dados disponíveis para aquisição de dados é possíveldestacar os servidores OPC-DA [OPC DA 3.00 Specification, Data Acess Automation

Interface Standard 2003], relativos a informações de variáveis de processo em temporeal, e os servidores OPC-A&E [OPC A&E 1.10 Specification, Alarm and Events Custom

Interface 2002], relativos a informações de alarmes e eventos em tempo real. Esses sãoprotocolos de comunicação amplamente utilizados em instalações industriais da área depetróleo e gás.

Na Figura 3.2 é possível ver o software em execução sem plug-ins carregados, primeira-mente, e com plug-ins carregados e executando.

Figura 3.2: Tela do BRTools sem plug-ins e com plug-ins executando.

3.1. TECNOLOGIAS UTILIZADAS 19

Assim, diante do exposto acima, a concepção e implementação do sistema de apoioà decisão apresentado nesta dissertação é encapsulado em formato de plug-in do sistemaBR-Tools.

3.1.2 Linguagem Java

A linguagem Java, criada pela Sun Microsystems em 1991, tem como principais ca-racterísticas o fato de ser segura, independente de plataforma e de ser uma linguagem deprogramação orientada a objetos.

Programas Java consistem em partes chamadas classes, que por sua vez incluem parteschamadas métodos que realizam tarefas e retornam informações quando as tarefas sãoconcluídas. Com sua ampla utilização, existem ricas coleções de classes já desenvolvidas,chamadas bibliotecas de classes. O próprio Java já oferece diversas bibliotecas, chamadastambém de Java APIs (Application Programming Language) [Deitel & Deitel 2009].

A compilação da linguagem resulta em uma forma intermediária de código bináriochamado bytecodes. Esse código é então submetido a um processo de tradução para umcódigo binário que possa ser reconhecido por cada processador específico. O tradutor debytecodes é chamado de Máquina Virtual Java (JVM), sendo o responsável pela flexibi-lidade dessa linguagem em ser executada por diferentes sistemas operacionais [Mecenas2008].

A opção da linguagem Java para o desenvolvimento da aplicação desta dissertaçãose deve em grande parte a portabilidade da linguagem. Essa característica é fundamentalpara aplicações de escopo industrial, devido à diversidade de plataformas presentes nosambientes industriais. Além disso essa linguagem é compatível com as bibliotecas uti-lizadas no desenvolvimento, a biblioteca visual Visual Library e o sistema de regras JBoss

Drools, e que serão explicadas nos tópicos seguintes.

3.1.3 Visual Library

A biblioteca Visual Library foi criada pela Netbeans a fim permitir uma maior vari-edade de formatos de visualização e modelagem gráfica de objetos, como por exemplo,grafos. Grande parte de sua utilização se deve ao fato de prover uma arquitetura queobjetiva e facilita a programação visual [Gameleira et al. 2008].

Incorporada ao NetBeans Plataform desde o JDK (Java Development Kit) 5.0, essaAPI vem sendo bastante utilizada por sua versatilidade e diversidade.

A escolha dessa biblioteca se deve a sua grande utilização em sistemas semelhantes,que se baseiam em programação visual de alto nível.


3.1.4 JBoss Drools

O sistema Drools, desenvolvido pela JBoss, já foi anteriormente explanado na Seção2.2.1.

Dentre as razões do sistema da JBoss ter sido utilizado no desenvolvimento da fer-ramenta apresentada nesta dissertação estão a compatibilidade com a linguagem de pro-gramação Java e o fato de ser distribuída gratuitamente e de ter seu código-fonte aberto(open-source).

3.2 Arquitetura e Aplicação Proposta

Com o intuito de permitir a adoção de diferentes aplicações utilizando-se o mesmomódulo de processamento o sistema foi desenvolvido uma arquitetura de característicamodular. Desta maneira, com módulos independentes e desacoplados, o desenvolvimentode novas aplicações se torna uma tarefa simples e rápida, permitindo que os módulosresponsáveis pelo sistema especialista e pela construção de regras sejam minimamentemodificados.

Seguindo este modelo, a arquitetura do BR-PlantExpert se encontra subdividida emtrês módulos: o sistema especialista baseado em regras, o ambiente de construção deregras, e um terceiro módulo diretamente ligado a visualização dos resultados obtidos noprocesso de inferência.

O primeiro módulo é o responsável por gerenciar o sistema baseado em regras, combi-nando o conhecimento armazenado através de regras de produção com os fatos adquiridosdurante sua execução.

O ambiente de construção de regras é um segundo módulo que tem como objetivoprover ao usuário ferramentas de modelagem gráfica de regras que serão posteriormentecarregadas na base de conhecimento do sistema especialista.

A fim de validar a usabilidade e funcionalidade do sistema o problema da supressãoonline de alarmes foi escolhida como a aplicação da ferramenta para realização destetrabalho de dissertação. Com o objetivo de filtrar alarmes que sejam considerados des-necessários ou irrelevantes em uma determinada situação é possível auxiliar o operadora tomar decisões de maneira mais ágil. Deste modo, o terceiro módulo desenvolvido foia tela de monitoramento de alarmes, responsável por disponibilizar as noticicações dealarmes juntamente com informações relevantes de um processo industrial.

Nas Seções 3.2.1, 3.2.2 e 3.2.3 esses três módulos serão explanados mais detalhada-mente.

3.2. ARQUITETURA E APLICAÇÃO PROPOSTA 21

A arquitetura proposta está ilustrada na Figura 3.3. As indicações numéricas demons-tram 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 possível o recebimento síncrono e assíncrono de dados devariáveis de processo e de alarmes e eventos. Esse fluxo é caracterizado pela indicação 1.

A indicação 2 demonstra o fluxo de dados que representa o carregamento da basede regras do sistema especialista pelas regras modeladas no ambiente de construção deregras.

Por fim, a indicação 3 representa o fluxo de alarmes repassados para a interface devisualização de alarmes devidamente filtrados pelas regras do sistema especialista.

3.2.1 Sistema Especialista Baseado em Regras

Este módulo é responsável pelo processamento de grande parte das funcionalidadesdo sistema. Como exemplo de funcionalidades, pode-se citar a associação entre regrase fatos. Como citado anteriormente, o sistema utilizado nesta ferramenta é o Drools,resultando em uma compatibilidade com os demais recursos deste módulo.

Por ser um módulo exclusivo de processamento, ele não apresenta interface gráfica eé transparente ao usuário, sendo executado em background.

Este módulo funciona independente dos demais, porém é necessário que o mesmo seja


alimentado com regras em linguagem Drools, de difícil compreensão para usuários inex-perientes. Por este motivo foi desenvolvido o ambiente de construção de regras, escopodo segundo módulo do sistema.

3.2.2 Ambiente de Construção de Regras

O ambiente de construção de regras é o módulo responsável por prover ao usuárioacesso à modelagem de regras, que posteriormente serão carregadas e executadas na basede conhecimento do sistema especialista.

Esta modelagem é feita a partir de programação visual através de blocos funcionaisexistentes e configurados pelo usuário. Fazendo uso desses blocos e de operadores lógicostambém disponíveis, é possível a construção de uma lógica mais complexa que representaa condição de uma regra.

Nas subseções seguintes, quatro aspectos importantes do ambiente de construção deregras são abordados com a finalidade de tornar mais claro seus objetivos e funcionali-dades. Um quinto aspecto é introduzido com o objetivo de demonstrar uma das aplicaçõespossibilitadas pela ferramenta.

Estrutura e Organização das Regras

A organização das regras no contexto da aplicação é formada seguindo a estruturailustrada na Figura 3.4.

Figura 3.4: Organização das regras no contexto da aplicação.

A modelagem é realizada a partir da definição de sistemas, estruturas que representamum conjunto ou parte de uma planta industrial. Estes sistemas são formados por estados,responsáveis por refletir o funcionamento atual do sistema em questão. Cada estado éentão definido por uma regra, que será posteriormente incluída na base de conhecimentodo sistema especialista.

A formulação de regras é realizada utilizando-se informações provenientes de fontesde dados, tais como de variáveis de processo, alarmes e eventos, e também de valores de


estados de outros sistemas.Estas regras são construídas então para definir a ativação ou não de um estado, deter-

minando assim o estado atual do sistema em questão. Então, a partir de blocos funcionais,o usuário constrói em forma de programação visual as condições necessárias para que oestado seja ativado e que determinadas ações sejam tomadas.

Tais ações dependem do escopo da aplicação em que o BR-PlantExpert está inserido,e para o caso desta dissertação esta aplicação foi a de supressão de alarmes.

Programação Visual Utilizando Blocos Funcionais

A disponibilidade de modelagem de regras utilizando-se programação visual é umafuncionalidade de extrema importância, visto que sistemas especialistas normalmenteutilizam-se de linguagem de programação com diferentes sintaxes dificultando seu en-tendimento e compreensão por um usuário sem experiência. Desta forma, a progra-mação visual auxilia oferecendo uma linguagem de alto nível, rápida, fácil e intuitivapara usuários de diferentes níveis de conhecimento.

A ferramenta apresentada nesta dissertação tem a proposta de oferecer blocos fun-cionais configuráveis, assim como operadores lógicos, para a lógica da regra em questãoser então elaborada.

Os blocos funcionais disponíveis na ferramenta são organizados em três classes, alarme/ evento, variável de processo e estado. A Figura 3.5 ilustra a visualização dos blocosdessas três classes.

Figura 3.5: Blocos funcionais disponíveis na aplicação.

I. Alarme/Evento

São blocos ativados caso um determinado alarme ou evento ocorra. Por exemplo, aocorrência do alarme XA-4321. Este bloco, caracterizado pela cor amarela, tem comopainel de configuração a tela apresentada na Figura 3.6.

A partir desta tela é possível optar por alarme ou evento e configurar a sua respectivatag. A opção delay funciona como um operador temporal, possibilitando somente a vali-dade da condição após este tempo pré-configurado pelo usuário. Por fim, a opção Tempo


Figura 3.6: Painel de configuração do bloco de alarmes e eventos.

de Expiração, habilitada somente para eventos, invalida a condição após este tempo pré-configurado pelo usuário.

II. Variável de Processo

São blocos ativados caso uma variável de processo satisfaça uma condição. Essacondição depende do tipo de variável a ser tratada. Por exemplo, uma variável contínua deprocesso, como temperatura, ultrapassar um determinado valor, ou uma variável discretade processo, como o estado de uma válvula estar ativado.

O painel de configuração deste bloco permite a escolha da tag a partir de três métodosdiferentes:

• Método manual: Este método permite inserir a tag manualmente, sem quaisquerbusca no servidor de dados. Desta maneira o tipo da variável também deve serdefinido pelo usuário (Figura 3.7a).

• Método hierárquico: Este método permite listar todas as tags do servidor de formahierárquica, caso o mesmo suporte esta funcionalidade. Desta maneira, as tagssão visualizadas de uma forma mais simples e organizada, facilitando a escolha damesma. A tag escolhida tem o seu tipo automaticamente definido através de umaconsulta ao servidor (Figura 3.7b).

• Método por busca com máscara: Este método permite ao usuário inserir umamáscara responsável por filtrar as tags disponíveis no servidor, facilitando a escolha


(a) (b) (c)

Figura 3.7: Painel de configuração do bloco de variável de processo.

da tag. A tag escolhida tem o seu tipo automaticamente definido através de umaconsulta ao servidor (Figura 3.7c).

Definida a tag da variável de processo, a condição do bloco é configurada a partirde uma expressão que define uma comparação matemática. Tal expressão terá uma saídaverdadeira (true) ou falsa (false). Os operadores disponíveis para formulação da expressãovariam de acordo com o tipo de variável associada. A lista abaixo indica os operadoresdisponíveis para cada tipo de variável de processo:

• Inteiro: >, >=, <, <=, ==• Double: >, >=, <, <=, ==• Booleano: true, false

• String: equals, startWith, endsWith

Esta expressão de comparação matemática permite ainda a opção por comparar umavariável a um valor constante (comparação estática) ou ainda a outra variável de processo,permitindo assim a configuração demonstrada na Figura 3.7c, que compara os valores deduas variáveis disponíveis no servidor (pid1.OUT > pid1.SP).

III. Estado

São blocos ativados quando um determinado estado de um sistema se encontra ativo.


Figura 3.8: Painel de configuração do bloco de estado.

Desta maneira é possível associar o estado de um sistema a partir dos estados de outrossistemas. O painel de configuração deste bloco pode ser visualizado na Figura 3.8.

Para auxiliar a construção das condições das regras são oferecidos também operadoreslógicos, permitindo-se assim a criação de lógicas mais complexas. Os operadores ofere-cidos pela ferramenta são: E lógico (a), OU lógico (b), negação lógica (c) e operadorvotação (n de m) (d). Estes operadores podem ser visualizados na Figura 3.9.

(a) (b) (c) (d)

Figura 3.9: Operadores disponíveis na construção de regras.

Modelagem Hierárquica

Uma das grandes inovações do sistema proposto consiste em permitir que as regras se-jam modeladas utilizando-se uma arquitetura hierárquica, o que torna possível uma estru-turação mais simples e organizada das informações sobre a planta industrial em questão.Essa hierarquia é visualizada a partir de uma estrutura do tipo árvore, permitindo assimque seja criado um sistema filho de um outro sistema, introduzindo assim o conceito desistema e subsistema.

Associando esta forma de modelagem com o objetivo da aplicação, no caso, a su-pressão de alarmes, essa estruturação parte do princípio de que toda vez que por algummotivo um sistema não esteja em funcionamento normal os alarmes associados a estesistema devem estar suprimidos.

No entanto, muitas vezes um sistema é composto por vários subsistemas que podemestar em funcionamento mesmo quando o sistema encontra-se parado. Nesse caso, osalarmes associados aos subsistemas em funcionamento não podem, de maneira alguma,estarem suprimidos.

Seguindo esta prática de modelagem, acredita-se que se o processo como um todo


for bem modelado, todo sistema/subsistema pertencente a ele terá apenas dois estados:Operando e Parado. Sempre que um terceiro estado precisa ser definido para caracterizaro subsistema, isto será indicativo de que este deverá ser subdividido em outros subsis-temas.

A Figura 3.10 demonstra um exemplo de modelagem hierárquica de uma planta didática:

Figura 3.10: Exemplo de modelagem hierárquica de uma planta industrial.

No entanto, a ferramenta permite também a modelagem de regras de um modo tradi-cional, ou, linear. Desta maneira, é possível simplesmente traduzir regras já estrategica-mente elaboradas e traduzi-las de forma visual no ambiente de construção de regras.

Essa possibilidade torna o sistema mais flexível, permitindo ao usuário diferentesmetodologias de modelagem de regras, tanto a mais tradicional quanto uma mais sofisti-cada.

Interface Gráfica

A interface gráfica (GUI) do ambiente de construção de regras foi desenvolvida como objetivo de simplificar a maneira como regras são modeladas, oferecendo facilidades etornando a sua utilização o mais intuitiva possível. Esta interface pode ser visualizada naFigura 3.11.

O painel responsável pela visualização dos sistemas pode ser visto na indicação 1.É possível visualizar a hierarquia dos sitemas e selecionar o sistema em que se desejaobservar/editar os estados.

A indicação 2 representa a barra de ferramentas da aplicação. Entre as ferramen-tas temos: criar novo sistema/subsistema; remover o sistema/subsistema selecionado;


Figura 3.11: Interface gráfica do ambiente de construção 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 descrição. Nele é possível visualizar oueditar a descrição de um determinado estado de um sistema.

Na indicação 4 temos o painel de edição de regras. Neste painel as regras são mo-deladas de modo visual utilizando os blocos de condição e de operadores anteriormentedescritos. A lógica da regra deve ser construída e sua saída conectada ao bloco final doestado, caracterizado pela borda cinza.

Por fim, a indicação 5 representa o painel de ações, onde se é possível determinar quaisalarmes serão suprimidos e/ou habilitados caso o referente estado seja ativado. Tambémé possível configurar uma mensagem de alerta caso seja de interesse do operador. Estepainel se adapta com a aplicação em que o sistema está inserido.

Tradução Visual-Funcional

Uma vez que as regras tenham sido modeladas, é necessário realizar um processode tradução tornando as mesmas conciliáveis com o sistema especialista. A linguagemutilizada no ambiente de construção de regras, essencialmente visual, necessita que aquelamesma informação inserida pelo usuário através da modelagem via blocos funcionais seja


repassada ao sistema especialista através de uma linguagem e sintaxe compatíveis. Faz-se necessário a utilização de uma interface de tradução entre o sistema especialista e oambiente de construção de regras, como ilustrado na Figura 3.12.

Figura 3.12: Interface de tradução acoplando o ambiente de construção de regras ao sis-tema especialista.

A fim de serem processadas pelo sistema especialista baseado em regras, é necessárioque as regras modeladas pelo usuário no ambiente de construção de regras sejam traduzi-das para uma linguagem compatível com o sistema. Essa tradução é realizada de formatransparente ao usuário, e não requer nenhum conhecimento acerca da sintaxe utilizadapelo sistema especialista.

O sistema especialista utilizado, o Drools, faz uso da linguagem nativa DRL (Drools

Rule Language) [Bali 2009]. O ambiente de construção de regras é então responsávelpor processar os blocos funcionais modelados e configurações realizadas pelo usuário etraduzi-la em uma regra na linguagem DRL.

A Figura 3.13 ilustra um exemplo de uma regra modelada utilizando programaçãovisual e a Figura 3.14 demonstra sua respectiva regra traduzida em linguagem DRL, po-dendo assim ser processada pelo Drools.

Figura 3.13: Exemplo de uma regra modelada utilizando programação visual.


rule "Bomba 1A - Parado" salience 0 when (AlarmEvent(tag == "XA-55556") from entry-point AlarmEvent or (ProcessDataFact(tag == "VX-1A", value == false) from entry-point Variable and ProcessData ProcessDataFact(tag == "VX-1B", value == false) from entry-point Variable) ) then OnlineStateDataBase.getInstance().setStateTrue("Sub-Sistema 10", "Parado"); 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 ativações de alarmes de um processo e validar as regras desupressão e habilitação elaboradas, uma tela auxiliar de operação foi desenvolvida visandoa integração de múltiplas informações consideradas relevantes em uma interface simplese objetiva. Deste modo, a identificação de possíveis causas-raiz de anormalidades a partirde alarmes se torna uma tarefa mais eficiente, resultando em ações imediatas mais eficazespor parte do operador.

Dentre os recursos adotados no desenvolvimento do módulo de monitoramento dealarmes, estão:

• Melhor aproveitamento da interface utilizando resoluções widescreen;• Utilização de diferentes cores para representar a prioridade dos alarmes;• Acesso ao histórico das principais variáveis de processo associadas ao alarme, per-

mitindo assim verificar seu comportamento nos últimos minutos;• Disponibilização de informações de racionalização do alarme provenientes de ou-

tras fontes de dados.

A interface (Figura 3.15), desenvolvida visando disponibilizar uma tela agradável afim de evitar o cansaço visual por parte do operador, dispõe de uma lista de alarmes ativos(Indicação 1) - já devidamente filtrados pelas regras do sistema especialista - com suasprioridades indicadas por diferentes cores pré-configuradas pelo operador. A partir destatela também é possível realizar o processo de reconhecimento do alarme.

Uma série de informações de racionalização do alarme (previamente selecionados nalista de alarmes ativos) é mostrada ao usuário através de um painel lateral (Indicação2). Tais informações são dados de documentação do alarme provenientes de sistemas degerenciamento de alarmes, tais como o BR-AlarmExpert, sistema já amplamente empre-gado em diversos setores industriais [Leitão 2008].


Figura 3.15: Interface gráfica da interface de visualização de alarmes.

A indicação 3 representa dados de leitura, em tempo real, de variáveis de processorelacionadas diretamente ao alarme pré-selecionado. Dessa forma, se torna mais intu-itiva a identificação da causa raiz da anormalidade sinalizada pelo alarme por parte dooperador.

Por fim, na indicação 4 é mostrada um gráfico com a leitura das últimas horas davariável de processo relacionada diretamente a ocorrência de alarme. Esse gráfico tema intenção de mostrar a curva de tendência da variável de processo que gerou o desviosinalizado pelo alarme.

Diante do apresentado, a tela de monitoramento proposta tem como intuito disponi-bilizar online ao operador as ocorrências de alarmes (identificados como relevantes pelosistema de supressão), além de todas as informações necessárias para uma melhor e maisrápida identificação da anormalidade. Essa interface não tem o intuito de substituir asatuais telas de monitoramento de alarmes dos sistemas de supervisão, mas sim servircomo mais uma fonte de informação integrada e disponível ao operador como um sistemaauxiliar.

Capítulo 4

Resultados

Este capítulo reúne testes e experimentos realizados a fim de se quantificar e qualificaro desempenho e a usabilidade do sistema desenvolvido. A Seção 4.1 apresenta três testesde desempenho (benchmarks), responsáveis por determinar e analisar os fatores limitantesda ferramenta, visto que se trata de um sistema online. A Seção 4.2 busca apresentara usabilidade da ferramenta através de um estudo de caso com dados de um processoindustrial real.

4.1 Desempenho do Sistema

Tendo em mente que o presente sistema é executado em tempo real, o mesmo tem aresponsabilidade de responder de forma rápida, dentro de um limite considerado aceitável.Ainda, espera-se que um sistema relacionado a supressão de alarmes — um problemaconsiderado crítico — responda em tempo hábil mesmo nos piores cenários.

A utilização de testes de desempenho e de tempo de execução é importante para aanálise do comportamento de um sistema em operação. A partir do estudo dos resultadosobtidos é então possível concluir se o sistema atende as especificações necessárias para acategoria em que ele está inserido.

Diferentes experimentos foram estudados e analisados a objetivando-se quantificar odesempenho do sistema desenvolvido. Após uma análise do tempo de execução do sis-tema, foram selecionados três principais fatores que poderiam refletir significativamenteno desempenho do sistema. São eles:

• Incremento de fatos• Incremento de regras• Incremento de disparos

34 CAPÍTULO 4. RESULTADOS

Os três fatores selecionados foram testados a partir de experimentos e cenários con-trolados, observando os tempos de resposta para posterior análise.

Os testes de desempenho foram realizados medindo-se o tempo de execução de umaiteração do sistema especialista em um computador com processados quad-core AMD

Phenom II 2.8GHz e 4GB de memória RAM. A fim de se obter resultados mais precisose confiáveis, cada teste foi repetido dez vezes e sua respectiva média aritmética foi calcu-lada.

Para um melhor entendimento dos experimentos realizados, três conceitos devem serrevisados:

• Regra: Regra na linguagem DRL, previamente modelada no ambiente de cons-trução de regras, formada por condição e ação. Se VX-001 está ABERTA então

Suprimir PI-22 é um exemplo de regra.• Fato: É o conhecimento armazenado na memória de trabalho do sistema especi-

alista. É uma informação 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 execução

da ação da mesma. Utilizando-se os exemplos anteriores, o disparo seria o casa-mento entre o fato e a regra e a sua respectiva ação (Suprimir PI-22).

As informações de cada um dos testes podem ser vistas na Tabela 4.1. Cada teste édetalhadamente explicado nas subseções seguintes.

# de fatos # de regras # de disparos

Teste I 10-100000 5000 500Teste II 5000 500-5000 500Teste III 5000 5000 10-5000

Tabela 4.1: Informações 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 memóriade trabalho do sistema especialista. A quantidade de regras e o número de disparos foramfixados.

As informações do primeiro teste podem ser vistas na Tabela 4.1. Os resultados obti-dos estão contidos na Tabela 4.2 e seu respectivo gráfico pode ser visto na Figura 4.1

4.1. DESEMPENHO DO SISTEMA 35

Quant. de fatos 10 100 1000 10000 100000

Tempo Mínimo 30 30 34 37 38Tempo Máximo 31 32 37 38 40Tempo Médio 30.3 31 35 37.1 39.5Desvio Padrão 0.48 0.67 1.15 0.32 0.70

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

Figura 4.1: Gráfico dos resultados obtidos no Teste I.

Como pode ser concluído analisando os resultados obtidos nesse experimento, o in-cremento de fatos não impactou significativamente o tempo de execução do sistema.

4.1.2 Teste II: Incremento de Regras

O segundo teste realizado teve como base o incremento gradual da quantidade deregras na base de regras do sistema especialista. A quantidade de fatos e o número dedisparos foram mantidas constantes. As informações deste teste podem ser vistas naTabela 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 Mínimo 30 33 33 34 34 34 34 34 35 35Tempo Máximo 35 35 35 35 36 36 36 36 37 37Tempo Médio 32.4 33.8 33.9 34.3 34.4 35.2 35.2 35.3 35.8 36.3Desvio Padrão 1.84 0.63 0.57 0.48 0.70 0.63 0.79 0.82 0.63 0.67

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


Figura 4.2: Gráfico dos resultados obtidos no Teste II.

Assim como no primeiro teste de desempenho, o incremento de regras não interferesignificativamente no tempo de execução 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 deexecução. O teste consistiu no incremento no número de regras disparadas durante umaiteração de execução das regras.

As informações deste teste de desempenho estão contidas na Tabela 4.1. Os resultadossão visualizados na Tabela 4.4 e na Figura 4.3.

Quant. de disparos 10 50 100 250 500 1000 2000 3000 4000 5000

Tempo Mínimo 1 3 7 18 30 65 167 277 463 594Tempo Máximo 1 4 9 20 37 70 171 289 475 607Tempo Médio 1 3.5 7.8 18.9 34.6 67.2 169.4 282.8 471.5 600.3Desvio Padrão 0 0.53 0.63 0.74 2.22 1.68 1.35 3.73 3.66 3.97

Tabela 4.4: Resultados do Teste III (em milisegundos).

Analisando este teste conclui-se que o fator limitante de desempenho do sistema é aquantidade de regras satisfeitas em uma mesma iteração. Porém, mesmo em um cenárioimprovável de 5000 regras sendo satisfeitas na mesma iteração, o sistema respondeu emum tempo médio de 600ms, o que é considerado satisfatório para o propósito de moni-toramento online de processos industriais.

4.2. ESTUDO DE CASO 37

Figura 4.3: Gráfico dos resultados obtidos no Teste III.

4.2 Estudo de Caso

A utilização de estudos de caso incorpora credibilidade a um sistema desenvolvido,principalmente por testar diferentes aspectos relativos a usabilidade. A partir de um es-tudo de caso é possível verificar a experiência do usuário desde a modelagem das regrasno ambiente proposto até a validação das mesmas através da observação das saídas indi-cadas na tela de monitoramento de alarmes.

4.2.1 Problema

O problema referente ao estudo de caso analisado neste trabalho é baseado em umaplanta industrial real comumente encontrada em refinarias de petróleo. Trata-se de umforno de uma Unidade de Coqueamento Retardado, unidade responsável pelo processosevero de craqueamento térmico bastante utilizado na conversão de uma fração bastantedepreciada em outras de maior valor comercial.

Este problema foi selecionado por se encaixar no contexto em que o sistema estáaplicado, pois os cenários escolhidos — a ocorrência de uma parada do forno (trip) e seuretorno a operação (start-up) — acarreta na ativação de uma quantidade significativa dealarmes, porém nem todos trazendo informações relevantes para aquela situação.

Uma grande parte dos alarmes ativados durante este processo de trip não trazem in-formações adequadas ao estado atual da planta, pois, após o acionamento do sistemaintertravamento do forno, grande parte dos subsistemas do mesmo não estarão em fun-cionamento. Ainda, durante o processo de recolocar o forno em operação, os subsistemasdo forno vão retornando aos poucos, tornando assim os alarmes relacionados a cada sub-


sistema novamente relevantes ao operador.A fim de ilustrar a avalanche de notificações em que o operador se torna sujeito durante

a ocorrência de um trip do forno industrial em questão, uma representação gráfica de umhistórico de um dia desta planta pode ser visualizada na Figura 4.4, onde o eixo dasabscissas representa o tempo e o eixo das ordenadas indicam a razão alarmes/hora. Énotável o grande aumento desta razão após a detecção da parada do forno.

Figura 4.4: Histórico de real de Alarmes/Hora na ocorrência de um trip no forno.

Análises realizadas por profissionais experientes no processo em estudo revelaram quena ocorrência de uma parada total do forno, 78 diferentes alarmes configurados se tornampassíveis de supressão, pois, as suas ativações se devem exatamente ao evento de paradado forno, já previamente detectada pelo operador.

Desta forma, é importante que durante a parada e a partida do forno, os alarmesque não tragam informações importantes sejam suprimidos (ou tenham suas prioridadesdegradas) de forma a não mascarar a ocorrência de alarmes relevantes ou até mesmo críti-cos ao processo. Uma menor carga de informações entregues ao operador resulta em umadetecção mais rápida e consequentemente em uma tomada de decisão mais eficaz.

Porém, a fim de se tornar um sistema seguro e eficiente é necessário também incorpo-rar lógicas de habilitação de alarmes durante a partida da planta, resultando na habilitaçãode todos os alarmes previamente suprimidos após o retorno operacional da planta.

4.2.2 Solução Proposta

A solução proposta buscou adotar uma estratégia de supressão de alarmes e de suas ha-bilitações automáticas de acordo com as condições operacionais do forno. Tais estratégiase lógicas envolvidas foram elaboradas por uma equipe multidisciplinar envolvida direta-mente ao processo de estudo, com conhecimento de seu comportamento em condiçõesnormais e anormais de operação.


A regra de supressão utilizada é baseada na observação de um evento de trip, acar-retando na ação de supressão de um total de 78 alarmes. Isto significa que, na paradado forno, a ocorrência de um alarme contido nestes 78 não será visualizada na tela demonitoramento de alarmes. A ativação de alarmes não contidos nesta lista é visualizadanormalmente.

Durante o retorno do forno a operação, os subsistemas componentes desta planta vãoretornando gradativamente, uns antes de outros. Deste modo, é necessária a utilizaçãode regras para habilitação de diferentes grupos de alarmes. Por exemplo, os alarmesindicativos de pressão baixa do sistema de alimentação de gás combustível para os pilotosdevem ser habilitados após a obtenção da permissão de purga e quando as válvulas dospilotos forem reabertas.

A Figura 4.5 exemplifica bem o processo de supressão e respectiva habilitação grada-tiva dos alarmes envolvidos nas estratégias elaboradas durante diferentes etapas.

Figura 4.5: Representação temporal dos alarmes e eventos do cenário estudado.

Como citado na Subseção 3.2.2, o sistema permite a modelagem de regras tanto damaneira tradicional (linear), quanto utilizando o modelo hierárquico. Para este estudo decaso, como se trata de estratégias de supressão de alarmes previamente elaboradas poruma equipe sem o intuito de torná-las hierárquicas, o exercício foi realizado modelandoas regras de forma linear, utilizando a funcionalidade de se utilizar subsistemas com oúnico objetivo de melhor organização das regras.

Diante de tais estratégias, um total de treze regras foram modeladas:

• 1 regra para supressão de alarmes (na ocorrência de um trip no forno)• 12 regras para habilitação de alarmes (no start-up do forno)


A Figura 4.6 demonstra a organização utilizada para elaboração das regras de su-pressão e habilitção de alarmes para o estudo de caso em questão.

Figura 4.6: Estrutura das regras modeladas para o estudo de caso.

4.2.3 Análise de Resultados

A partir de dados reais obtidos provenientes de históricos de operação do forno, foipossível realizar uma simulação do processo de parada e de partida da planta, conformeocorreria em uma situação real. Manipulando-se os valores das variáveis do processo, oscenários foram explorados a fim de se obter uma análise comparativa da quantidade denotificações indicativas na tela de operador.

Foi determinado o espaço de tempo de 1h a partir do momento da detecção do eventode trip do forno para obtenção de dados estatísticos, e os resultados podem ser vistos naTabela 4.5.

# de Alarmes # de Alarmes Suprimidos Redução (%)

259 154 59,4%

Tabela 4.5: Resultado da supressão em um intervalo de 1h.

Outra estatística foi extraída ao se analisar um único instante após a parada da planta,e os resultados estão contidos na Tabela 4.6.

Como mostrado na Tabela 4.5, os resultados obtidos se mostraram satisfatórios, aoponto de que uma redução de 59,4% na quantidade de alarmes a serem monitorados em


# de Alarmes # de Alarmes Suprimidos Redução (%)

15 10 66,7%

Tabela 4.6: Resultado da supressão em um dado instante.

um intervalo de tempo de uma hora acarreta em diversos benefícios no processo de opera-ção de uma planta industrial. Ao se evitar os eventos chamados de avalanche de alarmes,o tempo de detecção de alarmes críticos por parte do operador se torna menor, resultandoem rápida ações corretivas. A Figura 4.7 demonstra o estado da tela de monitoramentode alarmes com e sem o sistema de supressão em execução durante um certo momento daoperação após a parada do forno (redução de 66,7% na quantidade de alarmes).

Figura 4.7: Exemplo da tela de visualização de alarmes sem (à esquerda) e com (à direita)o sistema de regras em execução.

Capítulo 5

Considerações Finais e PerspectivasFuturas

A aplicação apresentada nesta dissertação tem como objetivo suprir uma demandaque vem sendo requisitada por grandes corporações do ramo de processos industriais: oauxílio à tomada de decisões, pois ações imediatas e precisas são necessárias para evitardecréscimo de produção e até mesmo evitar incidentes com consequências graves.

Neste escopo, a solução proposta mostrou atender bem esse objetivo ao fornecer aooperador uma tela de monitoramento de alarmes com menos informações redundantesou consideradas desnecessárias através de um processamento por um sistema especialistabaseado em regras modeladas para aquela situação. Desta maneira o operador foca suaatenção em alarmes que são de extrema importância naquele determinado momento, re-sultando possivelmente em uma decisão mais rápida e com maior acurácia. É importantefrisar que se faz necessária a validação das regras (simulações, tabelas-verdade, etc.) antesde torná-las operacionais, visto que a supressão de alarmes é um processo de alto nível decriticidade.

Esta aplicação incorpora uma importante inovação na área de processos industriais,que carece de tais ferramentas que visam evitar a sobrecarga de alarmes em um únicooperador em curtos intervalos de tempo. Tais contribuições, se utilizadas corretamente,impactam diretamente a operação, tornando-a mais segura e confiável.

A funcionalidade desta ferramenta a leva a ter uma ampla gama de aplicações quedevem ser incorporadas em trabalhos futuros. Devido a sua concepção modular (Figura3.3), a solução proposta é altamente flexível, permitindo ser utilizada como base paradiversas soluções baseadas em regras, como por exemplo, análise, diagnóstico e detecçãode falhas.

Outras perspectivas estão voltadas a adoção de lógica fuzzy nas regras modeladas,incorporando assim a possibilidade de não se obter uma única resposta do sistema de

44 CAPÍTULO 5. CONSIDERAÇÕES FINAIS E PERSPECTIVAS FUTURAS

inferência, e sim um conjunto de soluções devidamente ordenadas pela sua probabilidadede ser a mais correta. E por fim, a incorporação de um formalismo de checagem dasregras, a fim de se verificar a consistência das mesmas, evitando assim, por exemplo,regras conflitantes.

Este sistema vem sendo desenvolvido, aprimorado e testado no LII/DCA/UFRN emparceria com o CENPES/PETROBRAS dentro do projeto de pesquisa denominado SIST(Sistema Inteligente para Suporte a Decisão para Análise e Operação de Plantas Industri-ais).

A solução apresentada neste trabalho já conta com uma instalação-piloto no Centro dePesquisas Petrobras (CENPES), objetivando-se a realização de testes de validação e usa-bilidade assim como para coleta e análise de resultados a fim de aprimorar a ferramenta.Futuras instalações estão agendadas para incorporar mais credibilidade a ferramenta, as-sim como gerar retornos necessários para atualizações e correção de problemas.

Referências Bibliográficas

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 Developer’s Guide, Packt Publishing.

Browne, Paul (2009), JBoss Drools Business Rules, Packt Publishing.

Carrico, M. A., J. E. Girard & J. P. Jones (1989), Building Knowledge Systems: Develop-

ing and Managing Rule-Based Applications, McGraw-Hill, New York.

Dallavalle, Silvia Inês & Edson Walmir Cazarini (2000), ‘Regras do negócio, um fatorchave de sucesso no processo de desenvolvimento de sistemas de informação’, En-

contro Nacional de Engenharia de Produção (ENEGEP) .

Deitel, H. M. & P. J. Deitel (2009), Java How to Program, 8ª edição, Prentice Hall, NewJersey.

Devries, Stan (2010), ‘Why is alarm management required in modern plants?’, Invensys .

Ding, Yuxin, Qing Wang & Jiahua Huang (2009), ‘The performance optimization ofCLIPS’, Ninth International Conference on Hybrid Intelligent Systems (1).

Doorenbos, Robert B. (1995), Production matching for large learning systems, Tese dedoutorado, Pittsburgh, PA, USA. UMI Order No. GAX95-22942.

Druzdzel, M. J. & R. R. Flynn (2002), Decision Support Systems, 2ª edição, MarcelDekker, Inc, New York.

EEMUA191 (2007), ‘Alarm systems - a guide to design, management and procurement.publication no 191’, Equipment, Engineering & Materials Users Association .

Finlay, P. N. (1994), Introducing Decision Support Systems, Blackwell Publishers, Ox-ford, UK.

45

46 REFERÊNCIAS BIBLIOGRÁFICAS

Flores, C. D. (2003), Fundamentos dos sistemas especialistas, em ‘Sociedades Artificiais:a nova fronteira da inteligência nas máquinas’, p. 332.

Forgy, C. (1982), ‘What is a DSS?’, Rete: A Fast Algorithm for the Many Patterns/Many

Objects Match Problem 19(1), 17–37.

Friedman-Hill, Ernest (2003), Jess in action: rule-based systems in Java, 2ª edição, Man-ning Publications.

Gachet, A. & P. Haettenschwiler (2003), Developing intelligent decision support systems:A bipartite approach, em ‘Knowledge-Based Intelligent Information and Engineer-ing Systems, 7th KES Conference’, pp. 87–93.

Gameleira, Tiago A., Raimundo Santos Moura & Luiz Affonso H. Guedes (2008), ‘Visuallibrary: Uma biblioteca para criação de ferramentas de modelagem gráfica’.

Giarratano, J. & G. Riley (1994), Expert Systems Principles and Programming, PWSPublishing Company, Boston.

Habibi, Eddie & Bill Hollifield (2006), ‘Alarm systems greatly affect offshore facilitiesamid high oil prices’, World Oil Magazine 227 pp. 101–105.

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

ond Edition, Isa.

Hopgood, A. (2000), Intelligent Systems for Engineers and Scientists, 2ª edição, CRCPress, New York.

Ignizio, J. P. (1991), Introduction to Expert Systems - The Development and Implementa-

tion of Rule-based Expert Systems, McGraw-Hill, New York.

Keen, P. G. W. & M. S. Scott Morton (1978), Decision support systems : an organiza-

tional perspective, Addison-Wesley.

Leitão, Gustavo Bezerra Paz (2008), Algoritmos para análise de alarmes em processospetroquímicos, Dissertação de mestrado, Universidade Federal do Rio Grande doNorte.

REFERÊNCIAS BIBLIOGRÁFICAS 47

Lima, Marcelo (2010), ‘Sistema integrado para auxílio à análise de incidentes’, Prêmio

Petrobras de Tecnologia - 5ª Edição .

Mattiasson, C. (1999), The alarm system from the operator’s perspective, em ‘HumanInterfaces in Control Rooms, Cockpits and Command Centres, 1999. InternationalConference on’, pp. 217 –221.

Mecenas, Ivan (2008), Java 6: Fundamentos, Swing, BlueJ e JDBC, Alta Books.

Metaxiotis, K., D. Askounis & J. Psarras (2002), ‘Expert systems in production plan-ning and scheduling: a state-of-the-art survey’, Journal of Intelligent Manufacturing

13, 253–260.

Momoh, J., D. Srinivasan, K. Tomsovic & D. Baer (2000), Chapter 5: Expert systemsapplications, em ‘Tutorial on Fuzzy Logic Applications in Power Systems’.

Nayak, P. Pandurang, Anoop Gupta & Paul S. Rosenbloom (1988), Comparison of therete and treat production matchers for soar, em ‘AAAI’88’, pp. 693–698.

OPC A&E 1.10 Specification, Alarm and Events Custom Interface (2002), Relatório téc-nico, OPC Foundation.

OPC DA 3.00 Specification, Data Acess Automation Interface Standard (2003), Relatóriotécnico, OPC Foundation.

Passos, E. L. (1989), Inteligência 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 introdução’.

Sasikumar, M., S. Ramani, S. Muthu Raman, K. S. R. Anjaneyulu & R. Chandrasekar(1993), Rule Based Expert Systems: A Practical Introduction, Narosa PublishingHouse.

Tambe, M., D. Kalp & P.S. Rosenbloom (1992), An efficient algorithm for productionsystems with linear-time match, em ‘Tools with Artificial Intelligence, 1992. TAI’92, Proceedings., Fourth International Conference on’, pp. 36–43.

Turban, E. (1989), Decision Support Systems and Expert Systems, MacMillan, New York.

48 REFERÊNCIAS BIBLIOGRÁFICAS

Turban, E. (1994), Decision support and expert systems : management support systems,Prentice Hall, Englewood Cliffs, NJ.

Zimbrão, Geraldo (2001), ‘Atenas: Um sistema gerenciador de regras de negócio’, XV

Simpósio Brasileiro de Engenharia de Software (SBES) pp. 338–343.

Sistema Especialista para Supressão Alarmes em …...sistemas de apoio à decisão. Neste sentido,...

Documents

Transcript of Sistema Especialista para Supressão Alarmes em …...sistemas de apoio à decisão. Neste sentido,...