AUTOSAR BswM规范解析（一）

持续更新中…

1 引言与功能概述

本规范规定了 AUTOSAR 基础软件模块——基础软件模式管理器（BSW Mode Manager，简称 BswM）的功能、应用程序接口（API）及配置要求。

基础软件模式管理器是在基础软件（BSW）中实现车辆模式管理和应用模式管理概念相关功能的模块。其核心职责是依据简单规则，对来自应用层软件组件（SW-C）或其他基础软件模块的模式请求进行仲裁，并根据仲裁结果执行相应操作。

2 缩略语与简称

缩略语/简称
BSW
BswM
BSWMD
CDD
Dem
Det
ECU
ICOM
RTE
SWC / SW-C
SWCD

3 相关文档

3.1 输入文档

[1] 《基础软件模块列表》（AUTOSAR_TR_BSWModuleList.pdf）
[2] 《分层软件架构》（AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf）
[3] 《基础软件模块通用需求》（AUTOSAR_SRS_BSWGeneral.pdf）
[4] 《模式管理需求》（AUTOSAR_SRS_ModeManagement.pdf）
[5] 《通信规范》（AUTOSAR_SWS_COM.pdf）
[6] 《FlexRay 状态管理器规范》（AUTOSAR_SWS_FlexRayStateManager.pdf）
[7] 《PDU 路由器规范》（AUTOSAR_SWS_PDURouter.pdf）
[8] 《ECU 配置规范》（AUTOSAR_TPS_ECUConfiguration.pdf）
[9] 《默认错误跟踪器规范》（AUTOSAR_SWS_DefaultErrorTracer.pdf）
[10] 《运行时环境（RTE）软件规范》（AUTOSAR_SWS_RTE.pdf）
[11] 《诊断通信管理器规范》（AUTOSAR_SWS_DiagnosticCommunicationManager.pdf）
[12] 《ECU 状态管理器规范》（AUTOSAR_SWS_ECUStateManager.pdf）
[13] 《LIN 状态管理器规范》（AUTOSAR_SWS_LINStateManager.pdf）
[14] 《CAN 状态管理器规范》（AUTOSAR_SWS_CANStateManager.pdf）
[15] 《通用网络管理接口规范》（AUTOSAR_SWS_NetworkManagementInterface.pdf）
[16] 《通信管理器规范》（AUTOSAR_SWS_COMManager.pdf）
[17] 《以太网状态管理器规范》（AUTOSAR_SWS_EthernetStateManager.pdf）
[18] 《基础软件模块通用规范》（AUTOSAR_SWS_BSWGeneral.pdf）

3.2 相关标准与规范

无相关标准与规范。

3.3 相关规范

AUTOSAR 提供了《基础软件模块通用规范》[18]（SWS BSW General），该规范同样适用于基础软件模式管理器。因此，《基础软件模块通用规范》应被视为基础软件模式管理器的附加必备规范。

关于基础软件模式管理器的配置和使用信息，可参考辅助文档：《AUTOSAR_EXP_ModemanagementGuide.pdf》。

4 约束与假设

4.1 限制条件

在一个分区内，最多只能使用一个基础软件模式管理器实例。

4.2 汽车领域适用性

基础软件模式管理器适用于所有汽车领域。

5 与其他模块的依赖关系

基础软件模式管理器（BswM）与 AUTOSAR 架构中的多个基础软件（BSW）模块存在接口关联。不过，这些接口中的大部分为可选接口，是否使用需根据各电子控制单元（ECU）的需求来决定。

本章列出的依赖关系旨在概述 BswM 与其他模块之间可能存在的部分交互情况，不应将此处列出的交互内容和模块视为所有可能情况的完整清单。

5.1 运行时环境（RTE）

BswM 通过 RTE 接收来自软件组件（SW-C）的模式请求，同时也会通过 RTE 将模式切换通知传递给 SW-C。

5.2 ECU 状态管理器 - 灵活版（EcuM - Flex）

EcuM 灵活版可向 BswM 指示其唤醒源的状态。当使用 ECU 模式处理功能时，BswM 可设置 EcuM - Flex 的状态，并根据运行请求协议（RUN Request Protocol）接收特定模式的状态信息。

5.3 watchdog 管理器（WdgM）

WdgM 可通过 BswM_WdgM_RequestPartitionReset 应用程序接口（API）向 BswM 请求与分区重置相关的操作。WdgM 分区重置请求的配置通过 BswMWdgMRequestPartitionReset 模式请求源完成。

5.4 通信管理器（ComM）

源自 ComM 的模式切换指示会经由 BswM 进一步传递给 SW-C。BswM 可通过 ComM 用户（ComMUsers）向 ComM 请求通信模式。

5.5 通信模块（COM）

COM 中 I-PDU 组的处理由 BswM 负责。在 I-PDU 组启动/停止过程中，可将所含信号值重置为其对应的初始化值。

BswM 负责启用和禁用 COM 中信号的截止期限监控功能，此外，BswM 还可触发 I-PDU 的传输。

5.6 PDU 路由器（PduR）

BswM 可启用和禁用 PDU 路由器中 I-PDU 的路由组。

5.7 CAN 状态管理器（CanSM）

源自 CanSM 的模式切换指示会经由 BswM 进一步传递给 SW-C。

5.8 LIN 状态管理器（LinSM）

BswM 会协调 LinSM 中 LIN 调度表的切换与 COM 中对应 I-PDU 组的启动和停止操作。

源自 LinSM 的模式切换指示会经由 BswM 进一步传递给 SW-C。

5.9 LIN 传输协议（LinTp）

作为 LinIf 组成部分的 LIN 传输协议会向 BswM 请求模式，以确保在 LinTp 运行期间有正确的 LIN 调度表处于激活状态。

5.10 FlexRay 状态管理器（FrSM）

源自 FrSM 的模式切换指示会经由 BswM 进一步传递给 SW-C。

FlexRay 上“单时隙模式”（Single Slot Mode）的使用由 FrSM 根据 BswM 的请求进行控制。BswM 可通过调用 API（FrSM_SetEcuPassive），经由 FrSM 控制 FlexRay 协议栈的发送能力。

5.11 以太网状态管理器（EthSM）

源自 EthSM 的模式切换指示会经由 BswM 进一步传递给 SW-C。

5.12 诊断通信管理器（DCM）

DCM 会根据接收到的诊断请求向 BswM 发起模式请求。

示例：DCM 可请求“禁用正常通信”（Disable Normal Communication）模式。在此模式下，BswM 会关闭相应的 I-PDU 组和网络管理（NM）PDU。

5.13 J1939 诊断通信管理器（J1939Dcm）

J1939Dcm 会将通信状态变化情况报告给 BswM，再由 BswM 进一步传递给 SW-C。BswM 通过调用 J1939Dcm_SetState 来改变 J1939Dcm 的状态。

5.14 J1939 网络管理器（J1939Nm）

J1939Nm 通过 BswM_J1939Nm_StateChangeNotification 提供状态指示。

5.15 J1939 请求管理器（J1939Rm）

BswM 通过调用 J1939Rm_SetState 来改变 J1939Rm 的状态。

5.16 网络管理接口（NM Interface）

BswM 会使用 Nm_EnableCommunication 和 Nm_DisableCommunication 接口，根据当前模式控制 NM 通信。

示例：在“禁用正常通信”模式下，BswM 需要在相应的 NM 通道上禁用 NM 通信。

Nm 会通过 BswM_Nm_CarWakeUpIndication 指示车辆唤醒（CarWakeup）事件。

5.17 非易失性存储器管理器（NvM）

NvM 模块会通过注册为 NvM 回调函数的“集成代码”（integration code），向 BswM 报告其块（block）的状态。BswM 具有在启动和关闭期间触发 NvM 读取和写入所有块的操作。

5.18 操作系统（OS）

BswM 所需的 OS 功能取决于具体的实现方式。

5.19 服务发现（Sd）

BswM 通过多个导出的 API（示例可参见第 8.3 章）接收来自 Sd 的状态指示。这些来自 Sd 的状态指示可配置为 BswMModeRequestSource。

5.20 文件结构

BswM 可使用 AUTOSAR BSW 模块中的接口，即便这些接口未在本规范中明确定义。

6 Requirements traceability

略

7 功能规范

本章规定了基础软件模式管理器（BSW Mode Manager，BswM）的功能行为。基础软件模式管理器基础功能的运行可分为两个不同的任务：模式仲裁（Mode Arbitration）和模式控制（Mode Control）。

模式仲裁部分会根据来自软件组件（SW-C）或其他基础软件（BSW）模块的、基于规则的模式请求和模式指示，触发模式切换。

模式控制部分通过执行动作列表（包含其他基础软件模块的模式切换操作）来完成模式切换。

基础软件模式管理器（BswM）应被视为一个模式管理框架模块，其行为完全由自身配置定义。

基础软件模式管理器（BswM）的实现方式可能存在差异，例如基于配置生成完整的BswM，或作为在运行时解析编码配置的规则解释器。

然而，本规范并不打算规定基础软件模式管理器（BswM）的任何实现细节。因此，本文档中所有描述设计细节的示例均应仅作为说明性文本，而非需求。

7.1 模式仲裁

基础软件模式管理器（BswM）执行的模式仲裁基于简单规则。模式仲裁所使用的规则在基础软件模式管理器模块的配置中规定。

这些规则由简单的布尔表达式构成，因此模式仲裁对运行时的影响预计较低。

为了确定要执行哪些动作列表，基础软件模式管理器（BswM）需要检测模式仲裁结果与之前规则评估结果的差异。具体的检测方式以及存储结果所需的内存，属于实现相关内容，本文档不做描述。

7.1.1 仲裁规则

规则是由一组模式请求条件构成的逻辑表达式。当输入的模式请求和模式指示发生变化时，或在基础软件模式管理器（BswM）主函数执行过程中，会对规则进行评估。评估结果（真或假）将用于决定是否执行相应的模式控制动作列表。

7.1.2 模式条件与逻辑表达式

构成模式仲裁规则的逻辑表达式可使用“与（AND）”、“或（OR）”、“异或（XOR）”、“非（NOT）”、“与非（NAND）”等不同运算符。表达式中的每一项都对应一个模式请求条件。若模式条件引用了BswMModeRequestPort（模式请求端口），则该条件会验证请求或指示的模式是否等于（EQUAL）或不等于（NOT_EQUAL）某个特定模式；若模式条件引用了BswMEventRequestPort（事件请求端口），则该条件会验证请求端口处于置位（SET）还是清零（CLEAR）状态。

BswMEventRequestPort（事件请求端口）的事件请求与模式请求不同：事件请求的发起方向基础软件模式管理器（BswM）发送请求时，不会附带请求的模式/值，因此基础软件模式管理器（BswM）无需对模式条件进行评估，只需评估是否接收到事件即可。当发起方发送/调用事件时，BswMEventRequestPort（事件请求端口）会进入置位（SET）状态；之后，基础软件模式管理器（BswM）可通过执行BswMClearEventRequest（事件请求清零）动作，将BswMEventRequestPort（事件请求端口）置为清零（CLEAR）状态。

包含两个条件的规则示例如图1所示。规则及可用逻辑运算的集合在第10.2章所述的ECU配置中定义。

（图1：包含两个条件的规则伪代码表示）

[SWS_BswM_00252]
当BswMModeCondition（模式条件）的BswMConditionType（条件类型）设为BSWM_EVENT_IS_SET（事件已置位），且引用了某个BswMEventRequestPort（事件请求端口）时：

• 若该BswMEventRequestPort（事件请求端口）处于置位（SET）状态，则BswMModeCondition（模式条件）的评估结果应为真（TRUE）；
• 若该BswMEventRequestPort（事件请求端口）处于清零（CLEAR）状态，则BswMModeCondition（模式条件）的评估结果应为假（FALSE）。
  ⌋(SRS_ModeMgm_09180, SRS_ModeMgm_09177)

[SWS_BswM_00253]
当BswMModeCondition（模式条件）的BswMConditionType（条件类型）设为BSWM_EVENT_IS_CLEARED（事件已清零），且引用了某个BswMEventRequestPort（事件请求端口）时：

• 若该BswMEventRequestPort（事件请求端口）处于置位（SET）状态，则BswMModeCondition（模式条件）的评估结果应为假（FALSE）；
• 若该BswMEventRequestPort（事件请求端口）处于清零（CLEAR）状态，则BswMModeCondition（模式条件）的评估结果应为真（TRUE）。
  ⌋(SRS_ModeMgm_09180, SRS_ModeMgm_09177)

[SWS_BswM_00254]
当基础软件模式管理器（BswM）在已配置的BswMEventRequestPort（事件请求端口）上接收到事件时（例如，通信管理器（ComM）调用BswM_ComM_InitiateReset()函数），应将该BswMEventRequestPort（事件请求端口）置为置位（SET）状态。⌋(SRS_ModeMgm_09180)

[SWS_BswM_00255]
当对某个BswMEventRequestPort（事件请求端口）执行BswMClearEventRequest（事件请求清零）动作时，应将该BswMEventRequestPort（事件请求端口）置为清零（CLEAR）状态。⌋(SRS_ModeMgm_09180)

7.1.3 模式仲裁的需求

如前所述，基础软件模式管理器（BswM）接收模式请求和模式指示作为模式仲裁的输入。模式请求通常源自应用层软件组件（SW-C），但也可能源自诊断通信管理器（DCM）等其他基础软件（BSW）模块；模式指示则始终由CAN状态管理器（CanSM）、ECU状态管理器（EcuM）、看门狗管理器（WdgM）等其他基础软件（BSW）模块发出。在本文档中，“模式仲裁请求”这一通用术语既指模式指示，也指模式请求。

[SWS_BswM_00009]
基础软件模式管理器（BswM）应基于接收到的模式请求执行模式仲裁。⌋(SRS_ModeMgm_09180)

[SWS_BswM_00035]
基础软件模式管理器（BswM）应基于接收到的模式指示执行模式仲裁。⌋(SRS_ModeMgm_09180)

注：基础软件模式管理器（BswM）对所有模式仲裁请求（包括模式请求和模式指示）的处理方式相同。通过在BswMModeRequestSource（模式请求源）配置容器中选择相应的模式条件类型，即可完成对这些请求的配置。

[SWS_BswM_00010]
基础软件模式管理器（BswM）应使用已配置的规则执行模式仲裁。⌋(SRS_ModeMgm_09177)

[SWS_BswM_00012]
模式仲裁规则应能通过第10.2章所述的模块配置参数进行配置。⌋(SRS_ModeMgm_09177)

[SWS_BswM_00117]
基础软件模式管理器（BswM）不得将之前仲裁规则的评估结果用作逻辑表达式的输入。⌋(SRS_ModeMgm_09180)

注：需求[SWS_BswM_00117]的目的是禁止将规则评估结果用作其他规则评估的输入。该需求主要通过基础软件模式管理器（BswM）配置容器的现有结构来满足——逻辑表达式的可配置输入中，不包含之前规则评估的结果。

[SWS_BswM_00147]
评估基础软件模式管理器（BswM）仲裁规则后调用的动作，只能在动作列表的上下文中执行。⌋(SRS_ModeMgm_09178)

[SWS_BswM_00189]
基础软件模式管理器（BswM）应基于接收到的模式切换通知执行模式仲裁。⌋(SRS_ModeMgm_09180)

7.1.3.1 即时操作与延迟操作

模式仲裁的处理调度存在两种方式：一是在模式请求/指示的上下文中即时处理，二是延迟到基础软件模式管理器（BswM）的主函数中（周期性）处理。

“即时（Immediate）”请求在调用方的上下文中执行。系统集成商需确保动作列表的执行不会影响系统性能或一致性。
尤其需要注意的是，若调用方在中断上下文中运行（或可能在中断上下文中运行），则需遵守中断上下文中系统函数的使用限制。

即时操作与延迟操作的差异如图9.1和图9.2所示的时序图。

[SWS_BswM_00061]
模式仲裁规则可包含即时模式仲裁请求和延迟模式仲裁请求的任意组合。⌋(SRS_ModeMgm_09180)

[SWS_BswM_00013]
应能将基础软件模式管理器（BswM）配置为：在接收到模式仲裁请求后，即时执行模式仲裁。通过将BswMModeRequestPort（模式请求端口）容器中的BswMRequestProcessing（请求处理方式）配置参数设为BSWM_IMMEDIATE（即时），即可实现该配置。⌋(SRS_ModeMgm_09180)

[SWS_BswM_00059]
基础软件模式管理器（BswM）仅在特定模式请求/指示的上下文中，评估使用该特定即时模式条件的模式仲裁规则。⌋(SRS_ModeMgm_09180)

[SWS_BswM_00014]
也应能将模式仲裁延迟到基础软件模式管理器（BswM）主函数执行时处理。通过将BswMModeRequestPort（模式请求端口）容器中的BswMRequestProcessing（请求处理方式）配置参数设为BSWM_DEFERRED（延迟），即可实现该配置。⌋(SRS_ModeMgm_09180)

[SWS_BswM_00257]
应能将基础软件模式管理器（BswM）配置为：在事件置位时，即时执行模式仲裁。通过将BswMEventRequestPort（事件请求端口）容器中的BswMRequestProcessing（请求处理方式）配置参数设为BSWM_IMMEDIATE（即时），即可实现该配置。⌋(SRS_ModeMgm_09180)

[SWS_BswM_00258]
也应能将模式仲裁延迟到基础软件模式管理器（BswM）主函数执行时处理。通过将BswMEventRequestPort（事件请求端口）容器中的BswMRequestProcessing（请求处理方式）配置参数设为BSWM_DEFERRED（延迟），即可实现该配置。⌋(SRS_ModeMgm_09180)

[SWS_BswM_00060]
基础软件模式管理器（BswM）主函数每次执行时，都应评估所有至少包含一个延迟模式条件的规则。⌋(SRS_ModeMgm_09180)

[SWS_BswM_00068]
在基础软件模式管理器（BswM）主函数处理期间接收到的模式仲裁请求，应延迟至主函数处理完成后再处理。其中，延迟的“即时（IMMEDIATE）”请求应在基础软件模式管理器（BswM）主函数退出前直接处理；延迟的“延迟（DEFERRED）”请求应在基础软件模式管理器（BswM）下一次执行主函数时处理。⌋(SRS_ModeMgm_09180)

[SWS_BswM_00069]
在“即时（IMMEDIATE）”请求处理期间接收到的模式仲裁请求，应延迟至该“即时（IMMEDIATE）”请求处理完成后再处理。其中，延迟的“即时（IMMEDIATE）”请求应在原“即时（IMMEDIATE）”请求处理完成后直接处理；延迟的“延迟（DEFERRED）”请求应在基础软件模式管理器（BswM）下一次执行主函数时处理。⌋(SRS_ModeMgm_09180)

7.1.4 初始化后的仲裁行为

基础软件模式管理器（BswM）初始化后的模式仲裁行为，由BswMModeInitValue（模式初始值）配置容器控制。该参数可针对配置中的每个BswMModeRequestPort（模式请求端口）配置一次。

[SWS_BswM_00064]
若BswMModeInitValue（模式初始值）容器不存在，或模式请求（ModeRequest）尚无初始值，则基础软件模式管理器（BswM）应将相应的模式条件视为未定义，在该模式仲裁请求首次更新前，不将其用于模式仲裁。⌋(SRS_ModeMgm_09179, SRS_ModeMgm_09228, SRS_ModeMgm_09180)

[SWS_BswM_00241]
基础软件模式管理器（BswM）仅对逻辑表达式中不包含任何未定义模式条件的规则进行仲裁。⌋(SRS_ModeMgm_09180)

每个BswMModeRequestPort（模式请求端口）初始化后的初始值，可通过BswMModeInitValue（模式初始值）配置容器控制。

[SWS_BswM_00203]
若定义了BswMModeInitValue（模式初始值），则基础软件模式管理器（BswM）在初始化过程中，应使用BswMBswModeInitValue（基础软件模式初始值）或BswMCompuScaleModeValue（计算尺度模式值）对相应的BswMModeRequestSource（模式请求源）进行初始化。对于单个BswMModeInitValue（模式初始值），若配置中同时包含BswMBswModeInitValue（基础软件模式初始值）和BswMCompuScaleModeValue（计算尺度模式值），基础软件模式管理器（BswM）应拒绝该配置。该初始化值将用于仲裁规则，直至相应的模式仲裁请求被更新（例如，每次调用BswM_RequestMode函数都会更新通用请求（GenericRequest）模式）。⌋(SRS_ModeMgm_09179, SRS_ModeMgm_09228, SRS_ModeMgm_09180)

注：运行时环境（RTE）和调度管理器（SchM）的模式始终具有初始值（参见[SRS_Rte_00116]）。

[SWS_BswM_00251]
基础软件模式管理器（BswM）初始化时，所有BswMEventRequestPort（事件请求端口）均应初始化为清零（CLEAR）状态。⌋(SRS_ModeMgm_09183)

7.2 模式控制

基础软件模式管理器（BswM）的模式控制部分，会根据模式仲裁结果执行所有必要的动作，具体通过“动作列表（Action List）”实现。动作列表是一组有序动作的集合，当模式仲裁触发动作列表时，基础软件模式管理器（BswM）会执行列表中的动作。

动作列表中的动作可分为以下三类：

1. 调用其他基础软件（BSW）模块或运行时环境（RTE）的函数。第7.2.4章列出了一组预定义动作；
2. 指向其他动作列表的链接（执行时会包含被链接动作列表的内容）；
3. 模式仲裁规则（在执行相应动作列表时，会对这些规则进行评估）。通过这种方式，可形成规则的层级结构。

基础软件模式管理器（BswM）无需存储或响应其执行动作时各基础软件（BSW）模块返回的特定值。因此，基础软件（BSW）中的各个状态管理器会向基础软件模式管理器（BswM）指示自身的当前状态，作为模式仲裁的输入。但若某个动作返回错误（E_NOT_OK），基础软件模式管理器（BswM）可触发默认错误跟踪器（Det）的运行时错误报告，或取消当前正在执行的动作列表。

如图2所示，基础软件模式管理器（BswM）可包含多个动作列表，单个动作列表也可包含多个动作。为减少动作列表的总数，应支持动作列表的级联——动作列表中的元素既可以是具体动作、指向其他动作列表的引用，也可以是上述提到的、需由模式仲裁执行的规则。每个动作列表条目都应带有一个标识其类型（动作/引用/规则）的标志。对于包含具体动作的列表、包含引用的列表，或混合类型的列表，其激活方式应保持一致。

（图2：两个动作列表的示例）

7.2.1 模式处理周期

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

1. 模式请求方软件组件（SW-C）通过其发送端口（Sender Port）请求模式A；
2. 运行时环境（RTE）分发该请求，基础软件模式管理器（BswM）通过其接收端口（Receiver Port）接收该请求；
3. 基础软件模式管理器（BswM）要么根据接收到的模式仲裁请求评估规则，要么在执行主函数期间周期性地评估规则；
4. 根据选定的执行方式（参见“触发式和条件式动作列表”部分），执行相应的动作列表。执行动作列表时，基础软件模式管理器（BswM）可调用运行时环境（RTE）的切换API（参见[10]）作为动作，将仲裁结果通知给受影响的软件组件（SW-C）。包括模式请求方在内的所有软件组件（SW-C），都可注册以接收模式切换指示。

注：模式请求方只能从本地基础软件模式管理器（BswM）接收模式切换指示；即使请求源自其他ECU（由本地代理软件组件（SW-C）发起），该规则同样适用。

（图3：模式处理周期）

7.2.2 模式控制的需求

[SWS_BswM_00016]
基础软件模式管理器（BswM）应通过动作列表执行模式控制，动作列表的触发源自模式仲裁中的规则评估结果。⌋(SRS_ModeMgm_09177)

[SWS_BswM_00015]
对于模式仲裁的每条规则，基础软件模式管理器（BswM）应能根据规则评估结果为真（True）或假（False），执行不同的动作列表。⌋(SRS_ModeMgm_09177)

[SWS_BswM_00017]
动作列表由一组动作构成，基础软件模式管理器（BswM）应按顺序执行这些动作。⌋(SRS_ModeMgm_09178)

[SWS_BswM_00018]
动作列表可包含指向其他动作列表的链接，基础软件模式管理器（BswM）执行时应包含这些被链接动作列表的内容。⌋(SRS_ModeMgm_09178)

[SWS_BswM_00019]
动作列表也可包含指向模式仲裁规则的链接，基础软件模式管理器（BswM）应在当前动作列表的执行范围内，评估这些规则。⌋(SRS_ModeMgm_09178)

[SWS_BswM_00067]
如[SWS_BswM_00019]所述，若动作列表中包含某条规则，则该规则评估后触发的所有动作列表执行，都应在基础软件模式管理器（BswM）继续执行原动作列表之前完成。⌋(SRS_ModeMgm_09177, SRS_ModeMgm_09178)

[SWS_BswM_00037]
若使用级联动作列表（即引用其他规则或动作列表），则动作列表的层级结构最多可包含7层。
注：设置该限制的目的是为了便于基础软件模式管理器（BswM）实现和生成工具的测试，生成工具需检查该限制是否满足。⌋(SRS_ModeMgm_09178)

[SWS_BswM_00062]
在模式仲裁请求上下文中评估的规则所关联的动作列表，应在模式仲裁触发时由基础软件模式管理器（BswM）即时执行，不得延迟至主函数执行时处理。
原理：必要时，该需求可实现模式请求的极低延迟。⌋(SRS_ModeMgm_09177, SRS_ModeMgm_09178)

[SWS_BswM_00223]
若模式仲裁期间，多个规则触发了同一个顶级动作列表，则在模式控制阶段，该动作列表应仅被触发执行一次。⌋(SRS_ModeMgm_09177, SRS_ModeMgm_09178)

注：顶级动作列表指由顶级规则（即未嵌套在任何动作列表中的规则）直接执行，且自身未嵌套在其他动作列表中的动作列表。需求[SWS_BswM_00223]仅适用于顶级动作列表，不适用于嵌套规则和嵌套动作列表——因为嵌套规则和嵌套动作列表在父动作列表中的顺序由用户定义，应予以保留。

[SWS_BswM_CONSTR_00001]
若某个BswMActionList（动作列表）中包含BswMActionListItemIndex（动作列表条目索引）值相同的BswMActionListItem（动作列表条目），基础软件模式管理器（BswM）应拒绝该配置。⌋(SRS_ModeMgm_09178, SRS_BSW_00167)

[SWS_BswM_00260]
执行BswMActionList（动作列表）时，基础软件模式管理器（BswM）应从BswMActionListItemIndex（动作列表条目索引）值最小的BswMActionListItem（动作列表条目）开始执行，之后按BswMActionListItemIndex（动作列表条目索引）值递增的顺序执行后续条目。⌋(SRS_ModeMgm_09230)

注：在同一个动作列表中，配置的BswMActionListItemIndex（动作列表条目索引）无需连续，也无需从0开始。基础软件模式管理器（BswM）会从索引值最小的动作列表条目开始执行，直至索引值最大的条目；若索引存在“间隔”（即不连续），则这些间隔会被直接忽略。由于动作列表是有序列表，不允许在同一动作列表的配置中出现BswMActionListItemIndex（动作列表条目索引）值相同的情况。

7.2.3 触发式和条件式动作列表

根据规则评估结果，动作列表的执行存在两种方式：一种是每次规则评估得到对应结果时都执行；另一种是仅当评估结果与上一次评估结果相比发生变化时才执行。动作列表的执行方式通过BswMActionList（动作列表）容器中的BswMActionListExecution（动作列表执行方式）参数配置。

但对于未直接由规则引用的嵌套动作列表，BswMActionListExecution（动作列表执行方式）参数（如BSWM_CONDITION（条件式）或BSWM_TRIGGER（触发式））无实际意义，也不会影响该嵌套动作列表的执行方式。这类嵌套动作列表（即未直接由规则引用的动作列表）会在其父动作列表执行时一并执行。

[SWS_BswM_00011]
若“真（True）动作列表”配置为触发式（TRIGGER）执行，则基础软件模式管理器（BswM）仅在对应规则的评估结果从假（False）变为真（True）时，才执行该动作列表。⌋(SRS_ModeMgm_09180, SRS_ModeMgm_09230)

[SWS_BswM_00023]
若“假（False）动作列表”配置为触发式（TRIGGER）执行，则基础软件模式管理器（BswM）仅在对应规则的评估结果从真（True）变为假（False）时，才执行该动作列表。⌋(SRS_ModeMgm_09180, SRS_ModeMgm_09230)

[SWS_BswM_00115]
若“真（True）动作列表”配置为条件式（CONDITION）执行，则基础软件模式管理器（BswM）每次在对应规则的评估结果为真（True）时，都应执行该动作列表。⌋(SRS_ModeMgm_09180)

[SWS_BswM_00116]
若“假（False）动作列表”配置为条件式（CONDITION）执行，则基础软件模式管理器（BswM）每次在对应规则的评估结果为假（False）时，都应执行该动作列表。⌋(SRS_ModeMgm_09180)

[SWS_BswM_00055]
若某个动作返回错误（E_NOT_OK），且对应的BswMAbortOnFail（失败时中止）配置参数设为“true”（真），则基础软件模式管理器（BswM）应中止该动作列表的执行。⌋(SRS_ModeMgm_09178)

7.2.4 可用动作

动作列表中可使用的动作集合为预定义集合。这样设计的目的是为了简化ECU配置和基础软件模式管理器（BswM）配置代码的生成。

[SWS_BswM_00038]
基础软件模式管理器（BswM）应能执行由BswMAvailableActions（可用动作）配置容器定义的预定义动作。⌋(SRS_ModeMgm_09175, SRS_ModeMgm_09174, SRS_ModeMgm_09182, SRS_ModeMgm_09184)

[SWS_BswM_00039]
即使某个AUTOSAR基础软件（BSW）中的函数未包含在BswMAvailableActions（可用动作）定义的标准化动作中，基础软件模式管理器（BswM）也应能调用该函数。⌋(SRS_ModeMgm_09229)

[SWS_BswM_00040]
基础软件模式管理器（BswM）应能调用用户定义的函数。⌋(SRS_ModeMgm_09229)

[SWS_BswM_00054]
用户定义函数的参数及其值，应在ECU配置阶段通过BswMUserCallout（用户调用）配置容器定义。⌋(SRS_ModeMgm_09178)

7.2.5 初始化后的模式控制行为

基础软件模式管理器（BswM）初始化后，模式控制的行为由BswMRule（规则）容器中的BswMRuleInitState（规则初始状态）参数配置。该参数定义了规则首次评估后，决定执行哪个动作列表时所使用的“上一次评估结果”；此外，BswMActionList（动作列表）容器中的BswMActionListExecution（动作列表执行方式）参数，也会影响初始化后的动作列表执行。

[SWS_BswM_00066]
规则在初始化后首次评估时，基础软件模式管理器（BswM）应按照表2的规定执行操作。

（表2：BswMRuleInitState（规则初始状态）配置参数的使用说明）

BswMRuleInitState（规则初始状态）	BswMActionListExecution（动作列表执行方式）	规则评估结果为真（True）	规则评估结果为假（False）
BSWM_UNDEFINED（未定义）	BSWM_TRIGGER（触发式）	执行“真（True）动作列表”	执行“假（False）动作列表”
BSWM_TRUE（真）	BSWM_TRIGGER（触发式）	不执行任何操作	执行“假（False）动作列表”
BSWM_FALSE（假）	BSWM_TRIGGER（触发式）	执行“真（True）动作列表”	不执行任何操作
BSWM_UNDEFINED（未定义）	BSWM_CONDITION（条件式）	执行“真（True）动作列表”	执行“假（False）动作列表”
BSWM_TRUE（真）	BSWM_CONDITION（条件式）	执行“真（True）动作列表”	执行“假（False）动作列表”
BSWM_FALSE（假）	BSWM_CONDITION（条件式）	执行“真（True）动作列表”	执行“假（False）动作列表”

注：每条规则的“真（True）动作列表”和“假（False）动作列表”均为可选。⌋(SRS_ModeMgm_09180, SRS_ModeMgm_09230)

7.3 等待功能

有时需要延迟执行特定动作，或等待后续模式控制，为此基础软件模式管理器（BswM）中添加了定时器处理功能。

每个定时器都由作为BswMModeRequestSource（模式请求源）的BswMTimer（BswM定时器），以及控制该BswMTimer（BswM定时器）的相应动作（参见BswMTimerControl（定时器控制））构成——即只能在BswMTimerControl（定时器控制）-> BswMModeRequestSource（模式请求源）/BswMTimer（BswM定时器）的上下文中控制定时器，不存在控制或操作定时器的外部接口。

BswMTimer（BswM定时器）的值（如BSWM_TIMER_STOPPED（已停止）、BSWM_TIMER_STARTED（已启动）、BSWM_TIMER_EXPIRED（已过期））可由基础软件模式管理器（BswM）中配置的其他规则评估，以触发动作列表。

[SWS_BswM_00261]
初始化期间，每个BswMTimer（BswM定时器）都应处于停止状态（BSWM_TIMER_STOPPED）。⌋(SRS_BSW_00101)

[SWS_BswM_00262]
当执行BSWM_TIMER_START（定时器启动）类型的BswMTimerAction（定时器动作）时，应将引用的BswMTimer（BswM定时器）（通过BswMTimerRef（定时器引用）指定）重新加载为相应的定时器值（参见BswMTimerValue（定时器值）），并将定时器模式改为BSWM_TIMER_STARTED（已启动）。⌋(SRS_ModeMgm_09180)

注：只能通过BswMTimerAction（定时器动作）重新加载定时器（不支持自动重新加载）。

[SWS_BswM_00263]
处于BSWM_TIMER_STARTED（已启动）模式的每个BswMTimer（BswM定时器），应在BswM_MainFunction（BswM主函数）执行期间（按BswM_MainFunction（BswM主函数）的周期）递减计时值。⌋(SRS_ModeMgm_09180)

注：BswMTimer（BswM定时器）的分辨率是BswM_MainFunction（BswM主函数）周期的整数倍，其精度也取决于BswM_MainFunction（BswM主函数）的精度。

[SWS_BswM_00264]
若处于BSWM_TIMER_STARTED（已启动）模式的BswMTimer（BswM定时器）过期，则其模式应改为BSWM_TIMER_EXPIRED（已过期），且该BswMTimer（BswM定时器）的模式应在同一个BswM_MainFunction（BswM主函数）周期内进行仲裁。⌋(SRS_ModeMgm_09180)

[SWS_BswM_00265]
当执行BSWM_TIMER_STOP（定时器停止）类型的BswMTimerAction（定时器动作）时，应立即停止引用的BswMTimer（BswM定时器）（通过BswMTimerRef（定时器引用）指定），并将其模式改为BSWM_TIMER_STOPPED（已停止）。⌋(SRS_ModeMgm_09180)

7.4 多分区支持

对于多个基础软件模式管理器（BswM）实例，每个实例都会基于自身的配置集生成独立的服务组件描述。集成商需将这些独立的服务组件分配到对应的分区中。

7.5 错误分类

《基础软件模块通用规范》中“7.x 错误处理”章节详细描述了基础软件的错误处理机制，其中定义了基础软件模块中可能出现的五类错误的分类体系。

基于该体系，以下章节将按类别规定基础软件模式管理器（BswM）中的特定错误。

7.5.1 开发错误

本章列出了本软件模块中可检测到的所有开发错误，并为每个错误定义了对应的值。

[SWS_BswM_00230] 开发错误类型

（表3：开发错误类型）

开发错误类型	错误值（十六进制）
BSWM_E_PARAM_INVALID（参数无效）	0x03
BSWM_E_REQ_USER_OUT_OF_RANGE（请求用户超出范围）	0x04
BSWM_E_REQ_MODE_OUT_OF_RANGE（请求模式超出范围）	0x05
BSWM_E_PARAM_CONFIG（配置参数错误）	0x06
BSWM_E_PARAM_POINTER（指针参数错误）	0x07
BSWM_E_INIT_FAILED（初始化失败）（SRS_BSW_00385）	0x08

7.5.2 运行时错误

[SWS_BswM_00238] 运行时错误类型

（表4：运行时错误类型）

错误类型	相关错误代码	错误值（十六进制）
某个动作返回E_NOT_OK（执行错误）	BSWM_E_ACTION_FAILED（动作执行失败）	0x80~0xFF（具体值由BswMReportFailRuntimeErrorId（运行时错误ID报告）配置）
⌋(SRS_BSW_00452)

[SWS_BswM_00239]
若为某个BswMActionListItem（动作列表条目）配置了BswMReportFailRuntimeErrorId（运行时错误ID报告），且该动作返回E_NOT_OK（执行错误），则基础软件模式管理器（BswM）应向默认错误跟踪器（Det）报告BSWM_E_ACTION_FAILED（动作执行失败）类型的运行时错误，报告的错误ID（ErrorId）为BswMReportFailRuntimeErrorId（运行时错误ID报告）中配置的值。⌋(SRS_BSW_00452)

注：动作的调用上下文取决于配置（如延迟式（DEFERRED）或即时式（IMMEDIATE）），因此本规范未定义BSWM_E_ACTION_FAILED（动作执行失败）类型运行时错误中报告的API ID（接口标识），该ID可由实现方自行定义。

BSWM_E_ACTION_FAILED（动作执行失败）类型的运行时错误对应一组错误ID（ErrorId）值，其取值范围限制为“运行时错误类型表”中规定的范围。

[SWS_BswM_00240]
若某个BswMReportFailRuntimeErrorId（运行时错误ID报告）的值超出“运行时错误类型表”中BSWM_E_ACTION_FAILED（动作执行失败）对应的取值范围，则基础软件模式管理器（BswM）应拒绝该配置。⌋(SRS_BSW_00167)

7.5.3 瞬时故障

无瞬时故障。

7.5.4 生产错误

无生产错误。

7.5.5 扩展生产错误

无扩展生产错误。

7.6 BswM接口与端口

本章规定了基础软件模式管理器（BswM）提供的AUTOSAR接口与端口。需注意的是，运行时环境（RTE）两侧均需配置端口：基础软件模式管理器（BswM）服务的软件组件（SW-C）描述会定义运行时环境（RTE）下层的端口；使用该服务的每个AUTOSAR软件组件（SW-C），都需在自身的软件组件（SW-C）描述中包含服务端口——这些端口与基础软件模式管理器（BswM）的端口使用相同的接口类型，且需与基础软件模式管理器（BswM）的端口连接，以便运行时环境（RTE）生成相应的标识（ID）和所需符号。

软件组件（SW-C）通过基础软件模式管理器（BswM）请求模式：软件组件（SW-C）提供一个发送端口（Sender Port），该端口关联特殊的发送者/接收者接口（Mode Request Interface，模式请求接口），且接口中包含一个数据元素。基础软件模式管理器（BswM）侧对应的接收端口（Receiver Port）在第7.6.1章中描述。该数据元素的类型与对应模式的模式声明组（Mode Declaration Group）中的模式声明（Mode Declarations）值一致——因为该数据元素的实现数据类型（ImplementationDataType）映射到模式声明组（Mode Declaration Group）。

发起模式请求的软件组件（SW-C）也可能是模式使用者——即该软件组件（SW-C）可能需要了解基础软件模式管理器（BswM）的仲裁结果。这类软件组件（SW-C）具有一个模式切换端口（Mode Switch Port），该端口是关联模式切换接口（Mode Switch Interface）的接收端口（R-Port），接口中包含一个数据元素，且该数据元素的类型即为模式声明组（Mode Declaration Group）本身。此外，不发起模式请求但依赖模式的其他软件组件（SW-C），也需配置此类模式切换端口（Mode Switch Port）。关于模式使用者接口的详细描述，参见第7.6.3章。需注意的是，若基础软件模式管理器（BswM）在决策过程中，除了需要知道请求的模式外，还需要知道当前的模式，则其自身也需配置模式切换接收端口（Mode Switch R-Port）。

当模式管理器切换对应模式时，运行时环境（RTE）会分发模式通知（Mode Notifications）。为此，基础软件模式管理器（BswM）需提供一个模式切换提供端口（Mode Switch Provided Port），软件组件（SW-C）可连接该端口。关于模式切换端口（Mode Switch Ports）的详细描述，参见第7.6.2章。

在发起请求的软件组件（SW-C）的上下文中，定义了一个模式请求端口（Mode Request Port，发送者/接收者类型）。基础软件模式管理器（BswM）的配置会引用该端口定义。假设软件组件（SW-C）定义了应用模式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;
};

在软件组件（SW-C）的上下文中，定义了两个接口：

1. AppModeRequestInterface（应用模式请求接口）：发送者/接收者（Sender/Receiver）类型，软件组件（SW-C）作为发送者；
2. AppModeInterface（应用模式接口）：模式切换（Mode Switch）类型，软件组件（SW-C）可根据使用需求配置提供端口（PPorts）和接收端口（R-Ports）。

图4展示了应用层软件组件（SW-C）的端口与基础软件模式管理器（BswM）服务端口的连接方式：应用模式管理器软件组件（Application Mode Manager SW-C）具有一个模式请求端口（Mode Request Port）和一个模式切换接收端口（Mode Switch R-Port，命名为modeNotificationPort以区别于模式切换提供端口（Mode Switch P-Ports））。其中，模式请求端口用于请求更改自身的应用模式，模式切换接收端口用于接收基础软件模式管理器（BswM）完成模式切换后的通知。应用模式管理器（Application Mode Manager）的模式请求端口（modeRequestPort0）与基础软件模式管理器（BswM）对应的模式请求端口连接；由于这是标准的发送者/接收者（Sender/Receiver）通信，应用模式管理器（Application Mode Manager）甚至可连接到其他ECU上的多个基础软件模式管理器（BswM）。

（图4：应用模式管理器、应用组件与基础软件模式管理器之间的连接）

为了切换应用模式，基础软件模式管理器（BswM）具有一个由本地运行时环境（RTE）实现的模式切换端口（modeSwitchPort_{Name}）。当运行时环境（RTE）执行模式切换时，会通知所有通过模式切换接收端口（Mode Switch R-Ports）连接到该提供端口（Providing Port）的相关实体（基础软件（BSW）模块或软件组件（SW-C））。

以下示例包含应用模式管理器（Application Mode Manager）、其他依赖模式的应用组件（Application Part），以及基础软件模式管理器（BswM）本身（需注意：该端口命名为modeNotificationPort_{Name}，但端口类型为模式切换端口（Mode Switch Port））——所有这些连接均为本地连接。

图5展示了基于软件组件（SW-C）的应用模式管理器（如AUTOSAR R3.1及更早版本中使用的管理器）：这类管理器直接切换应用模式，无需向基础软件模式管理器（BswM）发起请求，因此会直接将模式切换端口（Mode Switch Port）连接到本地运行时环境（RTE）。这意味着应用模式需局限于该ECU，且无法在基础软件模式管理器（BswM）中进行仲裁；但基础软件模式管理器（BswM）仍可将当前应用模式作为规则输入——只需为该应用模式配置一个模式切换接收端口（Mode Switch R-Port，图中命名为modeNotificationPort0）即可。

（图5：基于软件组件的应用模式管理器、应用组件与基础软件模式管理器之间的连接）

注：配置基础软件模式管理器（BswM）时，需了解特定ECU所需/可用的模式请求端口和ECU资源，因此基础软件模式管理器（BswM）的软件组件（SW-C）描述只能在ECU配置阶段完成。

从本章开始，所有后续接口定义均在以下AR包（ARPackage）中解释：AUTOSAR_BswM/BswModuleDescription。

注：本章中的伪代码仅为示意，目的是说明需如何定义相应的模型元素，并非精确代码。

7.6.1 模式请求端口

基础软件模式管理器（BswM）必须声明一个接收端口（Receiver Port），该端口使用在软件组件（SW-C）上下文中定义的接口，声明格式如下：

RequirePort AppModeRequestInterface modeRequestPort_{ArbName}_{ReqName};

为读取当前请求的模式，基础软件模式管理器（BswM）的实现需调用以下函数：

Rte_Read_modeRequestPort_{ArbName}_{ReqName}_requestedMode( &<variable> );

7.6.2 模式切换端口

与模式请求类似，基础软件模式管理器（BswM）在其模式切换提供端口（Mode Switch Provide Ports）中，仅引用在相应软件组件（SW-C）描述的上下文中定义的模式切换接口。对于上述示例，模式切换端口的声明格式如下：

ProvidePort AppModeInterface modeSwitchPort_{ModConName}_{SwitchName};

配置参数BswMModeSwitchInterfaceRef（模式切换接口引用）会引用该模式切换接口（Mode Switch Interface）。

为切换当前激活的模式，基础软件模式管理器（BswM）的实现需在其动作列表中插入以下任一调用：

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

7.6.3 模式切换通知

除模式请求外，当前激活的模式也可作为模式仲裁的输入。对于应用模式（Application Modes）和车辆模式（Vehicle Modes），基础软件模式管理器（BswM）需注册为模式使用者（mode user），之后会通过模式切换端口（Mode Switch Port）接收模式更改通知。对于上述示例，模式通知的声明格式如下：

注：为便于区分模式切换端口（ModeSwitchPort）的接收端口（RequirePort）和提供端口（ProvidePort），以下示例中将接收端口（RequirePort）命名为“mode notification port（模式通知端口）”。

RequirePort AppModeInterface modeNotificationPort_{ArbName}_{ModeName};

为读取当前激活的模式，基础软件模式管理器（BswM）的实现需调用以下任一函数：

Rte_Mode_modeNotificationPort_{ArbName}_{ModeName}_currentMode( &<variable> ); 
SchM_Mode_modeNotificationPort_{ArbName}_{ModeName}_currentMode( &<variable> );

若配置了增强型Rte_Mode或SchM_Mode，则基础软件模式管理器（BswM）的实现需调用以下任一函数：

Rte_Mode_modeNotificationPort_{ArbName}_{ModeName}_currentMode( &<variable>, &<previousmode>, &<nextmode> ); 
SchM_Mode_modeNotificationPort_{ArbName}_{ModeName}_currentMode( &<variable>, &<previosmode>, &<nextmode> );

7.6.4 组件类型与内部行为

基础软件模式管理器（BswM）是一个服务组件（Service Component），为ECU本地的模式请求提供服务。基础软件模式管理器（BswM）的服务组件类型（ServiceComponentType）声明了上述所有端口，以及部分内部行为（Internal Behavior），声明格式如下：

ServiceComponentType BswM { 
    InternalBehavior { 
        // 内部行为定义 
    }; 
}; 
// 其他相关声明

基础软件模式管理器（BswM）的内部行为取决于对应模式请求端口（Mode Request Port）的BswMRequestProcessing（请求处理方式）参数：

• 若参数设为BSWM_DEFERRED（延迟）：运行时环境（RTE）无需执行特殊操作，基础软件模式管理器（BswM）会在其BswM_MainFunction（BswM主函数）中周期性地读取请求；
• 若参数设为BSWM_IMMEDIATE（即时）：运行时环境（RTE）需立即触发模式仲裁，因此基础软件模式管理器（BswM）需注册一个触发函数以触发模式仲裁。

对于上述示例，若需即时处理模式请求，需在基础软件模式管理器（BswM）的内部行为（Internal Behavior）中添加以下声明：

RunnableEntity ModeArbitrationRunnable { 
    symbol = <mode_arbitration_function>; // 模式仲裁函数符号 
    canBeInvokedConcurrently = TRUE; // 可并发调用 
}; 
DataReceiveEvent AppModeRequestEvent { 
    port = modeRequestPort0; // 关联的模式请求端口 
    dataElement = requestedMode; // 数据元素（请求的模式） 
    startOnEvent = ModeArbitrationRunnable; // 事件触发的可运行实体 
};

注：若需处理源自其他ECU的模式请求，需使用另一种服务组件——在虚拟功能总线（VFB）层面，该组件表现为一个全局服务组件，但实际上会在每个ECU的运行时环境（RTE）上层实例化一个服务组件。为支持该功能，软件组件模板（SW-C Template）提供了服务代理组件类型（ServiceProxyComponentType），而非标准的服务组件类型（ServiceComponentType）。

本文件未描述模式管理服务代理组件（Mode Management Service Proxy Component）的规范，该规范由用户自行定义。

7.7 虚拟网络（Pretended Networking）

当前版本的基础软件模式管理器（BswM）软件规范（SWS）仅通过API函数BswM_CanSM_CurrentIcomConfiguration（CAN状态管理器当前ICOM配置查询）和配置容器BswMCanSMIcomIndication（CAN状态管理器ICOM指示配置），支持CAN总线的虚拟网络（Pretended Networking）功能。

关于基础软件模式管理器（BswM）虚拟网络（Pretended Networking）配置的指南，参见文档AUTOSAR_EXP_ModemanagementGuide.pdf（模式管理指南）。