2. Stateflow建模基础回顾
变体管理之所以能在Stateflow中落地，前提是先把Stateflow自身的语义讲清楚。变体不是外挂在模型上的标签，而是通过状态、转移、事件和动作这些基本元素，把"不同配置下走不同逻辑"这件事表达成可执行、可验证的模型结构。本节围绕六个核心概念展开：状态、转移、事件、动作、层次化状态与并行机制，并说明它们如何共同构成变体管理的统一语义基础。
状态：变体逻辑的驻留点
状态（State）表示系统在某一时刻所处的条件或模式。在Stateflow中，状态用圆角矩形表示，可以包含入口动作（entry）、退出动作（exit）、during动作（during）以及内部转移。对变体管理而言，状态是"配置选择结果"的驻留点：例如一个Config_Select状态机中，可以设置Base、Sport、Eco三个状态，分别代表基础版、运动版和经济版配置。每个状态内部可以进一步绑定该配置专属的参数集或子系统使能条件。
状态的关键属性包括：状态名、状态动作、是否被激活、是否为默认状态。默认状态由默认转移（Default Transition）指定，通常用带圆点的箭头表示。变体管理中，默认状态往往对应"基础配置"或"安全回退配置"，确保在未收到明确配置指令时系统仍处于可运行状态。
转移：配置切换的路径
转移（Transition）描述状态之间的迁移关系，由源状态、目标状态、触发事件、条件（Guard）和转移动作组成。语法形式为：事件[条件]{动作}。例如：
ConfigCmd == SPORT [Speed > 0] {applySportParams();}这条转移表示：当收到配置命令为SPORT且车速大于0时，执行运动参数应用动作并迁移到Sport状态。在变体管理中，转移条件通常与变体变量（Variant Variable）或配置字（Configuration Word）绑定，例如Variant_Active == 2。转移的优先级也很重要：当多个转移同时满足条件时，Stateflow按从上到下、从左到右的顺序选择第一条有效转移，这一点在变体互斥逻辑中必须显式设计，避免出现非预期的配置切换。
事件：驱动配置变化的信号
事件（Event）是触发状态机动作的外部或内部信号。Stateflow支持输入事件、输出事件、本地事件和时间事件。变体管理中，事件通常来自：配置管理模块下发的配置切换请求、诊断模块上报的故障降级请求、或标定工具写入的变体选择信号。事件可以带参数，例如ConfigCmd(uint8 mode)，这样一条事件就能携带目标配置编号，减少事件数量。
需要区分"事件触发"与"条件满足"：事件是瞬时发生的，条件是在某个时刻持续为真的表达式。变体切换一般由事件触发，而条件用于判断当前是否允许切换，例如车速为0才允许切换驾驶模式，避免行驶中突变。
动作：配置生效的具体行为
动作（Action）是状态机在特定时机执行的语句，分为入口动作、during动作、退出动作和转移动作。变体管理中，动作承担"把配置选择转化为实际参数或使能信号"的职责。例如：
entry: Variant_Active = 2;
Kp = 1.8; Ki = 0.35;
Enable_SportDamper = true;
exit: Enable_SportDamper = false;入口动作在进入状态时执行一次，适合做参数赋值和使能置位；退出动作在离开状态时执行一次，适合做资源释放和使能复位；during动作在状态激活期间每个仿真步执行，适合做持续监控。变体管理中要特别注意：参数赋值应放在入口动作而非during动作，避免每个步长重复写入造成不必要的计算和潜在冲突。
层次化状态：变体结构的组织方式
层次化状态（Hierarchical State）允许状态内部嵌套子状态机，形成父子关系。父状态可以包含多个子状态，子状态之间通过转移切换。层次化的价值在于：把公共逻辑放在父状态，把配置差异放在子状态。例如父状态DriveMode包含公共的扭矩监控逻辑，子状态Eco、Normal、Sport分别实现不同的扭矩映射。当父状态退出时，所有子状态一并退出，公共逻辑自然终止。
层次化还支持"历史节点"（History Junction），用于记录上次退出时激活的子状态，重新进入父状态时恢复到该子状态。这在变体管理中可用于"配置记忆"：系统重启后恢复到上次使用的配置，而不是每次都回到默认配置。
并行机制：多配置维度的同时表达
并行状态（Parallel State）用虚线边框表示，其内部的所有子状态同时激活，而不是互斥切换。变体管理中，不同配置维度往往是正交的：动力配置、底盘配置、座舱配置可以同时存在且互不影响。用并行状态可以把这些维度分开建模，每个并行区域独立管理自己的变体选择，避免状态爆炸。
例如一个并行父状态包含三个区域：Powertrain区域管理Eco/Normal/Sport，Chassis区域管理Comfort/Sport，Cabin区域管理Basic/Premium。三个区域同时运行，各自响应自己的配置事件。需要注意的是，并行区域之间如果存在数据依赖，必须通过明确的共享变量或事件通信，不能依赖执行顺序，因为并行区域的执行顺序在语义上是不确定的。
六要素如何构成变体管理的统一语义
把六个概念串起来看：事件是配置切换的触发源，转移条件判断当前是否允许切换以及切换到哪个配置，动作负责把配置选择转化为参数和使能信号，状态是配置结果的驻留点，层次化状态把公共逻辑与配置差异分离，并行机制让多个配置维度同时存在且互不干扰。这六者共同构成一个可执行、可验证的语义框架。
在实际建模中，建议遵循以下约定：变体选择用事件驱动，不用条件持续轮询；参数赋值放在入口动作，不在during动作中重复写入；互斥配置用层次化状态的子状态表达，正交配置用并行区域表达；配置记忆用历史节点实现；默认转移指向安全回退配置。这些约定不是强制语法，而是让变体逻辑在Stateflow中保持清晰、可维护、可测试的工程实践。