Mise en perspective des résultats obtenus

Na rede veicular o acesso à Internet de modo constante é complicado de manter se a cobertura das RSUs não for suficiente. A solução por Wi-Fi funciona bem em casos pontuais em que o carro circula a baixa velocidade, ou se encontra parado junto de zonas de acesso wireless como hotspots. A solução de 3G, apesar de ser a mais simples, é a mais dispendiosa pois o tráfego usado é pago.

Uma das grandes vantagens e inovações que este projecto oferece é a possibilidade de enviar através de outro automóvel, informação para a Internet, como ilustra a figura 16. No caso de a OBU responder negativamente à aplicação quando inquirida sobre a disponibilidade de acesso web, a aplicação pode enviar o pedido para a VANET de modo que a mensagem seja recebida por outra OBU. Para isso é necessário que seja implementado nas OBUs software que funcione como gateway das mensagens de rede veicular para pedidos HTTP. A OBU deve verificar se a mensagem que recebe na interface WAVE é um pedido HTTP de outro veículo; deve depois verificar se possui acesso á Internet através de qualquer uma das interfaces; se existir deve reencaminhar esse pedido para a Web, se não existir deve descartar a mensagem.

38 UtilizadorA SmartPhoneA OBU_A SmartPhoneB UtilizadorB OBU_B Wi-Fi Wi-Fi WAVE 802.11p (1) Pedido http para VANET (2) Pedido http Internet

Figura 16 Representação de implementação da Gateway para pedidos HTTP de terceiros.

Para que esta funcionalidade exista, foi necessário adicionar algum código aos módulos da OBU. Para a aplicação nada altera, uma vez que o envio do pedido é feito, como já foi referido, como se de um qualquer pedido a rede Wi-Fi onde o smartphone está ligado se tratasse. A única alteração que na aplicação pode existir é a questão de decidir quais os pedidos que podem ser ou não forçados a seguir pela VANET quando a OBU à qual o smartphone está ligado não possui conectividade á Internet.

3.5 Sumário

No capítulo 3, foi introduzido o STRIVE. Foram abordados os conceitos teóricos necessários para uma posterior implementação, como arquitectura e modelação.

Foi introduzido o REINVENT, um sistema de troca de mensagens entre smartphones e OBU, já existente que vai ser alterado para que possa ser usado no STRIVE no acesso das mensagens à camada de transporte na rede veicular. Identificaram-se os principais módulos que iriam compor o REINVENT nos componentes necessários do STRIVE, smartphone e OBU.

Para funcionamento do REINVENT utiliza-se uma biblioteca externa de um sistema chamado RabbitMQ.É um gestor de filas de mensagens utilizado nas comunicações, por troca de mensagens, entre módulos do REINVENT o que ajuda a criar a camada de abstracção pretendida.

Foram identificados os principais cenários de utilização do STRIVE e com os cenários foram detectados os principais obstáculos, que se agruparam em 3 grupos: comunicação com sensores do veículo; comunicação dentro da rede; comunicação em escala global através do acesso a Internet. Foi ainda identificado um outro grupo de comunicações intrínseco da comunicação na VANET que pretende criar uma gateway das mensagens da rede veicular para a Internet aumentando o acesso a recursos externos.

39

4.Implementação do STRIVE

Neste capítulo descreve-se em maior detalhe as implementações necessárias para a criação do STRIVE. As implementações nos vários componentes visam dar suporte aos cenários descritos previamente, assim como a lista de funcionalidades para o utilizador.

4.1 Extensões no REINVENT

Como front-end de todo o sistema era necessário usar um dispositivo que processasse dados e não apenas os mostrasse. Como já foi referido, no mundo actual os telemóveis estão a cair em desuso e vieram dar lugar a telefones “inteligentes”, os chamados smartphones, que correndo diferentes tipos de sistemas operativos conseguem ter desempenhos semelhantes a computadores pessoais de há uns anos atrás. É fácil hoje em dia encontrar à venda estes smartphones, de gama média, com processadores de dois ou mais núcleos a trabalhar a frequências elevadíssimas, tudo graças à evolução da nanotecnologia que permite colocar em aparelhos de dimensões reduzidas o que existe em computadores de escritório ou portáteis.

A escolha da plataforma Android, de entre outras disponíveis como iOS ou Windows Phone, prendeu-se principalmente com a experiência que já existia com este sistema operativo, o que permitiu ultrapassar certas barreiras com maior facilidade do que seria com um SO desconhecido. Além deste factor, o facto de Android ser um sistema operativo aberto que pode ser usado em diversos aparelhos, torna mais abrangente o público-alvo e facilita também no processo de testes à aplicação.

De seguida será explicado em traços gerais como foram implementados os principais módulos que compõem a aplicação.

4.1.1 Arquitectura Android

A arquitectura geral de Android, como pode ser observado na figura 17, assenta num núcleo de Linux, camada de mais baixo nível onde estão os controladores que dão acesso aos recursos físicos do telemóvel. Estes recursos não são, normalmente, acedidos directamente pelas aplicações, devido a questões de segurança, mas através de bibliotecas que fazem a gestão de acesso das várias aplicações a esses mesmos recursos. Essas bibliotecas dão ainda lugar a camadas de mais alto nível, frameworks, que juntam diversas bibliotecas para efectuar diversas operações usadas pela maior parte das aplicações.

40

Figura 17 Arquitectura do Sistema Operativo Android, com visualização dos vários componentes internos, nomeadamente Content Providers no qual se baseia o funcionamento do REINVENT.[9]

No STRIVE usamos um Content Provider (application framework) criado pelo REINVENT. Servirão de suporte ao sistema de alerta de recepção e envio de mensagens via RabbitMQ. Utilizamos Serviços (“service”) do Android para implementar o sistema de escuta e processamento de novos alertas emitidos pelo REINVENT (content provider).

Usamos SQLite (base de dados relacional) para assegurar a persistência dos dados localmente no telemóvel nomeadamente dados vindos da placa como GPS e consumos. Esta informação, após processamento é apresentada aos utilizadores. Além destas frameworks, outras de uso mais comum como Activity, Activity Manager, Fragment e Views foram usadas para criar os ecrãs que permitem a visualização dos dados.

4.1.2 Content Providers

Os Content providers (provider) são uma abstracção baseada numa arquitectura REST que permite gerir acessos e partilhar infromação de uma fonte de dados “lógica” entre diferentes aplicações em Android usando uma designação única para lhes aceder - um Uniform Resource Identifier (URI). O content provider (instância da classe que representa o Content Provider) recebe pedidos de dados dos clientes, resolve esse pedido, e devolve o resultado (dados pretendidos).

A utilização de um Content Provider implica o recurso a um Content Resolver (resolver) que e irá mapear no cliente a informação que o provider acede.

O resolver permite que se crie uma escuta para alterações que o provider faça a um determinado recurso. Deste modo quando existe uma alteração e.g. nova mensagem, o provider vai lançar uma notificação para o URI identificador do tipo de mensagem recebido. Todos os tipos de mensagens

41

ficam registados nos respectivos URIs (um por cada tipo) no provider. Assim o resolver irá ser informado de qualquer nova alteração que ocorra nos URIs que estiver à escuta.

O REINVENT suporta todo o processo de gestão de mensagens por meio de um Content Provider acessível para várias aplicações no mesmo dispositivo.

4.1.3 Services

Os serviços (“services”) na plataforma Android são uma solução que permite a uma aplicação realizar determinadas operações de longa duração que não interagem com o utilizador, ou seja que executam em plano de fundo.

No projecto desenvolvido quer na aplicação MyCar, quer no REINVENT instalado no Android (content provider), foram utilizados vários serviços que para verificar a ocorrência de novas mensagens da OBU, e efectuar processamento sobre informação recebida.

Por exemplo, no caso do GPS, figura 18, os serviços suportam um fluxo de processamento que permite difundir e processar os alertas de novos dados desde a OBU até ao smartphone e aplicações cliente. Associando os Serviços ao Content Provider responsáveis pelo acesso a cada tipo de mensagens, é possível verificar em background as alterações lançadas pelo provider e despoletar as operações necessárias que podem ser desde guardar numa base de dados local até ao simples lançar de uma nova notificação de “ nova mensagem já tratada” que vai ser escutada pela aplicação e mostrada ao utilizador.

Figura 18 Ilustração do sistema de alertas