AUTOSAR 入门教程 14：BswM

搞清 BswM 如何通过"规则-动作"机制协调各 BSW 模块的行为，以及它与 EcuM 的协作关系。

AUTOSAR 基础软件有几十个模块，每个模块都有自己的状态机。通信栈需要知道什么时候启用、诊断栈需要知道什么时候响应请求、NvM 需要知道什么时候读写数据。这些模块之间不是各自为政，而是由 BswM（BSW Mode Manager）统一协调。BswM 像一个模式指挥官：它不直接做业务逻辑，但决定什么时候该做什么。

模式管理的三大能力

BswM 的核心能力分为三层，每层各司其职：模式仲裁接收来自各模块的模式请求和状态指示，基于预配置的布尔规则进行评估，输出 TRUE 或 FALSE；模式控制在仲裁结果为 TRUE 时执行一组操作列表，为 FALSE 时执行另一组操作列表，操作可能跨多个模块；执行机制确保所有规则和操作序列完全基于配置实现，不需要手写代码。

这三层形成一条清晰的链路：外部事件触发模式请求，BswM 评估规则，然后执行动作。开发者需要做的就是配置好"什么条件下执行什么操作"，BswM 框架负责运行。

协作网络

BswM 与 AUTOSAR 各核心模块都有交互，可以把它理解为一个交通枢纽：通信方面通过 RTE 接收应用模式请求，与 ComM 交换通信模式指令，控制 PDU Router 中的路由组开关；电源管理方面与 EcuM 同步 ECU 状态和唤醒源信息（教程 13 已详细介绍 EcuM），接收 WdgM 看门狗状态指示；诊断与存储方面响应 车载诊断 中 DCM 模块的诊断请求，触发 NvM 在启动/关闭时执行块读写操作。

这些交互关系说明 BswM 不是孤立的模块——它是 ECU 状态管理的调度中心。ECU 启动时 BswM 依次启用各 BSW 模块，关机时 BswM 反向关闭各模块，确保顺序正确。

仲裁与执行流程

BswM 提供两种仲裁处理方式：立即操作在模式请求或指示的上下文中即时响应，延迟最低；延迟操作在 BswM 主函数中周期性处理，适合不需要立即响应的场景。

整个工作流程分三步。第一步，SWC 通过 RTE 发送模式切换请求。第二步，BswM 根据预配置的布尔规则进行评估，每条规则对应 TRUE/FALSE 两种结果的操作列表。第三步，触发对应操作列表，与各基础软件和应用模块交互，通过 RTE 向上层反馈模式指示。

所有仲裁逻辑和操作序列均可通过配置工具（如 EB tresos 或 DaVinci Configurator）完成，无需修改源码。这意味着调整模式管理策略只是改配置、重新生成代码的事情。BswM 的这种配置驱动设计是分层架构理念在模式管理领域的具体体现——业务逻辑（规则）和执行机制（操作）分离，修改规则不影响执行框架。

实践建议

• BswM 的规则配置建议用表格整理，列出每条规则的输入条件、判断逻辑和执行动作，比在工具里直接配清晰得多
• 立即操作和延迟操作的选择取决于实时性要求：通信模式切换通常用立即操作，NvM 写入触发可以用延迟操作
• BswM 与 EcuM 的协作关系是 ECU 状态管理的主线，建议先画出状态转换图再开始配置
• 调试 BswM 问题时优先检查规则的条件是否齐全，常见问题是遗漏了某个状态导致规则永远不会触发

下一篇教程将进入诊断栈——车载诊断 系统的四大模块 DCM、DEM、FIM、DET 如何协作完成从故障检测到功能抑制的全流程。