1、概述

1.1、总览

1.2、功能描述

1.3、依赖关系

2、功能SPEC

2.1、PNC

2.2、通道状态机

2.3、时序图解析

3、COMM工具配置

3.1、ComMGeneral

3.2、ComMConfigSet

1、概述

1.1、总览

ComM的全程是Communication Manager 管理通信，是BSW里面的一个组件，位于AUTOSAR的系统服务层，组件位置如下图。

作为一个资源管理者，ComM封装了下层的通信服务，ComM控制通信相关的BSW模块，但不会去控制SWC或Runnable，ComM与USER用户直接交互（USER：可以是直接下发指令给ComM的模块，也可以是BSWM、SWC、Runables），ComM对下而言主要通过xxxSM、Nm来实现通信控制，实现SM与NM的协同。

1.2、功能描述

ComM模块的主要作用是：

1、简化用户对于总线通信协议的使用方式，包括简化的网络管理处理（这部分是不是可以人为ComM其实也有一定的网络管理作用呢？）

2、协调一个ECU上多个独立软件组件的总线通信栈的可用性(允许发送和接收信号)。

在上述情况里面，用户（user）无需知道硬件细节，例如应当使用哪个通道，只需要请求通信模式，ComM就会切换对应的通信通道状态。

3、提供API用以禁止信号的发送功能，防止主动唤醒总线上的其他ECU。

4、每一路Channel都有自己的状态机，ComM可以控制多个Channel，下文的配置里面会体现，将请求的通信模式给到CanSM\EthSM等，由CanSM\EthSM执行具体的操作，这点上文已经描述了ComM是一个资源管理者，不参与具体的执行操作，只是把指令下发下去。

每一路Channel都有自己的状态机程序体现。

配置体现

5、提供API强制让ECU进入No Communication状态

6、为请求的通信模式分配足够的资源，来简化资源管理，在用户请求Full Communication模式时，判断是否允许通信或者在通信状态下防止ECU进入shutdown状态。

7、另外，PNC扩展，也即“部分网络管理”，允许用户请求并将某一网络上被分到同一个逻辑分组的ECU保持唤醒状态, PNC gateway允许将不同物理总线和网络进行逻辑上的区分。

大体总结下来也就三个方面。

1、管理网络连接状态

ComM负责管理网络连接状态,当某个模块需要进行通信时,它会向 ComM 请求网络连接。ComM会根据当前网络状态和其他模块的请求情况，确定是否建立连接以及选择合适的连接方式。同时，如果整个系统的网络状态发生变化，ComM 也会及时通知其他模块,并做出相应处理。

2. 管理通信模式

Autosar-ComM 提供了多种通信模式，包括全通信、只收、只发、高速总线和低速总线等。ComM根据系统的实际需求和网络状况,选择合适的通信模式。例如,在电池电量不足的情况下，ComM 可能会将所有模块切换到“只收”模式，减少系统负担，延长电池寿命。

3.提供安全机制

Autosar-ComM 提供了一些安全机制，以确保系统数据安全和稳定性。例如，ComM 可以限制某些模块的网络访问权限，只允许授权的模块进行通信，防止非法侵入和数据泄露。同时，如果某个模块的通信异常，ComM 也可以及时发现并进行处理，避免整个系统受到影响。在实际应用中，Autosar-ComM 是非常重要的模块，其稳定性和可靠性直接关系到整个系统的运行效果和安全性。因此，开发人员应该重视 ComM 模块的设计和实现，尽可能减少通信故障和安全漏洞，为用户提供更好的使用体验和保障。同时，随着汽车电子系统的发展和进步, ComM模块的功能和性能也会不断地升级和完善,以满足用户对系统安全和稳定性的不断需求。

1.3、依赖关系

与AUTOSAR其他模块的依赖关系如下

RTE : 每个用户都可以请求一个通信模式。RTE将用户请求传播到ComM模块，并将ComM的通信模式指示传播给用户(此处一般是SM或者NM)。

EcuM :负责验证唤醒事件,然后发送指示到ComM, ComM切换到COM模式。ECU通讯的允许和关闭是由EcuM和BswM一起完成。（这点是存疑的，规范里面对这里其实并不是特别理解，之前的印象里面ECUM更侧重的是初始化）

BswM :配置Com相关的Action和Rules ,从而控制相关的通信,同时通信状态的改变也会报告给BswM ,在EcuM Flex下, BswM也会将Com允许通信的功能告诉ComM。

至于BSWM怎么去控制PDU Group呢？只需要在action list里面增加Com_IpduGroupControl此API的控制就好了。

NvM :负责处理与ComM相关的Nv Data操作。

注释:NVRAM管理器必须在上电或复位ECU后初始化。它必须在ComM之前初始化，因为当ComM初始化时，ComM假设NVRAM已经准备好使用，并且它可以回读非易失性配置数据。当ComM被去初始化时，它将非易失性数据写入NVRAM。

DCM：执行和诊断相关的ComM请求。作为一个user，DCM调度诊断PDUS通信到COMM_FULL_COMMUNICATION，为了不破坏分层结构，DCM不直接提供开始或者停止接口的，使用的是DCM_ActiveDiagnostic API。

xxxSM :包括了具体的通信媒介的状态管理，如CanSM,LINSM, EthSM, FrSM等，控制实际的总线状态，ComM请求xxxSM进行相关的状态转换，并传递到总线上。

NM：同步整个Ecu总线的开关。

Com :通过Com信号区分PNC的状态信息。DET：用于在开发中追溯ComM开发相关的错误。

2、功能SPEC

2.1、PNC

PNC的英文名：partial network cluster，个人的理解：某种条件下保持相同工作状态，且连接在同一个总线或者网关的ECU称之为一组PNC。

ComM为每个局部网络集群(PNC)实现一个状态机，以表示PNC的通信模式。每个PNC都有自己的状态。对于简单的映射，状态定义与ComM的状态相关。

ComM 可以请求与释放所有的PNC

系统通道节点上所有pnc的状态通过网管用户数据交换。

每个PNC在CAN和FlexRay上的NM用户数据的位向量内使用一个专用位。如果本节点的本地ComM用户请求PNC，则本节点将NM用户数据中对应的位置为1。如果不再要求PNC;节点将NM用户数据中相应的位置为0。总线nms为pnc收集和汇总NM用户数据，并通过COM信号向ComM提供COM位向量的状态。

工作项目里面没有使用PNC所以是关闭的

注意一下在AUTOSAR4.2.2里面最大支持56个PNC状态。

ComM 模块对每组 PN 定义了一组状态机，用于描述各 PN 组的状态、状态转移关系和状态转移动作。该状态机共包含 4 种状态，分别为：

1. PNC_NO_COMMUNICATION

2. PNC_PREPARE_SLEEP

3. PNC_READY_SLEEP

4. PNC_REQUESTED

状态机如下

观察状态切换图,可以看到上面出现了ERA, EIRA的字眼,无论是开启还是关闭ECU的通信功能,都是需要进行请求的,而这个请求则分为内部请求与外部请求,我们称之为External Internal Request Array,也即EIRA。每一个ECU都需要有EIRA,来根据部分网络活动进而切换IPdu Group的状态。至于ERA , External Requested Array ,它主要用于网关,仅收集外部PN请求的场景。网关会将外部PN请求镜像回请求总线,同时将这个请求发送到其他的总线上。IRA , Internal Requested Array ,代表ECU内部对于PNC状态的请求,既可以是SWC通过RTE直接请求ComM接口，或者在某种条件满足时，由BswM请求ComM接口。

系统上电后整个PNC的状态在PNC_NO_COMMUNICATION。

在PNC状态切换过程中如果是主动唤醒节点直接请求FULL通信,或者是网关节点控制的节点在收到网关下的ERA数组的相关状态位,直接从

PNC-NO-COMMUNICATION进入到PNC-REQUESTED阶段。如果是被动唤醒的节点,则根据接收到唤醒报文中的PNC位状态切换到PNC_READY_SLEEP或者PNC_PREPARE_SLEEP.而PNC_FULL_COMMUNICATION内部的三个子状态的切换也是根据该节电的是否能被动唤醒功能进行内部的状态切换,主要体现是主动唤醒下需要Request Full相关的操作以及NM报文中对应的UserData中相关的PNC位进行转换的。

总结一下可以让ComM的PNC状态机切换的事件可以来自于：

1.来自用户的请求 ComM_RequestComMode()函数调用

2. 来自 EcuM 模块的唤醒通知 ComM_EcuM_WakeUpIndication()

3. 来自 Com 模块的 PNC 值变化通知

4. ComM 模块内部定时器超时事件

注意点：PNC_READY_SLEEP（内部） PNC_PREPARE_SLEEP（外部）同样是准备进入休眠状态，但是来源是不一样的。

所有的PNC操作都应在执行通道相关操作之前执行

2.2、通道状态机

所有的PNC操作都应在执行通道相关操作之前执行

ComM只提供了三种不同的通信模式

1. COMM_NO_COMMUNICATION :系统上电后进入到COMM_NO_COMMUNICATION ,在该状态下具有下面两个子状态:COMM_NO_COM_NO_PENDING_REQUEST和COMM_NO_COM_REQUEST_PENDING

2. COMM-NO_COM-NO-PENDING-REQUEST :在初始化完成ComM后进入该状态,该状态下总线不能进行任何的通信活动,需要等待FULL_COM请求切换状态，请求可来源于：用户请求User Request; DCM Notification需要激活对应的通道；来自于EcuM或者NM的Passive WakeUp通知。

3. COMM_NO_COM_REQUEST_PENDING :收到FULL_COM请求后,会切换至COMM_NO_COM_REQUEST_PENDING状态，然后等待Communication Allowed的触发信号,只有"CommunicationAllowed=TRUE时"才能将通信模式转换为FULL_COM模式下进行数据通信，如果没有Allowed的使能，则对FULL_COM请求将不会被执行。

4. COMM_FULL_COMMUNICATION :离开NO_COM状态后，则进入COMM_FULL_COMMUNICATION状态，在该状态下总线可以进行正常的数据通信,其也有两个子状态: COMM_FULL_COM_NETWORK_REQUESTED和COMM_FULL_COM_READY_SLEEP。而这两个模式的切换则是会根据NmVariant的变化来变化,后面会对NmVariant进行介绍。

5. COMM_SILENT_COMMUNICATION :该状态主要用于支持NM的Sleep流程处理,是NM状态机的Prepare Sleep阶段,只有在NM进入到prepare Sleep模式下该状态才进入，表示仅仅在NM下才会出现此状态。

总结一下可以让ComM的Channel状态机切换的事件可以来自于：

1. 来自 User 的请求 ComM_RequestComMode()函数调用

2.来自Dcm 模块的 ComM_DCM_ActiveDiagnostic() 和ComM_DCM_InactiveDiagnostic()函数调用

当诊断仪与Dcm模块通信时,需要保证通道的正常可用状态,不能进入休眠。这时Dcm模块通过在适当的时机调用ComM模块的ComM_DCM_ActiveDiagnostic()来请求通道保持在FULL_COM状态。完成诊断通信后， Dcm模块再调用ComM_DCM_InactiveDiagnostic()接口释放对通道的使用。这时如果没有其他用户再使用该通道,则通道最终将进入NOCOM模式,通道关闭,所以在前面介绍Channel状态管理状态切换的时候就提到了Dcm模块是让ComM Channel状态切换的一个重要来源。

3. 来自 Nm 模块的网络状态通知 ComM_Nm_NetworkMode() 与ComM_Nm_PrepareBusSleepMode()和ComM_Nm_BusSleepMode()函数调用

4.来自Nm的ComM_Nm_RestartIndication()和ComM_Nm_NetworkStartindication()

5.来自EcuM 模块的唤醒通知 ComM_EcuM_WakeUplndication()当某个通信通道发生唤醒事件后, EcuM会调用ComM_Wakeuplndication()函数通知ComM模块。该通知会作为通道正常工作的一个触发源,将该通道状态切换到FULLCOM模式。这时ComM会调用网络管理模块的Nm-PassiveStartup()唤醒网络管理模块。

6. ComM模块内部定时器等

通信禁止包含两种情况：一是禁止唤醒总线，二是限制通信。在某些唤醒线路故障情况下，某些应用会错误地请求总线，从而错误地唤醒总线上其他ECU。这时可以通过调用ComM_PreventWakeUp()接口,忽略用户请求,从而避免系统错误。该功能称为禁止唤醒总线。该功能只在对应通道进入NO_COM或SILENT_COM时有效。当通道处于 FULL_COM 模式时 ,应用可以调用 ComM_LimitChannelToNoComMode()或 ComM_LimitECUToNoComMode()来强制某个通道或整个 ECU 所有通道进入 NO_COM模式。这时 ComM 将忽略 User 对通道的占用，调用 Nm_NetworkRelease（)释放网络管理。当远程休眠条件满足时,通道将最终进入 NO_COM模式。该功能称为限制通信。该功能只在对应通道处于FULL-COM时有效。

User\PNC\Channel三者关系如下图所示

每个User向下可以关联多个PNC,每个PNC向上也可以关联多个User, User既可以关联PNC也可以直接关联Channel,每个PNC向下可以关联多个Channel,每个Channel向上也可以关联多个PNC或User.但是同一Channel不能既关联User,又关联该User下的PNC。说得简单点就是自上而下，是交叉树状自上而下，用户想要控制一个一个总线接口，可以是User->PNC->Channel，也可以是User->Channel。

User 可以通过接口请求 FULLCOM 和 NOCOM 模式，此时所有该 User 映射的通道或 PNC 都会收到请求。由于一个通道或 PNC 可以映射多个User,因此只有当映射的所有User都请求了NOCOM时, ComM才会在该通道或PNC上释放通信能力,否则只要有一个User 请求 FULLCOM ,ComM 都会为该通道或 PNC 保持通信能力。

在某些特殊情况下,用户可以通过API限制某个通道或整个ECU的通信能力,这时即使有用户请求FULLCOM,该请求也会被暂时抑制。限制通信的优先级高于 User 对通道的请求。

DCM模块会使用某些通道作为诊断通道。它通过API激活该通道的通信能力。此时不论该通道映射的User请求何种模式,也不论该通道是否被限制通信,ComM 都会为该通道保持通信能力,也就是说 DCM 激活通道的优先级最高。

ComM 的一些配置状态和计数值可以保存到非易失存储器中，在下次上电后恢复。可以保存的内容包含：

1. ECU 所有通道的禁止唤醒总线状态( NoWakeup )

2. ECU 组分类（ EcuGroupClassification)

3.禁止计数器

当使能此功能时,需要在 NvM模块配置这几个 Block,且需要将其在 NvM模块中将这几个模块配置在ReadAll 和WriteAll 列表中,以便在上电时自动恢复数据，以及下电前自动保存数据。

2.3、时序图解析

下图是开始接收与发送时序图，其实很容易误解下面的图，下面的图含义是启动之前需要执行什么操作，有了西面这个时序才可以执行传输操作的。可以看到直接调用的是CANSM的API来执行操作的。

下图为被动唤醒时序图，目前的项目里面仅仅执行了此唤醒

网络shutdown时序图如下，这个图着重关注一下，在AUTOSAR4.2.2手册《AUTOSAR_SWS_COMManager.pdf》的P111

通讯请求时序图如下

3、COMM工具配置

由于项目尚未使用PNC功能，所以展示的配置项里面并没有PNC的配置项，且看且注意。

3.1、ComMGeneral

ComMDirectUserMapping：自动生成user

设置为true时，配置工具会根据ComMPnc和ComMChannel自动创建ComMUser。生成的ComMUsers的shortName应遵循以下命名约定:pncuser_commnld，例如PNCUser_13ChannelUser_ComMChannelld，例如ChannelUser_25 限制:由于此配置参数而创建的ComMUser不能被swc使用(仅对BswM可用)。

ComMEcuGroupClassification：定义模式抑制是否影响ECU。

000 没有模式抑制激活

001 唤醒抑制使能

依赖性:至少在唤醒抑制启用/允许的情况下，应该存储非易失性(在重置期间必须保持值)。可以在运行时使用ComM_SetECUGroupClassification()进行更改，因此默认值应该只设置一次(第一次ECU初始化)。

ComMModeLimitationEnabled：启用模式限制功能，上文有描述，能单独控制某一个Channel的。