1. 课程导入与一致性验证全景
基于模型的设计（Model-Based Design，MBD）把控制逻辑的“唯一真相源”从手写代码转移到了模型上。工程师在 Simulink/Stateflow 中搭建控制算法，通过自动代码生成工具（如 Embedded Coder）产出可直接编译烧录的 C 代码。这条链路极大提升了开发效率，但也引入了一个新的核心风险：模型和它生成的代码，真的表达同一件事吗？本课程要解决的，正是这个“一致性”问题。
MBD 开发流程与模型—代码映射关系
典型的 MBD 流程是：需求 → 模型设计 → 仿真验证 → 代码生成 → 集成编译 → 目标机测试。其中“模型设计”到“代码生成”这一步，是模型与代码发生映射的关键环节。理解映射关系，是理解一致性验证的前提。
映射并非“一个模块对应一段代码”这么简单。以常见的 Simulink 模块为例：
- Gain 增益模块：映射为一条乘法语句，如
y = K * u;，其中 K 是标定量或常量。 - Sum 求和模块：映射为加减表达式，符号由模块参数决定。
- Unit Delay 单位延迟：映射为一个状态变量，在步函数中先读旧值、再写新值，对应
y = state; state = u;的时序。 - Stateflow 状态机：映射为 switch-case 或状态变量加条件判断，状态迁移条件变成 if/else 分支。
- Lookup Table 查表：映射为插值函数调用或内联的插值计算，断点与表数据成为标定数组。
可以看到，模型中的“图形连接”在代码中变成了“变量赋值与执行顺序”，模型中的“采样时间”变成了代码中的“任务周期与调度”。这种语义转换，正是失配的高发地带。
一致性验证的目标与范围
一致性验证不是“代码能编译通过”或“功能看起来对”，它有明确的量化目标。工程上通常从四个维度定义：
| 维度 | 验证内容 | 典型判据 |
|---|---|---|
| 数值等价 | 相同输入序列下，模型输出与代码输出逐点比较 | 绝对误差 < 1e-6，或相对误差 < 0.1% |
| 时序一致 | 延迟步数、采样周期、执行顺序是否对齐 | 输出序列无整体偏移，延迟步数一致 |
| 状态迁移 | 状态机的状态序列与迁移条件是否匹配 | 状态序列完全相同，无额外/缺失迁移 |
| 参数一致 | 标定量、断点、表数据是否与模型一致 | 逐项比对，无默认值残留 |
验证范围要覆盖“模型—代码”链路上所有可能引入差异的环节：模块语义、数据类型与定标、采样时间、初始化条件、查表数据、以及编译器优化。范围界定不清，就会出现“测了很多但漏了关键路径”的情况。
典型失效案例
下面几个案例来自工程实践中的常见失配模式，理解它们有助于建立验证直觉。
案例一：数据类型溢出。模型中 Gain 输出为 double，代码中因配置为 single 或 int16，在输入较大时发生饱和或溢出。例如输入 30000、增益 2.5，int16 上限 32767，结果被截断为 32767 而非 75000。验证时若只测小信号，问题不会暴露。
案例二：采样周期错配。模型设定 Ts = 10 ms，代码任务实际调度为 5 ms。同一段积分逻辑在单位时间内执行次数翻倍，输出斜率明显偏大。这类问题在纯数值比对中容易被误判为“算法错误”。
案例三：状态初始化差异。模型中 Unit Delay 初值为 0，代码中状态变量未显式初始化，上电后为随机值。首帧输出即出现偏差，随后逐步收敛，表现为“启动瞬间异常”。
案例四：查表断点越界。模型查表输入范围 [0, 100]，代码中未做限幅，输入 120 时插值函数返回外推值或异常值。模型仿真因求解器限幅未暴露，代码侧却直接越界。
本课程的组织方式
后续章节将围绕“怎么验”展开：先建立模型与代码的映射检查方法，再进入数值比对、时序比对、状态机比对、参数比对的具体操作，最后覆盖自动化验证脚本与持续集成。每一节都会给出可复现的示例参数、观察点和判断依据，帮助你把一致性验证从“概念”落到“可执行”。
学习建议：在阅读后续内容时，建议同步打开一个自己熟悉的 Simulink 模型，对照生成的 C 代码逐模块查看映射关系。一致性验证的能力，很大程度上来自对“模型语义如何变成代码语义”的熟悉程度。