Um Sistema Multi-Agentes para Monitoramento e Aquisição em Tempo Real Frederico Silva Guimarães Orientador: Prof. Carlos José Pereira de Lucena

Frederico Silva Guimarães © LES/PUC-Rio Agenda Introdução Tecnologias Envolvidas Trabalhos Relacionados Arquitetura Implementação Conclusões e Resultados Trabalhos Futuros Introdução Contextualização O Estudo de Caso Organização da Dissertação Tecnologias Envolvidas Software Embarcado Software de Monitoramento e Aquisição de Dados Sistemas de Tempo Real Sistemas Orientados à Recuperação Agentes de Software Design by Contract Bluetooth Biblioteca Log4Cxx Biblioteca SQLite Biblioteca Qt Mock Objects Componentes de Software Trabalhos Relacionados Arquitetura Adotada O Software Embarcado O Software Supervisor A Comunicação Tecnologias Utilizadas Implementação Uso de Mock Objects Usando Assertivas Design by Contract e Mock Elements Banco de Dados Arquitetura de Janelas de Visualização Conclusões e Trabalhos Futuros Conclusões Trabalho Futuros 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Introdução

Frederico Silva Guimarães © LES/PUC-Rio Contextualização Motivação Sistemas supervisores e embarcados são encontrados com freqüência nos dias de hoje Muitos possuem severos requisitos de tolerância a falhas Objetivo Investigar (na prática) o uso de tecnologias de ponta como Design by Contract, Agentes de Software, Mock Objects, Sistemas orientados à recuperação, dentre outras, no auxílio ao desenvolvimento de sistemas de monitoramento e aquisição em tempo real 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio O Estudo de Caso Sistema para inspeção de dutos utilizando uma ferramenta de inspeção externa Requisitos Severos requisitos de tolerância a falhas Multi-plataforma ... Funcionalidades Permitir processamento e visualização dos dados em tempo real Monitorar o estado da ferramenta de inspeção Permitir a análise dos dados Auxiliar na gerência da inspeção Permitir a geração de relatórios 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Tecnologias Envolvidas

Tecnologias Envolvidas Software embarcado Software de monitoramento e aquisição de dados Sistema de tempo real Sistema orientado a recuperação Agentes de software Design by contract Bluetooth Biblioteca log4cxx Biblioteca SQLite Biblioteca Qt Mock objects Componentes de software 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Software Embarcado Descrição Capacidade de executar em ambientes isolados realizando tarefas muito bem definidas Executa em ambientes com limitações de tempo e hardware Hardware dedicado Possui nenhuma ou pouca interação com usuários Possui severos requisitos de confiabilidade e tolerância a falhas Muitos possuem requisitos de tempo real Uso neste trabalho O software desenvolvido para executar dentro ferramenta de inspeção é um software embarcado 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Software de Monitoramento e Aquisição de Dados Descrição Responsável por monitorar o estado ou o comportamento de um sistema ou dispositivo Normalmente é responsável por sistemas que devem ser à prova de falhas Normalmente é embarcado e está integrado ao sistema ou dispositivo que monitora Uso neste trabalho O software embarcado: Monitora o funcionamento da ferramenta de inspeção Coleta os dados lidos pelos sensores da ferramenta de inspeção 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Sistema de Tempo Real Descrição Deve ser capaz de responder a estímulos dentro de um limite de tempo (milissegundos ou microssegundos) Pode ser classificado como: Rígido (hard) Atrasos no tempo de resposta são inaceitáveis Leve (soft) Atrasos no tempo de resposta são aceitáveis Uso neste trabalho O sistema desenvolvido é um sistema de tempo real rígido Atrasos ou perda de dados na comunicação entre o software supervisor e o software embarcado são inaceitáveis Problemas na ferramenta de inspeção devem ser corrigidos ou notificados o mais rápido possível Dados coletados pelos sensores são processados e visualizados em tempo real 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Sistema Orientado à Recuperação Descrição “Falhas de hardware ou software e erros de operação do sistema são fatos com os quais é preciso conviver, e não problemas que possam ser adequadamente resolvidos e completamente eliminados durante o desenvolvimento do software.” [Patterson, 02] Uso neste trabalho Por ser um sistema com severos requisitos de tolerância a falhas, foi desenvolvido baseado nos conceitos de sistemas orientados à recuperação 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Agentes de Software Descrição [BRADSHAW, 97, 99] Objeto complexo com atitude; Um agente de software é governado pelo seu estado e seu comportamento Propriedades necessárias: Autonomia Interação Adaptação Uso neste trabalho Não foi utilizado um framework multi-agentes Várias partes do sistema foram modeladas e desenvolvidas com base nos conceitos de agentes, devido ao seu comportamento autônomo e à forma de comunicação No software embarcado os agentes foram utilizados apenas durante as fases de projeto e modelagem 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Design by Contract (DBC) Descrição [MEYER, 92] Contrato entre um artefato de software e seus clientes Cliente: deve garantir condições ou propriedades antes de invocar métodos do artefato Artefato: depois da execução, deve garantir que condições ou propriedades serão verdadeiras Contratos são executáveis, escritos na própria linguagem de programação ou em alguma meta-linguagem Pré-condições Pós-condições Invariantes Uso neste trabalho Por ser um sistema com severos requisitos de tolerância a falhas, foi desenvolvido baseado nos conceitos de DBC Contratos escritos em C++ 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Bluetooth Descrição Especificação aberta (royalty-free) de uma tecnologia para comunicação sem fio ad hoc, de curto alcance e baixo custo, através de conexões de rádio Assegura proteção contra interferência e segurança dos dados transmitidos Uso neste trabalho A comunicação entre o software embarcado e o software supervisor foi feita utilizando bluetooth Sem fio Padrão Com pequenas alterações, o sistema é capaz de comportar outros tipos de comunicação (cabo serial, internet, ...) 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Biblioteca Log4Cxx Descrição Biblioteca open source que implementa um log Baseado no log4j Configurável a partir de um arquivo Configuração hierárquica Mensagens com níveis (DEBUG, INFO, WARN, ERROR e FATAL) Uso neste trabalho Utilizado para fazer o log do software supervisor Tecnologia dominada pela equipe Utilizado para habilitar/desabilitar as assertivas 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Biblioteca SQLite Descrição Biblioteca open source desenvolvida em C que implementa um banco de dados auto-contido Armazena todos os dados em um único arquivo, o qual acessa diretamente Implementa o banco de dados e a camada de persistência Uso neste trabalho Utilizado para implementar o banco de dados do software supervisor Não necessita de instalação, configuração ou softwares adjacentes O banco pode ser manipulado como um arquivo comum 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Biblioteca Qt Descrição Biblioteca de uso geral Strings, coleções, maps, GUI, IO, ... Multi-plataforma Alternativa ao uso de Java Tratamento de eventos diferenciado Slots e Signals Utiliza pré-processamento Uso neste trabalho Suas classes são extremamente úteis no desenvolvimento Utilizado no software supervisor É requisito do sistema executar em Windows e Linux O sistema de slots/signals possibilita a interação entre objetos que não se conhecem comparar a parte de multi-plataforma de qt com java Pré-processamento: aumenta o tempo de compilacao. Mas nao necessariamente dobra 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Mock Objects Descrição [MACKINNON, 00] Um Mock Object é uma implementação falsa de um objeto Utilizado em testes quando: O teste precisa de informações sobre a utilização do objeto O objeto real não está disponível A utilização do objeto real é custosa Uso neste trabalho Utilizado para simular o software embarcado e a ferramenta de inspeção durante o desenvolvimento Os softwares foram desenvolvidos em paralelo Utilizado para validar o recebimento e envio das mensagens do sistema 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Componentes de Software Descrição Um componente de software pode ser definido como uma unidade de software independente, que encapsula, dentro de si, seu projeto e implementação, e oferece serviços para o meio externo, por meio de interfaces bem definidas. Os componentes se conectam por meio da interface requerida de um com a interface fornecida de outro. [D’SOUZA, 99] Uso neste trabalho Vários módulos interagem com o sistema “apenas” através de interfaces Utilização de slots e signals 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Trabalhos Relacionados

Trabalhos Relacionados Agentes de software + software embarcado Marinescu [02] Propõe o uso de agentes em software embarcado com comportamento ativo ou autônomo Foco na capacidade de mobilidade de um agente Apresenta apenas a idéia, nenhum estudo de caso Este trabalho Foco na autonomia dos agentes Foram encontrados diversos trabalhos relacionados referentes a cada assunto isoladamente, porém, optei por focar em trabalhos relevantes que focassem em mais tecnologias ao mesmo tempo. Tb procurei por trabalhos mais práticos, mas não encontrei. Foquei nas questões mais relevantes para este projeto, que são: Software embarcado, Sistemas de tempo real, Agentes de software, Design by contract Software embarcado + Software de monitoramento e aquisição de dados -> não encontrou trabalhos práticos Sistemas de tempo real + Sistemas orientados a recuperação -> não encontrou trabalhos práticos Agentes de software + Design by contract + Bluetooth -> tecnologias estabelecidas Biblioteca log4cxx -> tecnologias estabelecidas Biblioteca SQLite -> tecnologias estabelecidas Biblioteca Qt -> tecnologias estabelecidas Mock objects -> utilizou apenas a parte teórica (não foi necessário pesquisar por trabalhos práticos) Componentes de software -> utilizou apenas a parte teórica (não foi necessário pesquisar por trabalhos práticos) 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Trabalhos Relacionados Software embarcado + software de tempo real + DBC Richling [00] Apresenta uma arquitetura para software embarcado de tempo real que utiliza componentes DBC é usado para definir as interfaces dos componentes, incluindo os requisitos não funcionais (tempo, recursos, ...) Apresenta apenas a idéia, nenhum estudo de caso Este trabalho DBC é usado para definir interfaces DBC é usado nos testes das funções internas Foram encontrados diversos trabalhos relacionados referentes a cada assunto isoladamente, porém, optei por focar em trabalhos relevantes que focassem em mais tecnologias ao mesmo tempo. Tb procurei por trabalhos mais práticos, mas não encontrei. Foquei nas questões mais relevantes para este projeto, que são: Software embarcado, Sistemas de tempo real, Agentes de software, Design by contract Software embarcado + Software de monitoramento e aquisição de dados -> não encontrou trabalhos práticos Sistemas de tempo real + Sistemas orientados a recuperação -> não encontrou trabalhos práticos Agentes de software + Design by contract + Bluetooth -> tecnologias estabelecidas Biblioteca log4cxx -> tecnologias estabelecidas Biblioteca SQLite -> tecnologias estabelecidas Biblioteca Qt -> tecnologias estabelecidas Mock objects -> utilizou apenas a parte teórica (não foi necessário pesquisar por trabalhos práticos) Componentes de software -> utilizou apenas a parte teórica (não foi necessário pesquisar por trabalhos práticos) 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Trabalhos Relacionados Implementação de DBC/assertivas em C++ Guerreiro [00, 01] Não utiliza macros ou pré-processamento Define um objeto básico que possui os método das assertivas Abordagem invasiva Faz uso de exceções Rosenblum [95] Utiliza anotações em comentários Utiliza pré-processamento Event helix page [06] Utiliza macros Este trabalho 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Arquitetura

Frederico Silva Guimarães © LES/PUC-Rio Arquitetura Geral Software Embarcado Ferramenta de Inspeção Supervisor Notebook ou PC Bluetooth 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio O Software Embarcado Software Embarcado Agente Guardião Odométrico de Sensor 1 Comunicador Hardware Software Supervisor Sensores de Sensor 2 de Sensor N ... Camada de Controle do Sistema de Comunicação dos Sensores 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio O Software Supervisor Software Supervisor Agente Interpretador Software Embarcado Módulo de Protocolo Agente Comunicador Comunicação Agente Documentador Estatísticas Visualização Banco de Dados Camada de comunicação Camada de Visualização Camada de Persistencia Camada de Análise de Dados 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Implementação

Frederico Silva Guimarães © LES/PUC-Rio O Software Embarcado 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio O Software Supervisor 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Uso de Mock Objects - I Software Embarcado Agente Comunicador Módulos e Outros Agentes Software Supervisor 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Uso de Mock Objects - I Agente Comunicador Software Supervisor Software Embarcado Módulos e Outros Agentes 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Uso de Mock Objects - I Agente Comunicador Software Supervisor Simulando o software embarcado Software Embarcado Módulos e Outros Agentes Mock Tool 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Uso de Mock Objects - II Software Embarcado Agente Comunicador Agente Interpretador Módulos e Outros Agentes Software Supervisor 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Uso de Mock Objects - II Software Embarcado Agente Comunicador Agente Interpretador Módulos e Outros Agentes Software Supervisor 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Uso de Mock Objects - II Agente Comunicador Software Supervisor Simulando o Agente Interpretador Software Embarcado Agente Interpretador Módulos e Outros Agentes Mock Interpreter 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Assertivas Implementadas utilizando Macros ABORT(<msg>[, <args>]); ASSERT(<test>)(<msg>[, <args>]); ASSERT_VALID(<pointer>)(<msg>[, <args>]); 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Assertivas – Como ligar e desligar Primeira abordagem: Macro ASSERT_DISABLED Requer recompilação do programa para ligar/desligar Todas as assertivas ligadas ou desligadas Nenhum overhead quando as assertivas estão desligadas Segunda abordagem: Utilizando a configuração do log Não requer recompilação do programa para ligar/desligar Permite ligar/desligar apenas parte das assertivas Nível de habilitação do log -> Número de assertivas testadas Testes pesados são habilitados apenas com log em DEBUG Assertivas desligadas possuem pequeno overhead Teste do log Assertivas com testes simples não são afetadas Custo do teste do log > Custo do teste da assertiva 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Assertivas – AssertionHandler Problema observado Assertivas eram substituídas por: teste + código de recuperação de erro Alterações sem nenhum projeto prévio Mistura do código de negócio com o código de recuperação Solução proposta AssertionHandler AssertionVerifier FailureHandler Desvantagem Quebra da modularidade de raciocínio - ao atacar o Assertion Handler, mencionar a quebra da modularidade de raciocinio 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Assertivas – Assertion Handler AssertionHandler::verify(VALID_DOC, doc); AssertVerifierValidDoc::verify(VALID_DOC, doc) FailureHandlerInvalidDoc::handleFailure(VALID_DOC, doc) 1:invoca 2B:retorna true (nenhuma assertiva falhou) 2A: retorna false (alguma assertiva falhou) Continua a execução 3: invoca 4B:retorna true (recuperou-se do erro) Aborta o Programa 4A: retorna false (não conseguiu recuperar-se do erro) 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Banco de Dados Biblioteca SQLite Funções de acesso ao banco lidam com objeto e atributos Convertidos internamente em tabelas e colunas As classes persistidas são subclasses da classe Bean O Bean possui um atributo que identifica a sua classe real Permite que funções recebam um bean genérico como parâmetro Tratamento de erros Toda operação retorna uma string Uma operação bem sucedida retorna uma string vazia No caso de ocorrer um erro a operação retorna um string com a descrição do erro - mencionar que o termo Bean é usado nesse sistema da mesma forma q Java usa 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Janelas de Visualização Todas as janelas são subclasses de View Tratamento de eventos ViewManager (Pattern Mediator) View::adaptToNewConfig Views podem ser: Views de Sinais Exibem dados na forma gráfica Views de Tabela Exibem dados na forma de tabela Exibe o conteúdo dos Beans TableView TableItem 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Conclusões e Resultados

Frederico Silva Guimarães © LES/PUC-Rio Estatísticas Sistema Duração do desenvolvimento do sistema 3 meses (primeira versão) Tempo gasto em testes (ambiente de produção simulado) 2 semanas Tempo gasto na homologação (ambiente de produção real) 2 dias Software Supervisor Tamanho Cerca de 50.000 linhas de código 16% dedicadas a descoberta/tratamento de falhas 120 classes Equipe 3 programadores 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Estatísticas – Software Supervisor Faltas descobertas com as assertivas: 26 Tempo médio para consertar: 1h Desenvolvimento: 22 Homologação: 2 Produção (primeira versão – 2 meses e meio): 2 Produção (após 2 meses e meio): 0 Faltas que não foram detectadas por nenhuma assertiva: 5 Tempo médio para consertar: 6h Teriam sido evitadas ou consertadas mais facilmente se existissem assertivas em alguns pontos Desenvolvimento: 5 Homologação: 0 Produção: 0 Faltas descobertas/linhas de código: 0.062 falhas para cada 100 linhas Normalmente esse valor fica entre 0.3 a 0.5 falhas para cada 100 linhas [SHOOMAN, 75][ENDRES, 75] 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Conclusões Sucesso no uso de diversas tecnologias (em conjunto) no desenvolvimento de sistemas de tempo real robustos e tolerantes a falhas Outros sistemas estão sendo desenvolvidos utilizando a mesma abordagem As tecnologias utilizadas permitiram o desenvolvimento, em um curto espaço de tempo, de um sistema de grande porte com altos requisitos de tolerância a falhas Uso de Assertivas/DBC Principal responsável pelo reduzido... Tempo gasto em testes (ambiente de produção simulado) 2 semanas Tempo gasto na homologação (ambiente de produção real) 2 dias Extremamente necessário dado a natureza dos erros (e de seu efeito) na linguagem utilizada (C++) Fizeram o programador “pensar” 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Trabalhos Futuros

Frederico Silva Guimarães © LES/PUC-Rio Trabalhos Futuros Evolução do sistema Há demanda por novas funcionalidades Desenvolver outro sistema de inspeção de dutos Software supervisor executando em um PDA ou celular (J2ME) Software embarcado executando em ferramenta de inspeção manual Espera-se que o software embarcado possa ser o mesmo em ambos os sistemas Comparar o desenvolvimento dos 2 sistemas Evoluir o conceito do AssertionHandler Criar um módulo funcional e bem estruturado Estudo de caso: Alterar o sistema para fazer uso do AssertionHandler 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Referências MEYER, B. Applying ”design by contract”. Outubro 1992. BRADSHAW, J. M.. An introduction to software agents. In: Bradshaw, J. M., editor, SOFTWARE AGENTS, p. 3–46. AAAI Press / The MIT Press, 1997. BRADSHAW, J. M.. Multi-Agent System: An Introduction to Distributed Artificial Intelligence. Addison-Wesley, 1999. MACKINNON, T.. Endo-testing: Unit testing with mock objects. XP2000, 2000. D’SOUZA, D. F.; WILLS, A. C.. Objects, components, and frameworks with UML: the catalysis approach. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1999. PATTERSON, D.; BROWN, A.; BROADWELL, P.; CANDEA, G.; CHEN, M.; CUTLER, J.; ENRIQUEZ, P.; FOX, A.; KICIMAN, E.; MERZBACHER, M.; OPPENHEIMER, D.; SASTRY, N.; TETZLAFF, W.; TRAUPMAN, J. ; TREUHAFT, N.. Recovery oriented computing (roc): Motivation, definition, techniques, and case studies, 2002, http://www.stanford.edu/candea/papers/roc%5Fvision/roc%5Fvision.html. MARINESCU, D. C.; JI, Y.; MARINESCU, G. M. ; BAI, X.. Physical awareness and embedded software agents. 2002. 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Referências RICHLING, J.. Message scheduled system - a composable architecture for embedded real-time systems. 2000. GUERREIRO, P.. Another mediocre assertion mechanism for c++. In: TOOLS ’00: PROCEEDINGS OF THE TECHNOLOGY OF OBJECT-ORIENTED LANGUAGES AND SYSTEMS (TOOLS 33), p. 226, Washington, DC, USA, 2000. IEEE Computer Society. GUERREIRO, P.. Simple support for design by contract in c++. In: TOOLS ’01: PROC. OF TOOLS39, p. 24, Washington, DC, USA, 2001. IEEE Computer Society. ROSENBLUM, D. S.. A practical approach to programming with assertions. IEEE Computer Society, 1995. Event helix page - design by contract, Janeiro 2006, http://www.eventhelix.com/RealtimeMantra/Object_Oriented/design_by_contract.htm SHOOMAN, M. L.; BOLSKY, M. I.. Types, distribution, and test and correction times for programming errors. SIGPLAN Not., 10(6):347–357, 1975, http://doi.acm.org/10.1145/390016.808457/. ENDRES, A.. An analysis of errors and their causes in system programs. SIGPLAN Not., 10(6):327–336, 1975, http://doi.acm.org/10.1145/390016.808455/. 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Frederico Silva Guimarães © LES/PUC-Rio Curiosidade Ferramentas para inspeção de dutos 05/04/2006 Frederico Silva Guimarães © LES/PUC-Rio

Um Sistema Multi-Agentes para Monitoramento e Aquisição em Tempo Real Frederico Silva Guimarães Orientador: Prof. Carlos José Pereira de Lucena