Network Management Interface是AUTOSAR通信管理器和AUTOSAR总线特定网络管理模块之间的适配层，这也是其基本功能。
此外，NM还有如下功能：

• 连接到运行AUTOSAR NM的同一个(协调器)ECU的多个网络之间的互操作性，其中“互操作性”意味着这些网络可以同步进入睡眠状态。这也称为NM协调器功能。
• 部分网络集群处理，包括处理PNC定时器和处理同步PNC关闭请求。如果部分网络使能，AUTOSAR NM汇总所有内部PNC请求（由ComM通知）、所有外部PNC请求（由<Bus>Nm通知），并管理每个通知的PNC的定时器。另外，如果使用同步PNC关闭功能，AUTOSAR NM收集所有同步PNC关闭请求（由ComM通知）并控制PNC关闭处理。针对PNC关闭消息发送，AUTOSAR NM指示<Bus>Nm获取汇总的PN关闭请求。在接收到PN关闭消息时，AUTOSAR NM扮演<Bus>Nm与ComM之间的接口层，它将请求从<Bus>Nm转发到ComM。PNC定时器的处理和同步PNC关闭请求的处理也被称为部分网络功能。

对NM协调器功能和部分网络功能的支持是可选的。Nm可以只支持基础功能，或者支持如下的功能组合之一：

• 基础功能和NM协调器功能；
• 基础功能和部分网络功能；

NM协调器功能和PNC功能这两个功能不能同时支持。
Nm为ComM提供服务，使用特定的总线管理模块（CanNm、FrNm、UdpNm、J939Nm）的服务。对于不需要提供总线管理信息的总线类型，比如LIN总线，它的总线类型可以配置为‘Local Nm’。关于回调函数，Nm模块为<Bus>Nm模块提供提醒回调函数，Nm模块使用ComM提供的回调函数。
总的来说，NM模块功能有以下三部分组成；

• 与总线特定的NM模块一起，在ECU上运行AUTOSAR NM所需的基本功能。
• NM协调器功能是网关ECU用来同步关闭一条或多条总线的。
• 部分网络功能分为2个子部分:
  • PNC请求的处理(过滤、聚合和监控)由作为部分网络成员的任何ECU使用。
  • PNC定时器处理由作为部分网络成员的任何ECU使用
  • PNC网关ECU以顶层PNC协调器或中间PNC协调器的角色使用同步PNC关闭功能，以同步关闭整个PN拓扑中的特定PNC。

基础功能

通用的Network Management Interface(Nm)模块，独立于总线类型，在特定总线网络管理模块和通信管理模块之间扮演适配层的角色。Nm将ComM的通用型函数调用转换为特定总线的NM的特定总线型函数；以及将特定总线NM调用的回调函数转换为通用型回调提供给ComM。
Nm的基础功能可以通过宏定义选择完全实现或部分实现。

NM协调器功能

Nm协调器是Nm模块的一个功能，其使用协调算法来协调ECU所连接的所有或一个或多个独立总线子集上的NM的关闭。根据配置，协调算法可以配置为实现不同层级上的同步关闭。
主动执行NM协调器功能的使用NM的ECU通常被称为NM协调器。然而，在本规范中，当在需求中使用时，该术语与NM协调器功能同义。
如果配置了NM协调器功能，则应配置配置参数NmCycletimeMainFunction，NM协调器可以使用这个来计算内部定时器的超时状态。

NM协调器功能的适用性

协调算法应能够处理几条协调总线连接到一个网络管理协调器的拓扑结构。网络管理协调器应支持两个或更多网络管理协调器连接到同一个网络管理集群。NM协调器应能够协调运行官方AUTOSAR总线特定NMs的总线，以及实现所需功能、回调和接口的所有其他通用总线NMs。
NM协调器功能的前置条件小节规定了所需的功能、回调和接口。协调器不需要支持J1939Nm，因为J1939Nm不支持关机处理。
NM接口配置应提供参数NmCoordinatorSupportEnabled，以定义是否支持NM协调器功能。
应可以配置多个独立协调的NM协调集群。每条总线应属于零个或一个NM协调集群。配置参数NmCoordClusterIndex用于指定总线属于哪个协调集群。如果通道的此参数未定义，则相应的总线不属于NM协调集群。
应仅在协调集群的当前唤醒网络上协调关闭。已经处于“总线睡眠模式”的网络仍将受到监控，但不会进行协调。
NM协调器不要求协调集群中的所有总线都被唤醒，与协调集群的子集，部分网络一起工作, 执行协调关闭。它始终监控关闭启动条件，当满足这些条件时，它对协调群集中所有当前唤醒的总线执行协调关闭。
为协调总线提供同步唤醒超出了Nm的范围。如果一个通道发生唤醒，则由应用程序(->车辆模式管理)来唤醒所要求的所有通道。

保持协调总线活动

在协调集群中只要至少一条总线上节点实现的NM协调器未准备好休眠（如它主动请求网络），NM协调器应保证在这个协调集群在所有当前活动总线上的网络被请求。
只要协调集群中的至少一条总线没有准备好休眠(即，因为除NM协调器之外的另一个节点正在请求该总线)，NM协调器仍将确保在该协调集群中所有当前活动的总线上请求网络，即使本地ECU本身准备好在该协调集群的所有总线上休眠。
总线特定的NMs将通过调用回调Nm _ RemoteSleepIndication和Nm_RemoteSleepCancellation向Nm指示总线是否准备好进入睡眠状态。本地ECU将使用API函数Nm_NetworkRelease和Nm_NetworkRequest指示它在某个网络上是否准备好进入睡眠状态。
Nm在一个总线上请求网络使用NM特定的函数<Bus>Nm_NetworkRequest。
由于所有AUTOSAR总线特定NMs都是基于这样的原则构建的，即一个AUTOSAR节点可以保持总线活动，只要它保持网络被请求，则NM协调器将通过为特定总线NMs请求网络来保持协调集群的所有总线处于唤醒状态。
以上要求，总结就是：只要至少一个节点（包含了节点实现的NM协调器）保持协调集群中任一总线唤醒，NM协调器将保持协调集群上所有总线唤醒。
如果协调集群的一个总线，参数NmChannelSleepMaster设置为TRUE，那么NM协调器认为该总线总是已经准备好休眠状态，因此在开始关闭该网络前不等待来自该总线的Nm_RemoteSleepIndication调用。
应该为所有总线特定的NMs设置该属性，总线的睡眠可以完全仅由本地节点决定，并且该总线的任何其他节点都不能反对该决定。这种网络的一个例子是LIN，其中本地AUTOSAR ECU将总是LIN总线主机，并且总是能够单独决定网络何时进入睡眠状态。

总线关闭的协调

可实现的同步等级取决于配置。下图描述了协调算法。每个NM协调集群协调算法和协调关闭都应是独立。

由协调算法执行的动作应该在哪里发生没有限制。这可以通过Nm main函数(Nm main function)或模块指示/回调来完成。
当协调集群的所有网络准备进入睡眠状态或已经处于“总线睡眠模式”时，NM协调器应在所有唤醒的网络上启动协调关闭。NM协调器应持续评估协调关闭是否可以启动。
关闭条件的评估也可以在main函数之外的其他API调用中完成。评估可以被分段，然后只检查受API调用影响的特定条件，因此没有必要在每个主处理周期和每个API调用中重新评估所有条件。
如果协调集群中的任何总线参数NmSynchronizingNetwork配置为TRUE，则协调关闭应延迟，直到配置为该协调集群同步网络的网络调用Nm_SynchronizationPoint。
如果在协调网络上，协调器检测到模式更改为NM_MODE_SYNCHRONIZE、NM_MODE_PREPARE_BUS_SLEEP或NM_BUS_SLEEP，并且该网络所属的协调集群尚未启动关闭过程，并且如果ComM没有针对该通道的内部网络模式请求，则协调器应将该网络视为远程睡眠，并应为该网络调用< Bus>Nm_NetworkRelease。此外，如果该网络的配置参数NmSynchronizingNetwork为TRUE，则协调器不应在该网络上等待Nm_SynchronizationPoint。
如果NM协调群集中的一个或多个网络是循环的(例如FlexRay)，则如果算法与所包括的循环网络之一同步，将实现更高级别的同步关闭。如果这样配置，所有协调网络的关闭定时器将不会启动，直到同步网络调用Nm_SynchronizationPoint。
如果启动协调关闭的所有条件未得到满足，或者如果协调关闭已经启动(但未中止)，则应忽略对Nm_SynchronizationPoint的调用。
在某些情况下，非同步网络可能需要更长时间才能进入睡眠状态。如果发生这种情况，协调关闭将基于一个同步指示开始，但是由于同步网络不会被直接释放，它将继续调用(几个)更多的同步指示，这些同步指示可以被安全地忽略。
如果协调群集中所有当前唤醒的总线的配置参数NmSynchronizingNetwork为FALSE，则定时器应在满足所有关闭条件后启动，无需等待调用Nm_SynchronizationPoint()。
当协调关闭开始时，应激活协调集群中每个当前唤醒通道的关闭延迟定时器。每个定时器定时应设置为NmGlobalCoordinatorTime。如果NmBusType设置不是NM_BUSNM_LOCALNM，则应减去特定通道TSHUTDOWN_CHANNEL的关闭时间。
如果NmGlobalCoordinatorTime为零，则所有通道的关闭延迟计时器也应为零。
TSHUTDOWN_CHANNEL可按照第7.2.5小节所述或以下公式计算:
CanNm: Ready Sleep Time + Prepare BusSleep Time
FrNm: Ready Sleep Time, e.g.: (FrNmReadySleepCnt+1) * FrNmRepetitionCycle * ”Duration of one Flexray Cycle“
GenericNm: NmGenericBusNmShutdownTime
当网络的关闭定时器到期时，如果BusNmType设置不是NM_BUSNM_LOCALNM，Nm应通过调用< Bus > Nm_RequestBusSynchronization，然后调用< Bus>Nm_NetworkRelease来释放网络。如果BusNmType设置为NM_BUSNM_LOCALNM，NM应通过调用ComM_Nm_BusSleepMode()通知ComM有关关闭的信息。
在AUTOSAR Classic平台中，CanNm_PassiveStartUp、J1939Nm_PassiveStartUp、FrNm_PassiveStartUp和UdpNm_PassiveStartUp被指定为与< Bus>Nm_PassiveStartUp对应的预定义接口。
Nm应跟踪所有已释放但尚未报告“总线睡眠模式”的网络。如果关闭被中止，这些网络仍应被视为活动网络。
当所有网络都被释放并且所有网络都处于“总线睡眠模式”时，协调关闭完成。

嵌套子总线的协调

为了支持嵌套子总线的协调，NM协调器需要配置为建立协调的架构层次。最顶层的NM协调器是在每个协调集群中只有主动协调的通道(NmActiveCoordinator = TRUE)。该NM协调器必须为所有其他协调器启动协调关闭。嵌套的NM协调器从其被动配置的通道(NmActiveCoordinator = FALSE)接收其关闭指示信息，并通过其主动协调的通道(NmActiveCoordinator = TRUE)将该信息提供给后面的NM协调器。下图为一个示例图：

图7.2所示的示例性拓扑具有以下协调方法。GW 1已经将网络1和网络2上的信道配置为主动协调信道。GW 2连接网络2的信道配置为被动协调信道，但是连接网络3的信道配置为主动协调信道。GW 3连接网络3的信道被配置为被动协调信道，其连接到网络4的信道，是主动协调信道。
当参数NmCoordinatorSyncSupport设置为TRUE时，协调嵌套自总线的功能可用。参数NmActiveCoordinator表明NM协调器是否在此通道上以主动方式协调调器（主动协调通道）NmActiveCoordinator = TRUE，或以被动方式协调（被动通道）NmActiveCoordinator = FALSE。
在其被动协调的信道上，仅当节点具有未决的网络管理请求或者由Nm协调器主动协调的连接的网络没有准备好睡眠时，NM协调器才发送NM消息。
这防止了在同一信道的2个NM协调器在它们准备睡眠时发送NM消息，并因此保持总线唤醒。如果没有这种机制，就不可能检测是否有至少一个其他节点是活动的。
NM协调器在其主动协调通道上，应通过的Nm _ SetSleepReadyBit将NM消息中的NMcoordinatorSleepReady位设置为值1，当NM协调集群的所有节点准备睡眠（RemoteSleepIndication），且当NmSynchronizingNetwork使能，相应通道上收到一个Nm_SynchronizationPoint()调用，NM协调集群的所有通道配置为NmActiveCoordinator == TRUE，且NmBusType配置不为NM_BUSNM_LOCALNM。
包含被动协调信道的节点不需要同步点，因为它们已经被它们的主动协调器的睡眠就绪位同步。
如果被动协调通道上接收到Nm_CoordReadyToSleepIndication，则NmCoordinator应在其所有主动协调通道上通过API调用Nm_SetSleepReadyBit，将NMCoordinatorSleepReady位设置为SET(1)。
如果被动协调通道上接收到Nm_CoordReadyToSleepCancellation，则NmCoordinator应在其所有主动协调通道上通过API调用Nm_SetSleepReadyBit，将NMCoordinatorSleepReady位设置为UNSET(0)。
即NM协调器在其被动协调通道上不设置睡眠就绪位，但转发其从被动协调通道上收到的睡眠就绪位的状态的改变到它的主动协调通道上。
在NM协调器的主动协调信道上，不调用Nm_CoordReadyToSleepIndication和NM_CoordReadyToSleepCancellation。
在睡眠就绪位被请求SET（1）后，NM协调器应开始协调关机。NmGlobalCoordinatorTime应至少设置为关闭所有协调网络所需的最大时间。这包括所有嵌套连接。如下图所示：

当协调关闭因任何原因被中断，NM协调器应在其主动协调通道上通过API调用<Bus>Nm_SetSleepReadyBit将NMCoordinatorSleepReady设置位UNSET（0)。

关闭定时器的计算

协调算法非常灵活，因为可实现的同步水平取决于开关和定时器的配置。根据同步的目标是哪个事件或时间点，配置应该以不同的方式完成。本节介绍如何实现3个不同层级的同步。由配置来决定是遵循这些准则还是通过选择他/她自己的特定配置来实现单独的同步顺序。因此，本节将不包含任何要求，仅包含建议。
请注意，绝对同步永远不可能实现。决定同步精度的抖动因素包括Nm的处理周期、定时器的精确性以及非确定性总线的总线负载。正确配置后，下面描述的用例将给出考虑这些情况下可实现的最佳同步。
NM协调器的先前版本包括协调器算法将协调关闭的开始延迟“若干轮”的可能性。此特定延迟已被移除，但通过增加所有关闭定时器(配置参数NmGlobalCoordinatorTime)仍可获得类似的行为。当使用循环网络(如FlexRay)时，必须特别小心，因为这种增加的延迟时间应为网络的同步指示周期的整倍数。

同步用例1 – 同步指令

这个用例关注于如何同步不同网络释放的时间点。这会使所有网络尽可能快地完全关闭，但缺点是网络不会同时进入“总线睡眠模式”。这种使用情况的一个例子是，只要任何一个CAN节点请求其中一个网络，几个CAN网络就应该保持活动状态；但是，当所有节点都准备好进入睡眠状态时，不同网络是否同时进入“总线睡眠模式”并不重要。
由于用例不考虑网络的任何循环行为，所有网络的同步参数NmSynchronizingNetwork应设置为FALSE，并且不应配置任何总线特定的NM来调用Nm_SynchronizationPoint回调。
为了尽可能快地关闭，需要将关闭定时器参数NmGlobalCoordinatorTime设置为0.0。

同步用例2-同步启动

该用例是用例1的扩展，但是这里要考虑的事实是，对于一些网络来说，释放网络的请求将只在特定的时间点被执行。这个用例将像用例1一样命令同时关闭，但是将等到适合同步网络的时间点。这种使用情况的一个例子是当一个FlexRay网络和几个CAN网络时，所有网络都处于活动状态的时间应该最大化，但是网络仍然应该尽可能快地进入睡眠状态。
由于此用例应考虑所选网络的循环行为，因此其中一个网络应将同步参数NmSynchronizingNetwork设置为TRUE，而其他网络应将此参数设置为FALSE。同步网络的总线特定NM也应配置为在适当的时间点调用Nm_SynchronizationPoint回调，此时应启动关闭。
为了尽可能快地关闭，需要将关闭定时器参数NmGlobalCoordinatorTime设置为0.0。

同步用例3 -同步网络睡眠

这个用例将集中于同步不同网络进入“总线睡眠模式”的时间点。它将等待来自同步网络的指示，然后基于定时值延迟所有网络的网络释放，以便从“网络模式”(或“准备总线睡眠模式”)到“总线睡眠模式”的转换尽可能同步。
这种用例的一个例子是当一个FlexRay网络和几个CAN网络同时停止通信时。
由于该用例将考虑所选网络的循环行为，因此这些网络(最好是循环网络)应当将其同步参数NmSynchronizingNetwork设置为真，而其他网络应当将该参数设置为假。同步网络的总线特定NM也应配置为在适当的时间点调用Nm_SynchronizationPoint回调，启动关闭网络。
为了计算每个网络的关闭定时器TSHUTDOWN_CHANNEL，必须获得每个网络定时行为的特定知识。
对于所有网络，必须计算TSHUTDOWN_CHANNEL，这是网络进入“总线睡眠模式”所需的最短时间。对于非循环网络(如CAN)，时间应从网络释放的时间点开始测量，直到进入“总线睡眠模式”。对于循环网络(如FlexRay ),时间还应包括网络释放前同步指示的完整范围。对于通用BusNms，时间由配置参数NmGenericBusNmShutdownTime给出。
对于同步网络，必须确定TSYNCHRONIZATION_INDICATION。这是总线特定的NM对Nm_SynchronizationPoint进行的任何两次连续调用之间的时间。NmGlobalCoordinatorTime应为协调算法所需的总时间。这包括嵌套子总线的关闭时间。首先将同步网络的NmGlobalCoordinatorTime设置为与TSHUTDOWN_CHANNEL相同的值。如果任何其他网络的TSHUTDOWN_CHANNEL大于NmGlobalCoordinatorTime，使用TSYNCHRONIZATION_INDICATION重复扩展NmGlobalCoordinatorTime，直到NmGlobalCoordinatorTime等于或大于任何TSHUTDOWN_CHANNEL。
每个网络的关机延迟定时器都应计算，作为该网络的NmGlobalCoordinatorTime-TSHUTDOWN _ CHANNEL。
对于循环网络，该参数必须稍微增加，以确保网络释放将在同步指示之间发生，在Nm _ SynchronizationIndication(would)被调用之后不久。扩展定时器的时间量取决于总线特定NM的实现和配置，但是应该远小于TSYNCHRONIZATION_INDICATION。

示例

本例中，同步网络拥有最大的TSHUTDOWN_CHANNEL，因此等于NmGlobalCoordinatorTime。关闭延迟计时器是NmGlobalCoordinatorTime-TSHUTDOWN _ CHANNEL，其值为零的同步网络，随后会添加少量时间，以确保Nm将在两个同步点之间等待释放网络。
对于非循环网络，关闭延迟定时器将简单地为NmGlobalCoordinatorTime-TSHUTDOWN _ CHANNEL。

另一个示例中，非周期网络关闭网络花费非常长时间，因此拥有最大的TSHUTDOWN_CHANNEL。NmGlobalCoordinatorTime通过将同步网络的(稍短的)TSHUTDOWN_CHANNEL加上一次TSYNCHRONIZATION_INDICATION值而获得。
对于同步网络，关闭定时器将是NmGlobalCoordinatorTime-TSHUTDOWN _ CHANNEL，增加少量时间以确保Nm将等待在两个同步点之间释放网络。对于非循环网络，关闭定时器将简单地为NmGlobalCoordinatorTime-TSHUTDOWN _ CHANNEL。

唤醒和中止协调关闭

NM不负责节点或网络的正常唤醒，这将由ComM完成。

外部的网络唤醒

对与基础功能和NM协调功能，NM都将调用ComM_Nm_NetworkStartIndication()转发唤醒指示，从网络到ComM。唤醒指示是总线特定的NMs调用回调函数Nm_NetworkStartIndication指示的。ComM将调用Nm_PassiveStartUp， Nm会将它转发到总线特定的NM的相应接口。
总线睡眠(与收发器和控制器状态相关)通道的唤醒事件的处理将由ECU和ComM处理。这里没有Nm的交互。根据唤醒验证和各自的通信需求，Nm将从如上所述的ComM获取网络请求。
如果ComM为属于协调网络集群的一个网络调用Nm_PassiveStartUp()，则Nm协调器功能应将此调用视为ComM调用了Nm_NetworkRequest()。如果BusNmType设置不为NM_BUSNM_LOCALNM，则NM应转发一个< Bus>Nm_NetworkRequest调用到较低层，相应地，网络应被认为是被NM协调器请求。即当为网络协调集群上的某个网络调用Nm_PassiveStartUp，则应被”转换”或作为调用Nm_NetworkRequest处理。

协调唤醒

根据配置，ComM可以根据一个网络的指示启动多个网络。建议将ComM配置为如果NM协调集群的其中一个网络指示网络启动，自动启动所有网络，但这并不总是必要的。因为网络的唤醒不在NM的范围内，所以这与是否使用Nm协调功能无关。

协调关闭的中止

如果激活了NM协调功能，并且在NM协调集群上启动了协调关闭，根据协调器算法配置，在实际释放每个包含的总线之前可能需要一段时间。如果协调总线上的任何节点在所有网络被释放之前改变其状态并开始请求网络，则在协调算法中会出现竞争情况。这可能以四种方式发生:

• 网络上尚未被释放且仍处于“网络模式”的节点开始再次请求网络。这将被总线特定的Nm（对Can总线来说就是CanNm）检测到，它将通过调用Nm_RemoteSleepCancellation通知NM。
• 网络上已经被释放并指示“准备总线睡眠模式”而不是“总线睡眠模式”的节点再次开始请求网络。这将被总线特定的Nm检测到，该Nm将自动将状态改变为“网络模式”,并通过调用Nm_NetworkMode通知NM。
• ComM在协调集群中的任何网络上请求网络。
• 主动协调该网络的协调器发送带有清除的就绪睡眠位的Nm消息。这将由总线特定的NM(仅在被动协调通道上)检测到，并通过调用NM_CoordReadyToSleepCancellation转发给NM。
  一般的方法是中止关机并再次开始请求网络。然而，已经进入“总线睡眠模式”的网络不应被自动唤醒；这必须由ComM明确请求。
  如果任何NM协调集群中任一网络出现以下情况，应中止协调关闭：
• 指示Nm_RemoteSleepCancellation
• 指示Nm_NetworkMode
• 指示Nm_CoordReadyToSleepCancellation
• 或ComM在任一网络上请求Nm_NetworkRequest或Nm_PassiveStartUp.

Nm_NetworkStartIndication不是中止协调的触发器，因为这由上层处理。
如果协调关机被中止，网络管理协调器应为所有已指示“总线睡眠”的网络调用ComM_Nm_RestartIndication。
由于Nm不能自己决定唤醒网络，这必须由ComM决定，就像(外部)唤醒情况一样。
如果协调关闭被中止，在BusNmType的设置不为NM_BUSNM_LOCALNM情况下，NM协调器应为未指示“总线睡眠”的网络从< Bus>Nm请求网络。如果BusNmType设置为NM_BUSNM_LOCALNM，NM应通过调用ComM_Nm_NetworkMode()通知ComM网络启动。
如果协调算法已经中止，应重新评估所有保护协调停机启动的条件。
当协调关闭被中止时，在大多数情况下是该NM协调群集中的网络不再指示网络睡眠是可能的，因此NM协调器必须保持所有当前非睡眠网络唤醒。可能存在没有改变任何条件的情况，这会使协调关闭重新启动。
如果协调关机已经中止，并且Nm在< Bus>Nm_NetworkRequest上收到E_NOT_OK，则在再次评估启动协调关机的条件时，该网络不应被视为处于唤醒状态。
任何之前已经释放的网络的<Bus>Nm在中止协调关闭过程中都需要被ComM和Nm重新请求。< Bus>Nm负责通知ComM(通过Nm)网络确实已被释放，因此，即使Nm_NetworkRequest上的错误响应从未直接到达ComM，ComM也会知道网络状态。
如果协调关机已经启动，并且Nm在< Bus>Nm_NetworkRelease上收到E_NOT_OK，则应立即中止关闭。所有未进入“总线睡眠模式”的网络，Nm应为其请求网络，这包含那个指示< Bus>Nm_NetworkRelease错误的网络。在这完成之后，启动协调关闭的条件即可重新评估。这也适用于没有主动参与当前协调关闭的网络。
如果网络无法释放，应立即再次请求，同步NM和<Bus>Nm网络协调器的状态。只要< Bus>Nm的问题仍然存在，协调关闭最终将再次启动。这取决于< Bus>Nm直接向DEM和/或DET报告任何问题，因此Nm协调器将仅尝试释放网络，直到成功为止。

部分网络功能

PNC位向量过滤算法

PNC位向量过滤算法的目的是包括所有与用于PNC处理的ECU相关的PNC请求，并排除所有接收到的与ECU不相关的PNC请求。此外，过滤算法用于验证相关PNC传输请求。符合相关条件的PNC请求(重新)启动相应的PNC定时器。
为了区分与ECU相关的PNC请求和不相关的PNC请求，Nm评估由< Bus>Nm接收的PNC位向量(被动PNC请求，由网络中的另一个ECU远程发起)，并评估由ComM发送的PNC位向量(主动请求，由本地应用程序发起)。PNC位向量的每一位代表一个PNC。
PNC是静态配置的。一个PNC表示ECU加入特定的部分网络集群(PNC)。
PNC位向量过滤器算法应在Nm_PncBitVectorRxIndication的上下文中评估给定PNC位向量的字节。
PNC位向量的每个位(PNC位)代表一个部分网络簇(PNC)。如果PNC位设置为1，则请求部分网络集群。如果该位设置为0，则没有对此PNC的请求。
PNC位向量过滤算法应将接收到的PNC位向量与PN过滤器掩码进行比较(逐位位与),以检测是否请求了相关PNC。PN滤波器掩码的每个PNC位应具有以下含义:

• 0：PNC请求与ECU无关。如果在接收到的PNC位向量中设置了该位，则ECU的通信堆栈不会保持唤醒。
• 1：PNC请求与ECU相关。如果在接收到的PNC位向量中设置了该位，则ECU的通信堆栈保持唤醒状态。

如果启用了< Bus>NmAllNmMessagesKeepAwake ,即使没有接收到相关的PNC请求，ECU仍可能保持活动状态。
如果调用了Nm_PncBitVectorRxIndication，NmPnEiraCalcEnabled或NmPnEraCalcEnabled设置为TRUE，并且根据给定PNC位向量中的至少有一个PNC位被检测为相关PNC请求，则OUT参数RelevantPncRequestDetectedPtr应设置为TRUE。否则，应将RelevantPncRequestDetectedPtr的值设置为FALSE。
调用者<Bus>Nm使用RelevantPncRequestDetectedPtr的值来确定是否应考虑将接收到的NMPDU用于进一步的Rx指示处理。例如，给出的PNC位向量长度（NmPncBitVectorLength）为2字节：

本例中，NmPnFilterMaskByte设置为：

• NmPnFilterMaskByteIndex = 0 with NmPnFilterMaskByteValue = 0x01
• NmPnFilterMaskByteIndex = 1 with NmPnFilterMaskByteValue = 0x97
  那么过滤算法的行为及结果为：

过滤掩码值（Byte）	与接收到的PNC位向量对比	结果
0x01(Byte0)	0x12(NM PDU Byte4)	0x00(没有相关的PNC请求)
0x97(Byte1)	0x8E(NM PDU Byte5)	0x86(相关PNC请求)

由于一个字节包含了相关信息，布尔参数RelevantPncRequestDetectedPtr的值被设置为TRUE。
所有配置的NmPnFilterMaskBytes的长度应与相应NM通道的NmPncBitVectorLength的长度(以字节为单位)相同。如果配置的NmPnFilterMaskBytes的长度与相应NM通道配置的NmPncBitVectorLength不同，配置工具应报错。

PNC请求的汇总

内部和外部局部网络集群的汇合

如果NmPnEiraCalcEnabled设置为TRUE，则Nm应提供在NmPnEnabled设置为TRUE的所有Nm通道上存储联合的外部和内部请求的PNC的可能性。初始化时，EIRA境内所有PNC的值应设置为0 (代表PNC已释放)。
如果：

• NmPnEiraCalcEnabled是TRUE；
• 且收到PNC位向量，通过Nm_PncBitVectorRxIndication(<Nm-channel>, <PNC bit vector of external PNC requests>)或Nm_ForwardSynchronizedPncShutdown(<NM-channel>, <PNC bit vector PNCs indicated for a synchronized shutdown>)
• 且PNCs被请求（报文中相应PNC位设置为1）
• 且在PN过滤掩码中请求PNC的相应位设置为1

那么Nm应为这些PNCs储存这个请求信息，作为“PNC请求”。
如果：

• NmPnEiraCalcEnabled是TRUE；
• 且通过Nm_PncBitVectorTxIndication(<NM-channel>, <buffer to provide the unfiltered PNC bit vector of aggregated internal PNC requests >) 指示了PNC位向量的发送
• 且在所给的NM通道上没有等待的同步PNC关闭请求；
• 且在储存的未过滤的PNC位向量中PNCs被请求（位设置为1）；
• 且在配置的PN过滤掩码中，用于内部PNC请求的储存的未过滤的PNC位向量中所请求的PNCs，对应的位设置为1；

那么Nm应为这些PNCs储存这个请求信息，作为“PNC请求”。
如果NmPnEiraCalcEnabled为TRUE，Nm_PncBitVectorTxIndication(<NM-channel>, PncBitVectorPtr <buffer to provide the unfiltered PNC bit vector>)被调用，在给定通道上没有等待的PNC同步关闭请求，那么Nm应拷贝该用于给定NM通道内部PNC请求的未过滤的PNC位向量到PncBitVectorPtr指向的缓存中。
如果：

• NmPnEiraCalcEnabled设置为TRUE；
• 且在给定NM通道上存在等待处理的PNC同步关闭请求；
• 且通过Nm_PncBitVectorTxIndication(<NM-channel>, <buffer to provide the PNC bit vector of the aggregated synchronized PNC requests >)指示了PNC位向量的发送；
• 且同步PNC关闭的PNC在PNC位向量中被请求；
• 且PNC位向量的聚合的同步PNC请求，在配置的PN过滤掩码中设置为1；

那么Nm应为这些PNCs存储请求信息，作为“PNC请求”。
如果NmPnEiraCalcEnabled设置为TRUE，Nm_PncBitVectorTxIndication(NetworkHandle <NM-channel>, PncBitVectorPtr <buffer to provide the aggregated synchronized PNC requests as bit vector>)被调用，在给定NM通道上存在等待处理的同步PNC关闭请求，那么Nm应按照如下方式设置PncBitVectorPtr指向的缓存区：

• 将与给定NM通道的同步PNC关闭所请求的PNC相关的所有相应位设置为1；
• 所有其他位设置为0；
  Nm模块必须聚合所有PNC，这些PNC被指示用于同步PNC关闭，并将pncId’s传输到一个字节数组(PNC位向量)。
  PNC位向量的每个位(PNC位)代表一个特定的PNC。PNC位向量内PNC位的byteIndex和bitindex可由下式确定:
• byteIndex = (PncId div 8)
• bitIndex = (PncId mod 8)

对于NmPartialNetworkSupportEnabled设置为TRUE的所有已配置Nm通道，NM应提供存储NmPnEnabled设置为TRUE的所有NM通道上，联合的外部和内部请求PNC的可能性。初始化时，EIRA内所有PNC的值应设置为0。
如果Nm_UpdateIRA(<NM-channel>, <PncBitVector of aggregated internal PNC requests>)被调用，对每个给定的NM通道，Nm应储存接收到的未过滤的PncBitVector。因此，Nm模块应拷贝给定NM通道配置的长度（参见NmPncBitVectorLength）的字节的数据。
注意：Nm存储未过滤的内部PNC请求，以便支持在特定通道上请求PNC的可能性，即使PNC未被分配给该通道。
如果NmPnEiraCalcEnabled是TRUE，然后，Nm应提供在Nm_Mainfunction上下文监控每个相关PNC的可能性。如果PNC仍然在至少一个相关NM信道上被外部或内部请求，则监控应考虑PNC状态。
注意:这意味着只需要一个定时器来处理多个连接的物理信道上的一个PNC。例如:仅需要8个EIRA复位定时器来处理具有6个物理信道和8个部分网络集群的网关的请求。这是可能的，因为PNC相关PDU组的切换对于ECU是全局完成的，并且独立于物理信道。
如果NmPnEiraCalcEnabled是TRUE，每次PNC被储存为“PNC请求”，然后，应在Nm_Mainfunction的上下文中，根据NmPnResetTime重新启动对该PNC的监控。
注意:NmPnResetTime必须配置为大于< Bus>NmMsgCycleTime的值。如果NmPnResetTime被配置为小于< Bus>NmMsgCycleTime的值，并且只有一个ECU请求PNC，则请求状态在EIRA中跳变，因为请求的ECU在下一个NM消息发送PNC位向量之前，请求状态就会复位。
注意:NmPnResetTime必须配置为小于< Bus>NmTimeoutTime的值，以避免定时器在< Bus>Nm已经变为预期禁用应用通信的状态(例如，变为准备总线睡眠(UdpNm、CanNm)或总线睡眠(FrNm))后超时。
如果NmPnEiraCalcEnabled是TRUE，且在NmPnResetTime时间内未被再次请求，在Nm_Mainfunction的上下文中，该PNC的相应存储值应设置为PNC 释放(值0)。
如果NmPnEiraCalcEnabled是TRUE，且PNC的储存值设置为PNC请求或返回到PNC释放，那么Nm应通过调用ComM_Nm_UpdateEIRA(<PncBitVector of EIRA>))将改变后的EIRA状态转发ComM。
注意:如果收到PN关闭消息(PNSR设置为1)，不需要特殊处理，因为相应的PNC状态机需要保持在COMM_PNC_READY_SLEEP状态。只有ERA PDU的处理方式不同

外部部分网络集群的汇合

如果NmPnEraCalcEnabled为TRUE，则Nm应提供存储每个通道相关外部PNCs请求的可能性。初始化时，所有PNC的值应设置为0 (PNC释放)。
如果：

• NmPnEraCalcEnabled为TRUE；
• 且通过Nm_PncBitVectorRxIndication(<NMchannel>, <PncBitVector of external PNC requests>收到PNC位向量；
• 且PNCs在这个报文（所包含的PNC向量中）被请求，
• 且在配置的PN过滤掩码中所请求的PNC对应位的设置为1；

那么Nm应为这些PNCs储存该PNC请求信息，作为“PNC请求”。
如果NmPnEraCalcEnabled为TRUE，则Nm应提供在Nm_Mainfunction环境下监控每个通道的相关PNC的可能性。如果PNC仍在相应NM信道上被外部请求，则监控应考虑PNC状态。
注意:这意味着需要一个单独的定时器来处理多个物理通道上的一个PNC。例如:需要48个ERA PNC复位定时器来处理具有6个物理信道和8个部分网络集群的PNC网关的外部PNC请求。不能像EIRA PNC定时器那样组合PNC复位定时器，因为外部PNC请求不能镜像回从总线/网络接收PNC请求的总线/网络。因此，需要检测PNC请求的源物理通道（即PNC来源的物理通道）。
如果NmPnEraCalcEnabled为TRUE，那么每次PNC存储为“PNC请求”时，应在Nm_Mainfunction的上下文中根据NmPnResetTime重新开始对该PNC的监控。
注意:NmPnResetTime必须配置为大于< Bus>NmMsgCycleTime的值。如果NmPnResetTime被配置为小于< Bus>NmMsgCycleTime的值，并且只有一个ECU请求PNC，则请求状态将在EIRA中跳变，因为请求的ECU在下一个NM消息发送出PNC位向量之前，请求状态就会复位。

注意:NmPnResetTime必须配置为小于< Bus>NmTimeoutTime的值，以避免定时器在< Bus >Nm已经变为预期禁用应用通信的状态(例如，变为准备总线睡眠(UdpNm、CanNm)或总线睡眠(FrNm))后超时。
如果NmPnEraCalcEnabled是TRUE，且PNC的储存值设置为PNC请求或返回到PNC释放，那么Nm应通过调用ComM_Nm_UpdateERA (<ComMChannel>,<PncBitVector of ERA>)将受影响NM通道的ERA的更改状态转发ComM。
如果NmPnEiraCalcEnabled为真，NmPnEraCalcEnabled为真，则必须为EIRA和ERA信息分别存储PNC状态信息。

EIRA / ERA 状态和复位定时器处理

PNC的ERA和EIRA复位定时器在Nm_Mainfunction中处理。PNC复位定时器用于监控PNC请求。基于当前可用的PNC请求和相应PNC复位定时器的当前状态，必须执行特定的动作（如，重启PNC定时器，设置请求的PNC到PNC释放）。
如果NmPartialNetworkSupportEnabled设置是TRUE，那么所有PNC的复位定时器在初始化时都应停止。
如果NmPartialNetworkSupportEnabled设置为TRUE，那么结合PNC复位定时器对PNC状态进行评估时，应至少考虑以下顺序:

• 更新PNC复位定时器；
• 评估PNC状态；
• 根据当前PNC复位定时器状态和PNC请求执行动作；
  对PNC请求和PNC复位定时器处理的监控保持为特定于实现。下一节给出了一个例子，如何在Nm的主函数中处理EIRA / ERA评估和PNC复位定时器。这有助于理解Nm中PNC处理的整体机制。
  示例：下面的例子基于以下假设：
• 每个PNC复位定时器有3个状态（停止、超时、运行）；
• 如果一个PNC复位定时器被启动，PNC复位定时器载入NmPnResetTime的值；
• 在每次主函数调用中运行的PNC复位定时器中的值被递减直到达到0；
• PNC网关功能使能：
  • 每个通道存在一个ERA作为PNC位向量
  • 存在一个EIRA作为（整个PNC网络的）PNC位向量

在初始化时，PNC复位定时器在“停止”状态，且EIRA/ERA PNC位向量设置位0。如果接收到相关PNC(通过PN滤波器掩码的PNC)，且该值设置为“1”，则PNC复位定时器启动。在每个主函数中，所有PNC定时器首先递减。之后，结合相应PNC复位定时器的状态，对当前PNC请求进行评估。基于评估结果执行特定的动作。作为最后一步，EIRA / ERA PNC位向量被擦除(设置为‘0’)。这需要刷新PNC请求的当前状态，直到下一个主函数调用，并检测从PNC请求到PNC释放的变化，反之亦然。（请注意:如果接收到具有相关PNC请求的PNC位向量，或者如果发送了具有相关PNC请求的PNC位向量，则EIRA总是被更新。如果接收到具有相应通道的相关PNC请求的PNC位向量，ERA总是被更新。）基于这个例子，EIRA和ERA被用来存储两个主函数调用之间的PNC请求的快照。在每个主函数调用中，PNC请求从EIRA / ERA存储器传送到PNC复位定时器和/或作为改变到ComM。
下表列出了评估的详细示例。EIRA / ERA PNC state列和PNC reset timer state列是输入，Evalution result列是输出的评估结果。输出结果表示了要执行那个动作。
结合PNC复位定时器状态的EIRA / ERA PNC状态处理示例表:

EIRA/ERA PNC state	PNC reset timer state	Evaluation result
PNC requested	Stopped	Start PNC reset timer,set PNC reset timer state to “running” and inform ComM regarding the PNC state change
PNC requested	Elapsed	Restart PNC reset timer, set PNC reset timer state to “running” and inform ComM regarding the PNC state change
PNC requested	Running	Restart PNC reset timer
PNC released	Stopped	Do nothing
PNC released	Elapsed	Set PNC reset timer to “stopped” and inform ComM regarding the PNC state change
PNC released	Running	Do nothing (Please note: time of the PNC reset timer was already decrement as very first action in the main function)

同步PNC关闭功能

同步PNC关闭是ComM、Nm和< Bus>Nm的协作功能，以确保在整个PN拓扑中几乎同时同步PNC关闭。同步PNC关闭由ECU作为顶层PNC协调器或中间PNC协调器来处理，其中PNC网关已启用。如果处于顶层PNC协调者角色的ECU的ComM检测到PNC被释放，则ComM通过调用Nm_RequestSynchronizedPncShutdown 为每个ComMChannel和ComMPnc请求同步PNC关闭。Nm模块存储所有请求，并在Nm_Mainfunction的上下文中处理它们。Nm模块指示受影响的< Bus>Nms关于PNC关闭流程激活的信息。<Bus>Nm调用Nm模块，为每个给定网络管理通道提供聚合的聚合的同步PNC关闭请求作为PNC位向量。< Bus>Nms使用提供的PNC位向量来组装NM-PDU作为PN关闭消息，并在相应的NM通道上发送该NM消息。如果作为中间PNC协调器的ECU接收到PN关闭消息，则< Bus>Nms从接收到的PN关闭消息中提取PNC位向量，并通过调用回调函数Nm_ForwardSynchronizedPncShutdown转发信息。回调函数将通过调用ComM_Nm_ForwardSynchronizedPncShutdown立即将指示转发给ComM。通信将立即请求同步PNC关闭所有主动PNC协调(由PNC网关协调)的通信信道。同步PNC关闭的请求被转发到每个NM通道的Nm模块，并以与上所述相同的方式进行处理。
如果PNC叶节点接收到顶层PNC协调器NM帧，则它会将该帧作为普通Nm消息处理(更新本地PNC位向量并重置PN重置时间)。
如果NmPartialNetworkSupportEnabled设置为TRUE，那么PNC关闭处理在初始化时应认为是未激活的。
如果函数Nm_RequestSynchronizedPncShutdown被调用，NmSynchronizedPncShutdownEnabled设置为TRUE，且给定的NM通道的NmStandardBusType设置为非NM_BUSNM_LOCALNM，Nm模块应为每个NM通道存储所给的PNC（PncId）作为等待的同步PNC关闭请求。
如果通过回调函数Nm_ForwardSynchronizedPncShutdown指示了PN关闭报文的接收，那么Nm应停止PNCs的外部PNC请求的ERA相关的监测，这些请求在给定的PNC位向量中被指示为PNC关闭(PNC位被设置为‘1’)，在指示的Nm通道的ERA中将相应的ERA位设置为‘0’，并通过调用ComM_Nm_ForwardSynchronizedPncShutdown(< ComMChannel >，< PNC bit vector >)将指示转发给ComM的相应ComMChannel。
注意：

• 应使用接收到的PN关闭消息的PNC位向量来释放PNC以进行同步关闭。明确清除指示NM通道的受影响ERA位，停止对指示NM通道的指示PNC的ERA监控，并将同步PNC关闭的指示传递给通信模块。必须尽快处理同步的PNC关闭。因此，会立即通知通信模块。
• 停止与ERA相关的监控不应导致调用ComM_UpdateERA。ComM确保在ComM_Nm_ForwardSynchronizedPncShutdown上下文中正确处理ComM内部ERA位。这应该支持对同步PNC关闭的PNC状态机的明确处理。

如果配置了NmPnShutdownMessageRetransmissionDuration，且Nm_RequestSynchronizedPncShutdown被调用，那么在所有受影响的NM通道上，相应的PN关闭报文的重传定时器应启动，并载入NmPnShutdownMessageRetransmissionDuration的值。
如果NmSynchronizedPncShutdownEnabled设置为TRUE，同步PNC关闭请求在等待，且PNC关闭处理已被禁止，那么Nm应通过调用<Bus>Nm_ActivateTxPnShutdownMsg激活PNC关闭的处理。
如果NmSynchronizedPncShutdownEnabled设置为TRUE，没有同步PNC请求在等待，PNC关闭处理已激活，那么Nm应通过调用<Bus>Nm_DeactivateTxPnShutdownMsg关闭PNC关闭的处理。
如果NmSynchronizedPncShutdownEnabled设置为TRUE，PNC关闭处理已打开，且Nm_PncBitVectorTxConfirmation返回E_OK,那么Nm模块应认为这些PNC IDs已完成，储存作为所给NM通道的同步PNC关闭的挂起请求，由给定的PNC位向量指示（PNC位设为1），并从储存中移除。此外，如果配置了NmPnShutdownMessageRetransmissionDuration，那么Nm模块针对受影响的NM通道应取消PN关闭消息的重传定时器。
注意：

• 在一个正在进行的PNC关闭流程中，Nm必须保证同步PNC关闭的新请求（由Nm_RequestSynchronizedPncShutdown指示）不丢失。
• 只要Nm_PncBitVectorTxConfirmation返回E_NOT_OK或PN关闭消息的重传定时器正在运行，<Bus>Nm必须处理重传NM PDU作为PN关闭消息。

如果NmSynchronizedPncShutdownEnabled设置为TRUE，且Nm模块储存了PNC IDs作为同步PNC关闭的挂起请求，那么Nm因该从储存中移除这些PNC IDs，它们被外部或内部再次请求：

• 如果接收到外部PNC请求，Nm应通过调用Nm_PncBitVectorRxIndication检查PNC位向量的接收；
• 如果内部PNC请求可用，Nm应调用Nm_UpdateIRA检查PNC位向量的更新；

如果NmSynchronizedPncShutdownEnabled设置为TRUE，NmPnShutdownMessageRetransmissionDuration未配置，该NM通道相应的<Bus>Nm模块通过调用Nm_PncBitVectorTxIndication指示了传输请求，且Nm_PncBitVectorTxConfirmation调用返回E_NOT_OK(传输所给的PNC位向量失败)，那么Nm应从储存中移除相应通道上作为同步PNC关闭的挂起请求的PNC IDs，并报告运行时错误NM_E_TRANSMISSION_OF_PN_SHUTDOWN_MESSAGE_FAILED到DET。
如果NmSynchronizedPncShutdownEnabled设置为TRUE，且PN关闭消息的重传定时器超时，那么Nm应从存储中移除相应NM通道的同步PNC关闭的挂起请求，并报告运行时错误NM_E_TRANSMISSION_OF_PN_SHUTDOWN_MESSAGE_FAILED到DET。
注意：如果配置了PN关闭消息的重传定时器，且NM报文未被成功传输（Nm_PncBitVectorTxConfirmation调用返回E_NOT_OK），那么PNC关闭进程继续。在最坏的情况下，PN关闭过程与通过< Bus>NmMsgCycleTime发送的公布的NM消息同时发生。但是在任何情况下，如果在PN重置时间(EIRA)内没有恢复传输NM消息的能力，PNC将会不同步地关闭，这可能导致应用层的超时错误。

总线特定NM模块的前置条件

本章概述了用于基本功能、NM协调功能和同步PNC关闭功能的API调用，以及这两种功能的总线特定NM的预期行为信息。

基础功能的前置条件

在基础功能中Nm只作为ComM和总线特定NM之间的转发层。
所有来自上层API调用都要转发到相应的下层API调用。下层所引用的所有Nm的回调需要被转发到相应的上层回调。
基础功能提供如下API调用给ComM：
• Nm_NetworkRequest - [SWS_Nm_00032]
• Nm_NetworkRelease - [SWS_Nm_00046]
• Nm_PassiveStartUp - [SWS_Nm_00031]
这意味着总线特定的NM提供相应的函数< Bus>Nm_NetworkRequest、<Bus>Nm_NetworkRelease和< Bus>Nm_PassiveStartUp。
基础功能转发如下API回调给ComM：
• Nm_NetworkStartIndication - [SWS_Nm_00154]
• Nm_NetworkMode - [SWS_Nm_00156]
• Nm_BusSleepMode - [SWS_Nm_00162]
• Nm_PrepareBusSleepMode - [SWS_Nm_00159]
这意味着ComM提供相应的回调函数ComM_Nm_NetworkStartIndication, ComM_Nm_NetworkMode, ComM_Nm_BusSleepMode 和 ComM_Nm_PrepareBusSleepMode。
NM为上层提供了许多API调用，这些调用ComM不使用。这些API调用是为Nm堆栈的OEM特定扩展提供的，不是任何AUTOSAR模块所必需的。它们将被转发到由总线特定NMs提供的相应API调用。
基础功能提供以喜爱API调用给OEM的上层的扩展：
• Nm_DisableCommunication - [SWS_Nm_00033]
• Nm_EnableCommunication - [SWS_Nm_00034]
• Nm_SetUserData - [SWS_Nm_00035]
• Nm_GetUserData - [SWS_Nm_00036]
• Nm_GetPduData - [SWS_Nm_00037]
• Nm_RepeatMessageRequest - [SWS_Nm_00038]
• Nm_GetNodeIdentifier - [SWS_Nm_00039]
• Nm_GetLocalNodeIdentifier - [SWS_Nm_00040]
• Nm_CheckRemoteSleepIndication - [SWS_Nm_00042]
• Nm_GetState - [SWS_Nm_00043]
注意：这意味着总线特定NM可选地提供相应的函数。

NM协调器功能的前置条件

协调算法使用以下总线特定NM的接口：
• <Bus>Nm_NetworkRequest - [SWS_Nm_00119]
• <Bus>Nm_NetworkRelease - [SWS_Nm_00119]
• <Bus>Nm_RequestBusSynchronization - [SWS_Nm_00166]
• <Bus>Nm_CheckRemoteSleepIndication - [SWS_Nm_00166]
注意：配置为NM协调器功能的协调集群一部分的所有NM网络必须有相应的总线NM配置，能够主动发送NM报文（CANNM_PASSIVE_MODE_ENABLED = false）。由于这种配置限制，Nm模块的协调器功能所使用的所有<Bus>Nm必须提供API Nm_NetworkRequest。属于协调网络的网络，其<Bus>Nm配置为 passive是无效的。
在< Bus>Nm_NetworkRelease之前，Nm立即调用< Bus >Nm_RequestBusSynchronization，以便允许非同步网络在网络释放之前进行同步。对有些网络，这个调用是没有任何意义是。总线特定的NM将仍然提供这个接口，以便支持NM协调器功能的通用性，但是可以选择提供空的实现。
协调算法中从未明确提及< Bus >Nm_CheckRemoteSleepIndication。它的使用取决于实现。
协调算法要求以下Nm的回调可以被总线特定的Nm引用：
• Nm_NetworkStartIndication - [SWS_Nm_00154]
• Nm_NetworkMode - [SWS_Nm_00156]
• Nm_BusSleepMode - [SWS_Nm_00162]
• Nm_PrepareBusSleepMode - [SWS_Nm_00159]
• Nm_SynchronizeMode - [SWS_Nm_91002]
• Nm_RemoteSleepIndication - [SWS_Nm_00192]
• Nm_RemoteSleepCancellation - [SWS_Nm_00193]
• Nm_SynchronizationPoint - [SWS_Nm_00194]
Nm_NetworkStartIndication, Nm_NetworkMode, Nm_BusSleepMode 和 Nm_PrepareBusSleepMode被协调算法用来决定何时满足发起协调关闭的全部条件。当总线特定NM检测到网络上所有其他节点（除了它自己）准备好进入“总线睡眠”模式时，它将调用这个指示。有些实现也使用了API <Bus>Nm_CheckRemoteSleepIndication。
包含在协调集群中的总线特定NM必须监控其总线，以识别网络上的所有其他节点何时准备好进入睡眠。发生这种情况时，总线特定的Nm应调用NM的回调Nm _ RemoteSleepIndication。

在包含在协调群集中的总线特定的Nm向NM发信号通知网络上的所有其他节点准备好进入睡眠后，它必须继续监视其总线，以识别是否有任何节点再次开始请求网络，这意味着总线不再准备好进入睡眠。发生这种情况时，总线特定的Nm应调用NM的回调Nm_RemoteSleepCancellation。
远程睡眠指示和取消功能在相应的总线特定NM中进一步规定。
总线特定Nm应调用Nm_SynchronizationPoint，以便通知协调算法启动协调关闭的合适时间点。对于循环网络，这通常在循环边界处。对于非循环网络，这必须通过其他方式来定义。每个NM协调集群可以被配置为使用或不使用同步指示，并且如果使用同步指示，则协调算法过滤指示，并且仅作用于来自被配置为同步网络的网络的指示。
请注意< bus>Nm的实现:当没有其他节点请求网络时，循环网络重复调用Nm_SynchronizationPoint。当NM投票发生变化时，通常在总线特定NM协议的边界进行调用。
假设在这两个Nm_SynchronizationPoint之间对< Bus>Nm_ReleaseNetwork的任何调用都将在调用下一个Nm_SynchronizationPoint的同一时间点被执行。
同步指示应在通知Nm_RemoteSleepIndication时开始，并持续到网络被释放(<Bus>Nm_NetworkRelease)或Nm_RemoteSleepCanncellation被调用。
对于协调Flexray-channel A + B的用例，如果NM群集中没有其他网络，因此，如果NM协调器只包含一个NM通道，则此NmChannelConfig的NmActiveCoordinator需要设置为TRUE，NmChannelSleepMaster需要设置为FALSE，以允许通道自行协调。注意:“NmSynchronizingNetwork”的值仅在该网络与其他网络位于同一个协调群集中时才有意义。

部分网络功能的前置条件

PNC请求汇合的前置条件

PNC请求的聚合，要求以下Nm回调函数可以被总线特定Nm引用：
• Nm_PncBitVectorRxIndication
• Nm_PncBitVectorTxIndication
PNC请求聚合功能提供了以下API，可被ComM调用：
• Nm_UpdateIRA

同步PNC关闭功能的前置条件

同步PNC关闭功能使用以下特定总线NM的接口：
• <Bus>Nm_RequestSynchronizedPncShutdown
同步PNC关闭功能要求以下Nm的回调函数可以被总线特定NM引用：
• Nm_ForwardSynchronizedPncShutdown
同步PNC关闭功能提供以下API，供ComM调用：
• Nm_RequestSynchronizedPncShutdown

总线特定网络的全局参数配置

Nm的配置包含调节总线专用NMs中可选特征支持的参数。对于Nm协调器相关功能不使用的特性而言，NM只是一个直通接口层。在许多情况下，在Nm的配置中启用这些特性只会启用控制API函数和来自总线特定层的回调指示的直通。
为NM定义的许多参数仅用作所有总线特定NM模块的全局配置源。总线特定NMs的相应参数从这些参数中导出。

NM_BUSNM_LOCALNM

如果BusNmType为NM_BUSNM_LOCALNM，且ComM请求Nm_PassiveStartUp() 或Nm_NetworkRequest()，那么Nm应通知ComM关于通过调用ComM_Nm_NetworkMode()启动网络的信息。
NM_LOCAL_NM类型的总线被协调，没有网络管理消息，但是被同步，例如：通过像LIN这样的主从概念。这些总线类型总是根据ComM的请求直接启动，但关闭将由协调器算法完成。

多核分布

作为处理不同网络类型的中央模块，在Com堆栈是分布式的情况下，Nm交互跨越多个分区，因此应提供所需的多核功能，以确保干净的架构，并保持网络依赖的集群没有多分区(多核)插件。
Nm模块应应用适当的机制，以允许从除其主函数之外的其他分区调用其API，例如通过提供Nm卫星。
Nm应仅在分区中与< Bus>Nm交互(即调用< Bus>Nm APIs ),相应的< Bus > Nm模块被分配到该分区。
Nm内核应被分配到与ComM内核相同的分区，以保持这两个模块在分区内的交互。
即使基础软件(特别是Com栈)分布在几个分区中，ComM 和Nm主模块也应该分配在同一个分区中，以便保持两个模块之间的模式接口简单(更多信息请参见[BSW分布指南]中的 主模块/卫星方法一章)。

附加功能

Nm_CarWakeUpIndication

如果<Bus>Nm调用Nm_CarWakeUpIndication，且NmCarWakeUpCallout有定义，NM接口应以nmNetworkHandle作为参数调用NmCarWakeUpCallout定义的回调函数。
如果<Bus>Nm调用Nm_CarWakeUpIndication，且NmCarWakeUpCallout未定义，NM接口应以nmNetworkHandle作为参数调用函数BswM_Nm_CarWakeUpIndication。
该应用程序由NmCarWakeUpCallout调用，负责管理汽车唤醒(CWU)请求，并通过设置其自身Nm消息中的CWU位将该请求分发到其他Nm通道。如果请求在特定时间内没有重复，此应用程序将丢弃CWU请求。

Nm_StateChangeNotification

如果NmStateReportEnabled设置为TRUE，且NmStateReportSignalRef已配置，当发生NM状态改变时，Nm_StateChangeNotification应为由NmStateReportSignalRef引用的信号，使用下表的值调用函数Com_SendSignal(uint8, Com_SignalIdType, const void*)。

发送的信号必须至少是Com中的6位信号，它应该是NM消息的一部分。
当Nm_StateChangeNotification被调用报告NM状态改变时，NM应调用BswM_Nm_StateChangeNotification()报告当前的状态。
如果NmDynamicPncToChannelMappingEnabled设置为TRUE，且Nm_StateChangeNotification被调用，那么当nmPreviousState设置为NM_STATE_REPEAT_MESSAGE且nmCurrentState与NM_STATE_REPEAT_MESSAGE不同时应调用ComM_Nm_RepeatMessageLeftIndication()。

时序图

基础功能

当Nm作基础功能角色时，仅仅作为ComM和Nm之间的dispatcher，因此没有时序图。

NM协调器功能的时序

下图所示为NM协调器功能关闭网络的时序图

8.3 部分网络功能的时序
下面的序列图显示了Nm和CanIf模块之间的交互。如果使用FlexRay通信堆栈，必须考虑一下差异：

• FrNm没有类似于CanNmAllNmMessagesKeepAwake的ECUC参数；
• FrNm需要检查在FrIf中配置的NM PDU的ECUC参数FrIfImmediate；
• 如果使用FrNm，NM Pdu总是通过FrNm_TriggerTransmit获取。没有类似于CanIfTxPduTriggerTransmit的ECU参数

如果使用以太网通信堆栈，必须考虑以下差异:

• UdpNm模块与SoAd交互(而不是与EthIf交互)。因此，UdpNm必须调用SoAd_IfTransmit来触发NM PDU的传输。SoAd必须调用UdpNm_SoAdIfRxIndication来指示NM PDU的接收；
• UpdNm需要检查SoAd的ECUC参数SoAdBswModules/-SoAdIfTriggerTransmit，以确定NM PDU是否是通过调用UdpNm_SoAdIfTriggerTransmit获取的；