The Complexity of Electronic Systems in VehiclesMeinrad Staudenmaier, Heiko BauerCarMediaLab10.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 Servicese.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 bundlepro: Small footprintcon: Long roundtrip delay

! Full Diagnosticscon: Large footprint, inflexible

! Multi Bundlepro: Footprint as needed, flexiblecon: 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?