Smart city geofences for vulnerable road users

Universidade do Minho Escola de Engenharia Departamento de Inform´ atica Pedro Daniel Gomes Fonseca Smart City Geofences for Vulnerable Road Users October 2019 Universidade do Minho Escola de Engenharia Departamento de Inform´ atica Pedro Daniel Gomes Fonseca Smart City Geofences for Vulnerable Road Users Master dissertation Master Degree in Computer Science Dissertation supervised by Cesar Analide Bruno Fernandes October 2019 i A C K N O W L E D G E M E N T S Em primeiro lugar queria agradecer ao meu orientador Cesar Analide e ao meu coorientador Bruno Fernandes pela disponibilidade demonstrada para me guiar e ajudar durante toda a dissertac¸˜ ao, com um agradecimento especial ao Bruno por todo o empenho demonstrado e disponibilidade para me ajudar em todos os passos da construc¸˜ ao desta dissertac¸˜ ao. Queria agradecer tamb´ em aos meus pais, que tudo fizeram para me dar as melhores condic¸ ˜ oes poss´ ıveis para a conclus˜ ao deste cap´ ıtulo da minha vida. Um agradecimento especial tamb´ em aos meus amigos que sempre estiveram presentes ao longo deste percurso, todas as vivˆ encias e todas as mem´ orias cridas e tamb´ em a todos os meus colegas ao longo dos anos na Associac¸˜ ao Acad´ emica da Universidade do Minho por todo o conhecimento partilhado, as experiˆ encias que partilhamos nas v´ arias atividades realizadas. Por fim, mas n˜ ao menos importante, um grande agradecimento ` a minha namorada que foi um porto seguro para mim, que nunca me deixou perder o foco e que sempre me apoiou em todos os momentos e foi elemento essencial para que conseguisse entregar esta dissertac¸˜ ao. ii A B S T R A C T Some road users have been targeted in a way to try and create systems that help increase their safety. We are referring to, in this instance, pedestrians, cyclists and even motorcyclists whom we call Vulnerable Road Users (VRU) due to the fragility they present when compared to other users that circulate on the same roads, in particular cars. These systems fall within the ambit of the Smart Cities that are increasingly growing all over the world. The objective of this dissertation is to take advantage of geofencing technology, i.e., to create a virtual perimeter for a real geographical location in which it is desired to detect at any moment the entrance or exit of an user. To achieve such goals a mobile app was developed with the purpose of notifying the user as soon as he enters or exits such geofences. A web-based platform was also conceived and designed for city hall administrators where geofences may be created, updated, deleted and classified. The main focus went towards the creation of geofences in specific points of interest for VRUs, i.e., areas that may be considered dangerous for pedestrians when crossing the road, due to bad visibility for instance, signaling road blocks or construction areas that may cause disruption in traffic or even a road accident. Keywords: Geofences, Road Safety, Smart Alerts and Notifications, Smart Cities, Vulnerable Road Users. iii R E S U M O Certos utilizadores dos meios rodovi´ arios tˆ em sido alvo de estudo de forma a tentar criar sistemas que ajudem a aumentar a seguranc¸a dos mesmos. Estamos a falar em concreto de pe˜ oes, ciclistas e at´ e mesmo motociclistas e estes denominam-se VRU sendo que o seu nome adv´ em da fragilidade que apresentam perante os demais utilizadores que circulam nas mesmas estradas, em particular os carros. Estes sistemas inserem-se no ˆ ambito das Smart Cities, cidades tecnol´ ogicas que cada vez mais est˜ ao em crescendo pelo mundo inteiro. O objetivo desta dissertac¸˜ ao ´ e tirar partido das vantagens da tecnologia das geofences, isto ´ e, criar um per´ ımetro virtual para uma localizac¸˜ ao geogr´ afica real na qual se pretende detetar a todo o momento a entrada ou sa´ ıda de um utilizador. Para atingir estes objetivos desenvolveu-se uma mobile app com o prop´ osito de notificar um utilizador, seja este um pedestre, um ciclista ou um condutor, sempre que este entre ou saia de uma dessas geofences. Foi tamb´ em desenvolvida uma plataforma web para um administrador por exemplo um gestor de uma Cˆ amara Municipal, onde pode criar e remover geofences. O foco principal desta dissertac¸˜ ao estar´ a direcionado para a criac¸˜ ao de geofences em pontos de interesse espec´ ıficos para os VRU, isto ´ e, ´ areas que podem ser consideradas perigosas para travessias de pe˜ oes, devido a m´ a visibilidade, de forma a sinalizar acidentes rodovi´ arios ou ainda obras na via p´ ublica que possam causar disrupc¸ ˜ oes no tr´ afego. Palavras-Chave: Avisos Inteligentes, Geofences, Seguranc¸a Rodovi´ aria, Smart Cities,Vulnerable Road Users. iv v C O N T E ´ U D O 1 introduc¸˜ ao 1 1.1Motivac¸˜ ao 2 1.2Objetivos 2 1.3Estrutura do documento 3 2 revis ˜ ao do estado da arte 4 2.1Conceitos 4 2.1.1Vulnerable Road Users 4 2.1.2Smart Cities 5 2.1.3Geofences 6 2.2Trabalho Relacionado 8 2.2.1Spotique Service 8 2.2.2Vehicle-to-Pedestrian Communication Modeling and Collision Avoiding Method in Connected Vehicle Environment 9 2.2.3MotoWarn 11 2.2.4Safety Enhancement Service for Vulnerable Users using P2V12 3 an ´ alise de ferramentas e tecnologias 14 3.1Beacons 14 3.2TomTom Geofencing API 15 3.3Google Geofencing API 17 4 design e implementac¸˜ ao 19 4.1O Problema, Os Seus Desafios e a Soluc¸˜ ao Proposta 19 4.2Arquitetura do sistema 21 4.2.1Plataforma Web 22 4.2.2Mobile Application 23 4.3Design e Modulac¸˜ ao 24 4.3.1Diagramas de Sequˆ encia 24 4.3.2Mock ups 27 4.4Implementac¸˜ ao 30 4.4.1Plataforma Web 30 4.4.2Mobile Application 33 4.5Interface 36 4.5.1Plataforma Web 36 4.5.2Mobile Application 38 vi 1.1. Motivac¸˜ ao 2 1.1motivac¸˜ ao Cada vez mais caminhamos para um mundo onde Smart Cities ser˜ ao uma realidade, possuindo sistemas robustos para suprimir certas dificuldades que por vezes ultrapassam oˆ ambito do ser humano. No caso mais concreto da seguranc¸a rodovi´ aria com maior foco para os chamados VRU, dado que a sinistralidade rodovi´ aria continua a ter n´ umeros preocupantes, existe uma necessidade de se criarem sistemas inteligentes que atrav´ es da an´ alise de padr˜ oes de conduc¸˜ ao, do envio de avisos inteligentes sobre pe˜ oes ou ve´ ıculos nas proximidades, ajudem a diminuir estes n´ umeros. Considerando estes fatores assim como a possibilidade de contribuir para as cidades do amanh˜ a temos patente as maiores motivac¸˜ oes para o tema desta dissertac¸˜ ao, o desenvolvimento de um sistema que detete a presenc¸a de pe˜ oes e ve´ ıculos em certos locais considerados de maior risco para os VRU, de forma a previnir cen´ arios como atropelamentos que s˜ ao um grave problema no mundo inteiro e a contribuic¸ ˜ ao que ´ e feita para a sociedade com sistemas deste tipo que se provam cada vez mais essenciais para melhorar a qualidade de vida no nosso planeta. 1.2objetivos O objetivo principal desta dissertac¸˜ ao ´ e o de desenvolver um sistema que permita criar e remover geofences, nas quais os utilizadores numa mobile app conseguem em tempo real receber notificac¸ ˜ oes da sua entrada e sa´ ıda das geofences assim como informac¸ ˜ oes sobre a categorizac¸ ˜ ao das mesmas. Para tal ´ e necess´ ario a criac¸ ˜ ao de uma plataforma web na qual se faz toda a gest˜ ao da criac¸ ˜ ao, remoc¸˜ ao e categorizac¸ ˜ ao das geofences e uma aplicac¸ ˜ ao para o utilizador no qual este ´ e notificado das suas entradas e sa´ ıdas das geofences ativas mas tamb´ em onde possa visualizar as mesmas e onde possa ele pr´ oprio fazer sugest˜ oes para o administrador, que ser´ a respons´ avel pela verificac¸˜ ao dos dados recebidos. Esta dissertac¸˜ ao providencia ent˜ ao as seguintes contribuic¸ ˜ oes: •Conceber e desenvolver uma arquitetura modular e extens´ ıvel para a base de um sistema para detetar a presenc¸a de VRU na ´ area das geofences; •Identificac¸ ˜ ao de locais adequados para a implementac¸ ˜ ao de uma geofence; •Identificac¸ ˜ ao e caracterizac¸ ˜ ao de entradas, sa´ ıdas e presenc¸as de VRU; •Criac¸ ˜ ao de uma plataforma web para gest˜ ao de geofences; •Criac¸ ˜ ao de uma mobile app que faz uso de um sistema de avisos inteligentes para notificar VRUs da presenc¸a, entrada e sa´ ıda de geofences; •Criac¸ ˜ ao de avisos inteligentes para serem fornecidos aos VRU. 1.3. Estrutura do documento 3 1.3estrutura do documento Este documento est´ a organizado da seguinte maneira: No Cap´ ıtulo 2´ e feita uma revis˜ ao do estado da arte comec¸ando por olhar para conceitos e tecnologias que servem de base ao problema em si. Ser˜ ao apresentados outros sistemas e soluc¸ ˜ oes anteriormente feitas para esta problem´ atica, dando um foco maior para os que j´ a utilizem uma tecnologia semelhante ` a que ser´ a usada para apresentar a soluc¸˜ ao do tema desta dissertac¸ ˜ ao. No Cap´ ıtulo 3ser˜ ao apresentadas e analisadas v´ arias tecnologias que poderiam ser utilizadas para esta dissertac¸˜ ao como os Gimbal 10 Series Beacons,Google Geofencing API e TomTom Geofencing API, determinando os seus pontos fortes e pontos fracos, fazendo sempre comparac¸ ˜ oes entre elas de forma a ajudar na determinac¸˜ ao da mais adequada para esta dissertac¸ ˜ ao. No Cap´ ıtulo 4´ e feita uma abordagem ao problema em m˜ aos, descrevendo todos os fatores importantes, os principais desafios a ultrapassar, a comparac¸˜ ao final entre as v´ arias soluc¸ ˜ oes referidas no cap´ ıtulo anterior e por fim, a soluc¸˜ ao proposta. ´ E apresentada a soluc¸ ˜ ao implementada e o seu design. Refere-se de forma geral a arquitetura de todo sistema, constroem-se diagramas de sequˆ encia para as principais funcionalidades, apresentamse mock ups para ambas as componentes do sistema, descreve-se a metodologia utilizada para a implementac¸ ˜ ao do sistema e por fim apresenta-se a interface final de tanto a plataforma web como da mobile app. No Cap´ ıtulo 5apresenta-se um caso de estudo que serve de base para a obtenc¸˜ ao de resultados que posteriormente ser˜ ao analisados de forma a concluir a utilidade do sistema. Por fim, no Cap´ ıtulo 6faz-se uma conclus˜ ao sobre o trabalho desenvolvido assim como uma introspec¸˜ ao sobre o que foi realizado e os resultados obtidos, fazendo por fim uma ilac¸ ˜ ao do que poderia ser melhorado como trabalho futuro. 2 R E V I S ˜ A O D O E S TA D O D A A RT E A revis˜ ao do estado da arte ´ e feita de forma a que seja poss´ ıvel entender todo o trabalho j´ a realizado sobre esta problem´ atica por outros investigadores, como abordaram o problema, que ferramentas utilizaram, a que conclus˜ oes chegaram e qual o trabalho futuro que pode ser desenvolvido para melhorar ou aperfeic¸oar a sua abordagem. Esta revis˜ ao deve ser feita tanto para artigos em que tenha sido utilizada a tecnologia das geofences, assim como outros m´ etodos que tenham como objetivo aumentar a seguranc¸a dos chamados VRU, num contexto de Smart City. Assim no cap´ ıtulo 2.1.1´ e apresentado o conceito de VRU, no cap´ ıtulo 2.1.2´ e definido o conceito de Smart City e por fim no cap´ ıtulo 2.1.3´ e explicado o que s˜ ao geofences. 2.1conceitos 2.1.1Vulnerable Road Users Como foi referido anteriormente, o foco principal desta dissertac¸˜ ao s˜ ao os VRU e como aumentar a sua seguranc¸a. Primeiramente ´ e importante perceber quem s˜ ao estes VRU. S˜ ao considerados como VRU, quaisquer utilizadores de rodovias cujo ve´ ıculo utilizado seja considerado como fr´ agil, em caso de acidente. Mais fr´ agil ainda ser´ a aquele que nem ve´ ıculo utiliza, que neste caso ser˜ ao os pe˜ oes. Ora, quando falamos de ve´ ıculos fr´ ageis estamo-nos a referir a bicicletas e motociclos (Constant and Lagarde (2010)). Em caso de acidente, este tipo de utilizadores s˜ ao os mais fr´ ageis e mais sujeitos a consequˆ encias graves, devido ` a falta de protec¸˜ ao que apresentam perante os demais utilizadores como carros, autocarros, cami˜ oes etc. Como tal, tˆ em sido feitos estudos e propostas para a criac¸˜ ao de sistemas que tentam aumentar o n´ ıvel de seguranc¸a dos VRU quando circulam nas estradas. A grande parte deste tipo de sistemas est´ a, neste momento, mais vocacionado para ser utilizado nos carros pois ´ e o ve´ ıculo onde ser´ a mais f´ acil introduzir tecnologia que muitas vezes ocupa algum espac¸o ou necessita de certas caracter´ ısticas que motociclos e bicicletas n˜ ao possuem. Falamos de sistemas de prevenc¸˜ ao de colis˜ ao, por exemplo, que at´ e englobam para al´ em dos VRU, ou4 2.1. Conceitos 5 tros ve´ ıculos. Esta tecnologia est´ a a ter grande avanc¸o no mercado autom´ ovel sendo que muitos carros hoje em dia j´ a possuem sistemas que, abaixo de uma certa velocidade fazem o carro travar automaticamente caso este detete um objeto no seu caminho. Existem muitas marcas que j´ a tˆ em esta tecnologia implementada nos seus carros como por exemplo, a Toyota, a Tesla e muitos outros (Wong (n.d.), Tesla (2018)). 2.1.2Smart Cities Smart Cities ´ e um conceito em crescendo de importˆ ancia na sociedade e que tem como objetivo melhorar a qualidade de vida dos seus habitantes. Isto ´ e alcanc¸ado atrav´ es da recolha de dados utilizando por exemplo sensores, o que obriga a um posterior tratamento destes mesmos dados para que se possa fazer a correta gest˜ ao dos dispositivos em uso e feitos ajustes para melhorar a eficiˆ encia dos sistemas implementados para tirar o maior proveito do conceito de Smart Cities (Figura 1). Figura 1: Exemplo da estrutura uma Smart City (Artusse (n.d.)) As Smart Cities definem-se pela sua infra-estrutura de comunicac¸˜ ao, pelos seus espac¸os digitais assim como pelas ferramentas p´ ublicas que disponibiliza aos seus habitantes. Ou seja, uma s´ erie de sistemas que contribuam para a melhoria da qualidade de vida de todos os seus habitantes. Vamos ent˜ ao desta forma apresentar definic¸ ˜ oes do que ´ e uma Smart City sabendo sempre que a sua definic¸˜ ao e conceptualizac¸ ˜ ao ainda est´ a em progesso: (Boulton and Brunn (2011), Hollands (2008)) •“The use of Smart Computing technologies to make the critical infrastructure components and services of a city––which include city administration, education, healthcare, public safety, real estate, transportation, and utilities––more intelligent, interconnected, and efficient.” (Washburn (2010)). 2.1. Conceitos 6 •”A city that monitors and integrates conditions of all of its critical infrastructures, including roads, bridges, tunnels, rails, subways, airports, seaports, communications, water, power, even major buildings, can better optimize its resources, plan its preventive maintenance activities, and monitor security aspects while maximizing services to its citizens.”(Hall (2000)). •”A city well performing in a forward-looking way in economy, people, governance, mobility, environment, and living, built on the smart combination of endowments and activities of self-decisive, independent and aware citizens.”(Giffinger (2007)). Da leitura destas definic¸ ˜ oes e aglomerando numa s´ o definic¸ ˜ ao, conclu´ ımos que o prop´ osito de uma Smart City ser´ a incluir uma variedade de sistemas e tecnologias que monitorizem fatores e ´ ındices presentes numa cidade e que comuniquem entre si para otimizar os v´ arios recursos e sectores de uma cidade, de forma a aumentar a qualidade de vida de todos os seus habitantes. Existe uma grande variedade de abordagens existentes para resolver certos problemas no que diz respeito, por exemplo, ` a seguranc¸a de pe˜ oes no meio rodovi´ ario. Neste caso em concreto, o tema desta dissertac¸ ˜ ao foca-se em aplicar o conceito de geofences de forma a tentar providenciar maior seguranc¸a aos chamados VRU. Da´ ı que o tema desta dissertac¸ ˜ ao seja Smart City Geofences for Vulnerable Road Users. 2.1.3Geofences Um conceito muito importante para esta dissertac¸ ˜ ao s˜ ao as geofences. As geofences s˜ ao per´ ımetros virtuais para um local geogr´ afico real, no qual ´ e controlada a entrada, sa´ ıda e presenc¸a de aparelhos, pessoas e outros (Figura 2). Uma aplicac¸ ˜ ao desta tecnologia pode ser por exemplo numa empresa de venda de produtos, esta pode aumentar as suas vendas se, por exemplo, atrav´ es do uso geofences nas imediac¸ ˜ oes dos seus estabelecimentos, envie uma mensagem com um cup˜ ao para os utilizadores usarem. Um caso muito conhecido de utilizac¸˜ ao de geofences ocorreu recentemente e envolveu o Burger King e o McDonald’s. O Burger King utilizou a tecnologia das geofences integrada na sua nova aplicac¸˜ ao, na qual sempre que um utilizador estivesse num raio de sensivelmente 200 metros de um restaurante McDonald’s, a aplicac¸˜ ao enviava uma notificac¸ ˜ ao na qual oferecia uma promoc¸˜ ao num certo hamburger ficando este pelo prec¸o de um penny (Garcia (2018)). Tamb´ em no mercado do imobili´ ario, em concreto nos Estados Unidos da Am´ erica, est´ a a ser estudada a possibilidade de utilizar geofences para o chamado Open House Marketing, no qual ´ e enviada uma mensagem a potenciais compradores sempre que estes estejam nas imediac¸ ˜ oes de uma destas casas (Suart (n.d.)). 2.1. Conceitos 7 Figura 2: Exemplo de uso de uma geofence Bonack (n.d.) Outra aplicac¸ ˜ ao pode ser para controlo parental, determina-se um per´ ımetro do qual uma crianc¸a n˜ ao pode sair e caso o fac¸a os pais recebem uma notificac¸˜ ao no seu smartphone (De Lara (2008)). Outro contexto de aplicac¸˜ ao desta tecnologia passa por utilizar geofences como m´ etodo para a ativac¸˜ ao ou desativac¸˜ ao de armas de fogo, isto ´ e, um utilizador que possua uma arma em casa para auto-defesa, esta apenas funcionar´ a no per´ ımetro da sua residˆ encia sendo desativada sempre que esteja fora do mesmo, impossibilitando-a de ser usado noutro local para outro prop´ osito. Existem v´ arias formas de implementar uma geofence, a Google por exemplo j´ a d´ a acesso a uma API que permite a criac¸ ˜ ao de geofences (Google (n.d.a)). Outro m´ etodo passa pela utilizac¸ ˜ ao de v´ arios sensores para criar um per´ ımetro virtual numa localizac¸˜ ao geogr´ afica real. Atrav´ es do uso de sensores pode-se controlar o n´ umero de entradas, sa´ ıdas e presenc¸as de pessoas (Fernandes et al. (2018)). Este modo de implementac¸˜ ao pode ter muitos usos, especialmente no foro comercial mas tamb´ em no foro da seguranc¸a. Por exemplo, para uma superf´ ıcie comercial, saber quantas pessoas entraram em determinadas lojas ou visitaram certas partes de um centro comercial pode ser informac¸˜ ao muito valiosa para perceber se, por exemplo, uma certa loja tem pouco neg´ ocio porque poucas pessoas, em m´ edia passam por aquela zona do centro comercial. 2.2. Trabalho Relacionado 8 2.2trabalho relacionado Neste cap´ ıtulo ser´ a feita uma exposic¸ ˜ ao de todo o trabalho j´ a realizado sobre esta tem´ atica da seguranc¸a dos VRU e como garantir um aumento da sua seguranc¸a quando circulam em rodovias. No cap´ ıtulo 2.2.2´ e introduzido um exemplo da arquitetura de um sistema que usa uma rede Vehicle-to-Pedestrian (V2P) com comunicac¸ ˜ oes em tempo real de forma a prevenir acidentes. No cap´ ıtulo 2.2.3apresentamos uma soluc¸˜ ao de uma aplicac¸ ˜ ao que utiliza comunicac¸ ˜ ao unilateral entre o ve´ ıculo e os demais. No cap´ ıtulo 2.2.4´ e apresentado um sistema de comunicac¸ ˜ ao Pedestrian-to-Vehicular (P2V) para a seguranc¸a de VRU. 2.2.1Spotique Service Este projeto ´ e feito no contexto de Geofence and Network Proximity onde ´ e feito um estudo e posteriormente criac¸ ˜ ao de um sistema que tem como objetivo a substituic¸˜ ao da chamada geo data por network proximity. Esta necessidade adv´ em em parte, de um grande problema que os chamados Location Based Systems (LBS) atualmente tˆ em, que ´ e um grande consumo energ´ etico. Quando nos referimos a este consumo estamos claro a falar no lado do cliente pois este valor s´ o´ e elevado devido ` a reduzida capacidade das baterias no qual este sistemas correm, que neste caso em concreto ser˜ ao os smartphones (Namiot and Sneps-Sneppe (2013)). Este servic¸o tira partido de sinais de Wi-Fi que estejam nas imediac¸ ˜ oes de um Access Point, por exemplo, e grac¸as aos probes que por norma s˜ ao feitos entre os aparelhos, ´ e capaz de retirar informac¸ ˜ oes como a forc¸a do sinal e o enderec¸o MAC (Namiot and SnepsSneppe (2013)). Atrav´ es do uso de servic¸os como o Google Cloud Messaging for Android e do Apple Push Notification ´ e poss´ ıvel enviar para todos os utilizadores que se encontrem dentro do per´ ımetro da geofence uma mensagem sem que em momento algum seja necess´ ario explicitamente localizar o cliente, permitindo assim manter um certo n´ ıvel de privacidade. Este servic¸o pelas suas caracter´ ısticas permite tamb´ em que se reduza muito o consumo energ´ etico nos aparelhos m´ oveis comparativamente aos m´ etodos tradicionais. Esta forma de implementar geofences demonstra uma boa aplicac¸˜ ao para um sistema no interior de um edif´ ıcio ou algo semelhante, n˜ ao sendo o ˆ ambito pretendido para esta dissertac¸˜ ao mas que serve de exemplo para demonstrar outras poss´ ıveis aplicac¸ ˜ oes da tecnologia. Apresentamos por fim a figura 3retirada de Namiot and Sneps-Sneppe (2013) que representa o caso de estudo para a aplicar esta tecnologia. 2.2. Trabalho Relacionado 9 Figura 3: Detec¸˜ ao de Wi-Fi beacons (Spotique) 2.2.2Vehicle-to-Pedestrian Communication Modeling and Collision Avoiding Method in Connected Vehicle Environment Como referenciado em He et al. (2008) uma poss´ ıvel abordagem a esta problem´ atica passa por desenvolver uma rede V2Pcom comunicac¸ ˜ oes em tempo real. O sistema implementado funciona ` a base de comunicac¸ ˜ oes indiretas a uma distˆ ancia curta entre os ve´ ıculos e os pe˜ oes, atrav´ es do uso de um equipamento idealmente colocado ` a beira da estrada que funciona como nodo central entre as comunicac¸ ˜ oes e os intervenientes. Esta comunicac¸ ˜ ao V2P´ e modelada atrav´ es da criac¸ ˜ ao de um modelo geom´ etrico estoc´ astico combinado com uma func¸ ˜ ao que efetua estimativas de risco. Este modelo, formula os variados efeitos tendo em considerac¸ ˜ ao as variadas incertezas ou dificuldades que este sistema V2Ppode encontrar (He et al. (2008)). Os autores identificaram neste artigo certas dificuldades que maioritariamente s˜ ao consideradas como globais ` a tem´ atica aqui estudada: •Latˆ encia entre comunicac¸ ˜ oes feitas entre o ve´ ıculo e o pe˜ ao; •Incerteza da precis˜ ao dos sistemas de localizac¸˜ ao para a determinac¸˜ ao da posic¸ ˜ ao do ve´ ıculo e do pe˜ ao; •Incerteza no comportamento do pe˜ ao. A mais relevante destas incertezas ´ e sem d´ uvida a latˆ encia entre as comunicac¸ ˜ oes feitas entre o ve´ ıculo e o pe˜ ao. Dado que situac¸ ˜ oes como a referida anteriormente s˜ ao time sensitive, haver um atraso consider´ avel entre as comunicac¸ ˜ oes pode significar que o sistema n˜ ao responde a tempo e portanto n˜ ao ´ e poss´ ıvel evitar-se um acidente podendo resultar na perda de uma ou mais vidas, no caso mais dr´ astico. 2.2. Trabalho Relacionado 10 A incerteza da precis˜ ao dos sistemas utilizados para determinar a posic¸˜ ao dos intervenientes ´ e tamb´ em uma dificuldade que p˜ oe em causa o correto funcionamento do sistema. A maior parte dos sistemas que utilizam Global Positioning System (GPS) n˜ ao s˜ ao capazes de determinar uma localizac¸ ˜ ao precisa pois por norma, o GPS tem uma imprecis˜ ao de at´ e10 metros, sendo que esta imprecis˜ ao pode ainda piorar quando conjugada com outros fatores existentes que podem levar a que a precis˜ ao do GPS diminua como, condic¸ ˜ oes climat´ ericas ou obstruc¸ ˜ ao do sinal por parte de infraestruturas como, tun´ eis, edif´ ıcios, ´ arvores, entre outros (He et al. (2008)). Por ´ ultimo, a incerteza no comportamento do pe˜ ao ´ e um fator que n˜ ao pode ser desconsiderado de maneira alguma. Por vezes ´ e imprevis´ ıvel que um pe˜ ao atravesse a estrada sem antes verificar se o pode fazer em seguranc¸a e este tipo de comportamentos assim como muitos outros podem afetar os resultados obtidos nos testes efetuados para determinar a viabilidade do sistema. Figura 4: Apresentac¸˜ ao dos v´ arios cen´ arios: (a) Pe˜ ao atravessa a estrada em local sem linha de vis˜ ao, (b) curva ` a direita numa intersec¸˜ ao, (c) curva ` a esquerda numa intersec¸˜ ao, (d) descric¸˜ ao abstrata e generalizada de um sistema de movimento relativo Neste caso em concreto optaram por testar a tecnologia num cen´ ario em que n˜ ao existe campo de vis˜ ao entre o condutor e o pe˜ ao. Para melhor compreens˜ ao apresenta-se na figura 4, uma figura retirada de He et al. (2008) onde se exemplifica os casos de teste estudados para a realizac¸˜ ao do artigo. Ap´ os a realizac¸˜ ao de v´ arios testes no campus da Universidade de Alberta os autores conclu´ ıram que se o ve´ ıculo se deslocar a velocidades mais elevadas ´ e necess´ ario que a precis˜ ao do GPS seja maior, assim como uma menor 2.2. Trabalho Relacionado 11 latˆ encia na comunicac¸ ˜ ao V2P. Consideraram tamb´ em que para velocidades superiores a 90 km/h adoptar uma tecnologia como o Bluetooth ou o Wi-Fi como m´ etodo responsivo e de controlo n˜ ao ser´ a suficiente, ao inv´ es, o uso de uma Dedicated Short-Range Communication (DSRC) com a sua baixa latˆ encia e combinado com a tecnologia do Bluetooth, seria capaz de cumprir os requisitos para que de facto fosse capaz de providenciar protec¸˜ ao ativa a pe˜ oes que circulem nas rodovias. 2.2.3MotoWarn Anaya et al. (2015) no seu artigo sobre a detec¸˜ ao de VRU, abordam a problem´ atica da seguranc¸a dos mesmos propondo um modelo em que o centro da informac¸˜ ao estar´ a do lado do ve´ ıculo e a comunicac¸ ˜ ao ser´ a unilateral. Neste exemplo em concreto n˜ ao s˜ ao inclu´ ıdos pe˜ oes mas sim bicicletas e motociclos. Para o efeito, apresentam uma Vehicular Ad-Hoc Network onde os nodos ser˜ ao ve´ ıculos ou access points colocados junto ` as estradas, onde n˜ ao existe uma infraestrutura pr´ e-definida e a rede ser´ a descentralizada. As comunicac¸ ˜ oes ser˜ ao feitas atrav´ es de uma VANET onde o ve´ ıculo ligeiro ser´ a o principal emissor e recetor de informac¸ ˜ ao. Este tipo de redes s˜ ao conhecidas como Vehicle-to-X (V2X). De forma a manter uma boa qualidade nas comunicac¸ ˜ oes e para que sejam o mais completas poss´ ıveis, cada nodo da VANET ter´ a de conter uma s´ erie de protocolos organizado como demonstra na figura 5, a qual foi retirada de Anaya et al. (2015). Figura 5: Stack do modelo de comunicac¸˜ ao Como referido anteriormente, motociclos e bicicletas s˜ ao dois dos grupos pertencentes aos VRU devido ` as limitac¸ ˜ oes que os mesmos possuem, por falta de espac¸o e pouco peso, para a inclus˜ ao de tecnologia com o intuito de aumentar a sua seguranc¸a. Neste sistema o 3.3. Google Geofencing API 18 •Longitude •Raio A latitude e longitude definem ponto central da geofence que combinado com o raio define o per´ ımetro da geofence. (Figura 8) Figura 8: Exemplo da implementac¸˜ ao da API da Google (n.d.b) Ap´ os a criac¸ ˜ ao das geofences,´ e necess´ ario ficar ` a escuta por transic¸ ˜ oes de entrada e sa´ ıda das mesmas, para tal utiliza-se o Broadcast Receiver que ´ e acionado quando o Location Service envia um Intent. Apresenta ainda uma limitac¸˜ ao, no que diz respeito ao n´ umero de geofences ativas num dado momento, pois este nunca poder´ a ultrapassar os cem, sendo que poder´ a na verdade ser suficiente mediante o tamanho da zona que se pretende fazer este controlo e gest˜ ao. 4 D E S I G N E I M P L E M E N TA C¸ ˜ A O Neste cap´ ıtulo ir´ a ser feita uma abordagem ao problema, os seus principais desafios e a soluc¸ ˜ ao proposta. ´ E ainda apresentada a arquitetura do sistema e a sua ilustrac¸ ˜ ao. Recorrendo ` a linguagem Unified Modeling Language (UML) ser˜ ao criados diagramas de sequˆ encia para as v´ arias atividades existentes, como adicionar e remover geofences e adicionar e remover sugest˜ oes. Ir´ a ser feita tamb´ em uma descric¸ ˜ ao de todo o processo de implementac¸˜ ao da plataforma web assim como da mobile app, ser˜ ao apresentadas as mock ups desenhadas para ambos na ferramenta MarvelApp e por fim, ser´ a feita uma apresentac¸˜ ao da interface final destas duas componentes. 4.1o problema,os seus desafios e a soluc¸˜ ao proposta Como j´ a foi indicado anteriormente, para a implementac¸˜ ao do sistema ser´ a necess´ ario o desenvolvimento de uma plataforma web de forma a criar as geofences nos locais identificados como de relevˆ ancia pelos mais variados motivos. ´ E necess´ ario tamb´ em, criar uma aplicac¸ ˜ ao funcional que fac¸a os avisos inteligentes mediante a entrada e sa´ ıda das geofences ativas. As soluc¸ ˜ oes existentes para a problem´ atica da seguranc¸a de VRUs aquando da sua circulac¸˜ ao nas estradas acabam, em grande parte, por ter bons resultados mas s˜ ao ainda, de certa forma, limitadas e por vezes n˜ ao extens´ ıveis. Mais ainda, algumas destas soluc¸ ˜ oes necessitam que sejam criados aparelhos a serem integrados em ve´ ıculos para que se possa fazer o controlo da sua localizac¸˜ ao de forma correta, n˜ ao sendo isto pr´ atico. A soluc¸ ˜ ao proposta aqui, passa por identificar locais de alto congestionamento ou de m´ a visibilidade, entre outros, propensos a que existam acidentes envolvendo VRU, criando uma geofence no per´ ımetro desse local. Passa ainda, por permitir sinalizar acidentes na rodovia grac¸as ao servic¸o de geofencing ou ainda avisar da existˆ encia de zonas que se encontram em obras para o que o utilizador possa adequar o seu trajeto mediante essa informac¸ ˜ ao. A tecnologia escolhida para este fim foi a da Google. Olhando para a tabela 1, observamos que existem muitas similaridades entre a API da Google e da TomTom, no entanto a facilidade de criac¸ ˜ ao de avisos inteligentes para os utilizadores pesou na escolha, mais ainda com 19 4.1. O Problema, Os Seus Desafios e a Soluc¸˜ ao Proposta 20 Gimbal TomTom Google Criar geofences Remover geofences Detetar transic¸ ˜ oes Detetar outros utilizadores dentro da geofence Emitir avisos inteligentes Sem custo de implementac¸˜ ao Sem colocac¸˜ ao f´ ısica das geofences Tabela 1: Comparac¸˜ ao entre as v´ arias API fatores extra como o facto de esta ter bastante mais documentac¸˜ ao de suporte. Comparando com os beacons da Gimbal, denotamos que esta ´ ultima permite a detec¸˜ ao em qualquer momento de utilizadores dentro das geofences o que permitiria ` amobile app fazer avisos mais completos de forma a aumentar a seguranc¸a dos VRU. No entanto, utilizando estes beacons para a criac¸˜ ao das geofences,´ e necess´ ario a colocac¸˜ ao f´ ısica dos beacons nos v´ arios locais a controlar o que n˜ ao se prova muito pr´ atico acarretando ainda um custo por cada beacon utilizado pois ´ e necess´ ario fazer a sua compra. Mais ainda, numa fase inicial do trabalho de investigac¸˜ ao, experimentou-se implementar um simples caso de estudo recorrendo a beacons. Contudo, ap´ os v´ arios problemas e falta de suporte decidiu-se contactar a empresa respons´ avel pelos mesmos, tendo sido verificado que, na Uni˜ ao Europeia, os beacons tinham sido bloqueados devido ao Regulamento Geral de Protec¸ ˜ ao de Dados (RGPD), pelo que a opc¸ ˜ ao dos beacons se tornou invi´ avel. A identificac¸ ˜ ao dos locais a controlar ser´ a um passo de grande importˆ ancia ap´ os a conclus˜ ao do sistema. Um dos desafios ser´ a fazer a triagem dos locais que possam satisfazer os crit´ erios desejados, triagem esta que pode ou n˜ ao ser demorada mediante a ´ area escolhida para testar o sistema. O ideal ser´ a encontrar locais de muito congestionamento tanto de carros como de VRU. Outros locais podem tamb´ em cumprir os requisitos caso sejam considerados perigosos, e possivelmente serem selecionados para local de teste. Dado que se pretende que o administrador seja, por exemplo, uma entidade como uma Cˆ amara Municipal, criar uma geofence do tipo obras ser´ a perfeitamente determin´ avel de antem˜ ao dado que esta tem de ser informada deste tipo de acontecimentos. Quanto ` a determinac¸ ˜ ao da existˆ encia de um acidente na via p´ ublica, isto pode-se processar de duas formas, a primeira ser´ a pelos canais tradicionais com que este tipo de entidades s˜ ao informadas, a segunda ser´ a atrav´ es de feedback dos utilizadores, que ser´ a proporcionado pela mobile app. Um local que numa fase inicial pode servir de local de teste do tipo Zona Perigosa, situa-se junto ` a cantina da Universidade do Minho, como mostra na figura 9.´ E um local onde todos os dias passam centenas, se n˜ ao milhares de pessoas por dia que, devido aos carros estacionados, 4.2. Arquitetura do sistema 21 tem pouca visibilidade e portanto, como caso inicial de teste adequa-se para este tipo de geofence. Figura 9: Poss´ ıvel local de teste De forma a implementar este sistema, ser´ a necess´ ario criar duas aplicac¸ ˜ oes. Uma primeira, plataforma web, na qual um administrador tem de ser capaz de adicionar uma nova geofence, tem de ser capaz de remover geofences ativas e ainda poder-las categorizar e visualizar num mapa. O segundo passo ser´ a criar uma aplicac¸ ˜ ao destinada ao end user na qual este dever´ a ser capaz de visualizar a sua posic¸ ˜ ao, assim como as geofences ativas. Deve ainda, utiliando os servic¸os de localizac¸ ˜ ao, corretamente identificar a entrada, sa´ ıda e presenc¸a dos utilizadores, com maior ˆ enfase para os VRU. Com esta informac¸˜ ao, a aplicac¸˜ ao dever´ a emitir avisos em resposta a estes eventos identificando a geofence na qual houve uma transic¸˜ ao assim como o tipo da mesma, de forma a que o utilizador possa antecipar e ajustar o seu comportamento. Os avisos devem ser o mais completos e corretos poss´ ıveis para que a efic´ acia do sistema tenha impacto direto na seguranc¸a de quem circula na estrada. 4.2arquitetura do sistema Como referido anteriormente, a implementac¸˜ ao deste sistema dividiu-se em duas partes. Primeiramente, o desenvolvimento da plataforma web para a gest˜ ao por parte de um administrador de todo o sistema, na qual, este ser´ a capaz de adicionar novas geofences, remover as existentes, assim como visualiz´ a-las num mapa recorrendo ` a tecnologia Google Maps. Ter´ a ainda adicionalmente, acesso a uma lista de sugest˜ oes com coordenadas geogr´ aficas enviadas pelos utilizadores da mobile app de forma a poder ajudar e complementar todo o processo de identificac¸˜ ao de potenciais locais que devem ser monitorizados pelo sistema. A segunda parte, passa pelo desenvolvimento da referida aplicac¸˜ ao para os utilizadores, na qual estes ser˜ ao capazes de visualizar num mapa, criado novamente recorrendo ` aAPI Google Maps, centrado na sua posic¸˜ ao, todas as geofences ativas naquele instanste, recebendo notificac¸ ˜ oes de entrada e sa´ ıda das mesmas de forma a que possam adequar o seu com- 4.2. Arquitetura do sistema 22 Figura 10: Arquitetura do sistema portamento enquanto l´ a permanecerem. Ter´ a ainda a possibilidade de, carregando num bot˜ ao, visualizar no mapa a localizac¸˜ ao da geofence mais pr´ oxima em relac¸˜ ao ` a sua posic¸ ˜ ao atual, assim como sugerir ao administrador do sistema, novas geofences a adicionar, caso considere pertinente. Apresenta-se na figura 10 a aquitetura do sistema. 4.2.1Plataforma Web Para o desenvolvimento da plataforma web utilizou-se tecnologias como o JavaScript, HTML,CSS e recorreu-se ainda ao Google Firebase para fazer armazenamento persistente dos dados necess´ arios para criar as geofences. Definiu-se ent˜ ao que esta plataforma deveria ter as seguintes componentes: •Formul´ ario no qual o utilizador pode preencher os dados para a criac¸˜ ao das geofences: –Nome; –Latitude; –Longitude; –Raio; –Tipo da geofence. 4.2. Arquitetura do sistema 23 •Tabela com a lista das geofences ativas: –Nome que lhes foi atribu´ ıdo; –Tipo da geofence; –Bot˜ ao para as remover. •Tabela com a lista de sugest˜ oes enviadas pelos utilizadores: –Coordenadas geogr´ aficas enviadas pelo utilizador; –Bot˜ ao para as remover. •Mapa onde possa visualizar as geofences ativas: –Bot˜ ao para entrar em modo Street View para melhor visualizar certos locais; –Permitir com um clique no mapa determinar as coordenadas geogr´ aficas daquele ponto; –Permitir com um clique nas geofences ativas determinar a qual se refere, detalhando os seus parˆ ametros que a constituem; –Permitir ainda visualizar o estado do trˆ ansito, sendo este um bom indicador para determinar poss´ ıveis locais de acidentes. Para que todo este sistema funcione e seja persistente ´ e necess´ ario guardar os dados submetidos de cada geofence para que elas sejam vis´ ıveis para todos os utilizadores, a qualquer momento. 4.2.2Mobile Application Esta aplicac¸ ˜ ao ser´ a dispon´ ıvel para todos os potenciais utilizadores, com foco especial nos VRU pois s˜ ao os mais impactados de forma positiva pelo sistema delineado que tem como objetivo aumentar a seguranc¸a rodovi´ aria. Para todo o desenvolvimento da aplicac¸˜ ao escolheu-se utilizar a linguagem Java, utilizando o Android Studio como ambiente de desenvolvimento. Em termos de interface esta aplicac¸˜ ao ser´ a bastante simples, tendo apenas um ecr˜ a no qual o utilizador consegue visualizar num mapa todas as geofences ativas, dispondo ainda de um conjunto de funcionalidades como: •Centrar o mapa na sua posic¸ ˜ ao. •Pesquisar no mapa pela geofence mais pr´ oxima em relac¸˜ ao ` a sua posic¸ ˜ ao atual. •Sugerir a adic¸ ˜ ao de uma nova geofence ao sistema, enviando as suas coordenadas geogr´ aficas. 4.3. Design e Modulac¸˜ ao 24 •Notificac¸ ˜ oes de entrada e sa´ ıda das geofences ativas. Para a implementac¸˜ ao da aplicac¸˜ ao utilizou-se, como referido anteriormente, a API da Google. 4.3design e modulac¸˜ ao De forma a melhorar a compreens˜ ao de um qualquer sistema ´ e costume utilizar-se linguagens de modulac¸ ˜ ao como o UML para criar modelos e ou diagramas que, de forma visual, descrevem o funcionamento de todo o sistema assim como das v´ arias componentes que o integram. Como tal, nesta secc¸˜ ao iremos recorrer a diagramas de sequˆ encia para ilustrar todo o processo das funcionalidades mais importantes do sistema. No que diz respeito ` a parte do design de todo o sistema, nesta secc¸˜ ao ser˜ ao ainda apresentadas as mock ups desenhadas para representarem a interface do sistema para que sirvam de base para a criac¸ ˜ ao da interface final funcional tanto da plataforma web como da mobile app. 4.3.1Diagramas de Sequˆ encia Para ilustrar de uma forma visual toda a sequˆ encia de eventos que compˆ oem o processo de execuc¸ ˜ ao das funcionalidades mais importantes do sistema, recorreu-se ` a linguagem UML para criar diagramas de sequˆ encia. Adicionar Geofences O administrador de sistema ap´ os preencher o formul´ ario de adic¸ ˜ ao de novas geofences ao sistema, d´ a in´ ıcio ao processo ilustrado na figura 11. Este formul´ ario ter´ a de ser validado pela plataforma web, pelo que se cria ent˜ ao uma alternativa, representada pelo alt. Caso o formul´ ario seja v´ alido, a plataforma web envia ent˜ ao os dados recebidos para a base de dados presente no Google Firebase. Caso n˜ ao seja, o sistema emite ent˜ ao um aviso de erro para que o administrador possa tentar novamente. Na sequˆ encia do formul´ ario ser v´ alido e os dados serem enviados para a base de dados, aquando da inserc¸˜ ao ´ e enviado um sinal do tipo child added tanto para a plataforma web como para a mobile app, contendo a informac¸˜ ao que foi adicionada que neste caso ser´ a uma geofence. Similarmente o processo iniciado em ambos ser´ a ent˜ ao de adicionar a geofence recebida, dando-se ent˜ ao por terminada toda esta sequˆ encia. 4.3. Design e Modulac¸˜ ao 25 Figura 11: Diagrama de sequˆ encia de adicionar geofences Remover Geofences O ator ser´ a novamente o administrador de sistema que, ap´ os selecionar a linha da tabela a que corresponde a geofence a remover e submeter o formul´ ario, inicia o processo ilustrado na figura 12.´ E ent˜ ao chamado o m´ etodo respons´ avel pela remoc¸˜ ao da geofence da base de dados, sendo tamb´ em emitido um sinal child removed tanto para a plataforma web como para a mobile app para que possam remover localmente do sistema esta geofence. Figura 12: Diagrama de sequˆ encia de remover geofences 4.3. Design e Modulac¸˜ ao 26 Adicionar Sugest˜ ao Neste diagrama o nosso ator ser´ a o Utilizador, pois este ´ e o ´ unico com a possibilidade de fazer uma sugest˜ ao, figura (13). O processo inicia-se com o utilizador a submeter o envio da sua sugest˜ ao, sendo que esta ´ e ent˜ ao enviada para a base de dados das sugest˜ oes presente no Google Firebase.` A semelhanc¸a dos outros casos o Firebase envia um sinal de child added para a plataforma web de forma a que esta a adicione ent˜ ao ` a tabela de sugest˜ oes. Figura 13: Diagrama de sequˆ encia de adicionar sugest˜ oes Remover Sugest˜ ao Por fim a ´ ultima funcionalidade descrita ´ e a de remover sugest˜ oes da tabela presente na plataforma web, ilustrada na figura 14. Para este cen´ ario, o ator volta a ser o Administrador, pois apenas ele pode fazer a remoc¸˜ ao de sugest˜ oes desta tabela. O processo inicia-se quando este seleciona a linha da tabela correspondente ` a sugest˜ ao que ele deseja remover da tabela e envia o formul´ ario. ´ E ent˜ ao de seguida chamado o m´ etodo respons´ avel por fazer a remoc¸˜ ao da sugest˜ ao selecionada da base de dados no Google Firebase. Neste ponto ´ e enviado um sinal de child removed ` a plataforma web para que esta posteriormente possa ent˜ ao removˆ e-la da tabela de sugest˜ oes. 4.3. Design e Modulac¸˜ ao 27 Figura 14: Diagrama de sequˆ encia de remover sugest˜ oes 4.3.2Mock ups Recorrendo ` a ferramenta Marvel App, uma ferramenta especialmente criada para o design de interfaces, fez-se esboc¸os para os trˆ es ecr˜ as. O primeiro ecr˜ a, representado pela figura 15, ser´ a o ecr˜ a no qual o administrador ir´ a efetuar o login com as suas credenciais na plataforma web. Figura 15: Esboc¸o do login na plataforma web 4.4. Implementac¸˜ ao 34 3.Adicionar as geofences presentes na base de dados ` a lista que ser´ a monitorizada pela app e fazer o seu desenho no mapa; 4.Emitir avisos de transic¸ ˜ oes de entrada e sa´ ıda destas geofences. Para aceder ` a base de dados presente no Google Firebase, ao iniciar a aplicac¸˜ ao cri´ amos uma s´ erie de Listeners para detetar eventos de adic¸ ˜ ao e remoc¸˜ ao de geofences. As geofences ativas s˜ ao ent˜ ao tratadas pela classe Geofence, que definimos para encapsular os dados recebidos dado que a pr´ opria classe que a API disp˜ oe n˜ ao ´ e informativa o suficiente para os requisitos definidos. Figura 21: M´ etodo para adicionar geofences ` a lista que ´ e posteriormente monitorizada Como podemos ver na figura 21 ´ e necess´ ario fazer a convers˜ ao dos dados recebidos da base de dados para os tipos corretos de forma a que possamos ent˜ ao construir a Geofence que iremos adicionar ` a lista. Depois disto define-se RequestId que ser´ a a chave que identifica ageofence. De seguida, necessitamos de definir a zona circular que neste caso necessita do ponto central da geofence assim como do seu raio. O parˆ ametro talvez de maior importˆ ancia ser´ a a definic¸˜ ao dos tipos de transic¸ ˜ oes a controlar, que para este caso em concreto, ser˜ ao a entrada e sa´ ıda das geofences,GEOFENCE TRANSITION ENTER eGEOFENCE TRANSITION EXIT respetivamente. Precisamos tamb´ em de definir os Intents para que o Location Services quando detete que um utilizador entrou ou saiu de uma geofence envie este sinal. Para detetar este sinal definimos um Geofence Broadcast Receiver que a partir da detec¸ ˜ ao deste Intent consegue obter o evento de geofencing, determinando o tipo da transic¸ ˜ ao assim como a geofence que 4.4. Implementac¸˜ ao 35 foi transitada. ´ E ainda respons´ avel por emitir a notificac¸˜ ao ao utilizador detalhando qual a geofence transitada, o seu tipo e tamb´ em o tipo de transic¸ ˜ ao que ocorreu, fazendo ainda log dos detalhes desta transic¸ ˜ ao. Figura 22: M´ etodo que determina o Intent de cada geofence No m´ etodo da figura 22 determinamos o Pending Request para ser enviado com o pedido para adicionar ou remover geofences. Desta forma, sempre que o Location Services detetar uma transic¸ ˜ ao de alguma das geofences presentes na lista, este ir´ a emitir o Intent aqui definido. O m´ etodo da figura 23 ´ e respons´ avel por determinar os detalhes da transic¸˜ ao de cada geofence, isto ´ e, determina o tipo da transic¸ ˜ ao e o id da geofence transitada e devolve uma string com estes dados para ser utilizada no envio da notificac¸ ˜ ao ao utilizador. Figura 23: M´ etodo respons´ avel por determinar o tipo da transic¸˜ ao e a geofence transitada No m´ etodo da figura 24 constru´ ımos e retornamos um Geofencing Request. Definimos tamb´ em que caso o dispositivo j´ a se encontre dentro de uma geofence no momento da sua criac¸ ˜ ao, deve ser enviada uma notificac¸ ˜ ao na mesma (INITIAL TRIGGER ENTER). ´ E aqui tamb´ em que definimos a lista de geofences que ir´ a ser monitorizada para a detec¸ ˜ ao de transic¸ ˜ oes. O utilizador pode ainda, caso navegue no mapa, recentrar o mesmo na sua posic¸ ˜ ao atual carregando no bot˜ ao da Minha Localizac¸ ˜ ao. Pode ainda pesquisar pela 4.5. Interface 36 Figura 24: M´ etodo respons´ avel por construir e retornar o Geofencing Request e definic¸˜ ao do que ser´ a monitorizado geofence mais pr´ oxima, que ser´ a calculada com base na posic¸˜ ao atual do utilizador e o ponto central de cada geofence ativa. Disp˜ oe ainda da possibilidade de dar a sua contribuic¸ ˜ ao para acrescentar valor ao sistema, podendo enviar sugest˜ oes de locais que este identifique que necessitem de ser monitorizados pela criac¸˜ ao de uma nova geofence, sendo que esta informac¸˜ ao enviada ser´ a apenas a sua posic¸ ˜ ao atual. 4.5interface 4.5.1Plataforma Web Com base nos mock ups apresentados anteriormente, procedeu-se ent˜ ao ao desenho final da interface onde seriam inclu´ ıdos todos os componentes e funcionalidades especificados anteriormente nos demais cap´ ıtulos desta dissertac¸ ˜ ao. O primeiro ecr˜ a apresentado na figura 25 diz respeito ao ecr˜ a inicial onde o administrador ir´ a efetuar o login com as suas credenciais. 4.5. Interface 37 Figura 25: Ecr˜ a de login da plataforma web Ap´ os efetuar o login ele ser´ a redirecionado para a p´ agina principal onde poder´ a efetuar todas as operac¸ ˜ oes de gest˜ ao ao sistema em si (Figura 26). Figura 26: Ecr˜ a completo da plataforma web 4.5. Interface 38 Primeiramente temos o formul´ ario para adicionar novas geofences ao sistema. Como requerido pelo sistema, o administrador tem de preencher os campos todos obrigatoriamente. Caso n˜ ao o fac¸a o sistema ir´ a emitir um aviso como ilustrado pela figura 27. N˜ ao pode tamb´ em utilizar um nome que j´ a exista na lista de geofences, pois o sistema ir´ a emitir um aviso de erro. Figura 27: Aviso de erro no preenchimento do formul´ ario por falta de certos campos Caso o preenchimento esteja de acordo com os parˆ ametros requeridos ent˜ ao, ap´ os a submiss˜ ao do formul´ ario, a geofence ser´ a adicionada ` a tabela e desenhada no mapa. Tem ainda a possibilidade de, posteriormente, selecionando a checkbox de uma geofence, a remover do sistema para deixar de ser monitorizada. Por fim, temos ainda a tabela de sugest˜ oes enviadas pelos utilizadores da mobile app, na qual o administrador pode recolher uma grande variedade de dados importantes que podem de certa forma ajudar a todo o trabalho de selec¸ ˜ ao dos locais apropriados a serem controlados pela aplicac¸˜ ao. ` A medida que for validando as sugest˜ oes recebidas, o administrador pode remover essas sugest˜ oes selecionando acheckbox correspondente ` a sugest˜ ao que pretende remover e de seguida carregando no bot˜ ao de Remover Sugest˜ ao. Esta tabela ´ e muito ´ util pois permite uma interac¸˜ ao entre os utilizadores da aplicac¸˜ ao e o administrador de sistema, que pode em caso de ser informac¸˜ ao v´ alida, facilitar muito o trabalho do administrador. 4.5.2Mobile Application Uma das maiores preocupac¸ ˜ oes com o planeamento da mobile app foi garantir que a interface seria intuitiva e simples de utilizar. Como tal, ficou delineado que a aplicac¸˜ ao s´ o teria um ecr˜ a no qual o utilizador conseguiria ver imediatamente o mapa e as geofences ativas. Com base na mock up criada para servir de base para o desenho da interface final, criouse ent˜ ao o ecr˜ a como representado na figura 28. Como requerido anteriormente, temos trˆ es bot˜ oes, no canto superior direito o bot˜ ao para centar o mapa na localizac¸ ˜ ao atual do utilizador, um bot˜ ao para pesquisar e centrar na geofence mais pr´ oxima e por fim um bot˜ ao para poder sugerir novas geofences. 4.5. Interface 39 Figura 28: Ecr˜ a principal da mobile app Neste caso o utilizador ao carregar no bot˜ ao do Nearest Fence ser´ a transportado para o local que representa o centro da geofence mais pr´ oxima. (Figura 29) Figura 29: Ecr˜ a principal da mobile app centrado na geofence mais pr´ oxima 4.5. Interface 40 Ao clicar no bot˜ ao de Suggestion ser´ a enviada a sua localizac¸˜ ao geogr´ afica para a lista de sugest˜ oes presente na plataforma web. Adicionalmente acrescentou-se como se pode ver na figura, a Traffic API da Google para poder assitir os utilizadores a calcular melhor as suas rotas, no caso de estarem dentro de um ve´ ıculo, por exemplo. 5 C A S O S D E E S T U D O E R E S U LTA D O S Nesta secc¸ ˜ ao ir´ a ser feito e descrito um caso de estudo ilustrativo que testa a capacidade de resposta do sistema aos problemas a que se prop˜ oem, sendo feita uma an´ alise aos resultados obtidos. Com isto em mente considerou-se necess´ ario ter trˆ es tipos de atores neste caso de estudo. Primeiramente um administrador, respons´ avel por fazer a gest˜ ao da adic¸ ˜ ao, remoc¸˜ ao e categorizac¸ ˜ ao das geofences, um VRU que ir´ a navegar pela cidade passando nas geofences previamente adicionadas e fazendo sugest˜ oes de novas geofences a ser adicionadas. Consideramos ainda importante ter tamb´ em um outro ator, que neste caso ser´ a um condutor, que far´ a uma travessia pela cidade acompanhado de um passageiro respons´ avel por lhe transmitir a informac¸ ˜ ao recebida na aplicac¸˜ ao. 5.1caso de estudo O caso de estudo iniciou-se com uma an´ alise e selecec¸ ˜ ao de locais considerados ideais a serem controlados por serem zonas perigosas para os VRUs. Tendo completado este passo, o administrador tratou de fazer a adic¸˜ ao de geofences a esses pontos de interesse. O primeiro local identificado foi em Ferreiros, num cruzamento com pouca visibilidade onde ocorrem muitas vezes acidentes e onde n˜ ao existem passadeiras para os VRUs atravessarem a estrada em seguranc¸a. Como tal, o administrador de sistema adicionou nesse ponto de interesse uma geofence (Figura 30). 41 5.1. Caso de Estudo 42 Figura 30: Plataforma Web depois de adicionar a geofence De forma a testar a interac¸˜ ao do sistema, um VRU iniciou uma caminhada em direc¸˜ ao ` a geofence criada. Aquando da sua entrada na geofence, o envio da notificac¸˜ ao demorou cerca de trˆ es segundos ap´ os no mapa o ponto representativo da sua localizac¸ ˜ ao ter entrado na geofence. Para melhor compreens˜ ao, o aviso recebido est´ a ilustrado na figura 31. Como se pode ver, o aviso identifica o tipo da transic¸˜ ao (”Entered”), seguido do nome da geofence transitada, com uma mensagem a recomendar cuidado enquanto circular nessa regi˜ ao. De referir que, como se poder ver na figura, a geofence tem a cor vermelha, representativa do seu tipo que neste caso ´ e o de Zona Perigosa. 5.1. Caso de Estudo 43 Figura 31: Notificac¸˜ ao de entrada recebida pelo VRU Prosseguindo a sua caminhada em direc¸˜ ao ao local de sa´ ıda da geofence, recebeu nova notificac¸ ˜ ao, neste caso da sua sa´ ıda como se pode ver na figura 32. Novamente, denotou-se a existˆ encia de um atraso de cerca de trˆ es a quatro segundos no envio da notificac¸˜ ao. Dado que o VRU circula a p´ e este atraso ´ e aceit´ avel. Na eventualidade do local ser prop´ ıcio ` a passagem de ve´ ıculos a circular a alta velocidade, o raio da geofence ter´ a de ser ajustado para que tenha uma margem de seguranc¸a de forma a garantir que a notificac¸ ˜ ao ´ e enviada a tempo. 5.2. Resultados 50 poss´ ıvel que este entre e saia delas sem que o Location Services fac¸a uma query pela sua posic¸ ˜ ao no intervalo de tempo em que esteve dentro das mesmas. Como tal, pode-se dar uma falha na emiss˜ ao dos avisos de entrada e ou sa´ ıda de uma geofence que por norma nunca ir´ a acontecer caso a geofence tenha um raio grande. A funcionalidade de pesquisar pela geofence mais pr´ oxima necessitou que se fizesse uma query para receber a posic¸˜ ao atual do utilizador, pois caso n˜ ao seja feita, a LastKnownLocation ser´ a a localizac¸˜ ao onde o utilizador iniciou a aplicac¸ ˜ ao. Tendo sido feita esta alterac¸˜ ao, o bot˜ ao passa a fazer uma transic¸ ˜ ao no mapa primeiro para a localizac¸˜ ao do utilizador e de seguida para a geofence mais pr´ oxima da sua posic¸ ˜ ao. A funcionalidade do envio de sugest˜ ao ´ e bastante trivial. N˜ ao foi detetada qualquer falha, sendo o seu envio para a plataforma web quase instantˆ aneo. Com o que foi referenciado anteriormente, conclui-se que o sistema tem potencial pois ´ e bastante escal´ avel, est´ a no entanto dependente de atualizac¸ ˜ oes ` a sua API para poder tirar partido de mais funcionalidades que acrescentam valor. Conclui-se tamb´ em que ´ e ainda muito dependente da qualidade dos dispositivos onde ´ e utilizado, pois tendo estes fraca precis˜ ao no sinal GPS o sistema n˜ ao executa como esperado. Com as condic¸ ˜ oes corretas para o funcionamento do sistema, verificamos que apresenta resultados de forma c´ elere, com informac¸˜ ao detalhada nos avisos emitidos, com uma plataforma de gest˜ ao e aplicac¸˜ ao bastante intuitivas e simples, muito escal´ aveis e fidedignas, capazes de responder ` as necessidades dos seus utilizadores. 6 C O N C L U S ˜ O E S E T R A B A L H O F U T U R O 6.1s´ intese do trabalho realizado No in´ ıcio desta dissertac¸ ˜ ao definiu-se a criac¸ ˜ ao de um sistema com o intuito de aumentar a seguranc¸a dos VRUs recorrendo ao conceito de geofences.Geofencing consiste em criar um per´ ımetro virtual num local real onde ´ e feita a monitorizac¸ ˜ ao da presenc¸a, entrada e sa´ ıda de um ou mais utilizadores. Isto prova-se bastante ´ util no contexto desta dissertac¸ ˜ ao, pois conseguimos mediante a presenc¸a de um utilizador nestes locais, enviar avisos inteligentes para ajudar na prevenc¸˜ ao de acidentes rodovi´ arios. Para a criac¸ ˜ ao do sistema, definiu-se que teria de existir uma mobile application onde um utilizador pudesse ser notificado da presenc¸a, entrada ou sa´ ıda de uma geofence para que pudesse ajustar o seu comportamento, diminuindo o risco de sofrer qualquer tipo de incidente. Definiu-se tamb´ em que teria de haver alguma entidade respons´ avel por toda a gest˜ ao do sistema. Como tal, passou a ser necess´ ario tamb´ em criar uma plataforma web onde este administrador fosse capaz de adicionar, remover e categorizar geofences. De forma a estabelecer a ligac¸ ˜ ao entre estas duas componentes era necess´ ario criar uma ponte, que neste caso seria a base de dados onde seriam armazenadas as informac¸ ˜ oes das geofences adicionadas. Desta forma, recorreu-se ao Google Firebase, uma tecnologia que permite a criac¸ ˜ ao de uma base de dados persistente, de f´ acil utilizac¸ ˜ ao, que comunica em tempo real com tanto a plataforma web como a mobile app para que mantenham os seus dados atualizados. Paralelamente idealizou-se que, de forma a complementar o sistema, os utilizadores da mobile app deveriam ser capazes de enviar sugest˜ oes para o administrador de sistema, de potenciais pontos de interesse que deveriam passar a ser monitorizados. Obviamente que esta funcionalidade acarreta um certo risco, pois requer ao administrador de sistema uma capacidade de triagem dos dados recebidos muito alta, para que consiga filtrar de facto as sugest˜ oes realmente importantes e relevantes, daquelas que possam ser falaciosas. Com todos estes requisitos em mente, construiu-se a plataforma web, assim como a mobile app, compondo desta forma um sistema robusto e muito escal´ avel para ser integrado 51 6.2. Trabalho Futuro 52 na rede de tecnologias e dispositivos que comp˜ oem o mundo das Smart Cities. Face aos resultados analisados, verificamos que existe uma contribuic¸˜ ao positiva para aumentar a seguranc¸a dos VRUs pois conseguimos emitir avisos em tempo real para os utilizadores da mobile app que circulem dentro dos pontes de interesse onde foram colocadas geofences, contribuindo tamb´ em por consequˆ encia, para a diminuic¸˜ ao do risco dos demais utilizadores da via p´ ublica. Outra caracter´ ıstica importante de referir diz respeito ao facto deste sistema permitir ser aplicado a outros dom´ ınios n˜ ao relacionados com a seguranc¸a dos VRUs. Sendo escal´ avel podemos definir qualquer tipo de intuito ` as notificac¸ ˜ oes enviadas nas transic¸ ˜ oes de entrada e sa´ ıda das geofences, pelo que dar informac¸ ˜ oes relativas a locais em concreto, como monumentos, edif´ ıcios hist´ oricos, entre outros ´ e pass´ ıvel de ser realizado neste sistema. Pode-se ainda pensar tamb´ em numa vertente comercial, onde os avisos enviados podem estar relacionados com o marketing de uma certa empresa, ou como referido no cap´ ıtulo da revis˜ ao do estado da arte, oferta de promoc¸ ˜ oes para lojas ou estabelecimentos nas redondezas. Em suma, o sistema desenvolvido para esta dissertac¸˜ ao para al´ em do foco na seguranc¸a dos VRUs, caracteriza-se ainda pela sua escalabilidade, sendo poss´ ıvel aplic´ a-lo a uma grande variedade de contextos que n˜ ao o ˆ ambito inicial desta dissertac¸ ˜ ao. 6.2trabalho futuro Existem ainda otimizac¸ ˜ oes poss´ ıveis e necess´ arias para que o sistema se torne mais completo e robusto. Primeiramente, comec¸ar por criar uma aplicac¸˜ ao dispon´ ıvel para o Android Auto de forma a que condutores que circulem na rodovia sejam mais facilmente notificados das suas entradas, sa´ ıdas e presenc¸as nas geofences ativas para que a responsabilidade de adequar o seu comportamento passe tamb´ em para o seu lado e n˜ ao somente dos VRUs, tendo obviamente ciente que na evetualidade de ter um passageiro com a aplicac¸˜ ao ligada j´ a se consegue suprir esta lacuna. Um aspeto que pode ser escalado diz respeito aos tipos das geofences. Neste momento definiu-se que seriam apenas trˆ es, mas mediante as necessidades do sistema e toda a sua evoluc¸˜ ao, futuramente far´ a sentido adicionar mais alguns para acrescentar ainda mais valor ao sistema. Outro aspeto, para comodidade e realidade do sistema, diz respeito ` a forma da figura da geofence. De momento todas as geofences adicionadas s˜ ao c´ ırculos, pois ´ e assim que a API est´ a definida, fazendo todo o sentido que seja poss´ ıvel definir outras geometrias para controlar geofences, pois torna a localizac¸˜ ao das mesmas mais realista. Outra funcionalidade que poderia ser melhorada diz respeito ` as sugest˜ oes dos utilizadores. Neste momento, o utilizador envia meramente as suas coordenadas geogr´ aficas como informac¸ ˜ ao para o administrador o que obriga, como referido anteriormente nesta 6.2. Trabalho Futuro 53 dissertac¸ ˜ ao, a que exista uma filtragem e verificac¸˜ ao destes dados. Como trabalho futuro as sugest˜ oes dos utilizadores deveriam passar a incluir o poss´ ıvel tipo da geofence assim como uma pequena descric¸ ˜ ao que pudesse explicar o porquˆ e de achar que se deveria ter naquele local uma geofence, assim como outras informac¸ ˜ oes que o utilizador considerasse relevantes. Assim este canal de feedback passaria a ser muito mais completo e traria grandes vantagens a todo o sistema. B I B L I O G R A F I A Jos´ e J. Anaya, Edgar Talavera, David Gim´ enez, Nuria G´ omez, Felipe Jim´ enez, and Jos´ e E. Naranjo. Vulnerable Road Users Detection using V2X Communications.2015 IEE 18th International Conference on Intelligent Transportation Systems, 2015. Franc¸ois Artusse. The Importance of Smart Cities. Available from https://medium.com/zify/the-importance-of-smart-cities-2a4f7f89a6cd, n.d. ASNR. Relatorios De Sinistralidade. Available from http://www.ansr.pt/Estatisticas/RelatoriosDeSinistralidade/Pages/default.aspx, 2018a. ASNR. Relatorios De Sinistralidade. Available from http://www.ansr.pt/Estatisticas/RelatoriosDeSinistralidade/Documents/2018/RELAT2018b. Bryan Bonack. Geofences: What They Are, What They Aren’t, and Why They’re Effective. Available from https://www.geospatialworld.net/blogs/geofences-what-they-are-what-theyarent-and-why-theyre-effective/, n.d. A. Boulton and L. Brunn, S.D.and Devriendt. Cyberinfrastructures and “smart” world cities: Physical, human, and soft infrastructures. In Taylor, P., Derudder, B., Hoyler, M., Witlox, F. (Eds.), International Handbook of Globalization and World Cities. Cheltenham, UK: Edward Elgar, 2011. Woong Cho. Safety enhancement service for vulnerable users using P2V communications. International Conference on Connected Vehicles and Expo (ICCVE), 2014. Aymery Constant and Emmanuel Lagarde. Protecting vulnerable road users from injury. PLOS Medicine,7(3):1–4,03 2010. doi: 10.1371/journal.pmed.1000228. URL https://doi. org/10.1371/journal.pmed.1000228. Eyal; Anthony LaMarca; Mahadev Satyanarayanan De Lara. Location Systems: An Introduction to the Technology Behind Location Awareness. Morgan Claypool Publishers. p. 88. ISBN 978-1-59829-581-8., 2008. R. Duenkler. Security for vulnerable road users through Ko-TAG. Available from: https://www.iis.fraunhofer.de/en/ff/lv/lok/proj/kotag.html., 2013. Bruno Fernandes, Fabio Silva, Cesar Analide, and Jose Maia Neves. Crowd Sensing for Urban Security in Smart Cities. Journal of Universal Computer Science - June 2018,2018. POCI01-0145-FEDER-007043. 54 Bibliografia 55 Tonya Garcia. Available from https://www.marketwatch.com/story/burger-king-trollsmcdonalds-with-penny-whoppers-to-promote-new-app-2018-12-04,2018. Fertner C. Kramar H. Kalasek R. Pichler-Milanovi´ c N. Meijers E. Giffinger, R. Smart Cities: Ranking of European Medium-Sized Cities. Available from http://www.smartcities.eu/download/smartcitiesfinalreport.pd f , 2007. Google. Available from https://developer.android.com/training/location/geofencing, n.d.a. Google. Available from https://developers.google.com/location-context/geofencing/?hl=zhTW, n.d.b. R. E. Hall. The vision of a smart city. In Proceedings of the 2nd International Life Extension Technology Workshop. Available from http://www.osti.gov/bridge/servlets/purl/773961oyxp82/webviewable/773961.pdf., 2000. Shuxian He, Jiangchen Li, and Tony Z. Qiu. Vehicle-to-Pedestrian Communication Modeling Collision Avoiding Method in Connected Vehicle Environment. Journal of the Transportation Research Board, 2008. R.G. Hollands. Will the real smart city please stand up? City, 12(3), 303-320.2008. Dmitry Namiot and Manfred Sneps-Sneppe. Geofence and Network Proximity. Part of the Lecture Notes in Computer Science book series (LNCS, volume 8121), 2013. World Health Organization. Global Status Report on Road Safety 2015. Available from https://books.google.pt/books?hl=ptPTlr=id=wV40DgAAQBAJoi=fndpg=PP1dq=road+safetyots=DJXwwXdYwgsig=HncrieHGuQXUgC16QTQI yv =onepageq =road2015. K. Ota, T. Kumrai, M. Dong, J. Kishigami, and M. Guo. Smart infrastructure design for smart cities. IT Professional, pages 1–1,2017. doi: 10.1109/MITP.2017.265110715. Kim Suart. Available from https://mobilewalletmarketer.com/using-ibeacons-geofencingreal-estate-open-house-marketing/, n.d. Tesla. Available from https://www.tesla.com/ptPT/blog/q3−2018 −vehicle −sa f ety − report?redirect =no, 2018. TomTom. Available from https://developer.tomtom.com/maps-sdk-android/geofencingexamples, n.d. Sindhu U. Balaouras S. Dines R. A.-Hayes N. M. Nelson L. E. Washburn, D. Helping CIOs Understand ”Smart City”Initiatives: Defining the Smart City, Its Drivers, and the Role of the CIO. Cambridge, MA: Forrester Research, Inc., 2010. Bibliografia 56 SY Wong. Toyota Develops Automatic Brake System Assisted by GPS Technology for Safety Driving. Available from: https://www.mydigitallife.net/toyota-develops-automatic-brakesystem-assisted-by-gps-technology-for-safety-driving/, n.d.