This article describes a novel safety application based on the open source navigation software OsmAnd,
 which runs on the Android platform. The application offers vehicles with "smart navigation", and maintains a network
 of the vehicles that use our application. The process of network creation and maintenance is important as
 our application enables vehicles to communicate with one another to exchange useful information. The main
 function of the application is to inform vehicles of relevant vehicles approaching, termed as "administrative
 vehicles" in this article, and include ambulances, police cars and fire brigades. Based on the received 
 information, our application notifies the driver, who can now take navigation decisions based on it. While developing
 the application, problems were found when attempting to create an Ad-hoc network. A solution to the problem of managing the Ad-hoc network has been proposed and is under development

Calafate, Carlos T

Cano, Juan-Carlos

Manzoni, Pietro

Patra, Subhadeep

Tornell, Sergio M

English

Ghent University Academic Bibliography

Messiah: An ITS drive safety applicationSubhadeep Patra, Sergio Martinez, Carlos T. Calafate,Juan-Carlos Cano and Pietro Manzoni 1Abstract—This article describes a novel safety application basedon the open source navigation software OsmAnd, whichruns on the Android platform. The application o ersvehicles with “smart navigation”, and maintains a net-work of the vehicles that use our application. The pro-cess of network creation and maintenance is importantas our application enables vehicles to communicate withone another to exchange useful information. The mainfunction of the application is to inform vehicles of rel-evant vehicles approaching, termed as “administrativevehicles” in this article, and include ambulances, policecars and fire brigades. Based on the received informa-tion, our application notifies the driver, who can nowtake navigation decisions based on it. While developingthe application, problems were found when attemptingto create an Ad-hoc network. A solution to the prob-lem of managing the Ad-hoc network has been proposedand is under development.Keywords—ITS, VANET, Mobile Application, Android, Naviga-tion, Software, Ad-Hoc Network.I. IntroductionINTELLIGENT Transportation Systems(ITS) areadvanced applications that makes use of vehicu-lar and infrastructured networks to provide innovativeservices related to both tra c and, mobility manage-ment, and that interface with other models of trans-port [1]. Some of the examples of this type of applica-tions include automatic emergency calling to a helplinenumber when an accident occurs, monitoring tra c dodetect tra c rule violations [2] and defining variablespeed limits for a particular road depending on thecongestion [3].Many software applications and testbeds have beendeveloped keeping ITS and VANETs in mind. In[4], the authors developed an Android/OSGi platformwhich integrates the Open Gateway Service Initia-tive Vehicle Expert Group (OSGi/VEG) into an An-droid platform to generate a vehicular Android/OSGiplatform. The features provided by the platform in-cludes remote management, rich class-sharing, pro-prietary vehicular applications, security policies, easymanagement of the Application Programming Inter-face (APIs), and an open environment. Whipple et al.[5] developed an Android Public Safety Applicationwhich uses the GPS feature to find out the locationof the vehicle, and it uses the Google Maps API todetermine the location of nearby schools. It alerts thedriver when surpassing the speed limit within a schoolzone. CarSafe [6], is an application developed for An-droid phones; it uses the dual camera of smartphonesand other embedded sensors to detect drowsy and dis-tracted drivers. In particular, it uses computer vision1Grupo GRC, DISCA, Universitat Polite`cnica de Vale`ncia, e-mail: subpat@doctor.upv.es, sermarto@upv.es, {calafate,jucano, pmanzoni}@disca.upv.esand machine learning algorithms to detect the condi-tion of the driver using the front camera while trackingroad conditions using the back camera. Cabernet [7]is a system that takes advantage of open 802.11 accesspoints encountered opportunistically during travel fordelivering data to and from vehicles. Another exampleis CVet [8], a VANET testbed presented by researchersfrom UCLA. The CVet testbed was deployed over ve-hicles belonging to the UCLA car fleet.The aforementioned works highlight the many appli-cations that are being developed for ITS and VANETs.Navigation applications are one such group of verypopular, interesting and useful applications. Our goalis to build an application for Android [9] devices that,along with displaying maps and location information,could warn the user of important vehicles approach-ing (for example, an ambulance), so that the drivermay take decisions based on this information. For thispurpose, the OSM Automated Navigation Directions(OsmAnd) [10] application, a popular open source nav-igation solution was used and modified for our work.OsmAnd is a map and navigation application withsupport for both online and o ine use. It relies onOpenStreetMap(OSM) [11] [12] for map rendering anddisplaying. It is an application rich in features, and itmay be used by cars, bicycles or pedestrians. Ourapplication works as a plugin for the OsmAnd appli-cation that enables vehicles to communicate, create anetwork, exchange important information among thenodes, and alert the drivers about important nearbyvehicles.The rest of the paper is organized as follows: Sec-tion II provides a general overview of the di erent fea-tures of the developed application. The implementa-tion details of the developed application are providedin section III. Section IV describes the testing of thethe application prototype, the problems found duringapplication development, and its possible solution. Fi-nally, Section V concludes the paper.II. Features of the Messiah ApplicationThe application developed has been named Messiah.The Messiah application, upon installation, allows theuser to be a part of a “drive safety” network. If theuser chooses to be a part of this network, the softwareallows the user to select whether it is an administrativevehicle like the police or an ambulance, or a vehicle inneed of help (SOS vehicle). Based on this input, thesoftware has three modes of operation:• Administrative Mode.• Civil Mode.• SOS Mode.Jornadas Paralelismo 2014 409Fig. 1. The Device working in “Civil Mode”When choosing to participate in the network with-out selecting the “SOS” or “Administrative” mode,the vehicle is assumed to be a civilian vehicle by de-fault, and so the software starts working in the “Civilmode”. In this mode, it only receives or forwards datato and from its neighboring nodes. Apart from this,it also displays on-screen any received information, asshown in Fig. 1.Fig. 2. The Device working in “Administrative Mode”Users can also choose their vehicle as an “Admin-istrative vehicle”. In the future, we intend to makethis option available to only authorized personnels byimplementing security checks. Upon selecting this op-tion, the “Administrative mode” is turned on. In thismode, the nodes forward packets sent from other nodesand, in addition, also broadcasts generated packetscontaining mainly of their current location, their fu-ture route and the destination. The application shownis Fig. 2 is working in the “Administrative mode”,which forwards its location information, future routeand destination. The node in Fig. 1 receives this in-formation, forwards it, and displays the received infor-mation on screen.The software has another mode, through which avehicle in distress can send an SOS beacon, which uponreceipt by nearby vehicles results on the display of adi erent icon on screen, thus alerting other vehiclesthat someone in need of help is close-by.Also, some intelligent features have been includedin the software, for instance, when a source of infor-mation is more than 1 kilometer away from the re-ceiving node, the packet is dropped as the informationreceived may be stale. That is, by the time the infor-mation reaches the destination, the sender may havemoved to some other remote location. Again, if thefuture route is too long, the whole of the route infor-mation is not sent, but only a part of it. In Fig. 1, wecan see that this particular node receives only a part ofthe route of the vehicle shown in Fig. 2, and it displaysa broken line with an arrowhead to indicate the futureroute. The arrowhead indicates the possible directionin which the route will be updated in the future.Since the network is ad-hoc in nature, nodes mayjoin and leave the network at any time, and networkdisconnections may arise. All these are automaticallydetected by the Messiah application. Furthermore, theapplication continues to work in the background evenif the user is currently using some other application,or has minimized the Messiah Application, this allowsthe user to be a part of the network without requiringof our application to be on the foreground.410 Jornadas Paralelismo 2014Fig. 3. Architecture of the Messiah ApplicationIII. Implementation Details of the MessiahApplicationFig. 3 shows the di erent working blocks of the Mes-siah Application. “Messiah service” controls the func-tioning of our application and receives user input fromthe OsmAnd Application, for example, the mode of op-eration. The “Communicator Thread” is responsiblefor both sending and receiving of data. The “IdGener-ator Class” is used to generate a unique id for a node.The “MessageGenerator Class” is used to generate themessages to be send. The “Locater Class” helps totrack the current location of the device and suppliesit when asked for. The “DatabaseManager Class” isused to store received message, acting as a cache formessages. It is also used to retrieve information laterwhen needed.Fig. 4. The informations contained in the message used byMessiah ApplicationNow, let us look closely at the structure of messagesreceived or sent within the Messiah network. The mes-sage contains a node-id, time-stamp, the type of mes-sage, the current location of the sender, its intendedfuture route and the destination, as shown in Fig. 4.What is important to note here is the field “type” ina message. The icons and information displayed onscreen is dependent on the “type” field of a receivedmessage. A message can be of three types: i) Admin-istrative ii) SOS iii) Bye-Bye.An “Administrative” and “SOS” message are basi-cally identical, sent by an “Administrative vehicle” ora “SOS vehicle” respectively. Any important vehiclelike ambulances, police cars or fire brigades are consid-ered “Administrative vehicles”, while “SOS vehicles”includes vehicles that have faced critical accidents andneed assistance. A node sends these type of messagesto notify other nodes in the network its updated cur-rent location. The only reason for separating the Ad-ministrative and SOS into two distinct types is so thatthey can be identified and di erent icons can be dis-played for them. The “Bye-Bye” type message, on theother hand, is used by nodes that had been workingas “Administrative/SOS” vehicle to notify other nodeswithin the network that it is either going to switch to“Civil mode” of operation or may leave the networkaltogether.Let us look more closely at how the Messiah Appli-cation works. Fig. 5 demonstrates the operation of anormal vehicle working in the “Civil mode”. In thismode, the node is to only receive information, dis-play it and then forward it to its neighbors. Hence,the Communicator thread checks for incoming mes-sages. If a message is received, it is first checked if ita valid message for the Messiah Network. On findingthe received message to be valid, the distance of thesource from the current node is checked. If the senderis more than 1 km away from this node, the databaseis checked for any entry from this particular senderand the entry if any is eliminated. After this, packetis dropped assuming that the information containedmay be stale. On the other hand, if it is less than 1Km and the message is found to be new, its type ischecked. On receipt of a “Bye-bye” type message, themessage is broadcasted and any entry related to thesource node in the database is deleted. Otherwise, ifthe message is of other types, the information is storedin the database after adding a local timestamp. Andthen, the original message is broadcasted. The reasonfor adding a local timestamp before entering the in-formation to the database is because a node may loseconnectivity or network-partitioning may occur at anytime. Just relying on bye-bye messages is not su -cient, it is necessary to detect if a node, especially ifit working as an “Administrative/SOS” vehicle, leavesthe network. And to address to these kind of situ-ations, the database is checked for stale entries thathave been there for more than 10 seconds without anyupdates from the sender. Such entries on being en-countered, are eliminated.A node functioning as an “Administrative/SOS” ve-hicle, receives and broadcasts the received packets inthe same manner as a civil vehicle. They also generateand broadcast a message containing their id, a localtimestamp, the type of message depicting the modethey are working in, their current location, intendedfuture route and destination if any.Jornadas Paralelismo 2014 411Fig. 5. Flow Chart for a vehicle working in “Civil mode”IV. Prototype EvaluationThe first version of the application [13] has beentested within the campus of Universitat Polite`cnica deValencia, with real cars forming a Ad-hoc network,using the Wifi of the mobile devices.(a) A photograph from within the car(b) A photograph of the device usedFig. 6. The testing of the application within UPV CampusFor the evaluation, the devices used for testing ourapplication had to be rooted to make them work inan environment where any sort of infrastructured net-work is absent, because Android does not yet supportfull Ad-hoc mode. Normally, the Android operatingsystem does not provide the users with administrativerights thus the user lacks some access privileges. Thus,to gain total control of the wifi so that it may be usedto form a ad-hoc network, it was necessary to root thedevice.The Fig. 6 shows a successful testing of theapplication was performed within the UPV cam-pus with real cars. A video demonstrating thesame application being tested and its di erentfunctionalities is available at the following link:http://www.youtube.com/watch?v=Wh4cwmdvecM.We would like to discuss an idea which we believewill address the problem of configuring the devices androoting them. The idea is that we include cheap yete cient devices to work as routers and handle Ad-hoc communication. Each vehicle participating in thenetwork is supposed to contain one of these devices,and the mobile nodes present within this car would beconnected to the device and forward their data to it.The device would then forward the received data toother devices in other vehicles that are present withinits communication range. And in this way, the datawould be forwarded until it reached the destinationrouter or device, which would deliver the received datato the destination node in its local network.It was decided to use a cheap computer known asRaspberry Pi [14] [15] to work as the router placedwithin the cars to help the network function in Ad-hocmode. A Raspberry Pi is more or less of the same sizeas that of a credit card, working on Linux and supportsdi erent programming languages like Python, Java, Cand Pearl.Fig. 7. The Structure of the Ad-Hoc NetworkThe Fig. 7 explains the idea in details, each of thecars participating in the network contains a Raspberry412 Jornadas Paralelismo 2014Pi and the mobile nodes within the car is connected tothis Raspberry Pi. Thus the smartphones within thecar forms the local network of the Raspberry Pi whichworks as a router for them and forwards their data tothe outside world.V. ConclusionsOur application helps create a more safer tra c en-vironment as it displays important vehicle like the po-lice cars and ambulances on the navigation screen, thuswarning drivers to drive with attention and take deci-sions based on the displayed information. It has alsoa mode when a vehicle in distress can call for help.In this mode, a special icon is visible on screen of thevehicles that are close to the “SOS vehicle”, and hencethey can rush to its help. The ITS network may beboth infrastructureless or infrastructured. Problemswere encountered related to configuration of the de-vices to make them them work when there is no infras-tructured network available. Our application requiresthe devices to be rooted to support Ad-hoc network.Rooting of the device is not very encouraging from theuser perspective as it may void the manufacturer war-ranty of the devices. An alternative and hassle-freesolution to this problem has been proposed and is un-der implementation. On successful implementation, itwould save us the trouble of configuring the androiddevices. This added functionality would not only helpthe Messiah Application with Ad-hoc networks, butalso can be used as a testbed facilitating experimenta-tion with di erent scenarios, application and protocolsfor the VANET networks.AcknowledgmentsThis work was partially funded by (i) Svagata.eu,the Erasmus Mundus Programme, Action 2 (EMA2),of the European Commission. (ii) The Ministeriode Economı´a y Competitividad, Spain, under GrantsTIN2011-27543-C03-01 and BES-2012-052673.References[1] The 2010 directives of the European Parliament andof the council on the framework for the developmentof ITS, http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:207:0001:0013:EN:PDF, accessed May2014.[2] Luo Qi, “Research on Intelligent Transportation SystemTechnologies and Applications,”, Workshop on Power Elec-tronics and Intelligent Transportation System, 2008. PEITS’08, pp.529,531, 2-3 Aug. 2008.[3] Tackling congestion by making better use of England’s mo-torways and trunk roads, http://www.nao.org.uk/report/tackling-congestion-by-making-better-use-of-englands-motorways-and-trunk-roads/, accessed April 2014.[4] M. Chen, J. Chen, and T. Chang, “Android/OSGi-based ve-hicular network management system,”, Comput. Commun.,pp. 1644-1649, 2011.[5] J. Whipple, W. Arensman, and M.S. Boler, “A public safetyapplication of GPS-enabled smartphones and the androidoperating system,”, Systems, Man and Cybernetics, pp.2059-2061, 2009.[6] C.W. You, N.D. Lane, F. Chen, R. Wang, Z. Chen, T.J.Bao, M. Montes-de-Oca, Y. Cheng, M. Lin, L. Torresaniand A.T. Campbell, “CarSafe App: Alerting Drowsy andDistracted Drivers Using Dual Cameras on Smartphones,”,MobiSys ’13, pp. 13-26, 2013.[7] J. Eriksson, H. Balakrishnan, and S. Madden, “Cabernet:vehicular content delivery using wifi,”, MobiCom ’08. NewYork, NY, USA: ACM, 2008, pp. 199-210.[8] M. Gerla, J.-T. Weng, E. Giordano, and G. Pau, “Vehic-ular testbeds- Validating models and protocols before largescale deployment,”, Computing, Networking and Communi-cations (ICNC), 2012 International Conference on, 30 2012-feb. 2 2012, pp. 665-669.[9] J. Gozalvez, “First Google’s android phone launched [MobileRadio],”, IEEE Veh. Technol. Mag., vol. 3, no. 4, pp. 3-69,Dec. 2008.[10] OsmAnd software hompage, http://osmand.net/, accessedOctober 2013.[11] OSM homepage, http://www.openstreetmap.org/, accessedNovember 2013.[12] M. Haklay and P. Weber, “OpenStreetMap: User-Generated Street Maps,”, Pervasive Computing, IEEE ,vol.7, no.4, pp.12-18, Oct.-Dec. 2008.[13] S. M. Tornell, C. T. Calafate, J. Cano, P. Manzoni, M.Fogue, and F. J. Martinez, “Evaluating the feasibility ofusing smartphones for ITS safety applications,”, in VTCSpring 2013 IEEE Vehicular Technology Conference, 2013.[14] Raspberry Pi homepage, http://www.raspberrypi.org/, ac-cessed April 2014.[15] Cellan-Jones, Rory, ”A £15 computer to inspire young pro-grammers”, http://www.bbc.co.uk/blogs/legacy/thereporters/rorycellanjones/2011/05/a 15 computer to inspireyoung.html, accessed May 2014.Jornadas Paralelismo 2014 413

Messiah: An ITS drive safety application

https://biblio.ugent.be/publication/8520278/file/8520282

Messiah: An ITS drive safety application

Abstract

Similar works

Full text

Available Versions

Ghent University Academic Bibliography