safe strip safe and green sensor technologies for self- … · 2020. 4. 7. · deliverable d6.1:...

SAFE STRIP SAFE and green Sensor Technologies for self-

explaining and forgiving Road Interactive aPplications

Grant Agreement Number: 723211

Work package WP6: User trials Activity A6.1: Evaluationf framework and pilot plans Deliverable D6.1: Initial report on pilot framework and plans

Authors Maria Gkemou (CERTH/HIT), Javier Romo Garcia, Manuel

Ignacio Gonzalez Hernandez (CIDAUT) Co-authors Giannis Gkragkopoulos, Aristotelis Spiliotis, Evangelos Bekiaris

(CERTH/HIT), Andrea Steccanella (CRF), Natalia Kalfa (ATTD),

Thanasis Kotzakolios (UPAT), Elisa Landini (RELAB), Francesco

Biral (UNITN), Sarah Cros (VALEO)

Status Final Version V2.0 Dissemination Level Public Document date 18/11/2018 Delivery due date 31/10/2018 Actual delivery date 18/11/2018 Internal Reviewers Eleni Tirogianni (ATTD), Blanca Araujo (CIDAUT) External Reviewers Prof. George Dimitrakopoulos

This project has received funding from the European Union’s

Horizon 2020 Research and Innovation Programme under grant

agreement no 723211.

D6.1: Initial report on pilot framework and plans

Deliverable D6.1: Initial report on Pilot framework and plans Version V2.0 Date18/11/2018 2

Document Control Sheet

Version history table

Version Date Modification reason Modifier

0.1 15/10/2018 First version of Deliverable with

methodology, skeleton and request for

feedback.

M.Gkemou,

CERTH/HIT

0.2 21/10/2018 Second version, with feedback integrated.

Additional feedback requested regarding

topologies and KPI’s.

M.Gkemou,

CERTH/HIT

1.0 23/10/2018 Third version, provided for peer review. M.Gkemou,

CERTH/HIT

1.1 05/11/2018 Fourth version, implementing peer review

comments with additional requests for

optimisation and with respect to

interdepencies with other Deliverables.

M.Gkemou,

CERTH/HIT

2.0 18/11/2018 Final version, towards submission to the

EC.

M.Gkemou,

CERTH/HIT

Legal Disclaimer This document reflects only the views of the author(s). Neither the Innovation and

Networks Executive Agency (INEA) nor the European Commission is in any way

responsible for any use that may be made of the information it contains. The

information in this document is provided “as is”, and no guarantee or warranty is

given that the information is fit for any particular purpose. The above referenced

consortium members shall have no liability for damages of any kind including without

limitation direct, special, indirect, or consequential damages that may result from the

use of these materials subject to any liability which is mandatory due to applicable

law. © 2017 by SAFE STRIP Consortium.


Table of Contents

TABLE OF CONTENTS ........................................................................................................ 3

LIST OF TABLES ................................................................................................................... 5

LIST OF FIGURES ................................................................................................................. 7

ABBREVIATION LIST .......................................................................................................... 8

EXECUTIVE SUMMARY ................................................................................................... 10

1 INTRODUCTION ........................................................................................................ 12

1.1 PURPOSE OF THE DOCUMENT ..................................................................................... 12

1.2 INTENDED AUDIENCE .................................................................................................. 12

1.3 INTERRELATIONS ........................................................................................................ 12

2 SAFE STRIP PROJECT AIM AND OBJECTIVES ................................................. 12

3 METHODOLOGY ....................................................................................................... 14

4 SAFE STRIP FUNCTIONS, BASELINE AND USE CASES .................................. 15

4.1 SAFE STRIP FUNCTIONS, BASELINE & MAPPING TO USE CASES ............................. 15

4.2 INTENDED AND UNINTENDED EFFECTS OF SAFE STRIP AND STAKEHOLDERS

INVOLVED IN EVALUATION ................................................................................................. 26

5 EVALUATION FRAMEWORK ................................................................................. 36

5.1 EVALUATION OBJECTIVES OF THE TRIALS .................................................................. 36

5.2 OVERVIEW OF EVALUATION PLAN FOR 1ST AND 2ND ROUNDS WITH USER TRIALS ....... 48

5.3 REAL-LIFE EVALUATION SCENARIOS (ES) OF THE TRIALS ......................................... 49

5.3.1 Introduction & Guideline to the users ............................................................... 49

5.3.2 ES1.1: Virtual VRU protection of Mobile Cooperative safety function ............. 51

5.3.3 ES1.2: Wrong Way Driving of Mobile Cooperative safety function .................. 54

5.3.4 ES2.1: VRU protection of In-vehicle Cooperative safety function .................... 55

5.3.5 ES2.2: Wrong Way Driving of In-vehicle Cooperative safety function ............. 58

5.3.6 ES3: Road wear level and predictive road maintenance ................................... 59

5.3.7 ES4.1: Work zone detection of In-vehicle application for rail crossing and road

works safety function ...................................................................................................... 60

5.3.8 ES4.2: Railway crossing detection of In-vehicle application for rail crossing

and road works safety function ....................................................................................... 62

5.3.9 ES5.1: Work zone detection of Mobile application for rail crossing and road

works safety function ...................................................................................................... 63

5.3.10 ES5.2: Railway crossing detection of Mobile application for rail crossing and

road works safety function .............................................................................................. 65

5.3.11 ES6.1: Urban intersection of In-vehicle application for merging and

intersection support (e2Call) .......................................................................................... 66

5.3.12 ES6.2: Intersection with wet/dry road condition of In-vehicle application for

merging and intersection support (e2Call) ..................................................................... 68

5.3.13 ES6.3: Motorway exit of In-vehicle application for merging and intersection

support (e2Call) .............................................................................................................. 70

5.3.14 ES7.1: Urban intersection of Mobile application for merging and intersection

support 71

5.3.15 ES7.2: Intersection with wet/dry road condition of Mobile application for

merging and intersection support (e2Call) ..................................................................... 73

5.3.16 ES7.3: Motorway exit of Mobile application for merging and intersection

support (e2Call) .............................................................................................................. 75


5.3.17 ES8.1: Virtual VMS 1 – Critical case of In-vehicle application for

personalised VMS/VDS and Traffic Centre Information ................................................ 77

5.3.18 ES8.2: Virtual VMS 2 – Critical case of In-vehicle application for


5.3.19 ES8.3: Virtual VMS 2 – Non- Critical case of In-vehicle application for


5.3.20 ES9.1: Virtual VMS 1 – Critical case of Mobile application for personalised

VMS/VDS and Traffic Centre Information ..................................................................... 81

5.3.21 ES9.2: Virtual VMS 2 – Critical case of Mobile application for personalised

VMS/VDS and Traffic Centre Information ..................................................................... 82

5.3.22 ES9.3: Virtual VMS 2 – Non- Critical case of Mobile application for


5.3.23 ES10.1: Dynamic trajectory estimation of Autonomous vehicles support .... 84

5.3.24 ES10.2: Definition of lane-level virtual corridors of Autonomous vehicles

support 85

5.3.25 ES10.3: Tollgates management of Autonomous vehicles support ................. 86

5.3.26 ES10.4: Work zones detection of Autonomous vehicles support ................... 87

5.3.27 ES11: Virtual Toll Collection of Application for Virtual Toll Collection ..... 88

5.3.28 ES12.1: Numbered parking with payment of Application for parking booking

and charging ................................................................................................................... 90

5.3.29 ES12.2: Free of charge parking of Application for parking booking and

charging 91

5.3.30 ES12.3: Regulated parking (blue zone) of Application for parking booking

and charging ................................................................................................................... 92

5.3.31 Cross Use Cases Evaluation Scenarios (C-ES) - UNITN ............................. 93

6 DIRECT, DERIVED AND SELF-REPORTED MEASURES/METRICS &

MEASURING TOOLS ......................................................................................................... 98

6.1 DIRECT (RAW) & DERIVED MEASURES ....................................................................... 98

6.1.1 ES1.1: Virtual VRU protection of Mobile Cooperative safety function ............. 98

6.1.2 ES1.2: Wrong Way Driving of Mobile Cooperative safety function ................ 100

6.1.3 ES2.1: VRU protection of In-vehicle Cooperative safety function .................. 102

6.1.4 ES2.2: Wrong Way Driving of In-vehicle Cooperative safety function ........... 105

6.1.5 ES3: Road wear level and predictive road maintenance ................................. 107

6.1.6 ES4.1: Work zone detection of In-vehicle application for rail crossing and road

works safety function .................................................................................................... 108

6.1.7 ES4.2: Railway crossing detection of In-vehicle application for rail crossing

and road works safety function ..................................................................................... 110

6.1.8 ES5.1: Work zone detection of Mobile application for rail crossing and road

works safety function .................................................................................................... 112

6.1.9 ES5.2: Railway crossing detection of Mobile application for rail crossing and

road works safety function ............................................................................................ 114

6.1.10 ES6.1: Urban intersection of In-vehicle application for merging and

intersection support (e2Call) ........................................................................................ 117

6.1.11 ES6.2: Intersection with wet/dry road condition of In-vehicle application for

merging and intersection support (e2Call) ................................................................... 119

6.1.12 ES6.3: Motorway exit of In-vehicle application for merging and intersection

support (e2Call) ............................................................................................................ 121

6.1.13 ES7.1: Urban intersection of Mobile application for merging and intersection

support 123

6.1.14 ES7.2: Intersection with wet/dry road condition of Mobile application for

merging and intersection support (e2Call) ................................................................... 125

6.1.15 ES7.3: Motorway exit of Mobile application for merging and intersection

support (e2Call) ............................................................................................................ 128


6.1.16 ES8.1 & ES9.1: Virtual VMS 1 – Critical case of In-vehicle/Mobile

application for personalised VMS/VDS and Traffic Centre Information ..................... 130

6.1.17 ES8.2 & ES9.2: Virtual VMS 2 – Critical case of In-vehicle/Mobile


6.1.18 ES8.3 & ES9.3: Virtual VMS 2 – Non- Critical case of In-vehicle/Mobile


6.1.19 ES10.1 – ES10.4: Autonomous vehicles support functions ......................... 136

6.1.20 ES11: Virtual Toll Collection of Mobile application for Virtual Toll

Collection 139

6.1.21 ES12.1, ES12.2 and ES12.3 of Mobile application for parking booking and

charging 141

6.1.22 Cross Use Cases Evaluation Scenarios ....................................................... 143

6.2 SELF-REPORTED METRICS ......................................................................................... 148

7 EXPERIMENTAL DESIGN FOR 3RD ROUND TRIALS ...................................... 150

7.1 EXPERIMENTAL STUDY DESIGN ................................................................................ 150

7.2 PARTICIPANTS RECRUITMENT .................................................................................. 159

7.3 DATA ANALYSIS AND STATISTICS ............................................................................. 161

8 TEST INFRASTRUCTURE ...................................................................................... 161

8.1 TEST SITES AND DEMONSTRATORS .......................................................................... 161

8.2 TEST AREA AND TOPOLOGIES ................................................................................... 162

8.3 ITS LOGGING MECHANISMS ...................................................................................... 165

9 LEGAL, ETHICAL ISSUES & DATA MANAGEMENT PLAN .......................... 166

10 IMPACT ASSESSMENT FRAMEWORK .............................................................. 167

10.1 OBJECTIVE ............................................................................................................ 167

10.2 SCOPE AND TIMING .............................................................................................. 168

10.3 IMPACT ASSESSMENT FRAMEWORK ..................................................................... 169

10.4 TRAFFIC MODELLING (MICRO/MACRO) .............................................................. 171

10.5 COST-BENEFIT ANALYSIS .................................................................................... 172

10.5.1 Scenarios for Cost Benefit Analysis ............................................................ 172

10.5.2 Efficiency measurement ............................................................................... 172

10.5.3 Societal impact assessment based on Cost Benefit Analysis ....................... 173

10.5.4 Value of societal benefits (avoided costs) ................................................... 174

10.5.5 Value of costs for SAFE STRIP ................................................................... 179

11 NEXT STEPS .............................................................................................................. 180

REFERENCES .................................................................................................................... 182

ANNEX 1: INFRASTRUCTURE SET-UP FOR THE USER TRIALS ......................... 184

ANNEX 2: DRIVER AND RIDER BEHAVIOUR QUESTIONNAIRE ........................ 193

ANNEX 3: SUBJECTIVE TOOLS FOR DRIVERS/RIDERS AND OPERATORS IN

1ST ROUND OF USER TRIALS ........................................................................................ 205

ANNEX 4: TEST CONDUCTOR FORM/EVENT DIARY ............................................ 215

List of Tables Table 1: SAFE STRIP functions, mapping to UC’s, baseline context, dependability

requirements and limitation. ................................................................................... 16

Table 2: SAFE STRIP intended effects in short - medium/long term and relevant

stakeholders. ........................................................................................................... 27


Table 3: SAFE STRIP Research Questions, mapping to KPI’s and relevant functions to

evaluation rounds and user groups. ........................................................................ 37

Table 4: ES1.1.1 – Experimental conditions. ......................................................................... 52


Table 6: ES1.2 – Experimental conditions. ............................................................................ 54



Table 9: ES2.2 – Experimental conditions. ............................................................................ 59

Table 10: ES3 – Experimental conditions. ............................................................................. 60

Table 11: ES4.1 – Experimental conditions. .......................................................................... 61
















Table 27: ES10.1 – Experimental conditions. ........................................................................ 85




Table 31: ES11 – Experimental conditions. ........................................................................... 89




Table 35: C-ES1– Experimental conditions. .......................................................................... 94

Table 36: C-ES2 – Experimental conditions. ......................................................................... 96

Table 37: ES1 - research questions addressed, KPI’s, hypotheses & metrics. ....................... 98

Table 38: ES1.2 - research questions addressed, KPI’s, hypotheses & metrics. .................. 100



Table 41: ES3 - research questions addressed, KPI’s, hypotheses & metrics. ..................... 107














Table 55: ES10.1 – ES10.4 - research questions addressed, KPI’s, hypotheses & metrics. . 137

Table 56: ES11.1 - research questions addressed, KPI’s, hypotheses & metrics. ................ 139





Table 60: RQ, KPIs, hypotheses and subjective measures. .................................................. 148

Table 61: User trials plan for 1st evaluation round with user trials (3rd evaluation round SAFE

STRIP overall). ..................................................................................................... 152

Table 62: User trials plan for 2nd evaluation round with user trials (4th evaluation round of

SAFE STRIP overall). .......................................................................................... 157

Table 63: Example of variables definition for the accident data enquiry. ........................... 175

Table 64: Number of casualty accidents, fatalities, hospitalised injured casualties and non-

hospitalised injured casualties and their percentage distribution (Spain, 2016). .. 176

Table 65: Accident cost components and accident severity types per 2020 in the EU member

states (in 1000 €) (Source: HIPEBA project). ...................................................... 177

Table 66: Cost-unit Rates of Varying Benefit Components (Valid for period 2010-2020)

(Source: Deliverable D3 eIMPACT project). ....................................................... 178

Table 67: Congestion costs due to accidents with fatalities and severe injuries over location

and time of day (Source: Deliverable D4, eIMPACT project). ............................ 179

List of Figures Figure 1: SAFE STRIP evaluation methodology. ................................................................... 14 Figure 2: SAFE STRIP implementation & testing plan outline. ............................................. 48 Figure 3: CRF selected test site spot for 1st user trials round. .............................................. 163 Figure 4: ATTD selected test site spot for 1st user trials round. ........................................... 164 Figure 5: Thessaloniki peri-urban selected test site spots for 1st user trials round. ............... 164 Figure 6: ITS-LM for logging during user trials. .................................................................. 166 Figure 7: Cost-Benefit Analysis approach (own elaboration). ............................................. 172 Figure 8: Cost-Benefit Analysis model (own elaboration, based on Deliverable 3 eIMPACT

project). .................................................................................................................. 174 Figure 9: Flowchart of the Safety Impact assessment methodology. .................................... 177 Figure 10: Scheme for the breakdown cost evaluation. ......................................................... 180


Abbreviation List Abbreviation Definition

ASIL Automotive Safety Integrity Level

BLE Bluetooth Low Energy

CBA Cost – Benefit Analysis

CBR Cost – Benefits Ratio

CEA Cost – Effectiveness Analysis

C-ITS Cooperative Intelligent Transport Systems

DALI Driving Activity Load Index

DBQ Driver Behaviour Questionnaire

DENM Decentralized Environmental Notification Message

DoW Description of Work

DPA Data Protection Agency

DPO Data Protection Officer

ES Evaluation Scenarios

EU European Union

EUNET European UNIX Network

FOT Field Operational Trial

GDPR General Data Protection Regulation

GPS Global Positioning System

HMI Human Machine Interface

I2V Infrastructure to Vehicle

I2X Infrastructure to All

ICT Information and Communication Technologies

ID Identity Document

IEC International Electrotechnical Commission

IRI International Roughness Index

ISO International Organization for Standardization

ITS Intelligent Transportation Systems

KPI Key Performance Indicator

LM Logging Mechanisms

LTE Long Term Evolution

MRBQ Motorcycle Rider Behaviour Questionnaire

NPV Net Present Value

NTP Network Time Protocol

OBU On Board Unit

OEM Original Equipment Manufacturer

ORU On Road Unit

PDO Property Damage Only

POPD Protection Of Personal Data

PTW Powered two Wheelers

QM Quality Management

QoL Quality-of-Life

RFID Radio Frequency Identification

RQ Research Question

RSB Road Side Bridge

RTRRM Response Type Road Roughness Meter

SAE Society of Automation Engineers

SoA State-of-the-Art

SUPR-Q Standardized User Experience Percentile Rank Questionnaire

TMC Traffic Management Centre

UC Use Case


Abbreviation Definition

V2I Vehicle to Infrastructure

V2V Vehicle to Vehicle

V2X Vehicle to All

V2X Vehicle to All

VDS Variable Direction Sign

VMS Variable Message Sign

VRU Vulnerable Road User

VSL Variable Speed Limit

WP Work Package


Executive Summary

SAFE STRIP aims to introduce a disruptive technology that will achieve to embed C-

ITS applications in existing road infrastructure, including novel I2X and V2X, as well

as VMS/VSL functions into low-cost, integrated strips on the road pavement; to make

roads self-explanatory and forgiving for all road users (cars, trucks and vulnerable

road users, such as PTWs riders) and all vehicle generations (non-equipped, C-ITS

equipped, autonomous), with reduced maintenance cost, full recyclability and added

value services, as well as supporting real-time predictive road maintenance functions.

The vast potential of SAFE STRIP will be demonstrated through 9 Use Cases

reflecting specific applications (or applications clusters) as follows:

1. Virtual Cooperative safety function

2. Enhanced Cooperative safety function

3. Road wear level and predictive road maintenance

4. Rail crossing and road works safety functions

5. Merging and Intersection Support: e2Call

6. Personalised VMS/VDS and Traffic Centre Information

7. Autonomous vehicles support

8. Virtual Toll Collection - for non-autonomous vehicles

9. Parking booking and charging

The current Deliverable, entitled D6.1: Initial report in Pilot framework and plans, is

prepared in the context of WP6: User trials. It delineates the overall evaluation

framework for the user trials that will be conducted in the project lifespan, across 2

rounds, the specific experimental plans for the first round of user trials as well as the

first insights on the impact assessment framework.

It is underlined that the current document as well as WP6 overall addresses solely the

plans for the user trials of the project. All technical validation rounds have and will be

systematically monitored in WP5: “System integration” and, in specific, A5.6:

“Technical validation & Test Sites set-up”, whilst the first Deliverable has been

already released respectively (D5.4: Test sites set-up and experimental technical

validation plan).

The first round of user trials is placed in the context of the third validation round of

the project overall (out of four in total) and will be conducted in Attiki Odos highway

(and in a selected Thessaloniki periurban road only for the level crossing use case) in

Greece and in the closed test track of CRF in Italy. Prior to the first round of user

tests, the final (third in the row) technical validation phase will be conducted to

optimise the overall system and all functions of the project and to allow final

corrections and optimisation before proceeding with the user trials. The first round

will be conducted around March 2019 and the second round around November 2019.

In specific, Chapter 1 introduces this document purpose, intended audience and

interrelations, Chapter 2 reminds the project aim and objectives and Chapter 3

presents the iterative evaluation methodology to be applied, Chapter 4 presents the

SAFE STRIP functions, their baseline, their mapping to the project Use Cases as well


as their intended and unintended effects in short-medium and long term horizon,

Chapter 5 presents the overall evaluation framework, starting from the Research

Questions standing also as Evaluation Objectives and their mapping to Key

Performance Indicators (KPI’s) and SAFE STRIP functions, continuing with the

overall evaluation plan for both rounds, and, closing with the real-life evaluation

scenarios and their experimental conditions that will be run in the first round of user

trials for the evaluation of each SAFE STRIP function.

In total, there have been identified 13 Research Questions/Evaluation Objectives and

29 key evaluation scenarios (without estimating the sub-scenarios in their context).

Chapter 6 continues with the direct, derived and self-reported metrics and tools that

will implement the monitoring of KPI’s during the trials per each evaluation scenario

and Chapter 7 presents the detailed experimental plan for the first round of user trials

as well as an overview of the one for the 2nd round of user trials. Chapter 8 presents

the test infrastructure of the project, encompassing the test sites and demonstrators,

the infrastructure topologies per type of scenario (attached in Annex 1), the

provisionally selected specific test site spots for the first round and the ITS logging

mechanisms that will be built for the logging of the system and driver/rider

performance. Chapter 9 discusses the ethical and data management aspects of the

project, Chapter 10 presents the first version of the impact assessment framework,

whereas Chapter 11 concludes the deliverable with the next steps planned. Annex 1

presents the Driver Behaviour Questionnaire that will serve for the clustering of

drivers and riders participating in the trials, Annex 3 provides the subjective

measuring tools that will be used in the first round of user trials, and Annex 4

provides the test conductor form.

The first round of user trials will be small scale Field Operational Trials in controlled

environment. The project demonstrators that will participate in them are namely:

• A FIAT – 500L (passenger car) provided by CRF.

• A VW – PASSAT (autonomous passenger car) provided by VALEO for the

autonomous functions evaluation.

• A PIAGGIO MP3 (motorcycle - PTW) provided by PIAGGIO.

• A Renault Espace (passenger test vehicle) provided by CONTI (for the

dynamic friction coefficient estimation).

• A Lancia – Thesis (passenger car) provided by CERTH/HIT.

• A PIAGGIO – MP3 Hybrid (motorcycle - PTW) provided by CERTH/HIT.

There will be 13 drivers, 10 riders and 2 infrastructure operators representatives per

test site, recruited by the SAFE STRIP testing entities participating in the first round

of trials, whereas the above numbers will be doubled for the second round that will be

concluded with focus groups with representatives from the whole value chain (around

10 in each test site).


1 Introduction

1.1 Purpose of the Document This document is prepared in WP6: User Trials and, in specific, in A6.1: “Evaluation

framework and Pilot plans” and aims to present the upper level evaluation framework

for the user trials that will be conducted in the SAFE STRIP project across 2 rounds

and the experimental plans for the first round. It also aims to present the impact

assessment framework that has been established in parallel in order to allow the later

impact assessment study of the project.

It should be highlighted that technical validation of the system is not an objective of

this or its successive documents, as it is fully tackled in the dedicated activity A5.6:

Technical validation and test sites set-up and reported in D5.4: Test sites set-up and

experimental technical validation plan (submitted) and D5.5: Updated experimental

technical validation plan & results (for M24).

The current document might undergo internal revisions before the commencement of

the first round of user trials. Any updates on the experimental plan of the first round

as well as the experimental plans of the second round will be described in D6.2: Final

report on Pilot framework and plans”.

1.2 Intended audience This Deliverable is public and as such, it will be made available through the project

web site Library. The current deliverable, apart from setting up the context of the

project evaluation approach and plans, can prove to be of interest of relevant

initiatives dealing with evaluation of C-ITS.

1.3 Interrelations This Deliverable is related to the technical validation plans of WP5 (D5.4 and D5.5).

Whereas WP5 focuses on all different technical validation aspects of the project,

across the three first evaluation rounds of the project, WP6 focuses solely on the user

trials of the system.

Also, the scenarios of the project Use Cases, as they have been described in D1.2:

SAFE STRIP Use Cases have constituted the basis for the real-life scenarios that are

going to be reproduced in field. Whereas the Quality of Service indicators have

constituted the starting point for the measures/metrics of assessment during the trials.

2 SAFE STRIP Project aim and objectives SAFE STRIP aims to introduce a disruptive technology that will achieve to embed

C-ITS applications in existing road infrastructure, including novel I2V and V2I,

as well as VMS/VSL functions into low-cost, integrated strips markers on the

road; to make roads self-explanatory (with personalised in-vehicle messages) and

forgiving (due to advanced cooperative functions) for all road users (trucks, cars and

vulnerable road users, such as PTWs riders) and all vehicle generations (non-

equipped, C-ITS equipped, autonomous), with reduced maintenance cost, full


recyclability and added value services, as well as supporting real-time predictive road

maintenance functions.

The project’s aim will be realised through the following objectives:

Objective 1: To develop a novel micro/nano sensorial system – called SAFE

STRIP – integrated in road pavement tapes/ markers; that will provide advanced

safety functions to all road users at a fraction of the cost of current I2V/V2I nodes

and roadside equipment (VMS, VDS, etc.).

Objective 2: To support predictive infrastructure maintenance, through dynamic

road embedded sensors input.

Objective 3: To make road infrastructure (mainly for highways and interurban

roads but also for city rings and selected rural roads) self-explanatory (through

personalised info in own language and preferred format provided by the system to

each driver/rider) and forgiving (through key I2V/V2I info provided to the

cooperative system of the vehicle; such as dynamic speed limit and friction

coefficient factor); for all vehicle types.

Objective 4: To extend this notion to parking depots, key intermodal nodes, such as

railway crossings, harbor loading/uploading areas and logistic depots and –above all

– work zone areas.

Objective 5: To reduce the infrastructure operational (including VMS/VSL info and

toll collection functions), installation and maintenance costs by orders of magnitude,

make it nearly energy autonomous and its modules fully recyclable.

Objective 6: To provide key info to C-ITS equipped and autonomous vehicles

about road, weather and traffic conditions ahead, to support dynamic trajectory

estimation and optimisation.

Objective 7: To support a wide range of added value services (through “pushed”

info to the driver/rider) and facilitate the SAFE STRIP rapid market deployment and

sustainability through efficient business models.

Objective 8: To evaluate the system in a controlled environment (test bed in Spain,

in France and 2 closed test tracks in Italy) and real life conditions in 2 sites

(highways in Greece and Italy) with 4 car and 3 PTW demonstrators, validate its

performance, evaluate user interface and acceptance aspects and, finally, assess its

impacts to safety, mobility, the environment and European industrial

competitiveness.


3 Methodology The approach for structuring the evaluation framework and experimental plans of

SAFE STRIP has been based on FESTA methodology, as described in the latest

version of the FESTA handbook [v6; 5] and the CONVERGE (TR 1101)

methodology, as adapted and extended within the INSAFES subproject of PReVENT

[9].

Overall, SAFE STRIP user trials can be seen as small scale Field Operational Trials

in controlled environment. This is valid for both rounds planned, though the second

round will be of larger scale than the first round of user trials.

The following figure reflects the methodology followed by SAFE STRIP for its

evaluation and impact assessment.

In short, upon the definition of the SAFE STRIP functions and their mapping to UC’s

and baseline identification, the intended and unintended effects for stakeholders in

short/medium and long term have been recognised. The Research

Questions/Evaluation Objectives have in turn in defined, mapped to the SAFE STRIP

functions and also mapped to Key Performance Indicators (KPI’s), testing rounds and

user groups involved. In order to enable testing of the defined evaluation objectives

and KPIs, the real-life evaluation scenarios have been structured in a step-wise format

for each SAFE STRIP function and on the basis of the project use cases. The

experimental conditions for the 1st evaluation round with users have been also

defined. Those come together with the specific hypotheses that correspond to KPI for

each function, and the recognition of metrics that will be used for their assessment as

well as the measuring tools that will be used for this purpose in each case. All those

are placed in the context of an overall evaluation plan and its specific experimental

design that will be enabled by a specific test infrastructure that will be built. Legal,

ethical and Data Management principles will govern the trials, whereas the outcomes

of the latest will also feed the impact assessment of the project that is strongly related,

of course, to the project functions, their baseline and the research questions and KPI’s.

Figure 1: SAFE STRIP evaluation methodology.


4 SAFE STRIP Functions, Baseline and Use Cases

4.1 SAFE STRIP Functions, Baseline & Mapping to Use Cases SAFE STRIP target solution is a cooperative solution that implements I2X and V2X.

The innovative part of the solution lies in the cooperativeness and the fact that

through that, all types of vehicles, C-ITS equipped, autonomous and non-equipped

vehicles will enjoy the benefits of the technical solution that will be built on the road

infrastructure end.

In SAFE STRIP, the function to be tested is the road infrastructure solution that will

in turn enable C-ITS applications for vehicle drivers and infrastructure operators (one

targeted application). As thoroughly described in D1.2, the Use Cases scenarios

therein corresponds to each vehicle application that will be developed and will be C-

ITS enabled through the SAFE STRIP solution. As such, in reality, all Use Cases

correspond to different vehicle applications (and one application for infrastructure

operators) that serve as proof of concept of the same backbone.

It is reminded that SAFE STRIP functions, in their vast majority, are going to be

developed as in-vehicle applications for C-ITS equipped and autonomous vehicles

as well as mobile applications (delivered through mobile terminals) for non-

equipped vehicles. For the scope of the evaluation framework and experimental plans

the in-vehicle and the mobile counterpart, when existing, are considered different

applications (as they literally are).

The description of the functions are not repeated herein, as they are described in D1.2

in the context of Use Cases. The following table reflects the mapping of the SAFE

STRIP functions towards evaluation to the D1.2 project Use Cases. It also denotes

which is the baseline context that will serve as the “without the system” reference

case that will allow the impact assessment of the project, is in reality an objective of

the 2nd round and the primary and secondary actors in each. It should be noted that

baseline scenarios in SAFE STRIP are not always possible as it corresponds often to

situations that are not supported by ITS and it is extremely safety critical to run safety

related scenarios in real-traffic without any system support. For this reason, in those

situations, statistics will be used, whereas, whenever there is an existing process (i.e.

current passage with typical VMS or Toll stations), typical scenarios can be run

indeed. Still, there are cases that comparable applications have been developed in the

past (with alternative warning systems). In that case and if there is access to the past

app, baseline scenarios will be run.


Table 1: SAFE STRIP functions, mapping to UC’s, baseline context, dependability requirements and limitation.

No SAFE STRIP

function

Developer(s) Short description Primary & Secondary actors Relevant

UC

Baseline Dependability

requirements &

limitations (for

evaluation)

1. Mobile

Cooperative

safety function

UNITN Non-equipped

vehicles receive,

via a mobile app

from SAFE

STRIP cloud

server, the

warnings about

the presence of

VRU ready to or

crossing the road

and/or vehicle

coming from the

wrong way of a

motorway or gas

station exit.

By means of the

co-driver concept,

the warnings are

generated at cloud

level based on the

analysis of

potential and

feasible

Primary actor: The

drivers/riders/passengers of

non-equipped vehicles.

Secondary actor(s): The

driver/passenger of equipped

vehicles that are warned also of

the presence of non-equipped

vehicles (through V2V). Also,

the infrastructure operator for

the wrong way driving.

UC1 Baseline for

VRU

protection not

available

since SOLCO

industrial

project (BLT

based

detection)

was designed

for equipped

vehicle.

Baseline for

“Wrong Way

Driving”:

baseline not

available

since results

of Drive-C2X

project not

applicable

being

designed only

Maximum speed

in urban 50km/h

and 80km/h extra

urban.

Delay of

communication

via LTE greater

equal than 1s the

application cannot

warn the non-

equipped vehicle

when it less than

30m distance to

the crossing for

new VRU

approaching or

VRU changing

idea (e.g. leaving

the crossing).

System can detect

presence but not

speed and

direction of VRU.


No SAFE STRIP

function


UC


requirements &

limitations (for

evaluation)

manoeuvers the

driver can take in

the actual

scenario.

for equipped. Same problem for

Wrong way

driving but

distance is longer

(about 40m) due

to maximum

speed.

2. In-vehicle

Cooperative

safety function

UNITN Equipped vehicles

receive

information from

Safe Strip

technology about

the presence of

VRU ready to or

crossing the road

or vehicle coming

from the wrong

way of a

motorway or gas

station exit. By

means of the co-

driver concept, the

warnings are

generated in-

vehicle based on

Primary actor: The


equipped vehicles.


infrastructure operator for the

wrong way driving.

UC2 Baseline for

VRU

protection:

results from

SOLCO

industrial

project (BLT

based

detection).

Baseline for

“Wrong Way

Driving”:

results of

Drive-C2X

project where

warnings

were issued

manually by a

Maximum speed

in urban 50km/h

and 80km/h extra

urban.

System can detect

presence but not

speed and

direction of VRU.


No SAFE STRIP

function


UC


requirements &

limitations (for

evaluation)

the analysis of

potential and

feasible

manoeuvers the

driver can take in

the actual

scenario.

road operator.

3. Road wear level

and predictive

road maintenance

UPAT This function

serves for the

detection in real

time of critical

deformations of

the road pavement

to feed

respectively the

TMC operator

allowing quick

corrective

measures and

feedback to the

driver/rider.

Primary actor: Operators in

maintenance departments of

Traffic Management Centres or

similar.

Secondary actor(s): Road

users that are finally receiving

information about critical

failures of the infrastructure

through VMS (or the newly

introduced by SAFE STRIP

personalized VMS function).

Also, government agencies (in

cases of procurement or

strategic action plans cost-

efficiency study).

UC3 Current

practice for

road

maintenance

and operators

is using

roughness

data

collection

equipment

such as

Response

Type Road

Roughness

Meters

(RTRRMs) or

non-contact

profiling

Sufficient number

vehicle loads is

required in order

to come up with

sound results. As

such, this

application will be

“active”

throughout the

whole duration of

the trials.


No SAFE STRIP

function


UC


requirements &

limitations (for

evaluation)

devices

installed on

vehicles. All

methods are

fairly costly

in terms of

data

collection and

initial

procurement

cost.

4. In-vehicle

application for

rail crossing and

road works safety

function

UNITN SAFE STRIP

technology

informs equipped

vehicles about

train approaching

a level crossing

and/or about road

works ahead. By

means of the co-

driver concept, the

warnings are

generated in-

vehicle based on

the analysis of

Primary actor: The


equipped and non-equipped

vehicles.



traffic monitoring and

management.

UC4 Baseline for

“Road

Works” are

results of

Drive-C2X

project where

warnings

were issued

manually by a

road operator.

Baseline for

“Level

crossing” are

results from

-


No SAFE STRIP

function


UC


requirements &

limitations (for

evaluation)

potential and

feasible

manoeuvers the

driver can take in

the actual

scenario.

SAFER-LC

project but

based on

LTE.

5. Mobile

application for

rail crossing and

road works safety

function

UNITN Non-equipped

vehicles receive,

via a mobile app

from SAFE

STRIP cloud

server, the

warnings about

train approaching

a level crossing

and/or about road

works ahead. By

means of the co-

driver concept, the

warnings are

generated at cloud

level based on the

analysis of

potential and

feasible

As above

UC4 Baseline for

“Road

works”: not

available

since results

of Drive-C2X

project are

not applicable

since it was

designed only

for equipped.

Baseline for

“Level

crossing” are

results from

SAFER-LC

project (to

some extent).

Maximum speed

in urban 50km/h

and 80km/h extra

urban.

Delay of

communication

via LTE greater

equal than 1s the

application cannot

warn the non-

equipped vehicle

when it less than

30m distance to

the level crossing

or merging.


No SAFE STRIP

function


UC


requirements &

limitations (for

evaluation)

manoeuvers the

driver can take in

the actual

scenario.

6. In-vehicle

application for

merging and

intersection

Support (e2Call)

UNITN SAFE STRIP

technology

informs equipped

vehicles about

intersection or

merging scenario

and state of other

vehicles.

By means of the

co-driver concept,

the warnings are

generated in-

vehicle based on

the analysis of

potential

collisions and

feasible

manoeuvers the

driver can take in

the actual scenario

and scenario

Primary actor: The


equipped and non-equipped

vehicles.



traffic monitoring and

management.

UC5 Baseline for

“Merging and

Intersection”

are results of

e2Call

project.

Application

could be run

in an iteration

if available

past data are

not sufficient.

Maximum speed

in urban 50km/h

and 80km/h extra

urban.

Number of

vehicles travelling

at the same time

across the

intersection.


No SAFE STRIP

function


UC


requirements &

limitations (for

evaluation)

according to other

vehicle actions.

7. Mobile

application for

merging and

intersection

Support (e2Call)

UNITN Non-equipped

vehicles receive,

via a mobile app

from SAFE

STRIP cloud

server, the

warnings about

potential

collisions in

intersection or

merging scenario.

By means of the

co-driver concept,

the warnings are

generated at cloud

level based on the

analysis of

potential

collisions and

feasible

manoeuvers the

driver can take in

the actual scenario

As above UC5 Baseline for

“Merging and

Intersection”

is not

available

since e2Call

project was

designed for

equipped

only.

Maximum speed

in urban 50km/h

and 80km/h extra

urban.

Delay of

communication

via LTE greater

equal than 1s the

application cannot

warn the non-

equipped vehicle

when it less than

30m distance to

the crossing or

merging.

Number of

vehicles travelling

at the same time

across the

intersection.


No SAFE STRIP

function


UC


requirements &

limitations (for

evaluation)

and predicted

according to other

vehicle actions.

8. In-vehicle

application for

personalised

VMS/VDS and

Traffic Centre

Information

CERTH/HIT This application

corresponds to the

replacement of the

current VMS/VDS

infrastructure with

main objective to

depict the VMS’s

messages to the

passing vehicles

but in a more

accurate way and,

also, in a

personalized

manner.

Primary actor: Drivers/Riders

Secondary actor(s):

Infrastructure operators

(Traffic Management Centers)

UC6 Baseline is

the current

VMS/VDS

systems and

the current

accuracy,

content of

information

and

timeliness of

communicatio

n of the

information

to the users

(which is less

than 1 min

from the

moment of

the event

detection to

the moment

of road user’s

The TMC

operator side will

be emulated in the

3rd round.


No SAFE STRIP

function


UC


requirements &

limitations (for

evaluation)

notification).

9. Mobile

application for

personalised

VMS/VDS and

Traffic Centre

Information

CERTH/HIT As above As above UC6 As above As above

10. Autonomous

vehicles support

VALEO Enhanced

automated driving

functions by V2X.

Primary actor: Autonomous

vehicles drivers

Secondary actor(s):

Infrastructure / highway

operators (traffic info…)

UC7 Current

perception

system of

autonomous

vehicle of

VALEO

(working

without

SAFE

STRIP).

There is absolute

dependency on the

speed and length

of the test area; as

such, specific

speed has been

selected for the 1st

round, which is

not the “final

target” speed to be

reached in real

life.

11. Application for

Virtual Toll

Collection

RELAB The application

enables automatic

passage and

payment through a

virtual tool station

that is enabled

Primary actor: The key actors

are the drivers/riders who are

expected to go through the toll

gate.


UC8 Typical

passage

through real

toll station

without

SAFE STRIP

-


No SAFE STRIP

function


UC


requirements &

limitations (for

evaluation)

through strips,

thus cancelling the

need for a real

Toll station in the

motorway.

secondary actor is the

infrastructure operator and the

payment system/facility.

support and

(potentially)

with systems

for automatic

payment (e.g.

Telepass in

Italy).

12. Application for

parking booking

and charging

CIDAUT The application

optimises the

management of

the available

parking space and

provides

information to the

drivers/riders

about the

availability and

location of free

parking lots.

Primary actors:

• The driver/rider who is

looking for parking lot in a

zone.

• Parking manager/operator.

UC9 Search for

parking

without any

external help,

driving

around the

destination.

Parking

operators are

using their

own (varying)

parking

management

system.

-


4.2 Intended and unintended effects of SAFE STRIP and

stakeholders involved in evaluation The stakeholder chain of SAFE STRIP encompasses apart from road users of all types

(drivers, riders, pedestrians) infrastructure operators and authorities, OEM’s, Tier1

suppliers and despite the fact that SAFE STRIP will involve in its last round of real

life testing all of them directly or indirectly, it is worth reminding that the SAFE

STRIP solution per se is basically an infrastructure based cooperative solution with

direct impacts first of all to the road infrastructure holders, as it proposes a cost-

efficient solution that aims to impact positively the overall safety, traffic efficiency

and environmental status of the traffic network as well as to the drivers and riders of

all types of vehicles that benefit from the real-time, safety critical information that is

provided to them. Indirectly but equally apparently, SAFE STRIP is expected to affect

positively the other road users (i.e. the safety of VRUs such as pedestrians and

bicyclists) or other infrastructure operators (i.e. the parking operators, the railway

operators, etc.).

The research questions that is the objective of evaluation with users in SAFE STRIP

across the two planned rounds are translated in the following table to intended effects

for all the different stakeholders in short and medium/long term, whereas, next to

them, as it is the case with all novel technological solutions, the Consortium has

recognised some unintended effects that may also emerge during evaluation. The

mapping to Michon levels [15] (strategic, tactical and operational) and the affected

stakeholders of the value chain is also reflected.

Those have fed the research questions and the specific experimental hypothesis

generation that is described per evaluation scenario in the sections following. It

should be noted, however, that the following table is not exhaustive. In the sense that

it does not encompass all the intended and unintended effects of the SAFE STRIP

backbone solution, but only those that are correlated to the specific proof of concept

applications which are, as such, relevant to our study


Table 2: SAFE STRIP intended effects in short - medium/long term and relevant stakeholders.

No SAFE STRIP

function

Intended effects for

relevant stakeholders –

Short/Medium term

Intended effects for relevant

stakeholders – Long term

Unintended effects for relevant

stakeholders – Short/Medium

term

Unintended effects

for relevant

stakeholders –

Long term

1.

Mobile

Cooperative

safety function

▪ SAFE STRIP

technology can provide

virtual safety functions

(via mobile app) for

non-equipped vehicles

with minimal cost for

the user – Strategic

Michon level.

▪ Improved safety of

pedestrian and cyclist at

road crossing (impacts

on “non-users”) -–

Strategic Michon level.

▪ Faster penetration of C-

ITS overall due to cost-

effectiveness and easy to

use application also

improving “Equity in

roads” (not only for high

end vehicles) –


▪ Use of SAFE STRIP

technology may foster

development of new

sensors and solutions to

be integrated in Safe

Strips improving the

overall performance and

widening or creating new

markets - – Strategic

Michon level.

▪ Other public, and private

player may deploy new

applications based on

SAFE STRIP technology.

For example, VRU could

benefit of SAFE STRIP

technology using mobile

application that receive

warning from SAFE

STRIP cloud services

(like for not equipped). –


▪ The primary user may over

trust the system reducing

attention level to specific road

scenario - - Control/Tactical

Michon level.

▪ VRU could activate the SAFE

STRIP sensor in order to issue

warning to incoming vehicles

(e.g. Stepping on the plate but

not intending to cross the

road.) - Control/Tactical

Michon level.

▪ Overconfidence in the system

may lead to increase of driver

reaction time - -

Control/Tactical Michon

level. ▪ Risk of providing of

overloading users with many

pieces of information on the

road environment and road

scenario which are not

consistently merged: decrease

▪ “Non-users”

may rely too

much on safety

level guaranteed

by improvement

due to SAFE

STRIP

technology (e.g.

VRU crossing

without paying

attention) -

Control/Tactic

al Michon

level.

▪ Users

understand

limitations of

the system and

take driving

decisions to

avoid related

warning -

Control

Michon level.


No SAFE STRIP

function



Short/Medium term





term

Unintended effects

for relevant

stakeholders –

Long term

user acceptance. - Tactical

Michon level.

2. In-vehicle

Cooperative

safety function

▪ SAFE STRIP

technology enhances the

robustness and the

operating range of safety

function already

available for equipped

vehicles ADAS –

Tactical Michon level.


ITS overall due to better

performance of the

ADAS systems and

improvement of user

acceptance. - Strategic

Michon level.



development of new






markets-– Strategic

Michon level.

▪ SAFE STRIP technology

can be implemented as a

standard extension of

ADAS framework with

car makers and

infrastructure operator-–


▪ The primary user may over

trust the system reducing


scenario.-Control/Tactical

Michon level.

▪ VRU could activate the SAFE

STRIP sensor in order to issue

warning to incoming vehicles

(e.g. Stepping on the plate but

not intending to cross the

road.)- Control/Tactical

Michon level.



reaction time.


level.

▪ Risk of providing of






▪ “Non-users”

may rely too

much on safety

level guaranteed

by improvement

due to Safe

Strip

technology (e.g.

VRU crossing

without paying

attention). -

Control/Tactic

al Michon

level.

▪ Users

understand

limitations of

the system and

take driving

decisions to

avoid related

warning. -

Control


No SAFE STRIP

function



Short/Medium term





term

Unintended effects

for relevant

stakeholders –

Long term

user acceptance- Tactical

Michon level.

Michon level.

3. Road wear level

and predictive

road

maintenance

Detection in real time of

critical deformations of the

road pavement to feed

respectively the TMC

operator allowing quick

corrective measures and

feedback to the driver/rider

– Control/Tactical Michon

level

• Integration of the system

in the maintenance

schedule/routines.

Systematic design of road

pavements for predictive

maintenance philosophy.

– Tactical/Strategic

Michon level

• Increased road safety due

to better (self-forgiving)

roads – Strategic Michon

level

Not satisfactory deployment

leading to preference over

traditional/SoA practices.-

Strategic Michon level

-

4. In-vehicle

application for

rail crossing

and road works

safety function

▪ Significant reduction of

accidents occurring at

the unprotected level

crossings and road

works zones - Tactical/


▪ Improvement of traffic

flow in road work zones.

- Tactical/ Strategic

Michon level.




development of new






markets-– Strategic

Michon level.


▪ The primary user may

overtrust the system reducing


scenario-Control/Tactical

Michon level.



reaction time-


level.

▪ Users

understand

limitations of

the system and

take driving

decisions to

avoid related

warning. -

Control

Michon level.


No SAFE STRIP

function



Short/Medium term





term

Unintended effects

for relevant

stakeholders –

Long term


performance of the

ADAS systems and

improvement of user

acceptance. - Strategic

Michon level.



SAFE STRIP technology

such as highway operators

for traffic management to

increase the average

speed thought the work

zone or definition of train

interface for direct

communication towards

SAFE STRIP – Strategic

Michon level.

5. Mobile

application for

rail crossing

and road works

safety function

▪ SAFE STRIP

technology provides

level crossing and road

works (via mobile app)

for non-equipped

vehicles with minimal

cost - Strategic Michon

level.


accidents occurring at

the unprotected level

crossings equipped with

SAFE STRIP



development of new






markets - Strategic

Michon level.




As above. As above.


No SAFE STRIP

function



Short/Medium term





term

Unintended effects

for relevant

stakeholders –

Long term

technology - -–

Tactical/Strategic

Michon level.

▪ Improvement of traffic

flow at road work zones

and significant reduction

of accidents at

unprotected level

crossing - -–

Tactical/Strategic

Michon level.







end vehicles) - Strategic

Michon level.

SAFE STRIP technology

such as highway operators

for traffic management to

increase the average

speed thought the work

zone or definition of train

interface for direct

communication towards

SAFE STRIP. - Strategic

Michon level.

▪ Extension of operating

range of road works

safety function to rural

context –

Tactical/Strategic

Michon level.

6. In-vehicle

application for

merging and

intersection

Support

(e2Call)

▪ Enhancement of the

robustness and

performance of the

intersection safety

function already

available for equipped



development of new




▪ The primary user may

overtrust the system reducing


scenario - Control/Tactical

Michon level.


▪ Possible

distraction of

the drivers’

attention due to

multiple

incoming


No SAFE STRIP

function



Short/Medium term





term

Unintended effects

for relevant

stakeholders –

Long term

vehicles - Control

Michon level.

▪ Allows to implement

new safety function at

motorway exits -



accidents at intersection,

improving or

overcoming the limits of

on-board of equipped

vehicles -

Control/Tactical

Michon level.



performance of the

ADAS systems and

improvement of user

acceptance - Strategic

Michon level.



market s- Strategic

Michon level.

▪ Extension to lateral

dynamics to improve

Curve Warning functions

- Control Michon level.

▪ Implementation of app for

other type of vehicles

such as truck, busses or

other weather conditions

such as fog.-Strategic

Michon level.

▪ Road operator or

governmental

organisation may better

manage the traffic flow at

large intersections.-



reaction time -


level.

▪ Risk of providing of






user acceptance- Tactical

Michon level.

messages that

may lead to

road safety

issues. –

Control/Tactic

al Michon

level.

▪ Users

understand

limitations of

the system and

take driving

decisions to

avoid related

warning -

Control

Michon level.

7. Mobile

application for

merging and

intersection

▪ SAFE STRIP

technology provides

intersection and merging

safety functions (via



development of new


As above. As above


No SAFE STRIP

function



Short/Medium term





term

Unintended effects

for relevant

stakeholders –

Long term

Support

(e2Call)

mobile app) for non-

equipped vehicles with

minimal cost- Strategic

Michon level.







end vehicles) - Strategic

Michon level.





markets- Strategic

Michon level.

▪ Extension to lateral

dynamics to improve

Curve warning functions -

Control Michon level.

▪ Implementation for other

type of vehicles such as

truck, busses or other

weather conditions such

as fog.-Strategic Michon

level.

8. In-vehicle

application for

personalised

VMS/VDS and

Traffic Centre

Information

▪ Reduction of recovery

time in case of

emergency incident

(from the perspective of

the infrastructure

operators) – Tactical

Michon level.

▪ More accurate, enriched,

personalised and in-time

▪ Road users’ overreliance

to the system leading

potentially to incidents –


levels.

▪ Traffic efficiency due to

increase of speed –


level.

▪ It will require changes in the

business routines of

infrastructure operators, as the

maintenance of SAFE STRIP

will replace the maintenance of

▪ Driver/Rider

workload and

overreliance –

Control/Tactica

l Michon level.

▪ Changes in

business routines

(see previous

column) –

9. Mobile

application for

personalised


No SAFE STRIP

function



Short/Medium term





term

Unintended effects

for relevant

stakeholders –

Long term

VMS/VDS and

Traffic Centre

Information

information about

traffic/environmental

incidents to the road

users – Tactical Michon

level.

▪ Reduction of the

tremendous

manufacturing,

operational and

maintenance cost of real

VMS stations for

infrastructure operators –

Tactical and Strategic

Michon levels

VMS/VDS.– Tactical and

Strategic Michon levels

Tactical and

Strategic

Michon levels

10. Autonomous

vehicles support

▪ Driving efficiency -

Control Michon level.

▪ Fewer traffic congestion -


▪ Fewer traffic accidents

with a reduction of death

or injury - Tactical

Michon level.

▪ Reduction of insurance

cost – Strategic Michon

level.

▪ Economic toll for route

maintenance caused by

property damage–


▪ Hacking of vehicles - Tactical

Michon level.

▪ Driver sickness - Control

Michon level.

▪ Not smooth interaction with

other vehicles of surrounding

traffic, especially upon creation

of new lanes/corridors for

automated vehicles - Tactical

Michon level.

▪ Unemployment,

(truck or taxi

drivers...) –

Strategic

Michon level.

▪ Risk for

automotive

industry by

decline of the

private

ownership of


No SAFE STRIP

function



Short/Medium term





term

Unintended effects

for relevant

stakeholders –

Long term

cars- – Strategic

Michon level.

11. Application for

Virtual Toll

Collection


crossover time of the toll

booth - Control and

Tactical Michon levels


tremendous

manufacturing,

operational and

maintenance cost of real

toll stations for

infrastructure operators –

Tactical and Strategic

Michon levels

▪ Pollution reduction.-


▪ Increase of traffic

efficiency. – Tactical

Michon level

▪ It will require changes in the

business routines of

infrastructure operators, as the

maintenance of SAFE STRIP

will replace the maintenance of

toll stations. – Tactical and

Strategic Michon levels

Same as in previous

column.

12. Application for

parking

booking and

charging

▪ Reduction of the parking

searching time (for

drivers). - – Tactical

Michon level

▪ Better management of

the parking lots (for

operators). – Strategic

Michon level

When widely deployed, the

application will contribute to

the reduction of the traffic

density and the pollution. –


- -


5 Evaluation Framework

5.1 Evaluation objectives of the trials The following table presents the SAFE STRIP Evaluation Objectives, called also

Research Questions, their mapping to specific Key Performance Indicators and the

relevant functions. Also, it is made evident which of them are going to be addressed

in the 1st evaluation round and which of them in the 2nd one. For each research

question, the specific user groups that are addressed in each case are denoted.

Regarding the Research Question 1 (Does the system function as expected under

realistic conditions (according to specs but also according to user perception)?), the

reference point is the system specifications as they have been detailed in D2.1: System

architecture, sensor specifications, fabrication, maintenance, installation and security

requirements and Risk Assessment [13] and the functional expectations as being

reported in the Use Cases of D1.2: “SAFE STRIP Use Cases and application

scenarios” [11].

Also, as mentioned in D3.1: Micro & nano sensors, QR algorithms, power supply

units [19] Chapter 2, there will be two alternative configurations that will be

developed and tested in SAFE STRIP (for equipped vehicles) in terms of

communication between the RSB and the vehicles. One is based on the typical use of

C-ITS or LTE (for the non-equipped vehicles) and the other is based on the use of

BLE technology. The reasons that led to this decision and the added value in each

case are explained in D3.1. The potential of the second solution (use of BLE) will be

technically validated in the 2nd and 3rd round of technical tests in SAFE STRIP. If it

proves robust enough for the user trials, it will be assumed as one of the system

specifications and will be also applied therein. If not, the C-ITS and LTE solutions

will be only applied.

Though we have identified specific success targets for all the metrics that will

accommodate the assessment of each KPI for each SAFE STRIP function in the

context of the 3rd round, the overall and final target of SAFE STRIP per KPI below is

not feasible to be assumed at this stage of the project, as the SAFE STRIP solution is

very much innovative and is not safe to anticipate its behavior. On top of that, some of

the indicators related with expected impacts are very much dependent on the

penetration and they way of deployment of the project. Still, the key original project

goals for the key research questions (reflecting key expected impacts) are still valid

and constitute a commitment for the project. The key (quantitative) targets of SAFE

STRIP are as follows:

✓ Reduction of highway fatal accidents ≈ 5% - 8%

✓ Reduction of fatal accidents at specific traffic scenarios (i.e.

merging/intersections) ≈ 15% - 30%

✓ Cost saving for infrastructure ≈ 50%-95%

✓ Cost saving for driver/rider ≈ 95% - 100%

In the forthcoming D6.2 and with the knowledge acquired by the following

implementation and testing phases of the project, a specific target will be assumed for

each distinct Indicator of the project.


Table 3: SAFE STRIP Research Questions, mapping to KPI’s and relevant functions to evaluation rounds and user groups.

Research Questions & KPI’s

Research

Questions

Key Performance

Indicators (KPI’s)

Relevant

functions

Key evaluation

approach

Applicabilit

y for 1st

round of

user trials

Applicability

for 2nd round

of user trials

Relevant user groups

RQ1: Does the

system

function as

expected under

realistic

conditions

(according to

specs but also

according to

user

perception)?

• False/missed/delaye

d alarms

• Accuracy of vehicle

positioning

• Correctness/

Accuracy/

Reliability/

Personalisation of

warnings (in terms

of content and

time)

• Performance

enhancement (for

existing apps

working with

alternative systems)

• Automotive Safety

Integrity Level

(ASIL)1

All (performance

enhancement is

valid for the

automated

functions, the

current processes

followed for VMS

and Toll stations

and all safety

functions)

Through logging of

performance and

subjective data in

user trials (and in

the context of

technical validation

in WP5).

Will be addressed in

the impact

assessment task of

the project and upon

the aggregated and

final pilot results.

X

X

(personalisati

on and

interoperabilit

y are assessed

only in the 2nd

phase)

Drivers/riders/infrastruct

ure operators

1 Automotive Safety Integrity Level (ASIL) is a risk classification scheme defined by the ISO 26262 - Functional Safety for Road Vehicles standard. This is an adaptation

of the Safety Integrity Level used in IEC 61508 for the automotive industry. This classification helps defining the safety requirements necessary to be in line with the ISO

26262 standard. The ASIL is established by performing a risk analysis of a potential hazard by looking at the Severity, Exposure and Controllability of the vehicle operating

https://en.wikipedia.org/wiki/ISO_26262

https://en.wikipedia.org/wiki/Safety_Integrity_Level

https://en.wikipedia.org/wiki/IEC_61508



Research

Questions

Key Performance


Relevant

functions

Key evaluation

approach

Applicabilit

y for 1st

round of

user trials

Applicability

for 2nd round

of user trials


• Acceptance (this is

associated with the

system robust

functioning or not as

perceived by the

user; encompassing

comprehensibility

of function,

usefulness and HMI

usability)

• Trust

• Workload

• Perceived value of

service

• Interoperability

RQ2: Does the

system

function as

expected under

realistic

• False/missed/delaye

d alarms

• Accuracy of vehicle

positioning

Different

combinations of all

functions apart

from 3 and 10.

Through logging of

performance and

subjective data in

user trials (and in

the context of

X X

(personalisati

on is assessed

only in the 2nd

phase)

Drivers/riders/infrastruct

ure operators

scenario. The safety goal for that hazard in turn carries the ASIL requirements. There are four ASILs identified by the standard: ASIL A, ASIL B, ASIL C, ASIL D. ASIL D

dictates the highest integrity requirements on the product and ASIL A the lowest.[1] Hazards that are identified as QM do not dictate any safety requirements

[https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level].

https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level#cite_note-1

https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level



Research

Questions

Key Performance


Relevant

functions

Key evaluation

approach

Applicabilit

y for 1st

round of

user trials

Applicability

for 2nd round

of user trials


conditions

when more

than one SAFE

STRIP

functions are

running

concurrently in

the user’s

terminal

(according to

specs but also

according to

user

perception)?

• Correctness/

Accuracy/

Reliability/

Personalisation of

warnings (in terms

of content and

time)

• Performance

enhancement (for

existing apps

working with


• Automotive Safety

Integrity Level

(ASIL)2

• Acceptance (this is

associated with the

technical validation

in WP5).


the impact

assessment task of

the project and upon

the aggregated and

final pilot results.














Research

Questions

Key Performance


Relevant

functions

Key evaluation

approach

Applicabilit

y for 1st

round of

user trials

Applicability

for 2nd round

of user trials


system robust


perceived by the

user; encompassing

comprehensibility

of function,

usefulness and HMI

usability)

• Trust

• Workload

• Perceived value of

service

Interoperability

RQ3: What are

the impacts on

safety and

mobility?

• Self-explanatory

and forgiving roads

– (exposure to)

fewer and less

severe

incidents/near

accidents/ accidents

• Driving

performance/behav

iour (as evidence for

safety achieved

Cooperative

functions, rail

crossing & road

works,

merging/intersecti

on, personalized

VMS, autonomous

vehicles functions

Through off line

post-impact

assessment

accommodated

through

performance and

subjective data

logged during user

trials.


X

Only

driving

performanc

e/behavior,

and

Driver/Rid

er comfort

will be

assessed in

the 1st

X All stakeholders of the

value chain.



Research

Questions

Key Performance


Relevant

functions

Key evaluation

approach

Applicabilit

y for 1st

round of

user trials

Applicability

for 2nd round

of user trials


among other)

• Travel behaviour

• Driver/Rider

comfort - support

in driving task

through reliable

personalised

warnings

• Perceived societal

expectations

• Readiness to

unexpected traffic

incidents

• “Equity in roads” –

all vehicles are

enjoying the same

benefits from SAFE

STRIP

• Impacts on “non-

users” (i.e. VRU)

the impact

assessment task of

the project.

round.

RQ4: What are

the impacts on

traffic

efficiency?

• Traffic flow

• Traffic

volume/density

• Accessibility

Parking & Virtual

Toll, Road works,

merging/intersecti

on (applicable also

Through off line

post-impact

assessment

accommodated

X Mainly infrastructure

operators and authorities.



Research

Questions

Key Performance


Relevant

functions

Key evaluation

approach

Applicabilit

y for 1st

round of

user trials

Applicability

for 2nd round

of user trials


to roundabout)

through data logged

from the system

during trials and

assumptions based

on subjective views

of stakeholders.


the impact

assessment task of

the project.

RQ5: What are

the impacts on

environment?

• Greenhouse

emissions (at

specific traffic

network spots),

specifically CO2

• Noise

• Energy saving

• Fuel consumption

Parking, Virtual

Toll, VMS

functions.

All functions

regarding energy

saving.

Through off line

post-impact

assessment

accommodated

through data logged

from the system

during trials.


the impact

assessment task of

the project.

Evidence for he

X (power

sustainabilit

y will be

proven

already

from the 1st

round of the

trials)

X -



Research

Questions

Key Performance


Relevant

functions

Key evaluation

approach

Applicabilit

y for 1st

round of

user trials

Applicability

for 2nd round

of user trials


power sustainability

of the system will be

provided already

from the 1st round

trials.

RQ6: What is

the impact on

infrastructure

operation?

• Implications in

strategic

management (i.e.

maintenance) of

national pavement

network upon

SAFE STRIP

penetration

• Investments on

installation and

maintenance of

costly

infrastructure

elements (VMS,

Toll stations)

Virtual Toll,

Personalised VMS,

Road wear level

and predictive road

maintenance

On the basis of

subjective views

coming from

infrastructure

operators.


the impact

assessment task of

the project.

X Infrastructure operators

RQ7: What is

the expected

user uptake of

the system?

• Cost-effectiveness

of the system

• Acceptance (as it

provides insight on

All Post CBA Taking

into consideration

the cost of the

prototype system

X From all stakeholders’

point of view, with focal

groups the infrastructure

operators, the



Research

Questions

Key Performance


Relevant

functions

Key evaluation

approach

Applicabilit

y for 1st

round of

user trials

Applicability

for 2nd round

of user trials


future penetration) combined and

acceptance data, on

the basis of

subjective views of

all stakeholders of

the value chain

collected during the

2nd round of user

trials.


the impact

assessment task of

the project.

drivers/riders and the

OEM’s.

RQ8: What are

the

implications in

automated

driving in

specific?

• Robustness of

automated driving

functions.

• Frequency for the

driver having to

take back control of

the vehicle.

• Driver comfort.

• Advancement of

SAE level.

Automated

functions

On the basis of

performance and

system data logged

during the trials and

subjective views (for

driver comfort in

specific).


the impact

X Drivers/Riders



Research

Questions

Key Performance


Relevant

functions

Key evaluation

approach

Applicabilit

y for 1st

round of

user trials

Applicability

for 2nd round

of user trials


assessment task of

the project.

RQ9: What is

the expected

contribution of

SAFE STRIP

in C-ITS

overall

penetration?

• Cost-effectiveness

of the system

• Acceptance (as it

provides insight on

future penetration)

• Innovation &

added value

Overall (all proof

of concept

functions

considered)

Results of CBA

analysis coupled

with evidence based

innovation and

added value.


the impact

assessment task of

the project.

X

From all

involved in

the value

chain

stakeholders’

point of view

From all the involved

stakeholders’ point of

view.

RQ10: What is

the expected

contribution of

SAFE STRIP

in European

competitivenes

s?

• New markets/

existing markets

growth

Overall (all proof

of concept

functions

considered)

Assumption based

discussion on the

basis of subjective

views collected,

evidence based

innovation and

existing market. Will

be addressed in final

exploitation plans of

the project.

X

-

RQ11: What

are the • Readiness to adopt

SAFE STRIP -

Overall (all proof

of concept

Post analysis on the

basis of the

X

Infrastructure players

(and partially OEM’s)



Research

Questions

Key Performance


Relevant

functions

Key evaluation

approach

Applicabilit

y for 1st

round of

user trials

Applicability

for 2nd round

of user trials


implications on

standards,

legislation and

regulatory

framework?

changes required

(in terms of

standards,

regulation and

legislation

framework)

• Data protection

functions

considered, but

basically the

infrastructure

solution is the

focal point here)

subjective views

collected during the

2nd round of user

trials.


D7.7: Application

guidelines and

standardisation

recommendations.

RQ12: What

are the

implications

for policies &

business

models?

• Predicted

penetration/user

uptake

• User expectations

• Pricing models

• Policy decisions

• Authorities

implications

As above. Post analysis on the

basis of subjective

views collected

during user trials,

current (and

expected in near

future) policies and

associated business

models. Will be

addressed in final

exploitation plans of

the project.

X

Authorities, decision

makers

RQ13: What

are the • Road safety

• QoL

All – overall. Impact assessment

fed from all the

X

Society as a whole.



Research

Questions

Key Performance


Relevant

functions

Key evaluation

approach

Applicabilit

y for 1st

round of

user trials

Applicability

for 2nd round

of user trials


implications on

society? • Environment

• Enforcement (for

virtual toll stations

function)

• Sustainable

mobility

• Rehabilitation costs

above evidence

collected and

aggregated during

pilot activities of the

project.


5.2 Overview of evaluation plan for 1st and 2nd rounds with user

trials

As also mentioned in Deliverable 5.4: Test sites set-up and experimental technical

validation plan, the SAFE STRIP [21] and depicted in the following figure respective,

SAFE STRIP will adopt an iterative evaluation approach encompassing 4 evaluation

rounds in total. The 1st and the 2nd iteration rounds are dedicated to technical

validation solely, whereas the 3rd evaluation round starts with the final technical

validation that will examine the cooperative system overall and will lead to the latest

optimisation prior to the first round of user trials that are also part of this 3rd

evaluation round. Upon the outcomes of the 3rd evaluation round, a longer

optimisation period will follow on all the different layers of the cooperative system to

conclude with the final user trials (4th iteration) that will be of larger scale in

comparison with the 3rd one and will aim at capturing SAFE STRIP impact across the

different aspects defined in the Research Questions.

Figure 2: SAFE STRIP implementation & testing plan outline.

As such, the 1st round of user trials (that will be conducted in the context of the 3rd

validation round of SAFE STRIP overall as it is depicted in the above figure) will run

in each participating test site with:

• 10 drivers, who will test the in-vehicle and mobile functions for passenger

cars.

• 3 (different) drivers, who will evaluate the autonomous functions (a different

driver will be “in control” and the other 2 will be passengers).

• 10 riders, who will test the in-vehicle and mobile functions for motorcycles.

• 3 representatives from operators (motorway and parking) who will be involved

in the evaluation of the Road wear level and predictive road maintenance

and the Application for parking booking and charging.

In a similar way, the 2nd round of user trials (that will be conducted in the context of

the 4th validation round of SAFE STRIP overall as it is depicted in the above figure)

will run in each participating test site with:

• 20 drivers, who will test the in-vehicle and mobile functions for passenger

cars.

• 3 (different) drivers, who will evaluate the autonomous functions (a different

driver will be “in control” and the other 2 will be passengers).

• 20 riders, who will test the in-vehicle and mobile functions for motorcycles.

• 10 representatives from operators (motorway and parking) who will be

involved in the evaluation of the Road wear level and predictive road

maintenance and the Application for parking booking and charging.


The user trials of the 4th round will be complemented and concluded with focus

groups at each test site (Greece, Italy, Spain) that will be conducted on-site with key

stakeholder representatives from all the SAFE STRIP value chain: drivers, riders,

infrastructure operators, parking operators, authorities, Tier 1 suppliers, OEMs.

As mentioned again, the objective of the current Deliverable (and its subsequent

version, D6.2) according to the workplan is to focus on the user trials of the 3rd and 4th

rounds, while all technical validation rounds, including the one that is going to run

prior to the user trials of the 3rd round are addressed in WP5 (A5.6: Technical

validation & Test Sites set-up) and in deliverables D5.4: Test sites set-up and

experimental technical validation plan (submitted) and D5.5: Updated experimental

technical validation plan and results – final report (upcoming in M24).

5.3 Real-life evaluation scenarios (ES) of the trials

5.3.1 Introduction & Guideline to the users

The following sections present the real-life evaluation scenarios that will run during

the 1st evaluation round with users (3rd evaluation round in the row overall in SAFE

STRIP). Those are based on the scenarios of the use cases of the project, as described

in D1.2 [11] and as it can be seen below they are described in a way so that they will

accommodate the system performance and the driver response – behavior to it both

(key evaluation objectives of the first round).

In each case, the experimental conditions that will be applied in each scenario have

been defined. If there are more than one set of experimental conditions in each case

for the same type of vehicle, this implies a sub-scenario of the scenario, that will run

in a different row of iterations. The same is valid for the baseline scenarios, whenever

existing.

The Cross Use Cases evaluation scenarios are scenarios combining different functions

of SAFE STRIP and will serve the purpose of evaluating Research Question 2 which

concerns the concurrent operation of functions under the operation of the SAFE

STRIP Decision Support System which operates as HMI manager.

Whilst the following scenarios serve the needs of the test conductors and SAFE

STRIP Consortium it is important to stress here that the guideline that will be given to

the user participating will not reflect this detail, as it would not be appropriate for real

– life trials.

As such, the guideline that will be given to the users (basically drivers and riders of

the vehicles and PTW’s respectively) is that they should drive normally and in the

safest way possible - as they would in real life - with only two recommendations:

1. To enter the test area with the recommended speed (that is always denoted in

experimental conditions table of the scenarios below) and maintain it – if

nothing prohibits it – as average speed as much as possible.

2. To react normally – as they would in a real life situation – to the notifications,

warnings and recommendations as they will be provided by the system.


Whereas the users will be provided with the scope of the test and, as such, the

description of the system they are going to evaluate, they will not be given specific

instructions about the messages that they will receive from the system or the events

that will trigger those messages, as this would add bias to the real-life tests.

The case with the infrastructure operators (for the Road wear level and predictive road

maintenance function of SAFE STRIP) is not so direct anyway, as it is an off-line

function. The infrastructure operators will be explained the aim of this function again,

they will be depicted with the process that will be followed when this function is in

force and they will be requested to evaluate it envisioning it as part of their future

business routines.

It should be also mentioned that the scenarios presented below will be “rehearsed” in

the third technical validation round and, upon that, revisions may emerge. Also, the

specific HMI strategy (and elements) that will be applied – which are currently under

iterative development – are not reflected per se. Though the objectives of the user

trials encompass user experience which is associated with the HMI of the applications

the users will experience, the HMI elements will be specifically evaluated through

trials in simulators beforehand as described in upper level in D5.4 and will be

thoroughly described in the forthcoming (in M24) D5.5: Updated experimental

technical validation plan and results – final report (dedicated HMI testing is

considered by SAFE STRIP a technical validation activity). In the following D5.1:

SAFE STRIP decision making algorithms and module and HMI strategy & elements

(in M26) the detailed (finalised) HMI strategy and elements will be presented.


5.3.2 ES1.1: Virtual VRU protection of Mobile Cooperative safety function

ES1.1.1: Pedestrian prompt to cross the zebra crossing

Step 1: The driver/rider of the non-equipped ego vehicle drives in the test area with the recommended speed.

Step 2: At some point, the strip detects a pedestrian standing at the edge of the zebra crossing ahead.

Step 2.1: The strip sends to the RSB the information of the pedestrian existence.

Step 2.2: At the same time, the strip sends to the RSB the position and speed of the ego vehicle.

Step 2.3: The information is provided by the RSB to the C-ITS-S of SAFE STRIP via LTE-4G.

Step 2.4: The Mobile Cooperative safety function running on the C-ITS station predicts the ego driver/rider maneuver and provides a

warning to the mobile terminal of the non-equipped vehicle via LTE-4G about the pedestrian crossing the road with the indication that

the driver has to decelerate.

Step 3: The driver/rider decelerates accordingly.

Step 4: As soon as the Mobile Cooperative safety function detects driver/rider proper deceleration, the warning is deactivated in the Mobile

Cooperative safety function.


Table 4: ES1.1.1 – Experimental conditions.

Sub-

scenarios Experimental conditions Ego vehicle travel

speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day

Event SAFE STRIP

vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

1. 50 km/h Dry Daylight – sunny Pedestrian prompt to cross the

zebra crossing from right.

Passenger CRF, ATTD


zebra crossing from left.

Passenger CRF, ATTD


zebra crossing from right.

PTW CRF, ATTD


zebra crossing from left.

PTW CRF, ATTD

Baseline: Not available/feasible.

ES1.1.2: Pedestrian prompt to cross the zebra crossing with stopped vehicle

Step 1: The driver/rider of the non-equipped ego vehicle drives in the test area (a road with two lanes per direction) with the recommended

speed and car (or another vehicle) is stopped or parked in the right most lane before the zebra crossing.

Step 2: At some point, the strip detects a pedestrian standing at the edge of the zebra crossing ahead (which is partially or totally occluded by the

stopped car).




Step 2.4: The Mobile Cooperative safety function running on the C-ITS station predicts the ego driver/rider maneuver and provides a

warning to the mobile terminal of the non-equipped vehicle via LTE-4G about the pedestrian crossing the road with the indication that

the driver has to decelerate.



Step 4: As soon as the Mobile Cooperative safety function detects driver/rider proper deceleration, the warning is deactivated in the Mobile

Cooperative safety function.


Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day

Event 1 Event 2 SAFE STRIP

vehicle

(passenger, PTW)

Test Conductor

(CRF/ATTD)

1. 50 km/h Dry Daylight –

sunny Stopped/parked

car on the right

most lane before

zebra crossing.

Pedestrian

crossing the

zebra crossing

from right.

Passenger CRF, ATTD



car on the right

most lane before

zebra crossing.

Pedestrian

crossing the

zebra crossing

from left.

Passenger CRF, ATTD



car on the right

most lane before

zebra crossing.

Pedestrian

crossing the

zebra crossing

from right.

PTW CRF, ATTD



car on the right

most lane before

zebra crossing.

Pedestrian

crossing the

zebra crossing

from left.

Passenger CRF, ATTD

Baseline: Baseline scenario is not available.


5.3.3 ES1.2: Wrong Way Driving of Mobile Cooperative safety function

ES1.2: Wrong Way Driving

Step 1: The driver/rider of the non-equipped ego vehicle drives in the test area with the recommended speed.

Step 2: At some point, the strip detects a vehicle moving in the wrong direction in the entrance lane of a rest area or gas station of a motorway.

Step 2.1: The strip sends to the RSB notification about the presence of wrong way driving vehicle, its position and speed.



Step 2.4: The Mobile Cooperative safety function running on the C-ITS station issues a warning to the mobile terminal of the non-

equipped vehicle via LTE-4G of the presence of an incoming vehicle driving in the wrong direction to the ego vehicle in the motorway

approaching the entrance lane to the rest area/gas station with the indication that the driver has to reduce speed and/or stop if it gets more

critical. If the wrong way driving vehicle is a non-equipped vehicle it will receive a warning to stop in its mobile terminal of the non-

equipped vehicle via LTE-4G of the travelling in the wrong direction.

Step 4: The driver reduces the speed/stops accordingly. If the wrong way driving vehicle is a non-equipped vehicle it stops.

Step 5: The wrong way driving vehicle passes over the critical area.

Step 6: The warning provided by the Mobile Cooperative safety function is deactivated.

Table 6: ES1.2 – Experimental conditions.

Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e. dry,

wet)

Time of day

Event SAFE STRIP vehicle

(passenger, PTW) Test Conductor

(CRF/ATTD)

1. 80 km/h Dry Daylight – sunny Wrong way driving

vehicle driving in the

entrance lane of a rest

area or gas station of a

motorway.

Passenger CRF, ATTD


Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface


wet)

Time of day



(CRF/ATTD)

2. 80 km/h Dry Daylight – sunny Wrong way driving

vehicle driving in the

entrance lane of a rest

area or gas station of a

motorway.

PTW CRF, ATTD

Baseline: Baseline scenario is Drive-C2X where a human operator activates the warning after a wrong way driving vehicle is detected. CRF

Trento was partner of the project but we can have a limited access to results and not run.

5.3.4 ES2.1: VRU protection of In-vehicle Cooperative safety function

ES2.1.1: Pedestrian prompt to cross the zebra crossing

Step 1: The driver/rider drives in the test area with the recommended speed.

Step 2: At some point, the strip detects a pedestrian standing at the edge of the zebra crossing ahead.



Step 2.3: The RSB provides the above information to the equipped vehicle via ITS-G5 through the corresponding I2X DENM with

“Collision with Vulnerable Road User (VRU)” cause code and its coordinates.

Step 3: The In-vehicle Cooperative safety function (running on-board), upon receipt of the information, predicts the ego driver/rider maneuver

and provides a warning about the pedestrian crossing the road with the indication that the driver has to decelerate.


Step 5: As soon as the In-vehicle Cooperative safety function detects driver/rider proper deceleration, the warning is deactivated.

This scenario can be tested together with ES1.1 of non-equipped case to detect on-spot the variations in communication.



Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface


wet)

Time of day

Event SAFE STRIP

vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

1. 50 km/h Dry Daylight – sunny Pedestrian crossing the

zebra crossing from right. Passenger CRF, ATTD


zebra crossing from left. Passenger CRF, ATTD


zebra crossing from right. PTW CRF, ATTD


zebra crossing from left. PTW CRF, ATTD

Baseline: Baseline scenario comes from SOLCO industrial project by CRF where the VRU is detected through its mobile phone and three

Bluetooth antenna inside the vehicle. Speed in this case has to be lower (20km/h) and distance of detection is around 40m. It is possible to run

the application since was developed by the CRF team in Trento.

ES2.1.2: Pedestrian prompt to cross the zebra crossing with stopped vehicle

Step 1: The driver/rider drives in the test area (a road with two lanes per direction) with the recommended speed and car (or another vehicle) is

stopped or parked in the right most lane before the zebra crossing.

Step 2: At some point, the strip detects a pedestrian standing at the edge of the zebra crossing ahead (which is partially or totally occluded by the

stopped car).



Step 2.3: The RSB provides the above information to the equipped vehicle via ITS-G5 through the corresponding I2X DENM with

“Collision with Vulnerable Road User (VRU)” cause code and its coordinates.



and provides a warning about the pedestrian crossing the road with the indication that the driver has to decelerate.




Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road

surface

condition

(i.e. dry, wet)

Time of day

Event 1 Event 2 SAFE STRIP vehicle


(CRF/ATTD)



car on the right

most lane before

zebra crossing.

Pedestrian prompt

to cross the zebra

crossing from

right.

Passenger CRF, ATTD



car on the right

most lane before

zebra crossing.

Pedestrian prompt

to cross the zebra

crossing from left.

Passenger CRF, ATTD



car on the right

most lane before

zebra crossing.

Pedestrian prompt

to cross the zebra

crossing from

right.

PTW CRF, ATTD



car on the right

most lane before

zebra crossing.

Pedestrian prompt

to cross the zebra

crossing from left.

Passenger CRF, ATTD


Baseline: Baseline scenario comes from SOLCO industrial project by CRF where the VRU is detected through its mobile phone and three

Bluetooth antenna inside the vehicle. Speed in this case has to be lower (20km/h) and distance of detection is around 40m. It is possible to run

the application since was developed by the CRF team in Trento.

5.3.5 ES2.2: Wrong Way Driving of In-vehicle Cooperative safety function

ES2.2: Wrong Way Driving


Step 2: At some point, the strip detects a vehicle moving in the wrong direction in the entrance lane of a rest area or gas station of a motorway.

Step 2.1: The strip sends to the RSB notification about the presence of wrong way driving vehicle, its position and speed.


Step 2.3: The RSB provides the above information to the equipped vehicle via ITS-G5 through an I2X DENM with “Wrong Way

Driving” cause code.

Step 3: The In-vehicle Cooperative safety function (running on-board), upon receipt of the information, issues a warning of the presence of an

incoming vehicle driving in the wrong direction to the ego vehicle in the motorway approaching the entrance lane to the rest area/gas station

with the indication that the driver has to reduce the speed to a suggested safe value.

Step 4: The driver/rider reduces speed accordingly or stops if warning becomes more critical.

Step 5: The wrong way driving vehicle passes over the critical area.

Step 6: The warning provided by the In-Vehicle Cooperative safety function is deactivated.

This scenario can be tested together with ES1.2 of non-equipped case to detect on-spot the variations in communication.



Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface


wet)

Time of day

Event SAFE STRIP

vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

1. 80 km/h Dry Daylight – sunny Wrong way driving vehicle

driving in the entrance lane

of a rest area or gas station

of a motorway.

Passenger CRF, ATTD

2. 80 km/h Dry Daylight – sunny Wrong way driving vehicle

driving in the entrance lane

of a rest area or gas station

of a motorway.

PTW CRF, ATTD

Baseline: Baseline scenario is Drive-C2X where a human operator activate the warning after a wrong way driving vehicle is detected. CRF and

Trento were partners of the project but we can have a limited access to results and it is not feasible to run the app.

5.3.6 ES3: Road wear level and predictive road maintenance

ES3: Road wear level and predictive road maintenance

Step 1: At least 4 vehicle runs will be preceded to generate road pavement deformation.

Step 2: The strip (ORU part with strain gauges) installed at the selected pavement sections is transmitting information regarding pavement

thickness, traffic loading and measured tensile strain to the RSB (every half an hour during trials).

Step 3: The RSB transmits the information to the C-ITS-S of SAFE STRIP.

Step 4: The Road wear level and predictive road maintenance, running on the C-ITS-S, evaluates the types of distress (cracking) that are

collected by the strain gauge measurements during the survey to determine whether the factors that trigger the selection of treatments are

included.


Step 5: The Road wear level and predictive road maintenance evaluates the procedures that are used to convert pavement distress information

into pavement condition indices.

Step 6: The strain measurements are provided from the C-ITS station to the infrastructure operator.

Step 7: The infrastructure operator identifies treatments for repair, if applicable, and decides if prompt reaction or not is required, based on

strain signals that show deformations exceeding the safe operating strain levels.

Step 8: The infrastructure operator decision is sent back to the C-ITS station and is directed to the drivers through the (personalised) VMS

(this last step will not be assessed in the 3rd round of trials).

Table 10: ES3 – Experimental conditions.

Experimental conditions

Vehicles average

speed

Road surface


wet)

Time of day Event SAFE STRIP vehicle

(passenger, PTW)

Test Conductor

(CRF/ATTD)

80 km/h – vehicle

runs (IRI standard

speed)

Not relevant/dependent Not relevant/dependent Vehicle runs Passenger, PTW,

trucks vehicle loads

CRF, ATTD

No baseline scenario is applicable.

5.3.7 ES4.1: Work zone detection of In-vehicle application for rail crossing and road works safety function

ES4.1: Road works detection

Step 1: The driver/rider drives in the test area with the recommended speed towards a railway crossing.

Step 2: At some point, the strip detects a vehicle traveling towards the road work zone.

Step 2.1: The strip sends to the RSB the information of the vehicle existence.

Step 2.2: At the same time, the strip sends to the RSB the position at lane level and speed of the ego vehicle.

Step 2.3: At the same time, the strip sends to the RSB the presence of stopped vehicles (queue).

Step 2.4: At the same time, the strip sends to the RSB the road work lane geometry and layout (occupied lanes).

Step 2.5: The RSB sends information to the equipped vehicle via ITS-G5.



and provides a warning to adapt the speed, and/or change lane if necessary and/or stop if queue ahead.

Step 4: The driver/rider adapts speed accordingly and if required change lane.

Step 5: As soon as the In-vehicle Cooperative safety function detects driver/rider adapts to a proper speed or a stops and or change lane, the

warning is deactivated.


Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road

surface

condition

(i.e. dry, wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)


sunny Right most lane

closed. Vehicle is

approaching a road

work zone.

Passenger CRF, ATTD



closed. Vehicle is

approaching a road

work zone.

PTW CRF, ATTD



closed and left

lane occupied by

stopped vehicle.

Vehicle is

approaching a road

work zone.

Passenger CRF, ATTD



closed and left

lane occupied by

stopped vehicle.

Vehicle is

approaching a road

work zone.

PTW CRF, ATTD

Baseline: The baseline is Drive-C2X where an operator manually issues the road work ahead to approaching vehicle via ITS-G5.


5.3.8 ES4.2: Railway crossing detection of In-vehicle application for rail crossing and road works safety function

ES4.2: Railway crossing for equipped vehicles


Step 2: At some point, the strip detects a vehicle traveling towards the railway crossing.


Step 2.2: At the same time, the strip sends to the RSB the position and speed of the ego vehicle. Additionally, for unprotected railway

crossing information about speed limit at the crossing is also given.

Step 2.3: The SAFE STRIP technology also broadcast the information about ETA of approaching train obtained from SAFER LC to the

equipped vehicle via ITS-G5.


and provides a warning to adapt the speed to the prescribed speed limit at the railway crossing or to stop before if a train is approaching.

Step 4: The driver/rider adapts speed accordingly or stop before the crossing.

Step 5: As soon as the In-vehicle Cooperative safety function detects driver/rider proper speed or deceleration or it comes to a stop, the



Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road

surface

condition

(i.e. dry, wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)


sunny no train is

coming Vehicle is approaching a

railway crossing. Passenger CRF, Thessaloniki

(rail)


sunny no train is

coming Vehicle is approaching a

railway crossing. PTW

3. 50 km/h Dry Daylight – train is Vehicle is approaching a Passenger


Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road

surface

condition

(i.e. dry, wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

sunny approaching railway crossing.


sunny train is

approaching Vehicle is approaching a

railway crossing. PTW

Baseline: There is no baseline for equipped since SAFER-LC project is using LTE communication.

5.3.9 ES5.1: Work zone detection of Mobile application for rail crossing and road works safety function

ES5.1: Work zone detection


Step 2: At some point, the strip detects a vehicle traveling towards the road work zone.


Step 2.2: At the same time, the strip sends to the RSB the position at lane level and speed of the ego vehicle.

Step 2.3: At the same time, the strip sends to the RSB the presence of stopped vehicles (queue).

Step 2.4: At the same time, the strip sends to the RSB the road work lane geometry and layout (occupied lanes).

Step 2.5: The RSB sends information to the equipped vehicle via the C-ITS-S of SAFE STRIP via LTE-4G.

Step 3: The Mobile Cooperative safety function running on the C-ITS station issues a warning to the mobile terminal of the non-equipped

vehicle via LTE-4G, upon receipt of the information, predicts the ego driver/rider maneuver and provides a warning to adapt the speed, and/or

change lane if necessary and/or stop if queue ahead.

Step 4: The driver/rider adapts speed accordingly and if required change lane.

Step 5: As soon as the Mobile Cooperative safety function detects driver/rider adapts to a proper speed or a stops and or change lane, the




Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

1. 80 km/h Dry Daylight – sunny Right most

lane closed. Vehicle is

approaching a

road work zone.

Passenger CRF, ATTD


lane closed. Vehicle is

approaching a

road work zone.

PTW CRF, ATTD


lane closed and

left lane

occupied by

stopped

vehicle.

Vehicle is

approaching a

road work zone.

Passenger CRF, ATTD

4. 80 km/h Dry Daylight – sunny t Right most

lane closed and

left lane

occupied by

stopped

vehicle.

Vehicle is

approaching a

road work zone

PTW CRF, ATTD

Baseline: There is no baseline since Drive-C2X is designed for ITS-G5 communication (additionally is manually operated).


5.3.10 ES5.2: Railway crossing detection of Mobile application for rail crossing and road works safety function

ES5.2: Railway crossing for non-equipped vehicles


Step 2: At some point, the strip detects a vehicle traveling towards the railway crossing.


Step 2.2: At the same time, the strip sends to the RSB the position and speed of the ego vehicle. Additionally for unprotected railway

crossing information about speed limit at the crossing is also given. The information is provided by the RSB to the C-ITS-S of SAFE

STRIP via LTE-4G.

Step 2.3: The SAFE STRIP technology also broadcast the information about ETA of approaching train obtained from SAFER LC to the

equipped vehicle via the C-ITS-S of SAFE STRIP via LTE-4G.


vehicle via LTE-4G of upon receipt of the information, that predicts the ego driver/rider maneuver and provides a warning to adapt the speed to

the prescribed speed limit at the railway crossing or to stop before if a train is approaching.

Step 4: The driver/rider adapts speed accordingly or stop before the crossing.

Step 5: As soon as the Mobile Cooperative safety function detects driver/rider adapts to a proper speed or it comes to a stop, the warning is

deactivated.


Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)


sunny No train is

coming. Vehicle is

approaching a

railway crossing.

Passenger CRF, Thessaloniki

(rail)


Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)


sunny No train is

coming. Vehicle is

approaching a

railway crossing.

PTW


sunny Train is

approaching. Vehicle is

approaching a

railway crossing.

Passenger


sunny Train is

approaching. Vehicle is

approaching a

railway crossing.

PTW

Baseline: The baseline is SAFER-LC project which is using LTE communication to and a central service to detect via GPS signal of each

approaching vehicle if a vehicle is going to cross the railway.

5.3.11 ES6.1: Urban intersection of In-vehicle application for merging and intersection support (e2Call)

ES6.1: Urban intersection


Step 2: At some point, the strip detects a vehicle approaching to the intersection and an opponent vehicle coming from a side road.

Step 2.1: The strip sends to the RSB the information of the detected vehicle and the opponent vehicle.

Step 2.2: At the same time, the strip sends to the RSB the position at the lane level and speed of the ego vehicle and opponent vehicle.

Step 2.3: At the same time, the RSB sends additional information such as intersection layout, limit and right of way.

Step 2.4: The RSB provides the above information to the equipped vehicle via ITS-G5 through the corresponding I2X proper message

code and its coordinates.


Step 3: The In-vehicle Cooperative safety function (running on-board), upon receipt of the information, evaluates the potential feasible

manoeuvers and conflicting trajectories and issue a warning to the driver suggesting a deceleration and a proper speed.




Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)


sunny Obstacle

approaching and

stopping late at

intersection

Vehicle

approaching the

intersection with

right of way

Passenger CRF


sunny Obstacle

approaching and

stopping late at

intersection

Vehicle

approaching the

intersection with

right of way

PTW CRF


sunny Obstacle

approaching and

not stopping at

intersection

Vehicle

approaching the

intersection with

right of way

Passenger CRF


sunny Obstacle

approaching and

not stopping at

intersection

Vehicle

approaching the

intersection with

right of way

PTW CRF


Baseline: The baseline is e2Call project that can be run in the same scenario. System is based on accurate RTK-GPS positioning.

5.3.12 ES6.2: Intersection with wet/dry road condition of In-vehicle application for merging and intersection support (e2Call)

ES6.2: Urban intersection with wet/dry


Step 2: At some point, the strip detects a vehicle approaching to the intersection and another vehicle (opponent) approaching from a crossing

road.

Step 2.1: The strip sends to the RSB the information of the detected vehicle and opponent vehicle.

Step 2.2: At the same time, the strip sends to the RSB the position at the lane level and speed of the ego vehicle and opponent vehicle.


Step 2.4: At the same time, the RSB sends road surface friction condition.




manoeuvers and conflicting trajectories and issue a warning to the driver suggesting a deceleration to a proper speed including the friction

surface condition.




Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface


wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

1. 50 km/h Dry Daylight – Obstacle Vehicle Passenger CRF


Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface


wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

sunny approaching and

stopping late at

intersection

approaching the

intersection with

right of way


sunny Obstacle

approaching and

stopping late at

intersection

Vehicle

approaching the

intersection with

right of way

PTW CRF


sunny Obstacle

approaching and

not stopping at

intersection

Vehicle

approaching the

intersection with

right of way

Passenger CRF


sunny Obstacle

approaching and

not stopping at

intersection

Vehicle

approaching the

intersection with

right of way

PTW CRF

5. 50 km/h Wet Daylight –

sunny Obstacle

approaching and

stopping late at

intersection

Vehicle

approaching the

intersection with

right of way

Passenger CRF


sunny Obstacle

approaching and

stopping late at

intersection

Vehicle

approaching the

intersection with

right of way

PTW CRF


sunny Obstacle

approaching and

Vehicle

approaching the

Passenger CRF


Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface


wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

not stopping at

intersection intersection with

right of way


sunny Obstacle

approaching and

not stopping at

intersection

Vehicle

approaching the

intersection with

right of way

PTW CRF

Baseline: The baseline is e2Call project that can be run in the same scenario if necessary but does not include the friction information. System is

based on accurate RTK-GPS positioning.

5.3.13 ES6.3: Motorway exit of In-vehicle application for merging and intersection support (e2Call)

ES6.3: Motorway exit


Step 2: At some point, the strip detects a vehicle approaching an exit lane and a vehicle stopped or slowly moving in the exit lane.

Step 2.1: The strip sends to the RSB the information of the detected vehicle approaching and of the stopped vehicle.

Step 2.2: At the same time, the strip sends to the RSB the position and the speed of the ego vehicle and the position of the stopped or

slowly moving vehicle

Step 2.3: At the same time, the RSB sends additional information such as the road geometry of the exit lane.




manoeuvers and issue a warning to the driver suggesting a deceleration to a proper speed when its actual speed is not compatible with lane exit

road geometry and/or the ahead traffic.





Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface


wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)


sunny Obstacle

vehicle

stopped in the

vehicle lane

Vehicle

approaching and

taking the exit

lane

Passenger CRF


sunny Obstacle

vehicle

stopped in the

vehicle lane

Vehicle

approaching and

taking the exit

lane

PTW CRF

Baseline: There is no baseline for this scenario.

5.3.14 ES7.1: Urban intersection of Mobile application for merging and intersection support

ES7.1: Urban intersection


Step 2: At some point, the strip detects a vehicle approaching to the intersection and an opponent vehicle coming from a crossing road.

Step 2.1: The strip sends to the RSB the information of the detected vehicle and of the opponent vehicle.

Step 2.2: At the same time, the strip sends to the RSB the position at the lane level and speed of the ego vehicle and of opponent vehicle.



Step 2.4: The RSB provides the above information to the non-equipped vehicle via the C-ITS-S of SAFE STRIP and LTE-4G

communication.


vehicle via LTE-4G, evaluates the potential feasible manoeuvers and conflicting trajectories and issue a warning to the driver suggesting a

deceleration and a proper speed.


Step 5: As soon as the Mobile Cooperative safety function detects driver/rider proper deceleration, the warning is deactivated.


Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

1. 50 km/h Dry Daylight – sunny Obstacle

approaching

and stopping

late at

intersection

Vehicle

approaching the

intersection with

right of way

Passenger CRF


approaching

and stopping

late at

intersection

Vehicle

approaching the

intersection with

right of way

PTW CRF


approaching

and not

stopping at

Vehicle

approaching the

intersection with

right of way

Passenger CRF


Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

intersection


approaching

and not

stopping at

intersection

Vehicle

approaching the

intersection with

right of way

PTW CRF

Baseline: The baseline is e2Call project that can be run in the same scenario if necessary. System is based on accurate RTK-GPS positioning.

5.3.15 ES7.2: Intersection with wet/dry road condition of Mobile application for merging and intersection support (e2Call)

ES7.2: Urban intersection with wet/dry


Step 2: At some point, the strip detects a vehicle approaching to the intersection and an opponent vehicle coming from a crossing road.

Step 2.1: The strip sends to the RSB the information of the detected vehicle and of an opponent vehicle.

Step 2.2: At the same time, the strip sends to the RSB the position at the lane level and speed of the ego vehicle and of the opponent

vehicle.


Step 2.4: At the same time, the RSB sends road surface friction condition.


communication.

Step 3: Mobile Cooperative safety function running on the C-ITS station issues a warning to the mobile terminal of the non-equipped

vehicle via LTE-4G, upon receipt of the information, evaluates the potential feasible manoeuvers and conflicting trajectories and issue a warning

to the driver suggesting a deceleration to a proper speed including the friction surface condition.





Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day


vehicle

(passenger, PTW)

Test Conductor

(CRF/ATTD)


sunny Obstacle

approaching and

stopping late at

intersection

Vehicle approaching

the intersection with

right of way

Passenger CRF


sunny Obstacle

approaching and

stopping late at

intersection

Vehicle approaching


right of way

PTW CRF


sunny Obstacle

approaching and

not stopping at

intersection

Vehicle approaching


right of way

Passenger CRF


sunny Obstacle

approaching and

not stopping at

intersection

Vehicle approaching


right of way

PTW CRF


sunny Obstacle

approaching and

stopping late at

intersection

Vehicle approaching


right of way

Passenger CRF


Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day


vehicle

(passenger, PTW)

Test Conductor

(CRF/ATTD)


sunny Obstacle

approaching and

stopping late at

intersection

Vehicle approaching


right of way

PTW CRF


sunny Obstacle

approaching and

not stopping at

intersection

Vehicle approaching


right of way

Passenger CRF


sunny Obstacle

approaching and

not stopping at

intersection

Vehicle approaching


right of way

PTW CRF

Baseline: The baseline is e2Call project that can be run in the same scenario but does not include the friction information. System is based on

accurate RTK-GPS positioning.

5.3.16 ES7.3: Motorway exit of Mobile application for merging and intersection support (e2Call)

ES7.3: Motorway exit


Step 2: At some point, the strip detects a vehicle approaching an exit lane and a vehicle stopped or slowly moving in the exit lane.

Step 2.1: The strip sends to the RSB the information of the detected vehicle approaching and stopped vehicle.

Step 2.2: At the same time, the strip sends to the RSB the position and the speed of the ego vehicle and the position of the stopped or

slowly moving vehicle


Step 2.3: At the same time, the RSB sends additional information such as the road geometry of the exit lane.


communication.

Step 3: Mobile Cooperative safety function running on the C-ITS station issues a warning to the mobile terminal of the non-equipped

vehicle via LTE-4G, evaluates the potential feasible manoeuvers and issue a warning to the driver suggesting a deceleration to a proper speed

when its actual speed is not compatible with lane exit road geometry and/or the ahead traffic.




Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface


wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)


sunny Obstacle

vehicle

stopped in the

vehicle lane

Vehicle

approaching and

taking the exit

lane

Passenger CRF


sunny Obstacle

vehicle

stopped in the

vehicle lane

Vehicle

approaching and

taking the exit

lane

PTW CRF

Baseline: There is no baseline for this scenario.


5.3.17 ES8.1: Virtual VMS 1 – Critical case of In-vehicle application for personalised VMS/VDS and Traffic Centre Information

ES8.1: Virtual VMS 1 – Critical case

Step 1: The driver/rider of the equipped ego-vehicle drives in the test area with the recommended speed.

Step 2: The strip (through the ORU with switches) sendstraffic classification metric to the RSB.

Step 2.1: The RSB sends the data to the C-ITS-S.

Step 2.2: The part of the Application for personalised VMS/VDS and Traffic Centre Information that runs in the cloud determines

that there is heavy traffic ahead on the lane the ego-vehicle is running.

Step 2.3: A decision for notification to the drivers is issued and is sent to the TMC of the operator.

Step 2.4: The Operator validates the decision and sends back confirmation to the C-ITS-S.

Step 2.5: The decision is sent from C-ITS-S to the RSB.

Step 2.6: The RSB sends the decision to the equipped vehicle (on-board).

Step 3: The In-vehicle application for personalised VMS/VDS and Traffic Centre Information, upon receipt of the information, issues a

notification to the driver/rider to his/her language informing him at which point ahead the heavy traffic is noticed and recommends to him/her to

change lane and/or take the next exit.

Step 4: The driver/rider of the equipped ego-vehicle conforms to the recommendation and changes lane/takes the next exit.

Step 5: The In-vehicle application for personalised VMS/VDS and Traffic Centre Information detects that the event is no longer applicable

for the driver/rider and the info/warning/recommendation is deactivated.


Sub-

scenarios


Ego vehicle travel speed

(entry speed and average

speed when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day

Event SAFE STRIP

vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

1. 80 km/h Dry Daylight – sunny Heavy Traffic

(emulated in this

round)

Passenger CRF, ATTD


Sub-

scenarios





taking place)

Road surface

condition (i.e.

dry, wet)

Time of day

Event SAFE STRIP

vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

2. 80 km/h Dry Daylight – sunny Heavy Traffic

(emulated in this

round)

PTW CRF, ATTD

Baseline: The baseline scenario is in this case the typical usage of current VMS/VDS. At least 3 iterations will be run for this typical passage in

the toll stations of ATTD and A22 and the same KPI’s will be measured as anticipated in the SAFE STRIP scenarios (to the maximum extent

possible as there is no absolute mapping of the incidents targeted and supported currently by existing infrastructure) in order to cross-compare

after the pilots. Event diaries will be used in this case to replace the automatic logging mechanisms that will be used in SAFE STRIP scenarios.

5.3.18 ES8.2: Virtual VMS 2 – Critical case of In-vehicle application for personalised VMS/VDS and Traffic Centre Information



Step 2: The strip detects liquid fuel/oil 100 meters ahead in the lane of the ego-vehicle.

Step 2.1: The information is sent from the strip to the RSB.

Step 2.2: The RSB sends the info to the C-ITS-S.


that critical warning has to be issued.







critical warning to the driver/rider to his/her language informing him at which point ahead the leak is detected and recommends to him/her to

change lane (in a given timeframe depending on his/her current Time headway to the liquid fuel/oil leak).

Step 4: The driver/rider of the equipped ego-vehicle conforms to the recommendation and changes lane.




Sub-

scenarios


Ego vehicle travel

speed (entry speed

and average speed

when no event is

taking place)

Road surface


wet)

Time of day

Event SAFE STRIP

vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

1. 40 km/h (though

this is a scenario for

highway context, it

is necessary that the

speed is low due to

safety reasons)

Dry Daylight – sunny Fuel/oil leak on

the road

pavement.

Passenger CRF, ATTD

2. 40 km/h Dry Daylight – sunny Fuel/oil leak on

the road

pavement.

PTW CRF, ATTD

Baseline: As above.


5.3.19 ES8.3: Virtual VMS 2 – Non- Critical case of In-vehicle application for personalised VMS/VDS and Traffic Centre Information

ES8.3: Virtual VMS 2 – Non- Critical case


Step 2: The strip detects that there is the ambient light is low.




that a notification to the drivers/riders has to be issued.






notification to the driver/rider to his/her language informing him that visibility is low and s/he should switch on the headlights.

Step 4: The driver/rider of the equipped ego-vehicle conforms to the recommendation and switches on the headlights.




Sub-

scenarios


Ego vehicle travel

speed (entry speed

and average speed

when no event is

taking place)

Road surface


wet)

Time of day

Event SAFE STRIP

vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

1. 80 km/h Dry During sun setting. - Passenger CRF, ATTD

2. 80 km/h Dry During sun setting. - PTW CRF, ATTD


Baseline: As above.

5.3.20 ES9.1: Virtual VMS 1 – Critical case of Mobile application for personalised VMS/VDS and Traffic Centre Information


Step 1: The driver/rider of the non-equipped ego-vehicle drives in the test area with the recommended speed.

Step 2: The strip (through the ORU with switches) sends traffic classification metric data to the RSB.


Step 2.2: The Mobile application for personalised VMS/VDS and Traffic Centre Information that is running on C-ITS-S, determines

that there is heavy traffic ahead on the lane the ego-vehicle is running.



Step 2.5: The Mobile application for personalised VMS/VDS and Traffic Centre Information, provides a notification to the mobile

terminal of the non-equipped vehicle driver via LTE-4G about heavy traffic ahead in the ego lane to his/her language informing him at

which point ahead the heavy traffic is noticed and recommends to him/her to change lane and/or take the next exit.

Step 3: The driver/rider of the non - equipped ego-vehicle conforms to the recommendation and changes lane/takes the next exit.

Step 4: The Mobile application for personalised VMS/VDS and Traffic Centre Information detects that the event is no longer applicable for

the driver/rider and the info/warning/recommendation is deactivated.


Sub-

scenarios


Ego vehicle travel

speed (entry speed

and average speed

when no event is

taking place)

Road surface


wet)

Time of day

Event SAFE STRIP

vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)


Sub-

scenarios


Ego vehicle travel

speed (entry speed

and average speed

when no event is

taking place)

Road surface


wet)

Time of day

Event SAFE STRIP

vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

1. 80 km/h Dry Daylight – sunny Heavy Traffic (emulated

in this round)

Passenger CRF, ATTD

2. 80 km/h Dry Daylight – sunny Heavy Traffic (emulated

in this round)

PTW CRF, ATTD

Baseline: As above.

5.3.21 ES9.2: Virtual VMS 2 – Critical case of Mobile application for personalised VMS/VDS and Traffic Centre Information



Step 2: The strip detects liquid fuel/oil 100 meters ahead in the lane of the ego-vehicle.




that critical warning has to be issued, since there is liquid fuel ahead, on the lane the ego-vehicle is running.




terminal of the non-equipped vehicle driver via LTE-4G about liquid fuel/oil ahead in the ego lane, to his/her language, informing him

at which point ahead the leak is detected and recommends to him/her to change lane (in a given timeframe depending on his/her current

Time headway to the fuel/oil leak).

Step 3: The driver/rider of the non-equipped ego-vehicle conforms to the recommendation and changes lane.


Step 4: The Mobile application for personalised VMS/VDS and Traffic Centre Information detects that the event is no longer applicable for

the driver/rider and the info/warning/recommendation is deactivated.


Sub-

scenarios




speed when no event is taking

place)

Road surface


wet)

Time of day

Event SAFE STRIP

vehicle

(passenger,

PTW)

Test Conductor

(CRF/ATTD)

1. 40 km/h (though this is a

scenario for highway context,

it is necessary that the speed is

low due to safety reasons)

Dry Daylight – sunny Fuel/oil leak on the

road pavement Passenger CRF, ATTD

2. 40 km/h Dry Daylight – sunny Fuel/oil leak on the

road pavement PTW CRF, ATTD

Baseline: As above.

5.3.22 ES9.3: Virtual VMS 2 – Non- Critical case of Mobile application for personalised VMS/VDS and Traffic Centre Information

ES9.3: Virtual VMS 2 – Non - Critical case


Step 2: The strip detects that the ambient light is low.




that a notification to the drivers/riders has to be issued.





terminal of the non-equipped vehicle driver via LTE-4G that the visibility is low and she/he should switch on the headlights.

Step 3: The driver/rider of the non-equipped ego-vehicle conforms to the recommendation and switches on the headlights.


Sub-

scenarios





taking place)

Road surface


wet)

Time of day

Event SAFE STRIP

vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

1. 80 km/h Dry During sun setting. - Passenger CRF, ATTD

2. 80 km/h Dry During sun setting. - PTW CRF, ATTD

Baseline: As above.

5.3.23 ES10.1: Dynamic trajectory estimation of Autonomous vehicles support

ES10.1: Dynamic trajectory estimation for automated vehicles / ego lane trajectory information

Step 1: The autonomous vehicle drives in the test area with the recommended speed.

Step 2: Τhe strip provides to the RSB the identification of the lane in which the vehicle is driving, the position of the vehicle in the lane, the

GPS position of the center of the lane in which the ego - vehicle is driving and its width.

Step 3: The RSB provides the above information to the equipped vehicle via ITS-G5.

Step 4: The data provided by the RSB are merged with the data coming from the vehicle perception and localization system of the on-board

autonomous function to compute the dynamic trajectory.

Step 5: The vehicle trajectory is corrected.




Ego vehicle travel

speed (entry speed and

average speed when

no event is taking

place)

Road surface

condition (i.e. dry, wet)

Time of day


(passenger, PTW)

Test Conductor

(CRF/ATTD)

40 km/h Dry Daylight – sunny

Distorted lane

marking not

perceived by the on-

board system.

Autonomous vehicle CRF

Baseline: No baseline scenario will be run in CRF. Baseline data will be referenced from VALEO regarding existing vehicle perception system

operation (from own trials).

5.3.24 ES10.2: Definition of lane-level virtual corridors of Autonomous vehicles support

ES10.2: Definition of lane-level virtual corridors / multiple carriage way


Step 2: Τhe strip provides to the RSB the information that a new lane is created and ,what is the center position of the new lane (or the offset

from the center of the initial lane) and the width of the created lane.


Step 4: The vehicle receives at least 200m ahead this information from the RSB which allows the car to detect the updated data of available

lanes and the information of in which lane the car is now located.




Ego vehicle travel


average speed when

no event is taking

place)

Road surface


Time of day


(passenger, PTW)

Test Conductor

(CRF/ATTD)


A new lane is created

in the motorway.


Baseline: As above.

5.3.25 ES10.3: Tollgates management of Autonomous vehicles support

ES10.3: Tollgates management


Step 2: Τhe strip provides to the RSB the information that the vehicle is approaching a toll zone, the GPS position of the gate, the lane in which

the car is located and which lane corresponds to the targeted gate (besides data provided for dynamic trajectory estimation)


Step 4: The vehicle reaches the open gate.

Step 5: The car crosses the gate and follows the virtual lane (that is tagged by the strip) to reach a lane with road marking.




Ego vehicle travel


average speed when

no event is taking

place)

Road surface


Time of day


(passenger, PTW)

Test Conductor

(CRF/ATTD)


Toll zone existence

ahead of the vehicle.

One toll gate only

available for the

automated vehicle.


Baseline: As above.

5.3.26 ES10.4: Work zones detection of Autonomous vehicles support

ES10.4: Work zones detection


Step 2: Τhe strip provides to the RSB the information that the vehicle is approaching a workzone and the information of the precise localization

of the starting point and of the ending point of the work zone, that the Lane number 1 is closed and that the speed limit would be reduced at

20km/h over the entire work zone.


Step 4: The vehicle positions itself on the Lane number 2.

Step 5: The vehicle reduces its speed to the temporary limit to cross the work zone.




Ego vehicle travel


average speed when

no event is taking

place)

Road surface


Time of day


(passenger, PTW)

Test Conductor

(CRF/ATTD)


Work zone emulated.

2 Lanes. Lane 1

closed. Lane 2

available for vehicle.


Baseline: As above.

5.3.27 ES11: Virtual Toll Collection of Application for Virtual Toll Collection

ES11: Virtual Toll Collection

Pre-trip:

Step 1: The driver/rider opens the Application for Virtual Toll Collection.

Step 2: The Application for Virtual Toll Collection shows all configured vehicles (registered to the driver/rider).

On-trip

Step 3: The driver/rider enters the vehicle, opens the application and starts driving on the motorway heading a virtual toll gate.

Step 4: The strip close to the virtual toll gate detects and identifies the passing vehicle.

Step 4.1: The strip sends to the RSB the information.

Step 4.2: The RSB provides the above information to the C-ITS-S.

Step 4.3: The C-ITS-S sends the information (through LTE/4G) to the mobile terminal of the driver/rider.


Step 5: Upon receipt of the information, the Application for Virtual Toll Collection on mobile shows a pop-up for 5 seconds to inform the

driver/rider about approaching a virtual tollgate, giving a recommendation to slow down and that an automatic payment will be held in a specific

timeframe (the amount of payment is also acknowledged).

Step 6: The driver/rider passes over the next strip which is statically configured as virtual toll gate.

Step 7: The strip reads the RFID tag and identifies the vehicle.

Step 8: The strip sends the vehicle ID to the RSB.

Step 9: The RSB forwards the information to the C-ITS-S.

Step 10: The toll application part running on C-ITS-S receives the information and processes the payment.

Step 11: The toll application sends the payment status/result directly to the driver mobile terminal via LTE/4G.

Table 31: ES11 – Experimental conditions.

Sub-

scenarios


Ego vehicle travel speed (entry

speed and average speed when

no event is taking place)

Road surface

condition

Time of

day


(passenger, PTW)

Test Conductor

(CRF/ATTD)


sunny

Virtual Toll

ahead of the

driver.

Passenger CRF, ATTD


sunny

Virtual Toll

ahead of the

rider.

PTW CRF, ATTD

Baseline scenario: The baseline scenario is in this case the typical passage of drivers through current toll stations. At least 3 iterations will be

run for this typical passage in the toll stations of ATTD and A22 and the same KPI’s will be measured as anticipated in the SAFE STRIP

scenario in order to cross-compare after the pilots. It might be the case that additional runs will be also performed with the Telepass application

in Italy. Event diaries will be used in this case to replace the automatic logging mechanisms that will be used in SAFE STRIP scenarios.


5.3.28 ES12.1: Numbered parking with payment of Application for parking booking and charging

ES12.1: Numbered parking with payment

Step 1: The driver is driving in the test zone and wishes to park his/her vehicle. As such, s/he opens the Application for parking booking and

charging (in his/her mobile terminal).

Step 2: The driver requests for a parking place through the app.

Step 3: The information is sent to the C-ITS-S and from there to the parking operator.

Step 4: The parking operator receives the request.

Step 5: The strip (located in the parking zone) send information to the RSB (through ITS-G5) about availability of parking places, from there to

the C-ITS-S and from there to the parking operator.

Step 6: The parking operator, upon the information received by the strips (part of the Application for parking booking and charging running

on cloud), issues the answer for the driver regarding the availability of parking lots. The information is sent from the operator site to the C-ITS-S

of SAFE STRIP.

Step 7: C-ITS-S sends the information back to the driver mobile terminal.

Step 8: Upon receipt of the information, the driver makes the booking through the mobile app.

Step 9: The booking information is sent through LTE to the C-ITS-S and from there to the parking operator for his acknowledgement.

Step 10: The parking operator confirms. The confirmation is sent back to the C-ITS-S and from there to the mobile terminal of the driver

(through LTE).

Step 11: The driver gets into the parking and parks in the booked place.

Step 12: The strip records the vehicle ID and marks the beginning of the parking time.

Step 13: The information is sent to the RSB and from there to the parking operator.

Step 14: The status of the parking space is updated (occupied).

Step 15: After the desired parking time has passed, the driver moves the car out of the parking slot.

Step 16: The strip records the vehicle ID and marks the end of the parking time. This information is sent to operator via C-ITS-S (LTE).

Step 17: The operator charges the driver with the appropriate amount according to the parking time.

Step 18: The charging information is sent through LTE to C-ITS-S and from there to the mobile terminal of the driver.

Step 19: The charging transaction is accomplished from the mobile terminal of the driver.




Ego vehicle travel


average speed when

no event is taking

place)

Road surface

condition

Time of day


(passenger, PTW)

Test Conductor

(CRF/ATTD)


Parking zone equipped

with strips. One space

at least available (out of

at least two).

Passenger CRF/ATTD

Baseline: The current situation, in which the driver is searching for a parking space without support by any system will serve as baseline here.

Potential SoA systems will be also investigated in the context of the impact assessment. The baseline cannot be tested in a valuable way in SAFE

STRIP trials 3rd round, as the test area is very much specific and will not provide a sound reference point.

5.3.29 ES12.2: Free of charge parking of Application for parking booking and charging

ES12.2: Free of charge parking




Step 3: The information is sent to the C-ITS-S.

Step 4: The strip (located in the parking zone) sends information to the RSB (through ITS-G5) about availability of parking places and from

there to the C-ITS-S.

Step 5: The C-ITS-S, upon the information received by the strips, issues the answer for the driver regarding the availability of parking lots (in

this case, the C-ITS-S may be maintained by the City Authority or similar in a real business case).


Step 7: The driver is addressed by the application to the free lot parking and parks.


Step 8: The strip of the parking space is updated (to occupied).

Step 9: The driver removes his/her vehicle from the parking lot.

Step 10: The strip of the parking space is updated (turn to “available”).



Ego vehicle travel


average speed when

no event is taking

place)

Road surface

condition

Time of day


(passenger, PTW)

Test Conductor

(CRF/ATTD)


Free parking zone

equipped with strips.

One space at least

available (out of at least

two).

Passenger CRF/ATTD

Baseline: Same as above.

5.3.30 ES12.3: Regulated parking (blue zone) of Application for parking booking and charging

ES12.3: Regulated parking (blue zone)




Step 3: The information is sent to the C-ITS-S.

Step 4: The strip (located in the parking zone) sends information to the RSB (through ITS-G5) about availability of parking places and from

there to the C-ITS-S.

Step 5: The C-ITS-S, upon the information received by the strips, issues the answer for the driver regarding the availability of parking lots (in

this case, the C-ITS-S may be maintained by the City Authority or similar in a real business case).



Step 7: The driver is addressed by the application to the free lot parking and parks.

Step 8: The strip of the parking space is updated (to “occupied”).

Step 9: The strip records the duration of the parking time and the vehicle identification number.

Step 10: The information is sent to the RSB and from there to the municipal parking operator.

Step 11: The driver removes his/her vehicle from the parking lot.

Step 12: The status of the parking space is updated (now “available”) and the municipal parking operator issues the payment receipt.

Step 13: The information is sent through LTE to C-ITS-S and from there to the mobile terminal of the driver for his acknowledgement.



Ego vehicle travel


average speed when

no event is taking

place)

Road surface

condition

Time of day


(passenger, PTW)

Test Conductor

(CRF/ATTD)


Regulated parking zone

equipped with strips.

One space at least

available (out of at least

two).

Passenger CRF/ATTD

Baseline: Same as above.

5.3.31 Cross Use Cases Evaluation Scenarios (C-ES) - UNITN

It should be stressed that in SAFE STRIP, the effects of the vehicle functions are neither additive nor multiplicative, as the Decision Support

System that will be developed in SAFE STRIP will be responsible to prioritise warnings of all applications running together in the same

demonstrator or nomadic device. The following scenarios are indicative instances of real traffic scenarios when two different functions work

concurrently.


C-ES1: Urban intersection with pedestrian crossing with equipped vehicles


Step 2: At some point, the strip detects a vehicle approaching to the intersection, a pedestrian standing at the edge of the zebra crossing ahead

and an opponent vehicle coming from a crossing road at the same location of zebra crossing.

Step 2.1: The strip sends to the RSB the information of the detected vehicle, of the pedestrian existence.


vehicle.




Step 3: The two in-vehicle Cooperative safety functions (running on-board), upon receipt of the information, evaluate the potential feasible

manoeuvers and conflicting trajectories and each of them issue a warning suggesting a deceleration and a proper speed. The in-vehicle Decision

Support System priorities warning and deliver to the driver the most critical one.


Step 5: As soon as the, each in-vehicle Cooperative safety function detects driver/rider proper deceleration, it deactivates the warning.

Step 6: Potential situation is the one where the second warning (not initially delivered to the driver) is still judged as appropriate by the

corresponding in-vehicle Cooperative safety function. The in-vehicle Decision Support System forwards the warning to the driver.


Step 8: As soon as the, the corresponding in-vehicle Cooperative safety function detects driver/rider proper deceleration, it deactivates the

warning.

Table 35: C-ES1– Experimental conditions.

Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)


Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)


sunny Obstacle approaching and

stopping late at

intersection. Pedestrian

crossing from right

Vehicle

approaching

the

intersection

with right of

way

Passenger CRF


sunny Obstacle approaching and

stopping late at

intersection. Pedestrian

crossing from right

Vehicle

approaching

the

intersection

with right of

way

PTW CRF

No baseline scenario.

C-ES2: Urban intersection with pedestrian crossing with non-equipped vehicles


Step 2: At some point, the strip detects a vehicle approaching to the intersection, a pedestrian standing at the edge of the zebra crossing ahead

and an opponent vehicle coming from a crossing road at the same location of zebra crossing.

Step 2.1: The strip sends to the RSB the information of the detected vehicle, of the pedestrian existence.


vehicle.



Step 2.4: The RSB provides the above information to the non-equipped vehicle to C-ITS-S and then to non-equipped via LTE-4G

communication.

Step 3: The Mobile Cooperative safety function running on the C-ITS station, upon receipt of the information, evaluate the potential feasible

manoeuvers and conflicting trajectories and each of them issue a warning suggesting a deceleration and a proper speed. The Decision Support

System on the C-ITS station priorities warning and deliver to the driver the most critical one via LTE-4G communication.


Step 5: As soon as the, each Mobile Cooperative safety function detects driver/rider proper deceleration, it deactivates the warning.

Step 6: Potential situation is the one where the second warning (initially not delivered to the driver) is still judged as appropriate by the

corresponding Mobile Cooperative safety function. The Decision Support System on the C-ITS station forwards the warning to the driver.


Step 8: As soon as the, each in-vehicle Cooperative safety function detects driver/rider proper deceleration, it deactivates the warning.

Table 36: C-ES2 – Experimental conditions.

Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)


sunny Obstacle

approaching and

stopping late at

intersection.

Pedestrian

crossing from

right

Vehicle approaching


right of way

Passenger CRF


sunny Obstacle

approaching and

stopping late at

Vehicle approaching


right of way

PTW CRF


Sub-


speed (entry speed

and average speed

when no event is

taking place)

Road surface

condition (i.e.

dry, wet)

Time of day


vehicle (passenger,

PTW)

Test Conductor

(CRF/ATTD)

intersection.

Pedestrian

crossing from

right

No baseline scenario is applicable.


6 Direct, derived and self-reported measures/metrics & measuring tools

6.1 Direct (raw) & derived measures

6.1.1 ES1.1: Virtual VRU protection of Mobile Cooperative safety function

Table 37: ES1 - research questions addressed, KPI’s, hypotheses & metrics.

Research

Questions

KPI’s Hypotheses to be

tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

RQ1: Does the

system function

as expected

under realistic

conditions

(according to

specs but also

according to user

perception)?

False/missed/dela

yed alarms

• The system will

detect the pedestrian

in 1 second.

• The system will

detect the vehicle in 1

second.

• The function issues

the warning correctly.

• Detection of

pedestrian.

• Detection of vehicle

(non-equipped)

• Warning issued.

Step 2.1

Step 2.4

10 Hz <2-3%

false

alarms

<2-3%

false

negative

RSB, C-

ITS-S,

server app

Accuracy of

vehicle

positioning

Distance from the zebra

crossing is accurate.

Vehicle position (mean

and std)

Step 2 10 Hz < 5 m RSB, C-

ITS-S,

server app

Correctness/

Accuracy/

Reliability of

• The driver has enough

time to react.

• Time to collision @

warning (mean and

std)

Step 3 10 Hz • >3s

• >3s

• 3<1.5s

C-ITS-S,

server

app,

3 Reaction time depends a lot on driver profile. This is an average value.


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

warnings (in

terms of content

and time)

• Manoeuver time

• Reaction time (sec)

• Deceleration (mean

and std)

• 1m/s2

mobile

terminal

Performance

enhancement (for

existing apps

working with

alternative

systems)

N/A N/A N/A N/A N/A N/A

Automotive

Safety Integrity

Level (ASIL)4

System is ASIL B ASIL levels. All Continuous

(aggregated

derived

measure)

At least

ASIL B.

RSB,

OBU, C-

ITS-S,

server

app, test

conductor

event













Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

diary

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

• The driver is expected

to decelerate as soon

as the warning is

dispatched as long as

the warning is active.

• Expected deceleration

has to be compatible

with comfort values.

• Deceleration (mean,

std) during warning

period.

• Reaction time@

warning.

Steps 3 and

4

10Hz <1m/s2

<1.2 s

Mobile

terminal,

C-ITS-S,

server app

6.1.2 ES1.2: Wrong Way Driving of Mobile Cooperative safety function

Table 38: ES1.2 - research questions addressed, KPI’s, hypotheses & metrics.

Research

Questions


tested Measures Relevant steps

of scenario Frequency

of logging Success

target for

3rd round

ITS

Stations

that will be

logged

RQ1: Does the

system function

as expected under

realistic

conditions

(according to

False/missed/delayed

alarms

• The system will

detect the wrong

way driving vehicle

in 1 second.

• The system will

detect the vehicle in

1 second.

• Detection of wrong

way driving

vehicle.

• Detection of

vehicle (non-

equipped)

• Warning issued

Step 2.1

Step 2.4

10 Hz <2-3%

false

alarms

<2-3%

false

negative

RSB, C-

ITS-S,

server app


Research

Questions




of logging Success

target for

3rd round

ITS

Stations

that will be

logged

specs but also

according to user

perception)?


the warning

correctly.

Accuracy of vehicle

positioning

Distance from the

gas station exit.

Vehicle position

(mean and std)


ITS-S,

server app

Correctness/

Accuracy/ Reliability

of warnings (in terms

of content and time)

• The driver has

enough time to react.

• Time to collision

@ warning (mean

and std)

• Manoeuver time

• Reaction time


and std).

Step 3 10 Hz • >3s

• >3s

• <1.5s

• 1m/s2

C-ITS-S,

server app,

mobile

terminal

Performance

enhancement (for

existing apps

working with



improved

(higher).

• Reaction time @

warning

improved.

Time to collision Step 3,4 10 Hz >3s

<1.2s

RSB, C-

ITS-S,

server app,

Mobile

terminal

Automotive Safety

Integrity Level

(ASIL)


(aggregated

derived

measure)

At least

ASIL B.

RSB, C-

ITS-S,

Server app,

test,

conductor

event diary


Research

Questions




of logging Success

target for

3rd round

ITS

Stations

that will be

logged

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

• The driver is

expected to

decelerate as soon as

the warning is


the warning is

active.

• Expected

deceleration has to

be compatible with

comfort values.

• Deceleration

(mean, std) during

warning period,

• Reaction time@

warning

Steps 3 and 4 10Hz <1m/s2

< 1.2 s

HMI On-

board,

server app

6.1.3 ES2.1: VRU protection of In-vehicle Cooperative safety function


Research

Questions


tested Measures Relevant

steps of

scenario

Frequency of

logging Success

target for

3rd round

ITS

Stations

that will be

logged

RQ1: Does the

system function

as expected under

realistic

conditions

(according to


alarms

• The system will


in 0.2 second.

• The system will


0.2 second.

• Detection of

pedestrian.

• Detection of

vehicle (non-

equipped)

• Warning issued

Step 2.1

Step 2.4

10 Hz <2-3%

false

alarms

<2-3%

false

negative

RSB, server

app, on-

board


Research

Questions



steps of

scenario

Frequency of

logging Success

target for

3rd round

ITS

Stations

that will be

logged

specs but also

according to user

perception)?


the warning

correctly.

Accuracy of vehicle

positioning

Distance from the

zebra crossing is

accurate.

Vehicle position

(mean and std)

Step 2 10 Hz < 5 m RSB, on-

board app

Correctness/




• The driver has



@ warning (mean

and std)

• Manoeuver time

• Reaction time

• Deceleration

(mean and std)

Step 3 10 Hz • >3s

• >3s

• <1.5s

• 1m/s2

on-board

app

Performance

enhancement (for

existing apps

working with



Automotive Safety

Integrity Level

(ASIL)5


(aggregated

derived

At least

ASIL B.

RSB,

OBU,

Server app,









Research

Questions



steps of

scenario

Frequency of

logging Success

target for

3rd round

ITS

Stations

that will be

logged

measure) test

conductor

event diary

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

• The driver is

expected to


the warning is


the warning is

active.

• Expected

deceleration has to

be compatible with

comfort values.

• Deceleration

(mean, std)

during warning

period.

• Reaction time@

warning.


< 1.2 s

On-board






6.1.4 ES2.2: Wrong Way Driving of In-vehicle Cooperative safety function


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

RQ1: Does the

system function

as expected under

realistic

conditions

(according to

specs but also

according to user

perception)?


alarms

• The system will

detect the wrong

way driving

vehicle in 0.2s.

• The system will

detect the vehicle

in 0.2s.

• The function issue

the warning

correctly.

• Detection of wrong

way driving vehicle.


(non-equipped)

• Warning issued

Step 2.1

Step 2.4

10 Hz <2-3%

false

alarms

<2-3%

false

negative

RSB,

server app,

on-board

Accuracy of vehicle

positioning

Distance from the

gas station exit.

Vehicle position

(mean and std)

Step 2 10 Hz < 5 m RSB, on

board app

Correctness/




• The driver has

enough time to

react.


warning (mean and

std)

• Manoeuver time

• reaction time


and std)

Step 3 10 Hz • >3s

• >3s

• <1.5s

• 1m/s2

on-board

Performance

enhancement (for • Time to collision

improved


<1.2s

RSB, on

board app


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

existing apps

working with


(higher).

• Reaction time @

warning

improved.

Automotive Safety

Integrity Level

(ASIL)


(aggregated

derived

measure)

At least

ASIL B.

RSB, on-

board app,

test

conductor

event diary

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

• The driver is

expected to

decelerate as soon

as the warning is

dispatched as long

as the warning is

active.

• Expected

deceleration has to

be compatible with

comfort values.


std) during warning

period.

• Reaction time@

warning.

Steps 3

and 4

10Hz <1m/s2

< 1.2 s

On-board


6.1.5 ES3: Road wear level and predictive road maintenance

Table 41: ES3 - research questions addressed, KPI’s, hypotheses & metrics.

Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency of

logging

Success

target for

3rd round

ITS

Stations

that will

be logged

RQ1: Does the

system function

as expected under

realistic

conditions

(according to

specs but also

according to user

perception)?


alarms

The system will

provide strain output.

Measurement

pavement

deformation.

1-3 Continuous –

5 per day

50%

survivability

rate. Similar

systems

with sensors

embedded

inside road

pavement

have shown

survivability

rate less

than 25%.

Data

logger in

RSB unit,

C-ITS-S

and server

app.

Accuracy of vehicle

positioning


Correctness/


of warnings (in

terms of content and

time)

Accurate strain input Accuracy of

60-80% for

IRI condition.

4 Continuous –

5 per day

0-500 with

measured

values (+/-

100με)

Data

logger in

RSB unit,

C-ITS-S

and server

app.

Performance N/A N/A N/A N/A N/A N/A


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency of

logging

Success

target for

3rd round

ITS

Stations

that will

be logged

enhancement (for

existing apps

working with


Automotive Safety

Integrity Level

(ASIL)


RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour


6.1.6 ES4.1: Work zone detection of In-vehicle application for rail crossing and road works safety function


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

RQ1: Does the

system function

as expected under

realistic

conditions


alarms

• The system will


0.2s.


the warning


(non-equipped)

• Warning issued.

Step 2.4 10 Hz <2-3%

false

alarms

<2-3%

false

RSB,

server app,

on-board


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

(according to

specs but also

according to user

perception)?

correctly. negative

Accuracy of vehicle

positioning

Distance from the

work zone.

Vehicle position

(mean and std).

Step 2 10 Hz < 5 m RSB,

server app,

on-board

Correctness/




The driver has enough

time to react.


warning (mean and

std)

• Manoeuver time

• reaction time


and std)

Step 3 10 Hz • >3s

• >3s

• <1.5s

• 1m/s2

on-board

Performance

enhancement (for

existing apps

working with



improved (higher).

• Reaction time @

warning improved.


<1.2s

RSB, on

board app

Automotive Safety

Integrity Level

(ASIL)


(aggregated

derived

measure)

At least

ASIL B.

RSB, on-

board app,

test

conductor

event diary

RQ3: What are

the impacts on

safety and

Driving

performance/

behaviour

• The driver is

expected to



std) during warning

period,

Steps 3

and 4

10Hz <1m/s2

< 1.2 s

On-board


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

mobility? the warning is

dispatched as long

as the warning is

active.

• Expected

deceleration has to

be compatible with

comfort values.

• Reaction time@

warning

6.1.7 ES4.2: Railway crossing detection of In-vehicle application for rail crossing and road works safety function


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target for

3rd round

ITS

Stations

that will

be logged

RQ1: Does the

system function

as expected

under realistic

conditions

(according to

specs but also

according to user


alarms

• The system will

detect the

approaching train in

1.

• The system will


0.2s.


• Detection of

approaching

train vehicle.

• Detection of

vehicle (non-

equipped).

• Warning issued.

Step 2.1

Step 2.4

10 Hz <2-3%

false

alarms

<2-3%

false

negative

RSB,

server app,

on-board


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target for

3rd round

ITS

Stations

that will

be logged

perception)? the warning correctly.

Accuracy of vehicle

positioning

Distance from the

railway crossing.

Vehicle position

(mean and std)

Step 2 10 Hz < 5 m RSB,

server app,

on-board

Correctness/


of warnings (in


time)

• The driver has

enough time to react

• Time to

collision @

warning (mean

and std)

• Manoeuver

time

• Reaction time

• Deceleration

(mean and std)

Step 3 10 Hz • >3s

• >3s

• <1.5s

• 1m/s2

on-board

Performance

enhancement (for

existing apps

working with



Automotive Safety

Integrity Level

(ASIL)


(aggregated

derived

measure)

At least

ASIL B.

RSB, on-

board app,

test

conductor

event diary


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target for

3rd round

ITS

Stations

that will

be logged

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour



as the warning is






• Deceleration

(mean, std)

during warning

period,

• Reaction time@

warning.

Steps 3 and

4

10Hz <1m/s2

< 1.2 s

On-board

6.1.8 ES5.1: Work zone detection of Mobile application for rail crossing and road works safety function


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

RQ1: Does the

system function

as expected under

realistic

conditions

(according to

specs but also


alarms

• The system will


1s.

• The function issueS

the warning

correctly.

• Detection of

approaching work

zone.


(non-equipped)

• Warning issued.

Step 2.4 10 Hz <2-3%

false

alarms

<2-3%

false

negative

RSB, C-

ITS-S,

server app,

mobile

terminal

Accuracy of vehicle Distance from the Vehicle position Step 2 10 Hz < 5 m RSB, C-


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

according to user

perception)?

positioning work zone. (mean and std). ITS-S,

server app,

mobile

terminal

Correctness/




• The driver has

enough time to

react.


warning (mean and

std)

• Manoeuver time

• Reaction time


and std)

Step 3 10 Hz • >3s

• >3s

• <1.5s

• 1m/s2

C-ITS-S,

server app,

mobile

terminal

Performance

enhancement (for

existing apps

working with



Automotive Safety

Integrity Level

(ASIL)


(aggregated

derived

measure)

At least

ASIL B.

RSB, C-

ITS-S,

Server app,

test,

conductor

event diary


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

• The driver is

expected to


the warning is

dispatched as long

as the warning is

active.

• Expected

deceleration has to

be compatible with

comfort values.


std) during warning

period,

• Reaction time@

warning

Steps 3

and 4

10Hz <1m/s2

< 1.2 s

Mobile

terminal,

C-ITS-S

Server app

6.1.9 ES5.2: Railway crossing detection of Mobile application for rail crossing and road works safety function


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target for

3rd round

ITS Stations

that will be

logged

RQ1: Does the

system function

as expected

under realistic

conditions

(according to


alarms

• The system will

detect the

approaching train

in 1s.

• The system will

• Detection of

approaching

train vehicle.

• Detection of

vehicle (non-

Step 2.1

Step 2.4

10 Hz <2-3%

false

alarms

<2-3%

false

negative

RSB, C-ITS-

S, server app,

mobile

terminal


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target for

3rd round

ITS Stations

that will be

logged

specs but also

according to user

perception)?

detect the vehicle

in 1s.

• The function

issues the

warning

correctly.

equipped)

• Warning issued

Accuracy of vehicle

positioning

Distance from the

railway crossing.

Vehicle position

(mean and std)

Step 2 10 Hz < 5 m RSB, C-ITS-

S, server app,

mobile

terminal

Correctness/


of warnings (in


time)

• The driver has

enough time to

react.

• Time to

collision @

warning (mean

and std)

• Manoeuver

time

• Reaction time

• Deceleration

(mean and std)

Step 3 10 Hz • >3s

• >3s

• <1.5s

• 1m/s2

C-ITS-S,

server app,

mobile

terminal

Performance

enhancement (for

existing apps

working with


• Time to

collision

improved

(higher).

• Reaction time

@ warning

improved


<1.2s

RSB, C-ITS-

S, server app,

mobile

terminal


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target for

3rd round

ITS Stations

that will be

logged

Automotive Safety

Integrity Level

(ASIL)


(aggregated

derived

measure)

At least

ASIL B.

RSB, C-ITS-

S, server app,

mobile

terminal, test

conductor

event diary

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

• The driver is

expected to

decelerate as

soon as the

warning is

dispatched as

long as the

warning is active.

• Expected

deceleration has

to be compatible

with comfort

values.

• Deceleration

(mean, std)

during warning

period,

• Reaction time@

warning


< 1.2 s

Mobile

terminal, C-

ITS-S

Server app


6.1.10 ES6.1: Urban intersection of In-vehicle application for merging and intersection support (e2Call)


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target for

3rd round

ITS Stations

that will be

logged

RQ1: Does the

system function

as expected

under realistic

conditions

(according to

specs but also

according to user

perception)?

False/missed/dela

yed alarms

• The system will

detect the

approaching vehicle

in 0.2s.

• The system will


0.2s.



• Detection of

approaching

vehicle.

• Detection of

vehicle

(non-

equipped).

• Warning

issued.

Step 2.1

Step 2.4

10 Hz <2-3%

false

alarms

<2-3%

false

negative

RSB, On-board

Accuracy of

vehicle

positioning

Distance from the

center of intersection.

Vehicle

position

(mean and

std)

Step 2 10 Hz < 5 m RSB, On-board

Correctness/

Accuracy/

Reliability of

warnings (in

terms of content

and time)

• The driver has


• Time to

collision @

warning

(mean and

std)

• Manoeuver

time

• reaction

time

Step 3 10 Hz • >3s

• >3s

• <1.5s

• 1m/s2

On-board


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target for

3rd round

ITS Stations

that will be

logged

• Deceleration

(mean and

std)

Performance

enhancement

(for existing apps

working with

alternative

systems)


improved (higher).

• Reaction time @

warning improved.

Time to

collision

Step 3,4 10 Hz >3s

<1.2s

On-board

Automotive

Safety Integrity

Level (ASIL)


(aggregated

derived

measure)

At least

ASIL B.

RSB, on-board

app, test

conductor event

diary

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

• The driver is

expected to


the warning is



• Expected

deceleration has to be

compatible with

comfort values.

• Deceleration

(mean, std)

during

warning

period,

• Reaction

time@

warning


< 1.2 s

On-board


6.1.11 ES6.2: Intersection with wet/dry road condition of In-vehicle application for merging and intersection support (e2Call)


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

RQ1: Does the

system function

as expected under

realistic

conditions

(according to

specs but also

according to user

perception)?


alarms

• The system will

detect the

approaching

vehicle in 0.2s.

• The system will

detect the vehicle

in 0.2s.

• The system detects

the friction

coefficient.


the warning

correctly.

• Detection of

approaching

vehicle.

• Detection of

vehicle (non-

equipped)

• Warning issued

Step 2.1

Step 2.4

10 Hz <2-3%

false

alarms

<2-3%

false

negative

RSB, On-

board

Accuracy of vehicle

positioning

Distance from the

center of

intersection.

Vehicle position

(mean and std)

Step 2 10 Hz < 5 m RSB, On-

board

Correctness/




• Friction coefficient

is accurate.

• The driver has

enough time to

react.

• Friction

coefficient Time

to collision @

warning (mean

and std)

Step 2

Step 3

1Hz (for

friction) &

10 Hz (for

the rest)

• +/-0.2

(for

friction

)

• >3s

On-board


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

• Manoeuver time

• Reaction time

• Deceleration

(mean and std)

• >3s

• <1.5s

• 1m/s2

Performance

enhancement (for

existing apps

working with



improved

(higher).

• Reaction time @

warning

improved.


<1.2s

On-board

Automotive Safety

Integrity Level

(ASIL)


(aggregated

derived

measure)

At least

ASIL B.

RSB, on-

board app,

test

conductor

event diary

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

• The driver is

expected to

decelerate as soon

as the warning is

dispatched as long

as the warning is

active.

• Expected

deceleration has to

be compatible with

• Deceleration

(mean, std)

during warning

period.

• Reaction time@

warning.


< 1.2 s

On-board


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

comfort values.

6.1.12 ES6.3: Motorway exit of In-vehicle application for merging and intersection support (e2Call)


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target for 3rd

round

ITS

Stations

that will

be logged

RQ1: Does the

system function

as expected

under realistic

conditions

(according to

specs but also

according to

user

perception)?


alarms

• The system will

detect the

stopped vehicle

in 0.2s.

• The system will

detect the

vehicle in 0.2s.

• The function

issues the

warning

correctly.

• Detection of stopped

vehicle.


(non-equipped).

• Warning issued.

Step 2.1

Step 2.4

10 Hz <2-3% false

alarms

<2-3% false

negative

RSB, On-

board

Accuracy of vehicle Distance from the Vehicle position Step 2 10 Hz < 5 m RSB, On-


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target for 3rd

round

ITS

Stations

that will

be logged

positioning stopped vehicle. (mean and std) board

Correctness/

Accuracy/

Reliability of

warnings (in terms


• The driver has

enough time to

react


warning (mean and

std)

• Manoeuver time

• reaction time


and std)

Step 3 10 Hz • >3s

• >3s

• <1.5s

• 1m/s2

On-board

Performance

enhancement (for

existing apps

working with



Automotive Safety

Integrity Level

(ASIL)


(aggregated

derived

measure)

At least

ASIL B.

RSB, on-

board

app, test

conductor

event

diary

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

• The driver is

expected to

decelerate as

soon as the

warning is

dispatched as


std) during warning

period.

• Reaction time@

warning.

Steps 3 and

4

10Hz <1m/s2

< 1.2 s

On-board


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target for 3rd

round

ITS

Stations

that will

be logged

long as the

warning is

active.

• Expected

deceleration has

to be compatible

with comfort

values.

6.1.13 ES7.1: Urban intersection of Mobile application for merging and intersection support


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

RQ1: Does the

system function

as expected

under realistic

conditions

(according to

specs but also

according to user


alarms

• The system will

detect the

approaching vehicle

in 1s.

• The system will


1s.


• Detection of

approaching vehicle.


(non-equipped)

• Warning issued

Step 2.1

Step 2.4

10 Hz <2-3%

false

alarms

<2-3%

false

negative

RSB, C-

ITS-S,

server app,

mobile

terminal


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

perception)? the warning

correctly.

Accuracy of vehicle

positioning

Distance from the

center of intersection.


and std)


ITS-S,

server app,

mobile

terminal

Correctness/

Accuracy/

Reliability of

warnings (in terms


• The driver has

enough time to

react.


warning (mean and

std)

• Manoeuver time

• reaction time


and std)

Step 3 10 Hz • >3s

• >3s

• <1.5s

• 1m/s2

C-ITS-S,

server app,

mobile

terminal

Performance

enhancement (for

existing apps

working with



improved

(higher).

• Reaction time @

warning

improved.


<1.2s

server app,

mobile

terminal

Automotive Safety

Integrity Level

(ASIL)


(aggregated

derived

measure)

At least

ASIL B.

RSB, C-

ITS-S,

Server

app, test,

conductor


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

event

diary

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

• The driver is

expected to

decelerate as soon

as the warning is

dispatched as long

as the warning is

active.

• Expected

deceleration has to

be compatible with

comfort values.


std) during warning

period.

• Reaction time@

warning.

Steps 3

and 4

10Hz <1m/s2

< 1.2 s

Mobile

terminal,

C-ITS-S

Server app

6.1.14 ES7.2: Intersection with wet/dry road condition of Mobile application for merging and intersection support (e2Call)


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

RQ1: Does the

system function

as expected under


alarms

• The system will

detect the

approaching vehicle

• Detection of

approaching

vehicle.

Step 2.1

Step 2.4

10 Hz <2-3%

false

alarms

RSB, C-

ITS-S,

server app,


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

realistic

conditions

(according to

specs but also

according to user

perception)?

in 1s.

• The system will


1s.

• The system detects

the friction

coefficient


the warning

correctly.


(non-equipped)

• Warning issued

<2-3%

false

negative

mobile

terminal

Accuracy of vehicle

positioning

Distance from the

center of intersection

Vehicle position

(mean and std)


ITS-S,

server app,

mobile

terminal

Correctness/


of warnings (in


time)


is accurate.

• The driver has

enough time to

react.


Time to collision @

warning (mean and

std)

• Manoeuver time

• Reaction time


and std)

Step 2

Step 3

1Hz (for

friction) &

10 Hz (for

the rest)

• +/-0.2

(for

friction

)

• >3s

• >3s

• <1.5s

• 1m/s2

C-ITS-S,

server app,

mobile

terminal

Performance • Time to collision Time to collision Step 3,4 10 Hz >3s server app,


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

enhancement (for

existing apps

working with


improved (higher).

• Reaction time @

warning

improved.

<1.2s mobile

terminal

Automotive Safety

Integrity Level

(ASIL)


(aggregated

derived

measure)

At least

ASIL B.

RSB, C-

ITS-S,

Server app,

test,

conductor

event diary

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

• The driver is

expected to

decelerate as soon

as the warning is

dispatched as long

as the warning is

active.

• Expected

deceleration has to

be compatible with

comfort values.


std) during warning

period

• Reaction time@

warning.

Steps 3

and 4

10Hz <1m/s2

< 1.2 s

Mobile

terminal,

C-ITS-S

Server app


6.1.15 ES7.3: Motorway exit of Mobile application for merging and intersection support (e2Call)


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

RQ1: Does the

system function

as expected

under realistic

conditions

(according to

specs but also

according to user

perception)?

False/missed/dela

yed alarms

• The system will

detect the stopped

vehicle in 1s.

• The system will


1s.



• Detection of stopped

vehicle.


(non-equipped)

• Warning issued.

Step 2.1

Step 2.4

10 Hz <2-3%

false

alarms

<2-3%

false

negative

RSB, C-

ITS-S,

server app,

mobile

terminal

Accuracy of

vehicle

positioning

Distance from the

stopped vehicle.


and std)


ITS-S,

server app,

mobile

terminal

Correctness/

Accuracy/

Reliability of

warnings (in

terms of content

and time)

• The driver has enough

time to react.


warning (mean and

std)

• Manoeuver time

• Reaction time


and std)

Step 3 10 Hz • >3s

• >3s

• <1.5s

• 1m/s2

C-ITS-S,

server app,

mobile

terminal



Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

enhancement (for

existing apps

working with

alternative

systems)

Automotive

Safety Integrity

Level (ASIL)


(aggregated

derived

measure)

At least

ASIL B.

RSB, C-

ITS-S,

Server

app, test,

conductor

event

diary

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour



as the warning is







std) during warning

period,

• Reaction time@

warning.

Steps 3 and

4

10Hz <1m/s2

< 1.2 s

Mobile

terminal,

C-ITS-S

Server app


6.1.16 ES8.1 & ES9.1: Virtual VMS 1 – Critical case of In-vehicle/Mobile application for personalised VMS/VDS and Traffic Centre

Information


Research

Questions


tested

Measures Relevant steps

of scenario (of

in-vehicle;

rationally for

mobile)

Frequency

of logging

Success

target for

3rd round

ITS logging

mechanism

s

RQ1: Does the

system function

as expected

under realistic

conditions

(according to

specs but also

according to user

perception)?

False/missed/dela

yed alarms

1. The strip

continuously

detects vehicles

and measures their

speed.

2. Heavy traffic

detected and a

warring message

is authorized to be

sent to the driver.

3. The driver is

informed of the

incident ahead,

before s/he

actually notices by

himself.

1. Traffic

classification

accuracy

(vehicle

density

measured)

2. Time interval

between

heavy traffic

detection until

driver

warning in

sec.

3. Time interval

between the

moment that

the system

warns the

driver and the

moment the

1. Step 2

2. Steps: 2.1

up to 2.6

3. Steps: 3

and 4

All event

driven

1. N/A

for 3rd

round

2. Less

than 1

min.

3. N/A

for 3rd

round

1. RSB, C-

ITS-S

applicati

on

2. RSB, C-

ITS-S

applicati

ons,

OBU/m

obile

app

3. OBU/m

obile

app


Research

Questions


tested


of scenario (of

in-vehicle;

rationally for

mobile)

Frequency

of logging

Success

target for

3rd round

ITS logging

mechanism

s

driver needs

to take action

in sec.

Accuracy of

vehicle

positioning

Covered by the above.

Correctness/

Accuracy/

Reliability of

warnings (in

terms of content

and time)


Performance

enhancement

(for existing apps

working with

alternative

systems)


Automotive

Safety Integrity

Level (ASIL)



Research

Questions


tested


of scenario (of

in-vehicle;

rationally for

mobile)

Frequency

of logging

Success

target for

3rd round

ITS logging

mechanism

s

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

The driver

decelerates, changes

lane or takes next exit.

Deceleration, lane

changes, next exit

taken.

Steps: 4 and 5 Event

driven

Driver

reacts in

one of the

anticipated

ways.

RSB, C-

ITS-S

applications,

OBU/mobil

e app

6.1.17 ES8.2 & ES9.2: Virtual VMS 2 – Critical case of In-vehicle/Mobile application for personalised VMS/VDS and Traffic Centre

Information


Research

Questions


tested

Measures Relevant

steps of

scenario (of

in-vehicle;

rationally

for mobile)

Frequency

of logging

Success

target for

3rd round

ITS logging

mechanism

s

RQ1: Does the

system function

as expected under

realistic

conditions

(according to

specs but also

False/missed/de

layed alarms

1. There is fuel/oil on

road surface and the

strip detects it.

2. Fuel/oil detected

and a warning

message is

authorized to be

1. Existence of

fuel/oil.

2. Time interval

between

fuel/oil

detection until

driver warning

1. Step 2

2. Steps:

2.1 up

to 2.7

3. Steps: 3

and 4

1. Upon

detectio

n and

every 10

seconds

2. Event

driven

1. 2-3%

false

alarms

2. Less

than 1

min.

3. <1,5

1. RSB

2. RSB, C-

ITS-S

applicati

ons,

OBU/mo

bile app


Research

Questions


tested

Measures Relevant

steps of

scenario (of

in-vehicle;

rationally

for mobile)

Frequency

of logging

Success

target for

3rd round

ITS logging

mechanism

s

according to user

perception)?

sent to the driver.

3. The driver is

informed of the

incident ahead,

before s/he actually

notices by himself.

(in sec.).

3. Time interval

between the

moment that

the system

warns the

driver and the

moment the

driver needs to

take action (in

sec.).

3. Event

driven

sec.

3. OBU/mo

bile app

Accuracy of

vehicle

positioning


Correctness/

Accuracy/

Reliability of

warnings (in

terms of

content and

time)


Performance

enhancement



Research

Questions


tested

Measures Relevant

steps of

scenario (of

in-vehicle;

rationally

for mobile)

Frequency

of logging

Success

target for

3rd round

ITS logging

mechanism

s

(for existing

apps working

with alternative

systems)

Automotive

Safety Integrity

Level (ASIL)

The highest ASIL is

achieved.

ASIL levels. All Continuous

(aggregated

derived

measure)

At least

ASIL B.

RSB,

OBU/mobile

app, test

conductor

event diary

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

The driver decelerates,

or changes lane.

Decelaration/lane

changes

Steps: 4 and

5

Event

driven

Driver

reacts in

one of the

anticipated

ways.

RSB, C-

ITS-S

applications,

OBU/mobile

app


6.1.18 ES8.3 & ES9.3: Virtual VMS 2 – Non- Critical case of In-vehicle/Mobile application for personalised VMS/VDS and Traffic

Centre Information


Research

Questions


tested

Measures Relevant steps of

scenario (of in-

vehicle; rationally

for mobile)

Frequenc

y of

logging

Success

target for

3rd round

ITS logging

mechanisms

RQ1: Does

the system

function as

expected

under

realistic

conditions

(according to

specs but

also

according to

user

perception)?

False/missed/delay

ed alarms

1. The system

detects low

luminosity due to

sunset or heavy

clouds.

2. Driver receives

the

notification/advic

e to turn on the

headlights.

1. Ambient

light in

lumens

2. Notificatio

n/warning

reception

1. Step 2

2. Steps 2 and 3

1. Every

60

second

s

2. Event

driven

1. 0% false

alarms

2. 0%

message

loss

1. RSB

2. RSB, C-

ITS-S

application

s, vehicle

OBU

Accuracy of

vehicle positioning

Covered by the

above.

Correctness/

Accuracy/

Reliability of

warnings (in

terms of content

and time)

Covered by the

above.


Research

Questions


tested

Measures Relevant steps of

scenario (of in-

vehicle; rationally

for mobile)

Frequenc

y of

logging

Success

target for

3rd round

ITS logging

mechanisms

Performance

enhancement (for

existing apps

working with

alternative

systems)


Automotive Safety

Integrity Level

(ASIL)


RQ3: What

are the

impacts on

safety and

mobility?

Driving

performance/

behaviour

The driver turns the

lights on.

Headlights

switched on.

Steps 4 and 5 Event

driven

Driver

reacts in the

anticipated

ways.

OBU / Event

diary

6.1.19 ES10.1 – ES10.4: Autonomous vehicles support functions

The following are valid for all automated functions and are subject to revision upon the outcomes of the 3rd technical validation round.


Table 55: ES10.1 – ES10.4 - research questions addressed, KPI’s, hypotheses & metrics.

Research

Questions

KPI’s Hypotheses to

be tested


of scenario

Frequency of

logging

Success target

for 3rd round

ITS logging

mechanisms

RQ1: Does the

system function

as expected

under realistic

conditions

(according to

specs but also

according to

user

perception)?

False/missed/d

elayed alarms

1. Correct

positioning

in lane,

lanes

geometry,

toll gate

existence

and

positioning.

2. Infrastructu

re update is

automaticall

y received

by the

vehicle.

1. See below.

2. Msec.

1. See below

2. Step 3 of

scenarios

1. See below.

2. 200msec.

1. Not more

than 2%

errors.

2. Not more

than 200

msec delay

(subject to

revision).

RSB, OBU

Accuracy of

vehicle

positioning

Covered by the

following.

Correctness/

Accuracy/

Reliability of

warnings (in

terms of

content and

time)

The highest

possible

accuracy in

terms of vehicle

positioning in

lane, lanes

updated, toll

1. Position in

lane

2. Lane

marking

3. Toll gate

existence &

positioning

Step 2 of the

scenarios.

1. 200msec

2. 200msec

3. 1 min

4. 1 min

5. 2.5sec

0.3m lateral

(for position) &

0.1m lateral

(for lane

marking)

RSB, OBU


Research

Questions

KPI’s Hypotheses to

be tested


of scenario

Frequency of

logging

Success target

for 3rd round

ITS logging

mechanisms

gate existence

and positioning.

4. Number of

lanes

5. Lane the

(ego)

vehicle is

running

Performance

enhancement

(for existing

apps working

with

alternative

systems)

As above. As above. - - Improvement

by at least 20%

vs. current

perception

systems.

-

Automotive

Safety

Integrity Level

(ASIL)

The highest

ASIL is

achieved.

ASIL levels. All Continuous

(aggregated

derived

measure)

At least ASIL

B.

RSB, OBU, test

conductor event

diary

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

The scope of

the individual

automated

function is

achieved with

the driver not

required to take

back control

from the

system.

Number of

taking back

controls from

the driver.

Last step of

each scenario.

Continuous 0 times

requiring from

the driver to

take back

control during

any scenario.

RSB, OBU, test

conductor event

diary


6.1.20 ES11: Virtual Toll Collection of Mobile application for Virtual Toll Collection


Research

Questions

KPI’s Hypotheses to be tested Measures Relevant steps

of scenario

Frequ

ency

of

loggin

g

Success

target for 3rd

round

ITS logging

mechanisms

RQ1: Does the

system

function as

expected under

realistic

conditions

(according to

specs but also

according to

user

perception)?

False/missed/

delayed

alarms

1. The system will

always detect and

identify the vehicle.

2. The charging

process works

without incidents for

the specific vehicle as

expected (the

anticipated amount).

1. Detection &

identificatio

n of vehicle.

2. All the steps

of the

charging

protocol are

completed.

1. Steps 4 &

7

2. (mainly)

steps 6-11

2-10

Hz

1% false

detection/ident

ification.

RSB, C-ITS-S,

RELAB server,

mobile terminal

Accuracy of

vehicle

positioning


Correctness/

Accuracy/

Reliability of

warnings (in

terms of

content and

time)

Covered by 1st KPI in

this case.


Research

Questions

KPI’s Hypotheses to be tested Measures Relevant steps

of scenario

Frequ

ency

of

loggin

g

Success

target for 3rd

round

ITS logging

mechanisms

Performance

enhancement

(for existing

apps working

with

alternative

systems)


Automotive

Safety

Integrity

Level (ASIL)


RQ3: What

are the impacts

on safety and

mobility?

Driving

performance/

behaviour

Time to cross the

(virtual) toll gate.

Cross-over time Overall

process from

Step 3- Step

11.

2-10

Hz

Automatic

passage (not

more than 0,5

minutes for

the passage

anticipating

small

deceleration of

the vehicle)

RSB, C-ITS-S,

RELAB server

(charging process

completed is time-

stamped here

essentially),

mobile terminal

(confirmation of

charging

transaction

through

notification sent to

the driver)


6.1.21 ES12.1, ES12.2 and ES12.3 of Mobile application for parking booking and charging

The “steps” where the denoted measures are logged are indicated for ES12.1 and are rational for ES12.2 and ES12.3.


Research

Questions


tested

Measures Relevant

steps

Frequency

of logging

Success

target for 3rd

round

ITS logging

mechanisms

RQ1: Does the

system function

as expected

under realistic

conditions

(according to

specs but also

according to user

perception)?

False/missed/

delayed

alarms

1. The system

distinguishes the

occupied and the

free parking

spaces.

2. The information

is received

without delay in

the mobile

terminal.

3. The reservation

of the parking lot

is made properly.

4. The payment

process works

without

incidents.

1. Correct

identification of

parking spaces

status.

2. No delay in the

reception of the

free parking

lots

information.

3. The signal for

park reservation

is on.

4. All the steps of

the payment

protocol are

completed.

1. Steps 5,

14

2. Steps 5-

10

3. Steps 1-4

& 6-10

4. Steps 16-

19

Every 5-10

sec.

Less than 5%

errors in each

of the 3

measures.

Delay less

than 1second

in receiving

the updated

parking

information

in the mobile

terminal.

RSB, C-ITS-S,

parking

operator server,

mobile

terminal

Accuracy of

vehicle



Research

Questions


tested

Measures Relevant

steps

Frequency

of logging

Success

target for 3rd

round

ITS logging

mechanisms

positioning

Correctness/

Accuracy/

Reliability of

warnings (in

terms of

content and

time)

1. Detection of

parking space

position in lane

is accurate.

2. Detection of

parking space

lane marking

detection is

accurate.

1. Accuracy in

available

parking space

position in lane.

2. Accuracy in

available

parking space

lane marking.

Steps 5, 14

(for both)

1 sec. 0,5m RSB

Performance

enhancement

(for existing

apps

working with

alternative

systems)


Automotive

Safety

Integrity

Level (ASIL)


RQ3: What are

the impacts on

safety and

mobility?

Driving

performance

/ behaviour

The driver parks

his/her vehicle

following the system

recommendation

without spending

Parking of the

vehicle in the

denoted space

without deviations.

Step 11 1 second Successful

parking

management

in 99% of the

cases.

RSB, C-ITS-S,

Parking

operator server


Research

Questions


tested

Measures Relevant

steps

Frequency

of logging

Success

target for 3rd

round

ITS logging

mechanisms

more time for

parking exploration.

6.1.22 Cross Use Cases Evaluation Scenarios


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

RQ2: Does the

system function

as expected

under realistic

conditions when

more than one

SAFE STRIP

functions are

running

concurrently in

the user’s

terminal

(according to

specs but also

False/missed/dela

yed alarms

• The system will

detect the

approaching vehicle

in 0.2s.

• The system will


0.2s.

• The system will


at zebra crossing in

0.2s.



• Detection of

approaching

vehicle.

• Detection of

vehicle

• Detection of

pedestrian

• Warning issued

Step 2.1

Step 2.4

10 Hz <2-3%

false

alarms

<2-3%

false

negative

RSB, On-

board

Accuracy of Distance from the Vehicle position Step 2 10 Hz < 5 m RSB, On-


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

according to user

perception)?

vehicle

positioning

center of intersection. (mean and std) board

Correctness/

Accuracy/

Reliability of

warnings (in

terms of content

and time)

• The driver has



@ warning (mean

and std)

• Manoeuver time

• reaction time

• Deceleration

(mean and std)

• Correct warning is

issued

Step 3 10 Hz • >3s

• >3s

• <1.5s

• 1m/s2

On-board

Performance

enhancement (for

existing apps

working with

alternative

systems)


Automotive

Safety Integrity

Level (ASIL)


(aggregated

derived

measure)

At least

ASIL B.

RSB, on-

board app,

test

conductor

event diary


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target

for 3rd

round

ITS

Stations

that will

be logged

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour



as the warning is






• Deceleration

(mean, std) during

warning period,

• Reaction time@

warning.


< 1.2 s

On-board


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target for 3rd

round

ITS

Stations

that will

be

logged

RQ2: Does the

system function

as expected

under realistic

conditions

when more than

one SAFE

STRIP

functions are


alarms

• The system will

detect the

approaching

vehicle in 1s.

• The system will

detect the vehicle

in 1s.

• The system will

detect the

• Detection of

approaching

vehicle.

• Detection of

vehicle

• Detection of

pedestrian

• Warning issued

Step 2.1

Step 2.4

10 Hz <2-3% false

alarms

<2-3% false

negative

RSB, C-

ITS-S,

server

app,

mobile

terminal


Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target for 3rd

round

ITS

Stations

that will

be

logged

running

concurrently in

the user’s

terminal

(according to

specs but also

according to

user

perception)?

pedestrian at zebra

crossing in 1s.

• The function

issues the warning

correctly.

Accuracy of vehicle

positioning

Distance from the

center of

intersection

Vehicle position

(mean and std)


ITS-S,

server

app,

mobile

terminal

Correctness/

Accuracy/

Reliability of

warnings (in terms


• The driver has

enough time to

react.

• Time to

collision @

warning (mean

and std)

• Manoeuver

time

• reaction time

• Deceleration

(mean and std)

• Correct

warning is

issued

Step 3 10 Hz • >3s

• >3s

• <1.5s

• 1m/s2

C-ITS-S,

server

app,

mobile

terminal



Research

Questions


tested

Measures Relevant

steps of

scenario

Frequency

of logging

Success

target for 3rd

round

ITS

Stations

that will

be

logged

enhancement (for

existing apps

working with


Automotive Safety

Integrity Level

(ASIL)


(aggregated

derived

measure)

At least ASIL

B.

RSB, C-

ITS-S,

Server

app, test,

conductor

event

diary

RQ3: What are

the impacts on

safety and

mobility?

Driving

performance/

behaviour

• The driver is

expected to

decelerate as soon

as the warning is

dispatched as long

as the warning is

active.

• Expected

deceleration has to

be compatible with

comfort values.

• Deceleration

(mean, std)

during warning

period.

• Reaction

time@ warning.


< 1.2 s

Mobile

terminal,

C-ITS-S

Server

app


6.2 Self-reported metrics Self-reported measures/metrics are tackled in a common way. Mostly standardised scales have been selected to measure User Experience (UX)

dimensions and are applicable to all scenarios and respective services. Success targets are based on acceptable levels of UX success for services

and are presented in the following table (Table 60). The respective measuring tools are provided in Annex 3 of this document and are subject to

revision until the beginning of the 1st round of user trials.

Table 60: RQ, KPIs, hypotheses and subjective measures.

Research

Questions


tested

Measures Who (types of

users)

Success

target for

3rd round

Measuring tools

RQ1: Does the

system

function as

expected under

realistic

conditions

(according to

specs but also

according to

user

perception)?

Acceptance (this is

associated with the

system robust


perceived by the user;

encompassing

comprehensibility of

function, usefulness

and HMI usability)

User acceptance

will be at least

60%.

Usefulness/satisfa

ction scale (Van

der Laan et al.

1997) [22].

Drivers, riders,

infrastructure

operators (road,

parking operators,

etc.)

≥60% Standardised

Questionnaire

Trust User trust will be

at least 70%.

Perceived trust

based on the

empirical scale

created by Jian et

al. (2000) [12].

Drivers, riders,

infrastructure

operators

≥70% Empirical

questionnaire for

relationship

between user and

automated system;

however, as these

are new systems, it

applies well.

Workload Demand Driving Activity Drivers, riders ≤15% Standardised


Research

Questions


tested

Measures Who (types of

users)

Success

target for

3rd round

Measuring tools

(physical, visual,

mental) of the

system will be

maximum 15%.

Load Index

(DALI) [16] and

its adapted

version for riders.

Riding Activity

Load Index

(RALI) [17]

Questionnaire/Test

conductor

observation

Perceived value of

service

Perceived service

value will be at

least 60%

Question on

perceived value in

Standardized User

Experience

Percentile Rank

Questionnaire

(SUPR-Q) [20].

Drivers, riders,

infrastructure

operators

≥60% Question item

from standardized

questionnaire.


7 Experimental Design for 3rd round trials

7.1 Experimental study design This section focuses on the specific experimental study design for the 1st round of user

trials. The 1st round of user trials will be small scale Field Operational Trials

(FOTs) in controlled environment.

There will be a pre-pilot process that will take place upon the completion of technical

validation held in the 3rd validation round and the process that will be held in the

context of the pilots.

Pre - Pilot process:

Step 1: In the context of the final full technical validation round (3rd round), SAFE

STRIP Consortium will test among others the appropriateness of the evaluation

scenarios as described in 5.3 as well as the logging mechanisms that will be built (also

to accommodate the 3rd validation round) in order to capture the metrics determined

per scenario in section 6.. Throughout this process, it will be made evident in which

cases, if any, there will be required corrections/adjustments and changes. It will be

also determined if there are any metrics that cannot be logged via the built-in

mechanisms and will, thus, lead to the design of specific event diaries (although effort

will be made to avoid this tactic as it will disturb the smoothness of the user trials).

Finally, it will be made evident if the test infrastructure set-up or the SAFE STRIP

applications are adequate or if they require improvement in any aspect.

Step 2: Apart from above process and at least one month prior to the user trials

conduction, test sites conductors will be given a seminar by CERTH/HIT (issuer of

the evaluation plans and technical manager of the project) on how to run the

experimental process summarised below across all different aspects.

Step 3: Ethics sites authorised persons will pre - check compliance with the Ethics

Policy of the project. All consent forms and subjective measurements tools (annexed

in this document) will be updated, receive their final form and instantiated in each

local language for the users of the trials.

Step 4: Prior to the official process of the user trials, a full experimental round with

one user will be realised in order to ensure that everything is in place for the user

trials (i.e. pre-testing). This testing round will allow for timing the whole procedure

and for identifying any issues with the testing procedure and evaluation material.

The leaders for the test sites for the 3rd evaluation round are as follows:

• ATTD: Natalia Kalfa with support from HIT: Maria Gkemou

• CRF: Andrea Steccanella

Each leader, however, will appoint a team for the trials under his/her auspices.

On top of them, D9.1 and D9.2 report the persons authorised per test site to monitor

and control the ethics policy of the project.

The process that will be followed in each test site (and according to the specific plans

of each site as depicted in section 5.2) is as follows:


Pilot experimental process:

Step 1: All users (drivers, riders, infrastructure operators) will be explained by the

respective test conductor the aim and objectives of the project as well as the specific

objectives of the evaluation process. The project information sheet is current provided

as Annex of D9.2: “POPD - Requirement No.2”, but will be adjusted a while before

the kick-off of the user trials.

Step 2: All users will be asked to sign the consent form. Whoever does not wish to

participate to the user trials, s/he is free to withdraw without further commitment.

Step 3: All users will be introduced with the test area and the demonstrators (see

section 8) and they will be given time to familiarize with them.

Step 4: All users will be provided with the pre-test questionnaire to complete (Annex

3) and a Driver/Rider Behaviour Questionnaire (Annex 2) that will help classify them

in drivers’ clusters that will be later taken into consideration in the test outcomes

consolidation.

Step 5: In turn, users will run the Evaluation Scenarios (of section 5.3) that

correspond to them depending on which group they are classified (see below). They

will be given the guideline of section Error! Reference source not found.. One

representative from the test conductor entity will be present in the vehicle during the

running of the scenarios. Another representative, acting as overall supervisor of the

test, will be out of the vehicle to monitor the events triggering and the smooth

operation of the trials. During the trials, automatic system and driver behaviour

metrics logging will be performed in different ends of the system, as explained in

sections 6.1 and 8.3. In case there are metrics that cannot be automatically logged (for

any reason), the representative of the test conductor that will be present in the vehicle

will keep event diaries; still this is to be resolved in the next period. In the case of the

scenarios for the PTW’s, there will be no second rider on the motorcycle apart from

the ego rider. Whilst, in the case of the automated vehicles functions evaluation, there

will be always one driver in position of control and another two drivers that will be

passengers in addition to the test conductor representative. For the testing of the

mobile functions and specifically for the 1st round of user trials, the devices will be

provided by the test conductors with the mobile apps downloaded (and verified

beforehand) before they are provided to the users.

Step 6: Upon completion of all the scenarios that are anticipated for them, the users

will be asked to complete the post-test assessment form (see Annex 3) that will be

collected anonymously by the test conductors and the test will be concluded.

Step 7: Users will be debriefed and thanked for their participation. As they will be

employees, they are not reimbursed for their participation.

The plan for the 1st evaluation round with users is summarised in the following table.

The types of users indicated in the last column of the table are the actual type of users

that will be involved in the 1st round of user trials. In this round, the operators of

different types, such as the parking managers, etc. will be emulated though this is not

the case for the infrastructure operators that will be represented by the project

beneficiaries. Still, this is not the case for the 4th round, where actual actors will be

involved in the process.


Table 61: User trials plan for 1st evaluation round with user trials (3rd evaluation round

SAFE STRIP overall).

No SAFE STRIP

function

Evaluation Scenarios

(ES)

Test Site /

Conductor

Users

1. Mobile Cooperative

safety function

ES1.1: Virtual VRU

protection-ES1.1.1:

Pedestrian prompt to

cross the zebra crossing

CRF, ATTD Drivers, Riders

ES1.1: Virtual VRU

protection - ES1.1.2:

Pedestrian prompt to


with stopped vehicle


ES1.2: Wrong Way

Driving


2. In-vehicle

Cooperative safety

function

ES2.1: VRU protection

– ES2.1.1: Pedestrian

prompt to cross the

zebra crossing


ES2.2: VRU protection-

ES2.1.2: Pedestrian

prompt to cross the

zebra crossing with

stopped vehicle


ES2.2: Wrong Way

Driving


3. Road wear level and

predictive road

maintenance

ES3: Road wear level

and predictive road

maintenance

CRF, ATTD Infrastructure

operators

4. In-vehicle

application for rail

crossing and road

works safety

function

ES4.1: Work zone

detection


ES4.2: Railway

crossing detection

HIT

(Thessaloniki) Drivers, Riders,

“Railway

Operators”

5. Mobile application

for rail crossing and

road works safety

function

ES5.1: Work zone

detection


ES5.2: Railway

crossing detection

HIT

(Thessaloniki) Drivers, Riders,

“Railway

Operators”

6. In-vehicle

application for

merging and

intersection Support

(e2Call)

ES6.1: Urban

intersection

CRF Drivers, Riders

ES6.2: Intersection with

wet/dry road condition

CRF Drivers, Riders

ES6.3: Motorway exit CRF Drivers, Riders


for merging and

intersection Support

(e2Call)

ES7.1: Urban

intersection

CRF Drivers, Riders

ES7.2: Intersection with


CRF Drivers, Riders

ES7.3: Motorway exit CRF Drivers, Riders

8. In-vehicle

application for

personalised

VMS/VDS and

ES8.1: Virtual VMS 1 –

Critical case

CRF, ATTD Drivers, Riders,

TMC operators

of infrastructure

ES8.2: Virtual VMS 2 – CRF, ATTD Drivers, Riders,


No SAFE STRIP

function

Evaluation Scenarios

(ES)

Test Site /

Conductor

Users

Traffic Centre

Information

Critical case TMC operators

of infrastructure


Non- Critical case


TMC operators

of infrastructure


for personalised

VMS/VDS and

Traffic Centre

Information


Critical case


TMC operators

of infrastructure


Critical case


TMC operators

of infrastructure


Non- Critical case


TMC operators

of infrastructure

10. Autonomous

vehicles support

ES10.1: Dynamic

trajectory estimation for

automated vehicles /

ego lane trajectory

information

CRF Drivers

ES10.2: Definition of

lane-level virtual

corridors / multiple

carriage way

CRF Drivers

ES10.3: Tollgates

management

CRF Drivers

ES10.4: Work zones

detection

CRF Drivers

11. Application for

Virtual Toll

Collection

ES11: Virtual Toll

Collection


Infrastructure

operators

12. Application for

parking booking and

charging

ES12.1: Numbered

parking with payment

CRF, ATTD Drivers, Parking

managers

ES12.2: Free of charge

parking


managers

ES12.3: Regulated

parking (blue zone)


managers

13. Integrated in-vehicle

application

C-ES1: Urban

intersection with

pedestrian crossing

with equipped vehicles


14. Integrated mobile

application

C-ES2: Urban

intersection with

pedestrian crossing

with non-equipped

vehicles


The demonstrators that will participate in CRF 1st round of user trials will be:








The demonstrators that will participate in ATTD and HIT 1st round of user trials

will be:



The experimental design that will be applied in the 1st round of user trials will be

within-subjects design, as the number of users is very small. This means that all

drivers/riders that will try all scenarios (clustered to them) will run exactly the

scenarios with SAFE STRIP in-vehicle applications, the corresponding ones with

SAFE STRIP mobile applications, and, whenever it is applicable/existing, they will

also run the baseline scenario. This study is a 2x4 design with 2 independent variables

(technical performance and user performance) and 4 levels (baseline-if existing,

equipped, non-equipped and autonomous) for the two independent variables common

across testing all services. Type of vehicle (passenger car and PTW) are not common

across all evaluation scenarios and, hence, are not included as an overall independent

variable.

Users will be clustered in 6 experimental groups and 1 control group, as follows:

• Experimental Group 1: Drivers (10) of equipped passenger demonstrators

driving the scenarios corresponding to the following functions:

o In-vehicle Cooperative safety function

o In-vehicle application for rail crossing and road works safety function

o In-vehicle application for merging and intersection Support (e2Call)

o In-vehicle application for personalised VMS/VDS and Traffic Centre

Information

o Synthesised in-vehicle application

• Experimental Group 2: Drivers (same 106) of passenger vehicles using their

mobile terminal (smart phone) driving the scenarios corresponding to the

following functions:

o Mobile Cooperative safety function

o Mobile application for rail crossing and road works safety function

o Mobile application for merging and intersection Support (e2Call)

o Mobile application for personalised VMS/VDS and Traffic Centre

Information

o Application for Virtual Toll Collection

o Application for parking booking and charging

o Synthesised mobile application

• Experimental Group 3: Riders (10) of equipped PTW demonstrators driving

the scenarios corresponding to the following functions:

o In-vehicle Cooperative safety function

o In-vehicle application for rail crossing and road works safety function

o In-vehicle application for merging and intersection Support (e2Call)

6 “Same” here is meant in the way that the driver that will test the counter in-vehicle application will

also test the corresponding mobile application when existing. Still, it is not necessary that all the same

drivers will test all the pairs of the applications. As long as it is 10 drivers testing each pair, it suffices

for the experimental plan. The selection of the sample is dependent and as these will come from the

SAFE STRIP entities is dependent on internal decision of the entities.


o In-vehicle application for personalised VMS/VDS and Traffic Centre

Information

o Integrated in-vehicle application

• Experimental Group 4: Riders (same 10) of PTW’s driving the scenarios

corresponding to the following functions:

o Mobile Cooperative safety function

o Mobile application for rail crossing and road works safety function

o Mobile application for merging and intersection Support (e2Call)

o Mobile application for personalised VMS/VDS and Traffic Centre

Information

o Application for Virtual Toll Collection

o Integrated mobile application

• Experimental Group 5: Drivers (3, one in control by rotation) driving the

automated functions in the VALEO demonstrator (only in CRF test track):

o Autonomous vehicles support

• Experimental Group 6: Infrastructure operators (2 representatives per test

site) involved in the evaluation of scenarios corresponding to the following

functions (they will not be involved actively; will oversee the process and give

their feedback through the subjective measuring tools):

o Road wear level and predictive road maintenance

o In-vehicle and mobile application for personalised VMS/VDS and Traffic

Centre Information o Application for Virtual Toll Collection

• Control Group: Each driver testing the evaluation scenarios corresponding to

each function will run also the corresponding control scenarios whenever existing,

meaning whenever baseline does not originate from literature and traffic statistics

(which is the case for the most scenarios in SAFE STRIP though).

Each driver/rider will run each evaluation scenario (including the baseline whenever

existing) – according to the above clustering – in 3 iterations. This is the minimum

number of iterations that suffice for the collection of data that will enable statistical

analysis later which is also a compromise due to the big number of scenarios and

small relatively number of users. The events triggered in each evaluation scenario are

denoted in section 5.3 tables. An iteration is considered as the single run of the test

area as seen in section 8.2 as it will be implemented in the respective test site spots of

section 8.

Each step of the overall experimental process is translated in time below (on

participant level):

Step 1 & Step 2: Participant’s acquaintance with the project and the trials scope

and consent forms - This session will be common for all participants and can be

done on a separate day for all drivers, where no testing will be conducted. It will be

organized by the test site manager - (Day 1 – 1 hour).

Step 3 & Step 4: Participants’ familiarisation with the test area and the

demonstrator, pre-test & Driver/Rider behavior questionnaire completion - (Day

1 – 1,5 hours).

Step 5: User trials - (3 Days – 30 minutes the whole process per day max.

including all iterations)


1. Day 2: The participant will run the baseline scenarios (if existing) of the function

per day in 3 repetitions per each as a minimum.

2. Day 3: The participant will run the in-vehicle application (if existing) of the

function (again in 3 repetitions for each sub-scenario defined).

3. Day 4: The participant will run the mobile application (if existing) of the function

(again in 3 repetitions for each sub-scenario defined).

As mentioned above, it is not necessary that the same drivers/riders will test all pairs

(in-vehicle/mobile) of applications, as long as the overall target number is reached

and with the only prerequisite that those testing an application, will test all the

baseline, equipped and non-equipped version, whenever each of them exists, in order

to minimise as much as possible the effect of extraneous variables. If, for any

reasons, not the same drivers can participate in all conditions, then participants should

be matched to avoid threatening the applied within (repeated) measures’ design.

The Road wear level and predictive road maintenance function is not requiring drivers/riders

running specific scenarios. Summative data will be collected after the end of the trials (to

aggregate as many vehicle loads as possible) and the overall process will be evaluated by the

infrastructure operators’ representatives. Step 6 & Step 7: Completion of the post-test questionnaire completion and

conclusion - (Day 4 – 30 min. max.)

Thus, as a maximum, each participant will need 4 separate days of testing for each

function. This is the maximum, as some functions do not have counter-app for vehicle

or mobile and most of them have no baseline scenario as well. However, this does not

hinder the testing of more functions in Step 5 of the same or other driver on the same

day, as the actual duration of the testing is very small. Still, assuming that a “ride

round” is a complete round corresponding to Day 2, 3 or 4 above (meaning all

iterations of baseline, equipped or non-equipped scenarios), it is encouraged that the

same driver does not perform more than 2 ride rounds per day. It is also

recommended that the order of baseline – equipped – non/equipped is varying across

the sample but also for the same driver across different functions, to avoid making the

experience cumbersome, boring and tiring for the user. This happens for several

reasons; firstly, avoid drivers’ over-exposure and perceptual “numbing”. Keeping,

however, similar timelines across sites can harmonize the activities, data collection

and end-points of each scenario studied (i.e. especially true for common scenarios’

testing).

Overall, from the perspective of the test conductor, having to perform 3 ride rounds

(max) for 23 drivers/riders, each one lasting about 30 minutes, this equals to around

34,5 hours of testing in total for each test site. Assuming that each test day will

consist of not more than 6 hours of trials, this equals to around 6 days of trials which

turns to around 7 days in total in order to include the first day of introduction,

familiarisation, etc. If one takes into account delays due to adverse weather

conditions, unexpected failures to demonstrators/test infrastructure, or even the fact

that drivers would (and should not preferably) be present every single day in the row,

it would be safe to estimate around 2 or 3 weeks of testing overall (as anticipated in

the plan depicted in Figure 2 where in reality one month is reserved in the phase for

actual testing).


Participants will be matched across all functions, as not all users will test all

functions. Matching will be based at least on selecting potential individual based on

gender, age group, driving/riding experience (km driven per year and frequency on

weekly basis), literacy and driving/riding profile.

In addition, the order of trips, regardless of condition, will be counterbalanced to

avoid order effects and overfamiliarisation, and consequent desensitization of

participants. The latter holds true for drivers and not for road infrastructure operators.

PTW riders will be a separate road user group and users will complete the tests only

as riders and will not assume any other role.

Finally, dedicated weeks per function might be determined in order to ensure data

collection is smooth and experimenters have enough time to check data collection

level of quality and completeness.

The 1st round of trials is seen by the Consortium among other as a “rehearsal” for the

larger scale trials that will follow in the 2nd round. As such, the mobile applications

that will run in mobile terminals, ergonomically located on-board for safety reasons –

will be provided by the Consortium (which will not be the case for the 4th round most

probably).

Also, the demonstrators that will have been mentioned above are meant to be the

equipped demonstrators; still will be also used as non-equipped demonstrators in this

round (with V2X deactivated as the drivers/riders will be provided with the messages

in their mobile terminal).

Though the evaluation framework as presented in the current Deliverable will be

revised upon the feedback originated from the 1st user trials round and the detailed

experimental plans for the 2nd round of user trials will be detailed in the upcoming

version of this Deliverable, D6.2: Final report on Pilot framework and plans, the

following table summarises the provisional plans for the 2nd round of user trials which

are considered to be close to reality.

Table 62: User trials plan for 2nd evaluation round with user trials (4th evaluation round

of SAFE STRIP overall).

No SAFE STRIP function Evaluation Scenarios (ES) Test Site / Conductor

1. Mobile Cooperative safety

function

ES1.1: Virtual VRU

protection-ES1.1.1: Pedestrian

prompt to cross the zebra

crossing

A22, ATTD, CIDAUT

ES1.1: Virtual VRU protection

- ES1.1.2: Pedestrian prompt

to cross the zebra crossing

with stopped vehicle

A22, ATTD, CIDAUT

ES1.2: Wrong Way Driving A22, ATTD, CIDAUT 2. In-vehicle Cooperative

safety function

ES2.1: VRU protection –

ES2.1.1: Pedestrian prompt to


A22, ATTD, CIDAUT

ES2.2: VRU protection-

ES2.1.2: Pedestrian prompt to

A22, ATTD, CIDAUT



cross the zebra crossing with

stopped vehicle ES2.2: Wrong Way Driving A22, ATTD, CIDAUT

3. Road wear level and

predictive road

maintenance

ES3: Road wear level and

predictive road maintenance

A22, ATTD, CIDAUT

4. In-vehicle application for

rail crossing and road

works safety function

ES4.1: Work zone detection CRF, ATTD,

CIDAUT ES4.2: Railway crossing

detection

HIT (Thessaloniki)

5. Mobile application for rail

crossing and road works

safety function

ES5.1: Work zone detection CRF, ATTD,

CIDAUT ES5.2: Railway crossing

detection

HIT (Thessaloniki)


merging and intersection

Support (e2Call)

ES6.1: Urban intersection CRF, CIDAUT ES6.2: Intersection with


CRF, CIDAUT

ES6.3: Motorway exit CRF, A22, CIDAUT

7. Mobile application for

merging and intersection

Support (e2Call)

ES7.1: Urban intersection CRF, CIDAUT ES7.2: Intersection with


CRF, CIDAUT

ES7.3: Motorway exit CRF, A22, CIDAUT


personalised VMS/VDS

and Traffic Centre

Information


Critical case

A22, ATTD, CIDAUT


Critical case

A22, ATTD, CIDAUT

ES8.3: Virtual VMS 2 – Non-

Critical case

A22, ATTD, CIDAUT

9. Mobile application for

personalised VMS/VDS

and Traffic Centre

Information


Critical case

A22, ATTD, CIDAUT


Critical case

A22, ATTD, CIDAUT

ES9.3: Virtual VMS 2 – Non-

Critical case

A22, ATTD, CIDAUT

10. Autonomous vehicles

support

ES10.1: Dynamic trajectory

estimation for automated

vehicles / ego lane trajectory

information

CRF

ES10.2: Definition of lane-

level virtual corridors /

multiple carriage way

CRF

ES10.3: Tollgates management CRF ES10.4: Work zones detection CRF

11. Application for Virtual

Toll Collection

ES11: Virtual Toll Collection A22, ATTD, CIDAUT

12. Application for parking

booking and charging

ES12.1: Numbered parking

with payment

CRF, ATTD,

CIDAUT ES12.2: Free of charge parking CRF, ATTD,

CIDAUT ES12.3: Regulated parking

(blue zone)

CRF, ATTD,

CIDAUT



13. Integrated in-vehicle

application

C-ES1: Urban intersection

with pedestrian crossing with

equipped vehicles

CRF, ATTD,

CIDAUT

14. Integrated mobile

application

C-ES2: Urban intersection

with pedestrian crossing with

non-equipped vehicles

CRF, ATTD,

CIDAUT

The demonstrators that will participate in CRF and A22 2nd round of user trials will

be:







The demonstrators that will participate in ATTD, Thessaloniki (for the railway use

case) and CIDAUT 2nd round of user trials will be:



The CERTH/HIT demonstrators will be first used for the trials in ATTD and will be

then transferred to Spain for the trials in CIDAUT.

The experimental groups will be (most probably) maintained the same for the 2nd

round as for the 1st round with the only difference that they will be doubled and that at

the end of the 2nd round, focus groups with representative from additional

stakeholders will be conducted (each focus group per test site will consist maximum

10 participants but covering the whole value chain).

7.2 Participants recruitment The number of participants in user trials is predefined in SAFE STRIP Description of

Work. Though this may not be the optimum from a research point of view, research

initiatives often encompass such restrictions due to resource issues. Still, in order to

accommodate a smoother and ensure the possibility of statistical testing, the

Consortium has decided to increase the number of users that will participate in the 1st

round of user trials. As such, whereas before there were only 10 drivers/riders in total

per test site that would participate (according to the DoW), now there are 23

drivers/rides and 2 infrastructure operators representatives that will participate per test

site.

However, and as SAFE STRIP targets safety applications introducing at the same

time a breakthrough cooperative technological solution that has not been tested

before, will keep the 1st round of trials internal to the Consortium, meaning that the

drivers, riders and infrastructure operators that will participate will be recruited by the

participating entities personnel. Another reason for that, that will also affect the 2nd

round of trials, is that the equipped demonstrators of CRF, VALEO, CONTI and

CERTH/HIT can only be driven by employees of the respective entities by law.


However, and in order to enable a sound user acceptance process, the users that will

be recruited will be “blind to the project”, meaning that they will not be directly

involved in the project implementation. Also, during the 2nd round, for the mobile

functions, but also for those that are addressing infrastructure operators, the

Consortium will anticipate involving external users as well.

Employees of the partner organizing and conducting the tests but they will not only be

blind to the project but also to tests’ objectives, design and procedure. Not any such

material will be shared with them before their participation. Participants will be

required to be experienced and active drivers with no psychiatric or substance abuse

medical history, they will have normal or corrected vision and have at least moderate

experience with advanced in-vehicle systems and average ICT literacy. In addition,

pregnant women will not be included in the study.

For the recruitment of the external to the Consortium users, in the context of the 2nd

round, the Ethics Policy of the project will be applied that will by default respecting

the local institutional and national regulations. However, the inclusion criteria

mentioned in the previous paragraph will apply to external participants as well as the

matching criteria.

Another aspect that will be taken care of in the recruitment of participants is their

driving profile. This will be captured by the questionnaire provided in Annex 2 of this

document. This will serve three different purposes:

1. The need to collect some driver profile characteristics to take into account in

the later test results processing (to identify patterns and variations among

them).

2. The need to apply matching criteria in the 2nd round to accommodate the

statistical soundness of the experimental plan (due to lack of a big sample of

users vs. the existence of a big number of evaluation scenarios). As mentioned

earlier, matching criteria will be applied in the first ride based on the selected

driver characteristics.

3. The need to address the personalization aspects of SAFE STRIP that will be

tested in the 2nd round of user trials. Due to the fact that SAFE STRIP will not

have access to historical driver behavior/profile records of the drivers/riders

that are going to participate, this tool will serve for key classification of the

drivers in main clusters and will allow the activation of the respective

personalization strategy for each cluster during the trials.

Based on the Driver Behaviour Questionnaire (DBQ) [18] and the Motorcycle Rider

Behaviour Questionnaire (MRBQ) [10] respectively (Annex 2) drivers/riders will be

categorised as low, moderate and highly in risk drivers for being involved in crash

based on their overall scale score.

In addition, based on their answers to the three major question item clusters, they will

be categorized to being: a) error prone (i.e. susceptibility to human error), b) highway

code violations prone (non-compliance behaviour is interesting to investigate with

compliance to warnings), and c) aggressive violations prone (aggression is correlated

to risk-taking behaviour). It will be interesting to reveal how their categorized based

on this question will correlate to their actual compliance to the HMI information and

warnings, if it differentiates per level and if their tendency to be compliant (or not)


affects reaction time to the presented feedback. As both questionnaires are long, test

conductors are advised to share these questionnaires, along with the informed consent

form, prior user testing, to be completed at their own pace and time.

7.3 Data analysis and statistics The common two independent variables across all services-to-be-tested are the

equipment status (baseline, equipped, non-equipped, autonomous) and performance

type (technical and user-oriented).

Other arising factors that arise and are scenario-specific, they will be treated like co-

factors (e.g. environmental and road conditions) that will affect the dependent

variables that can be clustered into major categories (technical performance and user

performance). Both direct and self-reported metrics will be measured.

Data handling and preparation will firstly be conducted on scenario level and then

aggregated to answer the overarching hypotheses for quality of technical performance

and user acceptance. Dedicated common templates will be prepared for data

collection of subjective scales’ data. Vehicle data will be collected, cleaned and

prepared at each pilot site, respectively.

Data analysis will occur on two dimensions (system/driver performance and

subjective assessments). Subjective assessments comprise: a) perceived measures of

acceptance, trust, value and effort, b) measures of scenario/task completion, errors,

success level/ratio, operators short question and dedicated focus groups.

Two levels entail the purpose of data analysis. Data collected from the ITS logging

mechanisms will primarily be analysed to evaluate the system and driver performance

(i.e. technical validation that the system performs as required and how the driver

responds to the system messages). Self-reported scales are in majority standardised

and for those that benchmarking capability exists, comparisons will be carried out

with similar systems and/or services (only if this is feasible).

All self-reported measures will be transformed (to %) in order to answer the

respective hypotheses. Non parametric alternatives (e.g. Friedman tests) will be

applied to investigate potential differences among groups and conditions, as they have

been defined by the independent variables. Statistical significance will be set at α=.05.

However, at this stage, statistical significance will serve as guidance towards

answering the hypotheses and does not serve as a finite result. This phase is mostly

formative and by no means primarily summative.

8 Test Infrastructure

8.1 Test Sites and Demonstrators As already mentioned, the first round of user trials will be conducted in Attiki Odos

highway (and in a selected Thessaloniki periurban road only for the level crossing use

case) in Greece and in the closed test track of CRF in Italy.

The equipped demonstrators that will participate in SAFE STRIP user trials are

presented in D5.4: Test sites set-up and experimental technical validation plan [21]


and, as such, are not repeated herein. As mentioned again, those demonstrators will

serve for the evaluation scenarios that involve equipped vehicles but also (at least for

the 3rd evaluation round) for those involving also non-equipped vehicles (V2X will be

deactivated and mobile terminals will be only used). The demonstrators that will be

used in each test site of each user trial round are indicated in section 7.1.

Both CRF and CERTH/HIT passenger demonstrators will implement all vehicle

functions of Table 1, whereas the CERTH/HIT PTW demonstrator will implement the

respective on-board functions for PTW’s (it is not yet determined by PIAGGIO if the

respective PTW demonstrator of PIAGGIO will also implement the equipped on-

board functions). The VALEO demonstrator will only be used for the automated

functions evaluation (which cannot be tested by default with any other demonstrator),

whereas the demonstrator by CONTI will be used only in CRF test track in order to

generate the friction estimation data in the respective scenarios.

8.2 Test area and topologies The SAFE STRIP solution, being an infrastructure oriented system, will require the

specific set-up of a specific test area, whereas the installation of the different

(infrastructure) components of SAFE STRIP will be realised.

This set-up is presented per type of scenario in Annex 1 of this document and will

be applied in each test site that will run the specific scenario. The location and the

number of the strips and the RSB’s that will accommodate each scenario are depicted

in each case. Along with that, the evaluation scenarios are also depicted in a more

user-oriented way in D1.2 (Chapter 8) and, as such, are not repeated herein again.

The lane width in each case is about 3,5m (in all test sites). Marking will be present or

not (depending the scenario; i.e. for the evaluation of the automated functions, lane

markings have to be obstructed at some points).

The topologies mentioned above will be applied in each test site (for all rounds).

Slight variations of the layout shown in Annex 1 are very likely due to the uniqueness

of each pilot site. The general characteristics of the project test sites are provided in

D5.4 already (as the set-up of them is a task of WP5).

There are two main test rounds, the 3rd and the 4th, that will take place. The 3rd round

will run in three sites: CRF (Figure 2), ATTD (Figure 3) and Thessaloniki (Figure 4).

The CRF site is the most suitable one since it is an isolated test track and all the use

cases scenarios (except rail crossing) can be accomplished without the disturbance

and risk of real road traffic conditions. In the ATTD case, only for the 3rd round, the

area in the red circle has been selected as test track. It is a semi-isolated area where

only a subset of use case scenarios can be realized (though the vast majority of them).

In Thessaloniki, only the rail crossing scenario will take place both for 3rd and 4th test

rounds, in collaboration with SAFER-LC project. One of the three available spots will

be selected.

It should be stressed that due to resources issues (regarding the equipment that needs

to be installed in each test site), a merging of those topologies will be realised in each

test site. So that all evaluation scenarios will be able to be tested in a specific and


limited test area that will cover them all in terms of equipment. For this reason, each

iteration of each scenario will run on the level of this specified test area.

Those might alter in the 4th round. For example, the main lanes of ATTD will be used

in the 4th round – when the system will be more mature – whereas a respective spot

will be also selected for the trials to run in A22.

Location for all UCs but Intersection.

Possible location for Intersection UC

Figure 3: CRF selected test site spot for 1st user trials round.


Figure 4: ATTD selected test site spot for 1st user trials round.

Area overview

Cross 1

Cross 2

Cross 3

Figure 5: Thessaloniki peri-urban selected test site spots for 1st user trials round.

Cross 3

Cross 2

Cross 1


8.3 ITS logging mechanisms In order to log the metrics that are denoted for each evaluation scenario in section 6.1,

there will be specific logging mechanisms (ITS-Log modules) that will be built in

each main component of the system. The components where each metric will be

logged as well as the steps that each one will be logged is also denoted in section 6.1.

Overall, there are two types of direct (raw) or derived (pre-processed) measures

that will be logged; driver performance data and system performance data.

Driver performance data will be logged either on-board (for vehicle apps running with

the equipped demonstrators) or on device (mobile terminals of the users for the

mobile apps). System performance data will be logged in different phases of the

scenario running in different ends of the system, namely in the RSB, in the C-ITS-S

and the application servers that will communicate with it, also in vehicles’ OBU and

in mobile terminals. No logging mechanism can be implemented in strip’s ORU, due

to power limitations, low processing power, memory limitations and lack of accurate

time synchronisation.

The ITS-Log modules (ITS-LM) that will be built in the project will have a common

structure and will be commonly applied in all those different ends of the system in

order to allow the processing and consolidation of the test results analysis phase. The

most critical parameter for the logging mechanism is the accurate time

synchronization. For this reason the GPS timestamp is selected as time reference for

all the ITS devices and modules that have access to GPS signal. For the rest modules

without GPS reference, the NTP synchronisation mechanism will be used. The SAFE

STRIP system will produce a huge amount of data in runtime. The ITS-LM has to be

designed very carefully, in order to log only the data that are useful for the evaluation

process and to discard everything else.

The ITS-LM that will be built will also enable the technical validation phase of the 3rd

round. The latter will also serve as a rehearsal for their appropriateness and robust

performance, while it will reveal if there is any need to use and apply additional event

diaries for type of data that cannot be logged.

The detailed description of the ITS-LM that will be built for logging are depicted in

the following (latest) system architecture figure of SAFE STRIP.


Figure 6: ITS-LM for logging during user trials.

9 Legal, Ethical Issues & Data Management Plan The ethical, legal and Data Management aspects of the project have been defined in

Deliverables D9.1: “H – Ethics Requirement No. 1” [7], D9.2: “POPD - Ethics

Requirement No.2” [8] and D2.2: “SAFE STRIP Initial Data Management Plan

project” [14] that have been submitted. The respective policies of the project that will

be applied also in the context of the user trials have been defined therein. Still, below,

the most important aspects are indicated in short:

1. The informed consent forms that will be used in the trials are provided in

Annex 1 and 2 of D9.2. The factsheet of the project is also provided in Annex

4 of the Deliverable.

2. An ethics controlling process will be applied prior and after each round of

user trials and in each test site to check conformance with the policy of the

project (that will have already anticipated local specificities originated by

national and/or institutional regulations). Policy of the project deals with all

ethical matters, encompassing recruitment of participants, safety and security,

informed consent, etc., as described in D9.1 and D9.2. The Ethics Board

established in SAFE STRIP (see in D9.2) will oversee this process, as well as

whatever is related to the proper execution of data handling during all phases

of the project.

ITS-LM

ITS-LM ITS-LM

ITS-LM

ITS-LM

ITS-LM

ITS-LM

ITS-LM

ITS-LM


3. Data Management issues are tackled in D2.2 and D9.2 as well. As justified in

the recently updated D9.2, it is not mandatory for SAFE STRIP to appoint a

DPO or get authorisation from DPAs. However, with authorisation from the

SAFE STRIP Project Officer (INEA) and approval from the consortium, the

Project Coordinator Ervin Vermassen will act as the Data Protection Officer

for SAFE STRIP with the role to ensure that GDPR data processing within the

project is done according to current legal and ethical standards. Under his

auspices, the data manager, controllers and processors of the project will act

with each of them having and explicit role (as defined in D9.2). Also, in order

to comply with GDPR requirements on record keeping (Article 30), SAFE

STRIP asks all data processors acting on behalf of the data controller (and

under the monitoring on behalf of the Data Manager and in turn Data

Protection Officer) to record their processing activities in standard forms

which are provided in Annex 5 of D9.2).

In addition to the above that fulfil the project obligations according to current

regulation, SAFE STRIP has initiated on top, a mechanism where all entities

acting as data controllers but, mainly, data processors in the project will

request for a written approval in view of the user trials by their DPO and/or

their National Data Agency, if existing and if they are obliged to such a

process.

4. In a similar way as it will be followed for the GDPR issues, all Ethics sites

responsible participating in the Ethics Board (as described in D9.2) have been

asked to investigate if their entity is obliged to approval from Institutional

and/or National Ethics Committee, and, if it is the case, submit it.

Both above processes are on-going within SAFE STRIP and are expected to have

closed before the start of the 1st round of user trials. However, from the so far

outcomes as being reported by the respective project beneficiaries, there are no

special concerns raised.

10 Impact Assessment Framework

10.1 Objective

The objective of the SAFE STRIP impact assessment is to determine and measure

(quantitative or qualitatively) all changes to be brought by SAFE STRIP C-ITS

solutions, and to explore the possible impacts that different deployment scenarios will

cause at a national or European level.

This involves assessing:

• Whether stated overall goals and long range objectives have been achieved,

both for the project and for the specific use cases/functions/proof of concept of

the backbone cooperative solution.

• Assess the relationship between project results and effects, determine whether

this is attributable to the project.

• Determine comparative conditions before and after the project intervention.

• Identify unanticipated consequences.

• Document lessons learned, areas of excellence.

• Recommend corrective measures (if needed).


10.2 Scope and timing

In SAFE STRIP the impact assessment has been/will be carried out in the following

periods:

• Before the project use cases are implemented: Benchmarking. This intended to

have a picture of the local and current situation without the project. By using

well defined indicators, benchmark data will be used later in a comparative

analysis with the impact assessment results.

• During the WP5 an d WP6 duration. In this case, this ongoing iterative

evaluation will be a way to develop, test and validate the proposed

methodology for the different use cases. It will also focus on the evaluation of

the appropriateness of strategies and approaches as envisioned in the project

design, early effects that would result in generating the desired impacts,

relating these first results to the project objectives. As a result of this

evaluation minor modifications and tuning of the strategies and methodologies

used is foreseen.

• At the end of the project. This final assessment will focus on the analysis of

the overall project performance, assessment of strategies and approaches used,

and the efficiency of inputs invested in the project. It will also endeavor to

extrapolate the measured impacts to a larger and wider audience, considering

different potential deployment scenarios.

The following steps have been/ will be undertaken for the Impact Assessment:

1. Data gathering and quality assessment (validity of the data, reliability of available

information)

• Project goals and objectives (as stated in DoW – no deviation so far)

• Demonstrators/ Use cases specific objectives (as stated in DoW, D1.2

and D5.4 – no deviation so far)

• Anticipated results and changes sought

• Costs

• Key Performance Indicators to be measured, for the project and for

each use case (stated in this Deliverable, section 5.1)

• Assumptions used (stated in this Deliverable)

2. Complementary interviews with project implementers to have a wider overview of

the project goals and objectives

• Within Consortium partners to reach internal consensus on impact

indicators (already held; outcome depicted in this Deliverable)

• Perform interviews for users’ view exploration (performed already in

WP1)

3. Preparation of draft assessment design to be used (objective of the current and

upcoming evaluation and experimental plan as well as of the WP5 technical

validation planning)

• Measure those impacts that can be obtained directly

• Obtain data from traffic / accident data bases when needed

• Devise tool for qualitative data gathering (surveyMonkey or similar,

interviews with key stakeholders)

• Identify additional data needed


• Identify source of additional data needed

• Identify stakeholders along the value chain and develop strategy

• Define questionnaires

• Preview strategy and validate questionnaire with project partners

4. Data gathering (from different sources)

• Data bases and bibliography searches

• Compiling of tests measurements

• Survey communication

• Briefing/focus groups with stakeholders

5. Data organization and analysis (upon collection of data from all different sources,

such as technical validation, user trials, focus groups, etc.)

6. Preparation of impact assessment report (D6.3)

It is important to highlight that points 1 and 2 will have the stronger focus on the

benchmark evaluation, while points 3 to 6 will be the main activities carried out

during the ongoing and after the project evaluations.

During point 3, the tools to be used for the data organization and analysis (point 5)

will be defined, selecting Cost Benefit Analyses or other methodologies depending

both on the impact categorization and the defined KPIs.

10.3 Impact Assessment framework

To define the framework for SAFE STRIP Impact Assessment, the definition of

appropriate Key Performance Indicators (KPIs) is a prerequisite. These are

objectively verifiable measurements which indicate direction and magnitude of

change or result brought about by a project. For purposes of this assessment, the

indicators must be able to describe quantitatively or qualitatively the project impacts.

KPIs had to be defined to investigate the system performance, all the expected

impacts of the system as well as the usage, acceptance and satisfaction with the SAFE

STRIP solutions. KPIs will be accommodated quantitative or qualitative

measurements, agreed beforehand, expressed as a percentage, index, rate or other

value, which will be monitored (at regular or irregular intervals). KPIs can be directly

measured (e.g. speed profile) or derived from a measurement (e.g. speed is used to

calculate an average speed, to calculate standard deviation of speed, the deviation

from speed limit, the acceleration, etc). It can be also self-reported (by users

involved).

The SAFE STRIP KPI’s have been defined in section 5.1 of the current deliverable

and have been mapped to the key research hypotheses/evaluation objectives of the

project as well as to the project functions. The metrics that will accommodate them

are one of the key contents of the current deliverable and are provided in section 6

(direct, derived and self-reported) in very much detail, as they are mapped to specific

steps of the specific real-life evaluation scenarios that have been structured. In

addition, in section 4.1, the specific baseline has been recognised per SAFE STRIP

function and as it is already explained, it may be assumed through additional runs of

baseline scenarios, historic data/results of past projects or assessment of the process

that is currently valid (as it is the case for VMS and Toll Stations use). It is worth


noting that the baseline for SAFE STRIP varies a lot and, in some cases, it does not

even exist, which explains its innovation. Still, in a hypothetical situation, the

evaluation scenarios designed would be run without system support; however, this is

extremely dangerous as most of scenarios – as can be seen in Section 5 - are safety

critical. Finally, in Table 2, the intended and unintended effects of the SAFE

STRIP proof of concept functions have been defined.

KPI’s, baseline and expected effects are the 3 key elements constituting the SAFE

STRIP impact assessment framework. The key approach to be followed is also

explained in Table 3. Some further indications/clarifications on how the impact

assessment will be handled across some key different aspects are as follows:

• For the evaluation of the impact on the safety (i.e. VRU protection), it is

important to associate the changes in driving behaviour due to the implementation

of the SAFE STRIP solution and (number/severity of) accidents/incidents. Several

variables should be taken into account during the finding of this relation, which

can be logged during the trials. For example, the between selected speed and

safety can be estimated by models, according to the consulted bibliography. This

kind of variable can be logged during the SAFE STRIP trials.

• The impact on mobility can be analysed monitoring the effect of the SAFE STRIP

solutions on traffic variables such as amount of travel (number of journeys, their

length and duration), travel patterns (timing of journeys, used modes and routes)

and the quality of travel (feeling of safety and comfort, user stress and

uncertainty). In this case, an association has to be established between

performances parameters that will be logged during the trials and other that will

be self-reported.

• The efficiency (traffic flow, speed and density)of a traffic system can be measured

in relation to the optimum levels of these properties given the traffic demand and

the physical properties of the road network. Efficiency benefits are typically

composed of two effects. They involve:

• Direct efficiency effects resulting from impact on vehicle operations (car-

following, speed selection, etc.) and smoother traffic flow, improving

mean speeds by encouraging safe car-following behaviour. Direct

efficiency effects are reflected in changes of time costs, fuel consumption

costs and reliability changes. The investigation of direct efficiency effects

can involve microscopic traffic flow simulation together with data logging

during trials.

• Indirect efficiency effects resulting from reduction of number of

accidents/incidents (e.g. reduced delays). Indirect efficiency effects occur

when the number—as well as the severity—of accidents is reduced and

transport network becomes more efficient (less congestion, therefore

reducing journey times and fuel consumption).

• Exhaust emissions include many different substances like HC, CO, NOx, PM,

CO2, CH4, NMHC, Pb, SO2, N2O and NH3. Greenhouse gases—CO2, CH4 and

N2O—represent the same society cost anywhere, while costs for other substances

depend on the geographical position. There are two alternatives for quantifying

exhaust emissions: measured exhaust emissions or calculated. Because of the high

complexity and costs of such measurements, calculated emissions are in most

cases the only reasonable alternative. That is the proposal within the SAFE STRIP

proposal, determining the emissions through traffic activity evaluation (travel


time, idle time, time to parking, etc.), data on vehicle fleet, road network,

meteorological conditions, fuel quality and emission factors.\

• Regarding the impact assessment on the management of national pavement

network, infrastructure operators will have here a key role. Impact will be

evaluated through collection of information based on subjective views of the

infrastructure operators (who will be involved in the trials).

• Concerning investments, the costs of SAFE STRIP solutions have to be

elaborated through the compilation of economic information and data. The system

cost of the SAFE STRIP solutions could be broken down to production costs, i.e.

the costs induced by manufacturing the systems, operating and maintenance costs

of the systems as well as infrastructure (adaptation) costs. In a first stage, the

SAFE STRIP solution costs can be provided by the cost of the prototypes

employed in the pilot sites. However, in order to fine tune the assessment impact,

the cost at industrial level should be determined, taking into account the forecast

of the penetration rate of each SAFE STRIP solution. This estimated cost will be

also employed in the Cost- effectiveness and Cost-Benefits analysis proposed for

the evaluation of other subjects (see section 10.5). Cost Benefit Analysis (CBA)

estimates benefits and costs in monetary terms and it can be used to assess the

absolute efficiency of SAFE STRIP solutions, allowing finding whether a

proposed objective is economically efficient and how efficient it is. As a result of

the analysis, a quantitative relationship between benefits and costs will be

calculated (Cost benefits ratio – CBR- or Net Present value – NPV) (see section

10.5). Cost-effectiveness analysis (CEA), on the other hand, refers to the

consideration of decision alternatives in which both their costs and consequences

are taken into account in a systematic way. The consequences are often expressed

in non-monetary effectiveness indicators. In our case, it is proposed to carry out a

CEA taking into consideration the cost of the SAFE STRIP systems combined

with acceptance data (effectiveness evaluation), on the basis of subjective views

of all stakeholders of the value chain (subjective data gathered by means of

questionnaires or surveys).

• Implications on society can be considered as an impact which summarizes all the

prior impacts (safety, mobility, efficiency, environmental and economical).

Therefore, this impact assessment is fed from all the above evidence collected and

aggregated during pilot activities of the project. For the valuation of the social

impact, the consolidated findings from CBA and CEA will be used.

10.4 Traffic Modelling (Micro/Macro)

Traffic modelling tools can be an interesting support to the KPI evaluation based on

objective data, in two ways.

• On one hand, the micro-simulation models can extend the scope of the trials

carried out in the pilot sites. Trials findings can be limited by the low number of

user (vehicles) involved. A not representative number of users can take at a not

relevant results and conclusions based on the trials. Therefore, related with the

traffic impact, micro-simulation models will allow the modelling of changes in

driving behaviour due to the use of SAFE STRIP solutions at a larger scale than

the pilot demonstrations. A combination of measures on trials and traffic

modelling could be interesting to allow estimation of traffic efficiency impacts of

the tested SAFE STRIP solutions at use case level.


• On second hand, SAFE STRIP impact evaluated in the trials (micro level) needs

later to be scaled-up (at local, national, or European levels). This scaling up can be

carried out using statistical data information or through modelling, using a

macroscopic traffic model. The choice of scaling-up method will be based on the

availability of models and the type of effects expected.

10.5 Cost-Benefit Analysis

In this section, Cost Benefit Analysis is described, as the basic tool for the evaluation

of the overall impact assessment of the SAFE STRIP project that will later be

combined with CEA as mentioned above. Cost-benefit analysis (CBA) is broadly-

accepted as a sophisticated, objective evaluation instrument. In general, the CBA

compares the potential economic benefits across a set of impacts with all relevant

potential costs deriving from the implementation of a technology/ measure. As a

result of the analysis a quantitative relationship between benefits and costs is

calculated. CBA and CEA will be applied in SAFE STRIP on societal level in first

place, leading, finally, to the distinct costs and benefits for the main users of SAFE

STRIP.

10.5.1 Scenarios for Cost Benefit Analysis

To consider the CBA for the SAFE STRIP solutions it is necessary to estimate what

would happen if no countermeasure is implemented, it means, if new solutions would

not be introduced (reference case – current roads infrastructure). Additionally it is

necessary to evaluate what injuries mitigation and traffic improvement would be

related with the SAFE STRIP solutions, attending to several penetration rates on the

roads (SAFE STRIP Infrastructure). The difference between both scenarios allows

determining the social impact of the implementations of the SAFE STRIP solutions.

Current Roads Infrastructure Safe Strip Infrastructure

RoadsAccidents

Traffic Patterns

RoadsInjuries Mobility Efficiency Pollution

Current Valuation of the Social Impact

Safe Strip Systems -Penetration Rate Scenarios

RoadsAccidents avoided

Traffic Patterns

Improvement

New Valuation of the Social Impact

Implementation Cost

Social Benefits

Cost Benefits Analiyis (CBA) Figure 7: Cost-Benefit Analysis approach (own elaboration).

10.5.2 Efficiency measurement

Various measures of efficiency are used to perform a comparison between benefits

and costs on society level. The most common are the net present value (defined as

difference between the monetized benefits and the costs required to realise the

measure), the internal rate of return (defined as the interest rate that makes the net

present value equal to zero) and the cost-benefit ratio.


10.5.2.1 Cost-benefit ratio (CBR):

Although these indicators expressing the comparison between benefits and costs, the

most common is the cost-benefit ratio (CBR):

{1}

where:

CBR = cost-benefit ratio

t = time horizon defined

Bt = estimated value of benefits for the year t

Ct = estimated value of costs for the year t

i = discount rate (usually 2,5% - 3,0 %)

The value of the ratio indicates whether the implementations of Safe-Strip solutions

are favourable from a socio-economic point of view. A CBR of more than “1“

indicates that the benefits exceed the costs. Thus, the introduction of the SAFE STRIP

solutions would be beneficial to society. Furthermore, the value of the CBR expresses

the absolute profitability of the SAFE STRIP solutions which can be interpreted as the

socio-economic return for every monetary unit invested in the implementation of the

SAFE STRIP solutions. Whereas, CBR values below 1 reflect a situation in which the

measure benefits (in terms of a reduced monetary value of accidents) are not likely to

exceed the measure costs. A CBR of 0.5 for instance indicates that the calculated

measure costs are two times higher than the calculated benefits. A CBR with value 1,5

shows that 1,5 monetary units are gained for society for every monetary unit provided

for the investment evaluated.

10.5.2.2 Net present value (NPV):

Net present value is calculated with the following formula:

=

{2}

If the net present value (NPV) is positive, that means that over the measure life time,

the discounted cash inflows are higher than the discounted cash outflows of a project.

This means that the system has a profitability that is higher than the discount rate and

is attractive to society. Hence:

• If NPV >0, the project or solution is attractive for society (profitability is

higher than discount rate used).

• If NPV <0, the project or solution is not attractive enough for society

(profitability is lower than discount rate used).

10.5.3 Societal impact assessment based on Cost Benefit Analysis

Impact assessment analysis through a Cost Benefit Analysis might be done attending

to two different approaches, from a safety and a traffic impacts point of view, which

take place at the same time, whereby their effects have to been taken into account

simultaneously.


10.5.3.1 Safety impact assessment

The aim of the safety impact assessment is to provide estimates of safety impacts for

the SAFE STRIP solutions in different penetration scenarios – ‘business as usual’ and

several scenarios with different rates of implementation for the SAFE STRIP solution.

The safety impact estimates in terms of percent changes translated into numerical

estimates of avoided fatalities and injuries. These estimates provide a central input for

the benefit-cost calculations, in which a monetary value for these benefits is assigned.

10.5.3.2 Traffic impact assessment

SAFE STRIP solutions can potentially influence traffic flow on roads, through a

better mobility and efficiency, with a lower environmental impact. SAFE STRIP

solutions are especially beneficial in situations where road capacity approaches its

limits. Therefore the impact of SAFE STRIP solutions on traffic flow should be

considered, in an equivalent approach at the safety impact assessment (impacts of the

employment of the SAFE STRIP solutions concerning a reference scenario without

their deployment).

Safety Impact

Traffic Impact

Congestion

Vehicle Speed

Journey Patterns

Fuel Consumption

Implementation of Safe Strip

solutionsTraffic Flow

Road Capacity

Driving Behaviour

Accident

Number of Accident

Severity of Accidents

Cost of Avoided

Accidents

Decrease of Travel Timing and Vehicle

Operating Cost

Reduction Emission Cost

Figure 8: Cost-Benefit Analysis model (own elaboration, based on Deliverable 3

eIMPACT project).

In order to apply a Cost Benefit Analysis, it is necessary to handle the monetization

values of all the benefits and cost related with the system under study.

10.5.4 Value of societal benefits (avoided costs)

Societal benefits provided by the SAFE STRIP solutions can be classified into two

main groups, related with the safety (safety benefits) and the traffic flow (mobility,

efficiency and environmental benefits).

10.5.4.1 Safety Benefits

This part of the socio-economic assessment aims at calculating the benefits in terms

of safety effects which can be expected from the deployment of SAFE STRIP

solutions. The safety impacts are based on accident causation analyses identifying and


quantitatively assessing the relevant safety mechanisms of SAFE STRIP solution, e.g.

accident avoidance, changes in exposure and crash consequences.

The accident categories allow the separate calculation of effects, depending as

example, on the number and type of vehicles involved in the accident and the road

characteristics where the accident happens.

Road accident database is based on an accident classification that will be used within

the safety impact analysis of SAFE STRIP project. Differentiation of accidents can be

used in the safety impact assessment of SAFE STRIP solutions and, consequently, in

the socioeconomic evaluation of the safety systems.

From road accidents database, a high relevant information can be extracted, in order

to determine in an accurate way, the characterization of the accidents (types of

vehicles involved, type of roads - urban or rural-, types of accidents and also, levels of

caused injuries), related with the development of safety systems carried out within the

SAFE STRIP project.

Table 63: Example of variables definition for the accident data enquiry.


Table 64: Number of casualty accidents, fatalities, hospitalised injured casualties and

non-hospitalised injured casualties and their percentage distribution (Spain, 2016).

Without a monetization of fatalities and injuries, road casualty reduction measures

cannot be weighted properly. Estimation of crash cost-unit rates by severity class can

be used to ensure that best use is made of any investment through economic appraisal.

Potential economic benefits of each SAFE STRIP solution can be estimated based

upon predicted crash savings.

The accident definition used in the different member states is in most of European

countries in line with the EUNET definition are:

• Fatality: death within 30 days for causes arising out of the accident.

• Serious injury: casualties who require hospital treatment and have lasting

injuries, but who do not die within the recording period for a fatality.


• Slight injury: casualties whose injuries do not require hospital treatment or, if

they do, the effects of the injuries quickly subside.

• Property-damage-only accident (PDO): accident without casualties.

Table 65: Accident cost components and accident severity types per 2020 in the EU

member states (in 1000 €) (Source: HIPEBA project).

Fatality Severe Injury Slight Injury

Value of life per se € 2103 € 283 € 23

Loss of productivity € 740 € 28 € 3.2

Property damage € 14 € 5.5 € 3.2

Medical costs € 10 € 17 € 1.4

Administration costs € 2.8 € 0.5 € 0.2

Total (in 1000 €). € 2869.8 € 334 € 31

Accidents Database

Standardized Value for Injuries

Types of Accidents

Accidents Site

•Urban•Outside Urban

Types of Victims

• Fatalities•Serious injured•Slight injured

Types of Victims, related with Safe Strip Use Cases, in different sites

Safe StripUse cases

Types of Casualties to avoid with the Safe Strip solutions

Benefits due to Safe Strip solutions

Accident related with Safe Strip

Use Cases

Safe StripUse cases

Safe StripUse cases

Figure 9: Flowchart of the Safety Impact assessment methodology.

10.5.4.2 Traffic Benefits (mobility, efficiency and environmental benefits

The analysis of the traffic benefits can be distinguished between direct and indirect

effects:

• direct traffic effects on the traffic flow, e.g. changes in speeds and headways;

• indirect traffic effects in terms of reduced congestion, due to avoided accidents

with fatalities and injuries.

As direct effects, t are classified those related to the improvement of the transport

network overall, but, also, to the improvement of the mobility at personal level. Direct

effects are reflected in changes of time costs, fuel consumption costs and reliability

changes:

o Amount of travel: number of journeys, their length and duration

o Travel patterns: Timing of journeys, used modes and routes


o Quality of travel: feeling of safety and comfort, user stress and

uncertainty.

Indirect effects are provided by crashes reduction (e.g. reduced delays at incidents and

accidents). The benefits result from less congestion, therefore reducing journey times

and fuel consumption. Decrease of fuel consumption means an additional benefit, an

environmental benefits, which comprise lower CO2 and air pollutants emissions.

Noise also fits into this category.

Safety cost usually contains only cost components directly linked to the vehicles and

persons involved in a crash. Accidents are regularly accomplished by congestion

caused by a temporarily reduction of road capacity (e.g. blocking of a lane on a

motorway). Congestions lead to time losses, higher fuel consumption, higher air

pollution and CO2-emissions. Therefore, these effects have to be considered as

additional accident costs.

eImpact project provides an extensive study concerning this subject, based on the

results of several selected studies about travel delay costs per accident. Values of

15,500 € for congestions due to accidents with fatalities, 5,000 € for congestions due

to accidents with personal injuries and 1,000 € per congestion due to PDO accidents

are assumed. The following table provides all cost-unit rates which will be used to

calculate the potential benefits of the safety solutions of SAFE STRIP.

Table 66: Cost-unit Rates of Varying Benefit Components (Valid for period 2010-2020)

(Source: Deliverable D3 eIMPACT project).

As effects on the congestion costs (due to accident with casualties) may depend on the

road types and periods of the day, eIMPACT project made an additional disaggregate

cost study. The safety impact assessment gave no specific information about the

distribution of avoided accidents over the day. Assumptions about the effectiveness of


the SAFE STRIP solutions in different periods of the day could be made based on the

description of the SAFE STRIP use cases and factors identified in the safety impact

assessment (e.g. by comparing effectiveness factors for the day and night period).

eIMPACT project provided a disaggregated breakdown of congestion cost against

location and time of the day for the accidents, specifically developed for their safety

systems . The costs were disaggregated to obtain costs per road type and period of the

day. Assumptions for that were made based on available statistics on congestion

(SafetyNet, 2007 and Dutch accident statistics). For instance, a queue caused by a

fatal accident generates higher congestion costs in the morning (peak hour) than at

night. Also, on motorways congestion costs will be much higher than on rural roads,

because of the higher traffic flows.

Table 67: Congestion costs due to accidents with fatalities and severe injuries over location and

time of day (Source: Deliverable D4, eIMPACT project).

10.5.5 Value of costs for SAFE STRIP

In the socio-economic assessment of SAFE STRIP solutions the costs of the functions

to be evaluated have to be compared with the benefits the functions generate for the

society. Hence, the costs of SAFE STRIP solutions have to be elaborated through the

compilation of economic information and data.

The system cost of the SAFE STRIP solutions will be broken down to production

costs, i.e. the costs induced by manufacturing the systems, operating and maintenance

costs of the systems as well as infrastructure (adaptation) costs.

A clearer distinction between costs and prices is essential for the socioeconomic

assessment. The price of SAFE STRIP solutions is what the end user faces when

purchasing the system in the market-place. Hence, price determines to a large extent

the market penetration of the SAFE STRIP solutions. Therefore, price information is

relevant for any user-related assessment.

Prices are much higher than costs because they include profit margins. The relation

between prices and costs may not be so straightforward due to parameters such as the


users’ willingness-to-buy, the marketing strategy, the risks of market introduction and

other intangible values of a system.

Distinction between costs and prices of SAFE STRIP solutions is recommended for

covering the different approaches within a comprehensive socio-economic

assessment. Therefore, taking this distinction into account, a complete double set of

information on costs and prices for each SAFE STRIP solution to be evaluated is

mandatory.

The costs of SAFE STRIP solutions are mainly technology-specific; they are

determined by the technology and system components used for the specific safety (or

added value) application.

Systems Production Costs

Implementation Costs on Infrastructure

InvestmentCosts

Operating and Maintenance Costs(Vehicle and Infrastructure)

Implementation Costs on Vehicle

Figure 10: Scheme for the breakdown cost evaluation.

As a second step, and upon the overall socioeconomic assessment of SAFE STRIP

(on societal level), it is essential that the specific costs and benefits are then

specifically quantified for each key end-user, namely the drivers/riders and the

infrastructure operators (of different types).

11 Next steps The current Deliverable presents the evaluation framework for the two rounds of user

trials planned in SAFE STRIP, the detailed experimental plans for the first round and

the impact assessment framework of the project.

Prior to the first round of user trials and upon the feedback originated from the

progress on implementation end, but also upon the feedback provided by the third and

final technical validation round, the following revisions/optimisations might emerge

(though not necessarily):

• Revision of the evaluation scenarios as presented in this document.

• Revision of the test topologies (currently attached in Annex 1).

• Revision of the test site spots selected for the conduct of the trials.

• Revision (and translation) of the subjective measuring tools (attached in

Annex 3).

• Critical revision of the ITS logging mechanisms that will be built in the

different ends of the SAFE STRIP system.


All the above potential revisions/optimisations as well as the ones that will occur

upon the realisation of the first round with users will be reflected in the subsequent

version of this Deliverable, namely D6.2: Final report on Pilot framework and plans

(due for M28 of the project).

Last but not least, the impact assessment framework of the project – and upon

feedback from the 1st user trials round – will be specified in detail in D6.3: Pilot

results consolidation & Impact analysis, where the analytical methodology for each

type of expected impact will be included together with the derived results.


References

1. “Deliverable 5.1 - Cost-benefit analysis using advanced steels in highly

demanding safety barriers” HIPEBA project - High Performance Steel for Safer

and more Competitive Barriers, May 2017.

2. “Deliverable D11.3 – European Large-Scale Field Operational Tests on In-

Vehicle Systems”, euroFOT project, December 2012

3. “Deliverable D3 - Methodological framework and database for socio-economic

evaluation of Intelligent Vehicle Safety Systems“, eIMPACT project - Socio-

economic Impact Assessment of Stand-alone and Co-operative Intelligent

Vehicle Safety Systems (IVSS) in Europe, December 2006.

4. “Deliverable D4 - Impact assessment of Intelligent Vehicle Safety Systems”,

eIMPACT project - Socio-economic Impact Assessment of Stand-alone and Co-

operative Intelligent Vehicle Safety Systems (IVSS) in Europe, August 2008.

5. “FESTA Handbook Version 6 - Updated and maintained by FOT-Net (Field

Operational Test Networking and Methodology Promotion)”, December 2016.

6. “Main figures on road traffic accidents - Spain 2016 - SUMMARY”, Dirección

General de Tráfico, 2017

7. Bandhari, R., Deliverable D9.1: H – Ethics Requirement No. 1, SAFE STRIP

(SAFE and green Sensor Technologies for self-explaining and forgiving Road

Interactive aPplications) project, G.A. 723211, www.safestrip.eu, October 2017.

8. Bandhari, R., Deliverable D9.2: POPD - Ethics Requirement No.2 (update),

SAFE STRIP (SAFE and green Sensor Technologies for self-explaining and

forgiving Road Interactive aPplications) project, G.A. 723211, www.safestrip.eu,

November 2018.

9. Bekiaris, E., Gemou, M., D60.4: Validation Plan, INSAFES – INtegrated SAFEty

Systems, http://www.prevent-ip.org/insafes/, February 2008

10. Elliott, M.A., Baughan, C.J., Sexton., B.F. (2007). Errors and violations in

relation to motorcyclists’ crash risk Accident Analysis and Prevention, 39 (3) ,

pp. 491-499.

11. Gkemou, M. et al., Deliverable D1.2: SAFE STRIP Use Cases and application

scenarios, SAFE STRIP (SAFE and green Sensor Technologies for self-

explaining and forgiving Road Interactive aPplications) project, G.A. 723211,

www.safestrip.eu, November 2017.

12. Jian, J.-Y., Bisantz, A. M. and C. G. Drury, ‘Foundations for an Empirically

Determined Scale of Trust in Automated Systems’, Int. J. Cogn. Ergon., vol. 4,

no. 1, pp. 53–71, Mar. 2000.

13. Kehagias, D. et al., Deliverable D2.1: System architecture, sensor specifications,

fabrication, maintenance, installation and security requirements and Risk

Assessment, SAFE STRIP (SAFE and green Sensor Technologies for self-



14. Kehagias, D. et al., Deliverable D2.2: SAFE STRIP Initial Data Management

Plan project, SAFE STRIP (SAFE and green Sensor Technologies for self-



http://www.safestrip.eu/


http://www.prevent-ip.org/insafes/





15. Michon, J. A. (1985). A critical view of driver behaviour models: what do we

know, what should we do? In: L. Evans and R. C. Schwing (Eds.). Human

Behaviour and Traffic Safety, pp. 485-524. New York: Plenum Press.

16. Pauzie, ́ A., Pachiaudi, G. (1997) Subjective evaluation of the mental workload in

the driving context. In: Rothengatter T, Carbonell Vaya E (eds) Traffic and

transport psychology: theory and application, Pergamon, pp 173–182.

17. Pauziem, ́ A., Gelau, C., Aupetit, S. (2009) Safety evaluation methodology of ITS

for riders. International conference models and technologies for intelligent

transportation systems, 22–23 June 2009, Rome.

18. Reason, J.T., Manstead, A.S.R., Stradling, S., Baxter, J. and K. Campbell. (1990)

Errors and violations on the roads Ergonomics, 33, pp. 1315-1332.

19. Robinet, A., Deliverable D3.1: Micro & nano sensors, QR algorithms, power

supply units, SAFE STRIP (SAFE and green Sensor Technologies for self-



20. Sauro, J. (2015). SUPR-Q: A Comprehensive Measure of the Quality of the

Website User Experience. Journal of Usability Studies, 10 (2), pp. 68-86

21. Steccannella, A. et al, Deliverable D5.4: Test sites set-up and experimental

technical validation plan, SAFE STRIP (SAFE and green Sensor Technologies

for self-explaining and forgiving Road Interactive aPplications) project, G.A.

723211, www.safestrip.eu, June 2018.

22. Van Der Laan, J. D., Heino, A.and D. De Waard, ‘A simple procedure for the

assessment of acceptance of advanced transport telematics’, Transp. Res. Part C

Emerg. Technol., vol. 5, no. 1, pp. 1–10, février 1997.




Annex 1: Infrastructure set-up for the user trials

ES1.1.1 & ES2.1.1: Pedestrian prompt to cross the zebra crossing

ES1.1.2 & ES2.1.2: Stopped vehicle


ES1.2 & ES2.2: Wrong Way Driving

ES3: Road wear level and predictive road maintenance

No specific layout for this use case. A single strip equipped with strain gauges and

placed in the road surface, will monitor the road wear level.

ES4.1 & ES5.1: Work zone detection


ES4.2 & ES5.2: Railway crossing detection

ES6.1 & ES7.1: Urban intersection


ES6.2 & ES7.2: Intersection with wet/dry road condition

ES6.3 & ES7.3: Motorway exit


ES8.1 & ES9.1: Virtual VMS 1 – Critical case

ES8.2 & ES9.2: Virtual VMS 2 – Critical case

ES8.3 & ES9.3: Virtual VMS 2 – Non- Critical case


ES10.1: Dynamic trajectory estimation for automated vehicles / ego lane trajectory

information

ES10.2: Definition of lane-level virtual corridors / multiple carriage way


ES10.3: Tollgates management

ES10.4: Work zones detection


ES11: Virtual Toll Collection

ES12.1: Numbered parking with payment

ES12.2: Free of charge parking


ES12.3: Regulated parking (blue zone)


Annex 2: Driver and Rider Behaviour Questionnaire

Dear Participants,

Thank you for your participation in this study. This questionnaire is aimed to study

the driving behaviours of drivers. By participating in this study, you are required to

complete a series of questionnaires. Please note that there are no right or wrong

answers for any of these questions as we are expecting different people providing

different answers. This research is purely for academic purposes only and the

information you provide will be kept confidential at all times. Please answer and rate

the items as accurately and honestly as possible.

Section A: Demographics

Please kindly tick (√) or fill in your answers in the space provided.

1. Age: ☐ 1726 years ☐ 2736 years ☐ 3746 years ☐ > 46 years

2. Gender: ☐ Male ☐ Female

3. Status: ☐ Unmarried ☐ Married

4. Which state are you from? __________________________ (e.g.: Pahang)

5. What is your current driving license class?

☐ Probationary license (P-license) ☐ Competent license (D-license)

6. How many years have you been driving (from the year you got your driving license)?

☐ ≤ 10 years ☐ 1120 years ☐ 2130 years ☐ > 30 years

7. How old is the vehicle you drive most often?

☐ ≤ 5 years old ☐ 6 10 years old ☐ 11 15 years old ☐ > 15 years old

8. What is the engine size of the vehicle you drive most often?

☐ ≤ 10 liter ☐ 1.1 to 2.0 liter ☐ 2.1 to 3.0 liter ☐ > 3.0 liter

Section B: Driving Practices Questions

Please tick (√) your answer.

1. How often do you drive?

☐ Almost every day

☐ A few days a week

☐ A few days a month

☐ A few times a year

☐ Never


2. What type of driving do you usually do?





☐ Never

3. How frequent do you drive on the highway?





☐ Never

4. How frequent do you drive in the city or town?





☐ Never

5. How frequent do you drive in the outskirt or rural area?





☐ Never

6. Do you practise speeding while driving?

☐ Never

☐ Rarely

☐ Occasionally

☐ Often

☐ Always

7. How frequent do you speed on the highway?

☐ Never ☐ Rarely ☐ Occasionally ☐ Often

☐ Always

8. How frequent do your speed in the city or town?


☐ Always

9. How frequent do you speed in the outskirt or rural area?


☐ Always

10. What is/are the reason(s) of your speeding? (you may tick more than one options)


☐ It is fun.

☐ Driving fast keeps me awake. ☐ Running late for work/ interviews/ fetch kids from school/ etc. ☐ I am very familiar with the road.

☐ I was not aware of the speed limit of the location.

☐ I was not aware of the speed I am travelling in.

☐ The road designs encourage speeding.

☐ When I am feeling stressed.

☐ My car is built to speed.

☐ In order to keep up with surrounding traffic.

☐ When I am on a long journey.

☐ When under pressure from another driver following close behind me.

☐ When driving on quiet roads with little or no traffic.

☐ When another driver flashes their headlights or sounds their horn behind me.

☐ When another vehicle overtook me.

☐ When I am listening to certain types of music in the car.

☐ I feel the urge to showoff or assert myself.

☐ The passengers are encouraging me to drive faster.

☐ I seldom get caught for speeding.

Section C: Driving Experience Questions

Please tick (√) or fill in your answers in the space provided.

1. As a driver, have you been caught for any traffic violations? How frequent were you caught?

☐Yes ☐ Rarely ☐ Occasionally ☐ Often ☐ Always ☐ Never

2. What is/are the traffic offences you have violated?

_____________________________________________________________________________

_____________________________________________________________________________

3. As a driver, have you been caught for speeding? How frequent were you caught for speeding

?

☐Yes ☐ Rarely ☐ Occasionally ☐ Often ☐ Always ☐ Never

4. As a driver, how many road accidents have you involved in (including minor & injury free

road accidents)? _______

5. As a driver, how many road accidents due to speeding have you been involved in (including

minor & injury free road accidents)?

Section D: Driver Opinion Questions

Please rate from 1 to 10 for the following questions.

1. In your opinion, rate the following reasons to the high rate of road accidents in your country.


(i) Driverrelated factors

1 2 3 4 5 6 7 8 9 10

Not at all Very much

(ii) Vehiclerelated factors

1 2 3 4 5 6 7 8 9 10


(iii) Environmental factors (road design and infrastructurerelated factors, weather, time of

day, presence of passengers/ pedestrians, animal crossings etc.)

1 2 3 4 5 6 7 8 9 10


2. In your opinion, rate the following driving behaviours that are attributed to the high rate of

road accidents in your country.

(i) Speeding

1 2 3 4 5 6 7 8 9 10


(ii) Aggressivedriving

1 2 3 4 5 6 7 8 9 10


(iii) Mobile phone usage

1 2 3 4 5 6 7 8 9 10


(iv) Drug and drink driving

1 2 3 4 5 6 7 8 9 10


(v) Fatigue driving

1 2 3 4 5 6 7 8 9 10


(vi) Stress or workload driving

1 2 3 4 5 6 7 8 9 10


Section E: Driver SelfEvaluation Questions

Please rate from 1 to 10, which best describe you.

1. In general, I drive faster than other drivers.


1 2 3 4 5 6 7 8 9 10


2. Whenever my friends are with me in the car, I tend to drive faster.

1 2 3 4 5 6 7 8 9 10


3. Whenever my family is with me in the car, I tend to drive safer.

1 2 3 4 5 6 7 8 9 10


4. I get a real thrill out of driving fast.

1 2 3 4 5 6 7 8 9 10


5. Traffic violations does not necessarily lead to road accident, so it is worthwhile taking risks

on the road.

1 2 3 4 5 6 7 8 9 10


6. When driving on an unfamiliar road, I tend to drive slower.

1 2 3 4 5 6 7 8 9 10


7. My heart beats harder/ faster whenever I speed.

1 2 3 4 5 6 7 8 9 10


8. Driving is stressful, unless necessary I do not drive.

1 2 3 4 5 6 7 8 9 10


9. I get impatient during the rush hour.

1 2 3 4 5 6 7 8 9 10


10. In a traffic jam, I think of ways to get through the traffic faster.

1 2 3 4 5 6 7 8 9 10



11. In a traffic jam, when the lane next to me starts to move, I try to move into that lane as

soon as possible.

1 2 3 4 5 6 7 8 9 10


12. I drive through traffic lights that have just turned red.

1 2 3 4 5 6 7 8 9 10


13. I accelerate harder when the traffic lights turned yellow.

1 2 3 4 5 6 7 8 9 10


14. I enjoy cornering at high speed.

1 2 3 4 5 6 7 8 9 10


Section F: Situational Driver Behaviour Questions

Please rate from 1 to 10 for the following questions.

Situation A1: It is raining heavily at night and you are driving at 90km/h in a rural area without street lamps.

Suddenly, a cow crosses the road 5m away from you. How likely are you to involve in an

accident?

1 2 3 4 5 6 7 8 9 10


Situation A2: It is raining heavily at night and you are driving at 45km/h in a rural area without street lamps.

Suddenly, a cow crosses the road 5m away from you. How likely are you to involve in an

accident?

1 2 3 4 5 6 7 8 9 10


Situation B1: You are going to be late for work in the city and hence you speed up to 90km/h on a 50km/h

road. You are 5m away, the traffic light turns red and a pedestrian starts crossing the road without

noticing you. How likely that you are to hit the pedestrian?

1 2 3 4 5 6 7 8 9 10



Situation B2:

You are going to be late for work in the city but you abide to the speed limit of 50km/h. You are

5m away, the traffic light turns red and a pedestrian starts crossing the road without noticing you.

How likely that you are to hit the pedestrian?

1 2 3 4 5 6 7 8 9 10


Situation C1: It is a clear blue sky and therefore you confidently drive at 160km/h on the highway. Suddenly

your rear tyre burst. How likely that you will lose control of your car and lead to road accidents?

1 2 3 4 5 6 7 8 9 10


Situation C2: It is a clear blue sky and therefore you confidently drive at 100km/h on the highway. Suddenly

your rear tyre burst. How likely that you will lose control of your car and lead to road accidents?

1 2 3 4 5 6 7 8 9 10


Motorcycle Rider Behaviour Questionnaire (MRBQ)

1. Fail to notice that pedestrians are crossing when turning into a side street from a main road.

0 1 2 3 4 5

Never

Nearly all

the time

2. Not notice someone stepping out from behind a parked vehicle until it is nearly too late.

0 1 2 3 4 5

Never

Nearly all

the time

3. Pull out on to a main road in front of a vehicle that you had not noticed, or whose speed you

have misjudged.

0 1 2 3 4 5

Never

Nearly all

the time

4. Miss “Give Way” signs and narrowly avoid colliding with traffic having the right of way.

0 1 2 3 4 5

Never

Nearly all

the time

5. Turn on one thing, such as headlights, when you mean to switch on something else.

0 1 2 3 4 5


Never

Nearly all

the time

6. Fail to notice or anticipate that another vehicle might pull out in front of you and have

difficulty stopping.

0 1 2 3 4 5

Never

Nearly all

the time

7. Queuing to turn left on a main road, you pay such close attention to the main traffic that you

nearly hit the vehicle in front.

0 1 2 3 4 5

Never

Nearly all

the time

8. Distracted or pre-occupied, you belatedly realise that the vehicle in front has slowed and you

have to brake hard to avoid a collision.

0 1 2 3 4 5

Never

Nearly all

the time

9. Attempt to overtake someone that you had not noticed to be signalling a left turn.

0 1 2 3 4 5

Never

Nearly all

the time

10. When riding at the same speed as other traffic, you find it difficult to stop in time when a

traffic light has turned against you.

0 1 2 3 4 5

Never

Nearly all

the time

11. Ride so close to the vehicle in front that it would be difficult to stop in an emergency.

0 1 2 3 4 5

Never

Nearly all

the time

12. Run wide when going round a corner.

0 1 2 3 4 5

Never

Nearly all

the time

13. Ride so fast into a corner that you feel like you might lose control.

0 1 2 3 4 5

Never

Nearly all

the time

14. Exceed the speed limit on a country/rural road.


0 1 2 3 4 5

Never

Nearly all

the time

15. Disregard the speed limit late at night or in the early hours of the morning.

0 1 2 3 4 5

Never

Nearly all

the time

16. Exceed the speed limit on a motorway.

0 1 2 3 4 5

Never

Nearly all

the time

17. Exceed the speed limit on a residential road.

0 1 2 3 4 5

Never

Nearly all

the time

18. Race away from traffic lights with the intention of beating the driver/rider next to you.

0 1 2 3 4 5

Never

Nearly all

the time

19. Open up the throttle and just ‘go for it’ on country roads.

0 1 2 3 4 5

Never

Nearly all

the time

20. Ride between two lanes of fast moving traffic.

0 1 2 3 4 5

Never

Nearly all

the time

21. Get involved in unofficial ‘races’ with other riders or drivers.

0 1 2 3 4 5

Never

Nearly all

the time

22. Ride so fast into a corner that you scare yourself.

0 1 2 3 4 5

Never

Nearly all

the time

23. Attempt to do, or actually do, a wheelie.

0 1 2 3 4 5


Never

Nearly all

the time

24. Pull away too quickly and your front wheel comes off the road.

0 1 2 3 4 5

Never

Nearly all

the time

25. Intentionally do a wheel spin.

0 1 2 3 4 5

Never

Nearly all

the time

26. Unintentionally do a wheel spin.

0 1 2 3 4 5

Never

Nearly all

the time

27. Use dipped headlights on your bike?

0 1 2 3 4 5

Never

Nearly all

the time

28. Brake or throttle-back when going round a corner or bend.

0 1 2 3 4 5

Never

Nearly all

the time

29. Change gear when going round a corner or bend.

0 1 2 3 4 5

Never

Nearly all

the time

30. Find that you have difficulty controlling the bike when riding at speed (e.g. steering wobble).

0 1 2 3 4 5

Never

Nearly all

the time

31. Skid on a wet road or manhole cover.

0 1 2 3 4 5

Never

Nearly all

the time

32. Have trouble with your visor or goggles fogging up.

0 1 2 3 4 5

Never

Nearly all

the time


33. Driver deliberately annoys you or puts you at risk.

0 1 2 3 4 5

Never

Nearly all

the time

34. Ride when taking drugs or medications which might have effects on your riding.

0 1 2 3 4 5

Never

Nearly all

the time

35. Cross junction when traffic light is red.

0 1 2 3 4 5

Never

Nearly all

the time

36. Riding in opposite direction of road way.

0 1 2 3 4 5

Never

Nearly all

the time

37. Riding in sidewalk.

0 1 2 3 4 5

Never

Nearly all

the time

38. Call with mobile phone while riding.

0 1 2 3 4 5

Never

Nearly all

the time

39. Riding without putting prescription eyeglasses.

0 1 2 3 4 5

Never

Nearly all

the time

40. Smoking while riding.

0 1 2 3 4 5

Never

Nearly all

the time

41. Carry passengers by your motorcycle for money.

0 1 2 3 4 5

Never

Nearly all

the time

42. Using helmet without chin straps or not fastening it.


0 1 2 3 4 5

Never

Nearly all

the time

43. Carry a large carriage with motorcycle.

0 1 2 3 4 5

Never

Nearly all

the time

44. Carry more than one passenger with your motorcycle.

0 1 2 3 4 5

Never

Nearly all

the time

45. Have a crash with a parked vehicle and make damage to it, but escape from crash scene.

0 1 2 3 4 5

Never

Nearly all

the time

46. Riding with an impaired motorcycle.

0 1 2 3 4 5

Never

Nearly all

the time

47. Riding without helmet.

0 1 2 3 4 5

Never

Nearly all

the time

48. Carry a passenger who have not worn helmet.

0 1 2 3 4 5

Never

Nearly all

the time

49. Delay in noticing to in front car when opening door suddenly and control your motorcycle

difficultly.

0 1 2 3 4 5

Never

Nearly all

the time


Annex 3: Subjective tools for drivers/riders and operators in

1st round of user trials

Apart from the workload questionnaire, the rest of the questionnaires are common for

drivers/riders and operators.

BACKGROUND QUESTIONNAIRE FOR DRIVERS/RIDERS

1) Do you currently have a car (a motorcycle) available for your use?

yes, (nearly) always

yes, sometimes

no or hardly ever

2) Please state how often you use the following systems:

(Almost)

daily

Several

times a

week

Weekly Monthly Less

often

or

never

I d

o n

ot

kn

ow

th

is

syst

em

I d

o n

ot

have

this

syst

em

Parking Assist

System

Self-parking

Assist System

Cruise Control

Adaptive

Cruise Control

(ACC)

Navigation or

route planning

Other (please

specify)

3) Please state if your current vehicle is equipped with the following systems:


My c

urr

ent

car

is

equ

ipp

ed w

ith

th

is s

yst

em

My c

urr

ent

car

has

this

bu

t I

kee

p i

t off

I k

now

wh

at

it i

s b

ut

do

not

have

it

I d

o n

ot

kn

ow

th

is s

yst

em

or

wh

eth

er I

have

it

Blind spot monitoring

Lane departure warning systems

Lane keeping assistance

Forward Collision Warning

Integrated navigation system

The following question (Q4) to be answered ONLY by participants in automated

driving scenario):

4) Do you generally experience motion sickness when travelling as a passenger?

never or hardly ever

sometimes, specify (tick all that apply):

if not looking at the road

if sitting on back seat

if ride is curvy or bumpy

other or no clear pattern

often or always

5) How many years of driving (riding) experience do you have?

less than 1 year

1-2 years

2-10 years

more than 10 years

6) How much do you drive (ride) annually on average? ______ km

less than 5.000 km a year

5.000 up to 10.000 km

10.000 up to 15.000 km

15.000 up to 20.000 km

20.000 up to 25.000 km

25.000 up to 30.000 km

more than 30.000 km

don´t know


7) What year were you born?

______________ (dd/mm/yyyy) I would rather not say

8) Please specify your gender:

[ ] Male

[ ] Female

[ ] Other

[ ] Prefer not to say

BACKGROUND QUESTIONNAIRE FOR INFRASTRUCTURE OPERATORS

1. How many people work for your organisation? (please tick)

0 – 5 50 – 100

6-25 100-250

26-50 250 + 3

2. Years of professional experience:_____(years)

3. Position title (if you do not wish to state your exact title, please add a brief

description of your position):

4. What is the size of your infrastructure?_______

5. Do you operate road maintenance and inspection software?

Yes No

6. If you answered yes in Q5, which system do you use? (please specify name and

brand)

7. What type of system would suit your needs?

PRE –TESTING RATING

Will be completed for each type of function experienced by the user.

User acceptance by measuring usefulness/satisfaction scale (Van der Laan et al.,

1997). These experiences of the usefulness/satisfaction scale show that administering

it before and after having interacted with the system facilitates an understanding of

the evolution of user acceptance.

1 Useful |__|__|__|__|__| Useless

2 Pleasant |__|__|__|__|__| Unpleasant

3 Bad |__|__|__|__|__| Good

4 Nice |__|__|__|__|__| Annoying

5 Effective |__|__|__|__|__| Superfluous

6 Irritating |__|__|__|__|__| Likeable

7 Assisting |__|__|__|__|__| Worthless

8 Undesirable |__|__|__|__|__| Desirable


DURING – TESTING

(test conductor observations – presented in Annex 4)

This short section is completed after each event (or series of events) that the

participants are faced with during the test/experiment (several times in each

test/experiment). Although it is preferable to administer it during the experiment, it

can be possible to provide it at the end of each ride, using video auto-confrontation.

1. In this situation what would you have done without the SAFE STRIP?

2. How differently from what you would have done, did the app re-acted? Please

elaborate.

3. Were you stressed or frightened?

Any comments made about the event, should be noted by the facilitator. Registration of particular events – Session n. ___

(to be filled in by the test-conductor with feedback from the user – part of the test

conductor form in Annex 4) During the tests several not intended events might influence the results. Please note

any of the following aspects if applicable during the experiment.

• Function performance of the system during the test. Note what happened

and when (use time stamps) in terms of non-compliance or any other

unplanned behaviour of the system.

• Environmental influences (noise, disturbances, climate, etc.) • Personal influences (tiredness, sickness, negative attitude, time pressure, etc.)

POST-TESTING

Will be completed for each type of function experienced by the user.

Acceptance

9 Raising Alertness |__|__|__|__|__| Sleep-inducing

1 Useful |__|__|__|__|__| Useless

2 Pleasant |__|__|__|__|__| Unpleasant

3 Bad |__|__|__|__|__| Good

4 Nice |__|__|__|__|__| Annoying

5 Effective |__|__|__|__|__| Superfluous

6 Irritating |__|__|__|__|__| Likeable

7 Assisting |__|__|__|__|__| Worthless

8 Undesirable |__|__|__|__|__| Desirable

9 Raising Alertness |__|__|__|__|__| Sleep-inducing


Trust

This scale proposes 12 potential factors of trust between people and warning systems.


Perceived value

1. I consider myself as a future user

of the system.

2. I enjoy using the system.

3. I am willing to pay to use the

system in the future.

4. How likely is it that you recommend this function to a colleague or friend?

Driver’s workload (DALI)

VISUAL

DEMAND

Low/High To evaluate the visual demand necessary for the

activity.

AUDITORY

DEMAND

Low/High To evaluate the auditory demand necessary for

the activity.

TEMPORAL

DEMAND

Low/High To evaluate the specific constraint due to timing

demand when running the activity.

SYSTEM

INTERFERENCE

Low/High To evaluate the possible disturbance when

running the driving activity simultaneously with

any other supplementary task such as phoning,

using navigation system or radio, ...

EFFORT OF

ATTENTION

Low/High To evaluate the attention required by the activity

- to think about, to decide, to choose, to look for,

...

SITUATIONAL

STRESS

Low/High To evaluate the level of constraints / stress while

conducting the activity - fatigue, insecure feeling,

irritation, discouragement, ...


Instructions for driver: “During the experiment that you have just achieved, you may have felt some constraints and difficulties with regard to your usual driving task (or to the driving task you run with no system). You will now evaluate the last ride. For each factor, please rate the level of constraint felt during the session on a scale from 0 (low) to 5 (high). Tick the box that matches your experience.”

Rider’s Workload (RALI) – ONLY for scenarios with riders The RALI aims at measuring your subjective workload during riding by means of 8 dimensions. Please read the descriptions of the following 8 scales carefully or ask the test leader to explain them to you. If you have a question about any of the scales, feel free to ask about it. It is extremely important that they are clear to you.


VISUAL

DEMAND

Low/High To evaluate the visual demand necessary for the

activity.

AUDITORY

DEMAND

Low/High To evaluate the auditory demand necessary for

the activity.

TEMPORAL

DEMAND

Low/High To evaluate the specific constraint due to timing

demand when running the activity.

SYSTEM

INTERFERENCE

Low/High To evaluate the possible disturbance when

running the riding activity simultaneously with

any other supplementary task such as phoning,

using navigation system or radio, ...

EFFORT OF

ATTENTION

Low/High To evaluate the attention required by the activity

- to think about, to decide, to choose, to look for,

...

SITUATIONAL

OWN COPINT

Low/High To evaluate the workload induced for coping

with the other vehicles and with the complexity

of the environment.

SITUATIONAL

STRESS

Low/High To evaluate the level of constraints / stress while

conducting the activity - fatigue, insecure feeling,

irritation, discouragement, ...

EMOTIONS

HANDLING

VEHICLE

Low/High To evaluate the level of negative emotions linked

to the control and the handling of the motorbike.

Instructions for RIDER: “During the experiment that you have just achieved, you may have felt some constraints and difficulties with regard to your usual driving task (or to the riding task you run with no system). You will now evaluate the last ride. For each factor, please rate the level of constraint felt during the session on a scale from 0 (low) to 5 (high). Tick the box that matches your experience.”


VISUAL DEMAND

Low High

0 1 2 3 4 5

AUDITORY DEMAND

Low High

0 1 2 3 4 5

TEMPORAL DEMAND

Low High

0 1 2 3 4 5

SYSTEM INTERFERENCE

Low High

0 1 2 3 4 5

EFFORT OF ATTENTION

Low High

0 1 2 3 4 5

SITUATION OWN COPING

Low High

0 1 2 3 4 5

SITUATIONAL STRESS

Low High

0 1 2 3 4 5

EMOTIONS HANDLING VEHICLE Low High

0 1 2 3 4 5


Now, please answer the following questions about the function (each function experienced). Indicate your judgement by ticking one box per line.

1. Is the warning/information received useful? not at all

a lot

2. Did the warning/information received

distract you from the critical event?

not at all

a lot

3. Did the warning/information received help

you to manage the event?

not at all

a lot

4. Did you trust the warning/information

received?

not at all

a lot

5. How was the timing of the

warning/information received?

too early

too late

6. Did you like how the warning/information

received was presented?

not at all

a lot

7. Has the system had any influence on your

driving/riding/operation?

not at all

a lot

8. Did you appreciate the system? not at all

a lot

9. Do you think your fellow

drivers/riders/operators would appreciate

the system?

not at all

a lot

10. Did you feel confident using the system?

11. How important is the opinion of your

fellow drivers/ riders/colleagues (for

operators) about the system to you?

not at all

a lot

Service-oriented questionnaire that can be further adapted per function:

They can be administered to both user types (apart from question items 3 and 4 that

are relevant only to drivers).

Instruction to the driver/rider: Please think about the trip with using function X (add

function name).

1. What is your immediate reaction after the test?

__________________________________________

2. Did something happen during the drive (ride) that made you feel unsafe or

uncomfortable? If yes, please explain briefly:

__________________________________________

3. How do you feel about the notifications/warnings received during the trip?

1 (Useful) 2 3 (Neutral) 4 5 (Useless) Don’t

know


1 (Pleasant) 2 3 (Neutral) 4 5 (Annoying) Don’t

know

4. Do you have other comments on the notifications/warnings?

__________________________________________

Annex 4: Test conductor form/event diary

The following form may be completed with more system/data to be logged (if no

automatic logging is feasible). It will be completed on ride round level.

Date: ____________________

Participant ID: ____________________

Test site and specific location: ____________________

Test Leader (entity): ____________________

Test conductor ID:

Function(s) tested: ____________________

Evaluation Scenarios (title):

Demonstrator(s): ____________________

Experimental Condition:

(indicate order of the rides: “B=baseline”, “S1= setup

1” and “S2 = setup 2”)

1.__________________

2.__________________

3.__________________

Number of iterations run for the same scenario:

Trip completion status (Success/ Partial success/

Failure):

Reasons for partial success or failure:

Errors (system/driver):

Slips (driver/rider forgets to react or ignores

info/warning):

Compliance with warnings per level of imminence:

Facial/physical reactions:

Think aloud notes (if any):

Liked most, liked least, comments/ recommendations:

Time on task/scenario/event (note of delays):

Free events/ notes/ observations by the test

conductor:

safe strip safe and green sensor technologies for self- … · 2020. 4. 7. · deliverable d6.1:...

Documents