Integration of vulnerable road users in cooperative ITS systems

Abstract

Introduction

This paper describes the development of an architecture for the integration of Vulnerable Road Users (VRUs), i.e. pedestrians, cyclists and powered two-wheelers (PTWs) in Cooperative ITS (C-ITS) systems, and the requirements for VRU devices.

Methods

This paper starts with a literature overview on research related to safety applications using communication between vehicle and VRU, and an analysis of the different use cases for C-ITS for VRUs. An architecture is developed, starting from an architecture of C-ITS systems and incorporating the different alternative configuration for VRUs. Starting from the architecture and the use cases, the requirements for VRU devices are defined. Finally, a roadmap regarding C-ITS applications for VRUs is developed.

Results

C-ITS technologies allow to communicate with low latency in highly dynamic environments. C-ITS will be integrated in vehicles and can also become available for VRUs, either as an application on a smartphone or as a dedicated device, which can be integrated in the VRU’s vehicle. Two levels of use cases can be identified: awareness of the presence of VRUs near potentially dangerous situations, and collision risk warning, based on trajectories of the road users. A roadmap was developed aligned with the roadmap of the automotive industry.

Conclusions

Awareness related use cases are relatively close to the market, as they do not put stringent requirements to the (localization) sensors at infrastructure or vehicles. For the collision risk warning use case, the technical requirements for VRU devices towards sensor accuracy and calculation capabilities are challenging. Other challenges are power consumption, context sensitivity, channel congestion, privacy and security of messages. Standardisation of the messages exchanged between VRUs and other road users and infrastructure is a key issue.

1 Introduction

Vulnerable Road Users (VRUs) include a wide range of road users, such as pedestrians, cyclists and powered two wheelers (PTWs). Most of the existing ITS safety applications are targeted towards vehicles, and hence the impacts and usability of ITS applications for VRUs require more concrete research. Recent projects tackling VRU safety, such as ASPECCS [1], have mainly focused on detecting the pedestrians and avoiding accidents by utilizing on-board sensors, such as camera or radar. These systems can provide adequate performance in many use cases, but cannot handle scenarios in which there is no line-of-sight (LOS) connectivity between car and VRU. Cooperative ITS (C-ITS), using communication between road users, is a more performant technology than in-vehicle-only technologies to avoid these accidents. One way to improve the safety of VRUs is allowing them to communicate with the other cooperative road users and the infrastructure.

The VRUITS project has assessed the safety, mobility and comfort impact of existing and upcoming ITS applications for Vulnerable Road Users. According to the performed safety assessment of selected ITS systems [1], co-operative communications between vehicles and VRUs have the potential to improve the safety of Vulnerable Road Users. This paper will start with a literature overview on research related to ITS safety applications, using communication between vehicle and VRU. The different use cases are identified, and an architecture is developed, which also specifies the requirements for VRU devices. The paper concludes with a roadmap regarding C-ITS applications for VRUs.

2 Related work

Research and development in cooperative traffic telecommunications and road safety is mainly concentrated on vehicle-to-vehicle (V2 V) and vehicle-to-infrastructure (V2I) communications and applications. Vehicle-to-VRU (V2VRU) communications and VRU safety is a rather new research topic. Several research projects have addressed the communication between cars and pedestrian or cyclists. Through an analysis of the different proposed solutions, four different ways of communicating can be distinguished.

The first way is using a tag by the VRU, transmitting only limited information such as ID, and a reader in the vehicle, which localizes the VRU based on this signal. The ADOSE project developed and assessed a system for VRU detection based on harmonic radar and passive transponders [2]. SafeWay2School [3] developed a RFID-based VRU unit for children that consists of a standalone radio unit able to communicate with intelligent bus stops, which warn drivers with flashing lights about the vicinity of VRUs. The Ko-TAG project demonstrated an in-vehicle collision avoidance and mitigation system for VRUs, using car mounted transmitter-receivers, which can locate tags carried by VRUs, transmitting basic data at 5.9 GHz using a proprietary air protocol [4].

The second approach is to use smartphones for VRU detection, through exploiting of the signals periodically transmitted by the phone over Bluetooth Low Energy (BLE), Wi-Fi or cellular radio. A receiver in the car should hence localize the VRU. Main issues are large latency caused by the detection process, which is in the order of seconds, and the low accuracy of the positioning of the smartphone using radio signals. BLE is increasingly integrated in smartphones and is another candidate for non-time and non-safety critical applications.

In the third approach, apps on a smartphone transmitting also location data, possibly as standard C-ITS messages (ETSI ITS-G5 in Europe) have been described by Engel [5] and Liebner [6] and Wu [7]. Lee [8] proposes to use Wi-Fi Direct, and Arraya [9] Wi-Fi to transmit data. According to Borroni-Bird [10], future phones can include ITS-G5 without additional hardware. In the future, also LTE Release 14 will support V2P functionalities [11].

The fourth solution is to use a dedicated VRU device, transmitting location and other sensor data. The messages should be C-ITS compliant to communicate with standardized in-vehicle and roadside C-ITS equipment. The use of C-ITS devices on motorcycles has been demonstrated in the DRIVE-C2X project [12], and the Connected Motorcycle Consortium has promised to bring C-ITS enabled motorcycles on the market in 2020 [13].

C-ITS solutions, which can build on standard C-ITS equipment in vehicles and infrastructure, are the most promising for safety critical applications, but require further development and testing in real environments is required.

3 Methodology

Cooperative ITS (C-ITS) systems, in which intelligent vehicles communicate with intelligent roadside units, with other road users and with back-end systems, consist of a wide range of actors and interfaces. In order to assure interoperability between components of different providers, an architecture and interfaces should be standardised. In addition, the architecture should also describe the roles of and the interaction between the different actors and components.

In the US, the Connected Vehicle Reference Implementation Architecture (CVRIA [14]) has been set up, with as target to identify the key interfaces which need to be standardised. It describe the functions, physical and logical interfaces, organisational relationships, and application dependencies within the connected vehicle environment. In Europe, ETSI EN 302665 [15] specifies the communication architecture of single ITS stations, with examples for vehicle and roadside ITS stations, which consists of 4 functional domains (Applications, Facilities, Network & Transport and Access) and 2 support domains (Security and Management).

Large vehicle-centric projects in the field of cooperative ITS have produced architectures suited to their objectives, such as DRIVE C2X [16] and CONVERGE [17]. In the Netherlands, an architecture for C-ITS applications, that is based on an eco-system with organisational roles for both public and private stakeholders has been developed [18].

In most of the above architecture descriptions, the VRU is not regarded as an active stand-alone user. An exception is the CVRIA, which includes a set of mobility use cases related to the interaction between pedestrians and traffic lights. C-ITS systems for VRUs need to build on the architecture and specifications that are set up for vehicles, and need to provide additional applications that are beneficial for VRUs.

Within 3GPP cellular, Vehicle-to-Everything (V2X) specifications, are available for inclusion in the Release 14 ([11, 19, 20]), and also address Vehicle-2-Pedestrian (V2P) use cases. The scope (including communication architecture) is vehicle centric i.e. on vehicle-to-everything, not VRU-to-everything.

The architecture analysis, described in this paper, is based on a commonly used methodology with several distinct views on the architecture, as used in e.g. [18, 21]. First the different use cases regarding the interaction between VRUs and vehicles/roadside infrastructure (like traffic lights) are identified (section 4), taking the different configurations for communication into account. Opposed to other project related architectures, which only consider the use cases related to the scope of the project, our approach start with an extensive analysis of the different use cases, including different types of VRU interaction with the system and different traffic system configurations. In our architectural approach, an additional ‘layer’ with physical and functional elements specific for VRUs is included. The reference architecture is used to develop subsystems and elements for cooperative ITS applications for VRUs. The architecture is described in three ways:

• 1. Physical architecture: high-level description of the physical ITS sub-systems used in the VRU, Vehicle, Roadside and Central layer, together with high-level description of the communication / interaction between these sub-systems.

• 2. Functional architecture: description of the functional elements within the sub-systems in the VRU, Vehicle, Roadside and Central layer.

• 3. Communication architecture: description of the type of communication and networks used between the functional elements of the physical sub-systems.

Then, starting from the use cases and the architecture, a set of requirements regarding the performance of the devices for VRUs are derived.

Based on the complexity of the requirements, and by aligning with other roadmaps for C-ITS applications, a roadmap for C-ITS applications for VRUs is defined.

4 Use cases

The analysis of VRU use cases is complex due to the large variation in VRUs. VRUs include pedestrians, pedestrians on small wheels (roller skates, kick scooters…), cyclists (normal bikes, electric bikes, high-speed electric bikes), a wide range of PTWs, and can also include animal-powered transport. Regarding the interaction and communication between the VRU and the external (vehicle or roadside) C-ITS systems, there are different possibilities for a VRU device:

• the VRU is not equipped with a device;

• the VRU has a device which can only transmit data (i.e. a tag or beacon), e.g. a C-ITS transmitter attached to a backpack or the safety vest of a worker at a road works site;

• the VRU has a device which only receives (broadcasted) data;

• the VRU has a device with both transmitting and receiving functionality.

The mobile VRU device can be either stand-alone (e.g. a smartphone), a device integrated in the VRU vehicle (bicycle, motorcycle) or a tethered device (sensors in the vehicle, communication using smartphone).

There is a wide variety in the potential traffic conflicts between VRUs and other road users. The conflicts can be categorised regarding the different situational variables: road topology (intersection, mid-block, along a road), the location of the VRU (either on a special pedestrian or cyclist lane, or sharing the same lane as cars), the traffic infrastructure (zebra crossing, signalised crossing) and visibility (line of sight, no line of sight). In addition, compliance to traffic rules (car driving through red, pedestrian crossing during red, complying with right of way rules) is a critical factor in accident scenarios. The following groups of traffic conflicts are identified:

• 1. VRU crosses road at mid-block;

• 2. VRU crosses road at intersection, car driver straight;

• 3. VRU at separate lane (crosswalk, cycle lane) at intersection, initially same direction as car going to turn across VRU path;

• 4. VRU at car lane at intersection, initially same direction as car which crosses VRU path;

• 5. VRU at special lane at intersection, car crosses VRU path;

• 6. VRU at car lane at intersection, car crosses VRU path;

• 7. VRU moves along or at the road:

• a. car coming from behind;

• b. oncoming car in the same lane;

• c. VRU overtakes car in oncoming lane;

• d. overtaking parked car (door opening);

• e. VRU in front or back of static car, intending to start/reverse.

• 8. VRU-VRU conflicts: VRUs in same lane, shared lane with oncoming traffic, crossing traffic;

• 9. Mobility related use cases: traffic light info and traffic light green request.

For each of the conflicts there are different ways in which the conflict can be detected:

• by the vehicle on-board sensors;

• by the road side unit sensors, installed at intersections or dangerous locations;

• cooperatively, by status messages exchanged between the VRU and the vehicle.

Safety services for VRUs are defined at two levels. The simplest level is ‘Awareness’: road users are warned about the presence of other road users at dangerous situations, e.g. pedestrians/road workers on a motorway, presence of pedestrians at zebra crossing, pedestrians crossing signalised intersection with conflict to turning cars. For this type of road hazard warnings, no accurate information on VRU location and speed is needed.

Using a more advanced system, also ‘collision detection’ can be implemented: the messages exchanged contain accurate data to estimate the trajectories of the different road users, to make a risk assessment of potential collision, and to warn the road users in time to take an appropriate action. In order to avoid a high number of “nuisance” warnings, high positional accuracy is required. The risk assessment can be made either at the vehicle, the roadside unit, or the VRU device.

5 Architecture for the integration of VRUs in cooperative its

The architecture is developed using the methodology described in [18, 21]. Starting from the use case analysis, the following views of the system are derived:

• Context view, in which the system that supports the selected VRU ITS applications is modelled as a black box. Nothing is known about the inside of that box. At the borders of the black box ‘actors’ are connected through interfaces. The actors identified include end users, drivers, Vulnerable Road Users, road operators and information providers. The system should support mobility for VRUs in a safe and comfortable way in the existing road infrastructure with existing road users. Cooperative communication is used to support the VRU mobility.

• Functional view: the functional description of the system is based on the use cases, identified in section 4. The functional components identified at the VRU layer include VRU Transponder (VRU-T, a tag sending only limited data), a Personal ITS station or a VRU Vehicle ITS station (able to communicate via ITS-G5), the VRU Vehicle Electrics/Electronic (E/E) system providing sensor information, and a VRU connected system (able to communicate via mobile networks with internet). At the vehicle layer, the components are Vehicle ITS station, Vehicle E/E system, Vehicle Connected System, Vehicle Sensor system and Vehicle VRU localisation system, which is a specific system to locate VRU transponders. At the Roadside layer, the components are the Roadside ITS station (RIS), Roadside substation (sensor or actuator system), Traffic light controller and Roadside VRU localisation system for VRU transponders. At the Central layer, the components are the Central ITS station, an Internet Information system for providing information to a specific application and the Traffic Management Centre.

• Communication view: a more detailed sequence diagram of each use cases is presented to show the temporal interaction of the actors with the ITS subsystems and the message flow of functional components of the different ITS subsystems.

Based on the sequence diagrams of the selected ITS applications the functional and communication architecture are derived, i.e. the actors, functional components and interfaces are plotted in the four identified layers of the physical architecture, i.e. VRU, Vehicle, Roadside and Central layer. The overall functional architecture, which is derived from the sequence diagrams, is shown in Fig. 1, and shows the functional components and actors in the four defined layers, i.e. central, roadside, vehicle and VRU layer.

Fig. 1

Functional Architecture for cooperative ITS with Vulnerable Road Users

The VRU layer covers pedestrians and VRUs with a vehicle (PTW riders, cyclists). The actors per layer are shown in the right part. Colours are used to classify the different functional systems:

• 1. Red: cooperative ITS-based systems, as defined by ETSI ITS

• 2. Orange: tag-based systems for VRU detection

• 3. Green: smartphone based system, with Internet based communication

• 4. Grey: existing non-cooperative systems used today in vehicles and along roadside.

In this functional architecture the ITS station in each layer is regarded as the component for the cooperative applications responsible for sensor data fusion, situation management / situation awareness and e.g. collision risk calculations.

6 Requirements for VRU its stations

Starting from the use cases and the architecture, a set of different requirements were derived for the functional components of the system, additional to the existing requirements for the Basic Set of Applications as defined for ETSI C-ITS systems [22]. Major requirements relate to range, latency, scalability, and position accuracy. VRU ITS stations have restricted capabilities, which should be taken into account during standardisation.

Position accuracy

For vehicle applications, ETSI TS 101539–1 [23] requires a position accuracy of 1 m. For VRU applications a similar requirement holds, however a higher accuracy (0.5 m) is desired, to be able to distinct whether the VRU is in a safe area (on a sidewalk) or not (on the road). Data received by vehicles from VRUs have to be matched with data received from in-vehicle sensors. Here, more advanced techniques like differential GNSS methods [24] could be used, or additional meta-information, e.g. by use of the smartphone camera for positioning [25]. The position accuracy issue is more challenging for VRU devices than for vehicles, as e.g. smart phone GNSS receivers have lower accuracy.

Context awareness

VRUs use nomadic devices, e.g. smart phones, in different transport modes and contexts. Starting from the data of the nomadic device’s inertial sensors (accelerometer, gyroscope, magnetometer), the context of the VRU and the transition of the VRU object state (e.g. standing, cycling, walking, starting) can be determined. Bocksch [26] identified the different possible movements of a pedestrian (standing, walking, running, falling, cycling, entering a car, lying, throwing the tag) with an accuracy of 91% for most categories. Based on the context of the VRU, the safety app on the phone should be active or dormant, in order to save power [7].

Range

One of the major benefits of cooperative safety services is the possibility to detect dangerous situations earlier than using on-board vehicle sensors. The possible conflict between VRU and cars should be detected in time, in order to be able to warn the road users to make a corrective action. The time of warning depends on the Time To Collision (TTC), and should take the user reaction time, communication latency, the time needed to perform the manoeuvre, and a safety margin into account.

The range should hence be sufficient to perform a risk assessment based on CAM information prior to issuing the warning. As an initial guideline, a minimum range corresponding to a TTC of 5 s is proposed. For oncoming traffic scenarios, this results in a range requirement of about 100 m for pedestrian and cyclists in urban scenarios (car speed 50 km/h) and 160 m in extra-urban scenarios (car speed 90 km/h).

For cars, the range of vehicle-to-vehicle communications with ETSI ITS-G5 can be about 500–1000 m, assuming line-of-sight communication at a transmitting power of 20 dBm. For battery-life reasons, VRU devices will more likely have a less powerful transmitter and antenna (e.g. 10 dBm). In case the device is held near the body (e.g. a smartphone in a pocket), the power is attenuated even more. The transmitting power of the VRU device affects range: e.g. for a 10 dBm transmitter about 300 m is achieved, for a 0 dBm transmitter 120 m [27]. Objects in the link path have a considerable effect on range, which is decreased by about 50%. As a result, a VRU with a device transmitting at only 0 dBm, which is entering the road from behind an obstacle or coming from an obstructed side road, will only be perceived by fast moving vehicles (90 km/h) at a Time To Collision of 2.4 s. This is not sufficient for the vehicle to perform a complete stop [27]. Based on the measurements performed by Jutila [27] a minimum transmitting power of 10 dBm is needed to cover time critical scenarios.

Latency

Critical road safety and pre-crash applications require an estimated 300 ms end-to-end latency time as stated in ETSI TS 101539-1 [23] and ETSI TS 101539-3 [28]. The end-to-end latency includes the communication network and the in-vehicle processing delays. The data transmission and receiving delays should be kept below 100 ms for time-critical systems with intervention. Safety systems aiming only at informing and warning can work with slightly larger latencies.

ETSI ITS-G5 allows direct communication between vehicles with latencies as low as 1 ms [27]. ITS-G5 allows direct communication between sender and receiver. In contrast, in conventional cellular communications a mobile network operator and/or a service provider which supports geomessaging capabilities are needed [17]. In addition, a geolocation server is needed at the mobile network or at a service provider, which keeps track of the location of the different road users [17]. For end-to-end tests in which a warning was sent by a driver, messages were relayed via a LTE network and a service provider to another driver in the direct neighbourhood. In this case, measured latencies were in the order of 1 s [29]. Future cellular technologies will allow much smaller latencies: LTE Release 14 targets max. 100 ms latency for V2X applications [30], evolving to 1 ms in later versions of 5G [31]. LTE Release 14 will allow using ProSe (Proximity Service) for direct communication between devices, so that the information does not have to pass through the network infrastructure. Another feature, which can be beneficial for C-ITS is eMBMS (Multimedia Broadcast Multicast Services). More research is needed on how the different technologies, and especially cellular technologies, can support VRU applications.

Scalability

The system should work in an urban environment and perform well in a use case where many road users are at the same intersection. To avoid interference and degradation of C-ITS applications based on ITS-G5, Decentralised Congestion Control (DCC) is developed in order to handle network stability. This is especially important in the absence of a coordinating access point or base station, when faced with an increasing number of C-ITS messages being emitted. DCC has been standardised in the approved ETSI TS 102687 [32] and ETSI TS 103175 [33]. This current specification is deemed sufficient for early deployment of ‘Day 1’ applications. DCC needs to be revisited for ‘Day 1.5’ applications such as automated driving use-cases (e.g. C-ACC and platooning) but also for Infrastructural and Vulnerable Road User use-cases. The increase in data volumes exchanged and the increased message behavioural requirements demand further development of the predictability of the DCC as developed for Day 1 applications. This requires that both the communication network supports this as well as the developed services. Current Distributed Congestion Control does not differentiate on type of road users, and different DCC rules may be needed for e.g. pedestrians based on their location (distance to road) and estimated intention. If all VRUs would be equipped with C-ITS devices ‘continuously’ transmitting messages at the default 10 Hz, this will cause congestion of all channels. Currently only a single channel (CH0) in the 5.9 GHz band is used for ITS-G5 applications. Multiple channels in the ITS-G5 band are needed in addition to the current CH0 channel to cope with the future increased message traffic [34].

For cellular communication systems, the scalability requirement is challenging. Previous research, e.g. ETSI TR 102962 [35], have indicated that LTE networks may be overloaded due to heavy traffic broadcasted already by 20 cars per cell at a rate of 10 CAMs per second. Solutions are hence needed which not offload CAM messages to the network, or which use more resource efficient methods for providing status information.

7 Roadmap for C-ITS VRU applications

In order to come to a deployment of C-ITS applications for VRUs, there following major issues that have to be dealt with are:

• Technical performance of devices for VRUs, including position accuracy, battery management, power consumption. For smart phone implementations, this also includes context sensing and interaction with other applications on the smartphone. For dedicated devices, this includes miniaturisation of the devices and integration of the devices in the vehicles.

• Non-distracting user interfaces and efficient warning strategies. The user interfaces should be designed so, that the user keeps the main attention to the traffic situation. Warnings should be designed to provide the desired effect, and false alerts should be kept to a minimum to ensure user acceptance.

• Standardisation of the messages exchanged. CAM and DENM messages should accommodate for the restricted capabilities of VRU ITS devices, and allow the receiving road users to estimate the trajectory of the VRU. In addition to the CAM messages, also standardisation of co-operative perception should be taken forward. Observation from VRUs from infrastructure or vehicles may result in more accurate data than VRU device location sensors. Within ETSI ITS WG1 a study of use cases and standardization perspectives on VRUs is ongoing [36]

• Privacy and security rules should be agreed. Privacy and security are major acceptance barriers in the deployment of C-ITS Day 1 applications, which have been addressed in the work of the C-ITS platform [37]. According to the C-ITS platform, users need to provide consent for non-safety critical applications. The security solution proposed by the C-ITS platform for on-board units in vehicles is based on certificates stored in a HSM (Hardware Security Module). The security solution should also accommodate for software based solutions in smart phones. Privacy of VRUs (e.g. children) is a more sensitive matter than vehicle related privacy, and hence the establishment of standardised procedures that guarantee the privacy of VRUs and the security of the messages is a critical issue.

Based on the identified challenges, and roadmaps of supporting technologies such as the roadmap of the Car2Car Communication Consortium [38], a roadmap for C-ITS applications for VRUs has been developed.

Phase 1: Basic applications

This includes applications, which do not require substantial changes to existing message sets, and can be developed using existing technology. This includes:

• Signal Phase and Timing (SPaT) for Vulnerable Road Users. C-ITS messages for signalised intersections are addressed by ISO/TS 19091 [39], and include SPaT and intersection topology (MAP). The standard includes VRU related elements, such as pedestrian sidewalks and bicycle lanes Information on the status of the traffic lights, such as time until the next phase or speed advices can be provided to VRU devices, such as smart phones. Requirements that have to be fulfilled for these applications are the integration of C-ITS communications in the smartphone, an increased accuracy of GNSS positioning for smartphones, ability to identify the relevant traffic light, and a non-distracting user interface, allowing the VRU to keep his attention to the traffic situation.

• Presence warning at crossings and black spots, e.g. automatic detection of pedestrians waiting and/or crossing from infrastructure. Roadside units send message to drivers for increased awareness.

• Motorcycle approach warning is one of the ‘Day 1’ use cases. Motorcycles share the same roads as vehicles. Requirements to be fulfilled for this application is a sufficient level of positioning accuracy, to be able to derive the lane driven by the motorcycle.

Phase 2: Advanced warning

This phase includes more advanced application, which require more advanced sensing, e.g. tracking of VRUs by infrastructure, as well as VRUs equipped with devices, either equipped to VRU vehicles or a first generation of portable VRU devices. It includes:

• Cooperative perception from infrastructure. VRUs are detected and tracked by sensors, installed at the roadside. Either the data of the VRUs is transmitted to the vehicles, which assess the risk of collision, or the roadside unit assesses potential collisions based on messages of both vehicles and VRUs. Requirements to be fulfilled for this application is an increased detection accuracy of the roadside sensor, in order to be able to perform accurate risk assessment with a low amount of false and missed alerts. Detection and tracking of cyclists was demonstrated in the VRUITS trial in Helmond.

• Equipped VRUs. First implementations of VRUs (in addition to motorcycles) will be with either beacon type of devices or bidirectional devices. The VRU vehicles expected to be first equipped with devices are vehicles with electric power source, such as e-bikes and high speed bikes, mopeds, and wheelchairs. The use cases are awareness of other road users (i.e. information on presence of VRUs) as well as collision detection, dependent on the vehicle speed and the accuracy offered by the devices. High-end motorcycles and bikes may be equipped with bidirectional devices, for other vehicles beacon type of devices will be used. Specific user groups, such as workers at high-risk areas (e.g. highway maintenance) are expected to be the first to be equipped with nomadic VRU devices, or with smartphone C-ITS apps. Requirements to be fulfilled are the integration of VRU devices in the vehicle through miniaturisation and a limited power consumption. As the positioning accuracy of the first nomadic devices is expected to be in the order of 2–5 m, the main use case is awareness.

• Smartphones with safety-related apps. The apps allow to build a local dynamic map, based on the information received from other vehicles, and assess collision risk. The apps may also allow transmission of messages, either continuously or only in the case of high collision risk. Additional applications are speed advice at traffic lights, and, dependent on message implementations, green light request. The most critical requirement is to achieve sub-meter positioning the accuracy of the smartphone sensors in order to be able to make a high quality risk assessment, as well as a sufficiently low power consumption.

Phase 3: Cooperative sensing

During this phase the accuracy and performance of VRU devices is sufficient for collision risk detection, and vehicles share the information collected by sensors with each other. This phase includes:

• VRU devices have the same functionalities as Vehicle ITS stations, and transmit status messages, perform risk management and can warn other road users of potential collisions. Both dedicated devices, either portable or integrated in the VRU vehicles, as well as smart phone apps for C-ITS will be available. The major relevant requirements to fulfil for this application are - for both the vehicle and the VRU implementations - high quality risk management, with a low amount of false and missed alarms, as well as efficient warning strategies and non-distracting user interfaces which allow the user to keep the focus to the traffic situation.

• Cooperative perception by vehicles: According to the vision of the Car2Car Communication Consortium [38], vehicles may warn other vehicles of objects detected on their path. This also includes VRUs, which are e.g. behind a corner or obstructed through other vehicles. The major requirements to fulfil are efficient and accurate identification and tracking of VRUs by vehicles, fusion of information from different sources, and efficient and non-distracting warning and communication strategies.

8 Discussion and conclusions

This paper presented an architecture for the integration of Vulnerable Road Users (VRUs, pedestrians, cyclists, PTW riders) in Cooperative ITS systems. VRUs can be either detected by vehicles or infrastructure, or have a C-ITS enabled communication device, either integrated in the vehicle of the VRU, or stand-alone (e.g. smartphone). Two levels of use cases can be identified: awareness of the presence of VRUs near potentially dangerous situations, and collision risk assessment. For the latter use case, the technical requirements for VRU devices towards sensor accuracy and calculation capabilities are challenging. Other challenging requirements are related to power consumption, context sensitivity, channel congestion, privacy and security of messages. Awareness related use cases are closer to the market, as they do not put stringent requirements to the (localization) sensors at infrastructure or vehicles. Standardisation of the messages exchanged between Vulnerable Road Users and the infrastructure and vehicles is a key issue.

C-ITS systems for VRUs have the potential to improve the safety of VRUs. C-ITS systems for VRUs will build on the infrastructure that is being deployed for vehicles, and provide additional applications that are beneficial for VRUs. However, major efforts are required to overcome the technical challenges, such as message standardisation, research and development of improved location accuracy methods and of device miniaturisation technologies. Deployment of the systems requires collaboration between all stakeholders, both local authorities, automotive industry, and end-users. Incentives, such as financial support of innovation activities, are required for development of the systems, introduction of the systems to the market and deployment of the first systems in real environments.