Specification of the AUTOSAR Network

Management Protocol
AUTOSAR FO R23-11

Specification of the AUTOSAR

Document Title Network Management Protocol
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 928

Document Status published

Part of AUTOSAR Standard Foundation
Part of Standard Release R23-11

Document Change History

Date Release Changed by Description
AUTOSAR • Updates for AP and CP
2023-11-23 R23-11 Release NetworkManagement harmonization
Management • Reintroduced Use Cases chapter
AUTOSAR • Added definitions for network states
2022-11-24 R22-11 Release • Added definitions and clarifications for
Management Partial Networking NM protocol
• Updates for the rework of PNC related
AUTOSAR ComM and NM handling
2021-11-25 R21-11 Release
Management • Updates for AP and CP
NetworkManagement harmonization
• Moved Use Cases chapter to FO RS
NetworkManagement
AUTOSAR
• Added Partial Network Learning (PNL)
2020-11-30 R20-11 Release
bit in CBV
Management
• Added PN Shutdown Request Bit
(PNSR) bit in CBV
• Updated default positions for CBV and
AUTOSAR NID
2019-11-28 R19-11 Release
Management • Changed Document Status from Final to
published
AUTOSAR
2019-03-29 1.5.1 Release • No content changes
Management
5

1 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

4
AUTOSAR
2018-10-31 1.5.0 Release • Initial release
Management

2 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

Disclaimer

This work (specification and/or software implementation) and the material contained in
it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the
companies that have contributed to it shall not be liable for any use of the work.
The material contained in this work is protected by copyright and other types of intel-
lectual property rights. The commercial exploitation of the material contained in this
work requires a license to such intellectual property rights.
This work may be utilized or reproduced without any modification, in any form or by
any means, for informational purposes only. For any other purpose, no part of the work
may be utilized or reproduced, in any form or by any means, without permission in
writing from the publisher.
The work has been developed for automotive applications only. It has neither been
developed, nor tested for non-automotive applications.
The word AUTOSAR and the AUTOSAR logo are registered trademarks.

3 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

Contents
1 Introduction and overview 6
1.1 Protocol purpose and objectives . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Applicability of the protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Constraints and assumptions . . . . . . . . . . . . . . . . . . . 7
1.2.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Dependencies to other protocol layers . . . . . . . . . . . . . . 7
1.3.2 Dependencies to other standards and norms . . . . . . . . . . 7
1.3.3 Dependencies to the Application Layer . . . . . . . . . . . . . 7
2 Use Cases 8

3 Protocol Requirements 9
3.1 Requirements Traceability . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Definition of terms and acronyms 10
4.1 Acronyms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Definition of terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5 Protocol specification 13
5.1 NM message format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1 Source Node Identifier . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.2 Control Bit Vector . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.3 User Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 Partial Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.1 Handling of Rx NM messages . . . . . . . . . . . . . . . . . . 16
5.2.2 Handling of Tx NM messages . . . . . . . . . . . . . . . . . . 17
5.3 Timing behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.1 Sending NM message . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.2 Transition to Bus-Sleep Mode . . . . . . . . . . . . . . . . . . . 18
5.4 Networks specifics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4.1 CAN and Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4.2 FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5 Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.5.1 Communication request . . . . . . . . . . . . . . . . . . . . . . 22
5.5.2 Communication release . . . . . . . . . . . . . . . . . . . . . . 23
6 Configuration parameters 24
6.1 NM Message Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2 Timeout Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3 NM local configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7 Protocol usage and guidelines 26

8 References 27

4 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

A Change history of AUTOSAR traceable items 28

A.1 Traceable item history of this document according to AUTOSAR Re-
lease R23-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.1.1 Added Specification Items in R23-11 . . . . . . . . . . . . . . . 28
A.1.2 Changed Specification Items in R23-11 . . . . . . . . . . . . . 28
A.1.3 Deleted Specification Items in R23-11 . . . . . . . . . . . . . . 28

5 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

1 Introduction and overview

This protocol specification specifies the format, message sequences and semantics of
the AUTOSAR Network Management (NM) protocol.
NM is intended to work together with an underlying communication stack, independent
of the physical layer of the communication system used.
The AUTOSAR Network Management is a hardware independent protocol (for limita-
tions refer to chapter 1.2.2).
The following figure shows how the NM interfaces with an upper (see 1.3.3) and a lower
(bus) layer.

Figure 1.1: NM interfaces

1.1 Protocol purpose and objectives

Main purpose of the NM protocol is to coordinate one or more groups of ECUs to wake
up and shutdown their communication stack synchronously.
The NM algorithm is based on periodic NM messages, which are received by all nodes
in a NM cluster. Reception of NM messages indicates that sending nodes want to keep
NM cluster awake. If any node does not need communication any more, it stops send-
ing NM messages, but if NM messages from other nodes are received, it postpones
transition to sleep mode. Finally, if a dedicated timer elapses because no NM mes-
sages are received anymore, every node initiates transition to the sleep mode, the NM
node initiate the shutdown of the corresponding network.

6 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

If any node in the NM cluster requires bus-communication, it can keep the NM cluster
awake by transmitting NM messages.

1.2 Applicability of the protocol

1.2.1 Constraints and assumptions

There may exist NM nodes in the network which follow the protocol without ever actively
sending NM messages (called NM passive nodes).

1.2.2 Limitations

1. One NM instance is associated with only one NM cluster in one network. One
NM cluster can have only one instance of Nm in one node.
2. The maximum size of the NM message is limited by the used communication bus.
3. The NM Coordinator is only used in the AUTOSAR Classic Platform. Details can
be found in [1].

1.3 Dependencies

1.3.1 Dependencies to other protocol layers

NM algorithm uses services of the underlying communication stack modules to send

and receive NM messages.

1.3.2 Dependencies to other standards and norms

N/A

1.3.3 Dependencies to the Application Layer

Upper layer (e.g. application) uses NM services to request or release a network i.e. to
activate or deactivate sending of NM messages.
In addition, the upper layer/module may use the possibility to get informed about
changes of the NM operational modes.

7 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

2 Use Cases
The Use Cases for PRS Network Management Protocol are listed and described in the
chapter "Use Cases" of RS Adaptive Network Management [2]

8 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

3 Protocol Requirements

3.1 Requirements Traceability

Requirement Description Satisfied by

[RS_Nm_00047] Nm shall provide a service to request [PRS_Nm_00237] [PRS_Nm_00504]
to keep the bus awake and a service
to cancel this request.
[RS_Nm_00048] Nm shall put the communication [PRS_Nm_00103] [PRS_Nm_00115]
controller into sleep mode if there is
no bus communication
[RS_Nm_00054] There shall be a deterministic time [PRS_Nm_00103] [PRS_Nm_00115]
from the point where all nodes agree
to go to bus sleep to the point where
bus is switched off.
[RS_Nm_00150] Specific features of the Network [PRS_Nm_00013] [PRS_Nm_00045]
Management shall be configurable [PRS_Nm_00074] [PRS_Nm_00075]
[PRS_Nm_00158] [PRS_Nm_00328]
[PRS_Nm_00405] [PRS_Nm_00406]
[RS_Nm_02503] The Nm API shall optionally give the [PRS_Nm_00158]
possibility to send user data
[RS_Nm_02504] The Nm API shall optionally give the [PRS_Nm_00158]
possibility to get user data
[RS_Nm_02505] The Nm shall optionally set the local [PRS_Nm_00013] [PRS_Nm_00074]
node identifier to the Nm-message
[RS_Nm_02517] CanNm shall support Partial [PRS_Nm_00328] [PRS_Nm_00332]
Networking on CAN [PRS_Nm_00333] [PRS_Nm_00341]
[PRS_Nm_00412] [PRS_Nm_00413]
[RS_Nm_02519] The Nm Control Bit Vector shall [PRS_Nm_00328] [PRS_Nm_00329]
contain a PNI (Partial Network [PRS_Nm_00331] [PRS_Nm_00340]
Information) bit. [PRS_Nm_00409] [PRS_Nm_00410]
[PRS_Nm_00411]
[RS_Nm_02541] Nm shall define a common layout of [PRS_Nm_00077] [PRS_Nm_00501]
Nm messages. [PRS_Nm_00502] [PRS_Nm_00505]
[RS_Nm_02548] <Bus>Nm shall be able to propagate [PRS_Nm_00406] [PRS_Nm_00409]
and evaluate the need for [PRS_Nm_00411] [PRS_Nm_00412]
synchronized PNC shutdown in the [PRS_Nm_00413]
role of a top-level PNC coordinator or
intermediate PNC coordinator
(optional)

Table 3.1: RequirementsTracing

9 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

4 Definition of terms and acronyms

4.1 Acronyms and abbreviations

The glossary below includes acronyms and abbreviations relevant to the Network Man-
agement specification that are not included in the [3, AUTOSAR glossary].
Abbreviation / Acronym Description
CBV Control Bit Vector
FR FlexRay
NM Network Management
PN Partial Network
PNC Partial Network Cluster
PNI Partial Network Information
PNL Partial Network Learning

4.2 Definition of terms

Term Description
Network Mode In this state the network is requested or active.
Prepare Bus-Sleep Mode In this state the network is released or inactive.
Bus-Sleep Mode In this state the network is released or inactive. In this state no NM
message is sent
FlexRay communication cycle Part of FlexRay communication schedule consisting of time slots
(static or dynamic). Each FlexRay message is assigned to a spe-
cific time slot in one communication cycle.
NM cluster Set of NM nodes coordinated with the use of the NM algorithm.
NM Message Refers to the payload transmitted on the bus. It contains the User
Data as well as the Control Bit Vector and may contain the Source
Node Identifier.
Normal Operation In this state the node is sending periodic NM messages in order to
keep a NM cluster awake
Repeat Message State This state ensures that transition, through a repetitive transmission
of NM messages, to normal operation is visible for other nodes on
the bus
Repeat Message Request Request (received internally or externally via an NM message) to
transition back to the Repeat Message State
NM Node A ECU (electornic controll unit) which is connected to one or more
NM clusters
NM instance A NM instance represents the current status of one NM cluster in-
side one NM node
External Request Communication request via received NM message
Internal Request Communication request via a NM node internal (request by appli-
cation / uppler layer)
Passive wakeup A wakeup triggered by an external request
Active wakeup A wakeup triggered by an internal request
PNC Bit Vector Represent the Partial Network information in a NM frame
PNC Bit Vector Length Represent the length of a Partial Network information in bytes
PNC bit One bit with represent a particular Partial Network in the Partial
Network Bit Vector Length

10 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

Term Description
Top-level PNC coordinator An ECU acts as top-level PNC coordinator for those PNCs which
are actively coordinated on all assigned channels. This ECU has
the PNC gateway functionality enabled. The top-level PNC coordi-
nator triggers for those PNCs a synchronized PNC shutdown, if no
other ECU in the network requests them and if the synchronized
PNC shutdown is enabled. Note: For different PNCs it is possible
to have different top-level PNC coordinators. But for the same PNC
only one top-level coordinator is supported.
Intermediate PNC coordinator An ECU acts as intermediate PNC coordinator for those PNCs
which are passively coordinated on at least one channel. This ECU
has the PNC gateway functionality enabled. The intermediate PNC
coordinator forwards a synchronized PNC shutdown to active coor-
dinated channels for PNCs which are passively coordinated, if the
synchronized PNC shutdown is enabled.
PNC leaf node A PNC leaf node is an ECU that act neither as top-level PNC coor-
dinator nor as an intermediate PNC coordinator. It act as an ECU
without a PNC gateway in the network and process PN shutdown
message as usual NM messages.
PN shutdown message A top-level PNC coordinator transmits the PN shutdown messages
to indicate a synchronized PNC shutdown across the PN topology.
A PN shutdown message is an NM message where the PNSR bit
(resides in the control bit vector) and all PNC bits (reside in the
PNC Bit Vector) which are indicated for a synchronized shutdown
set to ’1’.
An intermediate PNC coordinator which receives a PN shutdown
message forwards the PNC Bit Vector as a PN shutdown message
on the affected channels.

Note: An intermediate PNC coordinator has to forward the

PNC Bit Vector of a received PN shutdown message as fast as
possible to ensure a synchronized shutdown of the affected PNCs
across the PN topology at nearly the same point in time.
PNC Gateway A PNC Gateway is used to span (logical) partial network clusters
across bus/communication channel boundaries, ”gatewaying” PNC
requests from one bus/network to the others. Therefore, a PNC
gateway needs to be connected to multiple physical communica-
tion channels. The PNC gateway collects PNC requests from all of
its multiple so-called ”active” coordinated channels.
The PNC gateway sends the aggregated PNC state in the network
to all its active channels, which causes all nodes to have the same
view on the global PNC request state as the gateway. If the PNC
gateway is not the topmost PNC gateway in the network hierar-
chy, the PNC gateway will also send the aggregated PNC request
state of all subordinate nodes, plus its own internal request state, to
its superior PNC coordinator, which is connected via the so-called
”passive” coordinated channel.
Active coordinated channel A PNC gateway has communication channels which must be co-
ordinated regarding the PNC requests. A PNC gateway collects
PNC requests from all of its active coordinated channels, aggre-
gates them and forwards it to all channels (independent if active
or passive coordinated). Active coordinated channels are actively
kept awake by this PNC gateway.

11 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

Term Description
Passive coordinated channel A PNC gateway has communication channels which must be co-
ordinated regarding the PNC requests. A PNC gateway collects
PNC requests from all of its passive coordinated channels, ag-
gregates them and forwards it to all active coordinated channels.
Passive coordinated channels are remotely kept awake by another
PNC gateway, which is connected to the same channel and actively
coordinates this channel.

12 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

5 Protocol specification

5.1 NM message format

[PRS_Nm_00501]{DRAFT} Contents of an Nm Message dAn Nm Message shall
consist of the following elements:
• Control Bit Vector (CBV) of 1 Byte (optional)
• Source Node ID (SNI) of 1 Byte (optional)
• User Data of n Bytes (optional, may include PN Request Vector of n Bytes)
c(RS_Nm_02541)
Note: There is an additional option to have a "Car Wakeup" bit.

[PRS_Nm_00502]{DRAFT} Format of an Nm Message dUser Data and/or PN Re-

quest Vector shall be located after CBV/SNIc(RS_Nm_02541)
Note: UserData and PN Request Vector may overlap.
The following table shows an example layout of an NM message:
Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Byte 0 Control Bit Vector (default)
Byte 1 Source Node Identifier (default)
Byte 2 User data 0
Byte 3 User data 1
Byte 4 User data 2
Byte 5 User data 3
... ...
Byte n User data n-2

Table 5.1: NM message layout example

[PRS_Nm_00505] dThe length of an NM message shall not exceed the MTU of the
underlying physical transport layer.
c(RS_Nm_02541)
[PRS_Nm_00077] dThe length (in bytes) of the NM message shall be configured by [
NmMessageLength].c(RS_Nm_02541)
Note: The length of the user data can be calculated from the NmMessageLength -
(amount of used system bytes).

13 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

5.1.1 Source Node Identifier

[PRS_Nm_00074] dThe location of the source node identifier shall be configurable to

position Byte 0 or Byte 1 or Off (default: Byte 1). For FlexRay the source node identifier
shall only be configurable to position Byte 1 or Off (default: Byte 1).c(RS_Nm_00150,
RS_Nm_02505)
[PRS_Nm_00013] dThe source node identifier shall be available (set to a configurable
value) unless the location of the source node identifier is set to Off.c(RS_Nm_00150,
RS_Nm_02505)

5.1.2 Control Bit Vector

[PRS_Nm_00075] dThe location of the Control Bit Vector shall be configurable to po-
sition Byte 0 or Byte 1 or Off (default: Byte 0). For FlexRay the Control Bit Vector shall
be non-configurable and always be set to position Byte 0.c(RS_Nm_00150)
[PRS_Nm_00045] dThe Control Bit Vector shall consist of:
• Bit 0: Repeat Message Request
0: Repeat Message State not requested
1: Repeat Message State requested
• Bit 1: PN Shutdown Request Bit (PNSR)
0: NM message does not contain synchronized Partial Network shutdown
request
1: NM message does contain synchronized Partial Network shutdown re-
quest for at least one PNC
• Bit 3: NM Coordinator Sleep Ready Bit
0: Start of synchronized shutdown is not requested by main coordinator
1: Start of synchronized shutdown is requested by main coordinator
• Bit 4: Active Wakeup Bit
0: Node has not woken up the network (passive wakeup)
1: Node has woken up the network (active wakeup)
• Bit 5: Partial Network Learning Bit (PNL)
0: PNC learning is not requested
1: PNC learning is requested
• Bit 6: Partial Network Information Bit (PNI)
0: NM message contains no Partial Network request information

14 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

1: NM message contains Partial Network request information

• Bits 2,7 are reserved for future extensions
0: Disabled/Reserved for future usage
c(RS_Nm_00150)
Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Byte 0/1 Reserved Partial Partial Active NM Co- Reserved PN Shut- Repeat
Network Network Wakeup ordinator down Re- Message
Informa- Learning Sleep quest Bit Request
tion Ready

Table 5.2: CBV layout

Note: For FlexRay bit 7 is used as the Vote bit in certain schedule variants.
Note: Bit 1 and 2 were used in R3.2 as NM Coordinator ID (Low Bit)

5.1.3 User Data

User Data is considered all data not being part of CBV and NID.
[PRS_Nm_00158] dIt shall be possible to enable or disable the support of NM user
data (NM user data is optional).c(RS_Nm_00150, RS_Nm_02503, RS_Nm_02504)

5.2 Partial Networking

[PRS_Nm_00405] dIt shall be possible to enable or disable the PN support (PN feature
is optional).c(RS_Nm_00150)
[PRS_Nm_00406] dIt shall be possible to enable or disable the handling of synchro-
nized PNC shutdown (handling is optional). If handling is enabled, then also PN sup-
port shall be enabled.c(RS_Nm_00150, RS_Nm_02548)
[PRS_Nm_00335] dIf PN Support is enabled, the layout of the PNC Bit Vector within
the NM message shall be pre-configured with PnInfoOffset and PnInfoLength (in
bytes).c()
Note:
Every bit (PNC bit) of the PNC Bit Vector Length represents one Partial Network. The
following interpretation has to be considered:
• PNI bit ="’1"’ and PNSR = "‘0"’: If the PNC bit is set to 1 the Partial Network is
requested. If the bit is set to 0 there is no request for this PN.
• PNI bit ="’1"’ and PNSR = "‘1"’ (received by a top-level PNC coordinator): ignore
the PNSR bit and handle the message as a usual NM message. A top-level
PNC coordinator should never receive a PN shutdown request. This is an error

15 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

case, where an intermediate PNC coordinator or PNC leaf node sets the PNSR
bit within the Nm message by accident.
• PNI bit ="’1"’ and PNSR = "‘1"’ (received by an intermediate PNC coordinator):
All the Partial Network were the corresponding PNC bits in the PNC Bit Vector
are set to 1 are indicated to be released. The remaining Partial Network (the
corresponding PNC bits are set to 0) are not affected.
• PNI bit ="’1"’ and PNSR = "‘1"’ (received by a PNC leaf node): same as if PNI bit
="’1"’ and PNSR = "‘0"’
Note: Each bit (PNC bit) of the PNC Bit Vector represent a particular PNC. The
byteIndex and bitIndex within the PNC Bit Vector of a PNC bit can be determined as
follows: byteIndex = (PncId div 8); bitIndex = (PncId mod 8).

[PRS_Nm_00338] dIf the PN Support is enabled, and if a message containing a PNC

bit set to 1 is received, and the ECU is interested in this PNC, that PNC shall be
considered "externally requested".c()
[PRS_Nm_00407] dIf the PN Support is enabled, and if a message containing a PNC
bit set to 0 is received, and the ECU is interested in this PNC, that PNC shall be
considered "externally released".c()
[PRS_Nm_00339] dIf the PN Support is enabled, and if one or more applications are
requesting a PNC, and the ECU is interested in this PNC, this PNC shall be considered
"internally requested".c()
[PRS_Nm_00408] dIf the PN Support is enabled, and if no application of an ECU is re-
questing a PNC anymore, then this PNC shall be considered as "internally released".c
()

5.2.1 Handling of Rx NM messages

[PRS_Nm_00328] dIf PN support is disabled, then its NM shall ignore any partial net-
working information contained in the received message.c(RS_Nm_00150, RS_Nm_-
02517, RS_Nm_02519)
[PRS_Nm_00329] dIf the PN support is enabled, and the PNI bit in the received NM
message is 0, the node’s NM shall ignore the partial networking information bytes of
the message.c(RS_Nm_02519)
[PRS_Nm_00331] dIf the PN support is enabled, the PNI bit is set to 1 and the PNSR
bit is set to 0 in the received NM message, NM shall process the Partial Networking
Information of the NM message.c(RS_Nm_02519)
[PRS_Nm_00409] dIf synchronized PNC shutdown is enabled, a NM message is re-
ceived in the role of a top-level PNC/intermediate PNC coordinator on an active coordi-

16 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

nated channel and PNI bit and PNSR bit are set to 1, then NM shall ignore the PNSR bit
and handle the message as a usual NM message.c(RS_Nm_02519, RS_Nm_02548)
Note: A PN shutdown message (PNI bit = 1 and PNSR bit = 1) should never be re-
ceived by a top-level/intermediate PNC coordinator on an active coordinated channel,
because only a top-level PNC coordinator of a dedicated PNC could initiate a PN
shutdown message. This is an error case where an intermediate PNC coordinator
transmits a PN shutdown message by accident on an active coordinated channel. A
receiving top-level/intermediate PNC coordinator should handle this message as a
usual NM message.

[PRS_Nm_00410] dIf the PN synchronized shutdown error reaction is enabled and the
received NM message is discarded due to [PRS_Nm_00409], then the top-level PNC
coordinator shall immediately transmit an NM message with all "‘internally requested"’
and "‘externally requested"’ PNCs as Partial Network Information.c(RS_Nm_02519)
[PRS_Nm_00411] dIf synchronized PNC shutdown is enabled, an NM message is re-
ceived in the role of an intermediate PNC coordinator on a passive coordinated channel
and PNI bit and PNSR bit are set to 1, then NM shall release the indicated PNCs (PNC
bits which are set to 1 within the PNC bit vector), reset the PN reset timer and forward
the received NM message with PNI bit and PNSR bit set to 1 and the according PNCs
set to 1 to all subordinated ECUs.c(RS_Nm_02519, RS_Nm_02548)
Note:

• An intermediate PNC coordinator has to forward the received NM message to all

remaining communication channels.
• Subordinated ECUs could be either further intermediate PNC coordinators and/or
PNC leaf nodes.
• A PNC leaf node has no special handling upon reception of a PN shutdown mes-
sage. It just handles the received NM message as specified in [PRS_Nm_00331].
[PRS_Nm_00340] dIf the PN support is enabled, and if one PNC is not requested
again (relevant PNC bit is not set to 1 again) within [PnResetTime] this PN shall be
considered as "not requested".c(RS_Nm_02519)
Note: PnResetTime is configured to a value greater than NmMsgCycleTime.

5.2.2 Handling of Tx NM messages

[PRS_Nm_00332] dIf the PN support is enabled, its NM shall set the value of the
transmitted PNI bit in the CBV to 1.c(RS_Nm_02517)
[PRS_Nm_00333] dIf the PN support is disabled, its NM shall set the value of the
transmitted PNI bit in the CBV to 0.c(RS_Nm_02517)

17 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

[PRS_Nm_00341] dIf the PN support is enabled, for PNCs that are "internally re-
quested" the corresponding bit in the PNC Request Bit Vector shall be set to 1 before
sending the NM message.c(RS_Nm_02517)
Constraint: The usage of the CBV is mandatory in case Partial Networking is used.
This must be ensured by configuration in the respective platform.
[PRS_Nm_00412] dIf the PN support is enabled, for PNCs that are "‘internally re-
quested"’ or "‘externally requested"’ the corresponding bit in the PNC Request Bit Vec-
tor shall be set to 1 before sending the NM message in the role of a top-level PNC
coordinator or an intermediate PNC coordinator.c(RS_Nm_02517, RS_Nm_02548)
[PRS_Nm_00413] dIf synchronized PNC shutdown is enabled and NM detect an tran-
sition of PNCs from "‘requested"’ to "‘released"’ (independent if externally or internally
requested), the corresponding bit of those released PNCs shall be set to 1, the remain-
ing shall be set 0 and the PNSR bit in CBV shall be set to 1 before sending the PN
shutdown message.c(RS_Nm_02517, RS_Nm_02548)

5.3 Timing behavior

5.3.1 Sending NM message

If communication on the bus is needed i.e. requested, NM messages are sent out. If
no communication is needed i.e. released, sending of NM messages is stopped.
[PRS_Nm_00237] dNM messages shall be sent periodically in states "Repeat Mes-
sage" and "Normal Operation" using configured NM Message Cycle Time (NmMsgCy-
cleTime).c(RS_Nm_00047)
[PRS_Nm_00005] dIf the "Repeat Message" state is not entered beacuse of network
request OR NM transmissions is zero (see NmImmediateNmTransmissions) the
transmission of NM messages shall be delayed by NM Cycle Offset (see NmMsgCy-
cleOffset) after entering the "Repeat Message" state.c()
[PRS_Nm_00334] dWhen the "Repeat Message" state is entered because of network
request or repeat message request and configured number of immediate NM transmis-
sions is greater than zero (see NmImmediateNmTransmissions), these immediate
NM messages shall be transmitted using Immediate NM Cycle Time (see NmImmedi-
ateNmCycleTime). NM Cycle Offset (see NmMsgCycleOffset) shall not be applied
in this case.c()

5.3.2 Transition to Bus-Sleep Mode

When a NM node does not need the communication on a bus, it will not immediately
shut down i.e. switch to Bus-Sleep Mode. Instead, it will first change to the so called
Ready Sleep state. This state ensures that any NM node in the NM cluster waits to

18 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

transition to the Bus-Sleep Mode as long as any other node keeps the NM cluster
awake.
[PRS_Nm_00103] dIf bus communication is released, the NM algorithm shall perform
transition to the Bus-Sleep Mode after a configurable amount of Ready Sleep Time has
expired and no new communication request occurs in between and no NM Message
has been received.c(RS_Nm_00048, RS_Nm_00054)
Note: The Ready Sleep Time depends on the used network, refer to 5.4.

5.4 Networks specifics

5.4.1 CAN and Ethernet

On the transition path from Network to Bus-Sleep Mode, CAN NM and UDP NM intro-
duce Prepare Bus Sleep Mode. The purpose of this state is to ensure that all nodes
have time to stop their network activity before the Bus Sleep state is entered.
[PRS_Nm_00506]{DRAFT} dIf NmStayInPbsEnabled is disabled and bus communi-
cation in a NM cluster is released, and there are no Network Management PDUs on the
bus for a configurable amount of time determined by NM Timeout Time (NmTimeOut-
Time) + Wait Bus-Sleep Time (NmWaitBusSleepTime) transition into the BusSleep
Mode shall be performed.c()
[PRS_Nm_00115] dIf NmStayInPbsEnabled is disabled the NM shall stay in the Pre-
pare Bus-Sleep Mode for an amount of time determined by the Wait Bus-Sleep Time.
After this time has expired, the Prepare Bus-Sleep Mode shall be left, and the Bus-
Sleep Mode shall be entered.c(RS_Nm_00048, RS_Nm_00054)
Note: Thus the Ready Sleep Time is extended by Wait Bus-Sleep Time (NmWaitBus-
SleepTime). The Ready Sleep Time on CAN and Ethernet starts when bus commu-
nication is released and it ends NM Timeout Time (NmTimeOutTime) after last NM
messages was transmitted or received on the bus.
[PRS_Nm_00504]{DRAFT} dWhen in Prepare Bus-Sleep Mode, and an NM message
is received, or the NM is requested for communication, than NM shall enter Network
Mode.c(RS_Nm_00047)
The following requirements concerns early shutdown. It does only apply to CAN and
Ethernet, since on FlexRay always all messages have to be considered (FlexRay can-
not shutdown earlier nodes):
[PRS_Nm_00503]{DRAFT} dIt shall be possible to enable or disable All Nm Messages
Keep Awake functionality.c()
[PRS_Nm_00337] dIf PN support is enabled, and All Nm Messages Keep Awake func-
tionality is disabled, the NM algorithm shall only process messages if they contain at
least one bit set to 1 in the PNC Request Bit Vector, that corresponds to a PNC which
is relevant for the ECU.c()

19 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

5.4.2 FlexRay

In addition to NM message containing data (see Figure 5.1), the FlexRay NM specifies
so-called NM-Vote messages.
In fact, the FlexRay NM algorithm is based on periodic NM-Vote messages received by
all nodes in the cluster. Reception of a NM-Vote message indicates that the sending
node wants to keep the NM cluster awake.
Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Byte 0 Vote Set to "0"

Table 5.3: NM-Vote message layout

[PRS_Nm_00116] dThe NM-Vote message format shall contain a Voting Bit (Vote) with
the following meaning:
0 - vote against keeping awake
1 - vote for keeping awake
c()
[PRS_Nm_00117] dThe FlexRay NM shall be able to separately transmit NM-Data and
NM-Vote, or to combine them within one NM message (in either static or dynamic slot).
Transmission format shall be configurable (Schedule Variant).c()
When the NM-Vote and NM-Data are combined (by Bit OR-ing) within one NM mes-
sage, the content of the NM-Vote will be combined with the content of the Control Bit
Vector Byte.
Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Byte 0 Vote Partial Partial Active NM Co- Reserved Reserved Repeat
Network Network Wakeup ordinator Message
Informa- Learning Sleep Request
tion Ready

Table 5.4: Combined NM-Vote and CBV

Each ECU, which participates in the FlexRay NM, is synchronized to a global time
based on periodic repetition of the FlexRay communication cycle. To assure syn-
chronous behaviour of all ECUs in a NM cluster, the FlexRay NM aligns the state
changes to a NM Repetition Cycle, which is aligned to a FlexRay communication cycle.
Every transition is bound to repetition cycles (refer to configuration parameter NmRep-
etitionCycle). Therefore the Ready Sleep Time is defined as the time that starts when
a new repetition cycle starts after bus communication has been released and ends
NmReadySleepCnt+1 repetition cycles without any NM-Vote.
[PRS_Nm_00118] dThe FlexRay NM shall specify the following cycle configuration
parameters:

20 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

Voting Cycle - number of cycles needed to transmit NM-Vote of every node at

least once
Data Cycle - number of cycles needed to transmit the NM-Data of every node at
least once
Repetition Cycle - number of repetitions of Voting Cycle
c()
Note: Further details can be found in the AUTOSAR SWS FlexRay specifications.

21 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

5.5 Sequences

5.5.1 Communication request

Figure 5.1: Communication request

22 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

5.5.2 Communication release

Figure 5.2: Communication release

23 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

6 Configuration parameters
This chapter lists all parameters the NM protocol uses.

6.1 NM Message Layout

Parameter Description
NmNidPosition Defines the position of the source node identifier (if used) within
the NM message
NodeId Node identifier of local node
NmCbvPosition Defines the position of the Control Bit Vector (if used) within the
NM message
UserDataEnabled Enables/disables user data support
NmMessageLength Specifies the length (in bytes) of the NM message
PnEnabled Enables/disables support of partial networking
PnInfoOffset Offset of the PN request information in the NM message. The
offset to the PNC data can only be configured to either be directly
after the system bytes or after the user data.
PnInfoLength Length of the PN request information in the NM message

6.2 Timeout Parameters

Parameter Description
NmTimeOutTime The time for a node between the reception of the last NM mes-
sage keeping it awake to the transition to Bus Sleep
NmMsgCycleTime The transmission periodicity of an NM message by a node
NmMsgCycleOffset The start delay of a transmission of Nm messages in Repeat
Message State
NmRepeatMessageTime The time for a node to remain in Repeat Message State
NmWaitBusSleepTime Timeout for bus calm down phase. It denotes the time in sec-
onds how long the NM shall stay in the Prepare Bus-Sleep Mode
before transition into Bus-Sleep Mode (CAN NM, UDP NM only).
NmReadySleepCnt Ready sleep counter. After NmReadySleepCnt+1 repetition cy-
cles without any NM-Vote, NM enters Bus-Sleep (FR NM only).
NmImmediateNmCycleTime Defines the immediate NM message cycle time in seconds used
in Repeat Message state (CAN NM, UDP NM only)
NmImmediateNmTransmissions Number of immediate NM messages which shall be transmitted
in Repeat Message state (CAN NM, UDP NM only)
NmDataCycle Number of FlexRay Schedule Cycles needed to transmit NM-
Data of all ECUs (FR NM only)
NmVotingCycle Number of FlexRay Schedule Cycles needed to transmit NM-Vote
of all ECUs (FR NM only)
NmRepetitionCycle Number of NM voting cycles where no change of voting behavior
is possible (FR NM only)
NmScheduleVariant Defines the transmission scheduling variant for sending NM-Vote
and NM-Data
PnResetTime Time a PNC is considered reqested externally after the last mes-
sage containing the corresponding bit set to one has been re-
ceived

24 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

6.3 NM local configuration

Parameter Description
SynchronizedPncShutdownEnabled Enable/Disable a synchronized PNC shutdown
NmStayInPbsEnabled If this parameter is disabled Prepare Bus-Sleep Mode is
left after NmWaitBusSleep Time. If this parameter is en-
abled Prepare Bus-Sleep Mode can only be left if ECU is
powered off or any restart reason applies.

25 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

7 Protocol usage and guidelines

No additional guidelines or How-To instructions for implementer.
All relevant information already provided in previous chapters.

26 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

8 References

[1] Specification of Network Management Interface

AUTOSAR_CP_SWS_NetworkManagementInterface
[2] Requirements on AUTOSAR Network Management
AUTOSAR_FO_RS_NetworkManagement
[3] Glossary
AUTOSAR_FO_TR_Glossary

27 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol

 Specification of the AUTOSAR Network
Management Protocol
AUTOSAR FO R23-11

A Change history of AUTOSAR traceable items

Please note that the lists in this chapter also include traceable items that have been
removed from the specification in a later version. These items do not appear as hyper-
links in the document.

A.1 Traceable item history of this document according to AU-

TOSAR Release R23-11

A.1.1 Added Specification Items in R23-11

Number Heading
[PRS_Nm_00005]
[PRS_Nm_00505]
[PRS_Nm_00506]
Table A.1: Added Specification Items in R23-11

A.1.2 Changed Specification Items in R23-11

Number Heading
[PRS_Nm_00115]
[PRS_Nm_00334]
Table A.2: Changed Specification Items in R23-11

A.1.3 Deleted Specification Items in R23-11

none

28 of 28 Document ID 928: AUTOSAR_FO_PRS_NetworkManagementProtocol