technical project status of sp1 christian zott
Post on 05-Jan-2016
30 Views
Preview:
DESCRIPTION
TRANSCRIPT
1SP1 meeting2006-09-28, Birmingham, MIRA
Technical Project Status of SP1Technical Project Status of SP1
Christian Zott
Bosch (Schwieberdingen, Germany) christian.zott@de.bosch.com
SP1 “In-Vehicle Platform and Sensing” leader
SAFEPROBESAFEPROBESAFEPROBESAFEPROBE
2SP1 meeting2006-09-28, Birmingham, MIRA
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
3SP1 meeting2006-09-28, Birmingham, MIRA
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
4SP1 meeting2006-09-28, Birmingham, MIRA
SafeSpot Scenario Attributes
5SP1 meeting2006-09-28, Birmingham, MIRA
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
6SP1 meeting2006-09-28, Birmingham, MIRA
Examples of SP1 Use Cases
7SP1 meeting2006-09-28, Birmingham, MIRA
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
8SP1 meeting2006-09-28, Birmingham, MIRA
In-Vehicle Networks Topology, Example
9SP1 meeting2006-09-28, Birmingham, MIRA
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)
10SP1 meeting2006-09-28, Birmingham, MIRA
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)
11SP1 meeting2006-09-28, Birmingham, MIRA
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
12SP1 meeting2006-09-28, Birmingham, MIRA
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
13SP1 meeting2006-09-28, Birmingham, MIRA
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
…
14SP1 meeting2006-09-28, Birmingham, MIRA
System Requirements: System Timing
!
15SP1 meeting2006-09-28, Birmingham, MIRA
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)
16SP1 meeting2006-09-28, Birmingham, MIRA
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%
17SP1 meeting2006-09-28, Birmingham, MIRA
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)
18SP1 meeting2006-09-28, Birmingham, MIRA
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
19SP1 meeting2006-09-28, Birmingham, MIRA
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,…
20SP1 meeting2006-09-28, Birmingham, MIRA
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
21SP1 meeting2006-09-28, Birmingham, MIRA
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,… ?
22SP1 meeting2006-09-28, Birmingham, MIRA
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)
23SP1 meeting2006-09-28, Birmingham, MIRA
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)
top related