前言
首先，请问大家几个小小问题，你清楚：
- 你知道BswM是做甚的吗？
- 常说的APP Mode或者System状态机与BswM关系又是如何的呢？
- BswM模块作为AUTOSAR的一个标准模块，内部工作机制如何实现？
- BswM与各SW-C以及各个BSW模块又是如何交互的呢？
- 。。。
今天，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：
正文
总体设计框架
顾名思义，BswM全称为基础软件管理模块（即Bsw Management）。该模块根据来自BSW或者SW-C特定的输入，在满足一定的规则条件下执行直接对各个BSW模块的序列化操作。从我刚刚总结的话语中不难得出BswM具有以下三个显著的特点：
- 输入来源于各SW-C或者各BSW模块；
- 执行时需要满足一定的规则条件；
- 实现对各BSW模块的序列化操作；
按照AUTOSAR规范，我们可以将前两者叫做模式仲裁过程，而最后的步骤称为模式控制过程。
为了便于大家理解，首先分别针对上述模式仲裁过程与模式控制过程做总体性介绍。
模式仲裁过程
如下图1所示，BswM模块将会接收来自SW-C或者BSW模块的Mode Request或者Mode Indication作为模式仲裁的两种输入方式。通常Mode Request来源于SW-C模块，当然也不排除BSW模块，比如DCM请求ComM进行full communication的时候。Mode Indication则总是来源于BSW模块，比如CANSM，EcuM，WdgM等。
在图中也可以看到定义了模式请求的一些规则条件，如只有Normal_Mode为TRUE且IFC1_Bus_Off为False时，条件成立为TRUE，其他情况则为False。由此可见，模式仲裁过程中的规则条件也就是真值表达式，而真值表达式的结果就是模式仲裁之后的结果，并作为下一环节模式控制过程的输入。
图1 模式仲裁过程
上述过程中提到的Mode Indication 与 Mode Request都是以同等的地位在BswM中接收仲裁，且这两种类型都可以在AUTOSAR标准配置项BswMModeRequestSource得以体现。
同时BswM模块会通过调用其他BSW模块如EcuM，COM，ComM，SM，PduR的标准接口来获取每个模块的当前状态作为模式仲裁的输入。但需要注意的是如果在调用这些标准接口之后返回的结果为错误（E_NOT_OK），那么BswM模块可以设置DTC来告知上层这一错误或者取消当前正在执行的Action List。
模式控制过程
模式控制指的是基于上述上述模式仲裁的结果（TRUE or FALSE）执行相应的行为序列。这些行为序列通常称为“Action List”，且这些Action List都是有序的，也就意味着可根据项目需要自由配置各类Action的执行顺序。
图2 模式控制过程
如上图2所示, 每一个Action List可以对应1个或者多个行为，AUTOSAR支持实现不同行为的自由组合与复用。每一种行为都可以分为以下三种方式来实现：
- 直接调用其他BSW模块或者RTE模块的标准接口来实现一系列的控制（即BSWM_ATOMIC）；
- ComM：设置对应通信接口的通信模式或允许在对应的通道上通信；
- COM：实现IPDU报文的切换；（带有初始值或者不带有初始值）；
- COM: 使能或者关闭信号的deadline timeout monitoring；
- NM：开启或者关闭NM通信；
- 链接其他Action List中的内容（即BSWM_LIST）；
- 执行某些仲裁规则（即BSWM_RULE）；
除此以外，模式控制在可控制多个行为的同时，也可以通过ID号来保证各个Action的执行顺序，所以说Action List是有序行为列表。某些仲裁规则可以作为从属规则成为某个主规则的Action List的一员。
从整体上介绍了模式仲裁与模式控制的过程之后，相信大家对BswM模块的控制流有了基本的了解。接下来，将针对模式仲裁与模式控制过程中的具体细节信息展开讲述，以便大家对BswM模块的配置过程能够更为清晰。
模式仲裁
模式请求来源(ModeRequestPorts)
模式请求来源指的是模式仲裁过程中需要判断的数据源是什么，而这些数据源的获取都是已定义好的标准接口，你只需要进行相应配置就能完成针对其他Bsw模块数据获取，即BswM会提供并生成相应的函数接口来获取对应Bsw模块的数据输入，举例说明常见的数据请求来源如下表1所示：
表1 模式请求来源举例
针对上述的模式请求来源，BswM存在以下两种方式去查询这些请求来源的状态：
- 事件触发型
- 在该模式下，只有接收到Mode Indication或者Mode Request才会执行，适用于模式请求来源数据变化不大较为稳定的场合；
- 轮询遍历型
- 在该模式下，BswM会在自身Mainfunction函数中主动查询Mode Indication以及Mode Reqest的状态，适用于Indication或者Request变化较为频繁的场合，一般情况下，都可以直接采用该模式去查询请求数据来源的状态；
上述两种状态可通过配置参数BswMRequestProcessing来进行选择。
模式条件(ModeCondition)
模式条件指的是根据上述模式请求来源与设定的值相比较的单一表达式。比如若模式请求来源为X，N为设定的常量状态，那么模式条件就是配置X ==N或者X ！=N的表达式。
逻辑表达式(LogicExpressions)
逻辑表达式是相比模式条件而言,它可以实现多个模式条件的逻辑组合。举例说明如下：
若Logic Expression仅需要两个Mode Indication 1与Mode Indication 2的逻辑组合，当然理论上可支持n个单一表达式的逻辑组合，取决于实际情况的需要。
Mode Condition 1： X == 3；
Mode Condition 2： Y == 4；
Logic Expression A = （Mode Condition 1 (OR或AND或XOR或NAND)Mode Condition 2 ）；
模式规则(ModeRules)
模式规则指的是根据上述逻辑表达式的结果（TRUE or FALSE）来执行相应的Action List。也就意味着模式规则是为了实现逻辑表达式与相应Action List 的Mapping关系。
为了对模式仲裁过程中的三大构件（模式请求来源、模式条件、逻辑表达式）的相互reference关系及执行对应关系有个更好的理解，如下图3所示则较为清晰地表示了彼此之间的关联关系。
图3 模式仲裁三大构件的组织关系
模式规则的初始化
模式规则可以设定其Map的逻辑表达式的结果初始值为TRUE或者FALSE，以便默认执行相应的Action List。
该初始值可通过参数BswMModeInitValue来进行配置，同时该参数属于BswMRules的子参数。如果没有配置初始值，则模式仲裁的初始值处于undefined的状态，在该状态下意味着BswM在完成其初始化之后默认就会执行一次。绝大多数情况下，模式规则的初始值为FALSE。
模式控制
模式控制基本流程
模式控制基本流程就是根据模式仲裁的结果去执行相应的Action List。如下图4所示，以SW-C组件模式请求为例：
- S1：SW-C通过sender port经由RTE向BswM模块发送模式请求信息；
- S2：BswM模块通过receive port接收请求并根据已配置好的模式仲裁规则得出相应的仲裁结果；
- S3：执行相应的Bsw相关的Action List及RTE状态切换；
- S4：经过RTE传输的状态将会传递给到需要使用该模式的SW-C以及返回请求该模式的SW-C；
图4 模式控制基本过程
模式行为
模式行为作为模式控制的基本执行单元，在执行Action List的过程中也存在着以下两种方式：
- 循环执行（BswM_Condition），只要模式仲裁规则成立，一直连续不断的执行;
- 事件触发（BswM_Trigger），仅在模式规则变化的情况下，才会去执行相应的Action List；
这两种执行方式可以通过模式控制过程中的参数BswMActionListExecution来进行配置。
图5 模式行为的触发方式
如上图5展示了BswMruleInitValue与模式行为的触发方式在不同组合情况下执行Action List的结果，以便我们在配置过程中能够注意到它们之间的关联。
需要注意的是如果在执行Action List的过程中返回结果为E_NOT_OK，那么BswM模块应当终止Action List的执行，如果需要实现，那么需要设置配置参数BswMAbortOnFail结果为TRUE。
在模式控制的配置选项中，一般会存在BswMAction与BswMActionList两类选项，解释如下：
- BswMAction: 则用来配置各种各样标准的行为；（如Com模块报文切换等）
- BswMActionList: 用来定义action的集合（即从BswMAction中取任意个自由组合）；
常用函数接口
为了更好的使用该模块函数以及遇到问题时方便调试该模块，特将BswM模块中较为重要的常用函数列举如下表2所示。
表2 Bsw模块常用函数列表