4. 验证环境搭建

MBD模型与生成代码一致性验证，本质上不是“打开Simulink点一下生成代码”这么简单，而是要让模型、代码生成器、编译器、测试执行器四者形成一条可复现、可追溯的工具链。环境搭建的目标是：给定同一个模型版本和同一套配置，任何一台机器都能生成语义一致的C代码，并能用同一套测试用例对模型和代码分别执行、自动比对结果。本节围绕这条工具链的配置与集成展开，重点讲清楚每个环节要配什么、为什么这样配，以及如何判断环境已经可用。

一、工具链的整体结构与版本约束

一致性验证环境可以拆成四层：建模层（MATLAB/Simulink）、代码生成层（Embedded Coder 及其目标支持包）、编译与执行层（目标编译器、链接器、运行时库）、测试与比对层（测试管理工具、覆盖率工具、结果比对脚本）。这四层之间存在严格的版本耦合关系：Embedded Coder 的版本必须与 MATLAB 主版本一致；目标支持包（如 TI C2000、ARM Cortex-M 的 Hardware Support Package）必须与 Embedded Coder 版本匹配；编译器版本又必须落在 MathWorks 官方支持的编译器列表中。版本不匹配最常见的表现是代码生成阶段报“无法找到目标编译器”或生成的代码在编译时出现内联函数、位域、浮点 ABI 不一致。

因此环境搭建的第一步不是装软件，而是锁定一张版本矩阵表。下面给出一个示例矩阵（示例参数，实际项目需按官方支持列表核对）：

二、MATLAB/Simulink 与 Embedded Coder 的关键配置

模型侧配置决定了生成代码的“形状”。在 Configuration Parameters 中，与一致性验证强相关的参数主要有以下几组，建议在模型级建立统一的配置引用（Configuration Reference），避免每个模型各配一套。

• Solver：一致性验证通常要求模型与代码在相同步长下执行，因此定步长（Fixed-step）是首选。示例：Fixed-step，Fixed-step size = 0.001 s，求解器 discrete (no continuous states)。若模型含连续状态，需明确离散化方式，否则模型与代码的数值轨迹会天然分叉。
• Code Generation → System target file：选择 ert.tlc（Embedded Coder 的 ERT 目标），而不是 grt.tlc。ERT 生成的是面向嵌入式部署的代码，接口更可控。
• Interface：Code interface packaging 建议选 Reusable function 或 C++ class，便于测试框架直接调用；Generate reusable code only 视复用需求决定。
• Data exchange：Signal storage reuse、Pass reusable subsystem outputs as 等会影响变量生命周期，进而影响测试时的观测点。若测试需要观测中间信号，应关闭过度优化或显式添加 Test Point。
• Code style：Language = C，Standard = C99，Parentheses level、Preserve expression order 等影响浮点运算顺序，进而影响与模型的逐位一致性。

配置完成后，用 slbuild('model_name') 或 rtwbuild 触发一次代码生成，检查 model_name_ert_rtw 目录下是否产生 .c/.h、ert_main.c、model_name.mk 等文件。若生成成功但编译失败，问题通常出在编译器路径或目标支持包，而不是模型本身。

三、目标编译器的集成与验证

Embedded Coder 通过 Toolchain 机制调用外部编译器。在 Configuration Parameters → Code Generation → Toolchain 中选择与目标芯片匹配的工具链，例如 ARM Compatible → ARM Cortex-M。若官方列表中没有，可通过 target 包或自定义 ToolchainInfo 注册。

编译器集成的验证不能只看“编译通过”，还要确认三件事：一是生成的 .obj/.elf 能被目标调试器加载；二是浮点 ABI 与模型假设一致（软浮点/硬浮点）；三是结构体对齐、位域布局与模型中的 Bus 定义一致。一个实用的检查方法是在生成代码中插入一个简单的自检函数，例如对固定输入计算固定输出，然后在目标板上运行并与 MATLAB 端 fi 或 double 计算结果比对。

% 示例：在模型回调中注册编译后检查
set_param('my_model', 'PostCodeGenCommand', 'my_post_codegen_check');
% my_post_codegen_check.m 中可调用 makefile 编译并检查产物

四、测试工具链的接入与一致性比对

测试工具链的核心任务是：同一组输入激励，分别驱动模型和生成代码，采集同一组输出，做数值比对。常见做法有两种：一是用 Simulink Test 做模型级测试，再用 SIL/PIL 模式把生成代码拉回 Simulink 环境执行；二是把生成代码编译成独立可执行文件或动态库，由外部测试框架（如 GoogleTest、VectorCAST）驱动，再与模型输出做离线比对。

SIL（Software-in-the-Loop）是最直接的集成方式：在 Configuration Parameters → Code Generation → Verification 中把 Create block 设为 SIL，Simulink 会自动把模型替换为生成代码的封装，输入输出接口保持不变。此时运行同一组测试用例，即可在 Test Manager 中看到模型与代码的偏差曲线。判断标准通常设为：绝对误差 ≤ 1e-6（浮点）或逐位相等（定点/整型）。若偏差超限，优先检查求解器步长、数据类型、运算顺序和编译器优化等级。

下面这张图给出四层工具链的集成关系与数据流，重点标出“模型—代码—编译器—测试”之间的接口和比对回路。

五、环境可用性的判定与常见问题

环境搭好后，不要直接上大模型，先用一个最小闭环验证：一个含 Gain、Unit Delay、Sum 的离散模型，输入为常量或简单正弦，输出为一路 double。执行以下流程：

1. 模型仿真，记录输出序列；
2. 生成 ERT 代码，用目标编译器编译为可执行文件；
3. 用相同输入驱动可执行文件，记录输出序列；
4. 在 MATLAB 中做逐点比对，绘制偏差曲线。

若偏差为 0 或小于 1e-12，说明工具链基本可用；若偏差在 1e-6 量级，通常是浮点运算顺序或编译器优化导致，可尝试关闭 -ffast-math、统一 double 精度、关闭 Signal storage reuse 再验证；若偏差达到 1e-3 以上，优先怀疑步长不一致、数据类型被隐式转换或定点标定不一致。常见问题还包括：生成代码中 rtwtypes.h 与目标平台 stdint.h 冲突、ert_main.c 的调度周期与模型步长不一致、SIL 模式下模型回调未正确注册导致代码未真正执行。这些问题都可以通过“最小闭环 + 逐层替换”的方式定位。