Sistema especialista de 2ª geração para diagnose técnica: modelo e procedimento

2nd generation expert system for technical diagnosis: a model and a procedure

Resumos

Este trabalho trata da diagnose em equipamentos industriais através do uso de Sistemas Especialistas. Com o objetivo de desenvolver procedimentos que contribuam na construção de Sistemas Especialistas para diagnose em Manutenção Industrial, consideramos os chamados Sistemas Especialistas de 2ª Geração. Propomos um modelo modificado e um procedimento de diagnose. Na estratégia de diagnose utilizamos uma busca "top-down best-first", que combina dois tipos de tratamento de incerteza: (i) entropia, para decidir pelo melhor caminho nas estruturas de conhecimento, e (ii) crença nos sintomas, para validar os diagnósticos obtidos. Esta proposta traz as seguintes vantagens: base de conhecimento mais completa, melhores explicação e apresentação de diagnósticos finais. Desenvolvemos um protótipo com base em informações reais sobre bombas centrífugas.

sistemas especialistas; manutenção industrial; diagnose técnica

Sistema especialista de 2ª geração para diagnose técnica: modelo e procedimento

2^nd generation expert system for technical diagnosis: a model and a procedure

Néocles Alves Pereira

Prof. Doutor do Departamento de Engenharia de Produção da Universidade Federal de São Carlos. C.P. 676 - 13565-905 - São Carlos-SP; Fone: 0162-748238; Fax: [phone]; E.Mail: [e-mail]

RESUMO

Este trabalho trata da diagnose em equipamentos industriais através do uso de Sistemas Especialistas. Com o objetivo de desenvolver procedimentos que contribuam na construção de Sistemas Especialistas para diagnose em Manutenção Industrial, consideramos os chamados Sistemas Especialistas de 2^a Geração. Propomos um modelo modificado e um procedimento de diagnose. Na estratégia de diagnose utilizamos uma busca "top-down best-first", que combina dois tipos de tratamento de incerteza: (i) entropia, para decidir pelo melhor caminho nas estruturas de conhecimento, e (ii) crença nos sintomas, para validar os diagnósticos obtidos. Esta proposta traz as seguintes vantagens: base de conhecimento mais completa, melhores explicação e apresentação de diagnósticos finais. Desenvolvemos um protótipo com base em informações reais sobre bombas centrífugas.

Palavras-chaves: sistemas especialistas, manutenção industrial, diagnose técnica.

ABSTRACT

This paper deals with the diagnosis of industrial equipments through the use of Expert Systems. Intending to develop procedures that result in diagnosis knowledge bases for Industrial Maintenance, we have considered 2^nd Generation Expert Systems. We have proposed a modified model and a diagnosis procedure. We used for the diagnosis strategy a "top-down best-first search", that combines two types of uncertainty treatment: (i) entropy, to find the best way in the search throughout knowledge structures, (ii) belief in the symptoms, to validate the resultant diagnostics. This proposal has the following advantages: a more complete knowledge base, a better explanation and presentation of the resultant diagnostics. We have developed a prototype considering real informations about centrifugal pumps.

Key-words: expert systems, industrial maintenance, technical diagnosis.

1. Introdução

Na Manutenção Industrial, diagnose técnica é o processo destinado a encontrar explicações que cubram todos os sintomas de um equipamento que não execute a função requerida.

Propomos neste trabalho um MODELO DE TRABALHO e um PROCEDIMENTO DE DIAGNOSE para o desenvolvimento de Sistemas Especialistas (SE) voltados para a diagnose de equipamentos mecânicos. SE's de 2^a Geração para diagnose técnica, de acordo com WIELINGA et al. (1987) e STEELS (1990), são aqueles que possuem um conhecimento "profundo" sobre o sistema que deve ser diagnosticado. O nosso MODELO DE TRABALHO considera não só o conhecimento de um especialista em diagnose técnica, mas também o conhecimento da decomposição funcional do sistema a ser diagnosticado, correspondendo ao conhecimento "profundo", próprio dos SE's de 2^a Geração.

Vamos utilizar como objeto de diagnose uma bomba centrífuga, para o qual desenvolvemos um protótipo de Sistema Especialista. Consideramos aspectos comuns a todas as bombas centrífugas, sem focalizar um tipo ou uma marca específica.

A estrutura do trabalho é a seguinte: na seção 2 discutimos o modelo a ser empregado, na seção 3 apresentamos o procedimento utilizado na obtenção dos diagnósticos, na seção 4 abordamos a questão da implementação e terminamos na seção 5 discutindo vários aspectos adicionais.

2. Modelo de Trabalho

O nosso MODELO DE TRABALHO tem como base o modelo proposto em STEELS (1989). Na seção 2.1 apresentamos características do modelo original, na seção 2.2 apresentamos o nosso MODELO DE TRABALHO e na seção 2.3 temos algumas ilustrações do modelo proposto no caso de diagnose de bomba centrífuga.

2.1 Características do Modelo Função-Falha Original

O modelo proposto por Steels é uma composição de dois modelos: MODELO DE FUNÇÕES e MODELO DE FALHAS.

Segundo Steels, uma função é uma descrição de uma tarefa que necessita ser realizada. A decomposição deve ser feita considerando a sua utilidade para a diagnose. Quando uma função não é realizada, há uma disfunção. Steels considera ainda que, além de dependências entre sub-funções e sua função correspondente, há também dependências entre funções de mesmo nível: se uma função não é realizada, as funções que dependem dela ficam comprometidas.

Steels afirma ainda que um componente em um estado anormal causa uma disfunção e que um componente pode ter vários estados anormais (causas) associados a uma mesma disfunção.

O MODELO DE FUNÇÕES corresponde a uma decomposição de funções e sub-funções. A cada função primitiva deve existir um MODELO DE FALHAS.

Notamos na figura 1 duas afirmações feitas por Steels:

i. "Note that symptoms associated with a particular malfunction are inherited by all the subfunctions of the corresponding function and their associated causes and explanations"(p.10).ii. "...Next there is the fault model. A variety of malfunctions is associated with each function. Each of these malfunctions has a set of associated causes in the form of abnormal states of the component which normally executes the function. Each cause has a set of explanations, and remedies associated with each explanation"(p.12).

Steels indica em (i) e em (ii) que várias disfunções podem estar associadas a uma função. Além disso, em (i) ele afirma que os sintomas de uma disfunção são herdados pelos seus "descendentes", o que faz supor que o MODELO DE FUNÇÕES seja uma hierarquia (HARMON & SAWYER, 1990, p.308).

Para Steels, a confirmação de uma disfunção depende de um único conjunto de sintomas, de forma que a disfunção será confirmada se todos os sintomas deste conjunto forem confirmados. Para que uma disfunção ou uma causa seja confirmada, é preciso que os sintomas correspondentes estejam se manifestando. Caso não se tenha uma posição sobre a manifestação ou não destes sintomas, testes devem ser realizados.

Na afirmação (ii) observamos que Steels considera que apenas um componente está ligado a cada função, pois várias disfunções são associadas a uma função, um componente realiza a função, e várias causas são associadas a uma disfunção.

No MODELO DE FALHAS, pode haver tantas disfunções quantas necessárias, pois uma causa pode ser explicada por uma outra disfunção. Esta disfunção terá uma outra causa associada e isto pode ir se repetindo. A cada par [Disfunção, Causa] iremos chamar de ciclo.

Por outro lado, apesar de em (ii) Steels dar a entender que existam funções no MODELO DE FALHAS, isto não acontece. As funções estão descritas apenas no MODELO DE FUNÇÕES.

2.2 Características do Modelo de Trabalho

O modelo que trabalhamos tem as seguintes diferenças em relação ao modelo de Steels.

i. Número de disfunções associadas a uma função:

Consideramos que no MODELO DE FUNÇÕES exista apenas uma disfunção associada a cada função não primitiva.

A razão para isso é a seguinte: apenas as funções primitivas têm ligação direta com componentes do equipamento. As demais funções têm sub-funções, cada qual levando às suas funções primitivas. Cada função não primitiva é realizada por um conjunto de componentes e por isso qualquer disfunção associada a uma função não primitiva deverá considerar sintomas comuns a todos estes componentes que contribuam para a sua realização. Dessa forma, faz sentido dizer que os sintomas de uma disfunção são herdados por todos os seus descendentes, até o primeiro ciclo [Disfunção, Causa].

ii. Vários conjuntos de sintomas levando a uma disfunção ou a uma causa: Consideramos que, para a confirmação de uma disfunção, seja possível se utilizar de um ou mais conjuntos de sintomas.

No MODELO DE FUNÇÕES nem todos os conjuntos associados a uma disfunção precisam ser confirmados. Apenas os sintomas de conjuntos confirmados são herdados. Como conseqüência, os sintomas de conjuntos não confirmados não são herdados. De qualquer forma, se a disfunção for confirmada, o caminho a seguir é um só, independente do que provocou a sua confirmação.

No MODELO DE FALHAS existem disfunções, causas e seus respectivos conjuntos de sintomas. Para uma disfunção no MODELO DE FALHAS, a confirmação de um conjunto de sintomas específico faz com que apenas as causas correspondentes a este conjunto de sintomas sejam investigadas. Quanto ao número de conjuntos de sintomas ligados a uma causa, trabalhamos da mesma maneira.

Sempre que um dos conjuntos de sintomas de uma causa for confirmado, uma explicação correspondente a este conjunto de sintomas será ativado. Uma explicação pode se referir a uma outra disfunção, a qual, por sua vez, deve ser investigada como discutido acima.

iii. Número de componentes associados a uma função primitiva:

Enquanto Steels considera um único componente ligado a cada função primitiva, nós consideramos que pode haver mais de um componente. Ou seja, nosso entendimento é que: (i) pode haver várias disfunções primitivas associadas a uma função primitiva, (ii) pode haver várias causas associadas a uma disfunção primitiva, e (iii) cada causa se relaciona a apenas um componente do equipamento. Para Steels, todas as causas se referem ao mesmo componente.

Certamente, a questão da decomposição de funções pesou neste nosso comportamento. Conforme já visto anteriormente, o próprio Steels afirma que não há um regra fixa para a questão do quanto decompor as funções.

Admitimos que um mesmo componente possa ter estados anormais diferentes, porém, nesta situação, cada estado anormal irá provocar disfunções diferentes. Por exemplo, um rotor excêntrico pode causar desbalanceamento, um rotor cujos furos de balanceamento hidráulico estejam inadequados pode causar desbalanceamento hidráulico, e um rotor obstruído pode causar tanto desbalanceamento como desempenho insatisfatório. Assim, um mesmo componente (rotor) pode gerar causas associadas a disfunções diferentes (desbalanceamento, desempenho insatisfatório, desbalanceamento hidraúlico).

A figura 2 mostra que há disfunções logo na entrada do nosso MODELO DE FALHAS. Estas são as disfunções primitivas. Por simplicidade de apresentação, omitimos nesta figura as dependências entre funções de um mesmo nível.

Além das três diferenças apresentadas, temos algumas considerações adicionais em relação ao nosso MODELO DE FALHAS:

a. admitimos que algum erro humano relacionado com a montagem dos componentes também pode ser o causador da disfunção, sem que um deles esteja com problemas; esta hipótese não foi prevista por Steels.

b. como não pode existir causa confirmada sem que a sua disfunção correspondente tenha sido confirmada, entendemos que os sintomas de uma disfunção são herdados pela causa associada, de maneira que ambas trabalham como peça única no processo de determinação do diagnóstico.

Em função disso, tratamos cada par [Disfunção, Causa] como um ciclo; pode ocorrer encadeamento de ciclos: uma causa de um ciclo se ligaria com a disfunção de um ciclo seguinte.

c. admitimos apenas uma explicação a cada causa.

d. pode haver várias disfunções primitivas associadas a uma função primitiva. Por exemplo, na nossa base de conhecimento há uma função primitiva chamada "fluxo do líquido bombeado", que tem as seguintes disfunções primitivas associadas: "forças hidráulicas", "cavitação", "recirculação" e "desempenho insatisfatório", cada qual com seus conjuntos de sintomas. Lembramos que uma função primitiva tem apenas uma disfunção no MODELO DE FUNÇÕES e uma ou mais disfunções no MODELO DE FALHAS.

2.3 Modelo de Trabalho na Diagnose de Bombas Centrífugas

O objetivo desta seção é de ilustrar o uso do MODELO DE TRABALHO na diagnose de bombas centrífugas.

Para chegarmos ao MODELO DE FUNÇÕES, apresentamos ao especialista uma proposta de decomposição de funções. As sugestões, ou correções, do especialista foram dos seguintes tipos: (i) mudar nomes de funções, (ii) reordenar funções e (iii) reduzir o número de funções primitivas. Exemplos de sugestões: ao invés de "acionamento da bomba", o especialista sugeriu "acionamento do conjunto rotativo"; a função "vedação do líquido bombeado" foi colocada antes do "acionamento do conjunto rotativo"; e as funções primitivas penduradas em "operação do conjunto rotativo", bem como as penduradas em "fluxo do líquido bombeado", foram agregadas às respectivas funções pais.

O modelo resultante se encontra na figura 3. Consideremos a função primitiva "suporte de esforços". Para a disfunção em "suporte de esforços", temos os seguintes conjuntos de sintomas:

a) sintomas relativos ao SPM, que corresponde a uma medida de condições dos rolamentos:

- "tipo de rolamento é (rolo)(esfera)",

- "valor da freqüência de trabalho = 3600",

- "valor do SPM_corrigido > 50".

b) sintomas relativos às freqüências:

- "valor da freqüência predominante ³ 6 * valor da freqüência de trabalho",

- "valor da freqüência predominante £ 12 * valor da freqüência de trabalho".

c) sintoma relativo a ruído:

- "ruído junto aos mancais parece um chiado contínuo".

Basta que se confirme os sintomas de um destes conjuntos para que a disfunção seja confirmada e, neste caso, apenas os sintomas confirmados serão considerados pelos elementos abaixo de "suporte de esforços". O MODELO DE FALHAS é ativado quando a disfunção é confirmada, independente de quantos ou quais conjuntos de sintomas são utilizados.

Ao ser ativado, o MODELO DE FALHAS provoca a investigação de disfunções primitivas e de causas associadas. Supondo que um conjunto de sintomas de uma disfunção primitiva tenha sido confirmado, as causas associadas a este conjunto de sintomas da disfunção são investigadas.

No caso, vamos supor que as causas correspondam aos seguintes componentes: caixa de mancais, rolamentos, munhão. Além disso, uma outra causa considerada é com relação a um possível erro humano na montagem dos rolamentos. Assim, existem quatro causas que irão ser investigadas.

Cada uma dessas causas tem os seus próprios conjuntos de sintomas. Por exemplo, para o caso do componente "rolamentos" existem os seguintes conjuntos de sintomas:

a) sintoma relativo ao mancal de escora:

-"mancal de escora esteja com excesso de esforço axial". b) sintoma relativo à escolha do rolamento:

-"escolha de rolamentos na montagem foi inadequada".

c) sintomas relativos à recomendação inadequada de rolamentos, por parte do fabricante da bomba:

-"haja dificuldade na solução do problema pelas vias normais de manutenção", -"este tipo de problema relativo ao suporte tem ocorrido com frequência", -"escolha de rolamentos na montagem foi adequada".

Como acontece para uma disfunção no MODELO DE FALHAS, a confirmação do rolamento como causa ocorrerá sempre que um desses conjuntos for confirmado. Caso o componente seja confirmado como causador da disfunção pelos conjuntos (b) ou (c), a nossa base de conhecimento irá resgatar a explicação correspondente ao conjunto que for utilizado.

Por outro lado, se a confirmação do componente como causador da disfunção for através do conjunto de sintomas (a), a explicação que deveria aparecer irá trazer em seu lugar uma nova disfunção: "desbalanceamento hidráulico do rotor". Neste caso, a situação se repete, como se estivessemos iniciando um novo ciclo [Disfunção, Causa], com os seus respectivos conjuntos de sintomas.

3. Obtenção do Diagnóstico

Apresentamos nesta seção o PROCEDIMENTO DE DIAGNOSE que utilizamos para a obtenção da solução do nosso problema. Inicialmente apresentamos a estratégia de diagnose utilizada e em seguida discutimos a questão relativa ao tratamento de incerteza no processo de solução.

3.1 Estratégia de Diagnose

O nosso PROCEDIMENTO DE DIAGNOSE considera uma busca do tipo "best-first", pois tentaremos decidir pelo melhor caminho para que se encontre mais rapidamente a solução.

Adicionalmente, como estamos considerando que poderão ser obtidos todos os diagnósticos, precisamos evitar a investigação de trechos da base de conhecimento que não sejam significativos. Em função disso, procuramos podar a árvore de conhecimento sempre que for possível.

Passamos a apresentar a estratégia que utilizamos no PROCEDIMENTO DE DIAGNOSE. Uma observação importante é que aqui apresentamos apenas a "lógica" principal da estratégia. A figura 2 pode ajudar na compreensão da estratégia.

Os passos 1 a 3 correspondem ao MODELO DE FUNÇÕES e os passos 5 a 7 correspondem aos MODELO DE FALHAS. O passo 4 faz uma ponte entre os dois modelos. Esta estratégia realiza uma busca "top-down best-first":

1. Considere as sub-funções associadas à "melhor" função principal disponível e confirmada por um sintoma principal observado e vá para o passo 2. Se não houver função principal confirmada disponível, terminou a diagnose.

2. Confirme a "melhor" disfunção disponível até atingir uma função primitiva e vá para o passo 3. Não havendo disfunção para confirmar, suba e tente no nível acima: atingindo o nível 1 da decomposição de funções, vá para o passo 1; senão repita o passo 2.

3. Confirme a disfunção da função primitiva e vá para o passo 4. Não sendo confirmada, volte ao nível da sub-função "pai" da função primitiva e vá para o passo 2.

4. Estando em uma função primitiva, considere se o MODELO DE FALHA já foi investigado:

- se ainda não foi investigado, resgate as disfunções primitivas, no MODELO DE FALHAS correspondente, e vá para 5;

- se já foi investigado, vá para o passo 2.

6. Confirme a "melhor" disfunção disponível e vá para o passo 6. Não havendo disfunção para confirmar, considere que:

- estando no nível de disfunções primitivas, volte à função primitiva e vá para o passo 4;

- não estando no nível de disfunções primitivas, retorne ao ciclo [Disfunção, Causa] anterior e vá para o passo 6.

7. Confirme a "melhor" causa disponível e vá para o passo 7. Não havendo causa para confirmar, volte para o passo 5.

8. Se existir um novo ciclo [Disfunção, Causa], considere as disfunções do novo ciclo e vá para o passo 5. Caso não exista um novo ciclo, vá para o passo 6.

Um primeiro aspecto a comentar sobre a estratégia é quanto ao significado do termo "confirme" utilizado nos passos 2, 3, 5 e 6. Diz respeito à confirmação dos conjuntos de sintomas associados à disfunção ou à causa, conforme o passo.

Devemos, entretanto, frisar que tanto a confirmação como o próprio resultado da confirmação são diferentes entre os dois modelos. No MODELO DE FUNÇÕES: basta que um dos conjuntos de sintomas seja confirmado para que uma disfunção seja confirmada (passos 2 e 3), e o caminho a seguir independe do(s) conjunto(s) de sintomas confirmados. Já no MODELOS DE FALHAS: a confirmação de um conjunto de sintomas, além de confirmar a disfunção (passo 5), ou causa (passo 6), estará também definindo um caminho particular a seguir.

Um segundo aspecto a considerar em relação à estratégia apresentada, diz respeito a movimentos de descida e de subida nas estruturas dos modelos:

a. MODELO DE FUNÇÕES: permite descer através do passo 2 e subir através dos passos 2 e 3.

b. MODELO DE FALHAS: permite descer através do passo 6 e subir através do passo 5.

O passo 4, como ponte entre os dois modelos, permite tanto subir ao MODELO DE FUNÇÕES, bem como descer ao MODELO DE FALHAS.

Um terceiro aspecto que merece registro é que, no processo de busca, ao mergulharmos no MODELO DE FALHAS, sempre que uma causa é encontrada, verificamos se o número de causas confirmadas acumuladas atingiu um limite pré-estabelecido.

Este limite pré-estabelecido (CARDOZO & TALUKDAR, 1987), representa o número máximo de causas permitido indicado por um especialista. Este valor varia de equipamento para equipamento e até das condições de manutenção na empresa.

Estas causas deverão ser armazenadas convenientemente, de forma que seja possível no final de todo o processamento indicar as causas de maneira ordenada.

Podem existir vários conjuntos de diagnósticos, todos com cardinalidade menor ou igual ao limite pré-estabelecido. Este procedimento serve para podarmos a árvore de busca, da mesma forma que o tratamento de incerteza faz ao invalidar o diagnóstico que está sendo construído.

Apresentamos um anexo com detalhes da estratégia de diagnose proposta.

3.2 Tratamento de Incerteza

3.2.1 Incerteza na Busca do Diagnóstico

A estratégia de diagnose apresentada exige que se tome algumas decisões:

- no MODELO DE FUNÇÕES: qual disfunção disponível deve ser confirmada? qual função primitiva disponível deve ser investigada?

- no MODELO DE FALHAS: qual disfunção disponível deve ser confirmada? qual causa disponível deve ser confirmada? qual conjunto de sintomas disponível deve ser confirmado?

Dependendo da decisão tomada, é seguido um caminho na estrutura de conhecimento.

Vamos estimar as incertezas com base nos custos de testes associados aos sintomas, bem como nas probabilidades de ocorrência também associadas aos sintomas, às causas e às disfunções. Dos dois parâmetros, convém esclarecer o que seria uma probabilidade de ocorrência.

Conforme vimos no MODELO DE TRABALHO, a nossa situação típica é ter uma disfunção entre várias de uma lista, uma causa entre várias de uma lista e um conjunto de sintomas entre vários de uma lista. A probabilidade de ocorrência diz respeito ao quanto um desses elementos conseguiria contribuir na explicação do problema sendo diagnosticado, relativamente aos demais elementos de sua lista. A soma das probabilidades de ocorrência dos elementos de uma mesma lista deve ser igual à unidade.

Por exemplo: dada uma lista de causas disponíveis e a probabilidade de ocorrência de uma das causas igual a 0.4, significa que esta causa consegue explicar oproblema sendo diagnosticado em 40% das vezes, relativamente às outras causas da lista. Esta probabilidade representa uma medida da obrigação da causa em explicar o problema, isto porque ao menos uma das causas da lista deve explicar o problema, caso contrário há um erro na base de conhecimento ou ela está incompleta.

A fórmula básica para o nosso cálculo de incerteza é:

CH = - [C_teste] * [P_ocorr*ln(P_ocorr)] (1)

Vamos inicialmente analisar a participação da entropia no cálculo de CH ("C" de custo e "H" para entropia).

Em (1), a parte da entropia envolve a probabilidade de ocorrência (P_ocorr) e foi proposta por Shannon, da Teoria de Informação. Nesta área, entropia é tida como uma medida da incerteza do conteúdo de uma mensagem antes de recebê-la (HYVÄRINEN (1968, p.24)).

Para o nosso trabalho, estamos considerando entropia como uma medida da incerteza do resultado da investigação de um sintoma antes de realizar os testes associados. Nos convém trabalhar com o candidato com a menor entropia.

Observamos em (1) que quanto menor ou quanto maior a probabilidade de ocorrência, menor será o valor de CH, devido, respectivamente, ao próprio valor da probabilidade e ao valor do logaritmo da probabilidade.

Além da entropia, consideramos em (1) o custo de teste dos sintomas relacionados com o elemento em análise.

Assim, o nosso critério para escolher o "melhor" elemento de uma lista é considerar o elemento com o menor valor de CH. Em outras palavras, iremos escolher o elemento que deverá ter o maior poder de conclusão, seja a favor ou contra, e com o menor custo de teste.

Passamos a apresentar a maneira pela qual iremos utilizar este critério. Vamos considerar os tipos de decisões no nosso MODELO DE TRABALHO:

a. no MODELO DE FUNÇÕES: escolher uma função de uma lista de funções associadas a uma função pai.

Como a cada função existe apenas uma disfunção, ao escolhermos uma função estaremos automaticamente escolhendo uma disfunção.

Para cada sub-função candidata, consideramos como custo de teste a soma dos custos de testes de todos os sintomas nos diversos conjuntos de sintomas associados à disfunção da função. As probabilidades de ocorrência são estimadas através de dados do setor de manutenção ou pelo especialista. A disfunção com o menor valor de CH é a escolhida.

Uma questão que poderia ser levantada seria quanto aos conjuntos de sintomas associados à disfunção: qual deve ser investigado primeiramente? Todos os conjuntos de sintomas devem ser investigados, independente da ordem, embora a confirmação de um deles baste para que a disfunção seja confirmada. A cada conjunto de sintomas confirmado, "mais forte" deverá ficar o diagnóstico final.

b. no MODELO DE FALHAS:

- escolher uma disfunção de uma lista de disfunções disponíveis (estas disfunções pertencem a um ciclo [Disfunção, Causa]).

- escolher um conjunto de sintomas de uma lista de conjuntos de sintomas disponíveis associada à disfunção sendo investigada.

- escolher uma causa disponível de uma lista de causas associada ao conjunto de sintomas da disfunção sendo investigada.

- escolher um conjunto de sintomas de uma lista de conjuntos de sintomas disponíveis associada à causa sendo investigada.

Em todos os casos supomos conhecidas as respectivas probabilidades de ocorrência. Assim, falta discutirmos como são calculados os respectivos custos de testes. Como regra geral, utilizamos o mesmo princípio usado no MODELO DE FUNÇÕES, ou seja, o custo de teste de uma causa ou de uma disfunção é igual à soma dos custos de testes de todos os sintomas de todos os conjuntos de sintomas associados. Na escolha do conjunto de sintomas a trabalhar, consideramos a soma dos próprios custos de testes do conjunto.

Uma observação geral com relação ao uso deste critério é: sempre que uma lista é formada, cada elemento da lista será investigado até o fim, antes que outro elemento da lista o seja.

Continuando a analisar a questão do tratamento de incerteza no auxílio do processo de busca no espaço de estados, devemos comentar duas situações que podem ocorrer na aplicação do procedimento proposto:

a) mudança na certeza sobre o conhecimento disponível após a investigação de um conjunto de sintomas

No MODELO DE FALHAS, em relação a uma causa ou a uma disfunção, quando um conjunto de sintomas de uma lista é investigado, isto faz com que as incertezas (CH's) dos demais conjuntos de sintomas da lista tenham que ser atualizadas antes de se escolher o próximo conjunto a ser investigado, já que as suas incertezas mudam e podem alterar a ordem de investigação anteriormente estabelecida. A cada atualização dessas não iremos alterar as incertezas das causas ou disfunções relacionadas.

No final da investigação de todos os conjuntos de sintomas de uma causa (ou disfunção), ela é desconsiderada de sua lista e aí sim atualizamos as incertezas das demais causas (disfunções) da lista.

Para uma disfunção no MODELO DE FUNÇÕES o raciocínio é idêntico. Atualizamos as incertezas das disfunções de uma lista, apenas quando uma das disfunções tiver sido completamente investigada e portanto eliminada da lista.

b) empate dos CH's na escolha de um conjunto de sintomas

Considerando a expressão para o cálculo de CH, as possibilidades que existem para esta situação são:

i. custos de teste iguais a 0(zero) nos conjuntos de sintomas empatados: de início esta situação pode acontecer se todos os sintomas, dos conjuntos de sintomas empatados, forem de conhecimento do usuário; durante o processamento, quando um teste é feito, o seu custo de teste é zerado para representar que não haverá gastos adicionais com este teste. Neste caso, a recomendação é de se trabalhar com a entropia pura, ou seja, na expressão em (1), não se deve considerar o custo de teste.

ii. custos de testes iguais entre si e probabilidades de ocorrência também iguais entre si, todos diferentes de 0(zero): a sugestão é considerar o tempo de teste de cada um e trabalhar com o que levar menor tempo.

3.2.2 Incerteza na Validade do Diagnóstico

O objetivo desta seção é de apresentar um procedimento que auxilie na poda da árvore de conhecimento do nosso MODELO DE TRABALHO e que auxilie também na classificação de diagnósticos encontrados.

Optamos pelo uso do procedimento aproximado do Mycin, o qual será adaptado para o nosso MODELO DE TRABALHO.

Para apresentação da proposta do tratamento de incerteza, lembramos que os dois modelos que compõem o nosso MODELO DE TRABALHO têm características próprias:

a. MODELO DE FUNÇÕES é uma decomposição funcional onde os sintomas de um conjunto de sintomas confirmado de uma disfunção são herdados por todas as suas sub-funções.

b. MODELO DE FALHAS também corresponde a uma árvore, porém em cada ramificação existe um encadeamento de ciclos [Disfunção, Causa]. Pode haver apenas um desses ciclos. A raiz dessa árvore é a função primitiva correspondente.

Vamos começar com o caso do MODELO DE FUNÇÕES. A convicção na confirmação de um sintoma é determinante na confirmação de um diagnóstico. Na descida do MODELO DE FUNÇÕES, o usuário entra com suas convicções sobre a confirmação de cada sintoma questionado. Esta sua crença deve ser dada através de um valor que lhe é perguntado. O mesmo acontece com relação a todos os sintomas dos conjuntos de sintomas associados à disfunção. Estes valores são compilados e então propagados.

Por exemplo, na figura 4, suponhamos que o conjunto de sintomas CS₁ possua três sintomas, os quais tenham sido confirmados e por isso o sistema solicita ao usuário que entre com um valor que represente a crença que ele tem sobre cada sintoma. Como os sintomas do conjunto devem ser todos satisfeitos (conjunção de sintomas) e como estes valores representam a convicção que o usuário tem sobre cada sintoma, temos que a certeza do conjunto CS₁ será (no máximo) igual à certeza do sintoma mais duvidoso do conjunto. Dessa forma, a certeza nos sintomas dentro de um conjunto de sintomas será igual à certeza do sintoma mais duvidoso.

Caso a disfunção tenha apenas um conjunto de sintomas, a certeza a ser propagada será representada pelo valor da certeza de seu conjunto de sintomas. Se a certeza do conjunto de sintomas for 0(zero), não haverá o que propagar, já que o usuário não terá a mínima convicção sobre a confirmação dos sintomas.

Para disfunções como D₃, da figura 4, que tem CS₃, CS₄ e CS₅, lembramos que basta que um destes conjuntos de sintomas seja confirmado para que D₃ seja confirmada e somente os conjuntos de sintomas confirmados serão herdados pelos elementos abaixo de D₃. Quanto mais conjuntos de sintomas forem confirmados, maior será a convicção no(s) diagnóstico(s) a ser(em) determinado(s) no MODELO DE FALHAS.

Como os conjuntos de sintomas confirmados de D₃ irão participar de uma conjunção de todos conjuntos de sintomas herdados por uma causa no MODELO DE FALHAS, adaptamos, para a certeza relativa a D₃, a conclusão vista anteriormente: a certeza de D₃ será igual à certeza do conjunto de sintomas confirmado mais duvidoso

Considerando o exposto, é possível estimarmos o valor da certeza da disfunção D₅, que poderá ser propagada abaixo de F₅ (o asterisco representa um valor de certeza para propagação):

Certeza^*(D₅) = min[Certeza(D₁), Certeza(D₃), Certeza(D₅)],

o que leva aos cálculos das certezas de D₁, D₃ e D₅:

Certeza(D₁) = Certeza(CS₁) = min [Certeza(S_i)],

onde os S_i's correspondem a todos os sintomas dentro de CS₁;

Certeza(D₃) = min [Certeza(CS₃), Certeza(CS₄), Certeza(CS₅)],

onde cada Certeza (CS_k) desta lista é calculada como:

Certeza(CS_k) = min [Certeza(S_r)],

onde os S_r's correspondem a todos os sintomas dentro de CS_k, e por último:

Certeza(D₅) = Certeza(CS₇) = min [Certeza(S_t)],

onde os S_t's correspondem a todos os sintomas dentro de CS₇.

O valor encontrado para "Certeza^*(D₅)" representa a medida da crença (ou

convicção ou certeza) em todos os sintomas confirmados até aquele ponto. Este valor poderia ter sido calculado de maneira um pouco diferente: bastaria achar o mínimo entre "Certeza(D₅)" e "Certeza^*(D₃)".

O valor da certeza de propagação associada a uma função primitiva deve ser utilizada pelas disfunções primitivas ligadas a ela. Considerando um ciclo [Disfunção, Causa] que emane de uma função primitiva, todos os sintomas confirmados anteriormente a ele serão herdados por sua disfunção, bem como pela causa associada.

A herança dos sintomas confirmados no MODELO DE FUNÇÕES pela disfunção primitiva se deve ao fato de que todos os sintomas de cada função são comuns a todos os componentes que contribuem com a sua realização dessa função.

Por outro lado, entendemos que uma disfunção em um ciclo [Disfunção, Causa] corresponde a um primeiro sinal ou a um sintoma mais aparente, que seja comum a todas às causas que emanem da disfunção.

Observamos, na figura 5, dois ciclos primitivos emanando de D₅: ciclos 1 e 2.

Os sintomas a serem considerados na incerteza da causa do ciclo 1 correspondem (i) a todos os sintomas herdados pela disfunção primitiva do ciclo 1, DP₁, mais (ii) os sintomas da disfunção, e (iii) os sintomas da própria causa. O cálculo da certeza correspondente segue o mesmo procedimento apresentado.

Dessa forma teremos um valor que representa a convicção que o usuário tem em relação a todos os sintomas confirmados até o momento, os quais estarão ligados à causa do ciclo 1. Mais precisamente, há uma regra que teria a seguinte estrutura para o exemplo:

SE

[sintomas do MODELO DE FUNÇÕES]

[sintomas relativos à disfunção do ciclo 1]

[sintomas relativos à causa do ciclo 1]

ENTÃO

[CAUSA É Y] (FC = 0,80)

Portanto a conclusão "CAUSA É Y" é confirmada se todas as suas três condições são confirmadas. "FC" corresponde ao fator de certeza da regra. Quanto maior o valor de FC, maior é a crença na conclusão. No exemplo, se as três condições fossem corretas, haveria uma forte evidência de que a "CAUSA É Y".

No entanto, na medida em que a crença nas condições diminui, a crença no diagnóstico também diminui. A maneira de se calcular o FC que considere esta situação é:

FC(conclusão) = FC(condições) * FC(regra) (2)

Nesta expressão, FC(condições) corresponde à crença acumulada em todos os sintomas ligados à causa, FC(regra) é um valor estimado por um especialista e FC(conclusão) corresponde à crença que resultou na confirmação de que "CAUSA É Y".

Eventualmente a conclusão confirmada poderia ser usada em um ciclo seguinte: suponha que estivéssemos trabalhando no ciclo 2 da figura 5 e que ele já tivesse sido confirmado. O ciclo 3 só será investigado se o ciclo 2 já tiver sido confirmado e a relação conjunta entre os dois ciclos pode ser vista como:

SE

[causa confirmada do ciclo 2]

[sintomas relativos à disfunção do ciclo 3]

[sintomas relativos à causa do ciclo 3]

ENTÃO

[CAUSA É Z] (FC = x)

e o valor da certeza sobre o diagnóstico deve ser calculado como indicado na expressão (2).

Caso houvesse outros ciclos o procedimento deveria ser análogo.

Os valores relativos a todas as certezas, sejam as estimadas pelo usuário, sejam as estabelecidas pelo especialista, variam entre [0; 1], onde 0(zero) significa que o sintoma ou a regra não é válida e 1 significa que o sintoma ou a regra está correto(a). Não trabalhamos com evidências desfavoráveis a uma causa ou a uma disfunção.

Uma situação importante, que é considerada, diz respeito ao FC da regra a ser utilizada no primeiro ciclo do MODELO DE FALHAS. Considerando a figura 5, sejam as duas regras em um ciclo primitivo:

R1:

CS1,CS3,CS4,CS7,CS(DP1),CS(CAUSA1)

==>

CAUSA1

(FC1)

R2:

CS1,CS3,CS7,CS(DP1),CS(CAUSA1)

==>

CAUSA1

(FC2)

a diferença entre as duas é que R1 considera que CS4 tenha sido confirmada, enquanto que na R2 não. Evidentemente FC1>FC2 já que a R1 incorpora mais evidências que a R2. Portanto, o valor do FC de uma regra do ciclo primitivo depende de quais conjuntos de sintomas são confirmados no MODELO DE FUNÇÕES.

Apresentada a maneira de se calcular o valor das certezas dos diagnósticos, resta indicar como ele é usado.

Para o primeiro objetivo estabelecido, que é o de auxiliar a podar a árvore de conhecimento do modelo, basta que comparemos o valor da certeza acumulada com um valor pré-definido pelo usuário. Este valor deve representar a certeza mínima exigida pelo usuário nos diagnósticos sendo concluídos. Assim, toda vez que o valor da certeza ficasse abaixo deste valor pré-definido, a busca seria interrompida na direção que estava indo e o controle do processamento passaria para o estágio anterior de onde foi interrompido.

Na medida em que o usuário entre com uma confirmação com pouca convicção, os valores das certezas no MODELO DE FUNÇÕES serão baixos, da mesma forma que os FC's finais ficam reduzidos. Isto significa que o grau de certeza tende a diminuir quando se desce pela árvore de conhecimento. Por isso, a cada momento que o grau de certeza é atualizado, ele deve ser comparado com o valor pré-definido pelo usuário.

Em relação ao segundo objetivo, que é de ter uma classificação dos diagnósticos encontrados, basta que os fatores de certezas correspondentes sirvam de base para a classificação.

4. Sobre a Implementação do SE de 2^a Geração

Utilizamos o "shell" Nexpert Object, da Neuron Data, para a implementação de um protótipo de SE relativo a este trabalho. O protótipo desenvolvido utiliza regras, objetos, propriedades e "meta-slots". Atualmente o número de cada um destes elementos ultrapassa: 135 regras, 250 objetos, 50 propriedades e 440 "meta-slots". Existem aproximadamente 90 diferentes sintomas, distribuídos em aproximadamente 70 conjuntos de sintomas.

O processo de desenvolvimento começou com a definição do MODELO DE FUNÇÕES e a partir dele elaboramos cada MODELO DE FALHA. Cada uma dessas bases de conhecimento foi verificada por várias vezes com o especialista e assim que todas as bases de conhecimento foram consideradas satisfatórias, coletamos as informações relativas à incerteza e integramos as bases de conhecimento.

Na elaboração de cada MODELO DE FALHAS, incorporamos o tratamento de incerteza de auxílio da melhor decisão do caminho a seguir, antes de integrar as bases de conhecimentos.

Os números de elementos no protótipo, apresentados acima, correspondem à base de conhecimento global.

As estruturas definidas pelo MODELO DE TRABALHO (v. figura 2), não correspondem à organização interna da base de conhecimento. Vamos descrever rapidamente a estrutura dos objetos e das regras da base de conhecimento global e um pouco de suas relações.

Todos os objetos utilizados compõem uma árvore cuja raiz é o objeto "BB_CENTRIFUGA" que tem a seguinte estrutura resumida:

. eventos

.. disfunções (todas as disfunções, de todos os ciclos)

... sintomas

.. causas (todas as causas, de todos os ciclos)

... sintomas

. pontes

.. entre causas e disfunções (todas as ligações do tipo)

.. entre disfunções e causas (todas as ligações do tipo)

.aux

.. em geral utilizada para ligação do lado direito de uma regra com a hipótese de outra regra

.outros: custo_max, hipo_geral e start.

As estruturas eventos e a estrutura pontes descrevem os dois modelos do nosso MODELO DE TRABALHO. Cada objeto da estrutura eventos tem um conjunto de "meta-slots" relacionados à determinação de, por exemplo: custo de teste, probabilidade de ocorrência, entropia, custo máximo etc.

O objeto custo_max foi utilizado como um artifício: na fórmula de CH, em (1), dividimos todos os custos de teste pelo custo max encontrado na base, a fim de que os valores dos respectivos pelos CH's fossem baixos e respeitassem uma restrição interna do "shell". Este artifício não altera a ordem do resultado. O objeto start é usado para disparar a sessão de maneira "top-down", buscando valores para alguns parâmetros. O hipo_geral inicia o PROCEDIMENTO DE DIAGNOSE indo verificar a melhor função principal.

Para a movimentação no MODELO DE FUNÇÕES, utilizamos regras do tipo:

SE

YES temperatura_junto_aos_mancais_esteja_acima_do_normal

ENTÃO

YES suporte_conjto_rotativo_X_partes_estacionarias.disfunção

DO suporte_conjto_rotativo_X_partes_estacionarias.entropia

DO aux_suporte_conjto_rotativo_X_partes_estacionarias

Caso o sintoma seja confirmado, fica provada a hipótese de que há uma disfunção e então duas ações serão imediatamente executadas. A primeira dessas ações serve para calcular o CH, de cada sub-função pendurada na função atual, que acaba de ser "provada" na regra atual. Cada CH está associado a uma regra que liga a função atual a uma sub-função abaixo dela. Cada uma dessas regras tem, como hipótese, o objeto aux na segunda ação do exemplo dado.

Dessa maneira, com base nos CH's escolhemos que regra iremos disparar e com isso iremos investigar a sub-função que mais nos interessa. As outras ficam em uma lista. É dessa maneira que descemos no nosso MODELO DE TRABALHO.

A cada pergunta sobre sintomas, que é feita ao usuário, há três alternativas: (i) "o sintoma é verdadeiro", (ii) "o sintoma é falso", e (iii) "não sei". Neste último caso, o controle do "shell" irá tentar provar outra disfunção, em outra regra, o melhor CH, para continuar a estratégia da diagnose.

Em relação aos valores das certezas calculados para validação do diagnóstico, eles devem ser guardados junto aos respectivos objetos.

5. Discussão

Apresentamos uma proposta de SE para diagnose, cuja base de conhecimento se utiliza de um MODELO DE TRABALHO e de um PROCEDIMENTO DE DIAGNOSE.

Mostramos várias diferenças entre o nosso MODELO DE TRABALHO e o modelo original de STEELS (1989). O MODELO DE TRABALHO possui uma estrutura padrão que permite a aplicação do PROCEDIMENTO DE DIAGNOSE, que segue uma estratégia de busca do tipo "top-down best-first".

Em CARDOZO & TALUKDAR (1987), os autores trabalham com uma busca do tipo "best-first", porém as manifestações são praticamente todas conhecidas no momento em que se inicia a diagnose. Em função disso, até poderia ser utilizada uma busca em paralelo. No nosso caso, boa parte das manifestações devem ser descobertas a partir do momento em que se inicia a diagnose. Isto nos impediu de utilizarmos a métrica proposta pelos autores.

Por outro lado, adaptamos a restrição de um número máximo de causas associadas a um problema a ser diagnosticado, utilizada no referido trabalho. Isto possibilitou à nossa estratégia encurtar a busca no espaço de soluções. Neste mesmo sentido, propomos o uso de um tratamento de incerteza que considera a convicção nas confirmações dos sintomas sendo investigados através dos modelos, para invalidar ou não um diagnóstico que vai sendo montado. Para esta tarefa, adaptamos o procedimento aproximado do Mycin. Na nossa revisão da literatura não tivemos a oportunidade de ver algo parecido.

Estes dois recursos, a validade do diagnóstico sendo montado e o número máximo de causas, permitem que se faça uma poda mais eficaz da árvore de soluções. Mesmo procurando considerar as diagnoses mais corretas, pode acontecer que testes desnecessários sejam realizados. Propomos então um procedimento que estima a incerteza correspondente a cada caminho por onde podemos descer pela nossa estrutura com base em dois parâmetros: custo do teste de cada sintoma e a probabilidade de ocorrência associada aos sintomas, às disfunções e às causas.

Vimos que, por exemplo, uma das causas associadas a uma disfunção confirmada deve necessariamente participar do diagnóstico final, caso contrário a base tem erros ou está incompleta. Assim, as probabilidades de ocorrência medem a obrigação que cada um tem na tentativa de montar o diagnóstico. Chamamos o cálculo desta incerteza de CH, pois multiplicamos o custo de teste pela entropia associada, a qual é calculada com a probabilidade de ocorrência.

LEE et al. (1992) utilizam custo relativo e entropia para este tipo de incerteza, sendo que para a entropia os autores utilizam uma medida de crença de algum especialista. Adicionalmente, no exemplo que apresentam, o modelo deep por onde começa a diagnose (que corresponderia ao nosso MODELO DE FUNÇÕES), corresponde a uma decomposição da estrutura física do sistema em diagnose. Não é feita qualquer investigação de sintomas neste modelo, no sentido de se confirmar algum problema. A entropia é utilizada apenas no modelo chamado shallow (que corresponderia ao nosso MODELO DE FALHAS), onde para o cálculo da entropia de um elemento qualquer, utilizam as entropias dos elementos de dois níveis abaixo do elemento para o qual se faz o cálculo, o que cria um problema no final da busca. Além disso, os autores não consideram a atualização das probabilidades a cada investigação que é realizada.

Não utilizamos "lógica nebulosa", no lugar do procedimento adaptado do Mycin, devido aos seguintes motivos:

(i) indefinição de que operador de composição e de que operador de implicação deveríamos utilizar na regra de inferência composicional de Zadeh (veja, por exemplo, TERANO et al. (1992, cap.3));

(ii) existência de vários sintomas usando variáveis "crisps" em nossa base de conhecimento, isto é, variáveis que não são "nebulosas";

(iii) grande volume de variáveis "nebulosas", onde para cada uma teríamos que identificar os possíveis qualificadores e para cada qüalificador, uma função de pertinência;

(iv) questões de interface: transformação de uma entrada na forma lingüística em um valor que pudesse ser operado em um conjunto "nebuloso" (seria uma "fuzzificação" da entrada), bem como a volta ("desfuzzificação");

(v) restrições do "shell" sendo utilizado.

Entendemos que o protótipo desenvolvido pode ser usado tanto no campo como na oficina e com o equipamento estando aberto ou fechado. Ficará mais fácil a utilização do protótipo que desenvolvemos em ambientes que trabalhem com manutenção preditiva, porque utilizamos informações relativas à análise de vibrações, que normalmente é utilizado em manutenção preditiva. Caso contrário, o usuário terá que levantar informações que pode não estar acostumado a lidar e com isso a sua convicção nas confirmações de sintomas pode ser baixa.

Para manutenção corretiva, em ambientes que não tenham manutenção preditiva, a sugestão é que o usuário forneça ao sistema uma "certeza mínima exigida nos diagnósticos" igual a 0(zero). Dessa forma, o usuário não terá diagnósticos desconsiderados devido à incerteza em suas validades. Em um extremo, o usuário poderia fazer com que o "número máximo de causas permitido" fosse alto a ponto de não atrapalhar na diagnose. Assim, o sistema poderia varrer toda a base de conhecimento. A cada diagnóstico encontrado, caso quizesse, o usuário poderia interromper a busca, ou congelar a sessão.

Por outro lado, no levantamento de todos os diagnósticos possíveis, muitos problemas futuros poderiam ser percebidos e corrigidos, o que contribuiria com o principal propósito da manutenção: aumentar a disponibilidade e a confiabilidade do equipamento.

• CARDOZO, E & TALUKDAR, S. N.: "D2: a distributed expert system for fault diagnosis". IEEE Power Industry Computer Application, April / 1987.
• HARMON, P. & SAWYER, B.: Creating Expert Systems for Business and Industry 1.ed., New York, John Wiley & Sons, 1990.
• HYVÄRINEN, L. P.: Information Theory for Systems Engineers (Lectures Notes in Operations Research and Mathematical Economics) Springer-Verlag Berlin, 1968.
• LEE, W. Y; ALEXANDER, S. M.; GRAHAM, J. H.: "A diagnostic expert system prototype for CIM". Computers & Industrial Engineering, vol. 22, n. 3, p. 337-352, 1992.
• STEELS, L.: "Components of Expertise". AI MAGAZINE, p. 28-49, Summer / 1990.
• STEELS, L.: "Diagnosis with a function-fault model". Applied Artificial Intelligence, v. 3, n. 2-3, 1989.
• TERANO, T.; KIYJI, A.; SUGENO, M.: Fuzzy Systems Theory And Its applications. Academic Press, London, 1992.
• WIELINGA, B. J.; BREDENEG, B. & BREUKER, J. A.: "Knowledge Acquisition for Expert Systems". Proceedings of the ACAI, Springer, Berlin, p. 96-124, 1987.

Datas de Publicação

• Publicação nesta coleção
  21 Jun 2010
• Data do Fascículo
  Abr 1994