The Complexity of Electronic Systems in VehiclesMeinrad Staudenmaier, Heiko BauerCarMediaLab

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 TelematicUnitbasic, advanced

Car ConnectivityVPN, Roaming,

Resuming

Car Integrated Services

e.g. Remote Diagnosis

publicZONE – Infrastruktur

WTLS

GPRS

Advanced CTU

WLAN

Carrier

iPAQ + DiagRA

Tablet PC

ParisOracleWorld @ HP Booth HP Democenter

HP Roaming Server

Oracle 9iAS wirless

Oracle CRM

WTLS

Oracle CollabSuite

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 –

ECU

Protocol/Bus

Embedded-Device

EmbeddedArchitektur

protocol/busservice

OS/3rd party

CommunicationCommunication-API

Service-API

Service-Application

ServiceArchitectur Config

Service-Interpreter

Physical Access

Dependencies

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?