Sistema Especialista para Supressão Online de Alarmes em Processos Industriais

(1)

UNIVERSIDADEFEDERALDO RIO GRANDE DO NORTE

UNIVERSIDADEFEDERAL DORIOGRANDE DO NORTE CENTRO DETECNOLOGIA

PROGRAMA DEPÓS-GRADUAÇÃO EMENGENHARIAELÉTRICA

Sistema Especialista para Supressão

Online

de

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

Programa de Pós-Graduação em Engenharia Elétrica e de Computação da UFRN (área de concentração: Engenharia de Computação) como parte dos requisitos para obtenção do título de Mestre em Ciências.

(2)

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 Neto Co-orientador: Jorge Dantas de Melo

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

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

(3)

Sistema Especialista para Supressão

Online

de

Alarmes em Processos Industriais

Danilo Curvelo de Souza

Dissertação de Mestrado aprovada em 01 de fevereiro de 2013 pela banca examinadora composta 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

(4)

Agradecimentos

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

Ao professores Dr. Luiz Affonso Henderson Guedes e Dr. Diego Rodrigo Cabral Silva pelas 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.

(5)

Resumo

A operação de processos industriais vem se tornando mais complexa ao longo dos anos, e um dos elementos que possibilitam este aumento de complexidade é a integração de novas tecnologias e soluções inteligentes empregadas no setor, como é o caso dos sistemas 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. O objetivo principal é tornar a operação mais confiável e segura ao maximizar a quantidade de informações relevantes a cada situação através da utilização 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-nível, que permite a criação e manipulaçã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 como foco o contexto de filtragem em tempo real de alarmes durante a operação, devidamente validada em um estudo de caso baseado em um cenário real ocorrido em uma planta industrial de uma refinaria de petróleo e gás.

Palavras-chave: sistema especialista, sistema baseado em regras, motor de inferência,

(6)

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

(7)

Sumário

Sumário i

Lista de Figuras iii

Lista de Tabelas v

Lista de Símbolos e Abreviaturas vii

1 Introdução 1

1.1 Objetivo da Dissertação . . . 3

1.2 Estrutura do Trabalho . . . 3

2 Fundamentação Teórica 5 2.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 17 3.1 Tecnologias Utilizadas . . . 17

3.1.1 BR-Tools . . . 17

3.1.2 LinguagemJava . . . 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

(8)

4 Resultados 33

4.1 Desempenho do Sistema . . . 33

4.1.1 Teste I: Incremento de Fatos . . . 34

4.1.2 Teste II: Incremento de Regras . . . 35

4.1.3 Teste III: Incremento de Disparos . . . 36

4.2 Estudo de Caso . . . 37

4.2.1 Problema . . . 37

4.2.2 Solução Proposta . . . 38

4.2.3 Análise de Resultados . . . 40

5 Considerações Finais e Perspectivas Futuras 43

(9)

Lista de Figuras

1.1 Crescimento da quantidade de alarmes controlados por operador ao longo

dos 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 deReteobtida do exemplo dado. . . 12

3.1 Arquitetura doBRTools. . . 18

3.2 Tela doBRToolssemplug-inse complug-insexecutando. . . 18

3.3 Arquitetura proposta doBR-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 ao sistema 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 linguagemDRL. . . 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 umtripno forno. . . 38

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

(10)

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

(11)

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

4.2 Resultados do Teste I (em milisegundos). . . 35

4.3 Resultados do Teste II (em milisegundos). . . 35

4.4 Resultados do Teste III (em milisegundos). . . 36

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

4.6 Resultado da supressão em um dado instante. . . 41

(12)

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

(13)

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 auxiliares de 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 restritivos para 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 camada pré-sal.

Assim, empresas do ramo industrial cada vez mais investem em novas tecnologias objetivando a melhoria do desempenho, da produtividade, da eficiência, da qualidade e da segurança operacional de seus processos. Dentre estas novas tecnologias estão os sistemas computacionais 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 de uma 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é mesmo inteligentes 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 de alarmes 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, normalmente baseada 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 de novos alarmes uma tarefa de baixo custo, acaba por promover a geração simultânea de múltiplos alarmes na ocorrência de determinados eventos.

(14)

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 alarmes controlados por operador ao longo dos anos, fato que pode vir a promover a ocorrência de 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 dos anos.

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 problema são as estratégias de inibição de alarmes, onde, a partir da detecção de certos cenários, determinados alarmes são suprimidos.

(15)

1.1. OBJETIVO DA DISSERTAÇÃO 3

1.1 Objetivo da Dissertação

O objetivo principal do desenvolvimento deste tema de dissertação é apresentar uma ferramenta responsável por auxiliar o monitoramento e a tomada de decisão em processos industriais. No cenário industrial atual, a ausência de sistemas eficazes que priorizem in-formações importantes e minimizem inin-formações redundantes durante a operação acabam resultando em ações falhas e/ou lentas por parte dos operadores. No entanto, a incorpo-ração de sistemas auxiliares de opeincorpo-ração não é uma tarefa fácil, no sentido em que o funcionamento de sistemasonlines durante a operação é considerada crítica, e seu mau funcionamento 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. O objetivo principal é tornar a operação mais confiável e segura ao priorizar informações e filtrar notificações irrelevantes durante a operação a partir do conhecimento armazenado de especialistas no processo. Este conhecimento é armazenado através da utilização de regras de produção, e o sistema proposto com o intuito de minimizar o custo de prover esse 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 seu emprego em ambientes industriais, onde os especialistas no problema podem desenvolver as suas regras sem a necessidade de conhecimento específico de programação. Desta forma, diferentes aplicações podem ser definidas para este sistema, tais como a detecção de 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 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 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 desta dissertação está inserido, este trabalho apresenta mais quatro capítulos.

(16)

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 a aplicação proposta.

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

(17)

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ão em processos industriais, e seu principal processamento é realizado pela ferramenta com-putacional chamada de sistema especialista. Tais definições serão apresentadas nas seções seguintes, 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 de sistemas 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 individuais entre 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 intuitivo humano e sua tomada de decisão estão longe de ser ideal, e se deteriora ainda mais com a 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 julgamento humano e a tomada de decisões um foco importante no âmbito da automação industrial ao longo dos anos.

(18)

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

vezes chamados de sistemas de apoio à decisão (SAD), ou tambémdecision 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 como um sistema de informação interativo, flexível e adaptável especialmente desenvolvido para suporte a solução de problemas gerenciais não 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 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, um sistema 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ário enfatizar 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 para diferenciar 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 tomada de decisão, mas não apresenta sugestões e/ou soluções do problema explicitamente. Um SAD ativo trabalha de forma semelhante, porém apresenta as sugestões e soluções. Já um SAD cooperativo permite ao operador modificar, complementar e ajustar a decisão apre-sentada pelo sistema, para que estas sugestões sejam validadas. Este processo é repetido até 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 ser dividida em subgrupos, como exemplificado na Figura 2.1. Entre eles, a área de sistemas especialistas — também conhecidos comoexpert systems— é uma solução amplamente utilizada em diferentes problemas [Giarratano & Riley 1994].

(19)

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 de um especialista para um sistema computacional e então para o usuário [Turban 1989].

Assim, sistemas especialistas podem ser definidos como ferramentas computacionais que 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 pode ser definido como um sistema computacional que emula a habilidade de tomada de de-cisão de um humano especialista.

(20)

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 um problema 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 foram formalizadas por especialistas em um determinado domínio. O conhecimento pode ser representado utilizando-se uma gama de técnicas, como as redes semânticas e a lógica predicativa, 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 que os fatos, heurísticas e relações que compõem a base de conhecimento são aplicados no processo 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ém prover 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.

(21)

• Perigo reduzido: Os sistemas especialistas podem ser utilizados em ambientes

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

algumas 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 estresse ou fadiga.

Todo sistema especialista é desenvolvido seguindo certas características gerais [Giarratano & Riley 1994]. O desempenho é uma característica fundamental que permite ao sistema a 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ística importante, fator que possibilita o sistema operar em um intervalo de tempo menor que o 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 sistema especialista é 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 em casos, redes neurais, redes probabilísticas, entre outros [Py 2002]. O sistema especialista utilizado para a aplicação apresentada nesta dissertação foi o sistema baseado em regras de 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 formatose-entãoousituação-ação. Além disto, regras são facilmente desenvolvidas a partir de tabelas e árvores de decisão [Hopgood 2000].

(22)

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 problema em questão não é complexo, pois existe a possibilidade do sistema baseado em regras se tornar 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ções uma regra define restrições específicas na criação, modificação e remoção de dados em um sistema de informação (SI) [Hay & Healy 1997].

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

Nos sistemas baseados em regras, a base de conhecimento é subdividida em dois módulos: a base de regras e memória de trabalho (ou base de fatos), como ilustrado na 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, o conjunto de regras de produção previamente elaboradas por um especialista.

(23)

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

O motor de inferência, já explanado anteriormente, associa o conhecimento abstrato contido 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 de uma 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ão consideradas principais na resolução de problemas e busca de soluções: o encadeamento progressivo e o encadeamento regressivo [Py 2002].

No encadeamento progressivo (forward chaining), a condição da regra é comparada com a descrição da situação atual contida na memória de trabalho (fatos). As regras que satisfazem a esta descrição tem suas ações executadas, o que, em geral, significa na introduçã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 por um 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 suas condições. As regras que satisfazem esta condição têm as instâncias correspondentes às suas ações adicionadas à lista de objetivos correntes. Caso uma dessas regras tenha todas as 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 satisfeito diretamente 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 por guiar a busca e casamento entre o conhecimento da memória de trabalho e da base de regras.

Charles L. Forgy, na Carnegie-Mellon University, em 1979, desenvolveu um algo-ritmo de casamento de padrões chamado deRete [Forgy 1982]. O algoritmoReteé um eficiente algoritmo de casamento de padrões e é a escolha mais comumente encontrada em motores de inferência comerciais. Os sistemas que utilizam este algoritmo incluem o CLIPS,Jess,Droolse oSoar[Ding et al. 2009, Friedman-Hill 2003, Browne 2009, Nayak et al. 1988].

(24)

proces-12 CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA

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, significa que todas as premissas da condição de uma regra particular foram satisfeitas. Então, a ação desta determinada regra é executada [Tambe et al. 1992, Doorenbos 1995].

Existem dois tipos de nós em uma rede deRete. Os nós alpha, também conhecidos como nós de uma entrada, e os nósbeta, ou nós de duas entradas. O fluxo realizado pelo algoritmo Rete inicialmente constrói um nó alpha para cada teste direto de um fato na condição de uma regra. Consequentemente, a entrada dos nós é um conjunto de fatos, e a saída é somente os fatos que tiveram a premissa considerada verdadeira. Posteriormente, os dois primeiros nósalphasã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óbetaanterior e o próximo nóalpha. Este passo é repetido até todas as premissas da condição da regra sejam unidas, uma a uma, em uma cadeia de nósbeta. A saída deste nóbetafinal é então o conjunto de fatos (que pode ser vazio), que casam com a regra.

Como exemplo, para a regra abaixo a redeReteobtida seria a ilustrada na Figura 2.4.

SeC1, C2, C3, C4entãoAção

(25)

Considerando uma segunda regra, o algoritmoRetereutiliza os nósalphae cria novos nósalphasomente 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 das premissas da condição de uma regra pode resultar em uma rede deRetemaior ou menor, e consequentemente, mais lenta ou mais rápida.

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

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

JBoss Drools

ODroolsé um sistema de gerenciamento de regras de negócio (SGRN) desenvolvido pelaJBoss. Atualmente se encontra na versão 5.5 e é distribuído gratuitamente pelo site da desenvolvedora.

ODroolsutiliza o algoritmo Rete-OO para casar os padrões entre fatos e regras, que trata-se de uma versão do algoritmo Reteotimizado e refinado para sistemas orientados a objeto [Bali 2009]. Ainda, oDroolsutiliza o modo de raciocínio baseado no encadea-mento progressivo (forward-chaining).

Um exemplo da sintaxe doDroolspode ser vista no código abaixo, com comentários em cada linha.

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

2 when

3 / / C o n d i c o e s 4 t h e n

5 / / Acoes

6 end / / Fim da r e g r a

(26)

== "dezembro") em uma instância da classe Feriado e executa o códigoJava caso essa condição seja satisfeita.

1 r u l e " F e r i a d o s do Mês de Dezembro "

2 when

3 f : F e r i a d o ( mes == " dezembro " )

4 t h e n

5 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, oDrools foi subdividido em cinco componentes: o Drools Guvnor, o Drools Flow, o Drools Planner, oDrools Expert e o Drools Fusion. O Drools Guvnor consiste em ferramentas gráficas para o gerenciamento de regras. O Drools Flow(oujBM5) provê ferramentas para construção de fluxogramas de processos de negócio. O componenteDrools Plannerauxilia a resolução de problemas de planeja-mento através de meta-heurísticas. O móduloDrools Experté o motor de regras, funda-mental para a utilização desse SGRN. E por fim o Drools Fusionadiciona a capacidade de processamento de eventos complexos ao sistema, tornando possível a utilização de elementos temporais.

Para o desenvolvimento do sistema apresentando nesta dissertação foram utilizados os módulosDrools ExperteDrools Fusion.

2.3 Sistemas de Alarmes

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

(27)

2.3. SISTEMAS DE ALARMES 15

Os responsáveis pela geração de alarmes são os sistemas supervisórios, programados para gerarem sinalizações quando detectado algum comportamento anormal no funciona-mento da planta. Dessa forma, tais sinalizações, ou melhor chamados alarmes, auxiliam os 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 as sinalizaçõ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 modernas centrais de operação, incluindo as plataformas e refinarias de petróleo. Seu principal objetivo é receber as notificações provenientes do processo e apresentá-las ao operador utilizando alguma representação visual.

Porém, nem todo sistema de monitoramento de alarmes estabelece uma política bem difundida 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 de múltiplas notificações uma tarefa humanamente impossível. Consequentemente, a tardia ou a não correta identificação de uma anormalidade colabora na ocorrência de incidentes na 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 incidentes resultando em danos a equipamento, três incidentes resultando em perda de produção e trê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 deste limite forçam o operador a ignorar certos alarmes. Porém estudos relatam a ocorrência típica de uma quantidade de alarmes muitas vezes acima deste limite aceitável, longe das habilidades de avaliação e resposta do operador [Hollifield & Habibi 2010]. Outros valores recomendados pela organização podem ser vistos na Tabela 2.1.

2.3.1 Estratégias de Inibição de Alarmes

(28)

Alarmes Anunciados por Tempo Valores Recomendados Valores Máximos

Alarmes Anunciados por Dia por

Operador ∼

150 alarmes por dia ∼300 alarmes por dia

Alarmes Anunciados por Hora por

Operador ∼

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 minutos sob 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 minutos subsequentes [EEMUA191 2007]. Isto se deve ao fato que alarmes são projetados para a operaçã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 de distú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 gerenciamento de alarmes, visto que utilização de supressões inapropriadas pode resultar em problemas relativos a segurança operacional.

(29)

Capítulo 3

Sistema Desenvolvido

Neste capítulo são apresentados os componentes fundamentais para o completo en-tendimento do sistema desenvolvido, chamado deBR-PlantExpert. Deste modo, as duas subseçõ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 utilizadas quatro principais tecnologias. Estas são: a plataforma de comunicação de dados BR-Tools, a linguagem de programaçãoJava, a biblioteca gráfica Visual Librarye o sistema de regrasJBoss 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 deplug-in para oframework BR-Tools.

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

(30)

18 CAPÍTULO 3. SISTEMA DESENVOLVIDO

Figura 3.1: Arquitetura doBRTools.

otimizando-os. Dentre as fontes de dados disponíveis para aquisição de dados é possível destacar 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 tempo real, e os servidores OPC-A&E [OPC A&E 1.10 Specification, Alarm and Events Custom Interface2002], relativos a informações de alarmes e eventos em tempo real. Esses são protocolos de comunicação amplamente utilizados em instalações industriais da área de petróleo e gás.

Na Figura 3.2 é possível ver osoftwareem execução semplug-inscarregados, primeira-mente, e complug-inscarregados e executando.

(31)

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 deplug-indo sistema BR-Tools.

3.1.2 Linguagem

Java

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

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

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

A opção da linguagem Java para o desenvolvimento da aplicação desta dissertação se deve em grande parte a portabilidade da linguagem. Essa característica é fundamental para aplicações de escopo industrial, devido à diversidade de plataformas presentes nos ambientes industriais. Além disso essa linguagem é compatível com as bibliotecas uti-lizadas no desenvolvimento, a biblioteca visualVisual Librarye o sistema de regrasJBoss Drools, e que serão explicadas nos tópicos seguintes.

3.1.3 Visual Library

A biblioteca Visual Libraryfoi 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 que objetiva e facilita a programação 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.

(32)

3.1.4 JBoss Drools

O sistemaDrools, desenvolvido pelaJBoss, já foi anteriormente explanado na Seção 2.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çãoJava 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 mesmo módulo de processamento o sistema foi desenvolvido uma arquitetura de característica modular. Desta maneira, com módulos independentes e desacoplados, o desenvolvimento de novas aplicações se torna uma tarefa simples e rápida, permitindo que os módulos responsáveis pelo sistema especialista e pela construção de regras sejam minimamente modificados.

Seguindo este modelo, a arquitetura doBR-PlantExpert se encontra subdividida em três módulos: o sistema especialista baseado em regras, o ambiente de construção de regras, e um terceiro módulo diretamente ligado a visualização dos resultados obtidos no processo 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 adquiridos durante sua execução.

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

A fim de validar a usabilidade e funcionalidade do sistema o problema da supressão online de alarmes foi escolhida como a aplicação da ferramenta para realização deste trabalho 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 operador a tomar decisões de maneira mais ágil. Deste modo, o terceiro módulo desenvolvido foi a tela de monitoramento de alarmes, responsável por disponibilizar as noticicações de alarmes juntamente com informações relevantes de um processo industrial.

(33)

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 doBR-PlantExpert.

O fluxo de dados da arquitetura é dado a partir de assinaturas realizadas peloplug-in e oBR-Tools, tornando assim possível o recebimento síncrono e assíncrono de dados de variá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 base de regras do sistema especialista pelas regras modeladas no ambiente de construção de regras.

Por fim, a indicação 3 representa o fluxo de alarmes repassados para a interface de visualizaçã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 funcionalidades do sistema. Como exemplo de funcionalidades, pode-se citar a associação entre regras e 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 embackground.

(34)

alimentado com regras em linguagemDrools, de difícil compreensão para usuários inex-perientes. Por este motivo foi desenvolvido o ambiente de construção de regras, escopo do 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ário acesso à modelagem de regras, que posteriormente serão carregadas e executadas na base de conhecimento do sistema especialista.

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

Nas subseções seguintes, quatro aspectos importantes do ambiente de construção de regras 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ções possibilitadas pela ferramenta.

Estrutura e Organização das Regras

A organização das regras no contexto da aplicação é formada seguindo a estrutura ilustrada 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 representam um 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 conhecimento do sistema especialista.

(35)

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 o estado seja ativado e que determinadas ações sejam tomadas.

Tais ações dependem do escopo da aplicação em que oBR-PlantExpertestá 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 é uma funcionalidade de extrema importância, visto que sistemas especialistas normalmente utilizam-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 intuitiva para 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ão ser 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 blocos dessas 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, a ocorrência do alarme XA-4321. Este bloco, caracterizado pela cor amarela, tem como painel de configuração a tela apresentada na Figura 3.6.

(36)

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. Essa condição depende do tipo de variável a ser tratada. Por exemplo, uma variável contínua de processo, como temperatura, ultrapassar um determinado valor, ou uma variável discreta de processo, como o estado de uma válvula estar ativado.

O painel de configuração deste bloco permite a escolha dataga partir de três métodos diferentes:

• Método manual: Este método permite inserir atagmanualmente, sem quaisquer busca no servidor de dados. Desta maneira o tipo da variável também deve ser definido pelo usuário (Figura 3.7a).

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

• Método por busca com máscara: Este método permite ao usuário inserir uma

(37)

(a) (b) (c)

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

datag. A tagescolhida tem o seu tipo automaticamente definido através de uma consulta ao servidor (Figura 3.7c).

Definida a tag da variável de processo, a condição do bloco é configurada a partir de uma expressão que define uma comparação matemática. Tal expressão terá uma saída verdadeira (true) ou falsa (false). Os operadores disponíveis para formulação da expressão variam de acordo com o tipo de variável associada. A lista abaixo indica os operadores disponí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 uma variá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 de duas variáveis disponíveis no servidor (pid1.OUT > pid1.SP).

III. Estado

(38)

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 outros sistemas. 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 operadores ló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 operador votação (ndem) (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 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 aplicação, no caso, a su-pressão de alarmes, essa estruturação parte do princípio de que toda vez que por algum motivo um sistema não esteja em funcionamento normal os alarmes associados a este sistema devem estar suprimidos.

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

(39)

for bem modelado, todo sistema/subsistema pertencente a ele terá apenas dois estados: OperandoeParado. Sempre que um terceiro estado precisa ser definido para caracterizar o 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 diferentes metodologias 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 com o objetivo de simplificar a maneira como regras são modeladas, oferecendo facilidades e tornando a sua utilização o mais intuitiva possível. Esta interface pode ser visualizada na Figura 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 deseja observar/editar os estados.

(40)

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 ou editar 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 anteriormente descritos. A lógica da regra deve ser construída e sua saída conectada ao bloco final do estado, caracterizado pela borda cinza.

Por fim, a indicação 5 representa o painel de ações, onde se é possível determinar quais alarmes 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. Este painel se adapta com a aplicação em que o sistema está inserido.

Tradução Visual-Funcional

(41)

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 o ambiente 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ário que 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 forma transparente ao usuário, e não 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 construção de regras é então responsável por processar os blocos funcionais modelados e configurações realizadas pelo usuário e traduzi-la em uma regra na linguagem DRL.

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

(42)

Figura 3.14: A mesma regra da Figura 3.13 traduzida para linguagemDRL.

3.2.3 Tela de Monitoramento de Alarmes

A fim de monitorar as ativações de alarmes de um processo e validar as regras de supressão e habilitação elaboradas, uma tela auxiliar de operação foi desenvolvida visando a integração de múltiplas informações consideradas relevantes em uma interface simples e objetiva. Deste modo, a identificação de possíveis causas-raiz de anormalidades a partir de alarmes se torna uma tarefa mais eficiente, resultando em ações imediatas mais eficazes por parte do operador.

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

• Melhor aproveitamento da interface utilizando resoluçõeswidescreen; • 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 a fim 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 suas prioridades indicadas por diferentes cores pré-configuradas pelo operador. A partir desta tela também é possível realizar o processo de reconhecimento do alarme.

(43)

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 processo relacionadas 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 do operador.

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

(44)

(45)

Capítulo 4

Resultados

Este capítulo reúne testes e experimentos realizados a fim de se quantificar e qualificar o desempenho e a usabilidade do sistema desenvolvido. A Seção 4.1 apresenta três testes de desempenho (benchmarks), responsáveis por determinar e analisar os fatores limitantes da ferramenta, visto que se trata de um sistema online. A Seção 4.2 busca apresentar a usabilidade da ferramenta através 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 rápida, dentro de um limite considerado aceitável. Ainda, espera-se que um sistema relacionado a supressão de alarmes — um problema considerado 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 a análise do comportamento de um sistema em operação. A partir do estudo dos resultados obtidos é então possível concluir se o sistema atende as especificações necessárias para a categoria em que ele está inserido.

Diferentes experimentos foram estudados e analisados a objetivando-se quantificar o desempenho 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 significativamente no desempenho do sistema. São eles:

(46)

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 uma iteração do sistema especialista em um computador com processados quad-core AMD Phenom II 2.8GHz e 4GB de memóriaRAM. A fim de se obter resultados mais precisos e 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 ser revisados:

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

Teste II 5000 500-5000 500 Teste 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ória de trabalho do sistema especialista. A quantidade de regras e o número de disparos foram fixados.

(47)

4.1. DESEMPENHO DO SISTEMA 35

Quant. de fatos 10 100 1000 10000 100000 Tempo Mínimo 30 30 34 37 38 Tempo Máximo 31 32 37 38 40 Tempo Médio 30.3 31 35 37.1 39.5 Desvio 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 de regras na base de regras do sistema especialista. A quantidade de fatos e o número de disparos foram mantidas constantes. As informações 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 Mínimo 30 33 33 34 34 34 34 34 35 35 Tempo Máximo 35 35 35 35 36 36 36 36 37 37 Tempo Médio 32.4 33.8 33.9 34.3 34.4 35.2 35.2 35.3 35.8 36.3 Desvio Padrão 1.84 0.63 0.57 0.48 0.70 0.63 0.79 0.82 0.63 0.67

(48)

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

Assim como no primeiro teste de desempenho, o incremento de regras não interfere significativamente 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 de execução. O teste consistiu no incremento no número de regras disparadas durante uma iteração de execução das regras.

As informações deste teste de desempenho estão contidas na Tabela 4.1. Os resultados sã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 594 Tempo Máximo 1 4 9 20 37 70 171 289 475 607 Tempo Médio 1 3.5 7.8 18.9 34.6 67.2 169.4 282.8 471.5 600.3 Desvio 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).

(49)

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 regras no 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 uma planta industrial real comumente encontrada em refinarias de petróleo. Trata-se de um forno de uma Unidade de Coqueamento Retardado, unidade responsável pelo processo severo de craqueamento térmico bastante utilizado na conversão de uma fração 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 cenários escolhidos — a ocorrência de uma parada do forno (trip) e seu retorno a operação (start-up) — acarreta na ativação de uma quantidade significativa de alarmes, porém nem todos trazendo informações relevantes para aquela situação.

(50)

sub-38 CAPÍTULO 4. RESULTADOS

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 umtripdo forno industrial em questão, uma representação gráfica de um histórico 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 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 umtripno forno.

Análises realizadas por profissionais experientes no processo em estudo revelaram que na ocorrência de uma parada total do forno, 78 diferentes alarmes configurados se tornam passíveis de supressão, pois, as suas ativações 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 não tragam informações importantes sejam suprimidos (ou tenham suas prioridades degradas) 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 uma detecçã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ção de todos os alarmes previamente suprimidos após o retorno operacional da planta.

4.2.2 Solução Proposta

(51)

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 parada do forno, a ocorrência de um alarme contido nestes 78 não será visualizada na tela de monitoramento de alarmes. A ativação de alarmes não contidos nesta lista é visualizada normalmente.

Durante o retorno do forno a operação, os subsistemas componentes desta planta vão retornando gradativamente, uns antes de outros. Deste modo, é necessária a utilização de regras para habilitação de diferentes grupos de alarmes. Por exemplo, os alarmes indicativos de pressão baixa do sistema de alimentação de gás combustível para os pilotos devem ser habilitados após a obtenção da permissão de purga e quando as válvulas dos pilotos 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 da maneira tradicional (linear), quanto utilizando o modelo hierárquico. Para este estudo de caso, como se trata de estratégias de supressão de alarmes previamente elaboradas por uma equipe sem o intuito de torná-las hierárquicas, o exercício foi realizado modelando as 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:

(52)

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, foi possível realizar uma simulação do processo de parada e de partida da planta, conforme ocorreria em uma situação real. Manipulando-se os valores das variáveis do processo, os cenários foram explorados a fim de se obter uma análise comparativa da quantidade de notificações indicativas na tela de operador.

Foi determinado o espaço de tempo de 1h a partir do momento da detecção do evento detripdo forno para obtenção de dados estatísticos, e os resultados podem ser vistos na Tabela 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.

(53)

# 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, resultando em rápida ações corretivas. A Figura 4.7 demonstra o estado da tela de monitoramento de alarmes com e sem o sistema de supressão em execução durante um certo momento da operação após a parada do forno (redução de 66,7% na quantidade de alarmes).

(54)