1.
OSGi Technology in the Vehicle
Hans-Ulrich Michel, BMW Group Research and Technology, hans.michel@bmw.de
10.23.03

2.
Agenda
§ Starting point: Importance of Standardization
§ Open Infotainment Systems
§ How does BMW tackle standardization ?
§ In-vehicle OSGi-integration
§ BMW ConnectedDrive and Research Vehicle

3.
§ Optimize vehicle system architecture:
- ressource sharing: shared functionality in the network
- dynamic partitioning: flexible integration of functions in ECU´s
§ Increasing Configuration Management
§ Achieve reusability of hw / sw-components in different
product lines
§ Enable “easy” maintenance of components
§ Solve lifecycle mismatch between consumer
hardware / sofware and vehicle
§ Reduction of development time,
Software-Downlaod
Some Resulting Challenges…
Manage increase in system complexity, save costs –
handle the variety forced by the market in the most efficient way !
Standardization
- Open E/E-Architecture
- Open Infotaiment Platform

4.
The Open System Approach at the SEI
(Software Engineering Institute)
What is an Open System?
An open system is a collection of interacting software, hardware, and human
components
- designed to satisfy stated needs
- with interface specifications of its components that are fully defined available to
the public
- maintained according to group consensus
- in which the implementations of the components are conform to the interface
specifications

5.
Open Infotainment Platform:
Part of an End-to-End System Framework
“Entities”:
§ Customer (with his personal appliances)
§ In-vehicle infotainment platform
§ “Outside” network infrastructure (GSM, GPRS, DVB-T, Bluetooth,
WLAN,..)
§ Backend Server infrastructure (Service-Provider, Content-Provider etc.)
§ “Inside” network infrastructure (CAN, MOST,..) with ECU components
„Open“ on 2 different levels: - e2e-system level
- platform level

6.
“Open” on system and platform level
Some Characteristics of an open e2e-system:
§ Seamless availability of services on different platforms
§ Personalization of services
§ Use of heterogenous networks and backend infrastructure (seamless
roaming between service provider)
Some Characteristics of an open platform:
§ Dynamic extendable functionality on the infotainment platform
§ Reusable library of basic functionality – creation of new app´s
§ Open interface specification that enables different supplier implementations

7.
Standardization Effort
§ Standardize the interfaces between the different,
independent entities
§ Standardize on platform level
More visual

8.
Open Infotainment System: “Outside World”
Service Provider
(Navigation)
Service Provider
(Parkinfo)
Service Provider
(Billing)
Server Plattform (Repository der
OSGi-Objekte)
BUNDLE
Service
Device Driver
Package
Comm with
external services
(billing etc.)
SERVICE PROVIDER
Customer-
Admin
USER
Service Aggregator (CC)
http
(SOAP)
services
Internet
VPN/PPP
I2 I1
James

9.
Open Infotainment System: “Internal World”
Other Vehicle
Bus Systems
Infotainment
Bus
Infotainment
Platform
Convenience / Service Framework
Operating System, HAL, Protocoll stack
Hardware Computing Platform (CPU)
Vehicle Bus net External net
JVM , JNI
1
4
5
AbstractionLayerAbstractionLayer
(not OEM specific)(not OEM specific)
I3= I2 +...
1
2
3
4
5
Java App´s (components)
Standard API-Layer I3
Java / Native App´s
Base service Components
Framework Components
2
Phone app
client comp
Virtual Most
device server
comp
3
Native Code
phonelib
Acess native
code

10.
How does BMW tackle standardization ? – Examples
Information for the millions
Third Generation Telematics
Gobal Systems Telematics
OSGi Alliance
Media Oriented Systems Transport
Automotive Open System Architecture
Industry consortium
EU-Projects

11.
Differentiation attributes Manufacturer consensus for
interfaces that are not
customer relevant
Look at End-2-End
service chain
Marketing oriented
view
OSGi-PF integration in
vehicle system architecture
New application scenarious
by using OSGi middleware
Focal Points for requirements and prioritization of OSGi
standardization

12.
In-vehicle OSGi integration
Case 1: OSGi “Head-Unit”
Bus 1 Bus 2 Bus 4Bus 3
Roles:
-Bus Gateway, Remote Acess Gateway, Service PF with App business logic functionality,
Head Unit – Terminal with complete HMI functionality

13.
In-vehicle OSGi integration
Case 1: OSGi “Head-Unit”
Standard On-board supply system
Engine man., gearunit, windows
control, anti theft system, center
lock
Vehicle App´s +
Multimedia / Telematic
Audio, CD, Phone, …+
Infomanager, News,…
• Separation of stable on-board
supply system
• Merging of basic vehicle-app´s
with multimedia/telematic world
Advantage:
• One platform (costs)
• Possible reduction of number
of ECU´s
• One HMI „for all“ is slightly
easier to implement
Riscs:
• High effort in system integration
• Performance
• Startup / Shutdown behaviour
• Safety / security more difficult

14.
In-vehicle OSGi integration
Case 2: OSGi “Advanced ECU”
Bus 1 Bus 2 Bus 4Bus 3
Roles:
Remote Acess Gateway, Service PF with App business logic functionality

15.
In-vehicle OSGi integration
Case 2: OSGi “Advanced ECU”
Standard On-board supply system
Engine man., gearunit, windows
control, anti theft system, center lock
Vehicle App´s
• Separation of stable on-board
supply system
• Head unit for vehicle
application world
• Seperation of multimedia and
telematic world
Advantage:
• Clear seperation of stable
vehicle functionality from the
dynamic multimedia / telematic
applications
• Security easier to achieve
Riscs:
• Cost penalty
• HMI communication
• Another ECU....
Multimedia / Telematic

16.
Example New App-Scenario: ECU Software Download
PT-CAN
byteflight
K-CAN
Terminal
TSP
Profile.xml:
SW / ECU
config.
Headunit
ECU 1
ECU 2
ECU 3
Headunit
Profile.xml:
Key/Value
Softwarepacket
configdata,state
data ,..
Profile.xml
ECU 1
Profile.xml
ECU 2
-TSP von Server / Flashcard auf Terminal
-- Server hat Masterkopie von TSP
-- SW wird immer von Server zum Fahrzeug abgeglichen
(Server entscheidet)
ECU
loader
Terminal
Agent
Terminal service management
Terminal capabilities
synchroniztion
Control Center
TCAP sync
Liste Tapp´s
Sync Delta TSP
Flashcard

17.
BMW ConnectedDrive: Networks Driver, Vehicle and
Environment
An Innovative concept which interconnects information,
communication and assistance systems inside and
outside the vehicle, location based and destination
oriented.
- BMW Assist
- BMW Online
- Driver Assistance

18.
BMW Research Vehicle – The Future

19.
Main Goals
• Use OSGi-Platform and implement End-2-End
service chain with a software management
architecture that enables software download
(3GT-based)
• Show different car networking situation:
- car to backend server
- car to personal appliances, (PDA,mobile)
- car to car (Ad-Hoc networking)

20.
BMW Research Vehicle - Architecture
Navigation
iDrive
Controller
Optolyzer
(MOST)
IR-Camera
Ethernet
VGA DisplayParkticket
Display
BT AP
Bluetooth
Access
Point
GPRS
GPRS
CSD
Module
DECT
Phone
Power
Management
Unit
14.10.2003
14:30
Hanauerstr.
ctr. 23618
14.10.2003
14:30
Hanauerstr.
ctr. 23618
MOST
Ring
WLAN
WLAN
Module
CD
Player
I/O Unit
(Router)
Head Unit
(Terminal)
Audio
System
CAN

21.
BMW Research Vehicle – The Future

22.
Head UnitHead Unit
Hardware:
P III 700 MHz, 256 MB, 30 GB
Bluetooth USB
Hardware:
P III 700 MHz, 256 MB, 30 GB
Bluetooth USB
OS:
Windows 2000 or Linux
OS:
Windows 2000 or Linux
3GT Framework
3GT Framework
Java:
≥ JDK 1.3.1
Java:
≥ JDK 1.3.1
OSGi:
ProSyst mBServer 5.1
OSGi:
ProSyst mBServer 5.1
3GT Terminal
3GT Terminal
Remote
Management
Transport
Provisioning
Remote
Management
Transport
Provisioning
Distributed
Registry
Distributed
Registry
HMI
Framework
HMI
Framework
SyncML
SyncML
Authentication
Authorization
Accounting
Authentication
Authorization
Accounting ......
Personal Info
Manager
Personal Info
Manager
Navigation
Application
Navigation
Application
Parkinfo
Application
Parkinfo
Application ......
......
Remote Management Agent
Remote Management Agent
User Application Layer
Terminal Application &
Managed Service Layer
Preinstalled (Unmanaged)
Bundles
Initial Provisioning Layer, I2

23.
Head UnitHead Unit
Hardware:
P III 700 MHz, 256 MB, 30 GB
Bluetooth USB
Hardware:
P III 700 MHz, 256 MB, 30 GB
Bluetooth USB
OS:
Windows 2000 or Linux
OS:
Windows 2000 or Linux
3GT Framework
3GT Framework
Java:
≥ JDK 1.3.1
Java:
≥ JDK 1.3.1
OSGi:
ProSyst mBServer 5.1
OSGi:
ProSyst mBServer 5.1
3GT Terminal
3GT Terminal
Remote
Management
Transport
Provisioning
Remote
Management
Transport
Provisioning
Distributed
Registry
Distributed
Registry
HMI
Framewor
k
HMI
Framewor
k
Navigation
Base
Navigation
Base
SyncML
SyncML
Authentication
Authorization
Accounting
Authentication
Authorization
Accounting ......
Personal Info
Manager
Personal Info
Manager
Navigation
Application
Navigation
Application
Parkinfo
Application
Parkinfo
Application ......
......
Remote Management Agent
Remote Management Agent
User Application Layer
Terminal Application &
Managed Service Layer
Preinstalled (Unmanaged)
Bundles
Initial Provisioning Layer, I2IO UnitIO Unit
Hardware:
P III 700 MHz, 256 MB, 30 GB
Bluetooth USB
Hardware:
P III 700 MHz, 256 MB, 30 GB
Bluetooth USB
OS:
Windows 2000, IP routing configuration
OS:
Windows 2000, IP routing configuration
Java:
≥ JDK 1.3.1
Java:
≥ JDK 1.3.1
OSGi:
ProSyst mBServer 5.1
OSGi:
ProSyst mBServer 5.1
AdHoc
Communication
AdHoc
Communication
AdHocMessage
Repeater
AdHocMessage
Repeater
Map Server
Map Server
Navigation
Connector
Navigation
Connector

24.
BMW Research Vehicle – Applications
Infomanager
Adresses, calender, email,
tasks,..

25.
Backend
• user account
• stored travel data
PC PDAVehicle
Bluetooth
Internet
Internet
1. Plan a travel at Home 2. Travel by car
• Download travel data / route
• Onboard-route guidance
3. Walking to destination
• Use PDA with map / walking route
to go from parking lot destination
BMW Research Vehicle – Applications
Seamless Navigation

26.
BMW Research Vehicle – Applications
Seamless Navigation

27.
BMW Research Vehicle – Applications
Seamless Navigation

28.
BMW Research vehicle – Applications
Car-2-Car Communication

29.
BMW Research vehicle – Applications
Car-2-Car Communication

30.
Thank you for paying attention

31.
We are
open for discussions for
open communication platforms and
open standards.

32.
Questions?

33.
Backup

34.
OS
AUTOSAR-RTE
function n-1 function n
Basic system functions
core functions, drivers
Hardware
HAL
get_v() v_warn() ...
OS
AUTOSAR-RTE
function n-1 function n
Basic system functions
core functions, drivers
Hardware
HAL
function 1 function 2 ...
AUTOSAR Architecture

35.
OSGi Integration Platform and Autosar -
What is possible…
OSGi Framework
MHP
Xlet
Xlet
Xlet
Xlet
WAP
Jini
UPnP
Communication
Autosar
Osalet
Osalet
Osalet
Osalet
Osalet

36.
Main Goals Functional Domains
Engine
Chassis
Safety
(active/
passive)
Functional
Domains
Multi-
media/
Telematics
Man
Machine
Interface
Body/
Comfort
Vehicle
´centric‘
Passenger
´centric‘
Automotive Open System Architecture (AUTOSAR)
Ø Specification of interfaces
Ø Standardized, openly disclosed interfaces
Ø HW-independent SW-layer
Ø Transferability of functions
Ø Redundancy activation
AUTOSAR RTE:
by specifying interfaces and their communiation
mechanisms, the application are decoupled from
the underlaying hardware and basic software,
enabling the realization of standard library functions