1. The Complexity of Electronic Systems in Vehicles Meinrad Staudenmaier, Heiko Bauer CarMediaLab 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 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. 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 3 rd 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. 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. 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 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. 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. 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. Questions?