Requirements on AUTOSAR Network

Management
AUTOSAR FO Release 1.5.1

Document Title Requirements on AUTOSAR

Network Management
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 927

Document Status Final

Part of AUTOSAR Standard Foundation
Part of Standard Release 1.5.1

Document Change History

Date Release Changed by Description
AUTOSAR
2019-03-29 1.5.1 Release • No content changes
Management
AUTOSAR
2018-10-31 1.5.0 Release • Initial release
Management

1 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

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.

2 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

Table of Contents
1 Scope of Document 4

2 Conventions to be used 5

3 Acronyms and abbreviations 6

4 Requirements Specification 7
4.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.3 Normal Operation . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.4 Fault Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.5 Gateway Operation . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.6 Partial Networking . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Non-Functional Requirements (Qualities) . . . . . . . . . . . . . . . . . 25
4.2.1 Timing Requirements . . . . . . . . . . . . . . . . . . . . . . 25
4.2.2 Resource Usage . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.3 Hardware independency . . . . . . . . . . . . . . . . . . . . 28
5 Requirements Tracing 28

6 References 30

3 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

1 Scope of Document
This document specifies requirements on the AUTOSAR Network Management.

The requirements apply on following functional entities:

• Network Management coordinating a particular NM-cluster.
• Network Management bus specifics for a particular bus.
• Gateway and Interoperability of Network Management between NM-clusters.
The communication system where NM is applicable has to support a “bus sleep” mode.
That means that the transceiver of the communication system can switch to a low
power mode and can be switched again to full power mode by (specific) bus traffic
and/or application.

4 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

2 Conventions to be used
The representation of requirements in AUTOSAR documents follows the table spec-
ified in [TPS_STDT_00078], see Standardization Template [1], chapter Support for
Traceability.
The verbal forms for the expression of obligation specified in [TPS_STDT_00053] shall
be used to indicate requirements, see Standardization Template [1], chapter Support
for Traceability.

5 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

3 Acronyms and abbreviations

Abbreviation / Acronym Description

EIRA External and Internal Requests Aggregated
ERA External Requests Aggregated
NM Network Management
PN Partial Network
PNI Partial Network Information

Term Description
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.
NM Node A ECU (electornic controll unit) which is connected to one or more
NM clusters
NM cluster Set of NM nodes coordinated with the use of the NM algorithm.
NM instance A NM instance represents the current status of one NM cluster in-
side one NM node

The acronyms/abbreviations and terms not provided in tables above are included in the
AUTOSAR Glossary [2].

6 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

4 Requirements Specification

4.1 Functional Requirements

4.1.1 Configuration

[RS_Nm_00150] Specific functions of the Network Management shall be config-

urable d

Type: valid
The following functions of the Network Management shall be configurable:
- Detection of present nodes (on/off) – [RS_Nm_00153]
- Notification that all other ECUs are (no more) ready to sleep (i.e.
Remote Sleep Indication (Cancellation)) (on/off) – [RS_Nm_00052],
[RS_Nm_02509]
- NM Coordination support (on/off) – [RS_Nm_02514]
- User data support (on/off) – [RS_Nm_02503], [RS_Nm_02504]
- Bus load reduction (on/off) – [RS_Nm_00142]
Description: - Sending node identifier (on/off) – [RS_Nm_02505]
- Receiving node identifier (on/off) – [RS_Nm_02506]
- Immediate Transmission Confirmation (on/off)
- Configurable Role In Cluster Shutdown (on/off) – [RS_Nm_02511]
- Bus Keep Awake Services (on/off) – [RS_Nm_00047]
- Partial Networking extensions (on/off) – [RS_Nm_02517]
- EIRA (External and Internal Requests Aggregated) reset timer timeout –
[RS_Nm_02525] and [RS_Nm_02526]
Rationale: Scalability
Dependencies: –

Use Case: Configuration of ECU SW

AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)

4.1.2 Initialization

[RS_Nm_00151] The Network Management algorithm shall allow any node to in-
tegrate into an already running NM cluster d

7 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

Type: valid
The Network Management algorithm shall allow any node to integrate into an
Description:
already running NM cluster.
Integration of
a) Late nodes
Rationale: b) nodes that have recovered from fault state
c) nodes that have been connected to a running vehicle network (e.g. by
service)
Dependencies: –
Use Case: See rationale
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_00043] NM shall not prohibit bus traffic with NM not being initialized d

Type: valid
It shall be possible that software modules are enabled to access the
Description: communication system, independent of the presence of NM (NM initialized or
not).
Initialization delays or errors of NM shall not prohibit the communication of
Rationale:
application software.
Dependencies: –

Use Case: ECU without NM or NM starts later (see rationale)

AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)

4.1.3 Normal Operation

[RS_Nm_00044] The NM shall be applicable to different types of communication

systems which are in the scope of Autosar and support a bus sleep mode. d

Type: valid
5

8 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

4
Network management mechanisms for each supported protocol shall be
realized using a limited number of predefined NM states and NM transitions.
The events triggering the transitions between states and the actions taken on
these transitions may be protocol specific. A bus sleep mode shall be
Description:
supported for each protocol. NM shall be executable on asynchronous
communication systems (e.g. CAN) as well as on synchronous communication
systems (e.g. FlexRay), and also on any other types of communication systems
which are in the scope of Autosar.
In today’s cars, multiple different communication systems are implemented. For
energy consumption, all ECUs have to be able to switch into a low power mode.
Rationale: Therefore, network management is necessary for all communication systems.
To facilitate understanding, NM shall be constructed from a common set of
state definitions.
Dependencies: –

Use Case: ECU with CAN and FlexRay, Ethernet

AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02515] NM shall offer a generic possibility to run other NMs than the
AUTOSAR-NMs d

Type: valid
Support for managing a non AUTOSAR-NM based network shall be done either
by extending/modifying an existing bus-specific NM or by introducing a
Complex Device Driver (CDD) which uses the generic interfaces of the NM.
Description: Support for running both one of the AUTOSAR-NM and a non AUTOSAR-NM
on a single network shall be done the same way.
The actual extensions for bus-specific NMs or CDDs are not specified by
AUTOSAR.
Rationale: –
Dependencies: –

Use Case: Running OSEK-NM or another Legacy-NM on one of the networks.

AppliesTo: CP
Supporting –
Material:

c(RS_Main_00190)
[RS_Nm_00045] NM shall provide services to coordinate shutdown of NM-
clusters independently of each other d

9 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

Type: valid
NM has to provide services to coordinate shutdown of NM-clusters
Description:
independently of each other.
In today’s cars, multiple different communication systems are implemented.
Therefore, ECUs might be connected to multiple communication channels (e.g.
Rationale: 2 CAN clusters, 1 FlexRay cluster, etc.). Not in all cases all channels have to be
in full power mode. Because of that, each channel has to be able to be started
up or shut down separately.
Dependencies: –

Use Case: Gateways with more than one bus

AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02513] NM shall provide functionality which enables upper layers to
control the sleep mode. d

Type: valid
NM shall provide an interface which enable upper layers to coordinate the
Description:
different NM modes (especially sleep and wake-up/keep awake).
Enable control of NM from the upper layers.
Rationale:
Enable the NM Coordinator to control multiple bus-specific NMs.
Dependencies: –
Control of NM
Use Case:
NM Coordinator
AppliesTo: AP, CP
Supporting Related requirement [RS_Nm_02512]
Material:

c(RS_Main_00420)
[RS_Nm_00046] It shall be possible to trigger the startup of all Nodes at any Point
in Time d

Type: valid
At a specific point in time all nodes connected to NM-cluster have to be
started-up (e.g. if the car is started). Because of that NM has to provide
services to start up NM of all nodes connected to a NM-cluster at any point in
time. The point in time can not be calculated offline, therefore this service has
Description:
to be accessible at any time.
Note regarding FlexRay networks: Under certain circumstances, a shutdown
may be required before a startup can occur. In this situation substantial delays
may occur.
5

10 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

4
All nodes means all nodes connected to clamp 30 (nodes permanently
connected to power supply). ECUs connected to clamp 15 (nodes power
supplied through some power relay) have to be treated separately, due to the
Rationale:
fact that they cannot be started-up at any point in time. Note: "Passive Nodes"
are not able to initiate a start-up of a NM-cluster, but they are able to be woken
up if any other node initiates a start-up. Please refer [RS_Nm_02511]
Dependencies: –

Use Case: Driver enters the car and wants to start the engine.
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_00047] NM shall provide a service to request to keep the bus awake and
a service to cancel this request. d

Type: valid
The application implemented on one ECU must be enabled to signal at any
point in time after the NM has been initialized, that it requests to keep the bus
Description: awake and at any other point in time want to cancel this request.
These bus keep awake services shall not be available for nodes configured to
not contribute to the cluster shutdown decision, refer [RS_Nm_02511]
Rationale: Basic NM functionality
Dependencies: –
Use Case: See Rationale
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_00048] NM shall put the communication controller into sleep mode if
there is no bus communication d

Type: valid
If no Application/ECU connected to a NM-cluster requires bus communication,
Description:
NM shall indicate to put the communication controller into sleep mode.
Rationale: Basic NM functionality
Dependencies: [RS_Nm_00047]
Use Case: See Rationale
AppliesTo: AP, CP
5

11 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

4
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_00050] The NM shall provide the current state of NM d

Type: valid

Description: The NM shall provide an interface to retrieve information about the current state
of NM.
The application shall be able to get NM state information by accessing specific
Rationale:
interfaces of NM. The NM state reflects the state of the bus.
Dependencies: –
Use Case: See Rationale
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_00051] NM shall inform application when NM state changes occur. d

Type: valid
NM shall provide an interface, which can be used by applications to get
Description:
informed when specific NM state changes occur.
Rationale: Applications shall be enabled to react on state changes.
Dependencies: –

Use Case: Especially the transition to sleep state to switch off transceiver is interesting.
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_00052] The NM interface shall signal to the application that all other
ECUs are ready to sleep. d

Type: valid
NM shall provide an interface, which signals to an application that all other
Description:
applications/ECUs are ready for sleep.
Rationale: Prohibition of unintentional keep awake.
Dependencies: [RS_Nm_02509]
5

12 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

4
Internal check in the application if ECU unintentionally keeps the bus awake.
Use Case: External network management coordination.
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02509] The NM interface shall signal to the application that at least one
ECU is not ready to sleep anymore. d

Type: valid
NM shall provide an interface, which signals to an application that at least one
Description:
other applications/ECUs is not ready for sleep anymore.
Rationale: Notification that a bus is kept awake if necessary.
Dependencies: [RS_Nm_00052]
Identification of the last node that keeps the bus awake.
Use Case: External network management gateway coordination.
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02503] The NM API shall optionally give the possibility to send user
data d

Type: valid
The NM API shall optionally give the possibility to set the user data that may be
Description: attached to every NM message sent on the bus.
NM shall guarantee data consistency for the write operation.
Rationale: Exchange of system relevant information within the network.
Dependencies: –

Use Case: Distribution of wakeup-reason in the network.

AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02504] The NM API shall optionally give the possibility to get user data
d

13 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

Type: valid
The NM API shall optionally give the possibility to get the user data that may be
Description: included in a received NM message.
NM shall guarantee data consistency for the read operation.
Rationale: Exchange of system relevant information within the network.
Dependencies: –

Use Case: Distribution of wakeup-reason in the network.

AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_00153] The Network Management shall optionally provide a possibility
to detect present nodes d

Type: valid
The Network Management shall optionally provide a possibility to detect nodes
that are currently present on the bus. It shall be possible that nodes, on
request, send their NM-related data.
Description:
This feature is statically configurable(available or not)(see [RS_Nm_00150]).
Comment: This function is only needed in master ECUs (e.g. head unit, central
body controller, ...)
Rationale: For diagnostics purposes and configuration checks.
Dependencies: –
The Vehicle State Management can use this information to check the
Use Case:
completeness of the network.
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02508] Every node shall have associated with it a node identifier that is
unique in the NM-cluster d

Type: valid

Description: Every node shall have associated with it a node identifier that is unique in the
NM-cluster.
Rationale: Avoidance of node misidentification.
Dependencies: –
Identification of the last node that keeps the bus awake.
Use Case:
Detection of present nodes.
5

14 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

4
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02505] The NM shall optionally set the local node identifier to the NM-
message d

Type: valid
Description: The NM shall optionally set the local node identifier to the NM-message.
Rationale: Exchange of system relevant information within the network.
Dependencies: –
Identification of the last node that keeps the bus awake.
Use Case:
Detection of present nodes.
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02506] The NM API shall give the possibility to read the source node
identifier of the sender d

Type: valid
The NM API shall give the possibility to read the source node identifier of the
sender from the most recently received NM message. NM shall guarantee data
Description: consistency for the read operation.
Note: This NM API is optional, since it is optional to send the source node
identifier.
Rationale: Exchange of system relevant information within the network.
Dependencies: –
Identification of the last node that keeps the bus awake.
Use Case:
Detection of present nodes.
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02511] It shall be possible to configure the Network Management of a
node in Cluster Shutdown d

15 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

Type: valid
It shall be possible to configure the Network Management of a node so that it
does not contribute to the cluster shutdown decision.
Specifically, it shall be possible to configure some nodes of a cluster so that
Description: they are not able to broadcast the information used by other nodes to trigger
shutdown, i.e., they have no NM-related communication defined for the node.
Such nodes shall not be capable of keeping the bus awake, but they are
required to shut down in a manner consistent with the others.
Eliminating unnecessary communication reduces bus and buffer overhead.
Allowing shutdown to be controlled by a subset of the cluster’s nodes enables
Rationale:
the possibility that only fault tolerant nodes control shutdown. However, these
nodes shall be otherwise capable of normal communication.
Dependencies: –
In a dual channel FlexRay cluster with some single channel nodes, the cluster
can be configured so that only dual channel nodes influence the shutdown.
Use Case: This ensures that all shutdown votes are replicated on across channels even
though some nodes are only connected to one channel, thus making the
decision process robust against the loss of a channel.
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02536] NM shall provide an interface which triggers the transition to the
Network Mode without keeping the network awake d

Type: valid
NM shall provide an interface which triggers the transition to the Network Mode
Description:
without keeping the network awake.
A node has to participate to the network management without actively
Rationale: requesting communication.
Dependencies: –

Use Case: A bus wake-up occurs.

AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02512] The NM shall give the possibility to enable or disable the net-
work management related communication configured for an active NM node d

16 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

Type: valid
The NM shall give the possibility to enable or disable the network management
Description: related communication configured for an active NM node.
By default network management related communication shall be enabled.
Rationale: Conformance to ISO 14229 CommunicationControl (28 hex) service
Dependencies: [RS_Nm_02511]
Use Case: Diagnostics
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)

4.1.4 Fault Operation

[RS_Nm_00053] NM on a node which is or become bus unavailable shall have a

deterministic Behavior d

Type: valid
NM on a node which is or become bus unavailable shall react such that:
• If a bus becomes unavailable and the node is not ready to sleep, the NM
shall not enter bus sleep mode by itself.
• If a bus becomes unavailable and the node is ready to sleep, the NM
Description: shall enter bus sleep mode by itself.
• If a bus is unavailable and the node changes its state to ready to sleep,
the NM shall enter bus sleep mode by itself.
• If a bus is unavailable and the node changes its state to not ready to
sleep, the NM shall not enter bus sleep mode by itself.
Rationale: Faults (transient and/or permanent) shall not cause non deterministic behavior.
Dependencies: –

Use Case: Bus unavailability (Bus Off), Loss of NM messages

AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00011)
Note:
The four rules in the description of [RS_Nm_00053] will make sure that the NM of a
node that is currently not in bus sleep mode will never enter bus sleep mode while the
node itself is not ready to sleep. If the node itself is ready to sleep, the NM shall enter
bus sleep mode on its own.

17 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

[RS_Nm_00053] does not apply for a node that is already in bus sleep mode. In
addition, bus unavailability may be hard to check at that time since the bus is not used
to communicate in bus sleep mode.

[RS_Nm_00137] NM shall perform communication system error handling for er-

rors that have impact on the NM behavior. d

Type: valid
If bus errors of a specific bus on which NM is running have impact on the NM
behavior, the error handling must be performed by NM.
Description:
Focus: bus errors, not protocol errors.
Example: loss of NM message is handled.
Rationale: Error handling
Dependencies: –
Use Case: Communication loss
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00011)

4.1.5 Gateway Operation

[RS_Nm_02514] It shall be possible to group networks into NM Coordination

Clusters d

Type: valid
It shall be possible to group networks into NM Coordination Clusters.
Each bus specific NM shall, by configuration, be part of 0 or 1 NM Coordination
Cluster.
NM shall provide functionality (NM Coordination) to coordinate the different NM
modes (especially sleep and keep awake) on all networks in an NM
Description: Coordination Cluster, by performing a synchronized shutdown on all included
networks.
The level of synchronization is determined by the configuration of the shutdown
synchronization algorithm.
Specifically, it shall be possible to perform NM Coordination for each NM
Coordination Cluster separately and independently.
It shall be possible to perform coordinated and/or synchronized shutdown of
Rationale:
multiple NM clusters independently.
Dependencies: –
5

18 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

4
Use Case: NM Coordinator
AppliesTo: CP
Supporting –
Material:

c(RS_Main_00420)
Note:
The definitions of NM Coordination Cluster, NM Coordinator, Synchronize and Coordi-
nate are available in [2].

[RS_Nm_02516] All AUTOSAR NM instances shall support the NM Coordinator

functionality including Bus synchronization on demand d

Type: valid
All AUTOSAR NM instances shall support the NM Coordinator functionality of
the Generic NM Interface including Bus synchronization on demand. Bus
Description: Synchronization on demand allows for synchronization of an NM-cluster at an
arbitrary point in time, meaning the NM-Timeout Timers in all nodes of the
NM-cluster are restarted simultaneously.
Bus synchronization on demand allows synchronization of a NM-cluster for an
Rationale: arbitrary point of time; in result, NM-Timeout Timers in all nodes of the
NM-cluster are restarted.
Dependencies: –
Use Case: NM Coordinator
AppliesTo: CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02535] The NM coordination shall support the coordination of nested
sub-buses d

Type: valid
The NM coordination algorithm shall support coordination of a second level of
Description: bus hierarchy, when shutting down coordinated buses. There is no limitation of
hierarchy levels.
5

19 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

4
The network management stack allows to have a coordinated shutdown of
more than one bus if an ECU exists which is connected to the buses which are
to be coordinated. The functionality is included in the NmIf module. However,
there are currently two limitations

1. If a sub-bus exists on a coordinated bus, which is connected by a gateway,

Rationale: this sub-bus can currently not be added to the list of coordinated buses,
because the algorithm only handles one level. As a result, a coordinated bus
may shut down, but connected sub buses may still be active.
2. The functionality is not reliable, because, if the coordinating ECU fails, the
buses will no longer be coordinated and act on their own; that is, they will – if no
node is active – shut down independently. This concept intent to fix these
shortcomings.
Dependencies: –

Use Case: Nested Gateways

AppliesTo: CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02537] The NM Coordinator shall be able to abort the coordinated shut-
down d

Type: valid
As long as the coordinated shutdown is not completed, a network request on
Description: one of the coordinated buses shall be forwarded to other buses of this
Coordination cluster.
Rationale: The state of all coordinated buses shall be the same
Dependencies: –
Internal or external communication request during coordinated shutdown of
Use Case:
buses.
AppliesTo: CP
Supporting –
Material:

c(RS_Main_00420)

4.1.6 Partial Networking

[RS_Nm_02517] <Bus>Nm shall support Partial Networking on CAN, FlexRay and

Ethernet d

20 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

Type: valid
Description: <Bus>Nm shall support Partial Networking on CAN, FlexRay and Ethernet.
It is necessary to implement complete partial network support on the bus
Rationale: protocol <Bus>, to reduce the power consumption of <Bus> communication
domains.
Dependencies: –
The power consumption can be reduced by e.g
• Shutting down of seat control functions

Use Case: • Shutting down of park assistant functions

• Hazard flashers
• Shutting down of Electric Park Brake (EPB)
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
Note:
The definitions of Partial Networking is available in more details in [3].

[RS_Nm_02518] <Bus>Nm shall be able to distinguish between NM Messages d

Type: valid
<Bus>Nm shall be able to distinguish between an NM message without PN
Description: request information and an NM message with PN request information
contained in the NM user data.
This is required to assure the compatibility between carry over parts from
Rationale: current vehicle platforms and valid ECUs with Partial Networking. Current
ECUs may not send NM messages with PN request information
Dependencies: [RS_Nm_02517]
Use Case: –
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02519] The NM Control Bit Vector shall contain a PNI (Partial Network
Information) bit. d

21 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

Type: valid
The NM Control Bit Vector shall contain a PNI (Partial Network Information) bit
with the following meaning:
Description:
0: NM message does not contain PN request information
1: NM message contains PN request information (PNI)
Rationale: –
Dependencies: [RS_Nm_02517]
Use Case: –
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02520] <Bus>Nm shall evaluate the PNI bit in the NM message d

Type: valid
NM shall evaluate the PNI bit in the NM message; If PNI bit is Set, the partial
Description:
networking information shall be evaluated from the message.
Rationale: –
Dependencies: [RS_Nm_02517]
Use Case: –
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02521] <Bus>Nm shall set the PNI bit to indicate availability of Partial
Network request information d

Type: valid
While sending NM message, NM will set the PNI bit to indicate that NM
Description:
message contains Partial Network request information.
Rationale: –
Dependencies: [RS_Nm_02517]
Use Case: –
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02527] <Bus>Nm shall implement a filter algorithm dropping all NM
messages that are not relevant for the ECU d

22 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

Type: valid
<Bus>Nm shall implement a filter algorithm dropping all NM messages that are
Description: not relevant for the ECU. The algorithm uses the Partial Network request
information included with <Bus>Nm.
Rationale: –
Dependencies: [RS_Nm_02517]
Use Case: –
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02528] <Bus>Nm shall provide a service which allows for spontaneous
sending of NM messages. d

Type: valid
<Bus>Nm shall provide a service which allows for spontaneous sending of NM
Description:
messages.
A PN request originating from the ECU needs to be sent out as fast as possible
Rationale: to avoid long latency
Dependencies: [RS_Nm_02517]
Use Case: –
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02522] <Bus>Nm shall calculate the combined partial network request
status EIRA d

Type: valid
NM shall calculate the combined partial network request status EIRA (External
and Internal Requests Aggregated) for each partial network relevant to the
Description:
ECU. The calculation shall use a configurable time constant for resetting EIRA
requests
Rationale: –
Dependencies: [RS_Nm_02517]
Use Case: –
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)

23 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

[RS_Nm_02523] <Bus>Nm shall calculate the status of the external partial net-
work requests ERA d
Type: valid
<Bus>Nm shall calculate the status of the external partial network requests
ERA (External Requests Aggregated) for each partial network relevant to the
Description:
ECU. The calculation shall use a configurable time constant for resetting ERA
requests.
Rationale: –
Dependencies: [RS_Nm_02517]
Use Case: –
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02524] <Bus>Nm shall communicate EIRA and ERA requests to the up-
per layers d

Type: valid
<Bus>NM shall communicate calculated EIRA and ERA requests to the upper
Description:
layers
Rationale: –
Dependencies: [RS_Nm_02517]
Use Case: –
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02525] <Bus>Nm shall support channel-specific configuration for ERA
d

Type: valid
Description: <Bus>Nm shall support channel-specific configuration for ERA
Rationale: –
Dependencies: [RS_Nm_02517]
Use Case: –
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_02526] <Bus>Nm shall support a global configuration for EIRA over all
<Bus>channels d

24 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

Type: valid
Description: <Bus>Nm shall support a global configuration for EIRA over all <Bus>channels
Rationale: –
Dependencies: [RS_Nm_02517]
Use Case: –
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)

4.2 Non-Functional Requirements (Qualities)

4.2.1 Timing Requirements

[RS_Nm_00054] There shall be a deterministic time from the point where all
nodes agree to go to bus sleep to the point where bus is switched off. d

Type: valid
The time required from the point in time when the NM of each ECU agree on
shutting down a communication system and the point in time when the
Description: communication system is really shutting down, has to be deterministic
(guarantee of min time and max time). This time must be statically configurable
per cluster.
Rationale: Determinism of network behavior, guarantee of synchronized sleep-mode.
Dependencies: –
Use Case: See Rationale
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00340)

4.2.2 Resource Usage

[RS_Nm_00142] NM shall guarantee an upper limit for the bus load generated by
NM itself. d

25 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

Type: valid
NM shall not exceed a specified upper limit of bus load. This bus load has to be
Description: specified.
Example: 3% in normal operation, 6% Bus load peak.
Rationale: Determinism
Dependencies: –

Use Case: Avoid solution like in OSEK NM 2.5.3: alive messages after bus wakeup
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00200)
[RS_Nm_00143] The bus load caused by NM shall be predictable. d

Type: valid
The bus load caused by NM shall be predictable. The bus load for normal
Description: operation (no error occurred) has to be specified or calculable (dependent on
the timing).
Rationale: Predictability
Dependencies: –

Use Case: Prediction of bus load for NM on the specific bus

AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00200)
[RS_Nm_00144] NM shall support communication clusters of up to 64 ECUs d

Type: valid

Description: Communication clusters of up to 64 ECUs / controllers shall be supported by

NM.
Rationale: Flexibility
Dependencies: –
Use Case: See Rationale
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_00145] On a properly configured node, NM shall tolerate a loss of a
predefined number of NM messages d

26 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

Type: valid
On a properly configured node, NM shall tolerate a loss of a predefined number
Description: of NM messages. The limitations of the number of message losses have to be
described in the specification.
Robustness: There shall be no need for NM to receive every NM message. A
Rationale: loss of one message (in case of bursts) shall have no impact on the NM
behaviour.
Dependencies: –

Use Case: Loss of NM-message(s) must be tolerated

AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_00146] The NM shall tolerate a time jitter of NM messages in one or
more ECUs d

Type: valid
The NM shall tolerate a time jitter of NM messages in one or more ECUs.
Description:
The limitations of the jitter have to be described in the specification.
Rationale: Robustness
Dependencies: –

Use Case: Jitter of NM-message(s) must be tolerated

AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00420)
[RS_Nm_00147] The NM algorithm shall be processor independent. d

Type: valid
The algorithm of NM shall not rely on processor specific mechanisms. It shall
Description:
be realizable on every processor architecture.
Rationale: Re-use
Dependencies: –

Use Case: Usage of NM on different processor architectures

AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00130)

27 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

4.2.3 Hardware independency

[RS_Nm_00154] The Network Management API shall be independent from the

communication bus d
Type: valid
The Network Management API shall be independent from the communication
Description:
bus i.e. equal for CAN and FlexRay.
Rationale: Common, standardized interface to upper layers.
Dependencies: –
Usage of NM on different types of bus; only one interface independent of the
Use Case: underlying bus architecture.
AppliesTo: AP, CP
Supporting –
Material:

c(RS_Main_00140)

5 Requirements Tracing

Feature Description Satisfied by

[RS_Main_00011] AUTOSAR shall support the development of [RS_Nm_00053]
reliable systems [RS_Nm_00137]
[RS_Main_00130] AUTOSAR shall provide an abstraction from [RS_Nm_00147]
hardware
[RS_Main_00140] AUTOSAR shall provide network independent [RS_Nm_00154]
communication mechanisms for applications
[RS_Main_00190] AUTOSAR shall support standardized [RS_Nm_02515]
interoperability with non-AUTOSAR software
[RS_Main_00200] AUTOSAR specifications shall allow resource [RS_Nm_00142]
efficient implementations [RS_Nm_00143]
[RS_Main_00340] AUTOSAR shall support the continuous timing [RS_Nm_00054]
requirement analysis

28 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

[RS_Main_00420] AUTOSAR shall use established software [RS_Nm_00043]

standards and consolidate de-facto standards for [RS_Nm_00044]
basic software functionality [RS_Nm_00045]
[RS_Nm_00046]
[RS_Nm_00047]
[RS_Nm_00048]
[RS_Nm_00050]
[RS_Nm_00051]
[RS_Nm_00052]
[RS_Nm_00144]
[RS_Nm_00145]
[RS_Nm_00146]
[RS_Nm_00150]
[RS_Nm_00151]
[RS_Nm_00153]
[RS_Nm_02503]
[RS_Nm_02504]
[RS_Nm_02505]
[RS_Nm_02506]
[RS_Nm_02508]
[RS_Nm_02509]
[RS_Nm_02511]
[RS_Nm_02512]
[RS_Nm_02513]
[RS_Nm_02514]
[RS_Nm_02516]
[RS_Nm_02517]
[RS_Nm_02518]
[RS_Nm_02519]
[RS_Nm_02520]
[RS_Nm_02521]
[RS_Nm_02522]
[RS_Nm_02523]
[RS_Nm_02524]
[RS_Nm_02525]
[RS_Nm_02526]
[RS_Nm_02527]
[RS_Nm_02528]
[RS_Nm_02535]
[RS_Nm_02536]
[RS_Nm_02537]

29 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —
 Requirements on AUTOSAR Network
Management
AUTOSAR FO Release 1.5.1

6 References

[1] System Template

AUTOSAR_TPS_SystemTemplate
[2] Glossary
AUTOSAR_TR_Glossary
[3] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture

30 of 30 Document ID 927: AUTOSAR_RS_NetworkManagement

— AUTOSAR CONFIDENTIAL —