A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


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

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

2 05/04/20062/52 Frederico Silva Guimarães © LES/PUC-Rio Agenda Introdução Tecnologias Envolvidas Trabalhos Relacionados Arquitetura Implementação Conclusões e Resultados Trabalhos Futuros

3 Introdução

4 05/04/20064/52 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

5 05/04/20065/52 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...

6 Tecnologias Envolvidas

7 05/04/20067/52 Frederico Silva Guimarães © LES/PUC-Rio 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

8 05/04/20068/52 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

9 05/04/20069/52 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

10 05/04/200610/52 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

11 05/04/200611/52 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

12 05/04/200612/52 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

13 05/04/200613/52 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++

14 05/04/200614/52 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,...)

15 05/04/200615/52 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

16 05/04/200616/52 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

17 05/04/200617/52 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 –Multi-plataforma É requisito do sistema executar em Windows e Linux –O sistema de slots/signals possibilita a interação entre objetos que não se conhecem

18 05/04/200618/52 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

19 05/04/200619/52 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. [DSOUZA, 99] Uso neste trabalho –Vários módulos interagem com o sistema apenas através de interfaces Utilização de slots e signals

20 Trabalhos Relacionados

21 05/04/200621/52 Frederico Silva Guimarães © LES/PUC-Rio 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

22 05/04/200622/52 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

23 05/04/200623/52 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 Utiliza macros

24 Arquitetura

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

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

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

28 Implementação

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

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

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

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

33 05/04/200633/52 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

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

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

36 05/04/200636/52 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

37 05/04/200637/52 Frederico Silva Guimarães © LES/PUC-Rio Assertivas Implementadas utilizando Macros –ABORT( [, ]); –ASSERT( )( [, ]); –ASSERT_VALID( )( [, ]);

38 05/04/200638/52 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

39 05/04/200639/52 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

40 05/04/200640/52 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)

41 05/04/200641/52 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

42 05/04/200642/52 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

43 Conclusões e Resultados

44 05/04/200644/52 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 linhas de código –16% dedicadas a descoberta/tratamento de falhas 120 classes –Equipe 3 programadores

45 05/04/200645/52 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]

46 05/04/200646/52 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

47 Trabalhos Futuros

48 05/04/200648/52 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

49 05/04/200649/52 Frederico Silva Guimarães © LES/PUC-Rio Referências MEYER, B. Applying design by contract. Outubro BRADSHAW, J. M.. An introduction to software agents. In: Bradshaw, J. M., editor, SOFTWARE AGENTS, p. 3–46. AAAI Press / The MIT Press, BRADSHAW, J. M.. Multi-Agent System: An Introduction to Distributed Artificial Intelligence. Addison-Wesley, MACKINNON, T.. Endo-testing: Unit testing with mock objects. XP2000, DSOUZA, D. F.; WILLS, A. C.. Objects, components, and frameworks with UML: the catalysis approach. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 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, MARINESCU, D. C.; JI, Y.; MARINESCU, G. M. ; BAI, X.. Physical awareness and embedded software agents

50 05/04/200650/52 Frederico Silva Guimarães © LES/PUC-Rio Referências RICHLING, J.. Message scheduled system - a composable architecture for embedded real-time systems 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, IEEE Computer Society. GUERREIRO, P.. Simple support for design by contract in c++. In: TOOLS 01: PROC. OF TOOLS39, p. 24, Washington, DC, USA, IEEE Computer Society. ROSENBLUM, D. S.. A practical approach to programming with assertions. IEEE Computer Society, Event helix page - design by contract, Janeiro 2006, SHOOMAN, M. L.; BOLSKY, M. I.. Types, distribution, and test and correction times for programming errors. SIGPLAN Not., 10(6):347–357, 1975, ENDRES, A.. An analysis of errors and their causes in system programs. SIGPLAN Not., 10(6):327–336, 1975,

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

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


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

Apresentações semelhantes


Anúncios Google