universidade federal do parÁ departamento de …‡Ão - igor pinto... · universidade federal do...

UNIVERSIDADE FEDERAL DO PARÁ

DEPARTAMENTO DE ENGENHARIA ELÉTRICA E DE COMPUTAÇÃO

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA

IGOR PINTO SIMÕES

UM SISTEMA MULTI-AGENTE PARA MONITORAMENTO DE

GERADORES DE ENERGIA ELÉTRICA

DM 07 / 2008

BELÉM

2008

1

IGOR PINTO SIMÕES



Dissertação apresentada ao Programa de Pós-

Graduação em Engenharia Elétrica da

Universidade Federal do Pará como requisito

parcial para a obtenção do título de Mestre.

Orientador: Prof. Dr. Walter Barra Junior

BELÉM

2008

2

IGOR PINTO SIMÕES



Dissertação apresentada ao Programa de Pós-

Graduação em Engenharia Elétrica da Universidade

Federal do Pará como requisito parcial para a

obtenção do título de Mestre.

Banca Examinadora:

_______________________________ - Orientador

Prof. Dr. Walter Barra Junior -UFPa

_______________________________ - 1º Membro

Prof. Dr. José Augusto Lima Barreiros - UFPa

_______________________________ - 2º Membro

Prof. Dr. Carlos Tavares da Costa Júnior - UFPa

_______________________________ - 3º Membro

Prof. Dr. Roberto Célio Limão de Oliveira - UFPa

_______________________________ - 4º Membro Prof. Dr. Orlando Fonseca Silva - UFPa

_______________________________ - 5º Membro Prof. Dr. José Augusto Furtado Real – UNAMA / IESAM

Julgado em: _____/_____/_____

Conceito: __________________

Visto:

Prof. Dr. ...........................................

(COORDENADOR DO PPGEE/ITEC/UFPA)

UFPA / ITEC / PPGEE

3

Dedico este trabalho aos meus pais que me

deram a oportunidade de estudar e me

apoiaram em todos os momentos que precisei,

me fornecendo assim, toda tranqüilidade e

confiança para desenvolver minhas atividades.

4

AGRADECIMENTOS

A todos os professores da graduação e pós-graduação que me propiciaram uma

excelente formação acadêmica e me deram incondicional apoio sempre que precisei.

A todos os colegas de curso em especial: André Nasser, Claudomir Junior, Patrícia

Endo e Luís Fernando pela convivência, aprendizado e amizade tão importantes em minha

formação enquanto profissional e ser humano.

Aos funcionários e amigos dos diversos laboratórios da UFPa, em especial do LACOS

e NESC, que me forneceram toda a infra-estrutura que precisei para desenvolver este projeto.

Aos amigos e familiares que sempre estiveram comigo me apoiando e incentivando.

Aos meus pais pelo apoio e incentivo dados desde o início de meus estudos.

Aos amigos Engenheiros Fabrício Gonzáles e Bruno Leal pelo desenvolvimento do

sistema de aquisição de dados e medição do desgaste das escovas.

Ao meu Orientador Prof. Dr. Walter Barra Junior pela dedicação incondicional sempre

que precisei, tanto como professor, Orientador PIBIC, Orientador de TCC e orientador de

mestrado. Em todos os momentos da graduação nunca me faltou e sempre correspondeu às

minhas expectativas, me dando suporte para desenvolver minhas atividades com o máximo de

excelência.

O autor e seu orientador agradecem ao suporte recebido das Centrais Elétricas do

Brasil (ELETRONORTE), através do projeto de pesquisa e desenvolvimento “

Desenvolvimento de um Sistema baseado em Agentes Inteligentes para o monitoramento de

Unidades Geradoras na UHE de Tucuruí ”, código 450005249, no desenvolvimento desta

pesquisa.

5

A sedução da distância e da dificuldade é

ilusória. A grande oportunidade está onde você

se encontra.

John Borroughs

6

RESUMO

De forma a obter um sistema apropriado que forneça funcionalidades importantes acerca da

operação e manutenção de um sistema de potência, faz-se necessário considerar alguns

aspectos sobre alarmes de faltas e monitoração. Quando se têm informações sobre o

relacionamento dos dados de entrada e fenômenos gerados por eles (estímulo-resposta), usam-

se normalmente algoritmos inteligentes de interpretação, tais como sistemas fuzzy e

mineração de dados. Mas se essas informações não estiverem disponíveis, uma abordagem

alternativa seria utilizar um sistema dinâmico de monitoração capaz de determinar o

comportamento esperado e normal de uma planta industrial. Esse trabalho descreve como a

tecnologia de sistemas multi-agente pode ser usada para construir um sistema desse tipo. Isso

é demonstrado através de um sistema multi-agente de alarme de anomalias aplicado a um

sistema de potencia.

Palavras-chave: Sistema de potência. Operação.

ABSTRACT

In order to have a more appropriate system that supplies important functions about operation

and maintenance of a power plant, it’s necessary to consider an alarm and on line condition

monitoring issues. When there is knowledge of the relationships between the raw data and the

underlying phenomena within the plant item, typical intelligent system-based interpretation

algorithms can be implemented, such as fuzzy systems and data mining. But if these

information are not present, an alternative approach might be used. The health data is

captured without any underlying knowledge concerning the link between the data and their

relationship to physical and electrical phenomena within the plant item. This leads to the

requirement for dynamic and learning condition monitoring systems that are able to determine

the expected and normal plant behavior over time. This paper describes how multi-agent

system technology can be used as the underpinning platform for such condition monitoring

systems. This is demonstrated through a multi-agent anomaly detection system applied to a

power system.

Key-words: Power plant. Operation. Condition monitoring.

8

LISTA DE TABELAS

Tabela 1 - Descrição geral do documento ....................................................................... 72

Tabela 2 – Benefícios do produto .................................................................................... 73

Tabela 3 – Matérias de referência .................................................................................... 73

Tabela 4 – Definições e siglas .......................................................................................... 74

Tabela 5 – Interfaces de usuário ...................................................................................... 76

Tabela 6 – Modos de operação ........................................................................................ 76

Tabela 7 – Funções do produto ........................................................................................ 77

Tabela 8 – Usuários do sistema ........................................................................................ 77

Tabela 9 – Informações acerca dos usuários .................................................................... 77

Tabela 10 – Restrições do sistema ................................................................................... 77

Tabela 11 – Hipóteses de trabalho ................................................................................... 77

9

LISTA DE FIGURAS

Figura 1: Modelo de agente reativo ............................................................................. 24

Figura 2: Modelo de agente cognitivo ......................................................................... 25

Figura 3: Representação conceitual de um agente definido por Ferber ....................... 26

Figura 4: Modelo de agente definido por Bussmann e Demazeau .............................. 27

Figura 5: Modelo de agente definido por Hayes-Roth ................................................ 28

Figura 6: Modelo de agente ARCHON definido por Jennings e Wittig ...................... 29

Figura 7: Modelo de agente definido por Hägg e Ygge .............................................. 31

Figura 8: Modelo de agente largamente utilizado ....................................................... 32

Figura 9: Protocolo de Interação de Agente, mostrando as interações para o

protocolo Contract Net. ................................................................................

38

Figura 10: Exemplo de um diagrama de pacotes ........................................................... 40

Figura 11: Exemplo da especificação de um template............................................. 41

Figura 12: Formato básico para comunicação de agente ............................................... 43

Figura 13: Transmissão simultânea de mensagens ........................................................ 43

Figura 14: Múltiplas técnicas para representar comunicação simultânea entre agentes,

utilizando múltiplos papéis ...........................................................................

44

Figura 15: Um exemplo de um diagrama de colaboração mostrando uma interação

entre agentes com papéis múltiplos ..............................................................

45

Figura 16: Diagrama de seqüência ................................................................................. 46

Figura 17: Um diagrama de atividade baseado em um caso de uso do sistema de

monitoração...................................................................................................

47

Figura 18: Um diagrama de estados indicando os estados e transições de uma conta

corrente .........................................................................................................

48

Figura 19: Um diagrama de atividade que especifica e ordena o comportamento do

processo para um agente ..............................................................................

49

Figura 20: Diagrama de estados que especifica processo interno do agente unidade

móvel ............................................................................................................

50

Figura 21: Modelos de sistemas ponto-a-ponto ............................................................. 53

Figura 22: Modelo de comunicação e relacionamentos ................................................ 55

Figura 23: Arquitetura global ........................................................................................ 60

Figura 24: Unidade geradora UGH1, na Casa de Força da 1ª Etapa da UHE de

Tucuruí .........................................................................................................

61

Figura 25: Diagrama simplificado da ponte retificadora tiristorizada ........................... 62

Figura 26(a): Armários de Tiristores da ponte retificadora .......................................... 63

10

Figura 26(b): Ventilador Exaustor do armário de Tiristores da ponte retificadora A ........ 63

Figura 26(c): Detalhe da gaveta de tiristores de um dos braços de condução da ponte

retificadora A ..........................................................................................

63

Figura 26(d): Sistema trocador de calor da ponte retificadora A .................................. 63

Figura 27: Diagrama esquemático ilustrando o subsistema de retificação em um dos

armários da ponte de tiristores do sistema de excitação de campo ..............

64

Figura 28: Sistemas de Escovas e de Anéis deslizantes, para aplicação da corrente

produzida pela ponte retificadora ao enrolamento de campo da máquina

síncrona ........................................................................................................

65

Figura 29: Quadro de sinalização de defeitos em um dos armários da ponte

retificadora ...................................................................................................

66

Figura 30: Sistema de aquisição dos sinais provenientes dos armários de tiristores ..... 68

Figura 31: Diagrama esquemático do sistema de aquisição de dados, incluindo a

medição remota do desgaste das escovas do gerador ...................................

69

Figura 32: Sistema de aquisição intermediária em Labview .......................................... 69

Figura 33: Diagrama do Sistema para Testes ................................................................ 71

Figura 34: Diagrama de contexto ................................................................................... 75

Figura 35: Interfaces do usuário .................................................................................... 79

Figura 36: Arquitetura do sistema multi-agente (sma) .................................................. 79

Figura 37: Estrutura de casos de uso ............................................................................. 82

Figura 38: Caso de uso orientado ao operador .............................................................. 83

Figura 39: Caso de uso orientado ao administrador ...................................................... 84

Figura 40: Diagrama de atividade – Inicializar sistema ................................................ 85

Figura 41: Diagrama de atividade – Agente supervisor ................................................ 86

Figura 42: Diagrama de atividade – Disparar comportamento alarme .......................... 87

Figura 43: Diagrama de atividade – Conectar ............................................................... 88

Figura 44: Diagrama de atividade – Enviar requisição .................................................. 89

Figura 45: Diagrama de atividade – Agente de banco de dados .................................... 90

Figura 46: Diagrama de atividade – Agente de banco de dados / Agente de aquisição .. 91

Figura 47: Diagrama de atividade – Agente de banco de dados / Agentes de detecção .. 91

Figura 48: Diagrama de atividade – Agente de banco de dados / agentes de

monitoração ..................................................................................................

92

Figura 49: Diagrama de atividade – Finalizar sistema .................................................. 93

Figura 50: Diagrama de atividade – Monitoração específica ........................................ 93

Figura 51: Diagrama de atividade – Monitoração em tempo real individual ................ 94

Figura 52: Diagrama de atividade – Iniciar Monitoração individual ............................. 95

11

Figura 53: Diagrama de atividade – Monitoração geral ................................................ 96

Figura 54: Diagrama de atividade – Iniciar monitoração geral ..................................... 96

Figura 55: Diagrama de atividade – Habilitar alarmes instantâneos ............................. 97

Figura 56: Diagrama de atividade – Agentes de detecção ............................................. 98

Figura 57: Diagrama de seqüência – Aquisição ............................................................ 99

Figura 58: Diagrama de seqüência – Detecção de anomalias ........................................ 100

Figura 59: Diagrama de seqüência – Monitoração ........................................................ 101

Figura 60: Autenticação inicial ...................................................................................... 103

Figura 61: Interface principal – operação ...................................................................... 104

Figura 62: Interface principal – administração .............................................................. 105

Figura 63: Monitoração individual – passo 1 ................................................................ 106




Figura 67: Monitoração geral – passo 1 ......................................................................... 108

Figura 68: Monitoração geral – passo 2 ......................................................................... 108

Figura 69: Alarme instantâneo ...................................................................................... 109

Figura 70: Desabilitar Alarmes instantâneos ................................................................. 109

Figura 71: RMA (Remote Management Agent) ............................................................. 110

Figura 72: SNIFFER ...................................................................................................... 111

Figura 73: Administração do sistema – Tela principal .................................................. 112

Figura 74: Cadastro de máquinas – passo 2 ................................................................... 112

Figura 75: Cadastro de máquinas – passo 3 ................................................................... 112

Figura 76: Atualização de máquinas – passo 1 .............................................................. 113

Figura 77: Atualização de máquinas – passo 2 .............................................................. 113

Figura 78: Exclusão de máquinas – passo 1 .................................................................. 114

Figura 79: Exclusão de máquinas – passo 2 .................................................................. 114

Figura 80: Cadastro de usuários – passo 1 .................................................................... 115

Figura 81: Cadastro de usuários – passo 2 .................................................................... 115

Figura 82: Atualização de usuários – passo 1 ................................................................ 116

Figura 83: Atualização de usuários – passo 2 ................................................................ 116

Figura 84: Exclusão de usuários – passo 1 .................................................................... 117

Figura 85: Exclusão de usuários – passo 2 .................................................................... 117

12

SUMÁRIO

1 INTRODUÇÃO ........................................................................................................... 15

1.1 DISPOSIÇÕES DO TRABALHO ............................................................................. 16

2 CONCEITOS FUNDAMENTAIS SOBRE A TEORIA DE AGENTES 18

2.1 CARACTERÍSTICAS DE UM AGENTE ................................................................ 19

2.2 SISTEMAS ABERTOS ............................................................................................. 20

2.3 SISTEMAS MULTI-AGENTE ................................................................................. 22

2.4 ARQUITETURA REATIVA PARA AGENTES ...................................................... 23

2.5 ARQUITETURA COGNITIVA PARA AGENTES ................................................. 25

2.6 MODELO DE AGENTE ........................................................................................... 26

2.6.1 Representação conceitual de um agente .............................................................. 26

2.6.2 Interação via troca de mensagens ........................................................................ 29

2.6.3 Componentes do modelo de um agente ............................................................... 32

3 ENGENHARIA DE SOFTWARE APLICADA AO DESENVOLVIMENTO DE

AGENTES ....................................................................................................................

34

3.1 METODOLOGIAS .................................................................................................... 34

3.1.1 UML ....................................................................................................................... 35

3.1.2 AUML .................................................................................................................... 37

3.2 UTILIZAÇÃO DE PADRÕES – NÍVEL 1 .............................................................. 39

3.2.1 Pacotes .................................................................................................................... 40

3.2.2 Templates ................................................................................................................ 41

3.3 INTERAÇÕES ENTRE AGENTES – NÍVEL 2 ....................................................... 42

3.3.1 Diagramas de Seqüência ....................................................................................... 42

3.3.2 Diagramas de Colaboração .................................................................................. 45

3.3.3 Diagramas de atividades ....................................................................................... 46

3.3.4 Diagrama de Estados ............................................................................................ 47

3.4 REPRESENTAÇÃO DE PROCESSOS INTERNOS DE AGENTES – NÍVEL 3....... 48

3.4.1 Diagramas de atividade ........................................................................................ 48

3.4.2 Diagramas de estado ............................................................................................. 49

4 AMBIENTE PARA DESENVOLVIMENTO DE AGENTES (JADE) ................. 51

4.1 INTRODUÇÃO ......................................................................................................... 51

4.2 JADE EM TERMOS GERAIS .................................................................................. 51

13

4.3 REFERÊNCIAS TECNOLÓGICAS ......................................................................... 51

4.3.1 O modelo ponto-a-ponto ....................................................................................... 51

4.3.2 O paradigma de agentes ....................................................................................... 53

4.4 O JADE EM TERMOS ESPECÍFICOS .................................................................... 56

4.4.1 O modelo de arquitetura ...................................................................................... 56

4.4.2 O modelo funcional ............................................................................................... 57

5 DESENVOLVIMENTO DE UM SISTEMA BASEADO EM AGENTES PARA

MONITORAÇÃO E DETECÇÃO DE FALTAS EM UM GERADOR ................

59

5.1 INTRODUÇÃO ......................................................................................................... 59

5.2 ARQUITETURA GLOBAL DO SISTEMA ............................................................. 60

5.2.1 Aquisição primária ............................................................................................... 60

5.2.2 Aquisição secundária ............................................................................................ 60

5.2.3 Monitoração e detecção ........................................................................................ 61

5.3 CARACTERÍSTICAS DO SISTEMA A SER MONITORADO: sistema de excita-

ção de campo da unidade hidrogeradora UGH1 ........................................................

61

5.3.1 Descrição dos subsistemas que compõem o sistema de excitação de campo,

com suas respectivas funções ...............................................................................

62

5.3.2 Sistema de alarmes e de tratamento de defeitos em cada armário da ponte

de titistores .............................................................................................................

66

5.4 PROJETO E DESENVOLVIMENTO DO SISTEMA DE AQUISIÇÃO DE

DADOS ......................................................................................................................

67

5.4.1 Configuração e arquitetura do sistema de aquisição de dados e monito-

ramento ..................................................................................................................

68

5.5 DESENVOLVIMENTO E IMPLEMENTAÇÃO DO SOFTWARE DO SISTEMA

DE MONITORAMENTO BASEADO EM AGENTES ...........................................

70

5.6 ANÁLISE E PROJETO DO SISTEMA BASEADO EM AGENTES INTELI-

GENTES ....................................................................................................................

71

5.6.1 Visão geral do Sistema .......................................................................................... 71

5.6.2 Levantamento de requisitos ................................................................................. 72

5.6.3 Arquitetura do Sistema Multi-agente (SMA) ..................................................... 79

5.6.4 Modelagem UML do Sistema Multi-agente (SMA) ........................................... 81

6 RESULTADOS OBTIDOS ........................................................................................ 103

6.1 DESCRIÇÃO DAS FUNCIONALIDADES DO SISTEMA .................................... 103

14

6.2 APRESENTAÇÃO INICIAL DO SISTEMA ........................................................... 103

6.3 FUNCIONALIDADES DO SISTEMA ..................................................................... 105

6.3.1 Monitoração on-line e individual de variáveis do sistema ................................. 106

6.3.2 Monitoração do Quadro geral das 5 variáveis de interesse do projeto pelo

Sistema. (Temperaturas dos 4 Armários e o desgaste das escovas) .................

108

6.3.3 Alarmes instantâneos ............................................................................................ 109

6.3.4 Monitorar Agentes (RMA) ................................................................................... 110

6.4 FUNCIONALIDADES ADMINISTRATIVAS ........................................................ 111

6.4.1 Cadastro e alteração de máquinas ....................................................................... 111

6.4.2 Exclusão de Máquinas .......................................................................................... 113

6.4.3 Cadastro e alteração de Armários, Tiristores e variáveis ................................. 114

6.4.4 Cadastro e Alteração de Usuários ....................................................................... 114

7 CONSIDERAÇÕES FINAIS ..................................................................................... 118

REFERÊNCIAS ............................................................................................................. 119

APÊNDICE ..................................................................................................................... 121

15

1 INTRODUÇÃO

O emprego de técnicas computacionais em auxílio ao monitoramento e alarme de

faltas em sistemas elétricos pode trazer benefícios tangíveis para as empresas do setor

elétrico, os quais podem ser expressos pela qualidade de operação da planta. No caso

específico de usinas de geração de energia elétrica, isto significa em reduções no tempo de

paradas não-programadas, ampliando-se, dessa forma, a disponibilidade das unidades

geradoras. Dessa forma, o retorno econômico do investimento realizado em pesquisa e

desenvolvimento neste campo poderá ser estimado quando se compara o custo da pesquisa

com os elevados prejuízos que poderiam advir da indisponibilidade temporária (ou

permanente) de uma unidade geradora, ocasionada por falha destrutiva que evoluiu a partir de

faltas incipientes que não foram percebidas pelos operadores pela falta de um sistema

automático de monitoramento e alarme de faltas.

Este tipo de problema ocorre principalmente devido à operação do equipamento sob

condição de intenso estresse, provocando, dessa forma, paradas que não foram programadas

antecipadamente. Com o uso de avançadas técnicas de monitoramento, as paradas não

programadas podem ser evitadas (ou pelo menos previstas) se os equipamentos estiverem

equipados com sistemas de monitoramento eficientes, capazes de informar precocemente a

ocorrência e evolução incipiente de faltas na operação dos equipamentos do sistema,

contribuindo assim para o aumento da disponibilidade das unidades e da confiabilidade da

planta.

Os modernos sistemas elétricos de potência devem atender a elevados índices de

desempenho e qualidade de operação, sendo a disponibilidade do serviço um dos mais

importantes índices de desempenho e de qualidade da operação. Para atender a esses critérios,

os sistemas estão se tornando cada vez mais complexos, pois além dos sistemas

eletromecânicos que naturalmente já compõem a planta propriamente dita, os sistemas de

potência modernos incorporam também avançadas e sofisticadas técnicas de automação e de

controle digital, realizando o processamento e análise de um elevado número de grandezas

medidas na planta, incluindo: temperatura, pressão, e grandezas elétricas diversas.

Assim sendo, com a elevada complexidade e a exigência de operação cada vez mais

rígidas, os sistemas de monitoramento modernos devem possuir um certo grau de autonomia e

de inteligência, em relação a tarefas que podem ser automatizadas, liberando o operador para

tarefas de mais elevado grau no sistema. Além disso, o sistema deve ainda assistir o operador,

16

realizando a detecção automática de faltas e auxiliando o operador no diagnóstico das

condições do sistema, sugerindo as melhores ações a serem executadas em cada caso.

Neste sentido, o debate acerca de técnicas de monitoração vem crescendo cada vez

mais, uma vez que as indústrias percebem o quanto o conhecimento sobre a “saúde” das

máquinas permite uma melhora significativa em relação à operação e manutenção dessas

máquinas. As técnicas atuais mais utilizadas são as ditas inteligentes, como lógica fuzzy e

mineração de dados. A primeira se aplica a casos onde se têm informações acerca da relação

entre os dados da planta e o fenômenos observados, de forma que seja possível classificar os

dados monitorados em classes especificas e fornecer informações mais inteligíveis aos

operadores. A segunda se aplica a situações em que existe uma massa de dados disponível

para que se possa encontrar relações entre os dados, de forma a identificar e classificar os

fenômenos de acordo com os dados de entrada. Entretanto, existem sistemas que podem ser

implementados com um conjunto reduzido de informações sobre o sistema como um todo.

Este trabalho, bem como os trabalhos de (STEPHEN; CAMPBELL, MCDONALD;

MCFADYEN), se enquadra exatamente e tão-somente nessa categoria e tem como objetivos

principais detectar anomalias em uma planta industrial de potência a partir de parâmetros pré-

concebidos em um sistema multi-agente, e agrupar uma massa de dados para que futuramente

um trabalho de mineração possa ser feito e com isso se tenha informações mais precisas

acerca da relação entre dados e fenômenos por eles causados.

1.1 ORGANIZAÇÃO DO TRABALHO

O capítulo 2 aborda os conceitos de sistemas baseados em agentes que são utilizados

neste trabalho. As características dos agentes, suas principais funcionalidades e a maneira de

como eles trabalham a partir de seus objetivos. Algumas arquiteturas interessantes de agentes

também são mostradas e uma análise acerca de sistemas multi-agente também é feita.

O capítulo 3 faz uma análise da engenharia de software aplicada a sistemas multi-

agente. Nesse capítulo são mostradas as principais técnicas de engenharia de software, mais

especificamente de linguagem de modelagem uml, aplicadas à tecnologia de agentes.

Mais adiante, no capítulo 4, é feita uma abordagem acerca do framework de

desenvolvimento de agentes: JADE. As principais características dessa importante ferramenta

são mostradas e analisadas. Conceitos como os de plataforma e cointainer são explicados de

17

forma a garantir um melhor entendimento acerca do funcionamento prático de um sistema

multi-agente.

Nos capítulos 5 e 6 é onde estão as principais contribuições deste trabalho. No capítulo

5 é detalhada toda a problemática acerca de um sistema de monitoração e detecção de faltas e

a forma proposta para uma solução baseada em agentes. Primeiramente é feita uma análise

acerca da planta industrial e após isso as soluções adotadas são abordadas. É feita uma análise

global e outra mais detalhada contendo os diagramas uml que detalham o funcionamento dos

agentes do sistema.

O capítulo 6 apresenta e discute os resultados obtidos com o sistema multi-agente em

testes realizados em laboratório. As interfaces gráficas em funcionamento são exibidas para

que se tenha uma perfeita noção acerca da aplicação prática do sistema. Esse capítulo

funciona inclusive como um tutorial de utilização do sistema dentro do contexto de

monitoração e detecção de faltas.

Por fim, tem-se o capítulo 7, que faz uma conclusão do trabalho, mostrando em linhas

gerais o que foi realizado e os objetivos que foram alcançados, além de possíveis trabalhos

futuros a partir do que já foi produzido.

18

2 CONCEITOS FUNDAMENTAIS SOBRE A TEORIA DE AGENTES

Um dos ramos da inteligência computacional estuda sociedades de agentes de software

para trabalhar em conjunto na solução de problemas de natureza distribuída, ou seja,

problemas complexos que não podem ser resolvidos por um único programa. Ainda não há na

literatura especializada uma única definição amplamente aceita para o conceito de agente. Na

literatura encontram-se conceitos distintos dependendo da especialidade do autor. Contudo,

tais definições não são antagônicas. Elas colaboram mutuamente para um entendimento mais

amplo da concepção de um agente. Um agente é um software persistente que permite a

interoperabilidade entre sistemas computacionais de organizações distintas. Tipicamente

devem possuir capacidade adaptativa entre os ambientes heterogêneos das organizações,

caracterizando a necessidade de sistemas abertos (GENESERETH; KETCHPEL, 1994).

De acordo com Smith et al. (1994), um Agente é uma entidade de software persistente

dedicada a um propósito específico. A capacidade de persistência do software distingue

agentes de sub-rotinas: um agente tem suas próprias concepções de como efetuar tarefas,

percepção das condições dinâmicas do ambiente, ação para modificar as condições no

ambiente e raciocínio para interpretar percepções, resolver problemas, fazer inferências e

determinar ações, ou seja, um agente pode agir sobre ele mesmo ou sobre o ambiente.

Um agente pode agir autonomamente, de maneira racional ou intencional, para

cumprir um conjunto de objetivos. Um agente de interface, por exemplo, pode ser definido

como um personagem desempenhado pelo computador para representar o usuário em um

ambiente virtual. Ao "pensar" e comunicar comportamentos, os agentes de interfaces

baseiam-se em metáforas de organismos vivos em termos de acessibilidade cognitiva e estilo

de comunicação (LAUREL, 1990; SYCARA et al., 1996; MAES, 1994b). Um agente ainda

pode ser mantenedor de informações ou responsável por tarefas simples, cujo principal intuito

é a filtragem da informação para reduzir a sobrecarga cognitiva do usuário (WOOLDRIDGE;

JENNINGS, 1995; MAES, 1994a; MITCHELL et al, 1994). Na comunidade de inteligência

artificial, os agentes são constantemente entendidos como entidades autônomas.

Segundo (RUSSEL; NORVIG, 1995; FRANKLIN; GRAESSER, 1997; MAES, 1995)

um agente pode ser visto como algo que observa o ambiente através de sensores e age nesse

ambiente através de atuadores, compondo sistemas computacionais que habitam algum

ambiente dinâmico complexo, percebem e agem de forma autônoma nesse ambiente e,

fazendo isto, realizam um conjunto de metas e tarefas para as quais foram projetados. Estes

19

agentes percebem o ambiente que estão inseridos e atuam continuamente para atender a seus

objetivos.

Olhando para o contexto da inteligência artificial, pode-se afirmar que a inteligência

artificial distribuída baseia-se no comportamento social, considerando sociedades de agentes

inteligentes, autônomas e dotadas de capacidades cognitivas. Os agentes especialistas nas

atividades que desempenham não trabalham isolados. De forma cooperativa eles tentam

resolver um problema da melhor forma possível, caracterizando uma área da inteligência

artificial distribuída, denominada sistemas multi-agente (DEMAZEAU, 1995).

Partindo deste pressuposto, começa-se a colocar a visão do agente como parte de um

contexto. Wayer e Cheong (1995) afirmam que um agente encontra-se imerso em uma

sociedade de agentes. Nesta sociedade, a interação e a coordenação das metas e dos planos de

ações destes agentes têm como objetivo a resolução cooperativa de uma determinada tarefa.

2.1 CARACTERÍSTICAS DE UM AGENTE

Um agente possui um conjunto de propriedades que ajudam em sua interação com o

ambiente em que está inserido. Desta forma, um agente pode ser ainda um sistema

computacional com habilidade de autonomia, capacidade social, reatividade e pró-atividade

(WOOLDRIDGE; JENNINGS, 1995). As propriedades ou habilidades dos agentes

diferenciam a atuação de um agente com relação a outro. Abaixo estão apresentadas algumas

das características que poderão ser encontradas em um agente:

Reatividade: propriedade que permite que os agentes percebam seu ambiente e responda

adequadamente às mudanças nele ocorrida. O ambiente aqui referido pode ser o mundo

físico, uma interface gráfica, uma coleção de outros agentes, a Internet ou ainda um

contexto que pode ser definido com a combinação de mais de um desses elementos.

Autonomia: capacidade de tomar iniciativa e ter um controle sobre as suas próprias ações

ou ainda a capacidade de tomar ações para realizar algumas tarefas e objetivos, sem a

interferência do usuário final. Deve haver um elemento de independência no agente, ou

seja, os agentes operam sem a intervenção direta de seres humanos ou outros agentes.

Habilidade social: habilidade que os agentes possuem de interagir com os outros agentes

ou pessoas no momento adequado, para concluir suas tarefas ou ajudar outros agentes.

20

Confiabilidade: Os agentes devem demonstrar “veracidade” e “benevolência”, ou seja, os

usuários precisam ter certeza de que os agentes serão confiáveis nas ações e informações e

que irão agir em seu benefício.

Comportamento adaptativo: Capacidade do agente de modificar seu comportamento em

função de experiências anteriores. Um agente deve possuir capacidade para executar uma

tarefa com maior eficiência do que em execuções anteriores.

Mobilidade: Capacidade do agente de transportar-se de uma máquina à outra, ou ainda,

habilidade do agente movimentar-se em uma rede.

Flexibilidade: Habilidade dos agentes de escolher dinamicamente as ações e a seqüência

de execução das mesmas, em resposta a um estado do ambiente.

Comunicabilidade: Capacidade dos agentes de comunicar através de troca de mensagens

em uma expressiva e específica linguagem para conversação

Pró-atividade: Capacidade manifestada pelo agente de exibir um comportamento

direcionado a objetivos. Desta forma, o agente não age simplesmente em resposta ao

ambiente, mas de acordo com um propósito. Para tanto, deve exibir um comportamento

oportunista, voltado para a realização de seus objetivos.

Racionalidade: Os agentes devem ter racionalidade para agir de forma lógica. A

capacidade de raciocínio é talvez o aspecto mais importante que distingue um agente

inteligente dos outros agentes. Dizer que um agente inteligente tem raciocínio significa

dizer que ele tem a habilidade de inferir e extrapolar, baseado no conhecimento atual e nas

experiências, de uma maneira racional e reprodutível.

Um agente não deve necessariamente possuir todas as habilidades descritas. As

habilidades do agente dependerão do contexto a que o mesmo está inserido e do papel que está

representando. Um agente sempre estará interagindo com o meio externo. Desta forma, o agente

deverá estar inserido em um contexto previamente definido, onde a troca de dados, informações

ou conhecimento ocorram através de um protocolo conhecido (PARAISO, 1996).

2.2 SISTEMAS ABERTOS

A integração dinâmica de agentes implica na capacidade de aprendizagem do agente sobre

tarefas em que estão envolvidos. Este conceito é usado em várias áreas da ciência da computação:

21

a) interconexão entre arquiteturas de diferentes máquinas (modelo OSI);

b) ligação dinâmica entre cliente e servidor (modelo CORBA);

c) reconfiguração dinâmica e seleção mútua (modelo Contract-Net) e

d) integração dinâmica de um agente em um contexto de trabalho (modelo

agente). A complexidade e a dinâmica dos sistemas levam a uma nova situação

onde saber como projetar sistemas computacionais eficientes, confiáveis e

corretos não é mais suficiente (FERBER, 1995, p. 87).

Ferber (1995) argumenta que os novos softwares devem facilitar adaptações, em

particular às mudanças no contexto do trabalho, tais como:

a) mudança do sistema operacional;

b) mudança do sistema gerenciador de banco de dados;

c) mudança da interface gráfica e

d) inserção de um novo software.

O novo sistema computacional deve ter capacidade que envolva situações como:

a) inclusão de novas funcionalidades;

b) alteração do modo de funcionamento do software;

c) integração do novo software. Neste sentido, pode-se dizer que sistemas abertos são

fortemente adaptativos.

Sistemas multi-agentes são candidatos promissores para implementação de

arquiteturas distribuídas, heterogêneas, flexíveis e abertas, capazes de oferecer uma grande

quantidade de serviço em ambientes de trabalho coletivo sem uma estrutura prévia definida.

Os sistemas multi-agentes podem ser classificados de acordo com a arquitetura, o grau de

autonomia de cada agente e o tipo de protocolo usado para comunicação, alem da sua

complexidade. A principal distinção está relacionada aos agentes autônomos. Os agentes

reativos são muito simples sem qualquer representação do seu ambiente. Eles interagem com

um tipo de comportamento estímulo-resposta (FERBER; DROGOUL, 1992). Assim,

comportamentos inteligentes podem emergir de uma população de numerosos agentes

(BROOKS, 1991; SCALABRIN, 1996; BEER, 1992; DEMAZEAU, 1990;

CASTELFRANCHI, 1990; WOOLDRIDGE; JENNINGS, 1994).

Uma condição essencial para o desenvolvimento de um sistema aberto é que o ambiente

permita gerir a adição e a supressão de um agente de uma aplicação sem a necessidade de parar e

reinicializar o sistema. Porque, quando um novo serviço é adicionado, a necessidade de

recompilar todos os programas em todas as máquinas da rede é claramente inaceitável.

Um ponto comum entre todas as arquiteturas baseadas no modelo cliente-servidor é a

presença de uma entidade mediadora entre o requisitante e o fornecedor de um serviço. As

abordagens se distinguem pelo nível de conhecimentos modelados sobre os objetos servidores

22

ou agentes de serviços. Em certos casos, essas entidades intermediárias recobrem

perfeitamente a noção de agente autônomo. Com relação ao modelo cliente-servidor, o

modelo de coordenação para agentes assíncronos é mais complexo. Porque os agentes são:

de um lado independentes para levar em conta ou rejeitar uma solicitação e,

de outro, obrigados (eles mesmos) a gerir as interações com os outros agentes

fornecedores de serviços. Os agentes autônomos utilizam o serviço de uma entidade

intermediária somente para o transporte das mensagens, sendo eles mesmos os próprios

responsáveis pela negociação de um serviço e pela gestão de suas relações com os demais

agentes (SCALABRIN, 1996).

2.3 SISTEMAS MULTI-AGENTE

A área de sistemas multi-agente estuda o comportamento de um grupo organizado de

agentes autônomos que cooperam na resolução de problemas que vão além das capacidades

de resolução de cada um individualmente (DURFEE et al., 1994). Duas propriedades,

aparentemente contraditórias, são fundamentais para os sistemas multi-agente: a autonomia

dos agentes e sua organização. Conforme já mencionado neste trabalho, o termo autônomo

significa a capacidade de tomar iniciativa e ter um controle sobre as suas próprias ações ou

ainda a capacidade de tomar ações para realizar algumas tarefas e objetivos, ou seja, para

funcionar, um agente não precisa de outros agentes, mesmo que para alcançar seus objetivos

ele eventualmente precise da ajuda de outros. Por outro lado, a organização coloca restrições

aos comportamentos dos agentes, procurando estabelecer um comportamento de grupo coeso

(JENNINGS; WOOLDRIDGE, 1998; WOOLDRIDGE, 2002).

Um sistema multi-agente surge em um cenário de entidades diversificadas onde cada

uma possui uma tarefa dedicada, ou seja, a necessidade de cumprir seus objetivos é suficiente

para tomar boa parte de seu tempo e processamento. Dada esta situação, a abordagem

destinada ao sistema multi-agente traz as seguintes características:

os agentes são concebidos independentemente de um problema particular;

a interação entre os agentes não é projetada anteriormente, busca-se definir

protocolos que possam ser utilizados em situações genéricas;

a decomposição de tarefas para solucionar um dado problema pode ser feita pelos

próprios agentes;

não existe um controle centralizado da resolução de um problema (HUBNER,

2003, p. 54).

23

As propriedades dos sistemas multi-agente apresentam algumas vantagens:

viabilizar sistemas adaptativos e evolutivos: um sistema multi-agente tem capacidade de

adaptação a novas situações, tanto pela eliminação e/ou pela inclusão de novos agentes ao

sistema quanto pela mudança da sua organização (HUBNER, 2003).

modelar sistemas complexos e distribuídos: em muitas situações, o conhecimento está

distribuído, o controle é distribuído, os recursos estão distribuídos. E, quanto à

modelagem do sistema, a decomposição de um problema e a atribuição dos sub-problemas

a agentes permite um alto nível de abstração e independência entre as partes do sistema

(JENNINGS; WOOLDRIDGE, 1998);

tirar proveito de ambientes heterogêneos e distribuídos: agentes com arquiteturas

diferentes, que funcionam em plataformas diferentes, distribuídas em uma rede de

computadores, podem cooperar na resolução de problemas. Isto permite o uso das

potencialidades particulares de cada arquitetura e, pela distribuição, melhora o

desempenho do sistema;

permitir a concepção de sistemas abertos: os agentes podem migrar entre sociedades, isto

é, agentes podem sair e entrar em sociedades, mesmo que desenvolvidos por projetistas e

objetivos distintos.

2.4 ARQUITETURA REATIVA PARA AGENTES

O modelo reativo não apresenta pré-definições, não apresenta nenhum modelo interno

do mundo exterior, possui apenas mapeamentos de situações e respectivas respostas

associadas, responde ao que lhe é questionado através de conhecimento obtido pelas situações

que já vivenciou e não usa argumentos simbólicos complexos. Assim, quando uma mudança

no ambiente ocorre, o agente executa a ação correspondente (FRANKLIN; GRAESSER,

1997; HEILMANN, 1995; RUSSEL; NORVIG, 1995; HOLLAND, 1975).

Os sistemas de agentes reativos são constituídos por um grande número de agentes,

bastante simples, sem inteligência e sem representação de seu ambiente. Eles podem modelar,

por exemplo, uma sociedade de formigas, ou ainda os clientes e os servidores na abordagem

OMG CORBA. Estes agentes são fortemente acoplados. Eles interagem utilizando um

comportamento do tipo estímulo/resposta (FERBER; DROGOUL, 1992).

24

Um comportamento inteligente emerge a partir das interações entre esses agentes e seu

ambiente (MINSKY, 1986). Ou seja, os agentes não são individualmente inteligentes, mas seu

comportamento global é inteligente.

Na figura 1 é apresentada a arquitetura definida por Russel e Norvig (1995) para o

modelo reativo de agente. A percepção do ambiente e um conjunto de regras são o que

determinam o comportamento de um agente. Um agente reativo por definição percebe um

estímulo e executa uma tarefa, pelo fato que a primeira é responsável pela ação do agente para

resolver à segunda. Neste caso, o agente normalmente age por ter recebido no ambiente uma

interação que o fez agir de tal maneira.

Figura 1: Modelo de agente reativo.

Fonte: Russel; Norvig (1995)

Na literatura, as aplicações mais freqüentes ainda são na área de robótica. Por

exemplo, o comportamento complexo de um robô pode ser decomposto em comportamentos

individuais simples. Esses comportamentos são colocados em contato com o mundo real; o

robô capta continuamente informações sobre o ambiente que o cerca. Deste modo, o robô faz

parte do ambiente e reage baseado em um comportamento simples, ditado pelos

estímulos/respostas que recebe (SCALABRIN, 1996). Dentre os trabalhos sobre os agentes

reativos, pode-se citar Brooks (1986), que realizou os primeiros estudos sobre os agentes

reativos, onde, a idéia central é que a concepção de um robô inteligente e autônomo recai na

criação de um conjunto de camadas que agem como pequenos robôs reativos. Ferber e

Jacopin (1990), Ferber e Drogoul (1992) utilizam a eco resolução, uma abordagem particular

de resolução distribuída de problemas. Eles consideram que a resolução distribuída de um

problema é uma série de interações bastante simples dentro de uma população de agentes. A

solução do problema emerge das interações entre os agentes. Steels (1989) tentou resolver o

problema da coleta de minério por robôs em ambiente desconhecido.

25

2.5 ARQUITETURA COGNITIVA PARA AGENTES

Também chamados de agentes cognitivos, estes agentes possuem um modelo do

mundo, que possivelmente os inclui também. Este modelo é de certa forma pré-concebido,

porém seu estado pode ser alterado através da comunicação com os demais agentes da rede e

através da percepção do ambiente realizada pelos sensores do agente. O agente estima que

ações serão necessárias para alcançar um determinado objetivo através da interpretação deste

modelo, e então executa ações que levarão à sua realização. (FRANKLIN; GRAESSER,

1997; HEILMANN, 1995; RUSSEL; NORVIG, 1995).

Figura 2: Modelo de agente cognitivo.

Fonte: Beer (1992).

Em Hubner (2003) encontra-se o modelo cognitivo, que apresenta na figura 2 a

arquitetura proposta por Beer, (1992): o conhecimento que o agente possui é formado a partir

da sua percepção do ambiente e da comunicação com outros agentes, ou seja, o conhecimento

é atribuído ao agente através de seus relacionamentos, seja com o ambiente ou com os demais

agentes da rede. Dado este conhecimento e uma meta, o agente gera um conjunto de possíveis

planos que atingem esta meta. Desta forma, o agente utiliza o conhecimento para rotear as

possíveis soluções para o problema que o mesmo foi incumbido de resolver. Dadas estas

possibilidades ou soluções, o agente analisa qual a melhor solução a ser executada. Neste

caso, pode-se afirmar que o agente tomou uma determinada ação porque esta ação faz parte

do processo que leva o agente a cumprir uma determinada tarefa. Obviamente, esta diferença

entre as arquiteturas somente pode ser percebida olhando-se “dentro” dos agentes. Somente

26

pela observação do comportamento externo não se pode dizer se um agente é reativo ou

cognitivo.

2.6 MODELO DE AGENTE

2.6.1 Representação conceitual de um agente

A figura 3 mostra as principais propriedades que devem existir em um agente

(percepção, comunicação, ações, etc.). Todavia, a maior parte dos modelos encontrados na

literatura são modelos que utilizam a percepção e a ação para as atividades de interações ou a

comunicação direta entre os agentes.

Figura 3: Representação conceitual de um agente definido por Ferber.

Fonte: Ferber (1995).

Uma importante classe de sistemas computacionais é conhecida como agentes

inteligentes, cujas tarefas requerem uma interação com as entidades dinâmicas do ambiente e

um raciocínio baseado em conhecimentos. Esse tipo de agente executa tarefas complexas.

Essas tarefas existem em vários domínios: controle de processos, monitoramento de

27

tratamentos intensivos, dentre outros. As pesquisas privilegiaram as comunicações indiretas

(através do ambiente) entre os agentes.

A busca pela criação de agentes autônomos capazes de viver em um ambiente real

requer a construção de modelos bastante complexos de interações com o ambiente (percepção,

cognição, ação). As Figura 4 e 5 mostram dois modelos de agentes que foram especificamente

desenvolvidos para tais situações. Nestes modelos, os conhecimentos representados são

essencialmente:

os estados mentais internos de um agente (planos, ações); e

o ambiente.

Os mecanismos implementados são:

o raciocínio ou a inferência;

o planejamento;

a execução de um plano;

a integração de um novo evento no mecanismo de raciocínio; e

a adaptação do plano.

Figura 4: Modelo de agente definido por Bussmann e Demazeau.

Fonte: Bussmann e Demazeau (1994).

28

Figura 5: Modelo de agente definido por Hayes-Roth.

Fonte: Hayes-Roth (1990).

As Figuras 4 e 5 representam modelos de agentes que estabelecem a integração de

modelos reativos e cognitivos a fim de realizar sistemas do tipo percepção/cognição/ação.

Eles concernem à organização dos processos internos de um agente e especificam as

interações entre os modelos que, no contexto de uma implementação real, devem assegurar

um comportamento tanto reativo quando cognitivo.

A tarefa principal do modelo de um agente é descrever como os dados de entrada são

tratados a fim de produzir uma saída tal como: sensor de entrada e ações (Figura 4). Com esse

mesmo princípio, a percepção e a execução fazem referência ao processo necessário para

interagir com o ambiente. Na Figura 4, o núcleo do agente é o modelo do mundo, o qual

compreende conhecimentos sobre o ambiente, o estado mental dos outros agentes (não é dito

como o agente que recupera o estado mental dos outros), e seu próprio estado mental. Este

último inclui em particular os planos que devem ser executados. Finalmente, para assegurar a

reatividade do agente, um processo de avaliação examina de modo contínuo o modelo do

mundo, detectando assim as situações que um agente deve reagir, bem como avaliar e decidir

as ações a executar (SCALABRIN, 1996).

Pode-se observar que, mesmo nestes modelos específicos (a uma classe de problemas),

existem certas diferenças, uma delas é o encadeamento dos módulos no interior dos modelos.

Ou seja, o laço que leva em conta os eventos internos e externos, bem como a adaptação do

29

comportamento de um agente em função desses eventos não é a mesma. Na Figura 4, um

evento externo é levado em conta primeiramente pelo módulo executor e somente na

seqüência pelos módulos planejamento e programador, o que não é o caso na Figura 5.

2.6.2 Interação via troca de mensagens

Tome-se como ponto de partida o modelo da Figura 6, que representa o sistema

ARCHON descrito em Jennings e Wittig (1992). Este é um dos primeiros modelos de agentes

utilizado no meio industrial. Este modelo é interessante porque ele separa claramente a

aplicação do sistema de serviços que correspondem respectivamente aos blocos inferior e

superior da Figura 6.

O sistema de serviços corresponde ao conjunto de mecanismos da arquitetura que não faz

parte de nenhum domínio de aplicação. Ele fornece facilidades de comunicação, tais como:

o endereçamento de mensagens;

a filtragem; e

a difusão de informações dirigida por interesses (Publish/Subscribe).

Figura 6: Modelo de agente ARCHON definido por Jennings e Wittig.

Fonte: Jennings e Wittig (1992)

30

Foram incluídos também certos modelos de representação e de interação:

a representação de si próprio;

a representação dos demais agentes ("acquaintances"); e

a interação via protocolo cliente-servidor ou redes contratuais (Contract-Net).

A representação dos demais agentes contém modelos para efetuar a comunicação em

termos de competências e de interesses. Esses modelos são pré-requisitos para todas as

atividades de coordenação entre agentes. Os serviços de difusão de informações utilizam esses

modelos para encontrar os agentes interessados em um determinado resultado. Da mesma

maneira, o modelo de si próprio representa, de um modo abstrato, o domínio do agente ou da

aplicação. A aplicação contém, antes de tudo, informações sobre o estado corrente do sistema

(tarefas em execução). Ela encapsula também os planos pré-compilados para a parte reativa

do controle.

Esses planos são acessíveis pelo monitor, que é responsável pelo controle da aplicação

e das trocas de informações entre as partes. O subsistema de planejamento e coordenação

representa a principal parte reflexiva do sistema de serviços. Se uma exceção ocorre, é tarefa

desse subsistema raciocinar e encontrar uma solução. Sua influência sobre o monitor ocorre

principalmente através do comportamento armazenado no modelo de si. Este contém também

partes reativas a respeitar no momento da inicialização da cooperação. Por exemplo, o agente

detecta a necessidade de cooperação e determina qual tarefa ele deve confiar aos outros

agentes. Deve-se frisar que a seleção do protocolo de cooperação a utilizar é feita em função

da carga de trabalho do sistema de raciocínio. O processo é o mesmo quando um agente

recebe uma demanda de cooperação da parte de um outro agente (SCALABRIN, 1996).

A figura 7 ilustra uma arquitetura similar à arquitetura ARCHON, exceto que a

separação entre o sistema de serviços e a aplicação é realizada pelo módulo de comunicação.

No entanto, a modelagem inclui um conjunto de modelos bastante completo em relação às

outras arquiteturas. Ou seja, ela possui uma base de dados onde são armazenados:

estados internos;

representação externa;

metas (parecidas com "scripts");

biblioteca de planos; e

modelo de intenções.

31

Ela gerencia uma biblioteca de planos, os quais podem ser: privados, não privados e a

especificar o executor. Cada plano contém um campo onde é inserido o nome do executor do

plano. Assim, se o valor desse campo é:

self, trata-se de um plano privado;

uma constante (nome de um outro agente), trata-se de um plano não privado;

uma variável, trata-se de um plano em que se deve determinar o seu executor.

Figura 7: Modelo de agente definido por Hägg e Ygge.

Fonte: Hägg; Ygge (1994)

Como visto, um modelo de agente pode ser concebido com uma divisão operacional

de uma estrutura capaz de suportar uma base de conhecimento, uma camada de comunicação,

uma memória externa, uma memória interna e uma central de processamento. A maioria dos

modelos conhecidos, já citados anteriormente, utiliza uma divisão parecida, pois a

necessidade de operação de um agente é sempre a mesma. Ou seja, sempre um agente deverá

interpretar as mensagens que recebe e formatar as mensagens que envia, deverá processar as

solicitações recebidas pelas mensagens e consultando a uma base de conhecimentos, pois um

agente existe para uma determinada função e poderá armazenar informações sobre si mesmo e

informações sobre a rede ou sociedade em que está envolvido. Desta forma, todas as

propostas de arquitetura de agente não fogem muito deste modelo, pois o funcionamento de

um agente depende no mínimo destes quesitos.

O modelo de agente da Figura 8 é baseado nos modelos apresentados anteriormente e

traz o modelo escolhido para o desenvolvimento da maioria dos sistemas de agentes já

concebidos.

32

Figura 8: Modelo de agente largamente utilizado.

Fonte: Fonte: Hägg; Ygge (1994).

2.6.3 Componentes do modelo de um agente

Interface com o Usuário: Responsável pelo recebimento das solicitações do usuário.

Após a recepção, as solicitações devem ser encaminhadas ao módulo de processamento para,

depois, apresentar os resultados ao usuário. Uma de suas funcionalidades é prover meios que

permitam ao usuário atualizar os objetivos e os conhecimentos do agente.

Módulo de Processamento: Está constantemente ligado à base de conhecimento do agente.

É o módulo responsável por responder todas as solicitações da camada de comunicação e

da interface com o usuário. Dentro de seu trabalho está a necessidade de avaliar as

diferentes alternativas de solução e selecionar a melhor opção. Pode, com base nas

mensagens recebidas de outros agentes e através de sua capacidade de percepção das

variáveis ambientais, atualizar sua base de conhecimento. O comportamento reflete todos

os estados possíveis na interação entre agentes.

Objetivos: Todo agente possui um objetivo definido. Este objetivo traz a responsabilidade

que possui dentro da sociedade em que está envolvido.

Base de Conhecimentos: Todo conhecimento do agente está armazenado em sua base de

conhecimento. É de onde o módulo de processamento tirará apoio para apresentar as

soluções exigidas pela sociedade.

33

Módulo de Codificação e Decodificação de Mensagens: Todas as mensagens recebidas e

enviadas pelos agentes estarão em um determinado formato, dependendo de qual padrão

ou ferramenta de comunicação a rede está utilizando. Desta forma, o módulo de

codificação e decodificação de mensagens é o módulo responsável por receber e enviar as

mesmas dentro do padrão destinado. As mensagens são trocadas com os demais agentes

da rede.

Módulo de Percepção: Refere-se aos meios disponíveis para o agente monitorar variáveis

do ambiente.

Módulo de Comunicação: Encarrega-se de enviar e receber mensagens de outros agentes

mediante protocolos de transporte (p.e. na Internet, via TCP e HTTP). Este módulo pode

desenvolver-se mediante KAPI (KQML Application Programmer's Interface), que provê

uma interface abstrata entre os protocolos de transporte (TORRES; CONSTANTINO,

1996).

34

3 ENGENHARIA DE SOFTWARE APLICADA AO DESENVOLVIMENTO DE

AGENTES

Sistemas informatizados têm enorme potencial de trazer benefícios. Têm também

enorme potencial de trazer prejuízos, quando feitos de forma errada. O software é a alma dos

sistemas informatizados, e a engenharia de software é a disciplina que ensina a construir

produtos reais a partir dos conceitos fundamentais da informática.

Em relação a sistemas de agentes, os métodos para desenvolvimento de software

dependem de representações e normas que sustentem a análise, especificação e projeto de um

software assim como nas demais aplicações, porém com certas peculiaridades envolvendo os

agentes. O problema ocorre quando percebe-se que as habilidades dos desenvolvedores são

enfocadas mais em metodologia de desenvolvimento que em acompanhamento das técnicas

de agente mais recentes.

A UML(Unified Modeling Language) é a linguagem amplamente aceita para a

concepção de software orientado a objeto. O princípio básico da linguagem proposta para

agentes é acomodar os requisitos dos agentes dentro da UML. Estarão sendo apresentadas

neste capítulo as abordagens necessárias para adaptar os modelos da UML a uma metodologia

que tratará da modelagem de um sistema de agentes.

3.1 METODOLOGIAS

A AUML (Agent UML) sintetiza alguns elementos importantes de uma metodologia

baseada em agentes. A comunidade de pesquisa e desenvolvimento de agente está interessada

em métodos e ferramentas representacionais para apoiar os softwares desenvolvidos com a

utilização de agentes. Este tema pode ser consultado em Burmeister (1996), Iglesias (1998),

Garijo (1999), Parunak (1998), Kinny (1996a), Kinny (1996b), Bryson (1998), Martin e Odell

(1998); Nodline et al. (1998); Wooldridge et al., (2000). Vários grupos têm divulgado

metodologias para projetar agentes, baseados sempre em mecanismos representacionais. O

paralelo que é realizado entre as metodologias de projeto para agentes e para objetos é

compartilhado por vários autores, por exemplo, Burmeister (1996), Bryson (1998). A

metodologia aplicada por Wooldridge et al. (2000) inclui recomendações específicas para

35

especificações que sustentam o resumo de um protocolo de alto nível, como uma unidade

atômica, uma especificação é refletida nesta metodologia. O programa em andamento na

Universidade Livre de Amsterdã em metodologias composicionais para requisitos Herlea

(1999), projeto Brazier (1998), e verificação Jonker (1997) usa representações gráficas com

vínculos fortes para diagramas de colaboração da UML. A discussão da composição de

protocolos é antecipada no trabalho de Burmeister et al. (1993). Os gráficos de Dooley

facilitam a identificação de um agente desempenhando um papel específico Parunak (1996),

Singh (1998a).

Esta larga atividade é um sinal saudável de que sistemas baseados em agentes estão

tendo uma evolução significativa. Esta demanda por metodologias e softwares reflete a

importância industrial crescente desta tecnologia. O objetivo não é competir com quaisquer

destes esforços, mas estender e aplicar um formalismo de modelagem extensamente aceito e

representacional.

3.1.1 UML

Durante os anos setenta, a programação estruturada era a abordagem dominante para

desenvolvimento de software. Junto com isto, tecnologias de engenharia de software eram

desenvolvidas a fim de aliviar e formalizar o desenvolvimento de sistemas conforme um ciclo

de vida definido: planejamento, análise e projeto, e finalmente a construção de um sistema,

teste e manutenção. Na década de oitenta, as linguagens orientadas a objetos surgiram,

trazendo com elas novos conceitos, como encapsulamento de dados, herança, mensagens,

polimorfismo e outros. Ao final dos anos oitenta e início dos anos noventa, uma grande

quantidade de abordagens de modelagem surgiu e passou a sustentar a esfera comercial de

softwares orientados a objetos. Para unificar estas várias abordagens, uma força tarefa de

Análise e Projeto era estabelecida em 29 de junho 1995 dentro do OMG. Por volta de

novembro de 1997, um padrão era adotado pela OMG, chamada pelos seus membros de

Linguagem de Modelagem Unificada (UML).

A UML unifica e formaliza os métodos de muitas abordagens para o ciclo de vida de

desenvolvimento de software orientado a objetos, inclusive para Booch, Rumbaugh (OMT),

Jacobson e (ODELL, 1999; BAUER, 1999). A UML suporta os seguintes tipos de modelos:

36

Diagramas Estruturais: existem para visualizar, especificar, construir e documentar os

aspectos estáticos de um sistema. Considerem-se os aspectos estáticos como uma

representação de seu esqueleto relativamente estáveis. Assim como os aspectos estáticos de

uma casa incluem a existência e a colocação de itens como paredes, portas, janelas, canos,

fios e outros, também os aspectos estáticos de um sistema de software abrangem a existência

e a colocação de itens como classes, interfaces, colaborações, componentes e nós. Os

diagramas estáticos da UML são organizados em função dos principais grupos de itens

encontrados na modelagem de um sistema.

1. Diagrama de classe: mostra um conjunto de classes, interfaces e colaborações e seus

relacionamentos. Os diagramas de classes são os diagramas mais encontrados em sistema

de orientação a objetos;

2. Diagrama de objetos: mostra um conjunto de Objetos e seus relacionamentos. Usa-se este

diagrama para ilustrar as estruturas de dados, registros estáticos de instâncias dos itens

encontrados no diagrama de classes;

3. Diagrama de componentes: mostra um conjunto de componentes e seus relacionamentos.

Usa-se este diagrama para representar a visão estática da implementação de um sistema;

4. Diagrama de implantação: mostra um conjunto de nós e seus relacionamentos. Usa-se

este diagrama para ilustrar a visão estática da implantação de uma arquitetura

(RUMBAUGH; JACOBSON; BOOCK, 1999).

Diagramas Comportamentais: Os cinco diagramas comportamentais da UML são utilizados

para visualizar, especificar, construir e documentar os aspectos dinâmicos de um sistema.

Considerem-se os aspectos dinâmicos de um sistema como uma representação de suas partes

que sofrem alterações. Assim como os aspectos dinâmicos de uma casa abrangem a circulação

de ar e a passagem de pessoas pelos cômodos da casa, também os aspectos dinâmicos de um

sistema de software envolvem itens como o fluxo de mensagens ao longo do tempo e a

movimentação física de componentes em uma rede. Os diagramas comportamentais são

basicamente organizados a partir das principais maneiras disponíveis para se fazer a

modelagem da dinâmica de um sistema.

1. Diagrama de caso de uso: mostra um conjunto de casos de uso, atores e seus

relacionamentos. Aplica-se este diagrama para ilustrar a visão estática do caso de uso de

um sistema;

2. Diagrama de seqüência: é um diagrama de interação que dá ênfase à ordenação temporal

das mensagens. Um diagrama de seqüência mostra o conjunto de objetos e as mensagens

enviadas e recebidas por estes objetos.

37

3. Diagrama de colaboração: é um diagrama de interação que dá ênfase à organização

estrutural dos objetos que enviam e recebem mensagem. Um diagrama de colaboração

mostra um conjunto de objetos, as ligações existentes entre estes objetos e as mensagens

enviadas e recebidas pelos objetos.

4. Diagrama de Estados: mostra uma máquina de estados, que consiste de estados,

transições, eventos e atividades. Usa-se o diagrama de estados para ilustrar a visão

dinâmica de um sistema.

5. Diagrama de atividades: mostra o fluxo de uma atividade para outra em um objeto. Um

diagrama de atividade mostra um conjunto de atividades, o fluxo seqüencial ou ramificado

de uma atividade para outra e os objetos que realizam ou sofrem ações (RUMBAUGH;

JACOBSON; BOOCK, 1999).

A proposta aqui é uma extensão baseada em UML para representar agentes com os

seguintes produtos: pacotes, templates, diagrama de seqüência, diagramas de colaboração,

diagramas de atividade e diagrama de estados (BRAZIER, 1998; HERLEA, 1999; JONKER,

1997; KINNY, 1996A; KINNY, 1996B; WOOLDRIDGE et al., 2000).

3.1.2 AUML

Comparados à abordagem tradicional de objetos, agentes são autônomos e interativos.

Baseados em estados internos, suas atividades incluem planos e condições que guiam à

execução de tarefas definidas. Enquanto as necessidades dos objetos são atendidas pelos seus

métodos, os agentes percebem as condições e planejam suas ações, tratando suas necessidades

com maior responsabilidade. Além disso, agentes podem agir só e com outros agentes. Os

sistemas multi-agente podem se assemelhar a uma comunidade social de membros

interdependentes que agem individualmente. Porém, ainda não existe nenhum formalismo

para especificar o desenvolvimento deste tipo de sistema. Para empregar a programação

baseada em agente, deve haver uma técnica de especificação que sustente o processo de

engenharia de software inteiro, desde o planejamento, análise, projeto, construção,

implantação e manutenção. A FIPA e o OMG Agent Work Group estão explorando o uso e

recomendando extensões da UML (BAUER, 1999; ODELL, 1999). Depke et al. (2000)

discute transformações de gráficos e papéis em uma base para modelagem UML de agente.

38

Nesta proposta, a UML pode ser usada como um Protocolo de Interação de Agente (AIP),

como mostra a Figura 9.

Este subconjunto foi escolhido porque protocolos de interação são complexos o

suficiente para ilustrar o uso de AUML. Os protocolos de interação de agente são um bom

exemplo de padrões de software em um contexto prático. Uma especificação de um protocolo

de interação de agente provê um exemplo ou analogia para resolução de problemas em análise

de sistema e projeto. A AUML é uma técnica para especificação de protocolo de interação de

agente com a semântica formal e intuitiva e uma anotação gráfica. A semântica permite uma

definição precisa, que também é utilizável no processo de engenharia de software. A anotação

gráfica provê uma linguagem comum para comunicação de protocolo de interação de agente.

Um protocolo de interação de agente descreve um padrão de comunicação como uma

seqüência permitida de mensagens entre agentes e as restrições no conteúdo destas mensagens

(ODELL, 1999).

Figura 9: Protocolo de Interação de Agente, mostrando as interações para o protocolo Contract Net.

Fonte: Odell (1999).

A Figura 9 mostra um protocolo expresso como em diagrama de seqüência AUML

para o Contract Net Protocol. Quando invocado, um agente Iniciador envia a proposta para

um agente que está disposto a participar e prover uma proposta. O agente Participante pode

então escolher o que responder para o Iniciador antes de um prazo final: recusando,

submetendo uma proposta, ou indicando que não entendeu. (O símbolo de diamante indica

uma decisão que pode resultar em zero ou mais comunicações). O “x” dentro do diamante

39

indica que deverá existir apenas uma resposta. Se uma proposta é oferecida, o Iniciador tem a

escolha de aceitar ou rejeitar a proposta. Quando o Participante receber uma aceitação de

proposta, informará o Iniciador sobre a execução da proposta. Adicionalmente, o Iniciador

pode cancelar a execução da proposta em qualquer hora.

A Figura 9 também expressa mais dois conceitos representados no nível superior do

quadro. Primeiro, o protocolo como um todo é tratado como uma entidade. A pasta de

anotação na parte superior indica que o protocolo é um pacote, uma agregação conceitual de

interação. Segundo, o pacote protocolo pode ser tratado como um padrão que pode ser

customizado para domínios de problemas análogos. A caixa no canto superior direito expressa

este padrão como uma especificação de template que identifica as entidades dentro do pacote

que precisam estar descritas quando o template estiver sendo instanciado. Em UML, o

protocolo de interação de agente serve como pacote e template. Um template é um módulo

parametrizado que pode ser instanciado por outro produto em uma outra relação de tempo. Na

Figura 9, a caixa pontilhada no lado superior direito indica que o pacote é um template. Os

parâmetros desconectados na caixa são divididos pelas linhas horizontais em três categorias:

parâmetros de papel, restrições e atos de comunicação.

3.2 UTILIZAÇÃO DE PADRÕES – NÍVEL 1

Padrões são idéias reaproveitadas em um contexto prático e que podem provavelmente

ser utilizadas em outros. Como tal, fornecem exemplos ou analogias que podem ser usadas

como soluções para problemas em análise de sistema e projeto. Protocolos de interação agente

são, então, projetados como soluções reutilizáveis que podem ser aplicadas aos vários tipos de

seqüência de mensagem que são encontradas entre os agentes. Existem duas técnicas de UML

que melhor expressam as soluções de reuso: Pacotes e Templates (RUMBAUGH;

JACOBSON; BOOCK, 1999).

40

3.2.1 Pacotes

Protocolos de interação são padrões. A UML descreve dois modos de expressar

agregação, que para a orientação a objetos, estrutura o comportamento dos objetos:

Componentes e Pacotes. Os componentes são agregações físicas que compõem classes para

propósitos de implementação. Pacotes são elementos da modelagem que agregam conjuntos

conceituais. Aqui, classes podem estar conceitualmente agrupadas para qualquer propósito

arbitrário.

Protocolos de interação agente podem ser classificados como padrões e tornam-se

módulos reutilizáveis.

Protocolos de interação são padrões. A UML descreve dois modos de expressar

agregação, que para a orientação a objetos, estrutura o comportamento dos objetos:

Componentes e Pacotes. Os componentes são agregações físicas que compõem classes para

propósitos de implementação. Pacotes são elementos da modelagem que agregam conjuntos

conceituais. Aqui, classes podem estar conceitualmente agrupadas para qualquer propósito

arbitrário.

Protocolos de interação agente podem ser classificados como padrões e tornam-se

módulos reutilizáveis.

Figura 10: Exemplo de um diagrama de pacotes.

Fonte: Elaborada pelo autor (2007).

41

3.2.2 Templates

Templates são padrões utilizados em situações práticas, onde algumas características

do padrão são especificadas para determinado caso concreto. Por exemplo, na figura 11 o

padrão de interação definido pelo protocolo Contract net é especializado para uma função do

sistema multi-agente utilizado nesse trabalho.

Figura 11: Exemplo da especificação de um template


3.3 INTERAÇÕES ENTRE AGENTES – NÍVEL 2

Os modelos dinâmicos da UML são úteis para expressar interações de agentes. Os

diagramas de interação capturam os padrões estruturais de interações de objetos. Os

diagramas de seqüência e os diagramas de colaboração fazem parte do modelo dinâmico. Os

dois diagramas contêm as mesmas informações. O plano gráfico do diagrama de seqüência

enfatiza a seqüência cronológica de comunicações, enquanto o plano gráfico do diagrama de

42

colaboração enfatiza as associações entre os agentes. Os diagramas de atividade e de estado

capturam o fluxo de processo na comunidade de agente.

3.3.1 Diagramas de Seqüência

O diagrama de seqüência definido para a AUML apresenta algumas evoluções com

relação ao diagrama definido pela UML (para uma discussão mais detalhada de diagramas de

seqüência, veja Rumbaugh; Jacobson, Boock (1999). Nesta seção, serão discutidas estas

extensões possíveis para UML, que também podem modelar protocolos de interação de

agente. A Figura 12 mostra alguns elementos básicos para comunicação de agente. O

retângulo pode expressar agentes individuais ou fixar papéis e classes de agentes. Por

exemplo, um agente individual poderia ser denominado como Bob/Cliente. Aqui, Bob é uma

instância de agente que representa o papel do cliente. Bob poderia também representar o papel

de provedor, empregado e proprietário. Para indicar que Bob é uma Pessoa (independente de

qualquer papel que ele tenha), Bob poderia ser expresso como Bob:Pessoa. O formato básico

para a etiqueta é nomedoagente/papel:classe. Então, podem-se expressar todas as várias

situações para Bob, como Bob/Cliente:Pessoa e Bob/Empregado:Pessoa.

A caixa retangular também pode indicar um conjunto geral de agentes desempenhando

um papel específico. Aqui, apenas a palavra cliente ou provedor apareceriam. Para especificar

que o papel é para ser protagonizado por uma classe específica de agente, o nome de classe

seria anexada (por exemplo, Empregado:Pessoa). Em outras palavras, o nomedoagente/papel:

classe é a sintaxe usada para especificar o nome do agente individual.

A sintaxe nomedoagente/papel:classe já é herdada da UML (a sintaxe da UML indica

um nome de objeto em vez de um agente). A Figura 12 estende a UML, denominando a seta

com um ato de comunicação agente (CA), em vez de uma mensagem.

43

Figura 12: Formato básico para comunicação de agente.


Outra recomendação que a extensão UML sustenta são as linhas simultâneas de

interação. A Figura 13 mostra três modos de expressar linhas múltiplas. A Figura 13(a) indica

que todas as linhas CA-1 para CA-n são concorrentemente enviadas. Na Figura 13(b) foi

incluída uma caixa de decisão indicando que deverá haver uma decisão antes do envio das

CA’s, zero ou mais, neste caso. Se mais de uma CA é enviada, a comunicação é simultânea. A

Figura 13(c) indica um “ou” exclusivo, de forma que exatamente uma CA será enviada. Desta

forma, a Figura 13(a) indica um “e” na comunicação.

Figura 13: Transmissão simultânea de mensagens.


A Figura 14 ilustra uma maneira de usar as linhas simultâneas de interação mostradas

na Figura 13. As Figuras 14(a) e (b) retratam dois modos de expressar linhas simultâneas, do

agente-1 até o agente-2. As múltiplas barras verticais indicam que o agente receptor é um

processo com várias linhas de comunicação concorrente. As barras de ativação da Figura

14(a) são exibidas em paralelo. Na Figura 14(b), as barras de ativação aparecem uma em cima

da outra. Algumas observações podem ser notadas sobre estas duas variações (BAUER, 1999;

ODELL, 1999):

44

O significado semântico é equivalente; a escolha é baseada em facilidade e clareza de

aparência visual.

Cada barra de ativação pode indicar que o agente está usando um papel diferente ou que

meramente está empregando uma linha de processo diferente para sustentar o ato da

comunicação. Se o agente está usando um papel diferente, a barra de ativação pode ser

apropriadamente anotada. Por exemplo, na figura 14(a) e (b), CA-n é manipulada pelo

agente debaixo de seu papel-1.

Estas figuras indicam que um único agente possui múltiplos processos de CA’s

concorrentemente. Porém, as CA’s simultâneas poderiam ser enviadas para agentes diferentes,

por exemplo, CA-1 para agente-2, CA-2 para agente-3, e assim por diante. Tal

comportamento de protocolo já está sustentado pela UML; a anotação na Figura 13, por outro

lado, é uma extensão recomendada para UML (para tratamento mais detalhado destas

extensões para a UML para diagrama de seqüência, veja Bauer (1999)).

Figura 14: Múltiplas técnicas para representar comunicação simultânea entre agentes, utilizando múltiplos papéis.


45

3.3.2 Diagramas de Colaboração

A Figura 15 é um exemplo de um diagrama de colaboração. Uma das distinções

primárias do diagrama de colaboração é que os agentes (os retângulos) podem ser dispostos

em qualquer lugar no diagrama; considerando que, em um diagrama de seqüência, os agentes

são colocados em uma camada horizontal na parte superior do diagrama. Semanticamente,

eles são quase equivalentes; graficamente eles são semelhantes. A experiência mostra que no

modelo baseado em agente ambos os diagramas são úteis.

A Figura 15 ilustra um exemplo de diagrama de colaboração.

Figura 15: Um exemplo de um diagrama de colaboração mostrando uma

interação entre agentes com papéis múltiplos.


A intuição na terminologia é que um caráter é um agente específico desempenhando

um papel específico. O papel é uma abstração acima de vários personagens com padrões

semelhantes de interação. Inversamente, cada nó é um agente em um papel específico, onde o

"papel" é definido estreitamente.

Em se tendo um papel preciso ou uma definição de papéis, é possível construir um

diagrama de colaboração que tem conteúdo semântico como um gráfico de Dooley. Na Figura

16 é ilustrada uma representação baseada em uma seqüência. O diagrama de seqüência é uma

forma de representação utilizada para explicitar a seqüência das operações, como já foi

mencionado, de certa forma a seqüência estabelecida em uma determinada situação necessita

da participação de vários agentes, o que caracteriza uma colaboração entre eles.

46

Figura 16: Diagrama de seqüência.


3.3.3 Diagramas de atividades

Os protocolos de interação agente podem, às vezes, exigir especificações muito claras

sobre semântica do processo. O diagrama de atividade expressa operações e eventos que os

ativam (para um tratamento mais detalhado, veja descrição do Odell de diagramas de

atividade em Martin e Odell, (1998)). O exemplo na Figura 17 mostra um conjunto de

atividades. O diagrama de atividades difere de diagramas de interação porque provê uma linha

explícita de controle. Isto é particularmente útil para protocolos de interação complexos que

envolvem processos simultâneos.

Os diagramas de atividade são semelhantes em redes de natureza Petri de vários

modos. Primeiro, diagramas de atividade provêm uma representação gráfica que possibilita a

visualização de processos simples, facilitando assim o projeto e comunicação dos modelos.

Diagramas de atividade podem representar processos simultâneos assíncronos. Finalmente,

47

eles podem expressar comunicações simultâneas com vários correspondentes. A diferença

primária entre as duas abordagens é aquela em que os diagramas de atividade são

formalmente baseados e estendidos na máquina de estados modelada pela UML

(RUMBAUGH; JACOBSON; BOOCK, 1999). Na formalização de BRIC, Ferber (1999)

estende redes de Petri para sistemas baseados em agentes. Esta proposta estende diagramas de

atividade de UML para o mesmo propósito.

Figura 17: Um diagrama de atividade baseado em um caso de uso do sistema de monitoração


3.3.4 Diagrama de Estados

Outro processo relacionado a diagramas da UML é o diagrama de estados. Um

diagrama de estados é um gráfico que representa uma máquina de estados. Os estados são

representados como retângulos com cantos arredondados, enquanto transições estão

geralmente representadas por arcos orientados que interconectam os estados. A Figura 18

mostra um exemplo de um diagrama de estados.

48

O diagrama de estados não é comumente usado para expressar protocolo de interação

porque é uma visão centrada no estado, em lugar de uma visão centrada no agente ou

processo. A visão centrada no agente retratada por diagramas de interação enfatiza o primeiro

e o segundo agente da interação. A visão centrada no processo enfatiza o fluxo do processo

(por agente). A visão centrada no estado enfatiza os estados permissíveis mais proeminentes

que o processo de transição de agente.

Figura 18: Um diagrama de estados indicando os estados e transições de uma conta corrente


3.4 REPRESENTAÇÃO DE PROCESSOS INTERNOS DE AGENTES – NÍVEL 3

No nível mais baixo da especificação de um protocolo de agente exige-se que um

processo que acontece dentro de um agente seja detalhado a fim de implementar o protocolo.

O comportamento interno de um agente pode, deste modo, ser descrito usando quaisquer

representações do Nível 2. Além de que diagramas de atividade e estados também podem

especificar o processo interno de agentes, como é ilustrado anteriormente.

3.4.1 Diagramas de atividade

A Figura 19 mostra o processo detalhado que acontece dentro de um agente unidade

móvel. Aqui, um diagrama de seqüência indicou que o processo do agente é ativado por uma

CA e finalizado com um atendimento concluído. O processo interno pela unidade móvel é

49

expresso como um diagrama de atividade, onde a unidade móvel analisa a viabilidade de um

atendimento, realiza o atendimento, encaminha a vítima, entrega a vítima e encerra o

atendimento. As caixas de operação destacadas e indicadas na linha mais abaixo representam

interfaces para os processos executados por agentes externos – como também é ilustrado no

diagrama de seqüência. Por exemplo, o diagrama indica isto quando a unidade móvel está

prestes a realizar um atendimento. Ambos, solicitar orientações e necessidades da vítima são

ações ativadas simultaneamente.

Figura 19: Um diagrama de atividade que especifica e ordena o comportamento do processo para um agente.


3.4.2 Diagramas de estado

O processo interno de um agente único também pode ser expresso como diagrama de

estado. A Figura 20 mostra os estados e transições internas da unidade móvel. Este uso do

diagrama de estados da UML dentro do agente sustenta a noção do Singh de esqueletos de

agente Singh (1998b).

50

Figura 20: Diagrama de estados que especifica processo interno do agente unidade móvel.


51

4 AMBIENTE PARA DESENVOLVIMENTO DE AGENTES (JADE)

4.1 INTRODUÇÃO

Este capítulo dará uma visão geral da plataforma JADE utilizada neste trabalho,

mostrando sua arquitetura, principais funcionalidades e o modelo conceitual explorado. Os

dois principais aspectos do modelo conceitual são apresentados: a topologia de sistemas

distribuídos com redes ponto-a-ponto, e a arquitetura de componentes de software no paradigma

de agentes. A topologia de rede afeta a maneira como os componentes conversam, enquanto a

arquitetura de componentes especifica o que os componentes devem esperar um dos outros. A

relevância de padrões para a interoperabilidade de softwares, e em particular a harmonização

com o padrão FIPA (Foundation for intelligent physical agents), também é abordada.

4.2 JADE EM TERMOS GERAIS

Jade é uma tecnologia habilitadora, um middleware para o desenvolvimento e

execução de aplicações ponto-a-ponto que são baseadas em agentes e que pode trabalhar e

operar em ambientes com fio e sem fio. Jade é uma tecnologia de uso livre desenvolvida e

distribuída pela Telecom Itália.

4.3 REFERÊNCIAS TECNOLÓGICAS

4.3.1 O modelo ponto-a-ponto

O modelo cliente/servidor é uma referência, bem conhecido e usado em aplicações

distribuídas. O modelo é baseado em uma rígida distinção dos papéis entre os nós clientes e o

nó servidores. O nó servidor fornece os serviços, as capacidades do sistema distribuído, mas

não é capaz de tomar qualquer iniciativa. É totalmente reativo e pode apenas esperar para ser

invocado pelos nós clientes. Nós clientes, opostamente, concentram toda a iniciativa do

sistema: eles acessam e usam os serviços, mas nunca fornecem nenhum tipo de

funcionalidade.

Clientes podem aparecer e desaparecer a qualquer tempo e geralmente possuem

endereços dinâmicos, enquanto servidores tipicamente devem ter uma certa estabilidade e por

isso possuem geralmente endereços fixos, estáticos. Clientes se comunicam com servidores,

52

mas não se comunicam com outros clientes. De outra forma, servidores não podem se

comunicar com clientes, a não ser que estes últimos iniciem a comunicação.

A web é um exemplo típico de uma aplicação cliente/servidor. Os servidores são os

portais, que armazenam toda a aplicação e funcionalidades e os usuários em suas máquinas

pessoais são os clientes.

Entretanto, uma larga família de aplicações distribuídas não se adapta a este modelo e

é ai que entra o modelo ponto-a-ponto. Por exemplo, uma aplicação de chat, assim como uma

aplicação de compartilhamento de arquivos, requer que os nós da rede possuam certas

capacidades de comunicação uns com os outros. Mesmo que nesses casos seja possível

utilizar a arquitetura cliente/servidor, muitas vantagens acerca de praticas de software e

arquiteturas seriam perdidas.

No modelo ponto-a-ponto não há qualquer distinção de papeis e cada ponto tem

capacidades de iniciativa e de prestação de serviços. Cada ponto pode iniciar uma

comunicação, ser sujeito ou objeto de um pedido, ser proativo, fornecer capacidades. A lógica

da aplicação não é mais concentrada em um único ponto (servidor), mas distribuída entre os

pontos da rede. Cada nó é capaz de descobrir outros nós e entrar e sair da rede a qualquer

tempo.

Uma importante conseqüência da diferença entre os dois modelos é a maneira como os

nós são descobertos. No sistema cliente/servidor os clientes devem conhecer o servidor, mas

não precisam saber da existência de outros clientes, pelo menos diretamente. Em sistemas P2P

(peer-to-peer ou ponto-a-ponto) é imperativo que os nós se conheçam diretamente, que

estejam cientes de suas capacidades e funcionalidades. No sentido de implementar esse

conhecimento entre os pontos de uma rede, existem dois modelos básicos de P2P: o modelo

puro (figura 21) e o modelo híbrido (figura 21).

53

Figura 21: Modelos de sistemas ponto-a-ponto.


Uma rede P2P pura é totalmente descentralizada e os pontos completamente

autônomos. A inexistência de um nó de referencia (servidor) torna difícil manter a coerência

da rede e a descoberta dos pontos, com uma complexidade e largura de banda que crescem

exponencialmente com o número de nós.

A arquitetura híbrida, ao contrário, é baseada em um nó especial que fornece um

serviço que simplifica o conhecimento entre os nós e a descoberta dos nós ativos da rede e

suas funcionalidades. Estes tipos de rede, usualmente, geram menos trafico e são mais

seguros, na medida em que requerem o registro e autenticação dos pontos. Entretanto, o

funcionamento desta arquitetura depende da disponibilidade de um ponto central, que pode

sofrer ataques e gerar falhas.

4.3.2 O paradigma de agentes

O paradigma de agentes aplica conceitos de inteligência artificial e teoria de ações de

fala à tecnologia de objetos distribuídos. O paradigma é baseado na abstração de agentes, um

componente de software que é autônomo, proativo e social.

Autônomo: agentes possuem um grau de controle sobre suas próprias ações, eles possuem

suas linhas de controle, e em algumas circunstancias podem até tomar decisões.

Proativo: agentes não apenas reagem a em resposta a eventos externos, eles também

podem exibir um comportamento direcionado a objetivos e, quando apropriado, tomam

iniciativa deste comportamento.

54

Social: agentes são capazes e têm necessidade de interagir com outros agentes de forma a

realizar suas tarefas e atingir os objetivos globais do sistema.

Sistemas baseados em agentes são intrinsecamente ponto-a-ponto. Cada agente é um

ponto que necessita potencialmente iniciar uma comunicação com outro agente, assim como pode

fornecer serviços aos demais agentes da rede. O papel da comunicação é muito importante em um

sistema baseado em agentes, e o seu modelo é baseado em três características principais:

1. agentes são entidades ativas, eles podem dizer “não”, e são fracamente acoplados, quer

dizer, bastante independentes. Estas características são a base do modelo de comunicação

assíncrona existente entre os agentes que é totalmente diferente do modelo de chamada de

procedimento remoto utilizado na maioria das aplicações. Um agente querendo se

comunicar com outro, deve apenas enviar uma mensagem a um certo destino. Neste

modelo o agente receptor tem a faculdade de selecionar as mensagens que deseja receber e

servir, assim como a ordem em que elas serão analisadas. O agente que enviou é tão

independente que não precisa esperar que a mensagem seja recebida, uma vez que ela

pode até não ser recebida, para continuar seu processamento. Caso a sua requisição não

seja atendida, ele não fica bloqueado, simplesmente tenta obter ajuda de outro agente da

rede. Outra situação oriunda desta independência ocorre quando verifica-se que o agente

que envia uma requisição não tem noção se o agente de destino está ou não na rede. Pode

acontecer de não estar ou de simplesmente não estar disponível naquele momento.

2. As ações de comunicação dos agentes são vistas como uma espécie do gênero ação.

Realizar ações comunicativas no mesmo nível que ações em geral permite que um agente,

por exemplo, elabore um plano que inclua tanto ações físicas (ex. dobrar a direita) quanto

ações comunicativas (ex. pedir para abrir a porta). De forma a fazer a comunicação como

algo planejável, efeitos e pré-condições de cada possível comunicação precisam ser

claramente definidos.

3. Ações comunicativas carregam um significado semântico. Quando um agente é o objeto

de uma ação comunicativa (quando ele recebe uma mensagem), ele deve ser capaz de

entender propriamente o significado daquela ação e, em particular, porque ela foi

executada (a intenção do agente que enviou a mensagem). Esta propriedade traz a

necessidade de uma semântica universal e consequentemente de um padrão.

Inspirado pela visão que “agentes não passarão de um sonho se a interoperabilidade ponto-

a-ponto entre diferentes fabricantes não for preservada”, a TILAB (organização que concebeu o

JADE) promoveu a criação do FIPA, uma associação internacional de empresas e organizações

que compartilham o desejo de criar especificações padrão para a tecnologia de agentes.

55

Baseado no primeiro conjunto de especificações liberado em 1997, no final de 2002 a

FIPA finalmente liberou um conjunto de padrões. Este conjunto tinha como foco a

interoperabilidade e, por conseqüência, deu ênfase ao comportamento externo dos componentes

do sistema, deixando abertos os detalhes de implementação e a arquitetura interna.

O padrão FIPA adota completamente o paradigma de agentes e, em particular, define o

modelo de referencia de uma plataforma de agentes e um conjunto de serviços que deveriam

ser fornecidos. O conjunto desses serviços e suas interfaces padrão representam as regras

normativas que fazem com que uma sociedade de agentes exista, opere e seja gerenciada.

Uma vez que os agentes são sociais e precisam se comunicar, a linguagem de

comunicação de agentes é um dos principais itens do padrão FIPA. O FIPA ACL (Agentes

comunication language) é baseado na teoria de ações de fala e nas presunções e requisitos do

paradigma de agentes descrito acima. A FIPA padronizou uma biblioteca extensiva de 22

ações de comunicação que permitem a representação de diferentes intenções de comunicação

(como pedidos, propostas, informações, consultas, recusas, etc.). A FIPA também definiu a

estrutura de mensagens que permite representar informações úteis para identificar os agentes

que enviam e recebem mensagens, o conteúdo das mensagens e suas propriedades, e, em

particular, informações úteis para identificar e seguir linhas de conversação entre agentes.

Padrões comuns de conversação também foram definidos pela FIPA, os chamados protocolos

de interação que fornecem aos agentes bibliotecas de padrões para atingir tarefas comuns,

como delegar uma ação, promover uma proposta, etc. A figura 22 representa o modelo de

comunicação definido pela FIPA e os relacionamentos entre seus elementos.

Figura 22: Modelo de comunicação e relacionamentos


56

4.4 O JADE EM TERMOS ESPECÍFICOS

JADE é o middleware desenvolvido pela TILAB para o desenvolvimento de

aplicações multi-agentes distribuídas baseadas na arquitetura de comunicação ponto-a-ponto.

A inteligência, a iniciativa, as informações, os recursos e o controle podem ser totalmente

distribuídos em terminais móveis assim como em computadores em uma rede cabeada. O

ambiente pode evoluir dinamicamente com pontos, que no JADE são chamados agentes, que

aparecem e desaparecem no sistema de acordo com as necessidades de requisitos da aplicação

em questão. A comunicação entre os pontos, independentemente se eles estão sendo

executados em ambientes sem fio ou não, é completamente simétrica, sendo que cada ponto

pode desempenhar o papel de servidor e cliente. O JADE é totalmente desenvolvido em java e

é baseado nos seguintes princípios:

Interoperabilidade: o JADE foi projetado de acordo com os padrões FIPA,

consequentemente, os agentes JADE podem operar com outros agentes, uma vez que todos

entendem o padrão.

Uniformidade e Portabilidade: o JADE fornece um conjunto de API’s homogêneo que

é independente da rede e da versão do java. Resumindo, o JADE run-time fornece as mesmas

API’s para a plataforma J2EE, J2ME ou J2SE.

Facilidade de uso: a complexidade do JADE é escondida atrás de um simples e

intuitivo conjunto de API’s.

Uso dirigido: os programadores não precisam conhecer todas as funcionalidades do JADE,

mas sim apenas aquelas relacionadas a sua aplicação.

4.4.1 O modelo de arquitetura

O JADE inclui tanto as bibliotecas necessárias ao desenvolvimento de aplicações

baseadas em agentes, quanto o ambiente run-time que fornece os serviços básicos e que deve

estar ativo no dispositivo antes que os agentes possam ser executados. Cada instancia do run-

time JADE é chamada de container (uma vez que contém agentes). O conjunto de todos os

containers é chamado de plataforma e fornece uma camada homogênea que esconde dos

57

agentes (e por conseqüência dos programadores) a complexidade e a diversidade de aspectos

acerca de hardware, sistemas operacionais, máquina virtual, entre outros.

4.4.2 O modelo funcional

Do ponto de vista funcional, o JADE fornece os serviços básicos necessários para

distribuir aplicações ponto-a-ponto em ambientes fixos e móveis. O JADE permite que cada

agente descubra dinamicamente outros agentes e se comunique com eles. Do ponto de vista da

aplicação, cada agente é identificado por um único nome e fornece um conjunto de serviços.

Ele pode registrar e modificar os serviços registrados e/ou procurar por outros agentes que

fornecem outros serviços, pode controlar seu ciclo de vida e, em particular, se comunicar com

outros pontos (agentes).

Agentes se comunicam através da troca assíncrona de mensagens, um modelo de

comunicação, quase universalmente aceito, de comunicação distribuída e fracamente acoplada

entre entidades heterogêneas que não se conhecem. De forma a iniciar a comunicação, um

agente apenas envia uma mensagem para um determinado destino. Agentes são identificados

por um nome e, como conseqüência, não há qualquer dependência temporal entre os agentes

que estão se comunicando. O agente cliente e o receptor podem não estar disponíveis ao

mesmo tempo. O receptor pode inclusive não existir ou não ser conhecido pelo agente cliente,

que pode simplesmente requisitar um serviço e aqueles agentes que prestam esse serviço

poderão atendê-lo.

Nesse tipo de aplicação a segurança também é um aspecto primordial. Existem

mecanismos de autenticação e verificação de “direitos” associados aos agentes por parte da

plataforma. Quando se faz necessário, portanto, uma aplicação pode verificar a identidade de

um agente cliente e evitar que ações não permitidas sejam executadas (por exemplo, um

agente pode receber mensagens de um outro agente, mas não pode enviar mensagens a ele). A

estrutura das mensagens está de acordo com a linguagem ACL da FIPA e inclui campos como

variáveis indicando o contexto a que uma mensagem se refere, o timeout suportado, entre

outros.

Para facilitar a criação e a manipulação do conteúdo das mensagens, o JADE fornece

suporte para uma conversão automática entre o formato apropriado para a troca de conteúdo,

incluindo XML e RDF, e o formato apropriado ara a manipulação do conteúdo (objetos java).

58

Para aumentar a scalabilidade ou atender as restrições de ambientes com recursos

limitados, o JADE oferece a oportunidade de executar múltiplas tarefas paralelas dentro da

mesma linha de execução.

Em aplicações desktop, o JADE suporta mobilidade de código e de estado de

execução. Ou seja, um agente pode parar de executar em uma máquina, migrar para outra

máquina da rede (sem a necessidade de ter o código do agente presente na máquina destino), e

recomeçar sua execução exatamente de onde parou. Essa funcionalidade permite, por

exemplo, uma distribuição da carga computacional em tempo de execução de acordo com a

situação do ambiente, movendo agentes para máquinas que estão com pouca carga

computacional e liberando máquinas sobrecarregadas.

A plataforma também inclui um serviço de nomeação dos agentes e um serviços de

“páginas amarelas”, onde se pode consultar serviços e os agentes prestadores desses serviços.

Outra característica importantíssima consiste na disponibilidade de um conjunto de

ferramentas gráficas para depurar a aplicação, bem como gerenciar e monitorar fases do ciclo

de vida da aplicação. Através dessas ferramentas, é possível controlar remotamente os

agentes, mesmo que eles estejam sendo executados. Conversas entre agentes podem ser

simuladas, trocas de mensagens podem ser forjadas, tarefas podem ser monitoradas e o ciclo

de vida de um agente pode ser totalmente controlado.

59

5 DESENVOLVIMENTO DE UM SISTEMA BASEADO EM AGENTES PARA

MONITORAÇÃO E DETECÇÃO DE FALTAS EM UM GERADOR

5.1 INTRODUÇÃO

Este trabalho investigou experimentalmente o desempenho de técnicas de inteligência

computacional baseadas em Tecnologia de Agentes, com aplicação ao projeto e

implementação de sistemas inteligentes para monitoramento de hidrogeradores na Usina

Hidrelétrica de Tucuruí, no estado do Pará, a qual é operada pela ELETRONORTE.

Primeiramente foram desenvolvidos estudos de campo que possibilitaram o

levantamento dos requisitos do sistema desenvolvido, através de estudo do sistema

anteriormente implantado na unidade geradora de estudo e também a partir de entrevistas com

técnicos operadores do sistema. Na seqüência, a tecnologia de agentes foi aplicada para o

projeto e implementação modular do software do sistema inteligente de monitoramento. A

vantagem da implementação em módulos é que esta permite maior facilidade e flexibilidade

para desenvolver e atualizar o sistema de monitoramento, o que é uma necessidade constante

durante toda a vida útil do sistema.

Para a aquisição das grandezas monitoradas, foi desenvolvido um sistema distribuído

de aquisição de dados baseado em rede industrial em padrões PROFIBUS e MODBUS. As

grandezas selecionadas para monitoramento foram às temperaturas dos componentes do

armário de tiristores do sistema de excitação de campo da unidade geradora e a desgaste das

escovas em contato com os anéis coletores do enrolamento de campo da máquina síncrona.

Para a medição remota do desgaste das escovas, foi desenvolvido no projeto um novo

instrumento, o qual é baseado em tecnologia embarcada.

Neste capítulo será mostrada a arquitetura global do sistema de monitoração e

detecção de faltas e uma descrição mais detalhada acerca de todas as estruturas. O sistema é

composto de três subsistemas: aquisição primária, aquisição secundária e monitoração e

detecção. A arquitetura foi projetada de forma a manter o máximo de independência entre os

subsistemas, de forma a substituir qualquer um deles sem a necessidade de alteração nos

demais.

60

5.2 ARQUITETURA GLOBAL DO SISTEMA

Figura 23: Arquitetura global.


5.2.1 Aquisição primária

Nessa etapa a planta industrial apresenta a seguinte estrutura: 4 armários dentro da

máquina 1. são extraídas 4 temperaturas destes armários e mais uma variável relacionada à

máquina, um sinal que representa o desgaste nas escovas. Como sensores existem 4

termoresistências do tipo pt-100 (4 temperaturas) e um sistema completo baseado no

microcontrolador PIC para obter o sinal de desgaste das escovas. Dos sensores estes dados

vão para um CLP responsável pela coleta das medidas.

5.2.2 Aquisição secundária

Nessa etapa os dados são repassados do CLP para um sistema feito no Labview para

facilitar a aquisição dos dados, uma vez que o Labview possui inúmeras interfaces prontas

para aquisição de dados. Após isso, o aplicativo Labview fica a espera de uma requisição do

sistema multi-agente (SMA) para preparar os dados e envia-los. Esta comunicação entre

61

sistemas diferentes (Labview e SMA) só é permitida pelo uso da tecnologia de socket, onde as

duas aplicações compartilham uma porta e trocam informações por ela.

5.2.3 Monitoração e detecção

Nessa etapa os dados já estão no SMA e serão tratados por ele. As funções dos agentes

são detalhadas no próximo capítulo.

5.3 CARACTERÍSTICAS DO SISTEMA A SER MONITORADO: sistema de excitação de

campo da unidade hidrogeradora UGH1

As máquinas síncronas são usadas nas usinas hidroelétricas para a realização da

conversão da energia mecânica das turbinas em elétrica a ser suprida para o sistema, sendo

composta basicamente de um rotor, que é a parte girante da máquina, e por um estator, que é a

parte fixa. Para que seja induzida tensão alternada nos enrolamentos do estator é necessário

criar um campo magnético girante, o que é feito através de um eletro-imã formado pelo

enrolamento de campo localizado no rotor. Para produzir o campo magnético é necessário

suprir o enrolamento do rotor com uma corrente elétrica contínua de valor consideravelmente

elevado. Abaixo é ilustrada a unidade geradora objeto do estudo.

Figura 24: Unidade geradora UGH1, na Casa de Força da 1ª Etapa da UHE de Tucuruí.


62

O sistema de excitação de campo é formado pelos equipamentos responsáveis por

suprir a corrente contínua ao enrolamento de campo. Esse subsistema é de vital importância

para o funcionamento correto do gerador. Uma falha nesse importante subsistema pode não só

provocar a parada não programada da unidade geradora quanto a perda da estabilidade de

operação do sistema de geração.

5.3.1 Descrição dos subsistemas que compõem o sistema de excitação de campo, com

suas respectivas funções

O sistema de excitação de campo da unidade geradora UGH1, da UHE de Tucuruí, é

formado por um sistema redundante composto por quatro retificadores trifásicos ligados em

paralelo para alimentar o enrolamento de campo do gerador, conforme ilustrado no esquema

da figura 25. Cada ponte retificadora está montada em armário individual (figura 26(a)). Para

a retirada do calor que é produzido por efeito Joule, durante a condução dos tiristores (figura

26(b)), cada um dos armários possui um sistema próprio para retirada de calor, o qual é

composto de um ventilador exaustor (figura 26(c)), para forçar a circulação do ar através do

sistema, e de um trocador de calor (figura 26(d)), o qual retira o calor através da troca térmica

mediante circulação de água fria. O esquema completo, detalhando o subsistema presente em

um dos armários de tiristores (armário A), é ilustrado no diagrama esquemático apresentado

na figura 27.

Figura 25: Diagrama simplificado da ponte retificadora tiristorizada.


Ventilador

Ponte de Tiristores

Trocador de Calor

63

Figura 26(a) – Armários de Tiristores da ponte

retificadora. Fonte: Elaborada pelo autor (2007).

Figura 26(b) – Ventilador Exaustor do armário de Tiristores

da ponte retificadora A.


Figura 26 (c) – Detalhe da gaveta de tiristores de um

dos braços de condução da ponte retificadora A.


Figura 26 (d) – Sistema trocador de calor da ponte

retificadora A.


Tiristores da ponte retificadora montados em dissipadores em dissipadores de calor

Trocador de calor

Ventilador exaustor

64

Figura 27: Diagrama esquemático ilustrando o subsistema de retificação em um dos armários da ponte de

tiristores do sistema de excitação de campo.


A ponte retificadora trifásica completa, incluindo os quatro armários, é composta por

um total de 48 tiristores, sendo que cada armário possui um total 12 tiristores. Estes armários

estão ligados em configuração paralela e, cada um deles possui, em seu interior, um total de

seis braços, sendo que cada braço é formado por dois tiristores ligados em série. Cada seis

braços forma uma ponte retificadora individual, colocada em cada um dos respectivos

armários A, B, C e D. Como existem quatro armários retificadores, existe um total de 24

circuitos idênticos. Quando em funcionamento normal, os armários estão ligados em paralelo

e fornecem a potência de excitação para o enrolamento de campo do gerador, conforme

ilustrado no detalhe apresentado na figura 27.

Em caso de defeito no subsistema de em um armário de tiristores, este pode ser

retirado de serviço por meio de uma chave seccionadora, sendo que os outros três armários

restantes têm suas pontes retificadoras dimensionadas para, em conjunto, suprir a potência

demandada pelo circuito de campo do gerador. Cada dois tiristores (em cada braço) estão em

série com um fusível de ação rápida, o qual protege os tiristores contra sobrecorrente. Este

fusível possui um micro-contato o qual opera quando o fusível abre, fornecendo um sinal

lógico utilizando para indicar alarme da ocorrência. Existe também, em cada tiristor, um

termostato que opera quando a temperatura no tiristor for superior a 80°C. A operação deste

termostato causa o imediato bloqueio dos pulsos de comando dos tiristores do respectivo

armário.

65

Com o funcionamento normal do sistema de excitação, os tiristores produzem energia

térmica que precisa ser removida para evitar o seu superaquecimento. A remoção deste calor é

feita através de um ventilador helicoidal que direciona um fluxo de ar de baixo para cima

(conforme ilustrado na figura 27). Ao passar pela ponte de tiristores, o ar absorve parte da

energia térmica produzida nos tiristores. Em seguida, o ar chega ao teto do armário e, não

tendo por onde escapar, pois o armário é totalmente fechado, desce pelas laterais e circula

pela parte inferior do radiador do trocador de calor. Após isso, já agora no sentido ascendente,

o ar é sugado pelo ventilador. Este processo é chamado de convecção. O trocador de calor

possui uma serpentina onde circula a água fria responsável por retirar o calor do ar quente

vindo dos tiristores.

A etapa final do processo de alimentação do circuito de campo da unidade geradora

consiste em aplicar a corrente continua, produzida pela ponte retificadora dos armários do

sistema de excitação, ao enrolamento de campo da unidade, o qual fica localizado no rotor da

máquina. Isto é feito por meio de contatos elétricos entre um conjunto de escovas, localizada

na parte fixa da máquina, que faz contato elétrico com um conjunto de anéis deslizantes, os

quais giram com a mesma velocidade angular do rotor e estão eletricamente ligados

diretamente aos terminais do enrolamento de campo do gerador (figura 28).

Figura 28: Sistemas de Escovas e de Anéis deslizantes, para aplicação da corrente produzida pela ponte

retificadora ao enrolamento de campo da máquina síncrona. Fonte: Elaborada pelo autor (2007).

Escovas

(fixas)

Anéis deslizantes (girantes)

66

5.3.2 Sistema de alarmes e de tratamento de defeitos em cada armário da ponte de

titistores

O tratamento dos defeitos nos armários de retificação é realizado localmente, em cada

armário, e a nível de reagrupamento nos painéis do comando do gerador, através de bornes de

saída nos armários de retificação. Cada armário possui um conjunto de lâmpadas de

sinalização e botões de rearme de defeito e de teste de lâmpadas. Os defeitos (faltas) na ponte

retificadora e subsistema de arrefecimento dos tiristores são sinalizados através de um painel

com lâmpadas sinalizadoras indicando uma mensagem associada ao defeito (figura 29). Cada

falta corresponde ao fechamento de um contato lógico que ativa a lâmpada sinalizadora do

respectivo alarme. Dentre as faltas sinalizadas estão: defeito no ventilador exaustor, falha de

condução ou de curto-circuito dos tiristores da ponte retificadora, temperatura dos tiristores

acima do limiar, e falta de circulação de água no sistema de trocador de calor.

Figura 29: Quadro de sinalização de defeitos em um dos armários da ponte retificadora.


Conforme é possível observar, o sistema de excitação de campo dos geradores da 1a

fase da UHE de Tucuruí é um sistema de elevado grau de complexidade, apresentando um

número considerável de subsistemas susceptíveis à falhas de natureza elétrica ou mecânica ou

térmica. Dessa forma, o número de variáveis passíveis de serem monitoradas pode se tornar

excessivamente grande. No entanto, observa-se que determinados subsistemas são muito mais

críticos ao funcionamento do sistema, pois uma falha em desses elementos implicaria na

necessidade de parada imediata da máquina, para evitar danos maiores aos equipamentos.

67

Dentre as grandezas cuja medição contínua é importante para o monitoramento do sistema

estão:

A temperatura do tiristores.

O fluxo do refrigerante, em cada armário.

Temperatura, valor RMS da corrente, e vibração do ventilador em cada armário.

As formas de ondas e pulsos dos circuitos de disparo.

O valor RMS das correntes nos tiristores.

O desgaste das escovas.

Foi observado, nos levantamentos de campo efetuados, a necessidade de medição das

grandezas, seu condicionamento local e a comunicação dos dados adquiridos até a sala de

controle da unidade geradora. Como o número de pontos de medição pode se tornar

consideravelmente grande, a solução de transmissão no padrão convencional de 4-20ma não é

indicada, pois isso implicaria em um número excessivo de fiação para comunicação dos

dados. Dessa forma, a solução adotada foi desenvolver um sistema remoto para medição

embarcada do desgaste das escovas, o qual se comunica com um computador na sala de

controle através de protocolo MODBUS e a implementação de um sistema de aquisição de

dados utilizando rede de barramento de campo (PROFIBUS), para a aquisição remota dos

dados das grandezas dos armários de tiristores da unidade geradora.

5.4 PROJETO E DESENVOLVIMENTO DO SISTEMA DE AQUISIÇÃO DE DADOS

O sistema de aquisição de dados é composto de sistema distribuído, composto de um

subsistema remoto, para medição das grandezas do armário e de um outro subsistema remoto,

destinado a medir o desgaste das escovas do gerador. Ambos se comunicam com um sistema

de monitoramento baseado em agentes inteligentes, que executa em um computador PC

industrial na sala de controle da unidade geradora. O sistema de medição das grandezas do

armário é composto de sensores e de um controlador, o sistema de monitoramento está

projetado de modo trocar informações com os demais sistemas da UHE.

68

5.4.1 Configuração e arquitetura do sistema de aquisição de dados e monitoramento

As variáveis importantes para aquisição são os valores das grandezas do armário de

tiristores, principalmente as temperaturas e sinais lógicos de alarme, além da medição do nível

do desgaste das escovas em contato com os anéis deslizantes no rotor do gerador. Para

aquisição dos sinais dos armários de tiristores, foi desenvolvido um sistema remoto baseado

em um contrador lógico programável (modelo Siemens S7-200, figura 30), que tem a função

de adquirir as medidas das grandezas nos armários de tiristores (figura 30). Os dados

adquiridos, são transmitidos remotamente para um computador do tipo PC industrial, que se

localiza na sala de controle da unidade geradora. No PC industrial é executado o software

para monitoramento baseado em agentes, desenvolvido neste projeto.

A comunicação entre o CLP de aquisição de dados e o PC industrial e realizada

através do padrão de barramento de campo Profibus DP. A distância entre o CLP e o

computador industrial é de aproximadamente 100 metros, enquanto que a distância

máxima dos sensores ao CLP é na faixa de 15 metros. A razão para a escolha do padrão,

para a transmissão das grandezas dos armários de tiristores, foi em razão da elevada taxa

de comunicação de dados permitida, facilitando a expansão futura do número de variáveis

a serem adquiridas, caso isso seja necessário. As medidas referentes ao desgaste das

escovas são realizadas através de sistema embarcado na cúpula do rotor da UHG1, o qual

foi desenvolvido no projeto para essa finalidade, e que se comunica com o PC industrial

no padrão de comunicação MODBUS sobre RS-485 (figura 31).

Figura 30: Sistema de aquisição dos sinais provenientes dos armários de tiristores.


69

Figura 31: Diagrama esquemático do sistema de aquisição de dados, incluindo a medição

remota do desgaste das escovas do gerador.


O computador PC industrial, na sala de controle, executa dois sistemas. Primeiramente

é executado em software no Labview(figura 32), o qual tem a função de receber os dados e

prepará-los para serem tratados no sistema multi-agente. A razão da escolha desse sistema foi

a facilidade com que o labview trabalha com aquisição e tratamento de dados e com a

comunicação com outras tecnologias. Abaixo é exibida a interface gráfica criada no sistema

em Labview para validar os dados de entrada.

Figura 32: Sistema de aquisição intermediária em Labview


70

Finalmente, têm-se o software desenvolvido no projeto para realizar o monitoramento

inteligente no sistema, o qual é baseado na tecnologia de agentes. O sistema de agentes possui

uma base de dados local e pode se comunicar via tecnologia de socket com o labview para ler

as grandezas monitoradas. A tecnologia de socket consiste em uma forma simples de comunicar

dois sistemas feitos em tecnologias diferentes. A tecnologia permite o compartilhamento e uma

determinada porta no computador, pela qual os sistemas heterogêneos escrevem e lêem. Desta

forma, o sistema em labview escreve os dados que chegam do CLP em uma determinada porta e

o sistema baseado em agentes lê e processa a informação.

Além disso, o sistema de monitoramento está projetado para se integrar, via rede local

intranet da UHE, com outros aplicativos executando nas salas da Engenharia e na Sala do

Sistema de Supervisão da UHE, permitindo assim a atualização das respectivas bases de

dados desses sistemas, incorporando a análise de tendências e histórico de eventos

disponibilizado pelo sistema baseado em agentes. A arquitetura do sistema de monitoramento

baseado em agentes será detalhado mais a frente.

5.5 DESENVOLVIMENTO E IMPLEMENTAÇÃO DO SOFTWARE DO SISTEMA DE

MONITORAMENTO BASEADO EM AGENTES

É no computador industrial que está presente o sistema para a detecção e o diagnóstico

de faltas. Ao receber os dados, o sistema os armazena em um banco de dados, função esta de

um dos agentes do sistema: o agente de banco de dados, que também é responsável por todas

as outras funções relacionadas ao banco de dados como leitura, escrita, alteração e exclusão

de dados. Um outro agente a exercer uma importante função no sistema é o agente de

aquisição de dados, o qual é responsável pelo tratamento dos dados armazenados no banco de

dados. Por isso, esse agente deve interagir com o agente de banco de dados.

Para os testes necessários ao desenvolvimento do sistema, implementou-se, em

laboratório, um arranjo composto por dois computadores PCs (figura 33). O primeiro

computador é usado para simular, em tempo real, o comportamento do sistema, gerando sinais

que simulam medidas remotas, as quais são enviadas ao computador de monitoramento

através da interface RS-232 ou de rede local, utilizando-se o formato do protocolo MODBUS

para o envio dos dados. O sistema de testes facilita o desenvolvimento do sistema de agentes,

permitindo simular defeitos que, embora prováveis, são de rara ocorrência na planta real.

71

Agente de Banco

de Dados

Agente de

Diagnóstico de

Faltas

Agente de

Aquisição de

Dados

Agente de

Processamento

de Sinais

MATLAB

Dinâmica do

Processo

Simular o

Processo

Dinâmico

DDE

C++ ou Java

Sistema Remoto

de Aquisição de

Dados

RS-232 RS-232

Computador Comum Computador Industrial

Rede

Computador da

EmpresaBanco de

Dados da Usina

Agente de

Interface de

UsuárioAgente de

Interface com

Sistema da ELNBanco de

Dados

MODBUS RTU

“CLP”

Aquisição de

Dados

Figura 33: Diagrama do Sistema para Testes.


5.6 ANÁLISE E PROJETO DO SISTEMA BASEADO EM AGENTES INTELIGENTES

5.6.1 Visão geral do Sistema

O operador se registrará ao sistema e selecionará qual a máquina a monitorar. O

operador então pode iniciar a análise e verificar as condições relacionadas diretamente à

máquina e seus armários de tiristores e condições do sistema de escovas. Caso queira um

nível de detalhe maior, o sistema de monitoramento disponibilizará visões mais detalhadas. O

operador poderá navegar em um nível de profundidade que julgar adequado para a análise.

Por exemplo, podem ser visualizados os Braços de Tiristores de um determinado armário da

ponte. Em todos estes cenários o operador especifica qual variável que deseja monitorar. As

possibilidades são: Temperatura no braço de determinado Tiristor, Tensão de junção do

Tiristor, Temperatura do armário, Condição de Vazamento do armário, Corrente de campo da

máquina e Tensão de campo da máquina. Os dados são recebidos e atualizados diretamente da

planta em um período de aproximadamente 1 segundo.

O Sistema continuamente atualiza sua base dados em relação as variáveis monitoradas.

Portanto sempre que alguma anomalia for detectada nesses dados, o sistema automaticamente

deve gerar uma notificação ao operador ou setor responsável, descrevendo em detalhes a falta

ocorrida, tempo de ocorrência do evento, o local específico de ocorrência, e sugestões de

possíveis causas e soluções.

72

O sistema continuamente atualiza sua base de dados em relação as variáveis

monitoradas e, além disso, faz análises acerca destes dados tentando identificar padrões.

Certos padrões nos dados podem indicar a ocorrência de falhas incipientes as quais, caso não

diagnosticadas, poderiam implicar em necessidade futura de parada da máquina por falha

destrutiva. A partir da análise destes dados é possível prever e informar o setor ou operador

responsável de possíveis faltas que venham a ocorrer em um determinado equipamento. Como

o sistema possui um controle criterioso de todas as variáveis de interesse, é possível

identificar o local exato da ocorrência da falta e as possíveis causas.

5.6.2 Levantamento de requisitos

Nessa etapa varias reuniões foram feitas junto aos engenheiros e técnicos da UHE de

Tucuruí com o objetivo de levantar os requisitos do sistema a ser implementado. Para

documentar o que foi discutido, foi utilizado o documento de especificação de requisitos de

software oriundo do Processo Institucional de Desenvolvimento de Software (PIDS)

desenvolvido por pesquisadores do Instituto de Ensino Superiores da Amazônia (IESAM).

Abaixo é exibido o referido documento.

- Especificação de requisitos de software

Tabela 1 - Descrição geral do documento

Título: Gerenciamento de informações acerca de determinadas condições em um sistema industrial de geração

de energia elétrica.

Cliente/endereço: Eletronorte

Identificação do item: Nome do Produto/ Serviço:

Característica:

Executante(s): Adolfo Sena, Bárbara Medeiros, Cynthia Leal, Igor Simões, Marcus Pantoja, Walter Barra Jr.

Versão: 1.0

Equipe executante:

Adolfo Sena, Bárbara Medeiros, Cynthia Leal, Igor Simões, Marcus Pantoja.

Descrição resumida do serviço:

O sistema está sendo construído para que os operadores e engenheiros da UHE de Tucuruí possam acompanhar

em tempo real determinadas condições no sistema de geração de energia elétrica. Esta aplicação possibilitará um

conhecimento vasto a partir do registro do histórico dos dados coletados e com isso permitirá análises atuais e

futuras a respeito da “saúde” das máquinas monitoradas.

Norma/instrução técnica utilizada:

Informações Adicionais:

Data da emissão do Documento: 25/09/2006

73

Objetivos deste documento

Definir de uma forma geral e posteriormente especifica o sistema de monitoração proposto.

- Escopo do produto

Nome do produto e de seus componentes principais

O Produto ainda não tem um nome específico. Os principais componentes do sistema são caracterizados por

agentes, que representam módulos do sistema. Cada agente será responsável por determinada função como por

exemplo: Interface com o usuário, Aquisição de dados, Interface com o Banco de dados, etc. A colaboração entre

estes componentes concretizará os objetivos do sistema.

- Missão do produto

Apoio informatizado aos operadores do sistema da UHE de Tucuruí no sentido de aperfeiçoar a detecção de

possíveis problemas que venham a ocorrer no sistema de geração.

- Limites do produto

O Sistema não fará Aquisição de variáveis inerentes ao sistema de troca de calor.

- Benefícios do produto

Tabela 2 – Benefícios do produto

Nº de Ordem Benefício Valor para o cliente

1

2

3

4

5

6

7

Visualização remota dos dados monitorados

Indicações de faltas Incipientes

Indicações de Faltas Instantâneas

Indicações de possíveis causas e soluções para as faltas

Facilidade de visualização das variáveis

Facilidade de Manutenção

Escalabilidade

Essencial

Essencial

Essencial

Essencial

Desejável

Desejável

Essencial

- Materiais de referência

Tabela 3 – Matérias de referência

Nº de Ordem Tipo do material Referência bibliográfica

1 Entrevista Entrevista feita com o coordenador do projeto.

2 Relatório Projeto de especificação do software de monitoração

3 Padrão PIDS - Processo IESAM de Desenvolvimento de Software.

74

- Definições e siglas

Tabela 4 – Definições e siglas

Nº de Ordem Sigla Definição

1 UHE Usina Hidrelétrica de Tucuruí

2 PIDS Processo institucional de desenvolvimento de software

3 SGBD Sistema Gerenciador de Banco de Dados

- Visão geral deste documento

De acordo com o Padrão para Especificação de Requisitos de Software, ou seja:

Parte 2: Descrição geral do produto

Parte 3: Requisitos específicos

Parte 4: Informação de suporte - listagens do Modelo de Análise

- Descrição geral do produto / Perspectiva do produto

MONITORAÇÃO DE UMA VARIÁVEL EM TEMPO REAL

O operador se registrará no sistema e escolherá o Armário que contém a variável a ser

monitorada. Ao escolher o Armário, o operador visualiza os Braços de Tiristores presentes

naquele Armário e o Ventilador que auxilia na troca de calor. Neste momento o operador

especifica qual variável quer monitorar. As possibilidades são: Temperatura no braço de

determinado Tiristor, Disjuntor do Tiristor, Temperatura do armário, Corrente RMS do motor

do Ventilador. Os dados são recebidos e atualizados diretamente da planta em um período de

1 segundo.

SINALIZAÇÃO DE FALHAS INSTANTÂNEAS

O Sistema continuamente atualiza sua base dados em relação as variáveis

monitoradas. Portanto sempre que alguma anomalia é detectada nesses dados o sistema

automaticamente gera uma notificação ao operador ou setor responsável, descrevendo em

detalhes a falta ocorrida, o local específico de ocorrência, possíveis causas e soluções. Isso é o

que se chama comummente de sistema de alarme.

SINALIZAÇÃO DE FALHAS INCIPIENTES

O sistema continuamente atualiza sua base de dados em relação as variáveis

monitoradas e, além disso, faz análises acerca destes dados tentando identificar padrões.

Certos padrões nos dados podem indicar falhas que possam vir a ocorrer em um futuro

próximo ou distante, essas são as chamadas faltas incipientes. A parir da análise destes dados

75

é possível prever e informar o setor ou operador responsável de possíveis faltas que venham a

ocorrer em um determinado equipamento. Como o sistema possui um controle criterioso de

todas as variáveis de interesse, é facilmente identificável o local exato onde as faltas podem

ocorrer e as possíveis causas.

VERIFICAÇÃO DO HISTÓRICO DE FALHAS

O operador pode fazer uma breve consulta para checar o histórico de falhas em uma

determinada máquina, Armário ou mesmo em um único Tisristor ou Ventilador. O Sistema

gera informações acerca das faltas em quaisquer destas estruturas em um período de tempo

determinado pelo operador.

GERAÇÃO DE RELATÓRIOS PERIÓDICOS

O Operador pode visualizar com mais detalhes o que vêem ocorrendo em todas as

estruturas monitoradas do sistema. Desta forma o sistema oferece um relatório completo

gerado em períodos pré-configurados. As informações fornecidas dizem respeito a faltas

instantâneas, faltas incipientes, padrões identificados nos dados, previsões futuras baseadas no

comportamento atual dos dados.

- Diagrama de contexto – Primeiras iterações

Notificação de faltas InstantaneasNotificação de faltas incipientes

Monitoração de Variável

Verificação do Histórico de Falhas

Geração de Relatórios PeriodicosOperador

Notificação de Faltas

Figura 34: Diagrama de contexto.

Fonte: Elaborada pelo autor (2007)..

76

- Interfaces de usuário (tabela 5)

Tabela 5 – Interfaces de usuário

Nº de ordem Nome Ator Caso de uso Descrição

1 Monitoração de

variável

Operador Monitoração de

variável

O Sistema permite que o operador

monitore em tempo real determinada

variável.

2 Verificação do

Histórico de

Faltas

Operador Verificação do

Histórico de

Faltas

O Sistema gera um relatório on-line

informando o histórico de faltas detectadas

durante um período determinado pelo

operador em uma determinada máquina.

3 Geração de

relatórios

periódicos

Operador Geração de

relatórios

periódicos

O Sistema gera automaticamente relatório

periódicos para funções gerenciais. Este

relatório se diferencia do anterior na

medida que contém informações mais

detalhadas acerca das condições de

operação de todas as máquinas

monitoradas. É um relatório voltado a

parte gerencial, em um nível de

formalismo mais adequado.

4 Notificação de

faltas

Operador Notificação de

faltas

O Sistema notifica o operador quando

alguma falta é detectada.

5 Notificação de

faltas

incipientes


faltas incipientes


existe padrões nos dados coletados que

indiquem uma possível falta futura em

determinada máquina.

6 Notificação de

faltas

Instantâneas


faltas Instantâneas


ocorrem faltas instantâneas denotadas

através dos dados coletados.

- Modos de operação (tabela 6)

Tabela 6 – Modos de operação

Nº de Ordem Tipo de

operação

Descrição da

operação

Detalhes de Operação

1 Operação Analisar o

comportamento

das variáveis do

sistema.

Nessa etapa o operador analisa em tempo real as variáveis

do sistema, bem como é notificado de faltas que vierem a

ocorrer.

2 Administração Cadastrar/alterar

entidades,

variáveis e

usuários.

Nessa etapa o administrador informa o sistema dos

usuários, das variáveis analisadas e das entidades que

contém essas variáveis.

77

- Funções do produto (tabela 7)

OBS: Os casos de uso serão detalhados em seção própria.

Tabela 7 – Funções do produto

Nº de Ordem Caso de uso Descrição

XXXX XXXX XXXX

- Usuários e sistemas externos (tabela 8)

Tabela 8 – Usuários do sistema

Nº de Ordem Ator Definição

1 Operador Usuário nomeado pela Eletronorte para monitorar as variáveis, diagnosticar

falhas, causas, soluções e tomar medidas a partir disso.

2 Administrador Funcionário da Eletronorte responsável por cadastrar e controlar os usuários

do sistema, bem como as entidades e variáveis relacionadas do sistema.

3 Gerente Usuário responsável por análises de alto nível acerca do comportamento do

sistema de excitação.

- Características dos usuários (tabela 9)

Obs: Essas informações não foram fornecidas pela empresa.

Tabela 9 – Informações acerca dos usuários

Nº de

Ordem

Ator Freqüência de

uso

Nível de

instrução

Proficiência na

aplicação

Proficiência em

informática

XXXX XXXX XXXX XXXX XXXX XXXX

- Restrições (tabela 10)

Tabela 10 – Restrições do sistema

Nº de Ordem Restrição Descrição

1 Segurança O produto deverá restringir o acesso através de senhas individuais para cada usuário.

2 Escalabilidade O sistema deve ser informado acerca de cada nova variável a ser monitorada

para que a mesma possa ser analisada.

- Hipóteses de trabalho (tabela 11)

Tabela 11 – Hipóteses de trabalho

Nº de Ordem Hipótese De quem depende

1 Pode ser utilizado o SGBD Oracle para otimizar a

performance no acesso aos dados e permitir um número

maior de operações acerca dos dados.

Coordenação do Projeto

2 Pode ser utilizada a ferramenta Jbuilder para

desenvolver o Sistema propriamente dito.

Coordenação do Projeto

3 Pode ser utilizado framework JADE para

desenvolvimento da plataforma de agentes

Estudos entre as possíveis alternativas

de frameworks de agentes.

78

- Requisitos de interface externa

INTERFACES DE USUÁRIO

Interface de usuário << nome da interface >>

Layout sugerido (figura 35)

Figura 35: Interfaces do usuário.


- Requisitos funcionais

DIAGRAMAS DE CASOS DE USO

Os diagramas de casos de uso serão detalhados mais adiante.

Diagrama de estado / Diagrama de atividade

O sistema possui um número vasto de diagramas de atividade. Esses diagramas serão

analisados detalhadamente em seção própria.

Diagramas de seqüência

Os diagramas de seqüência também serão detalhados adiante.

- Requisitos não funcionais

REQUISITOS DE DESEMPENHO

Requisito de desempenho << nome do requisito >>

O sistema deve monitorar as variáveis de forma periódica. Este período não pode ultrapassar 1 segundo. De

acordo com a natureza das variáveis (temperatura e desgaste nas escovas) esse período é bastante aceitável.

79

5.6.3 Arquitetura do Sistema Multi-agente (SMA)

Figura 36: Arquitetura do sistema multi-agente (sma).


A Figura 36 exibe a arquitetura do sistema multi-agente, em que são expostos os

agentes que fazem parte do sistema global. Cada agente possui uma função específica e a

partir da cooperação entre eles os objetivos globais do sistema são atingidos. Os agentes

foram projetados de forma bastante modular e independente, de forma que a alteração em um

não afeta os demais. A seguir é feita uma explanação mais detalhada acerca de cada agente.

- Agente Supervisor

Agente responsável pela supervisão do sistema quando ele é iniciado. Suas tarefas são:

Se comunicar com o Labview para que este inicie o processo de aquisição e envio dos

dados.

Criar a interface gráfica principal do sistema que irá permitir a criação dos demais agentes

do sistema.

Criar o agente de Aquisição e deixá-lo pronto para receber as mensagens vindas do

Labview.

Criar o agente de banco de dados para que o mesmo esteja apto a receber as informações

e armazená-las no banco.

Habilitar ou desabilitar os agentes de detecção para que eles registrem ou deixem de

registrar informações acerca das anomalias.

80

Desconectar do Labview.

Finalizar o envio das informações. Nessa situação o Labview apenas deixa de enviar as

informações, porém os dois sistemas permanecem conectados.

Desconectar do sistema Labview, o que faz com que os dois sistemas deixem de se

comunicar.

- Agente de Aquisição

Agente responsável por “pegar” os dados oriundos do Labview através da tecnologia

de socket, colocá-los no formato adequado e enviá-los ao agente de banco de dados para que

o mesmo salve os dados.

- Agentes de detecção

Agentes responsáveis por detectar anomalias nos dados recebidos e registrar as

informações acerca das mesmas.

Suas principais funções são:

Enviar uma mensagem ao agente de banco de dados requisitando os dados que ainda não

foram checados.

Receber esta mensagem e checar se os dados estão dentro dos limiares aceitos.

Caso haja alguma anomalia, o agente migra para a máquina do operador responsável pela

variável que apresenta a anomalia e nesta nova máquina registra em um arquivo de texto

todas as informações acerca do problema, tais como: nome da variável, entidade a que

pertence (máquina, armário ou tiristor), selo de tempo, valor detectado. Essa é uma das

partes mais interessantes do sistema, uma vez que utiliza um dos principais atrativos da

tecnologia de agentes, a mobilidade transparente a qualquer máquina da rede.

- Agente de Interface em Tempo Real

O Agente de interface é responsável por exibir os dados em tempo real de

determinada(s) variável (eis). Suas principais funções são:

Criar uma interface gráfica que permita o operador iniciar o procedimento de análise.

81

Enviar uma mensagem ao agente de banco de dados requisitando as informações mais

atuais acerca de determinada (s) variável (eis).

Receber esta mensagem com as informações e se comunicar com a interface gráfica para

exibi-las.

Finalizar o processo a partir da interface gráfica.

- Agente de banco de dados

O agente de banco de dados é o principal agente do sistema. Ele é o único agente

capaz de acessar o banco de dados, por isso é o agente que mais recebe requisições e mais

coopera com outros agentes para que os mesmos possam atingir seus objetivos locais. Suas

principais funções são:

Inserir os dados em banco, quando isso for requisitado pelo agente de aquisição.

Enviar informações acerca das variáveis do sistema para os agentes de detecção, quando

isso for requisitado por eles.

Enviar informações para o agente de interface em tempo real, quando isso for requisitado

por ele.

Deletar automaticamente do banco de dados informações antigas acerca das variáveis.

5.6.4 Modelagem UML do Sistema Multi-agente (SMA)

- Modelagem de casos de uso

O primeiro passo do processo de modelagem é elaborar os diagramas de casos de uso.

Tais diagramas fazem parte da notação uml e representam a base de todo o processo de

modelagem que vem a seguir, uma vez que diagramas de atividades, seqüência e colaboração

derivam dele.

Os diagramas de casos de uso mostram como os valores são processados, sem

preocupações com: ordenamento (seqüência) das ações, decisões ou estruturas dos

objetos.

82

Os diagramas de casos de uso são muito utilizados pelo papel que exercem na análise

de sistemas, uma vez que são os principais diagramas a serem usados no diálogo com o

usuário na descoberta e validação de requisitos, alem de estruturarem todas as etapas do

processo de software.

Os principais elementos de um caso de uso são mostrados na Figura 37 abaixo:

Figura 37: Estrutura de casos de uso.


Existem várias formas de se organizar um diagrama de casos de uso. Neste trabalho

será utilizada uma modelagem orientada a usuário. Desta forma, como o sistema agrupa

apenas dois tipos de usuário (operador e administrador), serão montados dois cenários.

83

PRIMEIRO CENÁRIO: uma análise orientada ao operador

Figura 38: Caso de uso orientado ao operador.


Na Figura 38 temos o primeiro cenário do sistema multi-agente. Cenário este orientado

ao usuário operador, o qual é responsável pela monitoração e detecção das faltas relacionadas

às variáveis do sistema. A descrição detalhada desses casos de uso é feita oportunamente a

partir dos diagramas de atividade mais adiante.

84

SEGUNDO CENÁRIO: uma análise orientada ao administrador

Figura 39: Caso de uso orientado ao administrador.


A Figura 39 apresenta os casos de uso do usuário administrador. Esses casos de uso

estão relacionados ao cadastro e alteração das entidades do sistema (máquinas, armários e

tiristores), das variáveis relacionadas a estas entidades e dos usuários do sistema.

85

- Modelagem de diagramas de atividade

Neste momento, o sistema já possui suas funcionalidades delimitadas pelos diagramas

de casos de uso. Entretanto, estes diagramas, como já foi dito, não se preocupam com a

seqüência das ações ou com qualquer aspecto temporal. Desta forma, nesta nova etapa serão

construídos os chamados diagramas de atividade que possuem a função de detalhar o fluxo de

atividades necessárias à consecução dos casos de uso apresentados.

Cada caso de uso será detalhado em várias atividades, que por sua vez podem ser

detalhadas em outras atividades, dependendo da complexidade das mesmas.

Cenário 1: Operadores

Caso de uso Inicializar sistema(figura 40)

Figura 40: Diagrama de atividade – Inicializar sistema.


86

Descrição das atividades:

Entrar com os dados de login e senha para autenticar o operador;

Fazer uma consulta ao banco de dados e checar se os dados conferem;

Se não conferirem, permite mais três tentativas;

Caso os dados estejam corretos, cria a plataforma de agentes;

Cria o container principal que vai abrigar os agentes;

Por ultimo cria o agente supervisor.

- Agente supervisor

Ao criar um agente, essa nova entidade passa a agir de forma autônoma dentro do sistema a

partir dos chamados comportamentos, que podem ser alterados de acordo com os objetivos do

agente e dos estímulos recebidos do ambiente externo. Abaixo é detalhada a seqüência de

comportamentos do agente de aquisição(figura 41).

.

Figura 41: Diagrama de atividade – Agente supervisor.


87


Cria a interface gráfica principal que está vinculada ao agente supervisor. Essa interface

possui todas as funcionalidades oferecidas pelo sistema.

Recebe uma determinada ação ou pedido da interface gráfica.

Verifica que tipo de pedido foi feito.

Caso seja para habilitar os alarmes instantâneos, o agente supervisor dispara o

comportamento correspondente.

Caso seja para conectar, o agente supervisor troca para o comportamento responsável pela

conexão.

Caso o sistema já esteja conectado e o pedido seja para enviar requisição, o agente

supervisor alterna para o comportamento responsável pelo envio de requisições ao

labview.

Caso o agente supervisor receba da interface gráfica uma requisição para desconectar ou

finalizar o sistema, também alterna para os comportamentos correspondentes.

- Disparar comportamento alarme (figura 42)

Figura 42: Diagrama de atividade – Disparar comportamento alarme.



Cria mensagens endereçadas aos agentes de detecção para habilitar ou desabilitar suas

operações.

Identifica os agentes de detecção através de nomenclaturas pré-especificadas.

88

Dependendo do tipo de ação (habilitar ou desabilitar)

Envia mensagem para que os agentes de detecção já criados parem de operar e se retirem

do container.

Se for para habilitar, então cria os agentes de detecção e os coloca em operação.

Obs: As demais atividades do agente supervisor serão explicadas em um momento oportuno

mais adiante.

- Caso de uso conectar (figura 43)

Figura 43: Diagrama de atividade – Conectar.



O operador seleciona a opção de conectar e uma mensagem é enviada da interface gráfica

ao agente supervisor.

O agente supervisor recebe a mensagem.

O agente supervisor envia uma mensagem à aplicação no labview através da tecnologia de

socket, autorizando a conexão entre os dois sistemas que se estabelece a partir daí.

89

- Caso de uso enviar requisição(figura 44)

Figura 44: Diagrama de atividade – Enviar requisição.



O operador seleciona a opção de enviar requisição e uma mensagem é enviada da

interface gráfica ao agente supervisor.

O agente supervisor recebe a mensagem.

O agente supervisor envia uma mensagem à aplicação no labview através da tecnologia de

socket, autorizando o inicio do processo de aquisição e o envio dos dados entre os dois

sistemas.

O agente supervisor cria o agente de banco de dados.

O agente supervisor cria o agente de aquisição.

90

- Agente de Banco de dados (figura 45)

Figura 45: Diagrama de atividade – Agente de banco de dados



Cria um container de comportamentos que são executados de forma paralela ou concorrente.

Cria comportamento responsável pela comunicação com o agente de aquisição.

Cria comportamento responsável pela comunicação com o agente de detecção de máquina.

Cria comportamento responsável pela comunicação com o agente de detecção de armário.

Cria comportamento responsável pela comunicação com o agente de detecção de tiristor.

Cria comportamento responsável pela comunicação com o agente de monitoração em

tempo real individual.

Cria comportamento responsável pela comunicação com o agente de monitoração em

tempo real geral.

91

Adciona todos os comportamentos ao container de comportamentos.

Cria e adiciona o comportamento monitorar dados, responsável por excluir do banco de

dados informações antigas e não mais úteis. O principal objetivo deste comportamento é

evitar um número exorbitante de registros no banco.

- Comportamento responsável pela comunicação com o agente de aquisição (figura 46)

Figura 46: Diagrama de atividade – Agente de banco de dados / Agente de aquisição.



Receber e processar apenas as mensagens oriundas do agente de aquisição.

Analisar a mensagem e obter as informações da variável que está sendo recebida.

A partir das informações acerca da variável, seu valor, selo de tempo, entidade

relacionada, o agente de banco de dados insere as informações no banco de dados.

- Comportamento responsável pela comunicação com os agentes de detecção (figura 47)

Figura 47: Diagrama de atividade – Agente de banco de dados / agentes de detecção.


92


Receber e processar apenas as mensagens oriundas dos agentes de detecção.

Recuperar as informações do banco de dados relacionadas a todas as variáveis das

entidades monitoradas (máquina, armário e tiristor).

Preparar as informações para serem enviadas aos agentes de detecção.

Enviar a mensagem aos agentes de detecção contendo o valor das variáveis monitoradas

para posterior análise.

- Comportamento responsável pela comunicação com os agentes de monitoração em tempo

real individual e geral (figura 48)

Figura 48: Diagrama de atividade – Agente de banco de dados / agentes de monitoração.



Receber e processar apenas as mensagens oriundas dos agentes de monitoração.

Verificar as informações requeridas pelos agentes de monitoração.

Recuperar as informações do banco de dados relacionadas a todas as variáveis requeridas.

Enviar a mensagem aos agentes de monitoração contendo o valor das variáveis requeridas

para posterior exibição.

93

- Caso de uso finalizar sistema (figura 49)

Figura 49: Diagrama de atividade – Finalizar sistema.



O operador seleciona a opção finalizar sistema e a interface envia uma mensagem ao

agente supervisor.

O agente supervisor recebe a mensagem

O agente supervisor verifica se a conexão está ativa. Caso esteja, o agente supervisor

envia uma mensagem ao labview para que o mesmo finalize o processo de envio dos

dados. Caso contrário, os dois sistemas já não se comunicam mais.

- Caso de uso monitoração especifica (figura 50)

Figura 50: Diagrama de atividade – Monitoração específica.


94


O operador seleciona a entidade a ser monitorada (máquina, armário ou tiristor).

O operador seleciona o elemento especifico (determinada máquina, armário ou tiristor).

O operador seleciona a variável a ser monitorada (temperatura, desgaste nas escovas, etc.).

O sistema cria o agente de monitoração em tempo real individual.

- Agente de monitoração em tempo real individual (figura 51)

Figura 51: Diagrama de atividade – Monitoração em tempo real individual.



O agente de monitoração recebe os dados acerca da entidade a ser monitorada e da

variável especifica.

O agente de monitoração cria a interface de monitoração.

O operador seleciona opção de iniciar ou finalizar a monitoração e a interface envia uma

mensagem ao agente de monitoração.

Caso seja uma mensagem para iniciar a monitoração, o agente executa o comportamento

para iniciar monitoração.

Caso seja uma mensagem parta finalizar, o agente de monitoração finaliza suas ações e se

retira do container.

95

- Comportamento Iniciar Monitoração (figura 52)

Figura 52: Diagrama de atividade – Iniciar Monitoração individual.



O agente de monitoração envia uma mensagem ao agente de banco de dados requisitando

os dados a serem monitorados acerca de uma única variável.

O agente de monitoração fica aguardando uma resposta

Ao receber a mensagem, o agente de monitoração recupera os dados.

O agente de monitoração repassa os dados à interface gráfica.

A interface gráfica exibe os dados em tempo real.

- Caso de uso Monitoração geral (figura 53)

O operador seleciona a opção monitoração geral e o agente de monitoração geral é

criado. Seu comportamento é descrito abaixo.

96

Figura 53: Diagrama de atividade – Monitoração geral.



O agente de monitoração geral cria a interface gráfica que irá exibir os dados.

O operador seleciona uma das opções da interface: Iniciar ou finalizar. E uma mensagem é

enviada ao agente de monitoração.

Caso seja iniciar, o agente de monitoração executa o comportamento Iniciar monitoração.

Caso seja finalizar, o agente de monitoração finaliza suas atividades e se retira do

container.

- Comportamento Iniciar monitoração (figura 54)

Figura 54: Diagrama de atividade – Iniciar monitoração geral.


97


O agente de monitoração envia uma mensagem ao agente de banco de dados requisitando

os dados a serem monitorados acerca das cinco principais variáveis do sistema:

temperaturas dos quatro armários e o desgaste nas escovas da máquina.

O agente de monitoração fica aguardando uma resposta.

Ao receber a mensagem, o agente de monitoração recupera os dados.

O agente de monitoração repassa os dados à interface gráfica.

A interface gráfica exibe os dados em tempo real.

- Caso de uso Habilitar alarmes instantâneos (figura 55)

Figura 55: Diagrama de atividade – Habilitar alarmes instantâneos.



O agente supervisor cria o agente de detecção de máquinas

O agente supervisor cria o agente de detecção de armários

O agente supervisor cria o agente de detecção de Tiristores

- Agentes de detecção

O diagrama a seguir (figura 56) mostra a operação dos agentes de detecção de máquina,

armário e tiristor, uma vez que o funcionamento deles é similar.

98

Figura 56: Diagrama de atividade – Agentes de detecção.



O agente de detecção estabelece o canal de comunicação com o agente de banco de dados.

O agente de detecção envia uma requisição ao agente de banco de dados.

O agente de detecção recebe os dados do agente de banco de dados.

O agente de detecção recupera os limites acerca das variáveis.

O agente de detecção checa se as variáveis estão dentro dos limites.

Caso haja alguma anomalia, o agente de detecção migra para a máquina do operador

responsável pela variável e executa os procedimentos de alarme.

99

- Diagramas de seqüência

- Seqüência de atividades para a aquisição de dados (figura 57)

Figura 57: Diagrama de seqüência – Aquisição.


Descrição da seqüência:

O agente supervisor cria a interface gráfica principal

Através da interface o operador manda uma mensagem ao agente supervisor para se

conectar com a aplicação do labview.

O agente supervisor envia uma mensagem ao labview para se conectar.

O labview retorna a conexão.

O operador através da interface envia uma mensagem ao agente supervisor requisitando os

dados.

O agente supervisor envia a requisição ao labview.

O agente supervisor cria o agente de aquisição que fica esperando os dados chegarem da

aplicação do labview.

100

A aplicação do labview envia os dados diretamente ao agente de aquisição.

O agente de aquisição se conecta com agente de banco de dados enviando uma proposta.

O agente de banco de dados envia a resposta concordando e estabelecendo a conexão.

O agente de aquisição envia ao agente de banco de dados às informações a serem inseridas

em banco.

O agente de banco de dados insere as informações e envia uma mensagem ao agente de

aquisição confirmando a transação.

- Seqüência de atividades para a detecção das anomalias(figura 58)

Figura 58: Diagrama de seqüência – Detecção de anomalias.



O agente de detecção envia uma proposta ao agente de banco de dados para estabelecer

uma conexão.

O agente de banco de dados concorda ou recusa a proposta, estabelecendo ou não a

conexão.

Caso a conexão esteja estabelecida, o agente de banco de dados envia as informações

acerca das variáveis ao agente de detecção.

101

Caso alguma anomalia seja detectada, as informações acerca da anomalia são repassadas à

máquina do operador responsável.

- Seqüência de atividades para a monitoração dos dados (figura 59)

Figura 59: Diagrama de seqüência – Monitoração.



O operador através da interface gráfica dá inicio ao processo de monitoração, enviando

uma mensagem ao agente de interface de monitoração.

O agente de interface envia uma proposta ao agente de banco de dados para estabelecer a

conexão.

O agente de banco de dados pode concordar ou recusar, estabelecendo ou não a conexão.

102

Caso a conexão esteja estabelecida, o agente de banco de dados repassa as informações a

serem monitoradas ao agente de interface.

O agente de interface repassa as informações à interface de monitoração.

O operador através da interface gráfica finaliza a monitoração, enviando uma mensagem

ao agente de interface.

O agente de interface envia uma mensagem ao agente de banco de dados para finalizar o

envio de informações

O agente de banco de dados confirma o recebimento da mensagem e a finalização do

processo.

103

6 RESULTADOS OBTIDOS

6.1 DESCRIÇÃO DAS FUNCIONALIDADES DO SISTEMA

Monitoração on-line e individual de variáveis do sistema

Monitoração do Quadro geral das 5 variáveis de interesse do projeto pelo Sistema.

(Temperaturas dos 4 Armários e o desgaste das escovas)

Alarmes instantâneos

Monitorar Agentes (RMA)

Cadastro e alteração de máquinas

Cadastro e alteração de armários

Cadastro e alteração de tiristores

Cadastro e alteração de variáveis

Cadastro e alteração de usuários

6.2 APRESENTAÇÃO INICIAL DO SISTEMA

Figura 60: Autenticação inicial.


Descrição:

Esta é a tela inicial do sistema (figura 60), onde os operadores autorizados poderão se

autenticar para a partir daí utilizarem o sistema.

104

Figura 61: Interface principal – operação.


Descrição:

Após a fase de autenticação o operador é levado a tela inicial da aplicação (figura 61).

Pode-se observar que existem duas “abas” presentes. A aba Operação e a aba Administração.

A primeira é composta dos seguintes Botões:

Conectar: Esse botão permite fazer a conexão com o sistema labview que enviará as

informações acerca das variáveis monitoradas.

Enviar Requisição: Esse botão permite que o Sistema Multi-Agente envie uma requisição

para o sistema implementado no labview indicando que o processo de monitoração pode

ser iniciado.

Finalizar Sistema: Esse botão finaliza o sistema, enviando uma mensagem ao labview

para que o mesmo cesse o processo de Aquisição e envio dos dados.

Monitoração em Tempo Real: Esse botão permite a monitoração on-line das variáveis de

forma individual. É uma das funcionalidades nucleares do sistema e será objeto de um

maior detalhamento mais adiante.

Monitorar Agentes (RMA): Esse botão permite a monitoração dos agentes da Aplicação. É

uma ferramenta independente que deve ser utilizada por quem já está familiarizado com ela.

Desabilitar Alarmes Instantâneos: Esse botão permite desabilitar os alarmes instantâneos

que são disparados automaticamente sempre que alguma variável apresenta uma condição

de anomalia.

Quadro Geral: Esse botão permite uma visualização geral de todas as variáveis propostas

no projeto de maneira bem amigável. É uma funcionalidade que será mais detalhada

adiante.

105

A aba Administração é explicada a seguir.

Figura 62: Interface principal – administração.


Descrição:

Na aba administração (figura 62) estão as funções relacionadas aos elementos

trabalhados pelo sistema. Em cada um desses botões o usuário deverá informar os elementos

que serão analisados pelo sistema, tais como as máquinas, armários, Tiristores, variáveis

relacionadas a cada um destes elementos e os usuários que terão acesso ao sistema. Cada

entidade será explicada adiante com mais detalhes.

6.3 FUNCIONALIDADES DO SISTEMA

A partir deste momento o Sistema multi-agente está conectado e recebendo

informações da planta industrial por meio do labview. Sendo assim, pode-se realizar os

procedimentos para monitoração das variáveis. Além disso, serão detalhadas as

funcionalidades de administração do sistema.

106

6.3.1 Monitoração on-line e individual de variáveis do sistema

Passo 1:

Como neste momento o sistema já está conectado, o primeiro passo é acionar o botão

Monitoração em tempo real (figura 63).

Figura 63: Monitoração individual – passo 1.


Passo 2:

Nesse momento deve-se escolher qual entidade a monitorar. Por exemplo, se deseja-se

monitorar a temperatura de um determinado armário, deve-se acionar o botão Armário como

ilustra a figura 64. Ou ainda, se a intenção for monitorar o desgaste das escovas de uma

determinada máquina, deve-se acionar o botão Máquina.



107

Passo 3:

Se, por exemplo, deseja-se monitorar a temperatura de um determinado armário,

conforme explicado no passo anterior, então deve-se escolher a Máquina que contém este

armário, o Armário especifico e por fim a variável a ser monitorada (figura 65).



Passo 4:

Neste momento já se sabe que variável especifica se quer monitorar, portanto basta

acionar o botão Iniciar (figura 66) para que os dados fiquem disponíveis em tempo real

conforme mostrado abaixo. A qualquer tempo o operador pode finalizar o processo acionando

o botão Finalizar.



108

6.3.2 Monitoração do Quadro geral das 5 variáveis de interesse do projeto pelo Sistema.

(Temperaturas dos 4 Armários e o desgaste das escovas)

Passo 1:

Para fazer uma análise geral das variáveis estudadas pelo projeto, basta acionar o

botão Quadro Geral (figura 67).

Figura 67: Monitoração geral – passo 1.


Passo 2:

Neste momento o quadro geral é exibido (figura 68) e o operador deve acionar o botão

Iniciar e a qualquer hora o botão Finalizar para terminar o processo de monitoração.

Figura 68: Monitoração geral – passo 2.


109

6.3.3 Alarmes instantâneos

Os alarmes instantâneos do sistema de monitoração de responsabilidades dos agentes

de detecção que, ao verificarem alguma anomalia em quaisquer variáveis do sistema,

disparam uma interface gráfica contendo as informações acerca da anomalia e do local de sua

ocorrência (figura 69).

Figura 69: Alarme instantâneo.


Entretanto é possível que estes alarmes sejam desativados e reativados a qualquer

tempo, bastando para isso acionar o botão Desabilitar Alarmes Instantâneos (figura 70) que

após essa ação se transforma em Habilitar Alarmes Instantâneos.

Figura 70: Desabilitar Alarmes instantâneos.


110

6.3.4 Monitorar Agentes (RMA)

RMA vem de Remote Management Agent, ou seja, Agente de gerenciamento remoto.

Trata-se de uma ferramenta para monitorar os agentes que estão sendo executados no

framework de agentes JADE, utilizado em nosso sistema. É uma ferramenta totalmente

independente de nossa aplicação e pode ser melhor explorada através de vários tutoriais

próprios no site jade.tilab.com.

Abaixo (figura 71) temos a tela inicial do RMA, a qual mostra os agentes em execução.

Figura 71: RMA (Remote Management Agent).


Na próxima tela (figura 72) temos uma função muito utilizada do RMA, a função

Sniffer que nos permite monitorar em tempo real através de um diagrama de seqüência a

interação entre os agentes em operação do sistema.

111

Figura 72: SNIFFER.


6.4 FUNCIONALIDADES ADMINISTRATIVAS

Toda vez que é feita uma monitoração da temperatura do armário 1 presente na

máquina 1 devemos lembrar que isso só é possível porque o sistema tem em seu banco de

dados as informações acerca da variável temperatura, do armário armário 1 e da máquina

máquina 1, ou seja, deve-se informar o sistema sobre as entidades que serão monitoradas bem

como suas variáveis relacionadas. Para tanto, teremos as funções cadastro de máquinas,

armários, tiristores, dentre outros.

6.4.1 Cadastro e alteração de máquinas

- Cadastro

Passo 1:

Acionar o botão Cadastrar/Alterar Máquinas (Figura 73).

112

Figura 73: Administração do sistema – Tela principal.


Passo 2:

Acionar o botão Novo (Figura 74) para limpar os campos de texto e permitir que você

entre com os dados.

Figura 74: Cadastro de máquinas – passo 2.


Passo 3:

Preencher os campos de texto e acionar o botão Salvar (Figura 75). Os campos de texto

contém informações a respeito da entidade máquina e de um identificador que se faz

necessário para relacionar as informações obtidas no processo de aquisição com determinada

entidade. (isso vale para todas as entidades, leia-se máquinas, armários e tiristores).

Figura 75: Cadastro de máquinas – passo 3.


113

- Atualização

Passo 1:

Para atualizar as informações desta entidade basta selecionar o registro através dos

botões Anterior e Próximo e acionar o botão Editar (Figura 76).

Figura 76: Atualização de máquinas – passo 1.


Passo 2:

Para salvar as atualizações devemos acionar o botão Salvar (Figura 77).

Figura 77: Atualização de máquinas – passo 2.


6.4.2 Exclusão de Máquinas

Passo 1:

Para deletar algum registro primeiro deve-se selecionar o registro através dos botões

Anterior e Próximo e acionar o botão Editar (Figura 78).

114

Figura 78: Exclusão de máquinas – passo 1.


Passo 2:

Para deletar o registro selecionado basta acionar o botão Excluir (Figura 79).

Figura 79: Exclusão de máquinas – passo 2.


6.4.3 Cadastro e alteração de Armários, Tiristores e variáveis

Os procedimentos são os mesmos, portanto não serão explicados aqui.

6.4.4 Cadastro e Alteração de Usuários

- Cadastro

Passo 1:

Acionar o botão Cadastrar/Alterar Usuários (Figura 80).

115

Figura 80: Cadastro de usuários– passo 1.


Passo 2:

Acionar o botão Novo (Figura 81) para limpar os campos de texto e permitir que você

entre com os dados.

Figura 81: Cadastro de usuários – passo 2.


Passo 3:

Preencher os campos de texto e acionar o botão Salvar. Os campos de texto contêm

informações a respeito do usuário. Informações como Atribuição tem a função de nivelar o

acesso ao sistema, ou seja, um usuário com a atribuição de administrador não poderá acessar

as funções de operador.

116

- Atualização

Passo 1:

Para atualizar as informações desta entidade basta selecionar o registro através dos


Figura 82: Atualização de usuários – passo 1.


Passo 2:

Para salvar as atualizações deve-se acionar o botão Salvar (Figura 83).

Figura 83: Atualização de usuários – passo 2.


117

- Exclusão

Passo 1:

Para deletar algum registro primeiro é necessário selecionar o registro através dos


Figura 84: Exclusão de usuários – passo 1.


Passo 2:

Para deletar o registro selecionado basta acionar o botão Excluir (Figura 85).

Figura 85: Exclusão de usuários – passo 2.


118

7 CONSIDERAÇÕES FINAIS

Neste trabalho procurou-se demonstrar que uma arquitetura baseada em agentes pode

ser utilizada para aplicações de monitoração e detecção de anomalias em uma planta

industrial. Os objetivos específicos foram:

Projetar agentes reutilizáveis com habilidades de processamento de dados.

Pesquisar e utilizar uma arquitetura de agentes capaz de fornecer as habilidades de

comunicação e cooperação necessárias em sistema multi-agente.

Construir um sistema propriamente dito para monitoração de variáveis e detecção de

anomalias.

Esses objetivos foram atingidos e as oportunidades que surgem a partir daí são

ilimitadas, uma vez que tal sistema possui grande flexibilidade de tal forma a permitir uma

adaptação às mais variadas situações de monitoração, análise, classificação e detecção de

anomalias.

Futuramente o sistema pode ser adaptado para trabalhar com tecnologias como lógica

fuzzy, redes neurais ou mineração de dados, pois já se tem uma base de dados com

informações acerca da relação entre dados de entrada e dados de saída. O sistema poderá

também se enquadrar em um nível mais gerencial, onde gráficos e informações mais

trabalhadas acerca das variáveis podem ser exibidas e analisadas.

119

REFERÊNCIAS

BAUER, B. Extending UML for the specification of interaction protocols. Submitted for

the 6th Call for Proposal of FIPA, 1999.

BEER R.D.; A Dynamical Systems Perspective on Autonomous Agents. In: Special issue of

the AI Journal on Computational Theories of Interaction and Agency, 1992.

BRAZIER, Frances M.T.; CATHOLIJN, M. Jonkers; TREUR, Jan (ed.). Principles of

compositional multi-agent system development. Chapman and Hall, 1998.

BROOKS R.A. A robust layered control system for a mobile robot. In: IEEE Journal of

Robotics and Automation, 2(1), p. 14-33, march, 1986.

______. Intelligence without representation. Vol. 47. Artificial Intelligence, 139-159, 1991.

BRYSON, Joanna; McGONIGLE, Brendan. Agent architecture as object oriented design.

Intelligent agents IV: agent theories, architectures, and languages. Proceedings of ATAL'97.

ed. Springer, Berlin, 1998.

BURMEISTER, Birgit. Models and methodology for agent-oriented analysis and design,

1996.

______; HADDADI; Afsaneh; KURT, Sundermeyer (ed.). Generic Configurable.

Cooperation Protocols for Multi-Agent Systems Springer, Neuchâtel, Switzerland, 1993.

BUSSMAN Demazeau Y.; An agent model combining reactive and cognitive capabilities, In:

IEEE, International Conference on Intelligent Robots and Systems, IROS, 1994.

CASTELFRANCHI C. A pont missed in multi-agent, DAI and HCI. Decentralized AI, Y.

Demazeau; J-P. Müller (Eds), Elsevier Science Publisher B.V. (North- Holland), 49-62,

1990.

______. Guarantees for autonomy in cognitive agent architecture. In: WOOLDRIDGE, M.;

JENNINGS, N. R. editors. Intelligent agents: theories, architectures, and languages, V. 890 ,

1990.

120

CHEONG, F. Internet agents. Indianapolis: New Riders Publishing, 1995.

DEMAZEAU Y.; MÜLLER J.P., From reactive to intentional agents, In: Decentralized

artificial intelligence. Elsevier Science Publishers., North Holland, v. 2, p. 3-10, 1991.

______. From interactions to collective behaviour in agent-based system. Saint Malo:

European Conference on Cognitive Science, 1995.

DEPKE, Ralph; REIKO Heckel; JOCHEN Malte Küster. Requirement specification and

design of agent-based systems with graph transformation. Roles and UML, in this volume,

2000.

DURFEE, E,H.; ROSENSCHEIN, J.S. Distributed problem solving and multi- agent systems:

comparisons and examples. Proceding of The International Workshop on Distributes

Artificial Inteligence, Jul. 1994.

FERBER J. JACOPIN E.; The Framework of Eco-Problem Solving, In: Proceedings of the

second MAAMAW. Saint-Quentin en Yvelines, August, 13-16, 1990.

______; DROGOUL A. Using reactive multi-agent systems in simulation and problem

solving, In : Avouris N.M., Gasser L. eds., Distributed Artificial Intelligence: Theory and

Praxis, Kluwer Academic Publishers, pp. 53-80, 1992.

______. La Kenetique: des systemes multi-agents a une science de linteraction, In: Revue

Internationale de systèmique, v. 8, n. 1, p. 13-27, 1994.

______. Les systemes multi-agents. Interéditions, Paris, 1995.

FRANKLIN, Stan; GRAESSER. Art is it an agent, or just a program?: a taxonomy for

autonomous agents, proceedings of the third international workshop on agent theories,

architectures, and languages. Published as intelligent agents III, p. 21-35, Springer-Verlag,

1997.

GARIJO, Francisco J.; BOMAN, Magnus ed. Multi-agent system engineering: proceedings

of MAAMAW'99. Berlin, Germany: Springer, 1999.

GENESERETH, M.R.; KETCHPEL, S.P. Software agents. Communications of the ACM.

Vol. 37 (7). July 48-53, 1994.

121

HAGG S., YGGE F. An architecture for agent-oriented programming with a programmable

model of interaction. In: Proceedings of the Seventh Annual Conference on AI and

Cognitive Science, September 8-9, 1994.

HAYES-ROTH, B. An arquitecture for adaptive intelligent systems. Artificial intelligence:

special issue on agent and interactivity, v. 72, 1990.

HEILMANN, Kathryn et al. Intelligent agents: a technology and business application

Analysis. 1995. Disponível em: <http://haas.berkeley.edu/~heilmann/agents/index.html>.

Acesso em: 12 jan. 2003.

HERLEA, Daniela E.; CATHOLIJUN, M. Jonker; TREUR, Jan; NIEK, J.E. Wijngaards (ed.).

Specification of behavioural requirements within compositional multi-agent system

design springer. Valencia, Spain, 1999.

HOLLAND, J.H. Adaptation. In: Natural and artificial systems. University of Michigan

Press, Ann Arbor, 1975.

HUBNER, Jomi Fred. Um modelo de reorganização de sistemas multiagentes. Tese

(Doutorado). Escola Politécnica da Universidade de São Paulo, 2003.

IGLESIAS, Carlos A., MERCEDES Garijo; González, José C. ed. A survey of agent-

oriented methodologies university Pierre et Marie curie. Paris: FR, 1998.

Jade.tilab.com. Tutoriais de utilização daplataforma JADE.

JENNINGS N.R., Wittig T.; ARCHON: Theory and Practice, In: Distributed Artificial

Intelligence: theory and praxis (eds. N.M. Avouris and L.Gasser), Kluwer Academic Press,

179-195, 1992.

JENNINGS, N. R.; WOOLDRIDGE, M. J. Agent technology: foundations, applications, and

markets. Springer Verlag, London, 1998.

JONKER, Catholijn M.; Treur, Jan (ed.). Compositional verification of multi-agent

systems: a formal analysis of pro-activeness and reactiveness springer, 1997.

KINNY, David, GEORGEFF, Michael; RAO, Anand. A methodology and modelling

technique for systems of BDI agents, agents breaking away. 7th European Workshop on

Modelling Autonomous Agents in a Multi-Agent World (MAAMAW'96). Walter

VandeVelde and John W. Perram ed., Springer, Berlin, 1996, p. 56-71, 1996.

122

KINNY, David; GEORGEFF, Michael. Modelling and design of multi-agent systems.

Intelligent agents III: proceedings of the third international workshop on agent theories,

architectures, and languages (ATAL'96), ed. Springer, Heidelberg, 1996.

LAUREL, Brenda. The art of human - Computer Interface Design, 1990.

MAES, Pattie. Agents that reduce work and information overload. In: Communications of

the ACM, 37(7), July, 1994a.

______. Social interface agents: acquiring competence by learning from users and ohter

agetns, In: O. Etzioni (eds.) Software agents - papers from the spring symposium (Technical

Report SS-94-03), p. 71-78, AAAI Press, 1994b.

______. Artificial life meets entertainment: life like autonomous agents. In: Communications

of the ACM, V. 38, 1995.

MARTIN, James; Odell, J. Object-oriented methods: a foundation, (UML edition). Prentice

Hall, Englewood Cliffs, NJ, 1998.

MCARTHUR, STEPHEN; BOOTH, CAMPBELL; MCDONALD, J. R.; MCFADYEN,

IAN. An Agent-Based Anomaly Detection Architecture for Condition Monitoring. In: IEEE

transactions on power systems, vol. 20, no. 4, november, 2005

MINSKY M. The society of mind.Simon and Schuster, New York, 1986.

MITCHELL, T. et al. Experience with a learning personal assistant, In: Communications of

the ACM, 37(7), Jul. 1994.

NODINE, Marian H.; UNRUH, Amy. Facilitating open communication in agent systems: the

infosleuth infrastructure. Intelligent Agents IV: agent theories, architectures, and languages.

Munindar P. Singh et al. ed., Springer, Berlin, p. 281-296, 1998.

ODELL, James (ed.). Agent technology. OMG, green paper produced by the OMG Agent

`Working Group, 1999.

PARAISO, Emerson C. MASC – Sistema Multi-Agente para Monitoração e Controle de

Processo. International ICSC Symposium on Engineering of Intelligent Systems - Tenerife,

Espanha, 1996.

123

PARUNAK, H. Van Dyke (ed.). Visualizing agent conversations: using enhanced dooley

graphs for agent design and analysis, 1996.

PARUNAK, H.; VAN DYKE, John Sauter; STEVEN, J. Clark. Toward the specification and

design of industrial synthetic ecosystems. Intelligent agents IV: agent theories, architectures,

and languages. Munindar P. Singh et al. ed., Springer, Berlin, 1998, p. 45-59, 1998.

RUMBAUGH, James; Ivar Jacobson; Grady Booch. The unified modeling language

reference manual. Addison-Wesley, Reading, MA, 1999.

RUSSEL, J. Stuart; NORVIG, P. Artificial intelligence: a modern Approach. Prentice Hall:

EUA, 1995.

SCALABRIN, E.E. Conception et Realisation d’environnement de développement de

systemes d’agents cognitifs. PhD Thesis. Université de Technologie de Compiégne, France,

1996.

SINGH, Munindar P. A Customizable coordination service for autonomous agents.

Intelligent Agents IV: agent theories, architectures, and languages. Munindar P. Singh et al.

ed., Springer, Berlin, p. 93-106, 1998.

SMITH, D. C., CIFRA; J. SPOHER. KidSim: programming agents whithout a programming

language. Communications of the ACM, 1994, v. 37, 1994.

STEELS L.; Cooperation between distributed agents through self-organization. In:

Proceedings of the First MAAMAW. Cambridge, England, August, pp. 16-18, 1989.

SYCARA, K., DECKER, K., WILLIAMSON, M.; PANNU, A. Distributed Intelligent

Agents, In: IEEE Expert, July, 1996.

TORRES M. CONSTANTINO. Polveri da fiuto allucinogene nel Cile precolombiano.

Altrove, Torino, vol. 3, p. 29-39, 1996.

TUTORIAL de administração e programação do JADE. [jade.tilab.com].

WAYER, P. Agents unleashed. USA: AP Professional, 1995.

124

WOOLDRIDGE M. J., JENNINGS N. R. Agent theories, architectures, and languages: a

survey. Workshop on agent theories. architectures and laguages, ECAI94, Amsterdam,

1994.

WOOLDRIDGE M., JENNINGS N. Intelligent agents: theory and practice, In: The

knowledge Engineering Review, V. 10 (2), p. 115-152, 1995.

______; NICHOLAS, R. Jennings; KINNY, David. The gaia methodology for agent-oriented

analysis and design. International Journal of Autonomous Agents and Multi-Agent

Systems, 3: Forthcoming, 2000.

______. An introduction to multiagent systems. John Wiley and Sons, 2002.

universidade federal do parÁ departamento de …‡Ão - igor pinto... · universidade federal do...

Documents