Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The Complexity of Electronic Systems in Vehicles - M Staudenmaier

541 views

Published on

OSGi World Congress 2003

Published in: Technology
  • Be the first to comment

  • Be the first to like this

The Complexity of Electronic Systems in Vehicles - M Staudenmaier

  1. 1. The Complexity of Electronic Systems in Vehicles Meinrad Staudenmaier, Heiko Bauer CarMediaLab 10.22.03
  2. 2. Overview ! CarMediaLab ! Car Telematic Unit and Backend System ! Problems in Car Diagnostics ! OSGi and Diagnostic Software ! Conclusion
  3. 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. 4. publicZONE – Infrastruktur WTLS GPRS Advanced CTU WLAN Carrier iPAQ + DiagRA Tablet PC Paris OracleWorld @ HP Booth HP Democenter HP Roaming Server Oracle 9iAS wirless Oracle CRM WTLS Oracle CollabSuite
  5. 5. Partner OSGI Infrastructure DB/ Apps Server Car Diagnostic Component (Shareholder) Carrier
  6. 6. Problems in Car Diagnostics – 1 – Automotive Diagnostics Lifecycle : • Research & Development • Production • Service Diagnostics of Systems: • Powertrain • Body & Security • Infotainment
  7. 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. 8. Problems in Car Diagnostics – 3 – ! Standars still leave room for interpretation ! OEM specific usage and extensions ! Customer specific requirements
  9. 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. 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. 11. Diagnostic Tester Architecture – 3 – ECU Protocol/Bus Embedded-Device Embedded Architektur protocol/bus service OS/3rd party Communication Communication-API Service-API Service-Application Service Architectur Config Service-Interpreter Physical Access Dependencies
  12. 12. OSGi and Diagnostic Software – 1 Ideas ! Components enclosed in (native) bundles ! Dynamic loading, unloading and update
  13. 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. 14. OSGi and Diagnostic Software – 3 Pros&Cons ! Embedded device only bundle pro: Small footprint con: Long roundtrip delay ! Full Diagnostics con: Large footprint, inflexible ! Multi Bundle pro: Footprint as needed, flexible con: Higher communication overhead, rules needed
  15. 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. 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. 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. 18. Conclusion & Plans ! 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
  19. 19. Questions?

×