简介

通信管理模块(COM Manager, 下称ComM)，是汽车开放系统架构AUTOSAR BSW中的一个模块。作为资源管理者，ComM封装了下层的通信服务。ComM控制通信相关的BSW模块，但不会去控制SWC或Runnable。ComM收集来自通信请求方（AUTOSAR中称之为User，后文会解释）的总线通信访问请求，然后来协调这些请求。

ComM模块的目的主要有：

• 简化用户对于总线通信协议栈的使用方式，包括简化后的网络管理处理。用户（即User，后文默认这两种说法代表同一个含义）不需要知道任何硬件细节，例如应当使用哪个channel。对于用户来说，只需要请求“通信模式”，ComM模块会切换对应的通信channel的开启或关闭。
• 提供API以禁用信号的发送功能，防止(主动)唤醒总线上其他汽车电子控制单元（ECU）。
• 每一路channel都有各自的状态机，ComM可以控制多个channel，将请求的通信模式给到CanSM, EthSM等，由它们来控制对应总线的状态。
• 提供API以强制让ECU进入No Communication的状态。
• 为请求的通信模式分配足够的资源，来简化资源管理。在用户请求Full Communication模式时，判断是否允许通信，或者在通信状态下防止ECU进入shutdown的状态。
• 另外，PNC扩展，也即“部分网络管理”，允许用户请求并将某一网络上被分到同一个逻辑分组的ECU保持唤醒状态，PNC gateway允许将不同物理总线和网络进行逻辑上的区分。

 

什么是“用户”

用户可以是BswM，runnable，(一个或一组)SWC，用户是来向ComM和各个State Manager模块请求的单一入口。

在用户当中，还有一个“系统用户”的概念，它只存在于ComM内部，用来做默认请求或者覆盖用户请求。

正常上电启动请求FULL_COMMUNICATION

在我们了解ComM完整的状态机之前，让我们先看看ECU正常上电启动后，是如何请求FULL COMMUNICATION的，这里以Elektrobit提供的demo作为示例，实际情况以项目需求为准。

当SWC初始化时，由于后续SWC中runnable有通信的需求，所以这里进行了ComM_RequestComMode的调用。

在这之后，你还需要Allow Communication，这个操作你可以通过函数调用的方式完成，例如：

也可以通过设置BswM Action的方式完成：

然后ComM模块会去调用CanSM_RequestComMode（如果是eth, flexray，则调对应eth和flexray的接口），让Can协议栈有收发消息的能力，返回OK的话，ComM就从刚才的No Communication进入到Full Com Network Requested状态了。

如果还加入了网络管理的功能，如果设置的NM Variant为Full，那么ComM还会调用CanNm_NetworkRequest接口，CanNm状态将由Bus Sleep状态迁移到Network Mode。

再然后，CanNm调用ComM_Nm_NetworkMode()接口，通知ComM网络管理状态已经进入Network Mode。

当CanSM状态进入到CanSM_CommFullCommunication状态时，会调用ComM_BusSM_ModeIndication()进行通知。

完整时序图可以参考：

如果你现在对启动后通信上线的流程已经有所理解，让我们来看看状态机图，是一个什么样的状态迁移流程：

不知道你有没有发现，SWC初始化时调用的接口(void) Rte_Call_UR_ComMUser_0_RequestComMode(FULL_COMMUNICATION)只给了一个参数，那么是如何在调用时知道是操作的哪个用户呢？

ComM是提供ComM_CurrentMode的接口的，

当你创建了用户后，ComM还会生成PORT API OPTION，

这样就只需要将SWC的R-Port与ComM的P-Port连接起来，

这样的话SWC在实现阶段只需要关注期望的通信状态是什么，而无需关注具体是操作的哪个user，如果未来项目的需求有变化，也只需要修改ComM模块中用户使用了哪些channel，而不用改动SWC。

网络关闭

接下来我们再一起了解网络关闭的流程。

假设我们已经经过了上述流程进入到了Full Communication状态并且正常收发消息，在某一个时间节点我们不需要继续进行网络通信，并且请求了No Communication:

那么ComM首先需要进入到Ready Sleep模式，并调用Nm_NetworkRelease()，当Nm状态进入到Prepare BusSleep时会通知ComM，随后ComM进入到Silent Communication状态，ComM调用CanSM接口要求CanSM进入到Silent Communication状态。

当Nm进入到Bus Sleep状态，完全不进行任何消息的收发时，通知ComM状态已经切换，随后ComM进入No Communication状态，并要求CanSM也同步进入No Communication状态。

Passive Startup

主要区别是从No Com到Full Com的触发条件的细微差别，这里不详细说明了，截个流程图吧。

通信抑制

模式抑制的目的是限制通信能力，包括总线唤醒抑制以及No Communication限定模式。ComM模块提供相应API以进行对应抑制模式的请求。通信抑制对每一路通信都可以单独设置。

总线唤醒抑制

总线唤醒抑制，在ComM模块中的概念为应当预防启用通信而导致的唤醒其他ECU的情况。

例如传感器ECU发生故障时，可能会向总线发出非预期的消息而导致唤醒整个网络，在出现这种故障情况时，相应故障处理的SWC应当设置对应通信channel的唤醒抑制位，防止意外唤醒网络。

如果ComM的抑制状态ComMNoWakeup设置为True，用户是无法请求Full Communication的。

No Communication限定模式

当前状态为COMM_FULL_COM_NETWORK_REQUESTED，并且已经请求了No Communication限定模式，对应的channel会切换至Ready Sleep状态，准备进行shutdown，用户的Full Communication请求不会得到任何处理。

ComM模块提供的服务

总结上面已经提到的，ComM模块可以提供这些接口：

基于不同的使用场景，可以分别利用不同的接口。例如SWC仅仅需要知道ComM状态，那么只用ComM_CurrentMode接口就足够了。

如果还需要控制ComM状态，那么就需要ComM_RequestMode接口。

对于Channel Wakeup, Channel Limitation以及ECU Mode Limitation，一般用于SWC向BSW请求模式转换，然后BswM和ComM进行交互，设置Wakeup或者Limitation。

 

相关产品：

经典 AUTOSAR基础软件、汽车操作系统和量身定制的工具环境: EB tresos

 

下载评估版：

免费试用EB tresos配置符合 AUTOSAR 标准的软件（支持Infineon AURIX TC38XQ和Renesas RH850/F1KM）

 

相关培训：

AUTOSAR和软件架构培训

 

成功案例：

• 软件定义汽车：Elektrobit为大众ID. 提供全新车辆基础设施架构 
• Elektrobit的AUTOSAR以太网解决方案将增强版Super Cruise驾驶辅助技术引入全新款凯迪拉克Escalade

 

相关新闻：

• Elektrobit支持BlackBerry QNX OS构建基于HPC的车辆架构 
• Elektrobit为芯驰科技汽车 SoC 芯片提供 AUTOSAR 软件
• 黑芝麻智能宣布支持Elektrobit的AUTOSAR经典平台软件，打造更安全的自动驾驶解决方案