1 / 19

The Complexity of Electronic Systems in Vehicles

The Complexity of Electronic Systems in Vehicles . Meinrad Staudenmaier, Heiko Bauer CarMediaLab 10.22.03. Overview. CarMediaLab Car Telematic Unit and Backend System Problems in Car Diagnostics OSGi and Diagnostic Software Conclusion. CarMedialab. Focus: End-to-End-Architecture

aizza
Download Presentation

The Complexity of Electronic Systems in Vehicles

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. The Complexity of Electronic Systems in Vehicles Meinrad Staudenmaier, Heiko BauerCarMediaLab 10.22.03

  2. Overview • CarMediaLab • Car Telematic Unit and Backend System • Problems in Car Diagnostics • OSGi and Diagnostic Software • Conclusion

  3. CarMedialab • Focus: End-to-End-Architecture Car Integrated Services Open Standards • Products: Car TelematicUnit basic, advanced Car Connectivity VPN, Roaming, Resuming Car Integrated Services e.g. Remote Diagnosis

  4. publicZONE – Infrastruktur Paris OracleWorld @ HP Booth Carrier HP Democenter WTLS Advanced CTU HP Roaming Server Oracle 9iAS wirless WTLS Oracle CRM Oracle CollabSuite iPAQ + DiagRA GPRS WLAN Tablet PC

  5. Partner OSGI Infrastructure DB/ Apps Server Car Diagnostic Component (Shareholder) Carrier

  6. Problems in Car Diagnostics – 1 – • Automotive Diagnostics Lifecycle : • Research & Development • Production • Service • Diagnostics of Systems: • Powertrain • Body & Security • Infotainment

  7. Problems in Car Diagnostics – 2 – Increasing number of… • ECUs (up to 80/Vehicle) • functions across ECUs (e.g. ESP) • official and OEM specific standards (buses, protocols, data formats,…)

  8. Problems in Car Diagnostics – 3 – • Standars still leave room for interpretation • OEM specific usage and extensions • Customer specific requirements

  9. Diagnostic Tester Architecture – 1 – Previous Architecture • Based on single set, highly specific requirements • Served as basis for various extension • Adaptability and extensibility wasn’t a design goal

  10. Diagnostic Tester Architecture – 2 – New Architecture Design Goals • Portability between architectures, operating systems and 3rd party interfaces • Clear separation of functionality into loosely coupled components: • User – customer specific (graphical, scripting) • diagnostic services – core + extensions, several possible • device access – protocol/bus/OS specific (“embedded”) • communication – local/remote between components

  11. Service-API Service-Application Config Service Architectur Service-Interpreter Embedded-Device Embedded Architektur OS/3rd party Protocol/Bus protocol/bus service ECU Diagnostic Tester Architecture – 3 – Communication-API Communication Dependencies Physical Access

  12. OSGi and Diagnostic Software – 1 Ideas • Components enclosed in (native) bundles • Dynamic loading, unloading and update

  13. OSGi and Diagnostic Software – 2 Scenarios • Entities: Service requester, backend, embedded device • Only embedded device as bundle in OSGi,Service application & GUI remote • Embedded device bundle and full service application bundles in OSGi (“full diagnostics”) • Embedded device bundle, service application bundles loaded on demand (“multi bundle”)

  14. OSGi and Diagnostic Software – 3 Pros&Cons • Embedded device only bundlepro: Small footprintcon: Long roundtrip delay • Full Diagnosticscon: Large footprint, inflexible • Multi Bundlepro: Footprint as needed, flexiblecon: Higher communication overhead, rules needed

  15. OSGi and Diagnostic Software – 4 Problems & Issues • Programming language boundaries Java<->C++ • Are device access bundles delivered with OSGi powerful enough • Impact on existing sourcecode

  16. OSGi and Diagnostic Software – 5 Decisions to be made • What type of services – if any – are being offered to other bundles • What type of communication will be used between service applications bundle and embedded bundle • Which – if any – other OSGi services will be used

  17. OSGi and Diagnostic Software – 6 Decisions made • Diagnostic bundles won’t offer services to other bundles • “Native” communication will be used between service application bundle and embedded bundle • So far no other OSGi services will be used except that • OSGi is considered as “infrastructure” for deployment and application management

  18. Components facilitate integration into OSGi, but there still remains a lot of work to do Basic CTU HP OpenView integration on Advanced CTU Tighter integration Diagnostics/OSGi by offering more services Conclusion & Plans

  19. Questions?

More Related