OSGi World Congress 2003

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