ISO 17356-5:2006
(Main)Road vehicles — Open interface for embedded automotive applications — Part 5: OSEK/VDX Network Management (NM)
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
Relations
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 2006
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
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
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
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.
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
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.
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
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
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
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.
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
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.
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
Figure 5 — Simplified state transition diagram of the direct NM
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
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.
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.
2.2.1.2 Addressing mechanisms used by the NM
Each node in the network is assigned a global identification known by all nodes within the entire network.
NM communication is performed by directional communication of NM messages using 1:1 connections. The
communication sequence complies with the definition of the logical ring in the respective network.
Therefore, node addressing mechanisms are used for NM communication. NM protocol data units shall
include global identifications of source and destination among other data.
These identifications are transferred into address-related NM messages. Each node transmits NM messages
with its global node identification and addresses the receiver by specifying its global node identification, e.g. in
the message header or in the data field.
12 © ISO 2006 – All rights reserved
Figure 7 — Encoding/decoding of the NMPDU to/from a message on the bus
Examples for mapping node identifiers into address-related NM messages are given in Annex A.
In order to simplify the handling of that amount of similar communication objects for NM communication, the
data link layer shall provide the interface of a window communication mechanism. The window mechanism
shall be defined by a WindowMask and an IdBase. However, the window mechanism shall be implemented by
the respective NM system responsible.
Figure 8 — Transmission and reception of NM protocol data units (NMPDU)
NOTE It depends on the system generation functionality whether the parameter DataLength is static and located
inside the DLL or whether it is dynamic and located inside NM.
14 © ISO 2006 – All rights reserved
Figure 9 — CAN, example for the transmission and reception mechanisms of a NMPDU
The CAN identifier consists of two parts:
⎯ a fixed IdBase; and
⎯ some bits of the address field, chosen by a mask.
2.2.2 NM infrastructure for data exchange
2.2.2.1 General
The NM does not monitor the contents of the NMPDU data field. Every received ring message will be
indicated to the application. The data field will be copied immediately into the buffer. The buffer will be copied
into the data field, when the ring message shall be passed to the logical successor.
2.2.2.2 Data consistency
The NM uses the following mechanisms to guarantee the data consistency:
⎯ The application can modify the ring data only between the reception of a ring message from the logical
predecessor and the emission of the ring message to the logical successor.
⎯ The NM allows the access to the ring data only if the logical ring runs in a stable state. The logical ring
runs stable if the configuration does not change and there is no NM message during the allowed access
time of the application to the ring data.
Figure 10 — Handling of data exchange between NM and application
2.2.3 Standard tasks
2.2.3.1 NM parameters
All NM parameters introduced in the concept description are known at compile time for a specific
implementation and stored in the ROM of all ECUs.
Table 2 — NM parameters
NM parameter Definition Valid area
Local
NodeId Relative identification of the node-specific NM messages
for each node specific
Global
T
Typical time interval between two ring messages
Typ
for all nodes
Global
T
Maximum time interval between two ring messages
Max
for all nodes
Time interval between two ring messages with Global
T
Error
NMLimpHome identification all nodes
Global
T
Time the NM waits before transmission in NMBusSleep
waitBusSleep
all nodes
Delay to repeat the transmission request of a NM Local
T
Tx
message if the request was rejected by the DLL for each node specific
16 © ISO 2006 – All rights reserved
To ensure the implementation of open and adaptive systems, all parameters of each node should be stored in
a non-volatile, but erasable and writeable memory.
These can thus be adapted whenever required, e.g. by a diagnostic node. As regards transfer of parameters,
reference is made to a specific download mode which is not dealt with in implementation specific system
definitions.
2.2.3.2 Network status
The NM informs the application on request about the network status it has acquired. The interpretation of
these data is system-specific and therefore with the application.
NM implementation should comply with minimum requirements to memory size which enables representation
and storage of the network state, can appear as shown in Table 3.
Table 3 — Encoding of the network status
Network status Interpretation
Present network configuration 0 No
a
stable 1 Yes
b
Operating mode of network 0 No error
c
interface
1 Error, bus blocked
0 NMPassive
Operation modes
1 NMActive
0 NMOn
1 NMOff
0 No NMLimpHome
1 NMLimpHome
0 No NMBusSleep
1 NMBusSleep
0 No NMTwbsNormal and no NMTwbsLimpHome
1 NMTwbsNormal or NMTwbsLimpHome
0 Using of Ring Data allowed
1 Using of Ring Data not allowed
0 Service GotoMode(Awake) called
1 Service GotoMode(BusSleep) called
a
Configuration did not change during the last loop of the NM message in the logical ring.
b
Reception and transmission of NM messages were successful.
c
CAN-busoff is an example.
2.2.3.3 Extended network status
The extended network status is specific to the user.
Table 4 — Example for the encoding of the extended network status
Extended network status Interpretation
a
Operating mode of network interface 00 No error
b
01 Error, communication possible
c
10 Error, Communication not possible
11 Reserved
Number of nodes which participate in the monitoring Up to the user
algorithm “logical ring”
Number of nodes which signal its limp home Up to the user
Time since the logical ring is in a stable state Up to the user
Time since the logical ring is in a dynamic state Up to the user
a
Reception and transmission of NM messages were successful.
b
Communication was via one wire.
c
CAN-busoff for a “long” time is an example.
2.2.4 Configuration management
2.2.4.1 General
Direct node monitoring is based on decentralized configuration management. The respective procedures are
described by one state transition diagram. The NM algorithm for decentralized configuration management can
be used for:
⎯ regular NM communication, i.e. transmission of ring messages according to the communication
sequence; and
⎯ exceptional NM communication, i.e. startup and limp home/failure modes.
2.2.4.2 Timing reference
Implementation of decentralized communication management requires several timing criteria to be respected.
To the resulting time intervals a relatively high jitter may be applied in the individual nodes.
In order to minimize the negative effect on user software, NM shall not require any sharp timing criteria in
general. The following timing criteria apply with NM implementations:
⎯ T typical interval between two ring messages on the bus;
Typ
⎯ T maximum admissible interval between two ring messages on the bus;
Max
⎯ T cycle time in which a node signals that an error has occurred;
Error
⎯ T delay to repeat the transmission request of a NM message if the preceding request was rejected.
Tx
2.2.4.3 Monitoring counter
To determine if a node is operational, the writing path and the reading path of the node should be checked
explicitly by the NM.
18 © ISO 2006 – All rights reserved
This is accomplished most easily by indirect mechanisms, using monitoring counters which are incremented
or decremented by different events. Their states — contents greater or less than the predefined limits — are
considered as information pertaining to the node’s readiness for operation.
2.2.4.4 State transition diagram
From the point of view of the application, the basic states of NM are:
⎯ NMReset: In NMReset, the node notifies its presence once in the network. For that purpose, the alive
message is transmitted. The NM then changes immediately over to NMNormal.
⎯ NMNormal: In NMNormal, the NM tries to pass one ring message cyclically with T from one node to
Typ
another. If a node is unable to receive or transmit any NM messages, it switches over into NMLimpHome.
⎯ NMLimpHome: In NMLimpHome the NM signals its limp home status by a limp home message cyclically
with TError and repetitively until it is able to transmit its own ring message to the bus and until it is able to
receive NM messages of other nodes correctly.
Figure 11 — State transition diagram of the NM algorithms for initialization, start-up and monitoring of
a network (logical ring and limp home)
Some hints include:
⎯ Time-out TMax: In case of ring messages: another node in the logical ring has disappeared.
⎯ NMrxcount: This counter is used to detect a failure at the receive functionality of the NM.
⎯ NMtxcount: This counter is used to detect a failure at the transmit functionality of the NM.
⎯ Enter NMLimpHome: This state is entered, if NMtxcount or NMrxcount is greater than system specific
limits (rx_limit, tx_limit). Typical value for rx_limit is 4 and a typical value for tx_limit is 8.
20 © ISO 2006 – All rights reserved
⎯ Leave NMLimpHome: This state is left, if the receive functionality and the transmit functionality is always
available for the NM.
⎯ Node skipped: If a node is skipped, it transmits an alive message asynchronously.
⎯ System-specific default configuration: “I am present at the network and I am my own logical successor”
⎯ Start-up of the logical ring: By entering the state NMNormal every node starts the alarm T .
Typ
⎯ Registration of a node: Alive messages and ring messages are used to introduce a node in the network.
⎯ Delay TTx: A transmit request can be rejected by the lower communication layer and shall be repeated
with a delay.
Figure 12 — Skipped in the logical ring
Figure 13 — Actions during NMNormal in case an NM message is received “at a time”
During the establishment of the logical ring, NM transmits and receives alive messages and ring messages
from the network interface.
Starting with a stable NM communication in the logical ring the management of two configuration failures
— dynamic introduction of a “new” node in the NM communication (node no. 3); and failure condition of
a node leading to its disappearance from the logical ring (node no. 1) — are shown in Figure 14.
22 © ISO 2006 – All rights reserved
Figure 14 — Regeneration principle of decentralized configuration management as a basis for NM
communication in the logical ring
2.2.4.5 Particularities regarding implementation
2.2.4.5.1 The emitting of a message is not interruptible
During normal operation, a ring message shall be transmitted or passed with a delay unless another ring
message has been received during the delay.
Due to particularities of some asynchronous protocol implementations, this task cannot be executed directly in
line with the verbal statement.
In view of node i, there is no way of preventing an external ring message being received which really prohibits
the transmission of the node’s own ring message between the decision to send the ring message of its own
and the actual transmission.
This effect is only critical if the external ring message received is destined to node i. In this case, two ring
messages can be maintained permanently, as exactly the same constellation may occur at the logical
successor.
Figure 15 shows a constellation of ring messages which enables the simultaneous occurrence of two ring
messages without specific measures.
Key
t The timer T in node i has elapsed and the ring message of node i is released for transmission. As the bus is busy,
1 Typ
this ring message cannot be transferred.
t Node i receives the respective ring message from node k.
t The ring message of node i is transmitted to the bus.
t The ring message of node i was transmitted to the bus successfully.
Figure 15 — Ring messages from the nodes i and k on an asynchronous bus
Node i would really pass the ring message received at t with a delay of T . However, in this case, it would
2 Typ
have to terminate the ring message requested at t which has not yet been emitted. This is not possible in
most cases.
To avoid two simultaneous ring messages occurring at the same time, each node shall ignore a ring message
addressed to it between the moments t and t .
1 4
2.2.4.5.2 Timer structure in the state “NMNormal”
The timers T and T are set, reset and cancelled for supervision of the NM communication.
Typ Max
The applicability of alarm services SetAlarm and CancelAlarm is assumed.
Table 5 — Timer actions in NMNormal, during various bus actions
T T
Typ Max
SetAlarm CancelAlarm SetAlarm CancelAlarm
Ring message received - 9 9 9
Addressed by ring message or 9 -
source equal destination
1)
Ring message transmitted - 9 9
Transition from NMReset to 9 - - -
NMNormal
NOTE A duplicated ring is avoided.
This application fulfils the bus-specific requirement to avoid several ring messages. The table shows the
activities of the timers in NMNormal. Individual timer requests are terminated abnormally and/or set as
required by the bus activities detected. In this context, the fact that a duplicate ring is avoided is of particular
interest. Between the moment when the decision to pass the node’s own ring message is made and the
24 © ISO 2006 – All rights reserved
moment when it is actually transmitted, any additional request to pass the ring message shall be ignored. So,
if the request T is cancelled as a precautionary measure whenever its own ring message is transmitted,
Typ
this task is accomplished with minimum effort.
Processing a timer request only necessitates triggering two actions in NMNormal. Timer T is responsible
Typ
for passing the r
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...