BR-PLANTEXPERT: UM SISTEMA ESPECIALISTA PARA AUXÍLIO À TOMADA DE DECISÃO EM PROCESSOS INDUSTRIAIS
DANILO C. DE SOUZA, ADRIÃO D. D. NETO, LUIZ A. GUEDES, JORGE D. DE MELO, GUSTAVO B. P. LEITÃO, KAKU SAITO
Laboratório de Informática Industrial, Departamento de Engenharia da Computação e Automação, Universidade Federal do Rio Grande do Norte (UFRN)
Campus Universitário Lagoa Nova, Natal, RN
E-mails: [curvelo, adriao, affonso, jdmelo, gustavo]@dca.ufrn.br, kaku@petrobras.com.br
Abstract This article presents a tool that integrates techniques and features to improve the efficiency and effectiveness of the diagnosis and its consequent decision action in industrial processes. This tool is based on a rule-based expert system that can process online data of process variables, alarms and events for operation support. This application, called BR-PlantExpert, is de- signed to function as a support operation screen, providing the operator with additional information that may be considered im- portant in critical situations. Despite its wide range of possible applications, this article focuses only in the context of real-time filtering of alarms during the operation.
Keywords expert system, rule-based system, inference engine, rules, alarm management, alarm filtering.
Resumo O presente artigo apresenta uma ferramenta que integra técnicas e funcionalidades a fim de melhorar a eficiência e eficácia dos procedimentos de diagnóstico e sua consequente tomada de decisão em processos industriais. Tal ferramenta é ba- seada em regras que podem processar dados on-line de variáveis de processo, alarmes e eventos para fins de suporte ao operador. Essa aplicação, chamada de BR-PlantExpert, foi desenvolvida para funcionar como suporte à operação, provendo diversas in- formações complementares que podem ser valiosas em momentos considerados críticos. A despeito de sua ampla gama de pos- síveis aplicações, neste artigo foca-se a ferramenta apenas no contexto de filtragem em tempo real de alarmes durante a opera- ção.
Palavras-chave sistema especialista, sistema baseado em regras, motor de inferência, regras, gerenciamento de alarmes, su- pressão de alarmes.
1 Introdução
Aplicações que visam a melhoria dos sistemas de gerenciamento de alarmes são de extrema importân- cia em processos industriais. Sistemas de alarmes ineficazes e/ou ineficientes impactam diretamente a produção e a segurança de uma planta industrial. Por este motivo existe um grande ganho ao tornar dispo- nível ao operador ferramentas inteligentes capazes de auxiliá-lo na tomada de decisão rápida e eficaz (Ha- bibi, 2006). É neste escopo de ferramentas que a aplicação apresentada neste artigo, chamada de BR- PlantExpert, se enquadra.
O BR-PlantExpert é uma ferramenta desenvolvida com o intuito de auxiliar o operador de processos industriais no monitoramento de alarmes, focando principalmente em momentos críticos, tais como nas situações onde ocorrem avalanches de alarmes. Este auxílio é baseado na execução de regras específicas modeladas a partir do conhecimento de uma equipe multidisciplinar, onde, a partir da detecção de deter- minados cenários, determinadas ações são realizadas. Para a modelagem das regras foi proposto uma ma- neira fácil e intuitiva de construção de regras a partir de programação visual baseada em blocos funcionais. A regra modelada é, então, associada a ações corres- pondentes que devem ser tomadas caso suas condi-
ções sejam satisfeitas. A princípio, tais ações estão limitadas a estratégias de inibição e habilitação de alarmes, assim como geração de mensagens de diag- nóstico para o operador, porém podem ser expandi- das para outras funcionalidades como diagnóstico de falhas.
O BR-PlantExpert foi desenvolvido como um plug-in do framework BR-Tool, tornando possível assim a utilização da interface de dados robusta e eficaz ofe- recida pela plataforma, além de outras vantagens (Lima, 2010).
Dessa maneira, o artigo encontra-se organizado da seguinte forma: na Seção 2 é apresentado um emba- samento teórico a respeito dos sistemas baseados em regras;; na Seção 3 é apresentada a ferramenta pro- posta e seus módulos;; na Seção 4 são apresentados experimentos e resultados obtidos;; e por fim, na se- ção 5 são apresentadas as principais conclusões e indicações para trabalhos futuros.
2 Sistemas especialistas
A área da computação chamada de inteligência artificial é bastante ampla e pode ser dividida em subgrupos. Entre eles, é possível citar os sistemas especialistas, denominados assim por modelarem conhecimento de especialista(s) em uma determinada
área, visando resolver problemas relativos a um do- mínio específico (Passos, 1989).
Assim, sistemas especialistas podem ser definidos como ferramentas computacionais que modelam o raciocínio e as ações de um humano ou grupo especi- alista em uma determinada á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). A arquitetura típica de um sistema especialista é composta de três componentes principais: 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 1.
Figura 1. Arquitetura típica de um sistema
especialista
A base de conhecimento é o conjunto de conheci- mento necessário para resolver um problema especí- fico. Esse conhecimento é extraído a partir fatos, heurísticas (experiências, opiniões, julgamentos, pre- dições, algoritmos) e relações que normalmente fo- ram formalizadas por especialistas em um determina- do 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 co- mumente utilizada é a conhecida como regras de pro- dução (Metaxiotis et al., 2002;; Ignizio, 1991). O motor de inferência é um elemento essencial para a existência de um sistema especialista. Ele é conside- rado o núcleo do sistema, uma vez que é por inter- mé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. Normalmente ela é com- posta de interfaces de visualização e diagnóstico, e pode também prover interfaces de comunicação para ferramentas externas, como bancos de dados.
Existe uma gama de formalismos que podem ser uti- lizados para modelar o conhecimento de sistemas especialistas, tais como, regras de produção, raciocí-
nio baseado em casos, redes neurais, redes probabi- lísticas, entre outros (Py, 2002). O sistema especialis- ta utilizado para a aplicação apresentada neste artigo foi o sistema baseado em regras de produção. 2.1 Sistemas baseados em regras de produção
O sistema baseado em regras é o método mais popular para representação de conhecimento dentre os sistemas especialistas (Carrico et al., 1989). Nessa abordagem, a construção de regras é realizada de forma procedural, no formato se-então ou situação- ação. Além disto, regras são facilmente desenvolvi- das a partir de tabelas e árvores de decisão (Hopgo- od, 2000).
Nos sistemas baseados em regras, a base de conheci- mento é subdividida em dois módulos: a base de re- gras e memória de trabalho (ou base de fatos), como ilustrado na Figura 2.
Figura 2. Arquitetura típica de um sistema baseado
em regras
A base de regras é responsável por armazenar o co- nhecimento abstrato, ou seja, o conjunto de regras de produção previamente elaboradas por um especialis- ta.
A memória de trabalho é o elemento que armazena o conhecimento concreto, ou seja, o conhecimento que pode ser considerado fato antes do processo de infe- rência. Essa base contém todas as informações sobre o problema que são fornecidas 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 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.
3 Arquitetura proposta
A arquitetura do BR-PlantExpert encontra-se subdivida em três módulos: o sistema especialista baseado em regras, a interface de visualização de alarmes e o ambiente de construção de regras. O pri- meiro é o módulo que implementa o sistema baseado em regras, responsável por combinar o conhecimento armazenado com os fatos adquiridos durante sua exe- cução. O segundo, a interface de visualização de alarmes, é responsável por prover ao operador uma tela de monitoramento de alarmes já validada pelo motor de inferência, ou seja, com a possibilidade de alguns alarmes já serem suprimidos. Por fim, o ambi- ente de construção de regras é o módulo responsável por permitir ao usuário a modelagem das regras que serão armazenadas na base de conhecimento do sis- tema especialista. Nas Subseções 3.1 a 3.3 esses três módulos são explicados mais detalhadamente. A arquitetura do sistema proposto pode ser vista na Figura 3. Na indicação (1) alarmes, eventos e variá- veis de processo provenientes das fontes de dados são armazenados na base de fatos (memória de traba- lho) do sistema especialista. Em (2) tem-se a indica- ção de que as ocorrências de alarmes são repassadas para a tela de visualização de alarmes. Na indicação (3) é representada a relação entre o ambiente de construção de regras, onde as regras são modeladas, e a base de regras, onde as mesmas são armazenadas. Por fim, em (4), tem-se os resultados do motor de inferência, que no escopo da aplicação, são indica- ções de supressão e/ou habilitação de alarmes.
Figura 3. Arquitetura do sistema proposto 3.1 Sistema baseado em regras
Este módulo é responsável pelo processamento de grande parte das funcionalidades do sistema. Co- mo exemplo de funcionalidades, pode-se citar a asso- ciação entre regras e fatos.
O sistema especialista baseado em regras utilizado nesta aplicação foi o Drools, um sistema desenvolvi- do pela JBoss (Bali, 2009).
O Drools fornece um conjunto de ferramentas com a função de definir, desenvolver, executar e monitorar a variedade e complexidade da lógica de decisão das regras de produção. Este sistema utiliza o algoritmo Rete, um algoritmo eficiente de casamento de pa- drões. No escopo dos motores de inferência, este algoritmo provê um suporte especializado na aplica- ção do casamento de padrões entre regras e fatos (Bali, 2009). Atualmente o sistema da JBoss está na versão 5.3 e é distribuído gratuitamente pelo site da desenvolvedora (http://jboss.org/drools).
3.2 Interface de visualização de alarmes
Como forma de validar as regras de supressão de alarmes configuradas, uma tela auxiliar específica foi desenvolvida para monitoramento de alarmes. Essa nova interface foi desenvolvida com o intuito de dis- ponibilizar a maior quantidade possível de informa- ções relevantes para o monitoramento de um proces- so e identificação de possíveis causas raízes de anor- malidades a partir dos alarmes.
Na Figura 4 é mostrada a interface de visualização desenvolvida para essa aplicação específica. Em (1) tem-se a lista de alarmes ativos que foram considera- dos relevantes pelo motor de inferência acoplado ao BR-PlantExpert. As cores identificam as prioridades dos alarmes e é possível até realizar o processo reco- nhecimento do alarme. Em (2) uma série de informa- ções do alarme (previamente selecionados na lista de alarmes ativos) é mostrada ao usuário. Tais informa- ções são dados de documentação do alarme disponi- bilizados pelo BR-AlarmExpert, sistema de gerenci- amento de alarmes que vem sendo implantado em diversos ambientes industriais (Leitão, 2008). Em (3) tem-se dados de leitura, em tempo real, de variáveis de processo relacionadas diretamente ao alarme pré- selecionado. Dessa forma, se torna mais intuitiva a identificação da causa raiz da anormalidade sinaliza- da pelo alarme por parte do operador. Por fim, em (4) é mostrada um gráfico com a leitura das últimas ho- ras 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.
Diante do apresentado, a interface de visualização proposta tem como intuito disponibilizar online ao operador as ocorrências de alarmes (identificados como relevantes pelo sistema de supressão), além de todas as informações necessárias para uma correta e rápida identificação da anormalidade. Essa interface não tem o intuito de substituir as atuais telas de moni- toramento de alarmes dos sistemas de supervisão, mas sim servir como mais uma fonte de informação integrada e disponível ao operador como um sistema auxiliar.
Figura 4. Interface de visualização de alarmes
3.3 Ambiente de construção de regras
O ambiente de construção de regras é o módulo responsável por prover ao usuário acesso à modela- gem de regras, que posteriormente serão carregadas e executadas na base de conhecimento do sistema es- pecialista.
A grande inovação do sistema proposto consiste em permitir que as regras sejam modeladas utilizando-se uma arquitetura hierárquica, o que torna possível uma estruturação mais simples e organizada da informa- ção sobre a planta industrial. Essa nova forma de modelagem se baseia no princípio de que toda vez que por algum motivo um sistema não esteja em fun- cionamento “normal” os alarmes associados devem estar suprimidos. No entanto, muitas vezes um siste- ma é composto por vários subsistemas que podem estar em funcionamento mesmo quando o sistema encontra-se parado. Nesse caso, os alarmes associa- dos aos subsistemas em funcionamento não podem, de maneira alguma, estarem suprimidos.
Por exemplo, se estamos modelando regras de su- pressão de alarmes de um forno, podemos modelar um sistema chamado Forno, e dois subsistemas: o sistema de alimentação de gás combustível para os pilotos (Header dos Pilotos) e o sistema de alimenta- ção de gás para os maçaricos (Header dos Maçari- cos). Desta maneira, podemos associar regras do sis- tema Forno levando em conta o estado de seus sub- sistemas, ou seja, o forno é considerado em pleno funcionamento quando todos seus subsistemas estão operacionais. No entanto, o subsistema Header dos Pilotos pode estar operacional mesmo quando o For-
modelagem das regras foi proposta uma forma hie- rárquica onde os estados do subsistema são modela- dos como parte integrante do forno e os alarmes as- sociados a um subsistema são suprimidos sempre que ele estiver parado. A divisão em subsistemas é feita com a premissa de que um dado subsistema deve possuir apenas dois estados: parado e operando. Sempre que um terceiro estado precisa ser definido para caracterizar o subsistema, isto será indicativo de que este deverá ser subdividido em outros subsiste- mas.
Um estado tem a função de refletir o funcionamento atual do sistema. Ou seja, estados estão associados a um sistema. Acredita-se que se o sistema for bem modelado, como foi descrito anteriormente, terá ape- nas dois estados: Operando e Parado.
As regras são construídas para definir a ativação ou não do estado, determinando assim o estado atual do sistema em questão. Então, a partir de blocos funcio- nais, 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. Para a construção das regras são disponibilizados blocos funcionais divididos em três classes:
x Alarme/Evento: São blocos ativados caso um determinado alarme ou evento ocorra. Por exemplo, a ocorrência do alarme PI- 98558.
x Variáveis 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 va- riável contínua de processo, como tempera-
uma variável discreta de processo, como o estado de uma válvula estar ativado.
x Estados: São blocos ativados quando um de- terminado estado de um sistema/subsistema se encontra ativo. Por exemplo, uma regra para o estado Operando do sistema Forno poderia ser se o Header dos Pilotos e o He- ader dos Maçaricos estiverem com o estado Operando ativo.
Para auxiliar a construção das condições das regras são oferecidos também operadores lógicos, permitin- do-se assim a criação de lógicas mais complexas. Há a possibilidade de se associar ações aos estados caso a condição de uma regra seja satisfeita. Mensa- gens de alerta e diagnóstico podem ser configuradas a fim de serem visualizadas na tela de operação. Ainda como ações, alarmes podem ser configurados para que sejam inibidos ou habilitados caso o estado em questão seja ativado. Assim, alarmes que estejam inibidos não serão visualizados na interface de visua- lização de alarmes.
Desta maneira, com estratégias bem elaboradas é possível tornar a tela de suporte a operação mais ob- jetiva sem perder informações importantes, auxilian-
do-se assim o operador de forma mais efetiva, princi- palmente em momentos críticos.
A interface do ambiente desenvolvido para constru- ção de regras pode ser visualizada na Figura 5. Em (1) tem-se o painel responsável pela visualização dos sistemas. É possível visualizar a hierarquia dos site- mas e selecionar o sistema em que se deseja obser- var/editar os estados. Em (2) tem-se a barra de ferra- mentas da aplicação. Entre as ferramentas temos: criar novo sistema/subsistema;; remover o siste- ma/subsistema selecionado;; renomear um siste- ma/subsistema;; criar novo estado para o siste- ma/subsistema selecionado;; salvar o trabalho atual;; e carregar um trabalho anteriormente salvo. Em (3) tem-se o painel de descrição. Nele é possível visuali- zar ou editar a descrição de um determinado estado de um sistema. Em (4) tem-se o painel de edição de regras. Neste painel as regras são modeladas de modo visual utilizando-se os blocos de condição e de ope- radores 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, em (5) encontra-se o painel de ações, onde se é possível determinar quais alarmes serão suprimidos e/ou habilitados da tela de visualização de alarmes. Também é possível configurar uma mensagem de alerta caso seja de interesse do operador.
Figura 5. Ambiente de construção de regras
4 Resultados
Os resultados foram realizados a fim de se veri- ficar dois importantes aspectos do sistema: desempe- nho e usabilidade. Na Subseção 4.1 foi realizada uma análise de desempenho da solução proposta. Na Sub- seção 4.2 um estudo de caso foi selecionado para demonstrar o funcionamento do sistema.
4.1 Análise de desempenho
A fim de se quantificar o desempenho do sistema realizou-se uma série de benchmarks. Após uma aná- lise do tempo de execução do sistema foram selecio- nados três fatores que poderiam refletir significati- vamente no desempenho do sistema: a quantidade de fatos na memória de trabalho, a quantidade de regras na base de regras e o número de regras disparadas em uma mesma iteração.
Os testes foram realizados medindo-se o tempo de execução de uma iteração do sistema de regras em um computador com processador quad-core AMD Phenom II 2.8GHz e 4GB de memória RAM. Para se obter valores mais confiáveis cada teste foi repetido dez vezes e sua média aritmética foi calculada. O primeiro teste baseou-se em fixar um número de regras e de disparos de regras (no caso, 2.500 para ambos) e incrementar a quantidade de fatos gradual- mente, de 100 até um total de 100.000 fatos. O resul- tado do teste (Figura 6) mostrou que o incremento de fatos não impacta significativamente o tempo de exe- cução. A diferença entre os tempos de execução para 100 e 100000 fatos não ultrapassou 4ms.
Figura 6. Impacto da quantidade de fatos no tempo
de execução do sistema
O segundo teste realizado visou determinar o impacto da quantidade de regras no tempo de execução do sistema. Fixou-se o número de fatos em 10.000 e o número de disparos de regras foi controlado para 100. O tamanho da base de regras variou entre 100 e 5.000 regras. O resultado obtido (Figura 7) mostra que a quantidade de regras não interfere significativamente o tempo de execução.
Figura 7. Impacto da quantidade de regras no tempo
de execução do sistema
O último teste de desempenho realizado foi o que trouxe o maior impacto ao tempo de execução. O teste consistiu-se em incrementar o número de regras disparadas durante uma iteração de execução das regras. O resultado obtido pode ser visto na Figura 8.
Figura 8. Impacto da quantidade de disparos de
regras no tempo de execução do sistema
Analisando-se todos os testes realizados, conclui-se que o fator limitante de desempenho do sistema é a quantidade de regras satisfeitas em uma mesma itera- ção. Porém, mesmo em um cenário improvável de 5.000 regras sendo satisfeitas na mesma iteração, o sistema respondeu em um tempo médio de 574ms, o que é satisfatório para o propósito de monitoramento de processos industriais.
4.2 Estudo de caso
Um experimento simulado foi desenvolvido para demonstrar o funcionamento do sistema. O estudo baseou-se em um forno industrial, e por motivos de simplificação foi modelado utilizando poucos subsis- temas (Figura 9).
O experimento controlado simula um cenário de ini- cialização da planta (start-up), onde o subsistema Header dos Pilotos está em operação e o Header dos Maçaricos está parado. Neste caso, a regra modelada para o estado Parado do Header dos Maçaricos tem como condição que uma das válvulas do subsistema esteja fechada (Figura 10). Como ação configurou-se a supressão dos alarmes associados a este subsistema, tais como os de pressão baixa, pressão muito baixa e de desvio de pressão baixa.
Figura 10. Regra modelada para o estado Parado do
Header dos Maçaricos
Neste cenário, a tela de monitoramento de alarmes do operador seria alimentada com alarmes provenientes do sistema em operação, o Header dos Pilotos, e com os alarmes do sistema que ainda está parado, o Hea- der dos Maçaricos. Com o módulo do sistema de regras em funcionamento, esta mesma tela seria oti- mizada a fim de serem visualizados somente alarmes relevantes no momento, que no caso seriam os asso- ciados ao subsistema em operação.
Na Figura 11 e 12 podem ser vistos o estado final da tela de monitoramento de alarmes rodando o sistema de regras (Figura 11), e sem este módulo em funcio- namento (Figura 12).
Figura 11. Tela de monitoramento de alarmes com o
sistema de regras
Figura 12. Tela de monitoramento de alarmes sem o
sistema de regras 5 Conclusão
A aplicação apresentada neste artigo tem como objetivo suprir uma demanda que vem sendo requisi- tada por grandes corporações do ramo de processos industriais: o auxílio à tomada de decisões, pois deci- sões rápidas e precisas são necessárias para evitar decréscimo de produção e até mesmo evitar inciden- tes com consequências graves.
Neste escopo, a solução proposta mostrou atender bem esse objetivo ao fornecer ao operador uma tela de alarmes com menos informações redundantes ou consideradas desnecessárias através de um processa- mento por um sistema especialista baseado em regras modeladas para aquela situação. Desta maneira o operador foca sua atenção em alarmes que são de extrema importância naquele determinado momento, resultando possivelmente em uma decisão mais rápi- da e com maior acurácia.
Esta característica incorpora uma importante inova- ção na área de processos industriais, que carece de tais ferramentas que visam evitar a sobrecarga de alarmes em um único operador em um curto intervalo de tempo.
A funcionalidade desta ferramenta a leva a ter uma ampla gama de aplicações que devem ser incorpora- das em trabalhos futuros.
Devido a sua concepção modular (Figura 3), a solu- ção proposta é altamente flexível, permitindo ser utilizada como base para diversas soluções baseadas em regras, como por exemplo, detecção e diagnóstico de falhas.
Agradecimentos
Os autores agradecem ao CENPES pelo apoio e recursos fornecidos ao projeto SIST2. O primeiro autor agradece a CAPES pela bolsa de estudos pro- porcionada.
Referências Bibliográficas
Bali, M. (2009). Drools JBoss Rules 5.0 Developer’s Guide, Packt Publishing.
Carrico, M. A., J. E. Girard, J. P. Jones. (1989). Building Knowledge Systems. Developing & Managing Rule-Based Applications. New York: McGraw-Hill Book Company.
Flores, C. D. (2003). Fundamentos dos Sistemas Especialistas. In: BARONE, D. A. C. (Ed.). Sociedades Artificiais: a nova fronteira da inteligência nas máquinas. Porto Alegre: Bookman. p.332.
Habibi, Eddie & Bill Hollifield (2006). ‘Alarm Systems Greatly Affect Offshore Facilities Amid High Oil Prices’, World Oil Magazine 227 pp. 101–105.
Hopgood, Adrian A. (2000). Intelligent Systems for Engineers and Scientists, Second Edition. CRC Press.
Ignizio, J.P. (1991). Introduction to Expert Systems – The Development and Implementation of Rule- based Expert Systems, New York: McGraw-Hill, Inc.
Leitão, Gustavo Bezerra Paz (2008). Algoritmos para Análise de Alarmes em Processos Petroquímicos, Dissertação de Mestrado, Universidade Federal do Rio Grande do Norte. Lima, Marcelo (2010). Sistema Integrado para
Auxílio à Análise de Incidentes. Prêmio Petrobras de Tecnologia – 5ª Edição.
Metaxiotis, K., Askounis, D. and Psarras, J. (2002) 'Expert systems in production planning and scheduling: a state-of-the-art survey', Journal of Intelligent Manufacturing, Vol. 13, pp.253-260. Momoh J., Srinivasan D., Tomsovic K., Baer D.
(2000). Chapter 5: Expert Systems Applications, em K. Tomsovic, M.Y. Chov (eds.), Tutorial on Fuzzy Logic Applications in Power Systems. Passos, E. L. (1989). Inteligência Artificial e
Sistemas Especialistas ao Alcance de Todos. Rio de Janeiro: LCT.
Py, M. X. (2002). Sistemas Especialistas: Uma introdução. Universidade Federal do Rio Grande do Sul. Porto Alegre.
