---

前言

本文介绍CP AUTOSAR 架构下的BswM组件，基于S32K312芯片、Vector提供的CBD包，使用DaVinci Configurator、DaVinci Developer工具进行配置的经验。
BswM是实现BSW中车辆模式管理和应用模式管理概念部分的模块。
它的职责是根据简单的规则仲裁来自应用层SWC或其他BSW模块的模式请求，并根据仲裁结果执行操作。

---

一、BswM功能概述

BSW模式管理器的基本功能可以描述为两个不同的任务：模式仲裁和模式控制。
模式仲裁来自SW-Cs或BSW模块的模式请求或状态指示来触发仲裁决策。
‌模式控制根据仲裁结果执行模式切换动作，调用底层BSW模块接口完成状态变更。

（一）、术语

1、BSW
基础软件。

2、CDD
复杂驱动。

3、SWC / SW-C
软件组件。

4、RTE
实时环境。

（二）、模块依赖性

BswM是AUTOSAR系统的协调者，通过与多个模块的交互实现模式仲裁（Mode Arbitration）‌和模式控制（Mode Control）。

1、RTE‌
作为SW-C与BswM的桥梁，传递模式请求（Mode Requests）和模式切换通知（Mode Switch Notifications）。

2、EcuM - Flex
EcuM Flex可以将其唤醒源的状态指示给BswM。
BswM也可以接收来自SW-C或其他BSW模块的‌运行请求，设置EcuM-Flex的目标状态。

3、ComM
BswM处理ComM的通信模式请求（如启用/禁用通信），并通过ComM User控制通信状态。

4、COM
负责管理I-PDU组的启动/停止，复位信号初始化值，控制信号截止时间监控，并触发I-PDU传输。

5、PduR
控制PDU路由组的启用/禁用。

6、CanSM
来自CanSM的Mode Switch Indication通过BswM传给SWC。

7、LinSM
当需要切换LIN总线调度表时（例如从正常通信切换到低功耗调度），LinSM向BswM发起请求，同时‌，BswM控制COM模块启用或禁用与该调度表关联的I-PDU组。
当LinSM状态变化（如总线睡眠、唤醒），BswM接收其Mode Switch Indication‌通过RTE将模式变更通知传递给SWC。

8、LinTp
LinTp向BswM发起调度表切换请求，BswM根据规则切换至目标调度表，并同步启停关联的I-PDU组。

9、FrSM
FrSM检测总线状态变化（如冷启动完成、进入被动模式）后，通知 BswM，BswM将该状态通过RTE分发给相关SWC。

10、EthSM
EthSM检测到状态变化（如以太网链路断开或交换机端口异常），生成对应的Mode Switch Indication‌通知BswM，BswM根据预配置的仲裁规则，判断是否允许模式切换并决定执行哪些关联动作，将模式切换指示相应的SWC。

11、DCM
根据诊断请求（如禁用通信），BswM关闭相关I-PDU组和NM PDU。

12、J1939Dcm
J1939Dcm状态变化时，向BswM上报状态变更，BswM可通过调用J1939Dcm_SetState()接口强制切换J1939Dcm的状态。

13、J1939Nm
J1939Nm监测J1939总线网络状态，通过BswM_J1939Nm_StateChangeNotification()通知BswM。

14、J1939Rm
BswM通过J1939Rm_SetState()直接控制J1939Rm的状态。

15、NM Interface
控制NM通信的启用/禁用，响应唤醒事件。

16、NvM
通过回调函数监控NvM块状态，并触发启动时的全块读写操作。

17、OS
依赖操作系统的具体实现（如任务调度）。

18、Sd
接收Sd模块的状态指示（如服务可用性），并作为模式请求源触发仲裁。

（三）、BswM主要功能

BswM起到模块的调度作用，如EcuM、ComM、Dcm、Nvm等这几个互相之间都有联系和调用接口，那么就需要有一个中间件去统一调度执行，否则软件组件之间的解耦性会非常差，BswM其实就是根据输入的条件去执行相应的动作。

BswM功能有两部分分别是模式仲裁和模式控制，模式仲裁即判断输入条件决定要执行什么样的操作，模式控制即这个操作需要怎样执行。

模式仲裁基于配置好的规则，规则里大概描述了如下行为：
if(“输入条件”)
{
“相应动作”
}
else
{
“相应动作”
}

输入条件为一串逻辑表达式，例如：
if((模式条件)&&(模式条件))或
if(!(模式条件)&&(模式条件))或
if((模式条件)||(模式条件))或
if((模式条件)^(模式条件))

相应动作即模式控制，去执行一系列动作列表即BSW模块的动作或者Rte Switch。

模式条件是由模式请求（Mode Request）和模式指示（Mode Indication）为输入源去判断是否为配置好的条件模式，然后去评估是否为TRUE。判断条件为==或!=。
请求端口又分为BswMModeRequestPort和BswMEventRequestPort，BswMModeRequestPort是接口被调用后去评估是否为预期的值如果则为TRUE，BswMEventRequestPort是被调用评估结果立即为TRUE。

模式仲裁可以分为立即仲裁和延时仲裁，为立即仲裁时当模式条件发生变化则立即进行评估规则否则在下一个主循环里进行评估规则。
在vector代码里如果为立即模式，在仲裁期间执行了动作列表，然后动作列表执行后模式条件发生了变化不会进行下一次仲裁。

模式控制里的动作列表执行可以基于条件式和触发式来执行，触发式只有逻辑表达式评估结果为发生变化时即从TRUE变为FALSE或从FALSE变为TRUE才执行动作列表，条件式是只要满足TRUE或FALSE都会执行动作列表。

以下是Deferred和Immediate仲裁行为的序列图：

二、模式仲裁

（一）、仲裁规则、模式条件、逻辑表达式

模式仲裁基于规则（Rule），用于模式仲裁的规则在BswM的配置中进行指定。

仲裁规则是由一组模式请求条件组成的逻辑表达式。当输入模式请求（Mode Request）和模式指示（Mode Indication）发生变化时，或在BswM主函数执行期间，会对这些规则进行评估。评估结果（真或假）用于决定是否执行相应的模式控制动作列表。

构成模式仲裁规则的逻辑表达式可使用不同的运算符，如 AND（与）、OR（或）、XOR（异或）、NOT（非）和 NAND（与非）。表达式中的每个项对应一个模式请求条件。

如果模式条件引用了BswMModeRequestPort，该条件将验证所请求或指示的模式是否等于（EQUAL）或不等于（NOT_EQUAL）某个特定模式。

如果模式条件引用了BswMEventRequestPort，则条件将验证该请求端口是置位（SET）还是清除（CLEAR）。

BswMEventRequestPort的事件请求和BswMModeRequestPort不同之处在于请求方不会向BswM发送所请求的模式 / 值，因此，BswM没有要执行的模式条件。相反，BswM只需评估是否接收到该事件。
当请求方发送 / 调用该事件时，BswMEventRequestPort将处于置位（SET）状态。BswM随后可通过执行BswMClearEventRequest动作，将该BswMEventRequestPort置于清除（CLEAR）状态。下图展示了一个包含两个条件的规则示例：

以上图中MyModeRequestPort和ComMInitiateReset便是模式请求BswMModeRequestPort或BswMEventRequestPort，&&为逻辑表达式，模式规则为TRUE执行Execute the True Action List否则执行Execute the False Action List，
模式条件便是MODE_A和IS_SET。

当BswMModeCondition的BswMConditionType为BSWM_EVENT_IS_SET并引用BswMEventRequestPort时：
若BswMEventRequestPort处于置位（SET）状态，则此BswMModeCondition的评估结果应为TRUE。
若BswMEventRequestPort处于清除（CLEAR）状态，则此BswMModeCondition的评估结果应为FALSE。

当BswMModeCondition的BswMConditionType为BSWM_EVENT_IS_CLEARED并引用一个BswMEventRequestPort时：
若该BswMEventRequestPort处于置位（SET）状态，则此BswMModeCondition的评估结果应为FALSE。
若该BswMEventRequestPort处于清除（CLEAR）状态，则此BswMModeCondition的评估结果应为TRUE。

当BswM在一个已配置的BswMEventRequestPort上接收到一个事件时（例如ComM调用了BswM_ComM_InitiateReset()），该BswMEventRequestPort应被置于置位（SET）状态。

当对一个BswMEventRequestPort执行BswMClearEventRequest动作时，该BswMEventRequestPort应被置于清除（CLEAR）状态。

（二）、模式仲裁的要求

BswM接收模式请求（Mode Request）和模式指示（Mode Indication）作为模式仲裁的输入。模式请求通常源自应用层软件组件（SWCs），但也可能来自其他BSW模块，如Dcm。模式指示则始终由其他BSW模块发出，如XXSM和EcuM。本文说的模式仲裁请求既可以指模式指示，也可以指模式请求。

BswM应基于传入的模式请求执行模式仲裁。

BswM应基于传入的模式指示执行模式仲裁。

BswM应基于事件请求以及事件请求的清除操作执行模式仲裁。所有模式仲裁请求（包括请求和指示）在BswM中以相同方式处理。它们通过在BswMModeRequestSource配置容器中选择相应的模式条件类型进行配置。

BswM应使用配置的规则执行模式仲裁。

模式仲裁规则应可使用模块配置参数进行配置。

BswM不允许将先前仲裁规则的评估结果用作逻辑表达式的输入。

作为评估BswM仲裁规则的结果而调用的动作只能在动作列表的上下文中调用。

BswM应基于传入的模式切换通知执行模式仲裁。

模式仲裁的处理有两种不同的调度方式。它要么在模式请求 / 指示的上下文中立即进行，要么（以循环方式）延迟到BswM的主函数中进行。

模式仲裁规则可以包含即时和延迟模式仲裁请求的任意组合。

可以对BswM进行配置，以便在收到模式仲裁请求时立即执行模式仲裁。这是通过将BswMRequestProcessing配置参数（在BswMModeRequestPort容器内）设置为BSWM_IMMEDIATE来实现的。

BswM应仅在特定模式请求 / 指示的上下文中评估使用特定即时模式条件的模式仲裁规则。

应当能够将模式仲裁延迟到BswM的主函数执行时。这是通过将BswMRequestProcessing配置参数（在BswMModeRequestPort容器内）设置为BSWM_DEFERRED来配置的。

应当能够配置BswM，以便在设置事件时立即执行模式仲裁。这是通过将BswMEventRequestProcessing配置参数（在BswMEventRequestPort容器内）设置为BSWM_IMMEDIATE来配置的。

应当能够将模式仲裁延迟到BswM的主函数执行时。这是通过将BswMEventRequestProcessing配置参数（在BswMEventRequestPort容器内）设置为BSWM_DEFERRED来配置的。

所有使用至少一个延迟模式条件的规则应在BswM主函数的每次执行期间进行评估。

BswM应将在主函数处理期间收到的模式仲裁请求推迟到主函数执行结束。任何此类推迟的IMMEDIATE请求应在BswM主函数退出前直接处理。任何此类推迟的DEFERRED请求应在接下来的BswM主函数中处理。

BswM应将在处理IMMEDIATE请求期间收到的模式仲裁请求推迟到该IMMEDIATE请求处理完成。任何此类推迟的IMMEDIATE请求应在原IMMEDIATE请求处理后直接处理。任何此类推迟的IMMEDIATE请求应在接下来的BswM主函数中处理。

BswM的实现可以选择使用保护机制（例如互斥区域），以确保动作的执行或BswM主函数不会被任何其他任务（例如更高优先级的任务）中断。

关于端口 “更新” 的术语说明：任何模式请求端口都有一个关联的值 / 状态。更新端口意味着改变其值 / 状态。

BswM应在仲裁实际发生之前直接更新IMMEDIATE模式请求端口的值，而不是在模式请求端口被触发时更新。

BswM应在模式请求端口被触发时更新DEFERRED模式请求端口的值。

（三）、初始化后的仲裁行为

BswM初始化后的模式仲裁行为由配置容器BswMModeInitValue控制。在配置中，该参数需为每个BswMModeRequestPort单独配置。

如果容器BswMModeInitValue不存在，或者模式请求没有初始值，BswM会将相应的模式条件视为未定义状态，并且在相应的模式仲裁请求首次更新之前，不会将其用于模式仲裁。

BswM只会对逻辑表达式中不包含未定义模式条件的规则进行仲裁。初始化后，每个BswMModeRequestPort的初始值可由配置容器BswMModeInitValue控制。

如果定义了BswMModeInitValue，在BswM初始化时，应使用BswMBswModeInitValue或BswMCompuScaleModeValue来初始化相应的BswMModeRequestSource。对于单个BswMModeInitValue，如果同时包含BswMBswModeInitValue和BswMCompuScaleModeValue，BswM应拒绝该配置。在相应的模式仲裁请求更新之前，此初始值应用于仲裁规则。例如，每次调用BswM_RequestMode()时应更新通用请求模式。

在BswM初始化时，所有BswMEventRequestPort应初始化为清除（CLEAR）状态。

三、模式控制

BswM的模式控制部分会基于模式仲裁的结果执行所有必要的操作。这一操作是通过动作列表（Action List）来实现的。动作列表是当BswM被模式仲裁触发时执行的一个有序动作集合。

动作列表中的动作有三种类型：
1、对其他BSW模块或RTE的调用。
2、指向其他要包含在执行中的动作列表的链接。
3、模式仲裁规则。当相应的动作列表被执行时，这些规则将被评估。通过这种方式，可得到一个规则层次结构。

BswM无需存储其执行动作时其他BSW模块的特定返回值，也无需对这些返回值做出反应。因此，BSW中的不同状态管理器会向BswM指示它们当前的状态，这些状态将用作模式仲裁的输入。
不过，如果返回了E_NOT_OK，BswM可以发出一个Det Runtime Error，并且 / 或者取消当前正在执行的动作列表。

BswM可能包含多个动作列表，并且单个动作列表可以包含多个动作。为了减少动作列表的总数，可以对它们进行级联。动作列表中的元素可以是一个具体的动作、对另一个动作列表的引用，或者如上文所述，是一个由模式仲裁执行的规则。每个动作列表条目都应连接一个标志，用于说明其类型（动作 / 引用 / 规则）。包含具体动作的列表、包含引用的列表，甚至是混合列表，它们的激活方式不应有差异。

如下图展示了模式请求的最小处理周期：

1、模式请求发起
模式请求者SW-C通过其发送端口请求模式A。RTE分发该请求，BswM通过其接收端口接收请求。

2、规则评估
BswM根据以下两种情况执行其仲裁规则：
接收到模式仲裁请求时立即执行（即时处理）
在 BswM主函数执行期间执行（延迟处理）

3、动作列表执行
BswM根据选定的执行方法执行相应的动作列表。

4、模式切换通知
在执行动作列表时，BswM可能调用RTE的切换API，通知相关的SWC仲裁结果。任何SW-C（尤其是模式请求者）可注册接收模式切换指示。
模式请求者只能从本地BswM接收模式切换指示，即使请求源自不同ECU的本地代理软件组件也是如此。

（一）、模式控制的要求

BswM应通过在模式仲裁中规则评估结果来执行动作列表以进行模式控制。

对于模式仲裁的每个规则，BswM应能够根据规则评估为真或假来执行不同的动作列表。

动作列表包含一组BswM应按顺序执行的动作。

动作列表可能包含指向其他动作列表的链接，BswM应将其纳入执行范围。

动作列表还可能包含指向模式仲裁规则的链接，BswM应在当前动作列表的执行范围内评估这些规则。如果一个规则如之前所说被包含在动作列表中，那么由该规则评估所导致的任何动作列表的执行，BswM都应在继续执行原始动作列表之前完成。

如果使用串联动作列表（即使用对其他规则或动作列表的引用），动作列表结构最多可包含七层层次结构。此限制的目的是使BswM实现和生成工具的测试成为可能。该限制必须由生成工具进行检查。

与在模式仲裁请求上下文中评估的规则相关联的动作列表，BswM应在模式仲裁触发时立即执行，而不应延迟到主函数执行时，因为这样在必要时就能使模式请求的响应时间大幅缩短。

如果在模式仲裁期间，一个顶层动作列表由多个规则触发，这应导致在模式控制期间仅触发一次以执行该动作列表。顶层动作列表是指由顶层规则直接执行（即不是嵌套在动作列表内的规则）且不嵌套在其他动作列表中的动作列表。仅适用于顶层动作列表。不适用于嵌套规则和嵌套动作列表，因为它们在父动作列表中的顺序是用户定义的，应予以尊重。

如果在模式控制期间要执行多个顶层动作列表，执行顺序应从最高的BswMActionListPriority开始，一直到最低的。如果BswMActionListPriority相同，执行顺序是任意的。

对于非顶层动作列表，BswMActionListPriority应被忽略。

没有BswMActionListPriority的动作列表应被解释为其BswMActionListPriority等于0。

BswM应拒绝配置中BswMActionList包含具有相同BswMActionListItemIndexes的BswMActionListItems的情况。

在执行BswMActionList时：BswM应从具有最低BswMActionListItemIndex的BswMActionListItem开始执行。后续的BswMActionListItems应按其BswMActionListItemIndex递增的顺序执行。
在动作列表内，配置的BswMActionListItemIndexes不一定需要是连续的或从0开始。BswM将从具有最低索引的动作列表项开始执行，并继续执行到具有最高索引的项。如果索引存在 “间隙”（即不连续），这些间隙将被简单地忽略。
因为动作列表是一个有序列表，所以不允许在动作列表的上下文中配置具有相同BswMActionListItemIndexes的情况。

（二）、触发式和条件式动作列表

基于规则的评估，动作列表有两种执行方式：
1、每次规则评估结果符合条件时执行动作列表。（CONDITION条件式）
2、仅当规则评估结果与前一次评估结果不同时执行动作列表。（TRIGGER触发式）
动作列表的执行方式通过BswMActionListExecution参数（在BswMActionList容器内）进行配置。
然而，对于未被规则直接引用的嵌套动作列表，BswMActionListExecution参数（如BSWM_CONDITION或BSWM_TRIGGER）没有意义，且对嵌套动作列表的执行方式没有影响。这种未被规则直接引用的嵌套动作列表，会在其父动作列表执行时被执行。

如果为True动作列表配置了触发式执行，BswM应仅在相应规则的评估结果从False变为True时执行该动作列表。

如果为False动作列表配置了触发式执行，BswM应仅在相应规则的评估结果从True变为False时执行该动作列表。

如果为True动作列表配置了条件式执行，BswM应在相应规则评估为True时每次都执行该动作列表。

如果为False动作列表配置了条件式执行，BswM应在相应规则评估为False时每次都执行该动作列表。

如果某个动作返回E_NOT_OK，且相应的BswMAbortOnFail配置参数设置为 “true”，BswM应中止动作列表的执行。

（三）、可用的操作

在动作列表中可用的动作集合是预先设定好的，这样做的原因是为了简化ECU的配置以及生成BswM配置代码。

BswM应能够执行由配置容器BswMAvailableActions定义的预定义操作。

即使某个函数不在BswMAvailableActions中定义的标准化操作之列，BswM也应能够调用AUTOSAR BSW中的任何函数。

BswM应能够调用用户定义的函数。

用户定义函数的参数及其值应在ECU配置时使用BswMUserCallout配置容器进行定义。

（四）、初始化后的模式控制行为

BswM初始化后，模式控制的行为由BswMRuleInitState参数（位于BswMRule容器内）进行配置。该参数定义了在初始化后首次评估规则时，决定执行哪个动作列表所使用的 “先前评估结果” 。配置参数BswMActionListExecution（位于BswMActionList容器内）也会影响初始化后的动作列表执行。

在BswM初始化后首次对规则进行评估时，BswM应按照本表所述进行操作。注意：对于每条规则，True动作列表和False动作列表是可选的。

四、等待功能

有时需要推迟某些操作或等待进一步的模式控制，在BswM中添加了定时器处理功能。

一个定时器由作为BswMModeRequestSource的BswMTimer以及控制BswMTimer的Action组成。BswMTimer的值(例如BSWM_TIMER_STOPPED、BSWM_TIMER_STARTED、BSWM_TIMER_EXPIRED可以通过在BswM中配置的其他规则进行评估，以触发动作列表。没有外部接口用于控制或操作该计时器。

在初始化期间，每个BswMTimer应处于BSWM_TIMER_STOPPED。

动作BswMTimerAction BSWM_TIMER_START应该通过BswMTimerRef将所引用的BswMTimer重新设置为相应的定时器值，并将定时器的模式更改为BSWM_TIMER_STARTED。
定时器只能通过BswMTimerAction操作进行重新加载(无法实现自动重新加载)。

处于BSWM_TIMER_STARTED模式的每个BswMTimer应在BswM_MainFunction()执行期间递减定时器值。
BswMTimer的分辨率是BswM_MainFunction()周期的倍数。此外，BswMTimer的精度取决于BswM_MainFunction()的精度。

如果处于BSWM_TIMER_STARTED模式的BswMTimer到期，其模式应更改为BSWM_TIMER_EXPIRED，然后应在同一个BswM_MainFunction()循环中对BswMTimer模式进行仲裁。

BswMTimerAction BSWM_TIMER_STOP应立即停止所引用的BswMTimer，并将其模式更改为BSWM_TIMER_STOPPED。

与BswMTimer相关联的BswMRequestProcessing配置应始终视为DEFERRED，BswMTimer应在BswM主函数中进行仲裁。
处于BSWM_TIMER_EXPIRED模式的BswMTimer不会被BswM自动设置为BSWM_TIMER_STOPPED。用户需要配置一个动作，以便将BswMTimer从BSWM_TIMER_EXPIRED模式转换为其他模式。如果没有配置将BswMTimer转为BSWM_TIMER_EXPIRED模式的动作，那么在后续的BswM主函数循环中，BswMTimer将继续以BSWM_TIMER_EXPIRED模式进行仲裁。

五、多分区

对于多个BswM实例，每个BswM实例将基于其自身的配置集生成各自独立的服务组件描述。系统集成商需要将这些独立的服务组件分配到相应的分区中。

每个分区中都存在具有特定分区配置的 BswM（每个分区都有独立的 BswMConfig 实例）。所包含的动作列表在分区本地执行。

六、BswM接口和端口

本章描述了BswM提供的AUTOSAR接口和端口，并阐述了SWC与RTE之间的交互机制。

RTE 两侧的端口要求：
BswM端口（RTE 下方）：在其 SW 描述中定义服务端口。
SWC服务端口：使用该服务的每个AUTOSAR SWC需在自身描述中包含服务端口，端口类型需与BswM一致并建立连接，以便RTE生成ID和符号。

SWC向BswM发起request modes。为此，它们提供一个Sender Port，该端口具有一个包含单个数据元素的特殊Sender/Receiver Interface（Mode Request Interface）。数据元素的类型与相应模式的Mode Declarations组中的Mode Declarations具有相同的值（因为数据元素的 ImplementationDataType 映射到 ModeDeclaration Group）。

请求模式的同一个SWC也可能是mode user，因为它可能还需要知道BswM的仲裁结果。该SWC具有一个Mode Switch Port，该端口是一个带有Mode Switch Interface的R-Port，包含单个数据元素。此数据元素的类型即为Mode Declarations组本身。此外，其他没有request modes但依赖于request modes的SWC具有Mode Switch Port。请注意，BswM在除了需要知道决策中的请求的当前模式外，还需要Mode Switch Port。

当BswM切换相应模式时，RTE会发出Mode Notification。为此，BswM有Mode
Switch Port的对应类型，SWC可以连接到该端口。

在请求SWC的上下文中，定义了一个Mode Request Port (Sender/Receiver）。BswM的配置引用此端口定义。假设SWC定义了一个应用模式AppModeType、相应的AppModeRequestType以及将这两种类型相互映射的AppModeTypeMap：
ModeDeclarationGroup AppModeType {
{ APP_MODE_A, APP_MODE_B, APP_MODE_C }
initialMode = APP_MODE_A;
};

ImplementationDataType AppModeRequestType {
lowerLimit = 0;
upperLimit = 2;
};

ModeRequestTypeMap AppModeTypeMap {
modeGroup = AppModeType;
implementationDataType = AppModeRequestType;
};

在SWC上下文中，定义了两个接口：Sender/Receiver类型的 AppModeRequestInterface（SWC 作为发送方），以及有Mode Switch类型的 AppModeInterface（SWC可根据使用场景包含P-Ports和R-Ports）：

以下图展示了应用SWC的端口如何连接到BswM的服务端口。应用模式管理器SWC具有一个Mode Request Port和Mode Switch R-port。第一个端口用于请求其应用模式的更改，后者用于在BswM执行模式更改时接收通知。应用模式管理器的模式请求端口（modeRequestPort0）连接到BswM的对应模式请求端口。由于这是常规的Sender/Receiver通信，应用模式管理器甚至可以连接到远程 ECU 上的多个BswM。

为了切换应用模式，BswM具有一个由本地RTE实现的Mode Switch
Port（modeSwitchPort_{Name}）。当RTE执行mode switch时，它会通知所有通过Mode Switch R-Ports连接到提供端口的连接实体（BSW模块或SWC）。以下图展示了应用模式管理器、其他依赖模式的应用部件和BswM本身（注意：其命名为 modeNotificationPort_{Name}，但端口类型为Mode Switch Port）。所有这些连接也都是本地的。

上图显示，基于SWC的应用模式管理器（如 AUTOSAR R3.1 及更早版本中使用的）直接切换应用模式，而不向BswM请求。因此，它们直接将Mode Switch Port连接到本地RTE。这意味着应用模式需要在该ECU本地，且BswM无法进行仲裁。尽管如此，BswM可以将当前应用模式作为其规则的输入，因为应用模式拥有一个Mode Switch R-Port。

（一）、Mode Request Ports

BswM必须声明一个接收方端口，其接口在SWC的上下文中定义：
RequirePort AppModeRequestInterface modeRequestPort_{ArbName}_{ReqName};

要读取当前请求的模式，BswM必须要调用：
Rte_Read_modeRequestPort_{ArbName}_{ReqName}_requestedMode( &
);

（二）、Mode Switch Ports

与模式请求类似，BswM在其用于模式切换的提供端口（Provide Ports）中仅引用在相应SWC描述上下文中定义的mode switch interfaces。对于上述示例，mode switch的声明如下：
ProvidePort AppModeInterface modeSwitchPort_{ModConName}
_{SwitchName};
配置参数BswMModeSwitchInterfaceRef引用此Mode Switch interface。
为了切换当前有效模式，BswM的实现必须在其操作列表中插入以下调用之一：

Rte_Switch_modeSwitchPort_{ModConName}_{SwitchName}_currentMode
( <new_mode> );

SchM_Switch_modeSwitchPort_{ModConName}_{SwitchName}_current
Mode( <new_mode> );

（三）、Notifications of Mode Switches

除了模式请求外，当前有效模式也可用作模式仲裁的输入。对于应用模式和车辆模式，BswM需要注册为mode user，然后通过Mode Switch Port接收模式变更通知。对于上述示例，模式通知的声明如下：
注意：为了便于区分ModeSwitchPort类型的RequirePort和ProvidePort，以下示例中将RequirePort命名为模式通知端口。
RequirePort AppModeInterface modeNotificationPort_{Arb
Name}_{ModeName};
为了读取当前有效模式，BswM的实现必须调用以下函数之一：

Rte_Mode_modeNotificationPort_{ArbName}_{ModeName}_currentMode(
& );

SchM_Mode_modeNotificationPort_{ArbName}_{ModeName}_currentMode
( & );

如果配置了增强型Rte_Mode或SchM_Mode，BswM的实现必须调用以下函数之一：
Rte_Mode_modeNotificationPort_{ArbName}{ModeName}currentMode(
&, &, & );
SchM_Mode_modeNotificationPort{ArbName}{ModeName}_currentMode
( &, &, & );

（四）、Component Type and Internal Behavior

BswM是一个服务组件，为ECU内部的模式请求提供服务。BswM的服务组件类型（ServiceComponentType）声明了上述所有端口以及一些内部行为。
ServiceComponentType BswM {
…
InternalBehavior {
…
};
};

内部行为取决于对应Mode Request Port的参数BswMRequestProcessing：

若为 BSWM_DEFERRED（延迟处理）：RTE无需执行任何特殊操作，因为BswM会在其BswM_MainFunction中周期性读取请求。
若为BSWM_IMMEDIATE（立即处理）：RTE 必须立即触发模式仲裁。因此，BswM需要注册一个触发模式仲裁的触发函数。

对于上述示例，在BswM的内部行为中，立即处理模式请求需要以下声明：
RunnableEntity ModeArbitrationRunnable {
symbol = <mode_arbitration_function>;
canBeInvokedConcurrently = TRUE;
};

DataReceiveEvent AppModeRequestEvent {
port = modeRequestPort0;
dataElement = requestedMode;
startOnEvent = ModeArbitrationRunnable;
};

注意：为了处理来自其他ECU的模式请求，需要另一种类型的服务组件。在VFB（虚拟功能总线）层面，它看起来像一个全局的服务组件，但实际上，对于每个ECU，它被实例化为一个位于RTE之上的服务组件。为了支持这一点，SWC模板提供了ServiceProxy ComponentType，而非普通的 ServiceComponentType。

七、以太网交换机端口组切换

当前R23-11版本的BswM支持以太网交换机端口组切换功能。基于当前请求的PNC（可能是物理网络配置），BswM将PNC请求映射到已配置的EthIfSwitchPortGroup（以太网接口交换机端口组），并调用EthIf_SwitchPortGroupRequestMode函数。当EthI（以太网接口）检测到累积链路状态发生变化时，会通知BswM。累积链路状态可用于通知应用程序，这在处理错误场景时尤为重要，例如当请求的EthIfSwitch端口组状态与当前累积链路状态冲突时，可以触发相应的错误处理机制。

八、Service Discovery Control

以下的TPS_SWCT指的是AUTOSAR_CP_TPS_SoftwareComponentTemplate。

（一）、General

除了用于请求和查询模式的通用方法外，BswM还提供了标准化接口，以控制应用层软件组件的服务发现（Service Discovery）。

根据以下章节所述，应基于SWC描述和ECUC的输入生成配置。生成配置的输入包括具有ServerServiceOffer、ServerEventSubscriptionStatus、ClientEventSubscription和ClientEventSubscriptionStatus的基于角色的数据分配（RoleBasedDataAssignment）的端口，以及它们的RepresentedPortGroups（所代表的端口组）。

有关如何对必要的端口和关系进行建模的详细信息，可参见AUTOSAR_CP_TPS_SoftwareComponentTemplate中的第 13.6.5 章 “Service Oriented Use Cases”。

以下是配置工具需要完成的步骤：
1、分析SWC描述以查找受影响的端口。
2、分析ECUC以推导出服务发现中相关的实体。
3、创建规则（Rules）和动作列表（ActionLists），以实现BswM提供的预期行为。
4、为来自服务发现模块的通知创建BswMModeRequestSources。
5、创建所需的发送方 / 接收方（S/R）端口的BswM侧，作为规则的输入。
6、创建所提供的ModeSwitch端口的BswM侧，用于向SWC发出指示。
7、基于定义良好的命名模式，在BswM服务SWC与应用SWC之间连接端口。
命名模式用于促进BswM与SWC之间的端口映射。这些模式的设计允许对名称（部分）进行匹配。通过尽可能使用SWC端口的名称，实现接口的解耦，使 SWC无需了解底层通信细节。

（二）、Client Service/Event Subscription Request

实现客户端功能的软件组件（Software Component, SWC）作为模式请求者，公开一个由发送方 / 接收方接口（SenderReceiverInterface）类型化的PPortPrototype。通过这种方式，该软件组件可以向BswM发送模式请求，以订阅和停止订阅特定的事件和方法。

上图展示了在使用（Some-IP）服务发现时构建事件订阅请求的链路。灰色元素表示已配置的元素。通过评估引用应用事件（此处为 Ev1）的端口组参考，可以推导出相应的请求端口（SWC_P1_Req）。应用事件与对应 SD事件（此处为事件组 1 中的 Ev1）之间的关系可通过 ECU 配置获得。

Event Subscription Rule Creation：
根据TPS_SWCT_03504（软件组件作为客户端订阅事件和方法），对于受请求端口影响的服务实例的每个事件（组），应创建一个BswM 规则。该规则的简称应为服务实例目标事件（组）的简称，并以ESR_作为前缀。
注意：SomeIP服务发现仅支持事件组。因此，在使用SomeIP时，此规则可能涵盖多个事件。

Service Request Rule Creation：
根据TPS_SWCT_03504，对于受请求端口影响的每个服务实例，应创建一个BswM 规则。该规则的简称应为目标服务实例的简称，并以SRR_作为前缀。
注意：服务请求规则会收集针对同一服务实例的所有请求端口。因此，当请求任何事件或方法时，将触发对客户端服务的请求。

Client Subscription SenderReceiver Interface：
发送方 / 接收方接口（SenderReceiverInterface）应按照AUTOSAR_CP_SWS_BSWModeManager[SWS_BSWM_91010]中的定义进行设计。
其中RuleName对应规则的名称。PortName对应SWC端口的简称。
PortName足以匹配相应的请求端口，无需额外命名空间。
同一接口可同时用于请求事件和客户端服务，实现接口复用。

Client Subscription RPort：
根据TPS_SWCT_03504，对于每个请求端口，应按照创建一个RPortPrototype。

Input for Event Subscription Rule：
属于同一事件（组）的所有请求端口应作为事件订阅规则的输入。

Input for Service Request Rule：
属于同一服务的所有请求端口应作为服务请求规则的输入。
注意：可通 EcuC（ECU 配置）推断哪些端口属于同一可请求实体（例如，在 SomeIP-SD 场景中为事件组和 / 或客户端服务）。

Content of Event Subscription rule：
事件订阅规则应按以下方式创建：
BswMRuleInitState = FALSE。
若至少一个关联的请求端口的评估结果为REQUEST_SERVICE，则规则评估为TRUE。
若所有请求端口的评估结果均为RELEASE_SERVICE，则规则评估为FALSE。

Content of Client Service request rule：
服务请求规则应按以下方式创建：
BswMRuleInitState = FALSE。
若至少一个关联的请求端口的评估结果为REQUEST_SERVICE，则规则评估为TRUE。
若所有请求端口的评估结果均为RELEASE_SERVICE，则规则评估为FALSE。

Client Service Request TRUE ActionList：
应创建一个动作列表（Action List），用于请求相应事件 / 方法的客户端服务。
当使用（SomeIP-）服务发现时：
需通过SD模块的Sd_ClientServiceSetState() 函数请求SD_CLIENT_SERVICE_REQUESTED状态。
该动作列表应作为规则的TRUE动作列表。

Client Service Request FALSE ActionList：
应创建一个动作列表，用于释放包含相应事件的客户端服务请求。
若使用（SomeIP-）服务发现，需通过SD模块的Sd_ClientServiceSetState()函数请求SD_CLIENT_SERVICE_RELEASED状态。
该动作列表应作为规则的FALSE动作列表。

Order of ActionList Execution：
客户端服务的事件订阅TRUE动作列表必须始终在该客户端服务的服务请求TRUE动作列表之后执行。
若在请求客户端服务之前先请求事件组，服务发现（Service Discovery）将不会处理该事件组请求。
释放客户端服务会隐式导致释放所有关联的事件组。

Event Subscription TRUE ActionList：
应创建一个动作列表，用于请求订阅相应的事件。
若使用（SomeIP-）服务发现，需通过SD模块的Sd_ConsumedEventGroupSetState()函数请求SD_CONSUMED_EVENTGROUP_REQUESTED状态。
该动作列表应作为规则的TRUE 动作列表。

Event Subscription FALSE ActionList：
应创建一个动作列表，用于请求取消订阅相应的事件。
若使用（SomeIP-）服务发现，需通过SD模块的Sd_ConsumedEventGroupSetState()函数请求SD_CONSUMED_EVENTGROUP_RELEASED 状态。
该动作列表应作为规则的FALSE 动作列表。

（三）、Client Service/Event Subscription state notification

作为客户端且关注事件和方法订阅状态的软件组件，需公开一个由ModeSwitchInterface所定义的RPortPrototype类型。通过这种方式，BswM可以通知该软件组件是否已完成订阅。

Mode Switch Interface ClientServiceSubscription-State：
Mode Switch Interface应符合AUTOSAR_CP_SWS_BSWModeManager的定义，其中：
{RuleName}：对应规则的名称。
{SwcName_PortName}：软件组件名称与端口名称的组合简称。
初始模式为RELEASE_SERVICE。
注意：根据受影响的是否为事件，该接口可同时用于通知事件订阅状态和 / 或客户端服务可用性。

Service Availability Notification Rule creation：
针对每个被RPortPrototype引用的端口组，当软件组件接收客户端事件和方法订阅状态变更通知时，应创建一个BswM规则。规则简称格式为：SANR_{端口组短名称}。

BswMModeRequestSource BswMSdConsumedEventGroup CurrentState：
对于受服务可用性通知规则影响的每个已消费事件组，应创建一个BswMModeRequestSource.BswMSdConsumedEventGroupCurrentState作为该规则的输入。

BswMModeRequestSource BswMSd-ClientServiceCurrentState：
对于受服务可用性通知规则影响的每个客户端服务，应创建一个BswMModeRequestSource.BswMSdClientServiceCurrentState作为该规则的输入。

Client Event Subscription notification rule：
针对每个被RPortPrototype引用的端口组，应按以下方式创建BswM规则：
BswMRuleInitState = FALSE。
评估为TRUE的条件：
所有关联的模式请求源均评估为SD_CLIENT_SERVICE_AVAILABLE
所有关联的模式请求源均评估为SD_CONSUMED_EVENTGROUP_AVAILABLE
否则评估为FALSE。

Client Subscription Notification PPort：
针对每个被RPortPrototype引用的端口组，应创建一个符合AUTOSAR_CP_SWS_BSWModeManager的PPortPrototype。

Client Service availability TRUE action list：
应创建一个动作列表，通过将客户端订阅通知PPort的当前模式设置为REQUEST_SERVICE，向相应的软件组件发送通知。此动作列表应作为规则的TRUE动作列表。

Client Service availability FALSE action list：
应创建一个动作列表，通过将客户端订阅通知 PPort的当前模式设置为RELEASE_SERVICE，向相应的软件组件发送通知。此动作列表应作为规则的 FALSE 动作列表。

注意：在典型场景中，通常仅涉及1个客户端服务中的1个事件（或仅涉及方法调用时的客户端服务）。然而，由于可以将任意数量的事件、方法甚至不同的服务（实例）进行组合，因此仅当所有这些元素均可用且已订阅时，才会触发通知。

（四）、Server Service Offer Request

实现服务器功能的软件组件充当模式请求者，并公开一个由SenderReceiverInterface所定义的PPortPrototype类型。通过这种方式，软件组件可以向BswM发送模式请求，以提供和停止提供该服务实例。在BswM一侧，使用由相同SenderReceiver-Interface定义的RPortPrototype来处理模式切换请求。与客户端用例不同，服务器服务的提供仅允许通过一个端口进行，这意味着每个服务实例仅支持单个端口。

Unique port for offering a service instance：
每个服务实例仅允许一个端口。

Sender Receiver Interface ServerServiceRequest：
SenderReceiverInterface应按照AUTOSAR_CP_SWS_BSWModeManager [SWS_BSWM_91009]中的定义进行设计，其中：
{RuleName}：对应规则的名称。
{PortName}：服务器 SWC 对应端口的简称。
注意：仅需通过{PortName}即可匹配相应的请求端口。

Service Offer Rule Creation：
根据 TPS_SWCT_03502，对于受请求端口影响的每个服务实例，应创建一个 BswM规则。该规则的简称应为目标服务的简称，并以SOR_作为前缀。

Service Offer Port Creation：
根据 TPS_SWCT_03502，对于每个请求端口，应按照AUTOSAR_CP_SWS_BSWModeManager [SWS_BSWM_91009] 创建一个 RPortPrototype。

Service Offer Rule Input：
属于同一服务实例的请求端口应作为规则 [SWS_BswM_00309] 的输入。
注意：每个规则仅会创建一个请求端口。
注意：可通过EcuC推断哪些端口属于同一服务实例。

Service Offer rule：
有以下创建方式：
BswMRuleInitState = FALSE。
当所有关联的请求端口的评估结果均为OFFER_SERVICE时，规则评估为TRUE。
当至少一个请求端口的评估结果为STOP_OFFER_SERVICE时，规则评估为FALSE。

Service Offer TRUE ActionList：
应创建一个动作列表，用于请求提供相应的服务实例。
若使用（SomeIP-）服务发现，需通过SD模块的Sd_ServerServiceSetState()函数请求SD_SERVER_SERVICE_AVAILABLE状态。
该动作列表应作为规则的TRUE动作列表。

Service Offer FALSE ActionList：
应创建一个动作列表，用于请求停止提供相应的服务实例。
若使用（SomeIP-）服务发现，需通过SD模块的Sd_ServerServiceSetState()函数请求SD_SERVER_SERVICE_DOWN状态。
该动作列表应作为规则的FALSE 动作列表。

（五）、Server Service/Event Subscription State Notification

如果服务器实例的事件没有任何订阅者，那么发送事件或字段通知的服务器实例可能无需生成和发送这些事件。
为了通知服务器实例是否至少有一个订阅者对其事件感兴趣，可通过 ModeSwitchInterface接收订阅通知。
作为服务器且关注服务实例事件订阅状态的软件组件，则会公开一个由ModeSwitchInterface所定义的RPortPrototype类型的接口。通过这种方式，BswM可以就订阅状态的变更通知该软件组件。

MSIF ServerServiceSubscriptionState：
Mode Switch Interface应按照AUTOSAR_CP_SWS_BSWModeManager [SWS_BSWM_91013] 中的定义进行设计，其中：
{RuleName}：对应规则的名称。
{SwcName_PortName}：软件组件的简称及对应端口的名称。
初始模式：RELEASE_SERVICE。

Server Event Subscription Notification Rule creation：
根据TPS_SWCT_03503（软件组件接收服务器事件订阅状态变更通知），对于每个被RPortPrototype引用的端口组，应创建一个BswM规则，其简称应为SESNR_{端口组短名称}。

Server Subscription Notification PPort：
根据TPS_SWCT_03503，对于每个通知端口，应按照AUTOSAR_CP_SWS_BSWModeManager [SWS_BSWM_91012] 创建一个 PPortPrototype。

BswMModeRequestSource BswMSdEventHandlerCurrentState：
对于受服务器事件订阅通知规则影响的每个事件（组），应创建一个BswMModeRequestSource.BswMSdEventHandlerCurrentState作为该规则的输入。

Client Service availability notification rule content：
如果属于服务器事件订阅通知规则的至少一个BswMModeRequestSource指示SD_EVENT_HANDLER_REQUESTED，则对应的模式切换接口的当前模式应为REQUEST_SERVICE。否则，其当前模式应为RELEASE_SERVICE。

（六）、Connecting ports at configuration time

接口实际类型的定义（尤其是给定的命名约定）有助于端口的连接。这意味着工具链可以通过分析接口名称自动完成端口连接，而实现这一点所需的属性在SWC描述的设计阶段通过ServiceDependency提供。以下属性的端口均适用这一机制：

SenderReceiverInterfaces：
当RoleBasedDataAssignment设置为ClientEventSubscription时。
ModeSwitchInterfaces：
当RoleBasedDataAssignment设置为ClientEventSubscriptionStatus时。
SenderReceiverInterfaces：
当RoleBasedDataAssignment设置为ServerServiceOffer时。
ModeSwitchInterfaces：
当RoleBasedDataAssignment设置为ClientEventSubscriptionStatus时。

九、多核

暂无。

十、主要代码和参数描述

（一）、主要函数

1、void BswM_BswMPartitionRestarted (void)
当ECU中包含BswM的分区被Rte重启时，由该分区的Restart Task调用此函数，告知BswM分区已完成重启，BswM接收此通知后，可基于配置的规则识别当前启动为分区单独重启（而非ECU整体正常启动），进而执行与分区重启相关的模式管理逻辑。

2、void BswM_CanSM_CurrentState (NetworkHandleTypeNetwork,CanSM_BswMCurrentStateType CurrentState)
由CanSM模块主动调用，当CAN通道的状态发生变化时，CanSM通过此函数将变化后的状态同步给BswM。BswM可根据此函数作为模式仲裁的输入条件之一，参与规则评估，例如CanSM处于CANSM_BSWM_SILENT_COMMUNICATION时执行动作去关闭发送的IPDU组。

3、void BswM_ComM_CurrentMode (NetworkHandleType Network,ComM_ModeType RequestedMode)
由ComM调用，当某一ComM通信通道的通信模式发生变化（如从COMM_NO_COMMUNICATION切换为COMM_FULL_COMMUNICATION）时，ComM通过此函数将变化后的当前模式同步给BswM。

4、void BswM_ComM_CurrentPNCMode (PNCHandleType PNC,
ComM_PncModeType CurrentPncMode)
由ComM调用，当某一PNC的通信模式发生变化（如从COMM_PNC_READY_SLEEP切换为COMM_PNC_REQUESTED）时，ComM通过此函数将变化后的PNC当前模式同步给BswM。

5、void BswM_ComM_InitiateReset (void)
ComM因为通信限制进入COMM_NO_COMMUNICATION后会调用该函数通知BswM，BswM将执行ECU的复位操作。

6、void BswM_Dcm_ApplicationUpdated (void)
如果Dcm的初始化是由于从Bootloader处跳转而引起的以及该应用程序是通过FLASH下载进行更新的，那么Dcm应调用该函数通知BswM。BswM接收该通知后，可以根据预设的配置规则执行与应用更新相关的动作，例如重新初始化与更新后应用关联的BSW模块等。

7、void BswM_Dcm_CommunicationMode_CurrentState (
NetworkHandleType Network,Dcm_CommunicationModeType RequestedMode)
由Dcm调用，当某一通信通道的诊断通信模式发生变化（如执行28服务后从允许通信变成禁止通信）时，Dcm通过此函数将变化后的当前模式同步给BswM，然后BswM可以执行开启关闭IPDU组的操作。

8、void BswM_Deinit (void)
BswM反初始化。

9、void BswM_EcuM_CurrentState (EcuM_StateType CurrentState)
由EcuM调用，当ECU的运行状态发生变化（如从ECUM_STATE_STARTUP_TWO切换为ECUM_STATE_WAKEUP_VALIDATION）时，EcuM通过此函数将变化后的当前ECU状态同步给BswM。

10、void BswM_EcuM_CurrentWakeup (EcuM_WakeupSourceType source,EcuM_WakeupStatusType state)
由EcuM调用，当ECU的某个唤醒源状态发生变化（如唤醒源从PENDING变为VALIDATED）时，EcuM通过此函数将状态同步给BswM。

11、void BswM_EcuM_RequestedState (EcuM_StateType State,
EcuM_RunStatusType CurrentState)
由EcuM调用，当EcuM的RUN或POST_RUN被请求释放时，EcuM通过此函数将状态同步给BswM。

12、void BswM_EthIf_PortGroupLinkStateChg (EthIf_SwitchPortGroupIdxType PortGroupIdx,EthTrcv_LinkStateType PortGroupState)
由Ethlf调用，用于指示某一以太网交换机端口组的链路状态变化。

13、void BswM_EthSM_CurrentState (NetworkHandleType Network,
EthSM_NetworkModeStateType CurrentState)
由EthSM调用，用于指示其当前状态。

14、void BswM_FrSM_CurrentState (NetworkHandleType Network,
FrSM_BswM_StateType CurrentState)
由FrSM调用，用于指示其当前状态。

15、void BswM_GetVersionInfo (Std_VersionInfoType* VersionInfo)
用于获取BswM的版本信息。

16、void BswM_Init (const BswM_ConfigType * ConfigPtr)
用于将BswM初始化。

17、void BswM_J1939DcmBroadcastStatus (uint16 NetworkMask)
由J1939Dcm调用，当J1939Dcm接收到诊断请求需调整各J1939网络的广播状态时，通过此函数将广播状态信息同步给BswM。

18、void BswM_J1939Nm_StateChangeNotification (NetworkHandleType Network,uint8 Node,
Nm_StateType NmState)
J1939Nm通知BswM当前状态。

19、void BswM_LinSM_CurrentSchedule (NetworkHandleType Network,LinIf_SchHandleType CurrentSchedule)
由LinSM调用，当某一LIN通道的调度表发生切换时，LinSM通过此函数将切换后的信息同步给BswM。

20、void BswM_LinSM_CurrentState (NetworkHandleType Network,LinSM_ModeType CurrentState)
LinSM通知BswM当前状态。

21、void BswM_LinTp_RequestMode (NetworkHandleType Network,LinTp_Mode LinTpRequestedMode)
LinIf通知BswM当前的Tp请求。

22、void BswM_Nm_CarWakeUpIndication (NetworkHandleType Network)
由Nm调用，当Nm检测到有CarWake事件时，通过此函数将该事件同步给BswM。

23、void BswM_Nm_StateChangeNotification (NetworkHandleType Network,Nm_StateType currentState)
由Nm调用，当某一Nm通道的网络状态发生变化时，Nm通过此函数将变化后的Nm通道状态同步给BswM。

24、void BswM_NvM_CurrentBlockMode (NvM_BlockIdType Block,NvM_RequestResultType CurrentBlockMode)
由NvM模块调用，当某一NvM块的操作状态发生变化时，NvM通过此函数将该块的当前状态同步给BswM。

25、void BswM_NvM_CurrentJobMode (NvM_MultiBlockRequestType MultiBlockRequest,
NvM_RequestResultType CurrentJobMode)
由NvM调用，当NvM执行的多块作业（如 NvM_ReadAll()、NvM_WriteAll()、NvM_FirstInitAll()等）状态发生变化时，NvM通过此函数将多块作业的当前状态同步给BswM。

26、void BswM_RequestMode (BswM_UserType requesting_user,BswM_ModeType requested_mode)
由无专用模式请求接口的BSW模块调用（例如部分非标准化或用户自定义BSW模块）。
在一些BSW中没有S/R接口，可直接使用BswM_RequestMode()当接口。
当这些BSW模块需要请求特定模式（如切换某功能的运行模式、启用/禁用某资源）时，因无专属BswM API（如BswM_CanSM_CurrentState这类总线模块专用API），需通过此通用函数向BswM传递请求，确保其模式需求被纳入BswM仲裁逻辑。

27、void BswM_Sd_ClientServiceCurrentState (uint16 SdClientServiceHandleId,Sd_ClientServiceCurrentStateType CurrentClientState)
该函数由Sd调用。在实际运行中，当客户服务的状态发生变化，Sd模块会调用此函数，将最新状态告知BswM。

28、void BswM_Sd_ConsumedEventGroupCurrentState (uint16 SdConsumedEventGroupHandleId,Sd_ConsumedEventGroupCurrentStateType ConsumedEventGroupState)
由Sd调用，当某一ConsumedEventGroup的状态发生变化时，Sd通过此函数将变化后的状态同步给BswM。

29、void BswM_Sd_EventHandlerCurrentState (uint16 SdEventHandlerHandleId,
Sd_EventHandlerCurrentStateType EventHandlerStatus)
由Sd调用，当某一EventHandler的运行状态发生变化时，Sd通过此函数将变化后的状态同步给BswM。

30、void BswM_SoAd_SoConModeChg (SoAd_SoConIdType SoConId,SoAd_SoConModeType State)
由SoAd调用，当某一SoCon的运行模式发生变化时，SoAd通过此函数将变化后的模式同步给BswM。

十一、DaVinci Configurator主要配置

（一）、BswMGeneral

Action LIst Queue Search Algorithm:
选择执行动作列表的算法。

BswMXXEnabled：是否使能对应组件的API。

BswMUserIncludeFiles：
需要包含的外部头文件， 一般用于调用User Callout函数时添加用户函数 的头文件。

（二）、BswMConfig

1、BswMArbitration

（1）、BswMLogicalExpressions

此处为逻辑表达式。

Logical Operator：
用于存在多个仲裁条件时，仲裁条件的连接符。
BSWM_AND、BSWM_NAND、BSWM_OR、BSWM_XOR，
即if((仲裁条件)&&(仲裁条件))、
if(!(仲裁条件)&&(仲裁条件))、
if((仲裁条件)||(仲裁条件))、
if((仲裁条件)^(仲裁条件))。

Argument Ref：
每一个Argument代表一个仲裁条件，仲裁条件在BswMModeConditions里配置。

（2）、BswMModeConditions

此处配置仲裁条件即模式条件。

Condition Type：
BSWM_EQUALS、BSWM_EQUALS_NOT、BSWM_EVENT_IS_CLEARED、BSWM_EVENT_IS_SET 。
当BswMConditionMode配置为引用BswMModeRequestPort时，此处只能选择BSWM_EQUALS或者BSWM_EQUALS_NOT。
当BswMConditionMode配置为引用BswMEventRequestPort时，此处只能选择BSWM_EVENT_IS_SET或者BSWM_EVENT_IS_CLEARED。
BSWM_EQUALS、BSWM_EQUALS_NOT即：
BswMConditionMode==BswMBswRequestedMode和BswMConditionMode!=BswMBswRequestedMode。

Condition Mode：
此处为条件的引用端口，BswMModeRequestPort或BswMEventRequestPort。

BswMConditionValue：
用于BswMConditionMode进行比较，可以选择BswMBswMode或BswMModeDeclaration。

BswMBswMode：
用于ConditionMode比较的值，需要手动填，如想判断CanSM的状态是否为无通信就填CANSM_BSWM_NO_COMMUNICATION。
如果引用的请求端口为BswMEventRequestPort则填TRUE或FALSE。

BswMModeDeclaration：
用于ConditionMode比较的值，来自模式声明组，模式声明组在swc中或BswMRteModeDclGroups中定义。

（3）、BswMModeRequestPorts

此处可以选择模式请求端口，BswMModeRequestPort和BswMEventRequestPort都在此处。
BswMModeRequestPort是有状态输入给BswM的接口，如BswM_CanSM_CurrentState()由CanSM调用并且把当前CanSM的状态通知给BswM，而BswMEventRequestPort是事件型通知的接口，如BswM_ComM_InitiateReset()，当这个事件型端口调用后，该端口的条件模式变为TRUE，事件型端口每次调用后条件模式都会变为TRUE，然后立即执行仲裁，之后条件模式变为FALSE。

Arbitrate On Init：
使能后在BswM_Init()时此请求端口的规则将根据此端口的初始值进行仲裁。

RequestProcessing：
BSWM_DEFERRED或BSWM_IMMEDIATE或BSWM_FORCED_IMMEDIATE，当请求源触发时，模式仲裁是立即处理还是推迟到下次在主任务中去处理，如果当前有在处理的规则，则IMMEDIATE型请求放在主循环的队列里处理，如果是FORCED_IMMEDIATE则把当前规则优先级提到最高立即处理。
如果引用的端口是BswMEventRequestPort型的必须选择IMMEDIATE。
在vector代码里如果为IMMEDIATE，在仲裁期间执行了动作列表，然后动作列表执行后模式条件发生了变化不会进行下一次仲裁。如动作为调用BswM_RequestMode()，而该请求源设为IMMEDIATE，当在某个动作列表调用了该函数，因为在规则执行期间所以不会触发新的模式仲裁。
有些请求源必须设置为DEFERRED，如BswMTimer。

BswMModeInitValue：
请求端口的初始值。

BswMModeRequestSource：
模式条件的请求源。BswM模块接收来自SWC的模式请求（Mode Request）和来自于其他BSW模块的模式指示（Mode indication）作为输入进入模式条件执行模式仲裁。
可选择的请求端口有：

BswMBswModeNotification：
模式请求或模式指示的来源。来自其他BSW模块，例如自己写的CDD模块。

BswMCanSMIndication：
请求接口为BswM_CanSM_CurrentState()。

BswMComMIndication：
请求接口为BswM_ComM_CurrentMode()。

BswMComMInitiateReset：
请求接口为BswM_ComM_InitiateReset()。

BswMComMPncRequest：
请求接口为BswM_ComM_CurrentPNCMode()。

BswMDcmApplicationUpdatedIndication：
请求接口为BswM_Dcm_ApplicationUpdated()。

BswMDcmComModeRequest：
请求接口为BswM_Dcm_CommunicationMode_CurrentState()。

BswMEcuMIndication：
请求接口为BswM_EcuM_CurrentState()。

BswMEcuMRUNRequestIndication：
请求接口为BswM_EcuM_RequestedState()。

BswMEcuMWakeupSource：
请求接口为BswM_EcuM_CurrentWakeup()。

BswMEthIfPortGroupLinkStateChg：
请求接口为BswM_EthIf_PortGroupLinkStateChg()。

BswMEthSMIndication：
请求接口为BswM_EthSM_CurrentState()。

BswMFrSMIndication：
请求接口为BswM_FrSM_CurrentState()。

BswMGenericRequest：
这是通用请求接口，在这里会定义请求ID和模式数量，该请求接口为BswM_RequestMode()，例如如下定以了ESH的一系列模式。

BswMJ1939DcmBroadcastStatus：
请求接口为BswM_J1939DcmBroadcastStatus()。

BswMJ1939NmIndication：
请求接口为BswM_J1939Nm_StateChangeNotification()。

BswMLinScheduleEndNotification：
来自Lin调度表通知。

BswMLinSMIndication：
请求接口为BswM_LinSM_CurrentState()。

BswMLinScheduleIndication：
请求接口为BswM_LinSM_CurrentSchedule()。

BswMLinTpModeRequest：
请求接口为BswM_LinTp_RequestMode()。

BswMNmIndication：
请求接口为BswM_Nm_StateChangeNotification()。

BswMNvMJobModeIndication：
请求接口为BswM_NvM_CurrentJobMode()。

BswMNvMRequest：
请求接口为BswM_NvM_CurrentBlockMode()。

BswMPduRPreTransmit：
在调用_Transmit()之前，会先发出此模式请求端口的信号。

BswMPduRRxIndication：
这是来自PduR的接收指示。

BswMPduRTpRxIndication：
这是来自PduR的TP协议接收指示。

BswMPduRTpStartOfReception：
这是来自PduR的StartOfReception指示。

BswMPduRTpTxConfirmation：
这是来自PduR的TP协议发送确认通知。

BswMPduRTransmit：
这是来自PduR的发送通知。

BswMPduRTxConfirmation：
这是来自PduR的发送确认通知。

BswMSwcModeNotification：
来自swc的模式切换通知接口。

BswMSdClientServiceCurrentState：
请求接口为BswM_Sd_ClientServiceCurrentState()。

BswMSdConsumedEventGroupCurrentState：
请求接口为BswM_Sd_ConsumedEventGroupCurrentState()。

BswMSdEventHandlerCurrentState：
请求接口为BswM_Sd_EventHandlerCurrentState()。

BswMSwcModeRequest：
来自swc的模式请求接口。

BswMTimer：
此处配置BswM定时器，默认状态为BSWM_TIMER_STOPPED，定时器启动由BswMActions里定义的BswMTimerControl触发。

BswMUserConditionRequest：
此请求的来源可以是任何具有返回值的可用函数。

BswMWdgMRequestPartitionReset：
请求接口为BswM_WdgM_RequestPartitionReset()。

（4）、BswMRules

这里定义每条rule。

Nested Execution Only：
置TRUE表示此Rule不能直接被仲裁，只能用于在模式控制Actionlist中被引用。

Rule Expression Ref：
引用的规则表达式，来自BswMLogicalExpressions。

Rule False Action List：
当此rule仲裁为FALSE时 ，需要执行的动作，来自BswMModeControl的BswMActionLists。

Rule Init State：
该rule的初始评估结果，有BSWM_FALSE、BSWM_TRUE、BSWM_UNDEFINED，比如初始为BSWM_FALSE，那只有该rule评估结果为BSWM_TRUE时才去执行Rule True Action List。

Rule True Action List：
当此rule仲裁为TRUE时 ，需要执行的动作，来自BswMModeControl的BswMActionLists。

2、BswMDataTypeMappingSets

引用Swc的DataTypeMappingSet。

3、BswMModeControl

Init Action List Ref：
BswM初始化时要执行的动作列表。

（1）、BswMActions

该项配置动作，即规则仲裁成功或失败后要执行的代码，被动作列表引用。
可以选择执行的动作有：

BswMComAllowed：
该动作会调用ComM_CommunicationAllowed()让ComM通道是否进入FULL通信状态。

BswMComMModeLimitation：
该动作会调用ComM_LimitChannelToNoComMode()让ComM通道是否通信限制。

BswMComMModeSwitch：
该动作会调用ComM_RequestComMode()让ComM通道进入BSWM_COMM_FULL_COMMUNICATION还是BSWM_COMM_NO_COMMUNICATION。

BswMDeadlineMonitoringControl：
该动作会调用Com_DisableReceptionDM()或Com_EnableReceptionDM()停止或启动对I-PDU组的接收截止期限监控。

BswMEcuMGoDownHaltPoll：
该动作会调用EcuM_GoDownHaltPoll()让EcuM进入SHUTDOWN PHASE或SLEEP PHASE。

BswMEcuMSelectShutdownTarget：
该动作会调用EcuM_SelectShutdownTarget()让EcuM选择关机目标。

BswMEcuMStateSwitch：
该动作会调用EcuM_SetState()改变EcuM的状态，有BSWM_ECUM_STATE_POST_RUN、BSWM_ECUM_STATE_RUN、BSWM_ECUM_STATE_SHUTDOWN、BSWM_ECUM_STATE_SLEEP、BSWM_ECUM_STATE_STARTUP。

BswMEthIfStartAllPorts：
该动作会调用EthIf_StartAllPorts()。

BswMGenericModeSwitch：
该动作会调用BswM_RequestMode()，入参请求user和请求mode为容器BswMModeRequestSource处定义的。
比如BswMModeRequestPorts处定义了ESH_State

本项就可以配置如下：

表示该动作会调用BswM_RequestMode()然后将模式ESH_State置为ESH_INIT。

然后BswMModeConditions定义的模式条件ESH_Cond_StateIsInit便仲裁为TRUE。

BswMIdsMBlockStateChangeRequest：
该动作会调用IdsM_BswM_StateChanged()。

BswMJ1939DcmStateSwitch：
该动作会调用J1939Dcm_SetState()。

BswMJ1939RmStateSwitch：
该动作会调用J1939Rm_SetState()。

BswMLinScheduleSwitch：
该动作会调用LinSM_ScheduleRequest()。

BswMNMControl：
该动作会调用Nm_EnableCommunication()或Nm_DisableCommunication()让Nm通道开启关闭通信。

BswMPduGroupSwitch：
该动作会调用Com_IpduGroupStart()或Com_IpduGroupStop()开启关闭Com的IPDU组。

BswMPduRouterControl：
该动作会调用PduR_EnableRouting()或PduR_DisableRouting()开启关闭PduR的路由路径组。

BswMRteModeRequest：
该动作会调用Rte_Write()进行模式请求。

BswMRteSwitch：
该动作会调用Rte_Switch()进行模式切换。

BswMSchMSwitch：
该动作会调用SchM_Switch()进行模式切换。

BswMSdClientServiceModeRequest：
该动作会调用Sd_ClientServiceSetState()。

BswMSdConsumedEventGroupModeRequest：
该动作会调用Sd_ConsumedEventGroupSetState()。

BswMSdServerServiceModeRequest：
该动作会调用Sd_ServerServiceSetState()。

BswMSdServiceGroupSwitch：
该动作会调用Sd_ServiceGroupStop()或Sd_ServiceGroupStart()。

BswMSwitchIPduMode：
该动作会调用Com_SwitchIpduTxMode()改变Com的某个IPDU的TMS发送模式为TRUE或FALSE。

BswMTriggerIPduSend：
该动作会调用Com_TriggerIPDUSend()触发某条IPDU的立即发送。

BswMTimerControl：

此处定义BswM定时器的触发动作。
TImer Action：
选择该动作触发后将定时器变为BSWM_TIMER_STOPPED还是BSWM_TIMER_STARTED，如果是BSWM_TIMER_STARTED，那么该定时器将在下个主函数里递减直到BSWM_TIMER_EXPIRED。

Timer Ref：
选择定时器，在BswMModeRequestPorts里定义。

Timer Value[s]：
定时器超时值。

BswMUserCallout：
当要执行的动作标志BSW模块里没有时可以在这里自定义动作，如下：

BswMRuleControl：
改变某个rule的评估结果。

（2）、BswMActionLists：

Action List Execution：
当配置为CONDITION模式时，此ActionList每次都会被执行。
当配置为TRIGGER模式时，此ActionList仅在仲裁结果发生改变时才会被执行。

Action List Priority：
动作列表的优先级，因为如果在主循环里有很多动作列表需要执行，那么根据优先级最高的来执行。

Abort On Fail：
如果一个action list有多个action，如果其中有个action返回E_NOT_OK后，actionlist就会终止执行。

（3）、BswMRteModeRequestPorts：

这里可以定义模式请求端口。

（4）、BswMSwitchPorts：

这里可以定义模式切换端口。

如上定义好后可以在如下文件看到有定义端口：

4、BswMRteModeDclGroups

这里是由BswM创建的模式声明组，定义的模式声明组可供模式切换接口使用（ModeSwitchInterface-MSI）。

定义后可以在Rte_BswM_Type.h里看到声明的数据集：

在Rte_Type.h里看到声明类型：

定义好后可以在BswMSwitchPorts里创建模式切换接口后或者在其他地方的模式切换接口进行引用：

十二、使用范例

Vector释放的代码包里有已经配置好的BswM项，主要有BSW初始化、ECU状态处理、通信控制等。

（一）、Initialization

BswM可以执行初始化模块动作，可以由集成人员进行配置。

BswM里对BSW模块初始化的动作列表叫做INIT_AL_Initialize，没有被包含在rule里，而是如下的配置项里，在BswM初始化时不需要仲裁就会执行。

在BSW Management界面可以添加要执行初始化动作：

当然首先需要在BswMActions容器里定义初始化的动作，然后才可以在上面的配置里进行引用：

这些初始化是在OS启动后进行的初始化，如下在StartOS()后激活第一个初始任务，在初始任务里调用EcuM_StartupTwo()，然后在里面调用BswM_Init()：

这里的初始化不同于

这里的初始化，这里的初始化是EcuM负责的并且是在OS启动前执行的。

（二）、ECU State Handling

BswM能够创建规则来对ECU执行启动和关闭。所以在BSW Management界面的ESH处可以配置。
ESH可以激活以下功能：
Dem初始化与关闭生成。
ComM通信的启用与禁用。
NvM处理的激活。
Rte模式变更通知。
状态转换过程中的Callouts。
ECU意外复位后的以太网交换机的重启。

EcuM的状态切换通常有条件限制并且切换后有相应的动作，那么这些行为可以在EcuM提供的callout函数里执行或者在SWC里执行或者在该BswM模块里执行。

ESH状态机切换如下，通过ESH状态机切换来与EcuM的状态切换来对应：

首先看下ESH里的定义的规则，根据状态机切换有如下规则：

1、ESH_DemInit

此规则生成的代码如下：

通过配置来看，此规则功能是当ESH_DemInitStatus为DEM_NOT_INITIALIZED时将Dem初始化：
当ESH_DemInitStatus为DEM_NOT_INITIALIZED时立即执行Dem_Init()和调用BswM_RequestMode()将ESH_DemInitStatus变为DEM_INITIALIZED。

当ESH的状态从WakeUp跳到Run时会执行一次此规则。

当ESH的状态从PostRun跳到PrepShutdown时会将ESH_DemInitStatus为DEM_NOT_INITIALIZED。

2、ESH_InitToWakeup

此规则生成的代码如下：

通过配置来看，此规则功能是当ESH状态进入Startup后执行跳转动作，跳到WakeUp状态：

当检测到ESH_State为ESH_INIT即使ESH初始状态为Initial时并且EcuM状态为ECUM_STATE_STARTUP即ECU刚上电EcuM初始化后处于STARTUP Phase时，该规则会执行：

调用BswM_ESH_OnEnterWakeup()即供用户添加自定义代码的callout。
将模式切换接口ESH_ModeSwitch设为WAKEUP即通知SWC ESH的模式为WAKEUP了。
调用BswM_RequestMode()将ESH_State变为ESH_WAKEUP表示ESH状态已经切换到WakeUp了。

3、ESH_PostRun

此规则生成的代码如下：


通过配置来看，此规则功能是当ESH状态进入PostRun后处理通信和DEM相关动作，然后要么跳到Run状态要么跳到Prepare Shutdown状态：

当检测到ESH_State为ESH_POST_RUN即ESH状态从Run切到PostRun，
并且模式切换通知接口ESH_ModeNotification为POSTRUN，
并且EcuM状态为ECUM_STATE_APP_POST_RUN即ECU刚上电EcuM初始化后处于STARTUP Phase时，该规则会执行：

进入临界区。
判断ComM的网络通道是否处于COMM_NO_COM_NO_PENDING_REQUEST状态，是的话调用BswM_RequestMode()将将ESH_ComMPendingRequests设为ESH_COMM_PENDING_REQUEST否则设为ESH_COMM_NO_REQUEST。
调用Dem的接口判断Dem模块是否已将所有NVM数据写完，Dem模块是否处于可安全关闭状态，是的话调用BswM_RequestMode()将ESH_DemPostRunRequested设为FALSE否则设为TRUE。
执行ESH_PostRunNested规则，在该规则里判断是跳到Run状态还是跳到Prepare Shutdown状态。
退出临界区。

4、ESH_PostRunNested

此规则生成的代码如下：



通过配置来看，此规则功能是当ESH状态进入PostRun后去判断要么跳到Run状态要么跳到Prepare Shutdown状态：

当检测到ESH_RunRequest_0为REQUESTED即SWC有请求ESH进入Run，
或者检测到ESH_EcuMRequest_RUN为REQUESTED即EcuM的接口EcuM_RequestRUN()被调用请求进入RUN模式，
或者调用EcuM_GetValidatedWakeupEvents()检测有验证过有效的唤醒事件（有唤醒事件不能进入休眠，需要调用EcuM_ClearWakeupEvent()清除有效事件），
或者检测到ESH_ComMPendingRequests为ESH_COMM_PENDING_REQUEST即表示ComM的网络通道是否处于COMM_NO_COM_REQUEST_PENDING状态的话，该规则会执行以下动作跳到Run状态：

调用ComM_CommunicationAllowed()将要通信的通道设为TRUE，设为TRUE后ComM的网络通道模式就会从COMM_NO_COM_REQUEST_PENDING变为COMM_FULL_COMMUNICATION了然后收发正常。
启动ESH_SelfRunRequestTimer定时器，将定时器状态设为START，超时时间设为0.1S。
调用BswM_ESH_OnEnterRun() callout函数，用户可添加进入Run前的自定义代码。
调用EcuM_SetState()将EcuM状态切换为ECUM_STATE_APP_RUN。
将模式切换接口ESH_ModeSwitch设为RUN即通知SWC ESH的模式为RUN了。
调用BswM_RequestMode()将ESH_State变为ESH_RUN表示ESH状态已经切换到Run了。

如果规则评估为FALSE则会执行：

执行ESH_PostRunToPrepNested规则，该规则是进入Shutdown前的准备工作处理。

5、ESH_PostRunToPrepNested

此规则生成的代码如下：


通过配置来看，此规则功能是当ESH状态进入PostRun后如果没有请求进入Run状态的话去判断要不要进入Prepare Shutdown状态，进入后去关闭一些模块：

当检测到ESH_PostRunRequest_0和ESH_PostRunRequest_1为RELEASED即SWC有是否PostRun的请求，
并且检测到ESH_EcuMRequest_POSTRUN为RELEASED即EcuM的接口EcuM_ReleasePOST_RUN()被调用释放POST_RUN请求，
并且判断ESH_DemPostRunRequested是否为FALSE，是的话代表Dem已经存储完NVM的话，该规则会执行以下动作并且进入Prepare Shutdown状态：

调用Rte_Stop()停止SWC的任务调度。
调用Dem_Shutdown()关闭Dem模块。
调用BswM_RequestMode()将ESH_DemInitStatus变为DEM_NOT_INITIALIZED。
调用BswM_ESH_OnEnterPrepShutdown() callout供用户添加自定义代码。
调用EcuM_SetState()将EcuM状态切换为ECUM_STATE_SHUTDOWN。
将模式切换接口ESH_ModeSwitch设为SHUTDOWN即通知SWC ESH的模式为SHUTDOWN了。
调用BswM_RequestMode()将ESH_State变为ESH_PREP_SHUTDOWN表示ESH状态已经切换到Prepare Shutdown了。

6、ESH_PrepToWait

此规则生成的代码如下：


通过配置来看，此规则功能是当ESH状态进入PrepareShutdown后去执行一些关闭前动作如保存NVM，然后跳到WaitforNvM状态：

当检测到ESH_State为ESH_PREP_SHUTDOWN即ESH状态从PostRun切到PrepareShutdown，
并且模式切换通知接口ESH_ModeNotification为SHUTDOWN，
并且EcuM状态为ECUM_STATE_SHUTDOWN或者ECUM_STATE_SLEEP即EcuM处于SHUTDOWN Phase和SLEEP Phase时，该规则会执行：

启动ESH_NvM_WriteAllTimer定时器，将定时器状态设为START，超时时间设为60S。
调用NvM_WriteAll()执行NVM写操作。
调用BswM_ESH_OnEnterWaitForNvm() callout用户可以在这里面添加自定义代码，如等待Nvm写操作完成。
判断ComM的网络通道是否处于COMM_NO_COM_NO_PENDING_REQUEST状态，是的话调用BswM_RequestMode()将将ESH_ComMPendingRequests设为ESH_COMM_PENDING_REQUEST否则设为ESH_COMM_NO_REQUEST。
调用BswM_RequestMode()将ESH_State变为ESH_WAIT_FOR_NVM表示ESH状态已经切换到WaitforNvM了。

7、ESH_RunToPostRun

此规则生成的代码如下：


通过配置来看，此规则功能是当ESH状态处于Run状态时判断要不要进入PostRun状态，如果触发进入的话执行相关动作：

当检测到ESH_State为ESH_RUN即ESH状态处于Run状态，
并且模式切换通知接口ESH_ModeNotification为RUN，
并且EcuM状态为ECUM_STATE_APP_RUN即EcuM处于RUN状态，
并且ComM的网络通道处于COMM_NO_COMMUNICATION模式即网络请求已释放，
并且检测到ESH_RunRequest_0为RELEASED即SWC有是否释放Run的请求，
并且检测到ESH_EcuMRequest_RUN为RELEASED即EcuM的接口EcuM_Release_RUN()被调用释放RUN请求，
并且判断ESH_SelfRunRequestTimer定时器是否超时（该定时器超时时间为0.1S，在ESH PostRun跳到Run时启动，防止ESH从PostRun跳到Run后又马上跳到PostRun进入PrepareShutdown）时，该规则会执行：

进入临界区。
判断ComM的网络通道是否处于COMM_NO_COM_NO_PENDING_REQUEST状态，是的话调用BswM_RequestMode()将将ESH_ComMPendingRequests设为ESH_COMM_PENDING_REQUEST否则设为ESH_COMM_NO_REQUEST。
执行ESH_RunToPostRunNested规则。
退出临界区。

8、ESH_RunToPostRunNested

此规则生成的代码如下：

通过配置来看，此规则功能是当ESH状态处于Run状态时满足条件要进入PostRun状态时，执行相关动作并将ESH切换到PostRun：

当检测到ESH_ComMPendingRequests为ESH_COMM_NO_REQUEST即表示ComM的网络通道是否处于COMM_NO_COM_REQUEST_PENDING状态，不是的话（网络通道释放）该规则会执行以下动作并且跳到Run状态：

调用ComM_CommunicationAllowed()将要通信的通道设为FALSE。
调用EcuM_ClearValidatedWakeupEvent()将EcuM的有效事件都清除（进入休眠前需要清除唤醒事件）。
调用BswM_ESH_OnEnterPostRun() callout供用户添加自定义代码。
调用EcuM_SetState()将EcuM状态切换为ECUM_STATE_APP_POST_RUN。
将模式切换接口ESH_ModeSwitch设为POSTRUN即通知SWC ESH的模式为POSTRUN了。
调用BswM_RequestMode()将ESH_State变为ESH_POST_RUN表示ESH状态已经切换到PostRun了。

9、ESH_WaitToShutdown

此规则生成的代码如下：

通过配置来看，此规则功能是当ESH状态从PrepareShutdown切换到WaitforNvM后判断NvM是否处理完毕，处理完成后执行关机目标即睡眠或关闭：

当检测到ESH_State为ESH_WAIT_FOR_NVM，
并且检测NvM模块是否没有任务在执行或者判断ESH_NvM_WriteAllTimer定时器是否超过60S（防止NvM模块一直在工作，该定时器在进入ESH Prepare Shutdown状态时开启），
并且调用EcuM_GetValidatedWakeupEvents()判断是否没有有效的唤醒事件，
并且ESH_ComMPendingRequests是否为ESH_COMM_NO_REQUEST，则该规则会执行以下动作：

停止ESH_NvM_WriteAllTimer定时器，将定时器状态设为STOP。
调用BswM_ESH_OnEnterShutdown() callout供用户添加自定义代码。
调用EcuM_GoToSelectedShutdownTarget()执行关机目标，进入Sleep（Poll或Halt）或Shutdown（vector代码里才有这个）。

10、ESH_WaitToWakeup

此规则生成的代码如下：

通过配置来看，此规则功能是当ESH状态处于WaitforNvM时，如果有通信请求或检测到有效验证的唤醒事件则不休眠进入WakeUp状态：

当检测到ESH_State为ESH_WAIT_FOR_NVM，
并且调用EcuM_GetValidatedWakeupEvents()判断是否有有效的唤醒事件或者ESH_ComMPendingRequests是否为ESH_COMM_PENDING_REQUEST（即有通信请求），则该规则会执行以下动作：

停止ESH_NvM_WriteAllTimer定时器，将定时器状态设为STOP。
启动ESH_NvM_CancelWriteAllTimer定时器，将定时器状态设为START，超时时间设为60S。
调用NvM_CancelWriteAll()取消写任务（在休眠时被唤醒通常有紧急任务所以先取消）。
调用BswM_ESH_OnEnterWakeup() callout供用户添加自定义代码。
将模式切换接口ESH_ModeSwitch设为WAKEUP即通知SWC ESH的模式为WAKEUP了。
调用BswM_RequestMode()将ESH_State变为ESH_WAKEUP表示ESH状态已经切换到WakeUp了。

11、ESH_WakeupToPrep

此规则生成的代码如下：

通过配置来看，此规则功能是当ESH状态处于WakeUp时，如果没有通信请求和唤醒事件则继续进入SHUTDOWN模式：

当检测到ESH_State为ESH_WAKEUP状态，
并且检测NvM模块是否没有任务在执行或者判断ESH_NvM_CancelWriteAllTimer定时器是否超过60S（防止NvM模块一直在工作，该定时器在WaitforNvM状态跳到WakeUp状态时开启），
并且调用EcuM_GetPendingWakeupEvents()检测是否没有待处理的唤醒事件，
并且调用EcuM_GetValidatedWakeupEvents()检测是否没有有效唤醒事件和ESH_ComMPendingRequests是否为ESH_COMM_NO_REQUEST（即没有通信请求），
并且模式切换通知接口ESH_ModeNotification为WAKEUP，则该规则会执行以下动作：

调用BswM_ESH_OnEnterPrepShutdown() callout供用户添加自定义代码。
调用EcuM_SetState()将EcuM状态切换为ECUM_STATE_SHUTDOWN。
将模式切换接口ESH_ModeSwitch设为WAKEUP即通知SWC ESH的模式为SHUTDOWN了。
调用BswM_RequestMode()将ESH_State变为ESH_PREP_SHUTDOWN表示ESH状态已经切换到PrepareShutdown了。

12、ESH_WakeupToRun

此规则生成的代码如下：


通过配置来看，此规则功能是当ESH状态处于WakeUp时，如果有通信请求和唤醒事件则切换到进入RUN模式：

当检测到ESH_State为ESH_WAKEUP状态，
并且调用EcuM_GetValidatedWakeupEvents()检测是否有有效唤醒事件和ESH_ComMPendingRequests是否为ESH_COMM_PENDING_REQUEST（即有通信请求），
并且检测NvM模块是否没有任务在执行或者判断ESH_NvM_CancelWriteAllTimer定时器是否超过60S（防止NvM模块一直在工作，该定时器在WaitforNvM状态跳到WakeUp状态时开启），
并且模式切换通知接口ESH_ModeNotification为WAKEUP，则该规则会执行以下动作：

停止ESH_NvM_CancelWriteAllTimer定时器，将定时器状态设为STOP。
执行ESH_DemInit规则。
调用ComM_CommunicationAllowed()将要通信的通道设为TRUE。
启动ESH_SelfRunRequestTimer定时器，将定时器状态设为START，超时时间设为0.1S。
调用BswM_ESH_OnEnterRun() callout函数供用户添加自定义代码。
调用EcuM_SetState()将EcuM状态切换为ECUM_STATE_APP_RUN。
将模式切换接口ESH_ModeSwitch设为RUN即通知SWC ESH的模式为RUN了。
调用BswM_RequestMode()将ESH_State变为ESH_RUN表示ESH状态已经切换到Run了。

（三）、Communication Control

BswM可以配置通信的开启关闭，因为ECU有很多场景下会控制通信，通信报文主要是应用报文和网络管理报文，比如在网络管理状态切换时、收到诊断28服务时、有PNC请求时、CAN BUSOFF时（CanSM里已经处理通信）等，这些都可以通过BswM调度去控制通信。

1、应用报文接收

上面两个规则生成的代码如下：

当检测CanSM的网络通道模式不为NO_COMMUNICATION时，调用Com_IpduGroupStart()使能接收的IPDU组，即这些IPDU是接收报文，Com模块会更新这些IPDU，否则调用Com_IpduGroupStop()停止接收IPDU组。
当检测CanSM的网络通道模式为FULL_COMMUNICATION时，调用Com_EnableReceptionDM()使能接收的IPDU组的接收监控，否则调用Com_DisableReceptionDM()停止接收IPDU组的接收监控，因为只有在FULL_COMMUNICATION时，说明总线上在通信，别的ECU会发报文，那么因为别的ECU在发报文，这时候可以开启接收监控。

2、应用报文发送

该规则生成的代码如下：



当检测CanSM的网络通道模式不为FULL_COMMUNICATION时，调用Com_IpduGroupStart()使能发送的IPDU组，否则调用Com_IpduGroupStop()停止发送IPDU组。

（四）、BswMTimer

BswM里有定时器功能，可以在某个动作触发后延时执行，那么就需要用到定时器。

首先在BswMModeRequestPorts里定义定时器：

RequestProcessing必须为DEFERRED。初始值也必须为STOPPED。

BswMModeConditions里也要配置模式条件，并且引用之前配置好的定时器：



这里表示定时器值不等于STARTED时为TRUE。

定时器触发需要在Actions里配置：


这里表示该动作执行后将之前的请求源定时器变为START，然后该定时器会在1S后又变为BSWM_TIMER_EXPIRED。

之后可以将该动作放在某个规则里，该规则执行该动作后并且触发定时器条件，然后再定义某个延时动作规则，在定时器触发后执行该延时动作规则。

（五）、Dcm请求复位

十三、参考资料

AUTOSAR_CP_SWS_BSWModeManager
AUTOSAR_EXP_LayeredSoftwareArchitecture
AUTOSAR_CP_EXP_ModeManagementGuide
AUTOSAR_CP_SRS_ModeManagement
AUTOSAR_CP_SRS_BSWGeneral
AUTOSAR_CP_SWS_BSWGeneral
AUTOSAR_CP_SWS_RTE
AUTOSAR_CP_TPS_SoftwareComponentTemplate
AUTOSAR_CP_RS_BSWModuleDescriptionTemplate
TechnicalReference_BswM

---

总结

本文文字描述多点，更像是本人的使用笔记，仅供参考，如有不对地方欢迎指教。