NM 252

OSEK/VDX
Open Systems and the Corresponding Interfaces for Automotive Electronics
OSEK/VDX
Network Management Concept and Application Programming Interface
Version 2.5.2 16th January 2003
This document is an official release and replaces all previously distributed documents. The OSEK group retains the right to make changes to this document without notice and does not accept liability for errors. All rights reserved. No part of this document may be reproduced, in any form or by any means, without permission in writing from the OSEK/VDX steering committee.
Page 1
by OSEK/VDX
NM Concept & API 2.5.2
OSEK/VDX
Open Systems and the Corresponding Interfaces for Automotive Electronics
Table of Contents
Introduction ................................................................................................................................ 3 Summary .................................................................................................................................... 4 1. 2. Scope of the OSEK Network Management........................................................................ 5 Direct Network Management ............................................................................................. 7 2.1. Concept....................................................................................................................... 7 2.1.1. Node Monitoring .................................................................................................... 7 2.1.2. Addressing.............................................................................................................. 8 2.1.3. NM Infrastructure for Data Exchange .................................................................. 10 2.1.4. Standard Functionality.......................................................................................... 10 2.1.5. Configuration Management.................................................................................. 10 2.1.6. Operating Modes .................................................................................................. 13 2.1.7. Network Error Detection and Treatment.............................................................. 14 2.1.8. Support of Diagnostic Application....................................................................... 15 2.2. Algorithms and Behavior ......................................................................................... 15 2.2.1. Communication of the Network Management System ........................................ 15 2.2.2. NM Infrastructure for Data Exchange .................................................................. 19 2.2.3. Standard Tasks ..................................................................................................... 20 2.2.4. Configuration Management.................................................................................. 23 2.2.5. Example: Skipped in the logical ring ................................................................... 31 2.2.6. Example: Logical Successor................................................................................. 33 2.2.7. Operating Mode.................................................................................................... 34 2.2.8. Fusion of Configuration Management and Operating Modes .............................. 39 2.2.9. Alarms inside the Network Management ............................................................. 56 3. Indirect Network Management......................................................................................... 60 3.1. Concept..................................................................................................................... 60 3.1.1. Node Monitoring .................................................................................................. 60 3.1.2. Configuration-Management ................................................................................. 61 3.1.3. Standard Task ....................................................................................................... 62 3.1.4. Monitoring Mechanisms....................................................................................... 63 3.1.5. Monitoring time-outs............................................................................................ 64 3.1.6. Operating Modes .................................................................................................. 67 3.2. Algorithms and behavior .......................................................................................... 67 3.2.1. Configuration Management.................................................................................. 67 3.2.2. Operating Mode.................................................................................................... 71 3.2.3. State Machine in SDL .......................................................................................... 73
Page 2 by OSEK/VDX NM Concept & API 2.5.2
OSEK/VDX
OSEK/VDX
4.
System generation and API .............................................................................................. 85 4.1. Overview .................................................................................................................. 85 4.2. Conventions for Service Description ....................................................................... 86 4.2.1. System Generation................................................................................................ 86 4.2.2. Type of Calls ........................................................................................................ 87 4.2.3. Error Characteristics............................................................................................. 87 4.2.4. Structure of the Description ................................................................................. 87 4.3. General Data Types .................................................................................................. 89 4.4. Common services ..................................................................................................... 89 4.4.1. Standard Functionality.......................................................................................... 89 4.4.2. Configuration Management.................................................................................. 91 4.4.3. Operating Modes and Operating Mode Management .......................................... 97 4.5. Services for direct NM ........................................................................................... 101 4.5.1. Standard Functionality........................................................................................ 101 4.5.2. Operating Modes and Operating Mode Management ........................................ 102 4.5.3. Data Field Management ..................................................................................... 103 4.6. Services for indirect NM ........................................................................................ 105 4.6.1. Standard functionality ........................................................................................ 105 4.6.2. Configuration Mangement ................................................................................. 106
5.
Impacts upon OS, COM and the data link layer............................................................. 106 5.1. Error Codes............................................................................................................. 106 5.2. Common impacts.................................................................................................... 107 5.2.1. Requirements of the data link layer.................................................................... 107 5.2.2. Requirements of OSEK Operating System (OSEK OS) .................................... 109 5.3. Impacts from direct NM ......................................................................................... 110 5.3.1. Interface to the data link layer ............................................................................ 110 5.4. Impacts from indirect NM ...................................................................................... 112 5.4.1. Interface to OSEK Communication (OSEK COM) ........................................... 112
6. 7.
History ............................................................................................................................ 114 Implementation proposal (direct NM)............................................................................ 115 7.0.1. Overview of Internal Activities .......................................................................... 115 7.0.2. Specification of Internal Activities..................................................................... 117 7.0.3. NMPDU ............................................................................................................. 122 7.0.4. Scalability........................................................................................................... 127 7.1. Implementation proposal (indirect NM)................................................................. 129 7.1.1. Scalability........................................................................................................... 129 7.1.2. Implementation hints.......................................................................................... 130 7.1.3. Summary of SDL state diagram graphical notation ........................................... 132 7.2. Outlook................................................................................................................... 133
8.
Index ............................................................................................................................... 135
Page 2
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Introduction
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 the OSEK/VDX co-operation, 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 must be accessible for authorized entities maximum tolerance with regard to temporary failures support of network related diagnostic features.
At a basic configuration stage, NM implementations complying with OSEK specifications must be 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 must be recorded and evaluated uniformly at all ECUs at intervals. Thus each node features a determined behavior as regards the network and the application concerned. OSEK 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 must be in accordance with requirements as regards to the entire networked system. System status In view of the application, NM comprises two standardized interfaces:

Software: Network behavior:
Application program NM Station Communication medium
The resulting entire system is open. Thus, it can adapt to new requirements within the restrictions defined by the system design.
by OSEK/VDX
Page 3
OSEK/VDX
OSEK/VDX
Remarks by the authors This document 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 the additional inter project "OSEK Overall Glossary" which is part of the OSEK Binding Specification.
Summary
In order to achieve the essential task of a network monitoring, i.e.
ensure safety and reliability of a communication network for ECUs,
OSEK 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 signaling 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) Support of diagnosis
There are two main parts within the document: Direct Network Management described by Chapter 2 and Indirect Network Management described by Chapter 3. Both chapters describe the concepts, the algorithms and behavior. The Subsections Concept describe the fundamental aspects of the configuration management, the operating states and operating state management. The Subsections Algorithms and Behavior describe the protocol used for communication between nodes. Chapter 4 describes the Application Programming Interface comprising the pure specification of the services offered by NM for both direct and indirect. Input and output data, the
Page 4
by OSEK/VDX
OSEK/VDX
OSEK/VDX
functional description, particularities, etc. are described for each service. Furthermore System Generation services are described within this chapter. Chapter 5 describes Impacts on OSEK Infrastructure and gives a brief description of all requirements to OSEK Communication, OSEK Operating System and the data link layer for both direct and indirect NM.
1.
Scope of the OSEK Network Management
Embedding of the Network Management OSEK NM defines a set of services for node monitoring. The next figure shows how the NM is embedded into a system. It is also shown that the NM has to be adapted to specific requirements of the bus system used or to the resources of the nodes.
Operating System
Application
Station 5) Management 1)
OSEK COM
4) Interaction Layer
Network Management OSEK 6) Algorithms Protocol 7) specific Algorithms 3)
Network Layer
Data Link Layer 2) Bus Communication Hardware
Figure 1
interface and algorithms responsibility 1) API, fixed by OSEK 2) several buses connected to one mController 3) interface to DLL - COM specific, protocol specific 4) interface to COM Interaction Layer 5) station management (outside OSEK, see text below) 6) OSEK algorithms 7) protocol specific management algorithms
by OSEK/VDX Page 5
OSEK/VDX
OSEK/VDX
OSEK NM interface to interact with the application (API) algorithm for node monitoring OSEK internal interfaces (NM <-> COM, ...) algorithm for transition into sleep mode NM protocol data unit (NMPDU)
adaptation to bus protocol specific requirements CAN, VAN, J1850, K-BUS, D2B, ... error handling, e.g. bus-off handling in a CAN, transmission line error handling interpretation of the status information, e.g. overrun or error active/passive in a CAN
adaptation to node resources scaling of the NM as a requirement of the node application specific usage of the NM services
adaptation to hardware specific requirements 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
station management (system specific algorithms) There are a variety of additional tasks to co-ordinate a network. Those are not described by OSEK, since they are system dependent. Hence these tasks are done by the application, e.g. by a module called station management. 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.
Page 6
by OSEK/VDX
OSEK/VDX
OSEK/VDX
2.
Direct Network Management
2.1. Concept
2.1.1. Node Monitoring OSEK NM supports the direct node monitoring by dedicated NM communication. A node is a logical whole to which a communication access is possible. A micro processor 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 OSEK 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 a 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. Logical ring 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 must be able to send NM messages to all other nodes and receive messages from them.
by OSEK/VDX
Page 7
OSEK/VDX
OSEK/VDX
A B
node
Electronic Communication Unit
A B B A
B A C B A C C B
A
B A A C
C A
B C
communication media 1
C A
B C
communication media 2
Figure 2 Principle
Infrastructure of the NM (logical ring), example with two buses
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 Receive ring message Interpretation as transmitter related registration to the logical ring. Interpretation as transmitter specific alive signal and synchronization to initiate transmission of own NM message according to the logical ring algorithm. Interpretation as transmitter specific break down
Time-out on ring message State of a node
A monitoring node is able to distinguish 2 states of a monitored node. node present node absent specific NM message received (alive or ring) specific NM message not received during time-out
A monitoring node is able to distinguish 2 states of itself. present or not mute absent or mute specific NM message transmitted (alive or ring) specific NM message not transmitted during time-out
2.1.2. Addressing The status of nodes and of the network has to be acquired and evaluated uniformly at intervals. For this purpose, all nodes must communicate via their NM.
Page 8
by OSEK/VDX
OSEK/VDX
OSEK/VDX
The NM communication is independent of the underlying bus protocol. Each node can communicate unidirectional and address related with any other node of the network. Therefore individual and group addressing of nodes is required. Node addressing Address related communication has to take 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. OSEK NM does not specify the encoding of these components into selected bus protocols.
Emitter (source) Receiver (destination)
Data
address related message
Encoding
Header
Data
general protocol format
Figure 3
Exemplary representation of encoding of a 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. Features of node addressing

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.
by OSEK/VDX
Page 9
OSEK/VDX
OSEK/VDX
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 OSEK.
logical predecessor
Station
t=0
NM
NM message received Data
Application
Data Buffer
t=Tdelay
Data NM message to transmit
-> .ind -> Read <- Transmit
logical successor
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 "shutdown", 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): Wakeup via external event
Page 10
by OSEK/VDX
OSEK/VDX
OSEK/VDX
-
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. OSEK NM distinguishes between

actual configuration: set of nodes to which access is possible limp home configuration: set of nodes which due to failure cannot participate in the logical ring
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
Operability of a node A node is considered operable in terms of NM, if the node participates in the logical ring. 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 start up
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.
by OSEK/VDX
Page 11
OSEK/VDX
OSEK/VDX
Another node is considered as having failed, if its NM message is not received or a NM message is received signaling an error state. 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. change over to redundant physical paths, must be specified together with entire system requirements.
2.1.5.3.
Internal Network Management States
The OSEK NM is specified in a hierarchical way. The OSEK NM can enter the internal states listed hereafter:

NMOff NMOn NMShutDown
NM is shut off NM is switched on Selective shut off of NM entity
NMOn:

NMInit NMAwake NMBusSleep NMActive NMPassive
NM initialization Active state of the NM NM is in sleep mode NM communication enabled NM communication disabled
NMAwake:

NMReset NMNormal NMLimpHome
The operability of the own node is determined Processing of direct node monitoring Handling of failure in own node
Page 12
by OSEK/VDX
OSEK/VDX
OSEK/VDX
NMShutDown
StopNM
NMOn
StartNM
NMOff NMOn NMBusSleep not any communication request communication request NMAwake TalkNM NMActive
SilentNM
NMInit
NMPassive
fatal Bus Error NMAwake NMLimpHome "Own station non operational" e.g. not any NM transmission "Failure at own station repaired" e.g. NM transmission and NM reception possible
"Own station non operational" i.e. not any NM reception "Station operational" e.g. not any error at NM reception recognized
NMNormal
NMReset
"data inconsistent" e.g. time out at ring message
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.
by OSEK/VDX
Page 13
OSEK/VDX
OSEK/VDX
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, 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.
Page 14
by OSEK/VDX
OSEK/VDX
OSEK/VDX
2.1.8. Support of Diagnostic Application The NM supports the diagnostic application in the ECU by providing on request:

status information of OSEK NM configuration information acquired
The NM is not responsible for recording the error history.
2.2. Algorithms and Behavior
2.2.1. Communication of the Network Management System
2.2.1.1.
Network Management Protocol Data Unit
Any NM message contains the NM protocol data unit (NMPDU). The NMPDU defined hereafter represents the OSEK 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
OSEK NM does not define network addresses. This parameter is dedicated to specific system design and therefore in the responsibility of the respective system developer.
by OSEK/VDX
Page 15
OSEK/VDX
OSEK/VDX
Address Field Source Id Dest. Id mandatory

res
Control Field OpCode

Ring Message (4 types) Alive Message (2 types) Limp Home Message (2 types)
Data Field Data optional
Table 1
NMPDU - the representation of the data is not fixed To guarantee the interoperability the data representation and the NMPDU encoding and decoding algorithms have to 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 TTyp, the reserved part of the OpCode is copied to the transmitted message.
logical predecessor
node
t=0
NM
Source Destination OpCode reserved XXX Data
NMPDU received
NM interprets
Source Destination
t=TTyp
reserved XXX OpCode
Data
NMPDU to transmit
logical successor
Figure 6
NM actions with the reserved area of the OpCode XXX encoding of NM message types
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. NMPDU length OSEK does neither fix the length of the NMPDU nor determine 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.
OSEK/VDX
OSEK/VDX
2.2.1.2.
Addressing Mechanisms used by the Network Management
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:1connections. 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 must 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.
NM responsibility Source Destination OpCode Data, optional
NMPDU to transmit
Encoding
Interoperability on node level
Header
Decoding
Data
Message with Header,

e.g. CAN
Source
Destination
OpCode
Data, optional
received NMPDU
NM responsibility
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 the annex. In order to simplify the handling of that amount of similar communication objects for NM communication the data link layer must provide the interface of a window communication mechanism. The window mechanism is defined by a WindowMask and an IdBase. However, the window mechanism has to be implemented by the respective NM system responsible.
by OSEK/VDX
Page 17
OSEK/VDX
OSEK/VDX
Node A
Network Management
Node B
Network Management
D_WindowData_ind(NetId,NMPDU)
D_WindowData_req(NetId,NMPDU)
Data Link Layer

WindowMask IdBase (SourceId) DataLength Encoding: -> Protocol Frame WindowMask IdBase DataLength
Data Link Layer

Decoding: -> NMPDU, NetId
WindowMask IdBase
SW-Acceptance: -> Protocol Frame
HW-Acceptance: Mask -> Protocol Frame
Protocol controller
Message Frame
Protocol controller
Message Frame
Network
Figure 8 Hint
Transmission and reception of NM protocol data units (NMPDU).
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.
Page 18
by OSEK/VDX
OSEK/VDX
OSEK/VDX
emitting NM
D_WindowData_req(NetId,NMPDU)
Node A
Address Field IdBase 10...1 WindowMask CAN-Identifier
Control Field Data Field
NMPDU
CAN Data Field
Protocol Frame
Bus
all messages
hardware acceptance: IF (ReceiveId AND AcceptanceMask = AcceptanceCode) = TRUE software acceptance: IF (ReceiveId AND WindowMask = IdBase) = TRUE CAN-Identifier Address Field CAN Data Field Control Field Data Field Protocol Frame NMPDU
D indow ata_ind(N _W D etId,N PD ) M U
receiving NM
Figure 9
Node B
CAN-Example for the transmission and reception mechanisms of a NMPDU The CAN identifier consists of two parts: 1) a fixed IdBase 2) some bits of the address field, chosen by a mask
2.2.2. NM Infrastructure for Data Exchange

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 has to be passed to the logical successor. Data consistency The NM uses several mechanisms to guarantee the data consistency:
NM Concept & API 2.5.2 by OSEK/VDX Page 19
OSEK/VDX
OSEK/VDX
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.
logical predecessor
node
t=0
NM
NMPDU received Source Destination OpCode RingData
Application
Ring Data Buffer

t=TTyp
Source Destination OpCode RingData NMPDU to transmit
-> RingData.ind -> ReadRingData <- TransmitRingData
logical successor
Figure 10
Handling of data exchange between NM and Application
2.2.3. Standard Tasks
2.2.3.1.
Network Management 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.
Page 20
by OSEK/VDX
OSEK/VDX
OSEK/VDX
NM Parameter
Definition Relative identification of the node-specific NM messages Typical time interval between two ring messages Maximum time interval between two ring messages Time interval between two ring messages with NMLimpHome identification Time the NM waits before transmission in NMBusSleep Delay to repeat the transmission request of a NM message if the request was rejected by the DLL NM parameters
Valid Area local for each node specific global for all nodes global for all nodes global all nodes global all nodes local for each node specific
NodeId TTyp TMax TError TWaitBusSleep TTx
Table 2
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. Thus these can 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. OSEK NM implementation should comply with minimum requirements to memory size which enables representation and storage of the network state, can appear as shown in the next table.
by OSEK/VDX
Page 21
OSEK/VDX
OSEK/VDX
Network Status

Interpretation 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 No Yes No error2) Error, bus blocked3) NMPassive NMActive NMOn NMOff no NMLimpHome NMLimpHome no NMBusSleep NMBusSleep no NMTwbsNormal and no NMTwbsLimpHome NMTwbsNormal or NMTwbsLimpHome using of Ring Data allowed using of Ring Data not allowed Service GotoMode(Awake) called Service GotoMode(BusSleep) called
Present network configuration stable1) Operating mode of network interface Operation modes
Table 3
Encoding of the network status. did not change during the last loop of the NM message in the logical ring 2) Reception and transmission of NM messages successful 3) e.g. CAN-busoff
1) Configuration
2.2.3.3.
Extended Network Status
The extended Network status is specific to the user.
Page 22
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Extended Network Status
Interpretation 00 01 10 11 No error1) Error, communication possible2) Error, Communication not possible3) reserved
Operating mode of network interface
Number of nodes which participate in the monitoring algorithm "logical ring" Number of nodes which signal its limp home time since the logical ring is in a stable state time since the logical ring is in a dynamic state ... Table 4
up to the user
up to the user up to the user up to the user
Example for the encoding of the extended network status. and transmission of NM messages successful 2) communication via one wire 3) e.g. CAN-busoff for a "long" time
1) Reception

Direct node monitoring is based on decentralized configuration management. The respective procedures are described by one state transition diagram. This OSEK algorithm for decentralized configuration management can be used for:

regular NM communication, i.e. transmission of ring messages according to the communication sequence exceptional NM communication, i.e. start up and limp home/failure modes
2.2.4.1.
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 must not require any sharp timing criteria in general. The following timing criteria apply with OSEK NM implementations: TTyp typical interval between two ring messages on the bus
by OSEK/VDX
Page 23
OSEK/VDX
OSEK/VDX
TMax TError TTx
maximum admissible interval between two ring messages on the bus cycle time in which a node signals that an error has occurred delay to repeat the transmission request of a NM message if the preceding request was rejected
2.2.4.2.
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. This is accomplished most easily by indirect mechanisms, using monitoring counters which are incremented or decremented by different events. Their states - contents greater or lesser than the predefined limits - are considered as information pertaining to the node's readiness for operation.
2.2.4.3.
State transition diagram
From the point of view of the application the basic states of OSEK NM are

NMReset NMNormal NMLimpHome
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 TTyp from one node to another one. If a node is unable to receive or to 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.
Page 24
by OSEK/VDX
OSEK/VDX
OSEK/VDX
NMOn
initialize hardware by D_Init(...;BusInit)
NMInitReset
- Timeout (TMax) at ring message
limphome message transmitted and any NM message received
- NMrxcount=0 - NMtxcount=0 - enable application communication by D_Online
NMrxcount <= rx_limit optional and NMtxcount <= tx_limit
NMReset
- reset the system specific default configuration - increment the reception counter - send an alive message, increment the transmission counter - initialize the NMPDU (reserved area in the Opcode and the data field)
NMInitNormal
start TTyp to transmit the 1st ring message
NMNormal
- determine present configuration (alive and ring messages received) - determine logical successor (alive and ring message received) - determine the limp home configuration - clear NMrxcount, if any NM message is received - clear NMtxcount in case of the transmission of any NM message - increment NMtxcount, if a NM message has to be transmitted - repeat the transmission request (TTx) in case of a rejection from the DLL, no effect to NMtxcount - send an alive message, if skipped in the logical ring - pass the ring message delayed (TTyp) (source=destination or destination=own station), if there is no ring message on the bus
NMrxcount > rx_limit optional or NMtxcount > tx_limit
NMtxcount > tx_limit
NMInitLimpHome
disable application communication by D_Offline initialize the hardware by D_Init(...;BusAwake)
start TError to transmit the 1st limp home message
NMLimpHome
- send limphome message cyclically (TError) - enable cyclically (TError) application communication by D_Online
fatal Bus Error signalled by D_Status.ind (e.g. BusOff)
Figure 11
State transition diagram of the NM algorithms for initialization, start up and monitoring of a network (logical ring and limp home)
Hints 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
by OSEK/VDX Page 25
OSEK/VDX
OSEK/VDX
limits (rx_limit, tx_limit). Typical value for rx_limit is 4 and a typical value for tx_limit is 8. 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.
SD
Source Skipped Node Destination
Figure 12 -
skipped in the logical ring
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 TTyp. 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 has to be repeated with a delay.
Page 26
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Clear NMrxcount
ring message or alive message
message type
limphome message
determine actual configuration
determine logical sucessor
ring message
message type
alive message
determine limphome configuration
-CancleAlarm(TTyp) -CancleAlarm(TMax)
to me
destination
to another node
SetAlarm(TTyp)
SetAlarm(TMax)
not skipped
skipped
own node skipped in logical ring
transmit alive message
Figure 13
Actions during NMNormal in case a 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.
by OSEK/VDX
Page 27
OSEK/VDX
OSEK/VDX
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 (here: node no. 3) failure condition of a node leading to its disappearance from the logical ring (here: node no. 1)
are shown in the figure below.

recognize node failure alive message ring message NodeId determination of node in failure condition
?
adding of node 3
skip node 1
failure of node 1
stable NM communication in the logical ring
transient state of the logical ring
transient state of the logical ring
NM messages
2 3
1 3
1 3
3 3
3
2
3
1
3
2
time
Figure 14
Regeneration principle of decentralized configuration management as a basis for NM communication in the logical ring
2.2.4.4.
Particularities Regarding Implementation
The emitting of a message is not interruptible During normal operation, a ring message must 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. The figure below shows a constellation of ring messages which enables the simultaneous occurrence of two ring messages without specific measures.
Page 28
by OSEK/VDX
OSEK/VDX
OSEK/VDX
t1
t2 t3
t4
node i node k
i k i
time
Figure 15
ring messages from the nodes i and k on an asynchronous bus t1 The timer TTyp in node i has elapsed and the ring message of node i is released for transmission. As the bus is busy, this ring message cannot be transferred. t2 Node i receives the respective ring message from node k. t3 The ring message of node i is transmitted to the bus. t4 The ring message of node i was transmitted to the bus successfully.
Node i would really pass the ring message received at t2 with a delay of TTyp. However in this case, it would have to terminate the ring message requested at t1 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 must ignore a ring message addressed to it between the moments t1 and t4. Timer Structure in the State "NMNormal" The timers TTyp and TMax are set, reset and cancelled for supervision of the NM communication. The applicability of alarm services SetAlarm and CancelAlarm is assumed (see also section Requirements to OSEK Operating System). TTyp
SetAlarm ring message received Addressed by ring message or source equal destination ring message transmitted Transition from NMReset to NMNormal CancelAlarm SetAlarm
TMax
CancelAlarm
1) -
Table 5
1)
Timer actions in NMNormal, during various bus actions. a duplicated ring is avoided (see text below)
by OSEK/VDX
Page 29
OSEK/VDX
OSEK/VDX
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, 1) is of particular interest. Between the moment when the decision to pass the node's own ring message is made and the moment when it is actually transmitted, any additional request to pass the ring message must be ignored. So, if the request TTyp is cancelled as a precautionary measure whenever its own ring message is transmitted, this task is accomplished with minimum effort. Processing a timer request only necessitates triggering two actions in NMNormal. Timer TTyp is responsible for passing the ring message, whereas timer TMax monitors the cyclic occurrence of the ring messages; it serves to detect a general configuration error. TTyp elapses send ring message go to NMReset Table 6 TMax elapses
Main actions which are triggered by an expired timer in NMNormal.
How two ring messages are prevented The NM was specified on the base of a broadcast channel and a serial bus protocol. Therefore every node receives every NM message at nearly the same time. NM adjustments are overwritten by a received NM message - NM messages are handled with time priority. One of the basic principals of the NM is the synonym between an elapsed TTyp alarm and the emission of a regular ring message to a logical successor. The specified algorithms guarantee, that a running TTyp alarm exists always in only one node inside the whole network. A received regular ring message re-triggers in the addressed node (destination of the message) the TTyp alarm and cancels in all other nodes the TTyp alarms.
Page 30
by OSEK/VDX
OSEK/VDX
OSEK/VDX
node 1, NMNormal
TMax TTyp TMax
Node 1 received a regular ring message and set a TTyp Alarm to pass the ring message. When TTyp elapses, the alarm TMax is set and the regular ring message is prepared to transmit. After emitting the prepared regular ring message on the bus, the running alarm TMax is re-triggered.
time
elapsed alarm messages on the bus
message ready to transmit
message emitted to the bus 1 -> 5
node 1, NMNormal
TTyp TTyp TMax TMax
Node 1 received a regular ring message and set a TTyp Alarm to pass the ring message. When TTyp elapses, the alarm TMax is set and the regular ring message is prepared to transmit. A regular ring message was received and a TTyp alarm was set while preparing the emission of the regular ring message. The emitted regular ring message now retriggers the TMax alarm. Every received regular ring message re-triggers a set TMax alarm.
TMax
elapsed message alarm ready to transmit messages on the bus
ring message received 3 -> 1
message emitted to the bus 1 -> 5 time
node during NMNormal

TMax TMax
ring message received messages on the bus 3 -> 1
ring message received 1 -> 2 time
Figure 16
Examples for mechanisms to synchronize the NM alarms and their effects on the behavior of the NM top middle bottom Passing of a ring message during the fixed state of the logical ring. Passing of a ring message during the dynamic state of the logical ring - mechanism to avoid two ring messages. Monitoring of ring messages during the fixed state of the logical ring.
2.2.5. Example: Skipped in the logical ring
by OSEK/VDX
Page 31
OSEK/VDX
OSEK/VDX
Every node is able to define a temporary logical ring in case of the reception of a ring message to any node in the network. The ring is given by the identifications of the receiver node, the source node of the message and the addressed destination node.
receiver node was not skipped receiver node was skipped
Figure 17 temporary logical ring for the test, whether the receiver node has been skipped or not Source ID Destination ID Receiver ID Transmitter of the ring message addressed node Receiver of the ring message
source ID destination ID receiver ID
source ID receiver ID destination ID
By arranging the node identifications in a numerical order, one will get:

SDR RSD DRS DSR RDS SRD (Source) (Receiver) (Destination) (Destination) (Receiver) (Source ) < < < < < < (Destination) (Source ) (Receiver) (Source ) (Destination) (Receiver) < < < < < < (Receiver) (Destination) (Source ) (Receiver) (Source ) (Destination) skipped skipped skipped
The receiver node has been skipped in the lower three combinations. An alive message has to be emitted asynchronously by the receiver node. Note It is not always necessary to look for skipping at the reception of a ring message. S=D D=R S=R The source node does not know anything about other nodes. The receiver node of the ring message itself was addressed. The receiver node was the sender of the message
Page 32
by OSEK/VDX
OSEK/VDX
OSEK/VDX
SDR RSD DRS DSR RDS SRD
Figure 18 IF-conditions for the test Was a receiver node skipped by a ring message on the logical ring?
no
RDS
yes
SDR DRS DSR
D <R
no
RSD RDS SRD
yes
SDR
S <D
DRS DSR
S <D
RSD SRD
no
yes
S node identification of the source R node identification of the receiver D node identification of the destination From two to three IF conditions are necessary.
S <R
DRS
yes
DSR
yes
SRD
S <R
RSD
no
skiped skiped
no
skiped
not skiped
not skiped
not skiped
2.2.6. Example: Logical Successor

The source node of any received NM message could turn to the logical successor of the received node. To reach a decision on whether the source node is the new logical successor of the receiver node, the receiver node has to look to the receiver identification, the source identification and to the identification of the logical successor.
SLR (Source) < (Log. successor) < (Receiver) new logical successor RSL (Receiver) < (Source) < (Log. successor) new logical
successor LRS (Log. successor) < (Receiver) < (Source) new logical
successor LSR RLS SRL (Log. successor) (Receiver) (Source) < < < (Source) (Log. successor) (Receiver) < < < (Receiver) (Source) (Log. successor)
The state NMReset initializes the system-related basic configuration. Therefore the values L (Log. successor identification) and R (Receiver identification) are equal. The algorithm has to be initialized: the source of the first received NM message will be the logical successor.
by OSEK/VDX
Page 33
OSEK/VDX
OSEK/VDX
yes L=R
SLR RSL LRS LSR RLS SRL
Figure 19 IF conditions to determine a logical successor

no
RSL RLS SRL
no
yes
SLR LRS LSR
L<R
S node identification of the source

no
RLS
yes
SLR
S<L
LRS LSR
S<L
RSL SRL
R node identification of the receiver L node identification of the logical successor in the receiver node From three to four IF conditions are necessary.
no
yes
S<R
LRS
yes
LSR
yes
SRL
S <R
RSL
no
no
L=S
L=S
L=S
L=S
Note Of course it is possible to determine the logical successor from the stored present configuration when a ring message has to be emitted.
2.2.7. Operating Mode
2.2.7.1.
NMActive - NMPassive
In heterogeneous networks, individual nodes can suspend their network communication due to their specific requirements. Each node owns a silent mark which can be set and reset by the application.

silent mark set silent mark cleared
NMPassive desired NMActive desired
= "1" = "0"
Page 34
by OSEK/VDX
OSEK/VDX
OSEK/VDX
NMOn
NMBusSleep
NMActive not any communication request
communication request
NMAwake
TalkNM
SilentNM
NMInit
NMPassive
Figure 20
Toggling between NMActive and NMPassive
2.2.7.2.
NMBusSleep - NMAwake
The NM controls the access to the communication media on demand of the application. If the application in all nodes does not require the communication media, then the NM changes to the state NMBusSleep. Principle for Transition into BusSleep Mode Each node owns a sleep mark, which can be set and cleared by the application. Service GotoMode(BusSleep) GotoMode(Awake) Table 7 Description NMBusSleep desired NMBusSleep not desired sleep mark set cleared
Services to change between the states NMBusSleep and NMAwake.
The NM maps this sleep mark (e.g. represented by a sleep bit) into each ring message ( bit sleep.ind). If a set bit sleep.ind is transmitted, the NM internally changes to the state NM~PrepBusSleep (~: Normal or LimpHome). When the sleep mark is set NM prepares for notified and network wide confirmed sleep mode. The request for global NMBusSleep is set in a ring message. At each node participating in the logical ring this request for global sleep must be confirmed. The sleep mode initiating node must wait for network-wide confirmation of his request.
by OSEK/VDX
Page 35
OSEK/VDX
OSEK/VDX
If the NM message has completely looped in the logical ring then the request is confirmed by a ring message with a set bit sleep.ack. The signaling specified by InitIndDeltaStatus is carried out and the transition is performed after a global delay TWaitBusSleep. After the successful transmission of the ring message with a set bit sleep.ack, there can still be user messages in the transmit queues. Nodes in the state LimpHome are transmitting limp-home messages delayed by TError. Several limp-home messages can be received in this time period thus a transition in the state NMBusSleep is possible without problems. If the NM message has completely looped in the logical ring and the request is not confirmed, a NM message with different content is received or a NM message did not loop completely, the signalling specified by InitIndDeltaStatus cannot be carried out.
GotoMode(BusSleep)
Ring message cleared Sleep.ind cleared Sleep.ack
PrepBussleep
wait TWaitBusSleep
Ring message set Sleep.ind cleared Sleep.ack
Ring message set Sleep.ind cleared Sleep.ack Ring message set Sleep.ind set Sleep.ack
BusSleep
wait TWaitBusSleep
wait TWaitBusSleep
BusSleep PrepBussleep
Ring message set Sleep.ind cleared Sleep.ack
BusSleep PrepBussleep
GotoMode(BusSleep)
GotoMode(BusSleep)
Figure 21
Algorithm of the transition: NMNormal NMBusSleep
Note: All nodes are ready to change over into NMBusSleep only if the signaling specified by InitIndDeltaStatus is carried out. Up to that moment, application and NM must operate in its normal mode (i.e. NMNormal). The application still continues with its communication in the network, thus preventing error messages by the asynchronous transition of the nodes into NMBusSleep. For transition into network-wide sleep mode the following cases are dealt with differently: transition from NMNormal into NMBusSleep transition form NMLimpHome into NMBusSleep
Page 36
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Transition from NMNormal into Network-wide BusSleep Mode The NM is informed about the mode requested by the local function GotoMode(BusSleep). The figures below show the respective definitions.
NMawake
NMReset
NMNormal
any NM message with a cleared bit sleep.ind received or GotoMode(Awake) called
NMNormalActive
NMNormalActivePrepSleep
pass the regular ring message with the bit sleep.ack delayed (TTyp)
pass the ring message delayed (TTyp)(source=destination or destination=own station)
GotoMode(BusSleep) called and ring message transmitted with a set bit sleep.ind
GotoMode(BusSleep) called and any NM message with a set bit sleep.ack received
ring message transmitted with a set bit sleep.ack
NMTwbsNormal
wait TWaitBusSleep disable application communication by D_Offline
NMReset
any NM message with a cleared bit Sleep.ind received or GotoMode(Awake) called
timer runs down
NMBusSleep
Figure 22
Algorithm for transition NMNormal NMBusSleep
by OSEK/VDX
Page 37
OSEK/VDX
OSEK/VDX
Transition from NMLimpHome into network wide BusSleep Mode The function GotoMode(BusSleep) can also be called while NM operates in the mode NMLimpHome. The figure below shows the respective definitions.
NMAwake
NMNormal
NMReset
NMLimpHome
any NM message received with a cleared bit sleep.ind or GotoMode(Awake) called
NMLimpHomeActive
send limp home message cyclically (TError)
NMLimpHomeActivePrepSleep
Timeout TMax at ring message
GotoMode(BusSleep) called and service to transmit limp home message (set bit sleep.ind) called
GotoMode(BusSleep) called and any NM message with a set bit sleep.ack received any NM message received with a cleared bit Sleep.ind or GotoMode(Awake) called
disable application communication by D_Offline
NMTwbsLimpHome
wait T WaitBusSleep
timer runs down
NMBusSleep
Figure 23
Algorithm for transition NMLimpHome NMBusSleep
Page 38
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Transition from Network-wide BusSleep Mode to NMAwake The state NMBusSleep is left if the service GotoMode(Awake) is called or if any NM message is received, i.e. a communication request exists.
2.2.8. Fusion of Configuration Management and Operating Modes
2.2.8.1.
State Diagrams
NMAwake
NMLimpHome NMActive ~PrepBusSleep NMPassive ~PrepBusSleep NMNormal NMActive ~PrepBusSleep
NMPassive ~PrepBusSleep
NMReset NMActive NMPassive
NMBusSleep
NMInit
NMOn
NMShutDown
NMOff
Figure 24
Simplified state transition diagram of the direct NM configuration management and operation modes are summarized
by OSEK/VDX
Page 39
OSEK/VDX
OSEK/VDX
NMOff
NMShutDown
switch the bus hardware off by D_Init(...;BusShutDown)
service StartNM
service StopNM
NMOn NMBusSleep
NMInit
clear the bits sleep.ind and sleep.ack initialize the hardware by D_Init(...;BusInit) initialize the hardware by D_Init(...;BusAwake)
clear limp home configuration
NMAwake
Figure 25
State transition diagram of NMInit
Page 40
by OSEK/VDX
OSEK/VDX
OSEK/VDX
NMOn
NMAwake
NMInitBusSleep
initialize the sleep mode of the bus hardware by D_Init(...;BusSleep)
NMBusSleep
wait for communication request
communication request received (e.g. GotoMode(Awake) called or wake-up signal from the bus signalled by D_Status.ind or any NM message received)
NMInit
Figure 26
State transition diagram of NMBusSleep
by OSEK/VDX
Page 41
OSEK/VDX
OSEK/VDX
NMInit
NMAwake NMLimpHome NMNormal
NMInitReset
- NMrxcount=0 - NMtxcount=0 - enable application communication by D_Online
- reset the system specific default configuration - initialize the NMPDU (reserved area in the OpCode and the data field) - increment the reception counter
NMReset NMResetActive
NMActive - send an alive message with a cleared bit sleep.ind - increment the transmission counter
NMReset Sandard
NMPassive
NMActive
NMPassive
NMResetPassive
NMrxcount > rx_limit optional or NMtxcount > tx_limit
NMrxcount <= rx_limit optional and NMtxcount <= tx_limit
NMLimpHome
NMNormal
Figure 27
State transition diagram of NMReset
Page 42
by OSEK/VDX
OSEK/VDX
OSEK/VDX
NMAwake
NMReset
NMInitNormal
start TTyp to transmit the 1st ring message
NMNormal
any NM message with a cleared bit sleep.ind received or GotoMode(Awake) called NMActive
NMNormalStandard
- determine present configuration (alive and ring messages received) - determine logical successor (alive and ring messages received) - determine the limphome configuration - clear NMrxcount, if any NM message is received - clear NMtxcount in case of the transmission of any NM message - send the bit Sleep.ind in case of an existing logical successor - increment NMtxcount, if a NM message has to be transmitted - repeat the transmission request in case of a rejection from the DLL, no effect to NMtxcount - send an alive meessage if skipped in the logical ring
NMNormalActive
- pass the regular ring message delayed (TTyp) (source=destination or destination=own station), if there is no ring message on the bus
NMNormalActivePrepSleep
- pass the regular ring message with the bit Sleep.ack delayed (TTyp) if there is no ring message on the bus
NMPassive NMActive
GotoMode(BusSleep) called and ring message transmitted (the bit sleep.ind is set) GotoMode(BusSleep) called cleared bit sleep.ind received in any NM message or GotoMode(Awake) called
NMPassive NMActive
NMNormalPassive
NMPassive
NMNormalPassivPrepSleep
txcounter > tx_limit
Time-Out (TMax) at ring message
GotoMode(BusSleep) called and a ring message with a set bit sleep.ack received
ring message with a set bit sleep.ack transmitted
NMTwbsNormal
wait T WaitBusSleep disable application communication by D_Offline
NMLimpHome
NMReset
any NM message with a cleared bit Sleep.ind received or GotoMode(Awake) called
timer runs down
NMBusSleep
Figure 28
State transition diagram of NMNormal
by OSEK/VDX
Page 43
OSEK/VDX
OSEK/VDX
NMAwake
NMNormal
NMReset
NMInitLimpHome
disable application communication by D_Offline initialize the hardware by D_Init(...;BusRestart) start TError to transmit the 1st limp home message any NM message with a cleared bit sleep.ind received or GotoMode(Awake) called
NMLimpHome
NMLimpHomeActive
NMActive - send limp home message cyclically (TError) - enable cyclically application communication (TError) by D_Online
NMLimpHomeActivePrepSleep
NMLimpHomeStandard
NMPassive
NMActive
GotoMode(BusSleep) called and service to transmit NMPassive limphome message (bit sleep.ind is set) called GotoMode (BusSleep) called
NMActive
NMPassive
NMLimpHomePassive
enable cyclically application communication (TError) by D_Online
NMLimpHome PassivePrepSleep
GotoMode(Awake) called
NMPassive and { (GotoMode(Awake) called and NM message received) or [GotoMode(BusSleep) called and any NM message with a cleared bit sleep.ack received] }
NMActive and { limphome message transmitted and [ (GotoMode(Awake) called and any NM message received) or (GotoMode(BusSleep) called and any NM message with a cleared bit sleep.ack received) ] }
GotoMode(BusSleep) called and any NM message with a set bit sleep.ack received any NM message with a cleared bit Sleep.ind received or GotoMode(Awake) called disable application communication by D_Offline
NMTwbsLimpHome
wait TWaitBusSleep timer runs down
NMReset
NMBusSleep
Figure 29
Page 44
State transition diagram of NMLimpHome

by OSEK/VDX NM Concept & API 2.5.2
OSEK/VDX
OSEK/VDX
2.2.8.2. SDL Diagrams
The specified behavior is represented by the state transition diagrams. This chapter describes a proposed SDL realization. Hints The following abbreviations are used: sleep.ind sleep.ack networkstatus.bussleep the bit "sleep.ind" from the actual received or transmitted NM message the bit "sleep.ack" from the actual received or transmitted NM message the bit of the network status "service GotoMode(Awake) called" or "service GoToMode(BusSleep) called"
by OSEK/VDX
Page 45
OSEK/VDX
OSEK/VDX
Start-up of the network

Startup
NMOn NMOff 0
Leave NMBusSleep StopNM StartNM 3 networkstatus. NMactive = 1 NMInit sleep.ind:=0 sleep.ack:=0
carry out shutdown activities
initialise the hardware D_Init (...;BusAwake) true false
NMInit initialise the hardware D_Init (...;BusInit) NMOff Leave NMLimpHome 5 send an alive message
config.limphome := 0
- CancelAlarm(TError) - NMMerker.limphome := 0
NMtxcount := NMtxcount +1
NMInitReset
NMrxcount := 0 NMtxcount := 0 Leave NMNormal 6 enable application communication (D_Online) NMrxcount <= rx_limit AND OPTIONAL NMtxcount <= tx_limit
false
true
from bus off or normal config.present := own station logical successor :=own station 1 SetAlarm(TTyp)
NMrxcount := NMrxcount + 1 SetAlarm(TError) Initialise the NMPDU (Data,Opcode)
NMLimpHome
NMNormal
Figure 30
Start-up of the network
Page 46
by OSEK/VDX
OSEK/VDX
OSEK/VDX
State NMOn
NMOn
NMActive
NMPassive
NMBusSleep
SilentNM
TalkNM
GotoMode (Awake) called
wakeup signal of the bus (D_status.ind)
disable application communication (D_Offline)
networkstatus. NMactive := 0
networkstatus. NMactive := 1
initialise the hardware D_Init (...;BusRestart)
NMPassive
NMActive
NMInit
1 enter state NMLimpHome
Figure 31
Transitions between NMActive and NMPassive, wake up from NMBusSleep, and bus off event.
by OSEK/VDX
Page 47
NMNormal NormalStandardNM
NMNormal
OSEK/VDX
State NMNormal
Page 48
any NM message received Time-out TTyp Time-out TMax GotoMode(BusSleep) Normal StandardNM NMInitReset CancelAlarm (TMax) SetAlarm (TMax) networkstatus. NMactive = 1 6 networkstatus. NMactive = 1 sleep.ack = 1 true false false true else networkstatus. bussleep = 1 true false false true Send ring message Send ring message with set sleep.ind bit networkstatus. bussleep = 1 NMtxcount++ true false NMtxcount > tx_limit false true NMMerker.stable =1 1 Enter state NMLimpHome true NMNormal 2 NMInitBusSleep NMNormal networkstatus. configurationstable := 1 NMMerker.stable := 1 false NMNormal PrepSleep NMNormal NMNormal
Figure 32
any NM message transmitted
NMtxcount := 0
message type
ring
OSEK/VDX
CancelAlarm (TTyp) CancelAlarm (TMax) SetAlarm (TMax)
sleep.ind = 1
Actions during the state NMNormal and transitions to leave the state NMNormal
by OSEK/VDX
false
true
networkstatus. bussleep = 1
true
false
sleep.ack := 1
NMNormal
NMNormal PrepSleep
NMNormal
OSEK/VDX
OSEK/VDX
State NMNormalPrepSleep
NMNormalPrepSleep
NMNormal PrepSleep
Time-out TTyp
any NM message received
ring message transmitted
networkstatus. NMactive = 1
sleep.ind = 0
NMInitBusSleep 2 true
false
true
true
false
Send ring message with set sleep.ack bit
SetAlarm(Twbs)
NMNormal
NMNormal PrepSleep
NMNormal
NMNormal PrepSleep
NMTwbsNormal
Figure 33
Actions during the state NMNormalPrepSleep and transitions to leave the state NMNormalPrepSleep
by OSEK/VDX
Page 49
OSEK/VDX
OSEK/VDX
NMTwbsNormal
State NMTwbsNormal
NMTwbsNormal
Time-out Twbs
received any NM message
initialize the sleep mode of the bus hardware D_init(...;BusSleep)
sleep.ind = 0 true
false
CancelAlarm(Twbs)
NMBusSleep
NMTwbsNormal
6 NMInitReset
Figure 34
Transitions to leave state NMTwbsNormal
Page 50
by OSEK/VDX
OSEK/VDX
NMLimpHome NMLimpHome
Figure 35
State NMLimpHome
Time-out TError
any NM message transmitted
enable application communication (D_Online) message type false limphome other
OSEK/VDX
true
networkstatus.
NMMerker.limphome := 1
NMMerker.limphome =1
bussleep = 1
true
false
false
true networkstatus. bussleep = 1
Actions during the state NMLimpHome and transitions to leave the state NMLimpHome
by OSEK/VDX
SetAlarm (TMax) networkstatus. NMactive = 1 NMInitBusSleep true 7 send limphome message with set bit sleep_ind NMPrepSleep NMLimpHome
SetAlarm(TError)
false
true
NMInitReset
sleep.ack = 1
false
true
false
true false
send limphome message
Page 51
NMLimpHome
SetAlarm (Twbs)
NMTwbsLimpHome
OSEK/VDX
OSEK/VDX
NMLimpHomePrepSleep
State NMLimpHomePrepSleep
NMLimpHome PrepSleep
Time-out TMax at ring message
sleep.ind =0
false
true
NMLimpHome
NMLimpHome PrepSleep
NMLimpHome
7 NMInitBusSleep
Figure 36
NMLimpHomePrepSleep
Page 52
by OSEK/VDX
OSEK/VDX
OSEK/VDX
State NMTwbsLimpHome
NMTwbsLimpHome
NMTwbsLimpHome
Time-out Twbs
CancelAlarm (Twbs)
sleep.ind = 0
initialize the sleep mode of the bus hardware D_init (...;BusSleep)
true
false
CancelAlarm (Twbs)
NMLimpHome
NMLimpHome
NMTwbsLimpHome
NMBusSleep
Figure 37
Transmissions to leave the state NMTwbsLimpHome
by OSEK/VDX
Page 53
OSEK/VDX
OSEK/VDX
Procedure NormalStandardNM
Procedure NormalStandardNM
Clear NMrxcount
message type ring or alive limphome
add sender to config.present
add sender to config.limphome
determine logical successor
message type ring alive
CancelAlarm (TTyp) CancelAlarm (TMax)
NMMerker.stable := 0 networkstatus. configurationstable := 0
destination station to me OR destination = source true false
SetAlarm (TTyp)
SetAlarm (TMax)
determine if skipped in the logical ring
skipped in the logical ring
false
true
true
networkstatus. bussleep = 1
false
false
true
send an alive message
send an alive message with set bit sleep.ind
Figure 38
Actions during NMNormalStandard
Page 54
by OSEK/VDX
OSEK/VDX
OSEK/VDX
DLL transmit rejection, GotoMode(Awake) and GotoMode(BusSleep)

NMNormal BusSleep and Wakeup
NMNormal
NMNormal * *
the DLL refected the command to send actual NM message (ring or alive)
Time-out Ttx GotoMode (Awake) GotoMode (BusSleep)
SetAlarm(Ttx)
Send actual NM message (Ring or Alive) networkstatus. bussleep := 0 networkstatus. bussleep := 1
NMNormal
NMNormal -
Figure 39
DLL transmit rejection and GotoMode(Awake/BusSleep)
by OSEK/VDX
Page 55
OSEK/VDX
OSEK/VDX
Indication of Ring Data, Configuration and Status

RingData, Configuration and Status indication
Set Timer TTyp
NM Status changed
at least one bit of the network Config changed
RingData.ind
NOT (SMask AND (TestStatus EXOR RefStatus))
NOT (CMask AND (TestConfig EXOR RefConfig))
false *
true
false
true
Status.ind
Config.ind
Figure 40
Indication of ring date, configuration and network status
2.2.9. Alarms inside the Network Management
2.2.9.1.
Rules to design the alarms TTyp and TMax
The definition of the logical ring requires, that no alarm TMax may run down, if a ring message is passed delayed with TTyp. This derives a requirement to the precision of the alarms inside a networked system (the transmission time of a message and the runtime of the software are not taken into consideration):
TMax K
>
T
Typ
K , J [0; N -1]
Page 56
by OSEK/VDX
OSEK/VDX
OSEK/VDX
TTyp,B A B
ring message NMNormal
Figure 41
B C
ring message NMNormal
node B
Effect of the condition TMax K > TTyp K , J [0, N -1] .

TMax,D D node D
alive message NMReset
condition TRUE: The Node D recognizes the correct running of the logical ring. condition FALSE: The node E recognizes the failure of another node although the ring is running perfectly.
t
TMax,E E node E
The failure of a monitored node has to be recognized by all the other nodes inside the logical ring. All nodes have to be in NMNormal again, when the 1st ring message is transmitted after NMReset. This derives a requirement to the precision of the alarms inside a networked system (the transmission time of a message and the runtime of the software are not taken into consideration):
T
TTyp,A A B
last ring message NMNormal logical successor: B M is out of order
Max
+ TTyp
>
TMax J
K , J [0; N -1]
TMax,A A
TTyp,A A C
1st ring message NMNormal logical successor C
Figure 42 Effect of the condition
node A
T
Max
+ TTyp
K , J [0, N -1] .
>
TMax J
T Max,D D node D
alive message NMReseD
condition FALSE: The node D does not recognize the failure of the node B.
TMax,C C node C
alive message NMReset C
condition TRUE: The node C recognizes the failure of the node B.

t
by OSEK/VDX
Page 57
OSEK/VDX
OSEK/VDX
Each of this alarms has to be provided with a tolerance (...min and ...max) for every node. Inside a network all nodes must meet both requirements:
T
Max min
+ TTyp
min
>
T
Max max
K , J [0; N -1] K , J [0; N -1]
T
2.2.9.2.
Max min
>
T
Typ max
Rules to design the alarm TError
No important requirements for the alarm TError, which should be taken into consideration, exist. A useful value of the alarm TError is the value of TTyp multiplied by 10. Tolerance calculations are insignificant.
2.2.9.3.
Rules to design the alarm TWaitBusSleep
After the successful transmission of the ring message with a set bit sleep.ack, there still can be user messages in the transmit queues. Nodes in the state limp-home are transmitting limphome messages delayed by TError. Several limp-home messages can be received in this time period thus a transition in the state NMBusSleep is possible without trouble. The timer TWaitBusSleep is defined in addiction to the timer TError. TWaitBusSleepmin TErrormax should be valid network wide. TWaitBusSleep is selected typically to 1.5 times of TError.
2.2.9.4.
Design of a system
System requirements result from the requirements to the single alarms. recognizing a node failure: recognizing the logical ring:
DTMax = TTyp
min
fS
0 < fS < 1 0 < fR < 1
TTyp
max
= TMax
min
fR
The tolerances of both alarms should be adapted to each other. precision: DTTyp = DTMax f ,
Page 58
by OSEK/VDX
OSEK/VDX
OSEK/VDX
The solution to determine the system requirements is:
TTyp
max
= TTyp
= TTyp
min
1+ f S f ,
1+ f S f , fR
TMax
min
min
TMax
max
= TTyp
min
1+ f S f , fS + fR , f S , f R , f , inside the whole network.
The designer of a system has to fix the values TTyp
min
2.2.9.4.1.
Worst Case
The worst case design points out the limit of the logical ring. The tolerances are selected for the perfect running of the logical ring in case of ideal communication system (e.g. the transmission time of a message and the runtime of the software disappears). recognizing a node failure: recognizing the logical ring: precision: worst case system requirements:
DTMax = TTyp
TTyp
max
min
fS = 1 fR = 1
= TMax
min
DTTyp = DTMax f ,
1+ f , TMax min = TTyp 1+ f , min TMax max = TTyp 2+ f , min
TTyp
max
= TTyp
min
TTyp,min
f, TTyp,min allowed range of TTyp
TTyp,min allowed range of TMax t TTyp,max TMax,min TMax,max
Figure 43 Worst case system design of the alarms inside the NM.
TTyp,min
2.2.9.4.2.
Example
min
The designer of the system fixed the values TTyp TTyp

min
, f S , f R , f , exemplary.
f R = 0.5 f , = 0.62
= 70ms
f S = 0.92
The system wide minimum and maximum values of the alarms TTyp and TMax result from the fixed values TTyp , f S , f R , f , :
min
by OSEK/VDX
Page 59
OSEK/VDX
OSEK/VDX
=110ms
TTyp
max
TMax
min
=220ms
TMax
max
=284ms
Every node has to guarantee that their alarms remain inside the fixed limits.
Example: System design TTyp = 70ms ... 110ms TMax = 220ms ... 284ms TError = ... 1s ... TWaitBusSleep = ... 1.5s ...
3.
Indirect Network Management
According to system design aspects, direct monitoring of the nodes may be impossible or nondesirable. This could be the case for example for very simple or time-critical applications. Therefore mechanism of indirect monitoring is introduced. This network management is based on the use of monitored application messages. Therefore indirect monitoring is limited to nodes that periodically send messages in the course of normal operation. In this case, a node emitting such a periodical message is monitored by one or more other nodes receiving that message. Nodes whose normal functionality is limited to receiving must send a dedicated periodic message in order to be monitored.
3.1. Concept
3.1.1. Node Monitoring

Indirect network management uses monitoring of periodic application messages to determine states of nodes connected to the network. It does not make use of dedicated network management messages.
3.1.1.1.
Emitter states
Node states
For a given node i, emitter states are used to check that node i, which is supposed to emit information on the bus, is indeed able to transmit. node is not mute
specific application message transmitted
Page 60
by OSEK/VDX
OSEK/VDX
OSEK/VDX
node is mute
specific application message not transmitted during a time-out
Node state "mute" can be extended to several state types (see "Extended node states").
Receiver states
A given node i monitors a subset of k nodes on the network: node i monitors only source nodes, from which it receives cyclic application messages. Therefore, node i will maintain a set of k receivers states, where k is the number of source nodes monitored by node i. Receiver states are used to check that node i, which is supposed to receive information from its k other source nodes, indeed receives information from each of its sources. node is present node is absent

specific application message received specific application message not received during a time-out
Node state "absent" can be extended to several state types (see "Extended node states").
3.1.1.2.
Extended Node states
Extended Emitter states
node is not mute statically node is mute statically
specific application message transmitted specific application message not transmitted during a "long" time (several time-outs)
Extended Receiver states
node is present statically node is absent statically
specific application message received specific application message not received during a "long" time (several time-outs)
3.1.2. Configuration-Management
3.1.2.1.
Configuration
The configuration puts together the node states of all the monitored nodes determined by the NM.
Target Configuration
The application recognizes node failures by comparison of the configuration (determined by the NM) with a target configuration. This target configuration may normally change depending on vehicle operation (e.g. nodes can appear and disappear from the network depending on ignition switch position).
by OSEK/VDX
Page 61
OSEK/VDX
OSEK/VDX
Remark
The target configuration is not located inside NM. Several target configurations and several masks can be pre-programmed in the application. By using these masks depending on vehicle operation, the application is then able to filter information provided by NM by itself and recognize node failures.
3.1.2.2.
Extended Configuration
The extended configuration puts together the extended node states of all the monitored nodes determined by the NM.
3.1.3. Standard Task
3.1.3.1.
Network status
The Network status is a set of information relating to local node hardware interface operation and local NM internal operating states.
Network Status Interpretation
Operating mode of network interface Operation modes
0 1 0 1 0 1 0 1 0 1
No error1) Error, Bus blocked2) NMOn NMOff no NMLimpHome NMLimpHome no NMBusSleep NMBusSleep no NMWaitBusSleep NMWaitBusSleep
Table 8
Encoding of the network status and transmission of application messages successful 2) e.g. CAN-busoff
1) Reception
3.1.3.2.
Extended network status
The extended Network status is specific to the user.
Page 62
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Network Status
Interpretation
Operating mode of network interface
00 01 10 11
No error1) Error, Communication possible2) Error, Communication not possible3) reserved
... Table 9 Example of encoding of the extended network status. and transmission of application messages successful 2) communication via one wire 3) e.g. CAN-busoff for a "long" time
1) Reception
3.1.4. Monitoring Mechanisms

In order to evaluate node states and network status, Indirect Network Management provides three non-exclusive mechanisms of monitoring.
A) transmission
Determination of the emitter states by using transmission monitoring scheme: transmission problems are detected by checking local confirmations related to transmissions of a unique periodic application frame chosen among those to be sent. This local confirmation is used to set the emitter states accordingly.
Example If a message is correctly transmitted in case of CAN, it is then acknowledged on the bus. If the transmission fails, there is no acknowledgement and after a timeout, node i is considered "mute" by the NM. B) reception
Determination of the set of receiver states by using reception monitoring scheme : node i checks the presence of all its source nodes by monitoring the reception of a chosen cyclic frame per each remote source. If the supervised message of node k is not received at least once by node i before a configurable time-out, node k is then considered absent.
by OSEK/VDX
Page 63
OSEK/VDX
OSEK/VDX
message cycles
Source 1 Source 2
Present/Absent
Present/Absent
node i
. . .
Source k
Present/Absent
Figure 44
C) status signal
Reception monitoring
Determination of Network Interface status by using controller indications from communication Data Link Layer, which itself uses low level controller or driver information.
Example If the bus is blocked in case of CAN, controller indicates a "bus off" error to upper layers.
3.1.5. Monitoring time-outs

OSEK Indirect NM transmission and reception monitoring is based on two possible time-out monitoring mechanisms. all messages are monitored by one global time-out TOB (time-out for observation) each message is monitored by its own dedicated time-out.
3.1.5.1.
One global time-out
The global monitoring time-out is located inside NM and is used as a time-window observation. node present/not mute node absent/ mute at least one message has been transmitted or received from node k during the global time-out (time window observation) no message has been transmitted or received from node k during the global time-out (time window observation)
Page 64
OSEK/VDX
OSEK/VDX
The monitoring time-out has to be adapted to the longest time requirement among all the monitored application messages.
Hint
The global time-window observation is handled in the SDL diagrams by a private configuration and a public configuration.
3.1.5.2.
One monitoring time-out per message
In this case, Indirect NM uses "COM Deadline Monitoring"1 mechanisms to monitor dedicated application messages. Time-outs are located at Interaction Layer level. NM is informed dynamically by COM each time a message has been correctly transmitted or received, or a time-out has expired for this message. Each monitoring time-out can be adapted to the time requirements of each monitored application message.
3.1.5.3.
Internal Network Management States
The OSEK NM can enter the internal states listed hereafter:

NMOff NMOn
NM is switched off NM is switched on
NMOn:

NMBusSleep NMAwake
NM is in sleep mode Active state of the NM
NMAwake:

NMNormal NMLimpHome NMWaitBusSleep
Processing of indirect node monitoring Handling of failure in own node Synchronizing the network wide jump to the state BusSleep
see paper OSEK/VDX COM current version by OSEK/VDX Page 65
OSEK/VDX
OSEK/VDX
NMOff
StopNM called
StartNM called
NMOn NMBusSleep
GoToMode(Awake) called or wake-up signal from the bus Fatal Bus Error
NMAwake
Timer WaitBusSleep is running down transmission ok AND reception ok
NMNormal
GoToMode(Awake) called GoToMode(BusSleep) called
NMLimpHome
not supported
NMWaitBusSleep
GoToMode(BusSleep) called
Figure 45
NMLimpHome
Simplified state transition diagram of the indirect NM.
This state is entered after a failure of the network communication interface, communication not being operational (e.g. Bus-Off failure for CAN). Node states values (e.g. "node absent") do not switch NM to the state NMLimphome. NM only performs monitoring actions but has no knowledge about the expected target configuration - NM does not know if a missing node is a failure or not.
NMWaitBusSleep
This state is entered after the demand of the application for entering the BusSleep mode. It is a waiting state preparing for BusSleep mode. During this time, all other nodes have to receive the SleepMode command via their application2 as well.
see chapter "User guide" Page 66 by OSEK/VDX NM Concept & API 2.5.2
OSEK/VDX
OSEK/VDX
3.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
In NMAwake the node monitors the selected application messages.

NMBusSleep If a node is in NMBusSleep, it does not monitor application messages. Depending on the hardware integrated in the networks, nodes can switch into some low power mode.
The NM provides services for: selection of NM operation modes, and indication of NM operating modes.
3.2. Algorithms and behavior

The NM supports the configuration and the optional extended configuration management. The extended configuration is specified by monitoring application messages with a "long" time. This "long" time is realized by using counters.
3.2.1.1.
Counter management
The states of the extended configuration are determined by decremeting and incrementing3 specific counters and by comparing the counters with a threshold. From the point of view of the functionality one of the values is redundant and can be selected statically. Therefore OSEK NM sets the threshold to a constant value.
The functions used to increment and decrement shall avoid any overflow and underflow. by OSEK/VDX Page 67
OSEK/VDX
OSEK/VDX
Timeout at monitoring a message from node k
message from node k received
INC counter by DeltaInc 0 ... threshold
DEC counter by DeltaDec 0 ... threshold
yes counter = threshold ?
no
node static absent
node static present
Figure 46
Extended configuration illustrated at node k.
Counter behavior and corresponding states are illustrated by the three following figures.
Page 68
by OSEK/VDX
OSEK/VDX
OSEK/VDX
message received from remote node k
message received from remote node k time-out expired time-out expired
Counter Threshold
,Inc ,Inc
,Dec ,Dec ,Dec
t state of node k
Present
Absent
Present
t extended state of node k

Static Present
Figure 47
Extended configuration illustrated at node k in the case of a very transient state of the node - the state "static absent" will not be reached.
by OSEK/VDX
Page 69
OSEK/VDX
OSEK/VDX

message received from remote node k
Time-out expired
Time-out expired
Time-out expired
Time-out expired
Time-out expired
Counter Threshold
Time-out
,Inc ,Inc ,Inc
,Dec ,Dec ,Dec ,Dec ,Dec
,Inc
state of node k
Absent
Present
extended state of node k

Static Present Static Absent Static Present
Figure 48
Extended configuration illustrated at node k in the case of a permanent state of the node.
Page 70
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Time-out expired Time-out expired
message received from node k Time-out expired Time-out expired Time-out expired
Counter Threshold
Time-out
,Inc ,Inc ,Inc ,Inc ,Dec ,Dec ,Dec ,Inc
0 state of node k
Absent
Present
Absent
t extended state of node k

Static Present Static Absent Static Absent
Figure 49
Extended configuration illustrated at node k in case of a repetitive state of the node.
OSEK Indirect NM static state detection algorithm is flexible and scaleable. It allows choosing different kinds of detection for static states by setting the parameters DeltaInc and DeltaDec at system generation time.
3.2.2. Operating Mode
3.2.2.1.
User Guide to handle BusSleep
The NM handles power down modes on demand of the user. Net-wide negotiations are not supported. Master slave and multi master behavior can be realized by using the given services - GotoMode(Awake) and GotoMode(BusSleep).
Example: Master - Slave
The user does reserve one bit in a application message which does the master broadcast to the slaves. bit is set bit is cleared
the master requires the mode NMBusSleep from all slaves the master does not require the mode NMBusSleep from any slave
by OSEK/VDX Page 71
OSEK/VDX
OSEK/VDX
application NMAwake in the master
NMBusSleep
set the reserved bit and send the corresponding message call GoToMode(BusSleep) after the message has been sent via the bus
call GoToMode(Awake) clear the reserved bit and send the corresponding message -
in the slave call GoToMode(BusSleep) when receiving the set bit call GoToMode(Awake) when receiving the cleared bit
Table 10
Example of the application behavior to handle NMAwake and NMBusSleep according to a master slave approach.
Hint
The master and the slave behaviors can be supported by a single implementation of the indirect NM.
Page 72
by OSEK/VDX
OSEK/VDX
OSEK/VDX
3.2.3. State Machine in SDL
3.2.3.1.
P ro c e s s In d ir e ct _ N M
SDL Model for one global time-out TOB

1 (4 )
In itC o n f ig
I n it N e tw o rkS t a tu s
In i tP riv a te C o n fig
a n y N M st a te
N M O ff
S topN M
S t a r tN M
P e rf o rm sh u t d o w n a c t ivit ie s
D _ In it ( N e tI d , B u s S h u td o w n )
P e r f o rm h a rw a re in it ia li za t io n
D _ In it ( N e tI d ,B u s In it )
D _ O n lin e (N e t Id )
N e tw o rk S ta t u s ! o p m o d e 1 := N M O f f
S e t T im e r( T O B )
N M O ff
In itP riv a te C o n f ig
R e m ark : S D L l a n g u a g e d o e s n o t h a n d le h ie r a rc h ic a l s ta t e s. I n it C o n f ig T h e re fo re , c o n c e p tu a l st a te s N M O n a n d N M A w a ke d o n o t a p p e a r a s S D L - st a t e s in th is m o d e l. T h is d e scr ip tio n d ire c tly re fe rs to b o t to m -s u b st a t e s .
I n it N e t w o rkS ta t u s
N M N o rm a l
Figure 50
Handling of the services StartNM and StopNM
by OSEK/VDX
Page 73
OSEK/VDX
OSEK/VDX
Process Indirect_NM
2(4)
NMNormal
Time-out for Observation expired
TOB
monitored application message received from remote node or m onitored a ppli cation message transm itted by own node
I_MsgTran sfer.i nd (Send er)
Last private co nfig is saved into "Config"
Config := PrivateConfig
Determine Node Id and NetId fro m Sender information
NMNetNodeMap ping (Sender,Nodek,Netk)
InitPrivate Config
Update private config : If (Node k = own node) then Node k is "not mute " else Node k is "present"
PrivateConfig(Nodek) := True
SetTimer (TOB)
Ne tworkStatus!opmode2 := noLimphom e, Ne tworkStatus!interface := noError
NMNormal
Figure 51
Handling of the events "TOB" and "message received" during state NMNormal
Page 74
by OSEK/VDX
OSEK/VDX
OSEK/VDX
P ro ces s Ind ir ect_N M
3 (4)
N M Lim p hom e
Tim e- ou t for O b s erv a tion e xpir ed
TO B
m on itor ed a pplic ation m e ss a ge re ce iv ed fro m r em ote n ode o r m onitor ed a ppli catio n me s sa ge tra nsm itted b y own n od e
I_M s gT r an sfer .i nd (S e nd er )
La st p riv ate c on fig i s sa ved into "C on fi g"
C on fig := P riva teC onfig
D eter m ine N od e Id an d Ne tId fro m Se nd er in fo rm a tion
NM N etN ode M ap pin g (S en de r,N ode k ,Ne tk)
InitP riva teC onfig
U pd ate pr iva te c on fig : If (N od e k = ow n nod e) the n N od e k is "no t m ute" els e N ode k is "pre se nt"
P riv ateC on fig (N od e k) := T r ue
Se tTim e r (TO B ) tr ue T x O K := T r ue
No de k = M yO w nN o de fals e R xO K := T r ue
NM e xits fro m Li m pho m e s ta te if own no de m e ss a geh as be e n tr ans m itte d and on e me s sa ge h as been re cei ved fro m a m o nitor ed r em ote no de
fals e
( T xO K = tr ue) a nd ( R xO K = tru e) tr ue Ne twor k Statu s!o pm od e2 := n oLim p hom e, Ne twor kS tatu s!inter fac e := no Er ro r
N M N or ma l
Figure 52
Handling of the events "TOB" and "message received" during NMLimpHome
by OSEK/VDX
Page 75
OSEK/VDX
OSEK/VDX
Process Indirect_NM
NMNormal, NMLimphome
any NMAwake state
NMLimphome
Fatal bus error example : BusOff for CAN
D_Status.ind (NetId,Error)
Terror
NetworkStatus!opmode2 := Limphome NetworkStatus!interface := CommunicationNotPossible
Enable transmissions
D_Online(NetId)
Disable transmissions
D_Offline(NetId)
Restart hardware
D_Init (NetId,BusRestart)
SetTimer (Terror)
RxOK := false, TxOK := false
NMLimphome
Figure 53
P ro c e d u r e I n i tC o n f ig
Handling of a fatal bus error

P r o c e d u r e I n itP r iv a t e C o n f ig
A t in i t ia l iz a t i o n , o w n n o d e is c o n s id e r e d "m u t e " a n d a ll s u p e rv is e d re m o te n o d e s a re c o n s i d e r e d " a b s e n t "
fo r k = 1 ,N N o d e M a x C o n fi g ( k ) : = F a ls e
A t in it ia liz a t io n , o w n n o d e is c o n s id e r e d " m u te " a n d a ll s u p e r v is e d r e m o te n o d e s a re c o n s id e re d "a b s e n t"
for k = 1 ,N N od eM ax P riv a te C o n fi g ( k ) : = F a
Figure 54
Initialization of the configuration
Page 76
by OSEK/VDX
OSEK/VDX
OSEK/VDX
P ro ce d u re I n itN e t w o r k S t a tu s
N e t w o rk S ta t u s ! i n te rf a c e : = n o E r ro r , N e t w o rk S ta t u s ! o p m o d e 1 : = N M O n , N e t w o rk S ta t u s ! o p m o d e 2 : = n o N M L im p h o m e , N e t w o rk S ta t u s ! o p m o d e 3 : = n o N M B u s S le e p , N e t w o rk S ta t u s ! o p m o d e 4 := n o T W a itB u s S le e p
Figure 55
Initialization of the NM status
by OSEK/VDX
Page 77
OSEK/VDX
OSEK/VDX
3.2.3.2.
P ro ces s Ind ire ct_ N M
SDL Model for one monitoring time-out per message

1 ( 6)
Ini tC on fig
In i tN e tw o rk Sta tu s
I ncC on fig C ou n t
D e cC o n figC o u n t
Ini tE xte n de d C on fig
Ini tE xte n de d N et w o rk Sta tu s
In cS ta tus C o u n t
D e cS tatu s C o u n t
a n y N M s tat e
N M N or m al, N M L im p ho m e N M W a itB u sS le ep
a n y N M A w ak e s t ate
N M O ff S to p N M In i tC o n fig
S tar tN M Pe rfo rm sh u td ow n a c tivitie s
P e rfo rm h ar w a re in itia liza ti o n
D _ In it (N e tId ,B u sIn it )
D _ In it ( N e tId ,B u s S h utd ow n )
In i tE xte n d e d C on fig
D _ O nl in e ( N e tId )
N et w o rkS ta tus !o p m od e 1 := N M O ff
In itC o n fig
N M O ff
In itE xte nd e d C o n fig
In itN e tw ork S ta tu s
In itE xte nd e d N e tw o rk S ta tu s
N M N or m al
Figure 56
Handling of the services StartNM, StopNM and InitConfig
Page 78
by OSEK/VDX
OSEK/VDX
OSEK/VDX
P ro ce s s In d ire ct _ N M
2 (6 )
N M N o rm a l
T im e -o u t a t m o n it o rin g a p p lic a t io n m e s s a g e f r o m r e m o t e n o d e e xp ir e d o r t im e - o u t a t m o n it o r in g t ra n s m i ss io n o f o w n a p p lica ti o n m e ss a g e e xp ir e d
I _ M sg T im e o u t .in d ( S end er )
m o n it o re d a p p lica tio n m e s s a g e r e c e iv e d f ro m re m o te n o d e o r m o n it o re d a p p lic a t io n m e s s a g e t ra n s m it te d b y o w n n o d e
I_ M sg T ra n s fe r. in d (S e n d e r )
D e te rm in e N o d e Id a n d N e t Id fr o m S e n d e r in f o r m a ti o n
N M N e tN o d e M a p p i n g (S e n d e r ,N o d e k ,N e t k )
D e t e rm in e N o d e Id a n d N e t Id f ro m S e n d e r in f o r m a ti o n
N M N e tN o d e M a p p i n g ( S e n d e r ,N o d e k ,N e t k )
I f (N o d e k = o w n n o d e ) t h e n N o d e k is " m u t e " e l se N o d e k is " a b se n t "
C o n f ig ( N o d e k ) : = F a lse
If ( N ode k = o w n no de) th en N o d e k is "n o t m u t e " e ls e N o d e k is " p r e s e n t"
C o n f ig (N o d e k ) := T r u e
I n c C o n f ig C o u n t If (N o d e k = o w n n o d e ) t h e n N o d e k is "s t a t ic m u te " e ls e N o d e k is "s t a t ic a b se n t" C o u n t e r( N o d e k) = T h re s h o ld
D e cC o n f ig C o u n t
tr u e
f a lse
If ( N ode k = o w n no de) th en N o d e k is s t a t ic n o t m u te e ls e N o d e k is st a t ic p r e s e n t
E xt e n d e d C o n f ig (N o d e k ) := T r u e
E xt e n d e d C o n f ig (N o d e k ) := F a lse
E x te n d e d C o n f ig ( N o d e k) := T r ue
N e t w o rk S ta tu s !o p m o d e 2 : = n o L im p h o m e , N e t w o rk S ta tu s !in t e rf a c e : = n o E rr o r
E xte n d e d N e tw o rk S t a t u s ! in t e r fa ce := n o E r ro r
D e cS t a t u s C o u n t
Figure 57
Handling of the events "timeout for message" and "message received" during state NMNormal
by OSEK/VDX
Page 79
OSEK/VDX
OSEK/VDX
P ro c e s s In d ire c t _ N M
3 (6 )
N M L im p h o m e
T im e -o u t a t m o n it o rin g a p p lic a t io n m e s s a g e f r o m r e m o t e n o d e e xp ir e d o r t im e - o u t a t m o n it o r in g t ra n s m i s s io n o f o w n a p p lic a ti o n m e s s a g e e x p ir e d
I _ M sg T im e o u t .in d (S end er)
m o n it o re d a p p lic a tio n m e s s a g e r e c e iv e d f ro m re m o te n o d e o r m o n it o re d a p p lic a t io n m e s s a g e t ra n s m it te d b y o w n n o d e
I_ M s g T ra n s fe r. in d (S e n d e r )
D e te rm in e N o d e Id a n d N e t Id fr o m S e n d e r in f o r m a ti o n
N M N e tN o d e M a p p i n g (S e n d e r ,N o d e k ,N e t k )
D e t e rm in e N o d e Id a n d N e t Id f ro m S e n d e r in f o r m a ti o n
N M N e tN o d e M a p p i n g ( S e n d e r ,N o d e k ,N e t k )
I f (N o d e k = o w n n o d e ) t h e n N o d e k is " m u t e " e l se N o d e k is " a b s e n t "
C o n f ig ( N o d e k ) : = F a ls e
If ( N o de k = o w n n o d e) th e n N o d e k is "n o t m u t e " e ls e N o d e k is " p r e s e n t"
C o n f ig (N o d e k ) := T r u e
I n c C o n f ig C o u n t If (N o d e k = o w n n o d e ) t h e n N o d e k is "s t a t ic m u te " e ls e N o d e k is "s t a t ic a b se n t" C o u n t e r( N o d e k) = T h re s h o ld
D e c C o n f ig C o u n t
tr u e
f a ls e
If ( N o de k = o w n n o d e) th e n N o d e k is " s ta tic n o t m u t e " e ls e N o d e k is " s ta tic p re se n t "
E x t e n d e d C o n f ig (N o d e k ) := T r u e
E xt e n d e d C o n f ig (N o d e k ) := F a ls e
E x te n d e d C o n f ig ( N o d e k ) := T r ue t ru e
N ode k = M y O w n N o de f a ls e
T x O K := T ru e -
R x O K := T r u e
f a ls e N M e x it s f ro m N M L im p h o m e s t a t e if o w n n o d e m e s s a g e h a s b e e n t r a n s m itt e d a n d if o n e m e s s a g e h a s b e e n re c e iv e d f ro m a m o n it o r e d r e m o t e n o d e
(T x O K = tr u e ) and (R x O K = t r u e ) tr u e N e t w o rk S ta tu s !o p m o d e 2 : = n o L im p h o m e , N e t w o rk S ta tu s !in t e rf a c e : = n o E rr o r
E x te n d e d N e tw o rk S t a t u s ! in t e r fa c e := n o E r ro r
D e cS t atu s C o u n t
N M N orm al
Figure 58
Handling of the events "timeout for message" and "message received" during state NMLimpHome
Page 80
by OSEK/VDX
OSEK/VDX
OSEK/VDX
P ro ces s In d ire ct_ N M
4 (6 )
N M N o rm a l, N M L im ph o m e, N M W a itB u s S le e p
a n y N M A w ak e st a te N M L im p h o m e
F ata l b us e r ror e xa m ple : B u sO f f fo r C A N
D _ S ta tu s.in d (N e tId ,E rr o r )
T e r ror
N e tw o r kS ta tu s !o pm o d e 2 := L im p ho m e N e tw o rk S ta tu s !in te r fac e := C o m m un ica tio n N o t Po s sib le
E n ab le tr a n sm is si on s
D _ O n lin e (N et Id )
N e tw o r kS ta tu s !o pm o d e 4 = T W aitB us S le ep f a lse D i sa b le tr an s m is s io n s D _ O ffl in e (N e tId )
tr u e
B u sS le ep c om m a n d w a s cal le d b e fo re err o r o c cu r ed
N M W a itB u sS le ep
R e s t ar t h a rd w ar e
D _ In it ( N e tId ,B u sR e st a rt)
Se tT i m er ( Te rr o r )
R x O K : = fa l se, T x O K := fa lse
In c S ta tu sC o u n t
C o unt = T h re s ho ld t ru e
fa ls e
co m m u n ica ti on is st a tic n ot p os s ib le
E xte n de d N e tw o rk S ta tu s! in te rf a ce := C o m m u n ic a tio n N o tP o ss ible
E xte nd e dN e tw o rk S ta tu s! in te rfa ce := n o E r ro r
N M Li m ph o m e
Figure 59
Handling of a fatal bus error
by OSEK/VDX
Page 81
OSEK/VDX
OSEK/VDX
Process Indirect_NM
5(6)
NMNormal, NMLimphome
NMWaitBusSleep
Sleep mode command received from the application
GoToMode (NetId,BusSleep)
TWaitBusSleep
GoToMode (NetId,BusAwake)
Wake-up command from the application
D_Offline(NetId)
Turn hardware into low power mode
D_Init(NetId,BusSleep)
D_Online(NetId)
SetTimer (TWaitBusSleep) NetworkStatus!opmode4 := noTWaitBusSleep NetworkStatus!opmode4 := TWaitBusSleep NetworkStatus!opmode3 := NMBusSleep NMWaitBusSleep NMNormal NetworkStatus!opmode4 := noTWaitBusSleep
NMBusSleep
Figure 60
Handle the transition to the state NMBusSleep
Page 82
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Process Indirect_NM
NMBusSleep
Wake-up signal received from the bus
D_Status (NetId,WakeUp)
GoToMode (NetId,Awake)
Wake-up command received from the application
NetworkStatus!opmode3 := noNMBusSleep
D_Init(NetId,BusAwake)
D_Online(NetId)
NMNormal
Figure 61
Handle the transition from NMBusSleep into NMNormal
by OSEK/VDX
Page 83
OSEK/VDX
OSEK/VDX
P ro c e d u r e I n itC o n f ig
P r o c e d u r e I n itE x te n d e d C o n f ig
A t in it ia liz a t io n , o w n n o d e is c o n s id e r e d "m u t e " a n d a ll s u p e rv is e d re m o te n o d e s a re c o n s i d e r e d " a b s e n t "
fo r k = 1 ,N N o d e M C o n fi g ( k ) : = F a l
o w n n o d e is c o n s id e r e d "s t a t ic n o tm u t e " a n d s u p e r vis e d r e m o te n o d e s a r e a ll co n si d e re d " s ta tic p re se n t "
f o r k= 1 ,N N Ex tend ed C o nfi
e a ch c o u n t e r is s e t t o 0
f o r k= 1 ,N N C o u n te r (k
Figure 62
Initialization of the configuration

P r o c e d u r e I n i tE x te n d e d N e t w o r k S ta tu s
P ro ce d u re I n itN e t w o r kS t a tu s
N e t w o rk S ta t u s! i n te rf a c e : = n o E r ro r , N e t w o rk S ta t u s! o p m o d e 1 : = N M O n , N e t w o rk S ta t u s ! o p m o d e 2 : = n o N M L im p h o N e t w o rk S ta t u s ! o p m o d e 3 : = n o N M B u sS le N e t w o rk S ta t u s ! o p m o d e 4 := n o T W a itB u s S
n e t w o r k i n te r f a c e c o m m u n i c a t i o n is c o n s id e re d s t a t ic o p e r a b l e a t i n it i a li z a ti o n
E x t e n d e d N e tw o r k S t a t u s : = n o E r ro r
C o u n t:=0
Figure 63
Initialization of the NM status
Page 84
by OSEK/VDX
OSEK/VDX
OSEK/VDX
P ro ced u re IncC on figC ou nt
P ro c e d u re D e c C o n f ig C o u n t
true
C ou nter( N ode k ) <= Th re sh old - D elta In c(n od ek)
false
tr u e
C o u n t e r (N o d e k ) > = D e lta D e c (N o d e k ) f a ls e
C ou n te r( No dek ) := C ou nter(N od ek) + D eltaInc (N od ek)
Co unter(N od ek ) := T hre s hold
C o u n t e r (N o d e k ) := C o u n te r( N o d e k )- D e lt a D e c (N o d e k )
C o u n te r(N o d e k ) : = 0
Figure 64
Decrement and increment procedures for the extended configuration

P ro c e d u r e D e c S ta t u s C o u n t
P r o c e d u re In cS ta t u s C o u n t
tr u e
Coun t <= T h re s h o ld - D e lta I n c
f a ls e
tr u e
C ou nt > = D e l ta D e c
f a ls e
C o u n t := C o u n t +D e lta In c
C o u n t := T h re sh o ld
C o u n t : = C o u n t-D e lta D e c
C o u n t := 0
Figure 65
Decrement and increment procedures for the extended network status
4.
System generation and API
4.1. Overview
one word capital letter ABCDE... letter abcdef...
Figure 66 Syntax of a NM service. Example: GetConfig
by OSEK/VDX
Page 85
OSEK/VDX
OSEK/VDX

ISL Hook Level E r r o r H o o k P P S S r o t h e s a u T t r t a T t d s a H o k s o w H k o n o H k H o o o k o o k k Task Level T a s k
Service Call
dir. ind. NM NM
I S R
Core or Optional Service
Configuration management - Initialization of static parameter - Initialization of individual configurations masks - Initialization of individual target configurations - Indication of Configuration change - select the indication sensitivity - start or restart the configuration management - Make current configuration available - Comparison of two configurations Operating mode management - Initialization of individual status masks - Initialization of individual target states - Indication of Status change - Start of NM, i.e. transition to NM mode 'NMON'. - Stop of NM, i.e. transition to NM mode 'NMShutDown' and finally to 'NMOff' - Transition to NM mode 'NMPassive' without network-wide notification - Transition to NM mode 'NMActive' after a previous call of SilentNM - Transition to a new operating mode (e.g. BusSleep, Awake) - select the indication sensitivity - Get status information (network, node) - Comparison of two states Data Field management - Indication of received data - Transmit data - Read received data
InitDirectNMParams InitIndirectNMParams InitCMaskTable InitTargetConfigTable InitIndDeltaConfig SelectDeltaConfig InitConfig GetConfig CmpConfig InitSMaskTable InitTargetStatusTable InitIndDeltaStatus StartNM StopNM SilentNM TalkNM GotoMode SelectDeltaStatus GetStatus CmpStatus InitIndRingData TransmitRingData ReadRingData
OPT OPT OPT OPT OPT OPT OPT OPT OPT OPT OPT CORE CORE OPT OPT OPT OPT OPT OPT OPT OPT OPT
Table 11
Breakdown of NM API-services into core services and optional services. Call to the NM service is allowed in this level (Interrupt level ISL, Hook level and Task level)
4.2. Conventions for Service Description
4.2.1. System Generation

Within OSEK NM all system objects have to be determined statically by the user (fixed at compile time). There are no system services available to dynamically create system objects.
OSEK/VDX
OSEK/VDX
System objects have to be defined or declared for usage in the application programs' source using specific calls. The design of system objects may require additional specific tools. They enable the user to add or to modify values which have been specified. Consequently, the system generation and the tools are also implementation specific.
4.2.2. Type of Calls

System services are called according to the ANSI-C syntax. The implementation is normally a function call, but may also be solved differently, as required by the implementation - for example by C-pre-processor macros.
4.2.3. Error Characteristics

All system services return a status to the user. The return status is E_OK if it has been possible to execute the system service without any restrictions. If the system recognizes an exceptional condition which restricts execution of any system service, a different status is returned. If it is possible to exclude some real errors before run time, the run time version may omit the checking of these errors. If the only possible return status is E_OK, the implementation is free to not return a status. To keep the system efficient and fast, OSEK NM does not check for all possible errors. OSEK NM assumes debugged applications, and the correct usage of the system services. It must be expected that undetected errors in the application result in undefined system behavior. All return values of a system service are listed under the individual descriptions. The return status distinguishes between the Standard and the Extended status. The Standard version fulfils the requirements of a debugged application system as described before. The "Extended" version is considered to support testing of not yet fully debugged applications. It comprises extended error checking compared to the standard version. The sequence of error checking within the NM module is not specified. If multiple errors occur, the status returned depends on the implementation. In case of fatal errors, the system service does not return to the application. Fatal error treatment is performed by the operating system.
4.2.4. Structure of the Description

The descriptions of NM services are logically grouped. A coherent description is provided for all services of the configuration management, the management of operating modes and data field management.
NM Concept & API 2.5.2 by OSEK/VDX Page 87
OSEK/VDX
OSEK/VDX
The description of each of these logical groups starts with a description of the data types defined for the group. That section is followed by a description of the group specific system generation support and subsequently the run time services are described.
4.2.4.1.
System Generation Support
The description of system generation actions comprises the following fields:

Name: Syntax: Parameter (In): Description: Particularities: Name of system generation action Call interface in C syntax List of all input parameters Explanation of the function Explanation of restrictions relating to the utilization
4.2.4.2.
Service Descriptions
A service description comprises the following fields:

Service name: Syntax: Parameter (In): Parameter (Out): Name of NM service Interface in ANSI-C syntax. The return value of the service is always of data type StatusType. List of all input parameters. List of all output parameters. Strictly speaking, transfers via the memory use the memory reference as input parameter and the memory contents as output parameter. To clarify the description, the reference is already specified with the output parameters. Explanation of the functionality of NM service. Explanation of restrictions related to the use of NM service. List of possible return values. List of return values provided in NM standard version. List of additional return values in NM extended version.
Description: Particularities: Status: Standard: Extended:
Page 88
by OSEK/VDX
OSEK/VDX
OSEK/VDX
4.3. General Data Types
General Data Types NodeIdType NetIdType RoutineRefType EventMaskType SignallingMode
StatusType TaskRefType TickType Table 12
Remark Type for references to several nodes. Type for references to several communication networks. Type for references to low level routines Type for references to event masks. Unique name defining the mode of signaling. Legal names are: "Activation", "Event". Type4 of returned status information. References to tasks. This type represents count values in ticks.
General data types
4.4. Common services
4.4.1.1.
In general the system designer has to select a NM which fits to his needs. The selected NM can be scaled and has to be parameterized.
Example
The system designer selects a special implementation of the direct NM which guarantees a minimal calculating power demand. He decides to do it without using any scaling features. He concludes by fixing the parameter of the NM. The services to support the system designer are the reflection of the know-how of a software vendor. The following proposals should give an idea how system generation could be handled.
Name: Syntax: Parameter (In): NetId
InitNMType
InitNMType ( NetIdType <NetId>, NMType <NMType>
Addressed communication network
common definition OS, NM and COM - see document binding - unsigned char proposed by OSEK/VDX Page 89
OSEK/VDX
OSEK/VDX
NMType Description: Particularities:
selected NM (e.g. direct or indirect) InitNMType is a directive to select a NM from a given set of NM implementations. none
Name: Syntax: Parameter (In): NetId ScalingParams Description:
InitNMScaling
InitNMScaling ( NetIdType <NetId>, ScalingParamType <ScalingParams>
Addressed communication network Set of parameter to scale the given NM InitNMScaling is a directive for scaling the given NM of the referenced net (e.g. the state NMBusSleep is supported or the state NMBusSleep ist not supported). none
Particularities:
Name: Syntax:
SelectHWRoutines
SelectHWRoutines ( NetIdType <NetId>, RoutineRefType <BusInit>, RoutineRefType <BusAwake>, RoutineRefType <BusSleep> RoutineRefType <BusRestart> RoutineRefType <BusShutDown> Addressed communication network Referenced routine to initialize the bus hardware once at the start of the network. Referenced routine to reinitialize the bus hardware to leave the power down mode. Referenced routine to initialize the power down mode of the bus hardware. Referenced routine to restart the bus hardware in the case of a fatal bus error
Parameter (In): NetId BusInit BusAwake BusSleep BusRestart
Page 90
by OSEK/VDX
OSEK/VDX
OSEK/VDX
BusShutDown Description: Particularities:
Referenced routine to shut down the bus hardware SelectHWRoutines is a directive to select routines from a given set of routines to drive the bus hardware. none
NMOff
Figure 67
BusShutDown BusInit
Routines to initialize, restart and shut down the bus hardware. The routines depend on the given hardware design and on the behavior of the NM which the application requires.
NMBusSleep
BusRestart
Fatal Bus Error
BusAwake
BusSleep
NMAwake
NMOn
4.4.2.1. Data Types NM Data Types Remark ConfigRefType This data type represents the reference of a configuration. ConfigKindName Unique name defining the requested kind of configuration: "Normal" supported by direct and indirect NM "Normal extended" only supported by indirect NM "LimpHome" only supported by direct NM. ConfigHandleType This data type represents a handle to reference values of the type ConfigRefType.
Table 13 Special data types of the configuration management
4.4.2.2.
Name:
InitCMaskTable
by OSEK/VDX
Page 91
OSEK/VDX
OSEK/VDX
Syntax:
InitCMaskTable ( NetIdType <NetId>, ConfigKindName <ConfigKind>, ConfigRefType <CMask> Addressed communication network Kind of configuration Configuration mask (list of relevant nodes) InitCMaskTable is a directive for initializing an element of a table of relevant configuration masks to be used by the signaling of changed configurations. none
Parameter (In): NetId ConfigKind CMask Description:
Particularities:
Name: Syntax:
InitTargetConfigTable
InitTargetConfigTable ( NetIdType <NetId>, ConfigKindName <ConfigKind>, ConfigRefType <TargetConfig> Addressed communication network Kind of configuration Target Configuration InitTargetConfigTable is a directive for initializing an element of a table of relevant target configurations to be used by the signaling of changed configurations. none
Parameter (In): NetId ConfigKind TargetConfig Description:
Particularities:
Name: Syntax:
InitIndDeltaConfig
InitIndDeltaConfig ( NetIdType <NetId> ConfigKindName <ConfigKind>, SignallingMode <SMode>, TaskRefType <TaskId>, EventMaskType <EMask>)
Parameter (In): NetId

Page 92

OSEK/VDX
OSEK/VDX
ConfigKind SMode TaskId EMask Description:
Kind of configuration Mode of signaling Reference to the task to be signaled Mask of the events to be set InitIndDeltaConfig is a directive for specifying the indication of configuration changes. The concerned configuration is specified by <ConfigKind>. The parameter <SMode> specifies whether task activation (SMode = Activation) or event signaling (SMode = Event) is used for indication. In case of task activation, <TaskId> contains a reference of the task to be activated if the configuration <ConfigKind> has changed. In case of event signalling <EMask> specified the event to be set for task <TaskId>, if the configuration <ConfigKind> has changed.
Particularities:
none
Name: Syntax: Parameter (In): NetId SMask Description:
InitSMaskTable
InitSMaskTable ( NetIdType <NetId>, StatusRefType <SMask> Addressed communication network status mask (list of relevant network states) InitSMaskTable is a directive for initializing an element of a table of relevant status masks to be used by the signaling of changed network states. none
Particularities:
Name: Syntax: Parameter (In):

InitTargetStatusTable
InitTargetStatusTable ( NetIdType <NetId>, StatusRefType <TargetStatus>
by OSEK/VDX
Page 93
OSEK/VDX
OSEK/VDX
NetId TargetStatus Description:
Addressed communication network Target network status InitTargetStatusTable is a directive for initializing an element of a table of relevant target network states to be used by the signaling of changed network states. none
Particularities:
Name: Syntax:
InitIndDeltaStatus
InitIndDeltaStatus ( NetIdType <NetId> SignallingMode <SMode>, TaskRefType <TaskId>, EventMaskType <EMask>)
Parameter (In): NetId SMode TaskId EMask Description:
Addressed communication network Mode of signaling Reference to the task to be signaled Mask of the events to be set InitIndDeltaStatus is a directive for specifying the indication of status changes. The parameter <SMode> specifies whether task activation (SMode = Activation) or event signaling (SMode = Event) is used for indication. In case of task activation, <TaskId> contains a reference of the task to be activated if the status has changed. In case of event signaling <EMask> specified the event to be set for task <TaskId>, if the status has changed.
Particularities:
none
The extended network status is not supported by the proposed system generation.
4.4.2.3.
Services
Service name: Syntax:
InitConfig
StatusType InitConfig ( NetIdType <NetId>)
Page 94
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Parameter (In): NetId Parameter (Out):
Description:
This service makes the NM start or restart the configuration management. The service only works if the NM is in the state NMNormal. The service makes the NM leave the state NMNormal.
Particularities: Status: Standard: Extended: E_OK, no error. none
GetConfig
StatusType GetConfig ( NetIdType <NetId> ConfigRefType <Config>, ConfigKindName <ConfigKind>) Addressed communication network Kind of configuration
Parameter (In): NetId ConfigKind Parameter (Out): Config Description: Particularities: Status: Standard: Extended:
Configuration inquired This service provides the actual configuration of the kind specified by <ConfigKind>. The application must provide the memory to transfer the configuration. E_OK, no error. none
by OSEK/VDX
Page 95
OSEK/VDX
OSEK/VDX
CmpConfig
StatusType CmpConfig (
NetIdType <NetId> ConfigRefType <TestConfig>, ConfigRefType <RefConfig>, ConfigRefType <CMask>)
Parameter(In): NetId TestConfig RefConfig CMask Parameter (Out): Description:
Addressed communication network Test configuration Reference configuration List of relevant nodes none The test configuration <TestConfig> is compared to the specified reference configuration <RefConfig> taking account of the mask <CMask>. The presence of a node in the network is identified within the test configuration and the reference configuration by TRUE. The relevance of the result of the comparison (<TestConfig> EXOR <RefConfig>) of the node within the network is identified within the <CMask> by TRUE. Status = NOT ( <CMask> AND (<TestConfig> EXOR <RefConfig>) ) Example
TestConfig RefConfig
1 1 1 1 0 0 0 0
1 node present / not mute 0 node absent / mute
CMask
0 dont care
Status
1 True 0 False
Page 96
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Status: Standard: Extended:
TRUE, test condition for specified mask exists. FALSE, else. none
SelectDeltaConfig
StatusType SelectDeltaConfig ( NetIdType <NetId>, ConfigKindName <ConfigKind>), ConfigHandleType <ConfigHandle>, ConfigHandleType <CMaskHandle> Addressed communication network Kind of configuration Referenced target configuration
Parameter(In): NetId ConfigKind ConfigHandle
CMaskHandle Referenced configuration mask Parameter (Out): Description: Status: none A set of predefined parameter is selectable to drive the signaling of changed configurations. none
4.4.3. Operating Modes and Operating Mode Management
4.4.3.1. Data Types NM Data Types Remark NMModeName Unique name defining the NM operational modes. Legal names are: "BusSleep" and "Awake" NetworkStatusType Type of Network status. StatusHandleType This data type represents a handle to reference values of the type StatusRefType.
Table 14 Special data types of the operating mode management
by OSEK/VDX
Page 97
OSEK/VDX
OSEK/VDX
4.4.3.2.
4.4.3.3.
Services
Service name: Syntax: Parameter (In): NetId Parameter (Out): Description: Particularities: Status: Standard: Extended:
StartNM
StatusType StartNM (NetIdType <NetId>) Addressed communication network none StartNM starts the local network management. This causes the state transition from NMOff to NMOn. none E_OK, no error. none
Service name: Syntax: Parameter (In): NetId Parameter (Out): Description:
StopNM
StatusType StopNM (NetIdType <NetId>) Addressed communication network none StopNM stops the local network management. This causes the state transition from NMOn to NMShutDown and after processing of the shutdown activities to NMOff. none E_OK, no error. none
Particularities: Status: Standard: Extended:
Service name:
GotoMode
Page 98
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Syntax: Parameter (In): NetId NewMode Parameter (Out): Description:
Network Management Concept and Application Programming Interface NetIdType <NetId> NMModeName <NewMode>)
StatusType GotoMode (
Addressed communication network NM operating mode to be set (only BusSleep, Awake). none GotoMode serves to set the NM operating mode specified by <NewMode>. Operating modes to be set globally are recognized by the local NM and treated accordingly.
Note: If a global operating mode has been set, the application - depending on the task specified by InitIndDeltaStatus - is informed accordingly.
Particularities: Status: Standard: Extended: none E_OK, no error none
GetStatus
StatusType GetStatus ( NetIdType <NetId> NetworkStatusRefType <NetworkStatus>) Addressed communication network
Parameter (In): NetId
Parameter (Out): NetworkStatus requested Status of the node Description: Particularities: Status: Standard: Extended: This service provides the current status of the network. none E_OK, no error none
by OSEK/VDX
Page 99
OSEK/VDX
OSEK/VDX
CmpStatus
StatusType CmpStatus (
NetIdType <NetId> StatusRefType <TestStatus>, StatusRefType <RefStatus>, StatusRefType <SMask>)
Parameter(In): NetId TestStatus RefStatus SMask Parameter (Out): Description:
Addressed communication network Test status Reference status List of relevant states none The test status <TestStatus> is compared to the specified reference status <RefStatus> taking account of the mask <SMask>. Status = NOT ( <SMask> AND (<TestStatus> EXOR <RefStatus>) ) Example
TestStatus RefStatus
1 1 1 1 0 0 0 0
SMask
0 dont care
Status
1 True 0 False
Status: Standard:
TRUE, test condition for specified mask exists. FALSE, else.
Page 100
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Extended: none
SelectDeltaStatus
StatusType SelectDeltaStatus ( NetIdType <NetId>, StatusHandleType <StatusHandle>, StatusHandleType <SMaskHandle> Addressed communication network Referenced target network status
Parameter(In): NetId StatusHandle
SMaskHandle Referenced network status mask Parameter (Out): Description: Status: none A set of predefined parameter is selectable to drive the signaling of changed states. none
4.5. Services for direct NM
4.5.1.1.
Name: Syntax:
InitDirectNMParams
InitDirectNMParams ( NetIdType <NetId>, NodeIdType <NodeId>, TickType <TimerTyp>, TickType <TimerMax>, TickType <TimerError>, TickType <TimerWaitBusSleep> TickType <TimerTx> Addressed communication network Relative identification of the node-specific NM messages Typical time interval between two ring messages
Parameter (In): NetId NodeId TimerTyp
by OSEK/VDX
Page 101
OSEK/VDX
OSEK/VDX
TimerMax TimerError TimerWaitBusSleep TimerTx Description: Particularities:
Maximum time interval between two ring messages Time interval between two NMLimpHome identification ring messages with
Time the NM waits before transmission into the state NMBusSleep Delay to repeat transmission requests
InitDirectNMParams is a directive for initializing the parameters of the direct NM. none
4.5.2. Operating Modes and Operating Mode Management
4.5.2.1.
Services
Service name: Syntax: Parameter (In): NetId Parameter (Out): Description: Particularities: Status: Standard: Extended:
SilentNM
StatusType SilentNM (NetIdType <NetId>) Addressed communication network none SilentNM disables the communication of the NM. This causes the state transition from NMActive to NMPassive. none E_OK, no error. none
Service name: Syntax: Parameter (In): NetId
TalkNM
StatusType TalkNM (NetIdType <NetId>) Addressed communication network
Page 102
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Parameter (Out): Description: none
TalkNM enables the communication of the NM again, after a previous call of SilentNM. This causes the state transition from NMPassive to NMActive. After a call of StartNM the NM is always in state NMActive. E_OK, no error. none
Particularities: Status: Standard: Extended:
4.5.3. Data Field Management
4.5.3.1. Data Types NM Data Types Remark RingDataType Type of the data field in the NMPDU
Table 15 Special data types of the data field management
4.5.3.2.
InitIndRingData
InitIndRingData ( NetIdType <NetId> SignallingMode <SMode>, TaskRefType <TaskId>, EventMaskType <EMask>)
Parameter (In): NetId SMode TaskId EMask Description:
Addressed communication network Mode of signaling Reference to the task to be signaled Mask of the events to be set InitIndRingData is a directive for specifying the indication of received data in the data field of a ring message, which is addressed to this node.
by OSEK/VDX
Page 103
OSEK/VDX
OSEK/VDX
The parameter <SMode> specifies whether task activation (SMode = Activation) or event signaling (SMode = Event) is used for indication. In case of task activation, <TaskId> contains a reference of the task to be activated if the NM received ring data. In case of event signaling, <EMask> specified the event to be set for task <TaskId> if the NM received ring data. Particularities: none
4.5.3.3.
Services
Service name: Syntax: Parameter (In): NetId Parameter (Out): RingData
ReadRingData
StatusType ReadRingData ( NetIdType <NetId> RingDataType <RingData>) Addressed communication network
Contents of the data field within the Network management that contains the data either received by the last NM message or written to by TransmitRingData ReadRingData enables the application to read the data that has been received by a ring message. none. E_OK, no error. E_NotOK - the NM does not pass a ring message currently - the logical ring does not run in a stable state.
Description: Particularities: Status: Standard:
Service name: Syntax: Parameter (In):

Page 104
TransmitRingData
StatusType TransmitRingData (NetIdType <NetId> RingDataType <RingData>)
by OSEK/VDX
OSEK/VDX
OSEK/VDX
RingData NetId Parameter (Out): Description: Particularities: Status: Standard:
Data which is written to the data field to be transmitted with the next ring message. Addressed communication network none This service enables the application to transmit data via the ring message. none E_OK, no error. E_NotOK - the NM does not pass a ring message currently - the logical ring does not run in a stable state.
4.6. Services for indirect NM
4.6.1. Standard functionality
4.6.1.1.
Name: Syntax:
InitIndirectNMParams
InitIndirectNMParams ( NetIdType <NetId>, NodeIdType <NodeId>, TickType <TOB>, TickType <TimerError>, TickType <TimerWaitBusSleep> Addressed communication network Relative identification of the node-specific NM messages Time to monitor a subset of nodes. Time interval before reinitializing the bus hardware after an error which makes the NM shift to LimpHome Time the NM waits before transmission in NMBusSleep
Parameter (In): NetId NodeId TOB TimerError TimerWaitBusSleep
by OSEK/VDX
Page 105
OSEK/VDX
OSEK/VDX
Description: Particularities:
InitIndirectNMParams is a directive for initialising the parameters of the indirect NM. none
4.6.2. Configuration Mangement
4.6.2.1.
The determination of the monitored messages which are used by the indirect NM is located and described by the system generation of COM.
Name: Syntax:
InitExtNodeMonitoring
InitExtNodeMonitiring ( NetIdType <NetId>, NodeIdType <NodeId>, Int < DeltaInc> Int < DeltaDec>
Parameter (In): NetId NodeId DeltaInc DeltaDec
Addressed communication network Relative identification of the node-specific NM messages Value to increment the node status counter when a message is not received during a given time. Value to decrement the node status counter when a message is received. InitExtNodeMonitoring is a directive for initializing a set of parameters to monitor one node with an individual time-out. The (redundant) parameter "threshold" is hidden. none
Description:
Particularities:
5.
Impacts upon OS, COM and the data link layer
5.1. Error Codes

The NM supports several mechanisms to pass errors inside the NM to the application:
Page 106
by OSEK/VDX
OSEK/VDX
OSEK/VDX

return value5 of the API-services indications which are activated by the NM if required configurations or network states are not recognized by the NM
The NM does not support centralized error handling by the application:

not any error-hook specific to NM not a common error-hook used by OS, COM and NM services to pass kernel errors to the application are not supported the handling of NM kernel errors are up to the implementers
5.2. Common impacts
5.2.1. Requirements of the data link layer

D_Init
From the NM point of view, five services to initialize the DLL are needed in general. Parameter are adjusted according to the following examples: baud rate sample point sample algorithm synchronization mechanism bit timing Sleep Mode of the protocol circuit Sleep Mode of the physical layer Standby Mode of the physical layer operation modes of the protocol circuit
example
parameter (in)
NetId
connected bus (not necessary when just one bus is connected)
see Error Codes inside the document binding by OSEK/VDX Page 107
OSEK/VDX
OSEK/VDX
InitRoutine
BusInit BusShutDown BusRestart BusSleep BusAwake
initialize the bus hardware once at the start of the network shut down the bus hardware restart the bus hardware in the case of a fatal bus error initialize the power down mode of the bus hardware reinitialize the bus hardware to leave the power down mode
D_Status.ind
Indication of states of the data link layer (software and hardware) according to the following examples: errors from the physical layer errors from bus monitoring circuits errors from the protocol circuit (CAN e.g.: bus off or error active/passive) errors from the DLL wake-up signal NetId status connected bus (not necessary when just one bus is connected) hardware specific status data
example
parameter (out)
D_GetLayerStatus
Reading the status information of the data link layer according to the following examples: interrupt acknowledge to the protocol circuit get the status of the protocol circuit, e.g. transmit, receive, overrun, bus off get the status of the physical layer, e.g. transmission line error NetId status connected bus (not necessary when just one bus is connected) hardware specific status data
example
parameter (in) parameter (out)
Page 108
by OSEK/VDX
OSEK/VDX
OSEK/VDX
D_Offline
This service allows the user transmission via the data link layer at least to be blocked.
example
parameter (in)
D_Online
NetId
This service enables the user communication on the data link layer, e.g. after a call of D_Offline.
example
parameter (in)
NetId
The NM calls DLL services at the transition from one state to another state.
NMOff
StartNM called
NMOff
StartNM called
D_Init(...;BusShutDown)
StopNM called
D_Init(...;BusShutDown)
StopNM called
D_Init(...;BusInit) NMOn NMBusSleep
D_Init(...;BusInit) NMOn NMBusSleep
D_Offline
GoToMode(Awake) called OR wake-up signal from the bus
D_Offline
GoToMode(Awake) called OR wake-up signal from the bus
D_Init(...;BusRestart)
Fatal Bus Error
D_Init(...;BusSleep) D_Init(...;BusAwake)
D_Init(...;BusRestart)
Fatal Bus Error
D_Init(...;BusSleep) D_Init(...;BusAwake)
Timer WaitBusSleep is running down
Timer WaitBusSleep is running down
BusSleep netwide confirmed
D_Offline NMLimpHome
transmission ok AND reception ok
D_Offline NMLimpHome
node operational GoToMode(Awake) called OR NM message received
NMWaitBusSleep
GoToMode(Awake) called
NMWaitBusSleep
not supported
D_Online
node not operational
D_Online NMNormal NMReset

BusSleep netwide confirmed
NMNormal NMAwake NMAwake
Figure 68
Using of DLL services by the NM left indirect NM right direct NM
5.2.2. Requirements of OSEK Operating System (OSEK OS)

The operating system requirements for implementation of OSEK NM are listed below. The standard services for configuration management, management of operating modes and data field management are available at the lowest conformance class BCC1 of OSEK OS. This allows the implementation of NM on the basis of OSEK OS class BCC1. Additional features partly require higher conformance classes.
by OSEK/VDX
Page 109
OSEK/VDX
OSEK/VDX
If NM uses the event triggering mechanism, then this feature is required from the operating system. The implementation can also be based on a non OSEK OS, which at least provides the functionality of OSEK OS services listed below.

Alarm services: Task management:
SetRelAlarm and CancelAlarm GetTaskState, DeclareTask, ActivateTask, TerminateTask and ChainTask.
5.3. Impacts from direct NM
5.3.1. Interface to the data link layer

From the NM point of view the NM in a node has to transmit a NMPDU to the bus and has to receive every NMPDU from the NMs in all networked nodes. The structure of the NMPDU is fixed by the NM. However the data representation inside a NMPDU and how to code/decode a NMPDU to a message is out of the scope of the NM. The annex contents proposals to handle these tasks.
topic responsible
structure of the NMPDU

example
OSEK NM
Address-Field (source and destination) Control-Field (12 message types) optional Data-Field data representation inside the NMPDU out of the scope of OSEK NM
coding and decoding of a NMPDU to a out of the scope of OSEK NM message Table 16 NMPDU - responsible
In general the interface between NM and the DLL to transmit and receive NMPDUs will be directly influenced by the agreement to fix the data representation inside a NMPDU and the coding/decoding to a message. Based on the experiences according to the state of the art and the proposals given in the annex an interface between NM and the DLL can be suggested.
D_DefineWindow
Page 110
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Definition of the encoding/decoding algorithm to broadcast/receive the NMPDU via the bus. This action will be handled by a system generation tool. The system generator is responsible for the selected algorithm.
example
static parameter (in) NetId WindowMask IdBase SourceId DataLengthTx DataLengthRx

D_Window_Data_req
connected bus (not necessary when just one bus is connected) mask for filtering NM messages base identification of an NM message identification of the source of the NMPDU number of bytes of the NMPDU to transmit (if data length is static) number of bytes of the NMPDUs to receive (if data length is static)
Service to transmit a NMPDU to the network.

example
parameter (in)
NetId NMPDU DataLengthTx
connected bus (not necessary when just one bus is connected) except the source (static see the example D_Define_Window, DataLengthTx) number of bytes of the NMPDU to transmit (if data length is dynamic)
D_Window_Data_ind
Service to receive a NMPDU to the network.

example
NetId NMPDU
connected bus (not necessary when just one bus is connected) number of bytes referenced by the value DataLengthRx (static see the example D_Define_Window) number of bytes of the NMPDUs to receive (if data length is dynamic)
DataLengthRx
by OSEK/VDX
Page 111
OSEK/VDX
OSEK/VDX
5.4. Impacts from indirect NM
5.4.1. Interface to OSEK Communication (OSEK COM)

When a monitored application message is received/transmitted by COM, indirect NM has to be informed. In case of using one dedicated time-out per message monitored, indirect NM has to be informed when a monitoring time-out expires. For each of these situations the indirect NM needs to know to which NetId and NodeId the monitored message refers. COM provides this information to NM via a parameter called "Sender", corresponding to a combination of both NetId and NodeId. Services needed between indirect NM and COM depend on the selected monitoring scheme (one global time-out / one dedicated time-out per monitored message).
Interface to OSEK COM IL Options One global time-out One dedicated time-out per monitored message
I_MessageTransfer.ind I_MessageTimeOut.ind Table 17 Interface of indirect OSEK NM with OSEK IL
core
core core
I_MessageTransfer.ind
Indication from COM that a monitored message has been received from a remote node or that the local monitored message has been transmitted. parameter (out)
I_MessageTimeOut.ind
Sender
combination of NodeId and NetId
Indication from COM that a time-out at monitoring a message from a remote node has expired or that the time-out at monitoring the local message transmission has expired. parameter (out) Sender combination of NodeId and NetId
Page 112
by OSEK/VDX
OSEK/VDX
OSEK/VDX
5.4.1.1.
Mapping NodeId, NetId Sender
Sender
! ! ! x x x x x
NodeMask
NodeId
! x x ! ! ! ! !
NetMask
NetId
Figure 69 Encoding and decoding of sender to a NodeId and a NetId by using a mechanism with a Mask. (x = don't care, take Message bit; ! = do not take this bit)
NMDefineNetNodeMapping
Definition of the algorithm to map a sender to a node and to a net. This action will be handled by a system generation tool. The system generator is responsible for the selected algorithm.
example
static parameter (in) NetMask NodeMask

NMNetNodeMapping
mask for filtering NM messages mask for filtering NM messages
Mapping of a given sender to the corresponding node and the corresponding net.
example
sender NodeId NetId node which corresponds referenced identification to the
by OSEK/VDX
Page 113
OSEK/VDX
OSEK/VDX
Date 11th Sept. 1995 Remarks
6.
1.00
History
initial release Authors involved in version 1.00 Christoph Hoffmann Volkswagen AG Jrgen Minuth Daimler-Benz AG Josef Krammer BMW AG Jrg Graf Adam Opel AG Karl Joachim Neumann IIIT, Univ. of Karlsruhe Franois Kaag PSA Peugeot Citron
Version
2.00 2.10
2.50 preliminary
2.50 2.51
2.5.2
Authors involved in Version 2.0 and 2.1 Josef Krammer BMW AG Jrgen Minuth Daimler-Benz AG Ansgar Maisch IIIT, University of Karlsruhe Willy Roche IIIT, University of Karlsruhe Christoph Hoffmann Volkswagen AG Olivier Quelenis Magneti Marelli Eric Farges Renault Peter Aberl Texas Instruments 31st March 1998 Authors involved in Version 2.5 Josef Krammer BMW AG Dirk John IIIT, University of Karlsruhe Christoph Hoffmann Volkswagen AG Lise Mathieu Renault Jrgen Minuth Daimler-Benz AG Olivier Quelenis Magneti Marelli summary of modifications since Version 2.1 - indirect NM: individual time outs per monitored message - update system generation services - update structure of the document - harmonization of NM services - harmonization interface to COM - update state transition diagrams and SDL diagrams 31st May 1998 editorial overworking of the preliminary version 2.50 31st May 2000 Results of the harmonization Authors involved in version 2.51 Jrgen Minuth DaimlerChrysler Martin Schtze Robert Bosch AG Dirk Gronemann Siemens 16th Jan. 2003 Adapt to COM 3.0 editor: Jochem Spohr, IMH
24th Dec. 1996 4th April 1997
Page 114
by OSEK/VDX
OSEK/VDX
OSEK/VDX
7.
Implementation proposal (direct NM)
7.0.1. Overview of Internal Activities

All the internal services of the NM begin with NM. All words of the service name begin with a capital letter.
one word NM capital letter ABCD... letter abcde...
Figure 70 Syntax of the names of internal NM services. Example: NMShutDown

Activity Core or Optional CORE CORE
- Shut-off of NM - Save parameters, store history and shutdown NM - Initialize NM and the resources pertaining to it - NM in the state NMBusSleep - NM in the state NMActive - NM in the state NMPassive - NM in the state NM~Standard - NM in the state NM~Active - NM in the state NM~Passive - NM in the state NM~ActivePrepBusSleep - NM in the state NM~PassivePrepBusSleep Table 18
NMOff NMShutDown NMInit NMBusSleep NMActive NMPassive NM~Standard NM~Active NM~Passive NM~ActivePrepBusSleep NM~PassivePrepBusSleep
CORE CORE CORE CORE CORE CORE CORE CORE CORE
Breakdown of internal NM activities into core services and optional services. ~ Reset, Normal or LimpHome
The state transition diagrams (STD) listed hereafter define system hierarchy and general transition rules for the NM behavior. NM activities are performed by calls of the internal activities in the respective states of the STD and identified by the names of these dedicated internal activity. Internal activities are defined verbally in the referenced chapters according to the description of their characteristics. Consequently, they can be considered as macros which are generated at compile time, using (elementary) services which are defined otherwise.
by OSEK/VDX
Page 115
OSEK/VDX
OSEK/VDX
Thus, there is neither an appropriate C syntax, nor specifications about input / output parameters or status of the internal activity.
level 0
NMShutDown StopNM
NMOn
StartNM
NMOff NMOn NMBusSleep not any communication request communication request NMAwake TalkNM NMActive
SilentNM
NMInit
NMPassive
level 1
fatal Bus Error NMAwake NMLimpHome "Own station non operational" e.g. not any NM transmission "Failure at own station repaired" e.g. NM transmission and NM reception possible
"Own station non operational" i.e. not any NM reception "Station operational" e.g. not any error at NM reception recognized
NMNormal
NMReset
"data inconsistent" e.g. time out at ring message
level 2
Figure 71
Simplified state transition diagram of the direct NM.
Page 116
by OSEK/VDX
OSEK/VDX
OSEK/VDX
NMReset, NMNormal, NMLimpHome
GotoMode(Awake) called or network not ready for BusSleep
NMActive
~Active
GotoMode (BusSleep) called
~ActivePrepBusSleep
network ready for BusSleep
~Standard
nmPassive GotoMode(Awake) called or nmActive network not ready for Bussleep
NMPassive
~Passive
GotoMode (BusSleep) called
~PassivePrepBusSleep
network ready for BusSleep
level 3
Figure 72
NM internal states "NMNormal" or "NMReset" or "NMLimpHome"
7.0.2. Specification of Internal Activities

Service name: Description: Particularities:
NMOff
NM of the node is shut-off. none
Service name: Description:
NMShutDown
Service for selective shut-off of NM entity. This includes all "clearing-up work" (see below) to be effected by NM. This service is effected without confirmation throughout the whole network. (see Figure 71) The tasks of this service comprise: - Saving NM state incl. the last valid network configuration, operating state, version number (optional, depending on system design). - Releasing all resources assigned for NM. - Reset interface module.
by OSEK/VDX
Page 117
OSEK/VDX
OSEK/VDX
none
Particularities:
NMInit
Service for initializing NM according to NM STD: - Initialization of network interface. - Assignment and initialization of NM resources.
Particularities:
none
NMBusSleep
The NM module of the node is mode NMBusSleep according to the NM STD (level 1). Concrete procedures must be specified by the respective system responsible.
NMActive
The NM module of the node is mode NMActive according to the NM STD (level 1). Concrete procedures must be specified by the respective system responsible.
NMPassive
The NM module of the node is mode NMPassive according to the NM STD (level 1). Concrete procedures must be specified by the respective system responsible.
Page 118
by OSEK/VDX
OSEK/VDX
OSEK/VDX
NMNormalActivePrepBusSleep
The NM module of the node is mode NMNormalActivePrepBusSleep according to the NM STD (level 3). The activities performed are according to the concept of OSEK NM the notification of a sleep request for the whole network to all nodes in the network and pending for confirmation.
Particularities:
Concrete procedures must be specified by the respective system responsible.
NMLimpHomeActivePrepBusSleep
The NM module of the node is mode NMLimpHomeActivePrepBusSleep according to the NM STD (level 3). The activities performed are according to the concept of OSEK NM the notification of a sleep request for the whole network to all nodes in the network and pending for confirmation.
Particularities:
NMResetActivePrepBusSleep
The NM module of the node is mode NMResetActivePrepBusSleep according to the NM STD (level 3). The activities performed are according to the concept of OSEK NM the notification of a sleep request for the whole network to all nodes in the network and pending for confirmation.
Particularities:
by OSEK/VDX
Page 119
OSEK/VDX
OSEK/VDX
NMNormalPassivePrepBusSleep
The NM module of the node is mode NMNormalPassivePrepBusSleep according to the NM STD (level 3). Concrete procedures must be specified by the respective system responsible.
Particularities:
NMLimpHomePassivePrepBusSleep
The NM module of the node is mode NMLimpHomePassivePrepBusSleep according to the NM STD (level 3)
Particularities:
NMResetPassivePrepBusSleep
The NM module of the node is mode NMResetPassivePrepBusSleep according to the NM STD (level 3) Concrete procedures must be specified by the respective system responsible.
Particularities:
NMNormalActive
The NM module of the node is mode NMNormalActive according to the NM STD (level 3). The procedure performed is to participate in the NM communication according to the logical ring concept and to assess the NMPDU.
Particularities:
none
Page 120
by OSEK/VDX
OSEK/VDX
OSEK/VDX
NMLimpHomeActive
The NM module of the node is mode NMLimpHomeActive according to the NM STD (level 3). The procedure performed is to participate in the NM communication according to the logical ring concept and to assess the NMPDU.
Particularities:
none
NMResetActive
The NM module of the node is mode NMResetActive according to the NM STD (level 3). The procedure performed is to participate in the NM communication according to the logical ring concept and to assess the NMPDU.
Particularities:
none
NMNormalPassive
The NM module of the node is mode NMNormalPassive according to the NM STD (level 3). none
NMLimpHomePassive
The NM module of the node is mode NMLimpHomePassive according to the NM STD (level 3). none

NMResetPassive
The NM module of the node is mode NMResetPassive according to the NM STD (level 3). none
by OSEK/VDX Page 121
OSEK/VDX
OSEK/VDX
NMNormalStandard
The NM module of the node is mode NMNormalStandard according to the NM STD (level 3). none
NMLimpHomeStandard
The NM module of the node is mode NMLimpHomeStandard according to the NM STD (level 3). none
NMResetStandard
The NM module of the node is mode NMResetStandard according to the NM STD (level 3). none
7.0.3. NMPDU
OSEK implementation of direct node monitoring supports the implementation of NMPDU as listed hereafter. Additional information for extended NM features, e.g. dedicated enhanced diagnosis support, could be mapped into the data field of the NM message. This is an optional feature in the responsibility of the respective system developer and it depends on the used bus protocol.
Implementation
The implementation features

support of a maximum number of 256 nodes demand of 3 Bytes
Page 122
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Addressing Field
Control Field
Data Field (optional)
8 bit Source Id Figure 73
8 bit Destination Id
8 bit OpCode
specific to the protocol (e.g. CAN) Data
Implementation of NMPDU
7.0.3.1.
OpCode
Address Field
Control Field
Data Field
Source Id Dest. Id
OpCode mandatory Coding Example Interpretation 0 0 0 0 0 0 0 1 Ring Message, cleared

Bussleep.ack, cleared Bussleep.ind
Data optional
0
0 0 0 0 0 1 0 1 Ring Message, cleared
Bussleep.ack, set Bussleep.ind
0 0 0 0 0 x 1 1 Ring Message, set Bussleep.ack 0 0 0 0 0 0 1 0 Alive Message, cleared

Bussleep.ind
0 0 0 0 0 1 1 0 Alive Message, set Bussleep.ind 0 0 0 0 0 0 0 0 Limp Home Message, cleared

Bussleep.ind Bussleep.ind
0 0 0 0 0 1 0 0 Limp Home Message, set
Table 19
NMPDU The 1st 5 bits of the OpCode are reserved for future extensions. They should be initialized to logical zero. The data field should be initialized to logical zero
by OSEK/VDX
Page 123
OSEK/VDX
OSEK/VDX
Encoding and decoding Addressing Mechanisms
7.0.3.2. 7.0.3.2.1.
The following set-up is required for each node to implement the window mechanism with a broadcast behavior:

one node-specific transmit object one or more global receive objects (windows) for all node-specific NM messages
Under worst case condition NM has to use a range of message headers for network-wide communication. Such a range of messages can be mapped to one or more window objects. Each window object is identified by the values: IdBase WindowMask Base identification of any NM message header. Mask for filtering NM messages (acceptance).
Example for Acceptance Filtering
Reception is OK:
IF( Id_of_Frame & WindowMask = = IdBase )
Example for encoding and decoding of a NMPDU

Source Destination OpCode Data
NMPDU to transmit
! !
! x x x x x
WindowMask Message
Header
! ! ! x x x x x
Data
WindowMask
Source
Destination
OpCode
Data
received NMPDU
Figure 74
Encoding and decoding of the NMPDU to a message by using the window mechanism with IdBase and WindowMask. (x = don't care, take NMPDU bit; ! = take original bit of IdBase)
The example shows, that the receiving node can determine parts of the NMPDU, e.g. the identification of the transmitting node, from the transmitted frame.
7.0.3.2.2.
Page 124
Coherent Allocation of NM message Headers

OSEK/VDX
OSEK/VDX
A simple implementation results if the message headers for NM are selected in a coherent numeric range. Two integers n and k must be selected in order to enable straightforward acceptance filtering of NM messages. Using the constant n, 2n (WindowSize) directly addressable nodes are made available. The constant k defines the Base of the message header as an integer multiple of the maximum number of directly addressable nodes. Node identification IdBase least message header greatest message header Table 20
General Example
0 ... 2n - 1 k 2n k 2n + 0 k 2n + 2n - 1
Selection of message headers and NodeNumbers
Addressing of 32 separate nodes shall be enabled. The NM message headers have to start with message identifier 600hex. This implies:

Selected parameters: Node identification Least header (600hex) Greatest header (61Fhex) IdBase WindowMask
32 = ( 2 ) 600hex = (48*32) 0 ... 31 dec

110 0000 0000 110 000 110 0001 1111 110 0000 0000 111 1110 0000
n=5 k = 48.
bin, bin bin bin bin
corresponds to k
"1" : "0" :
target don't care
CAN Example
A NM message containing the NMPDU has to be mapped into diverse bus protocols. The figures below show a CAN realization example (i.e. max. 256 nodes can be addressed). Because CAN implementations do not allow unique message identifiers used by more than one transmitter, it is essential that all NM messages differ from each another. This can be achieved by e.g. encoding the NM Source Id into the CAN message Id.
by OSEK/VDX
Page 125
OSEK/VDX
OSEK/VDX
DLC
CAN Identifier
CAN Data Field 64 bit Control Field Data Field
11 (29) bit 3 (21) bit 8 bit IdBase Source Id x S Figure 75 11 (29) bit 3 (21) bit 8 bit IdBase Source Id x S Figure 76
4 bit
Addressing Field
8bit Dest. Id D
8bit OpCode x
48bit Data x
Structure of NM message in case of CAN (6 Byte Data Field).

DLC CAN Data Field
CAN Identifier
4 bit
Addressing Field
16 bit
Control Field
8bit Dest. Id D
8bit OpCode x
Structure of NM message in case of CAN (without Data Field).

CAN Data Field 3 - 8 byte Control Field
1 byte OpCode 1 byte
CAN Identifier 11 (29) bit Address Field

3 (21) bit 8 bit 1 byte Source Id Dest. Id
Data Field
5 byte Data
x x x x x x x x
D D D D E E C C
hex hex hex hex hex hex hex hex
0 1 0 1 0 1 0 1
0 0 1 1 0 0 0 0
x x x x x x x x
x x x x x x x x
x x x x x x x x
x x x x x x x x
x x x x x x x x
x x x x x x x x
Ring Messages
Alive Messages Limp-Home Messages
Figure 77
Example of the mapping of the NMPDU to a NM message based on CAN - comparable to the DaimlerChrysler encoding x reserved
Important Note: In principle, message headers required to implement the window can obviously be assigned in any order. Selecting the digits n and k according to the principle introduced above, the choice is automatically limited to powers of two and enables straightforward filtering for acceptance in the destination system. In the case of possible dynamic allocations, the window parameters can be coded using two bytes, and can be transmitted with a message.
Page 126
by OSEK/VDX
OSEK/VDX
OSEK/VDX
7.0.3.2.3.
Non-coherent Allocation of NM message Headers
If the system design requires distribution - i.e. numerically separate arrangement - of the message headers, they can remain coherent within the software if an appropriate mask is used.
Example
Addressing of 32 separate nodes shall be enabled. The NM message headers 400hex to 40Fhex and 600hex to 60Fhex have to be used This implies:

Node identification Least header (400hex) Header 40Fhex Header 600hex Header 60Fhex IdBase WindowMask
0 ... 31 dec
100 0000 0000 bin 100 0000 1111 bin 110 0000 0000 bin 110 0000 1111 bin 100 0000 0000 bin 101 1111 0000 bin
"1" : "0" :
target don't care
7.0.3.2.4.
Node Identifications
The local node identifications of NM, and consequently the global node identifications must be allocated uniquely within the entire network. In accordance with the determinations, numeric values in the range from 0 to (2n - 1) are used for this purpose. Group addresses are provided for special applications by the system responsible. It depends on the selected transformation for node identification into message header, whether the local and global node identifications are equal.
Node Identification
Interpretation
0 1 ... 254 255 Table 21
reserved node no. 1 up to node no. 254 Group "all nodes"
Determination of node identifications using the example n=8
7.0.4. Scalability
In most control unit networks with a centralized structure, three node types are distinguished:
Function master Clearly defined node which performs all centralized and co-ordination functions.
by OSEK/VDX
Page 127
OSEK/VDX
OSEK/VDX
Potential function master In case of failure of the function master, e.g. node breaks down, each of these back-up masters is capable of performing at least some of the master's functions. Function slaves
The individual nodes may feature broadly varying available computing power for implementation of NM. The decentralized NM can be scaled to save resources (requirements of RAM/ROM and computer time), resulting in two extreme NM types:
Max_NM Set of all NM functions according to direct node monitoring. Min_NM Minimum set of required functionality enabling participation in direct node monitoring.
The choice of functions can be adapted to the nodes' performance.

Task Max NM
scaleable
Min NM
Store the present configuration Time-out monitoring to detect faulty node "Re-login" if skipped Login Determine logical successor Delayed transmission of NM message according to sequencing rule of the logical ring Start up of the logical ring Table 22
Functionality of the configuration algorithms of Max NM and Min NM
If necessary, the individual node types (Function master ... Function slave) can be supplied with subsets of the decentralized NM. In a centrally structured network, the group of nodes consisting of function master and potential function masters, can be considered as decently structured with regard to the configuration adjustment within the NM. The dynamic concept of configuration determination enables integration of any function slaves performing Min NM and of any potential function master into the network.
Page 128
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Important Note:
For the sake of clarity, the implementation of identical NM modules is required in each node. In other words: the basic scalability of the decentralized NM should only be used in vital, exceptional cases.
7.1. Implementation proposal (indirect NM)
7.1.1. Scalability
According to system designer needs and to computing power performance of nodes (RAM/ROM and computer time), Indirect NM can be scaled in NM types ranging from :
Max_NM Set of all NM functions including all extended features. Min_NM Minimum set of required functionality enabling network communication.
down to -
Function
Max NM
scalable

Min NM
Hardware initialization, restart of hardware after a failure, bus shutdown Dynamic states monitoring Static states monitoring BusSleep Table 23
Important Note:
Example of functionality for different NM types
The implementation of identical indirect NM type is not required in each node. Choice of functions to be implemented is let to system designer.
by OSEK/VDX
Page 129
OSEK/VDX
OSEK/VDX
7.1.2. Implementation hints
7.1.2.1.
Choice one global time-out / one monitoring time-out per message
Implementing node monitoring functionality, the system designer can choose two monitoring schemes: all messages are monitored by one global time-out TOB (time-out for observation) each message is monitored by its own dedicated time-out.
One global time-out Advantage This solution does not require much micro-controller CPU time resource. Drawback If monitored messages have very different transmission period (for example, one 10ms message from a node and one 500ms message from another), the user has to choose the biggest value for timer TOB to be sure than each message has arrived before time - out expires. The resulting delay on the 10ms message monitoring may be unacceptable if this message is time-critical for the application.
One time-out per monitored message Advantage Each message can be monitored regarding its time-criticity. Drawback This solution requires more micro-controller CPU time resource.
7.1.2.2.
Configuration of extended states detection algorithm
Extended states detection algorithm has to be configured at system generation time. Parameters to be set are: the Threshold value, which is the same for all counters, a DeltaInc (increment of counter) and a DeltaDec (decrement of counter) values per monitored node.
Threshold value is usually set to 255; its value has no impact on the algorithm behaviour. DeltaInc and DeltaDec modify algorithm behaviour.
Examples If the system designer needs:
"static states" corresponding to states during a unique TStatic time value for every monitored node, although these nodes have different transmission periods and are monitored by different time,
Page 130
OSEK/VDX
OSEK/VDX
-
counters return directly to 0 when static states are left

Counterk Parameters: DeltaDeck, DeltaInck
Threshold
extended state of the node k
TStatic
static absent/mute
Figure 78
Extended state example one

Value
Threshold TimeOut k TStatic
Parameter of node k DeltaInc DeltaDec
Threshold
Table 24
Calculation of DeltaInc and DeltaDec according example one TimeOutk: monitoring time-out for node k
If the system designer needs :
"static states" corresponding to states during a unique TStatic time value for every monitored node, although these nodes have different transmission periods and are monitored by different time-outs, counters keeping track of node states during a TErase time value after static states are left
by OSEK/VDX
Page 131
OSEK/VDX
OSEK/VDX
Counterk
Parameters: DeltaDeck, DeltaInck
Threshold
extended state of the node k
TStatic
TErase
static absent/mute
Figure 79
Extended state example two

Value
Threshold TimeOut k TStatic
T h re s h o ld T k T E r a se
Parameter for node k DeltaInc DeltaDec
Table 25
Calculation of DeltaInc and DeltaDec according example one TimeOutk: monitoring time-out for node k Tk: period of the supervised message received from node k
7.1.3. Summary of SDL state diagram graphical notation

The SDL graphical symbols used in the specification of the indirect network management state machine are described below:
Page 132
by OSEK/VDX
OSEK/VDX
OSEK/VDX
Process Symbols
1(1)
/* SDL graphical symbols summary */
Startup State
Declarations State /* Comments */
Annotations State Receive Signal
Signal Conditions
Actions and Assignments
Test Case 1 Case 2 Case 3
Procedure Call
Send Signal
Create Process
Other State
Terminate Process
Return to the Top Previous State
Figure 80
Summary of SDL state diagram graphical notation
7.2. Outlook
The mapping of a NMPDU into a CAN message is on the way to be confirmed among the vehicle manufacturers. Future requirements are visible, first steps to meet them were made:
Sub-net operating selective wake-up/go-to sleep via the bus lines a subset of nodes is active a subset of nodes is in a low power mode Gateway support monitoring of nodes across several networks negotiated operating modes across several networks
by OSEK/VDX
Page 133
OSEK/VDX
OSEK/VDX
Standardized Data Representation NMPDU inside a CAN message Network states simple certification API adding of service-prefix to simplify the readability negotiated operating modes across several networks optimized return value support sub-net operating e. g. by LogOff and LogOn Station Management e. g. algorithms specific to the application to handle a CAN bus-off
Page 134
by OSEK/VDX
OSEK/VDX
OSEK/VDX
8.
Index
List of all network management services, data types and internal activities.
CmpConfig 96 CmpStatus 100 ConfigHandleType 91 ConfigKindName 91 ConfigRefType 91 EventMaskType 89 GetConfig 95 GetStatus 99 GotoMode 98 InitCMaskTable 91 InitConfig 94 InitDirectNMParams 101, 105 InitExtNodeMonitoring 106 InitIndDeltaConfig 92 InitIndDeltaStatus 94 InitIndRingData 103 InitNMScaling 90 InitNMType 89 InitSMaskTable 93 InitTargetConfigTable 92 InitTargetStatusTable 93 NetIdType 89 NetworkStatusType 97 NMActive 118 NMBusSleep 118 NMInit 118 NMLimpHomeActive 121 NMLimpHomeActivePrepBusSleep 119 NMLimpHomePassive 121 NMLimpHomePassivePrepBusSleep 120 NMLimpHomeStandard 122 NMModeName 97 NMNormalActive 120 NMNormalActivePrepBusSleep 119 NMNormalPassive 121 NMNormalPassivePrepBusSleep 120
NMNormalStandard 122 NMOff 117 NMPassive 118 NMResetActive 121 NMResetActivePrepBusSleep 119 NMResetPassive 121 NMResetPassivePrepBusSleep 120 NMResetStandard 122 NMShutDown 117 NodeIdType 89 ReadRingData 104 RingDataType 103 RoutineRefType 89 SelectDeltaConfig 97 SelectDeltaStatus 101 SelectHWRoutines 90 SignallingMode 89 SilentNM 102 StartNM 98 StatusHandleType 97 StatusType 89 StopNM 98 TalkNM 102 TaskRefType 89 TickType 89 TransmitRingData 104
by OSEK/VDX
Page 135

NM 252

Uploaded by

Copyright:

Available Formats

NM 252

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NM 252

Uploaded by

Copyright:

Available Formats

OSEK/VDX

Open Systems and the Corresponding Interfaces for Automotive Electronics

Version 2.5.2 16th January 2003

NM Concept & API 2.5.2

Open Systems and the Corresponding Interfaces for Automotive Electronics

Network Management Concept and Application Programming Interface

Index ............................................................................................................................... 135

NM Concept & API 2.5.2

Network Management Concept and Application Programming Interface

Software: Network behavior:

Application program NM Station Communication medium

NM Concept & API 2.5.2

Network Management Concept and Application Programming Interface

ensure safety and reliability of a communication network for ECUs,

NM Concept & API 2.5.2

Network Management Concept and Application Programming Interface

Scope of the OSEK Network Management

Network Management OSEK 6) Algorithms Protocol 7) specific Algorithms 3)

Data Link Layer 2) Bus Communication Hardware

NM Concept & API 2.5.2

Network Management Concept and Application Programming Interface

NM Concept & API 2.5.2

Network Management Concept and Application Programming Interface

Direct Network Management

NM Concept & API 2.5.2

Network Management Concept and Application Programming Interface

Electronic Communication Unit

Infrastructure of the NM (logical ring), example with two buses

Time-out on ring message State of a node

NM Concept & API 2.5.2

Network Management Concept and Application Programming Interface

address related message

general protocol format

Exemplary representation of encoding of a NM communication message onto a general protocol format.

NM Concept & API 2.5.2

Network Management Concept and Application Programming Interface

-> .ind -> Read <- Transmit

Mechanism to transfer application data via the logical ring

2.1.4. Standard Functionality

2.1.5. Configuration Management

NM Concept & API 2.5.2

Network Management Concept and Application Programming Interface

Therefore NM provides the following services:

Detection of a Node in Fault Condition

NM Concept & API 2.5.2

Network Management Concept and Application Programming Interface

Internal Network Management States

NMOff NMOn NMShutDown

NM is shut off NM is switched on Selective shut off of NM entity

NMInit NMAwake NMBusSleep NMActive NMPassive

NMReset NMNormal NMLimpHome

NM Concept & API 2.5.2

Network Management Concept and Application Programming Interface

"data inconsistent" e.g. time out at ring message

Simplified state transition diagram of the direct NM.

NM Concept & API 2.5.2

Network Management Concept and Application Programming Interface

NM Concept & API 2.5.2

Network Management Concept and Application Programming Interface