Um Sistema Multi-Agentes para Monitoramento e Aquisição em Tempo Real Frederico Silva Guimarães...

Um Sistema Multi-Agentes para Monitoramento e Aquisição em Tempo Real

Frederico Silva Guimarães

Orientador: Prof. Carlos José Pereira de Lucena

05/04/2006 2/52Frederico 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

• 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


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

• ...

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


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


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


– O software embarcado:

• Monitora o funcionamento da ferramenta de inspeção

• Coleta os dados lidos pelos sensores da ferramenta de inspeção


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


– 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


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]


– Por ser um sistema com severos requisitos de tolerância a falhas, foi desenvolvido baseado nos conceitos de sistemas orientados à recuperação


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


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


– Por ser um sistema com severos requisitos de tolerância a falhas, foi desenvolvido baseado nos conceitos de DBC

– Contratos escritos em C++


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


– 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, ...)


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)


– Utilizado para fazer o log do software supervisor

• Tecnologia dominada pela equipe

– Utilizado para habilitar/desabilitar as assertivas


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


– 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


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


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


– 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


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]


– Vários módulos interagem com o sistema “apenas” através de interfaces

• Utilização de slots e signals

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



• 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



• 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

Arquitetura


Arquitetura Geral

Software Embarcado

Ferramentade Inspeção

Software Supervisor

Notebookou PC

BluetoothBluetooth


O Software Embarcado

Software Embarcado

Agente Guardião

AgenteOdométrico

Agente de Sensor 1

Agente Comunicador

Hardware

Software Supervisor

Sensores

Agente de Sensor 2

Agente de Sensor N

...

Camada de Controledo Sistema

Camada de

Comunicação

Camada de Controle

dos Sensores


O Software Supervisor

Software Supervisor

Agente Interpretador

Software Embarcado

Módulo de Protocolo

Agente Comunicador

Módulo de Comunicação

AgenteDocumentador

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

Implementação


O Software Embarcado


O Software Supervisor


Uso de Mock Objects - I

Agente Comunicador

Software Supervisor

SoftwareEmbarcado

Módulos e Outros Agentes



Agente Comunicador

Software Supervisor

SoftwareEmbarcado




Agente Comunicador

Software Supervisor

Simulandoo software embarcado

SoftwareEmbarcado


MockTool


Uso de Mock Objects - II

Agente Comunicador

Software Supervisor

SoftwareEmbarcado





Agente Comunicador

Software Supervisor

SoftwareEmbarcado





Agente Comunicador

Software Supervisor

Simulandoo Agente

Interpretador

SoftwareEmbarcado



MockInterpreter


Assertivas

• Implementadas utilizando Macros

– ABORT(<msg>[, <args>]);

– ASSERT(<test>)(<msg>[, <args>]);

– ASSERT_VALID(<pointer>)(<msg>[, <args>]);


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


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


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)


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


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

Conclusões e Resultados


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


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]


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”

Trabalhos Futuros


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


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.


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/.


Curiosidade

• Ferramentas para inspeção de dutos

Um Sistema Multi-Agentes para Monitoramento e Aquisição em Tempo Real

Frederico Silva Guimarães

Orientador: Prof. Carlos José Pereira de Lucena

Um Sistema Multi-Agentes para Monitoramento e Aquisição em Tempo Real Frederico Silva Guimarães...

Documents

Transcript of Um Sistema Multi-Agentes para Monitoramento e Aquisição em Tempo Real Frederico Silva Guimarães...