1 / 12

AMETIST Case Study 3: Real-time Service Allocation for Car Periphery Supervision

AMETIST Review Meeting June 19, 2003, Brussels. AMETIST Case Study 3: Real-time Service Allocation for Car Periphery Supervision. Stefan Kowalewski Robert Bosch GmbH Corporate Research and Development Frankfurt, Germany stefan.kowalewski@de.bosch.com. Outline.

ewan
Download Presentation

AMETIST Case Study 3: Real-time Service Allocation for Car Periphery Supervision

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. AMETIST Review MeetingJune 19, 2003, Brussels AMETIST Case Study 3:Real-time Service Allocationfor Car Periphery Supervision Stefan Kowalewski Robert Bosch GmbH Corporate Research and Development Frankfurt, Germany stefan.kowalewski@de.bosch.com

  2. Outline • Short Range Radar: Automotive Applications and Challenges • CPS Platform • Analysis Model as Problem Description FV/SLD-Kowalewski, September 2002

  3. Short Range Radar: Automotive Applications • Parking Assistance ( Automatic Parking) • ACC ( ACC Stop & Go) • Pre-Crash-Detection ( Collision Mitigation) • Dead Angle Supervision( Lane Change Assistant) FV/SLD-Kowalewski, September 2002

  4. Challenges • Traditional development: Each application has dedicated sensors, actuators, ECU, Software and HMI. • No longer possible due to number of applications, cost, space. • Platform development needed: • Integration of applications (services) • Sharing of distributed resources (sensors, ECU, data) • Different variants • Real-time requirements for single applications must be met by integrated system • Model-based analysis necessary FV/SLD-Kowalewski, September 2002

  5. CPS platform • Applications: Pre-Crash and Parking Assistance • One ECU per Sensor and one central ECU per cluster • Two sensor modes: • D (distance) mode: 1 - 7 m (D1), 1 - 2 m (D2) • Cv (closing velocity): 0.69 - 1.41 m • D2 is for recovery from precrash situation • Hard response time requirements, in particular lead time for precrash indication • Different HW and OS platforms: OSEK / dedicated scheduler FV/SLD-Kowalewski, September 2002

  6. Problem description (deliverable 3.1.3) • Abstracted but realistic specification • Restriction to one sensor group (front cluster) • Analysis model of basic components and their reponsibilities: • Abstract components/connectors view • Scheduling not considered • Few problem formulations • Basis for further refinement FV/SLD-Kowalewski, September 2002

  7. Analysis model: Context FV/SLD-Kowalewski, September 2002

  8. Analysis model: CPS system FV/SLD-Kowalewski, September 2002

  9. Analysis model: Sensor FV/SLD-Kowalewski, September 2002

  10. Analysis model: ECU FV/SLD-Kowalewski, September 2002

  11. Open problems • Current situation: • No complete prototype existing; only parts can be tested. • Timing still based on estimations and assumptions. • Any results on the relation between environment properties and timing requirements are welcome. • Examples: • Implications for object numbers/velocities/distances from the lead time requirements for Pre-Set and Pre-Fire? • How robust is the 15 ms frequency (in case of delays, or additional components)? • Optimal assignment to OSEK tasks? FV/SLD-Kowalewski, September 2002

  12. Future of SRR development at Bosch unclear • Business unit decided to put SRR component development on hold. • Possible decisions in future: • Buy SRR components and sell systems • Replace SRR (24 GHZ) by LRR (77 GHz) • Start SRR component development again • Consequence: platform development currently in waiting loop FV/SLD-Kowalewski, September 2002

More Related