ISO 17356-3:2005

Road vehicles — Open interface for embedded automotive applications — Part 3: OSEK/VDX Operating System (OS)

ISO 17356-3:2005 describes the concept of a real-time operating system, capable of multitasking, which can be used for motor vehicles. It is not a product description which relates to a specific implementation. It also specifies the operating system Application Program Interface (API). General conventions, explanations of terms and abbreviations have been compiled in ISO 17356-1. ISO 17356-6 discusses implementation and system generation aspects. The specification of the OS represents a uniform environment which supports efficient utilisation of resources for automotive control unit application software. The OS is a single processor operating system meant for distributed embedded control units.

Véhicules routiers — Interface ouverte pour applications automobiles embarquées — Partie 3: Système d'exploitation OSEK/VDX

General Information

• Status: Published
• Publication Date: 02-Nov-2005
• ICS: 43.040.15 - Car informatics. On board computer systems
• Technical Committee: ISO/TC 22/SC 31 - Data communication
• Drafting Committee: ISO/TC 22/SC 31/WG 5 - Test equipment/Data eXchange Formats
• Current Stage: 9093 - International Standard confirmed
• Completion Date: 20-Nov-2020

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 17356-3
First edition
2005-11-01

Road vehicles — Open interface for
embedded automotive applications —
Part 3:
OSEK/VDX Operating System (OS)
Véhicules routiers — Interface ouverte pour applications automobiles
embarquées —
Partie 3: Système d'exploitation OSEK/VDX




Reference number
ISO 17356-3:2005(E)
©
ISO 2005

---------------------- Page: 1 ----------------------
ISO 17356-3:2005(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


©  ISO 2005
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland

ii © ISO 2005 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 17356-3:2005(E)
Contents Page
Foreword. v
Introduction . vi
1 Scope .1
2 Normative references .1
3 Architecture of the operating system “OS” .1
3.1 Processing levels.1
3.2 Conformance classes.3
3.3 Relationship between OS and OSEKtime OS .4
4 Task management.5
4.1 Task concept.5
4.2 Task state model.5
4.3 Activating a task .8
4.4 Task switching mechanism .8
4.5 Task priority .8
4.6 Scheduling policy .9
4.7 Termination of tasks.12
5 Application modes.12
5.1 General.12
5.2 Scope of application modes .12
5.3 Start-up performance .13
5.4 Support for application modes.13
6 Interrupt processing.13
6.1 General.13
7 Event mechanism .14
8 Resource management .16
8.1 General.16
8.2 Behaviour during access to occupied resources .16
8.3 Restrictions when using resources.17
8.4 Scheduler as a resource .17
8.5 General problems with synchronization mechanisms .17
8.6 Priority Ceiling Protocol.18
8.7 Priority Ceiling Protocol with extensions for interrupt levels.19
8.8 Internal resources.21
9 Alarms.22
9.1 General.22
9.2 Counters .22
9.3 Alarm management.22
9.4 Alarm-callback routines .23
10 Messages.24
11 Error handling, tracing and debugging .24
11.1 Hook routines.24
11.2 Error handling .25
11.3 System start-up.26
11.4 System shutdown .28
11.5 Debugging .28
12 Description of system services.29
© ISO 2005 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 17356-3:2005(E)
12.1 Definition of system objects . 29
12.2 Conventions. 29
13 Specification of OS services. 31
13.1 Basics. 31
13.2 Common data types. 32
13.3 Task management. 33
13.4 Interrupt handling . 38
13.5 Resource management. 41
13.6 Event control . 43
13.7 Alarms . 46
13.8 OS execution control . 50
13.9 Hook routines . 51
14 Implementation- and application-specific topics. 54
14.1 General . 54
14.2 Implementation hints . 54
14.3 Application design hints . 56
14.4 Implementation-specific tools . 60
iv © ISO 2005 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 17356-3:2005(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 17356-3 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
ISO 17356 consists of the following parts, under the general title Road vehicles — Open interface for
embedded automotive applications:
⎯ Part 1: General structure and terms, definitions and abbreviations terms
⎯ Part 2: OSEK/VDX specifications for binding OS, COM and NM
⎯ Part 3: OSEK/VDX Operating System (OS)
⎯ Part 4: OSEK/VDX Communication (COM)
⎯ Part 5: OSEK/VDX Network Management (NM)
⎯ Part 6: OSEK/VDX Implementation Language (OIL)
© ISO 2005 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO 17356-3:2005(E)
Introduction
0.1 System philosophy
Automotive applications are characterized by stringent real-time requirements. Therefore, the operating
system (OS) offers the necessary functionality to support event-driven control systems.
The specified OS services constitute a basis to enable the integration of software modules made by various
manufacturers. To be able to react to the specific features of the individual control units as determined by their
performance and the requirements of a minimum consumption of resources, the prime focus was not to
achieve 100 % compatibility between the application modules, but their direct portability.
As the OS is intended for use in any type of control units, it supports time-critical applications on a wide range
of hardware. A high degree of modularity and ability for flexible configuration are prerequisites to making the
OS suitable for low-end microprocessors and complex control units alike. These requirements have been
supported by definition of “conformance classes” (see 3.2) and a certain capability for application specific
adaptations.
For time-critical applications, dynamic generation of system objects was left out. Instead, generation of system
objects was assigned to the system generation phase. Error inquiries within the operating system are obviated
to a large extent, so as not to affect the speed of the overall system unnecessarily. On the other hand, a
system version with extended error inquiries has been defined. It is intended for the test phase and for less
time-critical applications. Even at that stage, defined uniform system appearance is ensured.
0.1.1 Standardized interfaces
The interface between the application software and the OS is defined by system services. The interface is
identical for all implementations of the OS on various processor families.
System services are specified in an ISO/ANSI-C-like syntax, however the implementation language of the
system services is not specified.
0.1.2 Scalability
Different conformance classes, various scheduling mechanisms and the configuration features make the OS
feasible for a broad spectrum of applications and hardware.
The OS is designed to require only a minimum of hardware resources (RAM, ROM, CPU time) and therefore
runs even on 8-bit microcontrollers.
0.1.3 Error checking
The OS offers two levels of error checking, extended status for development phase and standard status for
production phase.
The extended status allows for enhanced plausibility checks on calling OS services. Due to the additional
error checking, it requires more execution time and memory space than the standard version. However, many
errors can be found in a test phase. After all errors have been eliminated, the system can be recompiled with
the standard version.
vi © ISO 2005 – All rights reserved

---------------------- Page: 6 ----------------------
ISO 17356-3:2005(E)
0.1.4 Portability of application software
One of the goals of ISO 17356 is to support the portability and re-usability of application software. Therefore,
the interface between the application software and the OS is defined by standardized system services with
well-defined functionality. Use of standardized system services reduces the effort to maintain and to port
application software and development cost.
Portability means the ability to transfer an application software module from one ECU to another without
bigger changes inside the application. The standardized interface (service calls, type definitions and
constants) to the operating system supports the portability on source code level. Exchange of object code is
not addressed by ISO 17356.
The application software lies on the operating system and in parallel on an application-specific Input/Output
System interface which is not standardized in ISO 17356. The application software module can have several
interfaces. There are interfaces to the OS for real-time control and resource management, but also interfaces
to other software modules to represent a complete functionality in a system, and at least to the hardware, if
the application works directly with microcontroller modules.

1)
Figure 1 — Software interfaces inside ECU
During the process to port application software from one ECU to another, it is necessary to consider
characteristics of the software development process, the development environment and the hardware
architecture of the ECU, for example:
⎯ software development guidelines;
⎯ file management system;
⎯ data allocation and stack usage of the compiler;
⎯ memory architecture of the ECU;
⎯ timing behaviour of the ECU;
⎯ different microcontroller specific interfaces e.g. ports, A/D converter, serial communication and watchdog
timer; and
⎯ placement of the API calls.

1) OSEK OS allows direct interfacing between application and the hardware.
© ISO 2005 – All rights reserved vii

---------------------- Page: 7 ----------------------
ISO 17356-3:2005(E)
This means that the specifications are not enough to describe an implementation completely. The
implementation supplies specific documentation.
0.1.5 Support of portability
The certification process ensures the conformance of different implementations to the specification. Clause 14
of this International Standard collects implementation specific details which should be regarded to increase
portability of an application between various implementations. Herein, only the OS interface to the application
is considered.
0.1.6 Special support for automotive requirements
Specific requirements for the OS arise in the application context of software development for automotive
control units. The following features address requirements such as reliability, real-time capability and cost
sensitivity:
⎯ The OS is configured and scaled statically. The user statically specifies the number of tasks, resources
and services required.
⎯ The specification of the OS supports implementations capable of running on ROM, i.e. the code could be
executed from Read-Only-Memory.
⎯ The OS supports portability of application tasks.
⎯ The specification of the OS provides a predictable and documented behaviour to enable OS
implementations, which meet automotive real-time requirements.
⎯ The specification of the OS allows the implementation of predictable performance parameters.
0.2 Purpose of this document
The following description is to be regarded as a generic description which is mandatory for any
implementation of the OS. This concerns the general description of strategy and functionality, the interface of
the calls, the meaning and declaration of the parameters and the possible error codes.
This part of ISO 17356 leaves a certain amount of flexibility. On the one hand, the description is generic
enough for future upgrades; on the other hand, part of the description is explicitly specified and
implementation-specific.
Any implementation defines all implementation-specific issues. The conformance classes supported by the
implementation are indicated precisely, and the issues identified as implementation-specific are documented.
Because this description is mandatory, definitions have only been made where the general system strategy is
concerned. In all other respects, it is up to the system implementation to determine the optimal adaptation to a
specific hardware type.
0.3 Structure of this document
0.3.1 General
In the following text, the clauses of this International Standard are described briefly:
0.3.2 Clause 3 — Architecture of the operating system “OS”
This clause gives a survey about the design principles and the architecture of the operating system.
viii © ISO 2005 – All rights reserved

---------------------- Page: 8 ----------------------
ISO 17356-3:2005(E)
0.3.3 Clause 4 — Task management
This clause explains task management with the different task types and scheduling mechanisms.
0.3.4 Clause 5 — Application modes
This clause describes application modes and how they are supported.
0.3.5 Clause 6 — Interrupt processing
This clause provides information about the interrupt strategy and the different types of interrupt service
routines.
0.3.6 Clause 7 — Event mechanism
This clause explains the event mechanism and the different behaviour depending on the scheduling.
0.3.7 Clause 8 — Resource management
This clause describes the resource management and discusses the benefits and implementation of the priority
ceiling protocol.
0.3.8 Clause 9 — Alarms
This clause describes the two-stage concept to support time-based events (e.g. hardware-timer) as well as
non-time-based events (e.g. angle measurement).
0.3.9 Clause 10 — Messages
The message handling for intra-processor communication is added to ISO 17356-3. Full message handling is
described in ISO 17356-4. The exact subset to be implemented is described in ISO 17356-4.
0.3.10 Clause 11 — Error handling, tracing and debugging
This clause describes the mechanisms to achieve centralized error handling. It also describes the services to
initialize and shut down the system.
0.3.11 Clause 12 — Description of system services
This clause describes the conventions used for description.
0.3.12 Clause 13 — Specification of operating system services
This clause describes all operating system services made available to the user. Structure of the description is
identical for any service; it contains all the information the service user requires.
0.3.13 Clause 14 — Implementation and application-specific topics
This clause provides a list of all operating system-specific topics, including services, data types, and
constants.
© ISO 2005 – All rights reserved ix

---------------------- Page: 9 ----------------------
ISO 17356-3:2005(E)
0.4 Summary
0.4.1 General
The OS provides a pool of different services and processing mechanisms. It is built according to the user’s
configuration instructions at system generation time.
Four conformance classes are described, meant to satisfy different requirements concerning functionality and
capability of the OS. Thus, the user can adapt the OS to the control task and the target hardware. It is not
possible to modify the OS later at execution time.
Applications which have been written for a certain conformance class are portable to implementations of the
same class. This is ensured by a definition of the services, their scope of capabilities, and the behaviour of
each conformance class. Only if all the services of a conformance class are offered with the determined scope
of capabilities does the OS implementation conform to ISO 17356-3. The service groups are structured in
terms of functionality.
0.4.2 Task management
Task management includes:
⎯ activation and termination of tasks; and
⎯ management of task states and task switching.
0.4.3 Synchronization
The OS supports the following means of synchronization effective on tasks:
⎯ resource management;
⎯ access control for inseparable operations to jointly used (logic) resources or devices, or for control of a
program flow;
⎯ event control; and
⎯ event management for task synchronization.
0.4.4 Interrupt management
This includes services for interrupt processing.
0.4.5 Alarms
Alarms can be either relative or absolute.
0.4.6 Intra-processor message handling
This includes services for exchange of data.
0.4.7 Error treatment
This includes mechanisms supporting the user in case of various errors.

x © ISO 2005 – All rights reserved

---------------------- Page: 10 ----------------------
INTERNATIONAL STANDARD ISO 17356-3:2005(E)

Road vehicles — Open interface for embedded automotive
applications —
Part 3:
OSEK/VDX Operating System (OS)
1 Scope
OSEK/VDX is a joint project of the automotive industry. It aims at an industry standard for an open-ended
architecture for distributed control units in vehicles.
This part of ISO 17356 describes the concept of a real-time operating system, capable of multitasking, which
can be used for motor vehicles. It is not a product description which relates to a specific implementation. It
also specifies the operating system Application Program Interface (API).
General conventions, explanations of terms and abbreviations have been compiled in ISO 17356-1.
ISO 17356-6 describes implementation and system generation aspects.
The specification of the OS represents a uniform environment which supports efficient utilization of resources
for automotive control unit application software. The OS is a single processor operating system meant for
distributed embedded control units.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 17356-1, Road vehicles — Open interface for embedded automotive applications — Part 1: General
structure and terms, definitions and abbreviations terms
ISO 17356-2, Road vehicles — Open interface for embedded automotive applications — Part 2: OSEK/VDX
specifications for binding OS, COM and NM
ISO 17356-6, Road vehicles — Open interface for embedded electronic equipment — Part 6: OSEK/VDX
Implementation Language (OIL)
3 Architecture of the operating system “OS”
3.1 Processing levels
The OS serves as a basis for application programs which are independent of each other, and provides their
environment on a processor. The OS enables a controlled real-time execution of several processes which
appear to run in parallel.
© ISO 2005 – All rights reserved 1

---------------------- Page: 11 ----------------------
ISO 17356-3:2005(E)
The OS provides a defined set of interfaces for the user. These interfaces are used by entities which are
competing for the CPU. There are two types of entities:
⎯ interrupt service routines managed by the operating system; and
⎯ tasks (basic tasks and extended tasks).
The hardware resources of a control unit can be managed by OS services. These OS services are called by a
unique interface, either by the application program or internally within the OS.
The OS defines three processing levels:
⎯ interrupt level;
⎯ logical level for scheduler; and
⎯ task level.
Within the task level, tasks are scheduled (non, full or mixed preemptive scheduling) according to their user
assigned priority. The run time context is occupied at the beginning of execution time and is released again
once the task is finished.

Figure 2 — Processing levels of the operating system
The following priority rules have been established:
⎯ Interrupts have precedence over tasks.
⎯ The interrupt processing level consists of one or more interrupt priority levels.
⎯ Interrupt service routines have a statically assigned interrupt priority level.
2 © ISO 2005 – All rights reserved

---------------------- Page: 12 ----------------------
ISO 17356-3:2005(E)
⎯ Assignment of interrupt service routines to interrupt priority levels is dependent on implementation and
hardware architecture.
⎯ For task priorities and resource ceiling-priorities bigger numbers refer to higher priorities.
⎯ The task’s priority is statically assigned by the user. (The meaning of task priorities is described in 4.5.)
Processing levels are defined for the handling of tasks and interrupt routines as a range of consecutive
values. Mapping of operating system priorities to hardware priorities is implementation-specific.
NOTE Assignment of a priority to the scheduler is only a logical concept which can be implemented without directly
using priorities. Additionally, it does not prescribe any rules concerning the relation of task priorities and hardware interrupt
levels of a specific microprocessor architecture.
3.2 Conformance classes
Various requirements of the application software for the system and various capabilities of a specific system
(e.g. processor, memory) demand different features of the OS. In the following description, these OS features
are described as “conformance classes” (CC)
...