1 / 23

Technical Project Status of SP1 Christian Zott

Technical Project Status of SP1 Christian Zott Bosch (Schwieberdingen, Germany) christian.zott@de.bosch.com SP1 “In-Vehicle Platform and Sensing” leader. SAFEPROBE. Status of SP1. D1.2.1 Vehicle Probe Use Cases Finalised by CRF, MIRA Delivery to EC at Monday this week

otis
Download Presentation

Technical Project Status of SP1 Christian Zott

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Status of SP1 • D1.2.1 Vehicle Probe Use Cases • Finalised by CRF, MIRA • Delivery 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

  3. 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

  4. SafeSpot Scenario Attributes

  5. Ingredients of a SP1 Use Case

  6. Examples of SP1 Use Cases

  7. 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

  8. In-Vehicle Networks Topology, Example

  9. Allocation of Data to Event Types

  10. Radar Availability Tree

  11. Typical Radar Performance Figures

  12. Typical VDM Performance Figures

  13. Performance Risks

  14. ! System Requirements: System Timing

  15. System Requirements: Performance Total System Performance Specification (SP4/5 Application) • Condition(s) defining the first event occurrence ( t event occurs ) • Vehicle which driver shall be warned • Notification data at HMI output device • Maximum Time-to-Notification (TTN): t driver notified - t event occurs • Accuracy of notification data • Availability of notification data • Integrity of notification data • Conditions of operation (context)

  16. Example System Specification • Example: Event type II - Lane condition change: • “PTW falling on the road, warning to approaching vehicle”t event occurs: PTW tilt angle sensor > threshold • 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 • acoustical warning signal and voice output : “Dropped PTW in <distance value> meters on road ahead!”t driver notified: end of speech sentence • time-to-notification < 1 seconds if 100km/h < approaching vehicle speed < 200km/h < 3 seconds if 0km/h < approaching vehicle speed < 100km/h • Prob( |notified distance - true distance| > 5m ) < 5 % • Prob( all data available for approaching vehicle to compute distance according to 6. given conditions under 9.) > 95 % • 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%

  17. Example System Specification Driving scenario attributes, e.g. a) single lane per direction, rural roads only, curvature less than TBDb) all lighting and weather conditions c) approaching vehicle of all types d) approaching vehicle in normal map mode (TBD) at t event occursd) 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 networkb) TBD in-band, near-band and out-of-band interference levels (CW, pulsed)

  18. 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

  19. Requirements from SP3 - LDM SP3 Model of Local Dynamic Map = Database with APIs, OOD transactions on database alwaysensuring integrity:editing, queries,… configurable object types, extensible attributes,… T-API: transformation API Q-API: query API see D3.2.2 User Needs and Requirements_LDM_final.doc as of 26.09.2006

  20. T-API Fusion and Map-Matching tracking: prediction&update of and data association to established map entities (objects/tracks/attributes) Feature Generation and Object Classification recognition of objects types, … Segmentation regions-of-interest extraction, gating, … Preprocessingcalibration, coord. transf., time-sync., interpolat., noise filt. Data Reconstruction and Validation composition of data elements (e.g. from frames), screening sensing comm 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

  21. 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,… ?

  22. 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)

  23. 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)

More Related