BswM配置介绍

hudaren43

01

简介

AUTOSAR在做模式管理时，通过bswm将其他模块的信息收集起来，统一的做模式的切换。

02

配置项

配置项来看，autosar的模块一般都是分为 General 和 Config 2个部分；

1

General

在bswm中，General配置是当前哪些模块需要关联bswm做管理，常见的有NvM、DCM、CanSM、Eth、Lin相关模块的Enable。

2

Config

主要关联于需求的配置模块在Config里，其中包含模式控制、数据类型匹配、仲裁：

模式控制就是当模式请求之后配置的具体执行函数，选项很多，可以用户自定义也可以调用autosar的标准接口；

数据类型匹配即是 moderequestport 的数据类型，可以在 Software->Infrastructure->Mode Declaration中去配置自己想要的新枚举类型；

仲裁中的子配置项较多，又分为：LogicalExpression、ModeConditions、ModeRequestPort、Rule,咱们下面的篇幅都是介绍仲裁的方式。

仲裁用一句绕口而又官方的话来说：

模式请求接口将模式数据给到模式条件做判断，之后送到逻辑表达式进行仲裁，最后根据仲裁的结果进行相应功能的触发。

以BswMRule为框架，根据配置框和伪代码来看，这句话可以这么理解：



/* '==' 在condition中可配置 == 或 != */#define Expression (ModeConditionVale == ModeRequestPort)if (Expression1 && Expression2) /* 表达式的个数、逻辑关系可配置 */{    TrueActionList();}else{    FalseActionList();}
03

关键变量

1

BswM_Config



不单单是这个结构体，其实仔细比对很多生成出来的结构体或者数组，生成出来的东西和工具里的配置项都是一一对应的上的，方便我们去理解对应功能的实现吧。

2

Action Function Point Array



3

Queue



队列中没有待执行的bsw任务时结构体的状态。

4

Action List



5

Request Mode Info



04

代码分析

以moderequestport配置的是 BswMGenericRequest为例， 咱们看看软件的具体实现，首先是请求的函数形参分析：
FUNC(void, BSWM_CODE) BswM_RequestMode(VAR(BswM_UserType, AUTOMATIC) requesting_user,VAR(BswM_ModeType, AUTOMATIC) requested_mode)

其中requesting_user 填充



requested_mode咱们需要根据自己的需要，填充



中配置的值。

函数首先会校验一下咱们填入的形参与config配置生成的结构体内容是否有冲突，

之后如果bswm当前没、有rule在被执行，则 BswM_Prv_IntrptQueueIn() 会将当前的request_user存储入队列，没有其他任务时，

BswM_Prv_flgNewReqstProgress_b = 1 ，

会最终执行函数 BswM_Prv_RuleEval()。



此时，如果配置的是deferred，则调用BswM_Prv_StoreDeferredRequest 存储入队列，到bsw的mainfunction中去执行，如果配置的是immediate，则调用BswM_Prv_Arbitrate_Rule立即执行action。



这边可以看下BSWM的源代码与咱们写的伪代码 之间的差异。苟以为大体上还是差不多的吧，哈哈

而最后的最后 action的执行函数如下，可以在关键变量的小节中

static CONST(BswM_Action_FuncPtr_t,BSWM_CONST)

BswM_Prv_AC_BswMActionFunction_FunPtr_cafct[BSWM_ACTIONLIST_SIZE] 变量去寻找对应的函数名称打断点调试啦。