Vehicle probe use cases and test scenarios

Transcription

Deliverable N D1.2.1
Copyright SAFESPOT
Dissemination Level: CO
Contract N. IST-4-026963-IP
SAFESPOT INTEGRATED PROJECT - IST-4-026963-IP
DELIVERABLE
SP1 – SAFEPROBE – In-Vehicle Sensing and Platform
Vehicle probe use cases and test scenarios
Deliverable No. (use the number indicated
on technical annex)
D1.2.1
Sub Project No.
SP1
Sub Project Title
SAFEPROBE
Work package No.
WP2
Work package Title
Needs and Requirements
Task No.
1.2.1
Task Title
Vehicle Probe Use Cases
Authors (per company, if more than one
company provide it together)
Debra Topham, Gary Ford, David Ward (MIRA)
Christian Zott (Bosch), Piero Mortara (MMSE)
Status:
Submitted to EC
Version No:
1.6
File Name:
SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc
Issue Date:
15/09/2006
Project start date and duration
01 February 2006, 48 Months
Page 1 of 143
Copyright SAFESPOT
Revision Log
Version
Date
Reason
1.0
28/6/06
Deliverable structure
created
Debra Topham MIRA Ltd
1.1
28/07/2006
Compiled 1st draft revision
Gary Ford MIRA Ltd
1.2
31/07/2006
Name and Company
nd
2 draft revision
Christian Zott, Bosch
rd
1.3
01/08/2006
1.4
04/08/2006
1.5
24/08/2006
1.6
25/09/2006
3 daft revision, pictograms
added, re-wording
paragraphs
Internal review and general
modifications to document
Updated Scenario Tables &
Use Cases 11_51 & 12_51
4th draft revision based on
Peer reviews
Page 2 of 143
Gary Ford MIRA Ltd
Gary Ford / David Ward MIRA Ltd
Piero Mortara, MMSE
Gary Ford Mira Ltd
Copyright SAFESPOT
Abbreviation List
C2C-CC
Car-to-Car Communication
CCWAS
Co-operative Collision Warning and Avoidance System
DWS
Driver Warning System
EC
European Commission
ETSC
European Transport Safety Council
EU
European Union
EUCAR
European Association for Collaborative Automotive Research
CC
Cruise Control
IST
Information Society Technologies
GPS
Global Positioning System
GST
Global System for Telematics
PReVENT
Integrated project for preventative safety
ITS
Intelligent Transportation System
IVI
Intelligent Vehicle Initiative
IVIS
In-vehicle Information Systems
IVSS
Intelligent Vehicle Safety Systems
LAN
Local Area Network
LCW
Lateral Collision Warning
LDW
Lane Departure Warning
PSAP
Public Safety Answering Points
PLATFORM
A set of technology, which acts as a foundation for real
world applications.
PTW
Powered two-wheeler
RT
Reaction time
SAFELANE
Situation Adaptive system for Enhanced Lane keeping support
SAFEPROBE
In-Vehicle Sensing and Platform
SASPENCE
Safe Speed and Safe Distance
Sintech
SAFESPOT Innovative Technologies
SoA
State of the Art
SuD
System under Design
UMTS
Universal Mobile Telecommunication System
WILLWARN
Wireless Localised danger Warning system
Page 3 of 143
Copyright SAFESPOT
WLAN
Wireless Local Area Network
WP
Work Package
VRU
Vulnerable Road User
V2V-C
Vehicle to Vehicle – Communication
V2I
Vehicle to Infrastructure
SP
Sub Project
Page 4 of 143
Copyright SAFESPOT
Table of contents
Revision Log .........................................................................................................2
Abbreviation List ...................................................................................................3
List of Figures .......................................................................................................6
List of Tables ........................................................................................................6
Executive Summary ..............................................................................................7
1 Introduction .....................................................................................................8
1.1
1.2
1.3
2
Innovation and Contribution to the SAFESPOT Objectives ............................................................ 8
Methodology .................................................................................................................................. 10
Deliverable structure ...................................................................................................................... 11
General Background .....................................................................................12
2.1 SAFEPROBE in-vehicle platform.................................................................................................. 12
2.1.1
Car platform.......................................................................................................................... 14
2.1.2
Truck platform...................................................................................................................... 14
2.1.3
PTW platform ....................................................................................................................... 15
2.2 Synergies with other subprojects.................................................................................................... 16
2.2.1
SP1-SP2................................................................................................................................ 17
2.2.2
SP1-SP3................................................................................................................................ 18
2.2.3
SP1-SP4................................................................................................................................ 18
2.3 Related Research............................................................................................................................ 19
2.3.1
Lateral Safe........................................................................................................................... 19
2.3.2
Saspence ............................................................................................................................... 20
2.3.3
Safelane ................................................................................................................................ 21
2.3.4
Willwarn ............................................................................................................................... 21
2.3.5
Intersafe ................................................................................................................................ 22
2.3.6
GST ...................................................................................................................................... 23
2.3.7
C2C-CC ................................................................................................................................ 24
3
Selection of SAFEPROBE Scenarios ...........................................................25
3.1 Introduction.................................................................................................................................... 25
3.1.1
Definition of SP1 Scenario ................................................................................................... 25
3.2 Methodology for Scenario Title Selection ..................................................................................... 26
3.3 Results of Scenario Title Selection ................................................................................................ 27
4
Description of basic scenarios ......................................................................29
4.1 Introduction.................................................................................................................................... 29
4.2 Methodology of basic scenario description.................................................................................... 29
4.2.1
Driving Scenario Attributes Diagram ................................................................................... 29
5
Use Case methodology.................................................................................34
5.1
5.2
5.3
5.4
5.5
6
7
8
Introduction.................................................................................................................................... 34
Definition of an actor ..................................................................................................................... 38
Description of a use case................................................................................................................ 42
Use case template naming convention ........................................................................................... 42
Use case suggestion list.................................................................................................................. 43
Conclusions ..................................................................................................45
References....................................................................................................46
Annexes........................................................................................................48
8.1
8.2
8.3
8.4
Annex 1 .......................................................................................................................................... 48
Annex 2: Merged Scenario Table................................................................................................... 50
Annex 3: Scenario tables................................................................................................................ 51
Annex 4: SAFEPROBE use cases.................................................................................................. 68
Page 5 of 143
Copyright SAFESPOT
List of Figures
Figure 2.1: High – Level functional diagram of the SAFEPROBE platform.................................. 12
Figure 2.2: Logic architecture of the SAFESPOT platform .......................................................... 13
Figure 2.3: Possible block diagram of the SAFESPOT platform.................................................. 13
Figure 2.4: Volvo FH 4x2 Tractor ................................................................................................ 14
Figure 2.5: Preliminary structure for Volvo demonstrator vehicle ................................................ 15
Figure 2.6: Piaggio “X9 500 Evolution”........................................................................................ 16
Figure 2.7: Activity flow diagram ................................................................................................ 17
Figure 4.1: Driving Scenario Attributes diagram .......................................................................... 32
Figure 5.1: Reference model for probe vehicle systems ............................................................. 35
Figure 5.2: Impacts on fatalities reduction.................................................................................. 36
Figure 5.3: Context diagram........................................................................................................ 39
List of Tables
Table 3.1: Scenario cluster tables .............................................................................................. 28
Table 4.1 : Reduced Scenarios ................................................................................................... 33
Table 5.1 : Example of actors and actor descriptions.................................................................. 42
Table 5.2: Use Cases Index........................................................................................................ 45
Page 6 of 143
Copyright SAFESPOT
Executive Summary
Objective:
SP1 SAFEPROBE is developing the vehicle-based SAFESPOT subsystem that
performs the in-vehicle sensing, the in-vehicle fusion of data into a local dynamic
map of the environment and the communication with other vehicles and
infrastructure subsystems enabling the applications developed by SP4 and SP5.
The aim of task T1.2.1, which this deliverable is reporting the results of, is to:
−
−
−
−
define use cases for the in-vehicle platform subsystem
support the SP4/5 use case definition respecting and partially anticipating
their needs and requirements
collaborate with SP3 to set the context for their technology developments
provide the foundation for the following SP1 requirements specification
Methods / work / document parts / results:
The following steps have been carried out:
1.
2.
3.
4.
5.
6.
7.
Revision of related research (ADAS projects) and their methodology for use
case specification. This led in particular to the definition of a use case
template in tabular form, which has also been adopted by other SP's.
Identification of SP1 system boundary: A major difference of SP1
SAFEPROBE to most of the related research projects is that the system
under design here (the platform) is only a subsystem or component instead
of a total driver assistance or safety system.
Restatement of the definition of actors and application to the in-vehicle
platform: It was found that primary actors for SP1 are only a SP4 subsystem
or SP1/2 subsystems of communicating vehicles and infrastructure.
Definition and identification of a driving scenario and its possible attributes:
This has been summarized in an entity relationship diagram, called a
“scenario attribute diagram”, supporting the scenario and use case
definition.
Compilation, merging, rating and selection of 15 out of 85 representative
driving scenarios.
Specification of 38 representative SP1 use cases based on the 15 selected
scenarios using the tabular use case templates.
Harmonization of the selected scenarios and use cases with esp. SP4
applications and their current use cases.
Interpretation of results:
A set of use cases and driving scenarios of SP4 and SP5 were derived in a
rigorous way, on high-level user needs basis.
Page 7 of 143
Copyright SAFESPOT
Harmonization of these results of the Use Case and Scenarios with SP4 have
been carried out.
The use cases for this subsystem presented in this document in this early project
phase are likely to be subject to change and extension while the application use
cases and the core architecture are under definition.
1 Introduction
The cooperative system approach to improve road safety is based on the
acquisition of in-vehicle information, its processing and distribution towards other
vehicles and the infrastructure.
It will represent an important and innovative step for the definition of an
architecture platform able to enhance:
• The on-board advance driver assistance systems for improving the driving
safety margin
• The on-board information system, by integrating safety related information
and warnings with digital maps.
The platform to be developed by this SP (SAFEPROBE) will acquire in-vehicle
available safety relevant information and exchange it with cooperative
communication partners in local ad-hoc networks such as other vehicles and
roadside units.
The information sources of the platform carrying (probe) vehicles are e.g.:
• vehicle dynamics and body networks
• on-board surround sensors
• occupant safety systems
• global satellite-positioning, static map and navigation systems
This information will be filtered, classified and fused into a standardized local
dynamic map of the vehicle environment (see WP1.3 and WP1.4).
1.1 Innovation and Contribution to the SAFESPOT Objectives
The information contained in the local dynamic map will in particular enable
vehicle based safety applications as developed by SP4.
Public interfaces, messages and protocols will be specified and validated to
achieve inter-operability with other SAFESPOT subsystems.
SAFEPROBE, together with INFRASENS, will develop also an open Data Base
and Data Dictionary. The vehicles will communicate between them and with
Page 8 of 143
Copyright SAFESPOT
public infrastructure using a common technology and protocol (developed in SP3,
according to the Core Architecture developed in SP7).
The applications, running on the vehicles or on the infrastructures, will be able, in
this way, to get information form all possible sources (vehicles, local
infrastructures, distributed infrastructure, etc.) and use them.
The technology lends itself to the task of providing such safety features within
SAFEPROBE and a common platform is key to providing a robust system that all
vehicle manufacturers and O.E.M's can provide to their respective customers
with confidence.
To achieve this objective, the following activities are part of SP1’s tasks:
•
Identification of driving scenarios and definition of use cases (this
deliverable’s task 1.2.1)
•
Deviation of requirements for the in-vehicle platform from the use
cases (task 1.2.3)
•
Definition of a flexible and configurable on-board architecture
•
Specification of useful vehicle internal data (vehicle sensors, surround
sensors, geo-position module, etc.) as a result of an in-vehicle system
analysis, started in task 1.2.2.
•
Specification of useful vehicle external data (data from neighboring
vehicles and infrastructure over communication system) for example in
terms of interface definitions (content and format) and of requirements
(e.g. accuracy, availability, latency)
•
Definition of modalities for receiving and transmitting data collected
from probe vehicles shared among all vehicle manufacturers
•
Definition of a common standard shared and interoperable of the data
coming from probe vehicles and infrastructure
•
Specification of data fusion algorithms (including data storage) for
“internal vehicle data”
•
Specification of data fusion algorithms for “cooperative data” (internal
and external) considering data requirements (e.g. accuracy,
availability, latency)
•
Definition of test cases and analysis of test results.
Page 9 of 143
Copyright SAFESPOT
The SAFEPROBE multi-system platform is a logical extension of the on-board
sensor data fusion activities and it will be built on the availability of on-board
sensors and cooperative systems for the safe integration of vehicles and
infrastructure.
1.2 Methodology
The requirement of Task 1.2.1 within SP1 is to define the use and test cases
under which the vehicle platform will be required to operate in order to provide
the necessary data for the applications that will be implemented by SP4 and
SP5.
Since the overall aim of the SAFESPOT project is to provide warning and
advisory information to the driver in order to decrease the number of safety
related accidents, the focus of the use cases will be driving scenarios where the
SAFEPROBE system could help prevent a safety related accident from occurring
using data gathered from sensors onboard the vehicle.
Ideally these scenarios would have been derived from use cases and the
corresponding driving scenarios as specified by all SAFESPOT applications, i.e.
the vehicle based applications (SP4) and the infrastructure based applications
(SP5).
For the following reasons this approach could not be taken:
1. The SP4 and SP5 use case specification was not scheduled to be finished
during the time allocation for this task in the project plan. Only a
preliminary set of applications and outlines of use cases were given.
2. The European core architecture specification for cooperative systems
based on ad-hoc networking is still under development, e.g. by the major
IPs SAFESPOT and CVIS as well as the Car-to-Car-Communication
Consortium. Therefore the In-vehicle platform boundary cannot be
regarded as fixed.
3. Even if a ‘complete’ set of use cases and driving scenarios of SP4 and
SP5 were derived in a rigorous as possible way on high level user needs,
accident data and technology analyses (see fig 2.2.1 below), a true invehicle ‘platform’ should be open and flexible to support use cases of
future safety and other applications, e.g. those of CVIS. Thus the objective
of this task should be to find a number of representative use cases that
are based on the experience of developers rather than found by formal
analysis methods alone.
Page 10 of 143
Copyright SAFESPOT
Therefore the following approach based essentially on proposal and voting of the
SAFEPROBE’s partners has been taken to complete Task 1.2.1:
1. Revision of related (ADAS) projects use cases and driving scenarios
2. Definition of a use case template in tabular form
3. Identification of SP1 system boundary by definition of primary/secondary
actors and further interacting entities
4. Definition of a driving scenario and its possible attributes, which were
summarized in a so-called “scenario attribute diagram”
5. Compilation, merging, rating and selection of 15 out of 85 representative
driving scenarios.
6. Specification of 38 representative SP1 use cases based on the 15
selected scenarios using the tabular use case templates.
7. Harmonization of the selected scenarios and use cases with esp. SP4
applications and their current high level use case descriptions
A more detailed explanation can be found in chapters 3, 4 and 5.
1.3 Deliverable structure
The remainder of this document is organised as follows.
In chapter 2, background information on the SAFESPOT architecture component
addressed in SAFEPROBE (the in-vehicle platform) can be found. Section 2.1
contains the preliminary view of the logic and common hardware architecture for
the in-vehicle platform along with some first hardware considerations on the
platforms for Cars (2.1.1), Trucks (2.1.2) and PTW’s (Powered two wheelers,
2.1.3).
Section 2.2 highlights the synergies with other subprojects.
Section 2.3 focuses on related research projects and consortia such as Willwarn,
Intersafe, Lateral Safe, GST, and the C2C-CC.
A list of detailed scenarios can be found in chapter 3 that have been derived by
the methodology described above (1.2) along with design tools / methods to
produce the results in section 3.3.
A description of basic scenarios is detailed in chapter 4.
In chapter 5 we describe the Use Case Methodology and list actor definitions
along with Use Cases that have been provided by collaborative partners of the
SAFEPROBE work partners consortium.
Chapter 6 concludes the document and highlights the results achieved during the
work on requirements and post conclusions from our discussions, which then
Page 11 of 143
Copyright SAFESPOT
leads onto the next sub project SP2 architecture, and the actual development
work.
Section 7 is a reference chapter for all material used and or referred to within this
document.
Section 8 provides the Annex section of this report.
2 General Background
2.1 SAFEPROBE in-vehicle platform
The following Figure 2.1 shows a high-level functional diagram of the SAFEPROBE
platform.
Figure 2.1: High – Level functional diagram of the SAFEPROBE platform
SAFEPROBE has the main task to develop the “in vehicle platform”. The platform
should support at least all the SAFESPOT applications and will be common for
the different type of vehicles (different cars, trucks, motorcycles) that will be used
in the demonstration and validation phase. Taking into account the high degree
of innovation of SAFESPOT a flexible platform able to easily implement new
applications and to easily interface specific modules is required. The platform
architecture as depicted in the technical annex is reported in Figure 2.2.
A first possible realisation considered is the one reported in Figure 2.3.
A hypothesis of using PC modules is assumed.
Page 12 of 143
Copyright SAFESPOT
It should be noted that the CVIS Project is preparing an on-board platform
dedicated to cooperative applications (traffic efficiency and safety) of which the
platform represented in fig. 2.1.2 could be a subset. A joint analysis activity has
been started in order to provide requirements from SAFESPOT to CVIS and to
verify if the CVIS platform may be used totally or partially in the SAFESPOT
project timeframe.
Figure 2.2: Logic architecture of the SAFESPOT platform
power train
CAN
comfort
CAN
surround
sensor IF
(CAN)
vehicle
gateway
ECU
(vehicle
specific)
Nav/map IF
SAFEPROBE
standard IF,
fusion,
e.g. private CAN msg generation
PC
Local Map
IF
(to application)
LAN
power supply
GPS raw IF
added HW
Ad-hoc
network proc.
(routing, buff,
security,…)
PC
car,
truck,
motorcycle
IF: interface
WLAN IF
Figure 2.3: Possible block diagram of the SAFESPOT platform
Page 13 of 143
Copyright SAFESPOT
The vehicle platform should be a suitable embedded module that can be mounted in
cars, trucks and motorcycles.
2.1.1 Car platform
Vehicles have normally one or more CAN buses where standard data (such as
speed, steering angle) are available. For the purpose of the demonstrators new
sensors (e.g. a laser scanner) could be added to one of these CAN buses or
perhaps using a new bus dedicated for this purpose. This could depend on the
specific characteristics of the considered vehicle and on the data bus capacity
already used by the existing data.
For this reason it is important to have a vehicle gateway that is able to deal with
the specifics of the single vehicle and to provide a unified protocol and set of data
to the other blocks of the platform.
Other specific items for car mounting are the compliance with standard car
supply range (nominal +12V) and additional power consumption requiring no
more than an upgraded battery or at most one supplementary battery which in
turn may require a larger alternator to supply the correct current in relation to the
charge rate required by upgraded battery.
2.1.2 Truck platform
The Volvo vehicle platform in SAFEPROBE will be a Volvo FH truck (Figure 2.4).
The base vehicle is equipped with a standard Radar based ACC system in
combination with an I-Shift automatic gearbox.
Figure 2.4: Volvo FH 4x2 Tractor
Page 14 of 143
Copyright SAFESPOT
The sensors that will be installed additional to the standard SAFESPOT system
will be:
Radar ACC sensor will be provided by Volvo.
LIDAR sensor will be provided by IBEO.
Additional sensors such as friction estimation, lateral position etc may be
available and can be added into the gateway functionality.
They will mainly be used to implement the SP4 SCOVA applications.
Figure 2.5: Preliminary structure for Volvo demonstrator vehicle
Figure 2.5 shows the preliminary structure for the Volvo demonstrator vehicle.
The Gateway is a rapid prototyping system for software development.
The Dynafleet system is a Volvo communication platform providing GPRS and
the possibility to add other functions.
Trucks have similar requirements to cars, but with the following specific features:
The power supply is nominal 24V therefore it may be possible to design the car /
truck platform with the same hardware and feature content, but with the design
including some type of Automotive smart power supply that will satisfy the needs
of both a Car and Truck power requirements.
2.1.3 PTW platform
The PTW platform for SAFESPOT project (SAFEPROBE – SP1) will be a Piaggio
“X9 500 Evolution”.
The base vehicle characteristics are:
Single-cylinder 460cc 4-stroke engine
Page 15 of 143
Copyright SAFESPOT
Continuous variable transmission
Water-cooled
Fuel electronic injection
ABS system
The vehicle also has an external temperature sensor and a tilt sensor.
Figure 2.6: Piaggio “X9 500 Evolution”.
Motorcycles have these further Specific features:
-
Small size
Power Supply 6V
Space is limited to fit module design
Platform design has to be small enough to allow the on-board mounting into PTW
that may result in smaller feature content compared to that of a car orTruck.
2.2 Synergies with other subprojects
In the analysis phase a significant effort has been dedicated at Integrated Project
level to analyze the relationship among different subprojects in order to obtain a
common harmonized process in the generation of needs, use cases and
Page 16 of 143
Copyright SAFESPOT
requirements of each subproject. This task has been lead by SP7 (SCORE –
SAFESPOT Core Architecture) with the support of all subprojects and will be
described in detail in the deliverable D7.2.1 “Core architecture requirement”.
Specifically the diagram in Figure 2.7, that will be part of that document, defines
the main relationships among subprojects.
Guidelines
Guidelines
(SP7)
(SP7)
High Level
Description
High Level User Needs
User\Actors
User\Actors
Identification
Identification
SP1-2-3-4-5
SP1-2-3-4-5
Accident data Analysis
Accident data Analysis
+SoAAnalysis
AnalysisSP4-SP5
SP4-SP5
+SoA
Technology analysis
Technology analysis
SP1-SP2-SP3
SP1-SP2-SP3
Scenarios
User Needs
Use Cases
High Level Stakeholders
High Level Stakeholders
Identification
Identification
(SP7)
(SP7)
(SP1-5)
Tech Scenarios
Sp1-SP2-SP3
Common Basic
Scenarios SP4-SP5
User (of the Subsystem)
Needs (SP1-2-3-4-5)
Use Cases (SP1-2-3-4-5)
Requirements
System Requirement SP5
Figure 2.7: Activity flow diagram
2.2.1 SP1-SP2
Both SP1 and SP2 have the task to develop the platform respectively for the
vehicle and infrastructure systems guaranteeing:
The communication among different nodes of V2V and V2I network structure
incorporating the results of SP3.
The correct hosting of algorithms for accurate positioning and local dynamics
map as provided by SP3 acquisition, conditioning and fusion of sensor data and
subsequent provision to applications hosting of the application software.
Based on these considerations, further to the use of the network protocol
provided by SP3 and hosting the common algorithms and data structure for
positioning and mapping, the inter-task SP1-SP2 will consist in the common
definition of the data to be exchanged according to the requirements of
applications that will run on the vehicle and infrastructure side.
Page 17 of 143
Copyright SAFESPOT
2.2.2 SP1-SP3
SP3 has the key role to provide algorithms and technological solutions for:
–
–
–
Ad hoc networking
Accurate positioning
Local dynamic maps
SP3 has the double task to explore several new technologies but also to select
and to develop (or to adapt) the ones to be used for SAFESPOT demonstration
and validation.
SP1, as already underlined, must create a platform incorporating the SP3 results
and able to host the algorithms developed by SP3.
For this purpose a mutual exchange of information is planned in order to cross
validate the practical feasibility of proposed solutions in the project timeframe.
2.2.3 SP1-SP4
SAFESPOT structure comprises two subprojects devoted to applications: SP4
and SP5
SP4 – SCOVA has the task to analyze, specify, develop and validate applications
based on V2V and V2I communication. In SCOVA it is supposed to have
available a high performance on board platform performing data fusion and
placing correctly on the local dynamic map the elements detected by on board
sensors or received by other vehicles or infrastructure nodes in real time.
SP5 – COSSIB has the task to analyze, specify, develop and validate
applications based on V2I communication. It may correspond to a first step of the
future deployment when V2V has not yet a good level of penetration while V2I
may already provide a valuable degree of road safety improvement. In this case
the intelligence is mainly concentrated on the infrastructure side and the on
vehicle platform is supposed to transmit on board data to infrastructure and to
provide to the driver the information elaborated by the infrastructure.
Taking into account these considerations SP1 should provide a platform able to
run SP4 applications and to deliver information warning to the driver according to
SP5 messages. In this sense the hardest requirement to SP1 will derive from
SP4 applications, while the SP5 requirements will be lighter and consequently it
is assumed that a platform able to run SP4 applications will be usable also for
SP5 demonstration and validation.
Up to now a first definition of SP1 – SP4 boundaries and data exchange has
been defined, however a higher detail is needed. This is the task of subsequent
requirements and specifications phases of the project.
Page 18 of 143
Copyright SAFESPOT
2.3 Related Research
The definition of use cases and scenarios constitute a significant part of the
system specification and system design development. The approach followed by
similar vehicle related EU projects was reviewed and considered while
developing the SAFEPROBE use case and scenario approach. In this section a
brief review is made concerning the methodology of some projects as indication
of at the categories of active safety automotive applications and communication
(V2V and V2I) related projects.
Active Safety
In order to demonstrate the methodologies of the approach usually followed
during the design of these kinds of systems specific Active Safety Projects
were selected for brief presentation in this paragraph.
2.3.1 Lateral Safe
The LATERAL SAFE subproject introduces a cluster of safety applications in
order to prevent lateral/rear area related accidents and assist the driver in
adverse or low visibility conditions and blind spot areas. LATERAL SAFE
applications are built in a common multi-sensor platform and include:
•
•
•
Lateral and Rear Monitoring system,
Lane Change Aid system,
Lateral Collision Warning system
A main deliverable [1] that includes the requirements and specifications is the
key working document that includes information related to the use case and
scenarios definition. This deliverable includes:
- User requirements identified from accident databases, questionnaires and
previous research experience,
- The state of the art analysis of similar applications and sensors used in these
applications
- The functional requirements, the all around functions and the functional
specifications of LATERAL SAFE applications.
As the aim of reduction and avoidance of rear and lateral area related accidents
are the main goal of this project, accidentology was identified as the main step
towards use cases definition. The review of extended accident databases has led
to detailed area coverage with specific percentage of accidents occurring in each
sector, something that assisted among others to sensor selection, as well.
The main parameters selected for LATERAL SAFE use cases together with their
fields are:
Page 19 of 143
Copyright SAFESPOT
•
•
•
•
Driver: Gender, Age.
Vehicle: Speed.
Other vehicles: Pre-crash scenario.
Environment: Light condition, Atmospheric condition, Roadway surface
condition, Roadway function, etc.
Moreover, the further steps included in the process were
•
•
•
•
•
•
Survey on experts’ opinion (by means of questionnaires answered by
project partners)
Survey on users’ opinion (literature study based on results from similar
research projects)
Prioritisation of parameters for the LATERAL SAFE use cases
According to accident analysis
According to experts
According to user requirements
2.3.2 Saspence
SASPENCE system is a driver assistance system that provides information to
the driver related to the safe speed and safe distance to keep, depending on
external scenarios and conditions. Two of this subproject’s deliverables contain
the methodology used: deliverable on application scenarios, safety criteria and
customers benefits analysis [2] and the deliverable of functional requirements [3].
The methodology followed in [2] was:
•
•
Secondary research (literature review) on the impact of speeding and
headway related accidents (accident analysis) and to review both
human performances in speeding and headway (drawing from Human
Factors and ITS research) and previous approaches to Intelligent
Speed Adaptation (ISA) technologies.
Primary research has been performed by submitting two different
questionnaires, one to a panel of 34 ITS domain experts (members of
SASPENCE subproject, IP PREVENT, IP AIDE), and the other to a
sample of 301 potential customers.
The functional requirements work found the requirements that should be taken
into account during system development. These requirements are referring to
functional needs that SASPENCE is required to comply with. The functional
analysis methodology was based on the study of users’ needs and expectations
on the system for different situations of use. Every function is then described in
terms of technical criteria and data and the situations of use of the system were
defined which in turn led to system functions. The main and imposed functions
Page 20 of 143
Copyright SAFESPOT
were described. Main functions are those for which the system has been
developed. They correspond to the system usefulness and to the contribution to
subjective users’ satisfaction. Imposed functions come from the system existence
and from the main functions. They contribute to the subjective users’ satisfaction
and they refer also to the integration faculties of the system on its surrounding.
2.3.3 Safelane
Another PReVENT subproject is SAFELANE with goal to develop a situation
adaptive system for enhanced lane keeping support. Deliverable 31.31
“Specification Catalogue” contains the specification catalogue and describes the
general system requirements arising from the state-of-the-art in accidentology,
traffic, vehicle technology, and system technology. The project’s use cases have
been defined as a result of an analysis of critical driving situations and include
several situations of interest to the application SAFESPOT: lane departure,
critical driver conditions, critical environmental conditions, critical road conditions,
critical infrastructure conditions, critical vehicle conditions, critical traffic
conditions, lane keeping support, integration and unification
2.3.4 Willwarn
The objectives of WILLWARN are:
•
•
To develop a wireless localised danger warning system to provide
warnings to the driver and alerts to other vehicles.
To develop on-board hazard detection and in car warning management
which will decentralise warning distribution by communication.
The hazard types covered by this project are:
•
•
•
•
Hazard type = own car as an obstacle; reason = Own accident car
failure detected by crash sensor, vehicle diagnosis, warning flashlights,
WILLWARN switch.
Hazard type = Obstacles; reason accident, traffic jam, vehicle, living
thing, object; detected by emergency breaking/avoidance, manoeuvre
and or obstacle sensor warning flashlights, WILLWARN switch.
Hazard type = reduced visibility; reason = weather and darkness:
detected by lights, wipers, rain sensor, temperature and speed profile
(CAN and vehicle data).
Hazard type = reduced friction; reason = weather or else; detected by
lights, wipers, rain sensor, temperature, speed profile, driving
dynamics
Page 21 of 143
Copyright SAFESPOT
•
Hazard = other; road works, ghost driver, emergency vehicles; speed,
braking and steering profiles, special sensors special digital map,
beacons infrastructure.
Other hazards:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Road
Road side lights off
Steep turn
Train crossing
Road works
Road conditions
Special vehicles
Road with no side barriers
Narrow road
Altered right of way
Wrong way driver
Road toll
Speed limit
Continuous steep turns
No warning availability
Entering a tunnel
Low bridge
2.3.5 Intersafe
The main objective of the INTERSAFE subproject is to improve safety and to
reduce (in the long term avoid) fatal collisions at intersections. Drivers shall be
prevented from missing red lights at intersections or ignoring stop signs.
Furthermore, drivers will be informed in case of turning to avoid collisions with
other vehicles. This will be achieved by use of infrastructure to vehicle
communication and path prediction of other road users.
On available test vehicles, there will be driver-warning functions implemented.
Speed recommendations for the driver, when approaching an intersection will be
given, depending on the intended colour of the traffic light when crossing the
intersection or turning at the intersection, so that there is no risk of collision.
The trajectories of the ego vehicle and other nearby vehicles will be predicted by
using a Laser scanner and a vision sensor.
An additional driving simulator approach allows the development of active safety
applications with state-of-the-art-technology as well as technology that will be
available in the future. This parameterised technology can easily be included in
various configurations. Thus, the system functionality and the system-specific
Page 22 of 143
Copyright SAFESPOT
potential for accident prevention and accident mitigation achievements can be
proven in a quantitative, risk-free and reproducible manner.
2.3.6 GST
The GST project aims to find an agreement on distributing software and data in a
controlled, secure way to mobile devices according to an open and standardized
architecture. Technology subprojects are addressing open systems, certification,
security and service payment, whereas the service oriented projects focus on
rescue, safety channel and enhanced floating car data applications. E.g. the
focus of the RESCUE sub-project is to accurately assess the type of emergency
and resources required to provide the appropriate response to a critical accident.
RESCUE ensures that information about the accident will be available in the
emergency vehicles and that they are able to quickly and safely reach the
accident scene. To ensure this, the sub-project will complete the in-vehicle
emergency call chain, provide guidance to the emergency service to the scene of
the accident by accurate locations, trial blue corridors and coning systems
(vehicle-to-vehicle communication) thus warning other road users of the
approach of the emergency services. In addition, the emergency response can
greatly benefit from an exchange of information between the rescue units and
control rooms (police, hospitals etc.).
GST RESCUE aims to:
•
•
Optimise the initialisation of in-vehicle eCall via an expert system
Optimise the eCall service chain by ensuring that in-vehicle data first
reach the emergency centres and then the emergency vehicles.
After the emergency vehicles receive the proper in-vehicle accident information,
a hybrid navigation solution - together with a "blue corridor" system notifying road
users of the emergency vehicles' approach - ensure that the emergency vehicles
reach the scene of the accident as quickly and safely as possible. The safety of
the accident scene will be ensured with a "coning" system warning approaching
road users about the accident. After the emergency vehicles leave the scene,
remote reporting and transfer of information such as patient data to hospitals will
be made possible.
GST RESCUE focuses on the following technical objectives, and will:
1. Create the specification and support the development, testing and validation of
an expert system used in the in-vehicle system to determine that an accident has
occurred.
Page 23 of 143
Copyright SAFESPOT
2. Create the specification and support the development, testing and validation of
the interface between the 1st and 2nd stage PSAPs (public safety answering
points).
3. Specify, test and validate the use of a common vehicle protocol as agreed
within GST for the interface between PSAP2 and the emergency vehicle.
4. Specify and support the development, testing and validation of a hybrid
navigation solution providing effective guidance of the emergency vehicles to the
accident scene.
5. Specify and support the development, testing and validation of accident
reports to be generated from rescue vehicles and their transmission to the
emergency authority control rooms.
6. Specify and support the development, testing and validation of a data link
among ambulances and hospitals in order to provide a technical and remote aid
(such as a tele-diagnosis) to the paramedics in the rescue vehicle.
7. Specify and support the development, testing and validation of the interface
that enables hospitals to receive and process data from the accident scene and
medical response vehicles.
8. Specify and support the development, testing and validation of the rescue
vehicle to vehicle data communication and "here I come" information (Blue
corridor) to divert other vehicles away from the emergency services' route and
the accident scene, as well as the provision of "Virtual" coning systems for
accident scene safety.
2.3.7 C2C-CC
The goal of the Car2Car Communication Consortium is to create a European
industrial standard for future communicating cars spanning all brands.
The radio system for the Car2Car Communication is derived from the standard
IEEE 802.11, also known as Wireless LAN. As soon as two or more vehicles are
in radio communication range, they connect automatically and establish an ad
hoc network.
As the range of a single Wireless LAN link is limited to a few hundred meters,
every vehicle is also a router and allows sending of messages using a multi-hop
scheme to further vehicles.
The routing algorithm is based on the position of the vehicles and is able to
handle fast changes of the ad hoc network topology. The onboard vehicle system
Page 24 of 143
Copyright SAFESPOT
then determines what action to take whether it is by informing the driver or by
activating safety systems installed on the vehicle.
This will lead to a reduction in traffic risks to the road user.
3 Selection of SAFEPROBE Scenarios
3.1 Introduction
The process of selecting SAFEPROBE scenarios will be explained within the
following 2 chapters.
Ideally the selection of scenarios would have been based upon scenarios defined
by the other sub-projects within SAFESPOT such as SP4. Due to the project
schedule SP1 carried out work in parallel with SP4 (and the other sub-projects)
that was subsequently harmonized. See further considerations to this subject
already given in section 1.2.
3.1.1 Definition of SP1 Scenario
A SP1 scenario sets environmental and driving context for all specifications
(functional, performance) at a particular spot. The spot can be at or between
junctions (i.e. at a link). For SP4 the spot may change while driving. For SP5 usually
a fixed spot (e.g. an intersection) will be considered.
The scenario description includes a description of the
–
–
–
spot and its geometry (e.g. extension, position and connectivity of
lanes)
traffic & environmental conditions
traffic participants and their behaviour
It usually does not include any feedback of SP4/5 systems (influence of
participants by SAFESPOT application) and can describe a situation of normal
driving (no trigger of any SAFESPOT intervention) or before any event (critical or
just increasing awareness, e.g. imminent accident, collisions, congestion) takes
place. It is not an accident description (collisions, cause, harm of participants,),
but maybe assessed due to its threat potential or required user response (e.g.
action, attention, awareness).
A scenario therefore
–
is an essential part of all SP1-5 use cases
Page 25 of 143
Copyright SAFESPOT
–
–
–
is a meeting point for platform and application development
enables analysis of sensing technologies
can be found either by accident or technology analyses
3.2 Methodology for Scenario Title Selection
The scenario selection process comprised the following steps:
1. Proposal of scenario titles by each collaborative work partner essentially
based on related project knowledge and experience
2. Grouping of the scenario titles into 9 scenario cluster entitled (see also
table below)
a.
b.
c.
d.
e.
f.
g.
h.
i.
normal driving
road surface condition change
lane traffic condition change
traffic condition change
weather/visibility change
approaching intersection
significant road geometry change
lane change
abnormal driver behavior / vehicle
2. Further addition of scenario titles to the scenario cluster by partners
3. Merging of scenario titles where an overlap occurred (85 merged
scenarios)
4. Each partner rated the merged scenario titles according to:
a.
b.
c.
d.
e.
essential SAFEPROBE scenario (top priority)
SAFEPROBE relevant
Nice to have
Not specific enough or too general
not appropriate to SAFEPROBE
5. Assessment on the rating applying the following rules (the results are
shown in column “rating assessment”, Annex 3.)
•
Priority => all partners agree that this scenario is priority 1
•
Priority L1 => Partners gave a rating which was a mixture of 1’s and
2’s, however the Mode is 1
Page 26 of 143
Copyright SAFESPOT
•
Priority L2 => Partners gave a rating which was a mixture of 1’s and
2’s, however the Mode is 2
•
Priority L3 => Partners gave a rating which was a mixture of 1’s, 2’s
and 3’s, however the Mode is 1
•
More info & reject => the scenario received mixed rating and included
both a rating of 4 and 5
•
More info => the scenario received mixed rating partner(s) rated this as
requiring more info. In order to give it a rating
•
Reject flag => the scenario received mixed rating partner(s) gave a 5
rating i.e. rejecting it
The scenarios which resulted in an assessment rating of Priority, L1, L2 and L3
have were compiled and can be found in the Basic Scenario table in section 3.3.
3.3 Results of Scenario Title Selection
85 scenario titles resulted from the scenario-merging step 4. Of these, 35 were
selected as the most relevant to SAFESPOT, see step 6.
These scenarios were then prioritised and 14 scenarios with the highest priority
were selected.
Due to the reasons already pointed out in Section 1.2, SP1 is focusing on a
preliminary list of 15 scenarios for the deliverable.
These selected scenarios have been assessed to have the highest level of
priority.
Page 27 of 143
Copyright SAFESPOT
Table 3.1: Scenario cluster tables
Page 28 of 143
Copyright SAFESPOT
4 Description of basic scenarios
4.1 Introduction
Up to this point the collaborative work partners have compiled only scenario titles
and selected those deemed to be top priority (see the following tables reported in
Annex 3).
Note that the term “ego vehicle” is used to denote a vehicle equipped with the
SAFEPROBE system and from the perspective of which the scenarios are
described. Other equivalent terms that may be considered are “my vehicle”,
“own vehicle” or “this vehicle”. Similarly terms such as “ego lane” refer to the
lane of the road in which the “ego vehicle” is travelling.
This chapter concentrates on the completion of allocated scenario titles to
detailed scenario descriptions using a Basic Scenario Template.
4.2 Methodology of basic scenario description
The basic template is completed using the scenario attribute diagram shown in
Figure 4.1 and was completed following the Flow diagram in Appendix 1.
Essentially the template captures the selection of attributes from the attribute
scenario diagram, which can be used to define the description of the basic
driving scenario.
Basic scenarios allowed us to focus on important situations and present SP1
focus to SP4.
In order to provide a basis for the description of the driving scenarios a driving
attributes diagram was derived through discussion with partners.
4.2.1 Driving Scenario Attributes Diagram
Following the definition of a SP1 scenario (see 3.1.1) a scenario description
should specify the
–
–
–
spot and its geometry (e.g. extension, position and connectivity of
lanes)
traffic & environmental conditions
traffic participants and their behaviour
It can be found either by accident or technology analyses. Consequently some
accident data bases, e.g. GIDAS (German In-Depth Accident Study, further ones
see in the SP5 D5.2.4 accident data review), have been scanned at first by
Page 29 of 143
Copyright SAFESPOT
partners with respect to its structuring. The driving environment has been
specified by defining some general driving attributes such as:
Area types
• Motorway/highway
• Urban
• Rural
Weather Conditions
• Fog
• Rain
• Wind
• Snow, Ice
Road structure
• Tunnel
• Bridge
Road segment / spot geometry
• Curved road
• Straight road
• Intersection/junction
• Roundabout
• Pedestrian crossing
– Signalled
– Un-signalled
Visibility conditions and diurnal cycle
• Day
• Night
• reduced (fire/smoke/blinded by sun)
General traffic conditions
• dense
• free
• congestion
Further accident attributes describe the behaviour of the traffic participants such
as their
•
intended and actually performed manoeuvres (turns, lane change, stop,
etc)
• rule violations (running a red light…)
• distractions (blinded by sun, low visibility, drug abuse…)
In order to support the definition of detailed basic scenarios all these attributes
and their dependencies have been integrated into an entity relationship diagram.
The two relationships found between the entities = attributes are
Page 30 of 143
Copyright SAFESPOT
•
•
attribute A consists of attributes B and C and … (aggregation)
attribute A can be one of B or C or. …(inheritance)
This scenario attribute diagram has also been distributed to SP2, SP4 and SP5
where it has also been used for use case specification purposes.
In Annex 3 the scenario tables are reported.
Page 31 of 143
Copyright SAFESPOT
Figure 4.1: Driving Scenario Attributes diagram
Page 32 of 143
Copyright SAFESPOT
Number
Partner
Contribution
Scenario
1
Ego turn, approaching obstacle (VRU, load, slow
MIRA
vehicle, jam) or crossing its path
2
Oncoming vehicle in wrong direction in ego lane
MIRA
3
Obstacle (VRU, load, slow vehicle, jam) in ego lane
BOSCH
4
Ego vehicle runs a red light or stop sign
BOSCH
5
Ego vehicle approaches vehicle fire/smoke section
CRF
(inside a tunnel, on motorway)
6
Ego vehicle - Lane departure (incl. off road)
CRF
7
PTW falling on roadway
Piaggio
8
Ego (PTW) overtaking OV while OV making a turn
Piaggio
9
Ego vehicle carrying dangerous goods
VOLVO
10
Ego vehicle meets dangerous goods vehicle
VOLVO
11
Ego vehicle approaching road works - restricted lane MMSE
usage
Emergency vehicle approaching - blue corridor
required
MMSE
12
13
Ego-vehicle starts braking very hard while other
ICCS
vehicle (PTW) is following
14
Overtaking ego on collision path with oncoming
vehicle
ICCS
15
Ice Warning
MIRA
Table 4.1 : Reduced Scenarios
Page 33 of 143
Copyright SAFESPOT
5 Use Case methodology
5.1 Introduction
Background to selection of use case methodology (i.e. UML versus
Template approach)
The decision to use template approach to define the use cases in preference to
UML (see a detailed description on what is UML in the paragraph below) was
based on several discussions with consortium partners and that due to time
constraints and the availability of software packages which consortium partners
had access to, it was deemed the best solution at this stage of the project.
This particular sub project is concerned with Vehicle Probe Use Case definitions
not software development at this stage, although UML approach would allow for
easier tracking of changes and traceability.
Not all collaborative partners had the necessary software to enable them to
follow the UML approach and so it was decided to follow the template approach.
It was decided by partners that the template method although not as graphically
pleasing it captures as much if not more detail than the using the UML approach.
This also allows contributions to be easily completed by partners filling in an
approved template.
Use case methodology using UML (Unified Modeling Language) approach
The Unified Modeling Language (UML) is a standard language for specifying,
visualizing, constructing, and documenting the artifacts of software systems, as
well as for business modeling and other non-software systems. UML represents
a collection of best engineering practices that have proven successful in the
modeling of large and complex systems. UML is a very important part of
developing object oriented software and the software development process. UML
uses mostly graphical notations to express the design of software projects.
Using UML helps project teams communicate, explore potential designs, and
validate the architectural design of the software.
Based on the before mentioned description, UML has quickly become the defacto standard modelling language in the software industry.
UML is a truly universal language because it can be applied in many areas of
software development.
The Use Case Driven nature of modelling with UML ensures that all levels of the
model trace back to elements of the original functional requirements. This
traceability between models comes without the extra effort creating and
Page 34 of 143
Copyright SAFESPOT
maintaining a 'traceability matrix’, which can be a complex and time consuming
job.
The result is that the impact of a requested change can quickly be estimated. A
change in requirements can be traced though analysis and design models into
those components affected and even lines of code. The code affected can then
be traced back to the requirements and total regression testing effort calculated.
The following is the reference model for probe vehicle systems.
This model consists of elements that are considered to be essential and
fundamental to various forms of probe vehicle systems.ref ISO/TC 204 N803.
Data
(Communication)
Vehicle
Process
*
Gather data about
the vehicles and its
environment
Information
*
*
*
users
Application
Providers
Collect data from
vehicles, store and
processe the data
vehicles
Utilize the
information
Note) Depicted by UML (Unified Modeling Language)
‘*’ denotes multiplicty (0 or more)
.
.
.
etc.
Figure 5.1: Reference model for probe vehicle systems
Use case methodology using a Template approach
This particular sub project is concerned with Vehicle Probe Use Case definitions
not software development at this stage, although UML approach would allow for
easier tracking of changes and traceability.
Not all collaborative partners had the necessary software to enable them to
follow the UML approach and so it was decided to follow the template approach.
It was decided by partners that the template method although not as graphically
pleasing it captures as much if not more detail than the using the UML approach.
This also allows contributions to be easily completed by partners filling in an
approved template.
Using this method the captured data is as detailed as using the UML approach
In SP1 D1.2.1 we are dealing with Vehicle Probe Use Case definitions and by
using this method it has allowed the contributions from consortium partners to be
compiled much quicker i.e. an approved template can be filled in by partners who
do not need UML modeling skills thus resulting in a far greater response from the
consortium partners.
Page 35 of 143
Copyright SAFESPOT
Criteria for SP1 use cases SAFESPOT Safety margin Concept
Figure 5.2: Impacts on fatalities reduction
The aim of the SAFESPOT safety margin concept is to provide warning and
advice to the driver in the time window shown in Figure 5.2 to enable the driver to
take any necessary action to avoid potential danger in ‘good time.’
Analysis and specific parameterisation of the Safety Margin in SP4-SCOVA
subproject will provide the required latency from an event detected to the local
dynamic map update (The extention of the Green area).
Applications, which provide immediate or autonomous intervention and fall within
the millisecond region of Figure 5.2, are considered to be outside the scope of
SAFESPOT.
This approach is taken in SP1 since the latency between detecting a potential
obstacle/accident to providing a local dynamic map update is estimated.
Therefore, for a vehicle having detected an accident/obstacle with only a time to
danger/collision (accident) in the region of milliseconds (ms), providing advice
and warning to the driver is not relevant for SAFESPOT.
However, given the latter scenario, if the time window between detection and
danger was in the region of seconds, then the detecting vehicle can provide both
warning and advise to the driver in ‘good time’.
Use cases fitting the safety margin concept
Application goal(s):
To provide advice and warning to drivers through probe vehicles and or
infrastructures giving the driver enough time to take appropriate action regarding
the scenario he or she finds themselves in and is not geared towards (immediate
or even autonomous) action i.e. specifically not for removing control of the
vehicle from the user.
Good example:
Page 36 of 143
Copyright SAFESPOT
Potential collision with a vehicle or object not in field-of-view i.e. around the
corner. Early Ego warning based on data from cooperative COM partners (probe
vehicle or VRU)
Good example:
Increased Ego safety by communicating with others (typical PTW use cases:
PTW increases awareness of close vehicles about its presence and intended
manoeuvre, e.g. PTW overtaking)
Bad example:
Low adhesion on road surface detected -> Ego driver warning? Very short
reaction time, warning useless, immediate (at best autonomous) action required > ESP
Bad example:
Close obstacle already in Ego's environmental perception sensors field-of-view > immediate (at best autonomous) action required -> emergency brake
Innovative solution
Using a distributed sensing and a cooperative approach in specific use case
scenario’s no warning is possible with autonomous systems that need to react
immediatley including non communicating ENP, VDM, MAP (look around the
corner, out of F.O.V)
Prototyping of SAFESPOT seems feasible
The process time for platform to take usable data and by employing data fusion
techniques to create and or send a message will be significantly below second.
However this timing has not been clarified / quantified as yet and is purley an
assumption at this phase of the SAFESPOT project based on the following
criteria:
•
Sufficient data availability (latency, bandwidth) and reliability given
•
Limited prototype system effort (e.g. number test vehicles and
VRU)
Political aspects respected
The following political aspects have also been regognised and important points
within the SAFEPOT project and are outlined below:
Page 37 of 143
Copyright SAFESPOT
•
•
Accident statistical significance is important in finalising such a
system and must be carried out as further work required based on
requirements from SP4/5
The SAFESPOT project can maintain a good fore seeable business
case and product maturity during the project lifecycle.
Use cases not covered by any other Eu Project must also be considered within
SAFESPOT.
5.2 Definition of an actor
An actor is an entity interacting with the system under design (SuD). Actors can
be captured from the following interactions with the SuD:
•
•
•
•
Primary actor of a use case, which is the entity initiating a response with
the SuD
Supporting actors within a use case i.e. entities that are involved with the
scenario but do not initiate the interaction the SuD
Internal entities within the SuD (depends where system boundary is
drawn)
Drawing a context diagram
System boundary
A context diagram can help define the boundary of the system (from this point
onwards the SuD will be referred to as ‘the system’) and the actors interacting
with the system. In the current context diagram the vehicle sensors are placed
outside the system, since SP1 works with the output of these devices.
However, at this stage the boundary of the system is flexible and the description
of the actors can change, without affecting the steps of the scenarios.
Page 38 of 143
Copyright SAFESPOT
Figure 5.3: Context diagram
Within SP1.2.1 the primary actor is the application subproject SCOVA SP4
(Cooperative Systems Applications Vehicle Based) and subproject CoSSIB SP5
(Cooperative Safety Systems Infrastructure Based) which have specific goals.
List of actors
The list of actors contains a short name, which will be referred to in the use
cases and a corresponding description of the role that the actor plays. It is
expected that the following changes will occur to the actors list, through
discussion with SP1 partners:
•
•
•
The role of each actor will be become more precise
Merging of actors into a generic name
Additional actors will be added to the list as the use cases are written.
Actors List
•
•
Warning
Advise –subsystem
Triggering Actors
Page 39 of 143
Copyright SAFESPOT
Roadside infrastructure I2V
Probe vehicles (V2V)
Vehicle sensors
Entities
• Probe vehicle
• Other vehicle (s)
• Bridge/tunnel infrastructure
• Ambient environment infrastructure
• Roadside infrastructure
• Pedestrian VRU
• Cyclist VRU
• PTW rider VRU
• Vehicle sensors
• Positioning source
• Other roadside sensors
• Roadside actuators
• Local roadside unit
• Central control unit
The stakeholders of a system are called Actors.
Hence a use case captures the requirements of the stakeholder.
Now moving onto activity that defines the interaction and affect the stakeholders
have on the system this can be captured using the following approach. (See
example below in Table 5.1).
Name of Actor
Probe vehicle
Actor Description
Probe vehicle
Car
SP4 subsystem
SP3 subsystem
Truck
*PTW
This actor is responsible for the generation of
application related warning and advice information
to the driver and defines the applications that will
run on the SP1 vehicle platform and hence imposes
specific use case requirements on SP1.
This actor is responsible for providing the V2V and
Page 40 of 143
Copyright SAFESPOT
Emergency vehicle
Other probe vehicle
Bridge Tunnel
infrastructure
Ambient environment
Other Roadside Sensors
Roadside actuators
Local roadside unit
Central control unit
Pedestrian
Cyclist
PTW Rider
vehicle to infrastructure communication
Police, Fire, Ambulance, Doctor, road recovery
vehicles
This actor represents any other probe vehicle
present in the driving scenario. This actor is able to:
1. forward a V2V message
2. receive the message passively
3. be detected by the probe vehicle
This actor is able detect the physical conditions of
bridges and tunnels that are part of the road
network. Data is provided by this actor on the
status of the bridge or tunnel infrastructure such as
fire in a tunnel, weather conditions, advisory speed
limits and any lane restrictions.
This actor a physical entity that the probe vehicle is
able to detect monitor the environment for weather
conditions such as rain, fog, snow, ice and is able to
inform the infrastructure and probe vehicles of
adverse weather conditions.
This actor is able to detect information relating to
road use (the passage of vehicles, occurrence of
collisions, stationary vehicles, the presence of other
road users, pedestrians, etc). It is able to
communicate this information to probe vehicles and
infrastructure.
This actor, located on the roadside, is able to give
warning signals or messages to passing vehicles.
This actor is able to undertake rapid processing of
data received from passing vehicles and/or sensors
in a local area and to communicate advisory
information to vehicles and infrastructure actuators
within this area.
This is a physical entity which receives trafficrelated data from the road network in a given area,
is able to process and store this data, generate
control actions and strategies, and broadcast
advisory information to probe vehicles and roadside
actuators.
This actor represents a human being which can be
classed as a vulnerable road user
This actor represents a cyclist which can be classed
as a vulnerable road user
This actor represents the vulnerable road user
Page 41 of 143
Copyright SAFESPOT
Vehicle Sensors
Positioning Source
Telematics unit
ADAS sensors, indicators, vehicle dynamics
This actor represents an entity (GPS, Galileo) that
continuously provides position information to the
system without being requested by the system.
Provides
Table 5.1 : Example of actors and actor descriptions
5.3 Description of a use case
The use case captures the systems response under various conditions as it
responds to a request from a primary actor.
The primary actor initiates an interaction with the system to accomplish a goal.
In order to capture the scenario, the proposed use case template defines a
number of fields that capture information about the use case. The description of
the use case is captured in steps from the initiating actor’s interaction with the
system through to the end goal, including any variations.
The data, which should be inserted into each of the use case fields, is defined in
the template. Each use case has a tracking section, which should be completed
each time any modifications are made to the template.
5.4 Use case template naming convention
The name of each use case and the document filename adheres to the following
naming convention:
SP1_UCnnn_IDpp_V1.#.doc
Where:
nn = partner assigned number - each should assign their own number when
creating a use case e.g. first use case created by partner = UC1, UC2
……, UCn
Member ID = partner number assigned at the IP level e.g. MIRA = 32.
V1.# = Insert the version number.
Each use case includes a tracking section.
The tracking section should be updated when either a comment or modification is
made.
Page 42 of 143
Copyright SAFESPOT
The filename should be amended accordingly to enable changes to be tracked.
5.5 Use case suggestion list
The list of potential use case titles is currently in a “raw” format and needs to be
grouped according to area and (in some cases) expanded to include all possible
permutations given the driving environment, as a result of:
•
•
•
•
•
•
Road types
Road segment (curved, bridge, tunnel, intersection, roundabout, straight
segment)
Weather conditions
Road conditions
Number of lanes
Divided/undivided road
Another consideration is that there could be more than one primary actor
initiating a particular use case (infrastructure, vehicle sensors, and other
vehicles) each of which causes a differing response from the system. This
situation could be resolved by defining a high level use case description and then
defining lower level use cases in order to cover the different initiating actors.
However, the different levels and permutations of a use case and how we deal
with this need was discussed between the project partners.
In the following table is reported the list of use cases that were been analysed by
the SP1 partners.
In Annex 4 the compiled tables of use cases are reported.
Use Case ID
Use Case Description
Priority
SP1_UC1_32_v1.0
Ego vehicle warned of stationary traffic at
next turn
Priority
L1
SP1_UC2_32_v1.0
Ego vehicle detects wrong way driver
Priority
L1
SP1_UC2.1_32_v1.0
Vehicle receives warning of wrong way driver
Priority
L1
SP1_UC2. 2_32_v1.0
Ego vehicle receives wrong way driver
warning
Priority
L1
SP1_UC3_32_v1.0
Ego vehicle turning receives warning of slow
moving object crossing
Priority
L1
SP1_UC3.1_32_v1.0
Ego vehicle receives warning of obstacle
(traffic jam) at next turn
Priority
L1
SP1_UC3.2_32_v1.0
Ego vehicle detects traffic jam
Priority
Page 43 of 143
Copyright SAFESPOT
L1
SP1_UC4_5_v1.0
Ego vehicle runs a red light
Priority
L1
SP1_UC4.1_5_v1.0
Ego Vehicle runs a red light on collision path
Priority
L1
SP1_UC4.2_5_v1.0
Other vehicle runs a red light
Priority
L1
SP1_UC5_1_V1.0
Ego-vehicle detects a fire / smoke section
Priority
L1
SP1_UC5.1_1_V1.0
Approaching a fire-smoke section: Egovehicle broadcasts the information
Priority
L1
SP1_UC5.1_1_V1.0
Approaching a fire / smoke section inside a
tunnel:
Ego-vehicle
broadcasts
the
information
Priority
L1
SP1_UC6_1_V1.0
Road departure on straight road for high
speed
Priority
L2
SP1_UC6.1_1_V1.0
Presence of sharp curve: ego vehicle detects
the presence of a sharp curve
Priority
L2
SP1_UC6.2_1_V1.0
Presence
of
information
warning
Priority
L2
SP1_UC7_11_v1.2
PTW falling down on the road: PTW tilt
sensor has detected vehicle falling down.
Priority
L3
SP1_UC7.1_11_v1.2
PTW falling down on the road: PTW sends a
warning signal
Priority
L3
SP1_UC8_11_v1.2
PTW overtaking OV while OV is making a
turn: PTW detects that preceding vehicle
makes a turn.
Priority
L1
SP1_UC8.1_11_v1.2
PTW overtaking OV while OV is making a
turn: PTW sends to preceding vehicle a
warning message
Priority
L1
SP1_UC9_4_v1.0
Ego vehicle carrying dangerous
approaches other vehicle.
goods
Priority
L2
SP1_UC9.1_4_v1.0
Ego vehicle carrying dangerous
approaches other vehicle.
goods
Priority
L2
SP1_UC10_4_v1.0
Ego vehicle approaching truck carrying
dangerous goods.
Priority
L2
SP1_UC10.1_4_v1.0
dangerous goods in tunnel.
Priority
L2
SP1_UC10.1_4_v1.0
dangerous goods in tunnel.
Priority
L2
sharp
curve:
Page 44 of 143
Copyright SAFESPOT
SP1_UC11_51_v2.0
Ego vehicle approaching in progress works
in a sub-urban road
Priority
L2
SP1_UC11.1_5_v1.0
Lost load in lane of oncoming traffic
Priority
L2
SP1_UC11.2_5_v1.0
Lost load in ego lane
Priority
L2
SP1_UC11.3_5_v1.0
Lost load in ego lane (2)
Priority
L2
SP1_UC12_51_v2.0
Emergency vehicle approaching
Priority
L1
SP1_UC13_29_v1.0
Ego-vehicle hard braking while other is
following: situation is detected
Priority
L1
SP1_UC13.1_29_v1.0
following: situation is detected and warning is
given to the driver
Priority
L1
SP1_UC13.2_29_v1.0
following: situation is detected and warning is
given to other probe vehicles
Priority
L1
SP1_UC14_29_v1.0
Ego-vehicle overtaking in collision path:
system detects danger
Priority
L1
SP1_UC14.1_29_v1.0
system detects danger and driver is warned
Priority
L1
SP1_UC14.2_29_v1.0
system detects danger and warning
message is transmitted to other probe
vehicles
Priority
L1
SP1_UC15_32_v1.0
Slippery road condition: Ego vehicle detects
Ice on the road
Priority
SP1_UC15.1_32_v1.0
Ego vehicle receives warning of ice on the
road
Priority
Table 5.2: Use Cases Index
6 Conclusions
With collaborative partners within a european project its sometimes difficult to
find the optimal methodology which differs for different sorts of projects, but also
different authors and project staff have different biases based around their
experiences, fears and principles.
Four variables key to the selection of a methodology are
Page 45 of 143
Copyright SAFESPOT
•
•
•
•
team size
distribution
project criticality
project priorities.
National and team cultural values are more difficult to characterize, but play in
the result.
Therefore any use cases omitted in this deliverable i.e. interaction with
infrastructure or any use cases that have missed or that become higher priority
will be incorporated into the Use Case Requirements deliverable D1.3.3.
The next steps on completion of this deliverable are to use the results in a
suitable manner that supports all future deliverables within SAFEPROBE,
specifically the first definition of the Scenario Creation Template by using the
Drivers Attribute diagram and flowchart procedure for capturing usefull scenario
data and UseCase’s that were derived.
7 References
[1]
D32.3: Requirements and Specifications”, PReVENT LATERAL SAFE
deliverable (v5, 15.03.2005).
[2]
D20.30: Application Scenarios, Safety Criteria and Customer’s Benefits
Analysis”, PReVENT SASPENCE deliverable (v1.1, 31.10.2004).
[3]
D20.33: Functional Requirements”, PReVENT SASPENCE deliverable
(v1.2, 30.11.2004).
[4]
D31.31: Specification Catalogue”, PReVENT SAFELANE deliverable (v4,
06.09.2004).
[5]
Use Cases Methodologyn ref
WebsiteofAlastairCockburn: http://alistair.cockburn.us/usecases/usecases.html
[6]
Car2Car Communication Consortium
The Car2Car Communication Consortium is dedicated to the objective of further
increasing road traffic safety and efficiency by means of inter-vehicle
communications www.car-to-car.org
[7]
PReVENT
Page 46 of 143
Copyright SAFESPOT
The Integrated Project PReVENT is a European automotive industry activity cofunded by the European Commission to contribute to road safety by developing
and demonstrating preventative safety applications and technologies
www.prevent-ip.org
[8]
GST: Global system for telematics Integrated Project
GST aims to create the technology and cooperation necessary for an open
market for online telematics services. This will allow different actors to operate
services using the same multibearer service delivery infrastructure and in-vehicle
terminals www.gstforum.org
Page 47 of 143
Copyright SAFESPOT
8 Annexes
8.1 Annex 1
Follow the steps of this flow chart in order to complete the Basic Scenario Template.
Start
Complete the ‘Scenario
description’ field giving a
high level summary of the
scenario
Complete the
‘Basic scenario
name’ field
Is the road graph to be
described a junction?
Complete the ‘Author
field’ including name
and company of the
author
In the junction field of the
Road graph section place an
’X’ against the attribute
which describes the
‘Junction’ from the
categories shown in the
attribute diagram. If the
category does not exist
insert the new entry in the
the ‘Other’ field.
Yes
Is the type of junction an
intersection?
The next step is to be complete
the template fields which define
attributes of the scenario. For
this you will need to reference
the scenario attributes diagram
shown in Figure 1.
Yes
Select the appropriate
attribute from the list for the
‘Shape’ class from the
scenario attribute diagram and
complete the Shape field for
the intersection on the
template.
No
No
For each lane of the road
graph we now build a
picture of the lane
conditions in the following
steps
In the ‘surface type’ field of
the Lane n section select the
appropriate attribute from the
list with the same class name
from the scenario attribute
diagram
Briefly describe the
‘relative position/
connectivity’ attribute of
the ‘lane geometry info.’
class for Lane n
The lane geometry Information
class for lane n is described by
a number attributes. These
attributes will be defined in the
next steps.
In the ‘lane type’ field of
the Lane n section select
the appropriate attribute
from the list with the same
class name from the
attribute diagram
Define the ‘width’ attribute
of the ‘lane geometry info.’
class for Lane n e.g. wide,
narrow, normal, restricted..
Define the driving
‘direction’ of lane n for
the lane geometry info
class e.g.?
The road graph is then a
link. Insert ‘X’ in the
‘link’ field
In the ‘surface condition’
field of the Lane n section
select the appropriate attribute
class name in the scenario
attribute diagram
Yes
Are there any more
lanes to define for this
scenario?
Select the attribute which
describes the ‘lighting
conditions’ class from the
list given in the attribute
diagram
No
Select the attribute for
the ‘Structure’ class
from the list given in the
attribute diagram
describes the ‘visibility’
class from the list given in
the attribute diagram.
Ensure that all the
background classes and
associates attributes have
been completed correctly
In the ‘lane traffic condition’
field of the Lane n section
select the appropriate attribute
class name in the scenario
attribute diagram
Briefly define the ‘curvature’ attribute of
lane n for the ‘lane geometry info.’ class.
This can be defined as either being
extreme and short, medium radius of
curvature of medium length, long and
low radius etc..,
describes the ‘Area type’
class, from the list given in
the attribute diagram
describes the ‘weather’
class from the list given in
Follow figure 3
to complete the
incident
attributes
Page 48 of 143
describes the ‘traffic
condition’ class from the
list given in the attribute
diagram
The environmental conditions
are described by a number of
different classes and
associated attributes by the
next steps.
Copyright SAFESPOT
Complete
incident
attributes
The incident is described through a
number of classes and associated
attributes for each participant
involved in the driving scenario
Briefly define the relative
position of the participant with
reference to the ego vehicle in
the ‘Start pos.’ field of the
template in the participant
section
Is this pariticpant
the ego vehicle?
No
Yes
Briefly define the relative position
of the ego vehicle with reference
to the road graph in the ‘start
pos.’ field of the template in the
participant section
Yes
Complete the ‘Type’ field for the
participant from the attribute
diagram
Complete the ‘obstruction’
field from the list given in
Complete the ‘manoeuvre’ field
for the participant from the
attribute diagram
Complete the ‘rule violation’
field from the list given in the
attribute diagram
In the ‘Incident’ field of the participant section,
briefly describe the expected trajectory with each
participant.
NOTE: if this scenario describes the situation after
the incident then the incident should be classed as
an obstacle with respect to the ego vehicle and
should appear as an obstacle in the ‘lane traffic
condition’ class of the affected Lane (s) of the
background attributes. If the expected trajectory of
any of the vehicles is a tree or stationary landmark
etc state this in the description.
Are there any other
vehicles taking part in
this scenario?
No
Check that all incident
attributes have been
completed correctly
If possible insert a
pictogram which
depicts the
scenario
The end
Page 49 of 143
Copyright SAFESPOT
8.2 Annex 2: Merged Scenario Table
Page 50 of 143
Copyright SAFESPOT
8.3 Annex 3: Scenario tables
Page 51 of 143
Copyright SAFESPOT
Page 52 of 143
Copyright SAFESPOT
Page 53 of 143
Copyright SAFESPOT
Page 54 of 143
Copyright SAFESPOT
Page 55 of 143
Copyright SAFESPOT
Page 56 of 143
Copyright SAFESPOT
Page 57 of 143
Copyright SAFESPOT
Page 58 of 143
Copyright SAFESPOT
Page 59 of 143
Copyright SAFESPOT
Page 60 of 143
Copyright SAFESPOT
Page 61 of 143
Copyright SAFESPOT
Page 62 of 143
Copyright SAFESPOT
Page 63 of 143
Copyright SAFESPOT
Page 64 of 143
Copyright SAFESPOT
Page 65 of 143
Copyright SAFESPOT
Page 66 of 143
Copyright SAFESPOT
Page 67 of 143
Copyright SAFESPOT
8.4 Annex 4: SAFEPROBE use cases
In the following all the use cases analysed by the partners are reported.
Case Name
Ego vehicle warned of stationary traffic at next turn
Case ID
SP1_UC1_32_v1.0
Status
Draft
Ego vehicle receives a message from the detecting vehicle that
there is a stationary/slow traffic on one of the roads leading off
the junction
Short description
Authors
Debra Topham (MIRA)
Driving environment
Urban, intersection
Vehicle probe type
Any type of probe vehicle
Risk’s source
Precondition
Stationary/Slow moving traffic jam out of detection range of the
ego vehicle located close to the next turn
• See MIRA basic scenario number 3
• 2 Safeprobe systems operational
• Detecting probe vehicle broadcasts a message
containing information about the location of the slow
moving traffic jam
• Local dynamic map contains information relating to the
driving environment and current situation prior to the
scenario occurring.
Page 68 of 143
Copyright SAFESPOT
Goal/Successful end
condition
Ego vehicle successfully updates the LDM with the location of
the slow moving traffic jam located at the next turn off the
intersection.
•
Failed end condition
Lane traffic condition not updated within the LDM
Trigger
Ego vehicle receives message from the detecting probe vehicle
Sensor types and
Useful data received from the detecting probe vehicle, data
fusion with NAV system data required
useful data
Actors/Entities
Primary Actor: SP4 subsystem
Internal Entity: SP3_module
Secondary Actor: Other probe vehicle (detecting)
Step
1
2
Scenario Description
3
4
5
Step
Action
Detecting vehicle broadcasts warning
SP1_UC3.3_32_v1.0
Ego vehicle SP3 module receives the warning
message
SP1 system updates the local dynamic map with
the information about the location of the slow
moving traffic jam
LDM update available for the SP4 subsystem to
provide warning and advise information
SP1 system determines that there are other
equipped vehicles and/or an active SP2 subsystem
within its communication range and rebroadcasts
the message
Action
Extensions
Super ordinates
Subordinates
Open issues
Comments
Page 69 of 143
Copyright SAFESPOT
Case Name
Case ID
SP1_UC2_32_v1.0
Status
Draft
Ego vehicle driving along a straight section of motorway detects
that there is a wrong way driver entering the slip from the exit
ramp (slip road) in the wrong direction (wrong way driver has
entered the motorway via the slip road)
Short description
Authors
Debra Topham, Gary Ford (MIRA)
Driving environment
Motorway primarily. However, this scenario could occur where
there is only one 1 lane and a vehicle is allowed to enter the road
in the wrong direction.
Vehicle probe type
Risk’s source
Wrong way driver in the adjacent lane
•
•
•
Precondition
Goal/Successful end
condition
•
See MIRA basic scenario number 2
Safeprobe system operational
Other probes vehicles in the same lane as the wrong way
driver 300m behind the ego vehicle
Local dynamic map contains information relating to the
scenario occurring.
Ego vehicle successfully broadcasts wrong way driver warning to
other probe vehicles approaching the wrong way driver.
•
•
Ego vehicle does not detect the wrong way driver
Required sensor data not complete
Page 70 of 143
Copyright SAFESPOT
•
•
Trigger
Sensor types and
useful data
Actors/Entities
Message not broadcast successfully
ENP sensors detect and classify object, wrong way driver
positioned accurately relative to ego vehicle in the LDM,
trajectory history required to track vehicle.
Primary Actor: Other probe vehicle
Secondary Actor: wrong way driver and Ego vehicle
Step
Action
Ego vehicle detects on coming vehicle in the
1
adjacent lane using appropriate ENP sensors
The LDM is updated with the location of the on
2
coming vehicle.
The ego vehicle determines that there are other
3
probe vehicles behind its current position heading
towards the on coming vehicle
The ego vehicle broadcasts the warning message
with containing data about the location of the wrong
4
way vehicle
Step
Action
Extensions
Super ordinates
SP1_UC2.1_32_v1.0
Subordinates
None
Open issues
Comments
Page 71 of 143
Copyright SAFESPOT
Case Name
Ego vehicle receives wrong way driver warning
Case ID
SP1_UC2. 2_32_v1.0
Status
Draft
Infrastructure detects vehicle entering a one-way road in the
wrong direction at an intersection and broadcasts a warning
message to other probe vehicles approaching the intersection.
Short description
Authors
Debra Topham (MIRA)
Driving environment
Urban, intersection
Vehicle probe type
Risk’s source
On-coming vehicle turning into a one-way road in the wrong
direction of an intersection
•
•
Precondition
Goal / Successful
•
•
SP2_Subsystem operational
SP2_subsystem has detected a vehicle turning left into a
one-way road at an intersection.
At least 1 operational SAFEPROBE equipped vehicle
scenario occurring.
Local dynamic map of ego vehicle updated with oncoming
vehicle data to enable SP4_subsystem to provide warning and
Page 72 of 143
Copyright SAFESPOT
end condition
advice information.
•
Local dynamic map not updated with obstacle information
Trigger
Ego vehicle receives message from subsystem SP2
Sensor types and
No sensor data, useful data communicated from the roadside
infrastructure SP2 subsystem
useful data
Actors/Entities
Extensions
Super ordinates
Primary Actor: SP4_subsystem (ego vehicle)
Secondary Actor: SP2_subsystem
Internal Entity: SP3_module (of ego vehicle)
Step
Action
Ego vehicle receives a message from the
SP2_subsystem located ahead of its current
1
trajectory indicating oncoming vehicle in the same
lane.
SP1 system updates its local dynamic map with the
2
position of the moving obstacle
LDM data available for the SP4_subsystem to
3
Ego vehicle determines from the relative
4
localization map that there are other equipped
vehicles behind its current position
SP3_module broadcasts the message to the
5
SP2_subsystem and other probe vehicles
Step
Action
Ego vehicle determines from the relative
4a
localization map that there are no other equipped
vehicles or SP2_systems
Message stored until other communicating nodes
5a
are found and region is still relevant and/or
message lifetime has not expired.
None (perhaps from use case generated by SP2 – Infrastructure
detects vehicle making a wrong turn)
Subordinates
Open issues
Comments
Page 73 of 143
Copyright SAFESPOT
Case Name
Vehicle receives warning of wrong way driver
Case ID
SP1_UC2.1_32_v1.0
Status
Draft
Ego vehicle receives a message from the detecting vehicle that
there is a wrong way driver approaching
Short description
Authors
Driving environment
Motorway
Vehicle probe type
Risk’s source
Wrong way driver in the same lane as the ego vehicle
•
•
•
Precondition
•
•
Goal/Successful end
condition
See MIRA basic scenario number 2
2 Safeprobe systems operational
Vehicle has detected a wrong way driver and broadcast
the message
Other probes vehicles in the same lane as the wrong way
driver 300m behind the ego vehicle
scenario occurring.
Ego vehicle successfully receives the message from the
detecting vehicle that a wrong way vehicle is approaching and
updates its LDM to enable the SP4 subsystem to provide
appropriate advice and warning information.
•
Page 74 of 143
Copyright SAFESPOT
Trigger
Ego vehicle receives message from the detecting probe vehicle
Sensor types and
No sensing information for this scenario the ego vehicle receives
the data from an outside source.
useful data
Actors/Entities
Secondary Actor: Other probe vehicle (detecting)
Step
1
2
3
4
5
Step
Action
Detecting vehicle broadcasts wrong way driver
warning SP1_UC2_32_v1.0
Ego vehicle SP3 module receives the warning
message
SP1 system updates the local dynamic map with
the information about the wrong way driver
LDM update available for the SP4 subsystem to
SP1 system determines that there are other
equipped vehicles and/or an active SP2 subsystem
within its communication range and rebroadcasts
the message
Action
Extensions
Super ordinates
None
Subordinates
SP1_UC2_32_v1.0
Open issues
Comments
Page 75 of 143
Copyright SAFESPOT
Case Name
Ego vehicle turning receives warning of slow moving object
crossing
Case ID
SP1_UC3_32_v1.0
Status
Draft
Ego vehicle approaches T-junction with intention of making a left
(right) turn. Pedestrian VRU is crossing the road and outside the
detection range of the ego vehicle. Possible collision with the
pedestrian.
Short description
Authors
Debra Topham (MIRA)
Driving environment
Urban
Vehicle probe type
Risk’s source
Pedestrian VRU crossing the road slowly
•
Precondition
•
•
•
•
See basic scenario description: SP2 subsystem detects
pedestrian VRU crossing the road
1 SafeProbe system operational
SP2_subsystem in operation at the T-junction
scenario occurring.
Pedestrian VRU crossing the road
Page 76 of 143
Copyright SAFESPOT
Goal/Successful end
condition
Local dynamic map of ego vehicle updated with position of
pedestrian VRU crossing the road to enable SP4 subsystem to
provide warning and advice information.
•
Local dynamic map not updated with Pedestrian VRU
crossing the road
Trigger
Ego vehicle receives message from the SP2 subsystem
Sensor types and
To be completed as part of the useful data task 1.2.2 (see
technical Annex.
useful data
Actors/Entities
Secondary Actor: SP2_subsystem and Pedestrian VRU.
Step
Action
SP2 subsystem detects a pedestrian VRU crossing
1
the road and broadcasts a warning message.
SP1 system of the Ego vehicle receives the
message from subsystem 2 and the updates the
2
local dynamic map with the location of the
pedestrian VRU.
LDM data available for the SP4 subsystem to
3
generate warning and advice information
Step
Action
Extensions
Super ordinates
None
Subordinates
None
Open issues
Comments
Page 77 of 143
Copyright SAFESPOT
Case Name
Ego vehicle receives warning of obstacle (traffic jam) at next turn
Case ID
SP1_UC3.1_32_v1.0
Status
Draft
Ego vehicle approaches intersection with the intention of making
a left (right) turn. Detection of traffic jam on road is outside the
detection range of the ego vehicle. Possible collision with
stationary vehicle.
Short description
Authors
Debra Topham (MIRA)
Driving environment
Urban
Vehicle probe type
Risk’s source
Traffic jam on road ego vehicle intends to turn into
•
•
•
Precondition
Goal/Successful end
At least 1 Safeprobe system operational
SP2_subsystem operational at the intersection
scenario occurring.
• Slow moving traffic jam on road ego vehicle intends to
turn into
Local dynamic map of ego vehicle updated with position of traffic
jam to enable SP4 subsystem to provide warning and advice
Page 78 of 143
Copyright SAFESPOT
condition
information.
•
Local dynamic map not updated with correct location of
traffic
Trigger
Ego vehicle receives message from the SP2 subsystem
Sensor types and
Useful data received from the roadside infrastructure SP2
system
useful data
Extensions
Secondary Actor: SP2_subsystem and other vehicles (involved
in traffic jam)
Step
Action
SP2 subsystem detects that there is a traffic jam on
1
one of the roads leading off the intersection.
SP1 system of the Ego vehicle receives the
2
message from subsystem 2 and the updates the
local dynamic map with the location traffic jam.
LDM data available for the SP4 subsystem to
3
generate warning and advice information
Step
SP3 module broadcasts LDM update/warning to
4
other probe vehicles
Super ordinates
None
Subordinates
None
Actors/Entities
Open issues
Comments
Page 79 of 143
Copyright SAFESPOT
Case Name
Ego vehicle detects traffic jam
Case ID
SP1_UC3.2_32_v1.0
Status
Draft
Ego vehicle detects stationary traffic on the adjacent lane in the
opposite traffic flow and broadcasts a warning message
addressed to vehicles turning into the affected lane.
Short description
Authors
Debra Topham (MIRA)
Driving environment
Urban
Vehicle probe type
Risk’s source
Traffic jam on in adjacent traffic flow at an intersection
•
•
Precondition
•
Goal/Successful end
condition
At least 2 operational Safeprobe systems
scenario occurring.
Slow moving traffic jam in opposite traffic flow
Local dynamic map of ego vehicle updated with position of traffic
jam and message broadcast to other probe vehicles
•
Local dynamic map not updated with location of traffic
and message and message not broadcast to other probe
Page 80 of 143
Copyright SAFESPOT
vehicles making a left turn into the affected junction
Trigger
Sensor types and
Ego vehicle detects slow moving traffic in the opposite traffic flow
at an approaching an intersection
ENP sensors, NAV system
useful data
Actors/Entities
Primary Actor: Other probe vehicles
Secondary Actor: other vehicles (involved in traffic jam)
Internal Entity: Sp3 module
Step
Action
Ego vehicle detects slow/stationary traffic in the
1
adjacent lane using appropriate ENP sensors and
NAV systems
The LDM is updated with the location of the traffic
2
jam. (Relative position of the last vehicle in the
traffic jam in relation to the junction is important)
The ego vehicle determines that there are other
3
probe vehicles that will enter the affected road
The ego vehicle broadcasts the warning message
4
containing data about the location stationary/slow
moving traffic jam
Step
Extensions
Super ordinates
None
Subordinates
None
Open issues
Comments
Page 81 of 143
Copyright SAFESPOT
Case Name
Ego vehicle runs a red light
Case ID
SP1_UC4_5_v1.0
Status
Draft
Ego vehicle approaches intersection with constant speed going to
run a red light, driver blinded by low sun
Short description
Authors
Driving
Sönke Carstens-Behrens, Christian Zott (Bosch)
Urban
environment
Vehicle probe type
All classes of probe vehicles
Risk’s source
Potential collision with other (crossing) vehicles, VRU
•
Precondition
See scenario 12 (from Bosch, only ego vehicle): x-shape
intersection, ego driver blinded by low sun, ego vehicle 300m
from intersection, 50km/h,
Page 82 of 143
Copyright SAFESPOT
•
•
Goal/Successful
end condition
1 SAFEPROBE system and RSU (SP2 platform) operational
Ego llocal dynamic map contains information relating to the
driving environment and current situation prior to the scenario
occurring.
Ego local dynamic map has been updated traffic sign status (red
light phase), SP4 or SP5 subsystem able to generate collision
warning and advise information.
condition
Local dynamic map lane traffic condition status does not change
timely.
Trigger
Communication message from RSU about traffic sign phase
Failed end
Sensor types and
No ego sensing traffic signal assumed
useful data
Actors/Entities
Scenario
Description
Extensions
Super ordinates
Secondary Actors: Other probe Vehicles and RSU
Internal Entity: SP3_module – internal entity
Step
Action
1
Com message RSU indicating red light phase
SP1 system updates local dynamic map (affected
intersection) with traffic signal status (red light
phase,)
2
Note: no fusion with internal vehicle data (ENP,)
except static map data or previous vehicle entries
in LDM (tracking)
LDM data available for SP4 subsystem to
3
generate rule violation and potential collision
warning, and driving advise
Step
Action
SP3 module broadcasts LDM update / warning to
4
SP2-subsystem and other probe vehicles
SP1_UC02_5_v0.1
SP1_UC03_5_v0.1 (from a crossing vehicle’s point of view)
Subordinates
Open issues
Comments
Page 83 of 143
Formatiert: Nummerierung
und Aufzählungszeichen
Copyright SAFESPOT
Case Name
Ego Vehicle runs a red light on collision path
Case ID
SP1_UC4.1_5_v1.0
Status
Draft
Ego vehicle approaches intersection with constant speed going to
run a red light, driver blinded by low sun; other vehicle is going to
cross the intersection; collision given no manoeuvre
Short description
Authors
Driving
Urban
environment
Vehicle probe type
Risk’s source
Collision with crossing vehicle
Precondition
•
See scenario 12 (from Bosch): x-shape intersection, ego driver
blinded by low sun, ego vehicle 300m from intersection,
Page 84 of 143
Copyright SAFESPOT
50km/h,
2 SAFEPROBE systems and RSU (SP2 platform) operational
occurring.
Ego local dynamic map has been updated with crossing vehicle
and its attributes (state) and traffic sign status (red light phase),
SP4 or SP5 subsystem able to generate collision warning and
advise regarding information.
•
•
Goal/Successful
end condition
Failed end
timely
condition
Trigger
Communication message from RSU about traffic sign phase
Sensor types and
No ego sensing of crossing vehicle (blocked view, > 300m
distance) and traffic signal assumed
useful data
Actors/Entities
Scenario
Description
Extensions
Super ordinates
Secondary Actors: Other probe vehicle and RSU
Step
Action
Com message RSU indicating crossing vehicle at
1
collision path and red light phase
intersection) with crossing vehicle position, speed,
time stamp (and further attributes) and traffic
2
signal status (red light phase,)
in LDM (tracking)
LDM data available for SP4 subsystem to
3
generate rule violation and collision warning, and
driving advise
Step
Action
4
SP1_UC03_5_v0.1 (from the crossing vehicle’s point of view)
Subordinates
Open issues
Comments
Page 85 of 143
Copyright SAFESPOT
Case Name
Other vehicle runs a red light
Case ID
SP1_UC4.2_5_v1.0
Status
Draft
Ego vehicle approaches/stands at intersection with green traffic
signal (right of way), other (crossing) vehicle is going to run red
light (e.g. driver blinded by low sun), collision with crossing
vehicle going to happen given no manoeuvre changes
Short description
Authors
Driving environment
Urban
Vehicle probe type
Risk’s source
Precondition
Collision with crossing vehicle going to happen given no
manoeuvre changes, blocked view at intersection
• See scenario 12 (from Bosch): x-shape intersection, other
driver blinded by low sun, ego and crossing vehicle 300m
from intersection, 50km/h,
• 2 SAFEPROBE systems and RSU (SP2 platform) operational
Page 86 of 143
Copyright SAFESPOT
•
occurring.
Ego local dynamic map has been updated with crossing vehicle
and its attributes (state) and traffic sign status,
SP4 or SP5 subsystem able to generate collision warning and
advise information.
timely
Trigger
Communication message from RSU about crossing vehicle and
traffic sign phase
Goal/Successful end
condition
Sensor types and
useful data
Actors/Entities
Extensions
No ego sensing of crossing vehicle (blocked view, > 300m
distance)
Secondary Actors: Other probe Vehicles and RSU
Step
Action
Com message RSU indicating crossing vehicle at
1
collision path and traffic signal phase
intersection) with crossing vehicle position, speed,
time stamp (and further attributes) and traffic signal
2
status
in LDM (tracking)
LDM data available for SP4 subsystem to generate
3
collision warning and driving advise
Step
Action
4
Red light runner is not equipped but RSU can
5
detect and track him, and sends COM message to
ego vehicle
Super ordinates
Subordinates
SP1_UC01_5_v0.1 (from the crossing vehicle’s point of view)
Open issues
Comments
Maybe too many false alarms for ego vehicle driver? Æ SP4
Page 87 of 143
Copyright SAFESPOT
Case Name
Ego-vehicle detects a fire / smoke section
Case ID
SP1_UC5_1_V1.0
Status
Draft
Host-vehicle approaching fire / smoke section, while travelling on a
dual carriageway
Short description
Authors
Driving
Elena Bianco and Fabio Tango; Centro Ricerche FIAT
Motorway
environment
Vehicle probe type
Risk’s source
Precondition
Obstruction view
Possible collision with slower or static obstacles
• See scenario description from CRF document
• SAFEPROBE system inside operative range
• Ego-vehicle detects smoke section
•
end condition
•
Local dynamic map is updated with the information of
smoke section on the way
SP4_subsystem is able to generate a warning
Failed end
•
•
Local dynamic map does not change
Data not delivered to SP4 application timely
Goal/Successful
condition
Trigger
On-board sensors activated and detected the critical situations
Page 88 of 143
Copyright SAFESPOT
Sensor types and
Camera (and specific Image Processing issues); Lidar
useful data
Actors/Entities
Scenario
Description
Extensions
Secondary Actors: Other probe-vehicles and SP2 subsystem
Internal Entity: SP3 module(s)
Step
Action
On board sensors detect the presence of fire /
1
smoke section
SP1 system updates local dynamic map with road
2
information, time stamp and possible further
features / attributes
3
Data available for SP4 subsystem
Step
Action
On-board sensors deliver corrupted or failure
1a
message
Super ordinates
Subordinates
Open issues
Comments
Page 89 of 143
Copyright SAFESPOT
Case Name
Approaching a fire-smoke section: Ego-vehicle broadcasts the
information
Case ID
SP1_UC5.1_1_V1.0
Status
Draft
Host-vehicle approaching fire / smoke section, while travelling on a
dual carriageway
Short description
Authors
Driving
Motorway
environment
Vehicle probe type
Risk’s source
Precondition
Goal/Successful
end condition
Failed end
condition
Obstruction view
• Ego-vehicle detects smoke section
• Other equipped vehicle (s) within the broadcast range
of the smoke section
• Local dynamic map is updated with the information of
• Information about possible danger situation is
broadcasted to approaching ones
•
•
Data are not broadcasted
Page 90 of 143
Copyright SAFESPOT
Trigger
Sensor types and
On-board sensors activated and detected the critical situations
Camera (and specific Image Processing issues); Lidar
useful data
Actors/Entities
Secondary Actors: Other probe-vehicles and SP2 subsystem
Internal Entity: SP3 module
Step
1
Scenario
Description
2
3
Step
Extensions
1a
2a
Action
On board sensors detect the presence of fire /
smoke section
SP1 broadcasts the information to other vehicles
or infrastructures
Action
On-board sensors deliver corrupted or failure
message
The information of no updated map is broadcasted
Super ordinates
Subordinates
Open issues
Comments
Page 91 of 143
Copyright SAFESPOT
Case Name
Approaching a fire / smoke section inside a tunnel: Ego-vehicle
broadcasts the information
Case ID
SP1_UC5.2_1_V1.0
Status
Draft
Host-vehicle is approaching a tunnel where the infrastructure has
detected a fire / smoke section
Short description
Authors
Driving
Urban – extra urban - motorway
environment
Vehicle probe type
Risk’s source
Precondition
Goal/Successful
end condition
Failed end
condition
Trigger
Sensor types and
useful data
Actors/Entities
Obstruction view
• Ego-vehicle receives from infrastructure the message
on critical section
• The ego-vehicle receives correctly the information from
the infrastructure
• Local dynamic map is updated with the information of
• Information about possible danger situation is
broadcasted to approaching vehicles
•
•
Data is not broadcasted
Infrastructure detects the critical information and broadcasts it.
Host vehicle receives it.
Camera (and specific Image Processing issues) installed on the
infrastructure
Primary Actors: Other probe-vehicles and SP2 application
Step
Action
Page 92 of 143
Copyright SAFESPOT
Description
1
2
3
4
5
Step
Extensions
5a
Infrastructure detects fire-smoke section
Infrastructure sends the information
Ego-vehicle receives it
SP1 broadcasts the information to other vehicles
through the SP3 module
Action
The information can be broadcasted also to
another infrastructure
Super ordinates
Subordinates
Open issues
Comments
Page 93 of 143
Copyright SAFESPOT
Case Name
Road departure on straight road for high speed
Case ID
SP1_UC6_1_V1.0
Status
Draft
Ego-vehicle is travelling on a straight road at very high speed. The
driver loses control of the vehicle and road departure occurs.
Short description
Authors
Driving
Extra-urban - motorway
environment
Vehicle probe type
Risk’s source
Road departure, for excessive speed
Precondition
•
•
•
•
Goal/Successful
end condition
•
See scenario description from CRF document
SAFEPROBE system inside operative range
Excessive host-vehicle speed with reference to the
described situation
Local dynamic map is updated with the road departure
information
Information is transmitted to approaching vehicles and
infrastructures
condition
timely
Trigger
The road departure is happened
Failed end
Sensor types and
Yaw rate sensor, ESP system
useful data
Actors/Entities
Primary Actor: Other probe-vehicles
Secondary Actor: SP2 subsystem
Step
Action
Page 94 of 143
Copyright SAFESPOT
Description
1
2
Extensions
3
Step
3a
3b
On board sensors detected the road departure
departure information, recommended speed, time
stamp and possible further features / attributes
LDM is broadcasted to other vehicles
Action
Data available for SP3 module broadcast
LDM is broadcasted to infrastructure
Super ordinates
Subordinates
Open issues
Comments
Page 95 of 143
Copyright SAFESPOT
Case Name
Presence of sharp curve: ego vehicle detects the presence of a
sharp curve
Case ID
SP1_UC6.1_1_V1.0
Status
Draft
Ego-vehicle is travelling on a two carriageway and broadcasted
the information about the presence of sharp curve to the following
vehicles.
Short description
Authors
Driving
environment
Vehicle probe type
Risk’s source
Precondition
Goal/Successful
end condition
Failed
condition
Trigger
end
•
•
•
•
•
•
•
Ego-vehicle detects the presence of a sharp curve
Local dynamic map is updated with the sharp curve
presence information
Information is transmitted to approaching vehicles and
infrastructures
The presence of a sharp curve is not detected
Local dynamic map not charged
Detection of a sharp curve from the ego-vehicle
Page 96 of 143
Copyright SAFESPOT
Sensor types and
useful data
Actors/Entities
Static navigation map; information from infrastructure, camera and
related image processing
Primary Actor: Other probe-vehicles
Step
1
Scenario
Description
Extensions
2
3
Step
3a
3b
Action
On board sensors detect the presence of a sharp
curve
SP1 system updates local dynamic map with
presence of a sharp curve information,
recommended speed, time stamp and possible
further features / attributes
LDM is broadcasted to other vehicles
Action
Data available for SP3 module broadcast
Super ordinates
Subordinates
Open issues
Comments
Page 97 of 143
Copyright SAFESPOT
Case Name
Presence of sharp curve: warning information
Case ID
SP1_UC6.2_1_V1.0
Status
Draft
Ego-vehicle is travelling at very high speed on a two carriageway
and receives information about the presence of sharp curve; a
warning message is provided.
Short description
Authors
Driving
environment
Vehicle probe type
Risk’s source
Precondition
Goal/Successful
end condition
•
•
•
Information about the presence of a sharp curve is
received from the infrastructure or from other vehicles
•
Local dynamic map is updated with the sharp curve
presence information
A warning message is provided to SP4 subsystem
•
•
Failed end
•
The presence of a sharp curve is not received by the
ego-vehicle
Local dynamic map is not charged
Page 98 of 143
Copyright SAFESPOT
condition
•
Trigger
Sensor types and
useful data
Actors/Entities
Scenario
Description
Extensions
•
•
Detection of a sharp curve from infrastructure or other
vehicle;
Information is received by the ego-vehicle
High Ego-vehicle speed
On-board information (i.e. ABS sensor) and communication
devices
Primary Actor: SP4 sub-system
Secondary Actors: Other probe vehicle and SP2 subsystem
Step
Action
Information about sharp curve is received from
1
external sources
SP1 system updates local dynamic map with
presence of a sharp curve information,
2
recommended speed, time stamp and possible
further features / attributes
3
The data are available for the SP4 subsystem
Step
Action
3a
Warning signal is provided to other probe vehicles
3b
Super ordinates
Subordinates
Open issues
Comments
Page 99 of 143
Copyright SAFESPOT
Case Name
PTW falling down on the road: PTW tilt sensor has detected
vehicle falling down.
Case ID
SP1_UC7_11_v1.2
Status
Draft
PTW falls down on a section of a single/dual carriageway and
stays motionless on the road surface
Short description
Authors
Paolo Cravini (Piaggio)
Driving environment
Urban, Suburban, Motorway (more dangerous on curve section)
Vehicle probe type
Falling PTW
Risk’s source
Possible collision or accident with incoming OV
•
•
scenario occurring.
•
Local dynamic map updates the carriageway
condition to indicate the falling PTW presence on the
Precondition
Goal/Successful end
Page 100 of 143
Copyright SAFESPOT
condition
road.
•
•
Trigger
Sensor types and
•
•
SP4_subsystem is able to generate a warning signal by
receiving PTW tilt sensor information.
Local dynamic map about carriageway condition status
does not change
Data not delivered to SP4 in a timely manner
Required tilt sensor data not complete
PTW tilt sensor activated
Tilt sensor.
useful data
Actors/Entities
Extensions
Secondary Actors: SP2 subsystem and Other probe Vehicles
Step
Action
Tilt sensor activation indicates the PTW fall
1
down
Infrastructure and other probe vehicle
2
indicates traffic situation
From the fusion of the PTW, probe vehicle and
infrastructure data the System determines that
3
there is a high probability of collision or
accident with incoming OV
SP1 Subsystem updates the carriageway
4
attribute of the local dynamic map
5
Data available for SP4 subsystem.
6
7
Step
Action
Tilt sensor data delivers corrupted or failure
1a
message
Super ordinates
Subordinates
Open issues
Comments
Page 101 of 143
Copyright SAFESPOT
Case Name
PTW falling down on the road: PTW sends a warning signal
Case ID
SP1_UC7.1_11_v1.2
Status
Draft
PTW falls down on a section of a single/dual carriageway and stays
motionless on the road surface.
Short
description
Authors
Driving
Urban, Suburban, Motorway (more dangerous on curve section)
environment
Vehicle probe
All classes of probe vehicle as receiver, falling PTW as transmitter
type
Risk’s source
Precondition
Possible collision or accident with falling PTW
•
•
Falling PTW detects dangerous situation.
Page 102 of 143
Copyright SAFESPOT
•
Other equipped vehicle(s) within the broadcast range of the falling
PTW
•
Local dynamic map is updates with the information indicating
the falling PTW presence on the road.
•
Information about possible danger situation is broadcasted to
approaching ones.
•
Local dynamic map about carriageway condition status does not
change
Data are not broadcasted
Goal/Successful
end condition
Failed end
condition
Trigger
Sensor types
•
PTW tilt sensor activated
Tilt sensor.
and useful data
Actors/Entities
Scenario
Description
Extensions
Secondary Actors: SP2 subsystem and Other Probe Vehicles
Step
Action
1
Tilt sensor activation detects PTW fall down
SP1 system updates dynamic map with road information,
2
time stamp and possible further features/attributes
SP1 broadcasts the information to other vehicles or
3
infrastructures
Step
Action
1a
Tilt sensor data delivers corrupted or failure message
Infrastructure and other probe vehicle sensor faulty, error
2a
reading – Local data map is not updated
Super ordinates
Subordinates
Open issues
Comments
Page 103 of 143
Copyright SAFESPOT
Case Name
PTW overtaking OV while OV is making a turn: PTW detects that
preceding vehicle makes a turn.
Case ID
SP1_UC8_11_v1.2
Status
Draft
PTW overtakes a preceding OV and entering in collision path
with turning movement of the same OV
Short description
Authors
Driving environment
Urban, Suburban, Motorway
Vehicle probe type
All classes of probe vehicle
Risk’s source
Possible collision or accident with turning OV
•
•
scenario occurring.
•
•
Local dynamic map updates the roadway traffic condition
SP4 subsystem able to generate a warning signal and
advise information by receiving PTW and OV information
on their position
Local dynamic map about carriageway condition status
does not change
Required PTW and OV data not complete
Precondition
Goal/Successful end
condition
•
Trigger
Sensor types and
•
•
Preceding OV making a turn
GPS??
Information from infrastructure??
Approach to be discussed between T1.2.1 partners
Page 104 of 143
Copyright SAFESPOT
useful data
Actors/Entities
Extensions
Primary Actor: Other Probe Vehicle making a turn (preceding
vehicle)
Step
Action
PTW on board system detects the turning
1
maneuver
SP1 subsystem updates local dynamic map with
2
turning vehicle position
LDM data available for SP4 subsystem generate
3
Step
Action
SP3 modules broadcast LDM update/warning to
3a
SP2 subsystem, PTW and preceding OV
3b
Super ordinates
Subordinates
Open issues
Comments
Page 105 of 143
Copyright SAFESPOT
Case Name
PTW overtaking OV while OV is making a turn: PTW sends to
preceding vehicle a warning message
Case ID
SP1_UC8.1_11_v1.2
Status
Draft
PTW overtakes a preceding OV and entering in collision path
with turning movement of the same OV
Short description
Authors
Driving environment
Urban, Suburban, Motorway
Vehicle probe type
All classes of probe vehicle as (PTW) overtaking vehicle
Risk’s source
Possible collision or accident with preceding OV
Precondition
•
•
•
SAFEPROBE system operational
Overtaking PTW detects preceding OV make a turn.
Preceding OV within the broadcast range of the PTW
Local dynamic map updates the roadway traffic
condition.
o
SP4_subsystem able to generate a warning signal
and advise information by receiving PTW and OV
information on their position
• Local dynamic map about traffic status does not change
• Data not delivered to SP4 in a timely manner
• Required PTW and OV data not complete
o
Goal/Successful end
condition
Trigger
Sensor types and
useful data
PTW overtaking
GPS
Information from infrastructure
Approach to be discussed between T1.2.1 partners
Page 106 of 143
Copyright SAFESPOT
Actors/Entities
Extensions
Secondary Actors: OV and SP2 subsystem
Step
Action
Message broadcast SP2 subsystem indicating
1
PTW incoming
SP1 subsystem updates local dynamic map with
2
OV position
LDM data available for SP4 subsystem generate
3
Preceding OV who is in direct communication
range with the PTW receives the message
Step
Action
SP3 modules broadcast LDM update/warning to
1a
SP2 subsystem, PTW and preceding OV
Super ordinates
Subordinates
Open issues
Comments
Page 107 of 143
Copyright SAFESPOT
Case Name
Ego vehicle carrying dangerous goods approaches other vehicle.
Case ID
SP1_UC9_4_v1.0
Status
Draft
The ego vehicle is a commercial vehicle carrying dangerous
goods traveling along (a tunnel / road) with two lanes,
approaching an other vehicle
Short description
Authors
Andreas Ekfjorden, Volvo
Driving environment
Highway, Extra-urban, …
Vehicle probe type
Risk’s source
Precondition
Goal/Successful end
•
•
A commercial vehicle
All classes of probe vehicle possible as other vehicle
Dangerous goods (causing more severe accidents and needs
extra margins)
• Ego vehicle and secondary vehicle traveling along a 2lane one-way road.
• Both are SAFESPOT vehicles
• Ego vehicle has information on its own cargo type
Vehicle goods data is sent to SP3 application for broadcasting
condition
Trigger
Sensor types and
useful data
Actors/Entities
•
•
Data is not sent correctly
Data is not sent at all
The ego vehicles on-board system indicates dangerous goods.
•
Information on goods type on host vehicle’s on-board
system.
Primary Actor: SP4 subsystem in ego vehicle
Secondary Actor: Other vehicle
Iinternal Entity: SP3_module
Truck Vehicle on-board system – secondary actor
Infrastructure device – secondary actor
Page 108 of 143
Copyright SAFESPOT
Step
1
2
3
Extensions
Step
1a
2a
Action
Ego detects dangerous goods on-board
The information is transferred to SP3
SP3 module broadcasts goods status to other
vehicles and infrastructure devices.
Action
Super ordinates
Subordinates
Open issues
Comments
Page 109 of 143
Copyright SAFESPOT
Case Name
Ego vehicle carrying dangerous goods approaches other vehicle.
Case ID
SP1_UC9.1_4_v1.0
Status
Draft
goods traveling along (a tunnel / road) with two lanes,
approaching an other vehicle
Short description
Authors
Driving environment
•
•
Vehicle probe type
Risk’s source
Precondition
Goal/Successful end
condition
A commercial vehicle
All classes of probe vehicle possible as other vehicle
extra margins)
• The ego vehicle is detected as carrying dangerous goods
Local dynamic map is updated with the information on dangerous
goods truck.
Local dynamic map is not updated
Trigger
Ego vehicle approaches other vehicle at a predefined distance
Sensor types and
•
•
useful data
Actors/Entities
Information on goods type on host vehicle’s on-board system.
Position information from SP3 system
Primary Actor: Other vehicle
Secondary Actors: SP4 subsystem in ego vehicle and Truck
Vehicle on-board system
Iinternal Entity: SP3_module
Page 110 of 143
Copyright SAFESPOT
Extensions
Step
1
2
3
Step
1a
2a
Action
SP4 application detects the trigger situation
SP4 application sends information to SP3_module
SP3_module transfers information to other vehicle
Action
Super ordinates
Subordinates
Open issues
Comments
Page 111 of 143
Copyright SAFESPOT
Case Name
Ego vehicle approaching truck carrying dangerous goods.
Case ID
SP1_UC10_4_v1.0
Status
Draft
goods traveling along (a tunnel / road) with two lanes
Short description
Authors
Driving environment
•
Vehicle probe type
Risk’s source
Precondition
•
All classes of probe vehicle possible as (ego)
approaching vehicle
At least one Truck
extra margins)
• Information on goods type is sent from truck
condition
Local dynamic map is updated with the information on
dangerous goods truck.
Trigger
The ego vehicle is approaching a dangerous goods vehicle
Goal/Successful end
Sensor types and
Information on goods type on host vehicle’s on-board system.
useful data
Actors/Entities
Secondary Actors: Truck and Truck Vehicle on-board system
Step
Action
Page 112 of 143
Copyright SAFESPOT
1
2
Extensions
3
4
Step
1a
2a
Car is approaching from behind.
Car receives information from truck about type of
goods.
Local dynamic map is updated on ego vehicle
Updated LDM data is available to SP4 applications
Action
Super ordinates
Subordinates
Open issues
Comments
Page 113 of 143
Copyright SAFESPOT
Case Name
Ego vehicle approaching truck carrying dangerous goods in
tunnel.
Case ID
SP1_UC10.1_4_v1.0
Status
Draft
goods traveling along a tunnel with two lanes
Short description
Authors
Driving environment
Tunnel
•
Vehicle probe type
Risk’s source
Precondition
All classes of probe vehicle possible as (ego)
approaching vehicle
• At least one Truck
extra margins), especially dangerous inside a tunnel
• Vehicles are detected to be inside a tunnel
condition
Local dynamic map is updated with the information on
dangerous goods truck.
Trigger
The ego vehicle is approaching a dangerous goods vehicle
Goal/Successful end
•
Sensor types and
useful data
Actors/Entities
system.
• Information from infrastructure on the driving environment
(tunnel)
Secondary Actors: Truck, Truck Vehicle on-board system and
Infrastructure device
Page 114 of 143
Copyright SAFESPOT
Step
1
Extensions
2
3
4
Step
1a
2a
Action
Car receives information on driving environment
Car receives information on goods type (dangerous
goods)
Local Dynamic Map on ego vehicle is updated
Updated LDM data is available to SP4 applications
Action
Super ordinates
Subordinates
Open issues
Comments
Page 115 of 143
Copyright SAFESPOT
Case Name
Ego vehicle approaching truck carrying dangerous goods in
tunnel.
Case ID
SP1_UC10.2_4_v1.0
Status
Draft
The ego vehicle approaches a commercial vehicle carrying
dangerous goods traveling along a tunnel / road with two lanes
Short description
Authors
Driving environment
Highway, Tunnel
•
Vehicle probe type
Risk’s source
Precondition
Goal/Successful end
All classes of probe vehicle possible as approaching
vehicle
• At least one Truck
extra margins), especially dangerous inside a tunnel
SP4 application receives updated information
condition
Trigger
Information is not correct or not at all sent
The LDM is updated with goods type information (dangerous
goods status is updated)
•
Sensor types and
useful data
Actors/Entities
system.
• Information from infrastructure on the driving environment
(tunnel)
Secondary Actors: Truck and Truck Vehicle on-board system
Page 116 of 143
Copyright SAFESPOT
Step
1
2
3
Extensions
Step
1a
2a
Action
Data is available in the LDM
The data is sent to the SP4 application
Sp4 application initiate relevant information to the
driver
Action
Super ordinates
Subordinates
Open issues
Comments
Page 117 of 143
Copyright SAFESPOT
Case Name
Ego vehicle approaching in progress works in a sub-urban road
Case ID
SP1_UC11_51_v2.0
Status
Short description
Draft
Vehicle is approaching in progress works in a sub-urban bidirectional
double lanes road; lane width reduced for 200 meters beyond
Authors
P. Mortara L.Picerno
Driving environment
Sub-urban road
Vehicle probe type
Ego vehicle (car, truck, PTW…)
Risk’s source
Potential collision with other vehicles and VRUs in proximity, or with
operation machines.
Safeprobe system operational with V2V and V2I communication
active
The LDM of the Ego vehicle updated on time of info about working
Goal/Successful end area, operation machines and oncoming vehicles. This message is
broadcasted by ego vehicle to other probe vehicles broadcast
condition
strategies of SP3
Failure in the communication, applications not ready to receive or not
Failed end condition present
Precondition
Ego vehicle approaches the works area
Trigger
Frequency
occurrence
Sensor types
of
and
Unpredictable
Obstacle sensor, lateral and front collision sensors
useful data
Actors/Entities
Scenario
Primary Actor: SP4_subsystem Other probe Vehicles
SP3_module – internal entity
Secondary Actor(s) and/or Entities: SP3 Module , other vehicles
Step
Action
1
Ego vehicle approaches the working area
Page 118 of 143
Copyright SAFESPOT
2
3
4
5
6
Step
Extensions
It gets from Infrastructure (I2V communication) info about
minimal road width and length of the working area and from
V2V communication or on board sensors the position and
dynamic information of possible vehicle coming in the
opposite direction and operation machines active in the
working area.
SP1 system updates the local dynamic map with the
information of the working area (position, width and length)
SP1 system update the local dynamic map with the vehicles
coming in the opposite direction
SP1 system updates the local dynamic map with operation
machines.
SP3_module broadcasts the working area information to
other probe vehicles
Action
No extensions
Super ordinates
Subordinates
Open issues
Comments
The working area is described as a geographic object (width, length,
relative position) or as complex object (containing additional objects:
on coming vehicles and or operation machines)? This means a
different sharing of tasks between SP1 and SP4.
SP 4 application will give way to operation machines (caterpillars…)
on the road, and a will establish a priority access strategy with other
V2V probe vehicles if the width reduction allows only an alternate one
way passing. Proper warning will be given to the driver, Otherwise, if
two way traffic is still available a simpler information is provided to the
driver that should take the closest position to available carriageway
margin in the direction of traffic
Page 119 of 143
Copyright SAFESPOT
Case Name
Lost load in lane of oncoming traffic
Case ID
SP1_UC11.1_5_v0.1
Status
Draft
Lost load in lane of oncoming traffic detected by ego vehicle, ego vehicle
broadcast position of lost load to oncoming vehicles before they pass the
dangerous spot
Short
description
Authors
Driving
Rural road
environment
Vehicle probe
All classes of probe vehicles equipped with suitable ENP sensors
type
Risk’s source
Collision of oncoming vehicles with lost load on their lane, spot in curve,
blocked view (no risk for ego vehicle)
Page 120 of 143
Copyright SAFESPOT
•
Precondition
•
•
Ego vehicle has passed lost load on lane of oncoming traffic and has
detected the obstacle with ENP sensors. It is 700m away from that
spot, other vehicle (oncoming) is 300m ahead
2 SAFEPROBE systems operational
Local dynamic map contains information relating to the driving
environment and current situation prior to the scenario occurring.
end condition
Local dynamic map has been updated with load object, warning message
about the lost load (=message with obstacle position, time stamp,) is
generated and sent to oncoming vehicle(s)
Failed end
•
Goal/Successful
condition
timely, warning message is not generated or sent
Trigger
Oncoming vehicle enters COM range
Sensor types
ENP sensors to detect and classify the obstacle; VDM, NAV to locate the
obstacle accurately in the LDM
and useful data
Actors/Entities
Scenario
Description
Primary Actor: Other probe vehicle
Step
Action
Ego vehicle passes the lost load lying on the lane of the
1
oncoming traffic, it detects the obstacle with suitable
ENP sensors and the SP1 subsystem updates the LDM
An oncoming vehicle enters the COM range of the ego
vehicle and the ego vehicle (SP3 module) sends a
2
(warning) message with information about the lost load
to the oncoming vehicle
3
Step
Action
Extensions
4
Super ordinates
SP1_UC12_5_v0.1 (succeeding use case)
Subordinates
Open issues
Comments
Page 121 of 143
Copyright SAFESPOT
Case Name
Lost load in ego lane
Case ID
SP1_UC11.2_5_v1.0
Status
Draft
Lost load in ego lane, oncoming vehicle has detected it and sends
information about it to ego vehicle
Short
description
Authors
Driving
Rural road
environment
Vehicle probe
type
Risk’s source
Precondition
Lost load on carriage way in curve, blocked view
•
See scenario 2 (from Bosch): ego vehicle approaching lost load on
ego lane, 1km away, oncoming vehicle has detected the obstacle from
Page 122 of 143
Copyright SAFESPOT
•
•
Goal/Successful
end condition
Failed end
its opposite lane and already passed the object and is reporting to ego
about detection, distance to ego 300m at use case trigger
Local dynamic map has been updated with lost load object and its
attributes (state), SP4_subsystem able to generate obstacle on the road
warning and advise information.
Local dynamic map lane traffic condition status does not change timely
condition
Trigger
Sensor types
and useful data
Actors/Entities
Scenario
Description
Extensions
Communication message from oncoming vehicle with obstacle
information
No ego sensing assumed for obstacle detection (1km distance to
obstacle), useful data only from oncoming vehicle
Secondary Actor: Other probe vehicles
Step
Action
Com message from oncoming vehicle indicating
1
obstacle in ego lane
road/lane segment) with lost load position, time stamp
2
(and further attributes)
Note: no fusion with internal vehicle data (ENP,) except
static map data or previous obstacle entries in LDM
3
obstacle warning and driving advise
Step
Action
SP3 module broadcasts LDM update / warning to SP24
subsystem and other probe vehicles
Super ordinates
SP1_UC13_5_v0.1 (succeeding use case)
Subordinates
SP1_UC11_5_v0.1 (preceding use case)
Open issues
Comments
Page 123 of 143
Copyright SAFESPOT
Case Name
Lost load in ego lane (2)
Case ID
SP1_UC11.3_5_v1.0
Status
Draft
Lost load in ego lane, oncoming vehicle has detected it and has
informed/warned ego vehicle by COM, ego vehicle detects lost load itself
and sends update message to succeeding vehicles
Short
description
Authors
Driving
Rural road
environment
Vehicle probe
All classes of probe vehicles with suitable ENP sensors
type
Risk’s source
Lost load on carriage way in curve, blocked view
Page 124 of 143
Copyright SAFESPOT
•
Precondition
•
•
See scenario 2 (from Bosch), ego vehicle approaching lost load on
ego lane, 150m away, succeeding vehicle 50m away
Local dynamic map has been updated with lost load object and its
Goal/Successful attributes (state), SP4_subsystem able to generate obstacle on the road
warning and advise information, message with updated information about
end condition
load generated and sent to succeeding vehicle
Failed end
No warning message sent to succeeding vehicle
condition
Trigger
Detection from ENP sensors
Sensor types
ENP sensors to detect and classify the obstacle; VDM, NAV to locate the
obstacle accurately in the LDM
and useful data
Actors/Entities
Scenario
Description
Extensions
Secondary Actor: Other probe vehicles
Step
Action
LDM of ego vehicle contains obstacle (lost load),
1
information obtained from oncoming vehicle
2
Obstacle gets in range of ego vehicle’s ENP sensors
3
Fusion of the ENP detections to the LDM (LDM update)
SP3 module broadcasts LDM update / warning to SP23
subsystem and other probe vehicles
Step
Action
4
improved obstacle warning and driving advise
Super ordinates
Subordinates
SP1_UC11_5_v0.1, SP1_UC12_5_v0.1 (preceding use cases)
Open issues
Comments
Page 125 of 143
Copyright SAFESPOT
Case Name
Emergency vehicle approaching
Case ID
SP12_UC1_51_v2.0
Status
Draft
Emergency vehicle is approaching in a sub-urban bidirectional double
lanes road requesting blue corridor
Short description
Authors
P. Mortara L.Picerno ( MMSE)
Driving environment
Sub-urban road
Vehicle probe type
Emergency vehicle
Risk’s source
Potential collision with vehicles and VRUs in proximity
Precondition
Safeprobe system operational with V2V and V2I communication active
Goal/Successful
end The emergency (Ego) vehicle is added to LDM of other probe vehicles
condition
and its message is broadcasted by other probe vehicles according to
geo broadcast strategies of SP3
Failure in the communication, applications not ready to receive or not
present
Trigger
Frequency
occurrence
Emergency vehicle activates blue corridor request
of
Unpredictable
Sensor types and useful Switch sensor blue corridor request (e.g. Linked to the emergency
data
siren activation)
Actors/Entities
Primary Actor: SP4_subsystem Other probe Vehicles
Page 126 of 143
Copyright SAFESPOT
SP3_module – internal entity
Secondary Actor(s) and/or Entities: SP3 Module, other vehicles
Step
1
2
3
4
5
Step
Extensions
Action
Emergency vehicle activates a blue corridor request
The SP3_module of the emergency vehicle start to
broadcast a blue corridor request to others equipped
vehicles and to infrastructure
SP3_module of other probe vehicles receive the data of the
emergency vehicle and broadcasts the message to other
probe vehicles and the infrastructure
SP1 system of other equipped vehicles updates the local
dynamic map
LDM of other probe vehicles is made available to SP4
application of their respective probe vehicles.
Action
No extensions
Super ordinates
Subordinates
Open issues
Comments
The presence of the Emergency Vehicle will be used by SP4 in other
probe vehicles to warn the drivers that should slow down and move to
the road border leaving blue corridor for the emergency vehicle.
Page 127 of 143
Copyright SAFESPOT
Case Name
Ego-vehicle hard braking while other is following: situation is
detected
Case ID
SP1_UC13_29_v1.0
Status
Final
Ego-vehicle starts braking very hard while other vehicle (including
PTW) is following. Environment status is detected and local
dynamic map is updated
Short description
Authors
Driving
Nikos Floudas, ICCS
All classes of driving environments
environment
Vehicle probe
Car, Truck
type
Risk’s source
Risk of collision with vehicle that follows ego-vehicle
•
•
Precondition
Goal/Successful
end condition
Failed end
condition
Trigger
Sensor types and
useful data
•
Information on driving environment at the rear side of egovehicle available
scenario occurring.
Local dynamic map updates the driving situation; risk of collision
can be detected.
Local dynamic map is not updated at all or in time; situation cannot
be detected
Detected abrupt ego-vehicle deceleration combined with existence
of vehicle(s) following it
Vehicle dynamics and environmental systems (sensing objects
moving to the rear side of ego-vehicle). Alternatively, rear side
information can be sent by other platform to ego-vehicle local
dynamic map.
Page 128 of 143
Copyright SAFESPOT
Actors/Entities
Scenario
Description
Extensions
Primary Actor: SP4 subsystem (user)
Secondary Actors: Other vehicle(s) and (external)
Internal Entities: SP3 module, vehicle dynamics and environmental
systems
Step
Action
SP1 system local dynamic map available with
1
indication of vehicles that are following ego-vehicle
SP1 system through vehicle dynamics identifies
2
hard braking
3
Local dynamic map is updated
4
Collision situation is detected
Step
Action
There are no sensors sensing rear area of vehicle,
1a.1
a hard braking warning can be send also in this
case
but there is a probe vehicle following that transmits
1a.2
its location information (including also other
vehicles)
Super ordinates
Subordinates
SP1_UC13.1_29_v1.0, SP1_UC13.2_29_v1.0
Open issues
Comments
As defined in the scenario 13 ego-vehicle is the vehicle that brakes.
The case that ego-vehicle is following the braking vehicle can be a
use case of scenario 1.
Page 129 of 143
Copyright SAFESPOT
Case Name
detected and warning is given to the driver
Case ID
SP1_UC13.1_29_v1.0
Status
Final
PTW) is following. Environment status is detected, local dynamic
map is updated warning is given to the driver
Short description
Authors
Driving
Nikos Floudas, ICCS
environment
Vehicle probe type
Car, Truck
Risk’s source
•
•
Precondition
Goal/Successful
end condition
Failed end
condition
Trigger
Sensor types and
useful data
•
scenario occurring.
Local dynamic map updates the driving situation; risk of collision is
detected and warning is given to the driver.
be detected and warning cannot be given
dynamic map.
Page 130 of 143
Copyright SAFESPOT
Actors/Entities
Scenario
Description
Extensions
Super ordinates
systems
Step
Action
1
2
hard braking
3
4
SP4 generates information/warning message and
5
sends it to the driver
Step
Action
1a.1
a hard braking warning can be sent also in this
case
1a.2
vehicles)
SP1_UC13_29_v1.0
Subordinates
Open issues
Comments
Page 131 of 143
Copyright SAFESPOT
Case Name
detected and warning is given to other probe vehicles
Case ID
SP1_UC13.2_29_v1.0
Status
Final
PTW) is following. Environment status is detected, local dynamic
map is updated warning is given to other probe vehicles
Short description
Authors
Driving
Nikos Floudas, ICCS
environment
Vehicle probe type
Car, Truck
Risk’s source
•
•
Precondition
Goal/Successful
end condition
Failed end
condition
Trigger
• Other SP2 platforms operational and within broadcast
range of ego-vehicle
scenario occurring.
Local dynamic map updates the driving situation; risk of collision is
detected and enables SP4 subsystem to generate warning or
advise information message, other SP2 platforms receive the
message.
be detected and warning cannot be given.
Local dynamic map is updated and message is generated but the
message does not reach the probe vehicle(s) in time.
Page 132 of 143
Copyright SAFESPOT
Sensor types and
useful data
Actors/Entities
Scenario
Description
Extensions
dynamic map.
systems
Step
Action
1
Other probe vehicles exist within broadcast range
2
of ego-vehicle
3
hard braking
4
5
6
sends it to other vehicles
7
Other probe vehicle(s) receive the message
Step
Action
a hard braking warning can be send also in this
1a.1
case
1a.2
7a
Super ordinates
vehicles)
Other probe vehicle(s) process the message and
can generate their own messages
SP1_UC13_29_v1.0
Subordinates
Open issues
Comments
Page 133 of 143
Copyright SAFESPOT
Case Name
Ego-vehicle overtaking in collision path: system detects danger
Case ID
SP1_UC14_29_v1.0
Status
Final
Ego-vehicle overtakes a vehicle changing lane and entering into a
collision path with other oncoming vehicle. Vehicle on board
sensors detect the dangerous situation
Short description
Authors
Driving
Nikos Floudas, ICCS
environment
Vehicle probe type
Risk’s source
Precondition
Goal/Successful
end condition
Car, Truck
Risk of collision with vehicle that is coming to the path of egovehicle
• SAFEPROBE system operational
• Sensors observing frontal area of ego-vehicle or relevant
information of this area available from communication
scenario occurring.
Local dynamic map is updated with the new driving situation and
risk of collision is detectable
condition
Local dynamic map is not updated at all or in time; consequently
the risk of collision cannot be detected
Trigger
Detected on-coming traffic in the path of ego-vehicle while
overtaking
Failed end
Sensor types and
useful data
moving to the frontal side of ego-vehicle)
Page 134 of 143
Copyright SAFESPOT
Actors/Entities
Scenario
Description
Extensions
Secondary Actors: Other vehicles and (external)
Internal Entities: SP3 module, vehicle dynamics and
environmental systems
Step
Action
1
SP1 system local dynamic map available
SP1 system through vehicle dynamics and
environmental systems identifies ego-vehicle
2
motion in collision path with on-coming vehicle(s)
3
4
Step
Action
The on-coming vehicles are out of range or view of
sensors but relative position information is
2a.1
transmitted by other probe platform in the area
Super ordinates
Subordinates
SP1_UC14.1_29_v1.0, SP1_UC14.2_29_v1.0
Open issues
Comments
As defined in scenario 14 ego-vehicle is the vehicle that overtakes.
The opposite case with the ego-vehicle driving while from the
opposite direction an overtaking vehicle is coming is covered by
scenario 2
Page 135 of 143
Copyright SAFESPOT
Case Name
and driver is warned
Case ID
SP1_UC14.1_29_v1.0
Status
Final
sensors detect the dangerous situation and driver is warned
Short description
Authors
Driving
Nikos Floudas, ICCS
environment
Vehicle probe type
Risk’s source
Precondition
Goal/Successful
end condition
Car, Truck
scenario occurring.
Local dynamic map is updated with the new driving situation and
risk of collision is detected and driver warning is generated
condition
Local dynamic map is not updated at all or in time; consequently
the risk of collision cannot be detected and warning to the driver is
not generated
Trigger
overtaking
Failed end
useful data
Actors/Entities
Sensor types and
Page 136 of 143
Copyright SAFESPOT
Extensions
Internal Entities: SP3 module, vehicle dynamics and
environmental systems
Step
Action
1
2
3
4
SP4 generates information/warning message and is
5
sent to the driver
Step
Action
2a.1
Super ordinates
SP1_UC14_29_v1.0
Scenario
Description
Subordinates
Open issues
Comments
scenario 2
Page 137 of 143
Copyright SAFESPOT
Case Name
and warning message is transmitted to other probe vehicles
Case ID
SP1_UC14.2_29_v1.0
Status
Final
sensors detect the dangerous situation and a warning is
transmitted to other nearby probe vehicles.
Short description
Authors
Driving
Nikos Floudas, ICCS
environment
Vehicle probe type
Risk’s source
Precondition
Goal/Successful
end condition
Failed end
condition
Trigger
Car, Truck
• Other SP2 platforms operational and within broadcast
range of ego-vehicle
scenario occurring.
Local dynamic map is updated with the new driving situation; risk
of collision is detected which enables SP4 subsystem to generate
warning or advise information message and other SP2 platforms
receive the message successfully.
1) Local dynamic map is not updated at all or in time; situation
cannot be detected and warning cannot be given.
2) Local dynamic map is updated and message is generated
but the message does not reach the probe vehicle(s) in
time.
overtaking
Page 138 of 143
Copyright SAFESPOT
Sensor types and
useful data
Actors/Entities
Scenario
Description
Extensions
systems
Step
Action
1
Other probe vehicles exist within broadcast range
2
of ego-vehicle
3
4
5
6
sends it to the driver
7
Other probe vehicle(s) receive the message
Step
Action
2a.1
Other probe vehicle(s) process the message and
7a
can generate their own messages
Super ordinates
Subordinates
SP1_UC14.1_29_v1.0, SP1_UC14.2_29_v1.0
Open issues
Comments
scenario 3.
Page 139 of 143
Copyright SAFESPOT
Case Name
Slippery road condition: Ego vehicle detects Ice on the road
Case ID
SP1_UC15_32_v1.0
Status
Draft
that the road surface is slippery as a result of ice on the
carriageway
Short description
Authors
Driving
Motorway
environment
Vehicle probe type
Truck, car, PTW
Risk’s source
Ice on the road
Precondition
Goal/Successful
end condition
Failed end
condition
•
•
scenario occurring.
Local dynamic map updates the road surface condition to indicate
ice on the road to enable SP4_subsystem to determine whether to
generate ice warning and advise information.
•
•
•
Local dynamic map road condition status does not change
Required sensor data not complete
Page 140 of 143
Copyright SAFESPOT
Trigger
Sensor types and
EPS, ABS activated
To be competed as part of the useful data task
useful data
Actors/Entities
Scenario
Description
Extensions
Primary actor: SP4 subsystem
Secondary actor: Vehicle_data_sources
Internal entity: SP3_module
Step
Action
Ego vehicle_data_sources (ESP, ABS etc.)
1
activated low road friction indicated
Outside air temperature sensor indicates that the
2
current air temperature is within the ice indication
range
From the fusion of the vehicle data the ego vehicle
3
System determines that there is a high probability of
ice on the road
The Ego vehicle System updates the local dynamic
4
map
Local dynamic map data available for SP4
5
subsystem to generate collision warning and driving
advise
Step
Action
ESP, ABS data delivers corrupted or failure
1a
message
Outside air temperature sensor faulty, error reading
2a.1 From data fusion process LDM road surface
2a
condition attribute is updated with a non-specific
slippery road condition status
Super ordinates
Subordinates
Open issues
Comments
•
•
Pre-conditions may form a separate driving scenario
Feasibility of mapping useful sensor data to use to be
discussed
Page 141 of 143
Copyright SAFESPOT
Case Name
Ego vehicle receives warning of ice on the road
Case ID
SP1_UC15.1_32_v1.1
Status
Draft
that the road surface is slippery as a result of ice on the
carriageway
Short description
Authors
Driving
Motorway
environment
Vehicle probe type
Truck, car PTW
Risk’s source
Ice on the road
•
•
Precondition
•
Goal/Successful
end condition
Failed end
condition
scenario occurring.
Other equipped vehicle(s) within the broadcast range of the
ego vehicle
Local dynamic map updates the road surface condition to indicate
ice on the road to enable SP4_subsystem to determine whether to
generate ice warning and advise information.
•
•
Local dynamic map road condition status does not change
for relevant vehicles
Data not delivered to SP4_subsystem in a timely manner
Page 142 of 143
Copyright SAFESPOT
Trigger
Ego vehicle detecting Ice on the road
Sensor types and
BOD system detect outside temperature, data from ENP systems
used to determine low road friction
useful data
Actors/Entities
Scenario
Secondary Actor: Other_probe_vehicle(1),
Other_probe_vehicle(2), SP2_subsystem and Vehicle data
sources
Step
Action
Ego vehicle detects ice on the road
1
(SP1_UC1_32_v1.0)
Ego vehicle determines from the relative localization
2
module that there are other vehicles within its
communication range
3
SP3_module broadcasts the message
Other_probe_vehicle (1) who is in direct
communication range with the ego vehicle receives
4
the message
5
Description
6
7
8
9
Step
Other_probe_vehicle (1) system determines that the
message is not of relevance to its current trajectory
SP3_subsystem of Other_Vehicle (1) rebroadcasts
the message
Other_vehicle(2) heading towards the position
where the ego vehicle generated the ice-warning
message receives the message from
other_probe_vehicle_2.
Other_probe_vehicle (2) updates its local dynamic
map with the ice warning
Fused data available for SP4_subsystem of
Other_probe_vehicle(2), to generate ice warning
and driving advise to the driver
Action
Extensions
Super ordinates
Subordinates
(SP1_UCP_32_v1.0)
Open issues
Comments
Page 143 of 143

Vehicle probe use cases and test scenarios

Transcription

Similar documents

Selling and Demonstrating In

CAMPING** Gennes - Camping Au Bord de Loire

Ford Powerstroke 6.4L - BorgWarner Turbo Systems

Mall - Powerpoint Skånetrafiken

Special Operations Tactical Vehicle Sales Brochure

MILLTEK SPORT / / EXHAUST FITTING MANUAL

KFOR Chroninle_MASTER_August_2014.indd

Life Without Oil: Microcab H2EV – 2011

Ferrari Enzo

Autorama