Protótipo Inicial – SEGRED-SCGAS 1.0

A criação de um protótipo inicial é uma fase importante no desenvolvimento do sistema especialista. Seu principal objetivo é implementar imediatamente as decisões feitas no projeto preliminar, e testar a sua validade no contexto do problema. Estas decisões devem ser justificadas ou corrigidas com base no conhecimento obtido dos especialistas durante o desenvolvimento do protótipo.

Se uma mudança de paradigma ou de ferramenta for necessária, isto pode ser feito o mais cedo possível para minimizar o desperdício de esforços e despesas com softwares e hardwares desnecessários (GONZALEZ e DANKEL, 1993).

O protótipo inicial deve parecer com o sistema final, exceto que ele será limitado em sua abrangência. Deve seguir as especificações de requisitos tanto quanto possível. Deve incluir uma interface com o usuário bem evoluída e uma base de conhecimento razoavelmente robusta para que os usuários julguem sua aceitabilidade e aplicabilidade. Porem isto não significa que o protótipo deve ser altamente robusto. Deve apenas refletir o sistema final que será desenvolvido.

O protótipo inicial, neste projeto, foi denominado SEGRED-SCGAS 1.0. Foi direcionado exclusivamente para o problema de diagnosticar falhas em válvulas de redução de pressão de estações ERP e ERPM na rede de distribuição de gás natural da SCGÁS. Definiu-se como domínio de aplicação a rede de distribuição da cidade de Joinville-SC. Na época em que o protótipo foi implementado, somente alguns clientes estavam consumindo gás, e apenas estes foram considerados na implementação. Este protótipo inclui as seguintes funções:

Configuração do cenário operacional – permite ao usuário modificar as variáveis de

processo, para testar as respostas do sistema especialista em diferentes situações operacionais.

Verificação da situação operacional da rede – apresenta um resumo com os problemas

detectados nas estações.

Diagnósticos em estações – realiza o diagnóstico de falhas em equipamentos de estações.

Para construir a base de conhecimento foram utilizadas as informações obtidas através da análise de falhas em válvulas de redução de pressão, feita juntamente com os técnicos e

engenheiros da SCGÁS. O método de inferência então escolhido era o encadeamento reverso, que corresponde à forma como os especialistas procuram pelas causas das falhas no processo de diagnóstico.

Para o projeto da interface gráfica do protótipo, buscou-se seguir os requisitos definidos no projeto preliminar. Foi criada uma representação gráfica da rede, em uma versão aproximada ao que seria a versão final do sistema, com acesso às informações referentes às estações e clientes que a integram. A Figura 4.2 apresenta a tela principal do protótipo inicial implementado.

Figura 4.2 - SEGRED-SCGAS 1.0 - tela principal

Embora simplificada, a tela principal fornece uma visualização da configuração da rede e da localização das suas estações e dos seus clientes, e permite identificar os diâmetros de tubulação, utilizados nos ramais da rede. Além disso, ela permite acessar as demais janelas e recursos oferecidos pelo protótipo.

O usuário pode acessar o ambiente específico para visualização de estações ERP ou ERPM da rede a partir da tela principal. A seguir, a Figura 4.3 mostra um exemplo de ambiente para estações, referente a uma estação ERPM da rede.

Figura 4.3 - SEGRED-SCGAS 1.0 - tela de ERPM

Neste ambiente, o usuário tem acesso a informações e variáveis operacionais referentes à estação. No lado esquerdo estão listados os valores de ajuste de pressão aplicados às válvulas reguladoras, válvulas de alívio e de bloqueio automático da estação. Á direita encontram-se as variáveis de pressão a jusante e montante da estação e o consumo instantâneo de gás do cliente. Mais abaixo existe um campo referente a sintomas observados em campo na estação.

Não havia, nessa ocasião, a disponibilidade de dados pelo sistema de aquisição, pois este se encontrava em fase de implantação na empresa. As variáveis de consumo de gás e pressões a montante e jusante da estação precisavam ser inseridas pelo usuário manualmente. Com a inserção destes dados, o usuário testava as respostas do sistema para diferentes cenários operacionais na rede. As informações referentes a sintomas específicos observados a estação também precisavam ser selecionadas pelo usuário antes de processar um diagnóstico. Estas informações eram usadas, juntamente com as variáveis de processo, como entradas do sistema especialista.

Ao solicitar uma verificação da situação operacional da rede, é apresentada ao usuário uma janela contendo um breve relatório, indicando os problemas detectados nas estações da rede. A Figura 4.4 mostra um exemplo de relatório.

Figura 4.4 - SEGRED-SCGAS 1.0 - verificação de situação operacional da rede

A detecção de problemas em estações é feita com base nas variáveis de processo inseridas pelo usuário. O usuário pode, então, solicitar o diagnóstico em uma estação, para investigar as causas dos problemas encontrados.

A intenção deste protótipo foi testar a abordagem do problema pelo encadeamento reverso. Desta forma, o processo de diagnóstico consiste em gerar hipóteses para as causas dos problemas encontrados e buscar por informações que comprovem estas hipóteses. Estas informações são solicitadas ao usuário em uma seqüência de perguntas, cuja ordem depende da prioridade definida na base de conhecimento. A Figura 4.5 mostra um exemplo de diagnóstico feito para uma estação ERPM que apresenta um problema de pressão alta a jusante.

O resultado do diagnóstico depende das respostas do usuário, e é apresentado na forma de um relatório, contendo todas as informações processadas e a conclusão.

Após a avaliação do protótipo pelos especialistas, constatou-se que sua aplicação seria mais adequada como uma ferramenta de treinamento de pessoal técnico na área de manutenção da rede de distribuição de gás. Porém, sua aplicação como ferramenta de apoio à operação da rede seria inviável. Embora de acordo com a prática dos especialistas, a abordagem proposta para o diagnóstico apresentou complicações, devido à natureza das informações solicitadas ao usuário.

Conforme apresentado mais adiante, no item 4.5.1, esta constatação implicou na mudança mais significativa ocorrida nas definições do projeto, qual seja, a substituição do método de inferência pelo encadeamento direto.

Este tipo de mudança é uma conseqüência esperada do processo. A maioria dos autores da área recomendam que o protótipo inicial seja descartado após sua avaliação, com o desenvolvimento do sistema final partindo do início. O reaproveitamento do seu código fonte para as próximas versões só deve ser cogitada caso todas as decisões tomadas inicialmente mostrem-se acertadas e justificáveis no protótipo inicial. O mais comum é que algumas decisões feitas durante o desenvolvimento do protótipo inicial, revelem-se inadequadas e dependentes de revisão pela equipe de desenvolvimento. Nestes casos, o esforço necessário para reaproveitar o código do protótipo inicial buscando refletir as revisões de projeto, raramente compensa.