Road vehicles — Open interface for embedded automotive applications — Part 5: OSEK/VDX Network Management (NM)

ISO 17356-5:2006 defines a set of services for node monitoring (NM). NM consists of the following: interface to interact with the Application Programming Interface(API); algorithm for node monitoring; internal interfaces (NM COM, etc.); algorithm for transition into sleep mode; and NM protocol data unit (NMPDU).

Véhicules routiers — Interface ouverte pour applications automobiles embarquées — Partie 5: Gestion du réseau OSEK/VDX (NM)

General Information

Status
Published
Publication Date
18-Jan-2006
Current Stage
9093 - International Standard confirmed
Completion Date
20-Nov-2020
Ref Project

Relations

Effective Date
06-Jun-2022

Buy Standard

Standard
ISO 17356-5:2006 - Road vehicles -- Open interface for embedded automotive applications
English language
117 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 17356-5
First edition
2006-02-01

Road vehicles — Open interface for
embedded automotive applications —
Part 5:
OSEK/VDX Network Management (NM)
Véhicules routiers — Interface ouverte pour applications automobiles
embarquées —
Partie 5: Gestion du réseau OSEK/VDX (NM)




Reference number
ISO 17356-5:2006(E)
©
ISO 2006

---------------------- Page: 1 ----------------------
ISO 17356-5:2006(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 2006
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 copyright@iso.org
Web www.iso.org
Published in Switzerland

ii © ISO 2006 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 17356-5:2006(E)
Contents Page
Foreword. iv
0 Introduction . v
0.1 General. v
0.2 System status. v
0.3 Remarks by the authors. v
0.4 Summary. vi
1 Scope . 1
1.1 Embedding of the Network Management (NM) . 1
1.2 Adaptation to bus protocol specific requirements . 1
1.3 Adaptation to node resources. 1
1.4 Adaptation to hardware-specific requirements . 1
1.5 Station management (system-specific algorithms) . 2
1.6 Philosophy of node monitoring. 2
2 Direct Network Management . 3
2.1 Concept. 3
2.2 Algorithms and behaviour . 11
3 Indirect Network Management. 54
3.1 General. 54
3.2 Concept. 54
3.3 Algorithms and behaviour . 60
4 System generation and API . 75
4.1 Overview . 75
4.2 Conventions for service description . 77
4.3 General data types. 79
4.4 Common services. 79
4.5 Services for direct NM. 89
4.6 Services for indirect NM. 92
5 Impacts upon OS, COM and the data link layer. 93
5.1 Error codes. 93
5.2 Common impacts. 93
5.3 Impacts from direct NM. 97
5.4 Impacts from indirect NM. 98
Annex A (informative) Implementation proposal (direct NM) . 101
Index. 117

© ISO 2006 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 17356-5:2006(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-5 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 2006 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 17356-5:2006(E)
0 Introduction
0.1 General
There is an increasing tendency for electronic control units (ECUs) made by different manufacturers to be
networked within vehicles by serial data communication links.
Therefore, standardization of basic and non-competitive infrastructure in ECUs aims at avoiding the design of
unnecessary variants and saving development time.
In the scope of OSEK/VDX cooperation, the Network Management system (NM) provides standardized
features which ensure the functionality of inter-networking by standardized interfaces.
The essential task of NM is to ensure the safety and the reliability of a communication network for ECUs.
In a vehicle, a networked ECU is expected to provide certain features:
⎯ each node accessible for authorized entities;
⎯ maximum tolerance with regard to temporary failures; and
⎯ support of network-related diagnostic features.
At a basic configuration stage, NM implementations complying with OSEK specifications are implemented in
all networked nodes. This implies a solution for NM which can be implemented throughout the broad range of
available hardware offered in today’s ECUs.
Therefore, the status of the network is recorded and evaluated uniformly at all ECUs at intervals. Thus, each
node features a determined behaviour as regards the network and the application concerned.
NM offers two alternative mechanisms for network monitoring:
⎯ indirect monitoring by monitored application messages; and
⎯ direct monitoring by dedicated NM communication using token principle.
However, the use of these mechanisms is up to the system responsible. Processing of information collected
by these mechanisms is in accordance with requirements as regards to the entire networked system.
0.2 System status
In view of the application, NM comprises two standardized interfaces:
⎯ Software: Application program <-> NM
⎯ Network behaviour: Station <-> Communication medium
The resulting entire system is open. Thus, it can adapt to new requirements within the restrictions defined by
the system design.
0.3 Remarks by the authors
This part of ISO 17356 describes the concept and the API of a Network Management, which can be used for
ECUs in vehicles. It is not a product description which relates to a specific implementation.
General conventions, explanations of terms and abbreviations have been compiled in ISO 17356-1.
© ISO 2006 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO 17356-5:2006(E)
0.4 Summary
In order to achieve the essential task of a network monitoring, i.e. ensure safety and reliability of a
communication network for ECUs, NM describes node-related (local) and network-related (global)
management methods. The global NM component is optional. However, it requires a minimum local
component to be operational.
Therefore, the following services are provided:
⎯ initialization of ECU resources, e.g. network interface;
⎯ start-up of network;
⎯ providing network configuration;
⎯ management of different mechanisms for node monitoring;
⎯ detecting, processing and signalling of operating states for network and node;
⎯ reading and setting of network- and node-specific parameters;
⎯ coordination of global operation modes (e.g. network wide sleep mode); and
⎯ support of diagnosis.
There are two main parts within the document: Direct Network Management described in Clause 2 and
Indirect Network Management described in Clause 3. Both clauses describe the concepts, algorithms and
behaviour.
Subclause 2.1, Concept, describes the fundamental aspects of the configuration management, the operating
states and operating state management.
Subclause 3.3, Algorithms and behaviour, describes the protocol used for communication between nodes.
Clause 4 describes the API (Application Programming Interface) comprising the pure specification of the
services offered for both direct and indirect NM. Input and output data, the functional description,
particularities, etc. are described for each service. Furthermore, System generation services are described
within this clause.
Clause 5 describes the impacts on the infrastructure of ISO 17356 and gives a brief description of all
requirements for COM, OS and the data link layer for both direct and indirect NM.

vi © ISO 2006 – All rights reserved

---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO 17356-5:2006(E)

Road vehicles — Open interface for embedded automotive
applications —
Part 5:
OSEK/VDX Network Management (NM)
1 Scope
1.1 Embedding of the Network Management (NM)
NM defines a set of services for node monitoring. Figure 1 shows how the NM is embedded into a system and
that the NM shall be adapted to specific requirements of the bus system used or to the resources of the nodes.
NM consists of the following:
⎯ interface to interact with the Application Programming Interface(API);
⎯ algorithm for node monitoring;
⎯ internal interfaces (NM <-> COM, etc.);
⎯ algorithm for transition into sleep mode; and
⎯ NM protocol data unit (NMPDU).
1.2 Adaptation to bus protocol specific requirements
Adaptation to bus protocol specific requirements consists of the following:
⎯ CAN, VAN, J1850, K-BUS, D2B, etc.;
⎯ error handling, e.g. bus-off handling in a CAN, transmission line error handling; and
⎯ interpretation of the status information, e.g. overrun or error active/passive in a CAN.
1.3 Adaptation to node resources
Adaptation to node resources consists of the following:
⎯ scaling of the NM as a requirement of the node; and
⎯ application-specific usage of the NM services.
1.4 Adaptation to hardware-specific requirements
This consists of adaptation to a protocol circuit and a physical layer circuit, e.g. switching the bus hardware to
one of the possible physically power save modes.
© ISO 2006 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO 17356-5:2006(E)
1.5 Station management (system-specific algorithms)
There are a variety of additional tasks involved in coordinating a network. These are not described in
ISO 17356, since they are system-dependent. Hence, these tasks are done by the application, e.g. by a
module called station management.
1.6 Philosophy of node monitoring
Node monitoring is used to inform the application about the nodes on the network. Thus, the application can
check with the appropriate service if all stations required for operation are present on the network.

Key
1 API
2 several buses connected to one µController
3 interface to DLL, COM-specific, protocol-specific
4 interface to COM Interaction Layer
5 station management (outside the scope of ISO 17356)
6 algorithms
7 protocol-specific management algorithms
Figure 1 — Responsibility of interface and algorithms
2 © ISO 2006 – All rights reserved

---------------------- Page: 8 ----------------------
ISO 17356-5:2006(E)
2 Direct Network Management
2.1 Concept
2.1.1 Node monitoring
2.1.1.1 General
NM supports the direct node monitoring by dedicated NM communication. A node is a logical whole to which a
communication access is possible. A microprocessor with two communication modules connected to two
different communication media (e.g. low speed CAN and a high-speed CAN) represents two nodes from the
NM point of view.
The rate of the NM communication is controlled across the network (minimization of bus load and
consumption of resources) and the messages are synchronized (avoiding negative effects on application data
by message bursts).
Every node is actively monitored by every other node in the network. For this purpose, the monitored node
sends an NM message according to a dedicated and uniform algorithm.
Direct node monitoring requires a network-wide synchronization of NM messages. For this purpose, a logical
ring is used.
2.1.1.2 Logical ring
2.1.1.2.1 General
In a logical ring, the communication sequence is defined independently from the network structure. Therefore,
each node is assigned a logical successor. The logically first node is the successor of the logically last node in
the ring.
Thus, the decentralized control of the overall amount of NM messages is ensured and the bus load due to
these messages is determined. The communication sequence of the logical ring synchronizes NM
communication. Any node shall be able to send NM messages to all other nodes and receive messages from
them.

Key
1 node
2 Electronic Communication Unit (ECU)
3 communication media 1
4 communication media 2
Figure 2 — Infrastructure of the NM (logical ring), example with two buses
© ISO 2006 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO 17356-5:2006(E)
2.1.1.2.2 Principle
The direct NM transmits and receives two types of messages to build the logical ring. An alive message
introduces a new transmitter to the logical ring. A ring message is responsible for the synchronized running of
the logical ring. It will be passed from one node to another (successor) node.
⎯ Receive alive message: Interpretation as transmitter-related registration to the logical ring.
⎯ Receive ring message: Interpretation as transmitter-specific alive signal and synchronization to initiate
transmission of own NM message according to the logical ring algorithm.
⎯ Time-out on ring message: Interpretation as transmitter-specific breakdown.
2.1.1.2.3 State of a node
A monitoring node is able to distinguish two states of a monitored node:
⎯ node present Æ specific NM message received (alive or ring);
⎯ node absent Æ specific NM message not received during time-out.
A monitoring node is able to distinguish two states of itself:
⎯ present or not mute Æ specific NM message transmitted (alive or ring);
⎯ absent or mute Æ specific NM message not transmitted during time-out.
2.1.2 Addressing
2.1.2.1 Status
The status of nodes and of the network shall be acquired and evaluated uniformly at intervals. For this
purpose, all nodes shall communicate via their NM.
The NM communication is independent of the underlying bus protocol. Each node can communicate
unidirectionally and address-related with any other node of the network. Therefore, individual and group
addressing of nodes is required.
2.1.2.2 Node addressing
2.1.2.2.1 General
Address-related communication takes into account receiver and emitter. Each node has a unique identification
which is known in the network.
Each address-related communication message contains certain data, the emitter identification and the
receiver identification. NM does not specify the encoding of these components into selected bus protocols.
4 © ISO 2006 – All rights reserved

---------------------- Page: 10 ----------------------
ISO 17356-5:2006(E)

Figure 3 — Exemplary representation of encoding of an NM communication message
onto a general protocol format

Individual addressing is implemented by node addressing using 1:1 connections. Group addressing is
implemented by node addressing using 1:k connections (k < number of nodes in the network). For this
purpose, groups of receivers join group addresses.
2.1.2.2.2 Features of node addressing
These include the following:
⎯ Each node is assigned a unique identification known within the whole network.
⎯ Emitter and receiver identifications are explicitly included in the message.
⎯ 1:k connections are implemented using group addresses.
⎯ All messages are broadcast.
⎯ Integrating a new node in an existing network does not require notification of the existing nodes.
2.1.3 NM infrastructure for data exchange
The NM supports the transfer of application data via its infrastructure (the logical ring). During the time delay
between the reception and the transmission of the ring message, the application is able to modify the data.
It is possible for the application to specify and implement management algorithms which are not provided by
NM.
© ISO 2006 – All rights reserved 5

---------------------- Page: 11 ----------------------
ISO 17356-5:2006(E)

Figure 4 — Mechanism to transfer application data via the logical ring
2.1.4 Standard functionality
Initializations are performed with any system start (“cold start”), e.g. timer services required from the operating
system or communication hardware via the data link layer interface.
Before the system is switched off, or switches off automatically, NM can be “shut down”, so that it can restore,
e.g. to the previously known network history when the system is started up again.
The NM handles individual parameters, e.g. time-outs and node identifications and, if necessary, version
numbers to identify hardware and software versions.
2.1.5 Configuration management
2.1.5.1 Network configurations
In the absence of any faults, the networked nodes are activated at different times, e.g.
⎯ stations on terminal 30 (permanent power): Wake-up via external event;
⎯ stations on terminal 15 (ignition): Switch ON via ignition key;
⎯ stations with switch in supply line: switching ON and OFF at random, by driver.
However, the actual configuration is also altered by faulty nodes and by defects in the communication network.
Consequently, different actual configurations can result for the individual nodes in the course of time, which
are additionally subject to external influences, e.g. actions by the driver.
As a rule, each node wants to start its application as quickly as possible. In view of NM, this means that an
actual configuration is made available to the applications as soon as possible. Finally, it is up to the
application to decide whether to start communication immediately after it has become operable, or whether to
wait until a minimum configuration is detected by NM.
NM distinguishes between:
⎯ actual configuration: set of nodes to which access is possible; and
⎯ limp home configuration: set of nodes which due to failure cannot participate in the logical ring.
6 © ISO 2006 – All rights reserved

---------------------- Page: 12 ----------------------
ISO 17356-5:2006(E)
Therefore, NM provides the following services:
⎯ supply of the actual configuration;
⎯ comparison of a configuration with a target configuration;
⎯ indication of changed configuration.
2.1.5.2 Detection of a node in fault condition
2.1.5.2.1 Operability of a node
A node is considered operable, in terms of NM, if the node participates in the logical ring.
2.1.5.2.2 Detection of failures
Only a node which is expected to be operable on the network can be recognized as having failed. The
application recognizes node failures by comparison to the previous knowledge regarding the target
configuration. There are several possible ways by which the application can acquire this knowledge:
⎯ the last stable state of the actual configuration;
⎯ one or several programmed target configuration(s);
⎯ the target/actual configuration determined by NM since system startup.
The NM recognizes its own node as having failed if it cannot send via the bus or if it cannot receive any
messages from the bus, i.e. it is no longer operable.
Another node is considered as having failed if its NM message is not received or a NM message is received
signalling an error state.
2.1.5.2.3 Reaction to a node failure
The NM of a node detecting a failure cannot distinguish whether the failed node is no longer able to
communicate due to a line fault or due to a complete failure, without additional support. Any possible reactions,
e.g. changeover to redundant physical paths, shall be specified together with entire system requirements.
2.1.5.3 Internal Network Management States
NM is specified in a hierarchical way. NM can enter the internal states listed below:
⎯ NMOff: NM is shut off;
⎯ NMOn: NM is switched on;
⎯ NMShutDown: Selective shutoff of NM entity.
NMOn:
⎯ NMInit: NM initialization;
⎯ NMAwake: Active state of the NM;
⎯ NMBusSleep: NM in sleep mode;
⎯ NMActive: NM communication enabled;
⎯ NMPassive: NM communication disabled.
© ISO 2006 – All rights reserved 7

---------------------- Page: 13 ----------------------
ISO 17356-5:2006(E)
NMAwake:
⎯ NMReset: The operability of the own node determined;
⎯ NMNormal: Processing of direct node monitoring;
⎯ NMLimpHome: Handling of failure in own node.
8 © ISO 2006 – All rights reserved

---------------------- Page: 14 ----------------------
ISO 17356-5:2006(E)

Figure 5 — Simplified state transition diagram of the direct NM
© ISO 2006 – All rights reserved 9

---------------------- Page: 15 ----------------------
ISO 17356-5:2006(E)
2.1.6 Operating modes
The NM does not manage application modes, but exclusively manages NM operating modes. NM
distinguishes two main operating modes. The modes of the NM are directly mapped to internal NM states:
NMAwake (NMActive): In NMAwake, the node participates in NM communication (logical ring) and monitors
all nodes with a NM in NMAwake.
NMBusSleep: If a node is in NMBusSleep, it does not participate in NM communication. Depending on the
hardware integrated in the networks, nodes can switch into NMBusSleep simultaneously.
The NM provides services for:
⎯ adjustment of NM operation modes; and
⎯ indication of NM operating modes.
2.1.7 Network error detection and treatment
Only a limited part of the network activities is “visible” for the NM to detect errors.
The problem with error detection is that many errors appear identical from the node’s point of view:
⎯ The fact that a node on the network is not transmitting messages may be due to various reasons:
⎯ it may be due to a control unit which has failed completely, or which has not been installed;
⎯ the communication module or the bus driver may be defective; or
⎯ bus lines may have been disconnected or the connector may be defective.
⎯ Great interest is attributed to any information which helps detect the cause of an error clearly, so as to
enable replacement or repair of the faulty component or to initiate an NMLimpHome.
⎯ Most errors occur during the course of assembly of the network during production and after repairs. If
connectors are interchanged or contacts are pushed back, this will have fatal consequences for the
network. Lines which are laid incorrectly, e.g. directly along components with sharp edges, can also
cause operating malfunctions within the network.
2.1.8 Support of diagnostic application
The NM supports the diagnostic application in the ECU by providing on request:
⎯ status information of NM;
⎯ configuration information acquired.
The NM is not responsible for recording the error history.
10 © ISO 2006 – All rights reserved

---------------------- Page: 16 ----------------------
ISO 17356-5:2006(E)
2.2 Algorithms and behaviour
2.2.1 Communication of the Network Management system
2.2.1.1 NM protocol data unit (NMPDU)
2.2.1.1.1 General
Any NM message contains the NM protocol data unit (NMPDU). The NMPDU defined hereafter represents the
NM data to be communicated in order to control NM performance.
In order to fulfil all requirements with regards to communication and NM the NMPDU contains the following
elements:
⎯ NM address field:
⎯ source Id,
⎯ destination Id;
⎯ NM control field:
⎯ OpCode,
⎯ NM data field (optional):
⎯ application specific data.
NM does not define network addresses. This parameter is dedicated to specific system design and therefore
is the responsibility of the respective system developer.
Table 1 — NMPDU – the representation of the data is not fixed
Address field Control field Data field
Source Id Dest. Id OpCode Data
Mandatory Optional

Res Ring Message (4 types)

Alive Message (2 types)

Limp Home Message (2 types)
To guarantee the interoperability, the data representation and the NMPDU encoding and decoding algorithms
shall be fixed. It is necessary to initialize the reserved area of the OpCode for future expansions. Whenever a
Network Management message is received and transmitted after T , the reserved part of the OpCode is
Typ
copied to the transmitted message.
© ISO 2006 – All rights reserved 11

---------------------- Page: 17 ----------------------
ISO 17356-5:2006(E)

Figure 6 — NM actions with the reserved area of the OpCode (XXX encoding of NM message types)

2.2.1.1.2 Data consistency
The NM guarantees the data consistency of the NMPDU, e.g. during the reception of a burst of NMPDUs. The
overrun of complete NMPDUs is possible.
2.2.1.1.3 NMPDU length
NM neither fixes the length of the NMPDU nor determines whether the data length is static or dynamic.
Dynamic means that the length of the user data may change from NM message to NM message without
affecting the specified algorithms.
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.