Um Sistema Multi-Agentes para Monitoramento e
Aquisição em Tempo Real
Frederico Silva Guimarães
Orientador: Prof. Carlos José Pereira de Lucena
Agenda
• Introdução
• Tecnologias Envolvidas
• Trabalhos Relacionados
• Arquitetura
• Implementação
• Conclusões e Resultados
• Trabalhos Futuros
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
2/52
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
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
4/52
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
5/52
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
7/52
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
8/52
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
9/52
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
10/52
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
11/52
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
12/52
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
13/52
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
14/52
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
15/52
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
16/52
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
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
17/52
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
18/52
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
19/52
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
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
21/52
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
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
22/52
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
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
23/52
Arquitetura
Arquitetura Geral
Ferramenta
de Inspeção
Software
Embarcado
05/04/2006
Notebook
ou PC
Bluetooth
Frederico Silva Guimarães © LES/PUC-Rio
Software
Supervisor
25/52
O Software Embarcado
Software Supervisor
Hardware
Software Embarcado
Agente
Guardião
Agente
de Sensor 1
Agente
Comunicador
Camada
de Controle
do Sistema
Agente
de Sensor 2
Agente
Odométrico
...
Camada
de
Comunicação
Agente
de Sensor N
Camada
de Controle
dos Sensores
Sensores
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
26/52
O Software Supervisor
Software Supervisor
Agente Interpretador
Módulo de
Protocolo
Camada de comunicação
Agente
Documentador
Agente Comunicador
Módulo de
Comunicação
Software Embarcado
Módulo de
Estatísticas
Módulo de
Visualização
Camada
de Visualização
Camada de
Análise de Dados
Camada de Persistencia
Módulo de
Banco de Dados
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
27/52
Implementação
O Software Embarcado
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
29/52
O Software Supervisor
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
30/52
Uso de Mock Objects - I
Software
Embarcado
Agente
Comunicador
Software Supervisor
05/04/2006
Módulos
e Outros Agentes
Frederico Silva Guimarães © LES/PUC-Rio
31/52
Uso de Mock Objects - I
Software
Embarcado
Agente
Comunicador
Software Supervisor
05/04/2006
Módulos
e Outros Agentes
Frederico Silva Guimarães © LES/PUC-Rio
32/52
Uso de Mock Objects - I
Software
Embarcado
Agente
Comunicador
Software Supervisor
05/04/2006
Simulando
o software
embarcado
Mock
Tool
Módulos
e Outros Agentes
Frederico Silva Guimarães © LES/PUC-Rio
33/52
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
34/52
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
35/52
Uso de Mock Objects - II
Software
Embarcado
Agente
Comunicador
Agente
Interpretador
Simulando
o Agente
Interpretador
Mock
Interpreter
Módulos
e Outros Agentes
Software Supervisor
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
36/52
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
37/52
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
38/52
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
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
39/52
Assertivas – Assertion Handler
AssertionHandler::verify(VALID_DOC, doc);
2A: retorna false
(alguma assertiva falhou)
1:invoca
AssertVerifierValidDoc::verify(VALID_DOC, doc)
2B:retorna true
(nenhuma assertiva falhou)
3: invoca
Continua a execução
4B:retorna true
(recuperou-se do erro)
FailureHandlerInvalidDoc::handleFailure(VALID_DOC, doc)
4A: retorna false
(não conseguiu recuperar-se do erro)
Aborta o Programa
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
40/52
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
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
41/52
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
42/52
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
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
44/52
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
45/52
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
46/52
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
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
48/52
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
49/52
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
50/52
Curiosidade
• Ferramentas para inspeção de dutos
05/04/2006
Frederico Silva Guimarães © LES/PUC-Rio
51/52
Um Sistema Multi-Agentes para Monitoramento e
Aquisição em Tempo Real
Frederico Silva Guimarães
Orientador: Prof. Carlos José Pereira de Lucena