2. Stateflow建模环境与工程准备
在汽车ECU控制软件开发中，Stateflow很少单独存在，它总是嵌入在Simulink模型里，而Simulink模型又运行在MATLAB环境中。因此，在真正开始画状态机之前，必须先把“三件套”的集成关系、模型文件的组织方式、工程目录的规范以及版本管理的基础打牢。这一节不讨论状态机的语义，而是解决一个更前置的问题：当团队多人协作、模型需要反复迭代、还要能追溯到某个ECU软件版本时，工程应该如何摆放和命名。
一、MATLAB / Simulink / Stateflow 的集成关系
三者是层层嵌套的关系，而不是并列的三个工具。MATLAB提供语言、数据字典和脚本环境；Simulink提供基于时间的框图仿真；Stateflow则作为Simulink中的一个特殊模块，提供基于事件和状态的逻辑建模能力。一个典型的ECU控制模型，往往在Simulink层完成信号采集、滤波、标定查表和PWM输出，而把模式管理、故障降级、上下电时序等逻辑放进Stateflow Chart中。
集成关系可以从“调用链”和“数据链”两个角度看。调用链上，MATLAB命令行或脚本启动Simulink模型，Simulink在仿真步进中调用Stateflow Chart的求解器；数据链上，Simulink信号通过Chart的输入端口进入状态机，状态机通过输出端口把控制量送回Simulink网络。理解这一点，才能明白为什么Stateflow的输入输出端口类型、采样时间、数据类型必须与Simulink侧严格一致——否则在代码生成阶段会出现类型不匹配或采样率冲突。
二、模型文件组织：从单文件到工程化
初学者常把整个ECU逻辑塞进一个.slx文件，这在功能验证阶段尚可，但一旦进入多模块协作就会失控。工程化的做法是按“功能域”拆分模型，再用模型引用（Model Reference）或子系统库组合。例如一个车身控制器可以拆成：BCM_Top.slx（顶层集成）、BCM_Light.slx（灯光逻辑）、BCM_Wiper.slx（雨刮逻辑）、BCM_PowerMode.slx（上下电与模式管理）。其中BCM_PowerMode.slx内部包含Stateflow Chart，负责IGN、ACC、OFF等状态的迁移。
拆分的原则是：按变更频率和职责边界拆分，而不是按信号数量拆分。灯光逻辑和雨刮逻辑的变更节奏不同，测试用例也不同，放在不同模型里可以独立仿真、独立生成代码。顶层模型只负责接口连接和调度，不承载具体算法。这样在后续做MIL/SIL测试时，可以单独对某个子模型做闭环验证。
三、工程目录规范
一个可维护的ECU建模工程，目录结构应当让新成员在不看文档的情况下也能大致判断文件用途。下面给出一个可直接参考的目录模板，适用于中小型ECU控制项目：
ECU_Project/
├── 00_docs/ # 需求、接口定义、评审记录
├── 01_model/
│ ├── top/ # 顶层集成模型 BCM_Top.slx
│ ├── sub/ # 功能子模型 BCM_Light.slx 等
│ └── lib/ # 公共库、自定义模块
├── 02_data/
│ ├── sldd/ # 数据字典 .sldd
│ └── cal/ # 标定参数 .m / .mat
├── 03_script/
│ ├── init/ # 工程初始化脚本
│ └── build/ # 代码生成与打包脚本
├── 04_test/
│ ├── mil/ # 模型在环测试
│ └── sil/ # 软件在环测试
└── 05_release/ # 发布版本归档
关键约定有三条。第一，模型文件与数据字典分离：所有Simulink.Parameter、Simulink.Signal对象统一放在.sldd中，模型只引用不定义，避免参数散落在各个.slx里。第二，初始化脚本唯一入口：03_script/init/init_project.m负责添加路径、加载数据字典、设置求解器参数，任何人打开工程先运行它。第三，发布目录只读：05_release中的内容一旦归档不再修改，新版本另建文件夹，保证可追溯。
project.prj（MATLAB Project），把路径、启动脚本、数据字典绑定在一起。团队成员双击工程文件即可进入一致的环境，减少“在我电脑上能跑”的问题。四、版本管理基础
Simulink模型是二进制文件，直接做文本diff几乎不可读，这是版本管理中最容易踩坑的地方。基础策略是：能文本化的尽量文本化，不能文本化的靠规范约束。
- 数据字典和脚本用Git管理：.sldd虽然是二进制，但MATLAB支持导出为.m脚本进行diff；初始化脚本、构建脚本、标定.m文件都是纯文本，应正常纳入Git。
- 模型文件设置保存格式：在Simulink Preferences中把模型保存为“SLX（压缩）”并启用“模型比较”功能，至少能在MATLAB内做可视化diff。
- 提交粒度按功能：一次提交对应一个可描述的功能变更，例如“增加雨刮间歇档状态迁移”，而不是“改了几个模型”。提交信息中写清影响的模型、数据字典条目和测试用例编号。
- 锁定与分支：多人同时改同一个.slx极易冲突。建议对顶层模型和公共库采用“锁定修改”策略，功能子模型可以并行开发，通过模型引用接口保持解耦。
slprj/、*.slxc、*.autosave等生成文件提交到版本库。这些文件由Simulink自动重建，提交后只会造成冲突和仓库膨胀。应在.gitignore中排除。五、一个可执行的工程准备检查清单
在开始第一个Stateflow Chart之前，建议按下面的清单逐项确认。这份清单可以直接作为工程启动会的检查表使用：
| 检查项 | 判断标准 | 示例 |
|---|---|---|
| MATLAB版本与工具箱 | Simulink、Stateflow、Embedded Coder均可用 | R2022b，ver命令确认 |
| 工程目录 | 按功能域分层，路径无中文和空格 | D:\ECU_Project\01_model |
| 初始化脚本 | 运行后路径、字典、求解器全部就绪 | init_project.m无报错 |
| 数据字典 | 参数和信号已定义，模型无未解析符号 | BCM_Data.sldd |
| 版本库 | .gitignore已排除生成文件，首次提交完成 | Git仓库可clone |
| 模型引用接口 | 子模型输入输出端口类型与顶层一致 | 端口数据类型uint8/boolean |
完成以上准备后，工程就具备了“可打开、可运行、可提交、可追溯”的基本条件。接下来在Stateflow中创建Chart、定义状态和迁移时，才不会因为路径错误、参数缺失或版本混乱而反复返工。工程准备看似与状态机逻辑无关，但它决定了后续建模效率的上限。