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: 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).
Motivation
GoalSupport of the portability and reusability of the application software by:
Advantages
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. |