Transcript Hinweise - Main / OSGi Alliance

Lessons learned from the VW Vehicle API
Jens Krüger, Hans-Christian Fricke
22.3.2007 OSGi VEG Workshop, Eindhoven
Volkswagen Group Research
Who are we?
Hans-Christian Fricke
Jens Krüger
•Data communications
•Mobile device applications
•Java technologies
•Vehice bus systems
•Vehicle abstraction
•VAPI development
Volkswagen AG, Group Research, Wolfsburg, Germany
Stand: 11. Juli 2006
Konzernforschung
\Vortraege\Mastervorlage.pot
2
What is the Vehicle API (VAPI)?
• Specification and implementation
of a vehicle object model
Hardware
access
• Manufacturer and model
independent
• All definitions, mappings, etc. are
verifiable by XML schema
Mapping
rules
VAPI
Object
representation
• VAPI covers all layers
Object
model
Stand: 11. Juli 2006
Konzernforschung
\Vortraege\Mastervorlage.pot
3
References and availability
• Proven solution used by
• >>30 research & development projects within VW and Audi
• NoW (Network On Wheels – VW, BMW, DC)
• VII (Vehicle Infrastructure Integration - VW, GM, Ford, Toyota, Nissan, DC, BMW)
• Free for research, development and education
•
•
•
•
Binary distribution for Linux Kernel 2.6.x (without NDA), Windows prototype exists
Option for access to the source-code (with NDA)
Tool chain available (e.g. Profile Generator for mapping and import of DBC files)
Java client API including simple OSGi wrapper
Stand: 11. Juli 2006
Konzernforschung
\Vortraege\Mastervorlage.pot
4
Experiences learned from the VAPI effort
• Prepare for throttling of data updates
• Within our applications we had to throttle the updates based on the specific
application requirements, to avoid “data update/notify-flooding”.
• For example: In a VW CAN systems some powertrain information is cyclic updated all
7ms
Stand: 11. Juli 2006
Konzernforschung
\Vortraege\Mastervorlage.pot
5
Experiences learned from the VAPI effort
• An abstract type model is valuable
• Use of abstract data type patterns to express the
behaviour of the specific data object
• Differentiation between
• abstract type conventions of objects and
• the naming scheme within the object tree
• Not only OSGi/Java centric
• The elements should be self-describing
• Abstract data types should have properties that
define their limits and character
• SI unit, max. value, min. value, enumeration states, etc.
Stand: 11. Juli 2006
Konzernforschung
\Vortraege\Mastervorlage.pot
6
Synergy between the vehicle interfaces
• Standardization and acceptance
• We are not fixed on our VAPI efforts, we need one wide accepted standard
• We would like to contribute in the VEG OMA-DM standardization
• We see a need for both, a reference implementation and a specification
• Collaboration
• As the Volkswagen (VAPI) and VEG proposals are quite close, we are open for further
work within the VEG
Stand: 11. Juli 2006
Konzernforschung
\Vortraege\Mastervorlage.pot
7
Summary
• Suggestions for further for the OSGi VEG efforts
• An electronic and verifiable specification (e.g. XML, Schema)
• A reference implementation of the API
• ...
• Collaboration
• We are open for further sharing of knowledge the helps to establish a common Vehicle
API
• The common goal must be to enable a market for vehicle applications. No
one profits from divergent APIs in such a small segment.
Stand: 11. Juli 2006
Konzernforschung
\Vortraege\Mastervorlage.pot
8
Questions?
[email protected]
Thank you.
Stand: 11. Juli 2006
Konzernforschung
\Vortraege\Mastervorlage.pot
9