AUTOSAR笔记：模式管理

目录

• 模式管理是什么？
• BswM
  • 概述
  • BswM执行流程
• EcuM
  • 上下电流程
    • 上电
    • 下电
    • 睡眠
• BswM配置
  • Ecu State Handling（ESH）
  • Module Initialization
  • Communication Control
• ComM
  • 内部唤醒
  • 外部唤醒
  • CanSM
  • 状态关联
• 手动模式管理
  • Mode Requester（MRqr）
  • Mode User(MUsr)
  • Mode Manager (MMgr)
  • Mode Declaration Group
  • Mode Switch Event
  • 小结
• 参考

模式管理是什么？

BSW层中，当满足一些规则（Rules）时，执行相应动作（Action），这就是模式管理.

每个ECU功能不太一样，底层BSW需根据应用需求做出相应实时调整，这个调整动作，我们称为 Action ；什么时候调整，我们称为 Rules.

例如，我们有个信号需要发送给别的ECU，目前有2路CAN：CAN BUS1，CAN BUS2. 信号是交替发送到2个总线上，即第一次发送到CAN BUS1，第二次发送到CAN BUS2.
此时，可用到模式管理：应用层在发送之前，发送该信号给Manager模块，Manager模块会根据应用层发送过来的信息，通过Rules判断是否需要进行模式变更（即执行相应Action），然后根据Action调用其他模块的一些动作，切换bus.

app request info -> manager - rules -  | -> action1 -> bus1
                                       | -> action2 -> bus2

常用概念：

• Mechanisms for notification: 通知机制. 比如，模式切换时发出通知，告诉我们需要被通知的地方，如某个应用层的SWC模式切换了

• Service requests for mode changes：应用层可主动请求一个模式切换

• Mode arbitration：模式仲裁. 判断当前状态是否满足Rules，是否需要进行模式切换

• Mode control：模式控制. 执行相应Action.

BswM

模式管理中，经常需要用到BswM、EcuM，ComM有时也会用到.

概述

BswM是一个基于Rules的服务模块，主要工作：根据Rules，执行相应Action.

BswM有3个Auto Configuration，是Davinci自动配置；有1个Miscellaneous 是用户自定义（通常不需要自定义）.

from ref. [1]

对Rules的评估，有两种形式：立即、延迟

• 立即：被call后，立马开始执行
• 延迟：被call后，需要执行到BswM_MainFunction()时，才开始执行，因此有延迟

BswM执行流程

以Ecu State Handling 中的InitToWakeup为例，

from ref. [1]

1. Rules中，可看到ESH_InitToWakeup规则，该规则需要一个表达式（Expressions），可在下面的Expressions中找到定义，也可以在下面红色方框内找到

当 ESH_State == ESH_INIT 时，即ECU处于初始化状态，也就满足了Rules条件

from ref. [1]

2. Rules下面，规则（Rules对应表达式）判断为真时，执行Action List（几个Action集合体）.

可以看出该Action List下，有3个Action：

from ref. [1]

3. 至此，BswM工作已完成，后面需要被调用的BswM模块响应模式切换

EcuM

EcuM有2类定义：Flexible（灵活的），Fixed（固定的）. 通常，使用Flexible，而Fixed一般会用在AUTOSAR 3.x上.

EcuM用于管理Ecu状态，Ecu状态一般是OFF, UP, SLEEP. 在这些大状态之间，又细分了很多小状态，如UP时，需要初始化BSW、OS、RTE等，对事件唤醒的处理.
EcuM主要用来管理EcuM的上下电、睡眠模式，与硬件/低功耗相关.

上下电流程

from ref. [1]

上电

from ref. [1]

上电与下电对应. 上电（Startup）主要分为4个阶段：

1. 上电（MCU启动流程）：由cstart.c引导代码，引导cpu跳入main()函数；然后，在main中做OS初始化准备（此时尚未启动OS，只是初始化）；

2. 预启动OS：进入EcuM_Init，做一些Error判断，然后启动OS；

3. 启动OS后：进入一个Task中，称为Init Task，会调用EcuM_StartupTwo()，执行SchM、BswM的初始化，并且通过BswM可将ADC、PORT等底层的驱动模块初始化

4. 启动BswM后：启动BswM后，完成Startup阶段，然后进入Rte_Start()，再进入UP阶段，即可以正常运行了

上电时序如下图所示：

from ref. [1]

下电

from ref. [1]

下电（shutdown） 也分为4个阶段：

1. BswM通知EcuM下电：调用关键函数EcuM_GoDown()后，就进入EcuM下电流程

2. 预关闭OS：做Deinit操作，然后进行下电设置，最后关闭OS

3. 关闭OS：调用ShutDownHook()，让用户处理关闭OS的一些定制工作

4. 关闭OS之后：根据不同下电需求（关机 or 重启），进入不同操作

下电时序如下图所示：

from ref. [1]

睡眠

工作在OFF挡电的ECU，需要进入睡眠模式，为了节省功耗.

睡眠（Sleep）有两种模式：Poll（轮训）, Halt（停止）. 睡眠与唤醒对应.

from ref. [1]

睡眠与唤醒：

1. 准备睡眠（GoSleep）：先使能唤醒，然后指定唤醒源当前的状态，最后GetResource，之后由EcuM接管.

时序如下：

2. 进入睡眠：睡眠有2种模式：

• Poll模式：先设置MCU状态Mcu_SetMode(ECUM_SLEEP...)，然后执行EcuM_Mainfunction，进入后激活唤醒源，然后不断检查是否被唤醒
• Halt模式：先设置Global Suspend，然后生成Ram Hash，接着设置MCU状态Mcu_SetMode(ECUM_HALT...)，然后Global Restore使得全局恢复. 如果在Halt下想要唤醒，需检查Ram Hash

3. 唤醒：先设置Mcu状态Mcu_SetMode(ECUM_NORMAL...)，然后禁止唤醒源，接着重启各类底层驱动，最后ReleaseResource，唤醒后由BswM接管.

时序如下：

BswM配置

通常，BswM自动配置足以，少数时候需要手动配置.

Ecu State Handling（ESH）

上电 UP流程：

Cfg会自动配置这些Rules、Action：

我们只需要勾上ESH中需要用到的选项即可. 勾选方式：

Module Initialization

OS启动后，在初始化BswM之后，由BswM对所有BSW中可管控模块进行初始化. 因此，Port、Dio等模块初始化，可以在这里配置勾选：

程序执行到 Module Initialization时，会自动调用Action Lists，如下图：

Action Lists可由用户配置，也可以调整顺序. 右边的User Code，用户可以添加C代码、include文件，会在生成代码时，加进去.

Module Initialization 与 Initialization 区别:

• Module Initialization: OS启动后，BswM初始化各BSW模块时，使用的初始化流程. OS启动后，进入Init Task，会在Task中初始化BswM和BSW各模块

• Initialization: OS启动前，初始化一些运行OS必要的初始化配置，一般是初始化Memory（Driver Init List 0）；还有一些底层驱动模块，如MCU模块、DIO模块、PORT模块等驱动，也可以放在这里（Driver Init List 1）.

Communication Control

依赖于EcuC> EcucPduCollection（如果没有，需要右键添加）

在这里勾选需要配置的模块

通信控制中，最基本的也是按照自动生成的Rules来处理的

ComM

ComM像一个通信的总开关，可以管住CAN、LIN、以太网等通信网络. 主要有3种状态：

• Full Communication（全通信）
• Silent（静默状态）
• No Communication（不通信）

ComM可通过NM（Network Manager，网络管理）保持网络的唤醒，也可通过SM（State Manager）激活通信.

下面通过2种唤醒源解释ComM状态机.

内部唤醒

1）当ComM初始化时，会先进入No Communication中，该状态下会不断循环判断有没有本地或远程的唤醒请求

2）如果循环中判断出本地通信请求API执行，则开始往Full Communication走（Allow 通道、让CanSM打开通信）

3）此时，NM会处于主动激活状态，快速发送一系列NM Message. 然后，进入Full Communication

4）进入Full Communication后，由于内部唤醒，首先进入Network Requested状态，执行正常的发送接收信息的状态，能一直主动保持Network的唤醒状态

5）一旦本地COM Mode释放后，则进入Ready State状态

6）如果此时其他ECU无需通信，Network进入Prepare Bus Sleep状态，ComM开始停止Tx IPDUs，不再发送数据，进入Slient状态

7）在Slient状态下，如果收到NM Message，则又回到Full Communication

8）在Slient状态下，如果没有收到NM Message，且此时收到NM Bus-Sleep的指示，则让CanSM去关闭通道，然后进入No Communication状态

外部唤醒

如果被外部唤醒，NM会进入被动状态（Passive）. 当ComM进入Full Communication后，默认进Ready Sleep状态，不会保持Network的唤醒状态.

CanSM

CanSM 管理ECU内部CAN节点状态.

NM 管理通信总线的状态，SM管理ECU本身通信节点的状态. CanSM针对ECU的CAN功能的状态管理（覆盖CanIf层），即可控制MCU内置CAN外设或外置CAN PHY的状态

状态关联

Ecu、Com、Network的状态图及其关系如下：

1. 只有当EcuM处于UP状态下，才能保持ComM的Full Communication状态和Slient状态
2. CanNM负责网络管理
3. ComM能全权负责本ECU通信状态，即管理SIM模块，但Network的状态不仅与本ECU有关，还与其他ECU有关，所以ComM对NM有一定的协调作用，而非全权管理

手动模式管理

前面讲模式管理时，用的是自动配置，而手动配置需要用到 Miscellaneous.

手动配置模式管理，需要涉及3个角色：

• Mode Requester：模式请求者
• Mode User：模式使用者（模式用户）
• Mode Manager：模式管理者（模式管理器）

它们会用到以下Ports：

Mode Requester（MRqr）

MRqr 对模式管理者（Mode Manager）请求一个模式切换，请求通过S/R接口实现，接口称之为 Mode Request PPorts.

MRqr可以是SWC，也可以是BSW，在一些BSW中没有S/R接口，可直接使用BswM_RequestMode()当接口

Mode User(MUsr)

MUsr 实现模式切换的对象，MUsr在收到一个 Mode Switch RPorts 的切换指令后，可以开始做一个模式切换.

模式使用者，通常也是模式请求者，所以一般也具有Mode Request PPorts. 模式切换分为5个阶段：Mode 1， On Exit（退出原模式），On Transition（模式切换），On Entry（进入新模式），Mode 2.

从On Exit到On Entry阶段，MUsr会处于模式失效状态.

Mode Manager (MMgr)

MMgr 根据Rules执行Action. MMgr 会收集其他模块的请求，然后根据rules判断是否能做模式切换.

如果可以，就告知相应模块进行切换. 收集其他模块的模式请求，用到了Mode Request RPorts；告知相应模块进行模式切换，用到了Mode Switch Ports.

Mode Declaration Group

Mode Declaration Group（模式声明组），以枚举形式定义模式，即给模式赋一个值，方便C语言用.

如我们的EcuM模块，用到了这几个模式：

Mode Switch Event

模式使用者在进行模式切换时，3种状态On Exit、On Transition、On Entry 能触发一个切换事件，该切换事件可以触发一个Runnable运行，从而实现切换过程中定制行为.

小结

模式管理本质是一个状态机，允许在同一个状态下，能进行一系列相关性操作，例如，LED亮灭，按键消抖. 因为有些操作无法立即返回结果，必须等待一段时间.

参考

[1] AutoSAR入门到精通系列讲解