Goals and Motivation

What is OSEK/VDX ?

In May 1993 OSEK has been founded as a joint project in the German automotive industry aiming at an industry standard for an open-ended architecture for distributed control units in vehicles. OSEK is an abbreviation for the German term "Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug" (English: Open Systems and the Corresponding Interfaces for Automotive Electronics). Initial project partners were BMW, Bosch, DaimlerChrysler, Opel, Siemens, VW and the IIIT of the University of Karlsruhe as co-ordinator. The French car manufacturers PSA and Renault joined OSEK in 1994 introducing their VDX-approach (Vehicle Distributed eXecutive) which is a similar project within the French automotive industry. At the first workshop on October 1995 the OSEK/VDX group presented the results of the harmonised specification between OSEK and VDX. After the 2nd international OSEK/VDX Workshop in October 1997 the 2nd versions of the specifications were published.

The open architecture introduced by OSEK/VDX comprises the three areas:

- Communication (data exchange within and between control units)
- Operating System (real-time execution of ECU software and base for the other OSEK/VDX modules)
- Network Management (Configuration determination and monitoring)

For Communication and Operating System, there are alternative standards for normal requirements (standard operating system/communication specifications), or special requirements covering globally synchronised fault-tolerant architectures (OSEKtime specifications).



  • - high, recurring expenses in the development and variant management of non-application related aspects of control unit software
  • - incompatibility of control units made by different manufactures due to different interfaces and protocols




Support of the portability and reusability of the application software by:
  • - specification of interfaces which are abstract and as application-independent as possible
  • - specification of an user interface independent of hardware and network
  • - efficient design of architecture: The functionalities shall be configurable and scalable, to enable optimal adjustment of the architecture to the application in question
  • - verification of functionality and implementation of prototypes in selected pilot projects




  • - clear savings in costs and development time
  • - enhanced quality of the software of control units of various companies
  • - standardized interfacing features for control units with different architectural designs
  • - sequenced utilization of the intelligence (existing resources) distributed in the vehicle, to enhance the performance of the overall system without requiring additional hardware
  • - provides absolute independence with regards to individual implementation, as the specification does not prescribe implementation aspects




A structured and modular software implementation based on standardised interfaces and protocols as proposed by OSEKVDX is a necessary condition for the portability and extendibility, and thus the reusability of existing software. Functional extendibility means the integration of new application functions into a single control unit together with other application functions.

Application porting is the transfer of application functions from one hardware platform to another one with only minor modifications, e.g. porting of existing application software to the next product generation of an ECU. Moreover, extendibility and portability should be independent of the supplier of application functions, i.e. a "co-habitation" of software from different suppliers must be possible. It shall be remarked that OSEKVDX does not prescribe the implementation of OSEKVDX modules, i.e. different ECUs may have the same OSEKVDX interfaces, but different implementations, depending on the hardware architecture and the performance required.