4. Stateflow 状态层次与并行机制

在汽车功能安全模型开发中,Stateflow 的状态层次与并行机制是表达复杂安全逻辑的核心手段。安全相关系统往往需要同时满足多个约束:既要有清晰的模式切换(如初始化、正常运行、降级、故障处理),又要在同一时刻监控多个独立通道(如双核锁步、多传感器冗余)。如果只用扁平的状态机,状态数量会呈指数级膨胀,可读性和可验证性都会急剧下降。Stateflow 通过父状态/子状态、历史节点、并行状态分解以及互斥与并发语义,为这类问题提供了结构化的表达方式。

父状态与子状态:层次化封装

父状态(Superstate)可以包含一个或多个子状态(Substate),形成树状层次。父状态本身可以拥有入口动作(entry)、退出动作(exit)和 during 动作,这些动作对其所有子状态生效。子状态之间的迁移默认是互斥的:同一时刻,父状态内只有一个子状态处于激活状态。这种“或”分解(OR-decomposition)是 Stateflow 中最基本的层次形式。

在安全逻辑中,层次化封装的价值在于把公共行为上提。例如,一个“电机控制”父状态可以统一处理使能条件、故障锁存和看门狗喂狗,而子状态只关注“待机”“扭矩输出”“主动短路”等具体模式。当父状态收到故障信号时,可以直接从父状态层迁移到“安全状态”,无需在每个子状态中重复编写相同的迁移条件。这既减少了模型复杂度,也降低了遗漏处理路径的风险。

历史节点:记住上次的激活子状态

默认情况下,父状态被重新进入时会从默认迁移指向的子状态开始执行。但在很多安全场景中,系统需要“恢复到故障前的状态”。历史节点(History Junction)正是为此设计:它记录父状态退出前最后激活的子状态,当父状态再次被进入时,直接回到该子状态,而不是重新初始化。

历史节点分为浅历史(Shallow History)和深历史(Deep History)。浅历史只恢复父状态直接包含的那一层子状态;深历史则递归恢复到最深层级的激活状态。对于嵌套较深的安全模式管理,深历史可以避免中间层被重新初始化,但也会增加状态恢复的验证难度。工程实践中,是否使用历史节点必须结合安全需求明确:如果安全目标要求每次进入某模式都必须从确定状态开始,则不应使用历史节点,而应显式定义默认迁移。

并行状态分解:AND 语义

与互斥的 OR 分解相对,并行状态分解(AND-decomposition)允许父状态内的多个子状态同时激活。在 Stateflow 中,并行状态通常用虚线边框表示,所有并行区域在父状态进入时同时被激活,各自独立执行迁移,互不干扰。只有当所有并行区域都到达退出条件时,父状态才可能整体退出。

并行机制非常适合表达安全系统中的冗余与监控关系。例如,一个“安全监控”父状态可以分解为三个并行区域:主通道监控、冗余通道监控、交叉校验。三个区域同时运行,各自维护自己的状态和计数器。如果任一区域检测到不一致,可以通过父状态层的迁移触发降级。这种结构天然对应了功能安全中“独立通道 + 比较逻辑”的架构。

Stateflow 层次与并行结构示意 父状态:SafetyManager entry: 初始化看门狗 / exit: 锁存故障码 OR 分解(互斥) Init 上电自检 Normal 扭矩输出 Degraded 限功率运行 SafeState 主动短路 自检通过 故障 恢复 H 历史节点 AND 分解(并行) 区域1:主通道监控 采样 比较 区域2:冗余通道监控 采样 比较 区域3:交叉校验 一致性 表决 同时激活 同时激活 同时激活 OR 分解:同一时刻仅一个子状态激活 | AND 分解:所有并行区域同时激活,独立迁移

状态互斥与并发执行的语义细节

理解 Stateflow 的执行语义对安全模型至关重要。在一个仿真步长内,Stateflow 按以下顺序执行:先执行当前激活状态的 during 动作,然后评估迁移条件,最后执行迁移并进入新状态。对于并行状态,所有并行区域在同一仿真步内依次执行,但它们的执行顺序不影响逻辑结果,因为并行区域之间不应存在数据竞争。如果并行区域之间需要共享数据,必须通过父状态层的动作或显式的数据存储进行同步,否则可能引入非确定性行为。

互斥状态之间的迁移具有优先级:当多个迁移条件同时为真时,Stateflow 按照迁移在图形中的位置(从上到下、从左到右)或用户指定的优先级进行选择。在安全逻辑中,必须显式定义优先级,尤其是“故障迁移”与“正常迁移”同时满足时,故障迁移应具有最高优先级。这可以通过将故障迁移放在最上方或使用迁移标签中的优先级数字来实现。

在安全相关逻辑中的表达实践

以一个电机控制器的安全监控为例,可以这样组织 Stateflow:顶层父状态“MotorControl”采用 OR 分解,包含“Init”“Run”“Fault”三个子状态。其中“Run”子状态内部再采用 AND 分解,包含“扭矩控制”“温度监控”“电流监控”三个并行区域。温度监控区域内部维护一个计数器,当温度超过阈值时,通过父状态层迁移到“Fault”。历史节点可以用于“Run”子状态,使得故障恢复后能够回到故障前的扭矩输出模式,但前提是安全需求允许这种恢复。

在建模时,建议遵循以下检查要点:第一,每个并行区域是否真正独立,是否存在隐式的执行顺序依赖;第二,历史节点的使用是否有明确的安全需求支撑,是否会导致不可预期的状态恢复;第三,互斥迁移的优先级是否显式定义,故障路径是否始终优先;第四,父状态的 entry/exit 动作是否与子状态动作产生冲突;第五,并行区域的退出条件是否覆盖所有区域,避免父状态无法退出。

在安全模型中,并行状态的数量不宜过多。每个并行区域都会增加状态空间的维度,给形式验证和测试覆盖带来压力。通常建议将并行区域控制在 3~5 个以内,并通过层次化封装将复杂逻辑下沉到子状态中。

Stateflow 的层次与并行机制为功能安全模型提供了结构化的表达手段。父状态/子状态实现逻辑封装与复用,历史节点支持状态恢复,并行分解对应冗余与监控架构,互斥与并发语义则决定了模型的执行行为。只有准确理解这些语义,才能在安全相关逻辑中正确使用它们,避免因状态恢复不当、优先级缺失或并行区域耦合而引入安全隐患。