Vehicle Workshop 11 January 2007

The OSGi Alliance organized an automotive workshop in Troy, Michigan USA, January 11. The reason for this workshop is the increasing interest in the automotive industry for the OSGi specifications: BMW, 3GT, GST, VII, and others. We organized this workshop with key people from the OSGi Alliance as well as from various OEMs, tier-1 suppliers and telematics service providers. The goal of the meeting was to closely align the standardization activities of the OSGi Vehicle Expert Group with the demands of the automotive industry.

Program

Organizer: Kai Hackbarth, ProSyst
Moderator: Peter Kriens, Technical Director & Evangelist, OSGi Alliance

08.30	Arrival and coffee
09.00	Welcome
09.15	Introduction OSGi Vehicle Expert Group
09.45	Participants Presentations Workshop participants can give a brief presentation (5 min) on desired areas of work
10.30	Open Discussion brainstorming on topics that VEG should work on Look for common interest of areas
12.00	Prioritizing ideas
12.30	Lunch
13.30	Continued open discussion based on priority
15.30	OSGi organization, technical process, IPR overview, next steps
16.30	Adjourn

Short summary

The workshop was held in a very positive and energetic atmosphere. After everybody was present, Peter Kriens opened the meeting. After short introductions, he presented the OSGi Alliance and the Vehicle Expert group. The next phase were the presentations from the particpants.

Robert Prince (Vetronix) had a presentation about Diagnostics in the car. Vetronix (a Bosch company) has developed on-board and off-board as well as remote diagnostics tool based on OSGi. Vetronix likes to standardize diagnostics APIs for the vehicle so their tools will work with more vehicles.

Kelvin Nilson (AONIX) presented a model whereby Java applications could run inside a real time VM. The way the Java code had to be written could had some specific requirements but the code could run unmodified on standard VMs. There are tools to verify that the code was written and annotated correctly. VMs in this class enable more applications to be written in Java. The OSGi service platform could be extended to support this type of VMs.

Rob van den Berg (Siemens VDO) presented some of the key issues that Siemens considers as very important for the future. Legacy integration of non-java code is crucial to move OSGi further in the domain of the vehicles. He also showed how the OSGi navigation model, which is work in progress, is a crucial component for many future services.

Gary Streelman (Delphi) gave an extensive presentation of the VII project. This is a massive project to minimize the number traffic related deaths and reduce congestion. The idea is to use communication technology to let vehicles communicate among themselves as well as with roadside units. This allows information to be spread to nearby vehicles (car is braking, stoplight is red), or to have the information be aggregated by Traffic Management Centers (TMC). The project is currently in the phase of creating a proof of concept. The OSGi specifications play a major role in this proof of concept.

After the presentations we started to work on the list of areas where OSGi should focus on for the Vehicle industry. This resulted in the following unordered areas:

Safety

Provide APIs to allow applications to exchange safety information with other units.

Use case: When a car in front you brakes, the braking vehicle could send out a message to other cars so they can notify the user, or even brake automatically. Other use case: Follow a car at a safe distance, slowing down when the next car slows down and speeding up when it speeds up again (within limits).

Safety APIs require communication APIs and a safety model. Key issues are liability for when/how the notifications are send and responded to. Requires generic safety oriented serviced that provides information about the road conditions and other vehicles and the proximity.

Integration with non-java code

Provide a standardized means to integrate OSGi applications with native code.

Provisioning

Provide a standardized means to deploy and provision the programs for the On Board Equipment (OBE).

Use case: Car Manufacturer or other control centers can push bundles to the OBEs

Download of other things then code

Provide a means to download information that is not code to the OBE.

Requires deployment of non-OSGi parts like native code, code for other processors (ECUs) in the vehicle which will be automatically reprogrammed, data, certificates, etc.

Resource management and hard real time

Restrict the usage of key resources (memory, CPU cycles, devices) on a per application basis as well as providing an environment where some of the code can run in a hard real time environment.

Any standard needs to take into account that the OBE will run more than just Java code. There is an ARINC avionics standard in this area that could be related to.

Vehicle Interface

A vehicle interface provides access to key vehicle data in a standardized way so that applications can run on multiple vehicles. Applications must also be able to discover the structure of the vehicle. That is, the application must be able to find out how many doors and the details for each door.

Types of data considered: Location, speed, temperature, heading, windspeed, traction, abs act. Airbag deployment, brake lights, technically any sensor, etc.

The OSGi VEG has been working on a Vehicle API. The European GST project also has developed a vehicle API.

An issue was raised if the car manufacturers will allow access to car data because currently this information is secret and guarded. The group expects the car manufacturers to open up this information in a controlled environment.

Human-Machine Interface (HMI)

Provide a way for applications to interact with the end user using an HMI present in the vehicle. Applications should be able to integrate seamlessly with the existing HMI, which might mean using controls that are not on a display.

AMI-C already started work in this area. VII will have HMI interaction requirements.

Security

Provide a secure programming model where different applications can run together in the same OBE.

Use case: how to secure sessions and how to secure the application integrity How to authenticate the vehicle (uses x509 certs) 1609.2 protocol. Confidentiality, integrity, authorization, authentication Management of certificates, upload certificates, etc.

It is not clear of the car manufacturers allow the OBE to be used for third party applications, but it is likely that this is the case.

Privacy issues.

Provide guarantees for privacy.

Use case: Session in VII must be anonymous because otherwise the government could track cars. However, certain use cases require

Drivers

Provide a comprehensive driver model so that many drivers can be written in an OSGi platform.

Use case: Connect an MP3 player and download the driver over the net.

Companies have to make too many drivers for too many platforms today. A standardized driver model would significantly simplify the world of the suppliers. Focus area is the things that connect from the outside like iPods.

AutoSAR

AutoSAR is a component standard in the vehicle industry for. It is not clear if there is an overlap or where the standard touches the OSGi domain. Maybe the AutoSAR APIs could become available as OSGi services?

Diagnostics

Provide access to detailed static data : VIN, model, type, options, engine, etc. as well as access to real time data: engine speed, cooling temp, etc.

A diagnostic abstraction is needed because there is so much variation in the bottom. Diagnostics will require a choice of features:

Choose network based on speed, access, etc.
Bus types abstractions
Multiple levels of security
Needs safeguards
Run special code on demand, download over the air

OSGi light

In certain case the features of code download and management over the air are very useful for very small devices. A light version of OSGi could increase the applicability of the OSGi service platform.

This question has popped up many times in the past. The majority of the weight of OSGi is caused by Java. However, in it would make sense to run OSGi on really small devices with a constrained memory budget. Maybe it is possible to create a slaved OSGi that runs under full control of a full blown OSGi (might be related to distributed OSGi).

However, it is not clear what memory budget and what service are target for such a light version.

Distributed OSGi

Provide a transparent model for using services from other frameworks.

Use case: Add an extra CPU to the vehicle OBE. Existing applications can be migrated to the second CPU transparently.

The Enterprise Expert group has this feature high on the list. The service registry is a very attractive service broker between a federated set of OSGi service platforms.

Navigation Model

Provide a comprehensive model for applications to interact with a navigation system. Requires a navigation data model and a control interface.

Use case: Route a UPS truck from a database in real time.

Prioritization

The above areas have been prioritized by voting. All remaining attendants received 5 votes that could be spread over the previously defined areas.

(7 votes) Resource management and hard real-time
(5 votes) Vehicle Interface and HMI
(4 votes) Non-Java code integration and AutoSAR
(3 votes) Safety Information, Provisioning, Drivers, Diagnostics, Download, and Navigation model
(2 votes) Security and OSGi Light

Non Functional

Several non functional areas were also discussed:

OSGi liaison with CVTA. Talks are going on but there is a dependency on what will happen with VEG.
A key issue that was noted by several participants is that the capabilities and benefits of OSGi service platforms are not known or not understood higher up in management of the car manufacturers. It is therefore adviced to make OSGi better known to people that decide what goes into the vehicle. That is, provide articles and white papers. Get rid of the question: OSG what?
There is a need to lobby with the governments to require OSGi. In a way, OSGi has few competitors because it is the only open standard. For example, lobby with governments to require OSGi. A concrete case is the toll fee collection system in Germany that is being discussed. For the US, it should be realized that a lot of decisions are made by the states in this area.
CVTA - Scott McCormick joined the group later and presented his work at CVTA. He is currently working for the Connected Vehicle Trade Organization. This organization wants to be a clearing house for information and collaborations in the connected vehicle world. There is an intention for a liaison with the OSGi because these specifications are seen as a cornerstone for the modern car.

Conclusions

The participants agreed that it was a very useful meeting. The goal of most participants had been to learn more about the OSGi Alliance and this was achieved. However, the goal for the Alliance was to stimulate more interest in the Vehicle Expert Group work. Several companies are highly interested but the car manufacturers indicated that they would like to promote and support the vision that OSGi has but that a full membership is not likely in the short run.

The VII project, and the GST/CVIS projects are likely to provide the best route to more adoption of OSGi in the vehicle industry.

The presentations (work in progress)

Introduction and results (Peter Kriens, OSGi)
OSGi and Real Time (Kelvin Nilson, AONIX)
Diagnostics (Robert Prince, Vetronix/ETAS)
OSGi Key Issues (Rob van den Berg, Siemens VDO)
VII Project (Gary Streelman, Delphi)

Attendees

Ford	Prasad Venkatesh
GM	Jay Parikh
SiemensVDO	Rob van den Berg
Delphi	Laci Jalics
Delphi	Frank Szczublewski
Delphi	Gary Streelman
Vetronix (ETAS)	Robert Prince
Wind River	Manny Hatz
Wind River	Patrick Shelly
Intel	Kevin Rushton
CVTA	Scott McCormick
Telcordia	Stan Pietrowicz
Aonix	Kelvin Nilson
Booz Allen Hamilton	Paul Valdetaro
Renesas	Amrit Vivekanand
OSGi	Peter Kriens
ProSyst	Kai Hackbarth