本篇我们介绍BSW中的ComM模块，它是一个资源管理器，封装了对底层通信服务的控制。ComM模块控制与通信相关的基本软件模块，而不是软件组件或可运行实体。ComM模块收集来自通信请求者(术语“用户”的定义)的总线通信访问请求,并协调总线通信访问请求。同样地，与ComM交互的模块也有很多，下图是ComM与其他模块的交互示意图。
ComM某块在BSW中的位置如下图所示，它被划分到属于系统服务。

模块交互

这里重点介绍下ComM与EcuM、ComM、BswM、CanSM、NM等模块的交互。

EcuM交互

EcuM负责wake-up的验证，如果验证是有效的唤醒事件，那么将验证结果发送到ComM。通信使能和shutdown ECU是由EcuM和BswM合作处理完成的。

BswM交互

BswM实现两种功能模式仲裁和模式控制，以允许应用模式管理和车辆模式管理的应用。如果在BswM的执行列表中配置,能够通过BswM请求ComM模式，BswM将用户请求传递到ComM模块。如果在执行列表中配置了Com_IpduGroupControl调用，则BswM可以控制AUTOSAR通信模块(COM)中的PDU Group。ComM向BswM提示所有通道主状态变化和所有PNC状态变化。如果使用EcuM-Flex，BswM将向ComM指示是否允许通信。

NvM交互

ComM模块使用NVRAM Manager去存储和读取数据。这里需要注意：NvM必须在ComM之前完成初始化，因为当ComM初始化时，即认为NvM已经初始化完成，处于可使用状态。

CanSM交互

Can State Manager是ComM模块通信模式对应的CAN总线实际状态的控制者。ComM从CanSM请求通信模式，CanSM将切换总线状态匹配到所请求的通信模式。简而言之就是CanSM是实际执行控制网络通信状态的模块，ComM请求CanSM执行某种通信状态设置，CanSM将实际去执行，从而将总线状态设置为ComM所请求的状态。

NM交互

ComM通过NM同步网络上的通信能力（同步通信开启和关闭）。此外PNCs的状态信息通过ComM和NM之间专门的APIs进行交互。
另外，ComM与CanSM的交互，在CanSM篇已经描述过。

ComM功能

ComM模块，为它的用户简化了资源管理，它的用户可能是一个runnable实体，一个SWC，BswM（如SW-C通过BswMing求）或Dcm（为了诊断需要通信）等。
ComM模块提供了三种通信模式：

• COMM_FULL_COMMUNICATION
• COMM_SILENT_COMMUNICATION
• COMM_NO_COMMUNICATION
  但对用户来说，可以请求的通信模式只有COMM_FULL_COMMUNICATION或COMM_NO_COMMUNICATION,而COMM_SILENT_COMMUNICATION仅用于同步网络。在COMM_FULL_COMMUNICATION模式的通道上，用户可正常接收和发送报文；在COMM_NO_COMMUNICATION模式的通道上，用户接收和发送报文均不可进行。
  当配置项ComMNmVariant = FULL | LIGHT | NONE时，DCM_ActiveDiagnostic指示被视为相应通道上COMM_FULL_COMMUNICATION的请求。

Paritial Network Cluster 管理

ComM模块为用户提供了唤醒和保持“Paritial Network Cluster（PNC）” 的功能。PNC是逻辑上的一组ECUs，它们必须同时处于活动状态才能实现某些分布式功能。如果使用支持PNC的网关，PNC可以跨越整个网络(网络层次结构上不同拓扑级别上的不同总线)。如果没有PN功能，NM消息只能唤醒并保持唤醒整个总线。
ComM针对每个PNC都实现了状态机去代表该PNC的通信状态。ComM User用于请求和释放PNCs。系统信道节点上所有PNC的状态通过网络管理报文的PNC位向量内交换。

Partial Network Cluster 管理功能

配置项ComMPncSupport勾选时，PNC功能才可用。在post-build阶段使用参数ComMPncEnabled使能或禁止PNC功能。ComM通过调用BswM_ComM_CurrentPncMode()通知BswM PNC状态机的每一次改变。ComM和NM之间使用PNC位向量（PNC Bit Vector）交换PNC状态信息，PNC位向量最长包括504bit。PNC位向量作为对uint8类型数组的引用通过专用的API提供给ComM。PNC位向量中的每一个bit都代表着某个PNC的状态，这些位称为PNC位。PNC位的计算需要用到 byteIndex和bitIndex，byteIndex和bitIndex计算方式如下所示：
byteIndex = ( ComMPncId / 8 ) - <PNC Vector Offset>
bitIndex = (ComMPncId % 8 )
相应通道的PNC位向量的长度由网络管理模块配置定义。ComM通过回调函数ComM_Nm_UpdateEIRA(<PNC bit vector of internal and external PNC requests>)接收内部和外部PNC请求的聚合状态，作为PNC位向量。如果ComM_Nm_UpdateEIRA(<PNC bit vector of EIRA>)被调用，那么ComM将会把所给的PNC位向量的内容转换为ComM的EIRA。
ComM通过回调函数ComM_Nm_UpdateERA(<Channel>, <PNC bit vector of external PNC requests>)接收聚合的外部PNC请求状态，作为每个通道的PNC位向量。如果配置参数ComMPncGatewayEnabled设置为TRUE，调用ComM_Nm_UpdateERA(<channel>,
<PNC bit vector of ERA>)且参数ComMPncGatewayType设置的通道，ComM将所给的PNC位向量内容转换为给定通道的ERA。通信在一个内部EIRA中转换Nm提供的EIRA PNC位向量，在每个通信信道的一个ERA中转换每个ERA PNC位向量。在ComM的内部EIRA / ERA中转换PNC位向量的内容，是将内部EIRA / ERA中的PNC位设置为‘1 ’(如果PNC位向量中的相应PNC位设置为‘1 ’),或者将内部EIRA / ERA中的PNC位设置为‘0 ’(如果PNC位向量中的相应PNC位设置为‘0 ’)。
ComM模块应能在分配的ComM通道上分发特定PNC的状态(PNC状态机的结果)。因此，ComM应通过调用API Nm_UpdateIRA(<channel>, <PNC bit vector of
aggregated internal PNC requests>)，将每个通信通道(如总线或网络)的内部PNC请求的聚合状态作为PNC位向量转发。IRA PNC位向量表示内部PNC请求的状态。

ComM PNC状态机

如果使能了PNC功能，那么在通道相关动作之前，所有PNC相关的改变应该被执行。每个PNC对应一个PNC状态机，它独立于ComMChannels的数量。ComM最多支持504个PNC状态机。PNC状态机由两个主状态组成：

• COMM_PNC_FULL_COMMUNICATION
• COMM_PNC_NO_COMMUNICATION

PNC主状态COMM_PNC_FULL_COMMUNICATION由三个子状态组成：

• COMM_PNC_PREPARE_SLEEP
• COMM_PNC_READY_SLEEP
• COMM_PNC_REQUESTED

每个状态改变，除了从PowerOff进入主状态COMM_PNC_NO_COMMUNICATION，都需要使用进入的PNC状态作为参数，调用API BswM_ComM_CurrentPncMode() ，进行通知。在ComM中PNC状态机切换的触发由调用ComM_RequestComMode()实现。该触发函数只可在ComM_MainFunction_<Channel.ShortName>中执行。
触发器“ComMUser”通过调用API ComM_RequestComMode()来表示关于ComMUser的通信请求的通知。在对于映射到一个或多个PNC的通道，在ComM_MainFunction_<Channel.ShortName>内，应按照以下顺序处理所请求的状态:

• ComM users的ComM user请求，映射到该通道一个或多个PNC；
• ComM users的ComM user请求映射到该通道；
• ERA（当配置开关ComMPncGatewayEnabled配置为TRUE时）
• EIRA
  关于“允许通信”和模式禁止，来自PNC状态机的请求应被视为用户对相应通道的请求。
  

在主状态COMM_PNC_NO_COMMUNICATION中PNC的行为

COMM_PNC_NO_COMMUNICATION主状态是上电后默认的PNC状态。当PNC没被外部请求，也没被内部请求时，PNC的目标状态就是COMM_PNC_NO_COMMUNICATION。
当PNC在COMM_PNC_NO_COMMUNICATION状态：

• API ComM_EcuM_WakeUpIndication()被调用，开关ComMSynchronousWakeUp配置为TRUE，并且所有PNC通过ComMChannelPerPnc至少引用一个ComMChannel，那么将离开PNC主状态COMM_PNC_NO_COMMUNICATION，进入PNC子状态COMM_PNC_PREPARE_SLEEP；
• API ComM_EcuM_WakeUpIndication()被调用，开关ComMSynchronousWakeUp配置为FALSE，PNC主状态COMM_PNC_NO_COMMUNICATION就是当前状态；
  当异步唤醒时，PNC状态应待在COMM_PNC_NO_COMMUNICATION，直到接收到PNC请求（EIRA中相应的 PNC bit 设为1）。
• 当API ComM_EcuM_PNCWakeUpIndication(<PNC>)被调用，并且指示的PNC通过ComMChannelPerPnc至少引用一个ComMChannel，那么将离开PNC主状态COMM_PNC_NO_COMMUNICATION，进入PNC子状态COMM_PNC_PREPARE_SLEEP；
• 当分到到PNC的ComMUser中，至少一个发起Full Communication请求，PNC将离开COMM_PNC_NO_COMMUNICATION状态，进入主状态COMM_PNC_FULL_COMMUNICATION的子状态COMM_PNC_REQUESTED。
• 当EIRA中代表该PNC的PNC位变为1，并且该PNC通过ComMChannelPerPnc至少引用一个ComMChannel，那么将离开PNC主状态COMM_PNC_NO_COMMUNICATION，进入PNC子状态COMM_PNC_READY_SLEEP；

PNC网关相关的要求

当PNC处在主状态COMM_PNC_NO_COMMUNICATION时，ERAn中至少一个代表该PNC的PNC位变为1，那么满足以下条件时，该PNC将离开状态COMM_PNC_NO_COMMUNICATION，进入子状态COMM_PNC_REQUESTED：

• 参数ComMPncGatewayEnable设置为TRUE；
• PNC通过ComMChannelPerPnc至少引用一个ComMChannel，所有被引用的通道都有ComMPncGatewayType设置；
  所有被PNC引用的通道要有GW类型设置，这里的引用与引用类型无关，如：ComMChannelPerPnc 或 ComMChannelPerTxOnlyPnc。

从断电进入PNC主状态COMM_PNC_NO_COMMUNICATION时

上电后从PowerOff进入主状态COMM_PNC_NO_COMMUNICATION

在主状态COMM_PNC_FULL_COMMUNICATION的行为

当PNC在状态COMM_PNC_FULL_COMMUNICATION，PNC通过ComMChannelPerPnc引用的所有通道都要处于COMM_FULL_COMMUNICATION状态。

进入PNC子状态COMM_PNC_REQUESTED时

• 当从COMM_PNC_NO_COM或COMM_PNC_PREPARE_SLEEP进入COMM_PNC_REQUESTED状态时，这个PNC通过ComMChannelPerPnc至少引用一个ComMChannel，并且该PNC的ComMPncWakeupSleepRequestEnabled设置为TRUE，那么将使用参数COMM_PNC_REQUESTED_WITH_WAKEUP_REQUEST调用BswM_ComM_CurrentPNCMode，而不是使用参数COMM_PNC_REQUESTED调用BswM_ComM_CurrentPNCMode。

• 当进入子状态COMM_PNC_REQUESTED时，ComM模块将在IRA内对应该PNC的PNC位设置为1，并通过调用Nm_UpdateIRA(<channel>, <IRA>) 将聚合的内部PNC请求转发到该PNC引用的每个通道。只要满足以下条件之一：

  • ComMPncGatewayEnabled 设为FALSE；
  • 该PNC引用的ComMChannel，ComMPncGatewayType 均未设置；

• 每次从其他状态进入COMM_PNC_REQUESTED，ComM应为所PNC配置通过参数ComMChannelPerPnc引用，且ComMWakeupSleepRequestEnabled为FALSE的所有ComM Channels请求COMM_FULL_COMMUNICATION，而无论通道是否被请求过。

• 每次由COMM_PNC_NO_COM或COMM_PNC_PREPARE_SLEEP进入COMM_PNC_REQUESTED，ComM应为所PNC配置通过参数ComMChannelPerPnc引用，且ComMWakeupSleepRequestEnabled为TRUE的所有ComM Channels请求COMM_FULL_COMMUNICATION_WITH_WAKEUP_REQUEST，而无论通道是否被请求过。

• 当从状态COMM_PNC_READY_SLEEP进入状态COMM_PNC_REQUESTED，ComM应为所PNC配置通过参数ComMChannelPerPnc引用，且ComMWakeupSleepRequestEnabled为TRUE的所有ComM Channels请求COMM_FULL_COMMUNICATION REQUEST，而无论通道是否被请求过。

注意从COMM_PNC_READY_SLEEP进入不应导致网络唤醒，因为(处于COMM_PNC_READY_SLEEP的)PNC(就代表)已经被另一个ECU远程请求。

PNC网关相关的要求

当进入PNC子状态COMM_PNC_REQUESTED且ComMPncGatewayEnabled设置为TRUE时，则
在ComMPncGatewayType设置为COMM_GATEWAY_TYPE_ACTIVE的所有引用的ComMChannels上，ComM应在IRA内设置该PNC位为‘1’，并通过调用Nm_UpdateIRA(<channel >，< IRA >)将聚合的内部PNC请求转发给这些ComMChannels。

在PNC子状态 COMM_PNC_REQUESTED的行为

• 若PNC引用的所有通道的ComMPncGatewayEnabled设置为FALSE或ComMPncGatewayType未设置，当分配给该PNC的所有ComMUsers请求No Communication时，则离开PNC子状态 COMM_PNC_REQUESTED，而进入PNC子状态COMM_PNC_READY_SLEEP。只要还有任何一个ComMUser还在请Full Communication，则应留在PNC子状态COMM_PNC_REQUESTED。
• 在子状态COMM_PNC_REQUESTED中，当ComMPncGatewayEnabled设置为FALSE，且分配到PNC的ComMUser中，至少存在一个请求“Full Communication”，则COMM应为该PNC通过ComMChannelPerTxOnlyPnc引用的ComMChannels请求COMM_FULL_COMMUNICATION。
• 在子状态COMM_PNC_REQUESTED中，当ComMPncGatewayEnabled设置为FALSE，且分配到PNC的ComMUser都请求“No Communication”，则COMM应为该PNC通过ComMChannelPerTxOnlyPnc引用的ComMChannels请求COMM_NO_COMMUNICATION。

PNC网关相关要求

• 满足以下条件时，应该离开子状态COMM_PNC_REQUESTED，进入子状态COMM_PNC_READY_SLEEP ：

  • 分配到该PNC的所有ComMUsers都请求“No Communication”；
  • 参数ComMPncGatewayEnabled设置为TRUE；
  • 至少有一个ComMChannel通过ComMChannelPerPnc被该PNC引用；
  • 该PNC引用的所有ComMChannel都设置了参数ComMPncGatewayType；
  • ERAn中代表该PNC的PNC位为0；

• 满足以下条件时，应该离开子状态COMM_PNC_REQUESTED，进入子状态COMM_PNC_READY_SLEEP ：

  • 分配到该PNC的所有ComMUsers都请求“No Communication”；
  • 参数ComMPncGatewayEnabled设置为TRUE；
  • 该PNC引用的所有ComMChannel都没设置参数ComMPncGatewayType；

• 在子状态COMM_PNC_REQUESTED，当ComMPncGatewayEnabled设置为TRUE，且分配到PNC的ComMUser中至少有一个请求“Full Communication”，则ComM应在这些ComMChannel：

  • 参数ComMPncGatewayType设置为COMM_GATEWAY_TYPE_PASSIVE ，且
  • 通过参数ComMChannelPerPnc或参数ComMChannelPerTxOnlyPnc被该PNC引用；

的IRA内将代表该PNC的PNC位设置为值‘1’，并调用 Nm_UpdateIRA(<channel>, <IRA>) 转发更新后的IRA。

• 在子状态COMM_PNC_REQUESTED，当ComMPncGatewayEnabled设置为TRUE，且至少在一个ERA中代表该PNC的PNC位为1，该PNC对应的ComMChannel的参数ComMPncGatewayType设置为COMM_GATEWAY_TYPE_ACTIVE，则ComM应在这些ComMChannel：
  • 参数ComMPncGatewayType设置为COMM_GATEWAY_TYPE_PASSIVE ，且
  • 通过参数ComMChannelPerPnc或参数ComMChannelPerTxOnlyPnc被该PNC引用；

的IRA内将代表该PNC的PNC位设置为值‘1’，并调用 Nm_UpdateIRA(<channel>, <IRA>)转发更新后的IRA。

• 在子状态COMM_PNC_REQUESTED当ComMPncGatewayEnabled设置为TRUE，分配到该PNC的ComMUsers中至少有一个请求“Full Communication”，ComM应为该PNC通过ComMChannelPerTxOnlyPnc引用的ComMChannels请求COMM_FULL_COMMUNICATION。

• 在子状态COMM_PNC_REQUESTED，当ComMPncGatewayEnabled 设置为TRUE，如果：

  • 分配到该PNC的所有ComMUsers都请求“No Communication”，且；
  • 表示该特定PNC的PNC位在ERAn中等于“0 ”,其对应的ComMChannel的参数ComMPncGatewayType设置为COMM_GATEWAY_TYPE_ACTIVE；

  则ComM应在这些ComMChannel：

  • 参数ComMPncGatewayType设置为COMM_GATEWAY_TYPE_PASSIVE，且；
  • 通过参数ComMChannelPerPnc或ComMChannelPerTxOnlyPnc 被该PNC引用；

的IRA中将代表该特定PNC的PNC位设置为值“0”，并通过调用 Nm_UpdateIRA(<channel>, <IRA>)转发更新后的IRA。

• 在子状态COMM_PNC_REQUESTED，当ComMPncGatewayEnabled设置为TRUE，如果：

  • 分配到该PNC的所有ComMUsers都请求“No Communication”，且；
  • 该PNC引用的ComMChannels的参数ComMPncGatewayType都未设置；
    则ComM应在PNC引用的所有ComMChannel的IRA中将代表该特定PNC的PNC位设置为值“0”，并通过调用 Nm_UpdateIRA(<channel>, <IRA>)转发更新后的IRA。

• 在子状态COMM_PNC_REQUESTED，当ComMPncGatewayEnabled 设置为TRUE，且分配到该PNC的所有ComMUsers都请求“No Communication”，ComM应为该PNC通过参数ComMChannelPerTxOnlyPnc引用的ComMChannels请求COMM_NO_COMMUNICATION。

• 当在子状态COMM_PNC_REQUESTED调用ComM_Nm_ForwardSynchronizedPncShutdown(<channel>, <PNC bit
  vector>)指示转发PNC同步关闭的请求时 ，且满足以下条件：

  • 分配到该PNC的所有ComMUsers都请求“No Com”；
  • 通过参数ComMChannelPerPnc被该PNC引用，且通道参数ComMPncGatewayType是COMM_GATEWAY_TYPE_ACTIVE的所有ComMChannel的ERAn的该PNC对应PNC位值为0；
  • 函数ComM_Nm_ForwardSynchronizedPncShutdown指示的通道是分配在该PNC上的，且该PNC已被指示关闭(在给定的PNC位向量中，PNC位被设置为‘1 ’)；
  • 指示的通道的参数ComMPncGatewayType为COMM_GATEWAY_TYPE_PASSIVE，且通道通过ComMChannelPerPnc被引用；
  • ComMSynchronizedPncShutdownEnabled设置为TRUE；

那么ComM应该执行以下操作：
- ComM将该PNC通过参数ComMChannelPerPnc引用的通道属性ComMPncGatewayType为 COMM_GATEWAY_TYPE_PASSIVE的所有ComMChannel的ERA中该PNC对应的PNC位设为0；
- 在通过参数ComMChannelPerPnc引用的通道属性ComMPncGatewayType为COMM_GATEWAY_TYPE_ACTIVE的通道上，ComM为每个通道使用当前的PNC Handle调用函数 Nm_RequestSynchronizedPncShutdown (<channel>,<PncId>);
- 离开子状态COMM_PNC_REQUESTED，进入子状态COMM_PNC_READY_SLEEP。

注意：
* 每当中间PNC协调器(具有至少一个ComMChannel且ComMPncGatewayType设置为COMM_GATEWAY_TYPE_PASSIVE的PNC协调器)从顶层PNC协调器接收Nm帧作为PN关闭消息，ComM立即释放PNC，转发PN关闭消息的PNC位向量，并且请求分配到受影响PNC的所有参数ComMPncGatewayType为COMM_GATEWAY_TYPE_ACTIVE的ComMChannels，PNC同步关闭（请求发送一条PN关闭消息）。
* ComM确保尽快处理作为关闭消息的NM报文，以保证PNC同步关闭的延时最小。
* 如果本地user请求受影响的PNC，或通过ComMPncGatewayType属性为COMM_GATEWAY_TYPE_ACTIVE的ComM Channel接收到PNC请求，转发PNC同步关闭的行为都不会执行。无论是本地或者远程PNC请求都将否决PNC同步关闭请求。
* PNC同步关闭仅在PNC处在 COMM_PNC_REQUESTED状态才执行

• 若该PNC已经调用ComM_Nm_ForwardSynchronizedPncShutdown(<channel>)指示请求转发PNC同步关闭。PNC满足释放条件且转发PNC同步关闭的前置条件不满足，ComM模块应该拒绝转发PNC同步关闭。而且如果ComMPncNmRequest设置为TRUE，无论当前受影响通道是否已处在“Full Communication”，ComM都应为分配到该PNC的所有通道，调用Nm_NetworkRequest再次请求网络。

• 如果ComMSynchronizedPncShutdownEnabled设置为TRUE，且分配到该PNC的所有ComM Channels的参数ComMPncGatewayType设置都为COMM_GATEWAY_TYPE_ACTIVE，那么在如下条件下应调用Nm_RequestSynchronizedPncShutdown (<channel>, <PncId>)，这里channel代表的当前处理的ComMChannel，PncId是该PNC的ComMPncId：

  • 在ERAn中PNC相应的PNC位为0；
  • 分配到该PNC的所有ComMUser都请求“No Communication”；
  • 通道通过参数ComMChannelPerPnc被PNC引用；

配置同步PNC关闭且ECU作为该PNC的顶层PNC协调器，每次释放PNC时，必须在受影响的
ComMChannels上发送PN关闭消息。因此，ComM为被分配到该PNC的每个ComMChannel调用
Nm_RequestSynchronizedPncShutdown，将关于释放PNC的检测的PNC位向量转发给NmIf。
NmIf将调用转发到受影响的< Bus>Nm。PN关闭消息在< Bus > Nm_Mainfunction中发送。

• 在子状态COMM_PNC_REQUESTED，如果ComM0PncVectorAvoidance设置为TRUE，且在通过参数 ComMChannelPerPnc引用的 ComMChannel 上计算的IRA中所有PNC位设为0，ComM释放ComMChannel。只要该IRA中存在一个PNC位变为1，ComM应再次请求这个ComMChannel。

只要远程请求PNC(即分配给该PNC的ERAn中至少有一个PNC位等于“1”)，并且配置开关
ComMPncGatewayEnabled设置为TRUE，则COMM_PNC_REQUESTED将是当前的PNC目标状态。

进入PNC子状态COMM_PNC_READY_SLEEP时

• 当从PNC子状态COMM_PNC_REQUESTED进入PNC子状态COMM_PNC_READY_SLEEP时，IRA中代表该PNC的PNC位应设置为0，且应调用Nm_UpdateIRA(<channel>, <IRA>)将聚合的内部PNC请求转发到被该PNC引用的每个通道。
• 当从PNC子状态COMM_PNC_REQUESTED进入PNC子状态COMM_PNC_READY_SLEEP时，ComM将为该PNC通过 ComMChannelPerPnc引用的ComM通道释放COMM_FULL_COMMUNICATION请求。

在PNC子状态COMM_PNC_READY_SLEEP的行为

只要PNC被请求(即在EIRA内代表该PNC的PNC位等于“1”)，并且没有分配给该PNC的ComMUser请求“Full Communication”，COMM_PNC_READY_SLEEP将是当前状态。

• 如果PNC被释放(即EIRA内代表该PNC的PNC位等于“0”)，应离开子状态COMM_PNC_READY_SLEEP，进入子状态COMM_PNC_PREPARE_SLEEP。
• 如果分配给此PNC的至少一个ComMUser请求“Full Communication”,则应离开子状态COMM_PNC_READY_SLEEP，并进入子状态COMM_PNC_REQUESTED。

PNC网关相关要求

• 当处于子状态COMM_PNC_READY_SLEEP时，ERAn中代表该PNC的至少一个PNC位变为‘1 ’,应离开子状态COMM_PNC_READY_SLEEP，并应进入子状态COMM_PNC_REQUESTED，当满足以下条件时：
  • 参数ComMPncGatewayEnabled设置为TRUE；
  • 该PNC通过参数ComMChannelPerPnc引用至少一个通道，且通道属性ComMPncGatewayType 有设置；

进入PNC子状态COMM_PNC_PREPARE_SLEEP时

• 进入PNC子状态COMM_PNC_PREPARE_SLEEP，定时器ComMPncPrepareSleepTimer将启动，倒计时初始值为配置值。

在PNC子状态COMM_PNC_PREPARE_SLEEP的行为

只要定时器 ComMPncPrepareSleepTimer在运行，ComMUser，EIRA或ERAn没有改变发生，COMM_PNC_PREPARE_SLEEP就是当前状态。

• 当定时器ComMPncPrepareSleepTimer超时，将离开PNC子状态COMM_PNC_PREPARE_SLEEP，进入PNC主状态COMM_PNC_NO_COMMUNICATION。
• 当在PNC子状态COMM_PNC_PREPARE_SLEEP时，分配到该PNC的ComMUser中至少一个请求“Full Communication”，那么将离开COMM_PNC_PREPARE_SLEEP，定时器ComMPncPrepareSleepTimer停止，进入PNC子状态COMM_PNC_REQUESTED。
• 当在PNC子状态COMM_PNC_PREPARE_SLEEP时，EIRA中代表该PNC的PNC位变为1，且该PNC通过参数ComMChannelPerPnc引用至少一个通道，那么应离开PNC子状态
  COMM_PNC_PREPARE_SLEEP，定时器ComMPncPrepareSleepTimer停止，进入PNC子状态COMM_PNC_READY_SLEEP 。

PNC网关相关要求

• 当在PNC子状态COMM_PNC_PREPARE_SLEEP时，ERAn中至少一个代表该PNC的PNC位变为1，那么应离开PNC子状态
  COMM_PNC_PREPARE_SLEEP，进入PNC子状态COMM_PNC_READY_SLEEP ，定时器ComMPncPrepareSleepTimer停止。在以下条件下：
  • 参数ComMPncGatewayEnabled设置为TRUE；
  • 该PNC通过参数ComMChannelPerPnc引用至少一个通道，且通道属性ComMPncGatewayType有设置；

PNC 网关

PNC网关功能用于跨越总线/通信信道边界的(逻辑)PNC，从一个总线/网络路由PNC请求到其他上(因此，对于存在的PNC网关，它需要连接到多个物理通道)。
为此，PNC网关配置包含了每个PNC的信息，PNC物理通道被要求到达PNC的所有成员（PNC-to-channel-mapping），如下图所示。

PNC网关从其多个活动通道收集PNC请求（其被称为主动的，因为如果需要的话，它主动地使它们保持清醒）并聚合它们。PNC网关将网络上的PNC状态的聚合发送到它的所有激活通道，从而使所有节点对全局PNC状态上，具有与网关一样的视角。
如果PNC网关不是网络层次结构中最顶层的PNC网关，PNC网关还会将所有下级节点的聚合PNC请求状态，加上其自己的内部请求状态，发送到其上级PNC协调器，该协调器通过所谓的“被动”通道连接。
上级PNC协调器将汇总下级协调器的PNC请求状态，因此顶层协调器将知道网络中所有活动的PNC请求，并将该信息发送给下级节点。
下级PNC协调器将在它们的被动信道上接收的PNC请求信息转发到它们的主动信道，以将顶层协调器的PNC请求状态的整体视图分发给逻辑层级中的所有叶节点，因此系统中的每个节点都在关于PNC请求状态的信息上保持一致。

PNC协调器决不能聚集和发送回其通过被动通道接收的信息，以免产生“幻像PNC请求”的无限镜像循环。

PNC到通道的映射由配置静态提供。此外，可选特性动态的PNC到通道映射可用于在运行时扩展PNC到通道的映射。

非协调PNC分配到多通道的支持

如果PNCs被分配到不同的ComMChannels，且这些ComMChannels不被PNC网关协调，那么网络拓扑和通信设计必须保证受影响ComMChannels能够及时地在同一时间被请求和释放。如果使用PNC，应用不关心ComMChannel状态，此外，对于这个用例，ComM也不会关心ComMChannel状态，因为这些ComMChannel的PNC协调没有执行。或者换句话说，如果PNC被请求(被动地),那么所有引用的ComMChannels也将被请求(被动地),因为应用程序期望分配给该PNC的所有ComMChannels驻留在COMM_FULL_COMMUNICATION中。下图所示为一个PNC网关（Node2）不带协调ComMChannels的例子。

主动PNC网关

系统通道上的主动PNC网关，应是系统通道上最后一个释放PNC的节点。如果一个PNC的PNC位在所有ERAn中都为零，则表明除了PNC网关之外，没有其他节点正在请求PNC。

被动PNC网关

被动的协调通道仅存在于当它们被连接到多个PNC网关的情形。如果ComM使能PNC网关功能（ComMPncGatewayEnabled设置为TRUE），映射到该PNC的ComM通道可设置为主动或被动模式（COMM_GATEWAY_TYPE_ACTIVE或COMM_GATEWAY_TYPE_PASSIVE）。如果一个ComM的通道映射到两个不同的PNC，那么只有一个网关主动协调这个通道，其他网关被动协调这个通道。这意味着，PNC网关总是至少映射到一个ComM的主动通道，并且可以映射到一个或多个ComM的被动通道。如果一个本地ComM user请求PNC或源自被动PNC网关的主动协调系统通道的ERA中至少一个PNC位不等于0，PNC网关请求PNC。

PNC同步关闭

PN拓扑总是反应分层架构拓扑，顶层PNC协调器处于最高层，在子层是多个中间PNC协调器和PNC叶节点。下图为一个反映了结构分层的PN拓扑示例：

上图所示PNC-Coor1为顶层PNC协调器，PNC-Coor2为中间PNC协调器，Node1和Node2作为PNC页节点，处于PN拓扑的最底层。例如，若Node1请求PNC1，那么该PNC请求通过PN传播到顶层PNC协调器。顶层PNC协调器“接管”PNC请求，并确保PNC请求发布到整个PN中。因此，顶层协调器会将PNC请求在通道1（PNC-Coor1.Ch1）上“镜像反射”回去，并且将该PNC请求转发到通道2。如果Node1释放PNC1，并且网络上没有其他ECU请求PNC1，Node1将仍然从顶层PNC协调器接收请求PNC1的Nm报文。对PNC叶节点的释放不立即在PN拓扑上转发，从PNC叶节点到顶层PNC协调器。PNC的释放由每个PN拓扑层的PN reset定时器延时，如果顶层PNC协调器检测到某个PNC的PN reset定时器超时，网络上也没有其他ECU请求该PNC。顶层PNC协调器复位所释放的PNC的PN reset定时器，并且发送PNC关闭消息，以保证所有PN层，从顶层PNC协调器往下到PNC叶节点， PNC几乎同步地关闭。中间PNC协调器收到PNC关闭消息后立即反应，因此中间PNC协调器释放指示的PNC，复位PN reset定时器，并在所有分配到受影响的PNC的主动ComM通道上转发PN关闭的消息。因此，几乎同一时刻，从顶层PNC协调器到PNC叶节点的所有PN层上的已释放PNC的所有PNC状态机驻留在COMM_PNC_READY_SLEEP中，并且复位相应的PN reset定时器。这样保证几乎同步的PNC关闭，以避免在应用层的超时。
参考AUTOSAR_SWS_COMMManager.pdf 图17和图18分别描述了在PNC同步关闭时，顶层PNC协调器和中间PNC协调器的行为。
注意：

• 为单向PNC配置的ComMChannel不会执行同步PNC关闭；
• 引用ComMChannel配置参数ComMChannelPerTxOnlyPnc的PNC，不执行同步PNC关闭；

多顶层PNC协调器的支持

PN拓扑总是至少存在一个顶层PNC协调器。如果所有被分配到特定PNC的通信信道都将ComMPncGatewayType设置为GATEWAYE_TYPE_ACTIVE，则该特定的PNC为顶层PNC协调器。因此，针对不同的PNC，可能存在不同的顶层PNC协调器。但是针对同一个PNC，它仅支持有一个顶层PNC协调器。多顶层PNC协调器的PN拓扑，必须要保证严格的PNC区分。下图所示为一个多顶层PNC协调器的PN拓扑：
上图中，PNC-Coor1作为PNC1和PNC2的顶层协调器。PNC3-Coor3作为PNC3的顶层协调器。因此，如果同步PNC关闭使能，PNC-Coor1负责发起PNC1和PNC2的同步PNC关闭。PNC-Coor3负责发起PNC3的同步PNC关闭。

动态PNC-to-channel-mapping(可选)

该功能使得可以在运行时更新PNC网关的PNC-to-channel-mapping。更新是通过所有参与的节点的request-response的学习过程完成的。当Nm PDUs请求Partial Network 学习，所有参与的节点将在相应通道上返回它们当前的PNC关系，然后PNC网关更新当前的PNC-to-channel-mapping。
如果PNC引用的通道中存在ComMChannelPerTxOnlyPnc属性的通道，那么动态PNC-to-channel-mapping功能不可用。
如果在一个通道上调用了函数ComM_Nm_PncLearningBitIndication，且该通道的ComMDynamicPncToChannelMappingEnabled设置为TRUE，或ComM在一个ComM通道上调用Nm_PnLearningRequest，ComM应该设置相应通道PNC学习阶段为激活状态。
如果ComMDynamicPncToChannelMappingEnabled设置为TRUE，函数ComM_Nm_RepeatMessageLeftIndication被调用后，ComM应设置相应通道PNC学习阶段为非激活状态。
如果ComMPncGatewayEnabled设置为TRUE，为一个通道调用函数ComM_Nm_PncLearningBitIndication后，应执行以下任一动作：

• 当通道ComMPncGatewayType设置为COMM_GATEWAY_TYPE_ACTIVE，ComM应通过调用Nm_PnLearningRequest，在所有协调的ComMDynamicPncToChannelMappingEnabled设置是TRUE的ComM通道（主动协调或被动协调）转发学习请求。
• 当通道ComMPncGatewayType设置为COMM_GATEWAY_TYPE_PASSIVE，ComM应通过调用Nm_PnLearningRequest，在ComMPncGatewayType设置为COMM_GATEWAY_TYPE_ACTIVE且ComMDynamicPncToChannelMappingEnabled设置为TRUE的ComM通道上转发学习请求。
  注意：PN学习位需要被转发到网络上的所有节点，但不需要被镜像回来，即使网络拓扑包含环。
  如果ComMPncGatewayEnabled和ComMPncDynamicMappingSupport都设置的是TRUE，且PNC学习阶段激活，ComM应该转发接收到的ERA Rx信息到ComMPncDynamicMappingEnabled设置是TRUE的通道。ComM应在所有其他ComMPncDynamicMappingEnabled设置为TRUE的通道上的所有受影响的ERAn中设置受影响的PNC位，考虑以下规则:
• ComMPncGatewayType设置为COMM_GATEWAY_TYPE_ACTIVE的通道上接收到Rx ERA，需要被转发到所有协调的通道上（主动协调或被动协调）；
• ComMPncGatewayType设置为COMM_GATEWAY_TYPE _PASSIVE的通道上接收到Rx ERA，需要被转发到ComMPncGatewayType设置为COMM_GATEWAY_TYPE_ACTIVE的通道上；

更新PNC-to-channel-mapping

PNC网关需要在运行时可以更新它的PNC-to-channel-mapping。如果ComMPncGatewayEnabled设置是TRUE，在 ComMDynamicPncToChannelMappingEnabled设置为TRUE的通道上，PNC学习激活且ERA中PNC位设置为1。ComM应在相应通道上为所有ComMPnc设置PNC-to-channel Mapping为1，相应的在ERA中相应的PNC位也设置为1。

PNC成员转发

在PNC学习阶段，每个参与的节点都必须发送当前的PNC成员。PNC网关还需要额外转发从其他通道接受到的PNC成员信息。
如果ComMPncGatewayEnabled设置为FALSE，且PNC学习阶段激活，ComM应在带有当前PNC成员信息的IRA中设置相应的PNC位，并为ComMDynamicPncToChannelMappingEnabled设置为TRUE的所有ComM通道调用Nm_UpdateIRA(, )。
如果ComMPncGatewayEnabled设置为TRUE，当PNC学习激活，ComM应为所有ComMDynamicPncToChannelMappingEnabled设置为TRUE的ComM通道调用函数Nm_UpdateIRA(, )，使用带当前PNC成员信息的IRA集合，并且组合了需要被转发的PNC信息。

ComM通道状态机

如果PNC功能打开，所有PNC动作应该在通道相关动作执行前执行。如果参数ComMPncNmRequest设置为TRUE，当由于PNC状态机进入COMM_PNC_REQUESTED请求“FULL Communication”时，应该调用API NM_NetworkRequest()，即使当前状态已经处于“Full Communication”。
ComM状态机包含三个主状态，对应通信模式：

• COMM_NO_COMMUNICATION
• COMM_SILENT_COMMUNICATION
• COMM_FULL_COMMUNICATION
  COMM_FULL_COMMUNICATION包含两个子状态：
  • COMM_FULL_COM_NETWORK_REQUESTED
  • COMM_FULL_COM_READY_SLEEP
    COMM_NO_COMMUNICATION包含两个子状态：
  • COMM_NO_COM_REQUEST_PENDING
  • COMM_NO_COM_NO_PENDING_REQUEST
    COMM_FULL_COM_READY_SLEEP 和 COMM_SILENT_COMMUNICATION对总线通信同步关闭是必须的。如果只有一个ECU通信关闭，总线上其他ECU会因为应用信号丢失而报错。
    主状态是对通道通信能力的抽象，专注于用户的兴趣（用户只在乎该通道是否具备通信能力）。子状态代表了中间状态，这些活动支持与外部伙伴同步关闭和管理协议。
    每个ComM通道的默认状态是COMM_NO_COMMUNICATION。若通道不是处在子状态COMM_NO_COM_REQUEST_PENDING，则ComM _ communication allowed(< channel >，FALSE)指示没有可见效果。除了初始化后的默认状态，主状态改变需要通过相应的提示通知到用户。请求通信模式COMM_FULL_COMMUNICATION_WITH_WAKEUP_REQUEST，ComM应该当作请求COMM_FULL_COMMUNICATION处理。

ComM的管理和被管理通道

一个ComM通道可以引用其他ComM通道，引用关系由ComMManageReference设置。ComMManageReference的源ComM通道称为“管理通道”，目标ComM通道称为“被管理通道”。管理通道可以引用0-n个被管理通道，被管理通道只能被一个管理通道引用。一个应用的场景是：管理通道处理与NM的交互，被管理通道不带NM功能。但需要注意以下几点：

• 管理通道的ComMNmVariant要设置为FULL；
• 被管理通道的ComMNmVariant设置为LIGHT，因为管理通道负责与NM通道交互；
• 被管理通道的ComMPncGatewayType既不能是COMM_GATEWAY_TYPE_ACTIVE也不能是COMM_GATEWAY_TYPE_PASSIVE。

在状态COMM_NO_COMMUNICATION下的行为

在进入COMM_NO_COMMUNICATION时，ComM通道状态机应该进入子状态COMM_NO_COM_NO_PENDING_REQUEST。初始化后进入COMM_NO_COMMUNICATION时，ComM不通知（通过RTE或BswM，此时RTE其实也是没有完成初始化）用户状态改变。在进入COMM_NO_COMMUNICATION状态时，该ComM通道状态机会关闭该通道的报文接收和发送能力，通过请求。在参数配置ComMNmVariant=FULL的通道上，进入COMM_NO_COMMUNICATION时，ComM还需要调用Nm_NetworkRelease()请求释放网络。
注意：如果该通道曾经请求过NM（通过Nm_NetworkRequest or Nm_PassiveStartup），并且此时还未释放，那么就需要调用Nm_NetworkRelease()释放网络。

子状态COMM_NO_COM_NO_PENDING_REQUEST

在子状态COMM_NO_COM_NO_PENDING_REQUEST，用户请求COMM_FULL_COMMUNICATION，且不存在通信限制。ComM通道状态机应该立即进入子状态COMM_NO_COM_REQUEST_PENDING。
在子状态COMM_NO_COM_NO_PENDING_REQUEST中，参数ComM通道参数ComMNmVariant=FULL|LIGHT|NONE，DCM指示ComM_DCM_ActiveDiagnostic，ComM通道状态机应该立即进入子状态COMM_NO_COM_REQUEST_PENDING。
在激活的诊断会话期间，潜在的通信限制应暂时处于非激活状态。
诊断激活时，假设诊断测试仪保持总线唤醒，因此管理的通道不需要特殊处理。
如果在子状态COMM_NO_COM_NO_PENDING_REQUEST中，调用了函数ComM_EcuM_WakeUpIndication，而且参数ComMSynchronousWakeUp设置为FALSE，ComM应立即将所请求通道的状态机切换到COMM_NO_COM_REQUEST_PENDING。如果请求的通道是被管理通道，那么管理通道的状态机也应切换到COMM_NO_COM_REQUEST_PENDING状态。
在子状态COMM_NO_COM_NO_PENDING_REQUEST，NM模块通过函数ComM_Nm_RestartIndication()指示重启，ComM通道状态机应立即切换到状态COMM_NO_COM_REQUEST_PENDING。
进入状态COMM_FULL_COMMUNICATION后，ComM通道状态机立即切换到子状态COMM_FULL_COM_NETWORK_REQUESTED。如果没有User请求COMM_FULL_COMMUNICATION，进入子状态COMM_FULL_COM_READY_SLEEP。ComM模块ComMTMinFullComModeDuration定时器可以阻止在可能的用户请求发生前的系统初始化/启动时间段内，状态机在COMM_NO_COMMUNICATION和COMM_FULL_COMMUNICATION之间反复横跳。
如果在子状态COMM_NO_COM_NO_PENDING_REQUEST 中调用了ComM_EcuM_WakeUpIndication，参数ComMSynchronousWakeUp设置为TRUE，ComM应将所有ComM通道状态机切换到子状态COMM_NO_COM_REQUEST_PENDING。
如果在子状态COMM_NO_COM_NO_PENDING_REQUEST 中调用了ComM_EcuM_PNCWakeUpIndication()，参数ComMSynchronousWakeUp设置为FALSE，且ComMPncSupport设置为TRUE，ComM应将被该PNC所引用的ComM通道状态机切换到子状态COMM_NO_COM_REQUEST_PENDING。
如果在子状态COMM_NO_COM_NO_PENDING_REQUEST 中调用了ComM_EcuM_PNCWakeUpIndication()，参数ComMSynchronousWakeUp设置为TRUE，且ComMPncSupport设置为TRUE，ComM应将所有ComM通道状态机切换到子状态COMM_NO_COM_REQUEST_PENDING。

子状态COMM_NO_COM_REQUEST_PENDING

在子状态COMM_NO_COM_REQUEST_PENDING，ComM通道状态机评估其相应的CommunicationAllowedflag，如果为TRUE，ComM通道状态机立即进入状态
COMM_FULL_COMMUNICATION。
在子状态COMM_NO_COM_REQUEST_PENDING，且不再有任何有效的COMM_FULL_COMMUNICATION请求挂起，ComM状态机应切换回到子状态COMM_NO_COM_NO_PENDING_REQUEST。该场景的应用，如：由用户调用ComM_RequestComMode(,COMM_FULL_COMMUNICATION)或DCM通过ComM_DCM_ActiveDiagnostic()指示触发的请求进入COMM_NO_COM_REQUEST_PENDING，但现在通过ComM_RequestComMode(,COMM_NO_COMMUNICATION)或ComM_DCM_InactiveDiagnostic()取消了。

在状态COMM_SILENT_COMMUNICATION下的行为

在进入状态COMM_SILENT_COMMUNICATION，ComM通道状态机应关闭总线报文发送能力(保留接收能力)。这是通过ComM模块通过CanSM请求相应的通信模式实现（SM_RequestComMode(network:=<channel state machine’s network>, mode:= COMM_SILENT_COMMUNICATION)）。该模式的应用场景，如：NM模块协调shutdow时对应的prepare bus sleep模式。
在状态COMM_SILENT_COMMUNICATION，用户请求COMM_FULL_COMMUNICATION，且无通信限制时，ComM通道状态机应切换进入COMM_FULL_COMMUNICATION状态。
在状态COMM_SILENT_COMMUNICATION，配置参数ComMNmVariant=FULL|LIGHT|NONE，DCM指示ComM_DCM_ActiveDiagnostic，ComM通道状态机应切换进入COMM_FULL_COMMUNICATION状态。
当诊断激活会话时，潜在的通信限制应该被临时关闭。
在状态COMM_SILENT_COMMUNICATION，网络管理模块指示ComM_Nm_BusSleepMode()，ComM通道状态机应切花进入COMM_NO_COMMUNICATION状态。
在状态COMM_SILENT_COMMUNICATION，网络管理模块指示ComM_Nm_NetworkMode()，ComM通道状态机应切换进入COMM_FULL_COMMUNICATION状态的子状态COMM_FULL_COM_READY_SLEEP。

在COMM_FULL_COMMUNICATION状态下的行为

在进入COMM_FULL_COMMUNICATION时，没有指定子状态时，ComM通道状态机应进入其子状态COMM_FULL_COM_NETWORK_REQUESTED。
进入COMM_FULL_COMMUNICATION，ComM通道状态机打开报文接收和发送能力，其实现是ComM模块通过CanSM请求相应的通信模式:

• 如果请求COMM_FULL_COMMUNICATION通信模式，那么应调用SM_RequestComMode(network:=<channel state machine’s
  network>, mode:= COMM_FULL_COMMUNICATION)；
• 如果请求COMM_FULL_COMMUNICATION_WITH_WAKEUP_REQUEST通信模式，且ComM通道的ComMWakeupSleepRequestEnabled设置为TRUE，那么应调用SM_RequestComMode(network:=<channel state machine’s network>, mode:=COMM_FULL_COMMUNICATION_WITH_WAKEUP_REQUEST)；
• 如果请求COMM_FULL_COMMUNICATION_WITH_WAKEUP_REQUEST通信模式，且ComM通道的ComMWakeupSleepRequestEnabled设置为FALSE或不可用，那么应调用SM_RequestComMode(network:=<channel state machine’s network>, mode:= COMM_FULL_COMMUNICATION)；
  每当ComM通道被请求COMM_FULL_COMMUNICATION_WITH_WAKEUP_REQUEST且ComMWakeupSleepRequestEnabled为TRUE，ComM应该通过调用SM_RequestComMode(COMM_FULL_COMMUNICATION_WITH_WAKEUP_ _REQUEST)请求ComM通道的相应网络，即使该ComM通道已经处于COMM_FULL_COMMUNICATION。若ComMWakeupSleepRequestEnabled为FALSE或不可用，ComM忽略此请求。
  在COMM_FULL_COMMUNICATION状态，网络管理模块指示ComM_Nm_BusSleepMode()，ComM通道状态机应切换到COMM_NO_COMMUNICATION。
  在COMM_FULL_COMMUNICATION状态，且配置参数ComMNmVariant=SLAVE_ACTIVE | SLAVE_PASSIVE，总线状态管理器模块指示ComM_BusSm_BusSleepMode()，ComM通道状态机应切换到COMM_NO_COMMUNICATION。
  在COMM_FULL_COMMUNICATION状态，且配置参数ComMNmVariant= FULL|PASSIVE，网络管理器模块指示ComM_Nm_PrepareBusSleepMode()，ComM通道状态机应切换到COMM_SILENT_COMMUNICATION。

子状态COMM_FULL_COM_NETWORK_REQUESTED

从COMM_NO_COM_REQUEST_PENDING进入COMM_FULL_COM_NETWORK_REQUESTED，并且EcuM模块通过ComM_EcuM_WakeUpIndication()或ComM_EcuM_PNCWakeUpIndication() 指示唤醒，ComM模块应从NM模块请求Nm_PassiveStartup()。
如果指示的ComM通道是被管理通道，那么ComM模块应从NM模块请求Nm_PassiveStartup()。
进入COMM_FULL_COM_NETWORK_REQUESTED，且Nm模块已通过ComM_Nm_RestartIndication()指示重启，ComM模块应从网络管理请求Nm_PassiveStartup()。
进入COMM_FULL_COM_NETWORK_REQUESTED，且Nm模块已通过ComM_Nm_NetworkStartIndication()指示启动，ComM模块应从网络管理请求Nm_PassiveStartup()。
从其他状态或子状态进入COMM_FULL_COM_NETWORK_REQUESTED，若配置参数ComMNmVariant=FULL且一个用户已请求ComM_RequestComMode(,COMM_FULL_COMMUNICATION)，ComM模块应从网络管理为相应NM通道请求Nm_NetworkRequest()。
进入COMM_FULL_COM_NETWORK_REQUESTED，若配置参数ComMNmVariant=FULL且DCM已经指示ComM_DCM_ActiveDiagnostic()，ComM模块应从网络管理为相应NM通道请求Nm_NetworkRequest()。
在子状态COMM_FULL_COM_NETWORK_REQUESTED，且配置参数ComMNmVariant=LIGHT|NONE，当ComMTMinFullComModeDuration的定时器超时，且此时没有用户请求ComM_RequestComMode(,COMM_FULL_COMMUNICATION)，DCM也没指示 ComM_DCM_ActiveDiagnostic()，那么ComM通道状态机应切换到子状态COMM_FULL_COM_READY_SLEEP。
在子状态COMM_FULL_COM_NETWORK_REQUESTED，且配置参数ComMNmVariant=FULL，此时没有用户请求ComM_RequestComMode(,COMM_FULL_COMMUNICATION)，DCM也没指示 ComM_DCM_ActiveDiagnostic()，那么ComM通道状态机应切换到子状态COMM_FULL_COM_READY_SLEEP。
在子状态COMM_FULL_COM_NETWORK_REQUESTED，且配置参数ComMNmVariant= SLAVE_ACTIVE，没用户请求ComM_RequestComMode(,COMM_FULL_COMMUNICATION)，那么ComM通道状态机应切换到子状态COMM_FULL_COM_READY_SLEEP。
在子状态COMM_FULL_COM_NETWORK_REQUESTED，且配置参数ComMNmVariant= PASSIVE | SLAVE_PASSIVE，那么ComM通道状态机应切换到子状态COMM_FULL_COM_READY_SLEEP。
在子状态COMM_FULL_COM_NETWORK_REQUESTED，且DCM也没指示 ComM_DCM_ActiveDiagnostic()，且请求了通信限制，那么ComM通道状态机应立即切换到子状态COMM_FULL_COM_READY_SLEEP，并取消ComMTMinFullComModeDuration的定时器。

子状态COMM_FULL_COM_READY_SLEEP

在进入子状态COMM_FULL_COM_READY_SLEEP，且配置参数ComMNmVariant=FULL时，ComM模块应从网络管理为相应的NM通道请求Nm_NetworkRelease()。
在进入子状态COMM_FULL_COM_READY_SLEEP，且配置参数ComMNmVariant=LIGHT时，应启动ComMNmLightTimeout定时器。
在子状态COMM_FULL_COM_READY_SLEEP，且配置参数ComMNmVariant=LIGHT，该通道没有pnc关系（ComMPncSupport设置为FALSE或该ComMChannel没被PNC引用），且ComMNmLightTimeout定时器超时，ComM通道寄存器应切换到状态COMM_NO_COMMUNICATION。
在子状态COMM_FULL_COM_READY_SLEEP，且配置参数ComMNmVariant=LIGHT，该ComMChannel被一个PNC引用，且ComMNmLightTimeout定时器超时，当所有引用的PNCs进入到COMM_NO_COMMUNICATION时，ComM通道也切换到COMM_NO_COMMUNICATION。
在子状态COMM_FULL_COM_READY_SLEEP，配置参数ComMNmVariant=LIGHT，这个ComMChannel扮演角色为被管理通道，而且被一个管理通道引用，但是没被任何PNC引用，当定时器ComMNmLightTimeout超时，只要引用它的ComMChannel转换到COMM_PNC_NO_COMMUNICATION状态，那么这个通道的ComM状态应切换到状态COMM_NO_COMMUNICATION。
在子状态COMM_FULL_COM_READY_SLEEP，配置参数ComMBusType=COMM_BUS_TYPE_INTERNAL，ComM通道状态应立即切换到COMM_NO_COMMUNICATION。
在子状态COMM_FULL_COM_READY_SLEEP，用户请求COMM_FULL_COMMUNICATION，当不存在通信限制时，ComM通道状态机应立即切换到子状态COMM_FULL_COM_NETWORK_REQUESTED。
在子状态COMM_FULL_COM_READY_SLEEP，配置参数ComMNmVariant=FULL|LIGHT|NONE，DCM指示ComM_DCM_ActiveDiagnostic，ComM通道状态机应切换到子状态COMM_FULL_COM_NETWORK_REQUESTED。
（诊断激活时通信限制会被暂时关闭）

ComM User到PNC的关系

在存在多个Channel的系统上，每个ComMUser可以被分配到一个或多个channel上，通过参数ComMUserPerChannel；
在存在多个PNC的系统上，ComMUser可以分配到一个或多个PNC，通过参数ComMUserPerPnc；
一个或多个PNC可以映射到一个或多个ComMChannel，通过参数ComMChannelPerPnc或ComMChannelPerTxOnlyPnc，其中ComMChannel的ComMNmVariants必须时FULL或LIGHT（LIGHT是被管理通道的属性，当被管理通道被关联到某个PNC时，其相应的管理通道（FULL）也要被关联到该PNC）。
被PNC引用的ComMChannel，禁止再被该PNC的ComMUser直接引用。
ComMChannel的ComMNmVariant= SLAVE_PASSIVE时，该通道不允许被任何ComMUser或PNC引用。ComMNmVariant= SLAVE_PASSIVE的通道应总是跟随其master的通信请求，不允许请求其master唤醒通信通道。

扩展功能

这里描述的扩展功能是根据项目具体情况，在运行时实施的特有的配置（如：使能唤醒抑制，但不强制No Communication）。在运行时，为了应对不断变换的条件，需要唤醒抑制/通信限制策略。如通过诊断改变唤醒抑制。

通信抑制

• 模式抑制的目的是限制通信能力；
• 以下是与模式抑制相关的参数以及函数调用：
  • ComMNoCom ： 模式抑制（限制到NoCom）的“请求位”，当ComMEcuGroupClassification使能该功能后，可由ComM_LimitChannelToNoComMode()和ComM_LimitECUToNoComMode()控制。
  • ComMNoWakeup：模式抑制（唤醒抑制）的请求位，当ComMEcuGroupClassification使能该功能后，可由ComM_PreventWakeUp()控制。
  • ComMEcuGroupClassification：模式抑制行为的“掩码位”，可由ComM_SetECUGroupClassification()控制，而无论ComMNoCom和ComMNoWakeup为何值。
    ComM提供请求何释放相应模式抑制的接口，ComM不关心谁请求模式抑制，但不能是一个普通的SWC，应该是一个特权SW-C或者OEM特定的BSW。
    每个通道上，模式抑制使能或关闭是相互独立的。ComM储存用户请求的状态。在模式抑制期间，若用户释放了请求，ComM应储存更新后的该用户请求。
    ComM提供存储Full Communication抑制的计数器，用于存放由于抑制通信而导致没有实现的COMM_FULL_COMMUNICATION的请求次数。计数器范围0-65535，储存在non-volatile内存，当计数器达到最大值后，停止计数。ComM可通过API读取或重置计数器。通过诊断服务也应可以读取和复位计数器的当前状态。

总线唤醒抑制

在ComM中，总线唤醒抑制是指ComM模块应采取预防措施，防止通过通信唤醒其他ECUs。唤醒抑制的实施其实就是忽略用户请求，忽略用户请求，意思就是会接收请求，但是不执行请求。当模式抑制接触后，“最高者赢”的策略会立即生效。
当通道的ComM抑制状态为ComMNoWakeup，用户的COMM_FULL_COMMUNICATION通信请求将会被抑制，而通道的状态将是COMM_NO_COMMUNICATION 或 COMM_SILENT_COMMUNICATION。
注意当通道已经处于Active状态时，设置通道的抑制状态，则不会激活（执行）通道抑制。ComM模块永远不能抑制“passive wake-up”的能力。必须保持总能对EcuM指示的总线唤醒的响应。在COMM_NO_COMMUNICATION模式，报文接收能力被关闭，但是是具备唤醒能力的。
ComMNoWakeup状态存储在非易失性内存，在启动时，在通信激活之前访问该储存的ComMNoWakeup状态决定通信抑制是否激活。

限制通信模式为COMM_NO_COMMUNICATION

若当前状态为COMM_FULL_COM_NETWORK_REQUESTED，且已经请求过模式限制到COMM_NO_COMMUNICATION。ComM模块应该切换到COMM_FULL_COM_READY_SLEEP，发起shutdown，而不管是否有用户请求COMM_FULL_COMMUNICATION。
强制进入COMM_NO_COMMUNICATION模式，需要关闭掉保持总线唤醒的软件组件。限制到COMM_NO_COMMUNICATION只有在通道被主动请求时才执行，在这种情况下，当前所有当前用户的Full Communication请求，甚至于新的请求，都将被忽略。但当ComM由于被动唤醒被远程保持唤醒，则限制到COMM_NO_COMMUNICATION的请求不会执行。
当调用函数ComM_LimitChannelToNoComMode()，ComM模块应为相应通道更新抑制状态（限制到COMM_NO_COMMUNICATION）。
每次请求限制到COMM_NO_COMMUNICATION，抑制状态的更新都必须进行，而不管当前状态是否会执行限制到的COMM_NO_COMMUNICATION状态（限制的动作是否执行？）。
如果ComMResetAfterForcingNoComm设置为TRUE，当ComM状态从COMM_FULL_COM_NETWORK_REQUESTED切换到COMM_FULL_COM_READY_SLEEP之后，被强制进入COMM_NO_COMMUNICATION，由于模式限制到COMM_NO_COMMUNICATION的请求，那么ComM应该调用BswM_ComM_InitiateReset()，调用该函数将触发ECU复位，复位操作执行要求尽快执行，具体却决于要做的动作(例如，存储所有NvM信息)。这么做的原因是因为，加入软件某个模块出现故障，不释放“Full Communication”的请求，持续地“Full Comunication”请求将导致通道在网络关闭和网络启动之间反复横跳，那么此种情况只能通过重启，让软件模块释放请求，实现限制模式到COMM_NO_COMMUNICATION。

总线通信管理

ComM使用CanSM相应的接口实现总线通信能力的控制。当配置ComMBusType = COMM_BUS_TYPE_INTERNAL 时，ComM将省略通信控制能力。

网络管理依赖

当ComMNmVariant = LIGHT | SLAVE_ACTIVE | SLAVE_PASSIVE | NONE 时，ComM模块不具备NM服务。
NM模块支持的Variant：
只有FULL和PASIVE时具有Autosar NM功能。

时序图

发送和接收启动（CAN)

下图所示为在CAN总线上启动发送和接收的时序图。在LIN，FlexRay，Ethernet上仅是API不同，时序一致。
### 被动唤醒（CAN）
下图所示为被EcuM模块或NM模块指示唤醒CAN通道后行为。在LIN，FlexRay，Ethernet上仅是API不同，时序一致。
### 网络关闭（CAN）
下图所示为CAN网络关闭行为。网络关闭可能来自于最后一个用户释放COMM_FULL_COMMUNICATION请求，或者来自于ComM_LimitChannelToNoComMode(…)被调用。在LIN，FlexRay，Ethernet上仅是API不同，时序一致。
### 通信请求
下图所示为在CAN总线上开始COMM_FULL_COMMUNICATION的行为。开启COMM_FULL_COMMUNICATION可能是因为用户请求COMM_FULL_COMMUNICATION，也可能是DCM指示ComM_DCM_ActiveDiagnostic。在LIN，FlexRay，Ethernet上仅是API不同，时序一致。

PNC同步关闭

下图所示为期望的时序，但并不一定是实现的（实际应用中根据实际配置会有区别）。下图是顶层PNC协调器检测到释放PNC，请求PNC同步关闭的时序图。
Request for a synchronized PNC shutdown in the role of a top-level PNC coordinator
(TLPC)
下图所示为中间PNC协调器接收到PN关闭消息，请求转发接收到的同步PNC关闭的行为：