Base de Factos

A base de factos (BF) é composta por tuplos que representam factos verda- deiros no domínio. Uma vez que o Sparse caracteriza um domínio de conhe- cimento dinâmico, os factos podem ser temporalmente etiquetados em função do instante em que ocorreram os eventos que lhes deram origem. No exemplo anterior, o primeiro facto msg/5 (linha 4) está temporalmente etiquetado com o instante T1 em contraste com o segundo facto disj/7 (linha 6) que não possui qualquer referência temporal.

Adicionalmente, o raciocínio temporal utilizado pressupõe que a não ser que algo seja expresso em sentido contrário, um facto manterá o seu valor lógico. Isto significa que o facto é verdadeiro a partir do instante em que é inserido na base de factos até ao instante da sua remoção.

4.2.1.3 Base de Meta-regras

A base de meta-regras (BMR) consiste num conjunto de relações com a seguinte estrutura:

facto_dispara_regra(Facto,Lista-de-janelas-temporais)

onde Lista-de-janelas-temporais é uma lista de tuplos com a seguinte estrutura: (Regra,TInicio,TFim)

na qual, Regra é o identificador de uma regra da BR e TInicio, TFim são os instantes inicial e final, respectivamente, que definem a janela de validade

temporal da regra Regra. Assim, a chegada de um facto (Facto) à base de factos, tem como consequência o escalonamento de um conjunto de regras para utilização nos respectivos períodos temporais. Este mecanismo permite configurar uma abordagem heurística comum na resolução de problemas de diagnóstico. Esta abordagem apresenta as seguintes características:

Limitar o espaço do problema – Visto que assegura que apenas um conjunto de regras, relacionadas com o facto, serão testadas, produzindo desta forma uma melhoria do desempenho do sistema;

Tentar diferentes soluções – Tipicamente o sistema progride das so- luções mais específicas para as mais genéricas. Este comportamento é modelado através do escalonamento das regras de acordo com uma ordem de teste específica.

No exemplo seguinte é apresentada uma das meta-regras que aquando da en- trada de um facto msg/5 com os parâmetros do exemplo permite escalonar as seguintes regras: d1, d2 e d3 (apresentada na secção anterior) para os intervalos [30, 50], [31, 51] e [52, 52], respectivamente. facto_dispara_regra( msg(_,_,[Inst1,Painel1,_],’>>>DISPARO’,’01’), [(d1,30,50), (d2,31,51), (d3,52,52)] ).

4.2.2 Mecanismo de Inferência

O mecanismo de inferência funciona de acordo com o algoritmo apresentado na figura 4.2. Em cada iteração do ciclo é seleccionado um facto da BF. Relembre- se que um facto pode corresponder a uma mensagem recolhida pelo sistema SCADA ou a uma conclusão previamente inferida. Com base nas meta-regras

definidas pelo tuplo facto_dispara_regra/2 são escalonadas para teste as regras associadas ao referido facto, ou seja, apesar de os factos serem processados sequencialmente em função da chegada à BF, isso não implica que as regras sejam igualmente processadas de forma sequencial, pois é possível diferir o processamento de uma regra através da definição da janela temporal.

Após a selecção de uma regra é utilizado o mecanismo de prova da linguagem PROLOG de forma a determinar o valor lógico do conjunto de condições que compõem o LHS da regra em causa. No caso das condições serem verdadeiras, o conjunto de acções que compreendem o RHS são executadas. Note-se que as condições que compõem o LHS podem não ser apenas factos, no sentido em que se descrevem eventos do domínio, mas também evocação de instruções específicas da linguagem (e.g., realização de cálculos).

4.3 Validação do Sparse

Conforme referido anteriormente, a verificação e validação são processos que têm um objectivo comum: garantir a qualidade do sistema desenvolvido. No entanto, em termos de funcionamento são bastantes distintos. A validação analisa a relação entre entradas e saídas do sistema de forma a determinar a adequação da solução desenvolvida ao problema a resolver, enquanto que a verificação visa certificar a adequação das técnicas ao desenvolvimento da referida solução.

No que diz respeito ao sistema Sparse, no processo de validação foram utiliza- das um conjunto de técnicas, designadamente, os testes de campo e simulação de cenários, que permitiram de forma conjugada avaliar diferentes aspectos do seu funcionamento.

Base de factos Iniciar Seleccionar facto Escalonar regras Base de meta-regras Testar regra Fluxo de Processo Fluxo de Dados Seleccionar meta-regra Base de regras Conclusão final Adicionar conclusão intermédia Gerar diagnóstico Sim Não Iterar Concluir Sim Não

4.3.1 Testes de Campo

Inicialmente foram realizados testes de campo nos quais operadores localizados num conjunto de subestações seleccionadas activavam equipamentos de forma a produzirem séries de mensagens que configuram cenários para os quais se pretendia avaliar o desempenho do sistema Sparse. Este desempenho foi avaliado de forma positiva por um conjunto de peritos do domínio.

Apesar dos evidentes benefícios, a realização de testes de campo levanta um conjunto de dificuldades logísticas e económicas, visto que é necessário envolver um número considerável de recursos humanos na execução e coordenação das manobras, bem como manter linhas de transmissão e outros recursos fora de serviço durante a execução dos testes.

4.3.2 Simulação de Cenários

De forma a obviar os custos relacionados com a execução dos testes de campo a equipa da REN (Rede Eléctrica Nacional) [Rosado, 1993] desenvolveu uma solução que assenta numa unidade de terminal remota (UTR) e num gerador de impulsos programável (GIP) que em conjunto permitem simular a produção e recepção dos sinais processados pelo sistema SCADA.

A técnica de simulação de cenários com o GIP pode ser utilizada numa subes- tação à escolha da equipa, normalmente a mais próxima do centro de controlo. Desta forma, o operador do GIP na subestação não está longe da equipa en- volvida na avaliação do Sparse e pode participar com facilidade nas reuniões de coordenação. Esta técnica permitiu simular uma vasta gama de incidentes de forma a validar o Sparse, tão exaustivamente quanto possível [Vale et al., 1997b].

Inicialmente, como entradas neste sistema de teste foram utilizados diversos casos reais que tinham sido coleccionados ao longo dos anos de operação da rede eléctrica. No entanto, no últimos anos, fundamentalmente devido aos naturais avanços tecnológicos, as redes eléctricas tornaram-se muito fiáveis, fazendo com que a ocorrência de determinados cenários ou incidentes particulares se torne rara. Por essa razão, foi necessário produzir casos de teste que retratassem situações não abrangidas pelos casos reais.

Na figura 4.3 são apresentados três diagramas que representam alguns dos testes que permitiram descrever situações que a equipa testou.

M D1 DISP 1 370 0 T1 DA 1 200 0 170 DF 1 270 0 100 DISP 1 7300 0 200 DA 1 200 6900 0 1100 _T1 DF 1 1200 0 100 6000 M D6: 120 DISP 1 1570 300 0 1100 200 DA 1 200 1420 0 170 1220 DF 1 370 T1 300 0 100 M D2/M D3:

Figura 4.3: Esquema com Simulação de Incidentes

Nestes diagramas são avaliados três sinais ao longo do tempo: DISP representa um disparo de um disjuntor enquanto que DA e DF representam disjuntor aberto e fechado, respectivamente. Cada um dos sinais binários pode ser

verdadeiro ou falso (’1’ ou ’0’). A representação do tempo não é proporcional, os instantes são representados pelos números nas células. Esta representação não proporcional permite assinalar de uma forma sintética todos os instantes relevantes (e.g., os limites das janelas temporais definidas nas meta-regras ou limites das operações temporais realizadas nas condições de cada regra). Note- se que quando um sinal muda de valor, o SCADA gera automaticamente uma mensagem que reporta o facto.

No seu conjunto, a avaliação produzida pelos peritos e pela simulação através de casos reais e produzidos forneceu as garantias requeridas para a utilização do Sparse em ambiente real.

4.4 Verificação do Sparse

No que diz respeito ao Sparse foram essencialmente dois os motivos para iniciar o trabalho de verificação:

• O Sparse, como qualquer outro projecto de software, após a fase ini- cial de desenvolvimento entrou numa fase de manutenção, que envolveu também a adição de funcionalidades e modificações à base de conheci- mento, sendo que no último caso seria necessário proceder aos trabalhos de validação após cada modificação. Ora, conforme se referiu anterior- mente, alguns dos testes abrangidos pela validação são, por razões várias, particularmente difíceis de realizar;

• O processo de validação coloca bastante ênfase na análise da relação entre entradas (casos) e saídas (resultados) do sistema, enquanto que a verificação permite fazer a análise mais exaustiva do funcionamento do próprio sistema, visto que coloca a ênfase nos métodos e técnicas

utilizadas no processamento das entradas e saídas do sistema.

As limitações inerentes às técnicas nas quais a validação se baseia são supe- radas pela verificação, pois a última preconiza a realização de testes lógicos exaustivos que podem ser realizados de forma expedita e sucessiva, por exem- plo, após cada actualização da base de regras.

As qualidades associadas às técnicas de verificação são mais visíveis quando existe uma ferramenta de verificação automática pois esta permite realizar os referidos testes de forma sistemática, exaustiva, rápida e com custos muito re- duzidos (sendo que neste caso o custo principal diz respeito ao desenvolvimento da própria ferramenta). A descrição da ferramenta de verificação, designada de Veritas, será realizada com detalhe no capítulo 5.

4.5 Problema da Verificação

Uma das abordagens mais utilizadas na verificação de sistemas baseados em regras consiste em determinar de forma sistemática e analítica todas as cadeias de inferência (expansões) passíveis de serem geradas pelo sistema e identificar situações potencialmente inválidas, isto é, situações em que o conjunto de restrições lógicas e/ou de domínio possam ser violadas. Na figura 4.4 são representados os componentes mais relevantes nesta visão do problema da verificação: uma base de regras e um conjunto de restrições são utilizados na identificação de problemas aquando do cálculo de expansões. Esta abordagem foi já seguida nos sistemas COVADIS [Rousset, 1988], COVER [Preece et al., 1992] e DIVER [Zlatareva, 1991], com resultados muito satisfatórios.

No entanto, a verificação de sistemas aplicados em ambientes reais obriga à consideração de um conjunto de restrições adicionais que podem tornar o pro-

Base de Regras Exp ansõ es das Reg ras R es triç õe_s

Figura 4.4: Problema da Verificação – Perspectiva Clássica

blema significativamente mais complexo. Aliás, esta foi talvez a mais impor- tante constatação aquando da verificação do sistema Sparse [Pereira, 1998] utilizando a primeira versão da ferramenta Veritas.

M e ca_n is_m o d e S e le cç_ã o d e R e g ra_s Avali ação de Variá veis R a cio cín io T_e m p_o ra_l Proced imenta l vs Decla rativo Base de Regras Exp ansõ es das Reg ras R es triç õe_s

Figura 4.5: Problema da Verificação – Perspectiva Veritas

Considere-se o caso do Sparse, sistema destinado a um ambiente dinâmico com algumas especificidades, como a necessidade de raciocinar sobre eventos temporais, que implicam alterações nas técnicas a utilizar na verificação. Na figura 4.5, o núcleo é circundado por alguns aspectos que merecem uma análise detalhada (ver secção 4.5.1 a 4.5.4).

A principal questão relacionada com a consideração dos aspectos particula- res de cada sistema é o risco de desenvolver soluções de verificação específicas eventualmente difíceis de reutilizar. No que diz respeito ao desenvolvimento de uma ferramenta automática de verificação para utilização no sistema Sparse, o trabalho foi conduzido de forma a tentar manter um equilíbrio entre a resolu- ção de problemas reais conhecidos e a pesquisa de técnicas e métodos genéricos que justificassem o investimento.