1. SAFEPROBE Project Status of SP1 Christian Zott!
Project Status of SP1
Christian Zott
Bosch (Schwieberdingen, Germany)
SP1 “In-Vehicle Platform and Sensing” leader

2. SP1 Schedule and Milestones
Activity
D1.2.1, 1.2.2, completed
23.4. DF spec to peer review (CRF)
24.8. public DF spec to peer review (CRF)
24.7. HW/SW spec to peer review (Bosch)
24.8. public HW/SW spec to peer rev. (CRF)
4 regular SP1 meetings in 2006: Berlin, Turin, Birmingham, Turin + ~ participation at 6 other SPs + KO + CG

3. SP1: Partners’ Effort and InvolvementMM

4. D1.2.1 Vehicle Probe Use Cases
SP1 system boundaries and actors defined
Bottom-up methodology:
Use case creation, merging
and selection (voting)
based on partners’ expertise
Tabular use case description →
Use case elements:
Scenario attributes
Event types
Event handling

5. Examples of SP1 Scenarios

6. D1.2.2 System Analysis of In-Vehicle Data
Collection of ~ 200 data titles in 6 cluster
ENP Environmental Perception
NAV Navigation and Positioning
VDM Vehicle Dynamics Management
BOD Body Management
OSS Occupant Safety Systems
SVD Static Vehicle Data
Allocation of data (cluster) to event types and use cases
Performance definitions and assessments:
Time-to-notification (TTN), accuracy & integrity of notification
Data availability trees (scenario & technology dependency)
Typical performance figures
Performance risks for use cases

7. D1.2.2, In-vehicle Data Examples
Vehicle Dynamics Management
Body Systems
Environmental Perception, e.g. Radar / Laserscanner
Occupant Safety Systems
Navigation Systems, e.g. static map data
Vehicle speed
Turn signal on
Longitudinal distance (range)
Airbags fired
Latitude / Longitude of shape points
Wheel speeds
Hazard warning lights
Lateral distance or azimuth and elevation
Crash signal status
(no crash / pretensioners / first level / second level)
Curvature of road element
Yaw rate
Wiper setting
Relative velocity (range rate)
Roll-over detected
Speed restriction
Lateral acceleration
Low / high beam headlighs on
Relative acceleration
Seat belt locked
Number of lanes
Longitudinal acceleration
Fog lights on
Track score
Lane category
ABS/ESP brake intervention
Hood open
Object class (e.g. pedestrian, PTW, car, truck, bike)
Lane type (exit, entrance, overtaking, emergency,…)
Brake pedal touched
Outside air temperature
Lane divider type (dashed, solid,…)
Brake light on
Ignition on
Lane direction (ahead, left, right, u-turn,…)
Friction coefficient estimation
PTW tilted

8. Qualitative Performance Assessment
Radar just taken as an example here

9. D1.2.3 Requirements Requirement Types General Hardware
Software & Architecture
Sensor
Data Fusion
Use Case derived
Requirement’s Attributes
System requirement ID
Name
System req’t definition
System req’t relevance
Responsibility
Type of system requirement
Rationale
Requirements
Scenarios
User Needs
Use Cases
Common Basic Scenarios SP4-SP5
User (of the Subsystem) Needs (SP )
Accident data Analysis +SoA Analysis SP4-SP5
Technology analysis
SP1-SP2-SP3
User\Actors
Identification SP
Use Cases (SP )
High Level User Needs
Guidelines
(SP7)
High Level Stakeholders
Tech Scenarios
(SP1-5)
System Requirements SP3
System Requirements SP5
System Requirements SP2
System Requirements SP4
System Requirements SP1
High Level Description

10. WP1.3 Specification Results
Current Architecture
Clients:
SP4/5 applications
SafeSpot message generation
Visualization of current LDM contents
Brokers:
cast requests into queries and subscriptions to notifications
select/filter data
translate messages, notifications
remote procedure calls over platform network
VANET: Vehicular Ad-hoc Network
LDM: Local Dynamic Map
Q-API: Query API
T-API: Transaction API
SP1-5,7
SP3
SP4/5

11. WP 1.3 Specification Results
Current Architecture (cont’d)
Data Fusion on Multiple Levels:
Raw sensor data, e.g. ranges, angles
Features, e.g. edges, reflection points
Object data, e.g. bounding boxes, lane lines, object attributes
Situations/Events, e.g. relations between objects, trajectory intersections, region/zone entering or exiting
SP1/2
SP3
SP1-5,7

12. Rationale for Client-Server and Event Processing by Platforms
WP 1.3 Specification
Rationale for Client-Server and Event Processing by Platforms
Development Organisation
Clear responsibility allocation for application and platform SPs
Avoid duplication of function development by application SPs
Performance
Critical functions concentrated in platforms, e.g. latency reduction for relationship searching by efficient geo-data storage (e.g. spatial indexing)
All applications gain from advances in esp. situation/event level data fusion and geo-data algorithms
Reduction of traffic on LDM-application interface, e.g. using event driven notifications
Business models
Event and fusion abstraction attractive for suppliers of maps, sensors, platforms
Vehicle manufacturers and traffic control get standardized APIs

13. WP 1.3 Specification Next Steps
Detailed scenario definition and simulation:
Vehicles’ trajectories, collisions,…
Sensor & communication configuration: Placement, fields-of-view,...
Resulting detections times (sensing & communication), occlusions,…
Design of cooperative concepts:
Sensor-level to central-level fusion: Activity diagrams, data flow
Data models and dictionary, common with SP2, CVIS
Syntax (XML, ASN.1)
Semantics: Structure and behaviour (UML, XML)
Performance prediction of data fusion approaches:
Timing for sensing, communication, queries, fusion, LDM transaction,…
Accuracy of LDM contents for assumed configurations
“Do-able” scenarios (for given HW: vehicles, equipment)

14. WP 1.3 Specification
Open Java Micro Traffic Simulator for scenario exchange and detailed analysis, e.g. generation of timing diagrams
Executable, doc and sources at SSCA SP1 - SAFEPROBE / Working Area / WP3 / detection scenario simulation

15. WP 1.3 Specification Next Steps
Some Open Issues
Detailed contents of LDM (first class diagrams available)
Only presence or also future in LDM, e.g. predicted trajectory hypotheses?
What other kinds of “elementary” events in LDM?
SF Message definition and generation
Common task for SP1-5, 7
Until now some types identified:
Beaconing data (periodic, e.g. IDs, position, velocity, heading,…)
Raw data (object or sensor data)
Events (elementary or similar to TPEG-TEC)
Framing structure likely (c.f. ISO Probe or TPEG-TEC)
Some core data elements agreed (time & location stamp,…)

16. WP 1.3 Specification Next Steps
5RT
Example:
Intersection
5MT
5LT
LDM Content:
31LF
31RF
27RF
27RT
27MF
27LT
27LF
9LF
9LT
9MF
9MT
9RF
9RT
10s
10s 0s 0s
Objects’ Current State :
Moving vehicles’ state paramater: position, speed, accel., heading,…
Static road map geometry with attributes (lane direction, connectivity, type…)
Traffic lights’ phases (e.g. s to change)
Road/lane surface conditions
Weather & visibility condition
18RF
18MF
18LF
0LT
0RT

17. Summary of Main SP1 Achievements in 1st Year
3 Deliverables completed in due time:
D1.2.1 Vehicle probe use cases
D1.2.2 System analysis of useful in-vehicle data
D1.2.3 Requirements for the SAFEPROBE platform
Architecture designed jointly with other SPs
Client-server with brokers
Local Dynamic Map database, T/Q-APIs, query & notification,… (SP3)
Local Dynamic Map Contents proposed
Objects of static and dynamic layers
Trajectory prediction hypotheses
Situations/Events: timely & spatial relations betw. objects, trajectories,…
Open Java Micro Traffic Simulator developed & published to consortium