Vehicle probe use cases and test scenarios

Transcription

1 SAFESPOT INTEGRATED PROJECT - IST 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 Task Title Vehicle Probe Use Cases Authors (per company, if more than one company provide it together) Status: Debra Topham, Gary Ford, David Ward (MIRA) Christian Zott (Bosch), Piero Mortara (MMSE) 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 1 of 143

2 Revision Log Version Date Reason Name and Company /6/06 Deliverable structure created Debra Topham MIRA Ltd /07/2006 Compiled 1 st draft revision Gary Ford MIRA Ltd /07/ nd draft revision Christian Zott, Bosch /08/ /08/ /08/ /09/ rd daft revision, pictograms added, re-wording paragraphs Internal review and general modifications to document Updated Scenario Tables & Use Cases 11_51 & 12_51 4 th draft revision based on Peer reviews Gary Ford MIRA Ltd Gary Ford / David Ward MIRA Ltd Piero Mortara, MMSE Gary Ford Mira Ltd SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 2 of 143

3 Abbreviation List C2C-CC CCWAS DWS EC ETSC EU EUCAR CC IST GPS GST PReVENT ITS IVI IVIS IVSS LAN LCW LDW PSAP PLATFORM PTW RT SAFELANE SAFEPROBE SASPENCE Sintech SoA SuD UMTS WILLWARN Car-to-Car Communication Co-operative Collision Warning and Avoidance System Driver Warning System European Commission European Transport Safety Council European Union European Association for Collaborative Automotive Research Cruise Control Information Society Technologies Global Positioning System Global System for Telematics Integrated project for preventative safety Intelligent Transportation System Intelligent Vehicle Initiative In-vehicle Information Systems Intelligent Vehicle Safety Systems Local Area Network Lateral Collision Warning Lane Departure Warning Public Safety Answering Points A set of technology, which acts as a foundation for real world applications. Powered two-wheeler Reaction time Situation Adaptive system for Enhanced Lane keeping support In-Vehicle Sensing and Platform Safe Speed and Safe Distance SAFESPOT Innovative Technologies State of the Art System under Design Universal Mobile Telecommunication System Wireless Localised danger Warning system SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 3 of 143

4 WLAN WP VRU V2V-C V2I SP Wireless Local Area Network Work Package Vulnerable Road User Vehicle to Vehicle Communication Vehicle to Infrastructure Sub Project SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 4 of 143

5 Table of contents Revision Log...2 Abbreviation List...3 List of Figures...6 List of Tables...6 Executive Summary Introduction Innovation and Contribution to the SAFESPOT Objectives Methodology Deliverable structure General Background SAFEPROBE in-vehicle platform Car platform Truck platform PTW platform Synergies with other subprojects SP1-SP SP1-SP SP1-SP Related Research Lateral Safe Saspence Safelane Willwarn Intersafe GST C2C-CC Selection of SAFEPROBE Scenarios Introduction Definition of SP1 Scenario Methodology for Scenario Title Selection Results of Scenario Title Selection Description of basic scenarios Introduction Methodology of basic scenario description Driving Scenario Attributes Diagram Use Case methodology Introduction Definition of an actor Description of a use case Use case template naming convention Use case suggestion list Conclusions References Annexes Annex Annex 2: Merged Scenario Table Annex 3: Scenario tables Annex 4: SAFEPROBE use cases SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 5 of 143

6 List of Figures Figure 2.1: High Level functional diagram of the SAFEPROBE platform Figure 2.2: Logic architecture of the SAFESPOT platform Figure 2.3: Possible block diagram of the SAFESPOT platform Figure 2.4: Volvo FH 4x2 Tractor Figure 2.5: Preliminary structure for Volvo demonstrator vehicle Figure 2.6: Piaggio X9 500 Evolution Figure 2.7: Activity flow diagram Figure 4.1: Driving Scenario Attributes diagram Figure 5.1: Reference model for probe vehicle systems Figure 5.2: Impacts on fatalities reduction Figure 5.3: Context diagram List of Tables Table 3.1: Scenario cluster tables Table 4.1 : Reduced Scenarios Table 5.1 : Example of actors and actor descriptions Table 5.2: Use Cases Index SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 6 of 143

7 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. 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. 2. 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. 3. 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. 4. 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. 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 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. SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 7 of 143

8 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 8 of 143

9 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 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. SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 9 of 143

10 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 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 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. SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 10 of 143

11 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 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 11 of 143

12 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. SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 12 of 143

13 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 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) SAFEPROBE standard IF, e.g. private CAN fusion, msg generation PC LAN Local Map IF (to application) Nav/map IF GPS raw IF power supply added HW Ad-hoc network proc. (routing, buff, security, ) car, truck, motorcycle PC WLAN IF IF: interface Figure 2.3: Possible block diagram of the SAFESPOT platform SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 13 of 143

14 The vehicle platform should be a suitable embedded module that can be mounted in cars, trucks and motorcycles 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 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 14 of 143

15 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 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 15 of 143

16 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 16 of 143

17 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. High Level Description Guidelines Guidelines (SP7) (SP7) High Level User Needs High Level Stakeholders High Level Stakeholders Identification Identification (SP7) (SP7) Scenarios User Needs Use Cases Technology analysis Technology analysis SP1-SP2-SP3 SP1-SP2-SP3 Tech Scenarios Sp1-SP2-SP3 Accident data Analysis Accident data Analysis +SoA +SoA Analysis Analysis SP4-SP5 SP4-SP5 Common Basic Scenarios SP4-SP5 User\Actors User\Actors Identification Identification SP SP (SP1-5) User (of the Subsystem) Needs (SP ) Use Cases (SP ) Requirements System Requirement SP5 System Requirement SP4 System Requirement SP2 System Requirement SP1 System Requirement SP3 Figure 2.7: Activity flow diagram 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. SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 17 of 143

18 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 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. SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 18 of 143

19 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 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: SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 19 of 143

20 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 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 20 of 143

21 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 Safelane Another PReVENT subproject is SAFELANE with goal to develop a situation adaptive system for enhanced lane keeping support. Deliverable 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 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 21 of 143

22 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 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 22 of 143

23 potential for accident prevention and accident mitigation achievements can be proven in a quantitative, risk-free and reproducible manner 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. SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 23 of 143

24 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 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 , 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 24 of 143

25 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 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 25 of 143

26 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. normal driving b. road surface condition change c. lane traffic condition change d. traffic condition change e. weather/visibility change f. approaching intersection g. significant road geometry change h. lane change i. 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. essential SAFEPROBE scenario (top priority) b. SAFEPROBE relevant c. Nice to have d. Not specific enough or too general e. 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 26 of 143

27 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 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. SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 27 of 143

28 Table 3.1: Scenario cluster tables SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 28 of 143

29 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 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 29 of 143

30 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 30 of 143

31 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. SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 31 of 143

32 Figure 4.1: Driving Scenario Attributes diagram SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 32 of 143

33 Number Scenario Partner Contribution 1 Ego turn, approaching obstacle (VRU, load, slow vehicle, jam) or crossing its path MIRA 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 (inside a tunnel, on motorway) CRF 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 usage Emergency vehicle approaching - blue corridor 12 required MMSE MMSE Ego-vehicle starts braking very hard while other vehicle (PTW) is following Overtaking ego on collision path with oncoming vehicle ICCS ICCS 15 Ice Warning MIRA Table 4.1 : Reduced Scenarios SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 33 of 143

34 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 SP_D1 2 1_Vehicle_Probe_UseCase_v1.6.doc Page 34 of 143