um estudo sobre coordenação de nós simulados e expansão de...
TRANSCRIPT
Simulador de nós móveis cooperantes no
ContextNet
Um estudo sobre coordenação de nós simulados
e expansão de suas funcionalidades
Lucas Alves
Proposta de Projeto Final de Graduação
Centro Técnico Científico - CTC
Departamento de Informática
Curso de Graduação em Engenharia de Computação
Rio de Janeiro, Junho de 2013
Lucas Alves
Simulador de nós móveis cooperantes no ContextNet Um estudo sobre coordenação de nós simulados e expansão de suas
funcionalidades
Relatório de Projeto Final, apresentado ao
curso Engenharia de Computação da PUC-Rio
como requisito parcial para a obtenção do
título de Engenheiro de Computação
Orientador: Markus Endler
Rio de Janeiro, Junho de 2013
Dedico este trabalho, primeiramente, a toda a minha família que me deu todo o suporte, financeiro e emocional durante os cinco anos de engenharia. Não tenho qualquer motivo para esconder que meu sucesso é decorrente do sucesso de vocês, que foram (e são) meus pilares, me sustentando através de todas as dificuldades. Seu exemplo de união e de sempre dar o seu melhor ajudou a moldar a pessoa que sou hoje.
Dedico também, ao professor e orientador Markus Endler, não só pelas horas que passou durante minha graduação ajudando e corrigindo trabalhos, mas também pela amizade e interesse verdadeiros, pelas conversas sobre a carreira de engenheiro e pela compreensão, nos momentos que mais precisei.
Dedico a professora Noemi Rodriguez, por despertar meu interesse nas áreas que para mim se mostraram as mais interessantes dentro do universo da computação. Threads e processos já não são mais tão assustadores assim...
Dedico, por fim, ao meu avô, que há muito tempo me disse que uma das coisas que mais o intrigava era o funcionamento da internet. Eu acho que hoje talvez eu seria capaz de lhe explicar.
1 Introdução
A grande evolução apresentada na área de sistemas distribuídos e
middleware proporcionou um aumento significativo na utilização destas
tecnologias para as mais diversas finalidades e também sua incorporação
na rotina diária das pessoas: estas passaram a poder rastrear seus
celulares através de aplicativos, verificar atualizações de mensagens de
seu interesse em tempo real, visualizar informações sobre rotas em mapas
na maioria dos smartphones, etc. Seguindo esta linha de raciocínio, foi
desenvolvido pelo LAC [1] (Laboratory for Advanced Collaboration) o
ContextNet [2], na PUC-Rio, uma plataforma (middleware) para dar suporte
a aplicações que necessitem de algumas das funcionalidades mais comuns
desta nova era: comunicação entre nós móveis em tempo real,
comunicação confiável, escalabilidade, bem como diversas outras
relacionadas a veículos: rastreamento, definição de grupos, controle
remoto, etc. Para testar a capacidade do middleware, foi desenvolvido um
projeto piloto, que simula uma frota de caminhões e estes, por sua vez,
podem ser visualizados em um mapa. Além de visualização, também
podem ser enviadas mensagens a estes nós móveis, verificar informações
sobre sua conectividade e verificar a qual Grupo de Interesse ele pertence,
entre outras coisas. Inicialmente, o simulador que criava estes nós móveis
não fazia muito além de enviar e receber mensagens e informações de rota
(através de uma interface Web, que será melhor descrita na seção 5 -
Tecnologias Utilizadas), porém era de extremo interesse que o estudo
fosse estendido para aumentar a qualidade da simulação, principalmente
do ponto de vista do ContextNet, uma vez que seria impossível (ou pelo
menos inviável) reunir um conjunto suficientemente grande de pessoas,
veículos ou aparelhos para testar as diferentes funcionalidades oferecidas
pelo middleware no mundo real. De fato, uma propriedade fundamental do
middleware do ContextNet é que fosse um sistema escalável
(característica diretamente determinada pelos protocolos de comunicação
desenvolvidos e a sua arquitetura inerentemente descentralizada). Assim,
fazia-se necessário um simulador capaz de emular centenas e milhares de
nós móveis - que por sua vez deveriam ter a capacidade de,
individualmente, gerar informações e dados de contexto ao sistema.
O objetivo deste projeto final será aperfeiçoar este simulador, não só
adicionando funcionalidades novas, como também incorporando algoritmos
que definam um comportamento de deslocamento - individual e coletivo -
mais realista dos nós móveis. Estas novas funcionalidades terão um
enfoque principal em comunicação, que será utilizada para controlar o
ambiente de simulação e os objetivos individuais de cada nó simulado.
Além disto, será incorporada aos nós simulados a capacidade de
comunicação proativa (ou seja, mensagens serão trocadas entres os nós
simulados de forma automatizada) para compartilhar informações
relevantes para a simulação, como por exemplo a posição do nó móvel,
resposta a alertas enviados para o sistema, etc.
1.2 Estado da Arte
Para a criação do middleware de comunicação do ContextNet, denominado
Scalable Data Distribution Layer (SDDL) foram escolhidas algumas
tecnologias chave que garantem uma comunicação robusta e eficiente
de/para dispositivos móveis. Não é tão simples garantir confiabilidade,
baixa latência e alta vazão para uma comunicação segura e confiável
quando a rede apresenta características que dificultam a comunicação, tais
como: cobertura irregular provida pelas operadoras de telefonia móvel
(2G/3G), alto índice de desconexões, sobrecarga nos canais de
comunicação, etc. Mesmo com o lançamento da rede 4G no Brasil, ainda
existe um número muito grande de reclamações referentes aos serviços
mais básicos, como por exemplo a perda de informação em serviços de
SMS e, ainda pior, cobertura intermitente mesmo dentro de grandes
centros.
O core do middleware SDDL consiste de um conjunto de máquinas que
fazem parte de uma infraestrutura de rede (cabeada) e de software de
apoio a interação com os clientes móveis. Como software de comunicação,
optou-se por adotar o padrão DDS (Data Distribution Service) da OMG [3]
para garantir que o core pudesse suportar uma grande vazão de tráfego de
dados para comunicação e processamento de dados de contexto ou
localização dos nós móveis. O padrão DDS implementa uma forma mais
otimizada de comunicação, utilizando uma arquitetura descentralizada e
peer-to-peer (sem brokers) e oferecendo uma extensa lista de políticas de
QoS, que são úteis para aplicações distribuídas com requisitos de
comunicação de alta vazão e em tempo real.
Para a comunicação do core do middleware com os nós móveis, foi
implementado o protocolo MRUDP (Mobile Reliable-UDP[4]), o qual utiliza
UDP para uma maior escalabilidade (evitando assim uma grande
quantidade de sockets abertos, e a latência do estabelecimento de uma
comunicação, como ocorre no TCP) e apresentou uma performance
satisfatória quando testado em redes com comunicação intermitente [5].
Para testar o desempenho do sistema e avaliar sua escalabilidade utiliza-
se um programa que simula um determinado número de nós móveis, que
se deslocam em direções aleatórias (ou ao longo de uma sequência de
pontos geográficos) dentro de uma determinada região e que se
comunicam com o core através do protocolo MR-UDP - que por sua vez é
encapsulado em uma biblioteca cliente (ContextNet Client Lib - CNCLib).
Este programa é composto por duas classes Java, uma é responsável por
implementar a rotina de operação de cada nó e a outra efetivamente
executa um número determinado de nós (escolhidos através de um
parâmetro) através de um esquema de pool de threads, pois seria
impossível rodar uma quantidade muito grande de threads ou processos -
um para cada nó simulado - no Sistema Operacional, devido a limitação de
recursos.
A classe "TruckMock.*", que define como o nó simulado irá se
comportar/movimentar, possui propriedades (do nó) que refletem em tempo
de simulação, como sua velocidade, algoritmo de percorrimento de
"caminhos" definidos por pontos geométricos , seu identificador individual,
etc. Também é nesta classe que foi incorporada a simulação de geração
de dados de contexto, como por exemplo, o nível de energia residual do
veículo. Como mencionado anteriormente, o core SDDL se comunica com
o nó através do protocolo MR-UDP e este implementa um conjunto de
listeners que capturam alguns eventos, por exemplo: conexão realizada
com sucesso, perda de conexão e entrega de "nova mensagem". E foi
através do sistema de troca de mensagens do protocolo que foi
implementada a capacidade de receber comandos: uma aplicação Web
(applet em Java) dispara strings de comando que são transformadas pelo
gateway (módulo do sistema que faz um "link" entre os nós simulados e o
core) em objetos e são enviados pelo protocolo MR-UDP. O nó simulado
então recebe o objeto e faz o tratamento para reconhecer que se trata de
um comando, podendo então iniciar sua execução. A partir desta forma de
operação é possível expandir significativamente as funcionalidades do
simulador, apenas adicionando os tratamentos a esses comandos para os
nós simulados.
Em relação a outros simuladores, foi identificado que existem muitos tipos
de algoritmos de coordenação, todos em nichos bem específicos como
aplicações militares, de aviação civil ou logística, etc.
No artigo "Evaluation of Dynamic Fleet Management: A Simulation
Framework" [6] é tratado um problema de coordenação muito similar ao
explorado neste trabalho, definido no texto como "Sistema de controle de
frotas dinâmicas". O principal objetivo do Framework é prover ferramentas
para a organização e tomada de decisões no gerenciamento de frotas de
caminhões. Cada caminhão possui "entregas" que precisa realizar e após
cada entrega ele pode ser realocado para uma outra posição específica do
mapa. A abordagem do problema em si tem um foco diferente do trabalho
aqui apresentado, pois o artigo propõe um sistema de apoio a decisão em
tempo real. Monitorando todos os caminhões, os autores objetivam prever
qual caminhão deverá fazer determinada entrega em determinado tempo,
com o objetivo de minimizar o deslocamento da frota como um todo.
Outro trabalho interessante, "In-vehicle information systems for network
traffic control: a simulation framework to study alternative guidance
strategies" [7] propõe o uso de simulação de frota de veículos para tentar
avaliar o impacto de diversos componentes no trânsito urbano. Também é
um problema bem similar, porém o simulador é usado para capturar e
quantificar algumas situações, como por exemplo a conduta do motorista
do veículo, que extrapolam os objetivos do nosso trabalho.
Em "Vehicle-to- vehicle ad hoc communication protocol evaluation using
realistic simulation framework" [8] o trabalho apresentado é mais geral -
apesar de também se preocupar com simulações em ambientes urbanos,
os autores dão foco ao protocolo de comunicação em si -, procurando obter
o limite máximo de vazão para otimizar o tráfego, disseminar eventos, etc.
Existe também a capacidade de expansão do projeto para trabalhar com
protocolos de comunicação alternativos ou ainda modelos de simulação de
comportamento do motorista alternativos.
Finalmente, o artigo, "Dynamic Incident Handling in Urban Freight
Distributions" [9] apresenta pontos interessantes, inclusive algumas
simulações com empresas de transporte reais, e segundo os autores, os
resultados foram significantes no sentido de tempo de resposta dos
veículos, custo reduzido para as empresas e qualidade do serviço superior
oferecida aos clientes. Porém, como o próprio nome sugere, novamente a
preocupação maior é na criação de um sistema capaz de resolver
problemas do trânsito urbano - que atualmente existe na forma de solução
manual oferecida por um operador, não apresentando a mesma eficácia de
uma solução automatizada, baseada em algoritmos.
Como pode ser visto, grande parte dos trabalhos nesta linha procuram
abordar a simulação de frota de veículos de forma bem específica (resolver
o problema do tráfego urbano, auxiliar o motorista em determinadas
situações...), quando o objetivo deste trabalho é prover um simulador com
algumas capacidades bem definidas e que seja capaz de testar o
middleware ContextNet e também ser expansível, de forma que novas
funcionalidades possam ser incorporadas no simulador para avaliar futuras
features no middleware.
2 Objetivos do trabalho A solução proposta cobriu o aperfeiçoamento e extensão do simulador
original do laboratório LAC.
Durante o projeto final I, o simulador já foi modificado para aceitar alguns
comandos de controle de movimentação dos nós, inseridos pelo usuário do
Controlador. O controlador provê uma interface web (applet Java) que
recebe periodicamente dados de localização de todos os nós móveis
(simulados ou não) e apresenta-os instantaneamente em um mapa
fornecido pelo Google.
No projeto final II, então, foram incorporadas as principais melhorias
propostas e foi explorado o potencial de coordenação dos nós móveis,
através da comunicação em grupo. O interesse foi em proporcionar uma
simulação que apresente uma capacidade de reação automatizada por
parte dos nós simulados ao mesmo tempo em que estes se comunicam e
realizam tarefas específicas.
Também faz parte do escopo do trabalho explorar o conceito de grupos -
que facilitam a coordenação e captação de informações de interesse em
sistemas muito grandes, como o ContextNet (plataforma utilizada nesse
trabalho - vide seção 5), que é feito para suportar um alto número de
entidades capazes de gerar informação. Apesar da simulação aqui se
restringir a uma quantidade limitada de nós apresentados em uma região
delimitada, o conceito explorado é baseado em que uma vez que se
consiga atribuir os nós simulados a grupos, é possível que através do
grupo estes nós sejam capazes de consumir e produzir informações com
poder de alterar o contexto de outros membros do grupo. Estas
informações podem ser consumidas em formato de alertas, capazes de
alterar o itinerário do nó simulado ou ainda no formato de comandos,
explicitamente obrigando uma alteração no contexto do nó simulado que
recebeu o comando.
Explorar a capacidade de executar movimentações dependentes de
comandos enviados a indivíduos ou grupos de nós simulados proporciona
um efeito interessante de apresentação, e é um primeiro passo rumo a
criação de soluções de coordenação mais complexas, tais como a
movimentação do grupo de nós em alguma formação, a convergência para
determinado ponto (posição), ou para um nó específico, etc.
Mesmo que de maneira ainda simples (em comparação com o trabalhos
mais completos na parte de simulação de veículos), aumentar o grau de
realidade da simulação - por exemplo, obrigando o algoritmo de
caminhamento a considerar a energia residual do nó simulado e restringir
seu deslocamento na falta da mesma.
De forma geral, construir uma aplicação mais complexa permite uma visão
mais ampla sobre a plataforma que está sendo utilizada, inspira possíveis
aplicações futuras e valida algumas hipóteses iniciais sobre a plataforma
que só realmente são testadas quando diferentes aplicações são
executadas.
3 Fundamentação Conceitual Durante a implementação do projeto final, boa parte dos conceitos
utilizados foram aqueles adquiridos ao longo do curso de Engenharia de
Computação, como:
Comunicação UDP
Programação orientada a objetos
Conceitos sobre threads são utilizados na construção do
simulador, pois cada nó simulado nada mais é do que um objeto
"runnable" Java que é executado em um pool de threads,
localizado na classe principal do simulador. Desta forma, é possível
rodar vários nós simulados e manter o consumo de recursos
razoável.
Conceitos de listeners são utilizados em diversos pontos do
projeto. Dentro do simulador, um listener responsável por capturar
o evento de nova mensagem recebida é utilizado para implementar
as rotinas que serão executadas quando um comando é recebido
pelo nó simulado. Além disto, este conceito é muito importante pois
aparece diversas vezes dentro da GroupAPI e do próprio
ContextNet.
Além dos conhecimentos adquiridos durante a graduação, algumas
novidades foram tema para estudo, por exemplo:
Capturar alterações no contexto da simulação e reagir de forma
proativa - mesmo que de forma básica, os nós móveis possuem a
capacidade de reagir a eventos que são gerados no contexto.
Coordenação em grupos - Dado que vários veículos estão
presentes em um mesmo grupo, a coordenação entre os nós passa
a ser fundamental para a realização de atividades em grupo, por
exemplo, responder a um alerta de um nó simulado e
potencialmente auxiliar em seu problema.
Alterações no contexto de simulação de forma automatizada - foi
desenvolvido um esquema (detalhado na seção 8 - Alterações no
simulador, na parte de comandos implícitos) que capacita os nós
simulados de alterar algumas propriedades do contexto da
simulação, através de comandos que são gerados e enviados aos
grupos dos quais estes fazem parte.
Além das citadas acima, é de extrema importância o conhecimento de
alguns paradigmas de programação e também um bom entendimento
sobre os protocolos utilizados no sistema e como estes foram construídos,
portanto também foi necessário estudar:
O paradigma pub/sub é utilizado no padrão DDS da OMG (base de
construção do sistema ContexNet) e na GroupAPI, assim é
fundamental entender os conceitos de tópicos publicados e sobre o
ciclo de vida da informação.
Além do próprio pub/sub é importante entender como o DDS é
utilizado e quais são as políticas de QoS utilizadas no sistema, pois
por exemplo quando um comando é gerado pelo controlador
(applet) este primeiro passa pelo SDDL, é então consumido pelo
Gateway e só então é encaminhado para os nós simulados.
Conceitos de redes de computadores, pois toda a comunicação
entre os nós é distribuída e baseada em protocolos não muito
convencionais (como já citado anteriormente, a comunicação dos
nós simulados com o core do sistema é feita através do protocolo
MR-UDP, baseado no protocolo UDP e que permite uma entrega
confiável de pacotes aos nós simulados de forma eficiente, com
baixa latência).
4 Metodologia
As etapas de desenvolvimento de software podem ser divididas da
seguinte forma:
Desenvolvimento de protótipo (na conclusão do projeto final I) com
algumas das funcionalidades mais básicas.
Implementação de comandos individuais de parar/iniciar simulação,
controle de velocidade e alteração de rota em tempo real.
Refatoração e correções no código original do simulador
(inicialmente apenas construído de forma básica e por ser
constantemente atualizado várias versões diferentes foram
geradas, agora mescladas em apenas um simulador completo).
Otimização no algoritmo para percorrer caminhos: agora suporta
uma precisão maior na descrição dos caminhos, melhor suporte as
"constantes" necessárias para que a simulação pareça mais real
(nós simulados não mais se movimentam com velocidades
astronômicas, reconhecem curvas e desvios no caminho com uma
precisão maior e o erro permitido no algoritmo de caminhamento foi
reduzido consideravelmente, obrigando o nó simulado a ser mais
fiel a sua rota) e correção de alguns bugs encontrados.
Implementação das características propostas no simulador descrito neste
documento (projeto final II).
Suporte a comandos enviados pela nova API de grupos, presente
no projeto ContextNet: entrada e saída de grupos, publicar
mensagens em grupo, etc (uma lista completa pode ser encontrada
na seção 5 - Tecnologias Utilizadas).
Implementar comandos e alterações de rotas em grupos, de forma
que cada caminhão mantenha informações sobre os nós
pertencentes a todos os seus grupos e possa também se comunicar
com eles - necessário para implementações em que os veículos
disparam avisos, alertas e alterações de rota.
Permitir que de forma automatizada os nós móveis sejam capazes
de coordenar, dentro de um grupo, quais serão os nós
selecionados para cumprir uma tarefa que foi atribuída ao grupo.
Possibilitar alterações de rotas baseadas a partir de informações
baseadas em contexto como alertas (falta de combustível, pedido
de resgate, etc.), desvios e comunicados.
5 Tecnologias Utilizadas
Como descrito na seção 1.2, os nós simulados estão presentes em um
sistema composto por vários outros módulos, que desempenham papéis
específicos dentro de um sistema maior chamado de ContextNet.
Para conectar os módulos presentes no ContextNet, existe o core do
sistema - chamado SDDL - utilizado para publicar e consumir dados em
uma espécie de "cloud" que irá disponibilizar estas informações para
aplicações ou módulos que estejam interessados.
Figura 1 - Modelo de comunicação dos nós móveis (e outros sistemas) com o core do ContextNet, definido como SDDL.
Como é possível ver na Figura 1, o Core SDDL é um domínio DDS, que
possui diversos módulos de processamento e controle geral:
GroupDefiner - responsável por definir grupos aos veículos. Pode
ser utilizado junto a API de grupos, para coordenação combinada
dos nós, uma vez que a API de grupos manipula os grupos em
tempo de execução e realiza as alterações somente quando é feito
um pedido por parte de um controlador ou nó simulado - ao
contrário do GroupDefiner que irá adicionar os veículos a grupos
através de um algoritmo que define quando este veículo deverá
pertencer ao grupo ou não, por exemplo: dividir todos os veículos
do país em grupos por região, dado suas posições no mapa.
Gateway - realiza toda a comunicação com cada veículo simulado
através do protocolo MR-UDP, repassando mensagens do domínio
DDS para os nós simulados, e vice-versa, de forma que cada
veículo possa potencialmente receber informações de outros
veículos conectados a outros Gateways.
Externo ao Core SDDL é possível identificar os possíveis veículos (aqui
serão nós simulados) presentes no sistema, mas não limitados a isto
podemos ainda ter tablets que podem receber informações do domínio em
tempo real (via WiFi) e o sistema de monitoramento e controle, que
atualmente é utilizado para gerar todos os comandos implementados aqui -
via uma interface Web (um applet Java). Toda esta arquitetura permite que
o ContextNet de forma geral consiga evoluir para alcançar todos os meios
de comunicações móvel existentes - não se restringindo por exemplo a
colher dados apenas de um veículo em movimento, como também do
celular do motorista que estaria dirigindo este veículo e da carga
transportada, assumindo que esta teria alguma espécie de rastreador ou
sensor para identificar propriedades específicas da mesma.
Figura 2 - Modelo de arquitetura geral do ContextNet. Neste projeto estamos interessados apenas na camada de distribuição de dados.
Tendo em vista como funciona o core do ContextNet, o ciclo de informação
- que futuramente pode ser transformada em comandos, informações de
posição ou até mesmo mensagens - flui através do core para as duas
pontas: o nó móvel e o applet Java utilizado para controlar a simulação.
No esquema acima, todo comando ou mensagem gerado pelo applet é
publicado no domínio DDS e será coletado pelo Gateway, que por sua vez
se encarregará de enviar a informação para o nó simulado corretamente.
Da mesma forma, quando surge uma informação a ser enviada pelo nó
móvel, esta deverá obrigatoriamente passar pelo domínio DDS antes de
ser consumida pelo applet.
Assim, a partir do applet, podem ser disparados quaisquer comandos que o
simulador seja capaz de receber, bem como mensagens de texto ou ainda
avisos. No fluxo contrário, chegam mensagens contendo a localização dos
nós simulados, para que seja possível posicionar os mesmo no mapa.
Já a partir de cada nó móvel, podem ser disparados comandos ou alertas
para outros nós móveis, e estes podem receber comandos tanto do applet
como de outros nós.
A Figura 3 representa apenas duas entidades previstas dentre várias no
SDDL, porém, conforme já explicitado, existem muitos outros módulos de
processamento que fazem parte do sistema.
Grupos
Uma outra tecnologia utilizada - que apesar de estar contida no ContextNet
será apresentada de forma separada, pois sua utilização foi um fator crítico
de sucesso para a aplicação -, foi a comunicação em grupos: que permite o
controlador se comunicar com um conjunto de nós através de uma única
mensagem, ou ainda, os nós móveis se comunicarem entre si através de
um grupo. Para implementar a comunicação em grupos no ContextNet foi
criada a GroupAPI - que tem um valor inestimável dentro de um ambiente
que propõe escalabilidade para milhares de dispositivos móveis, uma vez
Figura 3 - Fluxo de comunicação entre o controlador (applet) e o nó móvel
que seria inviável trocar informações com cada um destes dispositivos
individualmente. A figura a seguir representa um esquema de
funcionamento da GAPI para a formação de grupos:
Uma vez que tenham sido criados os grupos, é possível enviar mensagens
(consequentemente comandos também) através do applet, especificando o
ID e o TIPO do grupo com o qual se deseja comunicar. Este par forma uma
chave única capaz de identificar um grupo. Veja, a seguir, um exemplo de
comunicação com um grupo criado e formado por dois nós:
Figura 5 - Veículo recebendo comando de pedido de subscrição no grupo ID 20 e tipo 10. Á direita: mensagem olá será enviada para o grupo selecionado.
Figura 4 - Representação da formação de grupos através da GAPI
Figura 6 - Log do console dos veículos simulados mostrando a mensagem 'Olá' sendo recebida de forma correta.
Portanto, a API de grupos contempla:
permitir a subscrição de nós em um grupo qualquer, que poderá ter sido
definido anteriormente (pelo GroupDefiner) ou não.
permitir o nó móvel sair de um grupo em que explicitamente (o pedido de
entrar no grupo foi originado pelo próprio nó móvel) ou implicitamente
(pedido gerado pelo GroupDefiner ou algum outro módulo do sistema)
pertence.
receber e transmitir mensagens ao grupo, através de "GroupCasts" -
mensagens que por sua vez poderão ser traduzidas para comandos.
visualizar a quais grupos está atualmente inscrito.
visualizar todos os grupos existentes.
Com a utilização desta API foram implementadas as funcionalidades que
exigem a comunicação de grupos no simulador. Além de prover as
funções descritas acima, a API fornece um responsável por gerenciar toda
a comunicação e subscrição dos grupos, denominada
GroupCommunicationManager.
Applet
Como não faz parte do projeto, não será descrito neste documento a fundo
a criação e utilização completa do applet Java. No ambiente de simulação
criado seu uso se resume a enviar comandos (ou mensagens) para os nós
simulados, bem como o poder de visualizá-los em um mapa. Além disso,
por estar conectado diretamente ao SDDL (ou seja, ele publica e subscreve
tópicos DDS) este applet poderia facilmente ser substituído por algo mais
atual, como por exemplo um serviço Web rodando em um servidor mais
poderoso - que além de melhorar muito a performance em relação ao
applet, também permitiria a visualização dos nós simulados por
computadores que não tenham acesso ao SDDL em si, fundamental para
critérios de segurança, por exemplo. A seguir uma imagem mostra as
principais funcionalidades e informações relevantes para a interação com o
simulador:
Figura 7 - Descrição do applet
6 Projeto e Implementação do simulador
Ao final do Projeto Final I, foi concluído o primeiro protótipo de
implementação: um simulador capaz de percorrer rotas, alterar rotas em
tempo real, prover informações sobre localização, receber comandos
remotos de início e pausa de simulação entre outras pequenas
funcionalidades.
Durante o Projeto Final II, diversas melhorias foram realizadas e houve
uma grande extensão na lista de funcionalidades que o projeto Simulador
pode realizar. Para uma lista completa e descrição dos avanços do
simulador verificar a seção 8 - Avanços no simulador.
Durante a implementação do simulador, foi realizado um trabalho em
conjunto com a equipe do laboratório LAC para alinhas as expectativas do
projeto e atualizar o ContextNet para uma versão genérica, onde o
simulador pode ser encarado apenas como uma aplicação desenvolvida.
Também durante a implementação orientador a aluno perceberam que o
tema "coordenação" não era totalmente condizente com o trabalho sendo
realizado (este foi o tema do PFI). Desta forma, optou-se por alterar o
nome do projeto e focar nas características que realmente descrevem o
trabalho, como: comunicação em grupos, realização de atividades
baseadas em comandos, que podem ser gerados também pelos próprios
nós simulados baseados no contexto da simulação.
7 Testes e Avaliação
Como primeiramente foi implementado apenas um pequeno protótipo, uma
demo junto a equipe do LAC foi apresentada em seu próprio laboratório.
Testes manuais foram realizados neste período e o simulador já está
sendo utilizado em outras áreas e aplicações do laboratório (principalmente
para apresentações a clientes).
Para o projeto final II, testes mais elaborados foram construídos, de forma
a explorar algumas funcionalidades específicas que foram implementadas,
como:
Teste para coordenação de vários nós de um mesmo grupo.
Testes para verificar se a API de grupos funcionava da maneira
esperada.
Verificação se o aumento significativo de tráfego na rede impactou o
sistema core de forma geral.
Diversas melhorias no algoritmo de caminhamento original, de forma que
as apresentações do LAC aconteçam de forma mais suave, com
elementos que se aproximem mais da realidade.
Testes de reação a adversidades (alertas em grupos) que podem ser
comunicadas através do sistema. Estes tiveram um resultado muito
positivo, os nós simulados se comportaram da maneira como esperado.
Comunicação entre os nós simulados e o Gateway foi testada e algumas
vezes apresentou falhas. Algumas desconexões aconteceram com
exceções levantas pelo protocolo de comunicação MRUDP. Como este
não faz parte do escopo do projeto, os erros foram repassados a equipe
do LAC para que possam ser corrigidos.
O applet utilizado como monitor e controlador do projeto também foi
testado e claramente apresentou suas limitações. O applet consome
muita memória do computador e eventualmente chega a travar quando
um fluxo suficiente de informações é gerado. Como o applet também não
faz parte do escopo do projeto, estas informações foram repassadas ao
LAC, que já está desenvolvendo um controlador mais avançado, capaz
de suportar um tráfego muito superior de informação.
8 Avanços no simulador
Diversos avanços foram realizados no projeto simulador, dos quais os
principais são:
Desenvolvimento das características intrínsecas a veículos móveis, como
locomoção restrita a quantidade de energia disponível, alterações no
algoritmo de caminhamento - para que uma aparência mais "real" fosse
dada aos veículos - e geração de alertas que poderiam ser disparados
por sensores presentes no veículo.
Adição de diversos comandos no simulador, capazes de realizar
mudanças no contexto da simulação, como: mudança na velocidade do
veículo, mudanças em sua rota atual, alteração da quantidade de energia
disponível, etc.
Adição de capacidade responsiva dos nós, ou seja, agora existe a
possibilidade de cada nó simulado trocar de "estado" de forma
automática, estado esse que define o objetivo corrente do nó simulado.
Isto será realizado de forma proativa por parte do nó simulado, com a
finalidade de cumprir uma tarefa ou objetivo pré-estabelecido, bem como
disparar alertas e/ou mensagens quando julgar necessário.
Possibilidade de comunicação em grupo entre os nós, seja para disparar
ou receber comandos, que por sua vez, podem ser comandos explícitos
ou comandos implícitos - relacionados apenas a simulação. Exemplo:
capacidade de enviar pedido de resgate a nós membros de todos os seus
grupos atuais, implicando em uma resposta dos nós simulados ao grupo
indicando que a ajuda está a caminho e designando um nó responsável
por atender ao chamado.
Designação de "estados" para o simulador: agora cada nó simulado pode
assumir um papel de líder - que permitirá a este cumprir um conjunto de
funções e modificar o comportamento de movimentação dos demais nós
de seus grupos - ou ainda um papel de "suporte", no qual o nó simulado
poderá receber comandos do líder e, de acordo com esses,
possivelmente modificar seu padrão de locomoção. Algumas
funcionalidades do simulador (comandos que podem ser enviados ou
recebidos) estarão disponíveis apenas para cada um dos possíveis
"estados", quanto outras serão comuns a ambas. Por exemplo: o
comando que obriga um nó de "suporte" a seguir um líder não tem
qualquer efeito se utilizado em um nó "líder", enquanto o comando que
obriga o nó simulado a parar se de mover pode ser utilizado em ambos.
1. Das propriedades do simulador
Novas "propriedades" de movimentação e coordenação foram
implementadas no simulador, que conferem aos nós simulados um maior
grau de realismo durante à simulação. Estas propriedades representam as
características dos nós simulados que, diferente da versão original do
simulador, podem ditar como será o comportamento do nó móvel: por
exemplo, no caso da energia, a cada iteração de simulação será verificado
se o nó móvel ainda possui energia suficiente para continuar a se mover.
Caso a resposta seja negativa, o veículo ficará parado até receber energia
de alguma forma - ficando, portanto, incapacitado de cumprir seu objetivo.
As principais propriedades adicionadas foram:
Nível de Energia - Tem impacto direto na capacidade do nó
simulado conseguir se locomover. É reduzido de forma uniforme a
cada ciclo de simulação e pode ser manipulado através de
comandos explícitos (pelo controlador) ou implícitos (quando
acontece uma transferência de energia de um nó "suporte" para nó
"líder" - descrito melhor adiante).
Velocidade - Velocidade inicial é uma velocidade mediana
(aceleração é zero em toda simulação) e sofrerá alterações apenas
em resposta a comandos explícitos ou implícitos. O módulo do vetor
velocidade poderá ser alterado para apenas quatro categorias:
o Inicial
o Com incremento de 20% ou 40%
o Com decremento de 20% e 40%
o Parado
2. Dos possíveis estados do simulador
Da mesma forma que estas novas características de certa forma ditam o
comportamento dos nós móveis simulados, também é possível que elas
alterem seu estado. Estados definem os objetivos principais que o nó
simulado deverá procurar cumprir em determinado momento. Assim que o
simulador é iniciado, o nó móvel é definido em um dos dois possíveis
modos de operação: como nó "líder" ou de "suporte". Este modo de
operação não poderá ser alterado durante a simulação, porém é possível
alternar entre diferentes estados dentro de cada modo (nas seções abaixo
que descrevem cada um dos modos é possível ver o diagrama que
representa todas as possíveis variações de estado para cada modo).
O principal exemplo explorado neste projeto é quando um nó simulado fica
sem energia para se locomover, então imediatamente ele publica para
todos os grupos ao qual pertence um alerta de "socorro", que poderá (ou
não) ser atendido por nós que façam parte destes grupos. Como já dito
anteriormente, não é parte do escopo do projeto final determinar de forma
automática qual nó deverá pertencer a qual grupo, mas sim possibilitar
coordenação e comunicação entre os mesmos através dos grupos.
Portanto, assumimos que estes alertas serão devidamente entregues aos
nós de "suporte", que poderão então atender a chamada ou recusá-la.
Modo Líder: quando um nó móvel se encontra em modo líder, pode-se
assumir que este possui um objetivo inicial a ser cumprido. No caso do
simulador construído este objetivo é percorrer um caminho pré-
estabelecido que é sorteado, dentre os caminhos disponíveis, quando a
simulação se inicia. Uma vez que o veículo possua o caminho a ser
trilhado, ele inicia sua locomoção através dos pontos, que são a própria
representação do caminho escolhido, conforme a figura abaixo:
Figura 8 - Veículo simulado percorrendo um caminho e em vermelho sua trajetória futura. Em preto, estão demarcadas as áreas dos "checkpoints".
Este caminho é traçado utilizando o seguinte algoritmo de caminhamento:
A cada ciclo de simulação, o nó simulado calcula qual direção ele deverá
tomar para atingir seu objetivo. Para tal, este calcula o coeficiente angular
da reta formada pelo próximo ponto demarcado no caminho e sua posição
atual, gerando então um pequeno deslocamento baseado em sua
velocidade atual nesta direção. Uma vez que o nó simulado atinge uma
área próxima a um destes pontos (na figura está demarcada por um circulo
preto, onde as retas se encontram), ele assume um "checkpoint" e passa a
seguir em direção ao próximo ponto. Este simples modelo permite uma
inteligência mínima ao veículo para que este possa cumprir o trajeto em
questão, passando pelos pontos demarcados. Não seria interessante para
este projeto implementar modelos complexos de simulação, uma vez que o
foco é na interação do simulador com grupos e outros nós, além de
explorar a capacidade de controlar um ambiente simulado através de
comandos.
Portanto, quando em modo líder, o simulador tentará cumprir seu
objetivo, que será sempre percorrer um caminho, porém este deverá
obedecer algumas regras e poderá mudar de estado conforme a simulação
acontece:
Caso o nó móvel receba um comando de "#stop", este deverá parar
imediatamente no local em que se encontra e não poderá se mover
até que um comando de "#start" seja recebido. Quando neste
estado o simulador sequer "tenta caminhar", mas ainda está ativo e
apto a receber comandos de simulação ou mensagens (como por
exemplo, aumento ou diminuição de velocidade - que obviamente
será refletido apenas quando o veículo puder se mover -, ou ainda
comandos que realizem variações em sua energia).
É possível que no meio da simulação o veículo fique sem energia
para continuar sua trajetória, neste caso ele mudará de "estado" -
ainda pertencendo ao modo "líder" (lembrando que o modo não
pode ser alterado durante a simulação). Em seu novo estado,
denominado "ouf-of-energy", o veículo não poderá se mover por
não possuir energia suficiente para continuar o percurso, porém, ele
irá enviar alertas de socorro a todos os grupos ao qual ele
pertence.
Periodicamente estes alertas serão enviados até que um nó com
função de "suporte" proativamente se proponha a responder ao
chamado e auxiliar o nó "líder". Quando isto acontece, o líder para
de enviar alertas e entra em um modo de "espera", denominado
"waiting-response", que simplesmente aguarda a chegada do nó de
apoio. Quando o nó de apoio se encontra suficientemente perto
para uma transferência de energia, ele transfere uma parte de sua
energia para o líder e então este volta ao estado de se locomover e
continua sua trajetória normalmente.
O esquema a seguir representa quais estados o nó "líder" pode assumir,
indica suas transições e os motivos que levaram a troca de estado:
Analisando o fluxograma acima, é possível ver a semelhança com uma
espécie de "máquina de estados" dentro do simulador. Ao receber o
comando de "stop", como dito, o nó simulado deverá apenas entrar em um
estado de espera no qual não é possível se mover. Já no caso de quando
falta energia ao líder, na realidade será gerado um comando implícito
aos grupos no qual ele está inscrito. O comando gerado, chamado de #out-
of-energy, irá realizar uma mudança no estado dos nós de "suporte"
(descritos a seguir), que por sua vez, irão se organizar para decidir qual
veículo deverá responder a chamada do líder.
Para que a simulação funcione corretamente, é necessário que os nós de
"suporte" saibam da localização do nó líder, portanto este deverá publicar
sua posição em todos os grupos ao qual pertence periodicamente, para
que seja possível que os nós móveis possam se reorganizar no mapa a
ponto de assumir melhores posições no caso de eventualmente ser
necessário atender algum chamado. Neste projeto, isto é representado por
um comando que obriga os nós de "suporte" perseguirem o nó líder, e será
melhor explicado na descrição dos nós de "suporte".
Figura 9 - Diagrama representa o modo "líder". Os losangos representam verificações por parte do algoritmo de caminhamento. As setas azuis indicam direções incondicionais enquanto as vermelhas representam direções condicionais.
Modo Suporte: quando um nó móvel se encontra no modo "suporte", seu
estado inicial é uma forma de "espera" - na qual ele irá se mover de forma
randômica pelo espaço de simulação, uma região delimitada no mapa da
cidade do Rio de Janeiro apenas para a simulação, representando os
locais onde é possível alocar uma posição inicial para os nós de "suporte".
Veja a seguir:
Figura 10 - Área delimitada para a simulação no mapa do rio de janeiro.
Assim que a simulação se inicia, o veículo "aparece" dentro da área
delimitada acima e entra no modo de "espera", permanecendo neste
estado até que algum comando ou alerta seja recebido (novamente, neste
estado o nó simulado irá se mover de forma aleatória).
Análogo ao funcionamento do modo líder, o modo suporte também
apresenta um estado de "stop", quando o nó deverá permanecer parado
independente de outros comandos ou situações de contexto. A grande
diferença entre o nó de apoio e o líder, como o próprio nome sugere, é a
capacidade do veículo de auxiliar o líder em caso de alguma necessidade.
Para implementação desta funcionalidade, a primeira coisa que deverá
ficar bem clara é que uma comunicação entre os nós se faz necessária, e
que neste simulador ela acontece integralmente através dos grupos que o
nó de apoio pertence, através da GroupAPI (conforme a seção 5 -
Tecnologias Utilizadas). Todas as vezes em que um nó móvel necessita
enviar uma mensagem para um grupo (isto também é válido para o modo
"líder") ele o faz através do GroupCommunicationManager - uma entidade
da GroupAPI responsável pela comunicação de grupos. Para que seja
possível um nó de "suporte" auxiliar um nó "líder", é necessário que este
um seja capaz de se comunicar proativamente com o líder. Assim, quando
os nós precisam se comunicar, uma mensagem é gerada em tempo de
execução e disparada automaticamente (sem qualquer conhecimento do
monitor ou de qualquer entidade do core do SDDL). Portanto, através da
capacidade de enviar e receber mensagens aos grupos, os próprios nós
móveis estão constantemente alterando o contexto (rotas, velocidade,
energia e etc. podem ser alterados) da simulação, alterando o estado do nó
líder de seu grupo e também seu próprio estado e atributos. Um exemplo
disto acontece quando um nó de "suporte" consegue atender um líder que
está sem energia (por atender entenda que este nó recebeu um pedido de
socorro e se aproximou suficientemente do líder para realizar uma
transferência): o nó de "suporte" internamente gera um comando implícito
que chega ao nó líder através de um grupo comum e transfere 1000
unidades (genéricas) de energia ao nó "líder" - tudo feito de forma
automatizada, sem qualquer conhecimento do core SDDL ou dos nós
móveis presentes em outros grupos.
Obs: Apesar de não existirem quaisquer restrições sobre quando é
permitido a um nó móvel se inscrever em um grupo, é ideal para a
simulação que exista apenas um líder por grupo, e também que cada nó de
apoio pertença apenas a um único grupo. Isto se deve ao fato que o nó
líder publica sua posição periodicamente para os membros de todos os
grupos a que pertence, e em algumas situações os nós de suporte deverão
seguir estas instruções e caminhar em direção ao líder. Da forma como isto
foi implementado, quando o comando "#followLeader" é recebido, o nó de
apoio sairá de seu estado de "espera" (movimentação randômica) para
este novo estado, e tendo como base as posições difundidas pelo líder,
caminhará em uma linha reta até sua última posição conhecida. Portanto,
se um nó simulado de "suporte" pertencesse a vários grupos ele não
saberia qual líder deveria seguir.
Para dar suporte a funcionalidade de auxiliar um nó líder, também foram
criados estados para o nó de "suporte". Como dito, assim que um nó "líder"
fica sem energia, este enviará uma mensagem pedindo auxilio a todos os
integrantes de seu grupo. Ao receber esta mensagem, todos os nós de
suporte irão sair de seu estado inicial e irão para um estado de "iniciando
resposta". Ao mudar para este estado, todos os nós de suporte também
publicam sua posição atual no grupo ao qual pertencem, para que cada um
deles possa calcular sua distância atual até o líder. Em seguida, apenas o
mais próximo atenderá o chamado (e seu estado irá para "attending-
request") enquanto os demais proativamente desistem de prestar auxílio e
retornam ao seu estado inicial. Mesmo desistindo, todos os nós de suporte
irão informar ao líder que uma resposta está a caminho (imaginando que
em outros tipos de alerta, mais especificamente em situações de risco, é
importante avisar o mais rápido e de maneira confiável possível que a
ajuda está a caminho - portanto, em um ambiente onde a comunicação
pode ser considerada frágil, como no ambiente móvel, é uma segurança a
mais oferecida pelo sistema).
Assim que o nó de suporte eleito o mais próximo no momento do alerta
conseguir se aproximar suficientemente do nó líder ele então realizará a
transferência da energia e retornará ao estado de "espera", passando a
aguardar outros comandos ou alertas.
De maneira muito similar, quando um nó de suporte recebe um comando
de seguir o líder ("#followLeader"), este passará também a perseguir o
líder, com a diferença de que o objetivo é apenas se aproximar do mesmo
e não realizar uma transferência de energia. Outro ponto interessante é
que neste modo o líder também pode estar se movendo, então é possível
que o nó de apoio só consiga alcançar o líder quando o mesmo ficar sem
energia ou reduzir sua velocidade - motivo pelo qual esta funcionalidade é
interessante, pois pode ser utilizada para reposicionar no mapa os nós de
"suporte" para o caso de um eventual pedido de ajuda. Quando o nó de
suporte consegue se aproximar suficientemente do líder ele apenas
retornará ao seu estado inicial.
A seguir uma representação dos principais estados do modo suporte:
Assim como foram inseridas novas características no simulador também foram criados comandos para manipular algumas desta
3. Dos comandos do simulador
Como mencionado, foram adicionados comandos que podem ser
interpretados pelo simulador, seja para alterar o contexto ou realizar
alguma mudança na simulação atual.
Os comandos podem ser originados de duas formas bem distintas:
Forma explícita: quando o comando é gerado por uma pessoa
humana, através do applet controlador, conforme visto na seção 5 -
Tecnolodias utilizadas
Forma implícita: quando o comando é gerado automaticamente
por um nó simulado e é enviado para um grupo ao qual pertence.
Neste caso, o applet sequer possui informação de que o comando
foi enviado e poderá apenas acompanhar seus resultados
Figura 11 - Representação dos possíveis estados e transições do modo de "suporte". Setas azuis indicam desvios incondicionais enquanto as vermelhas indicam desvios condicionais.
baseando-se em mudanças de contexto, rotas dos nós simulados,
etc.
Todos os comandos são originados na forma de Strings em Java e
independente se têm como destino um único nó simulado ou um grupo,
este será tratado pelo nó simulado que o recebeu, realizando um "parsing"
(validação) para verificar se a String recebida realmente foi um comando.
Caso tenha sido recebido um comando, o nó simulado irá executar a rotina
relativa ao comando e em caso negativo, este irá interpretar apenas como
uma mensagem, imprimindo seu conteúdo no console do simulador.
Lista dos principais comandos explícitos:
#joinGroup - comando envia pedido ao GroupManager (que
pertence a GroupAPI, responsável por manter os grupos) para se
inscrever em determinado grupo. GroupManager adiciona o nó no
grupo requisitado e este passa a estar apto a receber informações
de todos os outros nós simulados pertencentes ao grupo. Mais
informações sobre a GroupAPI podem ser encontradas na seção
que descreve a mesma
#speed [val] - determina um aumento ou diminuição na velocidade
do nó simulado, variando em uma escala percentual de -40% até
+40% (os avanços são discretizados em 5 níveis, por exemplo, o
comando #speed 2 geraria um aumento de nível 2, ou seja 40% na
velocidade)
#showEnergy - comando mostra no console do simulador a
quantidade de energia ainda disponível para locomoção
#incEnergy - aumenta em 1000 unidades (genéricas) a quantidade
de energia disponível
#decEnergy - reduz em 1000 unidades a quantidade de energia
disponível
Estes comandos são comandos "explícitos" que são gerados ao simulador,
porém também existem comandos "implícitos" - que serão descritos a
seguir -, gerados de forma automatizada pelos próprios nós móveis em
algumas situações específicas:
#out-of-energy [pos] - comando gerado apenas por nós simulados
operando no modo líder, quando o mesmo fica sem energia para se
locomover.
#go [pos] - também gerado apenas por nós líder, este comando é
utilizado para publicar periodicamente a posição do líder para seu
grupo. Desta forma, caso algum nó de suporte receba um comando
de seguir o líder, ou ainda, caso o líder fique sem energia para
continuar seu objetivo, os nós de suporte possam começar a se
mover para uma posição relativamente atualizada.
#attending [pos] - comando emitido pelos nós de suporte e para os
nós de suporte. Este comando indica um "interesse" do nó de apoio
em responder uma chamada de um nó líder. A posição é publicada
junto com a informação de que o nó deseja atender ao chamado,
para que os nós mais distantes do líder possam proativamente
desistir de prestar auxílio.
#responseComing - comando enviado por todos os nós de suporte
para informar ao líder de que uma resposta ao seu pedido de
energia já está sendo enviada.
#incEnergyL - comando disparado por um nó de suporte quando um
este consegue se aproximar suficientemente do líder para realizar
uma transferência. O nó de suporte perderá 1000 unidades de
energia e o nó líder receberá 1000.
9 Conclusão
Durante o aperfeiçoamento do projeto simulador, foi possível colocar em
prática diversos conceitos aprendidos durante o curso de Engenharia de
Computação na PUC-Rio. Além disso, novos conhecimentos de redes de
computadores, sistemas distribuídos e middleware foram adquiridos e
rapidamente colocados em prática, no aperfeiçoamento do simulador e no
entendimento do ContextNet de forma mais geral.
Desde o início do projeto, foi de extremo interesse do autor que houvesse
uma aplicação que fizesse sentido sendo implementada, algo que pudesse
ter um efeito visual interessante, ou seja causar um impacto positivo na
apresentação. O simulador desenvolvido tem essa capacidade e aborda
temas que fazem muito sentido dentro do atual contexto da computação.
Pensando em um mundo onde a informação se torna cada dia mais
disponível, dados são gerados em tempo real e cada vez mais aumenta a
dificuldade de se aplicar filtros que tornem estas informações úteis,
construir um simulador que tem - mesmo que de forma muito simples - um
"context awereness" realmente é bastante interessante.
Além disto, ser capaz de dar alguma inteligência ao simulador atribui ao
projeto um "ar" de jogo, tornando o processo de desenvolvimento mais
divertido e com certeza mais interessante.
Para trabalhos futuros, a quantidade de coisas que podem ser realizadas
dentro do ContextNet realmente é muito grande. Imaginando um escopo
menor, dentro do universo de simuladores, poderíamos encarar o
simulador como uma forma muito simples de "crawler", algo que existe
dentro de um contexto bem específico e é capaz de se utilizar dos dados
deste contexto para realizar ações. Este tipo de aplicação se torna cada dia
mais útil e importante, pois como dito anteriormente, é humanamente
impossível verificar todas as informações que são geradas nos dias de
hoje.
Sobre o simulador, algumas melhorias muito claras poderiam ser
exploradas para gerar um produto com um valor bastante alto, que
realmente possa ser utilizado em trabalhos mais complexos:
Melhoria do algoritmo de caminhamento: Talvez o primeiro passo
seja abolir a forma como o simulador se move atualmente no mapa
e passar a utilizar um algoritmo mais complexo, que realmente
descreva o comportamento de um veículo. Isto porque o simulador
atual não leva em conta diversas propriedades físicas e
matemáticas que poderiam enriquecer muito a aplicação, como:
aceleração, vetor velocidade instantâneo (no simulador atual o vetor
velocidade tem sua direção sempre calculada em relação ao seu
alvo, porém para algoritmos mais realistas as duas coisas poderiam
ser separadas - por exemplo, permitindo o simulador a reconhecer
obstáculos na pista em vez de andar em linha reta até o próximo
objetivo).
Implementação de inferências baseadas em contexto: Apesar se
utilizar de várias informações que são geradas por si e por outros
nós simulados, uma inferência mais complexa não é realizada no
simulador. Isto poderia potencializar em muito o valor gerado pela
aplicação, uma vez que existiria a capacidade de relacionar dados
gerados por diferentes módulos de um sistema como o ContextNet.
Comunicação pub/sub: Já existe no ContextNet a possibilidade de
os nós simulados se comunicarem através de uma API pub/sub.
Este adicional poderia contribuir na forma como os nós simulados
se comunicam e a capacidade de subscrição a determinados
tópicos (e não somente a grupos) não limitaria a capacidade de
resposta a eventos a um ou poucos grupos - por exemplo, se todos
os nós simulados estivessem subscritos ao tópico alertas, todos
poderiam prestar auxílio no caso de uma necessidade, ou ainda
evitar uma zona de perigo, etc.
Melhorar a capacidade de resposta do simulador - o simulador
possui alguma capacidade de resposta mínima e um investimento
em melhorias neste caso poderiam convergir para nós simulados
mais eficientes, capazes de desempenhar mais do que apenas uma
função específica dentro da simulação.
Como mostrado na seção Estado da Arte, existem vários estudos
sobre melhorias no trânsito urbano e também estudos em apoio a
decisão para logística de entregas e/ou resgates. Nestes casos, um
simulador eficiente poderia contribuir com estes estudos, a
capacidade de receber comandos (individualmente ou em grupos)
poderia ser utilizada para testar diferentes situações.
10 Referências
[1] http://www.lac.inf.puc-rio.br/
[2] http://www.lac.inf.puc-rio.br/projects/contextnet
[3] http://www.omg.org/technology/documents/dds_spec_catalog.htm
[4] http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol
[5] Artigo do LAC com mais informações sobre testes
http://www.lac.inf.puc-rio.br/sites/default/files/WETICE-2012.pdf
[6] Amelia C. Regan, Hani S. Mahmassani e Patrick Jaillet. University of
California, Irvine - Jan 1988
[7] Jayakrishnan, R e Mahmassani, H S - University of California, Irvine.
1992
[8] Vuyyuru, R. e Oguchi, K. - Wireless on Demand Network Systems and
Services, 2007
[9] Zeimpekis, V., Giaglis, G., Minis, I. 2006
