Gap Analysis in Cooperative Systems within Intelligent ... · in Cooperative Systems within...

Gap Analysis

in Cooperative Systems within Intelligent

Transportation Systems

H A N N E S S A L I N

Master of Science Thesis Stockholm, Sweden 2012

Gap Analysis

in Cooperative Systems within Intelligent

Transportation Systems

H A N N E S S A L I N

DD221X, Master’s Thesis in Computer Science (30 ECTS credits) Degree Progr. in Computer Science and Engineering 300 credits Royal Institute of Technology year 2012 Supervisor at CSC was Douglas Wikström Examiner was Johan Håstad TRITA-CSC-E 2012:080 ISRN-KTH/CSC/E--12/080--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.kth.se/csc

AbstractThis master thesis project was performed at Volvo GroupTrucks Technology (GTT), Advanced Technology & Re-search within the department for Intelligent TransportationSystems, located in Gothenburg, Sweden.

This thesis provides an gap analysis in an area calledcooperative intelligent transportation systems, with a par-ticular focus on wireless-based solutions for vulnerable roadusers such as pedestrians and cyclists. The aim of theanalysis is to investigate the current status of the area andcompare that to what is wanted in future. Naturally, by us-ing smartphones these vulnerable road users should be ableto be part of a wireless cooperative solution. It was showedthat there exists a need for wireless-based cooperative so-lutions and that a technical obstacle is present, namely in-compatible communication protocols between smartphonesand vehicles.

The analysis led to a hypothesis for how to solve thisproblem and was implemented as a proof-of-concept. IEEE802.11a/b/g was used to communicate between smartphonesand road side units (a device integrated in traffic infrastruc-ture), to further relay that communication from the roadside unit to vehicles by using the vehicular standard proto-col IEEE 802.11p. This concept created a bridge over theobstacle and it was shown that the proof-of-concept workedwell without any significant delay.

Referat

Gap-analys av kooperativa system inomIntelligenta Transport System

Det bakomliggande projektet till denna rapport utfördesvid Volvo Group Trucks Technology (GTT), Advanced Te-chnology & Research, på avdelningen för Intelligenta trans-portsystem, i Göteborg.

Denna rapport tillhandahåller en gap analys inom om-rådet kooperativa intelligenta transportsystem (eng. coope-rative intelligent transportation systems), med särskilt fo-kus på trådlösa lösningar för oskyddade trafikanter (eng.vulnerable road users), dvs. fotgängare och cyklister i hu-vudsak. Målet med analysen var att undersöka områdetsnuvarande status och jämföra med vad som önskas i fram-tiden. Att använda smartphones för att integrera fotgäng-are och cyklister i en kooperativ lösning med fordon var ennaturlig utgångspunkt. Det påvisades att det existerar ettbehov av trådlösa lösningar i fordonssammanhang och attdet finns ett tekniskt hinder gällande inkompatibla kom-munikationsprotokoll mellan smartphones och fordon.

Analysen ledde till en hypotes om hur detta hinder kanöverbryggas och detta realiserades i ett proof-of-concept.Protokollen IEEE 802.11a/b/g användes mellan smartpho-nes och trafikvägsenheter (eng. road side units) (typiskatrafikenheter i traffikinfrastrukturen), för att sedan vida-rebefordra kommunikationen till omkringliggande fordonmed hjälp av det fordonsspecifika kommunikationsproto-kollet IEEE 802.11p. Lösningen implementerades och detvisades att prototypen gav tillfredsställande resultat.

CollaborationThis master thesis was performed in collaboration with Irma Hodzic, ESIEE Paris(Ècole Supèrieure d’Ingènieurs en Èlectrotechnique et Èlectronique). One reportfor Volvo specifically, as a deliverable, was written together with Irma Hodzic. Thisreport is based on that deliverable and customized for KTH. This means that themajor part of this report has been created together with Irma Hodzic, i.e., written inone document by both authors at the same time. However, Section 2.1 and Chapter5 (except Section 5.8, 5.9 and 5.10) are written by the author alone, and Section3.2, 3.3 and 3.4 are created by Irma Hodzic alone. In this report those parts whichare based on Irmas text are slightly modified and re-written to suit this report. Allother chapters contain text written by both parties together as described above.

The author had a larger part in the development of the implementation, andIrma Hodzic had the major role in testing and evaluating all software. All back-ground work (literature studies), analyses and conclusions were made together.

AcknowledgementsA special thanks goes to Edvin Valtersson at Volvo, who provided a lot of valuableinput, feedback and engineering knowledge to the work. Another special thanksgoes to Katrin Sjöberg who supervised in the best way possible during our time atVTEC. I’m also very grateful to Hossein Zakizadeh who gave me the opportunityto perform this master thesis at Volvo.

Finally, all thanks to my supervisor at KTH, Douglas Wikström, my examinerJohan Håstad, my family, Julia and all friends.

List of abbreviationsAP Access PointC-ITS Cooperative Intelligent Transportation SystemsETSI European Telecommunication Standards InstituteFOT Field Operational TestITS Intelligent Transportation SystemsND Nomadic DeviceOBU On-Board UnitRSU Road Side UnitSERVQUAL (Service Quality) gap analysis modelV2V Vehicle to VehicleV2I Vehicle to InfrastructureVANET Vehicular Ad Hoc NetworkVRU Vulnerable Road User

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Purpose and contribution . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Description of this document . . . . . . . . . . . . . . . . . . . . . . 4

2 Theory 72.1 Basic data communication theory . . . . . . . . . . . . . . . . . . . . 7

2.1.1 TCP/IP protocol stack . . . . . . . . . . . . . . . . . . . . . 72.1.2 Ad hoc- and Access Point networks . . . . . . . . . . . . . . . 9

2.2 Basic wireless communication theory . . . . . . . . . . . . . . . . . . 102.2.1 Communication channel characteristics . . . . . . . . . . . . . 102.2.2 IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Intelligent Transportation Systems 113.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Cooperative Intelligent Transportation Systems . . . . . . . . . . . . 123.3 European projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.1 Previous projects . . . . . . . . . . . . . . . . . . . . . . . . . 123.3.2 Current projects . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4 Standardization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4.1 Frequency standards . . . . . . . . . . . . . . . . . . . . . . . 143.4.2 ETSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4.3 ITS architecture . . . . . . . . . . . . . . . . . . . . . . . . . 143.4.4 IEEE 802.11p . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Gap analysis 174.1 Definition of gap analysis . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Gap analysis methods . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2.1 Literature studies . . . . . . . . . . . . . . . . . . . . . . . . . 174.2.2 SERVQUAL model for survey . . . . . . . . . . . . . . . . . . 17

4.3 Background work for gap analysis . . . . . . . . . . . . . . . . . . . . 184.4 Gap analysis on cooperative solutions for vulnerable road users . . . 204.5 Gap analysis on compliance of communication standards for nomadic

devices and vehicles . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.5.1 Issues using IEEE 802.11p in nomadic devices . . . . . . . . . 234.5.2 Modyfing hardware . . . . . . . . . . . . . . . . . . . . . . . . 234.5.3 Modyfing firmware . . . . . . . . . . . . . . . . . . . . . . . . 23

4.6 Gap analysis with survey . . . . . . . . . . . . . . . . . . . . . . . . 234.7 Summary and complete analysis . . . . . . . . . . . . . . . . . . . . 26

4.7.1 Needs and requirements . . . . . . . . . . . . . . . . . . . . . 27

5 Implementation 315.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.1.1 Hardware setup . . . . . . . . . . . . . . . . . . . . . . . . . . 325.1.2 Software setup . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 GeoLoc Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.2.1 Android platform . . . . . . . . . . . . . . . . . . . . . . . . . 365.2.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2.3 Logical architecture . . . . . . . . . . . . . . . . . . . . . . . 38

5.3 GeoLoc Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.3.2 Logical architecture . . . . . . . . . . . . . . . . . . . . . . . 41

5.4 In-vehicle software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4.1 Setup 1: Non-graphical version . . . . . . . . . . . . . . . . . 435.4.2 Setup 2: Graphical version . . . . . . . . . . . . . . . . . . . 44

5.5 ND and RSU communication . . . . . . . . . . . . . . . . . . . . . . 455.5.1 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.5.2 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.6 Data protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.7 Summary of developed software . . . . . . . . . . . . . . . . . . . . . 475.8 Field operational test and measurements . . . . . . . . . . . . . . . . 47

5.8.1 Availability: Range of connection . . . . . . . . . . . . . . . . 475.8.2 Congestion: Frequency of receiving packets . . . . . . . . . . 475.8.3 Field operation test . . . . . . . . . . . . . . . . . . . . . . . 48

5.9 Security aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.10 VRU Awareness Message . . . . . . . . . . . . . . . . . . . . . . . . . 51

6 Conclusion and future work 53

Bibliography 55

Appendices 59

Chapter 1

Introduction

1.1 Background

Mobility is vital for the successful functioning of any modern society nowadays. It isimpacting strongly on the economy and the standard of living. Systems of transportas the main mean of mobility are enabling job creation, economical growth andfreedom of movement, consequently increasing the quality of life for citizens.

In Europe, transport industry accounts for 7% of GDP (Gross Domestic Prod-uct) and overall 5% of total employment [1], therefore this sector is in constantneed of change and improvement. It is expected that by the year 2060, 30% of thepopulation will be people aged 65 or above and the world population is expectedto increase up to 9 billion [1]. They will tend to move and travel more then theirformers. With this increase comes the necessity of increasing retirement and health-and care fonds. Eventually, this will result in higher transport costs. Migrations ofthe young population for studies, or mature population for working are more andmore common. Especially the movement of workers inside EU is increasing rapidlysince all legal barriers are removed. Now there are more people in the world, more ofthem emigrating, more personal cars, more congested roads and more CO2 emissionin urban and inter-urban areas then ever before. All these future trends are at thesame time challenges that are provoking a need for unified transport networks andintelligent transport systems.

ITS (Intelligent Transportation Systems) is information- and communicationtechnologies for communication between vehicles and infrastructure with the aimto improve traffic safety, transport efficiency, environmental performance and othervehicle related areas. Since the 1960’s [3] there have been research and demonstra-tions of such systems around the world, mainly in Japan, U.S. and Europe, buttoday there still exists no coherent systems world wide which are compatible or infull use. Thus, still some research, development and progress has to be done in thefield.

A subarea of ITS called C-ITS (Cooperative Intelligent Transportation Sys-tems), is defined to be all systems building on interacting services in vehicular

1

CHAPTER 1. INTRODUCTION

environments. This means that entities in such systems are able to communicatewith each other and share information. A VANET (Vehicular Ad hoc Network)is a typical C-ITS concept where vehicles in a temporary WLAN environment areconnected and share information to achieve better safety, efficiency and/or trafficflow.

Figure 1.1. Graphical depiction of a VANET, a concept within ITS. Image ©Car 2Car Communications Consortium.

During the last decade there have been projects [28], [29], [30], especially in Eu-rope, which have drawn together stakeholders (companies, industries, organizationsetc.) and developed interesting and powerful technologies within ITS. Today thereare more ongoing projects, under European Commission government and indepen-dently, then ever before and their aim is to harmonize the technology and push itfurther into the actual market.

1.2 Problem statement

The focus of the work in the C-ITS domain up until now was mainly on V2V(Vehicle-to-Vehicle) and V2I (Vehicle-to-Infrastructure) communications. Only asmall percentage of the research conducted focus on so called NDs (Nomadic De-vices) and to actual focus on VRUs. NDs are handheld devices such as smartphones,PDAs and equivalent, which could be a part of a vehicle or carried around by apedestrian or cyclist. VRUs are referred to pedestrians, cyclists, motorcyclists andother two-wheelers.

2

1.3. SCOPE

In this thesis it is assumed that most people in Europe owns a smartphone, inthe sense that the device can easily use Wi-Fi or similar communication protocols,therefore it would be suitable to integrate pedestrians into VANETs by using thesedevices. It is obvious that the safety for VRUs would have a potential increase ifthey were allowed to be integrated into VANET communications. For such inte-gration, some technical obstacles will appear. The communication standard usedfor VANETs was accepted to be IEEE 802.11p, and smartphones are not compati-ble with that standard since they are mostly working on IEEE 802.11a/b/g. Mostresearch projects related to VRUs, e.g [28], [30], [29], have been focusing mostlyon sensor technologies for vehicles and infrastructure, not to actually communicatewith VRUs explicitly. Pedestrians and two-wheelers is a big part of all entities inmost urban locations, therefore it is natural to include them in the traffic com-munication as well. The problem is then to find a suitable solution to integrateVRUs into VANETs and overcome the technical obstacle of incompatible protocolsbetween NDs and vehicles.

1.3 Scope

This master thesis project is limited to the problem of finding a cooperative solutionfor VRUs using smartphones, and communication protocols IEEE 802.11a/b/g/p.This includes a gap analysis on cooperative solutions for VRUs in order to identifyany potential solution that could be implemented as a proof-of-concept.

Outside the scope of this master thesis project is an in-depth analysis of securityregarding the implementation. Communication security in ad hoc networks wouldbe its own topic of research.

1.4 Purpose and contribution

The purpose of this thesis is to contribute with an analysis of a missing researcharea within C-ITS, and hopefully propose a solution for the identified gap that willtrigger further investigations and research in future. Volvo and other stakeholders(e.g ERTICO, COMeSafety, ETSI, road side traffic controllers, car manufacturersetc.) could benefit from potential solutions engineered as results of this thesis,because if any chosen implementation shows to be successful (as a proof-of-conceptor other prototype), stakeholders will then know on which type of research to investmore fundings, resulting in a generally greater economical profit.

1.5 Methodology

This subsection gives a brief overview of the methodology used in this thesis. Thefirst research steps are described in following flow chart:

3

CHAPTER 1. INTRODUCTION

Literature studiesin ITS area ::

Identify areaww

// gap analysis inidentified area

// Proposesolution

The first step is to identify an area within ITS that needs to be investigated fur-ther, namely to conduct an analysis of why this is needed. After this step, a gapanalysis is performed in that specific area. This is done by using certain methodsdescribed in chapter 4. Depending on the analysis, a possible solution to fill anyidentified gaps can be formulated and eventually implemented. Thus, next researchsteps consists of the development and evaluation of the proposed solution:

Formulatehypothesis

// Implementationphase

// Testing // Analysis ofresults

After these final steps, the analysis of the implementation results will tell if theidentified gaps can be closed or not.

1.6 Description of this document

Introduction The introduction gives a brief background to the problem state-ment, the actual problem statement itself, the purpose of the project, selectedmethodologies and some motivation for what this project can contribute with.

Theory This chapter introduces the reader to basic wireless communication the-ory and basic data networking theory, which this report is based on.

Intelligent Transportation Systems This chapter describes ITS in general,the subarea C-ITS and describes current / previous ITS projects and technologystandards regarding that area. The purpose is to introduce the reader of backgroundto the gap analysis.

Gap analysis Here the actual gap analysis is presented with an general overview,background to the chosen area and related work, leading to a hypothesis of a possiblesolution for closing identified gaps.

Implementation This chapter describes the implementation of a hypothesis givenfrom the results of the gap analysis. This part is of a more technical nature andgives a full specification of all software and hardware involved.

4

1.6. DESCRIPTION OF THIS DOCUMENT

Conclusion Conclusions and discussion about future work regarding the imple-mentation and results from this master thesis report.

5

Chapter 2

Theory

This chapter will provide a brief theoretical background in wireless communicationtheory, and basic data communication theory. The idea is not to give a detaileddescription of these areas, only to provide the needed reading for this report.

2.1 Basic data communication theory

2.1.1 TCP/IP protocol stack

To be able to communicate in a computer network, some sort of protocol(s) mustbe used. Today, the TCP/IP protocol stack is a very common and used set of suchprotocols. The TCP/IP protocol stack is a layered architecture, similar to the OSI-standard model, and it uses 5 different layers [2]: application-, transport-, network-,link- and physical layer. The main concept is that all computers in a network musthave a specific address assigned to itself (an IP-address), to be able to be part ofthe communication. When data is to be sent by some program in a client computer,the data is encapsulated and sent down trough all 5 layers in the stack, addressedto a receiving client. The lowest layer - the physical layer, will then physically sendthe data packets via some communication medium to the recipient.

Application layer

In the TCP/IP stack the three top layers in the OSI-model (session-, presentation-and applications layer) are merged into one: the application layer. It serves as thewindow for users and application processes to access network services, meaning itis the closest one to the end-user. Some of the typical functions include identi-fying communication partners, determining resource availability and synchronizingcommunication [2]. Everything at this layer is application-specific. It also providesapplication services for file transfers, e-mail and other network software services [46].Telnet, FTP and HTTP are well known example applications that exist entirely onthis level.

7

CHAPTER 2. THEORY

Figure 2.1. TCP/IP stack compared to the OSI-model. source:http://www.networkingreviews.com/2008/06/04/tcpip-model-vs-osi-model/

Transport layer

In the transport layer one can choose between different protocols to use for handlingthe data communication, in a perspective of data stream support, reliability, flowcontrol and multiplexing [2]. The most common protocols are TCP and UDP. TCPis a connection-oriented, reliable, handshaking protocol that establishes a connec-tion between two hosts and provides error handling (resending dropped packets,acknowledge entities etc.). The TCP handshake is a three-way handshake, whichcan be illustrated by the following example:

Example 1. Let α and β be two hosts in a network, and α wants to send somedata to β. First β needs to bind a connection to a specific port and start listenfor incoming connections. Next, α creates a packet of data (first a so called TCPsegment which in turn is encapsulated by an IP packet, and finally encapsulated bya data frame in the physical layer) and send it to β’s connection at the specifiedport. This first data packet is called a SYN-packet. β receives the SYN-packet andresponds with a SYN-packet himself and an ACK-packet, which acknowledge thathe actually received α’s SYN-packet. Finally, α responds with an ACK-packet toacknowledge β, and a connection is now established.

As seen in example 1, the three-way handshake is necessary in order to establishthat both parties exchange communication addressing (port number), correct datatransfer and also acknowledge each other.

UDP is not a reliable protocol because it is a connectionless protocol. So thereis no need for handshakes and connection establishments, which is useful for chat

8

2.1. BASIC DATA COMMUNICATION THEORY

applications or media streaming where it is desirable to just send a lot of packetswithout caring if they reach the destination at all times.

Network layer

The network layer provides functional and procedural means for transferring datafrom the source host in one network to a destination host in another network. Itprovides routing technologies [2], creating logical paths, known as virtual circuits,for transmitting data. Routing, forwarding, addressing, inter-networking, error han-dling, congestion control and packet sequencing is the network layer’s main func-tionality [46].

At this layer the most common choice nowadays is between IPv4 and IPv6protocol. These protocols encapsulate the UDP/TCP packets coming from thetransport layer into IP-packets, and send them further down the layer-chain [48].The main difference between IPv4 and IPv6 is that IPv6 has a larger address spaceand better security functionality [2].

Link layer

This layer provides error-free transfer of data frames from one host to another,(inside the same network), over the physical layer, allowing layers above it to assumevirtually error-free transmission over the link [47]. The data link layer is dividedinto two sub layers: The MAC (Media Access Control) layer and the LLC (LogicalLink Control) layer. The MAC sub layer controls how a computer on the networkgains access to the data and permission to transmit it. The LLC layer controlsframe synchronization, flow control and error checking[4]. The most common typeof equipment operating at this level is given by network switches. A network switchor hub is a computer networking device that connects network devices and relaydata packets within the network.

Physical layer

This layer conveys the bit stream, electrical impulse, light or radio signal, throughthe network at the electrical and mechanical level. It provides the hardware meansof sending and receiving data, including transmission medium (defining cables) andphysical aspects like hubs, repeaters, network adapters, layouts of pins, voltagesetc.[49]. One of the main functions of the physical layer is modulation. Modulationis the conversion between digital data and the corresponding signals that will betransmitted over a communication channel. A communication channel refers toeither a wired or a wireless transmission medium.

2.1.2 Ad hoc- and Access Point networks

There are two different types of network topologies used in wireless data networks:ad hoc networks where two nodes are able to connect directly to each other, and

9

CHAPTER 2. THEORY

access point networks where all nodes are interconnected via some base station(access point) which regulates all traffic between nodes.

2.2 Basic wireless communication theory

2.2.1 Communication channel characteristicsA wired network is connected with a shared cable whereas wireless networks areconnected with RF (Radio Frequency) transmitter(s) and receiver(s) over an airinterface. RF is an electromagnetic signal with a frequency between 3 kHz and 300GHz[5]. The information in wireless systems is sent over a RF signal, usually sinu-soidal one. This RF signal carrying the information is called carrier wave. In orderfor the information to be carried properly it has to be encoded in some way. Thismeans that the carrier wave needs to be modulated. Since the RF signal can carryanalog (information content continuously varies over time) and digital information(information content consists of discrete units, 0 and 1), consequently there arecorresponding analog and digital modulations. An analog signal is mostly modu-lated using AM (Amplitude Modulation) and FM (Frequency Modulation), whereasdigital signals is mostly modulated using ASK (Amplitude Shift Keying) and FSK(Frequency Shift Keying). Naturally, when the modulated signal is transmitted, itneeds to be demodulated on the receivers side and returned into the original signal.

Typically any signal transmitted nowadays will include many different frequen-cies. The range of the frequencies varying in the signal is called spectrum and thewidth of the spectrum is defined as the bandwidth of the signal. Attenuation andreflection are common distortion factors during transmission, also called signal in-terferences, which gives what is known as path loss. Expectedly, the received signalwill always be weaker than the sent signal due to these distortions.

2.2.2 IEEE 802.11IEEE (Institute of Electrical and Electronics Engineers) is a standards organiza-tion which created the set of standards for implementing WLANs (Wireless LocalArea Networks) [11]. This set of standards is called 802.11 and allows wirelesscommunication in the 2.4 GHz and 5 GHz frequency bands. The most commonprotocol standards in the 802.11 family are the a, b, g and n protocols, but in thevehicle industry also the p protocol exists nowadays [13]. They are all using thesame basic protocol which was created in 1997, but different modulation techniques.Protocols a,b and g are commonly called Wi-Fi. Regarding the frequency band forthese Wi-Fi protocols, only protocol a is using 5 GHz and not 2.4 GHz as b andg, which is usually more used. On the other hand, a and g are using OFDM (Or-thogonal Frequency-division Multiplexing) transmission, whereas b is using DSSS(Direct-sequence Spread Spectrum) [5].

10

Chapter 3

Intelligent Transportation Systems

“Intelligent Transport Systems (ITS) are systems to support transportation of goodsand humans with information and communication technologies in order to efficientlyand safely use the transport infrastructure and transport means (cars, trains, planes,ships). Elements of ITS are standardized in various standardisation organisations,both on an international level at e.g. ISO TC204, and on regional levels, e.g. inEurope at ETSI TC ITS and at CEN TC278.” (ETSI Intelligent Transport Systems(ITS); Communications Architecture, 2010, p. 5).

3.1 Overview

The above citation describe ITS quite well. This area has a wide set of differentambitions, such as safety, efficiency, mobility, sustainability etc. There is a greatnumber of potential applications for these kind of systems, and many have beeninvestigated and even deployed: automated tolling systems, number plate recog-nition technologies, car navigation and speed cameras are all parts of ITS. Thesetechnologies have saved a lot of time, money and most importantly—human lives.

ITS is based on several different technologies and also depends on other fieldsof research, e.g., the development of new/better telecommunication- or GPS-relatedtechnologies. There is also ITS-specific technologies developed, like the IEEE 802.11pstandard for wireless data exchange in VANETs. This standard is often used in C-ITS, and have a lot of applications in road traffic, e.g., real-time traffic routing,collision risk computations, automatic lane-shifting etc [3]. This means that vehi-cles in cooperation could prevent unnecessary accidents and road congestions byexchanging relevant information. Warning about road works and current road sit-uation, and suggestions of optimal routes are just some of the advantages when itcomes to V2V/V2I communication.

11

CHAPTER 3. INTELLIGENT TRANSPORTATION SYSTEMS

3.2 Cooperative Intelligent Transportation Systems

ITS is a huge area with many different subareas, where one of them are C-ITS (Co-operative Intelligent Transportation Systems), which simply is all systems whereITS stations cooperate, e.g by communicating with wireless networks or exchangingsensor data. By using wireless communication and sensors, vehicles and infrastruc-ture can communicate in VANETs dynamically, and exchange traffic information.A mobile ITS-station is any kind of vehicle with ITS-technology installed and afixed ITS-station is any roadside installation (infrastructure) with ITS-technology.A typical mobile ITS-station is the OBU (On Board Unit): hardware and soft-ware that enables the vehicle to communicate with RSUs (Road Side Units) orother OBUs. A RSU is a typical fixed ITS-station and is often equipped with sen-sors, cameras and/or different communication means in order to communicate withnearby vehicles and traffic control centers [3].

Vehicles today can be connected thanks to various wireless communication stan-dards. Not only so that they could send the information about themselves (currentposition, fuel status, CO2 emission, driving speed etc.) and their environment toa traffic control center, but also to exchange this information among themselvesor nearby infrastructure. C-ITS services are then giving the drivers an additionalawareness on the road.

Today’s most commonly used standard for exchange data packets between ITS-stations is the CAM (Cooperative Awareness Messages) [9]. The CAM messagecontains vehicle- and environment information. Together with CAMs in cooperativesystems, DENMs (Decentralized Event Notification Messages) [10] is also a type ofwarning messages, which provides environmental information, e.g., potential roadworks, road congestions and similar sudden events.

3.3 European projects

This section gives a brief description of previous and current C-ITS projects in Eu-rope, in order to prepare for the gap analysis. It is important to perform an analysisof what these projects contained, to give a good picture of the current status of C-ITS (what have been investigated so far in these projects). After investigating theseprojects it can then be found if there was a lack of research regarding cooperativesolutions for VRUs.

3.3.1 Previous projects

The COOPERS project investigated V2I communication particularly, and devel-oped a RSU using the ISO CALM standard [12], [28]. This system was usingIR-radars along roads that could get real-time traffic information which could forinstance be relayed back to a traffic control center. It was concluded that theCALM IR system worked satisfiable. Another project, CVIS, was also focused on

12

3.3. EUROPEAN PROJECTS

V2V/V2I communication (platforms) considering CALM-related technologies[29],but also using IPv6.

The SAFESPOT project consisted of 8 sub-projects, in which all were relatedto V2V/V2I communication. Especially equipped vehicles and specific RSUs weredeveloped and tested in different parts of Europe. IEEE 802.11p communicationbenchmarks and testing of a wide range of different use cases were conducted. Theabbreviation IRIS (Intelligent coopeRative Intersection safety Systems) was intro-duced during the project, which refers to systems aiming to decrease the number ofaccidents occurring at intersections. The general conclusion was that the equipmentdid provide drivers with warning information in a satisfiable way [30].

There is an idea of combining all the previous discovered applications in thedomain of cooperative systems regarding V2V/V2I, and testing them on a largerscale. This is led by the project DRIVE C2X [31] that is connecting all the nationalFOTs (Field Operational Test) into one large European platform. Besides FOTs,pilot tests are built as well and several of them are concerned with freight transportand safety while delivering goods. An example of such pilot tests is in the FREILOTproject [32].

After the final testing and piloting it is important to standardize the findingsand promote the usage, or at least maintain cooperation between EU and U.S. stan-dardization bodies so that they hopefully result in globally harmonized standards.COMeSAFETY2 [33] is working on these issues on the European side.

3.3.2 Current projects

It seems to be of general interest in making the cities, cars and driving more envi-ronmental friendly within ITS today. There are several ongoing projects regardingthese issues, e.g. COSMO [34], eCoMove [35], EcoGem [36], CATS [37].

COSMO are dealing with the increase of energy efficiency on its Italian site,and traffic sustainability on its Swedish site. Traffic management, low energy streetlightening, eco-driving, eco-dynamic parking management and green light optimiza-tion are also performed on these sites. Wireless communication technologies havebeen used, in particular IEEE 802.11p. The core concept of the eCoMove andEcoGem projects is that they investigate the theoretical minimum of energy con-sumption regarding driving. CATS are trying to develop next generation vehicles,for the every day drive as well as for seasonal tourist usage.

As it has been stated in the problem statement, there have not been manyprojects that are dealing specifically with the protection of VRUs even thoughthe percentage of road fatalities for VRUs is high. However, there are currentlysome steps forward regarding this area: projects like ASPECSS [42], ARTRAC[43], AMULETT [38], MINIFAROS [44], and SAFEWAY2SCHOOL [41] are worthmentioning. Most of them are trying to develop assessment methodologies for in-creasing pedestrian- and cyclist safety using radars, sensors but less often wirelesscommunication techniques [38], [41].

Besides cooperative systems communication, so called environmental sensing

13

CHAPTER 3. INTELLIGENT TRANSPORTATION SYSTEMS

and object recognition are included in research projects, especially when it comes toincreasing safety of VRUs. Previously, radars have been used mostly with approx-imately 24 GHz (ARTRAC project [43]) frequency, but lately 75-110 GHz rangeis introduced, as in the usage with visual sensors for autonomous vehicles. Somevery novel concepts and ideas in the domain of ITS sensing technologies have beenintroduced e.g a new laser-scanner made for the MINIFAROS project [44]. Theyare used as sensors for ADAS (Advanced Driver Assistance Systems) in vehicles, toassist object recognition.

3.4 Standardization

3.4.1 Frequency standards

In 2008, the European Commission decided that the frequency band in range 5.875-5.905 MHz should be used for ITS road safety applications. After this decisionthe CEPT ECC (European Conference of Postal and Telecommunication Adminis-trations Electronic Communications Committe) has decided to use this same bandfor V2V and V2I communication. In addition they have added frequency band5.905-5.925 MHz for future ITS applications [50].

3.4.2 ETSI

In Europe, a major role in standardization is performed by ETSI (European Telecom-munication Standards Institute). ETSI produces globally applicable standards forinformation and communication technologies, including fixed, mobile, radio, con-verged, broadcast and internet technologies[7]. One of its main tasks is also tosupport industry and European regulations deciding on frequency requirements onthe technologies that have been standardized. ETSI has around 700 company mem-bers from all five continents[7].

3.4.3 ITS architecture

Standardization organizations such as ETSI have created certain standards for ITSarchitectures. The commonly used, but not fully accepted by everyone, ITS ar-chitecture standard[8] from ETSI builds on a protocol stack customized for ITSapplications. This standard is also built on layers, corresponding to the OSI-model.

Some important concepts in the ITS architecture are the CAM and DENMmessages. As described in section 3.2, the CAM message contains specific hostinformation, and is generated by the vehicle itself. Typical data in a CAM mes-sage is information about speed, direction, vehicle status etc. These messages arebroadcasted to all nearby vehicles in range of a single-hop. The DENM messagestravel further than just a single-hop, but is also only generated during suddenevents. DENM contains environmental related data such as traffic jam ahead orbad weather conditions.

14

3.4. STANDARDIZATION

3.4.4 IEEE 802.11pBack in 1999 when the U.S. Federal Communication Commission allocated 75 MHzof DSRC (Dedicated Short Range Communications) spectrum at 5.9 GHz to be usedexclusively for cooperative systems communications. This was free for usage but alicensed spectrum which could be used with the respect of certain rules. Many effortshave been made for the standardization of DSRC radio technology and in 2004 thiseffort was migrated to IEEE 802.11[13]. Since DSRC is IEEE 802.11a adjusted forlow overhead operations, it has become known as IEEE 802.11p WAVE (WirelessAccess in Vehicular Environments) within the IEEE 802.11 standard.

Figure 3.1. IEEE standards (source: www.davidrust.com).

IEEE 802.11p was introduced by an amendment[6] to be a support for wire-less access for vehicular environments. This means that IEEE 802.11p enablescommunication between hosts dynamically without a need for actual establishmentprocedures, aka ad hoc networking. The amendment regarded the MAC layer andthe physical layer in the protocol stack. The channel bandwidth of IEEE 802.11pis 10 MHz whereas for IEEE 802.11a it is 20 MHz.

The majority of all investigated C-ITS projects seem to be putting great effortsin the on-field testing and actual implementation of IEEE 802.11p based solutions,e.g. [29], [30], [31], [35].

15

Chapter 4

Gap analysis

4.1 Definition of gap analysisWhen performing a gap analysis, the aim is to identify gaps of missing/necessaryneeds in a selected area in relation to what outcomes are desired. In other words: onemust compare what has been done in the area, and compare this to the ambitions ofwhat to aim for. There will probably be a gap in-between, which in that case mustbe identified. When this identifying process is completed the analysis hopefullyproposes a solution of how to fill the gap.

There are two tools used for gap analysis in this report: literature studies andsurvey. Literature studies include research papers, articles, books and ITS projectdeliverables. For survey, a numerical approach (quantitative method) was used torepresent gaps visually.

4.2 Gap analysis methods

4.2.1 Literature studiesThe following discussion is based on publications and deliverables from the C-ITSprojects described in this chapter, but also articles and industry standardizationdocuments.

4.2.2 SERVQUAL model for surveySERVQUAL is a model for measuring customer perceptions of service quality in-vented in the late 1980’s [14]. Later, the model was refined [15]: from measuring10 aspects of service quality, down to 5 aspects, called dimensions. The idea, as inany gap analysis, is to get a good understanding in what customers want and toidentify what they have at the moment. Note that all 5 dimensions are measuredand corresponds to 5 different gaps.

The methodology is to make surveys and/or interviews within each dimensionthat determine the relative importance of each attribute (expectations and perceived

17

CHAPTER 4. GAP ANALYSIS

sensations) and to rank them using a Likert scale [16] of 5 or 7 scoring levels. To getresults, a arithmetic mean is calculated from both the expectation- and perceivedsensations perspective. These arithmetic means are then compared, which will showif there exists a gap, according to any possible numeric differences. This also meansthat the model uses a quantitative method for collecting data, using surveys as themain method.

A Likert item is a statement that a respondent have to evaluate according toeither a subjective or objective criteria, e.g. level of agreement. The item can bevisualized as a horizontal line with circles corresponding to each evaluation level:

◦ ◦ ◦ ◦ ◦good quite neutral quite bad

A respondent evaluates a set of Likert items and then the results are summed,which is called theLikert scale. To do this properly, each evaluation level need tohave a numerical value, e.g. progressive positive integers:

◦ ◦ ◦ ◦ ◦1 2 3 4 5

To do a gap analysis is then to compute the Likert scales that corresponds tothe attributes ci, ei in a dimension, both in the perspective of current view, sayCk = ∑n

i=1 ci, and in the perspective of expected/wanted view, say Ek = ∑ni=1 ei.

Then, compute the arithmetic mean value, Ek and Ck, for each sum according tothe number of people who answered the questions. Finally, compute the difference∆k = Ek−Ck where gaps are identified. Note that the distances between every levelwithin an item should be equidistant, otherwise the outcome have a high potentialto be biased.

4.3 Background work for gap analysis

Before performing a gap analysis, one must choose an area to analyze. It is notalways the case that there are any gaps, therefore it is required to iterate the processof finding an area until a gap is identified.

After performing an extensive literature study of current and previous ITSprojects, mainly in Europe, it was found that not many projects (as well in theU.S. or Japan) was investigating how to integrate pedestrians and cyclists in coop-erative ITS safety solutions. As described in sections 3.3.1 and 3.3.2, most researchseems to be into sensor technologies and communication between vehicles and in-frastructure only. This process of identifying an area with potential gaps to analyze,ended with a table describing the major part of all investigated projects in Europe,which is found in appendix A. From the table it is clear that there is a lack of focuson VRUs with cooperative solutions.

18

4.3. BACKGROUND WORK FOR GAP ANALYSIS

A suggestion is that due to today’s rapid development in smartphones, suchas Iphones and Android units, no one have had the time and/or opportunity yetto investigate them in the context of cooperative ITS solutions. If this suggestionis true, then it is a perfect area to analyze and two matching questions can beasked: where are we today regarding integration of smartphones into traffic? anddo stakeholders want this type of integration?

Another issue found during the identifying process was the lack of compatiblecommunication technology for smartphones and the IEEE 802.11p protocol. At thetime, no mobile manufacturer had any products in the market that supported thisstandard. This was problematic because the majority of all investigated VANETsand projects used IEEE 802.11p as communication standard protocol. The rea-son why IEEE 802.11a/b/g have not been used more extensively is because IEEE802.11p is more suitable for ad hoc networking; as described in chapter 2 IEEE cre-ated this standard for that particular reason. Also, IEEE 802.11a and IEEE 802.11pdoes have the same physical layer [13], but in IEEE 802.11p one cannot have powersave mode enabled which will drain the battery of any standalone device using it.This clearly is a problem if NDs are suppose to use IEEE 802.11p. Another issueis that IEEE 802.11p is specifically for VANETs and vehicle communication, whichmeans that the frequency is already heavily used. If VRUs also are going to be partof that frequency, there might be a high risk for data traffic congestion (too manyVANET entities share same frequency).

Figure 4.1. Statistics for VRU fatalities in Sweden between 1996-2010. The y-axisdescribes number of fatalities. Source: Trafikverket [25].

One can conclude that there are many different factors in the traffic that couldcontribute to VRUs exposure of danger, e.g., number of vehicles, experience levelof drivers, weather conditions, safety related infrastructure etc. Another factorthat has a great impact on VRUs safety in traffic is the actual traffic flow [17],

19


which is an area that potentially could be improved by cooperative solutions inC-ITS. If ITS-stations in a VANET are aware of VRUs and/or can communicatewith them, it is natural to conclude that there must be solutions for their safety.Also, one important motivation for using cooperative solutions for VRUs instead ofconventional sensor safety (radar, cameras etc.), is that such systems cannot identifyor perform accurate target classifications of hidden or partly hidden VRUs.

As early as in 1996, in Sweden, it was concluded [17] that pedestrians was themost vulnerable VRUs, which is also verified in figure 4.1, although the trend seemsto be that motorcyclists are going to be just as exposed as pedestrians (countingnumber of fatalities) in the future.

These facts lead to the conclusion that there is a gap: no satisfiable integrationof VRUs in VANETs. Also, there exist problems in this area that needs to besolved if such integration will be feasible. At the same time one can argue that thisintegration would be very important and have great impact on traffic safety; if weare able to put one more variable into a safety application (the awareness of VRUs)it is most likely that we can provide better safety. In a typical VANET situation, e.gan intersection, each vehicle could have satisfactory accurate data of all pedestriansand cyclists in the vicinity, which in turn can be used to calculate collision risksand estimate their trajectories. This means that if the VRUs is integrated intothe VANET and provide all ITS stations with at least coordinates (and preferablymore data such as speed, direction etc.) a better safety could be achieved. Thiswould most likely be solvable with some sort of wireless communication and not bysensors. From this, a call for a gap analysis of cooperative solutions for VRUs wasinitiated.

4.4 Gap analysis on cooperative solutions for vulnerableroad users

Most VRU related R&D projects have been focusing on sensors and other non-cooperative solutions. These technologies are mostly IR-sensors, cameras, laserscanners etc. For example, in PReVENT’s sub-project COMPOSE [51], differentkind of legacy image- and distance sensors are used, but even if the results aresatisfactory it puts a significant added cost to the automotive electronics budget[18]. Another example would be the SAVE-U [39] project that has been investigatingthe prevention of accidents concerning VRUs, using non-cooperative technologies.The main concern is that it had limited applicability regarding VRUs hidden byobstacles, or in the blind spot area of the sensor.

Other solutions investigated are so called cooperative sensors; sensors from alltraffic entities or parts of them, that cooperate in the perspective of emitting andtransmitting sensor data to each other. During 2006-2008 a European project calledWATCH-OVER[45] developed a wearable tag for VRUs, using low-cost antennas.The typical range (under free-field conditions) was about 140 meters and non-line ofsight distances was measured to around 30-40 meters which is more than sufficient

20

4.4. GAP ANALYSIS ON COOPERATIVE SOLUTIONS FOR VULNERABLE ROADUSERS

for intra-urban traffic scenarios [18]. More measurements showed that raw-data ac-curacies below 1 meter under free-field conditions were obtained [20], [19]. Problemsarising with this kind of solution is to make people wear the tag, it requires a user toget hold of an additional device to keep track of. Also, compared to a smartphonewhich can run graphical and interactive applications, a tag is much harder to assesswhether it is still working.

Another project that has been investigating cooperative solutions for VRUs wasthe AMULETT project[38]. The project was performed during 2007-2009 and wasfunded by Germany’s State Ministry for Economic Affairs, Infrastructure, Transportand Technology, and the system was mainly developed by BMW. The investigatedsolution was focused on a specific dedicated 2.4 GHz transponder for pedestrians tocarry around, that could receive and transmit data with an in-vehicle localizationunit. The vehicle emitted an interrogation pulse every 20 ms that surroundingtransponders could receive. If so, the transponder decoded the pulse and respondedafter waiting for a certain TDMA (Time Division Multiple Access) protection timeinterval. When the localization unit in the vehicle received the transponders answer,it was checked for authenticity. If successful then the distance between the vehicleand transponder was calculated. Autonomous distance measurement between twoobjects was done using RTOF (Round-Trip-of-Flight). This corresponded to thetime for the signal to travel from vehicle to pedestrian and vice-versa. Firstlythe distance, ∆s, between the two is calculated using the total elapsed time Tp,additional fixed waiting time Tw (added on the pedestrian side of sensor to eliminateinfluences of passive reflections) and speed of light c0. This is given by the followingformula [24]:

∆s = Tp − Tw

2 c0

To initiate the measurement of time, the vehicle sensor broadcasts data duringtime Ts. The pedestrian sensor listens to the data and responds after the waitingtime Tw, specific for every pedestrian. The data sent is coded by pseudo randomcodes. Applying correlation techniques, time of arrival can be determined by com-paring the time of received data (pedestrian sensor) and the time of broadcasteddata (vehicle sensor).

It was concluded that this localization and positioning system is working in asatisfying way even without line-of-sight between communication partners and clearidentification of pedestrians is present [24]. In an article (Autoevolution magazine,2nd of June 2009) BMW states that their portable devices can easily be integratedin mobile phones and even walking sticks for blind people. The backside of thisproject is that a completely new device (as in the WATCH-OVER project) wasintroduced. Even if the device can be integrated into a mobile phone or equivalent,a hardware modification is needed. Therefore, this project only gives a customizedsolution which in no way is deployable in large scale in the near future.

In Japan, relatively extensive research in the area have been conducted [22]: in-vehicle cameras and sensors which was shown to not be completely satisfactory due

21


to the drivers difficulties to recognize pedestrians from out of sight, within necessarytime limit. Another system that was also looked into was a developed communi-cation system that used the 5.8 Ghz band based on DSRC. The drawback of thiswas that, as in the above described European projects, specific hand-held deviceswas needed to be developed instead of using mobile phones. On the other hand,in 2008 it was developed [22], [23] a communication system that used IEEE802.11band 3G (via the Japanese 3G-provider FOMA) to integrate mobile phones intoVANETs. The communication delay when using 3G and IEEE802.11b was investi-gated and it was concluded that the delay did not create any significant problems,e.g the IEEE802.11b delay was around 20 ms regardless of the distance betweenvehicle and pedestrian. The system configuration consisted of mobile phones, in-vehicle GPS systems and a server which provided both pedestrians and vehicleswith collision risk computations. This means that the vehicles and VRUs werecommunicating both explicitly via WLAN and implicitly by 3G via a server. First,the mobile phones and vehicles get information (coordinates, velocity, time stamps,direction of movements etc.) about each other via the server, which also calculatethe collision risks. If it was concluded that certain nodes were in danger, then theserver would setup a peer-to-peer communication between those (mobile phone andvehicle). This to start an exchange of the latest information about each other toavoid collision.

The conclusion was that this type of system worked well and it did not need anyadditional infrastructure. Also, by measurements it was concluded that informationabout potential collisions could be sent to drivers 6 seconds ahead (12 seconds atmost in the tests[23]). On the other hand, because the solution relies on 3G andthat all entities in the VANET used the same provider (FOMA), the whole conceptis only customized for one particular provider and is far from generic.

Ongoing projects regarding solutions for VRUs are Safeway2School[41] (systemsproposed is on-board hardware for the buses, intelligent bus stops/bus signs, mo-bile devices and communication centrals for localization and communication) andARTRAC[43] (development of a new transmit/receive antenna and multi-channelreceiver and using single automotive 24 GHz narrowband radar sensors). Bothprojects are EU funded.

4.5 Gap analysis on compliance of communicationstandards for nomadic devices and vehicles

Another analysis was conducted focusing on the technological aspect of using IEEE802.11p in NDs. As described previously in the problem statement, most ITSprojects today uses IEEE 802.11p for V2V/V2I- communication. Unfortunatelyno smartphone manufacturers found in this research had any products compliantwith IEEE 802.11p, thus no cooperative solutions involving smartphones can beintegrated into a project using IEEE 802.11p.

22

4.6. GAP ANALYSIS WITH SURVEY

4.5.1 Issues using IEEE 802.11p in nomadic devices

Even if there existed hardware or drivers that enables a smartphone to use IEEE802.11p, it would still not be feasible to use that device. The main reasons, asdescribed in 4.1.2, is that there is no power save mode for IEEE 802.11p (the batterywill be drained very fast) and that there would be a high risk of data communicationcongestion if pedestrians and cyclists are going to share the same frequency withvehicles to send/receive data.

There are at least two potential solutions one can investigate, in order to makea smartphone work with IEEE 802.11p: 1) modifying the chipset/hardware in thephone, and/or 2) modifying the firmware if the chipset allows the phone to use thecorrect frequencies and protocol layers.

4.5.2 Modyfing hardware

There exists a few mini-PC cards with IEEE 802.11p, e.g the DCMA-86P2 card[52],but this is still not feasible for a ND, especially not a smartphone due to its size.Another IEEE 802.11p compliant hardware is the Cohda MK2 Radio[53], which ismanufactured especially for ITS solutions. Unfortunately this piece of hardwareis also to big in size to fit in a smartphone and is developed for in-vehicle usage(OBUs).

We conclude that during research no hardware well-suited for smartphones wasfound.

4.5.3 Modyfing firmware

Smartphones using the Android platform might be open for firmware/softwarechanges to adjust the frequency of the already existing wireless component. Allsuch smartphones are based on the Linux kernel 2.6[55]. This means that if somesoftware modifications are to be performed, they have to be specific to that partic-ular kernel.

There exists a driver, ath5k, for Linux, customized for Atheros based wirelesschipsets[54] which enables the usage of IEEE 802.11p. Unfortunately, during theresearch, no Atheros chipsets found, were small enough or compliant to be used ina smartphone.

4.6 Gap analysis with survey

A questionnaire as a type of survey was conducted. Its main purpose was to visu-alize the current status and to notify future needs in the research with cooperativesystems regarding VRUs.

By using the concept of the SERVQUAL model, changing the dimensions andattributes to better suit a gap analysis in cooperative systems, a numerical pre-

23


sentation for the analysis can be given. The modification of SERVQUAL is thefollowing:

Definition 1. In gap analysis model SERVQUAL-ITS, the measurable dimensionsare A and B where

• A = Involvement

• B = Successfulness

A refers to questions regarding a respondents current and desirable involvement inITS, and B refers to level of successfulness as experienced successful cooperativesolutions regarding VRUs and the desire for such solutions in future.

The respondents answered the survey by indicating the choice that best expressestheir opinion about the questions below by choosing on one of the five choices. Thelevel for each question were: 1. Minimum; 2. Some; 3. Medium; 4. Many; 5.Maximum, corresponding to the Likert scale.

1. This question belongs to dimension A

a) What is the quantity of the research performed in the area of ITS/Co-operative systems by your company?

b) What is the quantity of the research that your company should performin the area of ITS/Cooperative systems?


a) How would you describe your company‘s involvement in well known ITSprojects?

b) How do you see this involvement in the future?

3. This question belongs to dimension B

a) Overall, how many of the ITS projects regarding VRUs gave satisfyingresults when it comes to the implementation?

b) How many of the successful systems from those projects would you liketo be commercialized?


a) How many of those projects have presented solutions for increasing VRUssafety?

b) How much would you like the VRUs safety to be increased with thoseprojects?


24

4.6. GAP ANALYSIS WITH SURVEY

a) How many of those projects have presented solutions for increasing VRUssafety with the usage of wireless technologies?

b) How much of the solutions for increasing VRUs safety would you like tobe resolved by wireless communication?


a) How many of those projects have presented solutions for increasing VRUssafety by using NDs (Smartphones)?

b) How much of the solutions for increasing VRUs safety would you like toinclude NDs (Smartphones)?


a) How many of those projects (with wireless solution) have used IEEE802.11p and IEEE 802.11a/b/g types of communication?

b) How much would you like those solutions regarding VRUs safety to in-clude IEEE 802.11p and IEEE 802.11a/b/g ?


a) How much is your company investing and investigating in the cooperativesolutions regarding VRUs?

b) How would you evaluate the need for more investment and investigationregarding cooperative solutions for VRUs?

Two sets of questions were posed alternately. The first set of questions wasreferring to a current situation in the area of ITS cooperative systems. The sec-ond set of questions was related to future plans, wishes and expectations from therespondent’s point of view. The average value for each question in every pair ofcorresponding questions was calculated.

The survey was sent with email to all respondents, as a web link to an interactivesurvey created with Google docs. Due to the time limit of this master thesis project,all calculations were performed after 30 received responses. From these 30 respon-dents, 21 were employees within the ITS area, e.g., vehicle manufacturers, researchlaboratories and organizations. Remaining 9 was engineering master students.

The results are shown in following table:

Question Mean value (perceived) Mean value (expected) ∆1 2.57 3.25 0.682 2.00 2.20 0.203 3.50 3.10 -0.404 2.50 4.50 2.005 2.30 3.90 1.606 2.50 3.40 0.907 4.10 4.70 0.608 2.20 3.60 1.40

25


The results were represented as a graph for the visualization of the actual gaps,shown in figure 4.2. On the x-axis 8 questions from each set are represented, op-posing 5 levels of the Likert scale on the y-axis. As it can be seen, the blue curve isreferring to current situation and the red curve is referring to the desirable situationin future. The first two questions were of an introducing character with the purposeof give an insight of the respondent’s involvement in ITS projects and that area ingeneral. As shown from question 3, some projects that gave good results imple-mentation wise was not to wanted as commercial products in future. Results ofquestions 6 and 7 state that ND were not incorporated in many projects regardingVRUs, whereas IEEE 802.11a/b/g/p wireless standards were more present.

Figure 4.2. Result analysis of the conducted survey - using the Likert scale.

The biggest gap exists in the issues concerned in questions 4, 5 and 8. Question4 is showing the lack of research projects for increasing the VRUs safety. Question5 is showing that even if there is a research conducted for increasing VRUs safetyit is not based on wireless communication solutions. Finally, question 8 shows thatthere is a need for a bigger investment in the area of cooperative solutions for VRUs.

4.7 Summary and complete analysisEven if there exists and have existed many ITS projects that in some sense havetouched the area of VRUs, there have not been many at all that explicitly focus onthe issue, especially regarding wireless communication by using Wi-Fi or other non-sensor solutions. Particularly, not much have been investigated in Europe comparedto Japan for instance. But all research that actually have been looking into coop-erative solutions for VRUs have used some type of wireless communication. Thisclearly implies that cheap and efficient (possibly long range, short reaction time,high accuracy and full functionality under all possible circumstances) VRU solutions

26

4.7. SUMMARY AND COMPLETE ANALYSIS

might not be found in independent use of sensors and cameras, but instead usingcooperative solutions. It is also notable that none of the projects that developeddevices with dedicated wireless communication, did so with IEEE 802.11p.

Regarding a hardware or software modification to a smartphone to make itcompliant with IEEE 802.11p, it was concluded that it is not feasible. At leastnot from a economical or deployable point of view. There only exists a few IEEE802.11p specific cards, and none of them can physically be used in a smartphone.There are software drivers that can enable Atheros based chipsets to use IEEE802.11p, but there are no such chipsets compliant with smartphones. This clearlyshows that the industry must develop new hardware to make this work. It mightnot be difficult to develop such hardware, but probably it will be more difficult toconvince the industry to do that considering the main drawback explained earlier(no power save mode which leads to battery drainage).

The survey gave a clear proof that the choice of analyzed area was valid, sinceVRUs in the context of cooperative ITS solutions are lacking attention. The majorgaps found (question 4,5 and 8) describes a desire for cooperative solutions (wire-lessly) for VRUs, to actively increase their safety and in the end put more financialinvestment into that type of research.

The complete analysis leads to an hypothesis of how to solve the technologicalgap for smartphones and IEEE 802.11p with the aim of increasing VRUs safety intraffic. The hypothesis is formulated as:

Hypothesis 1. To close the technological gap between smartphones that have nohardware/software for using the IEEE 802.11p protocol and V2V/V2I communica-tion in urban areas, a relaying RSU can be used. For all types of applications thatinvolves pedestrians to be part of a VANET, a smartphone sending data with IEEE802.11a/b/g to a RSU that in turn can relay the data to surrounding vehicles withIEEE 802.11p without significant delay, will prove that this kind of data-exchangecan be a feasible concept for further research and deployment.

The background to the hypothesis is that instead of forcing the smartphoneindustry to start developing new hardware that supports IEEE 802.11p and maybewait many years until they hit the market, a fast and relatively easy solution is given.The believed strength of the hypothesis is that there is no need for any difficulthardware/software changes in neither the vehicles nor the RSUs. For smartphones,there is only a need for a simple installation of a new application.

4.7.1 Needs and requirementsWith hypothesis 1 in mind, certain requirements for potential users and systemsmust be described. The typical user is most likely a pedestrian, but can also be acyclist/motorcyclist. On the other hand, the vehicle driver is also seen as a userin this context because he/she must be able to interpret the data and be awareof surrounding VRUs. The system must be able to extract data from smartphoneusers and forward them fast and reliably to vehicles trough a RSU. The data itself

27


needs to be displayed for drivers in a satisfactory way, preferably as a map view. Allfundamental needs and requirements from both a user- and a system perspective ispresented in following tables:

Smartphone user need Description

Participate in VANET Users must be able to be part of a urbanVANET to make drivers aware of there ex-istence.

Share geographical loca-tion

Users must be able to share their GPS coor-dinates to all vehicles in a VANET.

Vehicle user need Description

Get hold of VRU data The vehicle user must be able to get hold ofsurrounding VRUs existence.

Interpret incoming data Interpret the incoming data sent from smart-phone users, preferably in a visual context,to be aware of there relative positions.

System need Description

Reliable The system must offer a reliable and stablecommunication. Communication congestioncannot be present.

Safe The system must offer a solution for VRUs toincrease the safety in urban traffic situations.

Economical The system cannot cost a user and manufac-turer too much when buying/deploying it ina large scale.

28

4.7. SUMMARY AND COMPLETE ANALYSIS

Smartphone user require-ment

Description

Smartphone Must use the Android platform and haveGPS and Wi-Fi enabled. The power usagecannot be extensively used so the applicationcan maintain for a relatively long time (morethen a few hours at least).

Application An Android application that can get hold ofand forward GPS-data to a RSU in real-time.

Vehicle user requirement Description

In-vehicle equipment A car with installed in-vehicle equipmentable to receive packets form RSU with IEEE802.11p.

In-vehicle software Software that can extract data-packets sentfrom RSUs (which originates from the smart-phones) and display the information in a mapview.

System requirement Description

Nomadic device A smartphone using the Android platform.RSU RSU with both a IEEE 802.11a/b/g and

IEEE 802.11p cards.Access point Inside the RSU to create a WLAN.In-vehicle system Computer system able to handle GPS and

receiving equipment.In-vehicle GPS GPS for the vehicles own position.Receiving equipment Antenna which is connected to the in-vehicle

system, for receiving broadcasted packetssent from the RSU.

Software Above described software for smartphone-and vehicle user. Server system in the RSUthat can handle multiple connected smart-phones and relay data packets out to vehiclesby broadcasting them via IEEE 802.11p.

Detailed system requirements are found in chapter 5.

29

Chapter 5

Implementation

This chapter describes an implementation developed, with the proposed hypothesisin chapter 4 as background (which was formulated according to the results fromthe gap analysis). The implementation is a proof-of-concept and not a completed,deployable product. The aim was to show whether the hypothesis could be verifiedas a cooperative solution for VRUs, that is to investigate wireless communicationsregarding traffic safety in the perspective of feasibility and safety impact for VRUs.

5.1 Overview

The main idea for the wireless solution for VRUs was to use a nomadic device,preferably a smartphone, that could communicate with surrounding vehicles via aRSU or directly. The aim was to inform drivers about a VRUs location so that thevehicle can keep track of them and by certain computations decide if there is anyrisk of collision or equivalent.

V ehicleOO

IEEE 802.11p

Nomadic deviceW LAN/IP

// RSU

V ehicle

��

IEEE 802.11p

31

CHAPTER 5. IMPLEMENTATION

By using WLAN as mean of communication to the RSU, and then IEEE 802.11pfrom the RSU to vehicles, a bridge for the lack of compatible protocols betweennomadic devices and vehicles is achieved. The conceptual communication modelis depicted in the diagram above (the arrows describe the chosen communicationmean).

5.1.1 Hardware setupAny smartphone using the Android 2.1 (or higher) platform can be used as a NDin the setup, and during development several Samsung Galaxy tabs were used. TheRSU consisted of an AP (Access Point) and a customized build unit containinga small computer running Linux (Ubuntu) and a transmitter antenna. Inside thevehicle there was a receiver unit, also consisting of a smaller computer togetherwith a GPS and an antenna. The RSU and the receiver unit used the same type ofsystem boards and antennas.

Nomadic device

Smartphone

Type InformationName Samsung Galaxy TabOperating system Android 2.2.1CPU Samsung Exynos 3110, ARM cortex A8

1.0 GhzStorage 2 GBMemory 512 MBConnectivity GSM / GPRS / EDGE, Wi-Fi

802.11b/g/n, Bluetooth 3.0Power 4000 mAh battery

Road side unit

System board

Type InformationName Alix3d2CPU 500 Mhz AMD Geode LX800Storage CompactFlashMemory 256 MB DDR DRAMOther Running Linux operating system. Us-

ing a modified madwifi driver from q-free,branch of driver developed for CVIS forIEEE 802.11p

WLAN card

32

5.1. OVERVIEW

Figure 5.1. The RSU.

Type InformationName UNEX DCMA-86P2Card type miniPCI, Atheros AR5414A-B2B

AntennaType InformationName MobileMark ECOM6-5500Antenna type Omni-directional 6dBi gain

In-vehicle receiver unit

System board

Type InformationName Alix3d2CPU 500 Mhz AMD Geode LX800Storage CompactFlashMemory 256 MB DDR DRAMOther Running Linux operating system. Using

ath5k driver to enable IEEE 802.11p com-munication.

AntennaType InformationName MobileMark ECOM6-5500Antenna type Omni-directional 6dBi gain

33


Vehicle GPS

Type InformationName uBlox EVK-4TGPS antenna Smarteq minisat

Figure 5.2. The in-vehicle receiver unit. (1) system board, (2) antenna, (3) connec-tor, (4) power cable and (5) in-vehicle GPS.

Figure 5.3. The in-vehicle receiver unit system board. (1) COM-port, (2) powersource, (3) RJ45 network cable and (4) GPS cable.

34

5.1. OVERVIEW

5.1.2 Software setup

The implementation required a set of different software components, where someof them were actively interconnected. The package of developed software for thisproject was called GeoLoc, which consisted of a client, server and an in-vehiclecomponent. The conceptual setup is described as follows:

GeoLoc Client // GeoLoc Server =⇒ VTEC Modules // In-vehiclesoftware

The GeoLoc Client is an Android application which has the ability to connectto a RSU with TCP/IP and forward real-time GPS-data. The middle componentconsists of two separate sub-components: a GeoLoc Server and a set of VTECmodules. These modules are created using MBLMT, a tool developed at VTEC.A third software component was also developed: the in-vehicle software. Thiscomponent simply receives all data from the server/VTEC modules and displaysit on a screen or equivalent. The core part of this component was coded usingMBLMT.

As a brief overview, the GeoLoc client fetches GPS-data and connects to theGeoLoc server, inside the RSU. The server collects all data, which is sent via TCPconnections and make a check if it is relevant to forward the data into the VTECmodules which in turn can perform IEEE 802.11p communication. If so, it sendsthe data with UDP, and finally it is broadcasted via IEEE 802.11p and displayedinside receiving vehicles.

MBLMT

MBLMT create modules and interconnects them, e.g., if one wants to receive UDPmessages and display the data in a vehicles data display, MBLMT is then used forcreating certain modules that are able to perform these tasks. These modules arethen connected inside the tool and a final single software is produced. The mainuse of MBLMT is to create modules that could send and receive data with IEEE802.11p with the given hardware.

MBLMT is written completely in C++ and is open for creating customizedmodules. For the GeoLoc implementation some modifications of the core librariesof MBLMT was needed, and also a few completely new type of modules had tobe developed. The modification was needed because some parts was written forLinux exclusively, and the developing environment was MS Windows at the time.The new developed modules was needed to correctly extract data from a UDPpacket containing a GeoLoc specific message, and forward these in right order tothe in-vehicle software. A fix for converting big-endian to/from little-endian wasalso included.

35


Figure 5.4. A screenshot of the MBLMT graphical user interface and the intercon-nection of three modules.

5.2 GeoLoc ClientFor the implementation, an Android application was developed. The idea was todevelop an application that could send GPS related data (e.g values for longitude,latitude, speed, time) from any smartphone to a RSU. The data will then be for-warded to all drivers in the vicinity. There are different smartphones and hand-helddevices on the market, such as Android- and Apple devices, and the assumption isthat if one can show that it is possible to develop the specified application for oneplatform, it is then feasible to convert it to the other.

The GeoLoc client was completely developed in Java. The graphical user inter-face was not prioritized, hence only a simple window of fetched GPS data and aconfiguration field is present.

5.2.1 Android platform

Android is an open source, Linux-based operating system for smartphones andtablets, developed by Open Handset Alliance which was led by Google [55]. TheAndroid community consists of many developers, and by February 2012 there wasmore than 450,000 applications available [55]. The current version of the platformis 4.0 which was released in 2011.

The main hardware platform for Android is the ARM architecture, but thereis also support for x86 and MIPS architectures [55]. The kernel is Linux-basedand the applications are running on an application framework which includes Java-compatible libraries. Android uses the DVM (Dalvik virtual machine) which is the

36

5.2. GEOLOC CLIENT

Figure 5.5. A screenshot of the GeoLoc client application.

actual software that runs Android applications in a device. The main difference ofJava Virtual Machines and DVM is that the latter is register-based (like an ordinarycomputer) instead of stack-based [57]. The platform also gives relatively easy accessto a device’s hardware, and support for a great variety of different media/sensors andother features are available. For example, Android have support for Wi-Fi, LTE,NFC, WiMAX, Bluetooth, GSM/EDGE, UTMS, GPS, multitasking and tetheringamong many [55], [56].

5.2.2 Requirements

The requirements, both functional and non-functional, were identified to be:

Functional requirement Input Output

Fetch GPS coordinates None Double long,Double lat

Fetch GPS accuracy None Double accFetch GPS speed None Double speedFetch GPS timestamps None Double

time_stSend fetched data to RSU long, lat, acc,

speed, time_stInformationPacketiPack

where InformationPacket is a data structure for the fetched data.

37


Non-functional requirement Description

Availability At least send data as long asthere is a connection to anyAP.

Accessibility Easy to use application, notechnical background neededfor use.

Reliability Only send data to RSU thatare within a satisfactory accu-racy: 15-30 m.

Interoperability Be able to communicate withRSU.

Scalability All Android based devices, us-ing platform 2.1 or newer canuse the application and sup-port for multiple devices to beconnected simultaneously.

5.2.3 Logical architecture

The Android platform gives access to the GPS provider via a collection of Javaclasses, inherited from the class package android.location: Location, Location-Provider and LocationListener. Using these classes, it is possible to createobjects that directly reads geographical locations from the GPS provider, and re-lated data such as speed, accuracy and UTC time stamps. The concept is to setupa LocationManager object that works as a communication manager between theapplication and the GPS, and a Location where all GPS data can be stored. Nextis to create a LocationListener object that listens for updates from the GPS.When a user moves and the coordinates change, this update will be present withinthe Location object and the LocationListener can perform certain operationsdepending on what updates are present.

The GeoLoc client consists of two logical components: the GPS- and Networkcomponent. The GPS component fetches GPS data as described previously, andthe network component establishes communication with a GeoLoc server for datatransfer. The procedure is very simple; when the application starts and initialize, athread for fetching GPS-data starts. When the user want to be a part of the trafficanother thread starts, which is a networking thread. When executed, a socketconnection is created and tries to connect to the server. If connected, the clientstart sending GPS-data. The procedure is depicted in following flow chart:

38

5.2. GEOLOC CLIENT

initializeapplication

fetchGPS-data

createpacket

send dataand sleep500 ms.

is clientcon-

nected?

closeconnection

no

yes

As long as there is a connection, the client continue sending packets. Becauseof fast moving VRUs, i.e. cyclists, the sending frequency is set to 5 Hz. If lowerfrequency, it might be too late if a high speed cyclist approaches an intersection,and if a higher frequency is used it might overload the server.

Pseudo code for GeoLoc client part that handles GPS-data and networking:

ipack ← nullpacknr ← 0socket.connect()while socket.isConnected() do

ipack ← GPS.getGPSData()socket.send(ipack + packnr)packnr ← packnr + 1sleep(500)

end whilesocket.close()

39


5.3 GeoLoc Server

The server application consists of two separate modules: the server part and theVTEC modules. The actual server part was completely developed in Java and usesmulti-threading. This means that a new thread starts for every connecting device.This is valuable in order to get a more structured overview of all incoming data,and all threads saves a number of the most recent packets into a global HashMapdata structure in case there is a need for re-using/re-sending packets.

For all incoming packets, a relevance check is performed (if the VRU is nearenough to be considered as a potential element of danger) and depending on theresult, the packets are sent via UDP to a set of modules that broadcasts the datawith IEEE 802.11p to all surrounding vehicles. Before sending to the modules,two additional data values are inserted into a data packet called Information-PacketExtended: the distance between the VRU and the RSU, and a uniqueidentification number for that specific VRU. For details, see section 5.3.2.

The GeoLoc server is set to handle 30 connecting clients, but of course thiscould easily be changed. The assumption is that displaying more then 30 VRUs ina vehicle’s display unit, it might be very difficult to get an adequate overview of thecurrent traffic situation.

5.3.1 Requirements

The requirements, both functional and non-functional, was identified to be:

Functional requirement Input Output

Receive GPS-data iPack iPackExtendedCompute distance fromRSU to ND

Double long,Double lat

Double nd-Delta, DoublendID

Forward data to VTECModule

iPackExtended iPackExtended

The server collects all received data into objects of type informationPacke-tExtended which is a standard informationPacket but with some additionaldata fields: ndDelta, and ndID. These additional two doubles are calculated inthe server and represents the distance between the RSU and the VRU, and the IDof the VRU, respectively.

40

5.3. GEOLOC SERVER

Non-functional requirement Description

Availability Only broadcast data to vehi-cles when necessary, e.g whenVRUs are in a specified radiusfrom the RSU.

Accessibility None.Reliability Create a thread for every in-

coming client and handle theirdata separately.

Interoperability At least be able to communi-cate with the module to senddata with IEEE 802.11p to ve-hicles.

Scalability Up to 30 clients should be ableto connect to a single server.

5.3.2 Logical architecture

The server creates a thread for each connecting client. A thread will listen toincoming data, collect it into informationPacketExtended objects and forwardthem to the vehicles. Note that before forwarding any data to vehicles, a check isperformed whether the distance between the VRU and RSU is in a specified range.This check is necessary to avoid overloading. The distance, specified as nDelta, ismeasured in meters and is computed according to the Haversine formula [58]:

nDelta = 2R arcsin

(√sin2

(φ1 − φ2

2

)+ cos(φ1)cos(φ2)sin2

(ψ1 − ψ2

2

))(5.1)

where φ1, φ2 is latitude, ψ1, ψ2 longitude and R the radius of earth. Formula 5.1is used for calculating distances between two longitude and latitude coordinateson a sphere. The formula is well suitable to use in the implementation becausethe servers location is static: the RSU location will not change, hence only thecoordinates for a VRU is needed as external input.

Each connecting device will get a unique identification number as well. In theprototype implementation a simple iterator is used to set the identity number in-creasingly as integers. In a deployable version this process of creating identificationidentities should be more sophisticated due to security reasons. It would then bepreferably if there were no logical way to derive a smartphone to its identity number.

41


threadstarts

receivedata

nDelta <X meters?

senddata tomodule

savedata toarray

yes

no

The flow diagram depicts how the server behave when an incoming client con-nects, and a new thread dedicated to that client starts. In the step “save datato array”, the data is inserted into the globally reachable HashMap data structurewhich all threads share.

The second component within the RSU, the set of modules, is a chain of smallermodule blocks performing certain tasks in receiving, decoding, encoding and sendingdata. The complete chain of modules are:

UDPReader // TopoBroadcastRequestDecoder // NetworkSender

where the UDPReader simply receives incoming UDP-packets to a specified port,the TopoBroadcastRequestDecoder handles the conversion to comply with the IEEE802.11p protocol, and the NetworkSender simply sends the UDP-packets over IEEE802.11p. The corresponding pseudo code for the server Main-method:

while socket.IsListening() doif socket.ConnectionStarts() then

thread.Run()end if

end whilesocket.close()

42

5.4. IN-VEHICLE SOFTWARE

and for every thread:

while connection.IsAlive() doV RUdata← connection.ReadDatadelta← distance(RSUlocation, V RUlocation)ID ← IDfunction()update(V RUdata, delta, ID)IpackTable.add(connection.adress(), V RUdata)if delta < criticalDelta then

broadcast(V RUdata)end if

end whilecommection.close()

As long as there is a TCP-connection with a device, VRUdata is collected andupdated with additional variables. The IpackTable is the data structure whichsaves packets and sort them accordingly to the connecting devices’ IP-address. Thevariable criticalDelta is a pre-defined max value for the longest distance betweenthe RSU and any approaching VRU. This measurement can be used for prioritizingpackets from VRUs accordingly to how near they are (higher priority for the closestVRU).

5.4 In-vehicle softwareThe requirements for the in-vehicle software was only to be able to display datasent from a smartphone in a satisfactory way. The GeoLoc package allows sendingGPS-data and additional information to the vehicle, and representing this data canbe done in several different ways. Therefore two different setups of the GeoLocpackage in-vehicle software were developed.

5.4.1 Setup 1: Non-graphical version

The first setup displayed incoming data in text-only windows, called ListViews inMBLMT. The NetworkReader receives IEEE 802.11p traffic and forwards it to amodule called C2XRequestDecoder which ins turn processes the incoming data tobe read as regular UDP-packets.

NetworkReader // C2XRequestDecoder // DataFilter

ttDataDecoder // ListView

43


The DataFilter module was developed as a part of the implementation. Thefunctionality of DataFilter is simply to make sure that packets coming from differentdevices are displayed separately. This is done by checking the unique ID every devicegets from the GeoLoc server and adding it into the broadcasting UDP-packets. Forall packets with same ID, a DataDecoder module extracts all data such as longitude,latitude, speed etc. and forward them to the ListView which display all data.

Figure 5.6. A screenshot of the MBLMT module called ListView.

The ListView simply displays all data sent from the GeoLoc Server.

5.4.2 Setup 2: Graphical versionThe other setup was using a map representation of all connecting devices. For thisto work, some changes to setup 1 was made:

NetworkReader // C2XRequestDecoder // DataFilter

ttDataDecoder // GPSMuxer // MapView

Instead of forwarding all extracted data from UDP-packets to a ListView, thevalues for longitude and latitude were sent to a module called GPSMux. Thismodule was also developed for this particular implementation and converts twodoubles to a GPS fix (a data entity containing the longitude and latitude). Thisis necessary because the MapView module needs GPS fixes as input to be able todisplay a VRU on the map. The MapView was then customized so multiple VRUscould be displayed. All VRUs were displayed as red dots on the map.

The idea was to make a driver aware of surrounding VRUs in a easy and under-standable way. In setup 1, with text-only representation it is impossible to get a

44

5.5. ND AND RSU COMMUNICATION

visual understanding of surrounding VRUs, only a relatively large collection of datais seen. As for a driver, one only wants to be aware of any VRUs position relativeto herself, thus a map of the current vicinity with real-time updates of all connectedentities in the VANET is probably the best choice.

Figure 5.7. A screenshot of a MapView displaying two moving VRUs.

5.5 ND and RSU communication

5.5.1 Protocol

The client-server communication is done with the TCP (IPv4) protocol. A prototypeclient-server software package using UDP and TCP respectively, was developed andanalyzed. The conclusion was that with TCP it will be easier to control the trafficand handling the clients in the server, compared to using UDP. On the other hand,UDP is probably better in a real application because it does not need to bind a socketfor the communication using handshakes and error-control (which may produce adelay).

5.5.2 Availability

In the GeoLoc prototype, only a manual connection can be made between the NDand the RSU. This means that the user needs to press a button in the GeoLocclient to start a connection. The choice of having a manual connection procedure isdue to debugging. In a real deployable product, there can be a variety of differentapproaches on how to connect the NDs. The Android platform provides access tothe Wi-Fi card in a way that one can force the application to automatically connectto a certain open WLAN by using the WiFiManager[56]. It then depends on howthe RSU infrastructure is going to be structured, if all RSUs should have a standardIP to connect to or if there should be unique IPs according to some RSU list.

45


It is important to note that it is required to use an open WLAN for the RSU inorder to let anyone to connect. This clearly give rise to severe security issues whichis discussed more in detail in chapter 7. These issues belongs to future work and isout of scope for this thesis.

5.6 Data protocols

When all GPS related data is fetched from the client, it is inserted into a specificdata structure called InformationPacket. The structure was created by a simpleJava class containing a set of doubles. The complete data protocol was specified to:

1 public class Informat ionPacket {2 Double ndLongitude ;3 Double ndLat i t iude ;4 Double ndSpeed ;5 Double ndAccuracy ;6 Double ndTimestamp ;78 /∗ Get and s e t methods ∗/9 . . .

10 } ;

On the server side, another protocol is used: InformationPacketExtended.This is necessary because the server will compute a set of new variables, dependingon the data from the clients, which will be forwarded to the vehicles. The extendedprotocol is specified to:

1 public class InformationPacketExtended {2 Double ndLongitude ;3 Double ndLat i t iude ;4 Double ndSpeed ;5 Double ndAccuracy ;6 Double ndTimestamp ;78 Double ndDelta ;9 Double ndID ;

10 /∗ Get and s e t methods ∗/11 . . .12 } ;

The variable ndDelta is the distance between the RSU and the client, andndID is simply a given identification value for each nomadic device.

46

5.7. SUMMARY OF DEVELOPED SOFTWARE

5.7 Summary of developed softwareThe GeoLoc package contained following components which was developed by theauthor:

• GeoLoc Client, Android application;

• GeoLoc Server, Java server for handling connecting smartphones;

• MBLMT module DataFilter, filtering incoming data according to ID;

• MBLMT module DataDecoder, extracts all data sent from the server to in-vehicle software;

• MBLMT module GPSMuxer, converts two doubles to a GPS fix.

All other software, namely the rest of the MBLMT modules, was already createdby VTEC.

5.8 Field operational test and measurementsThis section presents all measurements and tests of the GeoLoc package prototype.Emphasis has been on congestion- and availability assessment, because it is believedthat these two factors are most important in any traffic situation: preferably nocongestion to get a constant information flow, and available connections as longthere is physically possible.

5.8.1 Availability: Range of connectionMeasurements of the communication according to different distances within andoutside the WLAN range of the RSU was made. The measurements were conductedby walking with a smarthphone running the GeoLoc client, towards and away fromthe RSU.

With a frequency of 5 Hz of sending packets from the GeoLoc client, no differ-ences were measured within the range of the RSU. When the client moved outsidethe range, the connection was immediately closed. When moved back into range itimmediately connected with no differences in received packets in the in-vehicle soft-ware. The measured WLAN range was approximately 30 m. until the connectionwas lost.

5.8.2 Congestion: Frequency of receiving packetsA number of measurements of the receiving frequency of data packets from theGeoLoc client was conducted. The client was tweaked with four different packetsending frequencies and the number of actual received packets were logged in thein-vehicle software. During the measurements, noise packets were intercepted bythe RSU to simulate some VANET traffic. Following results were given:

47


Frequency Received packets500 ms (2 packets / sec.) 1

2 *3

200 ms (5 packets / sec.) 4 *5 *6

100 ms (10 packets / sec.) 567 *8 *9 *1011

50 ms (20 packets / sec.) 7891011 *12 *13 *14 *1518

* this number of packets was significantly more commonly observed (more then 50% of the time).

Above data was given from sending and receiving packets during a time frameof 5 minutes. The second column shows all logged number of received packets persecond.

5.8.3 Field operation test

A FOT (Field Operational Test) was performed. A car, one RSU and three NDswere used in a dummy scenario in order to simulate important traffic situationswhere the GeoLoc implementation could be useful. The tests were conducted atVTEC and in the surrounding parking lot area. The RSU was connected to aregular 12V power source from the VTEC garage with an extension cord. Thevehicle then went back and forth in a radius of approximately 50 meters from the

48

5.8. FIELD OPERATIONAL TEST AND MEASUREMENTS

RSU. The NDs with installed GeoLoc clients were handed out to testing personalwho walked around in different directions toward/forward the RSU.

Figure 5.8. In-vehicle hardware used in FOT, receiver unit.

Figure 5.9. In-vehicle hardware used in FOT, receiver unit connected to a displayunit (laptop).

In the FOT a typical laptop was used as a display unit. It was connected to thereceiver unit which had an antenna and a GPS connected. The setup was the sameas described in chapter 5.

49


In this scenario a VRU walked along a building, not in the eye-sight of the driver.The VRU was detected around 30 meters away from the RSU. This was the case forall three VRUs, from all directions. The vehicle GPS was a bit slow before findingsufficient many satellites (around 5-10 min.), but the NDs got good accuracy undera minute. The test showed that there were no experienced delay or difficulties inthe communication between all participants.

Figure 5.10. The red dot in the top (a VRU) was completely out of sight for thedriver, but detected around 30 meters from the RSU. The RSU was located at thecorner of the building.

The display unit used a map view to show all VANET participants (except theRSU). The red dots are all connected VRUs using the GeoLoc client and the bluedot with an arrow shows the vehicles position.

5.9 Security aspects

All tests performed showed that the implementation did fulfill the fundamental re-quirements, such as being able to provide multiple VRUs’ GPS-locations to vehiclesin the vicinity (which all are dynamically connected to the RSU WLAN). It alsoshowed that some of the major obstacles were solved, such as the issue with IEEE802.11p and NDs, and providing reliable VRU detection in usually difficult trafficsituations. On the contrary, a severe security issue arises due to the usage of openWLANs. This is a real dilemma because firstly, it is impossible to use an encrypted,closed WLAN due to practical issues: every user needs to type and send a passwordevery time when connecting to a RSU. This procedure then opens up for even more

50

5.10. VRU AWARENESS MESSAGE

issues, such as possible delay due to security protocols and the key managementin the RSU. Secondly, when using an open WLAN it is completely open for any-one to connect and possibly perform DoS-attacks, spoofing or Man-in-the-middleattacks[59]. These type of network security attacks may have serious consequencesto society if performed.

The lack of satisfactory solutions for the security of the implementation arethen the main drawback, and there is no evidence that such solutions might beavailable in the near future. The authors of this thesis believe that there is a strongconnection between any possible security solution, and technologies for enablinghigh speed communication. The reason is that even if an optimized and perfectlyconstructed authentication protocol or encryption algorithm were designed, it stillcreates additional information that needs to be transmitted in a VANET.

5.10 VRU Awareness MessageAnother finding during the implementation phase is the probable need for an ad-ditional standard message in V2V communication. The previously described CAMand DENM message standards are not customized for VRUs, lacking of VRU spe-cific data such as classification type, VRU behavior patterns etc. that might beuseful in future implementations. The proposed message will be called VRUAM(VRU Awareness Message).

This VRUAM will work as DENM messages, which is giving the notificationabout sudden events. Similarly, VRUAM will give a notification about suddenVRUs in a specified dangerous radius for the vehicle. Drivers will be informedabout their presence, giving them enough time to react in the right way. Frequencyof the message sent should vary depending on the type of the VRU: pedestrian,cyclists or motorcyclist. It should vary in the range of 1 Hz to 5 Hz (1 s to 62 ms).This was concluded from analyzing the ETSI standard specification of the VANETmessaging types [26] where the CAM and DENM message are sent with 1Hz (5Hzare fixed for the motorcyclists). The frequency proposal is also based on the averagepedestrian movement speed, which is approximated to 1.2 m/s [27].

The actual VRUAM should be based on similar structures as the Informa-tionPacket and InformationPacketExtended described in section 5.6.

51

Chapter 6

Conclusion and future work

During the gap analysis, it became clear that this type of assessment heavily reliedon performing surveys or interviews. Using literature studies alone was not sufficientto create an adequate analysis. To be able to collect data about expected anddesired outcomes in the field, it was required to ask involved people, which in turnwas completed using a survey.

There are many possible ways to present the findings in a gap analysis, and theLikert scale served well in providing a visual representation by using numbers. Fromthe results of the survey it is clearly shown that both dimensions (involvement andsuccessfulness) consisted of gaps. The major gaps found, concerned the low level ofinvolvement of the wirelessly based projects regarding VRUs safety. Also, there is asignificant lack of investment regarding cooperative solutions today. One suggestionto why this is the case is that, even if ITS has more than half a century as beinga field of research, it is only the last decade where more powerful and efficientwireless/cooperative technologies have been developed.

To use smartphones in traffic safety then seems obvious, so at first sight itseems a bit strange that not much work have been done in the area. On the otherhand, today’s smartphones and current platforms are still developing; Android andIphone are relatively young technologies, but this is most likely the future for ITSand VRUs.

Another way to approach the problem of incompatible technologies could havebeen to investigate further how to actually modify the smartphone to make it workwith the IEEE 802.11p protocol. This would most likely lead to a hardware changein the device. A firmware tweak would also be possible for some devices, but eitherway, the smartphone industry must be involved in ITS and make modifications totheir products. With the given hypothesis in this report, no such involvement isnecessary. On the other hand, one can argue that the involvement of the smartphoneindustry (and make them convinced to modify their hardware) is good for ITSstakeholders.

According to the results in the conducted FOT and all other measurements,this implementation clearly shows that there are no arguments for not continuing

53

CHAPTER 6. CONCLUSION AND FUTURE WORK

to develop it further and make it a deployable product. The main goal to increaseVRU safety in traffic is then achieved.

The strongest dependencies are in accurate GPS-signals and strong AP-rangesfor RSUs. Therefore, in a software engineering point of view, there are some furtherdevelopments to do (handle more users, adding more computations in server to getvaluable data, advanced risk collision algorithms etc.), but it is only limited bythe hardware. Using IEEE 802.11p directly in a ND is believed not to be feasiblesimply due to battery drainage and occupying the already used VANET frequencytoo much.

The identified C-ITS area, cooperative solutions for VRUs, consisted of gapswhich the literature study and survey illustrated. It is now shown that there is aneed for cooperative solutions, using wireless technology. The GeoLoc implementa-tion is the starting step in closing this gap. More work needs to be done in future,but the core concept is now presented.

54

Bibliography

Books, articles and publications[1] European Commission: Directorate-General for Energy and Transport, A sus-

tainable future for transport, 2009.

[2] Forouzan, B. TCP/IP Protocol Suite, McGraw Hill Higher Education, 4th ed.2004.

[3] Hartenstein, H, Laberteaux, K. VANET: Vehicular Applications and Inter-networking Technologies, Jihn Wiley and Sons, 2th ed. 2010.

[4] K. Bandyopadhyay, S. K. Chaulya, P. K. Mishra, Wireless Communicationin Underground Mines: RFID-Based Sensor Networking, Springer 2010, NewYork, p.273.

[5] Tse,D, Viswanath, P., Fundamentals Of Wireless Communication, CambridgeUniversity Press, 2005

[6] IEEE, Part 11: Wireless LAN Medium Access Control (MAC) and PhysicalLayer (PHY) Specifications - Amendment 6: Wireless Access in Vehicular En-vironments, 2007, Available: http://standards.ieee.org/about/get/802/802.11.html [2012-01-24].

[7] ETSI - European Telecommunication Standard Institute [www].Available:http://www.etsi.org/WebSite/AboutETSI/AboutEtsi.aspx[2012-03-06].

[8] ETSI, Intelligent Transport Systems (ITS) - Communications Architecture,ETSI EN 302 665 V1.1.1, 2010, Available: http://www.etsi.org/deliver/etsi_en/302600_302699/302665/01.01.01_60/en_302665v010101p.pdf[2012-01-18].

[9] ETSI, Intelligent Transport Systems (ITS);Vehicular Communica-tions;Basic Set of Applications;Part 2:Specification of CooperativeAwareness Basic Service,ETSI TS 102 637-2 V1.2.1,2011 Available:http://www.etsi.org/deliver/etsi_ts/102600_102699/10263702/01.02.01_60/ts_10263702v010201p.pdf [2012-02-01].

55

BIBLIOGRAPHY

[10] ETSI, Intelligent Transport Systems (ITS);Vehicular Communications;BasicSet of Applications;Part 3:Specifications of Decentralized EnvironmentalNotification Basic Service, ETSI TS 102 637-3 V1.1.1, 2010, Avail-able: http://www.etsi.org/deliver/etsi_ts/102600_102699/10263703/01.01.01_60/ts_10263703v010101p.pdf [2012-02-01].

[11] Sjöberg K., Standardization of Wireless Vehicular Communications withinIEEE and ETSI, IEEE VTS Workshop on Wireless Vehicular Communica-tions, Halmstad University, Sweden, November 2011.

[12] Jan Erik Hakegard, Bengt Holter, Isabella Tardy, Terje Moen. Assessmentof wireless technologies, European Commission; DG Information Society andMedia; Smartfreight Project.

[13] Daniel Jiang, Luca Delagrossi. IEEE 802.11p: Towards an International Stan-dard for Wireless Access in Vehicular Environments, Mercedes-Benz Researchand Development North America, Inc., IEEE 2008.

[14] Parasuraman, Zeithaml & Berry, SERVQUAL: A Multiple-Item Scale for Mea-suring Customer Perceptions of Service Quality, Journal of Retailing, Spring1988, pp. 12-40.

[15] Parasuraman, Berry & Zeithaml, Refinement and Reassessment of theSERVQUAL Scale, Journal of Retailing, Winter 1991, pp. 420-50.

[16] Dawes, John, Do Data Characteristics Change According to the number ofscale points used? An experiment using 5-point, 7-point and 10-point scales,International Journal of Market Research 50 (1), 2008, pp. 61-77.

[17] Ekman, Lars, On the Treatment of Flow in Traffic Safety Analysis, - a non-parametric approach applied on vulnerable road users, 1996, Department ofTraffic Planning and Engineering, Lund Institute of Technology, Box 118, 22100 Lund, Sweden

[18] Lill, D.; Schappacher, M.; Gutjahr, A.; Sikora, A.;, Development of a wire-less communication and localization system for VRU eSafety, CommunicationSystems Networks and Digital Signal Processing (CSNDSP), 2010 7th Interna-tional Symposium on , vol., no., pp.459-463, 21-23 July 2010,

[19] Sikora, A., Communication and Localization for a Cooperative eSafety-System,Intelligent Data Acquisition and Advanced Computing Systems: Technologyand Applications, 2007. IDAACS 2007. 4th IEEE Workshop on , vol., no.,pp.682-685, 6-8 Sept. 2007, doi: 10.1109/IDAACS.2007.4488509

[20] A. Sikora, V. Groza, Fields Tests for Ranging and Localization with Time-of-Flight-Measurements Using Chirp Spread Spectrum RF-devices, IMTC 2007-IEEE Instrumentation and Measurement Technology Conference Warsaw, 1-3.5.2007.

56

BIBLIOGRAPHY

[21] C. Morhart, E.M. Biebl, D. Schwarz, R.H. Rasshofer, Cooperative Multi-UserDetection and Localization for Pedestrian Protection, GeMIC 2009 ITG-ReportVol. 213, 2009.

[22] Sugimoto, C., Nakamura, Y., Hashimoto, T., Prototype of pedestrian-to-vehiclecommunication system for the prevention of pedestrian accidents using both3G wireless and WLAN communication, Wireless Pervasive Computing, 2008.ISWPC 2008. 3rd International Symposium, pp.764-767, 2008.

[23] Sugimoto, C. Nakamura, Y., Provision of information support by pedestrian-to-vehicle communication system, ITS Telecommunications, 2008. ITST 2008.8th International Conference, pp.160-163, 2008.

[24] Ralph H. Rasshofer, Daniel Schwarz Cooperative Sensor Technology for Pre-ventive Vulnerable Road User Protection, BMW Forschung and Technik GmbH,Haunauer Str.46, Technische Universität Munchen, Fachgebiet Höchstfrequen-zentechnik, Munich, Germany,Paper Number 09-0136.

[25] Trafikverket, Analys av trafiksakerhetsutvecklingen 2010,Målstyrning avtrafiksakerhetsarbetet mot etappmålen 2020, 2011, Publication 2011:113. Avail-able: http://www.publikationswebbutik.vv.se [2012-02-22].

[26] ETSI TR Use Cases and Technical Specifications , Intelligent Transport Sys-tems (ITS), Vehicular Communications, C2C-CC Demonstrator, Sophia An-tipolis, France, 2008.

[27] LaPlante J., Kaeser P.J. A history of pedestrian signal walking speed assump-tions,3rd Urban System Symposium, Seattle, Washington, June.

Internet resources

[28] COOPERS - Cooperative Systems for Intelligent Road Safety [www]. Available:http://www.coopers-ip.eu/ [2012-01-17].

[29] CVIS - Cooperative Vehicle-Infrastructure Systems [www]. Available: http://www.cvisproject.org/ [2012-01-18].

[30] SAFESPOT [www], Available: http://www.safespot-eu.org/ [2012-01-18].

[31] DRIVE-C2X-Large European FOT on cooperative systems [www]. Available:http://www.drive-c2x.eu/project/ [2012-02-20].

[32] FREILOT- Urban Freight Efficiency Pilot [www]. Available: http://www.freilot.eu/ [2012-02-17].

[33] COMeSAFETY2-Communication for eSafety [www]. Available: http://www.comesafety.org/index.php?id=4 [2012-01-23].

57

BIBLIOGRAPHY

[34] COSMO- Cooperative Systems for Sustainable Mobility and Energy Efficiency[www]. Available: http://www.cosmo-project.eu/ [2012-02-6].

[35] eCoMOve- Cooperative Mobility Systems and Services for Energy Efficiency[www]. Available: http://www.ecomove-project.eu/ [2012-02-27].

[36] EcoGem-Cooperative Sdvanced Driver Assistance Systems for Green Cars[www]. Available: http://www.softeco.it/ecogem/home.aspx [2012-02-27].

[37] CATS-City Alternative Transport Systems [www]. Available: http://www.cats-project.org/ [2012-02-17].

[38] AMULETT-Active mobile accident avoidance and accident mitigation throughcooperative acquisition and tracking technology [www]. Available: http://www.projekt-amulett.de/ [2012-02-23].

[39] SAVE-U [www], Available: http://www.save-u.org/ [2012-02-22].

[40] ARTRAC [www], Available: http://cordis.europa.eu/search/index.cfm?fuseaction=proj.document&PJ_RCN=12361726 [2012-02-22].

[41] Safeway2School [www], Available: http://safeway2school-eu.org/ [2012-02-07].

[42] ASPECSS-Assessment methodologies for forward looking Integrated Pedes-trian and further extension to cyclist safety systems [www]. Available: http://www.aspecss-project.eu/ [2012-02-17].

[43] ARTRAC-Advanced Radar Tracking and Classification [www]. Avail-able: http://tutech.net/index.php/page/Projects-2011-03-04#1 [2012-02-27].

[44] Mantzouranis Irene, ICCS, Kaffes Vassilis, ICCS. Project Presentation, Deliv-erable 1.1, Project MINIFAROS, 2010.

[45] WATCH-OVER project: Cooperative Vulnerable Road Users, 2006. Available:http://www.watchover-eu.org [2012-02-12].

[46] The OSI Model’s Seven Layers Defined and Functions Explained [www], Avail-able: http://support.microsoft.com/kb/103884 [2012-05-05].

[47] The 7 Layers of the OSI model [www], Available: http://www.webopedia.com/quick_ref/OSI_layers.asp [2012-05-05].

[48] Some notes about various encapsulation methods. [www], Available: http://waldner.netsons.org/d4-encapsulation.php [2012-05-07].

[49] Network Essentials, OSI Model Layer [www], Available: http://www.stevesalloom.com/ITNW110/CHAPTER02_OSIModelLayers2.doc [2012-05-07].

58

BIBLIOGRAPHY

[50] Grumert E.,Cooperative systems, VTI, Sweden, 2011. [www]. Available: http://www.vti.se/publications [2012-03-06]

[51] PReVENT, sub-project COMPOSE [www], Available: http://www.prevent-ip.org/en/prevent_subprojects/vulnerable_road_users_collision_mitigation/compose/ [2012-02-22].

[52] DCMA 86P2 card [www], Available: http://www.alibaba.com/product-free/107641165/DCMA_86P2_industrial_grade_high_power.html [2012-05-07].

[53] Cohda M2K Radio device [www], Available: http://www.cohdawireless.com/ [2012-05-07].

[54] Atheros [www], Available: http://wireless.kernel.org/en/users/Drivers/ath5k [2012-05-07].

[55] Wikipedia on Android [www], http://en.wikipedia.org/wiki/Android_(operating_system), Available: [2012-03-06].

[56] Android developers [www], http://developer.android.com/, Available:[2012-03-08].

[57] Dalvik Virtual Machine [www], http://www.dalvikvm.com/, Available: [2012-03-08].

[58] Romuald Ireneus Scibor-Marchocki, Spherical trigonometry, Elementary-Geometry Trigonometry web page (1997) [www], http://www.webcitation.org/query?url=http://www.geocities.com/ResearchTriangle/2363/trig02.html&date=2009-10-25+09:44:36, Available: [2012-03-27].

[59] Wikipedia on Network security [www], http://en.wikipedia.org/wiki/Network_security, Available: [2012-03-16].

[60] GeoNet, D2.2 Final GeoNet SpecificationICT-2007.6.1: ICT for intelligentvehicles and mobility services, Available: http://www.geonet-project.eu/?download=GeoNet-D2.2-final_specification.pdf [2012-03-01].

[61] KAMO, ,VTT, Unknown release date, Available: http://www.vtt.fi/files/services/ipr/mobile_guide_for_city_travellers.pdf, [2012-02-07].

59

Appendix A

Project INTER SAFE-2Activity Intersection safety and monitoringActivity description Left- and right turns, turn- and cross path. V2X

communication with 802.11p, on-board stereo camerafor environmental monitoring, infrastructure sensors(laser scanner, cameras) for traffic and road conditionclassifying, high level fusion of collected infrastructuretraffic data, traffic light prediction algorithms, local-ization.

Project technologiesused

802.11p, laser scanners, cameras.

Project conclusions All described technology and services was investi-gated. Combination of on-board- and and infrastruc-ture sensors gave more reliable interpretation of theintersection scene. Successfully object tracking andclassifying.

Project HeEROActivity eCall pre-deploymentActivity description Harmonize and define functional/operational require-

ments for eCall systems, implement needed technical/-operational infrastructure upgrades, produce recom-mendations for future eCall deployment.


Strategies.

Project conclusions Operational and functional requirements are de-scribed.

Project SAFEWAY2- SCHOOLActivity Integrated system for safe transportation of children

to school.Activity description The project aims to design, develop, integrate and

evaluate technologies for providing a holistic and safetransportation service for children, from their homedoor to the school door and vice versa. Systems pro-posed is on-board hardware for the buses, intelligentbus stops/bus signs, mobile devices and communica-tion centrals.


Software, ad hoc hardware (NDs), platforms.

Project conclusions So far a crash test analysis has been done, telematicsystems have been developed and use cases are inves-tigated for the test sites.

Project AspeccsActivity Harmonized test and assessment procedures for for-

ward looking integrated pedestrian safety systems.Activity description Develop standardized procedures, standards and

methodologies (and related tools) related to forwardlooking pedestrians and two-wheelers safety.


Documents.

Project conclusions None so far.

Project eVADERActivity Investigate the interior and exterior sound scape of

electric vehicle for safe operation.Activity description Improve the acoustic detectability of electric vehicles

in urban scenarios, define solutions to warn vulnerableusers of a nearby moving vehicles, driver and pedes-trian warning systems and pedestrian safety.


Theory.


Project ARTRACActivity Advanced Radar Tracking and Classification for En-

hanced Road Safety.Activity description Develop an active safety system to protect vulnerable

road users (VRUs) from vehicles in motion. A newtransmit/receive antenna and multi-channel receiverwill be developed.


Vehicle actuators, 24 Ghz narrowband radar sensor.


Project ASPISActivity Development of a prototype surveillance system based

on autonomous, smart monitoring devices.Activity description With the system store what happened just before and

just after the event, set up a ad-hoc network across theremaining devices and transfer the stored sequences tothe first responders.


Monitoring devices.


Project ADOSEActivity Collision Avoidance Extra-Urban.Activity description Collision detection at long distances for collision warn-

ing/intervention.Activity Collision Avoidance Inter-Urban.Activity description Collision detection at medium/short distances for col-

lision warning/intervention.Activity Pre-Crash Warning/ Preparation Front Impact.Activity description Crash prediction for Pre-Crash warning/preparation

for front impact (Pre-fire and Pre-set applications).Activity Pre-Crash Warning/ Preparation Side Impact.Activity description Crash prediction for Pre-Crash warning/preparation

for side impact (Pre-fire and Pre-set applications).Activity Pre-Crash Warning/ Preparation Rear Impact.Activity description Crash prediction for Pre-Crash warning/preparation

for rear impact (Pre-fire and Pre-set applications).Project technologiesused

FIR, MFOS, 3DCAM, HR P/A TAG, SRS.

Project conclusions ADOSE has impacted on a “virtual safety belt”around vehicles and increased the safety functionswith new sensor technology. Sensors have been madeand proven to work.

Project eValuActivity Adaptive Cruise Control (ACC).Activity description Stand alone system for taking over task of longitudinal

vehicle control.Activity Forward Collision Warning (FCW).Activity description Stand alone system that provides alerts to assist

drivers in avoiding or reducing the severity of crashesby striking the rear-end of another vehicle.

Activity Collision Mitigation (CM).Activity description Stand alone driver assistance system that helps the

driver in mitigating imminent frontal collision by giv-ing brake support.

Activity Blind Spot Detection (BSD).Activity description Stand alone driver assistance system that helps to

avoid side swipe collisions in lane change situations.The system issues a warning to the driver when anobject is detected in the blind spot area.

Activity Lane Departure Warning (LDW).Activity description Stand alone system that supports the driver to stay in

the lane, by issuing a warning to the driver in case ofan unintended lane change.

Activity Lane Keeping Assistant (LKA).Activity description Stand alone system that supports the driver to stay in

the lane, by enhancing the Lane Departure Warningsystem with actuators which either applies a steeringwheel vibration or applies a torque on the steeringsystem into the direction of the lane center.

Activity Electronic Stability Control (ESC).Activity description Stand alone system that helps to stabilize the yaw

behavior of a vehicle in critical driving situations byusing controlled braking and engine interventions.

Activity Antilock Brake System (ABS).Activity description Stand alone system that controls the brake wheel slips

and prevents locking of the individual wheels whilebraking.


IR LIDAR, IR SRR, FIR Camera, Yaw rate sensor,Steering angle sensor, Acceleration sensor, 2D CMOScamera.

Project conclusions The eVALUE project now offers explicit testing proto-cols for vehicle active safety that can found the basisfor either implementation or more detailed specifica-tion, depending on the level of definition. While themethods for stability-related testing were regarded asmature, testing of longitudinal and lateral safety func-tion requires more research.

Project eSafety ChallengeActivity Electronic Stability Control (ESC) and Warning and

Emergency Braking Systems).Activity description It helps avoiding a crash by significantly reducing the

risk of a car going into a skid during a sudden emer-gency maneuver like avoiding an obstacle in front ofthe driver.

Activity Blind Spot MonitoringActivity description It helps avoiding a crash with a vehicle in the lane

next to a driver by continuously screening the blindspots.

Activity Speed Alert.Activity description It helps keeping the correct speed and avoiding the

speed related traffic crashes. It informs about thespeed limits and tells when you are about to exceedthem.

Activity Lane Support System.Activity description It can assist and warn when you unintentionally leave

the road lane or when you change lane without indi-cation.


Wheel Speed Sensors, Yaw Rate Sensor, AccelerationSensors, Steering angle Sensor, HCU (Hydraulic Con-trol Unit).

Project conclusions eSafety systems have been on the market for severalyears and are increasingly expected to provide a ma-jor contribution to the reduction of casualties on ourroads. ESC alone can save at least 4,000 lives in Eu-rope alone and prevent more than 100,000 injuries.Other systems have proven to make the driving verycomfortable as the systems are not disturbing driver’sdriving but is making it more smooth and relaxed.

Project SAFE-RIDERActivity Speed Alert Functionality.Activity description The speed alert functionality is to inform the rider

when the speed exceeds the legal speed limit. Infor-mation about legal speed will come from maps andfocused with vehicle data.

Activity Curve warning.Activity description The curve warning is to warn the rider that there are

high risk factors when negotiating the curve ahead.Activity Frontal Collision Warning.Activity description The frontal collision warning is to warn the driver

when there is a risk of collision with an obstacle de-tected in the near field of the motorcycle.

Activity Intersection support.Activity description Improve safety on intersections.Activity Lane change support.Activity description The lane change support is to warn the driver in case a

potential lane change is critical in terms of a potentialcollision.

Activity Tele diagnostics Module.Activity description Tele diagnostics services provide added value for the

rider by monitoring constantly the use and functioningconditions of the vehicle.

Activity eCallActivity description The eCall system requires the capacity of PTW to de-

tect and remotely provide information, as the locationof a crash or fall.

Activity Navigation and Route Guidance.Activity description The navigation unit has been conceived specifically for

the riding task and it needs to include icons on incom-ing danger arrives, information about traffic conditionand weather ,manual activation of eCall.

Activity Weather, Traffic and Black Spot Warning.Activity description This function will integrate the navigation system with

weather, traffic and accident data, in order to warnthe vehicle occupant about potential dangers along theroute.


GNSS sensor, Laser scanner, Remote communicationmodel GSM/UMTS, CAN Bus, Digital Maps, Pres-sure Sensors, Bluetooth connections.

Project conclusions Pilots have shown expected results to be achieved andshowed optimizing results with smaller abbreviations.

Project MINI-FAROSActivity Low-cost Miniature Laserscanner for Environment

Perception.Activity description New type of a laser sensor for enhanced environment

perception in terms of optics.Project technologiesused

Laserscanner, MEMS (mirrors, comb sensors..), CCDor CMOS cameras, Laser diode, Avalanche photodiode(photodetector), TDC (time-to-digital converter).

Project conclusions MiniFaros activities lies in the extended utilization en-vironment perception technology, and especially lasertechnology aiming at a generic and affordable sensorenabling fast market penetration of IVSS in mediumterm. Architecture of the sensor and specificationshave been finished but the real implementation is stillholding on.

Project 2WIDE-SENSEActivity Cost-effective InGaAs focal plane array with wide

spectral response (VIS-NIR-SWIR camera, sensing de-vice)

Activity description The next generation of imaging sensors beyond thecurrent CMOS imagers for enhancing preventivesafety functions and car energy efficiency.


VIS-NIR-SWIR camera, sensing device, optoelec-tronic.

Project conclusions Regarding concept design following things have beendone and following conclusion have been made: NewFocal Plane Arrays (FPA) based on the optimized de-sign have been processed and measured. The FPAwith the best quantum efficiency is available for in-tegration in camera. OWL SWIR camera is alreadymade and available. Also wide spectral sensitivity hasbeen studied and showed that the high pass filtersconsist in the most convenient choice for the appli-cation.An anti-reflection coating (ARC) required onlyfor clear pixels in the final demonstrator has beendeveloped. Real in car demonstration still not per-formed.

Project FNIRActivity Night Vision Enhancement Systems using Sensor Fu-

sionActivity description Night Vision System with automatic detection of up-

coming hazards at an affordable cost. A combinedNIR/FIR system enable substantial system cost re-duction and increased performance through sensor sig-nal fusion.


Not specified.

Project conclusions The system that was invented as part of the FNIRproject is a low cost system with a brilliant night viewimage on the one hand and a detection performancehigher than that of a single sensor Night Vision system(FIR) on the other hand. The comparison between afusion classifier and a FIR mono classifier shows, thatthe detection rate as well as the fraction of missedpedestrians can be significantly improved.

Project EURIDICEActivity Connected transport and production processes.Activity description Increase synchronization between transportation and

manufacturing processes.Activity Active cold-chain monitoringActivity description Improve monitoring of the cargo physical conditions

and of the cargo delivery process.Activity Cargo controlling transportation in 3PL services to

final customer.Activity description The objective is to reduce inefficiencies and errors, al-

lowing the departure of the cargo from a hub to triggerexternal scheduling at destination hubs.

Activity Cooperative warehousing through cargo-centric infor-mation services.

Activity description The objective is to improve storage scheduling anddeliveries forwarding.

Activity Self-returning empty pallets and boxes.Activity description The objective is to provide a complete traceability,

documentation and observation of transports in real-time and to achieve better utilization of empties.

Activity Cargo-assisted inter-modal transport.Activity description The objective is to improve customer service and effi-

cient utilization of wagons in inter-modal operations.Activity Intelligent routing through cargo-infrastructure coop-

eration.Activity description The objective is to avoid congestion and accidents and

to optimize utilization of road and parking infrastruc-tures.

Activity Automated clearance and billing of transiting goods.Activity description The objective is to speed up the transit of goods at

international borders and to increase security levels.Project technologiesused

RFID, EDI-XML

Project conclusions Project was successful with 8 pilots tested on the wayfrom Finland to Norway and this type of system willbe used to track shipments flowing through intercon-tinental African-European transport corridors.

Project HAVEitActivity Design of the task repartition between the driver and

co-driving system (ADAS) in the joint system.Activity description Instead of just switching off an ADAS system in case

of an impending potentially critical situation, a pro-gressive step-by-step-approach will be used to transferthe driving task back from the automated system tothe driver.

Activity Highly automated driving in public traffic.Activity description The aim is to help the driver in the certain uncom-

fortable situations regarding public traffic with au-tonomous driving of the vehicle in order to increasesafety but comfort itself as well.

Activity Safety architecture applications.Activity description The safety architecture application group will present

a migration concept and a demonstrator to show pos-sible migration paths.


FlexRay, CAN and LIN for communication, C2CC2I,Generic ECU, Steer-by-wire, Break-by-wire, IBEOLUX laser scanners.

Project conclusions During the implementation process all system com-ponents have been verified individually before bring-ing the system together. Algorithm and the fully in-tegrated system works as intended.The most criticalpart of ARC vehicle, the hands off driving through aroad construction is tested successfully. Drivers ratedit as a quite meaningful and useful system. All in allsuccessful project.

Project In-TimeActivity Multimodal Real Time Traffic and Travel Information

services.Activity description Get accurate and precise door-to-door information on

the current travel times within the city, including al-ternative routes and alternative modes to be used.The aim is to changing the mobility behavior of thesingle traveller. The services are supposed to be of-fered via Internet and mobile devices or navigationaldevices.


Internet services / software.

Project conclusions A list of recommended services within In-Time isgiven, e.g“well readable content”, “planned traveltime”, fastest route” and so on.

Project Instant MobilityActivity Multimodal Real Time Traffic and Travel Information

services (including goods).Activity description Develop a platform/system that contains online ser-

vices for destination support (real-time traffic status,transport availability etc.), goods delivery monitoring,management of parcels, trucks and parking.


Software.

Project conclusions Use cases to test is described, no additional info.

Project FREILOTActivity Urban freight energy efficiency.Activity description Eco-driving support to driver, speed- and acceleration

limiter, delivery space booking and intersection con-trol to optimize fuel consumption.


Platform, software.

Project conclusions Use cases to test is described, no additional info.

Project CitylogActivity Sustainability and efficiency of city logistics.Activity description By develop a whole platform for city logistics, i.e. new

vehicles, navigation systems and last mile parcel track-ing via SMS, this project aims to make city logisticsmore efficient by better coordination and communica-tion.


Customized load units and vehicles, software.


Project CityMoveActivity Develop efficient and CO2-reducing urban goods de-

livery vehicles.Activity description Design new vehicle architecture appropriate to freights

operating in urban context, develop the Pedestrian /vulnerable-user protection functionality and Collisionavoidance - Driver assistance functionality for urbangoods delivery trucks.


Vehicle architecture for freights operations in urbancontext.

Project conclusions User needs are identified in a publication

Project eFUTUREActivity Creating a platform for electronic vehicles for min-

imized energy consumption and optimizing decisionbetween safety and efficiency.

Activity description Creating a platform which minimizes its energy needsbut can still optimize dynamically its decision betweensafety and energy efficiency, requirements on and en-gineering of ECUs.


System architecture.


Project EcoGemActivity Continuous monitoring of the vehicle‘s battery level

and energy consumption.Activity description No description needed.Activity Autonomous optimized route planning.Activity description By exploiting the tracked records, utilizing past

knowledge and experience, and applying suitable ma-chine learning processes, the FEVs will be equippedwith traffic estimation and optimal route selection ca-pabilities.

Activity Cooperative optimized route planning.Activity description Through (V2V) interactions, FEVs will be able to

share their route-selection experiences.Activity Continuous awareness of recharging points and opti-

mized recharging strategyActivity description Inform the driver, whenever necessary, to select a

recharging option and to book the most convenientrecharging point.

Activity Online management of recharging points.Activity description As the availability of recharging points can change on

a rather frequent basis, there is need for a managementsystem capable of tracking current availability in real-time.


V2V, V2I, Electrical Grid.


Project GeoNetActivity V2V and V2I communication in a particular geo-

graphic area, IPv6 geo networking (geo-routing andgeo-addressing)

Activity description The aim is in providing a standard solution for IPv6geo networking to all Intelligent Transportation Sys-tems (ITS), relying on the IPv6 standard and on Car-to-Car Communication Consortium’s (C2C-CC) geonetworking.


Geo-routing (geounicast, geoanycast, geocast), IPv6,IP/TCP, PC Linux Ubuntu, Java.

Project conclusions Indoor and outdoor test have been performed. IPv6over C2CNet is feasible and vehicular communicationis possible but C2C-IP SAP causes delay overhead.Outdoor test have shown that communication is sta-ble even with the bigger speed, therefore IPv6 overC2CNet works.

Project eCoMoveActivity eco-pre-Trip Planning.Activity description It advises optimal departure time and greenest

route, in combination with energy-relevant informa-tion about vehicle functions, for least impact journey.

Activity ecoSmart-Driving.Activity description This is “virtual coach” providing dynamic green driv-

ing and routing guidance as well as on trip tips to tunevehicle functions for minimum fuel use.

Activity ecoPostTrip.Activity description Personalized recommendations based on driving

record for eco-driving optimization.Activity ecoMonitoring.Activity description Information derived from vehicles‘ post trip eco record

is distributed in a fully anonymous way to the trafficcontrol center, to identify energy black spots.

Activity ecoDriver Coaching.Activity description Dynamic “coaching” for commercial vehicle drivers in-

cluding training and incentive scheme.Activity ecoTour Planning.Activity description Planning for logistics companies to define eco-efficient

tours considering drivers‘ eco-performance, vehiclepayload and road infrastructure status.

Activity Truck ecoNavigation.Activity description Calculating the most fuel efficient route based on

truck-specific attributes and traffic state information.Activity ecoAdaptive Balancing.Activity description Strategies for energy-optimized traffic distribution at

network and local levels.Activity ecoAdaptive Traveller Support.Activity description Support to drivers by sending information on traffic

state, route recommendations and speed profile dataneeded by on-board assistance systems.

Activity ecoMotorway Management.Activity description Measures for energy-optimized flow management on

the interurban network coupled with ramp meteringand merging assistance at individual vehicle level.


V2V, V2I, IEEE802.11p, geo networking, IPv6,CALM M5/CALM FAST.

Project conclusions Still platform and architecture on the run. Not testedyet.

Project STRAIGHT SOLActivity DHL Supply Chain‘s Urban Consolidation Centre in

L‘Hospitalet de Llobregat.Activity description To improve the performance of urban freight deliver-

ies DHL Supply Chain will operate an urban consol-idation centre (UCC) that will reduce the number ofvehicles entering the defined area.

Activity TNT Express in Brussels - City Logistics Mobile De-pot.

Activity description Every day this mobile depot is bringing the deliveriesto the central station in the inner city and afterwards,a set of electrically supported tricycles carries out thelast mile delivery operations.

Activity Remote bring-site monitoring for more reactive andsustainable logistics.

Activity description The aim is to target the banks in demographically andgeographically opposing areas, and to demonstrate theremote monitoring.

Activity Rail tracking and warehouse management.Activity description The aim is to provide real-time information to WMS

(Warehouse Management System).Activity Smart Urban Transport Solution - Retail supply chain

management and “last mile” distribution by use ofstandardized information.

Activity description The idea is to show urban transportation authorities,LSPs and retailers how automatic data capturing andinformation sharing will make it possible to harmonizethe urban transport.

Activity TNT Night Distribution.Activity description The objective is to extend the existing In-night net-

work by introducing radio frequency identificationand additional secure pick-up/drop-off locations whichshould persuade potential customers fearing liabilityand safety issues.

Activity Municipal regulation of loading and unloading offreight.

Activity description In Lisbon, there are growing problems with unregu-lated loading/unloading activities, with road conges-tion and often blockage of roads, when trucks stop onnarrow streets for quick loading/unloading activities.


RFID, GPS, GSM/satellite, Intelligent Lockers.


Project SMART FREIGHTActivity Analyses of urban freight transport challenges and re-

quirements.Activity description Defining commonalities between wireless communi-

cation systems used in freight distribution manage-ment (FDMS) and urban traffic management systems(UTMS).

Activity Traffic management and distribution management ser-vices.

Activity description The aim is to specify a generic implementation of newsolutions for urban freight traffic management andfreight distribution management.

Activity On board support and control on top of CALM.Activity description The aim is to analyze, design and implement generic

solutions for on-board and on-cargo equipment neededto support innovative freight distribution services.

Activity System architecture for open solutions for freighttransport.

Activity description The aim is to provide a total picture of smarter freighttransport in urban areas by specifying conceptual,logical and technical aspects that support the plan-ning and implementation of new solutions in Europeancities.

Activity Impact evaluation of new concepts.Activity description This will address the effects of the new services be-

ing developed for traffic management and freight man-agement, separately but also combined for the urbantransport system as a whole.

Activity Proof of concept and verification of ICT solutions.Activity description Innovative concepts defined in the project are imple-

mented and tested technologically by the use of CALMplatform at the Trondheim, Norway test site. Othertypes of proof of concept will be verified at Bologna,Winchester and Dublin.


CALM IR, CALM MAIL or DCRS, CALM MM,WiFI, WiMax, 3GPP 2G/3G/4G, iBurst.

Project conclusions Open services that are required for interoperabilitywith existing traffic management and freight distri-bution management systems are identified. It isconcluded that CALM technology is not yet matureenough for commercial solutions. As a final conclusionit can be stated that the main objective of implement-ing and developing the SMARTFREIGHT concept hasbeen successful, therefore the technology works.

Project EBSFActivity Develop urban bus system adapted to the specificities

of the European cities.Activity description Develop vehicle- and infrastructure based systems for

next generation buses.Project technologiesused

Software.


Project KAMO (VTT Technical Research Centre of Finland)Activity Real-time public transport information delivered to

mobile phones.Activity description Delivery of travel information to mobile devices and

on-trip information services.Project technologiesused

Software.

Project conclusions The Mobile Guide for City Traveller (KAMO) is amobile application that can track the progress ofany buses, trams or underground trains included inthe real-time positioning-based monitoring. The ser-vice also enables journey planning and tracking theplanned route via mobile phone.

Project ViajeoActivity Develop open platform for data sharing and exchange.Activity description The platform will enable all data and information used

for real-time operation to be used for transport plan-ning.


Software.


Project CATSActivity Develop new urban transport service based on a new

generation of vehicles.Activity description Develop new type of vehicles used in urban ares for

transport and the aim is to filling the gap betweenpublic mass transport and private individual vehicles.


New generation vehicles.


Project CityNet MobilActivity Small automated low-polluting vehicles for driverless

transport in cities.Activity description Investigate if these small automated low-polluting ve-

hicles can be integrated into urban environments, ifthey will solve efficiency, environmental and safetyproblems and how users would react using this kind ofconcept.


New generation vehicles.


Project Freight Urban RoBOTic vehicle (FURBOT)Activity Light-duty, full-electrical vehicles for efficient sustain-

able urban freight transport.Activity description Develop architectures of light-duty, full-electrical ve-

hicles for efficient sustainable urban freight transportto factually demonstrate the performances expected.


Robotics, full-electrical vehicle.


Project ELVIREActivity Developing of an effective and open E-service platform

to connect electric vehicles to their E-energy environ-ment.

Activity description Develop a connected on-board unit and external ser-vice infrastructure, which will support optimal andseamless interaction between the user/vehicle, thedata processing & service provision layer and an in-telligent electricity infrastructure.


On-board unit, software.

Project conclusions Investigated use cases and requirements for the on-board unit performed.

Project AMITRANActivity Develop assessment methodologies for ITS CO2 emis-

sion.Activity description Define a reference methodology to assess the impact of

ITS on CO2 emission, the deliverable will be a hand-book on such methodologies.


Documents.


Project CO2NTRLActivity Integrated solutions for noise and vibration control in

vehicles, focused on CO2.Activity description Investigate integrated solutions for noise and vibration

control in vehicles to improve vehicle fuel efficiencyand reduce their impact on the environment.


Not specified.


Project CityHushActivity Noise action planActivity description Eliminate harmful effects of noise exposure and de-

crease levels of transport noise creation, especially inurban areas.


Quiet tires, smooth elastic dense road surface.

Project conclusions Investigation into noise score ratings, tools for creatingQ-zones (quiet zones).

Project iCar-SupportActivity Intelligent Car Support.Activity description Intelligent Car Support is a 36 month Support Action

with the objective to support the implementation ofactions and recommendations resulting from the workof the eSafety Forum and the Intelligent Car Initiative.


Coordination of Standards Development Organiza-tions (SDOs). Be the contact point on standard mat-ters both for the EU ITS community and for non-EUbodies (e.g. in light of U.S./EU/Japan cooperation).

Project conclusions Still in execution.

Project FESTAActivity European FOT Support Action.Activity description The FOTs will comprise a comprehensive program of

research to assess the impacts of ICT systems on driverbehavior, both in terms of individual (safety) benefitsand larger scale socio-economic benefits.


To validate the effectiveness of ICT systems for safer,cleaner and more efficient transport. To analyzedrivers behavior and user acceptance of the system.To obtain technical data for system design and devel-opment. FESTA will provide a handbook regardingthat.

Project conclusions Handbook was made and the it can be found on thefollowing site.

Project FREIGHT-VISIONActivity Vision and action plan for European freight transport

until 2050.Activity description The FREIGHT-VISION team is therefore developing

framework strategy for freight transport and freightlogistics in Europe based on scenario building for thetime horizons 2020, 2035 and 2050.


GNSS, RFID.

Project conclusions Transport policy, technology developments, and megatrends with regard to long-distance freight transporthave been analyzed. Scenarios how to reach a desir-able future have been developed and the vision andaction plan for this have been presented as well.

Project FOT-NET (FOTNET2)Activity Develop platform to share FOT data and standardize

FOT methodology.Activity description Create a wiki tool about all FOT projects with the

aim to share data and experiences. Develop FESTAwhich will be a common methodology when executingFOT’s.


Software.

Project conclusions A Wiki tool is online and the FESTA project (hand-book) is under development.

Project euroFOTActivity Perform FOTs.Activity description By using FOT-NET’s FESTA handbook and guide-

lines, perform and execute FOT’s of different car man-ufacturers/projects innovations: adaptive cruise con-trol, forward collision warning, lane departure warn-ing, blind spot information system, fuel efficiency ad-visor, safe human interaction, curve speed warning,speed regulation system.


Documents.

Project conclusions Data is collected and is at the moment analyzed. Theresults will contribute to update/improve the FESTAhandbook.

TRITA-CSC-E 2012:080 ISRN-KTH/CSC/E--12/080-SE

ISSN-1653-5715

www.kth.se

Gap Analysis in Cooperative Systems within Intelligent ... · in Cooperative Systems within...

Documents

Transcript of Gap Analysis in Cooperative Systems within Intelligent ... · in Cooperative Systems within...