general assembly 2007-01-30, orbassano (crf) 1 ! safeprobe safeprobe project status of sp1 christian...

1General Assembly2007-01-30, Orbassano (CRF)

!

SAFEPROBESAFEPROBEProject Status of SP1Project Status of SP1

Christian Zott

Bosch (Schwieberdingen, Germany) [email protected]

SP1 “In-Vehicle Platform and Sensing” leader


Vorgangsname

WP 1.1 Technical Management

Kick Off

M 1.1.1 SAFEPROBE MTR

M 1.1.2 SAFEPROBE Final Review

WP 1.2 Requirements

T 1.2.1 Vehicle Probe Use Cases

T 1.2.2 System Analysis

T 1.2.3 Requirements

WP 1.3 Specification

T 1.3.1 Internal Data Fusion Spec

T 1.3.2 Environment Data Acquisition Spec

T1.3.2 Cooperative Data Fusion

T 1.3.4 Data Refinement Spec

T 1.3.5 HW Platform Spec

T 1.3.6 SW Platform

WP 1.4 Implementation

T 1.4.1 In-Vehicle HW Platform Dev

T 1.4.2 Data Fusion Algo Dev & Impl

T 1.4.3 In-Vehicle SW Platform Dev

T 1.4.4 Data Communication Impl

T 1.4.5 Cooperative On-board Sensors

T 1.4.6 Development of Probe Vehicles

WP 1.5 Test and Validation

T 1.5.1 Validation Plan

T 1.5.2 In lab Test

T 1.5.3 In-Vehicle Platform Validation

T 1.5.4 Performance Analysis

01.02.

31.07.

30.01.

01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 042006 2007 2008 2009

SP1 Schedule and Milestones

23.4. DF spec to peer review (CRF)

24.8. public HW/SW spec to peer rev. (CRF)

24.8. public DF spec to peer review (CRF)

24.7. HW/SW spec to peer review (Bosch)

Activity

4 regular SP1 meetings in 2006: Berlin, Turin, Birmingham, Turin + ~ participation at 6 other SPs + KO + CG

D1.2.1, 1.2.2, 1.2.3 completed


SP1: Partners’ Effort and Involvement

0

10

20

30

40

50

60

70

80

CR

F

RE

GIE

NO

VO

LV

O

PIA

GG

IO

MM

SE

BO

SC

H

SV

DO

IBE

O

ICC

S

MIR

A

WP 1.1 WP 1.2 WP 1.3 WP 1.4 WP 1.5

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

Received signalpower > threshold:

reflector infield-of-view / beam

Radar Tracksavailable with

sufficientperformance

Strong dependenceon driving scenario /

event

Enough detections /limited misseddetection rate

Limited falsedetection rate

Appropriate noiseenvironment/

limited interference

Sufficient reflectorresolution in range,azimuth, elevation

Observation to trackassociation with

sufficientperformance

Sufficient transmitsignal power

Sufficient scan rate,e.g. pulse repitition

rate

AND

AND

AND

Strong dependenceon technology

Strong dependenceon environmental

conditions

No occlusion byother vehicles/

obstacles

No occlusion bybuildings and other

road-sideconstructions

Appropriate aspectangle given a

specular reflection

Sufficient reflectorradar-cross-section

Sufficient rx/txantenna gain

for reflector range,azimuth, elevation

Limited clutter /unwanted detections

(e.g. pavement,guardrails,…)

Appropriatedynamical models forreflector movement

(track prediction)

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

ScenariosUser NeedsUse Cases

Common Basic Scenarios SP4-SP5

User (of the Subsystem) Needs

(SP1-2-3-4-5)

Accident data Analysis +SoA Analysis SP4-SP5Accident data Analysis

+SoA Analysis SP4-SP5

Technology analysis SP1-SP2-SP3Technology analysis

SP1-SP2-SP3

User\ActorsIdentificationSP1-2-3-4-5

User\ActorsIdentificationSP1-2-3-4-5

Use Cases (SP1-2-3-4-5)

High Level User NeedsGuidelines

(SP7)Guidelines(SP7)

High Level StakeholdersIdentification

(SP7)

High Level StakeholdersIdentification

(SP7)

Tech Scenarios SP1-SP2-SP3

(SP1-5)

System Requirements SP3





High Level Description


WP1.3 Specification Results

Current Architecture Clients:• SP4/5 applications • SafeSpot message generation• Visualization of current LDM contents

VANET: Vehicular Ad-hoc NetworkLDM: Local Dynamic MapQ-API: Query APIT-API: Transaction APISP4/5

cmp Component Model

Certified Client #1,2,...,M

Applicatioin #N Broker

Application #N (SP4/5)

Certified Client #N+1Broker management

Sensor #N (Radar/Laserscanner) VANET

communication

Data Fusion with Database Surv eillance

#1 #N commap #N+1 #N+x

Transaction Query

Transaction Call Generation

Ego Postioning (v ehicle only)

Object refinement Situation refinement

LDM Database (SP1/2) Serv er

Not Certified Clients #M+1,..., N

Application #1 (SP4/5)

Message Generation & Management

VANET communication

SP3: LDM Margin Generation (v ehicle

only)

Message Broker

Broker

Static Map

Sensor #1 (GPS)

HMI Management (SMA)Application #1 Broker

Nav igation Data

Traffic Control States (infrastructure only)

HMI subsystem (v ehicle only)

Message Stack

Q-API

Q-API

Q-API

T-API

Q-API

LDM data

appl #1dataselection

SP3

Brokers:• cast requests

into queries and subscriptions to notifications

• select/filter data• translate messages,

notifications• remote procedure

calls over platform network

SP1-5,7


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

cmp Component Model

Certified Client #1,2,...,M

Applicatioin #N Broker

Application #N (SP4/5)

Certified Client #N+1Broker management

Sensor #N (Radar/Laserscanner) VANET

communication

Data Fusion with Database Surv eillance

#1 #N commap #N+1 #N+x

Transaction Query

Transaction Call Generation

Ego Postioning (v ehicle only)

Object refinement Situation refinement

LDM Database (SP1/2) Serv er

Not Certified Clients #M+1,..., N

Application #1 (SP4/5)

Message Generation & Management

VANET communication

SP3: LDM Margin Generation (v ehicle

only)

Message Broker

Broker

Static Map

Sensor #1 (GPS)

HMI Management (SMA)Application #1 Broker

Nav igation Data

Traffic Control States (infrastructure only)

HMI subsystem (v ehicle only)

Message Stack

Q-API

Q-API

Q-API

T-API

Q-API

LDM data

appl #1dataselection

SP3SP1/2 SP1-5,7



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)



• 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



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



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

10s

0s

10s

0s

9RF9MF

9LF

27RT27LT

18

LF

18

MF

18

RF

0L

T 0R

T

9RT9MT

9LT

27RF

27LF27MF

5RT5M

T5LT 31LF

31RFLDM Content:Example:Intersection


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

general assembly 2007-01-30, orbassano (crf) 1 ! safeprobe safeprobe project status of sp1 christian...

Documents