l~ OSEKNDX
`
`Binding Specification
`
`OSEKIVDX
`
`Binding Specification
`
`Version 1.3
`
`1 ih September 2001
`
`This document is an official release and replaces all previously distributed documents. The OSEK group retains the right to
`make changes to this document without notice and does not accept any liability for errors.
`All rights reserved. No part of this document may be reproduced, in any form or by any means, without permission in
`writing from the OSEKNDX steering committee.
`
`OSEKNDX BD 1.3
`PAGE 1 OF 12
`
`© byOSEK
`
`- 1 -
`
`BMW EXHIBIT 1007
`
`

`

`Ill OSEKIVDX
`
`Binding Specification
`
`What is OSEKIVDX?
`OSEKNDX is a joint project of the automotive industiy . It aims at an industiy standard for an
`open-ended architecture for disu·ibuted conu·ol mlits in vehicles.
`A real-time operating system, software interfaces and fi.mctions for connmmication and
`network management tasks are thus jointly specified.
`The te1m OSEK means "Offene Systeme und deren Schnittstellen fur die Elekti·onik im
`Kraftfahrzeug" (Open systems and the conesponding interfaces for automotive elecu·omcs).
`The ten n VDX means ,Vehicle Disu·ibuted eXecutive". The fi.mctionality of OSEK operating
`system was hrumomsed with VDX. For simplicity OSEK will be used instead of OSEKNDX
`in the document.
`
`OSEKNDX partners
`The following list is an incomplete list of compallies which attended and conti'ibuted to the
`OSEKNDX Technical Committee:
`
`Accelerated Technology Inc.,
`ACTIA,
`Adam Opel AG,
`AFT GmbH,
`ATM Computer GmbH,
`Blaupunkt,
`BMWAG,
`Borg Instllllllents GmbH,
`Crunbridge Consultants,
`Continental Teves,
`Cmmllins Engine Company,
`DaimlerCmysler AG,
`Delco Elecu·omcs,
`Denso,
`Epsilon GmbH,
`ETAS GmbH
`FIAT - Cenu·o Ricerche,
`FZI,
`GM Europe GmbH,
`HellaKG,
`Hewlett Packru·d France,
`Hitachi Micro Systems Europe Ltd.,
`Hitex,
`IBM Deutschland Entwicklung GmbH,
`IIIT- Umversity ofKarlsmhe,
`Infineon,
`INRIA,
`Integrated Systems Inc.,
`IRIS A,
`LucasVarity,
`Magneti Marelli,
`
`Mecel,
`Motorola,
`National Senliconductor,
`NEC Elecu·omcs GmbH,
`NRTA,
`Philips Car Systems,
`Porsche AG,
`PSA,
`Renault,
`Robe1i Bosch GmbH,
`Sagem Elecu·omc Division,
`Siemens Automotive,
`Softing GmbH,
`ST Mircroelecu·onics,
`Stenkil Systems AB,
`Sysgo Real-Time Solutions GmbH,
`TECSI,
`Telelogic GmbH,
`TEMIC,
`Texas Instllllllents,
`Thomson-CSF Detexis,
`Trialog,
`TRW Automotive Elecu·omcs,
`UTA - Umted Technologies Automotive,
`VDO Adolf Schindling GmbH,
`Vector Inf01m atik,
`Visteon,
`Volkswagen AG,
`Volvo Car Corporation,
`Wind River Systems,
`3Soft GmbH.
`
`OSEKNDX BD 1.3
`PAGE2 OF 12
`
`© byOSEK
`
`- 2 -
`
`

`

`Motivation
`•
`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 manufacturers due to different
`interfaces and protocols.
`
`•
`
` Goal
` Support of the portability and reusability of the application software by:
`•
`Specification of interfaces which are abstract and as application-independent as possible,
`in the following areas: real-time operating system, communication and network
`management.
`Specification of a user interface independent of hardware and network.
`Efficient design of architecture: The functionality shall be configurable and scaleable, to
`enable optimal adjustment of the architecture to the application in question.
`Verification of functionality and implementation of prototypes in selected pilot projects.
`
`•
`•
`
`•
`
` Advantages
`•
`Clear savings in costs and development time.
`•
`Enhanced quality of the software of control units of various companies.
`•
`Standardised interfacing features for control units with different architectural designs.
`•
`Sequenced utilisation of the intelligence (existing resources) distributed in the vehicle, to
`enhance the performance of the overall system without requiring additional hardware.
`Provides independence with regards to individual implementation, as the specification
`does not prescribe implementation aspects.
`
`•
`
`Scope of the document :
`
`As the standardisation of requirements that are applicable to different OSEK/VDX
`specifications should not be replicated within the different specifications, this document is
`therefore set-up to collate all requirements that are owned by the different specifications.
`This document also provides an overall description of the OSEK/VDX specifications set.
`This binding specification is therefore a ‘normative’ document and intention is laid to prevent
`a divergence of the OSEK/VDX specifications by giving the possibility to refer to a single
`binding document.
`
`OSEK/VDX BD 1.3
`
`© by OSEK
`
`- 3 -
`
`PAGE 3 OF 12
`
`

`

`liJJ
`
`OSEKNDX I
`
`Binding Specification
`
`Table of Contents
`
`1
`
`2
`
`GENERAL DESCRIPTION (INFORMATIVE) .................................................................................. 5
`
`BINDINGS CONFIGURATION (NORMATIVE) ............................................................................... 9
`
`201 B INDINGINDEXOFOSE KND X SPECIFICATIONS: ooo o .. .. .. o .. .. .. o .. .. .. .. .. o .. .. .. o .. .. .. o .. .. .. .. .. o .. .. .. o .. .. .. o .. .. .. .. .. 0 .. 9
`202 B INDINGINDEXOFOSE KND X CERTIFICATION PLANS: .. .. .. .. o .. .. .. .. .. o .. .. .. o .. .. .. o .. .. .. .. .. o .. .. .. o .. .. .. o .. .. .. .. .. 0 .. 9
`
`3
`
`COMMON REQUIREMENTS SPECIFICATION (NOR.:i\fATIVE) ................................................ 10
`
`3 01 D EFINITION OF ERROR CODES o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o 10
`302 D EFINITIONOFSTATUSTYPEoooo oooooo oooooo ooooooo oooooo oooooo oooooo ooooooo oooooo oooooo oooooo ooooooo oooooo oooooo oooooo ooooooo oooooo oooooo o10
`303
`SUPPORT OF 'INTERNAL COMMUNICATION'ooooo oooooo oooooo oooooo ooooooo oooooo oooooo oooooo ooooooo oooooo oooooo oooooo ooooooo oooooo oooooo o1 1
`
`4
`
`HISTORY ............................................................................................................................................ 12
`
`List of Figures
`
`FIGURE 1- 1: LAYER MODEL OF OSE KNDX WTIH OSE K OS .... .. .. .. .. .. ........ .. .. .. .. .. .... .. .. .. .. .. .. .. .... .. .. .. .. .. ........ .. .. .. 5
`FIGURE 1-2
`LAYERMODELOFOSEKNDX WTIHOSEKTIMEOS .. .. ........ .. .. .. .. .. .... .. .. .. .. .. .. .. .... .. .. .. .. .. ........ .. .. .. 6
`
`List of Tables
`
`T ABLE 2- 1 : BINDING INDEX OSEKNDX SPECIFICATIONS .. .. .... .. .. .. .. .. ........ .. .. .. .. .. .... .. .. .. .. .. .. .. .... .. .. .. .. .. ........ .. .. .. 9
`T ABLE 2-2 : BINDING INDEX OSEK CERTIFICATION PLANS .. .. .... .. .. .. .. .. ........ .. .. .. .. .. .... .. .. .. .. .. .. .. .... .. .. .. .. .. ........ .. .. .. 9
`
`OSEKND X B D 103
`PAGE40F12
`
`©byOSEK
`
`- 4 -
`
`

`

`OSEKNDX
`
`Binding Specification
`
`1 General description (informative)
`The OSEKNDX specification set consists of 4 nonnative documents that defme the
`requirements of two choices of operating systems (real-time executive for ECU's) with two
`choices of communication features (data exchange within and between ECU' s) linked to the
`respective operating systems, and network management strategies (configuration detennination
`and monitoring).
`
`OSEK Operating System
`
`Application
`
`Networl< API t
`
`Communication API i
`:
`
`Interaction Layer
`
`:
`
`Networ1< Layer
`
`OSEKNDX
`
`Networ1<
`Management
`
`:
`
`+
`
`I
`Data Link Layer
`.......................................................
`Bus 110 Driver
`
`Bus Communication Hardware
`
`OSEJ</COM
`Standard API
`
`OSEKICOM
`Standard Protocols
`
`OSEKICOM
`Device Driver
`Interface
`
`Bus Frame
`
`Figure 1-1: Layer model of OSEKNDX with OSEK OS
`
`OSEKNDX BD 1.3
`PAGE5 0 F12
`
`© byOSEK
`
`5
`
`

`

`OSEKIVDX
`
`Binding Specification
`
`au
`
`E
`
`• . . . , . .
`
`I
`
`j~
`
`Application
`
`•
`
`OSEKtime FTCom Layer
`.------l----.
`
`Application Layer
`
`I
`
`OSEKNDX
`Network
`Management
`
`I Message Filtering Layer
`
`r---- ---------1~
`~;;:j:~~~;~;:t;:b;~;~;;~r-~-:
`u---------------.
`l
`1
`Fault Tolerant Layer
`11
`I
`~L:::: '::::::::: :;~ 1-- ~
`
`:
`
`Communication Subsystem
`
`Interaction Layer
`
`• CNI Driver
`
`Bus 1/0 Driver
`
`Bus Communication Hardware
`
`Time
`Service
`
`• ..
`
`I
`
`I
`
`Figure 1-2
`
`Layer model of OSEKIVDX with OSEKtime OS
`
`OSEKNDX operating system (OS)
`
`The specification of the OSEKNDX OS provides a pool of se1v ices and processing
`mechanisms. The operating system se1v es as a basis for the controlled real-time execution of
`concmTent application and provides their environment on a processor. The architecture of the
`OSEKNDX OS distinguishes three processing levels: intenupt level, a logical level for
`operating systems activities and task level. The intenupt level is assigned higher priorities than
`the task level. In addition to the management of the processing levels, operating system
`se1v ices are provided for functionality like task management, event management, resource
`management, counter, almm and en or treatment.
`
`OSEKNDX communication (COM)
`The communication specification provides interfaces and protocols for the transfer of data
`within vehicle networks systems. This communication takes place between and within network
`stations (ECU's). The positioning ofOSEK/VDX COM within the OSEKNDX m·chitectme is
`represented in Figme 1-1 . It shows the interface with the application, OSEKIVDX network
`management and the hardware communication bus. This specification is organised in layers,
`including the interaction layer, network layer and data link layer inte1face. The interaction layer
`provides the application programming interface (API) of OSEK/VDX COM to supp01i the
`
`OSEK.NDX BD 1.3
`PAGE60F12
`
`~ byOSEK
`
`- 6 -
`
`

`

`OSEKIVDX
`
`Binding Specification
`
`n·ansfer of messages within and between network stations. For network commmlication, the
`interaction layer uses services provided by the lower layers. The network layer provides a
`protocol for the unacknowledged and segmented (USDT) n·ansfer of application messages.
`The data link layer defmes an open interface so that OSEKNDX protocols can interface with
`different type of buses. ECU-intemal communication is handled by the interaction layer only.
`
`OSEKNDX OSEKtime - Operating System
`The OSEKtime operating system provides the necessmy setvices to suppoli disn·ibuted fault(cid:173)
`tolerant lllghly dependable real-time applications (e.g., stati -up of the system, message
`handling, state message intetface, intemtpt processing, synchrorusation and enor handling).
`
`The operating system is built according to the user's configuration instructions at system
`generation time. The operating system cannot be modified later at execution time.
`
`Described in the operating system specification is also the Time Setvice specification. The
`Time Setvices supp011 the synchrorusation of the task execution due to a global time base
`during system strut-up and repeatedly during n01m al operation (e.g., at evety end of the
`dispatching table). The Time Setvice functionality are usually close connected to the
`c01mnunication layer, therefore the Time Setvice is implemented in FTCom.
`
`If the functionality of both OSEKtime OS and OSEK OS is needed, it is possible to mn both
`systems in parallel (not shown in Figure 1-2).
`
`OSEKNDX Fault-Tolerant Communication FTCom
`
`FTCom is divided into the layers: Application, Message Filtering, Fault Tolerant, and
`Interaction. The Application layer provides the Application Progrrumning Intetface (API). The
`Message Filtering layer provides mechrulisrns for message filtering. The Fault Tolerant layer
`provides setv ices required to supp011 the fault-tolerant fi.mctionality, that includes judgement
`mechrulistns for message instance management and supp011 of message status infon nation. The
`Interaction layer provides setv ices for the n·ansfer of message instances via network: Resolves
`issues connected with the presentation of a message instance on different hosts (e.g. different
`byte ordering), provides a message instance packing/unpacking setvice and supp01ts a message
`instance status inf01m ation. For efficiency reasons the Filter and Fault Tolerant layer ru·e
`optional
`
`OSEKNDX network management (NM)
`Network setves as a basis for new disn·ibuted conn·ol functions that ru·e independent of local
`ECU platf01ms. As a consequence of networking, the local station behaviour influences and
`depends on the global behaviour, and vice versa. The mutual influences and dependencies often
`require network wide negotiated management. In order to guarantee the reliability and safety
`of a dis111buted system, the OSEKNDX NM gives supp011 for several of such management
`tasks. The basic concept of OSEKNDX NM is morutoring network stations. Two altematives
`morutoring mechrulisrns ru·e offered: direct and indirect station morutoring. Direct morutOI1ng is
`petfonned by a dedicated communication of the network management Direct morutOI1ng of
`the nodes may be impossible or undesirable. Tills could be the case for exrunple for vety simple
`or time ct1tical applications. The mechrulism of indirect morutOI1ng is therefore available. It is
`OSEKNDX BD 1.3
`© by OSEK
`7
`PAGE70F12
`
`

`

`OSEKIVDX I
`
`Binding Specification
`
`based on the use of monitored application messages. This indirect monitoring is limited to
`nodes that send messages in the comse of nonnal operation.
`
`OSEKNDX Implementation Language (OIL)
`To reach the original goal of the OSEKNDX project in having portable software, a
`recommended way of describing an OSEKNDX system has to be defmed. This is the
`motivation for elaborating a standardised OSEKNDX Implementation language, called OIL.
`In parallel, OIL provides a possibility to configme an OSEKNDX application inside a
`pruiicular cenu·al processing unit (CPU). As a consequence there is exactly one OIL
`description for each CPU.
`
`OSEKNDX Run Time Interface (ORTI)
`To provide debugging supp011 on the level of OSEK objects, it is necessaty to have debuggers
`available that are capable of displaying and debugging OSEK components. The ORTI
`specification provides an inteiface for debugging and monitoring tools to access OSEK objects
`in tru·get mem01y. Tools can evaluate intemal data stlu ctmes of OSEK objects and their
`location in mem01y. ORTI is consisting of a language to describe kemel objects (KOIL, Kemel
`Object Interface Language) and a description of OSEK specific objects and atu·ibutes.
`Cunently, only the KOIL specification has been released (ORTI Pati A).
`
`OSEKNDX BD 1.3
`PAGE80F12
`
`© byOSEK
`
`- 8 -
`
`

`

`OSEKIVDX
`
`Binding Specification
`
`2 Bindings configuration (normative)
`Multiple bindings of the OSEKIVDX specifications are available, each reflecting development
`eff01ts resulting fi:om OSEKIVDX evaluations and introduction of new requirements.
`Inteifaces between the OSEKIVDX specifications are guaranteed within the following binding
`sets . The following tables list the issues of all OSEKIVDX specifications applicable to each
`pruticular binding reference. Two binding references are created to document on one hand the
`configuration of OSEKIVDX specifications (i.e. refen ed to as 'SB ') and on the other hand the
`configuration ofOSEKIVDX ce1t ification plans ((i.e. refened to as 'CB').
`
`2.1 Binding index of OSEKNDX specifications :
`
`Specification binding identifier:
`
`Binding
`
`Operating System (OS)
`
`Communication (COM)
`
`Network management (NM)
`
`OSEK Implementation Language (OIL)
`
`OSEKtime OS
`
`OSEKtime COM (FTCOM)
`
`580
`-
`1.0
`1.0
`1.0
`-
`
`581
`-
`2.0r1
`2.0a
`2.1
`2.0
`
`582
`-
`2.0r1
`2.1r1
`2.5
`2.1
`
`583
`1.2
`2.1r1
`2.2.2
`2.5.1
`2.2
`1.0
`1.0
`
`583
`1.3
`2.2
`2.2.2
`2.5.1
`2.3
`1.0
`1.0
`
`Table 2-1 : Binding index OSEKIVDX specifications
`
`2.2 Binding index of OSEKNDX certification plans :
`
`Conf01mance methodology
`
`OS test plan
`
`Certification binding identifier: C80
`-
`-
`-
`-
`
`COM test plan
`
`NMtestplan
`
`OSEKtime test plan
`
`C81
`2.0
`2.0
`-
`-
`
`C82
`
`2.0
`
`2.0
`2.0
`2.0
`
`C83
`3.0
`3.0
`3.0
`3.0
`-
`
`C84
`4.0
`4.0
`4.0
`4.0
`-
`
`Table 2-2 : Binding index OSEK ce1tification plans
`
`OSEKIVDX BD 1.3
`PAGE 9 OF 12
`
`~ byOSEK
`
`9
`
`

`

`Ill OSEKIVDX
`
`Binding Specification
`
`3 Common requirements specification (normative)
`
`3.1 Definition of error codes
`
`The different palis of OSEKNDX (e.g. OSEK OS, OSEK COM) specify retum codes of
`system :ftmctions to indicate different conditions which can arise dming perfonning the system
`ftmction. These retum codes of type StatusType are defmed as defme-variables in the
`respective documentation. However, because these retmn codes can not be seen locally (e.g.
`they are used as input parameter to ShutdownOS), lmique values have to be defmed across the
`different specifications.
`
`To accommodate this, ranges of enor code values have been defmed which are assigned to the
`different palis of the specification. Each range consists of 32 values. Within each range, the
`first up to 16 values are consecutively defined as standard retmn values. Struiing with the
`second half of the range, the second 16 values may be defined consecutively to inf01m about
`detection of implementation specific additional enors (e.g. stack overflow, conuption of
`intemal lists etc.).
`
`Within the first range, the value ' 0' (E_OK) has a special meaning. It indicates the successful
`completion of a system fimction without any specific retum indication.
`
`The ranges ru·e assigned as follows:
`
`0
`
`1 to 31
`
`32 to 63
`
`64 to 95
`
`96 to 127
`
`128 to 159
`
`160 to 255
`
`E OK
`
`OSEK OS enor codes
`
`OSEK COM enor codes
`
`OSEK NM enor codes
`
`OSEKtime OS enor codes
`
`OSEKtime FTCom enor codes
`OSEK RESERVED
`
`3.2 Definition of StatusType
`
`The data type StatusType is used within all pruis of OSEKNDX. To be able to combine
`different pruis of OSEKNDX from different supplies (e.g. OSEK COM fi:om supplier A,
`OSEK NM from supplier B), the definition of this type has to be handled with cru·e to avoid
`conflicts.
`Conflicts can ru·ise if the defmitions are different between the different pruis of OSEKNDX.
`Moreover, even if the defmitions ru·e the same, the compiler will have to create an enor if the
`srune type is defmed more than once in one translation lmit.
`
`OSEKNDX BD 1.3
`PAGE 10 OF 12
`
`© byOSEK
`
`- 10-
`
`

`

`liJ] OSEKNDX
`
`Binding Specification
`
`Therefore, the definition of Status Type and of the constant E _OK have to be done as follows
`in all pa1is of OSEK:
`
`#ifndef STATUSTYPEDEFINED
`
`#define STA TUSTYPEDEFINED
`
`typedefllllsigned char StatusType;
`
`#defmeE OKO
`
`#endif
`
`These definitions have to be done in the header files supplied by the OSEK suppliers.
`
`Please note that, if Status Type is not set to 'lmsigned char', there is no guarantee that
`implementations of different OSEK pa1is by different suppliers will be able to coexist.
`
`3.3 Support of 'internal communication'
`
`The definition of messages for internal, external and internal-external communication must be
`consistent and guaranteed. To cope with the situation that both kemels, i.e. COM and OS, are
`linked within a system, mles are set up clarifying which kemel handles internal
`communication.
`
`Ifboth COM and OS kemels are present but one ofCCCA or CCCB only is to be supp01ied
`(no application message use external communication) then the OSEK OS kemel shall provide
`the fimctionality to handle intemal messages, i.e. those using internal communication.
`
`If both COM and OS kemels are present but one of CCCO onwards is to be supp01ied to
`handle external communication in addition to intemal communication then the OSEK COM
`kemel shall provide the fimctionality to handle intemal messages, i.e. those using internal
`communication.
`
`Thus, it is guaranteed that definitions of data types used within intemal and extemal message
`handling are consistent within a system.
`
`To intemally assure that the stated mles are followed, a defme-variable
`LOCALMESSAGESONL Y is defmed. Internal communication within OSEK OS must be
`implemented if this defme-variable is set.
`
`The define-variable LOCALMESSAGESONL Y shall be defmed by the tool which generates a
`system out of an OIL file. As long as the definition of messages in OIL has not been
`completed, other means of definition may be used.
`
`OSEKNDX BD 1.3
`PAGE 11 OF 12
`
`©byOSEK
`
`11
`
`

`

`OSEKNDX
`
`Binding Specification
`
`liJJ
`
`4 History
`
`Issue
`
`Description
`
`Date
`
`1.0 c 1
`
`Original issue candidate release 1.
`
`21st July 2000
`
`1.0
`
`1.1
`
`1.2
`
`1.3
`
`Original issue 1.0 from candidate release 1 with 28th July 2000
`no requirement change.
`
`Replacement of COM 2.2 with COM 2.2.1 in
`section 2.1.
`
`Replacement of OS 2.1 by OS 2.1rl and COM
`2.2.1 by COM 2.2.2 in section 2.1.
`
`Replacement of OS 2.1rl by OS 2.2 and OIL
`2.2 by OIL 2.3. Add OSEKtime/ORTI.
`
`11th September 2000
`
`08th December 2000
`
`14th September 2001
`
`OSEKNDX BD 1.3
`PAGE 12 OF 12
`
`© byOSEK
`
`- 12-
`
`