OSEK_概述

来源：华佗小知识

OSEK/VDXBinding SpecificationOSEK/VDX

Binding Specification

Version 1.3

17th 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.

writing from the OSEK/VDX steering committee.

OSEK/VDX BD 1.3© by OSEK- 1 -

OSEK/VDXWhat is OSEK/VDX?

Binding SpecificationOSEK/VDX is a joint project of the automotive industry. It aims at an industry standard for anopen-ended architecture for distributed control units in vehicles.

A real-time operating system, software interfaces and functions for communication andnetwork management tasks are thus jointly specified.

The term OSEK means ”Offene Systeme und deren Schnittstellen für die Elektronik imKraftfahrzeug” (Open systems and the corresponding interfaces for automotive electronics).The term VDX means „Vehicle Distributed eXecutive“. The functionality of OSEK operatingsystem was harmonised with VDX. For simplicity OSEK will be used instead of OSEK/VDXin the document.

OSEK/VDX partners

The following list is an incomplete list of companies which attended and contributed to theOSEK/VDX Technical Committee:Accelerated Technology Inc.,ACTIA,

Adam Opel AG,AFT GmbH,

ATM Computer GmbH,Blaupunkt,BMW AG,

Borg Instruments GmbH,Cambridge Consultants,Continental Teves,

Cummins Engine Company,DaimlerChrysler AG,Delco Electronics,Denso,

Epsilon GmbH,ETAS GmbH

FIAT - Centro Ricerche,FZI,

GM Europe GmbH,Hella KG,

Hewlett Packard France,

Hitachi Micro Systems Europe Ltd.,Hitex,

IBM Deutschland Entwicklung GmbH,IIIT - University of Karlsruhe,Infineon,INRIA,

Integrated Systems Inc.,IRISA,

LucasVarity,Magneti Marelli,

OSEK/VDX BD 1.3

Mecel,Motorola,

National Semiconductor,NEC Electronics GmbH,NRTA,

Philips Car Systems,Porsche AG,PSA,Renault,

Robert Bosch GmbH,

Sagem Electronic Division,Siemens Automotive,Softing GmbH,

ST Mircroelectronics,Stenkil Systems AB,

Sysgo Real-Time Solutions GmbH,TECSI,

Telelogic GmbH,TEMIC,

Texas Instruments,Thomson-CSF Detexis,Trialog,

TRW Automotive Electronics,

UTA - United Technologies Automotive,VDO Adolf Schindling GmbH,Vector Informatik,Visteon,

Volkswagen AG,

Volvo Car Corporation,Wind River Systems,3Soft GmbH.

- 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 networkmanagement.

Specification of a user interface independent of hardware and network.

Efficient design of architecture: The functionality shall be configurable and scaleable, toenable 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.

Standardised interfacing features for control units with different architectural designs.Sequenced utilisation of the intelligence (existing resources) distributed in the vehicle, toenhance the performance of the overall system without requiring additional hardware.Provides independence with regards to individual implementation, as the specificationdoes not prescribe implementation aspects.

• • • • • • • •

Advantages

Scope of the document :

As the standardisation of requirements that are applicable to different OSEK/VDXspecifications should not be replicated within the different specifications, this document istherefore 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 preventa divergence of the OSEK/VDX specifications by giving the possibility to refer to a singlebinding document.

OSEK/VDX BD 1.3© by OSEK- 3 -

OSEK/VDXBinding SpecificationTable of Contents

GENERAL DESCRIPTION (INFORMATIVE)..................................................................................5BINDINGS CONFIGURATION (NORMATIVE)...............................................................................92.12.233.13.23.34

BINDING INDEX OF OSEK/VDX SPECIFICATIONS :.................................................................................9BINDING INDEX OF OSEK/VDX CERTIFICATION PLANS :........................................................................9DEFINITION OF ERROR CODES..............................................................................................................10DEFINITION OF STATUSTYPE...............................................................................................................10SUPPORT OF ‘INTERNAL COMMUNICATION’.............................................................................................11

COMMON REQUIREMENTS SPECIFICATION (NORMATIVE)................................................10

HISTORY............................................................................................................................................12

List of Figures

FIGURE 1-1: LAYER MODEL OF OSEK/VDX WITH OSEK OS..............................................................................5FIGURE 1-2LAYER MODEL OF OSEK/VDX WITH OSEKTIME OS....................................................................6

List of Tables

TABLE 2-1 : BINDING INDEX OSEK/VDX SPECIFICATIONS..................................................................................9TABLE 2-2 : BINDING INDEX OSEK CERTIFICATION PLANS..................................................................................9

OSEK/VDX BD 1.3© by OSEK- 4 -

OSEK/VDXBinding Specification1 General description (informative)

The OSEK/VDX specification set consists of 4 normative documents that define therequirements of two choices of operating systems (real-time executive for ECU’s) with twochoices of communication features (data exchange within and between ECU’s) linked to therespective operating systems, and network management strategies (configuration determinationand monitoring).

OSEK Operating SystemApplicationCommunication APINetwork APIOSEK/COMStandard APIInteraction LayerOSEK/VDXNetworkManagementNetwork LayerOSEK/COMStandard ProtocolsOSEK/COMDevice DriverInterfaceData Link LayerBus I/O DriverBus FrameBus Communication HardwareFigure 1-1: Layer model of OSEK/VDX with OSEK OS

OSEK/VDX BD 1.3© by OSEK5

OSEK/VDXOSEKtimeOperatingSystemApplicationBinding SpecificationOSEKtime FTCom LayerApplication LayerMessageFiltering LayerTimeServiceFault-Tolerant SubsystemFault Tolerant LayerCommunication SubsystemInteraction LayerOSEK/VDXNetworkManagementCNIDriverBus I/OBus I/ODriverDriverBus I/ODriverBusCommunicationHardwareBusCommunicationHardwareFigure 1-2Layer model of OSEK/VDX with OSEKtime OS

OSEK/VDX operating system (OS)

The specification of the OSEK/VDX OS provides a pool of services and processing

mechanisms. The operating system serves as a basis for the controlled real-time execution ofconcurrent application and provides their environment on a processor. The architecture of theOSEK/VDX OS distinguishes three processing levels: interrupt level, a logical level foroperating systems activities and task level. The interrupt level is assigned higher priorities thanthe task level. In addition to the management of the processing levels, operating systemservices are provided for functionality like task management, event management, resourcemanagement, counter, alarm and error treatment.OSEK/VDX communication (COM)

The communication specification provides interfaces and protocols for the transfer of datawithin vehicle networks systems. This communication takes place between and within networkstations (ECU’s). The positioning of OSEK/VDX COM within the OSEK/VDX architecture isrepresented in Figure 1-1. It shows the interface with the application, OSEK/VDX networkmanagement and the hardware communication bus. This specification is organised in layers,including the interaction layer, network layer and data link layer interface. The interaction layerprovides the application programming interface (API) of OSEK/VDX COM to support the

OSEK/VDX BD 1.3

- 6 -

OSEK/VDXBinding Specificationtransfer of messages within and between network stations. For network communication, theinteraction layer uses services provided by the lower layers. The network layer provides aprotocol for the unacknowledged and segmented (USDT) transfer of application messages.The data link layer defines an open interface so that OSEK/VDX protocols can interface withdifferent type of buses. ECU-internal communication is handled by the interaction layer only.OSEK/VDX OSEKtime – Operating System

The OSEKtime operating system provides the necessary services to support distributed fault-tolerant highly dependable real-time applications (e.g., start-up of the system, message

handling, state message interface, interrupt processing, synchronisation and error handling).The operating system is built according to the user's configuration instructions at systemgeneration time. The operating system cannot be modified later at execution time.Described in the operating system specification is also the Time Service specification. TheTime Services support the synchronisation of the task execution due to a global time baseduring system start-up and repeatedly during normal operation (e.g., at every end of thedispatching table). The Time Service functionality are usually close connected to thecommunication layer, therefore the Time Service is implemented in FTCom.

If the functionality of both OSEKtime OS and OSEK OS is needed, it is possible to run bothsystems in parallel (not shown in Figure 1-2).

OSEK/VDX Fault-Tolerant Communication FTCom

FTCom is divided into the layers: Application, Message Filtering, Fault Tolerant, and

Interaction. The Application layer provides the Application Programming Interface (API). TheMessage Filtering layer provides mechanisms for message filtering. The Fault Tolerant layerprovides services required to support the fault-tolerant functionality, that includes judgementmechanisms for message instance management and support of message status information. TheInteraction layer provides services for the transfer of message instances via network: Resolvesissues connected with the presentation of a message instance on different hosts (e.g. differentbyte ordering), provides a message instance packing/unpacking service and supports a messageinstance status information. For efficiency reasons the Filter and Fault Tolerant layer areoptional.

OSEK/VDX network management (NM)

Network serves as a basis for new distributed control functions that are independent of localECU platforms. As a consequence of networking, the local station behaviour influences anddepends on the global behaviour, and vice versa. The mutual influences and dependencies oftenrequire network wide negotiated management. In order to guarantee the reliability and safetyof a distributed system, the OSEK/VDX NM gives support for several of such managementtasks. The basic concept of OSEK/VDX NM is monitoring network stations. Two alternativesmonitoring mechanisms are offered: direct and indirect station monitoring. Direct monitoring isperformed by a dedicated communication of the network management. Direct monitoring ofthe nodes may be impossible or undesirable. This could be the case for example for very simpleor time critical applications. The mechanism of indirect monitoring is therefore available. It is

OSEK/VDX BD 1.3

OSEK/VDXBinding Specificationbased on the use of monitored application messages. This indirect monitoring is limited tonodes that send messages in the course of normal operation.OSEK/VDX Implementation Language (OIL)

To reach the original goal of the OSEK/VDX project in having portable software, arecommended way of describing an OSEK/VDX system has to be defined. This is themotivation for elaborating a standardised OSEK/VDX Implementation language, called OIL.In parallel, OIL provides a possibility to configure an OSEK/VDX application inside aparticular central processing unit (CPU). As a consequence there is exactly one OILdescription for each CPU.

OSEK/VDX Run Time Interface (ORTI)

To provide debugging support on the level of OSEK objects, it is necessary to have debuggersavailable that are capable of displaying and debugging OSEK components. The ORTIspecification provides an interface for debugging and monitoring tools to access OSEK objectsin target memory. Tools can evaluate internal data structures of OSEK objects and theirlocation in memory. ORTI is consisting of a language to describe kernel objects (KOIL, KernelObject Interface Language) and a description of OSEK specific objects and attributes.Currently, only the KOIL specification has been released (ORTI Part A).

OSEK/VDX BD 1.3© by OSEK- 8 -

OSEK/VDXBinding Specification2 Bindings configuration (normative)

Multiple bindings of the OSEK/VDX specifications are available, each reflecting developmentefforts resulting from OSEK/VDX evaluations and introduction of new requirements.Interfaces between the OSEK/VDX specifications are guaranteed within the following bindingsets. The following tables list the issues of all OSEK/VDX specifications applicable to eachparticular binding reference. Two binding references are created to document on one hand theconfiguration of OSEK/VDX specifications (i.e. referred to as ‘SB’) and on the other hand theconfiguration of OSEK/VDX certification plans ((i.e. referred to as ‘CB’).

2.1 Binding index of OSEK/VDX specifications :

Specification binding identifier:

Binding

Operating System (OS)Communication (COM)Network management (NM)

OSEK Implementation Language (OIL)OSEKtime OS

OSEKtime COM (FTCOM)

Table 2-1 : Binding index OSEK/VDX specifications

SB0-1.01.01.0-SB1-2.0r12.0a2.12.0

SB2-2.0r12.1r12.52.1

SB31.22.1r12.2.22.5.12.21.01.0

SB31.32.22.2.22.5.12.31.01.0

2.2 Binding index of OSEK/VDX certification plans :

Certification binding identifier:

Conformance methodologyOS test planCOM test planNM test planOSEKtime test plan

Table 2-2 : Binding index OSEK certification plans

CB0----CB12.02.0--CB22.02.02.02.0

CB33.03.03.03.0-CB44.04.04.04.0-

OSEK/VDXBinding Specification3 Common requirements specification (normative)

3.1 Definition of error codes

The different parts of OSEK/VDX (e.g. OSEK OS, OSEK COM) specify return codes ofsystem functions to indicate different conditions which can arise during performing the systemfunction. These return codes of type StatusType are defined as define-variables in therespective documentation. However, because these return codes can not be seen locally (e.g.they are used as input parameter to ShutdownOS), unique values have to be defined across thedifferent specifications.

To accommodate this, ranges of error code values have been defined which are assigned to thedifferent parts of the specification. Each range consists of 32 values. Within each range, thefirst up to 16 values are consecutively defined as standard return values. Starting with thesecond half of the range, the second 16 values may be defined consecutively to inform aboutdetection of implementation specific additional errors (e.g. stack overflow, corruption ofinternal lists etc.).

Within the first range, the value ‘0’ (E_OK) has a special meaning. It indicates the successfulcompletion of a system function without any specific return indication.The ranges are assigned as follows:01 to 3132 to 63 to 9596 to 127128 to 159160 to 255

E_OK

OSEK OS error codesOSEK COM error codesOSEK NM error codesOSEKtime OS error codesOSEKtime FTCom error codesOSEK RESERVED

3.2 Definition of StatusType

The data type StatusType is used within all parts of OSEK/VDX. To be able to combinedifferent parts of OSEK/VDX from different supplies (e.g. OSEK COM from supplier A,OSEK NM from supplier B), the definition of this type has to be handled with care to avoidconflicts.

Conflicts can arise if the definitions are different between the different parts of OSEK/VDX.Moreover, even if the definitions are the same, the compiler will have to create an error if thesame type is defined more than once in one translation unit.

OSEK/VDX BD 1.3

- 10 -

OSEK/VDXBinding SpecificationTherefore, the definition of StatusType and of the constant E_OK have to be done as followsin all parts of OSEK:

#ifndef STATUSTYPEDEFINED#define STATUSTYPEDEFINEDtypedef unsigned char StatusType;#define E_OK 0#endif

These definitions have to be done in the header files supplied by the OSEK suppliers.

Please note that, if StatusType is not set to ‘unsigned char’, there is no guarantee thatimplementations of different OSEK parts 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 beconsistent and guaranteed. To cope with the situation that both kernels, i.e. COM and OS, arelinked within a system, rules are set up clarifying which kernel handles internalcommunication.

If both COM and OS kernels are present but one of CCCA or CCCB only is to be supported(no application message use external communication) then the OSEK OS kernel shall providethe functionality to handle internal messages, i.e. those using internal communication.If both COM and OS kernels are present but one of CCC0 onwards is to be supported tohandle external communication in addition to internal communication then the OSEK COMkernel shall provide the functionality to handle internal messages, i.e. those using internalcommunication.

Thus, it is guaranteed that definitions of data types used within internal and external messagehandling are consistent within a system.

To internally assure that the stated rules are followed, a define-variable

LOCALMESSAGESONLY is defined. Internal communication within OSEK OS must beimplemented if this define-variable is set.

The define-variable LOCALMESSAGESONLY shall be defined by the tool which generates asystem out of an OIL file. As long as the definition of messages in OIL has not beencompleted, other means of definition may be used.

OSEK/VDX4 History

Issue1.0 c 11.01.11.21.3

Description

Original issue candidate release 1.

Binding SpecificationDate

21st July 200028th July 200011th September 200008th December 200014th September 2001

Original issue 1.0 from candidate release 1 withno requirement change.

Replacement of COM 2.2 with COM 2.2.1 insection 2.1.

Replacement of OS 2.1 by OS 2.1r1 and COM2.2.1 by COM 2.2.2 in section 2.1.

Replacement of OS 2.1r1 by OS 2.2 and OIL2.2 by OIL 2.3. Add OSEKtime/ORTI.

因篇幅问题不能全部显示，请点此查看更多更全内容

查看全文