D45.1 Cooperative systems test case functions. Work package WP4.5 Cooperative Systems Functions. Restricted to other program participants (PP)

Transcription

1 Cooperative Systems Test Case Deliverable n. D45.1 Cooperative systems test case functions Sub Project SP4 Test Case Work package WP4.5 Cooperative Systems Tasks T4.5.1 Solutions Design Authors Joost van Doorn NXP File name Status Distribution Deserve_D4.5.1_Cooperative Systems_Test_Case Solution_Designs_1.0.docx Final Restricted to other program participants (PP) Issue date 10/01/2014 Creation date 7/10/2013 Project start and duration 1 st of September, months

2 REVISION CHART AND HISTORY LOG Ver. DATE AUTHOR REASON Joost van Doorn Initial revision created Joost van Doorn Processed NXP internal feedback Gerardo Daalderop Formatting of and Readability of legend in Pictures Joost van Doorn Solved picture readability issues Gerardo Daalderop Jose Fernandez Xavier Savatier Paul van Koningsbruggen Nereo Pallaro Joost van Doorn Defining and elaboration partner contributions and extending document outline. Collected input of WP members. Prepared document for review by WP members Gerardo Daalderop Joost van Doorn Executive summary, tuning and editing misc contributions, conclusions and outlook Joost van Doorn Version used for final WP-internal review Gerardo Daalderop Adaptations of architecture drivers Joost van Doorn Processed comments from WP-internal review. Document now ready for peer review Joost van Doorn Processed comments from peer reviewers Page 2

3 TABLE OF CONTENTS REVISION CHART AND HISTORY LOG... 2 TABLE OF CONTENTS... 3 LIST OF FIGURES... 4 LIST OF TABLES... 4 LIST OF ABBREVIATIONS... 5 EXECUTIVE SUMMARY INTRODUCTION Objective and scope of this document Structure of the document OVERALL ARCHITECTURE COOPERATIVE MODULE REQUIREMENTS COOPERATIVE MODULE HARDWARE ARCHITECTURE COOPERATIVE MODULE SOFTWARE ARCHITECTURE PARTNER CONTRIBUTIONS NXP Technolution Use case definition CRF Use case Vehicle detects other vehicles ahead Use case Vehicle approaches an intersection CTAG IRSEEM Page 3

4 LIST OF FIGURES Figure 1: General ADAS architecture... 9 Figure 2: DESERVE platform Figure 3 : Cooperative module functional blocks Figure 4 : ADAS system partitioning Figure 5 : Cooperative module configuration options Figure 6 : OEM specific antenna configurations Figure 7 : Antenna configuration tradeoffs Figure 8 : Modem location tradeoffs Figure 9 : Core standards Figure 10 : Software to system mapping Figure 11 : Software interfacing Figure 12 Vehicle centric use cases for the road traffic Figure 13 FESTA methodology definition Figure 14 Simulation framework in a scenario with two cars and ground station LIST OF TABLES None Page 4

5 LIST OF ABBREVIATIONS ABBREVIATION DESCRIPTION BSA Basic set of applications. Group of use cases that should be supported by a vehicular communication system. C2C Car to car communication. This is synonymous to V2V. C2I Car to infrastructure communication. This is synonymous to V2I. C2X Combination of Car to car and Car to infrastructure communication. This is synonymous to V2X. CFOT Cooperative field operational test FE Front End. This refers to the antenna, RF and modems parts of an ADAS system. FOT Field operational test ITS Intelligent traffic systems TCU Total control unit. This refers to one complete unit, executing both ADAS and other functionality. V2I Vehicle to infrastructure communication V2V Vehicle to vehicle communication V2X Combination of Vehicle to vehicle and Vehicle to infrastructure communication Page 5

6 EXECUTIVE SUMMARY Through the efforts of all partners in WP4.5 the definition, simulation and development, testing and demonstration of cooperative functionality within the framework of the comprehensive cooperative ADAS system of DESERVE is brought together. This encompasses the definition and development of a plug-and-play cooperative module with well-defined hw/sw interfaces, a real-time simulation and testing framework and their actual testing, the development and demonstration of live system labdemonstrators with a few use cases that are today relevant in the combined domain of ADAS & ITS, as well as an evaluation how OEM introduction can be technically feasible. The specific partner investigations and contributions can be summarized as follows: 1. NXP is researching and developing a small-form-factor cooperative module, with a specific attention to a modular system-architecture with well-defined hw/sw interfaces, a pre-requisite to keep cooperative ADAS system complexity under control. Interoperability of the module at communication level will be tested. NXP will also collaborate with other WP45 members to realize vehicle- and/or labdemonstrators using the cooperative module. 2. TECHNOLUTION has investigated and will develop live system lab demonstrators showing at least the use case Collision warning/slow vehicle ahead, which combines ADAS with ITS functionality. Possibly the use cases Traffic flow drop warning, Merge assistance and Traffic jam tail warning will be shown. These use cases are extensions to the basic use case Collision Warning. The lab demonstrator utilizes the cooperative module, the insights from the DESERVE architecture and the simulation and testing requirements, and will be shown at the EC review of the 2 nd year of the DESERVE project. 3. CRF will provide a description of the use case Collision warning/slow vehicle ahead and a description of the software architecture related to this. CRF will also demonstrate the use case on simulation level. The insights and requirements that CRF develops will be taking into account in the development of the Collision warning/slow vehicle use case mentioned above. 4. CTAG contributes to methods on testing of V2X communication and V2X use cases, bringing in their past learning s and test-infrastructure inherited from several Cooperative Field Operational Tests (CFOTs) carried out. They will investigate the swap of the cooperative module in their test infrastructure with a DESERVE cooperative module. Based on this investigation CTAG will decide whether a swap will be performed. If the swap is performed CTAG will test existing use cases using the DESERVE cooperative module, to validate interoperability at the application level. 5. IRSEEM will describe the possible incorporation of the cooperative module into RTMaps and the Pro-Sivic simulation framework. IRSEEM will also describe the enrichment of an already existing ADAS use case with the cooperative module. This description will provide input on the minimally required interface that needs to be provided by the cooperative module. The perceived benefits of the enrichment are indicated Page 6

7 In addition to an elaboration of the topics mentioned above, this deliverable also provides a more detailed description of the analyzed requirements and the design of the cooperative module in the context of a cooperative ADAS system. Described are the following aspects: 1. The overall architecture of ADAS, emphasizing the benefits of a cooperative module. 2. Top level requirements of a cooperative module within such architecture. 3. The modular hardware architecture of the cooperative module. Modularity is a key aspect to be able to fulfill the various business and application requirements of the different OEMs. 4. The ETSI software stacks running on the cooperative module and the interfaces provided by such stacks. These software stacks are essential to fulfill ADAS requirements. 5. A selection of the relevant software stacks (CAM and DENM), shown to be sufficient for the above use cases Page 7

8 1. Introduction In WP 4.5 the test case functions for the DESERVE platform addressing the cooperative systems functions will be defined, designed and developed, up to the stage of working prototypes, including shark fin RF integration, tuner, flexible baseband and protocol SW. Cooperative systems functions are the ones involving the vehicle to vehicle (V2V) and the vehicle to infrastructure (V2I) communication to provide reciprocal awareness (and to share the benefits deriving from this awareness) among the vehicles and the infrastructure nodes in the cooperative system. Examples of these functions are: Intersection support, to get the awareness of other crossing vehicles. Collision warning. Hazardous location warning. Traffic light information, to get information on current traffic light status and timing as well as optimal speed advisory. Speed limit information, to show regulatory or context dependant speed limit on the instrument panel Objective and scope of this document The objective of task T4.5.1 Requirement analysis and solution designs of Work Package WP45 Cooperative systems functions is to analyze the requirements of the DESERVE platform and define solutions for the cooperative systems functions. These requirements span commercial vehicles to passenger cars to other types of vehicles. Therefore, the solution design has to take into account that the system should be flexible enough to be used in different kinds of vehicles using different equipment. Furthermore, requirements from the data sensing, processing units, infrastructure nodes, etc. are made explicit Structure of the document This deliverable is structured using the following chapters: Chapter 2 describes the structure of an Advanced Driver Assistance System and the role of a cooperative module within an ADAS. Chapter 3 describes the top level requirements of a cooperative module. Chapter 4 describes the hardware architecture of a cooperative module. Chapter 5 describes the software architecture of a cooperative module, including the mapping of the software on the system parts. Chapter 6 describes the contributions of the partners involved in this work package Page 8

9 2. Overall architecture The general architecture of an Advanced Driver Assistance System (ADAS) is described in Figure 1, below. Figure 1: General ADAS architecture Within the classical ADAS functions sensing is done by on-board devices. Some of this sensing can be replaced by direct communication between vehicles of the relevant information (e.g. position, speed, identification of the obstacle type: truck / vulnerable road user, etc). Direct communication can also be used to propagate sensed information to other vehicles. This increases situational visibility beyond the direct environment of the vehicle and provides the advantage of early information on traffic behavior leading to improved anticipation on changing traffic situations, e.g. braking cars in front of a truck when driving at the back of a truck. As a consequence, the direct communication can extend the horizon of the driver and car beyond what physical sensors are able to accomplish, potentially improving both safety and comfort of driving. A second role of the direct communication is to provide information from and to the roadand traffic-management infrastructure. For example, dynamic maximum speed, the existence of traffic jams and the propagation of the tails of such traffic jams can be derived and communicated in both directions Page 9

10 A third role of the direct communication is to keep systems and databases up to date. For example, it will be important to make maps more accurate and keep them up to date. In addition all software will need to be kept up to date. Because of the less stringent timing constraints, it is expected that cellular (UMTS/LTE) and normal wifi direct communication (IEEE abgn) will be used in these cases. All direct communications with very stringent timing constraints, where real-time communication is required, is handled by the cooperative module. A cooperative module is considered to be a virtual sensor within the ADAS context, playing a role next to more conventional sensors (e.g. camera, lidar and radar) in sensing the environment of a vehicle. The cooperative module is special since it does not only provide input data into the ADAS Sense part (also known as the DESERVE Perception Platform). The module also provides output data from the ADAS Think part (also known as the DESERVE Application Platform). So in summary, there are a number of drivers to promote cooperative modules in automotive architectures: Increasing safety. Also the cost associated with adding an active safety shell is smaller than the cost involved in increasing passive safety. Increasing comfort. Comfort is increased by accurate and up to date information in advance; both the driver as well as the ADAS-functions and automated driving manouvres of the vehicles can anticipate better, leading to more comfortable (besides safer) driving. Improved dynamic traffic information and traffic management. Besides a clear informational benefit for both driver and government, with benefits as stated above, it can also lead to improvements in the driver-style leading to reduced CO2 emission and fuel-usage. Connectivity can support the systems in the vehicle to stay up to date, this will become increasing important. Within the context of the DESERVE platform the interaction with the cooperative module is described in Figure 2 below. Here the cooperative module is presented as V2X node. The figure states V2X nodes with both roles of providing input data into the platform and providing output data from the platform Page 10

11 Figure 2: DESERVE platform Examples of generic ADAS use cases that benefit from a cooperative module are: 1. In-Vehicle signage: Using V2X communication information on current valid traffic signs is given to the driver. 2. Electronic emergency brake light: Emergency brake lights are switched on when a vehicle brakes hard. The hard braking condition is communicated onwards to following vehicles using V2V communication. 3. Emergency vehicle warning: Using V2V communication an active emergency vehicle can indicate its presence. Other vehicle will give way to the emergency vehicle. 4. Stationary/slow vehicle warning: Using V2V communication a stationary or slow vehicle signals its presence to other vehicles. 5. Motorcycle approaching warning: Using V2V communication a driver can be warned for an arriving motorcycle. 6. Transparent truck: Using V2V communication the vehicle driving at the back of a truck is signaled by the vehicle driving in front of the truck it is breaking. 7. Cooperative adaptive cruise control: Acceleration and deceleration of the vehicle are controlled automatically using information from preceding vehicles. This information is communicated using V2V communication. 8. Cooperative lane change: Using V2V communication neighboring vehicles provide information on current position, speed, direction, etc. This information is used to assist the driver in changing lanes. An overview of the DESERVE specific use cases is presented in WP Page 11

12 Within the framework of DESERVE the use cases addressed by OEMs do not deploy a cooperative module. However, a few use cases are foreseen to be demonstrated with non-oem partners. More specifically, we anticipate use cases 4 and 6 of the list above may be demonstrated by non-oem partners in DESERVE. This will be clarified further in the 2 nd year of the DESERVE project. Information on the contributions of the work package partners is described in chapter Page 12

13 3. Cooperative module requirements The top-level requirements of a cooperative module are all related to four specific areas: 1. Timing. 2. Amount of messages. 3. Security. 4. Operational conditions. Timing All use cases have their own specific timing requirements as is also elucidated in supproject 2 of DESERVE. We foresee that two types of standardizes messages can fulfill the requirements, namely CAM and DENM. 1. CAM (Cooperative Awareness Messages): These messages contain information on current position, current speed, current direction, etc. This information is sent between 2 and 10 times per second. A maximum delay of 300 milliseconds is guaranteed. This delay is measured from the moment the information is put into the perception layer of the sending vehicle, until the moment the Intervention- Warning-Information Controller action starts at the receiving vehicle. 2. DENM (Distributed Environment Notification Messages): These messages contain information on special occasions (e.g. accidents, road condition warning). A maximum delay of 300 milliseconds is guaranteed. This delay is measured from the moment the occasion is detected in the perception layer of the sending vehicle, until the moment the Intervention-Warning-Information Controller action starts at the receiving vehicle. Amount of messages. In terms of implementation the cooperative module fulfills 2 roles. It can be a sender (ACT part of the architecture, in Figure 1) or it can be the receiver (SENSE part of the architecture, in Figure 1). These roles imply different performance criteria in terms of messages processed per second. For the sending part this indicates roughly 20 messages per second. For the receiving side one vehicle will need to process all the sending vehicles in the neighborhood, resulting in a number of messages 10 to 100 times more (max 2000). Security In this case security refers to two different topics: 1. Verification. A correctly verified message implies that the content of the message has not been changed, from the moment the verification information was created and the message was sent, until the message is received and the content of the message is verified using the verification information. 2. Authentication. A message that can be authenticated implies the received message has been sent by a trusted sender. 3. Privacy. Exchanging messages must be done in a way that protects the privacy of the owner/driver of the vehicle Page 13

14 Operational conditions The most important operational condition in which a cooperative module must be able to operate is the condition of high speed of the vehicles. It has been specified that a cooperative module must able to operate up to a vehicle speed of 200 km/hour. In general, it is important to consider requirements on availability and performance of the cooperative module Page 14

15 4. Cooperative module hardware architecture DESERVE is about platform architectures, tools and methodologies for ADAS systems. Considering the business and application requirements for ADAS it is clear a large amount of flexibility needs to be provided. From our investigations it has also become clear that the cooperative subsystem needs to show a high degree of modularity and a simple interfacing between such a module and the overall architecture. These two aspects are explained below. Functionally, the cooperative module can be divided into several blocks. These blocks are listed in Figure 3. Interfaces between these blocks are indicated using dashed vertical lines. The horizontal solid line indicates there are two different antenna/modem configurations: Combination of one antenna (roof antenna) and a modem. Combination of two antennas (roof and mirror antenna) and a modem. AR AR/AM M M S A HMI AR Antenna roof AM Antenna mirror M Modem S Security & Network A Application & Facilities HMI Human Machine Interface Figure 3 : Cooperative module functional blocks Based on these functional blocks ADAS systems can be partitioned in several ways. System partitioning can be centralized or distributed. Either a single or dual antenna system can be defined. Within a dual antenna system the locations of the antenna can vary. Possible ADAS system configurations are listed in Figure 4. Figure 4 : ADAS system partitioning Page 15

16 By combining the functional blocks of the cooperative module in order to realize the desired ADAS system partitioning, an OEM can define various system configurations. Figure 5 presents an overview of configuration options of the cooperative module. The horizontal axis shows a variation in location of the modem. The vertical axis shows a variation in antenna configuration. Figure 5 : Cooperative module configuration options The antenna location and configuration is OEM specific since the shape of a car has a large impact on the quality of signal reception. In general, it can be stated that a dualantenna configuration performs better than a single-antenna configuration. Within the dual-antenna configurations a remote configuration performs better than an adjacent configuration. Reception graphs of the different antenna configurations are shown in Figure 6. The vertical axes in the graphs show the lateral direction. However, going from a single-antenna configuration through a dual-antenna adjacent configuration to a dualantenna remote configuration not only improves performance but also increases complexity and cost. An OEM has to do tradeoff analysis to come up with the optimal solution, which is specific to every type of car. Figure 7 and Figure 8 present the tradeoff aspects when considering different antenna configuration and modem locations Page 16

17 Figure 6 : OEM specific antenna configurations Figure 7 : Antenna configuration tradeoffs Page 17

18 Figure 8 : Modem location tradeoffs Interfacing to DESERVE platform The cooperative module is connected to the DESERVE platform using USB or Ethernet Page 18

19 5. Cooperative module software architecture A wide variety of standards are worked on and finalized in ETSI and IEEE. They have various degree of maturity. A few are finalized, most are under development. Figure 9 provides an overview of the core ETSI standards. All standards are linked to the layers in the software platform. Whether or not the standard is under development or finalized can be derived from the name of the standard: If the name of the standard starts with EN then the standard is finalized. If the name of the standard starts with TS or TR then the standard is under development. Figure 9 : Core standards The list below contains short descriptions on the most important standards: EN ITS G5 Access Layer: This standard describes how the network is accessed. It is basically a mapping of IEEE802.11p incorporating European specific changes. EN /2 Geonetworking: This standard describes geographically bound communication, for example used to exchange information on road conditions. EN BTP (Basic Transport Protocol): This standard describes the format of the low-level packets which are used as containers for the higher level messages. EN CAM (Cooperative Awareness Messages): This standard describes the format of the messages that are used to publish vehicle information. These Page 19

20 messages contain current position, speed, direction etc. They are sent at a frequency from 2Hz to 10Hz, using a single-hop broadcast. EN DENM (Distributed Environmental Notification Message): This standard describes the format of the messages that are used in case of special occasions, for example accidents and road condition warnings. These messages are sent based on events, using multi-hop or geonetworking broadcast. TR LDM (Local Dynamic Map): This technical report describes the conceptual data store that is located within an ITS station. It contains information that is relevant to the safe and successful operation of ITS applications. Data can be received from a range of different sources such as vehicles, infrastructure units, traffic centers and on-board sensors. The data range from very static to highly dynamic data (road topography, static speed limit, signs and signals, road works, temporary speed limits, current information on vehicles or infrastructure nearby). TS RHS (Road Hazard Signaling): Road Hazard Signaling is one of the applications within the defined Basic Set of Applications (BSA), as defined by ETSI. This document describes the application requirements of the application. Goal of the application is present a warning between 6 and 30 seconds before actual collision. TS ICRW (Intersection Collision Risk Warning): Intersection Collision Risk Warning is one of the applications within the defined Basic Set of Applications (BSA). This document describes the application requirements of the application. Goal of the application is to present a warning between 2 and 6 seconds before actual collision. TS LCRW (Longitudinal Collision Risk Warning): Longitudinal Collision Risk Warning is one of the applications within the defined Basic Set of Applications (BSA). This document describes the application requirements of the application. Goal of the application is to present a warning between 2 and 6 seconds before actual collision Page 20

21 Mapping of software on the system parts Figure 10 presents an overview of all the ETSI software parts that are involved in an ADAS system, along with the deployment within the ADAS system. On the right side the system parts of an ADAS system are listed. They are already described in chapter 4, more specifically in Figure 3. The arrows originating from each system part encapsulate the software parts that are mapped onto this system part. For example: The software parts CAM and DENM reside in the system part Security & Network. Figure 10 : Software to system mapping Page 21

22 Use of software in selected use cases In general software that implements the CAM and DENM standards provide sufficient functionality to realize a lot of the ADAS use cases. The generic ADAS use cases that will be developed first, for example Electronic Emergency Brake Lights, Hazardous Location Notification, Working Area Warning and Approaching Emergency Vehicle Warning, can all be addressed using only information defined in the CAM and DENM standards. In particular the use cases we have selected in our work package, Stationary/Slow Vehicle Warning and Transparent Truck, can be addressed by using the information defined in the DENM standard. Figure 11 again shows the overview of the core ETSI standards. This figure emphasizes the scope of the software that is provided by NXP and the interfaces with the applications. NXP provides all the software enclosed by the red border with the cooperative module. In order to develop a use case the interfaces at the top of the CAM and DENM parts have to be used. Figure 11 : Software interfacing Page 22

23 6. Partner contributions 6.1. NXP Provide cooperative module and collaborate with partners to realize demonstrators Since NXP is developing the cooperate module their main contribution is to provide the cooperative module. The role of the cooperative module within an ADAS system as well as the hardware and software architecture is explained in the previous chapters. NXP will also collaborate with other WP45 partners to realize lab/vehicle demonstrators Technolution Technolution will develop a lab demonstrator using the cooperative module. This lab demonstrator will be shown at the EC review of the 2 nd year of the DESERVE project. The use cases that will be addressed by this lab demonstrator are described in the paragraphs below Use case definition More sensors, more and more accurate data Modern vehicles produce a lot of real time data coming from measuring dynamic vehicle properties like realized speeds, wipers on/off, break condition, headlights on/off, etc. This mesoscopic data reaches the central board computer. On microscopic level, vehicles use advanced sensors like radar, ultra sound or camera vision to scan and interpret the direct surrounding. Only the interpreted data is sent to the central board computer to assist the vehicle driver with ADAS functionalities. In the DESERVE concept the smart sensors share (parts of) the microscopic data level with a central board computer to allow sensor data fusion on the mesoscopic level. One step further, the smart sensors can share what they have seen on the road in their direct surroundings and even with service centers, where this car vision data will be used to enhance the traffic state estimation. This one step further is the key of this project and forms the basis of the set of selected use cases. In modern vehicles the sensors tend to produce lane accurate data. The ADAS functions shift to a driver lane oriented level. GPS reaches lane accuracy; radar and camera provide enough lane information to build lane departure and lane based collision prevention systems. Selection of use cases A subset of possible use cases is selected based on the need for smart and lane oriented ADAS functions within reach of the sensors available today Page 23

24 An advanced driver assist system or in short ADAS can support the driver on different driving tasks. With the focus on ADAS for dynamic lane guidance, four vehicle centric use cases will be detailed out. These are (Figure 12): Collision warning: Warning for an on-coming obstacle on the traffic lane, like a slow driving truck. Traffic flow drop warning: Warning for a sudden speed drop of a cluster of vehicles downstream on the traffic lane / carriage way, like a cluster passing a platoon of trucks. Merge assistance: An assistant that guides to a gap in the traffic flow on the adjacent traffic lane, useful for vehicles on a short on-ramp that need to find a gap in a platoon of trucks. Traffic jam tail warning: Traffic jam signalization functionality brought into the vehicle. The basic use case is Collision warning, which comes down to obstacle detection in the form of a preceding vehicle that drives slowly or is even in a stand-still mode on the same traffic lane. The other three use cases build on this basic use case and concentrate on recognizing the traffic pattern that caused the preceding vehicle to decelerate or accelerate suddenly. The use cases differ in the available time to react ( T) and the distance to the vehicles to react on. Note that in these use cases the ADAS system does not intervene in the vehicle, the system only signals the driver. Collision warning Traffic flow drop warning Merge assistance Traffic jam tail warning Figure 12 Vehicle centric use cases for the road traffic Page 24

25 In order to describe the vehicle centric use cases in more detail the following definition of traffic lanes is used: 1 = right traffic lane 2 = traffic lane left to traffic lane number 1 3 = traffic lane left to traffic lane number 2 and so on Collision warning A vehicle is driving on a traffic lane on the highway. Another vehicle is driving with a significant lower speed or is even standing still on the same traffic lane in front of the driving car. The collision warning system detects the preceding, stalled vehicle, checks the speed difference and gives a collision warning to the driver of the vehicle. The driver notices the collision warning and starts to brake to prevent a collision. An accident is prevented. Detailed consideration A formula should be derived and tested to get a good balance. The collision warning should not come too late, for then an accident is not prevented. A collision warning must also not be given to early, because this can be annoying for the driver. The V2V communications can be supported by obstacle detection via radar and camera. Traffic flow drop warning The traffic flow on a motorway can drop quite suddenly due to significant differences in speed between vehicles and severe braking by on-coming vehicles. Such drops in the traffic flow occur, for instance, around an emerged platoon of trucks, especially when trucks in the platoon overtake slower driving trucks with a minimum of speed difference, thereby blocking the middle or left traffic lane for longer time for faster driving passenger vehicles. A dynamic cluster of vehicles emerges that moves over the motorway with the speed of the original platoon of trucks. In the pre-cluster phase a platoon of trucks should be recognized by vehicles on the traffic lane number 2 as potential risk for cluster forming and corresponding drop in the traffic flow. No warning or advice needs to be given; the detected truck platoon will be communicated with vehicles downstream. In the pre-cluster as well as in the cluster phase an overtaking truck should warn vehicles downstream of the risk of cluster forming or continuation of the clustering. In the cluster phase on-coming vehicles that had to brake, need to recognize the platoon of trucks in the cluster that caused cluster forming. The detected truck platoon will be communicated with the vehicles downstream. Detailed consideration The difference between the collision warning function and the traffic flow drop warning function is the use of information on multiple lanes and optional context information from other vehicles in front of the vehicle. Inter-vehicle communication can give information about actual driving speed and speed drop of other cars even earlier than the sensors in the car can detect the situation. This information can be used to filter if a detection is valid and thus when to inform the driver. The traffic flow warning is given earlier than a collision warning. If the driver does not adapt its speed and the distance is shortened, a collision warning will be given Page 25

26 Traffic jam tail warning A vehicle that has had to brake for a slow driving vehicle or a vehicle in a stand-still mode on the same traffic lane should recognize whether it is a singular vehicle it had to stop for, or a vehicle in the tail of a queue. Once the vehicle has dropped its speed, it should recognize whether it has stopped for one vehicle or has joined a queue consisting of a preceding vehicle driving with tempered speed and multiple vehicles driving with a harmonized speed and short headways on the adjacent traffic lanes. Detailed consideration A vehicle is driving on a lane on the highway. In front of the vehicle a traffic jam causes vehicles in stop and go traffic. Sensors in the vehicle detect the lower traffic speed on multiple lanes and give traffic jam warning to the driver of the vehicle with a speed indication to drop to. The driver adapts his speed to the proposed speed. The difference between the collision warning function and the traffic jam warning function is the use of information on multiple lanes and optional context information from other vehicles in front of the vehicle. Inter-vehicle communication can give information about actual driving speed and speed drop of other cars. This information can be used to filter if a detection is valid and thus when to inform the driver. The warning is given earlier than a collision warning. If the driver does not adapt his speed and the distance is shortened, a collision warning will be given Page 26

27 6.3. CRF CRF will address two possible use cases for the V2x based speed adaptation function: Vehicle detecting other vehicles ahead Vehicle approaching an intersection One use case will be selected to be demonstrated on simulation level using the DESERVE tool chain. How the simulation will be implemented will be defined at the beginning of task T Development of prototype solutions is depending on synergies with partners involved in WP45 and availability of some key software perception modules. In the following paragraphs a detailed description of the above mentioned use cases is provided Use case Vehicle detects other vehicles ahead Use Case Name Short description Goal Constraints Driving situation Risk s source and mitigation Successful end condition Failed end condition Vehicle detects other vehicles ahead. The presence of other vehicles ahead of the ego vehicle requires an update of the target speed profile to avoid accidents. Driving improvement and safety Precise vehicle position related to the position of the other vehicles, information about vehicles speeds, legal speed limit on the road. The egovehicle moves on a generic road, and it knows the presence of other vehicles due to the communication with them. These vehicles move on the same road, on the same lane and with the same direction of the egovehicle. The Speed Assist system uses the information of the other vehicles position and speed, together with the legal speed limit on the road, to modify the speed profile of the vehicle, in order to avoid manual braking by the driver. Wrong position of the vehicle if compared with the position of the other vehicles, wrong speed information from other vehicles. Speed Assist evaluates the correct speed profile to drive the vehicle on the road with other vehicles ahead. The vehicle approaches the other vehicles with Page 27

28 high speed that requires manual braking from the driver. Scenario Description Step Action Ego vehicle approaches other vehicles on the same lane and with a higher speed. The precise positioning of the vehicles and the speed of the vehicles and of the egovehicle is processed from the Speed Assist system, together with the legal speed limit on the road. The Speed Assist algorithm computes the correct speed profile, eventually reducing the reference speed, to drive the vehicle toward the other vehicles without collisions. The ego vehicle is automatically driven on the road without a manual brake requested to the driver. Environmental conditions /road conditions Pre-condition Post-condition Inefficiencies Good weather conditions and road status. Vehicle approaching other vehicles. Vehicle moving behind the other vehicles in automatic way. The absence of precise positioning of the egovehicle and of the other vehicles does not allow to evaluate the correct speed profile, and requires manual braking from the driver, which is not ecological Page 28

29 Use case Vehicle approaches an intersection Use Case Name Short description Goal Constraints Driving situation Risk s source and mitigation Successful end condition Failed end condition Vehicle approaches an intersection Vehicle approaches an intersection. The vehicle could have the right of way; in this case the correct manoeuvre is to keep the current speed. If the vehicle has to leave the road to the others because it does not have right of way, or because other vehicles are already in the intersection, the speed shall be reduced. Cross the intersection with the correct speed profile. Precise vehicle position related to the position of the intersection and knowledge about the right of way. Vehicle approaching the intersection at a predefined target speed. The target speed shall be updated as function of the right of way for that intersection. Wrong position of the vehicle if compared with the position of the intersection. This does not allow the Speed Assist system to make the appropriate manoeuvre, and could require manual braking by the driver and a consequent manual driving. Approach made automatically from the Speed Assist, with optimal speed management and crossing of the intersection in a comfortable way for the driver. The approach to the intersection is done with wrong speed profile, which causes the driver to force a possible acceleration or deceleration as function of the right of way. Step Action Scenario Description 1 Ego vehicle approaches the intersection. 2 The precise positioning of the intersection is processed from the Speed Assist system together with the position Page 29

30 of the vehicle, the right of way and the possible presence of other vehicles already crossing the intersection. 3 4 The Speed Assist algorithm chooses the correct speed profile to be actuated. The ego vehicle is automatically driven toward the intersection from the Speed Assist system. Environmental conditions /road conditions Pre-condition Post-condition Inefficiencies Good weather conditions and road status. Vehicle approaching the intersection with a predefined speed profile. Vehicle crossing the intersection automatically driven from the Speed Assist. The absence of precise positioning among the ego vehicle and the intersection, or the missing knowledge about the right of way causes a wrong autonomous manoeuvre, which forces the driver to shift to manual driving Page 30

31 6.4. CTAG CTAG contributes to methods on testing of V2X communication and V2X use cases. They will describe their past experience, methods and learning s in this field and will investigate the swap of the cooperative module in their test infrastructure with a DESERVE cooperative module. Based on this investigation CTAG will decide whether or not a swap will be performed. If the swap is performed CTAG will test existing use cases using the DESERVE cooperative module, to validate interoperability at the application level. The experience, methods and learning s of CTAG are described in the paragraphs below. Vision on how to test cooperative modules The detailed contribution of CTAG in year 2 is to be determined. CTAG role within DESERVE WP45 will be focused on testing those functions which may come up from this WP. The reason of this statement should be found on taking advantage of the experience that CTAG has gained on this kind of tasks after carrying out a couple of C2X Field Operational Tests (FOTs): SISCOGA (National FOT) and DRIVE C2X (European FOT). The functions tested during the execution of these two FOTs were: Car Breakdown Warning (CBW) Traffic Jam Ahead Warning (TJAW) Road Works Warning (RWW) Weather Warning (WW) In Vehicle Signage (IVS) All these functions were tested under a naturalistic approach making use of the almost 100 km of highway and motorway roads close to the area of Vigo city where high traffic density, sharp bends, slopes, tunnels, variable speed limits and weather conditions are usual. In order to gather all the potential information derived from this conditioning, 30 road side units were installed and connected to the DGT (Spain Ministry of Traffic) network and making them capable of obtaining in real time information from the 21 cameras, 19 Variable Message Signs and 10 Weather Stations deployed along the mentioned area a permanent corridor to test cooperative functions is now established. The following steps were taken in order to carry out all the previously mentioned tests: Selection of methodology to define functions to be evaluated. FESTA methodology ( was elected due to being recognized at European level as an optimal medium to verify the impact of new systems within a real environment and identify the potential benefits from them. The base of this methodology is the comparison between the effects which a determinate function may have on traffic (experimental phase) and what happens when the function is not available (base line) by means of collecting data from driving sessions. In this sense, the principal impact areas evaluated are: o o o o Safety Driver behavior Efficiency Fuel consumption Page 31

32 Figure 13 FESTA methodology definition Intelligent corridor deployment and vehicles preparation (see the provided overview of this task in the previous page). FOT execution, comprehending, as commented, a base line period (20% of FOT execution time) and an experimental phase (80% of FOT execution time). Previous to this, a piloting phase was carried out in order to verify everything is ready for FOT. During the FOT execution both subjective data (e.g. questionnaires, personal interviews with participants ) and objective data (e.g. vehicle data speed, brakes usage, wipers activation -) were collected in order to evaluate the system and its associated functions. Analysis and evaluation of collected data. Cooperative technologies evaluation in terms of measuring how much quality and reliability of the available information concerning the vehicle environment may be improved and how it may affect the different impact areas previously exposed is the final goal of FOTs. In parallel, user acceptance with respect to the usage of these technologies may be evaluated as well. Besides, within the DRIVE C2X framework, also other functions were tested under a controlled environment (test track). These ones were: Green Light Optimal Speed Advisory (GLOSA) Approaching Emergency Vehicle (AEV) Page 32

33 6.5. IRSEEM IRSEEM will describe the possible incorporation of the cooperative module into RTMaps and the Pro-Sivic simulation framework. IRSEEM will also describe the enrichment of an already existing ADAS use case with the cooperative module. This description will contain a hint on the minimal required interface that needs to be provided by the cooperative module and the perceived benefits of the enrichment are postulated. The possible incorporation of the cooperative module into RTMaps and the Pro-Sivic simulation framework is described in the paragraphs below. Simulation and virtual testing for cooperative system functions In order to demonstrate the benefits of DESERVE development platform for the integration of cooperative systems in ADAS functions, test and evaluation have to be done at the application level i.e. testing a connected vehicle into a broad variety of situations: highway, urban area, with or without other collaborative vehicles in the vicinity Testing in such a variety of situations, which can be hard or dangerous to reproduce, is better achieved using simulation software instead of real hardware. A complete simulation however has the disadvantage of excluding the real system from the testing process and limit the effectiveness of this approach. A mixed solution is known as hardware-in-the-loop and allows including real hardware into a simulated environment which allows a broad testing of both the real hardware and embedded software stack. This approach will be implemented to help the development of intelligent ADAS systems designed to use data from, or provide data to other vehicle through the collaborative module. In DESERVE SP2, a virtual testing framework is developed using Pro-Sivic simulation software. Pro-Sivic will allow simulation at the perception layer (camera, lidar ) helping the design of ADAS with RTMAPS. As described in SP2 specifications, collaborative and communication functions should be considered as virtual sensors. Including cooperative functions in Pro-Sivic/RTMAPS simulation framework will permit the setup of a virtual testbed for DESERVE SP4 and SP5. Communication functions integrated into the DESERVE simulation framework should be considered at the application level to allow testing complex ADAS relying on both real sensors like cameras, but also the virtual sensors given by the collaborative functions described in this report. Simulation framework description The simulation framework is build around two main pieces of software: RTMaps and Pro- Sivic. RTMaps is a component-based development platform. It will be used for execution of the simulation framework, implemented as a set of RTMaps components. Pro-Sivic is a multi-sensor simulation engine. It will provide simulated sensor data based on a virtual environment description, vehicle position and sensor model. Hardware-in-the-loop The simulation framework allows embedding real hardware into the simulation loop to test the real system. The HIL bench is built around a 4WD chassis dynamometer controlled by the simulation framework. This setup allows to embed a complete vehicle Page 33

34 which runs the DESERVE software stack on its computer into a simulated environment. The vehicle sensors are replaced by their simulated counterpart. The connection between the simulation software and the embedded processor is done using CAN bus or dedicated interfaces and allows the simulation of various sensors (cameras, lidar, radar, ultra-sonic rangefinder ). This hardware-in-the-loop test bench allows various level of virtual testing : from full software-based simulation where the DESERVE stack is running on a desktop computer and all sensor inputs came from the simulation software, up to full HIL simulation where a complete car is in the loop. Cooperative module simulation In this WP, the simulation framework will be expanded to simulate the communication behavior of the collaborative module. The selected approach uses an application-level simulation where the communication packets are broadcasted to all actors (other vehicles, ground stations ) in a given distance radius. More complex wave propagation models will not be investigated as this is outside of the scope of this simulation framework. This simulation will help to develop complex ADAS using the DESERVE perception layer as input, including virtual sensors provided by the cooperative system. Various scenarios can be implemented to validate the DESERVE platform approach. For example, a vehicle equipped with numerous sensors can broadcast information about the surrounding environment (pedestrian position and motion vector, obstacles positions, ) while another vehicle equipped with only basic sensing ability can benefit from this information to recognize objects which were previously detected but unclassified; or improve its knowledge of the surrounding environment beyond its own sensor range. This scenario can also use a Ground station responsible for maintaining a local dynamic map of road segments and current obstacles. Such map is used and updated by vehicles in the vicinity. Figure 14 Simulation framework in a scenario with two cars and ground station Page 34