4.2 Life cycle cost analysis
4.3.3 Uncertainty analysis
O ambiente de construção de regras é o módulo responsável por prover ao usuário acesso à modelagem de regras, que posteriormente serão carregadas e executadas na base de conhecimento do sistema especialista.
Esta modelagem é feita a partir de programação visual através de blocos funcionais existentes e configurados pelo usuário. Fazendo uso desses blocos e de operadores lógicos também disponíveis, é possível a construção de uma lógica mais complexa que representa a condição de uma regra.
Nas subseções seguintes, quatro aspectos importantes do ambiente de construção de regras são abordados com a finalidade de tornar mais claro seus objetivos e funcionali- dades. Um quinto aspecto é introduzido com o objetivo de demonstrar uma das aplicações possibilitadas pela ferramenta.
Estrutura e Organização das Regras
A organização das regras no contexto da aplicação é formada seguindo a estrutura ilustrada na Figura 3.4.
Figura 3.4: Organização das regras no contexto da aplicação.
A modelagem é realizada a partir da definição de sistemas, estruturas que representam um conjunto ou parte de uma planta industrial. Estes sistemas são formados por estados, responsáveis por refletir o funcionamento atual do sistema em questão. Cada estado é então definido por uma regra, que será posteriormente incluída na base de conhecimento do sistema especialista.
A formulação de regras é realizada utilizando-se informações provenientes de fontes de dados, tais como de variáveis de processo, alarmes e eventos, e também de valores de
3.2. ARQUITETURA E APLICAÇÃO PROPOSTA 23 estados de outros sistemas.
Estas regras são construídas então para definir a ativação ou não de um estado, deter- minando assim o estado atual do sistema em questão. Então, a partir de blocos funcionais, o usuário constrói em forma de programação visual as condições necessárias para que o estado seja ativado e que determinadas ações sejam tomadas.
Tais ações dependem do escopo da aplicação em que o BR-PlantExpert está inserido, e para o caso desta dissertação esta aplicação foi a de supressão de alarmes.
Programação Visual Utilizando Blocos Funcionais
A disponibilidade de modelagem de regras utilizando-se programação visual é uma funcionalidade de extrema importância, visto que sistemas especialistas normalmente utilizam-se de linguagem de programação com diferentes sintaxes dificultando seu en- tendimento e compreensão por um usuário sem experiência. Desta forma, a progra- mação visual auxilia oferecendo uma linguagem de alto nível, rápida, fácil e intuitiva para usuários de diferentes níveis de conhecimento.
A ferramenta apresentada nesta dissertação tem a proposta de oferecer blocos fun- cionais configuráveis, assim como operadores lógicos, para a lógica da regra em questão ser então elaborada.
Os blocos funcionais disponíveis na ferramenta são organizados em três classes, alarme / evento, variável de processo e estado. A Figura 3.5 ilustra a visualização dos blocos dessas três classes.
Figura 3.5: Blocos funcionais disponíveis na aplicação.
I. Alarme/Evento
São blocos ativados caso um determinado alarme ou evento ocorra. Por exemplo, a ocorrência do alarme XA-4321. Este bloco, caracterizado pela cor amarela, tem como painel de configuração a tela apresentada na Figura 3.6.
A partir desta tela é possível optar por alarme ou evento e configurar a sua respectiva tag. A opção delay funciona como um operador temporal, possibilitando somente a vali- dade da condição após este tempo pré-configurado pelo usuário. Por fim, a opção Tempo
24 CAPÍTULO 3. SISTEMA DESENVOLVIDO
Figura 3.6: Painel de configuração do bloco de alarmes e eventos.
de Expiração, habilitada somente para eventos, invalida a condição após este tempo pré- configurado pelo usuário.
II. Variável de Processo
São blocos ativados caso uma variável de processo satisfaça uma condição. Essa condição depende do tipo de variável a ser tratada. Por exemplo, uma variável contínua de processo, como temperatura, ultrapassar um determinado valor, ou uma variável discreta de processo, como o estado de uma válvula estar ativado.
O painel de configuração deste bloco permite a escolha da tag a partir de três métodos diferentes:
• Método manual: Este método permite inserir a tag manualmente, sem quaisquer busca no servidor de dados. Desta maneira o tipo da variável também deve ser definido pelo usuário (Figura 3.7a).
• Método hierárquico: Este método permite listar todas as tags do servidor de forma hierárquica, caso o mesmo suporte esta funcionalidade. Desta maneira, as tags são visualizadas de uma forma mais simples e organizada, facilitando a escolha da mesma. A tag escolhida tem o seu tipo automaticamente definido através de uma consulta ao servidor (Figura 3.7b).
• Método por busca com máscara: Este método permite ao usuário inserir uma máscara responsável por filtrar as tags disponíveis no servidor, facilitando a escolha
3.2. ARQUITETURA E APLICAÇÃO PROPOSTA 25
(a) (b) (c)
Figura 3.7: Painel de configuração do bloco de variável de processo.
da tag. A tag escolhida tem o seu tipo automaticamente definido através de uma consulta ao servidor (Figura 3.7c).
Definida a tag da variável de processo, a condição do bloco é configurada a partir de uma expressão que define uma comparação matemática. Tal expressão terá uma saída verdadeira (true) ou falsa (false). Os operadores disponíveis para formulação da expressão variam de acordo com o tipo de variável associada. A lista abaixo indica os operadores disponíveis para cada tipo de variável de processo:
• Inteiro: >, >=, <, <=, == • Double: >, >=, <, <=, == • Booleano: true, false
• String: equals, startWith, endsWith
Esta expressão de comparação matemática permite ainda a opção por comparar uma variável a um valor constante (comparação estática) ou ainda a outra variável de processo, permitindo assim a configuração demonstrada na Figura 3.7c, que compara os valores de duas variáveis disponíveis no servidor (pid1.OUT > pid1.SP).
III. Estado
26 CAPÍTULO 3. SISTEMA DESENVOLVIDO
Figura 3.8: Painel de configuração do bloco de estado.
Desta maneira é possível associar o estado de um sistema a partir dos estados de outros sistemas. O painel de configuração deste bloco pode ser visualizado na Figura 3.8.
Para auxiliar a construção das condições das regras são oferecidos também operadores lógicos, permitindo-se assim a criação de lógicas mais complexas. Os operadores ofere- cidos pela ferramenta são: E lógico (a), OU lógico (b), negação lógica (c) e operador votação (n de m) (d). Estes operadores podem ser visualizados na Figura 3.9.
(a) (b) (c) (d)
Figura 3.9: Operadores disponíveis na construção de regras.
Modelagem Hierárquica
Uma das grandes inovações do sistema proposto consiste em permitir que as regras se- jam modeladas utilizando-se uma arquitetura hierárquica, o que torna possível uma estru- turação mais simples e organizada das informações sobre a planta industrial em questão. Essa hierarquia é visualizada a partir de uma estrutura do tipo árvore, permitindo assim que seja criado um sistema filho de um outro sistema, introduzindo assim o conceito de sistema e subsistema.
Associando esta forma de modelagem com o objetivo da aplicação, no caso, a su- pressão de alarmes, essa estruturação parte do princípio de que toda vez que por algum motivo um sistema não esteja em funcionamento normal os alarmes associados a este sistema devem estar suprimidos.
No entanto, muitas vezes um sistema é composto por vários subsistemas que podem estar em funcionamento mesmo quando o sistema encontra-se parado. Nesse caso, os alarmes associados aos subsistemas em funcionamento não podem, de maneira alguma, estarem suprimidos.
3.2. ARQUITETURA E APLICAÇÃO PROPOSTA 27 for bem modelado, todo sistema/subsistema pertencente a ele terá apenas dois estados: Operandoe Parado. Sempre que um terceiro estado precisa ser definido para caracterizar o subsistema, isto será indicativo de que este deverá ser subdividido em outros subsis- temas.
A Figura 3.10 demonstra um exemplo de modelagem hierárquica de uma planta didática:
Figura 3.10: Exemplo de modelagem hierárquica de uma planta industrial.
No entanto, a ferramenta permite também a modelagem de regras de um modo tradi- cional, ou, linear. Desta maneira, é possível simplesmente traduzir regras já estrategica- mente elaboradas e traduzi-las de forma visual no ambiente de construção de regras.
Essa possibilidade torna o sistema mais flexível, permitindo ao usuário diferentes metodologias de modelagem de regras, tanto a mais tradicional quanto uma mais sofisti- cada.
Interface Gráfica
A interface gráfica (GUI) do ambiente de construção de regras foi desenvolvida com o objetivo de simplificar a maneira como regras são modeladas, oferecendo facilidades e tornando a sua utilização o mais intuitiva possível. Esta interface pode ser visualizada na Figura 3.11.
O painel responsável pela visualização dos sistemas pode ser visto na indicação 1. É possível visualizar a hierarquia dos sitemas e selecionar o sistema em que se deseja observar/editar os estados.
A indicação 2 representa a barra de ferramentas da aplicação. Entre as ferramen- tas temos: criar novo sistema/subsistema; remover o sistema/subsistema selecionado;
28 CAPÍTULO 3. SISTEMA DESENVOLVIDO
Figura 3.11: Interface gráfica do ambiente de construção de regras.
renomear um sistema/subsistema; criar novo estado para o sistema/subsistema selecionado; salvar o trabalho atual; e carregar um trabalho anteriormente salvo.
O indicado em 3 é chamado de painel de descrição. Nele é possível visualizar ou editar a descrição de um determinado estado de um sistema.
Na indicação 4 temos o painel de edição de regras. Neste painel as regras são mo- deladas de modo visual utilizando os blocos de condição e de operadores anteriormente descritos. A lógica da regra deve ser construída e sua saída conectada ao bloco final do estado, caracterizado pela borda cinza.
Por fim, a indicação 5 representa o painel de ações, onde se é possível determinar quais alarmes serão suprimidos e/ou habilitados caso o referente estado seja ativado. Também é possível configurar uma mensagem de alerta caso seja de interesse do operador. Este painel se adapta com a aplicação em que o sistema está inserido.
Tradução Visual-Funcional
Uma vez que as regras tenham sido modeladas, é necessário realizar um processo de tradução tornando as mesmas conciliáveis com o sistema especialista. A linguagem utilizada no ambiente de construção de regras, essencialmente visual, necessita que aquela mesma informação inserida pelo usuário através da modelagem via blocos funcionais seja
3.2. ARQUITETURA E APLICAÇÃO PROPOSTA 29 repassada ao sistema especialista através de uma linguagem e sintaxe compatíveis. Faz- se necessário a utilização de uma interface de tradução entre o sistema especialista e o ambiente de construção de regras, como ilustrado na Figura 3.12.
Figura 3.12: Interface de tradução acoplando o ambiente de construção de regras ao sis- tema especialista.
A fim de serem processadas pelo sistema especialista baseado em regras, é necessário que as regras modeladas pelo usuário no ambiente de construção de regras sejam traduzi- das para uma linguagem compatível com o sistema. Essa tradução é realizada de forma transparente ao usuário, e não requer nenhum conhecimento acerca da sintaxe utilizada pelo sistema especialista.
O sistema especialista utilizado, o Drools, faz uso da linguagem nativa DRL (Drools Rule Language) [Bali 2009]. O ambiente de construção de regras é então responsável por processar os blocos funcionais modelados e configurações realizadas pelo usuário e traduzi-la em uma regra na linguagem DRL.
A Figura 3.13 ilustra um exemplo de uma regra modelada utilizando programação visual e a Figura 3.14 demonstra sua respectiva regra traduzida em linguagem DRL, po- dendo assim ser processada pelo Drools.
30 CAPÍTULO 3. SISTEMA DESENVOLVIDO
Figura 3.14: A mesma regra da Figura 3.13 traduzida para linguagem DRL.