1. 课程导入与治理目标
在基于模型的设计（Model-Based Design）流程中，Stateflow 常被用来描述模式切换、故障处理、状态机调度和使能逻辑。一个中等规模的控制器模型里，Stateflow 图表可能包含几十个状态、上百个转移条件，以及大量与 Simulink 信号、数据存储、总线对象交互的数据项。真正让模型难以维护的，往往不是状态机画得不够漂亮，而是数据与接口缺乏统一治理：同一个物理量在不同图表里叫不同名字，单位不一致，数据类型随意继承，接口信号在多个层级被重复定义，最终导致集成失败、代码生成报错或测试结果不可复现。
本课程要解决的核心问题可以概括为一句话：让 Stateflow 中的数据与接口成为可定义、可追溯、可校验、可交付的工程资产。数据字典负责“数据是什么”，接口治理负责“数据怎么连”，两者共同构成模型可集成、可复用、可验证的基础。
一、为什么需要数据字典与接口治理
先看一个典型场景。某整车控制器项目中，Stateflow 图表需要读取车速信号。设计者在图表 A 中定义局部数据 VehSpd，在图表 B 中通过输入端口引入 VehicleSpeed_kph，在图表 C 中又直接引用 Simulink 信号 v_spd。三个名字指向同一物理量，但单位分别是 km/h、km/h 和 m/s，数据类型分别是 single、double 和继承。模型单独仿真时都能跑通，一旦集成到整车模型，就会出现量纲错误、溢出或状态判断失效。
这类问题的根源不是算法能力，而是缺少统一的数据定义入口和接口契约。数据字典的价值在于把散落在各处的数据定义收敛到一处，形成单一事实来源；接口治理的价值在于把跨图表、跨层级的连接关系显式化，避免隐式继承和重复定义。
二、核心挑战：从“能跑”到“可交付”
很多团队在模型能仿真之后才意识到治理问题，此时返工成本已经很高。核心挑战集中在四个方面。
- 命名与语义漂移：同一物理量在不同图表、不同层级出现多个别名，缺少命名规范，导致搜索、替换和评审困难。
- 类型与单位失控：Stateflow 数据项默认继承类型，局部数据与输入输出端口类型不匹配时，仿真可能自动转换，但代码生成阶段会暴露精度或溢出问题。
- 接口重复定义：同一信号在多个 Stateflow 图表中作为输入端口重复声明，修改时容易遗漏，造成接口不一致。
- 追溯链断裂：从需求到数据字典条目、到 Stateflow 数据对象、到生成代码变量，缺少可追踪的映射关系，评审和变更影响分析只能靠人工翻模型。
这些挑战的共同点是：它们不会在单次仿真中立刻暴露，却会在集成、代码生成、测试和长期维护中持续放大。因此，治理的目标不是“让模型更整齐”，而是降低集成风险、提高变更可控性、保证生成代码与模型语义一致。
三、本课程的学习路径
课程围绕“定义—绑定—校验—交付”四个环节展开，但不会机械地按四步走。整体学习路径如下：
- 建立数据字典基础：理解 Simulink 数据字典、Stateflow 数据对象、信号对象、参数对象之间的关系，掌握数据条目的关键属性（名称、类型、单位、初值、存储类、作用域）。
- 治理 Stateflow 内部数据：区分局部数据、输入输出数据、参数数据和临时数据，明确各自的生命周期与可见性，避免用局部数据替代接口。
- 治理接口与连接：通过端口、总线、信号线、数据存储等方式建立显式连接，减少隐式继承和跨层引用。
- 建立校验与追溯：利用模型顾问、数据字典检查、命名规范脚本和需求链接，形成可重复执行的校验流程。
- 形成交付物：输出数据字典清单、接口矩阵、命名规范、校验报告和变更记录，使治理结果可评审、可交接。
学习过程中会反复接触真实工程对象：Simulink 数据字典文件（.sldd）、Stateflow 数据对象、总线对象、存储类、模型顾问检查项、代码生成配置等。每一节都会围绕一个可操作的对象或判断展开，而不是停留在概念介绍。
四、最终交付物与判断标准
完成本课程后，应当能够交付一套可落地的治理成果。交付物不是单一文件，而是一组相互关联的工程资产：
| 交付物 | 核心内容 | 判断标准 |
|---|---|---|
| 数据字典清单 | 数据名称、类型、单位、初值、作用域、存储类、所属图表 | 无重复定义，命名符合规范，类型与单位明确 |
| 接口矩阵 | 源图表、目标图表、信号名、数据类型、单位、更新方式 | 每条连接可追溯，无隐式继承，无悬空端口 |
| 命名与建模规范 | 命名规则、数据类型选择规则、单位约定、局部数据使用边界 | 可被脚本检查，团队评审通过 |
| 校验报告 | 模型顾问检查结果、数据字典一致性检查、代码生成预检 | 关键检查项全部通过，遗留问题有明确处理结论 |
| 变更记录 | 数据条目变更、接口变更、影响范围、验证结果 | 变更可回溯，影响分析完整 |
判断治理是否达成的最终标准，不是“模型看起来整齐”，而是：换一个人接手，能否仅凭数据字典和接口矩阵理解模型的数据流；修改一个数据条目，能否快速定位所有受影响的位置；生成代码时，能否不出现类型不匹配或未定义变量。
五、从导入到落地：本节的起点
本节作为课程导入，不要求立刻完成全部治理工作，但需要建立三个基本判断。第一，数据字典不是可选项，只要模型需要多人协作、需要生成代码、需要长期维护，就必须有统一的数据定义入口。第二，接口治理的核心是显式化，凡是跨图表、跨层级的数据传递，都应当有明确的端口、总线或数据存储定义，而不是依赖隐式继承。第三，治理成果必须可校验，不能只靠人工评审，要能通过模型顾问、脚本或检查表重复验证。