Technical Project Status of SP1 Christian Zott

1SP1 meeting2006-09-28, Birmingham, MIRA

Technical Project Status of SP1Technical Project Status of SP1

Christian Zott

Bosch (Schwieberdingen, Germany) [email protected]

SP1 “In-Vehicle Platform and Sensing” leader

SAFEPROBESAFEPROBESAFEPROBESAFEPROBE


Status of SP1

• D1.2.1 Vehicle Probe Use Cases

Finalised by CRF, MIRADelivery to EC at Monday this week

• D1.2.2 System Analysis of Useful In-vehicle Data

Currently under peer review

• Compilation of Requirements ongoing

• Commencement of Specification Phase now


Status of SP1

D1.2.1 Vehicle Probe Use Cases:

• Use cases and scenarios, bottom-up, examples

• Scenario attributes

• Event types: - manoeuvres- road conditions- area conditions

• Event handling:- Rx, Tx, repeater


SafeSpot Scenario Attributes


Ingredients of a SP1 Use Case

SP1 Use Casespecification

normal driving info event info event handling

AND

Continuous egovehicle state

AND

ORRepeater:

ego forwardsevent info

AND

AND

III:area conditions (change)

not road/lane specific

II:road/lane conditionsor attributes (change)

I:traffic participants

states and/or manouvresassigned to road/lane

OR

Local (moving)road map

Rx:ego receives

event infoby ad-hoc com

Tx:ego broadcasts

event infoby ad-hoc com

Detector:ego detects

event

Use case unspecific(mandatory)

Defining a specificuse case

Ego LDMupdate


Examples of SP1 Use Cases


Status of SP1

D1.2.2 System Analysis of In-vehicle Data:

• Collection of data in cluster ENP, NAV, VDM, BOD, OSS, SVD

• Allocation of data (cluster) to event types and use cases

• Application performance definition and proposal:

- time-to-notification (TTN), accuracy / integrity of notification- availability trees- typical performance figures – tables- performance risks for use cases


In-Vehicle Networks Topology, Example


Allocation of Data to Event Types

II:road/lane conditions

or attributes (change)

OR

In-vehicleenvironmental

perception data (ENP)

in-vehicle fused data

vehicledynamics

data (VDM)

vehiclebody

data (BOD)

vehicle only data

road-side fused data

V2

I I2VV

2I/I2V

RS

U_

intern

Ve

h_intern

I2V

I2V

road-side only data

SP1 systems SP2 systems

V2

V

I2I

road-sidevehicle sensing

(VEH)

III:area conditions (change)

not road/lane specific

I:traffic participants

states and/or manouvresassigned to road/lane

road-sidetraffic status sensing

(TRAF)

road-sideenvironmental condtions

(ENV)

road-sideobject detections

(OBJ)

Infrastructure (map)features(INFRA)

In-vehiclenavigationdata (NAV)

Staticvehicle data

(SVD)

Occupant safetysystems data

(OSS)


Radar Availability Tree

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)


Typical Radar Performance Figures

Parameter Long-Range Radar Short-Range Radar Unit

Maximum range 120…150 50 m

Minimum range 4 2 m

Range accuracy σR 0.1 0.1 m

Range resolution 1 0.3 m

Range rate accuracy σRR 0.5 n.a. km/h

Horizontal Field of View 8 ( 5.5) 35 (deg)

Vertical Field of View 4 8 (deg)

Horizontal beamwidth 3 70 (deg)

Vertical beamwidth 4 15 (deg)

Number of Objects (max) 20 8 … 64 Nr

Update rate 100 (40) 35 ms


Typical VDM Performance Figures

Parameter Value Update Rate

Vehicle speed 0…512 km/h 50 / 100 ms

Vehicle speed accuracy 0.3%

Vehicle speed resolution 0.0625 km/h

Wheel speed (each wheel) 0…512 km/h 10 ms

Wheel speed accuracy 2%

Wheel speed resolution 0.0625 km/h

Yaw rate filtered (CRF / Volvo)

-128…127.938 /s-3.9 rad/s…3.9rad/s

10 / 20 ms

Yaw rate accuracy 0.25 /s

Yaw rate resolution(CRF / Volvo)

0.0625 /s0.00012207 rad/s

Master cylinder pressure 0…200 bar 7 ms

Master cylinder pressure accuracy 5 bar

Master cylinder pressure resolution 0.25 bar

Lateral acceleration -40.96…40.92 m/s2

-15…15 m/s2

10 / 20 ms

Lateral acceleration accuracy 0.02 m/s2

Lateral acceleration resolution (CRF / Volvo)

0.02 m/s2

0.00048828 m/s2


Performance Risks

Performance risk

Use Case Descriptionclutter, flooding

dynamical modelling of object movement

dense objects / object resolution

veh occlusions

occlusions by road-side

adverse environ-mentalconditions

Ego vehicle detects wrong way driver x

Ego vehicle detects traffic jam x x x x

Ego Vehicle runs a red light on collision path x x

Ego-vehicle detects a fire / smoke section x x

Approaching a fire-smoke section: Ego-vehicle broadcasts the information x x

Approaching a fire / smoke section inside a tunnel: Ego-vehicle broadcasts the information x x x

Road departure on straight road for high speed x

Presence of sharp curve: ego vehicle detects the presence of a sharp curve x

Ego vehicle carrying dangerous goods approaches other vehicle. x

…


System Requirements: System Timing

!


System Requirements: Performance

1. Condition(s) defining the first event occurrence ( t event occurs )

2. Vehicle which driver shall be warned

3. Notification data at HMI output device

4. Maximum Time-to-Notification (TTN): t driver notified - t event occurs

5. Accuracy of notification data

6. Availability of notification data

7. Integrity of notification data

8. Conditions of operation (context)

Total System Performance Specification (SP4/5 Application)


Example System Specification

Example: Event type II - Lane condition change:

1. “PTW falling on the road, warning to approaching vehicle”t event occurs: PTW tilt angle sensor > threshold

2. any equipped vehicle at t event occurs in communication range (single hop) of PTW approaching PTW and able to collide (there is a possible route to PTW location) but not closer than 100m

3. acoustical warning signal and voice output : “Dropped PTW in <distance value> meters on road ahead!”t driver notified: end of speech sentence

4. time-to-notification < 1 seconds if 100km/h < approaching vehicle speed < 200km/h < 3 seconds if 0km/h < approaching vehicle speed < 100km/h

5. Prob( |notified distance - true distance| > 5m ) < 5 %

6. Prob( all data available for approaching vehicle to compute distance according to 6. given conditions under 9.) > 95 %

7. a) Abnormal error condition (AEC) := |notified distance - true distance| > 30m Prob(AEC AND no annunciation about AEC) < 0.01 % b) False Alarm: Prob( dropped PTW notification given no event) < 0.01%c) Missed Event Recognition: Prob( no notification acc. to 5 given 1. and 2.) < 1%


Example System Specification

Driving scenario attributes, e.g.

a) single lane per direction, rural roads only, curvature less than TBD

b) all lighting and weather conditions

c) approaching vehicle of all types

d) approaching vehicle in normal map mode (TBD) at t event occurs d) clear line-of-sight between PTW and approaching vehicle (no occlusion / masking)

Interference conditions, e.g.

a) less than 20 nodes in local ad-hoc network

b) TBD in-band, near-band and out-of-band interference levels (CW, pulsed)


Next Steps

• Requirements for in-vehicle platform

- Currently requirements from - SP3, LDM, positioning, ad-hoc communication - SP7

- 1st Requirements Harmonization end of October (led by SP7)

- HW availability: vehicles and equipment

• Commencement of WP1.3 Specification


Requirements from SP3 - LDM

WORLDMODELWORLD

MODEL

WORLD

LDMdynamic layer

Datatransformation

sensing comm/S

Datainterpretation

data server

T-A

PI

Q-A

PI

Application

requests

data

comm/R

dataanswers

SP3 Model of Local Dynamic Map = Database with APIs, OOD

T-API: transformation API

Q-API: query API

see D3.2.2 User Needs and Requirements_LDM_final.doc as of 26.09.2006

transactions on database alwaysensuring integrity:editing, queries,…

configurable object types, extensible attributes,…


Requirements from SP3 - LDM

Functional Levels of Data Transformation

• not all levels mandatory

• no prescription for order of sequence,e.g. maybe object classification after fusion or map-matching before segmentation, etc.

• allocation to sensor and comm subsystems open, e.g. IBEO laserscanner:pre-data-fusion with static map data already in sensor deviceor reconstruction already by comm

Data Reconstruction and Validationcomposition of data elements (e.g. from frames), screening

Preprocessingcalibration, coord. transf., time-sync., interpolat., noise filt.

Segmentationregions-of-interest extraction, gating, …

Feature Generation and Object Classificationrecognition of objects types, …

Fusion and Map-Matchingtracking: prediction&update of and data association to established map entities (objects/tracks/attributes)

sensing comm

T-API


Next Steps

WP1.3 Specification, 2 Objectives:

• General platform specification

- Function, interfaces, data models, performance → interoperability, standardisation

- UML, XML, (SDL?)- Top-level UML diagrams until end of November- Data Modelling: with SP2 (small WG at 25.10.?) and CVIS,

ISO 22837 Vehicle probe data (draft)

• Reference / demonstrator system

- constraints, test scenarios, test beds,…- use of CVIS components (CALM, OSGi,…)- security: how close to deployed, attack-safe,… ?


Proposed Next Steps for Specification

• Detailed scenario definition: speed/acceleration, distances before collision,...

• Design of cooperative concepts:

- Sensor-level to central-level fusion- Processing steps: acitivity diagrams, data flow

• Simulation of scenarios with few vehicles / RSUs / buildings and fov-masking for sens & com → length of time intervals of detection (sensing & comm)

• Detailed performance estimation & req'ts for signal processing:

- timing: time-to-detect / classify / fuse / decode- accuracy: e.g. necessary req’ts for collision prediction- doable scenarios (for given HW: vehicles, equipment)


Proposed Next Steps

Use Detection Scenario Java Tool for detailed analysis

• see Alison’s presentation • find executable, doc and sources at SSCA

SP1 - SAFEPROBE / Working Area / WP3 / detection scenario simulation

Platform data dictionary

• together with SP2 and CVIS • use UML - Enterprise Architect

• syntax, list of data titles (ICD list), see ISO, ASN.1 (?)• semantics of data by

- structure: E-R-Diagrams, UML, aggregation & inheritance- behaviour: intended usage (algo), purpose (see fusion

concepts, scenarios, simulations)

Technical Project Status of SP1 Christian Zott

Documents

Transcript of Technical Project Status of SP1 Christian Zott