Transcript OSGi World Congress Presentation Template

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
Car Integrated Services
Open Standards

Products:
Car TelematicUnit
basic, advanced
Car Connectivity
VPN, Roaming, Resuming
Car Integrated Services
e.g. Remote Diagnosis
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
Partner
OSGI
Infrastructure
DB/ Apps Server
Car Diagnostic Component (Shareholder)
Carrier
Problems in Car Diagnostics – 1 –
Automotive Diagnostics Lifecycle :
• Research & Development
• Production
• Service
Diagnostics of Systems:
• Powertrain
• Body & Security
• Infotainment
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,…)
Problems in Car Diagnostics – 3 –

Standars still leave room for interpretation

OEM specific usage and extensions

Customer specific requirements
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
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
Diagnostic Tester Architecture – 3 –
Service-API
Service-Application
Service
Architectur
Config
Service-Interpreter
Communication-API
Communication
Embedded-Device
Embedded
Architektur
Dependencies
Protocol/Bus
Physical Access
ECU
OS/3rd party
protocol/bus
service
OSGi and Diagnostic Software – 1
Ideas

Components enclosed in (native) bundles

Dynamic loading, unloading and update
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”)
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
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
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
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
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
Questions?