ISO 17356-1:2005

Road vehicles — Open interface for embedded automotive applications — Part 1: General structure and terms, definitions and abbreviated terms

ISO 17356-1:2005 outlines the general structure of, and defines terms and abbreviations used in relation to, the specification of the software open interface for embedded automotive applications given by the other parts of ISO 17356.

Véhicules routiers — Interface ouverte pour applications automobiles embarquées — Partie 1: Structure générale et termes, définitions et termes abrégés

General Information

• Status: Published
• Publication Date: 11-Jan-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
• Start Date: 20-Nov-2020
• Completion Date: 19-Apr-2025

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 17356-1
First edition
2005-01-15
Road vehicles — Open interface for
embedded automotive applications —
Part 1:
General structure and terms, definitions
and abbreviated terms
Véhicules routiers — Interface ouverte pour applications automobiles
embarquées —
Partie 1: Structure générale et termes, définitions et termes abrégés

Reference number
©
ISO 2005
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

Contents Page
Foreword. iv
1 Scope. 1
2 Terms, definitions and abbreviated terms. 1
3 Structure of ISO 17356. 17
Annex A (informative) History and rationale of OSEK/VDX . 19
Bibliography . 21

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-1 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 abbreviated 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)

iv © ISO 2005 – All rights reserved

INTERNATIONAL STANDARD ISO 17356-1:2005(E)

Road vehicles — Open interface for embedded automotive
applications —
Part 1:
General structure and terms, definitions and abbreviated terms
1 Scope
This part of ISO 17356 outlines the general structure of, and defines terms and abbreviations used in relation
to, the specification of the software open interface for embedded automotive applications given by the other
parts of ISO 17356.
2 Terms, definitions and abbreviated terms
For the purposes of this document, the following terms, definitions and abbreviated terms apply.
2.1
acceptance filtering
mechanism which decides whether each received protocol frame is to be taken into account by the local node
or ignored
2.2
activate
action of changing a task from the suspended to the ready state
NOTE The transition is achieved by a system service.
2.3
actual configuration
set of all operable nodes to which communication access is possible
NOTE See operability of a node (2.81).
2.4
address-related communication
type of communication between nodes using node addresses where each address-related communication
message contains certain data and — either explicitly or implicitly — the node address of the transmitter and
the receiver
NOTE 1 See node addressing (2.76).
NOTE 2 The communication of the network management is based completely on address-related communication.
2.5
alarm
association between a counter and a task, event or callback such that the task, event or callback occurs when
a particular counter value is reached
NOTE 1 The expiry value can be defined relative to the current counter value or can be an absolute value.
NOTE 2 Alarms can be defined to be either single-shot or cyclic.
NOTE 3 An alarm is statically assigned at system generation time to one counter and a task, event or alarm callback
routine.
2.6
alarm callback
short function, provided by the application, called when an alarm expires but before any task is activated or
event set
2.7
alarm management
manipulation of an alarm’s running/cancelled state, and the counter value at which it next expires
NOTE Alarm management is based on the counter concept. Alarms are a way of linking alarm callbacks, task
activation or event setting to counter values.
2.8
alive message
message used to announce an initialized and operable node for integration in the actual configuration
NOTE 1 See operability of a node (2.81).
NOTE 2 A dedicated NM message is used for this purpose.
2.9
application program interface
API
description of the application's interface to the operating system, communications and network management
functions
2.10
application error
error where the operating system cannot execute the requested service correctly, but assumes the
correctness of its internal data, and calls centralized error treatment
2.11
arbitration
mechanism that guarantees that a simultaneous access made by multiple stations results in contention where
one frame will survive uncorrupted
2.12
basic conformance class
BCC
conformance class of the operating system in which only basic tasks are permitted
NOTE Two basic conformance classes are distinguished: BCC1 and BCC2.
2.13
basic task
BT
task that can only release the processor when it terminates, when the operating system executes a
higher-priority task or when an interrupt occurs
NOTE 1 A basic task can only enter the task states suspended, ready and running.
NOTE 2 It is not possible for a basic task to wait for an event.
2.14
broadcast
case of multicast whereby a single message is addressed to all nodes simultaneously
2.15
busOff
condition of switching off from the bus so that protocol frames can neither be sent nor received
2 © ISO 2005 – All rights reserved

2.16
callout
general mechanism, based upon function calls, allowing the behaviour of the interaction layer to be
customized and enhanced
NOTE 1 Callouts are configured statically, are invoked in response to the passage of a message or I-PDU and cannot
be changed at run-time.
NOTE 2 The prototype for a callout allows it to return a value that determines further treatment by the IL of the
message or I-PDU.
2.17
controller area network
CAN
protocol originally defined for use as a communication network for control application in vehicles
2.18
certification
process of determining whether an implementation is consistent with a given reference model
NOTE The scope of the reference model has to be settled according to the objectives of the project and all
constraints necessary to fulfil those objectives incorporated in the reference model.
2.19
COM-callback
short function, provided by the application, which can be called by the interaction layer as a notification
mechanism (class 1)
NOTE No parameters are passed to a COM-callback routine and it does not have a return value. A COM-callback
routine runs either on interrupt level or on task level.
2.20
communication layer
set of all entities and elements which constitute a communication layer based on the ISO/OSI reference model
NOTE For the basic model, see ISO 7498-1.
2.21
configurability
ability to set the parameters of a system in terms of static values
EXAMPLE Number of tasks, RAM size for stack, size of message buffer.
2.22
confirmation
service primitive via which a service provider informs a service user about the result of a preceding service
request
NOTE The confirmation service primitive is defined by the ISO/OSI reference model (ISO 7498).
2.23
conformance class
CC
subset of services chosen by the application
NOTE 1 In each module (operating system, communication, network management), a pool of services is provided, with
each of these being divided into a number of defined subsets. Applications can choose to use a particular subset of the
services in order to reduce demands on the CPU and memory.
NOTE 2 The subsets are upwardly compatible and are described as conformance classes.
2.24
connection
logical communication channel between a transmitter and a receiver
NOTE A message is sent by exactly one transmitter and is received by exactly one receiver.
2.25
constructional element
definition and declaration services for system objects
2.26
counter
system object that registers recurring events such as time or angle
NOTE A counter is represented by a count and some counter-specific constants.
2.27
critical section
sequence of instructions where mutual exclusion is ensured
NOTE Such a section is called “critical” because shared data is modified within it.
2.28
data consistency
content of a given message correlating unambiguously to the operation performed on the message by the
application such that no unforeseen sequence of operations may alter the content and thereby render it
inconsistent with respect to its allowed and expected value
2.29
data link layer
communication layer, consisting of the communication hardware and the communication driver software, that
provides services for the transfer of I-PDUs
2.30
deadlock
tasks that block one another so that further processing of the tasks concerned is no longer possible
EXAMPLE Each of two tasks waits for the reception of a message to be sent by the other task before sending its
own message.
2.31
direct node monitoring
active monitoring of a node by another node in the network
NOTE For this purpose, the monitored node sends an NM message according to a dedicated and uniform algorithm.
For the network-wide synchronization of NM messages, a logical ring is used.
2.32
deadline monitoring
informing of the application via the notification mechanism that a message has not been received from
another node within a specified interval, or if a request to send an I-PDU has not been completed by the DLL
within a specified interval
2.33
error handling
error service provided to handle errors detected by the operating system
NOTE The basic framework is predefined and has to be completed by the user, thus giving the user a choice of
efficient centralized or decentralized error handling.
4 © ISO 2005 – All rights reserved

2.34
error hook
routine (ErrorHook) called when a system service returns a StatusType value not equal to E_OK or when an
error is detected during task activation or event setting
2.35
event
method of task synchronization peculiar to extended task whereby a task may suspend its execution without
terminating
NOTE The task suspends its execution by waiting for an event and continues when an appropriate event is set. Basic
tasks cannot use events.
2.36
event mechanism
means of task synchronization using events
2.37
extended conformance class
ECC
conformance class of the operating system in which basic and extended tasks are permitted
NOTE Two extended conformance classes are distinguished: ECC1 and ECC2.
2.38
extended task
ET
task that is allowed to use additional operating system services, which may result in a waiting state
NOTE An extended task can enter the task state suspended, ready, running or waiting.
2.39
fatal error
error where the operating system can no longer assume correctness of its internal data
NOTE In this case, the operating system calls the centralized system shutdown.
2.40
frame
data unit determined according to the data link protocol specifying the arrangement and meaning of bits or bit
fields in the data transferred across the transfer medium
2.41
full pre-emptive scheduling
scheduling where a task which is presently running may be pre-empted at any instru
...