90 likes | 437 Views
Lessons learned from the VW Vehicle API Jens Krüger, Hans-Christian Fricke. 22.3.2007 OSGi VEG Workshop, Eindhoven . Who are we?. Jens Krüger Vehice bus systems Vehicle abstraction VAPI development. Hans-Christian Fricke Data communications Mobile device applications
E N D
Lessons learned from the VW Vehicle APIJens Krüger, Hans-Christian Fricke 22.3.2007 OSGi VEG Workshop, Eindhoven
Who are we? • Jens Krüger • Vehice bus systems • Vehicle abstraction • VAPI development • Hans-Christian Fricke • Data communications • Mobile device applications • Java technologies Volkswagen AG, Group Research, Wolfsburg, Germany \Vortraege\Mastervorlage.pot
What is the Vehicle API (VAPI)? • Specification and implementation of a vehicle object model • Manufacturer and model independent • All definitions, mappings, etc. are verifiable by XML schema • VAPI covers all layers \Vortraege\Mastervorlage.pot
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 \Vortraege\Mastervorlage.pot
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 \Vortraege\Mastervorlage.pot
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. \Vortraege\Mastervorlage.pot
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 \Vortraege\Mastervorlage.pot
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. \Vortraege\Mastervorlage.pot
Questions? vapi@volkswagen.de Thank you. \Vortraege\Mastervorlage.pot