NM
1. 文档范围¶
本文档规定对 AUTOSAR 网络管理（Network Management）的需求。
这些需求适用于以下功能实体：
- 协调特定 Nm 集群（Nm-cluster）的网络管理
- 特定总线的网络管理总线特定部分
- Nm 集群之间网络管理的网关与互操作性
Nm 所适用的通信系统必须支持「总线休眠（bus sleep）」模式。这意味着通信系统的收发器可以切换到低功耗模式，并且可以通过（特定的）总线流量和/或应用再次切换回全功率模式。
2. 所用约定¶
2.1. 文档约定¶
AUTOSAR 文档中需求的呈现遵循 TPS_STDT_00078 中规定的表格，参见标准化模板（Standardization Template）的「可追溯性支持（Support for Traceability）」章节（[1]）。
应使用 TPS_STDT_00053 中规定的表达义务的言语形式来表示需求，参见标准化模板的「可追溯性支持」章节（[1]）。
3. 缩略语和缩写¶
Nm
网络管理（Network Management）
PN
部分网络（Partial Network）
PNI
部分网络信息（Partial Network Information）
Nm Message
指总线上传输的载荷。它包含用户数据（User Data）以及控制位向量（Control Bit Vector），并可以包含源节点标识符（Source Node Identifier）。
Nm Node
连接到一个或多个 Nm 集群的 ECU（电子控制单元）。
Nm cluster
使用 Nm 算法协调的 Nm 节点集合。
Nm instance
一个 Nm 实例表示一个 Nm 节点内部一个 Nm 集群的当前状态。
上文各表未提供的缩略语/缩写和术语包含在 AUTOSAR 术语表 [2] 中。
4. 用例¶
表4.1：网络管理的用例（Use Cases of Network Management）
| ID | 名称 | 描述 |
|---|---|---|
| 0001 | 同步关闭（Synchronous Shutdown） | 如果 Nm 集群中没有通信需求，Nm 协议确保所有 Nm 节点同步进入休眠模式。 |
| 0002 | 子网络同步关闭（Sub-networks Synchronous Shutdown） | 支持多个子网络的协调关闭。这可以视为同步关闭用例的扩展，其目标是同步关闭多个 Nm 集群。 |
| 0003 | 保持 Nm 集群唤醒（Keep Nm Cluster Awake） | 如果 Nm 集群中至少有一个 Nm 节点需要通信，Nm 协议确保所有需要的 Nm 节点保持唤醒。 |
| 0004 | 部分网络（Partial Network） | 通过定义通信/功能域来支持部分网络，从而在某些条件下不需要某些 ECU 所提供的功能时，允许关闭跨多个 ECU 的网络通信。其他 ECU 可以继续在相同的总线通道上通信。此外，使用 Nm 消息在参与的 ECU 之间传递部分网络集群的请求/释放信息。 |
| 0005 | 被动模式（Passive Mode） | 配置为被动节点（Passive node）的 Nm 节点不能发起 Nm 集群的启动，但如果任何其他节点发起启动，它能够被唤醒。这消除了不必要的通信并减少了总线和缓冲区开销。允许关闭由集群节点的一个子集控制，使得只有容错节点控制关闭成为可能。 |
| 0006 | 部分网络网关（Partial Network Gateway） | 由于部分网络跨越多条总线，网络管理协议定义了部分网络信息应如何在这些总线之间网关转发，即应能够向子网络转发请求/释放信息，从而允许网关 ECU 代表原始的部分网络请求方 ECU 采取行动。 |
| 0007 | FlexRay Nm（FlexRay Nm） | 支持 FlexRay 总线的特定特性及其 HW Nm 向量支持。网络管理协议应支持 FlexRay 总线的替代方案，其中可以使用 FlexRay 协议规范的网络管理向量（Network Management Vector）。 |
上文各表未提供的缩略语/缩写和术语包含在 AUTOSAR 术语表 [2] 中。
5. 需求规范¶
5.1. 功能需求¶
5.1.1. 配置¶
网络管理的特定功能应可配置
| 描述 | 网络管理的以下功能应可配置： * 现有节点的检测 * （不再）所有其他 ECU 已准备好休眠的通知（即远程休眠指示（取消）） * Nm 协调支持 * 用户数据支持 * 总线负载降低 * 发送节点标识符 * 接收节点标识符 * 立即发送确认 * 集群关闭中角色的可配置性 * 总线保持唤醒服务 * 部分网络扩展 * 动态 PNC 映射 * 同步 PNC 关闭 |
|---|---|
| 理由 | 可扩展性（Scalability） |
| 依赖项 | - |
| 用例 | ECU 软件的配置 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
5.1.2. 初始化¶
网络管理算法应允许任何节点加入已运行的 Nm 集群
| 描述 | 网络管理算法应允许任何节点加入已运行的 Nm 集群。 |
|---|---|
| 理由 | 以下节点的加入： * a) 迟到节点（Late nodes） * b) 已从故障状态恢复的节点 * c) 已被连接到运行中的车辆网络的节点（例如通过维修接入） |
| 依赖项 | - |
| 用例 | 见理由 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
Nm 未初始化时不应禁止总线通信
| 描述 | 应可以使软件模块能够访问通信系统，而与 Nm 是否存在（Nm 已初始化或未初始化）无关。 |
|---|---|
| 理由 | Nm 的初始化延迟或错误不应禁止应用软件的通信。 |
| 依赖项 | - |
| 用例 | 不带 Nm 的 ECU，或 Nm 较晚启动（见理由） |
| 适用平台 | AP、CP |
| 支撑材料 | - |
5.1.3. 正常运行¶
Nm 应适用于 AUTOSAR 范围内且支持总线休眠模式的不同类型通信系统
| 描述 | 每个受支持协议的网络管理机制应使用有限数量的预定义 Nm 状态和 Nm 转换来实现。触发状态间转换的事件以及在这些转换上采取的动作可以是协议特定的。每种协议都应支持总线休眠模式。Nm 应既可在异步通信系统（例如 CAN）上执行，也可在同步通信系统（例如 FlexRay）上执行，还可在这两种系统之上的、AUTOSAR 范围内的任何其他类型通信系统上执行。 |
|---|---|
| 理由 | 在当今的汽车中，实现了多种不同的通信系统。出于能耗考虑，所有 ECU 都必须能够切换到低功耗模式。因此，所有通信系统都需要网络管理。为便于理解，Nm 应由一组共同的状态定义构成。 |
| 依赖项 | - |
| 用例 | 同时具备 CAN 和 FlexRay、以太网的 ECU |
| 适用平台 | AP、CP |
| 支撑材料 | - |
Nm 应提供运行 AUTOSAR-Nm 之外的其他 Nm 的通用可能性
| 描述 | 对管理基于非 AUTOSAR-Nm 的网络的支持，应通过扩展/修改现有的总线特定 Nm，或通过引入使用 Nm 通用接口的复杂设备驱动（CDD）来实现。在单个网络上同时运行一个 AUTOSAR-Nm 和一个非 AUTOSAR-Nm 的支持，也应以同样的方式实现。总线特定 Nm 或 CDD 的实际扩展不由 AUTOSAR 规定。 |
|---|---|
| 理由 | - |
| 依赖项 | - |
| 用例 | 在其中一个网络上运行 ISO 17356-5: Nm Specification 或其他传统 Nm。 |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 应提供相互独立地协调 Nm 集群关闭的服务
| 描述 | Nm 必须提供相互独立地协调各 Nm 集群关闭的服务。 |
|---|---|
| 理由 | 在当今的汽车中，实现了多种不同的通信系统。因此，ECU 可能连接到多个通信通道（例如 2 个 CAN 集群、1 个 FlexRay 集群等）。并非在所有情形下所有通道都必须处于全功率模式。因此，每个通道都必须能够被单独启动或关闭。 |
| 依赖项 | - |
| 用例 | 带有多条总线的网关 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
Nm 应提供使上层能够控制休眠模式的功能
| 描述 | Nm 应提供一个接口，使上层能够协调不同的 Nm 模式（尤其是休眠和唤醒/保持唤醒）。 |
|---|---|
| 理由 | 使上层能够控制 Nm。使 Nm 协调器能够控制多个总线特定的 Nm。 |
| 依赖项 | - |
| 用例 | 由 Nm 协调器控制 Nm |
| 适用平台 | AP、CP |
| 支撑材料 | 相关需求 RS_Nm_02512 |
应可以在任何时间点触发所有节点的启动
| 描述 | 在特定的时间点，连接到 Nm 集群的所有节点都必须被启动（例如车辆启动时）。因此，Nm 必须提供在任何时间点启动连接到一个 Nm 集群的所有节点的 Nm 的服务。该时间点无法离线计算，因此该服务必须可以随时访问。关于 FlexRay 网络的说明：在某些情况下，可能需要先关闭才能启动。在这种情况下可能出现明显的延迟。 |
|---|---|
| 理由 | 所有节点是指所有连接到端子 30（永久连接到电源的节点）的节点。连接到端子 15 的 ECU（通过某个电源继电器供电的节点）必须单独处理，因为它们无法在任何时间点被启动。注意：「被动节点（Passive Nodes）」不能发起 Nm 集群的启动，但如果任何其他节点发起启动，它们能够被唤醒。参见 RS_Nm_02511。 |
| 依赖项 | - |
| 用例 | 驾驶员进入车辆并想要启动发动机。 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
Nm 应提供请求保持总线唤醒的服务和取消该请求的服务
| 描述 | 在 Nm 已初始化之后的任何时间点，必须使实现于某个 ECU 上的应用能够发出它请求保持总线唤醒的信号，并在其他任何时间点想要取消该请求。这些总线保持唤醒服务不提供给被配置为不参与集群关闭决策的节点，参见 RS_Nm_02511。 |
|---|---|
| 理由 | 基本的 Nm 功能 |
| 依赖项 | - |
| 用例 | 见理由 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
如果没有总线通信，Nm 应将通信控制器置于休眠模式
| 描述 | 如果连接到 Nm 集群的应用/ECU 都不需要总线通信，Nm 应指示将通信控制器置于休眠模式。 |
|---|---|
| 理由 | 基本的 Nm 功能 |
| 依赖项 | RS_Nm_00047 |
| 用例 | 见理由 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
Nm 应提供 Nm 的当前状态
| 描述 | Nm 应提供一个接口，用于检索关于 Nm 当前状态的信息。 |
|---|---|
| 理由 | 应用应能够通过访问 Nm 的特定接口获取 Nm 状态信息。Nm 状态反映总线的状态。 |
| 依赖项 | - |
| 用例 | 见理由 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
当 Nm 状态变化发生时，Nm 应通知应用
| 描述 | Nm 应提供一个接口，应用可以使用它在特定的 Nm 状态变化发生时获得通知。 |
|---|---|
| 理由 | 应使应用能够对状态变化作出反应。 |
| 依赖项 | - |
| 用例 | 尤其有趣的是向休眠状态的转换，以便关闭收发器。 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
Nm 接口应向应用指示所有其他 ECU 已准备好休眠
| 描述 | Nm 应提供一个接口，向应用指示所有其他应用/ECU 已准备好休眠。 |
|---|---|
| 理由 | 防止无意的保持唤醒。 |
| 依赖项 | RS_Nm_02509 |
| 用例 | 应用内部的检查，确认 ECU 是否在无意中保持总线唤醒。外部网络管理协调。 |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 接口应向应用指示至少一个 ECU 不再准备好休眠
| 描述 | Nm 应提供一个接口，向应用指示至少一个其他应用/ECU 不再准备好休眠。 |
|---|---|
| 理由 | 必要时通知总线正被保持唤醒。 |
| 依赖项 | RS_Nm_00052 |
| 用例 | 识别保持总线唤醒的最后一个节点。外部网络管理网关协调。 |
| 适用平台 | CP |
| 支撑材料 | - |
Nm API 应可选地提供发送用户数据的可能性
| 描述 | Nm API 应可选地提供设置用户数据的可能性，该用户数据可以附加到总线上发送的每条 Nm 消息中。Nm 应为写操作保证数据一致性。 |
|---|---|
| 理由 | 网络内系统相关信息的交换。 |
| 依赖项 | - |
| 用例 | 唤醒原因在网络中的分发。 |
| 适用平台 | CP |
| 支撑材料 | - |
Nm API 应可选地提供获取用户数据的可能性
| 描述 | Nm API 应可选地提供获取用户数据的可能性，该用户数据可以包含在接收到的 Nm 消息中。Nm 应为读操作保证数据一致性。 |
|---|---|
| 理由 | 网络内系统相关信息的交换。 |
| 依赖项 | - |
| 用例 | 唤醒原因在网络中的分发。 |
| 适用平台 | CP |
| 支撑材料 | - |
网络管理应可选地提供检测现有节点的可能性
| 描述 | 网络管理应可选地提供检测总线上当前存在的节点的可能性。应可以使节点应请求发送其 Nm 相关数据。该功能为静态配置（可用或不可用）。评注：该功能只在主 ECU（例如主机单元、中央车身控制器等）中需要。 |
|---|---|
| 理由 | 用于诊断目的和配置检查。 |
| 依赖项 | - |
| 用例 | 车辆状态管理可以使用该信息检查网络的完整性。 |
| 适用平台 | CP |
| 支撑材料 | - |
每个节点都应有一个在 Nm 集群内唯一的节点标识符
| 描述 | 每个节点都应有一个与之关联的、在 Nm 集群内唯一的节点标识符。 |
|---|---|
| 理由 | 避免节点误识别。 |
| 依赖项 | - |
| 用例 | 识别保持总线唤醒的最后一个节点。现有节点的检测。 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
Nm 应可选地将本地节点标识符设置到 Nm 消息中
| 描述 | Nm 应可选地将本地节点标识符设置到 Nm 消息中。另见 RS_Nm_00150。 |
|---|---|
| 理由 | 网络内系统相关信息的交换。 |
| 依赖项 | - |
| 用例 | 识别保持总线唤醒的最后一个节点。现有节点的检测。 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
Nm API 应提供读取发送方源节点标识符的可能性
| 描述 | Nm API 应提供从最近接收的 Nm 消息中读取发送方源节点标识符的可能性。Nm 应为读操作保证数据一致性。注意： 该 Nm API 是可选的，因为源节点标识符的发送是可选的。另见 RS_Nm_00150。 |
|---|---|
| 理由 | 网络内系统相关信息的交换。 |
| 依赖项 | - |
| 用例 | 识别保持总线唤醒的最后一个节点。现有节点的检测。 |
| 适用平台 | CP |
| 支撑材料 | - |
应可以将节点的网络管理配置为不参与集群关闭决策
| 描述 | 应可以将节点的网络管理配置为不参与集群关闭决策。具体而言，应可以将集群中的某些节点配置为不能广播其他节点用于触发关闭的信息，即没有为该节点定义任何 Nm 相关通信。此类节点不得具有保持总线唤醒的能力，但要求它们以与其他节点一致的方式关闭。另见 RS_Nm_00150。 |
|---|---|
| 理由 | 消除不必要的通信可减少总线和缓冲区开销。允许关闭由集群节点的一个子集控制，使得只有容错节点控制关闭成为可能。然而，这些节点在其他方面应具备正常通信的能力。 |
| 依赖项 | - |
| 用例 | 在一个带有某些单通道节点的双通道 FlexRay 集群中，可以将集群配置为只有双通道节点影响关闭。这确保所有关闭投票在通道间都被复制，即使某些节点只连接到一个通道，从而使决策过程对通道丢失具有鲁棒性。 |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 应提供不请求网络而启动的功能
| 描述 | Nm 应提供一个接口，该接口触发向网络模式（Network Mode）的转换而不保持网络唤醒。 |
|---|---|
| 理由 | 节点必须参与网络管理而不主动请求通信。 |
| 依赖项 | - |
| 用例 | 发生总线唤醒。 |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 应提供启用或禁用为活动 Nm 节点配置的网络管理相关通信的可能性
| 描述 | Nm 应提供启用或禁用为活动 Nm 节点配置的网络管理相关通信的可能性。默认情况下，网络管理相关通信应处于启用状态。 |
|---|---|
| 理由 | 符合 ISO 14229 CommunicationControl（28 hex）服务 |
| 依赖项 | RS_Nm_02511 |
| 用例 | 诊断 |
| 适用平台 | CP |
| 支撑材料 | - |
<Bus>Nm 应处理 NM-PDU 的重传
| 描述 | 如果某条 NM-PDU 的传输未被下层接受或未被下层确认，<Bus>Nm 必须在主函数调用的上下文中对该 NM-PDU 执行重传处理。 |
|---|---|
| 理由 | <Bus>Nm 的重传请求应覆盖下层无法传输 Nm 消息的错误情形。 |
| 依赖项 | RS_Nm_02517, RS_Nm_02550, RS_Nm_02546 |
| 用例 | 覆盖下层无法传输 NM-PDU 的错误情形。 |
| 适用平台 | CP |
| 支撑材料 | - |
5.1.4. 故障运行¶
Nm 应对影响 Nm 行为的错误执行通信系统错误处理
| 描述 | 如果 Nm 所运行总线的特定总线错误对 Nm 行为产生影响，则错误处理必须由 Nm 执行。焦点：总线错误，而非协议错误。示例：Nm 消息丢失的处理。 |
|---|---|
| 理由 | 错误处理 |
| 依赖项 | - |
| 用例 | 通信丢失 |
| 适用平台 | CP |
| 支撑材料 | - |
5.1.5. Nm 协调¶
应可以将网络分组为 Nm 协调集群
| 描述 | 应可以将网络分组为 Nm 协调集群（Nm Coordination Cluster）。每个总线特定的 Nm 应通过配置成为 0 或 1 个 Nm 协调集群的一部分。Nm 应提供功能（Nm 协调），通过在所有包含的网络上执行同步关闭，来协调一个 Nm 协调集群中所有网络上不同的 Nm 模式（尤其是休眠和保持唤醒）。同步的级别由关闭同步算法的配置决定。具体而言，应可以为每个 Nm 协调集群单独且独立地执行 Nm 协调。 |
|---|---|
| 理由 | 应可以独立地对多个 Nm 集群执行协调的和/或同步的关闭。 |
| 依赖项 | - |
| 用例 | Nm 协调器 |
| 适用平台 | CP |
| 支撑材料 | - |
注意： Nm 协调集群、Nm 协调器、同步（Synchronize）和协调（Coordinate）的定义见 [2]。
所有 AUTOSAR Nm 实例应支持 Nm 协调器功能，包括按需的总线同步
| 描述 | 所有 AUTOSAR Nm 实例应支持通用 Nm 接口（Generic Nm Interface）的 Nm 协调器功能，包括按需的总线同步。按需的总线同步允许在任意时间点同步一个 Nm 集群，这意味着 Nm 集群中所有节点的 Nm 超时定时器被同时重启。 |
|---|---|
| 理由 | 按需的总线同步允许在任意时间点同步一个 Nm 集群；结果是，Nm 集群中所有节点的 Nm 超时定时器被重启。 |
| 依赖项 | - |
| 用例 | Nm 协调器 |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 协调应支持嵌套子总线的协调
| 描述 | 在协调关闭各总线时，Nm 协调算法应支持第二层总线层级的协调。层级数量没有限制。 |
|---|---|
| 理由 | 网络管理栈允许在存在连接到待协调总线的 ECU 时，对多条总线执行协调关闭。该功能包含在 NmIf 模块中。然而，目前存在两个限制：1. 如果某个被协调的总线上存在通过网关连接的子总线，该子总线目前无法加入被协调总线的列表，因为该算法只处理一层。结果是，一个被协调的总线可能关闭，但所连接的子总线可能仍然处于活动状态。2. 该功能不可靠，因为如果执行协调的 ECU 失效，各总线将不再被协调而各自行动；也就是说，如果没有节点处于活动状态，它们将独立关闭。本概念旨在修复这些缺陷。 |
| 依赖项 | - |
| 用例 | 嵌套网关 |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 协调器应能够中止协调关闭
| 描述 | 只要协调关闭尚未完成，某个被协调总线上的网络请求就应被转发到该协调集群的其他总线。 |
|---|---|
| 理由 | 所有被协调总线的状态应当相同。 |
| 依赖项 | - |
| 用例 | 协调关闭总线期间的内部或外部通信请求。 |
| 适用平台 | CP |
| 支撑材料 | - |
5.1.6. 部分网络¶
注意： 部分网络（Partial Networking）的定义在 [3] 中有更详细的说明。
Nm 应提供请求和指示重复消息请求的接口（可选）
| 描述 | Nm 控制位向量（Nm Control Bit Vector）中的一个位应用于传播接收节点进入 NmRepeatMessage 状态的需求。应有一个接口在 <Bus>Nm 中设置该位与重复消息请求位（Repeat Message Request bit）的值，并有一个接口在接收期间指示该位的变化。该功能应为静态配置（可用或不可用）。 |
|---|---|
| 理由 | - |
| 依赖项 | RS_Nm_00153, RS_Nm_02547 |
| 用例 | 节点检测、动态 PNC 映射 |
| 适用平台 | CP |
| 支撑材料 | - |
CanNm 应支持 CAN 上的部分网络
| 描述 | CanNm 应支持 CAN 上的部分网络。 |
|---|---|
| 理由 | 必须在 CAN 总线协议上实现完整的部分网络支持，以降低 CAN 通信域的功耗。 |
| 依赖项 | - |
| 用例 | * 驻车辅助功能的关闭 |
| 适用平台 | CP |
| 支撑材料 | - |
FrNm 应支持 FlexRay 上的部分网络
| 描述 | FrNm 应支持 FlexRay 上的部分网络。 |
|---|---|
| 理由 | 必须在 FlexRay 总线协议上实现完整的部分网络支持，以降低 FlexRay 通信域的功耗。 |
| 依赖项 | - |
| 用例 | * 座椅控制功能的关闭 * 驻车辅助功能的关闭 * 危险警告灯 * 电子驻车制动（EPB）的关闭 |
| 适用平台 | CP |
| 支撑材料 | - |
UdpNm 应支持以太网上的部分网络
| 描述 | UdpNm 应支持以太网上的部分网络。 |
|---|---|
| 理由 | 必须在以太网总线协议上实现完整的部分网络支持，以降低以太网通信域的功耗。 |
| 依赖项 | - |
| 用例 | 功耗可以通过例如以下方式降低： * 座椅控制功能的关闭 * 驻车辅助功能的关闭 * 危险警告灯 * 电子驻车制动（EPB）的关闭 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
Nm 控制位向量应包含一个 PNI（部分网络信息）位
| 描述 | Nm 控制位向量应包含一个 PNI（部分网络信息，Partial Network Information）位，含义如下：0：Nm 消息不包含 PN 请求信息；1：Nm 消息包含 PN 请求信息（PNI）。 |
|---|---|
| 理由 | 需要该位来确保来自当前车辆平台的沿用部件与支持部分网络的有效 ECU 之间的兼容性。当前 ECU 可能不发送带有 PN 请求信息的 Nm 消息。 |
| 依赖项 | RS_Nm_02517 |
| 用例 | - |
| 适用平台 | AP、CP |
| 支撑材料 | - |
Nm 应实现过滤算法，丢弃与 ECU 不相关的所有 Nm 消息
| 描述 | Nm 应实现一个过滤算法，丢弃与该 ECU 不相关的所有 Nm 消息。该算法使用随 Nm 和 <Bus>Nm 包含的部分网络请求信息。 |
|---|---|
| 理由 | - |
| 依赖项 | RS_Nm_02517 |
| 用例 | - |
| 适用平台 | AP、CP |
| 支撑材料 | - |
Nm 应提供允许立即发送 Nm 消息的服务
| 描述 | 在请求的 PN 发生变化时，应自发地发送 Nm 消息。 |
|---|---|
| 理由 | 来自 ECU 的 PN 请求需要尽快发送出去，以避免长延迟。 |
| 依赖项 | RS_Nm_02517 |
| 用例 | - |
| 适用平台 | AP、CP |
| 支撑材料 | - |
<Bus>Nm 应能够传播和评估部分网络学习（Partial Networking Learning）的需求（可选）
| 描述 | Nm 控制位向量中的一个位应用于传播部分网络学习（Partial Networking Learning）的需求。应有一个接口在 <Bus>Nm 中设置该位与重复消息请求位的值，并有一个接口在接收期间指示该位的变化。该功能应为静态配置（可用或不可用）（参见 RS_Nm_00150）。 |
|---|---|
| 理由 | - |
| 依赖项 | - |
| 用例 | 动态 PNC 映射 |
| 适用平台 | CP |
| 支撑材料 | 部分网络学习在以下两者之间有所不同： * 请求 Nm PDU，其中部分网络学习位与重复消息请求位都被置位 * 响应 Nm PDU，其中只有部分网络学习位被置位（但重复消息请求位保持未置位）。 |
<Bus>Nm 应能够以顶层 PNC 协调器或中间 PNC 协调器的角色传播和评估同步 PNC 关闭的需求（可选）
| 描述 | Nm 控制位向量中的一个位应用于传播同步 PNC 关闭。应有一个接口在 <Bus>Nm 中设置该位的值，并有一个接口在接收期间指示该位被置位。该功能应为静态配置（可用或不可用）（参见 RS_Nm_00150）。 |
|---|---|
| 理由 | 该位用于指示顶层 PNC 协调器释放了至少一个 PNC。该位仅由中间 PNC 协调器评估。PNC 叶节点忽略该位。 |
| 依赖项 | RS_Nm_02517 |
| 用例 | 网络内 PNC 的同步 PNC 关闭，以缩短在所有受影响 ECU 上释放 PNC 的传播时间。 |
| 适用平台 | CP |
| 支撑材料 | 同步 PNC 关闭在以下两者之间有所不同： * 请求 Nm PDU，其中以顶层 PNC 协调器角色的 ECU 将部分网络位与 PN 关闭请求位都置位 * 转发 Nm PDU，其中以中间 PNC 协调器角色的 ECU 将部分网络位与 PN 关闭请求位都置位。 |
Nm 控制位向量应包含一个 PN 关闭请求位
| 描述 | Nm 控制位向量应包含一个 PN 关闭请求位，含义如下： * 0：Nm 消息不包含同步的部分网络关闭请求 * 1：Nm 消息包含针对至少一个 PNC 的同步部分网络关闭请求 |
|---|---|
| 理由 | 该位用于指示顶层 PNC 协调器释放了至少一个 PNC。该位仅由中间 PNC 协调器评估。PNC 叶节点忽略该位。 |
| 依赖项 | RS_Nm_02517, RS_Nm_02550, RS_Nm_02546 |
| 用例 | 网络内 PNC 的同步 PNC 关闭 |
| 适用平台 | CP |
| 支撑材料 | - |
如果至少释放了一个 PNC，顶层 PNC 协调器的 <Bus>Nm 应设置 PN 关闭请求位
| 描述 | 顶层 PNC 协调器的 <Bus>Nm 应在至少一个 PNC 被释放时传输一条 PN 关闭消息。PN 关闭消息将 PN 关闭请求位和被释放 PNC 的 PNC 位置为 1。因此，PN 关闭消息中只考虑被释放的 PNC。其余 PNC 位被置为 0。 |
|---|---|
| 理由 | PN 关闭请求位用于指示顶层 PNC 协调器释放了至少一个 PNC。因此，顶层 PNC 协调器通过将 PN 关闭位和所有被释放 PNC 的 PNC 位置为 1 来传输 PN 关闭消息。此外，顶层 PNC 协调器再次复位被释放 PNC 相应的 PN 复位定时器。接收节点应根据 PNC 网络角色（中间 PNC 协调器或 PNC 叶节点）立即作出反应。 |
| 依赖项 | RS_Nm_02517, RS_Nm_02550, RS_Nm_02546 |
| 用例 | 网络内 PNC 的同步 PNC 关闭 |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 应处理同步 PNC 关闭的请求
| 描述 | 处于顶层 PNC 协调器或中间 PNC 协调器角色的 ECU 的 Nm 应处理由 ComM 指示的同步 PNC 关闭请求。因此，所有被指示的、必须释放的 PNC 的信息应按 NM 通道存储。所存储的同步 PNC 关闭请求被转换为一个字节数组，其中每个位代表一个特定的 PNC（PNC 位向量）。如果 <Bus>Nm 指示获取并传输 NM-PDU 作为相应 Nm 通道上的 PN 关闭消息，则应按 NM 通道提供该 PNC 位向量。 |
|---|---|
| 理由 | 如果 <Bus>Nm 指示传输一条 NM-PDU，同步 PNC 关闭的请求应被聚合并作为 PNC 位向量提供给所有受影响的 NM 通道。 |
| 依赖项 | RS_Nm_02517, RS_Nm_02550, RS_Nm_02546 |
| 用例 | 网络内 PNC 的同步 PNC 关闭。 |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 应转发 PN 关闭消息的指示
| 描述 | 处于中间 PNC 协调器角色的 ECU 的 Nm 应立即将接收到的 PN 关闭消息的指示转发给 ComM。 |
|---|---|
| 理由 | 同步 PNC 关闭的请求应立即转发给 ComM，以尽量缩短 PN 关闭消息在 PNC 网络内的传播延迟。 |
| 依赖项 | RS_Nm_02517, RS_Nm_02550, RS_Nm_02546 |
| 用例 | 转发同步 PNC 关闭请求，以支持 PNC 几乎在同一时间点关闭 |
| 适用平台 | CP |
| 支撑材料 | - |
<Bus>Nm 应将同步 PNC 关闭的请求作为 NM-PDU 传输
| 描述 | 处于顶层 PNC 协调器或中间 PNC 协调器角色的 ECU 的 Nm 处理同步 PNC 关闭的请求。因此，NM 指示启动或停止某个 PNC 关闭过程。如果某个特定 NM 通道的 PNC 关闭过程已经启动，则 <Bus>Nm 获取聚合后的同步 PNC 关闭请求（作为 PNC 位向量），并将 NM-PDU 作为 PN 关闭消息在相应的 NM 通道上传输。<Bus>Nm 向 Nm 指示传输成功。否则，如果已配置，则应执行重传。 |
|---|---|
| 理由 | <Bus>Nm 应尽可能快地处理作为 PN 关闭消息的 NM-PDU 传输，以尽量缩短 PN 关闭消息在 PN 拓扑中传播的延迟。 |
| 依赖项 | RS_Nm_02517, RS_Nm_02550, RS_Nm_02546 |
| 用例 | 网络内 PNC 的同步 PNC 关闭。 |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 应支持部分网络
| 描述 | Nm 应支持部分网络。 |
|---|---|
| 理由 | Nm 维护 PNC 定时器处理，并向上层指示关于内部和外部 PNC 请求的变化。 |
| 依赖项 | - |
| 用例 | 功耗的降低 |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 应支持按通道存储 IRA
| 描述 | Nm 应支持按通道存储 IRA。 |
|---|---|
| 理由 | Nm 存储最新的 IRA（内部请求数组，internal request array），它以 PNC 位向量的形式表示内部 PNC 请求。IRA 按给定的 Nm 通道存储，并提供给 <Bus>Nm 以便在 Nm 消息内传输。 |
| 依赖项 | RS_Nm_02517 |
| 用例 | - |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 应计算组合的部分网络请求状态 EIRA
| 描述 | Nm 应为与该 ECU 相关的每个部分网络计算组合的部分网络请求状态 EIRA（外部和内部请求聚合，External and Internal Requests Aggregated）。该计算应使用一个可配置的时间常数来复位 EIRA 请求。 |
|---|---|
| 理由 | - |
| 依赖项 | RS_Nm_02517, RS_Nm_02561 |
| 用例 | - |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 应计算外部部分网络请求状态 ERA
| 描述 | Nm 应为与该 ECU 相关的每个部分网络计算外部部分网络请求状态 ERA（外部请求聚合，External Requests Aggregated）。该计算应使用一个可配置的时间常数来复位 ERA 请求。 |
|---|---|
| 理由 | - |
| 依赖项 | RS_Nm_02517, RS_Nm_02561 |
| 用例 | - |
| 适用平台 | CP |
| 支撑材料 | - |
<Bus>Nm 应使用专用 API 将 EIRA 和 ERA 请求传递给上层
| 描述 | Nm 应使用专用 API（不包含在系统描述中，而是在 ECU 配置期间生成）将 EIRA 和 ERA 请求传递给上层。 |
|---|---|
| 理由 | - |
| 依赖项 | RS_Nm_02517, RS_Nm_02561 |
| 用例 | - |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 应支持 ERA 的按通道配置
| 描述 | Nm 应支持 ERA 的按通道配置。 |
|---|---|
| 理由 | - |
| 依赖项 | RS_Nm_02517, RS_Nm_02561 |
| 用例 | - |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 应支持所有通道上的 EIRA 全局配置
| 描述 | Nm 应支持所有通道上的 EIRA 全局配置。 |
|---|---|
| 理由 | - |
| 依赖项 | RS_Nm_02517, RS_Nm_02561 |
| 用例 | - |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 应提供确认 API 以指示 PNC 位向量的传输状态
| 描述 | Nm 应提供一个确认 API，用于按 NM 通道指示 PNC 位向量的传输状态。 |
|---|---|
| 理由 | 需要该确认指示来更新内部的 PNC 处理。 |
| 依赖项 | RS_Nm_02517, RS_Nm_02550, RS_Nm_02546 |
| 用例 | 网络内 PNC 的同步 PNC 关闭、PN 复位定时器的重启。 |
| 适用平台 | CP |
| 支撑材料 | - |
5.2. 非功能需求¶
5.2.1. 布局需求¶
Nm 应定义 Nm 消息的通用布局
| 描述 | Nm 协议规定 Nm 消息格式，以便独立于所使用通信系统的底层物理层，对协议形成共同的理解。 |
|---|---|
| 理由 | Nm 消息的兼容性、互操作性、解释与创建。 |
| 依赖项 | - |
| 用例 | - |
| 适用平台 | AP、CP |
| 支撑材料 | - |
5.2.2. 时序需求¶
从所有节点一致同意进入总线休眠到总线被关闭之间应有确定性的时间
| 描述 | 从每个 ECU 的 Nm 就关闭某个通信系统达成一致的时间点，到该通信系统真正关闭的时间点，所需的时间必须是确定性的（保证最小时间和最大时间）。该时间必须是按集群静态可配置的。 |
|---|---|
| 理由 | 网络行为的确定性，同步休眠模式的保证。 |
| 依赖项 | - |
| 用例 | 见理由 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
5.2.3. 资源使用¶
Nm 应提供限制其总线负载的机制
| 描述 | Nm 不得超过规定的总线负载上限。该总线负载必须被规定。示例：正常运行时 3%，总线负载峰值 6%。 |
|---|---|
| 理由 | 确定性 |
| 依赖项 | - |
| 用例 | 避免 ISO 17356-5: Nm Specification 中的方案，例如总线唤醒后的存活消息 |
| 适用平台 | CP |
| 支撑材料 | - |
Nm 应支持最多 64 个 ECU 的通信集群
| 描述 | Nm 应支持最多 64 个 ECU/控制器的通信集群。 |
|---|---|
| 理由 | 灵活性 |
| 依赖项 | - |
| 用例 | 见理由 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
在正确配置的节点上，Nm 应容忍预定义数量 Nm 消息的丢失
| 描述 | 在正确配置的节点上，Nm 应容忍预定义数量 Nm 消息的丢失。消息丢失数量的限制必须在规范中描述。 |
|---|---|
| 理由 | 鲁棒性：Nm 不需要接收到每一条 Nm 消息。一条消息的丢失（在突发情形下）不应对 Nm 行为产生影响。 |
| 依赖项 | - |
| 用例 | 必须容忍 Nm 消息的丢失 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
Nm 应容忍一个或多个 ECU 中 Nm 消息的时间抖动
| 描述 | Nm 应容忍一个或多个 ECU 中 Nm 消息的时间抖动。抖动的限制必须在规范中描述。 |
|---|---|
| 理由 | 鲁棒性 |
| 依赖项 | - |
| 用例 | 必须容忍 Nm 消息的抖动 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
规范和实现应拆分为通信系统无关部分和通信系统相关部分
| 描述 | 规范和实现应拆分为通信系统无关部分和通信系统相关部分（通信系统相关部分应基于通信系统抽象）。 |
|---|---|
| 理由 | 复用 |
| 依赖项 | - |
| 用例 | 使用不同的总线系统（例如 CAN、FlexRay、以太网）而不必多次实现相同的通用逻辑。 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
Nm 的时序应可配置
| 描述 | Nm 的所有时序参数都应可配置。这包括定义 Nm 消息发送、最小发送重复次数、保持唤醒直至共同关闭等的时序。 |
|---|---|
| 理由 | 灵活性 |
| 依赖项 | - |
| 用例 | * 所有节点都已指示它们准备好休眠之后、网络被关闭之前的时间。 * 节点两次连续状态指示（是否准备好休眠）之间的时间间隔。 * 取决于可配置节点数量的时序确定。 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
5.2.4. 硬件无关性¶
网络管理 API 应独立于通信总线
| 描述 | 网络管理 API 应独立于通信总线，即对 CAN 和 FlexRay 是相同的。 |
|---|---|
| 理由 | 面向上层的通用、标准化接口。 |
| 依赖项 | - |
| 用例 | 在不同类型的总线上使用 Nm；只有一个独立于底层总线架构的接口。 |
| 适用平台 | AP、CP |
| 支撑材料 | - |
6. 参考文献¶
AUTOSAR_FO_TPS_StandardizationTemplate
AUTOSAR_FO_TR_Glossary
[3] Layered Software Architecture
AUTOSAR_CP_EXP_LayeredSoftwareArchitecture
A. AUTOSAR 可追溯项变更历史¶
请注意，本章中的列表还包括在后续版本中已从规范中移除的可追溯项。这些可追溯项在文档中不作为超链接出现。
由于本批次决议整体省略需求项 ID，本附录变更表的 Number 列省略，仅保留标题列。
A.1. 本文档依据 AUTOSAR 版本 R22-11 的可追溯项变更历史¶
A.1.1. R22-11 中新增的需求¶
表A.1：R22-11 中新增的需求
| 标题 |
|---|
| Nm 应处理同步 PNC 关闭的请求 |
| <Bus>Nm 应将同步 PNC 关闭的请求作为 NM-PDU 传输 |
| <Bus>Nm 应处理 NM-PDU 的重传 |
| Nm 应提供确认 API 以指示 PNC 位向量的传输状态 |
A.1.2. R22-11 中变更的需求¶
表A.2：R22-11 中变更的需求
| 标题 |
|---|
| Nm 未初始化时不应禁止总线通信 |
| Nm 应适用于 AUTOSAR 范围内且支持总线休眠模式的不同类型通信系统 |
| Nm 应提供相互独立地协调 Nm 集群关闭的服务 |
| 应可以在任何时间点触发所有节点的启动 |
| Nm 应提供请求保持总线唤醒的服务和取消该请求的服务 |
| 如果没有总线通信，Nm 应将通信控制器置于休眠模式 |
| Nm 应提供 Nm 的当前状态 |
| 当 Nm 状态变化发生时，Nm 应通知应用 |
| Nm 接口应向应用指示所有其他 ECU 已准备好休眠 |
| 从所有节点一致同意进入总线休眠到总线被关闭之间应有确定性的时间 |
| Nm 应对影响 Nm 行为的错误执行通信系统错误处理 |
| Nm 应提供限制其总线负载的机制 |
| Nm 应支持最多 64 个 ECU 的通信集群 |
| 在正确配置的节点上，Nm 应容忍预定义数量 Nm 消息的丢失 |
| Nm 应容忍一个或多个 ECU 中 Nm 消息的时间抖动 |
| Nm 的时序应可配置 |
| 网络管理的特定功能应可配置 |
| 网络管理算法应允许任何节点加入已运行的 Nm 集群 |
| 网络管理应可选地提供检测现有节点的可能性 |
| 网络管理 API 应独立于通信总线 |
| Nm API 应可选地提供发送用户数据的可能性 |
| Nm API 应可选地提供获取用户数据的可能性 |
| Nm 应可选地将本地节点标识符设置到 Nm 消息中 |
| Nm API 应提供读取发送方源节点标识符的可能性 |
| 每个节点都应有一个在 Nm 集群内唯一的节点标识符 |
| Nm 接口应向应用指示至少一个 ECU 不再准备好休眠 |
| 应可以将节点的网络管理配置为不参与集群关闭决策 |
| Nm 应提供启用或禁用为活动 Nm 节点配置的网络管理相关通信的可能性 |
| Nm 应提供使上层能够控制休眠模式的功能 |
| 应可以将网络分组为 Nm 协调集群 |
| Nm 应提供运行 AUTOSAR-Nm 之外的其他 Nm 的通用可能性 |
| 所有 AUTOSAR Nm 实例应支持 Nm 协调器功能，包括按需的总线同步 |
| Nm 控制位向量应包含一个 PNI（部分网络信息）位 |
| Nm 应实现过滤算法，丢弃与 ECU 不相关的所有 Nm 消息 |
| Nm 应提供允许立即发送 Nm 消息的服务 |
| Nm 协调应支持嵌套子总线的协调 |
| Nm 应提供不请求网络而启动的功能 |
| Nm 协调器应能够中止协调关闭 |
| Nm 控制位向量应包含一个 PN 关闭请求位 |
| Nm 应定义 Nm 消息的通用布局 |
| 如果至少释放了一个 PNC，顶层 PNC 协调器的 <Bus>Nm 应设置 PN 关闭请求位 |
| Nm 应转发 PN 关闭消息的指示 |
| UdpNm 应支持以太网上的部分网络 |
| <Bus>Nm 应能够传播和评估部分网络学习（Partial Networking Learning）的需求（可选） |
| <Bus>Nm 应能够以顶层 PNC 协调器或中间 PNC 协调器的角色传播和评估同步 PNC 关闭的需求（可选） |
| Nm 应提供请求和指示重复消息请求的接口（可选） |
| Nm 应支持按通道存储 IRA |
| Nm 应计算组合的部分网络请求状态 EIRA |
| Nm 应计算外部部分网络请求状态 ERA |
| <Bus>Nm 应使用专用 API 将 EIRA 和 ERA 请求传递给上层 |
| Nm 应支持 ERA 的按通道配置 |
| Nm 应支持所有通道上的 EIRA 全局配置 |
A.1.3. R22-11 中删除的需求¶
表A.3：R22-11 中删除的需求
| 标题 |
|---|
| NM 应转发同步 PNC 关闭的请求 |
| <Bus>NM 应处理同步 PNC 关闭的请求 |
A.1.4. R22-11 中新增的约束¶
无。
A.1.5. R22-11 中变更的约束¶
无。
A.1.6. R22-11 中删除的约束¶
无。
A.2. 本文档依据 AUTOSAR 版本 R23-11 的可追溯项变更历史¶
A.2.1. R23-11 中新增的需求¶
无。
A.2.2. R23-11 中变更的需求¶
无。
A.2.3. R23-11 中删除的需求¶
无。
A.2.4. R23-11 中新增的约束¶
无。
A.2.5. R23-11 中变更的约束¶
无。
A.2.6. R23-11 中删除的约束¶
无。