A Infoestrutura assume a capacidade de prover contexto veicular significativo em nuvem, com valor semântico acrescido em relação aos modelos de contexto tradicionais. Dessa maneira, é esperado que o projeto de novas aplicações veiculares cientes do contexto se baseiem na Infoestrutura para consumir contexto veicular significativo, ao invés de incluir em suas arquiteturas suas próprias capacidades de sensibilidade ao contexto. Com isso, é esperado que as aplicações se tornem mais simples, e assim exijam/consumam menos recursos computacionais (como CPU, energia, e armazenamento), para além de impactarem em menor complexidade e custos de implementação. Para isso, a arquitetura da Infoestrutura representa um ecossistema modular, com sub-módulos que vão além dos trabalhos relacionados pelas seguintes propriedades:
• Provisão de informação contextual veicular significativa, com capacidade aumentada de caracterização semântica de situações, condições, e eventos veiculares a partir de múltiplas fontes sensoriais veiculares;
• Mecanismos de inferência contextual baseado em históricos, fazendo uso do Banco de Dados;
• Desacoplamento das camadas de sensoriamento e as de aplicação; e
• Integração facilitada com dados da Web para refino de contexto, assim como disse- minação do contexto diferentes mídias (como páginas Web ou mesmo redes sociais). Como descrito anteriormente, a Infoestrutura deve ser base para aplicações veiculares que adotam contexto veicular como direcionador de suas ações. Cabe as aplicações vei- culares guiadas por contexto instruir a Infoestrutura com os procedimentos para gerar o contexto do seu interesse na nuvem. Portanto, é de responsabilidade da aplicação passar informações essenciais para o processo de contextualização, tais como: veículo alvo, uni- dades sensoriais desse veículo, modelo analítico necessário para geração do contexto, e a forma de devolução da informação contextual. A Figura 9 expõe uma visão geral da ar- quitetura de referência proposta para a Infoestrutura, considerando seus subcomponentes, interfaces internas e externas.
A composição da arquitetura de referência da Infoestrutura é descrita a seguir: • Controlador da Infoestrutura: Esse subsistema é o ponto de entrada da Infoestru-
Figura 9: Arquitetura de Referência da Infoestrutura
mada Remota de Procedimento (RPC) com módulos externos (i.e., Sensores Pro- vedores de Dados, Outras Fontes, Aplicação) cada um com sua interface específica) de modo que possam solicitar as devidas funções a Infoestrutura, como por exem- plo, enviar dados sensoriais, postar informações contextuais em uma rede social, ou ainda acessar a Infoestrutura para configurar uma nova aplicação. As aplicações se utilizam desta interface para enviar instruções para criação de novos contextos ou para consultar as informações contextuais que estejam armazenado na base de dados;
• Repositório de Contexto: Subsistema responsável pelo armazenamento de informa- ções veiculares contextuais. Segue o modelo de Banco de Dados não relacional para suporte ao armazenamento e recuperação de informações. Aplicações tem acesso a estas informações por de eventos sob-demanda controlados pelo módulo Agente de Eventos;
• Codificador de Contexto: Responsável por interpretar as instruções fornecidas pelas aplicações veiculares guiadas pelo contexto. Cabe ao Codificador de Contexto ins- tanciar um Agente de Contexto e um Manipulador específico para cada aplicação
em reposta as suas demandas;
• Agente de Contexto: Subsistema encarregado por consumir os dados dos Sensores Provedores de Dados. O Agente de Contexto implementa interfaces com as tecnolo- gias de cada sensor, permitindo sensoriamento multiparte em simultâneo. O Agente de Contexto segue os padrões temporais quanto a coleta de dados nos sensores res- peitando as instruções fornecidas pelo Codificador de Contexto, aplica o modelo analítico de contextualização sobre os dados sensoriais e os registra em uma tupla no Registro de Contexto criada no memento que a aplicação solicita um novo serviço de contexto;
• Manipulador: O Manipulador é responsável por aplicar regras de ativação guiadas por contexto registrado nas tuplas do Registro de Contexto. Para tal, adota lógica Fuzzy [CINGOLANI; ALCALA-FDEZ, 2012], descritas através de Fuzzy Control Language (FCL) [IEC 61131-7, 1997]. Através do UbiBroker, o Manipulador recebe notificações sempre que uma nova tupla é inserida no Registro de Contexto, para então processar a regra sobre o referido contexto, no intuito de classificar se satisfaz a condição contextual indicada. Em caso positivo, o Agente de Eventos é ativado, caso contrário o Manipulador aguarda a seguinte tupla;
• Agente de Eventos: Responsável em controlar as ativações das aplicações consumi- doras do serviço de contexto veicular em nuvem (i.e., postar em uma rede social que uma via encontra-se congestionada, ou então alarmar uma aplicação que uma de- terminada ação ocorreu) de acordo com que foi requisitado. Dois modelos de reação são suportados:
(i) Programado, gera eventos sempre que alguma condição for satisfeita, o Ma- nipulador o ativa, para avisar a aplicação que tal evento ocorreu. Para além, é capaz de distribuir as informações veiculares contextuais em Outras Fontes de informação (e.g., Facebook, Google+, Twitter) em tempo real, para que usuários interessados em tal situação (e.g., aferir que uma rodovia está con- gestionada e postar tal informação em um perfil do Twitter) possam difundir a seus seguidores tal informação;
(ii) Sob-demanda, neste modelo as aplicações buscam na Infoestrutura informações de seu interesse. Essa operação é do tipo solicitação-resposta, e não requer qual- quer pré-configuração. As informações de interesse serão inferidas no módulo de armazenamento da Infoestrutura e posteriormente são disponibilizadas, caso existam.