Downloaded from SAE International by University of New South Wales, Saturday, September 15, 2018

SAE TECHNICAL950291
PAPER SERIES

Open Systems and Interfaces for Distributed

Electronics in Cars (OSEK)

U. Kiencke and K. J. Neumann

IIIT, University of Karlsruhe
L. Frey, J. Graf, and T. Wollstadt
Adam Opel AG

J. Krammer, W. Kremer, F. Lersch, and E. Schmidt

AG
BMW

J. Minuth, T. Raith, and T. Thurner

Daimler-Benz AG

H. Kuder and V. Wilhelmi

Mercedes-Benz AG

H.-J. Mathony and D. Schäfer-Siebert

Robert Bosch AG

R. John, M. Reinfrank, and K. Storjohann

Siemens AG

C. Hoffmann
Volkswagen AG

Reprinted from: Automotive Multiplexing Technology

(SP-1070)

International CongressDetroit,
and Exposition
Michigan
February 27 - March 2, 1995
400 Commonwealth Drive, Warrendale, PA 15096-0001 U.S.A. Tel : (412)776-4841 Fax:(412)776-5760
 Downloaded from SAE International by University of New South Wales, Saturday, September 15, 2018

The appearance of the ISSN code at the bottom of this page indicates SAE's consent
that copies of the paper may be made for personal or internal use of specific clients.
This consent is given on the condition, however, thatthe copier pay a $5.00 per article
copy fee through the Copyright Clearance Center, Inc. Operations Center, 222
Rosewood Drive, Danvers, MA 01923 for copying beyond that permitted by Sections
107 or 108 of the U.S. Copyright Law. This consent does not extend to other kinds
of copying such as copying for general distribution, for advertising or promotional
purposes, for creating new collective works, or for resale.
SAE routinely stocks printed papers for a period of three years following date of
publication. Direct your orders to SAE Customer Sales and Satisfaction
Department.
Quantity reprint rates can be obtained from the Customer Sales and Satisfaction
Department.

To request permission to reprint a technical paper or permission to use copyrighted

SAE publications in other works, contact the SAE Publications Group.

No part of this publication may by reproduced in any form, in an electronic retrieval

system or otherwise, without the prior written permission of the publisher.
ISSN 0148-7191
Copyright 1995 Society of Automotive Engineers, inc.
Positions and opinions advanced in this paper are those of the author(s) and not
necessarily those of SAE. The author is solely responsible for the content of the
paper. A process is available by which discussions will be printed with the paper if
it is published in SAE transactions. For permission to publish this paper in full or in
part, contact the SAE Publications Group.
Persons wishing to submit papers to be considered for presentation or publication
through SAE should send the manuscript or a 300 word abstract of a proposed
manuscript to: Secretary, Engineering Activity Board, SAE.
Printed in USA90-1203D/PG
 Downloaded from SAE International by University of New South Wales, Saturday, September 15, 2018

950291

Open Systems and Interfaces for Distributed

Electronics in Cars (OSEK)
U. Kiencke and K. J. Neumann H. Kuder and V. Wilhelmi
IIIT, University of Karlsruhe Mercedes-Benz AG

L. Frey, J. Graf, and T. Wollstadt H.-J. Mathony and D. Schäfer-Siebert

Adam Opel AG Robert Bosch AG

J. Krammer, W. Kremer, F. Lersch, and E. Schmidt R. John, M. Reinfrank, and K. Storjohann

AG
BMW Siemens AG

J. Minuth, T. Raith, and T. Thurner C. Hoffmann

Daimler-Benz AG Volkswagen AG

ABSTRACT
The individual development process for distributed,
communicating electronic control units hinders the
integration of Automotive systems and increases the
overall costs. In order to facilitate such applications,
services and protocols for Communication, Network
Management, and Operating System must be
standardized. The aim of the OSEK project is to
work out a respective specification proposal in co
operation with several car manufacturers and
suppliers. This will permit a cost-effective system
integration and support the portation of system
functions between different electronic control units. The project "Open Systems and Interfaces for
Electronics in Cars (OSEK)" thus aims to specify an
1. INTRODUCTION open architecture for communicating vehicle
In a distributed control system, several controllers systems [2]. This architecture comprises:
(stations) are connected via a communication link • Communication (Data exchange within and
(Fig. 1), e.g. electronic control units within an between Control Units);
automobile. Generally these control units are • Network Management (Configuration determi
supplied by different companies, and they have nation and monitoring); and
different microcontroller architectures. For the
connection of distributed system functions, stations • Realtime Executive (Operating system for
exchange messages with standardized interfaces. A Control Unit software).
uniform network management guarantees the safe
operation of safety-relevant, distributed systems [1]. With OSEK this expensive investment is only
needed once, and it is possible to re-use it with
The development costs for the communication and minor modifications for various applications.
network management software may be significantly
reduced, if the interfaces and procedures are Particular targets of OSEK are:
standardized not just within one subsystem, but for • company-independent specification of interfaces,
the entire distributed system. The software should be functions and protocols for Communication,
implemented in a uniform operating system. In Network Management and Realtime Executive;
addition, operating systems with uniform interfaces
offer different application programs available from • specification of a hardware- and software
various suppliers which co-exist in a single independent user interface, which enhances
processor. In that way, the multitasking approach portability and re-usability of application
serves as an efficient means to cut costs. programs;

71
 Downloaded from SAE International by University of New South Wales, Saturday, September 15, 2018

• efficient architectural adaption to respective electronic control units for production purposes.
applications by reconfiguration and scaling; and Today's extremely costly and error-prone stage
between prototypes and end products is thus
• functional verification and implementation of overcome.
prototypes in selected pilot projects.
It is not the aim of OSEK to engage into an
implementation of products. These should be left
open for e.g. software houses or microcontroller
manufacturers.

Another multi company project in the German

Automotive industry is MSR [3][4]. The aim here is
an enhanced development efficiency by an improved
information exchange between car manufacturers
and their suppliers, on the basis of a common
procedural model and - again - uniform interfaces
and tools. There are contacts between OSEK and
the MSR initiative. In the long run, OSEK could offer
the software implementation platform for functions
previously defined within the MSR framework.
When several different suppliers need to co-operate
to incorporate their individual subsystems into a
complete system, the MSR/OSEK approach is even
more beneficial (Fig. 3). Since the OSEK interface
can integrate end products together with prototypes,
different timescales or eventual time delays at one
supplier no longer impede vehicle tests of the
complete system at the car manufacturer.

The aim of an integrated development process is

shown in Fig. 2. A rough specification is supplied in a
commercial contract between a car manufacturer
and a supplier. This functional specification can be
recursively more detailed, until it contains any
specification requirement of the contracted
subsystem. The MSR framework allows for the
simulation of functions in advance, so that the
subsequent development work necessitates
significantly fewer modifications of target functions.
The final MSR specification is done on the basis of
the OSEK interface. From there, functional In this paper, the OSEK project is presented. An
prototypes can be built and tested in vehicles. The overview is given of the rough specifications for
suppliers use the same basis to develop their communication, network management and realtime
executive.

72
 Downloaded from SAE International by University of New South Wales, Saturday, September 15, 2018

2. OSEK COMMUNICATION • guarantees data consistency by organizing

(OSEK-KOM)
The OSEK sub project communication (OSEK-KOM)
specifies interfaces and protocols for in-vehicle
communications. This comprises communication:
• between interlinked control units;
• within control units; and
• between control units and peripherals.
The control-unit software is thus simplified and can
be re-used. The standardized interfaces keep the
application software independent of special network
protocols, such as CAN, ABUS, VAN, J1850, K-BUS,
P-BUS, l-Bus etc.). OSEK communication can be
provided for different protocols and microcontrollers.
As far as it is feasible in realtime systems, the
communication is defined according to the ISO/OSI
layer model [5], consisting of the safety layer, the
interaction layer and optional in-between transport
layer (Fig. 4). The physical layer below will be
integrated in the interface circuitry. It is therefore not
part of OSEK-KOM [6].
The safety layer provides services for the
transmission of single messages via the network
protocol used. The next link up is the optional
transport layer. It provides services for the
transmission of message packages of any length.
There is a differentiation into transmission without
acknowledge (1:n communication) and with
acknowledge (1:1 communication). The interaction
layer connects the interface to the application. Its
services are fully independent of microcontroller
architectures and network protocols. Service
processes of the interaction layer are concurrent to
application processes.
The interaction layer enables communication by:
• Variables for the transmission of system states,
such as engine speed, engine temperature; and
• Channels for the transmission of various events,
such as transgression of maximum engine
temperature.
Intertask communication by such means
• offers a well-defined communication interface;
• is based upon a uniform, previously developed
communication software;
simultaneous access to data from concurrent
processes; and
• supports portability of application software which
can be assigned to different control units as long
as time factors are not adversely affected.
2.1 Communication by Variables
The interaction layer contains a common data buffer
for variables from distributed application tasks. A
communication is accomplished, when one
transmitter actualizes a variable by write, and when
one or several receivers read that variable by read
(1:n communication, Fig. 5). The value of a variable
may be read many times. There is no time or
scheduling information in such variables.
The communicating tasks can be located in just one
station or in several stations. That is why there is a
distinction into station-global and network-global
variables, allowing different implementations.
Implementation of Network-global Variables
The variable x is stored in the transmitter station. A
copy x' of that variable is transferred to the receiver
stations. A write access from the transmitter locally
updates variable x. The interaction layer now takes
care, that the copies x' are also updated by a
message transmission. Subsequent read accesses
are again local operations.
Update of Copies of Variables
Network-global variables can be copied into
receiving stations in different ways:

73
 Downloaded from SAE International by University of New South Wales, Saturday, September 15, 2018

• event-driven: A write access triggers the

transmission of respective variable data
(transmission upon request); and
• time-controlled: Variable data are periodically
transmitted, independently of any changes of
their value. The time period is an attribute of the
variable.

An eventual combination would transfer variable data

either event-driven in case of changes, or time-
controlled at the end of a given time period.
Monitoring the Actuality of Variables
Any variable can be monitored by giving it a A fixed-capacity attribute is assigned to each
particular timeout. A variable is considered to be no channel, defining how many subsequent messages
longer actual, if its value has not changed during the can be stored in the channel. Messages go through
timeout period. the channel according to the FIFO principle. They
are received in the same sequence as they have
2.2 Communication by Channels been transmitted. In case of an overflow (capacity is
exceeded), the oldest message is deleted in order to
A channel is an object which comprises: prevent transmitters from blocking.
• a data structure for buffering messages;
Fig. 8 shows a 1:3 channel with a capacity of 2. Two
• a data structure for storing task identifications; messages can thus be stored in this channel. A list
and with 3 task identifiers is assigned to each of the
• operations send and receive. message buffers. Whilst reading, the receiving task
leaves its identifier at the buffer. A multiple reception
In a communication by channel, data (messages) of the same message can thus be prevented,
from one task are transferred to other tasks (1:n separately for all tasks. A message is considered to
communication). The execution is done through a be consumed, when all receiving tasks have
channel. The message will be stored into the performed their receive operation.
channel, if the receiver is not yet ready for the
communication. The operation send stores a
message into the channel, receive reads that
message from the channel and 'consumes' it, i.e.
rendering its data in the channel obsolete (empty
channel). The receive operation can only be
performed once by a task, unless there is a new
update.

Communication by channel implies the synchro
nization of the communication partners, i.e. the
sequencing of participant tasks over time. A
message can only be received if it has been
previously stored into the channel. Transmission is
however done asynchronously. There are two
reception modes, either asynchronous (non
blocking) or synchronous (blocking). In the
synchronous mode, the receive task is blocked until
a new message arrives in the channel (Fig. 7). In
order to prevent receivers from blocking
continuously, the ready state of the receiver is limited
by a timeout.
As in the case of variables, channels are defined as
station-global and network-global. A network-global
channel is implemented by a channel buffer y in the
transmitting station and channel buffers y' in the
receiving stations. The message transfer is
performed by the interaction layer.
3. OSEK NETWORK MANAGEMENT
(OSEK-NM)
The reliability and availability of the communication
link is guaranteed by an integrated network
management (OSEK-NM). Its essential services are:

74
 Downloaded from SAE International by University of New South Wales, Saturday, September 15, 2018
• defined and synchronized initialization of the
network communication, determination of the
configuration. Application tasks can only start
their operation, after all data transmitting stations
are fully operational.
• continuous configuration monitoring, detecting
the addition or the eventual failure of stations.
Changes in configuration are relayed to the
application layer, where a functional
reconfiguration must be decided (e.g. graceful
degradation).
• defined and synchronized transfer of the network
into the "sleep mode".
This configuration management makes up the core
services of OSEK-NM. Further optional services are:
• initialization of operating resources and of
objects defined by OSEK-KOM and OSEK-BS;
• control of operation modes;
• detection, management and messaging of
failures;
• diagnostic support, e.g. error statistics,
monitoring; and
• handling of network resources, e.g. temporary
channels.
The network management relies upon station-
address-oriented communication services which are
provided by OSEK-KOM.
Configuration Management
A station transmits a status message over the
network, when triggered by the previous station. By
definition of predecessors and successors, a
sequence develops, in which stations transmit their
status messages. A logical ring is thus installed,
where the status is forwarded from a station to its
successor within the given configuration /7,8/. The
additional traffic load on the network due to these
status messages is relatively low.
The configuration is defined as the set of all stations,
which are operational and accessible by
communication. A station is regarded ready by the
network management, first, when it transmits its
status message cyclically or is triggered by its
predecessor, and second, when it receives status
messages of the other stations.
The configurations are as follows:
• The Actual Configuration is the set of all
operational stations recorded by the network
75
management at a time t. This set may change,
e.g. differing among stations in case of failures,
or stations being switched on or off by the driver.
• The Reference Configuration is given by the
car manufacturer. It depends on the vehicle
equipment and options available. This reference
is used as a comparison to the actual
configuration, which allows to eventually start
operations of the application.
• The Sum of actual Configurations is the union
of all actual configurations observed since the
first start of the distributed system. It may serve
as a substitute for the reference configuration.
All configurations are accessible through the
application layer.
The state diagram of the network management
within a single station is shown in Fig. 9.
Start and Configuration Monitoring
With the Start, stations are initialized one at a time.
The duration of initialization depends mostly on the
specific application. This is one reason, why some
stations become operational sooner than others, and
why the actual configuration may change at a later
date.
Configuration management is done in parallel in all
stations without any master function. As a first step,
an eventually still stored previous actual configura
tion is reset to the reset configuration which consists
just of its own station. Immediately thereafter, a
status message is transmitted through the network,
by which the station makes itself known to all other
stations. Now OSEK-NM is transferred to the state
Operational. All status messages on the network
from other stations are then received, and the actual
configuration is derived from that. Without any
reception of status messages from other stations,
 Downloaded from SAE International by University of New South Wales, Saturday, September 15, 2018
the own station repeats its own status message after
a timeout. It follows, that a logical ring can always be
built up. With the reception of some other status
messages, available stations are inserted into a
logical ring according to their given addresses.
Status messages are triggered by a respective
message from the predecessor station, and are
directed to the successor station. Since all these
data are accessible to the application layer, the
availability of the reference configuration can be
easily checked.
In case that a station is no longer operational, it
reverts to the state Non-operational. From there, a
respectively adapted status message is cyclically
transmitted. A station failure can also be detected,
when its status message is no longer transmitted
within a given timeout. This is diagnosed in all other
stations, which then go back to the Reset state, and
determine the actual configuration from scratch.
Announcement of Stations
A new station is detected from its status message by
the other stations within the actual configuration. It is
incorporated into the logical ring.
Withdrawal of Stations
There is no defined specific procedure. A station just
discontinues the transmission of its own status
message.
Sleep Mode
The switch-down to sleep mode is initiated by one
station. The corresponding request is entered into its
status message, which is then transmitted from
station to station. If all stations in the logical ring
have acknowledged the request for sleep mode by
forwarding it, and when this information transfer has
completed a full loop, the entire network can be
switched down.
4. OSEK OPERATING SYSTEM
(OSEK-BS)
It will provide a uniform and efficient execution
environment for all Automotive Electronic Control
Units. Program Modules written e.g. in "C" language
will be readily exchanged.
There seems to be an inherent contradiction
between the targets for standardization and
efficiency. This is due to the commercial realtime
executives which burden applications with huge
overheads. They:
76
• offer users a variety of services, functions, of
which only a portion is incorporated into the
actual application;
• guarantee 100% portability of tasks; and
• may be dynamically reconfigured and scaled.
Such a complexity appears to be an overkill in high-
volume Automotive applications. OSEK-BS is
therefore deliberately restricted in its capabilities. To
overcome this, the basic targets are somewhat
similar to those of commercial realtime executives.
However, there are some significant differences.
OSEK-BS:
• is configured and scaled just statically. The
number of tasks, resources and services is
specified in advance by a user;
• also aims at the portability of tasks. There is
however no 100% portability;
• requires experienced users, since application
errors are not always backed up by extensive
routines; and
• operates from ROM code.
4.1 The OSEK-BS Concept
It is the basis for the independent development of
different application programs. Their execution in
realtime is controlled by events from the plant. The
control-unit hardware is accessible through uniform
interfaces. This enables the application software to
have a certain degree of independence from the
control-unit hardware.
Execution Layers
The overall application software is partitioned into
software portions, which are concurrently processed
according to their urgency in realtime. In order to
cover the large variety of realtime constraints,
OSEK-BS contains 4 different execution layers with
different priority levels (Fig. 10). These priority levels
determine the order of processing.
The Interrupt level holds the highest priority. It is
dedicated for time-critical activities, which are
characterized by short latency and execution times.
In order to match these constraints, the Interrupt
Service Routines (ISR) should not contain any data
processing. The interrupt response and acknow
ledge can be very fast, if the real processing of data
and other actions are shifted to the job level.
The next priority level is taken by the internal
operating-system functions, which are defined by
core and optional services.
 Downloaded from SAE International by University of New South Wales, Saturday, September 15, 2018

The essential elements of task management are the

scheduler and the dispatcher. In case of an event,
the scheduler decides according to priorities and to
realtime constraints, which one of the tasks is going
into the state running. During a task switch, the
dispatcher saves the context of the task running up
to that point, and installs the context of the next task.
At the Job level, programs cover complete functions
which are not interruptable (atomic) by other jobs or Two principle scheduling procedures can be defined:
tasks. Within a job, there can be no status waiting for • Full pre-emptive scheduling allows the
an event. Several attending jobs are sequentially displacement of running tasks, if a higher-
executed. Therefore jobs are a special kind of tasks. priority task becomes ready.
Typical jobs are:
• Non pre-emptive scheduling allows the
• Interrupt postprocessing; displacement of running tasks, only, if intended
• internal functions of the operating system such by the user or if terminated. This can only be
as timer manipulation, acceptance filtering of done in case of short execution times.
arriving messages; and
OSEK-BS also offers:
• execution of application routines reacting on
asynchronous events. • Mixed pre-emptive scheduling which combines
the two alternatives depending on the task.
Because of their atomic nature, such jobs increase Non pre-emptive tasks are useful when the
interrupt latency times. They are however still short execution time comes close to the duration of the
enough not to justify the installation of full tasks. task switch, if RAM space can be saved by not
Task Level and Task Management storing a task context, or if a task may not be
interrupted by another one. For a clean portability of
Tasks are organized by static priorities. They imply non preemptive application software into a full
full context switch and the saving of variables into a preemptive environment, the user must have
stack. There are 4 task states. designed in the interruptability principle beforehand.
running The processor is assigned to the task, Services of OSEK-BS:
the respective instructions are executed.
a) Core Services:
ready All preconditions for execution are met,
the task is waiting for access to the Task Management Management of task
processor. states, scheduling and
dispatching.
waiting At least one precondition for execution is
still lacking. • Interrupt Manage- Procedure for fast even
ment tually bufferd interrupt
passive The task is not part of the execution. handling
Fig. 11 shows the state diagram • Job Management Execution of short pro
gram files (jobs), without
context and without
interruption by other jobs
and tasks.

77
 Downloaded from SAE International by University of New South Wales, Saturday, September 15, 2018

• Event Control Management of events When this paper was filed for publication to the SAE
for task synchronization. in July 1994, a rough specification of OSEK had just
• Time Control Cyclical release of certain been completed. Currently a detailed specification is
tasks into the ready being worked out. It should be noted, that the OSEK
initiative is not restricted to a limited region of the
state, which are then world. All potential partners willing to be actively
activated.
involved in a fruitful OSEK co-operation are most
• Angle Control Optional version similar welcome onto the OSEK bandwagon.
to time control.
REFERENCES
b) Optional Services: /1/
Kiencke U., "Distributed Realtime Processing
• • Time Management Provision
time, services to calcu
absolute
of in Automotive Networks", SAE Technical Paper
No. 900696, 1990.
late relative times and to
exchange time units. /2/ Mathony H.-J., Kaiser K.-H., Unruh J., Raith T.,
Thurner T., "Open Systems and their
• • Angle Management Similar to time
control. Interfaces for the electronic in Cars - OSEK",
• • Error Management User sup ort in of
errors.
case 13. Tagung 'Elektronik im Kraft-fahrzeug im
Haus der Technik, Essen, 1993.
• Intertask Station-global variables /3/ Besel, K.-G., Hirth, T. "Design systems for the
Communication and channels. MSR-Project", (German-language), VDI-
Exclusive access to
Berichte Nr.: 1009, S. 503, 1992.
• Semaphore
Management atomic operations, com /4/ Leohold, J., "The MSR-Project: Tool support
monly used resources for new ways of cooperation between vehicle
and devices. manufacturer and supplier", (German-
language) VDI-Berichte Nr.: 1009, S. 491,
5.SCALING AND CONFIGURATION 1992.

The concepts and services of OSEK shall be applied /5/ ISO "Information Processing Systems - Open
to all stations of a distributed system, from the top- Systems Interconnection - Basic Reference
end to the bottom-end. They must support different Model", ISO 7498, 1984.
bus protocols such as CAN, ABUS, VAN, J1850, K
BUS, P-BUS, l-BUS etc. An adaption to the required /6/ Mathony H.-J., Kaiser K.-H., Unruh J.,
capabilities and the used resources is done by "Network Architecture for CAN", SAE Technical
scaling and configuring. Paper No. 930004, 1993.
The core services are mandatory basic functions. /7/ Raith T., Thurner T., Kocher H., "Netsoftware
They are part of any implementation. The optional for databus systems in vehicles", (German-
services are then used to extend the performance of language), VDI-Berichte Nr.: 819, S. 171,
OSEK for a specific application. The configuration is 1990.
done by static parameters. /8/ Kühner T., Häußler B., Thurner T., Müller K.
H., "Standardized netsoftware moduls for car
6.SUMMARY
ECU'S - realized on a CAN-System", (German-
The aims of the OSEK initiative are to specify language), VDI-Berichte Nr.: 1009, S. 653,
uniform services, interfaces and protocols for the 1992.
communication, network management and the
operating system of a distributed realtime system.
The cooperative effort of many car manufacturers
and suppliers is not just in order to achieve a
standardization. It guarantees, that practical
application issues are considered on a broad basis
within the OSEK specification, ensuring its
acceptance by development engineers in their daily
programs.

78