SAFEPROBE Project Status of SP1 Christian Zott ! Project Status of SP1 Christian Zott Bosch (Schwieberdingen, Germany) christian.zott@de.bosch.com SP1 “In-Vehicle Platform and Sensing” leader

SP1 Schedule and Milestones Activity D1.2.1, 1.2.2, 1.2.3 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

SP1: Partners’ Effort and Involvement MM

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

Examples of SP1 Scenarios

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

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

Qualitative Performance Assessment Radar just taken as an example here

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 (SP1-2-3-4-5) Accident data Analysis +SoA Analysis SP4-SP5 Technology analysis SP1-SP2-SP3 User\Actors Identification SP1-2-3-4-5 Use Cases (SP1-2-3-4-5) 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

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

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

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

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)

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

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,…)

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

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