D7.4.5 System Conformance & Interoperability Tests - Safespot

Deliverable D7.4.5

Copyright SAFESPOT

Dissemination Level (PU)

Contract N. IST-4-026963-IP

SAFESPOT INTEGRATED PROJECT - IST-4-026963-IP DELIVERABLE

SP7 – SCORE – SAFESPOT Core Architecture System Conformance & Interoperability Tests

Deliverable No. (use the number indicated on D7.4.5 technical annex) SubProject No.

SP7

SubProject Title

SCORE

Workpackage No.

WP7.4

Workpackage Title

Exploitation Convergence & Certification

Task No.

T7.4.3

Task Title

C2C & C2I Test System Assessment

Authors (per company, if more than one Main Authors: company provide it together) J. Ibanez-Guzman, A. K. Mokaddem, (Renault) U. Staehlin, Y Xiuxun (Continental) A. Plaza (AT4 Wireless) S. Zangherati, F. Sommariva, G. Vivo (CRF) E. Nordin (VOLVO) A. Spence (MIZAR) D. Willemsen (TNO)

Status (F: final; D: draft; RD: revised draft):

F

Version No:

1.6

File Name:

SF_D7.4.5_System Conformance and Interoperability Tests_v1.6.doc

Planned Date of submission according to TA:

April 2010

Issue Date:

July 2010

Project start date and duration

01 February 2006, 48 Months


Page 1 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



Revision Log Version

Date

Reason

Name and Company

0.1

20/04/2010

First Draft

A. K. Mokaddem J. Ibanez-Guzmán (Renault)

0.2

10/05/2010

Contribution Vehicles Renault

J. Ibanez-Guzmán (Renault)

0.3

11/06/2010

Contributions Communications

A. Plaza (AT4 Wireless)

0.4

11/06/2010

Contributions Infrastructure

A. Spence (MIZAR)

0.5

17/06/2010

Contribution Vehicles CRF

G. Vivo (CRF)

0.6

18/06/2010

Contribution Vehicle TNO

D. Willemsen (TNO)

0.7

20/06/2010

Contribution Vehicle Volvo

E. Nordin (Volvo)

1.0

23/06/2010

Document Compilation, Introduction & Conclusion


1.1

29/06/2010

Revision and integration of summaries; overall review

S. Zangherati F. Sommariva (CRF)

1.2

30/06/2010

Final revision

G. Vivo (CRF)

1.4.1

07/07/2010

Includes Feedback from Reviewers


1.4.2

07/07/2010

Further peer reading

F. Sommariva (CRF)

1.5

08/07/2010

Finalisation and approval for the submission to EC

G. Vivo (CRF)

1.6

07/10/2010

Including fixes to the remarks after the project final review

G. Vivo (CRF)


Page 2 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



Abbreviation List API

Application Programming Interface

AT

Attention

ATC

Abstract Test Case

ATCRF

Automobile Telematics Certification Reference Framework

ATL

Authorized Test Laboratory

ATM

Abstract Test Method

ATS

Abstract Test Suite

C2C – CC

Car to Car Communication Consortium

C2I

Car to Infrastructure

CA

Certification Authority

CAM

Cooperative Awareness Message

CAN

Controller Area Network

CEN

Comité Européen de Normalisation

COSSIB

Cooperative Safety Systems Infrastructure Based

COTS

Commercial Off the Shelf

CVIS

Co-operative Vehicle-Infrastructure Systems (IP project, IST 027 293)

DC

Direct Current

DGPS

Differential - GPS

DLNA

Digital Living Network Alliance

DSRC

Dedicated Short Range Communications

DV

Diverting Vehicle

EC

European Commission

EITSFA

European Intelligent Transport Systems Framework Architecture

ESPOSYTOR

SAFESPOT System Monitor

ETS

Executable Test System

ETSI

European Telecommunications Standards Institute

EV

Ego Vehicle

FCW

Frontal Collision Warning

GPS

Global Positioning System

GUI

Graphical User Interface

HMI

Human Machine Interface

HTV

High Tonnage Vehicles

HW

Hardware

ICS

Implementation Conformance Statement

IEC

International Electrotechnical Commission


Page 3 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



IEEE

Institute of Electrical and Electronics Engineers

IP

Internet Protocol

IRIS

Intelligent Cooperative Intersection Safety Co -operative Intersection Collision Prevent System

ISO

International Organization for Standardization

ITS

Intelligent Transportation Systems

ITU

International Telecommunication Union

IUT

Implementation Under Test

IV

Intrusion Vehicle

KVM

Key Video Monitor

LAN

Local Area Network

LCM

Lane Change Manoeuvre

LDM

Local Dynamic Map

MARS

Multi Agent Real-Time Simulation

MSG

Message

MTC

Main Test Component

NTP

Network Time Protocol

OEM

Original Equipment Manufacturing

OSI

Open System Interconnection

OV

Other Vehicle

PA

Platform Adaptor

PC

Personal Computer

PICS

Protocol Implementation Conformance Statement

PIXIT

Protocol Implementation eXtra Information for Testing

POV

Potential Other Vehicle

PTC

Parallel Test Component

PTW

Power Two Wheeled

Q-API

Query API (to the LDM)

RF

Radio Frequency

RP

Reference Point

R&D

Research and Development

RQ

Requirement Catalogue

RSU

Road Side Unit

SA

System Adaptor

SO

Safe Overtaking

SCORE

SAFESPOT CORE architecture

SID

Sound Interface Device

SINTECH

SAFESPOT Innovative Technologies


Page 4 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



SLSD

Speed Limitation and Safety Distance

SMAEV

Safety Margin for Assistance and Emergency Vehicles

SP

Sub Project

SRA

Swedish Road Administration

SUT

System Under Test

SUUT

SAFESPOT Unit Under Test

SV

Subject Vehicle

SW

Software

T3RTS

TTCN-3 RunTime System

T-API

Transaction API (to the LDM)

TCI

TTCN-3 Control Interface

TCP

Transport Control Protocol

TCRL

Test Case Reference List

TE

TTCN-3 Executable

TGW

Volvo Telematic Gateway

TL

Test Logging

TP

Test Purpose

TRI

TTCN-3 RunTime Interface

TS

Test Site

TSI

Test System Interface

TSS

Test Suite Structure

TTCN-3

Testing and Test Control Notation

TTL

Telematic Test Laboratory

UDP

User Data Protocol

UML

Unified Modelling Language

V2I

Vehicle to Infrastructure

V2V

Vehicle to Vehicle

VANET

Vehicle Ad Hoc Network

VMS

Variable Message Sign

VRU

Vulnerable Road Users

VRUAA

Vulnerable Road User Detection and Accident Avoidance

WP

Work Package


Page 5 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



Table of contents Revision Log ...................................................................................................................................................... 2 Abbreviation List................................................................................................................................................ 3 Table of contents ................................................................................................................................................ 6 List of Figures .................................................................................................................................................... 8 List of Tables...................................................................................................................................................... 9 EXECUTIVE SUMMARY .............................................................................................................................. 10 1. Introduction .............................................................................................................................................. 11 1.1. Contribution to the SAFESPOT Objectives............................................................................... 11 1.2. Method ....................................................................................................................................... 12 1.3. Background ................................................................................................................................ 12 1.4. Deliverable purpose ................................................................................................................... 14 2. System architecture compliance ............................................................................................................... 15 2.1. CRF Implementation.................................................................................................................. 15 2.1.1. Helmond..................................................................................................................................... 15 2.1.2. ITS - Stockholm......................................................................................................................... 15 2.1.3. Cooperative Mobility Showcase - Amsterdam .......................................................................... 16 2.1.4. Implemented architecture........................................................................................................... 16 2.1.4.1. System Description .................................................................................................................... 16 2.1.4.2. Hardware description ................................................................................................................. 17 2.1.4.3. Software description .................................................................................................................. 21 2.1.5. List of implemented use cases ................................................................................................... 24 2.1.6. Major integration issues and systems architecture compliance.................................................. 27 2.1.7. Issues during field trial............................................................................................................... 30 2.1.8. Final remarks / Recommendations............................................................................................. 31 2.2. Piaggio implementation ............................................................................................................. 33 2.2.1. Implemented architecture........................................................................................................... 35 2.2.1.1. System Description .................................................................................................................... 35 2.2.1.2. Hardware Description ................................................................................................................ 35 2.2.1.3. Software Description ................................................................................................................. 38 2.2.2. List of implemented use cases ................................................................................................... 40 2.2.3. Major integration issues and systems architecture compliance.................................................. 43 2.2.4. Issues during field trials ............................................................................................................. 43 2.2.5. Final remarks / Recommendations............................................................................................. 44 2.3. Renault – Continental implementation....................................................................................... 45 2.3.1. Implemented architecture........................................................................................................... 48 2.3.1.1. System Description .................................................................................................................... 48 2.3.1.2. Hardware Description ................................................................................................................ 49 2.3.1.3. Software Description ................................................................................................................. 50 2.3.2. List of implemented use cases ................................................................................................... 52 2.3.3. Major integration issues and systems architecture compliance.................................................. 54 2.3.4. Issues during field trials ............................................................................................................. 55 2.3.5. Final remarks / Recommendations............................................................................................. 59 2.4. MIZAR implementation............................................................................................................. 60 2.4.1. Implemented architecture........................................................................................................... 62 2.4.1.1. System Description .................................................................................................................... 63 2.4.1.2. Hardware Description ................................................................................................................ 64 2.4.1.3. Software Description ................................................................................................................. 65 2.4.2. List of Implemented Use cases .................................................................................................. 66 2.4.3. Major integration issues and systems architecture compliance.................................................. 66 2.4.4. Issues during field trial............................................................................................................... 67 2.4.5. Final remarks / Recommendations............................................................................................. 68 2.5. TNO implementation ................................................................................................................. 69 2.5.1. Implemented architecture........................................................................................................... 71 2.5.1.1. System Description .................................................................................................................... 72 2.5.1.2. Hardware description ................................................................................................................. 72 2.5.1.3. Software description .................................................................................................................. 73


Page 6 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



2.5.2. List of implemented use cases (referenced to relevant documents) ........................................... 74 2.5.3. Major integration issues and systems architecture compliance.................................................. 74 2.5.4. Issues during field trial............................................................................................................... 74 2.5.5. Final remarks / Recommendations............................................................................................. 74 2.6. Volvo implementation ............................................................................................................... 75 2.6.1. Implemented architecture........................................................................................................... 75 2.6.1.1. System Description .................................................................................................................... 75 2.6.1.2. Hardware description ................................................................................................................. 76 2.6.1.3. Software description .................................................................................................................. 81 2.6.1.4. Road Side Architecture at Test Site Sweden.............................................................................. 82 2.6.2. Integration and cooperation with legacy system at Test Site Sweden........................................ 82 2.6.3. List of implemented use cases (referenced to relevant documents) ........................................... 84 2.6.3.1. Frontal Collision Warning ......................................................................................................... 85 2.6.3.2. Road Condition Status – Slippery Road..................................................................................... 85 2.6.3.3. Vulnerable Road User Detection and Accident Avoidance ....................................................... 86 2.6.3.4. VANET (CALM M5) Datarate and range tests performed by Volvo Technology and Qfree ... 86 2.6.4. Demonstration events................................................................................................................. 89 2.6.4.1. ITS WC Stockholm 2009........................................................................................................... 89 2.6.4.2. Cooperative Mobility Showcase Amsterdam 2010.................................................................... 90 2.6.5. Major integration issues and systems architecture compliance.................................................. 91 2.6.6. Issues during field trial............................................................................................................... 91 2.6.7. Final remarks / Recommendations............................................................................................. 92 3. Certification of communication interoperability ...................................................................................... 93 3.1. Certification Program................................................................................................................. 93 3.2. Testing ....................................................................................................................................... 95 4. Conclusions .............................................................................................................................................. 96 References ........................................................................................................................................................ 98


Page 7 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



List of Figures Figure 1.3-1 SAFESPOT general architecture: “The Guyancourt Architecture” .................................12 Figure 2.1-1 CRF SAFEPROBE (red car) and SCOVA (blue car) demonstrator vehicles .................17 Figure 2.1-2 CRF COSSIB vehicle......................................................................................................17 Figure 2.1-3 System architecture of the SAFEPROBE and SCOVA CRF demonstrators..................18 Figure 2.1-4 System architecture of the COSSIB demonstrator .........................................................19 Figure 2.1-5 Physical architecture and data exchange for the COSSIB demonstrator.......................20 Figure 2.1-6 software architecture in vehicles SAFEPROBE and SCOVA.........................................21 Figure 2.1-7 SAFEPROBE Platform HW Architecture and SW to HW Allocation ..............................23 Figure 2.1-8 COSSIB software modules .............................................................................................24 Figure 2.1-9 Lane Change Manouvre (v2 is CRF vehicle)..................................................................26 Figure 2.1-10 Use Case 2: Safety Distance Warning (vehicle 1 is CRF) ...........................................26 Figure 2.1-11 Use Case 2: Head On Collision Warning (vehicle 1 is CRF)........................................27 Figure 2.1-12 Main page – Ego Vehicle – of the ESPOSYTOR system monitoring tool ....................31 Figure 2.1-13 Detail of the VANET antenna in the COSSIB vehicle...................................................31 Figure 2.2-1: ITS Stockholm event – Preparation of the Use Case to demonstrate...........................33 Figure 2.2-2: ITS Stockholm event – Execution of the Use Case.......................................................34 Figure 2.2-3: Cooperative Mobility Showcase 2010 - Preparation phase of the demonstrated manoeuvres.........................................................................................................................................34 Figure 2.2-4: Cooperative Mobility Showcase 2010 - Manoeuvre in the Area #1 during the Amsterdam Showcase 2010 ...............................................................................................................34 Figure 2.2-5: Overall picture and tilting scheme of the PTW vehicles ................................................35 Figure 2.2-6 Scheme of the hardware implementation .......................................................................36 Figure 2.2-7 Physical location of subsystems .....................................................................................37 Figure 2.2-8 HMI of Piaggio Demonstrator – Bluetooth helmet ..........................................................38 Figure 2.2-9 software architecture in the PTW vehicles......................................................................38 Figure 2.2-10 Lane Change Manoeuvre scenario...............................................................................41 Figure 2.2-6 Safe Overtaking scenario ...............................................................................................42 Figure 2.3-1 Configuration of a crossroad intersection in an Urban Environment (After [2]) .............46 Figure 2.3-2 Establishing communications between vehicles and the infrastructure .........................46 Figure 2.3-3 Establishing communications between vehicles and the infrastructure .........................47 Figure 2.3-4 Block Diagram representation of the test vehicles .........................................................48 Figure 2.3-5 Implementation SAFESPOT System in the Renault Vehicles ........................................50 Figure 2.3-6 Implantation of the software components inside the System Hardware.........................50 Figure 2.3-7 Visualization tool developed by Continental and User Interface applied to road Intersections ........................................................................................................................................51 Figure 2.3-8 Distribution of software into the PC-type computers ......................................................52 Figure 2.3-9 shows Use Case 1 accident at an Intersection...............................................................53 Figure 2.3-10 shows Use Case 1f, Approaching Emergency Vehicle Warning..................................54 Figure 2.3-11 Spatial context for the La Brosse intersection ..............................................................57 Figure 2.3-12 Use Case 1f at Mobility 2010........................................................................................57 Figure 2.3-13 Localization and map-matching issue during SAFESPOT experiments ......................58 Figure 2.4-1 Hardware installed on the test site..................................................................................60 Figure 2.4-2 Architecture of roadside elements (SP2 and SP5) .........................................................62 Figure 2.4-3 Icons displayed on VMS panel .......................................................................................63 Figure 2.4-4 COSSIB Wireless Sensor Nodes mounted on the roadside barrier ...............................64 Figure 2.4-5 Software and Hardware implementation ........................................................................65 Figure 2.5-1 Test/demonstration track of Wrong Way Driver and Slippery Area Detection applications .............................................................................................................................................................69 Figure 2.5-2 BMW wrong way .............................................................................................................70


Page 8 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



Figure 2.5-3 BMW and slippery area ..................................................................................................70 Figure 2.5-4 BMW, Daimler and TNO car ...........................................................................................71 Figure 2.5-5 Volkswagen Passat (INCA) SAFESPOT equipment ......................................................72 Figure 2.5-6 BMW SAFESPOT equipment .........................................................................................72 Figure 2.5-7 Software implementation in TNO’s BMW .......................................................................73 Figure 2.5-8 Software implementation in TNO’s INCA........................................................................73 Figure 2.6-1 Volvo demonstrators: a Volvo FH-520 6x2 rigid, a Volvo FH-520 6x2 tractor and a Renault Premium Distribution Truck....................................................................................................76 Figure 2.6-2 SAFESPOT and CVIS common architecture – VOLVO implementation .......................77 Figure 2.6-3 SAFESPOT and CVIS common architecture – Connection to the in-vehicle data for the VOLVO trucks......................................................................................................................................77 Figure 2.6-4 VOLVO SAFESPOT FH-520 6x2 architecture ...............................................................78 Figure 2.6-5 System layout for Volvo FH-520 6x2 tractor and Volvo FH-520 6x2 rigid ......................79 Figure 2.6-6 Vehicle router..................................................................................................................80 Figure 2.6-7 CVIS Host (application PC) ............................................................................................80 Figure 2.6-8 Roof antennas.................................................................................................................81 Figure 2.6-9 System Software Architecture ........................................................................................82 Figure 2.6-10 SRA Legacy systems....................................................................................................83 Figure 2.6-11 Testsite DATEX information flow ..................................................................................84 Figure 2.6-12 FCW – General Use Case ............................................................................................85 Figure 2.6-13 RCS – General Use Case.............................................................................................86 Figure 2.6-14 VRU – General Use Case.............................................................................................86 Figure 2.6-15 imagine from vehicle .....................................................................................................87 Figure 2.6-16 V2V data rate ................................................................................................................87 Figure 2.6-17 infrastructure location....................................................................................................88 Figure 2.6-18 Roadside to Vehicle data rate.......................................................................................88 Figure 2.6-19 Demonstration of the FCW scenario.............................................................................89 Figure 2.6-20 The presentation podium at ITS Stockholm 2009 ........................................................90 Figure 2.6-21 Cooperative Mobility Showcase 2010 – The use cases demonstrated included CRF & Volvo vehicles......................................................................................................................................90 Figure 2.6-22 Cooperative Mobility Showcase 2010 – A guest is received by the driver ...................91

List of Tables Table 2.4-1 Summary of the deployed Software and Hardware by Mizar ..........................................66


Page 9 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



EXECUTIVE SUMMARY This deliverable reports relevant informative elements on the different instances of the SAFESPOT architecture as they were implemented by several partners, with a specific focus on the last demonstration event, the “Amsterdam Cooperative Mobility Showcase” (at InterTraffic Mobility 2010). The major functional issues found during the implementation and demonstrations are also reported. Significant experience on the different way of implementing the SAFESPOT Use Cases was accumulated during the reported demonstration events, which constituted the most important opportunities where to check and evaluate the interoperability among the different vehicles and road side units collected and operated by the project partners. Those events offered the possibility to show the developed technologies to a wide audience and were the enablers for the system conformance evaluation of the prototypes and the convergence of applications. The SAFESPOT architecture was very effective, as it was implemented and tested intensely both during the activities on the test sites and in the demonstration events. The level of sophistication attained increased as demonstrators moved from Helmond, Stockholm and Amsterdam. Different software and hardware versions were used, notably for the VANET, the LDM and the positioning modules. Whilst typical integration difficulties were found in such a large project with modules developed across Europe by R&D engineers rather than software developers, the demonstrations showed that an excellent level of conformance with the reference system architecture as well as a complete level of interoperability was achieved. It was possible to gain also a better understanding of the cooperative vehicle functions that were tested.


Page 10 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



1. Introduction 1.1.

Contribution to the SAFESPOT Objectives

The SAFESPOT system is the result of the conciliation of multiple requirements for safety use cases, based on the use of V2V and V2I communications technologies. It consists of a complex architecture that relies on vehicle ego-state information, digital maps, accurate positioning and communications technologies. The application software then uses this collection of information to implement the required use-cases. The subsequent implementation was made by different partners having distributed responsibilities as well as different working practices. In order to ensure the coherence of the implemented applications, it was necessary to define a common architecture, to specify the core components and interfaces. Each project partner had the freedom to decide details and strategies for the implementation of the applications. It was also possible to ensure interoperability amongst the various vehicles as well as with the infrastructure, characteristics that are fundamental for cooperative systems. The aim of the technical subprojects was to create the conditions to implement and test the use cases and to verify the interoperability of the implementation achieved. Throughout the project, there have been several international events related to mobility and cooperative systems in which SAFESPOT prototypes and results were demonstrated and tested. Those events offered the opportunity to demonstrate the developed technologies to a wide audience but also were the enablers for the integration of prototypes and the convergence of applications as well as to test the attained interoperability. Different applications demonstrated the communications among vehicles developed by different OEMs taking active part in V2V, V2I applications. The overall purpose of this deliverable is to compile the difference instances of the SAFESPOT architectures as they were implemented, particularly for the “Amsterdam Cooperative Mobility Showcase” (the InterTraffic Mobility 2010) demonstrators as well as to identify major functional issues found during the implementation and demonstrations. The aim will be to share amongst the project partners experiences regarding the implementation of the Use Cases and to highlight the research issues that still need to be addressed as well as to validate some of the assumptions taken for the systems to operate. The results should contribute to the experimental validation of the SAFESPOT architecture and an evaluation of the technologies based on the experience gained by all the partners involved in the demonstrations, whilst at the same time enriching the findings to be incorporated onto the final project report and recommendations of the project. The remainder of this section introduces the approach taken for the compilation of results; for consistency reasons a description of the architecture elements is provided for comparative purposes.


Page 11 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



1.2.

Method

To assess the reached level of system conformance and interoperability across the different implementations designed, developed and instantiated in SAFESPOT, the following steps were followed: •

The partners responsible for the implementation of the Use Case within SAFESPOT were invited to contribute to this deliverable. Emphasis was made on those that took in particular those that have participated in the intensive demonstrators at the Cooperative Mobility Showcase demonstration;

•

Each partner provided a summary description of the implementation according to indications and a check list table sent to all partners;

•

The deliverable has been formatted accordingly in order to facilitate the contributions;

•

The contributions are illustrations of the implementations together with comments of the major findings during the integration and demonstration periods. The deliverable is intended as a summary of the lessons learned;

•

The difference with respect to other user-driven deliverables with respect to the reference architecture is described for the different interpretations

1.3.

Background

The overall SAFESPOT system architecture is known as the Guyancourt architecture and has been defined in [8]. Figure 1.3-1 shows an UML based representation of this architecture. This is introduced to outline the theoretical representation of the SAFESPOT proposed solution and to compare it with the instances that have been implemented by the project partners. sd Domain Model

Application Coordination Actuator, HMI, VMS, ...

External Application, e.g. CVIS

This Node's Application #1

This Node's Application #N Message Stack Q-API

determi nes at desi gn ti me by Message Generation rules

LDM

Q-API

Q-API

context relev ance checking

T-API

Message Router

common LDM ev aluation, for all SF applications

Q-API

Data Processing / Fusion

VANET T ransmitter

messages not rel evant for thi s node

relev ance checking, e.g. position based VANET Receiver

messages rel evant to this node SP1/2 SP3 SP4/5

This Vehi cl e / Infrastructure Node's Sensing & Data Sources

Figure 1.3-1 SAFESPOT general architecture: “The Guyancourt Architecture”


Page 12 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



For completeness an overview of the main functions is included as follows: •

Routing & Data Processing Fusion. All incoming messages arrive to this component. These can be ignored when they are irrelevant, routed to the Data Fusion function when the contribute towards building a representation of the environment around the subject vehicle or sent to the Message Manager for evaluation of the situation (context) as they can be of use to other entities. The fusion process includes all steps necessary to permit the validation of data, object and situation refinement, and should result in geo-referenced data with a stated level of reliability.

•

Local dynamic map (LDM). The basis is made from the road geometry available in standard navigation digital map to which additional information collected by vehicles and the infrastructure will be added. It provides and maintains a description of relevant static, temporary and dynamic elements and objects around the hosting node (infrastructure and noninfrastructure). The LDM is a true server with dedicated access functionalities such as searching, grouping, and filtering. Thus queries are more than requests for simple data items/parameters. These will require some evaluation of the spatio-temporal situation of the dynamic entities registered in it. A complete “situation” is made up of a combination of relations and attributes/conditions and is formulated by the users/clients of the LDM server:

•

Message generation. The function of this component is to determine which messages need to be communicated via the VANET on the basis of a set of rules defined a priori by the Applications. It also evaluates the content of incoming messages to check their relevance for re-broadcast via the VANET (e.g. to implement multihop communications).

•

Application. The purpose of this component is to host applications (messages to be displayed by the HMI of the host vehicle or roadside devices linked to the RSU). Data/messages useful for non-host applications are dealt with by the Message Manager. This implies that whilst individual applications will run in specific vehicles, all application “clients” must be able to run in all vehicles. The Applications have to define the rules for generating the messages, but can’t modify the content of message itself in real time. This is decided at ‘design time’. It implies that is needed a certification process to decide the ‘official’ messages.

Complete details of the SAFESPOT architecture can be found in deliverable entitled SAFESPOT Core Architecture, Global System Reference Architecture Specification [8].


Page 13 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



1.4.

Deliverable purpose

The purpose of this deliverable is to make an “état des lieux” (an account) of the instances deployed of the SAFESPOT architecture by the various implementations with different tests made during the Cooperative Mobility Showcase 2010 demonstration or the site evaluation trials. The objectives of the deliverable can be summarised as follows: •

To outline the designed SAFESPOT architecture;

•

To present the system level descriptions. Hardware and Software implementation of the architecture on deployed at various tests;

•

To present the relevant issues found by the project partners with the different instances of these architectures;

•

To make a summary of the problems encountered.

Section 2 is centred on the implemented architectures, thus it includes the compilation of the results issued of the various instances of the implementation made by the project partners. Contributions include those of CRF and MagnetiMarelli, TNO, Volvo and Renault for the Vehicle components. The work of Mizar reports the activities carried out for the Infrastructure part. Section 3 completes the instances report with an analysis on the communications interoperability by AT4 wireless. Section 4 concludes the document with a summary of major findings and recommendations for future development and research issues.


Page 14 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



2. System architecture compliance 2.1.

CRF Implementation

CRF involvement in the SAFESPOT project is referred both to vehicle and road infrastructure. In this document the applications showed at three project milestone events are presented: Helmond, Stockholm and Amsterdam. The emphasis of this report is on the architecture of the implemented vehicles from the hardware and software perspectives. 2.1.1. Helmond CRF took part in Helmond showcase with 2 vehicles. SAFEPROBE vehicle (Fiat Bravo red): complete equipment including radar, laser scanner, camera and Esposytor to view system status and working operation. This vehicle was able to participate actively to the IRIS application. This means that it is a secondary actor for the RSU sending the beacon message and as a primary actor receiving the messages from the RSU and displaying the warnings. COSSIB vehicle (Fiat Croma): represents road operator vehicle, equipped as SAFESPOT and in charge to work as mobile road side unit, forwarding to incoming vehicles indication about stopped vehicle ahead. Helmond site was also equipped with one RSU to test and demonstrate V2I applications. In the demonstrated scenarios, the VANET was fundamental for enabling the communication and cooperation among all the systems and from CRF point of view the capability to receive important warning from road infrastructure (example IRIS – road intersection). Helmond was also important for the test of interoperability between SAFESPOT and CVIS. It was the first (successful) attempt to achieve full interoperability among both systems. 2.1.2. ITS - Stockholm CRF took part at the Stockholm ITS World congress. A SAFEPROBE vehicle and a “bench version” of COSSIB vehicle were demonstrated as part of the congress exhibition. The following use cases were demonstrated: •

Rear End Collision

•

Speed Limitation and Safety Distance

•

Obstacle detection warning (COSSIB vehicle involved)

At the same event a RSU was provided by Peek Traffic. Given the difficulties with the localisation precision and requirements for the demonstration, the introduction of differential GPS to improve the precision in positioning and warrant the quality of the V2V was made. This event triggered the application and completion of communication issues related to the VANET module.


Page 15 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



2.1.3. Cooperative Mobility Showcase - Amsterdam CRF took part at the Amsterdam Cooperative Mobility Showcase with 3 vehicles: •

2 Fiat Bravo (SAFEPROBE and SCOVA) working as fully SAFESPOT equipped vehicles, acting as prime and secondary actor in the selected use cases;

•

1 Fiat Croma (COSSIB), working as mobile road side unit, demonstrating the SMAEV application.

The uses cases demonstrated included two types of SAFESPOT vehicles, namely, SAFEPROBE and SCOVA. These were: •

Lane Change Manoeuvre;

•

Speed Limitation and Safety Distance;

•

Frontal Collision Warning;

•

Head On Collision Warning.

The applications demonstrated are based on a full cooperative scenario in which the fundamental issue was communications among the vehicles. For this purpose the vehicles involved were from CRF, Piaggio and Volvo. Due to the specific requirements and main characteristic of the use cases the time synchronization among different nodes taking part in the scenario was a very important issue, contributing to success achievement. That is all spatial data was associated in time, any time discrepancy between the clocks in the vehicle would reflect in the positioning of the vehicles in the LDM at a given instance in time. 2.1.4. Implemented architecture The architecture of the vehicles equipped by CRF is presented in this section. The starting point is that the 3 vehicles present SAFESPOT core components (from HW and SW point of view). Then according to specific application requirements there are different instances with regard to sensors or software modules. 2.1.4.1.

System Description

The demonstrator vehicles developed by CRF were: the FIAT Bravo “SCOVA”, the FIAT Bravo “SAFEPROBE” and the FIAT Croma “COSSIB”. CRF was responsible for the entire chain of development, from the definition of User Needs and Requirements, Specifications, Implementation, to the Evaluation and Validation. This included the V2V applications as well as the External Msg Application. The External Message Application is a component, of a horizontal nature. It is needed to provide access to the on board HMI resource by External Applications (for instance to support SP5-COSSIB or CVIS applications). The single “special” sensing component installed in the SCOVA vehicle was a Fujitsu Ten millimetre wave radar. The vehicle uses also the VANET, performed by


Page 16 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



the SINTECH router, The SAFEPROBE vehicle was equipped by an additional perception system, apart from the Fujitsu Ten long range radar, an IBEO Laser Scanner Unit is used. Both sensors were located in front of the vehicle as shown in figure 2.1-1.

Figure 2.1-1 CRF SAFEPROBE (red car) and SCOVA (blue car) demonstrator vehicles

Figure 2.1-2 CRF COSSIB vehicle

2.1.4.2.

Hardware description

Several modifications and adaptations were needed to equip the vehicles with the sensors and actuators required by the SAFESPOT applications to be implemented and demonstrated. Figure 2.1-3 shows an outline of the networking architecture of the SAFEPROBE and SCOVA demonstrators, together with the physical location of the associated subsystems.


Page 17 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



Figure 2.1-3 System architecture of the SAFEPROBE and SCOVA CRF demonstrators

The outline shows the major system components: the millimeter wave radar, the computer processing units and the networking interconnections. It should be remarked that systems #18 (the IBEO Laser Scanner) and #19 (the Laser Scanner Control Unit) were included only in the SAFEPROBE demonstrator. A unified Ethernet LAN network is used to connect the different SAFESPOT units. The vehicle CAN bus and the microwave radar private CAN bus are mapped into the Ethernet network. Access is based on a dedicated SAFESPOT UDP protocol. The mapping is implemented in the SAFESPOT vehicle gateway. The different PC-type computers are assigned to host different software modules (application, positioning, core algorithms and data acquisition and fusion modules). The COSSIB demonstrator is a Safety Car used for the SMAEV_01 (SP5) application; this has been used also as a mobile road side unit for the SP4 Curve Warning application. Figure 2.1-4 presents an overview of the components installed in the vehicle.


Page 18 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



Figure 2.1-4 System architecture of the COSSIB demonstrator

The following components are integrated in the COSSIB vehicle: •

Main PC hosting the SP1 framework, and the SP5 SMAEV and SP4 Curve Warning applications. It also includes the LDM, Data Acquisition and a reduced version of SAFESPOT positioning software for vehicles

•

VANET router, provided by SP3, to exchange information with VANET

•

Gateway board, provided by SP4, to acquire vehicle data

•

Ethernet Switch for LAN connection

•

VMS Panel

•

GPS sensor

•

Yaw Rate sensor

•

The HMI client, which is a laptop connected to the vehicle LAN.

Figure 2.1-4 shows the layout of components within the vehicle. The signaling unit, VMS panel is similar to the ones used on Road Service Vehicles; it has been mounted on top of the COSSIB vehicle. Figure 2.1-5 illustrates the components of the physical architecture and provides a high level view of the data exchanged between modules.


Page 19 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



Figure 2.1-5 Physical architecture and data exchange for the COSSIB demonstrator

An important component of the CRF demonstrators is ESPOSYTOR: the diagnostics and System Monitor tool developed by MagnetiMarelli. It has been designed and implemented to assist during the system development, and to facilitate the understanding of the functioning of SAFESPOT components. This tool allows the monitoring of the work of each module in the SAFESPOT architecture. ESPOSYTOR tool run on a dedicated computer and it is connected to the Ethernet network of SAFESPOT.


Page 20 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



2.1.4.3.

Software description

Figure 2.1-6 shows the manner in which the main software modules are implemented on board of the computer used as part of the SAFEPROBE and SCOVA vehicles.

Figure 2.1-6 software architecture in vehicles SAFEPROBE and SCOVA

The modules of the SAFESPOT architecture are standard. A complete description of them can be found in the deliverables of SP1, SP3, SP4 and SP7. The demonstrators stressed the operations of all the modules as high reliability was necessary for them to be deployed. The requirements needed for positioning system were once again highlighted as these provide the spatial description of entities and thus it needs to be robust but also interoperable. Since all data are time pertinent, the synchronisation of timing mechanisms was important for this purpose the NTP server was used in all vehicles. A server for the time reference synchronization among all components connected within the intra vehicle network (using the GPS Time signal so the internal clock can be aligned uniquely).


Page 21 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



The core of the system is represented by MAIN PC, in charge to host and run the specific algorithm and interfaces modules towards other components. The on board system is characterized by the following functionalities: •

Networking with all components within the in-vehicle network: the OEM gateway, positioning PC, VANET router, Laser scanner PC (only on SAFEPROBE), message generation and application clients;

•

Initialisation, settings, power-up sequence, built-in-testing, error handling of all internal PCs (including the LDM) and connected external devices;

•

Data fusion (object and situation refinement) in collaboration with the LDM database management system (including support for push and pull mechanisms: transactions, queries, subscriptions);

•

Execution of all applications’ message generation;

•

VANET router;

•

All software modules included a logging functionality that can be triggered whenever it was necessary;

•

Interface towards ESPOSYTOR through UDP messages and visualizing data on LDM.

The application PC hosted the software that implemented separate applications for each of the demonstrated use cases. Figure 2.1-7 illustrates the allocation of SW to HW components in the on board platforms. The different functional elements are assigned to attach them to the responsible subproject: SP1, SP3, SP4 and the OEMs applications.


Page 22 of 98

SP7 - SCORE

Deliverable D7.4.5

Copyright SAFESPOT



Figure 2.1-7 SAFEPROBE Platform HW Architecture and SW to HW Allocation


Page 23 of 98

SP7 - SCORE

Deliverable N. D7.4.5

Copyright SAFESPOT



Some software modules in the COSSIB vehicle differ from those in the SAFEPROBE and SCOVA vehicles. The implementation of the software modules in the COSSIB vehicle is shown in figure 2.1-8.

Figure 2.1-8 COSSIB software modules

The software architecture is based on a variation of SP1 architecture. The application resides on the main PC. The HMI module is accessible by the user through any terminal with the following configuration: •

An HMI server on the main PC, accessible through a web browser;

•

An HMI client, which can be any computer connected to the vehicle LAN. Using a browser, the user can access the HMI server.

The main advantage of this HMI configuration is robustness, as the application runs on a static industrial PC, which remains inside the vehicle. Failures in the physical HMI peripheral can be managed by substituting only the terminal. 2.1.5. List of implemented use cases The three demonstration events in which the applications were shown were scheduled in an extended manner and were linked to the release of the software implementation in SAFESPOT. It allow for interoperability testing and for attaining the final release of key SAFESPOT architecture components.


Page 24 of 98

SP7 - SCORE


Copyright SAFESPOT



The use cases in which CRF took part are as follows: Intersection safety application – IRIS (Helmond) The RSU was provided by TUM and Peek Traffic. The function to identify the vehicle passage providing information about red traffic light status, warn about vehicle presence in the intersection area and warn about the presence of vulnerable road user in the intersection area. The CRF vehicle used External message application to receive and visualize incoming warning. The vehicle identification was made: in one case using beacon information (red traffic light warning), and the use of the laser scanner in RSU for detection (identifying a vehicle in the intersection area). Event warning – vehicle stopped (Helmond, Amsterdam) The Assistance Vehicle is on the site where the event has happened and warns incoming vehicles. The Vehicles traversing this area (included CRF vehicle) receive a warning through the external message application. This use case has been presented at all the show case demonstrations with some differences in the emphasis. In Helmond, but also in Amsterdam the vehicle warned CVIS minivans, thus demonstrating the interoperability of CVIS and SAFESPOT prototypes. Rear end Collision warning (Stockholm) In the scenario, CRF vehicle was the primary actor. When Piaggio motorbike arrives from behind CRF vehicle receives “rear end” warning, increasing speed to reduce the risk of collision. Dynamic speed limitation (Stockholm) The aim of the application is to receive and visualize on the subject vehicle the right speed, suggested from RSU. Software features tested in this scenario have been, beaconing and the external message application. Obstacle detection warning (Stockholm) This application aims to demonstrate the interaction between the RSU and the subject vehicle. This is done through beaconing and the external message application. In fact the RSU in this case send to the incoming vehicle information about obstacle ahead. The RSU is static RSU, a mobile RSU provided by CRF (COSSIB vehicle), is used as a repeater to extend the range of communications coverage.


Page 25 of 98

SP7 - SCORE


Copyright SAFESPOT



Lane change manouvre (Amsterdam) The test setup is composed by two vehicles. The Ego vehicle V1, which is a PIAGGIO motorbike, traveling on left lane. The CRF vehicle (V2) arrives in the right lane. When V1 decides to move to the right lane, see figure below, it will receive a warning due to the presence of an incoming vehicle.

V1 V2

Figure 2.1-9 Lane Change Manouvre (v2 is CRF vehicle)

Speed Limitation and Safety Distance (Amsterdam) The applications configuration is as shown in figure 2.1-10. It is composed of a motorbike and a vehicle (CRF). V1 recognizes the presence of the motorbike as it receives a beacon transmitted by the PTW or by using the radar or laser scanner onboard of V1. The information of the PTW is fused and written in the LDM from the SAFEPROBE architecture. The SLSD application, developed by Magneti Marelli, uses the information of presence of the PTW, and computes the current distance with the PTW, the safety distance (based on the current speed of the vehicle V1, on the weather conditions, and on both the positions of the vehicles), and compares the distance and the safety distance. From the comparison, three levels of warning can be sent to the driver of V1.

Figure 2.1-10 Use Case 2: Safety Distance Warning (vehicle 1 is CRF)


Page 26 of 98

SP7 - SCORE


Copyright SAFESPOT



Frontal collision warning (Amsterdam) There are three actors in this use case: •

V1: CRF vehicle stopped on the road, sends beacons;

•

V2: Volvo truck not SAFESPOT equipped behind V1:

•

V3: Volvo truck SAFESPOT equipped is not able to see V1 but thanks to the beacon from V1, the driver is informed and could thus reduce the speed in time.

Head on collision warning (Amsterdam) The set up of the scenario is described in figure 2.1-11. V1 is the CRF vehicle which is would like to overtake a non SAFESPOT vehicle. Once the maneuver has started the systems recognizes the presence of vehicle V2 arriving in the opposite direction and the application in V1 will inform the driver.

3

Figure 2.1-11 Use Case 2: Head On Collision Warning (vehicle 1 is CRF)

2.1.6. Major integration compliance

issues

and

systems

architecture

The SAFESPOT system is complex, in terms of HW and SW, details can be found in the deliverables associated to the technologies used namely SP1 for the vehicle and SP3 for the digital map; localisation, and communication. The strategy adopted by the project was to define a standard interface so to as to implement the overall architecture scalable and modular. Whilst at the same time facilitating the final integration of developments made by multiple partners. The experience acquired by CRF following the demonstrated showcases can be listed as follows: VANET The most relevant enabling technology for a cooperative system is the communication channel (V2V, V2I). From the HW point of view, CRF vehicles are equipped with QFree boards that integrate a preliminary version of the standard 802.11p. Upon the physical layer CRF implemented the application SW to manage the


Page 27 of 98

SP7 - SCORE


Copyright SAFESPOT



communication (called VANET Router). A set of common messages have been defined, specified and implemented to create a common language understandable by all components. A dedicated tool, called VANET player, has been implemented, tested, maintained and shared among all partners. It was used to test each implementation on site and work remotely towards interoperability goal. A very important part is the management of node ID assignment which has been done univocally for all the components to avoid duplication and collision risks. This proved to be valuable as during the Stockholm and Amsterdam showcases the number of network nodes active simultaneously was quite high. Interoperability with CVIS At the Helmond showcase SAFESPOT and CVIS were able to share and exchange information. A specific protocol layer adaptation has been purposely developed to make both systems compliant so the information broadcasted by each of them could be recognized. In a real scenario in which “speaking/communicating” vehicles are travelling on the same road, the goal is that each could recognize the presence of the neighborhood vehicles and thus take them into account. The implementation resides on specifications defined as part of the COMeSafety documents defined for cooperative systems. UDP messages In order to provide to the application developer the freedom to customize the selection of the SAFESPOT modules and overall integration, interfaces have been standardized. For this purpose all data structures exchanged between the different units in the SAFESPOT system have been defined. This included internal LDM data (i.e. internal data in the LDM format and accessed through the Q-API or T-API). Towards interoperability achievement this has been very important offering the possibility to integrate in CRF vehicle components developed by other partner and running remote debug. The messages are exchanged between the detection system and acquisition module, but also they are generated to feed the VANET router or sniffed by ESPOSYTOR to monitor the overall running system. LDM There were two concurrent versions of the LDM, these were developed by the map suppliers Navteq and Teleatlas. The CRF vehicles were used to demonstrate the SAFESPOT use cases and applications in terms of reference implementation; for this reason both the LDM provided by Teleatlas and Navteq have been adopted, depending on the specific requirements and constraints of the different test sites. The use cases


Page 28 of 98

SP7 - SCORE


Copyright SAFESPOT



demonstrated in Helmond, were based on the usage of the Navteq LDM. In Stockholm the Teleatlas LDM was adopted and in Amsterdam both LDMs were adopted. ESPOSYTOR The connection of ESPOSYTOR to the systems in the CRF vehicles has been demonstrated in all showcases. It was used as a visualization tool supporting the explanation of the application to visitors, as well as a debugging tool in the interoperability trials. The standard interface used in ESPOSYTOR allows the connection to any sub-network of any SAFEPOT implementation (vehicle or RSU) and visualizes the operation of the LDM. ESPOSYTOR also displayed the overall system status. Further details can be found in deliverables: •

D3.4.4 – ESPOSYTOR Architecture;

•

D3.4.5 – ESPOSYTOR Prototype;

•

D3.5.5 – ESPOSYTOR Validation report.


Page 29 of 98

SP7 - SCORE


Copyright SAFESPOT



2.1.7. Issues during field trial The showcases provided a unique opportunity for the integration of the solutions originating from all SAFESPOT partners as well as for the dissemination of the technologies. A summary of the issues encountered and the lessons learned comprises the following: •

Logistic and organization: once the use cases to be demonstrated have been decided, a precise working plan had to be formulated. Partners in different countries developed different software modules and these have to be ready at pre-established dates for the integration to proceed. o The time reserved for each test was limited and had to be optimized; o The resources (devices, vehicles) had to be shared. This required careful planning of project activities.

•

VANET: working and settings in real environment implied that during the showcases a significant number of VANET nodes, working simultaneously were present. The three events are characterized by their increasing complexity. Stockholm demonstrated the importance of network management and node ID assignment. Amsterdam showed the coexistence of more than 20 operating VANET nodes used in the different use cases without mutual interferences. The later event includes nodes from the COOPERS and CVIS projects.

•

Positioning and time synchronization V2V applications required high precision vehicle pose information as found earlier on at the Helmond demonstration. As a result, a differential GPS solution was to be used, the reference bases and receivers are from Novatel and Trimble. Piaggio used differential corrections from an augmentation system, Omnistar. Different solutions were used by the Vehicles participating in the showcases. Moreover CRF, guests in the sites, should adapt vehicle equipment accordingly to the reference base station available on site.

•

LDM was provided by Navteq and Teleatlas. Different vehicles at the showcases used these LDMs with the underlying SAFESPOT being the same. It should be remarked that by using both the TeleAtlas (in CRF Vehicles) and the Navteq LDMs the interoperability of the various software modules was demonstrated at the different demonstrators.

•

ESPOSYTOR has become an important tool for the understanding of the operation of the overall cooperating system and thus used for debugging purposes as well as to provide an overall insight into the inners of the SAFESPOT system during the demonstrations. Figure 2.1-12 shows a screen dump of ESPOSYTOR.


Page 30 of 98

SP7 - SCORE


Copyright SAFESPOT



Figure 2.1-12 Main page – Ego Vehicle – of the ESPOSYTOR system monitoring tool

2.1.8. Final remarks / Recommendations The integration of the SAFESPOT components, the various operational tests and demonstrations enabled partners to acquire a unique experience when using the configurations implemented in the CRF vehicles. In conclusion the following could be stated: •

There is room for the optimisation of onboard vehicle equipment. The use of a high communications frequency meant that care should be take on the antenna selection, layout and cabling. For example, in the COSSIB vehicle, the presence of the light bar device on roof reduced the coverage of the VANET. Figure 2.1-13 shows how this physical occlusion affects the VANET: the light bar is interposed between the VANET antenna and the rest of the environment.

Figure 2.1-13 Detail of the VANET antenna in the COSSIB vehicle


Page 31 of 98

SP7 - SCORE


Copyright SAFESPOT



•

Timing and synchronization is fundamental for all the applications.

•

The use of different area requires continuous adaptation of the LDM, cartography. Applications need specific LDM attributes and their integration into the database. Further, the demonstrations required specific maps to be generated, as these were in non-public roads. Thus the map providers had to generated specific road geometries plus attributes for each of the demonstration sites.


Page 32 of 98

SP7 - SCORE


Copyright SAFESPOT



2.2.

Piaggio implementation

The Piaggio implementation consisted in two working PTW vehicles of a full architecture compliant with the SAFESPOT. The Piaggio test vehicles have been mainly used to support the Italian TS SP with the vehicle based applications whose Piaggio is Application Leader, namely the Lane Change Manoeuvre and the Safe Overtaking. These SAFESPOT applications have the task to process the collected information in order to analyze the surrounding scenario and warn the driver by means of a suitable human user interface. Both of the vehicles have been built based on the same common architecture as described in D7.3.1 – Global System Reference Architecture. Two relevant demonstration events happened in the last year of activity of the SAFESPOT project: the demonstration, during the 16th World Congress for ITS Systems and Services in Stockholm, on September 2009: http://www.itsworldcongress.com/ and the demonstration during the Cooperative Mobility Showcase 2010 smart vehicles on intelligent roads, held in Amsterdam, on March 2010: http://www.cooperativemobilityshowcase.eu/nl/en/pages/default.aspx Following pictures report some of the activities carried out during the above demonstration events.

Figure 2.2-1: ITS Stockholm event – Preparation of the Use Case to demonstrate


Page 33 of 98

SP7 - SCORE


Copyright SAFESPOT



Figure 2.2-2: ITS Stockholm event – Execution of the Use Case

Figure 2.2-3: Cooperative Mobility Showcase 2010 - Preparation phase of the demonstrated manoeuvres

Figure 2.2-4: Cooperative Mobility Showcase 2010 - Manoeuvre in the Area #1 during the Amsterdam Showcase 2010


Page 34 of 98

SP7 - SCORE


Copyright SAFESPOT



2.2.1. Implemented architecture The Piaggio PTW presented unique challenges for SAFESPOT. The space available for hardware is limited (65 dm3 of under-seat capacity), as is the electrical power availability. Further the vehicle dynamics are completely different respect to the ones of other vehicles. 2.2.1.1.

System Description

The space available under the seat of the motorcycle and electric power supplies are limited, these constraints have driven the design rather than the environmental perception systems. A minimal system configuration consists of a gateway, a VANET Router, a Main PC and a GPS module. As possible to see in the figure below the motorcycle is an MP3 scooter that has two front wheels and one rear.

Figure 2.2-5: Overall picture and tilting scheme of the PTW vehicles

The innovative scooter model has been chosen because their characteristics guarantee an increasing of safety level due to an increased stability. In addition, the MP3 has a representative and up to date electrical and electronic architecture, suitable for the integration of new features of SAFESPOT system. 2.2.1.2.

Hardware Description

Several modifications and adaptations have been necessary in order to equip the vehicles with the devices required for the SAFESPOT applications to be implemented and demonstrated.


Page 35 of 98

SP7 - SCORE


Copyright SAFESPOT



Figure 2.2-6 presents the components and the high level interconnections of the hardware architecture for the PTW demonstrators.

Figure 2.2-6 Scheme of the hardware implementation

The scheme depicted in the above figure indicates the main system components: the various processing units, the network interconnections and in particular the dual frequency GPS receiver with Omnistar corrections. This last device is necessary in order to improve the accuracy of positioning (up to the 0,2 m target) as in Piaggio demonstrators no videocamera or laser scanner are installed to support a standard GPS in order to reach the SAFESPOT requirements in terms of position accuracy. The power supply of the demonstrator is a lead battery of “12V-12Ah”, so for the SAFESPOT systems two DC-DC converters are needed: a “12v to 5v” and a “12v to 7.5v”. In the figure below it is possible to all the devices onboard the PTW. The main PC is located under the seat.


Page 36 of 98

SP7 - SCORE


Copyright SAFESPOT



3 1 4

2

1 – LCD screen 2 – GPS, GW, Eth.Switch, Inert. Plat. 3 – GPS Antenna

4 – Main PC & Router

Figure 2.2-7 Physical location of subsystems

Another important part of the architecture is the helmet, which is equipped with a Bluetooth communication system which receives the audio warnings sent by the main PC.


Page 37 of 98

SP7 - SCORE


Copyright SAFESPOT



“A vehicle is approaching from the behind”

Figure 2.2-8 HMI of Piaggio Demonstrator – Bluetooth helmet

2.2.1.3.

Software Description

Figure 2.2-9 shows the manner in which the main software modules are implemented on board of the computer used as part of the SAFEPROBE Piaggio vehicles.

Figure 2.2-9 software architecture in the PTW vehicles


Page 38 of 98

SP7 - SCORE


Copyright SAFESPOT



Due to spatial constrains and power requirements on the Piaggio Mp3 vehicles the implemented SAFESPOT architecture modules are standard. All the software is hosted by a single PC-type computer. A complete description of it can be found in the specific deliverables for SP1, SP3, SP4 and SP7. The demonstrators stressed the operations of all the modules as high reliability was necessary for them to be deployed. The requirements needed for positioning system were once again highlighted as these provide the spatial description of entities intervening in the use case scenarios. Since all data are time pertinent, the synchronization of timing mechanisms was important for this purpose; for this reason an NTP server was used for the PC computers in all vehicles. This server was used for the time reference synchronization among all components connected within the intra vehicle network (the GPS Time signal was used as a global clock reference for keeping all the systems and modules aligned). The core of the simplified system implemented in the Piaggio vehicles is represented by a MAIN PC, that hosts and run the specific algorithms and interfaces modules with other components. The on board system is characterized by the following functionalities: •

Networking with all components within the in-vehicle network: the OEM gateway, positioning software, VANET router, message generation and application clients;

•

Initialization, settings, power-up sequence, built-in-testing, error handling of all internal PCs (including the LDM) and connected external devices;

•

Data fusion (object and situation refinement) in collaboration with the LDM database management system (including support for push and pull mechanisms: transactions, queries, subscriptions);

•

Execution of all applications’ message generation;

•

VANET router;

•

All software modules included a logging functionality that can be triggered whenever was needed;

•

Interface with ESPOSYTOR through UDP messages and visualisation of data in the LDM;

•

Hosting the software which implements separate applications for each of the demonstrated use cases. It is recalled that in the Piaggio vehicle there is a single PC due to space constraints.


Page 39 of 98

SP7 - SCORE


Copyright SAFESPOT



2.2.2. List of implemented use cases LANE CHANGE MANOEUVRE This was implemented by Piaggio and the Politecnico of Milan. It was evaluated in a closed test track that is part of the internal roads in Politecnico campus. The performed tests involved two equipped Piaggio MP3 in a generic scenario of possible lateral collision. The two PTWs drove in the same direction but in different lanes: the EV in the leftmost one at 40 km/h, the OV in the rightmost one at 50 km/h, starting from a given relative distance (150 meters). The PTW (OV) behind, which had a role of secondary actor, quickly approached the PTW ahead. Then the EV tried to change lane setting the direction light. This application has the purpose to avoid an accident due to blind spot with PTW during lane change maneuver. In case of a dangerous situation the rider of the involved vehicle is warned. Once the EV starts the lane change manoeuvre (triggered by the turn indicator activation), the LCM application evaluates the Time To Collision (TTC) as a solution of this equation:

1 ⋅ ∆a ⋅ TTC 2 + ∆v ⋅ TTC + ∆s = 0 2 With: ∆v : the speed difference between the ego vehicle and the other vehicle ∆a : the acceleration difference between the ego vehicle and the other vehicle ∆s : the distance between the ego vehicle and the other vehicle

Then the obtained TTC value is compared with three thresholds defining the three different levels of warning. When the two vehicles travel at about same speed, it is considered just their relative distance: if it is below a ‘safety distance’, the risk of a lateral collision is high, so a critical warning is provided to the rider. The ‘safety distance’ d ( safe ) is computed from the speed of ego vehicle ( v EV ) and the reaction time of the rider ( t react ):

∆s < d safe = t react ⋅ v EV The evaluation carried out in the present assesses the application reliability and correctness.


Page 40 of 98

SP7 - SCORE


Copyright SAFESPOT



Test scenario According to the test form, the scenario tested is the ‘Lane Change Manoeuvre General Case” EV OV

EV OV

Figure 2.2-10 Lane Change Manoeuvre scenario

The PTW on the leftmost lane (see figure above) is the primary actor of the LCM use case. The OV (second PTW) is approaching from the behind on the rightmost lane of the road, at a higher speed. Different tests were made to evaluate the implemented application. These were applied to the phases of entrance and exit from the conditions of lane change manoeuvre warning. In all tests the EV moved at 40km/h in the leftmost lane of the road. In the first set, the secondary vehicle started at a given distance from EV and approached it from behind in the rightmost lane, then the OV overtakes the ego vehicle. In the second set, the OV is approaching the ego vehicle from behind, but it does not overtake the EV. In both tests, the OV speed is at 50 km/h. The different warnings (comfort, safety and critical) depend on the distance between the vehicles, when the lane change manoeuvre was started (by setting the direction light) to initiate a different warning. Tests under different weather conditions were not performed, since the conditions were constant during the testing period. SAFE OVERTAKING The Safe Overtaking application, implemented by Piaggio and Politecnico of Milan, was evaluated in a closed test track that is part of the internal roads in Politecnico campus. The tests involved two equipped Piaggio MP3 in a generic scenario of possible lateral collision. The two PTWs drove in the same direction but in different lanes: the EV in the rightmost one at 40 km/h, the OV in the leftmost one at 50 km/h, starting from a relative distance (~150 m). The OV behind, which had a role of secondary actor, was carrying out the overtaking manoeuvre of EV. The EV had in front of it, in the same lane, an obstacle (in the current case a car, V3). The EV tried to change lane setting the direction light.


Page 41 of 98

SP7 - SCORE


Copyright SAFESPOT



This application has the purpose of avoiding an accident due to a blind spot scenarios, with PTW during the overtaking manoeuvre. In case of a dangerous situation, the rider of the Ego Vehicle is warned. Once the EV starts the overtaking manoeuvre (triggered by the turn indicator activation), the SO application evaluates the Time To Collision (TTC) as a solution of this equation:

1 ⋅ ∆a ⋅ TTC 2 + ∆v ⋅ TTC + ∆s = 0 2 With: ∆v : the speed difference between the ego vehicle and the other vehicle ∆a : the acceleration difference between the ego vehicle and the other vehicle ∆s : the distance between the ego vehicle and the other vehicle

Then the obtained TTC value is compared with three thresholds defining the three different levels of warning. When the two vehicles travel at about same speed, it is considered just their relative distance: if it is below a ‘safety distance’, the risk of a lateral collision is high, so a critical warning is provided to the rider. The ‘safety distance’ d ( safe ) is computed from the speed of ego vehicle ( v EV ) and the reaction time of the rider ( t react ):

∆s < d safe = t react ⋅ v EV The evaluation carried out in the present report assesses the application reliability and correctness. Test scenario According to the test form, the scenario tested is the ‘Safe Overtaking General Case” OV V3 EV

OV V3 EV

Figure 2.2-11 Safe Overtaking scenario


Page 42 of 98

SP7 - SCORE


Copyright SAFESPOT



The PTW (OV) on the leftmost lane (see above) is the secondary actor of the SO use case. It is approaching from behind, at a higher speed, and it is involved in overtaking manoeuvre of EV. Ego Vehicle has in front of it, in the same rightmost lane, a car (V3), so EV decides to start the overtake manoeuvre of V3. Different tests were made to evaluate the implemented application. These included the entrance and exit phases from the conditions of lane change manoeuvre warning. In all the tests the EV moved at 40km/h in the rightmost lane of the road. In the first the secondary vehicle started at a given distance from the EV and approached it from behind, in the leftmost lane, but it didn’t overtake the EV. In the second set of the tests the OV is approaching the ego vehicle from the behind, overtaking the ego vehicle. In both the tests the OV speed is of 50 km/h. The different warnings (comfort, safety and critical) depend on the distance between the vehicles, when the overtaking manoeuvre by EV was started (by setting the direction light) to initiate a different warning. Tests under different weather conditions were not performed, since the specific weather conditions did not happen during the testing periods.


issues

and

systems

architecture

The identified non-compliance related to the updating frequency of the LDM tables was not so critical for the LCM use case. The thresholds used by the application have been chosen considering the latency in the whole chain of the process, which is maximum in case of data coming from other vehicles. In this case the data flow is as follows: other vehicles data and positioning SP1 framework LDM router wireless communication router SP1 framework LDM SP4 application HMI visualization.

2.2.4. Issues during field trials The achieved results in the evaluation tests were very positive and evidenced the good performance of both the implemented function: Lane Change Manoeuvre and Safe Overtaking. In 100% of the cases the application worked properly, providing warnings coherent with the data acquired from the LDM and used by the algorithm. Since the specification phase, it is known that a very accurate positioning system is mandatory for achieving a right behavior of the application; the precise position of the vehicle on the road is needed for detecting the lane where it is travelling.


Page 43 of 98

SP7 - SCORE


Copyright SAFESPOT



2.2.5. Final remarks / Recommendations The integration of the SAFESPOT components, the various operational tests and demonstrations have highlighted some limit of the architecture that were not engineered as part of the initial design. However these can be easly overcome with the realization of a product. Below it is briefly listed some of the weaknesses point of the system: •

The space on the motorcycle, for the installation of various devices, is small and it has made difficult the implementation of the on board architecture

•

The capacity of power supply is limited to a few hours


Page 44 of 98

SP7 - SCORE


Copyright SAFESPOT



2.3.

Renault – Continental implementation

The V2V applications use cases relating to Intersections have been implemented by Renault S.A. and Continental. Road intersections represent one of the most complex configurations encountered when traversing road networks, different type of powered vehicles converge into them with vulnerable road users traversing using intersections to cross roads. In accidentology terms, a high number of accidents occur at these locations with the situation for the elderly representing a very high percentage [1]. Road Intersection safety could be regarded as a relative spatio-temporal problem with regard to its context, the intersection itself. Figure 2.3-1 represents a hypothetical situation of a crossroad type intersection where different types of vehicles converge. For the purpose of this analysis, the vehicle holding the cooperative application is known as the Subject Vehicle (SV). The subject vehicle (SV) arrives to the intersection, consequently the driver needs to be aware of the presence of all the vehicles or vulnerable road users that represent a risk. These include other vehicles (POV), potential risk vehicles or intruder vehicles (IV), vulnerable road users (VRU), high tonnage vehicles (HTV), etc. Whilst in principle, by mounting a front detection sensor, as shown in figure 2.3-1 is possible to detect other entities sharing the road, as represented by the triangular shape in the figure. However, occlusion will mask several potential risks like the diverting vehicle (DV), the power two wheeled vehicle (PTW), etc. Further, supposing that there is only the Intrusion Vehicle (IV) and that this arrives at a prohibited speed, it is impossible for the driver of the SV to know that the IV will not have sufficient space to brake at the stop line due to the speed at which it is travelling, presenting a risk to the SV.


Page 45 of 98

SP7 - SCORE


Copyright SAFESPOT



ESV VRU

DV

PTW

POV

SV = subject vehicle IV = intrusion vehicle DV= distracter vehicle HTV= high tonnage vehicle VRU= vulnerable road user ESV= emergency services vehicle PTW= power two wheel vehicle

HTV

IV

SV

POV

Figure 2.3-1 Configuration of a crossroad intersection in an Urban Environment (After [2])

V2V or V2I communications systems will lead towards the sharing of information between the vehicles or infrastructure. Information sharing would thus enlarge the situational awareness of the driver as shown in figure 2.3-2.

Information Facilitates comms. Link Enhanced

Figure 2.3-2 Establishing communications between vehicles and the infrastructure


Page 46 of 98

SP7 - SCORE


Copyright SAFESPOT



The principle applied to the design of the application follows the association in time and with respect to the intersection, of state variables representing the vehicle behaviour, that is its absolute position and speed, the former projected onto the Local Dynamic map. That is the projection of the vehicle states despite their uncertainty associated to it in time and space is projected. Figure 2.3-3 shows the spatial relationship that would exist at a given time between the vehicles with respect to the intersection shown in figure 2.3-1. Therefore, if the spatio-temporal situation of the vehicles arriving at the intersection is known together with their speed, it will be possible to infer what can be notified to the SV driver, according to the a priori contextual information associated to the target intersection.

VRU

DV

POV

PTW

IV

HTV

Figure 2.3-3 Establishing communications between vehicles and the infrastructure

The above outlines the context within which the Renault-Continental applications were implemented. That is: •

The relative position of the vehicles with respect to each other and to the intersection to which they are converging is very important. It represents the spatial relationship between all entities. Positioning System in SP3;

•

The time at which measurements is taken is critical as all entities are in motion with respect to each other. Time Stamping and Synchronisation in SP1 and SP3;

•

Context is provided by the road geometric description in the LDM where the vehicles positions are written. Local Dynamic Map in SP3;

•

The sharing of vehicle state information in a timely manner. VANET in SP3.

Within this perspective the implementation has been centred on the use of the referred SAFESPOT components for the implementation of the application.


Page 47 of 98

SP7 - SCORE


Copyright SAFESPOT



2.3.1. Implemented architecture Within this perspective the implementation has been centred on the use of the referred SAFESPOT components for the implementation of the application. The Renault vehicles were different from many implementations in the following points: •

The LDM was the NAVTEQ version;

•

The modems used during most of the testing were from Hitachi rather than the standard modems used by other partners;

•

The positioning system did not use the SP3 solution or one using external references. It was based on an Inertial Navigation System solution that provided accurate readings. 2.3.1.1.

System Description

Within this perspective the implementation of the applications has been centred on the use of the referred SAFESPOT components. Two Renault vehicles namely an Espace IV and a Laguna III were used each having exactly the same configuration. A system block diagram of each of the vehicles is shown in figure 2.3-4. The main characteristics of these are outlined in the diagram as well as the interaction with the various components. GPS antenna GPS antenna

High grade GPS receiver Odometry interface

Trajectometer

VANET Modem

Emulation Vanet PC

IMU + CPU Position Emulation PC

SP1 & LDM PC

Application

PC

Vehicle Gateway

Vehicle CAN-bus

• • • • • •

Gateway: Interface to vehicle CAN-bus Positioning System Purpose Built Map LDM Fusion Process Application Computer RF Modems 5.9GHz

GPS antenna GPS antenna

High grade GPS receiver

Trajectomete r IMU

VANET Modem

Emulation Vanet PC

+ CPU

Odometry interface

Position Emulation PC

SP1 & LDM PC

Vehicle Gateway

Vehicle CAN

-bu s

Figure 2.3-4 Block Diagram representation of the test vehicles

A fundamental characteristic of the systems is that direct contact with the vehicle is made using the Vehicle Gateway that reads data in the vehicle canbus. The overall system configuration follows that from as outlined in the SAFESPOT architecture.


Page 48 of 98

SP7 - SCORE

Application

PC


Copyright SAFESPOT



2.3.1.2.


The implementation is based on the use of PC-type computers connected via an Ethernet switch; all the computers are running the Windows XP Operating System, except the VANET router that is running a FEDORA version of LINUX. Both vehicles use similar hardware; the major components are as follows: •

CAN gateway. CVSFM600, embedded system supplied by Viveris Technologies, the gateway to the vehicle can-bus. It has been programmed to give only access to the can-bus messages used in SAFESPOT. The unit has limited telematic capabilities. It had difficulties on providing GPS time-stamped data.

•

Positioning System. A COTS system is used, the LandINS from IXEA [7]. An inertial-based positioning system that uses an inertial measurement unit based on fiber-optic type gyroscopes, a surveyor type GPS and the vehicle odometry. It provides technology georeferencing data (3D position, heading, roll and pitch) for landbased vehicles. It operates in real-time conditions at high precision. The system output was translated so it is compliant with the SAFESPOT messages. This is done in what has been labeled as the Positioning PC.

•

VANET PC. This is the VS-EmRunner as recommended by the project consortium. It was used to run the earlier versions of the VANET software, under the LINUX OS, the Fedora release.

•

RF Modems. The modems used in the initial configuration were from Hitachi, they are RF compliant with the SAFESPOT used frequencies. They were used as a black box acting as repeaters on data managed from the VANET PC.

•

Main PC. This is an Axiomtek eBox638-FL, it hosts the SP1 framework as well as the LDM from Navteq. The hardware was recommended by our project partners. It runs the Windows XP operating system.

•

Applications PC. This is an Axiomtek eBox638-FL, it hosts the applications software written by Renault and Continental. The hardware was recommended by our project partners.

•

Timing GPS. A U-blox GPS unit was used to generate the all important synchronization time.

•

Ethernet Switch. An Ethernet switch was used linked all the various computer units.

Figure 2.3-5 shows the schematic description of the hardware deployed in the project. The messages sent to the driver were displayed on a LCD screen connected to the application computer.


Page 49 of 98

SP7 - SCORE


Copyright SAFESPOT



Figure 2.3-5 Implementation SAFESPOT System in the Renault Vehicles

2.3.1.3.


The manner in which the various software components were implemented into the various computers is shown in figure 2.3-6.

WiFi

Generic NTP Client

NTP Server

Hitachi PC WiFi Antennas

Netcat Pipeline ?

Application PC NTP Client

Emergency Service Vehicle A. ?

VanetPC

Main PC

Netcat Pipeline

NTP Client IP LDM – Navteq

Positioning PC NTP Server

SP1-Framework Vanet DAQ

OR

SR

NTP Client EgoPositioningData

EgoPositioningData

Gateway (CVS) GatewayReader

SetTimeByGPS

RSA SafeSpot Converter CAN BUS

Ublox

GPS Antenna

Configuration

LandINS (iXSea) Configuration GPS Antenna

Figure 2.3-6 Implantation of the software components inside the System Hardware

A particularity of this implementation is that the Hitachi modems used are connected via a Netcat type pipeline with the VANENT PC where the


Page 50 of 98

SP7 - SCORE


Copyright SAFESPOT



standard SAFESPOT software is running. As stated before the Positioning PC is acting as a translator of the IXSEA based localization system output in order to have a SAFESPOT compatible message that is used in the SP1 framework. The application PC runs two types of applications, the ones by Renault, which is the Emergency Service Vehicle Use case and the Intersection related use cases by Continental. The later uses an in-house real-time visualization software, that allowed for the visualization of the vehicles arriving to the intersection, their projection onto a geometric representation of the roads. This is a very powerful visualization tool that facilitated the debugging. Figure 2.3-7 shows an instance of this visualization tool, the arrival to the intersection of the Emergency Service Vehicle together with the warning given through the Safety Margin based Driver Interface.

Figure 2.3-7 Visualization tool developed by Continental and User Interface applied to road Intersections

The synchronization of the PC was made via the use of an NTP server which was aligned with respect to the GPS time. The server was used in both vehicles. Shareware software was used for this purpose. The allocation of software and version control as implemented in the Renault vehicles is shown in a diagram form in figure 2.3-8.


Page 51 of 98

SP7 - SCORE


Copyright SAFESPOT


Contract N. IST-4-026963-IP Positioning PC

GPS system time updater NTP server IP setting Haliburton/UDP SAFESPOT Position converter

Main PC

Gateway CAN / Ethernet

WAVE software from Hitachi Ethernet / Wireless player

SWITCH

NTP client IP setting CAN vehicle / UDP SAFESPOT converter

NTP client IP setting DHCP server Continental Application Manager Renault SP4-1F dll application Continental SP4-1x applications HMI Manager Message Manager

NTP client ADASRP server Navteq LDM (v6.0) Geometric Map data of La Brosse & Satory site area SP1 framework for NQ (v 7.2)

Hitachi Modem

OS + tools Message framework from CRF ESPOSYTOR

Applications

RENAULT LAPTOP

Figure 2.3-8 Distribution of software into the PC-type computers

2.3.2. List of implemented use cases The implemented use cases were tried as part of activities of the West Test Site, there were tried in the LaBrosse area and at the Satory test site near Guyancourt. The HMI consisted of the HMI and debugging screens showing the movement of all vehicles participating in the test, as shown in figure 2.3-6. This interfaces enabled an easier synchronization the vehicles approaching the intersection, since for road intersection safety (RIS) the triggering conditions for the applications to be launched requires the correct tempora-spatial synchronisation of both vehicles; else the applications could not be triggered or the notification made too late. The Use Cases were tested at different speeds in order to increase the test space. Due to safety reasons, 80 km/h was the highest speed at which the tests were performed. Testing was performed for 4 Use Cases; these were demonstrated at the Cooperative Mobility Showcase 2010 in Amsterdam: •

Use Case 1a, Accident at intersection. Here, one of the vehicles pretended to have had an accident at the intersection while another vehicle was approaching the intersection.

•

Use Case 1b, obstructed view at intersection. During the trials the occlusion vehicle was a non-SAFESPOT vehicle whilst both vehicles converging to the intersection were full SAFESPOT vehicles.

•

Use Case 1c, Permission denial to go ahead. One vehicle is standing at the intersection while the other is approaching it. Only visual warnings are given, their level is defined by the speeds and


Page 52 of 98

SP7 - SCORE


Copyright SAFESPOT



distances that exist between them as they converge to the intersection. •

Use Case 1f, Approaching Emergency Vehicle Warning. One vehicle represents an emergency service vehicle (ESV) approaching the intersection. The subject vehicle converges to the same intersection in a way that it would interfere with the emergency vehicle. The use of V2V communications is made to increase awareness of the ESV presence and warn the driver in the SV accordingly.

Use Case 1d, malfunction of the traffic sign, was not tested, the way that it is implemented it will show the same results as those of Use Case 1c. Therefore, and since other issues already took most of the resources, the additional work of building up the traffic light for the tests was difficult. Use Case 1e is not tested, since it is not implemented. Figure 2.3-9 shows Use Case 1 a, the geolocation of the vehicles on the road tracks traced for the Mobility 2010 demonstration together with the icon shown to the driver when the message identifying the accident becomes pertinent.

Figure 2.3-9 shows Use Case 1 accident at an Intersection

The graphic indicates that not only the correct position of the vehicles projected onto the road geometry is necessary but that the geometry representation of the road should be precise. The Use Case 1f, Approaching Emergency Vehicle implemented at the Satory test circuit and during the demonstration at Amsterdam. The ESPACE IV vehicle emergency service vehicle and the Laguna as the subject


Warning was Mobility 2010 acted like the vehicle. Figure

Page 53 of 98

SP7 - SCORE


Copyright SAFESPOT



2.3-10 shows the geolocation of the vehicles on top of the road geometry traced as part of the Mobility 2010 demonstration.

Figure 2.3-10 shows Use Case 1f, Approaching Emergency Vehicle Warning

The figure shows the messaged displayed in the driver HMI, with the level of warning increasing from yellow, to orange, to red as the vehicles converge to the same road intersection. This is the display shown to the users. 2.3.3. Major integration compliance

issues

and

systems

architecture

Integration of the various systems was extremely difficult and took longer that what was planned in terms of time and manpower. The main reason was that most software was not entirely debugged prior to the integration task. That is, software was not ready for integration and version incompatibility existed. Several design choices should have been done better and some of the selected equipment was not appropriate. Further, at one point Renault was the only SAFESPOT partner using the Navteq LDM as well as the Hitachi modems. Whilst the former took considerable time to be operational, the later proved to be difficult to interface with the VANET system. The applications have been developed using simulated data and in Matlab, different strategies were formulated and tested via simulation. Despite the innumerable bugs and incompatibilities an initial preliminary integration test was made using the Hitachi modems. The first version of the implementation was compatible fully with the SAFESPOT architecture. It uses the all of its features: object refinement, map-matching, queries onto the LDM, and data sharing between both vehicles.


Page 54 of 98

SP7 - SCORE


Copyright SAFESPOT



Difficulties encountered were mainly the integration of Software that at times had multiple bugs, these appeared as the integration advanced hampering most efforts. The integration done at Helmond by TNO assisted very much as it was used as a benchmark. Map matching difficulties remain, likely due to the accuracy of the road geometry in the LDM and the map-matching algorithms. The later are very simple. All tests performed were successful. During the course of testing several issues with the SAFESPOT system were detected and reported via the non compliance form process or through direct contact to the respective developers. Finally, all crucial problems where resolved and the application tests could be run successfully. Prior to the Cooperative Mobility Showcase 2010 the latest version of the VANET was used running on an Ubuntu release of Linux OS, together with the Peek modems, this allowed full compatibility with the SAFESPOT architecture and thus communications with other nodes like the Road Side Unit developed by the LIVIC laboratory. All the applications are based on the environment developed by Continental and their powerful visualisation tool. A particularity of the RIS use cases is that they need full operation of the SAFESPOT components for them to be functioning correctly. A major issue was de synchronisation of the time bases on the computers of all the vehicles. Delays appeared overtime despite the use of NTP servers, resulting in latencies in the overall system that stopped the operation of the applications. Time synchronisation of the computers was difficult and time consuming. It is very important to remark that during the implementation the range of the communications links was poor, simple obstacles will create disruptions, the modems used were prototypes, tests with modems used elsewhere demonstrated that communications links even in cluttered environments could be maintained. 2.3.4. Issues during field trials Field trials were systematic, that is the working of the various elements was made for each vehicle when these were static and when in motion. Testing was limited to the Brosse intersection area and the Satory tracks site. The main track resulted in the road intersection delineated for the Mobility 2010 demonstration. The major issues found during the field trials were: •

SP1 Framework. This is the core software of the cooperative vehicles platforms. The map matching features are included within the framework. Whilst it basic features are able to sustain the functions for which it was designed, it is not as tolerant to positioning estimation and road network geometric errors. The implemented map matching processes is less error tolerant to existing COTS systems. Delays within the network are intrinsically variable and affected by uncertainty, thus a temporal-spatial association of information was difficult. It was then very difficult to understand when things did not operate properly. Latencies were sometimes reaching levels directly perceptible, by using the SAFESPOT visualisation


Page 55 of 98

SP7 - SCORE


Copyright SAFESPOT



tool, in terms of instabilities of the position in the LDM. In this context the fusion processes within the SP1 framework play an important role, in order to compensate for the system latencies, missing data, and uncertainty in the data handled as at times - even in ideal conditions - some wrong representations occur. •

LDM. The map is what holds all the information together. It contained the necessary information in terms of nodes and segments representing the road geometry for which the maps were used. The maps were for very small areas. They needed to be precisely geolocalised as errors implied that the applications were not longer operational. For the RIS use cases the precision of the maps is very important as all estimations are with respect to the intersection. It is to note that queries to the LDM for the RIS use cases were simple, e.g. what is the distance between the vehicle and the intersection? The main issue in the overall process is how to address latencies within the overall framework.

•

Localisation Function. The spatial relationship between vehicles is a major factor in the RIS use cases. Tests were performed with standard automotive type GPS units, the results were not encouraging. The solution taken by Renault relies on a tactical level IMU integrated to a surveyor level GPS, this proved to be very effective, but not a solution to be integrated onto the vehicles. The solution developed as part of SP3 was difficult to integrate, the loosely coupled approach would not provide the precision required. Renault opted for the decoupling of the positioning function from the rest of the architecture to focus on the use the applications.

•

VANET. The first set of modems used did not have sufficient reach to work in the la Brosse intersection. It was difficult to link the vehicles and when this existed it was unreliable. Figure 2.3-11 shows pictures taken of the environment found at the la Brosse intersection. In open space the problem did not exists though latencies were not periodic. A major issue was time stamping synchronisation between computers in both vehicles. The use of the NTP server took considerable time for this to come to effect. Latencies between the vehicles’ clocks were at times more than 200 ms, which resulted in the wrong representation of the vehicles on the LDM. Further over long periods there will be clock drifts, thus there was the need to re-synchronise again the clocks in the PCs onboard all the vehicles.


Page 56 of 98

SP7 - SCORE


Copyright SAFESPOT



Véhicule masque stationné

Arrivée véhicule sujet

véhicule sujet Trajet véhicule « urgence »

Figure 2.3-11 Spatial context for the La Brosse intersection

•

Applications. The applications listed above were implemented and tested on site. Particulars of the level of acceptance made attained with the applications are made else where.

Use Case 1f was demonstrated at the Satory site with vehicles driven by Renault Managers, responsible for the evaluation of driving assistance systems for safety applications. Each participant did not know any details of the applications; they only have outsider knowledge of the project details. After the initial briefing, each participant has driven the vehicle activating the use case. That is, they were driving the SV vehicle and participated actively in the demonstrations/test. The potential of the V2X was well accepted, this was followed by a discussion on the manner in which such system could be deployed. The use case 1.f was presented to the EU commission at the Mobility 2010 event, at total of 370 visitors were hosted in the subject vehicle, the Renault Laguna. Figure 2.3-12 shows both vehicles operating during the demonstrations.

Figure 2.3-12 Use Case 1f at Mobility 2010


Page 57 of 98

SP7 - SCORE


Copyright SAFESPOT



Other than the communication range limits observed during the implementation of the RIS use cases. The following phenomenon was several times observed. The information held by the subject vehicle (SV) about another vehicle (the Principal Other Vehicle - POV) is not always sufficient for the SV to localize correctly the POV on the LDM. As a result the system onboard the SV will not be aware that the two vehicles could be heading towards the same intersection; hazardous conditions might arise. Figure 2.3-13 illustrates what occurred during one of the field experiments. It starts with the SV and POV ~500 m apart, with both vehicles establishing a communications link. The vehicles drive towards the same intersection, until they reach the intersection without any communications break. Both vehicles are equipped with the same high-precision IMU-based localization system, thus each can estimate accurately its own trajectory, as illustrated in figure 2.3-13 (SV in blue, POV in red). The vehicles share their position via V2V communications. However, the SV is not able to estimate correctly the trajectory of the POV; the map-matching algorithm running in SV localizes POV on the wrong road (dotted line in the top of figure 2.3-13). This was unexpected, as the data used by SV and POV to localize the POV is the same: position data comes from the localization system, and the same mapmatching algorithm runs in both vehicles. The main difference is on the information received by the SV about the position of POV via V2V communications. It was observed that the link is not ideal. When vehicles are far some messages were lost. The lack of positioning data, coupled with inaccuracies in the digital map geometric descriptions, plus the likely weakness in the map-matching function, leads to a large initial error in the trajectory estimation, as illustrated in figure 2.3-13. The POV as seen from the SV is assigned to the wrong road with the error being propagated through the rest of the experiment. The position of the vehicles will be interpreted as not converging to the intersection. Vehicle localization is a major issue for situational awareness.

Figure 2.3-13 Localization and map-matching issue during SAFESPOT experiments


Page 58 of 98

SP7 - SCORE


Copyright SAFESPOT



2.3.5. Final remarks / Recommendations The following remarks and recommendations can be made out of the field experienced gained whilst deploying the RIS use cases: •

Experiments showed the limitations of the wireless networks, the need for clock synchronisation and time stamping, and for means to compensate for communication delays or breaks as well as for data time alignment.

•

The importance of localisation systems in cooperative vehicles was highlighted. Contrary to applications developed elsewhere, there was no reliance on road side units that should improve communications links. This is not feasible with series vehicles; the Renault solution though autonomous is not economically feasible. Currently different alternatives are being examined. If cooperative vehicles will be deployed, COTS systems are needed with precise information that should provide also the synchronisation data, likely leading to a minimum performance standard that should be required for systems to be incorporated in cooperative vehicle applications.

•

The testing of these systems remains a challenge in terms of resources, other than the test site, drivers, etc. means to quantify and log results are needed. Further, to trigger safety mechanisms, hazardous situations needed must be created, this implies a level of risk limiting evaluations. Large scale tests must take into account these considerations, and likely a combined strategy is needed, trials in dedicated sites and standard traffic conditions as well as advanced simulation.

•

Future work should centre on the building of digital representations for decision making and on the development of metrics to effect quantitative performance assessments.


Page 59 of 98

SP7 - SCORE


Copyright SAFESPOT



2.4.

MIZAR implementation

The aim of this implementation was to demonstrate the Use Case SP5_UC34: Detection of Wrong Way (Ghost) Driver (described in D5.2.1). This Use Case was one of the SP5 Hazard and Incident Warning applications (H&IW_02). The objective of the system is to detect a vehicle travelling in the wrong direction and to generate warning messages broadcasted to approaching vehicles that might collide with the “wrong way” vehicle. The warnings were delivered both via roadside devices (e.g. VMS) and also sent by the roadside unit (RSU) to the HMI of two SAFESPOT vehicles (provided by TNO and Daimler) through the V2I communications channels of the VANET. The roadside sensing technology adopted was the Wireless Sensor Network (WSN) developed in SP2. Figure 2.4-1 shows the configuration of the components deployed for the demonstration and field trials.

Figure 2.4-1 Hardware installed on the test site LEGEND Wireless sensor nodes VMS panel BMW vehicle INCA vehicle / DAIMLER vehicle Wrong way direction Correct direction Traffic light Lane lights


Page 60 of 98

SP7 - SCORE


Copyright SAFESPOT



From system interoperability perspective, the demonstration included several significant aspects as there is an overall interdependence between the various actors for the use case to be operational: •

I2V messages had to be received by vehicles provided by different partners (TNO and Daimler), and with the SAFESPOT software running in different versions;;

•

Different versions of the Local Dynamic Map (LDM) were also used: the RSU and Daimler used the TeleAtlas version whilst the TNO vehicles used the Navteq LDM version;

•

Two applications ran concurrently within the same area, therefore the HMI message corresponding to the respective application had to be displayed on the vehicles.

The description in this section focuses on the system architecture particularly the infrastructure side components (the RSU), as well as the I2V and V-I communications. Details on the vehicle are given in Chapter 2.4 written by TNO. A separate report has been written describing the full test results, this forms part of one of the deliverables for the SP5 subproject under references D5.2.2 and D5.6.3. The demonstration for the use cases at the Cooperative Mobility Showcase 2010 reproduced a situation in which a driver has unintentionally entered a motorway exit road in the wrong direction as it travels towards the motorway. If vehicles on the motorway intending to take this exit are not warned, and if the wrong way vehicle is not stopped, there is a high risk of a serious head-on collision.


Page 61 of 98

SP7 - SCORE


Copyright SAFESPOT



2.4.1. Implemented architecture The block diagram level architecture shown in figure 2.4-2 represents an instance of the SAFESPOT Guyancourt architecture (source, SP5 deliverable D5.4.2) mapped to the SP5 applications. The modules in the bottom part of the figure represent the Infrastructure Platform (developed by SP2), those in the central part are representing the LDM and VANET (developed by SP3) and those in the top represent the modules used as part of the SP5 infrastructure-based applications.

Figure 2.4-2 Architecture of roadside elements (SP2 and SP5)

For the Wrong Way Driver implementation demonstrated at the Amsterdam Show case, two modifications were made to the standard system architecture: •

The Message Manager, instead of operating as an external module, it was integrated within the SP5 application H&IW02. This modification implied that fewer processes needed to be executed within the Road Site Unit.

•

In order to activate the VMS signs in the CRF vehicle used as part of the H&IW02 to display messages from the roadside unit, it was necessary to add an electrically operated switch (relay) managed by the RSU. This component was not described in the original architecture as the inclusion of a VMS was not foreseen. This component was added because the VMS was purposely built for this demonstration.


Page 62 of 98

SP7 - SCORE


Copyright SAFESPOT



2.4.1.1.

System Description

For the Wrong Way Driver scenario, three vehicles were used: an INCA and BMW Series 5 (provided by TNO) and a Mercedes Benz S-class (provided by Daimler). The roles of the vehicles were as follows: I. The application developed for the INCA vehicle can display warnings (sent via the VANET) on the in-vehicle HMI as well as to provide haptic feedback to the driver via the vibrating seat; II. The Daimler vehicle was also equipped with an HMI for displaying VANET messages; III. The application developed for the BMW acted as the wrong way vehicle and did not communicate with the infrastructure or other vehicles via the VANET. When a wrong way driver was detected, the H&IW_2 application generated the following warnings: IV. Red warning lights, installed at the end of the slip road, were activated to alert the wrong way driver (the application on the BMW vehicle) to stop and prevent it entering the outer circuit. V. A message displayed on a VMS panel on the outer circuit warned all vehicles travelling in the outer circuit (in the correct direction) that the slip road is temporarily closed. The message on the VMS alternated the icons shown in figure 2.4-3.

Figure 2.4-3 Icons displayed on VMS panel

VI. A warning message was sent via the VANET to the SAFESPOT equipped vehicles (INCA and Daimler) travelling on the outer track in the correct direction. The HMI display indicated an icon representing the presence of a Ghost Driver. In the INCA vehicle a haptic warning was sent to the driver in the form of the vibrating seat was activated. The Wrong Way Driver demonstration was made in conjunction with the Slipper road use case the same vehicles and alternated with the Slippery Road scenario in the same area).


Page 63 of 98

SP7 - SCORE


Copyright SAFESPOT



2.4.1.2.


Wireless Sensor Network (WSN) A network developed in SP2 consisting of three sensing nodes was mounted on the roadside barrier. It was connected to the RSU via a gateway. Figure 2.4-4 shows pictures of the WSN nodes attached to roadside barrier used to build the environment where the use case functions. The nodes hold sensors used to detect the presence of a vehicle crossing in front of them, it detects whether or not the vehicle is flowing against the expected direction.

Figure 2.4-4 COSSIB Wireless Sensor Nodes mounted on the roadside barrier

WSN gateway The role of the gateway PC was to connect the WSN with the roadside unit. It had remote system capabilities so it could be monitored at a distance. The principal function was to collect data from the sensors and send this to the RSU using UPD messages. Roadside Unit The roadside unit was a PC-type computer where the Data Fusion and the H&IW_02 application software together with the LDM were, and the LDM. VANET Router The VANET Router for the RSU part used 0.9.1003, for vehicle BMW VANET the VANET Router version was 0.9-1003. Figure 2.4-5 shows the manner in which the software has been implemented onto the system components.


Page 64 of 98

SP7 - SCORE


Copyright SAFESPOT



Figure 2.4-5 Software and Hardware implementation

2.4.1.3.


Data Fusion The Data Fusion version 5.0 software was used. It included a remote system which monitored the performance of the sensors. It could also present graphically the alerts, the state of the sensors, the detection of the vehicles arriving in the wrong direction, etc. The software had logging capabilities which together with backups of the LDM could be downloaded via a File Transfer Protocol program each day. Local Dynamic Map (LDM) The system used the TeleAtlas version of the LDM. Access to the LDM data was via the C++ interface CL_R1_9_10 version with the data model based on version 10.0.12 of the specifications. The spatial location of the sensors with respect to the absolute reference coordinate system was determined using GPS measurements. Esposytor The Esposytor software version 2.0.2.6 was used to monitor the infrastructure and vehicle part. H&IW Application The application software runs in the same PC-type computer used by SP2 framework. It is to note that he OS of this computer is Linux, configuration that facilitates direct access to LDM data. A summary of the software and hardware used in the implementation made by Mizar is shown in


Page 65 of 98

SP7 - SCORE


Copyright SAFESPOT



table 2.4-1.


Page 66 of 98

SP7 - SCORE


Copyright SAFESPOT



Table 2.4-1 Summary of the deployed Software and Hardware by Mizar

Hardware

Software

3 sensing nodes

LDA v2 (sensors)

Gateway PC RRbox Cabinet for the gateway WSN (RRbox) Cabinet for the road side components Roadside Unit (industrial PC ECW281B-ATOM)

RRbox Core app (Gateway) Windows CE for RRbox (Gateway)

Positioning notebook HP 6710b GPS: U-blox. Router ALIX C3

RRbox Core Windows CE for RRbox Linux version 8.04 (RSU) SP2 Data Fusion Framework H&IW_02 Application LDM v 10.0 Positioning software V 4.4

Router VANET 0.9.1003

2.4.2. List of Implemented Use cases The use case demonstrated and tested during the InterTraffic Mobility 2010 showcase was: •

SP5_UC34: Detection of wrong way (ghost) driver using WSN and warning of approaching SF-vehicle (Test IT_02)


issues

and

systems

architecture

A number of problems were encountered during the overall system integration phase. Whilst every effort was made to solve them prior to the demonstration at the Amsterdam Test Site, others could only be resolved during the on site preparation phase. These were mainly due to version incompatibilities but also linked with the performance of the system once everything was integrated. The main integration issues could be summarises as follows: Wireless Sensor Network, gateway and RSU The problems were mainly due to the system configuration rather than errors in the development of the components themselves. When the integration was performed between the WSN, gateway and RSU, the identification of the sensors was a problem. This caused wrong data to be written in the LDM for the traffic events. As a result, no traffic event was written in the LDM when a wrong way driver was present. The reason was due to wrong positioning information of the sensors in the static table of the LDM. By writing the correct absolute position of the sensors, the issue was resolved. The use of logs of


Page 67 of 98

SP7 - SCORE


Copyright SAFESPOT



the data fusion module proved to be very helpful as the issue could be tracked. RSU and VANET with Esposytor The integration of Esposytor with the RSU was straightforward requiring few configuration changes. Limits on the communications range resulted in the representation of the detected vehicle being shown by Esposytor as travelling in the incorrect direction. The reason was that the Data Fusion module did not change the last position of the vehicle when it went out of range. As a result, the vehicles shown by Esposytor remained in their last reachable position. The problem was resolved through the calibration of the time stamp difference between the vehicle beacons and that at the RSU. The correction was inserted as part of the configuration file setup for the Data Fusion module. RSU with VANET, communications with the different vehicles Whilst no problems were encountered in communicating with the vehicles, it is important to emphasize the interoperability of the various systems. Even though they had different versions of the LDM, these could receive standard messages though the VANET. The differences between the APIs of the different LDMs versions (Navteq and TeleAtlas was not a problem. The messages generated from the RSU used the API TELEATLAS and those messages were correctly received by vehicles using both NAVTEQ and TELEATLAS APIs. 2.4.4. Issues during field trial The field trials were an excellent means to examine the performance of the SAFESPOT system when running this V2I use case, the system operated constantly with multiple VANET nodes running in the proximity. The following provides a summary of the issues encountered: SP5 Application: During the test demo an anomaly coming from the SP5 application was found. This occurred after some hours, after around 6 hours of operation. The error implied the generation of HMI messages without geovalidity information, this effect was solved by MIZAR after the Amsterdam Demo. The problem was solved after an update of the system. The reason was a lack of memory in the application PC, and a modification in the software SP5 was implemented (a garbage collector system). WSN gateway: A second anomaly was identified in the software of the WSN gateway, this exception was very rarely the reason for this effect was related with the generation of logs and the amount of memory used. An update to the gateway was installed in the gateway on 25 May after this update the problem was solved.


Page 68 of 98

SP7 - SCORE


Copyright SAFESPOT



2.4.5. Final remarks / Recommendations Wireless Sensor Network: After calibration and adjustment, the wireless sensor network functioned very well and detected the wrong way driver on all vehicles passages (555 times). The connection of the system with the roadside equipment (lane lights controller and traffic lights) functioned well. V2I and I2V communications: The transmission of the beaconing data from the vehicles to the RSU worked in a correct manner for both vehicles. After identification of the critical situation (wrong way driver), the appropriate message was transmitted in all cases. Communication via 802.11p was successful. Even though in the test area a large number of applications transmitted and received beacon messages at the same time, the communication worked without interference. The latency of the VANET messages towards the vehicles using the VANET was around 1.5 second after the vehicle enters inside the geovalidity area (measurement made on-site, after the vehicle enters inside the geovalidity area). This value was sufficient to warn them to slow down and not take the exit road. Positioning: The positioning worked in an adequate way for this Use Case with optimized GPS. Accurate positioning was especially important for the correct working of the Esposytor monitoring system. Local Dynamic Map framework: The LDM contained all the necessary data for testing this H&IW application. The performance of the LDM was satisfactory. H&IW_02 application: The H&IW_02 proved to be stable and was able to cope with the requirements of this Use Case. Final recommendations for future implementations: •

The results demonstrated that cooperative systems are a spatiotemporal problem, thus time synchronization and positioning information are very important for the successful deployment of the applications

•

Good management of memory in the roadside unit is a significant aspect. The use of garbage collectors in the software components allowed an efficient work for the SP2 and SP5 applications.

•

The set-up process of all the components should be improved; the current procedure is not user-oriented. There are some constraints relating to the Operative System (Linux/Windows) and libraries versions.


Page 69 of 98

SP7 - SCORE


Copyright SAFESPOT



2.5.

TNO implementation

This section only describes TNO’s implementation of the Wrong Way Driver Detection and Slippery Road Detection as demonstrated at the Cooperative Mobility Showcase in Amsterdam (March 2010). Other partners that participated in the demonstration were MIZAR, MagnetiMarelli, DAIMLER and Ministerie van Verkeer en Waterstaat (RWS). Note that TNO also implemented and evaluated a Lane Change Manoeuvre Application in SP4 and Speed Alert and IRIS in SP5. Since these applications are fully described as well as their evaluation in SP4/SP5 the reader is referred to the respective deliverables ([9], [10], [11], [12] and [13]). It will not be included here. The applications involved two vehicles from TNO, one vehicle of Daimler and a road side barrier with RSU of Mizar. Here only the TNO side of the applications are described. To be able to demonstrate the two applications after one another and also because the road barrier had a specific length, the track shown in figure 2.5-1 was set-up at Amsterdam Airport for the Cooperative Mobility Showcase 2010 exhibition.

Figure 2.5-1 Test/demonstration track of Wrong Way Driver and Slippery Area Detection applications Legend Wireless sensors VMS panel BMW vehicle INCA vehicle / DAIMLER vehicle Wrong way direction Correct direction Traffic light Lane lights Slippery Area


Page 70 of 98

SP7 - SCORE


Copyright SAFESPOT



The scenario was driven with two vehicles. In the first round (anti-clockwise) one vehicle would enter the slip road (diagonal) from the wrong way (right driving direction is from upper right to lower left). The other vehicle continues along the outer ring. The vehicle driving in the wrong way is detected by sensors on the barrier and the RSU sends out a warning to the other vehicle not to use the oncoming slip road through a message in the vehicle and through a message on the panel (for unequipped vehicles and also for the spectators watching in Amsterdam). Then one vehicle continued to the slippery area, driving over it and detecting that it is indeed slippery. It then sends a warning to the other approaching vehicle (to be displayed in the vehicle) and to the RSU (to be displayed on a second panel).

Figure 2.5-2 BMW wrong way

In the figure above the BMW just has taken the wrong way and is stopped by a red light. The application developed on Daimler vehicle is receiving a warning message.

Figure 2.5-3 BMW and slippery area

The picture above shows the BMW vehicle approaching the slippery area (between the pylons). The panel shows no message since no slippery area


Page 71 of 98

SP7 - SCORE


Copyright SAFESPOT



has been detected yet. The Daimler vehicle is driving the diagonal slip road in the correct direction (see traffic sign).

Figure 2.5-4 BMW, Daimler and TNO car

In the figure above the application developed on BMW just detected the slippery road and notified the situation to other vehicles and to the RSU. A specific tool developed by MagnetiMarelli detect the message incoming to the RSU and activate the VMS panel with the slippery road warning 2.5.1. Implemented architecture As showed in the figures below, the SAFESPOT equipment consists of: 1. Main PC: common laptop where also the applications are running 2. Positioning: RTK GPS connected to the on-board ControlCIT/dSPACE computer 3. Gateway: ControlCIT/dSPACE computer 4. HMI via CVIS box and ControlCIT computer. Note that the CVIS box also provides audio feedback in both vehicles. The HMI in the BMW was realised differently through ControlDesk of dSPACE. 5. Router/VANET: first integration was done with the Alix/Ubiquity solution, and then the CVIS router was taken as the SAFESPOT router to be interoperable with CVIS.


Page 72 of 98

SP7 - SCORE


Copyright SAFESPOT



Figure 2.5-5 Volkswagen Passat (INCA) SAFESPOT equipment

HMI dSPACE Autobox

PC

Figure 2.5-6 BMW SAFESPOT equipment

2.5.1.1.

System Description

In the Amsterdam demonstration TNO participated with two vehicles: the Volkswagen Passat/INCA and the BMW. Latter vehicle was able to estimate the road friction level and send a VANET warning to surrounding vehicles and RSUs. The INCA implemented the External Message Application of SP4, picking up sent messages from other participants and displaying them to the driver. 2.5.1.2.


For a description of the implemented hardware the reader is referred to [9].


Page 73 of 98

SP7 - SCORE


Copyright SAFESPOT



2.5.1.3.


The implementation of the different software components is shown in following two figures: laptop (ControlDesk)

in-vehicle computer (‘dSPACE’)

GPS

HMI ebox router

Switch

vehicle CAN

gateway position application PC (slippery area detection and SendWarn)

laptop main PC (framework & LDM)

Figure 2.5-7 Software implementation in TNO’s BMW

In the BMW many computers are combined. The gateway, positioning and application ran on a dedicated real time system (Autobox of dSPACE). This was caused by the fact that this computer provided connections to the vehicle CAN bus, the RS232 output of the RTK GPS system. The application (estimation of the friction level between the tire and the road) uses sensors from the vehicle (CAN mainly) hence the application also ran on the dSPACE system. in-vehicle computer (‘ControlCIT’)

ebox router Switch ebox CVIS HMI

HMI

GPS vehicle CAN

gateway position

haptic devices

laptop main PC (framework & LDM) application PC (ExtMsgApp)

Figure 2.5-8 Software implementation in TNO’s INCA

The same argumentation also holds for the INCA, where the gateway and positioning are combined on a real time system (a TNO product called ControlCIT). The main PC and application PC are combined on a laptop.


Page 74 of 98

SP7 - SCORE


Copyright SAFESPOT



2.5.2. List of implemented use cases (referenced to relevant documents) The implemented applications are the External Message Application [14] and a form of Road Condition Status / H&IW [15, 16]. The implemented use cases for the Slippery Road Detection / Road Condition Status are [15, 16]: • Road Condition Status – V2I Based 8a; • Road Condition Status V2V Based 8b; • H&IW. 2.5.3. Major integration compliance

issues

and

systems

architecture

The mapping of the vehicles to the map turned out to be a difficult task, not working always in a satisfying manner. Lane mapping was inadequate to use for the lane change in earlier versions. Hence some workaround had to be applied and was kept for the tests. Updating of some LDM tables stopped at some times, this was most probably due to time misalignments between the different computers, a restart of the vehicles solved the problem. 2.5.4. Issues during field trial The final field trial is well described in the Annex to [10]. Major issue there was indeed the time synchronization of the different systems causing the framework to disregard information send by the other vehicle. A system restart including a new time synchronization was necessary after about 2.5 to 3 hours of testing. 2.5.5. Final remarks / Recommendations Taking all experiences with the system through usage over more than a year, the following conclusions and recommendations can be made: • Overall the system works quite well, even though it is only a prototype. • No major communication issues were met (after the first good setup in the Helmond demonstration) • Good positioning is very important for the safety related applications. Here an RTK GPS was used. Though expensive, this system still has limitations, like the range of the base station. Looking forward towards market introduction, research into cheap but precise positioning is still needed. The tested applications require a positioning precision of lane level, i.e. about 1 – 2m. • The last really remaining issue was the time synchronization of the different systems. First of all it should be noted that this is indeed a prototype system. Integration should solve some of the issues. However, solutions can also be found on the architectural side of the system.


Page 75 of 98

SP7 - SCORE


Copyright SAFESPOT



2.6.

Volvo implementation

Volvo Technology has developed a number of different V2V and V2I applications, namely Frontal Collision Warning (FCW), Road Condition Status (RCS) and Vulnerable Road User Detection and Accident Avoidance (VRUAA). These applications are all based on the SAFESPOT system architecture [8] which has been installed in two Volvo trucks located in Test Site Sweden and one Renault truck located in Test Site West. The applications use a blend of sensor equipment data and floating car data in order to give the driver of the vehicle proper warnings in time. Volvo has also been the representative for Test Site Sweden. The test site has shared space with a number of other European research project, synergies between the CVIS project and SAFESPOT have benefited a lot in the deployment of the two platforms. On the test site a number of road side units has been connected to the legacy system from the Swedish Road Administrator (SRA) and additional sensors has been installed on public roads in Gothenburg, the second largest city of Sweden, to support the V2V and V2I evaluation of the Volvo implemented SAFESPOT and CVIS applications. 2.6.1. Implemented architecture Volvo has implemented the SAFESPOT system [8] into vehicles and on roads at the Swedish test site. Below the architecture implemented by Volvo in vehicle demonstrators and on Test Site Sweden is described. 2.6.1.1.

System Description

Volvo implemented the SAFESPOT system in three normal productions trucks: a Volvo FH-520 6x2 tractor, a Volvo FH-520 6x2 rigid, and a Renault Premium Distribution Truck as shown in figure 2.6-1. They are three typical trucks for long, mid and short distances and are representative hosts for the communication based applications implemented by Volvo.


Page 76 of 98

SP7 - SCORE


Copyright SAFESPOT



Figure 2.6-1 Volvo demonstrators: a Volvo FH-520 6x2 rigid, a Volvo FH-520 6x2 tractor and a Renault Premium Distribution Truck

2.6.1.2.


The hardware installation challenge has been mostly to fit the computers into the vehicle, since there is not much space for installing computers inside the cabin, but also to ensure a stable power supply to all the equipment that will deliver power to the units regardless of if the truck is connected to external power or not. By sharing hardware for SAFESPOT and CVIS the installation has been simplified and the power consumption as well as space has been optimized. Each vehicle is equipped in order to integrate SAFESPOT and CVIS systems on a common reference platform, according to figure 2.6-2.


Page 77 of 98

SP7 - SCORE


Copyright SAFESPOT



Figure 2.6-2 SAFESPOT and CVIS common architecture – VOLVO implementation

Then the Volvo trucks have a connection to the in-vehicle data using a gateway as shown in figure 2.6-3.

Figure 2.6-3 SAFESPOT and CVIS common architecture – Connection to the in-vehicle data for the VOLVO trucks

Eventually, the Volvo FH-520 6x2 truck used as probe vehicle, is equipped with a Road Eye sensor and Laser Scanners for the benefit of the Road Condition Status and the Vulnerable Road User Detection and Accident Avoidance applications respectively.


Page 78 of 98

SP7 - SCORE


Copyright SAFESPOT



Figure 2.6-4 VOLVO SAFESPOT FH-520 6x2 architecture

The SAFESPOT vehicle equipment present in the Volvo demonstrator trucks has been described in detail in D1.4.2 [1]. Vehicle Installation Layout The SAFESPOT equipment is installed in the Volvo FH-520 6x2 truck and the Volvo FH-520 6x2. The Renault Premium Distribution Truck is smaller and cannot follow the same installation layout as the Volvo trucks. For the Renault Premium Distribution Truck the SAFESPOT components are mainly installed behind the seats inside the driver cabin in a dedicated compartment.


Page 79 of 98

SP7 - SCORE


Copyright SAFESPOT



Antenna rack

Ante nna Pos PC

Camera

Camera

Safespot PC compartment

Safespot PC compartment

Cvis PC (hmi host) compartment Batt box

Laser

Pos PC

Router

Road eye

Batt box

Laser

R o a d

Laser

Laser

Figure 2.6-5 System layout for Volvo FH-520 6x2 tractor and Volvo FH-520 6x2 rigid

Shared equipment (CVIS/SAFESPOT) Modified TGW

A Modified TGW was accessible on an Ethernet port on the vehicle LAN. The software has two different modes, one for SAFESPOT and one for CVIS. They are adaptations of the Semifot TGW platform. Communcation Router

The Communcation Router is located in the rear upper luggage compartment due to the connection to antennas on the roof. The Router is connected to the CVIS antenna, 12 V and the Vehicle Ethernet. It also contains a 3G communication card.


Page 80 of 98

SP7 - SCORE


Copyright SAFESPOT



Figure 2.6-6 Vehicle router

CVIS Host (Application PC)

The CVIS Host is used to run the common HMI as well as the SAFESPOT applications. It is located in the Right hand side Cabin luggage compartment. It is connected to the SID (Sound Interface Device), to a KVM switch and to the Ethernet network.

Figure 2.6-7 CVIS Host (application PC) Antennas

On the Roof the antennas are located. There is the CVIS Antenna, an additional 5,9 GHz Wlan Antenna for test and reference and the GSM/GPS


Page 81 of 98

SP7 - SCORE


Copyright SAFESPOT



antenna to the Vehicle Gateway. There is also a GPS antenna for the positioning reference system.

Figure 2.6-8 Roof antennas

2.6.1.3.


The deployed system utilizes synergies between the CVIS and SAFESPOT platform in order to share functionalities such as HMI and communication platform. A mid-wife software called Translator was developed by Ramsys that wraps SAFESPOT SP7 messages in CAM (Cooperative Awareness Message) and sends them as payload in the CALM M5 packets. The common HMI runs in a Java OSGI framework and the SAFESPOT applications sends UDP messages to the Java bundle in order to trigger HMI events. A modified version of the Volvo Telematic Gateway (TGW) is used to fetch vehicle parameters used in the data fusion of the SP1 framework. The SAFESPOT applications get all their data from the local dynamic map (LDM). Two different GPS receiver were used in the project, a standard uBlox receiver as well as a DGPS system. The latter was used when very high accuracy was needed.


Page 82 of 98

SP7 - SCORE


Copyright SAFESPOT



Figure 2.6-9 System Software Architecture

2.6.1.4.

Road Side Architecture at Test Site Sweden

The Swedish test site is located in Gothenburg the second largest city in Sweden and as such the use cases have been set in such an environment including tunnels, multiple vehicles etc.. The most important parameter for a successful ITS application is the data that is used in the applications. In order to get realistic data in the applications developed at the Swedish test site integration with the Swedish road administration was a crucial step. The Swedish Road Administrator (SRA) have a number of legacy systems in use that uses cameras, sensors etc to gather information about the traffic situation. In addition to information received from the infrastructure vehicle sensors were used (laser scanners) as well as CAN data (accurate speed, yaw rate etc). In combination with the data available in the local dynamic map, the applications could get the needed information. 2.6.2. Integration and cooperation with legacy system at Test Site Sweden The information from SRA to the Swedish test site is gathered from the SRA legacy systems such as Triss, Stress, VViS etc. In addition there is a system developed during the project that will monitor a number of different parameters and report changes to the test site.


Page 83 of 98

SP7 - SCORE


Copyright SAFESPOT



Figure 2.6-10 SRA Legacy systems

The DATEX messages are transferred to the test site via Internet.


Page 84 of 98

SP7 - SCORE


Copyright SAFESPOT



SRA BizTalk

DATEX

Internet DATEX

DATEX

Traffic Simulator

Standard D2Logical WebService

DATEXBroker DATEX Subscription DATEX

DATEX Subscription

Subscription DATEX

LSP Database Handler

DFLHandler

PTV Handler

PTV format WebService DATEXII

SQL

Internet DFL COMO Center

LSP Database (MS SQL Server)

UDP/IP

Filetransfer (ftp)

PTV

RSU

Figure 2.6-11 Testsite DATEX information flow

2.6.3. List of implemented use cases (referenced to relevant documents) Volvo has implemented three SAFESPOT V2V and V2I applications. • FCW – Frontal Collision Warning • RCS – Road Condition Status – Slippery Road • VRUAA –Vulnerable Road User detection and Accident Avoidance


Page 85 of 98

SP7 - SCORE


Copyright SAFESPOT



All these applications have been initially introduced in D4.2.2 - Safety Margin concept and in D4.2.3. The related functional specifications have been detailed in D4.3.2. The testing has been described in D4.5.1, D4.5.2 and the final evaluation of the implemented applications is written in D4.6.3. In below chapters a short description of the implemented use cases of the applications. 2.6.3.1.

Frontal Collision Warning

The General Use Case for the Frontal Collision Warning application provides assistance for general scenarios such as the one showed in the pictogram below. Recommendations are provided to the driver of the ego vehicle (actor 1 in the figure 2.6-12) in order to prevent the risk of frontal collisions due to static obstacles or unexpected queuing in front. The information about the obstacle can be sent from a probe vehicle or from the infrastructure. The application has been tested and evaluated on closed test tracks and in a tunnel.

Figure 2.6-12 FCW – General Use Case

2.6.3.2.

Road Condition Status – Slippery Road

The General Use Case for the Road Condition Status – Slippery Road is a generalisation of the two basic Use Cases, where the needed information about the slippery condition of the road segment is considered independently if the information source is from the infrastructure or direct from another vehicle. The application has been tested and evaluated on closed test tracks and on public roads.


Page 86 of 98

SP7 - SCORE


Copyright SAFESPOT



Figure 2.6-13 RCS – General Use Case

2.6.3.3. Vulnerable Avoidance

Road

User

Detection

and

Accident

The general use case for the Vulnerable Road User Detection and Accident Avoidance application is coincident with the use case 10a: Vulnerable road user crossing a road, based on on-board detection system. The application has been tested and evaluated on closed test tracks.

Figure 2.6-14 VRU – General Use Case

2.6.3.4. VANET (CALM M5) Datarate and performed by Volvo Technology and Qfree

range

tests

Two different tests/scenarios were conducted, one vehicle to vehicle test and one infrastructure to vehicle test. The objective of the tests were to messure the range and datarate of the M5 components of the CVIS communication platform. The vehicle-to-vehicle test were performed at high speed;two vehicles driving towards each other on an open highway, meeting on a bridge with relativly free sight. The second scenario was conducted in a typical urban environent with trees, buildings, vehicles and pedestrains that at times covered the area between the RSU (infrastructure) and the vehicle.


Page 87 of 98

SP7 - SCORE


Copyright SAFESPOT



Vehicle-to-Vehicle test The tests were performed on E6 at Kungälv north of Gothenburg. A Volvo cooperative truck and car (fully CVIS equiped) were driving towards each other with 2 lanes in each direction, all data throughput was logged and later analyzed.

Figure 2.6-15 imagine from vehicle

Figure 2.6-16 V2V data rate

From the analysis can be concluded that the vehicle becomes aware of the approaching vehicle at a distance of at least 200 meters. That is equal to 4 sec at a relative speed of 180 km/h.


Page 88 of 98

SP7 - SCORE


Copyright SAFESPOT



When departing the communcation window is more than 10 sec (180 km/h relative). The datarate is more or less constant in the window, independent of speed (ca 3.5 Mbit/s). There is a dip in the performance at around 300 meter which is probably due to a multipath issue. Infrastructure-to-Vehicle The tests were performed in the vicinity of the Swedish test site (Lindholmsallén). RSU 1 that is mounted in the infrastructure was used as a stationary point and a cooperative car was driven in circles around the RSU and all data throughput was logged and later analyzed. The RSU acted as transmitter and the cooperative car acted as receiver.

Figure 2.6-17 infrastructure location

Figure 2.6-18 Roadside to Vehicle data rate


Page 89 of 98

SP7 - SCORE


Copyright SAFESPOT



From the analysis can be concluded that the communcation link is good up to 600 meters. Some irregularities was noted, it could be due to the urban environment changing as we drive (trees and other objects obstructing the sight). A similar issue with a dip in the performance at around 300 meter was observed. 2.6.4. Demonstration events 2.6.4.1.

ITS WC Stockholm 2009

Volvo participated in the organization and demonstrations at the World ITS Congress in Stockholm 2009. During these demonstrations Volvo showcased the FCW, RCS and VRUAA SAFESPOT applications. The Dynamic Speed Limit, Access Control, Road Charging and Parking Zone applications from the CVIS project was also presented. In addition a joint session was set up where the joint effort between CVIS, SAFESPOT and COOPERS was demonstrated. The focus of the joint session demonstration was common/shared resources such as hardware platforms as well as data in three scenarios Dynamic speed limit, broken down vehicle, CAM Beaconing and LDM demonstration.

Figure 2.6-19 Demonstration of the FCW scenario

To allow as many observers as possible the audience observed the scenarios from a podium. Three screens showed a camera view from inside the vehicle and a remote desktop feed from the vehicle HMI.


Page 90 of 98

SP7 - SCORE


Copyright SAFESPOT



Figure 2.6-20 The presentation podium at ITS Stockholm 2009

2.6.4.2.

Cooperative Mobility Showcase Amsterdam 2010

At the Cooperative Mobility Showcase 2010 in Amsterdam Volvo participated with the two SAFESPOT equipped Volvo trucks. Together with a CRF car the two Volvo trucks was used to demonstrate the Frontal Collision Warning and the Head On Collision Warning application. The Frontal Collision warning was presented in a Volvo truck, while the Head On Collision Warning was presented by CORF car.

Figure 2.6-21 Cooperative Mobility Showcase 2010 – The use cases demonstrated included CRF & Volvo vehicles


Page 91 of 98

SP7 - SCORE


Copyright SAFESPOT



In these demonstrations the guest was invited into the vehicles for real life experience of the driving scenarios and the benefits of the cooperative applications.

Figure 2.6-22 Cooperative Mobility Showcase 2010 – A guest is received by the driver


issues

and

systems

architecture

The SP1 framework requires all data to be time synched in order for it to work properly. An NTP software was installed on the CVIS Router which could be used to synchronize clocks with the pulse of the GPS receiver. All computers within the vehicle network connect to the NTP server in order to not drift too much from the synchronized time. At times when the vehicle had no GPS connectivity the clock would drift, this had to be manually fixed in order to get the clock back in synch. 2.6.6. Issues during field trial During field operation trials we noticed that the SP1 would get overloaded when multiple vehicles were broadcasting floating car data in the same area. This would cause map-matching to fail for one or more of the vehicles. In order to solve this issue a black-list was introduced in the SINTECH router framework. However the SP1 framework is still only able to handle one vehicle at a time when performing map-matching. While performing sensor fusion tests we noticed that the yaw rate was not stable. This caused the heading of the vehicle to be misrepresented causing the projected trajectory to be incorrect. Hence the dead reckoning functionality was not reliable enough to use in some cases when doing sharp turns.


Page 92 of 98

SP7 - SCORE


Copyright SAFESPOT



2.6.7. Final remarks / Recommendations The positioning system used was not able to deliver lane accuracy. In order to achieve lane accuracy an expensive DGPS system was used during demonstrations. The SP1 framework needs optimization in order to be able to handle mapmatching of multiple vehicles. In future projects system scalability should be prioritized.


Page 93 of 98

SP7 - SCORE


Copyright SAFESPOT



3. Certification of communication interoperability Simulation of the certification process according to partner’s feedback & contributions.

3.1.

Certification Program

The European Commission issued a Standardization Mandate on cooperative ITS systems in October 2009. It gives political support for the ITS standardization and requires ETSI and CEN/CENELEC to produce a minimum set of standards in the field of cooperative systems to ensure interoperability for vehicle to vehicle communications (V2V), for vehicle to infrastructure communications (V2I) and for communications between infrastructure operators. European Standardization activities together with international cooperation are essential for successful, wide market deployment of new ITS systems and services. Standardization of new system interfaces and protocols can assure interoperability of the new ITS systems, make them more cost efficient to deploy and also allow fast market penetration. Currently ETSI is working to define technical specifications for ITS technologies. Interoperability and safety are critical success factors of future ITS services. Examples from global technology markets such as the cellular market show that having a well planned certification program in place can significantly increase the efficiency and quality of technology implementations, facilitating and speeding up the growth of new technology adoption. Certification programs have been and will be a key driver for worldwide ITS adoption. D7.4.3-Part B.1 describes an ITS certification program called in the context of SAFESPOT, SAFESPOT Certification Framework (SCRF). It aims to guarantee compliance to SAFESPOT Specifications and that the SAFESPOT devices will be interoperable with other vendor equipments. This certification programs identifies several players involved on it. One of the most important one is the Cooperative System Forum which is defined as an organized group of companies, laboratories and bodies that are aiming to promote, develop, certify, test and sell products containing ITS technology. A certification program provides several benefits: •

Easy Process to Follow: Having clear, documented certification process available is important. Also setting up a test laboratory or several laboratories that are capable to serve the international ITS community, and being available when vendor is ready to go for certification testing, is a clear benefit. Using web based tools can provide easy booking and access to certification process, allowing vendors to follow and monitor testing of each product. This can be provided by the laboratory. An experience laboratory can offer full service including experienced staff to perform services and offer support for all vendors. The need for any additional tasks and certification effort from the vendors should be removed when ever possible.


Page 94 of 98

SP7 - SCORE


Copyright SAFESPOT



•

Ensure Conformance and Interoperability: Ideally a certificate would guarantee that a certified device works in any commercial ITS network or environment in the world. Each device should need to be certified only once to be compliant with current certification requirements. This ensures faster time to market for new devices and supports global market growth.

•

Cut Testing Time and Cost: Having well defined certification process and established test laboratories in place, reduces testing time and cost significantly. Further there is an opportunity to use automated test tools to further improve efficiency, quality and reliability, since manual test operator intervention can always be considered as a source of uncertainty. Also using standardized languages like TTCN3, which is already used in ITS testing, improve cost efficiency and save time.

•

Benefits of Third Party Laboratories: Having accredited, commercial third party test laboratory for certification testing brings several benefits. These laboratories have quality controlled facilities, testbeds and test tools for all testing needs vendors require. Further, customer focused staff with experience in working with international customers from any continent is a clear benefit. Laboratory staff can take the full responsibility and care of the testing effort, and vendors do not need to train their own staff specifically for certification testing. Also, international commercial laboratories can offer vendors an access to additional Testing Services (‘one stop shop’ approach). External laboratories are used to compete in international business environment, offering efficiency, low cost and quick lead times for vendors.

•

Build Worldwide Market: Efficient certification program makes easier and faster for vendors to reach international market with their new products, which in turn attracts more companies to develop the technology. Also the greater confidence on the quality of the technology helps to boos adoption of new systems, considering both infrastructure to be build and new vehicles and devices consumers can purchase

Having in mind the tremendous success of this technology, ITS should consider seriously the fact of creating, firstly, a Forum (called Cooperative System Forum in this deliverable, but C2C-Consortium could be considered the proper one in the future) with the aim of promoting ITS Technologies, and secondly, a certification program, here the SCRF (SAFESPOT Certification Reference Framework), to achieve maximum interoperability between V2V/V2I products from different vendors.


Page 95 of 98

SP7 - SCORE


Copyright SAFESPOT



3.2.

Testing

All certification programs include a process where testing must be performed in order to check that a product interoperate with other products based on the same technology. D7.4.3-Part B.2 suggested that the key interfaces to be tested for improving the interoperability between vehicles and road side units are the vehicle-to-vehicle interface and the vehicle-to-infrastructure interface. In addition, D7.4.3-Part B.2 has provided a good state of the art of the different type of testing that should be taken into account, including Plugfest events, whose relevance and purpose are explained in the deliverable D7.4.3Part B.2. Concretely, SAFESPOT has used two of these types of testing: Plugtests (Test Site) and Conformance Testing (Test System Development). The first one is mainly focused on interoperability when the technology is at the early stage of its development, this type of testing is called plugtest and it has been performed in the different SAFESPOT Test Suite distributed around Europe. These test sites reproduce several vehicular scenarios characterizing real life driving contexts where highway, rural roads, test tracks, tunnels will be equipped as well as several vehicles where different applications, technologies, platforms, etc. from SAFESPOT Subprojects have been validated and the impacts and end-user acceptances have been also evaluated. The target of the second one is focalized on conformance testing based on the development of a test system mock-up as it was described in D7.4.4. This type of testing is considered mandatory in all certification programs and tries to check that an implementation is compliant to the technical specification used for implementing it. This type of testing shall be performed following a formal method. The first step to carry out is the definition of the test specification following a format procedure (ISO 9646 and ETSI recommendations) where TTCN-3 is considered the language to be used for developing the test cases. SAFESPOT has followed this procedure, and has produced a complete set of test specifications for the beaconing functionality (http://bscw.safespot-eu.org/bscw/bscw.cgi/163215) using TTCN-3, as well as developing a complete test system for validating the beaconing implementations. At the time being, ETSI is working in the definition of a complete conformance test specifications based on the CAM, DENM and geo-Networking technical specifications in order to achieve interoperability in this future standard.


Page 96 of 98

SP7 - SCORE


Copyright SAFESPOT



4. Conclusions The architecture formulated as part of SAFESPOT has probed to be very effective. This was implemented and tested intensely as part of tasks associated to the work on the test sites, but mainly in the three major demonstrations. The level of sophistication attained increased as demonstrators moved from Helmond, Stockholm and Amsterdam. Different versions software and hardware were used, notably for the VANET, the LDM and the positioning modules. Whilst typical integration difficulties were found in such a large project with modules developed across Europe by R&D engineers rather than software developers, the demonstrations showed that an excellent level of integration and interoperability was achieved. The document has presented in detail representative use cases as shown during the various demonstrations, the contributors have shared their own experiences, what it worked and what it did not. They key for the success can be found in the formulation of an architecture where all stakeholders could find themselves. This was followed by the modularity of the various systems components, the standardisation of messages evolving within the onboard system as well as via the VANET. Another important factor was the flexibility of project partners in accommodating for the unknowns found during the integration process. Making an abstraction of integration issues, the proof of concepts of the multiple use cases demonstrated have shown that cooperative vehicles is and remains an spatio-temporal problem. Reliance and the need for good localisation technology, the synchronisation of onboard clocks and the communications infrastructure were demonstrated. Further, the use of the LDM as the centre where all information can be stored following a well defined structure was crucial for the successful demonstrations. A question remains on the manner in which the switching between the different use cases could be made in a reliable manner that is to trigger the correct applications. Whilst tests were made very successfully and much was learnt during the process these remain a challenge in terms of resources. Further, tests are difficult to implement, it requires risk situations like in the case of the overtaking and intersection related use cases, to make them in real traffic conditions implies the reproduction of risk situation that might not be at times controllable. Further testing with large numbers of vehicles remains prohibitive. With this respect simulation techniques like the one used for the MARS software used in the project are very important. Access to test sites and quantitative measurements of performance are important, thus a test facility where such systems could be tested in conditions similar to those found in everyday traffic would contribute to progress in the domain. In conclusion SAFESPOT applications were successfully demonstrated using all the features that have incorporated in the SAFESPOT architecture. The architecture is complex and needs to be optimised. Today it is interoperable and connectivity of multiple nodes have been achieved. Successfully addressed problems include those relating to the precision of the localisation systems, the quality of the digital maps and latencies plus range in the communication systems.


Page 97 of 98

SP7 - SCORE


Copyright SAFESPOT



Finally, the demonstrators allowed better interactions with project partners and thus for researchers to build networks, learn about different working practices and the use of different types of equipment. From a research perspective, the main issue resides on the overall system integrity to warrant that the different safety functions should operate correctly despite the presence of errors like position uncertainty, communications latencies, accuracy on the attributes of the LDM and the spatial description, etc. In the implemented vehicles and infrastructure specific means to ensure an high level of integrity across the system have been developed. Latencies and clock synchronisation are very important. Perhaps a standard ensuring a minimum bound in the performance of key modules could be proposed. The document has provided a means to compile the experiences of the major implementations within SAFESPOT and to share across the project the field experiences acquired during the implementation process.


Page 98 of 98

SP7 - SCORE


Copyright SAFESPOT



References [1] [2] [3] [4] [5] [6] [7]

[8]

[9] [10] [11] [12] [13] [14] [15] [16]

D3.3.4 – Vehicular Ad hoc Network Specification v1.1, SAFESPOT SP3 SINTECH, 2007-11-19. User Data Format & Messages v2.3, SAFESPOT SP7 SCORE, 2008-0109. D3.4.2 – Implementation Plan v3.6, SAFESPOT SP3 SINTECH, 2008-0204. D7.4.3 – SAFESPOT Certification reference framework – Part B v1.0, SAFESPOT SP7 SCORE, 2008-04-24. Requirements Catalogue for VANET – Beaconing v1.0, SAFESPOT SP7 SCORE, 2008-04-02. Test Suite Structure and Test Purpose for VANET – Beaconing v1.0, SAFESPOT SP7 SCORE, 2008-04-08. LandINS, positioning system, http://www.ixsea.com/en/mobile_mapping_airborne_survey/1/landins.html accessed on the 20th of April 2010 D7.3.1 - SAFESPOT Core Architecture, Global System Reference Architecture Specification, SAFESPOT SP7 SCORE

D4.2.2 – Equipped Cars Integrating the Safety Margin Applications, SAFESPOT SP4 SCOVA D4.6.3 – Results Evaluation, SAFESPOT SP4 SCOVA D5.6.2 - Evaluation on Urban Roads, SAFESPOT SP5 COSSIB D5.6.4 - Evaluation on Rural Roads, SAFESPOT SP5 COSSIB D5.6.5 – Evaluation Final Report, SAFESPOT SP5 COSSIB D4.3.2 – Applications Functional Specifications, SAFESPOT SP4 SCOVA D4.2.3 – Use Case and Typical Accident Situation, SAFESPOT SP4 SCOVA D5.2.3 – Application Scenarios and Requirements, SAFESPOT SP5 COSSIB


Page 99 of 98

SP7 - SCORE