By using this site you agree to the use of cookies for analytics Learn More

案例研究 | ComM — Communication Manager 通信管理模块(Classic AUTOSAR基础知识)

案例研究 | ComM — Communication Manager 通信管理模块
(Classic AUTOSAR基础知识)

简介

通信管理模块(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中国团队的专家

专注于Classic AUTOSAR