4. Stateflow数据对象与存储类

在Stateflow中，数据对象不是“画完状态机再补”的附属品，而是决定生成代码接口形态、内存占用和可测试性的核心设计输入。同一个状态机逻辑，若把某个变量从局部改为输出、从常量改为参数，生成的C代码在函数签名、RAM/ROM占用、标定能力和集成方式上都会发生实质变化。因此，量产项目中通常先定数据对象与存储类，再细化状态迁移和动作。

四类数据对象的本质区别

Stateflow数据对象按作用域和生命周期可分为四类，理解它们的关键是看“谁可见、谁拥有、何时存在”。

• 局部变量（Local）：仅在当前Stateflow图表内部可见，不进入函数参数列表，通常映射为生成函数内的局部变量或静态变量。它适合保存中间计算结果、临时标志位，例如“本次任务是否已超时”的中间判断。局部变量不参与外部接口，但若被设为“函数内静态”，会跨调用周期保持值，需谨慎使用。
• 输入（Input）：由外部调用者传入，出现在生成函数的形参中。输入是状态机感知外部世界的唯一通道，例如传感器采样值、使能信号、故障标志。输入应尽量保持“只读”语义，避免在动作中直接改写输入数据。
• 输出（Output）：由状态机产生并返回给调用者，出现在函数返回值或输出指针参数中。输出是状态机影响外部执行器的通道，例如PWM占空比、继电器命令、故障码。输出必须在每个执行路径上都有明确赋值，否则量产代码中可能出现未初始化读取。
• 参数（Parameter）与常量（Constant）：参数是可在标定阶段修改的输入，通常映射为标定量（如CALIBRATION或可写参数），参与接口但不占用普通RAM；常量是编译期固定值，映射为ROM中的const，不参与函数参数。参数适合阈值、增益、时间常数等需要整车标定的量；常量适合物理极限、枚举边界、固定查表地址等不应被修改的量。

存储类选择：从“能跑”到“能量产”

存储类（Storage Class）决定数据对象在生成代码中的声明方式、内存段和链接属性。在量产接口设计中，存储类选择比变量类型更关键，因为它直接影响AUTOSAR SWC的端口映射、内存保护和多核共享。

常见存储类及其适用场景如下：

存储类	生成形态	典型用途	量产注意点
Auto	函数内局部变量	纯中间计算	不跨周期保持，不可外部观测
ExportedGlobal	全局变量，外部可链接	调试观测、跨模块共享	需定义内存段，避免命名冲突
ImportedExtern	extern声明，引用外部定义	引用其他模块的全局量	需保证定义方存在且类型一致
Parameter	const或标定对象	阈值、增益、标定表	需与A2L生成流程配合
Define	宏定义	编译期常量	不占内存，但不可标定

选择存储类时，先问三个问题：该数据是否需要跨周期保持？是否需要被其他模块或标定工具访问？是否需要在不同编译配置下改变？若答案均为“否”，优先用Auto局部变量；若需要标定，用Parameter；若需要跨模块共享，用ExportedGlobal并明确内存段。

量产接口设计：从Stateflow到C函数

Stateflow图表的接口设计，最终体现为生成函数的签名。以一个“电机使能与故障管理”状态机为例，其数据对象设计如下：

输入：
  EnableReq      boolean   来自整车控制器
  MotorSpeed     uint16    来自转速传感器，单位rpm
  FaultClear     boolean   来自诊断仪

输出：
  MotorEnable    boolean   驱动使能
  FaultCode      uint8     故障码，0表示无故障

参数：
  SpeedLimit     uint16    超速阈值，默认8000rpm
  FaultDebounce  uint8     故障去抖周期数，默认3

局部变量：
  FaultCounter   uint8     故障计数
  LastState      uint8     上一周期状态

对应生成的C函数接口大致为：

void MotorFaultMgr_step(boolean EnableReq,
                        uint16 MotorSpeed,
                        boolean FaultClear,
                        boolean *MotorEnable,
                        uint8 *FaultCode);

其中SpeedLimit和FaultDebounce作为参数，不进入函数形参，而是通过标定对象或const全局量在函数内部引用。这样做的目的是：接口保持稳定，标定值变化不需要重新生成接口代码。

数据对象与存储类的协同设计流程

下面这张图展示了从状态机需求到量产接口的映射关系，重点表达四类数据对象如何分别进入函数形参、标定对象和内部变量，以及存储类选择对生成代码形态的影响。

接口设计中的关键约束

在量产项目中，Stateflow接口设计还需满足以下约束，否则会在集成阶段暴露问题。

第一，输入输出类型必须与AUTOSAR数据类型对齐。Stateflow中若使用boolean、uint8、uint16等基础类型，生成代码时需映射到RTE端口类型。若整车使用uint8表示使能，而Stateflow中定义为boolean，集成时会出现类型不匹配。建议在建模前先确定SWC端口类型，再反向约束Stateflow数据对象类型。

第二，参数必须可标定且带默认值。参数对象在生成代码中通常以const全局量或标定段变量出现。若参数没有默认值，编译可能通过但标定前行为不确定。量产中要求每个Parameter都有明确的初始值，并纳入A2L描述。

第三，局部变量要区分“每周期重置”和“跨周期保持”。Stateflow中局部变量默认在每次图表执行时重新初始化，若需要跨周期保持，必须显式设置为“函数内静态”或使用单位延迟。量产中常见故障：故障计数器本应跨周期累加，却因局部变量每周期清零而永远无法触发去抖。

第四，输出必须在所有路径上赋值。若某个状态分支未给输出赋值，生成代码中该输出可能保持上一次值或未初始化。建议在Stateflow中为输出设置默认值，或在默认迁移中统一赋值。

从设计到验证的闭环

数据对象与存储类设计完成后，验证应覆盖三个层面：接口层验证函数签名和参数类型是否与SWC端口一致；标定层验证Parameter是否出现在A2L中且可读写；行为层验证局部变量跨周期保持和输出赋值是否满足状态机逻辑。只有这三层都通过，Stateflow生成的代码才具备量产集成条件。

实际项目中，建议在Stateflow建模规范中明确：输入输出命名前缀、参数命名规则、局部变量使用限制、存储类默认选择策略。这些规则一旦固化，后续所有状态机图表都能保持一致接口风格，显著降低集成和测试成本。