1. 为什么需要软件在环仿真从“模型能跑”到“代码能跑”你在 Simulink 里搭好了一个控制器模型离线仿真曲线非常漂亮阶跃响应、抗扰性能都符合预期。把模型生成 C 代码集成到真实嵌入式板子上之后电机转速却出现了诡异的高频抖动或者控制输出在某几个工况且突然跳变。这种场景在电机控制、汽车电子、电源控制项目里并不少见。问题通常不是控制参数算错了而是模型和代码之间出现了行为差异。在基于模型设计的开发流程里SILSoftware in the Loop软件在环就是专门用来提前发现这类差异的验证手段。很多人容易把 SIL 理解成“在电脑上跑仿真”这个理解虽然不算错但实际上只看到了表象。SIL 更深层的价值在于它把 Simulink 模型生成的 C 代码编译成可在宿主机上运行的组件再放回 Simulink 环境里跑一遍然后和原来的模型仿真结果做对比。也就是说SIL 验证的不是“算法逻辑对不对”而是“模型变成代码之后行为和模型原来表达的是不是一致”。这篇文章围绕“Simulink 软件在环仿真 SIL”展开会讲清楚 SIL 和 MIL、PIL、HIL 的区别为什么要做 SIL以及从配置、运行到结果对比的完整操作流程。读完你应该能自己把任意一个 Simulink 控制模型切换到 SIL 模式并且判断模型仿真和代码仿真是否一致。如果你正在做嵌入式控制算法、车辆控制策略、无人机飞控或者电机控制相关的项目这篇文章尤其适合收藏备用。在我接触过的不少工程团队里SIL 往往是整个 Matlab/Simulink 开发流程中最早被执行、也最容易被跳过的一道验证。跳过它的理由无非是“模型仿真都过了代码生成配置也基本没动过应该没问题”。但恰恰是这种侥幸心理导致了很多问题被拖到台架测试甚至实车测试才暴露。等到那个时候定位问题的成本已经上升了一个数量级。SIL 的核心意义就在于把代码行为验证提前到纯软件阶段用最低的成本尽早发现问题。2. SIL 到底是什么与 MIL、PIL、HIL 的概念对比2.1 MIL、SIL、PIL、HIL 分别指什么在基于模型设计Model-Based DesignMBD的流程中控制算法通常经历四个典型的验证阶段MIL、SIL、PIL、HIL。这四个阶段名字相近但运行对象、运行环境和验证目标完全不同。MILModel in the Loop模型在环直接运行 Simulink 中的控制算法模型。此时算法还是以图形化模块和数学表达式的形式存在运行环境是开发机上的 MATLAB/Simulink。MIL 验证的是算法逻辑、控制参数和功能需求是否符合预期。SILSoftware in the Loop软件在环先把模型生成 C 代码再把这些代码编译成可在开发机上运行的动态库S-Function然后在 Simulink 环境中运行。SIL 验证的是“模型生成的代码”和“模型本身”的行为是否一致。PILProcessor in the Loop处理器在环把生成的 C 代码交叉编译后下载到目标处理器上运行通过调试接口与 MATLAB 通信获取运行结果。PIL 验证的是目标处理器的指令集、字长、编译器优化及浮点运算差异对算法行为的影响。HILHardware in the Loop硬件在环把代码部署到真实的控制器硬件ECU上并通过实时仿真机连接被控对象模型和真实 IO。HIL 验证的是控制器硬件、传感器/执行器接口以及时序逻辑在真实环境中的表现。2.2 一表看懂四个阶段的区别为了更直观地理解我整理了下面这张对比表。这张表可以作为你在评审会上向别人解释 SIL 定位时的参考。阶段运行对象运行环境主要验证目标成本MILSimulink 模型开发机 Simulink算法逻辑、功能正确性、控制参数低SIL模型生成的 C 代码开发机 Simulink 回调代码与模型一致性、代码生成配置较低PIL生成代码 目标处理器目标处理器 调试接口目标平台指令/字长/编译器行为中HIL代码 真实 ECU真实 ECU 实时仿真机控制器与真实 IO、被控对象集成高从这张表可以看出一条清晰的规律越往右成本越高越接近真实环境调试难度也越大。而 SIL 恰好处于“代码行为验证”和“低成本”的交叉点这也是它在工程流程中不可替代的原因。2.3 SIL 的通俗理解如果用一个比喻来理解 SILMIL 相当于你用公式算出了一道题的答案SIL 相当于你把公式翻译成了程序代码然后在同一台电脑上检查程序跑出来的结果和公式算出来的是否一致。PIL 相当于把这个程序放到一台不同架构的机器上跑看结果是否还保持一致HIL 则是把整个系统连上真实外设做完整验证。需要特别注意的一点是SIL 不是在“另一个环境”中运行模型而是把模型生成的代码以 S-Function 的形式嵌入回 Simulink 中运行。这个机制让 SIL 可以提供比较可控的调试环境同时又能验证真实代码的行为。3. SIL 背后的核心原理为什么“代码”可能不等于“模型”很多初学者会问一个问题SIL 和普通仿真看起来一样啊区别到底在哪里要回答这个问题必须先理解一个核心事实模型是数学表达代码是工程实现。同样的数学公式经过代码生成之后行为并不一定等价。为什么会不等价主要来自以下几个方面的差异。3.1 数据类型转换带来的精度损失在建模阶段为了调试方便大部分 Simulink 信号都是 double 类型。但生成嵌入式代码时为了节约 RAM、Flash 和 CPU 计算时间工程上会把大量信号改为 single、int16、uint16 甚至定点数。数据类型一旦收窄数值范围和精度都会受影响。举个例子某个物理量用 uint16 表示取值范围是 0~1000那么量化步长约为 1000/65535≈0.0153。如果原模型的控制器输出在这个物理量上要求 0.001 的精度生成代码后精度就不够了。这种差异在纯模型仿真阶段根本看不出来只有在跑代码时才能发现。3.2 计算顺序和浮点舍入差异模型中的数学表达式在生成 C 代码时编译器会按照数据依赖关系调整计算顺序甚至进行表达式折叠。浮点数的加法没有结合律(a b) c和a (b c)的结果可能不同。当模型中有积分器、累加器或者状态更新时这种微小的舍入误差会随着时间累积最终在结果上体现为可观察的偏差。SIL 的价值就在于把这个偏差暴露出来。如果偏差在可接受范围内说明代码生成设置没有问题如果偏差超出了阈值就要检查是哪一类运算导致的。3.3 求解器与采样时间设置差异很多算法模型在开发阶段使用变步长求解器比如 ode45仿真步长会根据误差自动调整。但生成嵌入式代码时目标平台几乎都采用固定步长离散求解器。如果在模型配置中没有把仿真类型切换为“固定步长”MIL 仿真结果和 SIL 仿真结果会很难对齐。更麻烦的是如果模型中某个模块采样时间设置错了比如离散控制器使用 1ms但被控对象离散模型使用了 2msSIL 模式下代码执行的周期可能与模型不一致。这种问题在纯仿真阶段不容易被注意但在 SIL 对比中会表现为曲线形状明显不同。3.4 代码生成优化选项的影响Embedded Coder 提供了很多优化选项比如“信号回收”“表达式折叠”“内存复用”等。这些优化在绝大多数情况下不会改变代码语义但极端情况下可能会改变中间变量的存储方式和计算精度。如果 SIL 验证中发现结果不一致不要只盯着模型本身也要检查代码生成配置中的优化项。3.5 自定义代码集成的差异当模型中包含 S-Function、C Caller 或 Stateflow 调用外部 C 代码时生成代码的编译环境、宏定义、头文件搜索路径都可能影响最终行为。SIL 模式下这些外部代码也会被一起编译并执行因此能顺便验证自定义代码的集成是否正常。理解了这些差异来源你就能明白SIL 不仅仅是一种“仿真模式”它本质上是一种代码级等价性检查。这也是我写这篇文章时最希望强调的判断在嵌入式控制开发中代码与模型不一致是常态而不是意外。SIL 就是用来发现这种“不一致”并量化其影响的最佳手段。4. SIL 适用场景与工程定位4.1 什么项目最需要 SILSIL 并不是所有 Simulink 用户的必需品。如果你只是用 Simulink 做算法验证从不生成代码那 SIL 对你的价值有限。SIL 真正的用户是这些场景的开发者汽车电子控制器开发包括 VCU、BMS、MCU 等电机控制算法开发包括 PMSM、BLDC、感应电机驱动电源与变换器控制比如 LLC、DAB、三相逆变器无人机与飞行器飞控算法其他需要把 Simulink 模型自动生成 C 代码并部署到嵌入式处理器的项目。这些项目有一个共同特点模型和代码都必须经过严格的验证流程而且验证结果需要可追溯。SIL 是这一流程中比较早、成本也比较低的一环。4.2 SIL 在 V 流程中的位置在经典的 V 流程中左侧是需求分解和设计右侧是集成验证。SIL 位于右侧的较早阶段紧跟在 MIL 验证之后。从整个流程来看MIL 通过 - SIL 通过 - PIL 通过 - HIL 通过 - 台架/实车测试SIL 承接的是“模型验证”和“代码验证”之间的转换点。如果 SIL 没通过后面的 PIL 和 HIL 大概率也会出问题。反过来如果 SIL 通过了至少可以确认模型行为到代码行为的转换没有明显错误。4.3 SIL 适合什么阶段介入SIL 最好在“模型功能基本稳定、准备开始代码生成”的阶段介入。也就是说你不需要在算法迭代阶段频繁跑 SIL因为算法还在大改跑一次代码生成和编译比较耗时。但当算法确认后第一次做代码生成的时候SIL 就应该同步跟上。从另一个角度看SIL 也非常适合作为自动化回归测试的一部分。当代码生成配置、模型结构或控制参数发生变化后自动跑一遍 MIL 和 SIL 对比能快速判断改动是否影响了代码行为。4.4 SIL 不适合什么场景SIL 不适用于验证硬件的实时性能比如中断响应时间、任务执行周期抖动、IO 延迟等。这些问题必须通过 PIL 或 HIL 才能验证。同时SIL 也无法覆盖真实传感器的噪声、故障模式和通信延迟。这些都是 SIL 的边界需要清醒认识。5. 环境准备与前置条件5.1 软件与授权要求要在 Simulink 中开展软件在环仿真 SIL通常需要安装以下组件MATLAB/Simulink 基础环境Simulink Coder用于从模型生成 C/C 代码Embedded Coder推荐支持 ERT 目标文件、代码优化和更多配置选项MATLAB Coder视模型情况而定如果模型中包含 MATLAB Function 模块就会用到支持的 C/C 编译器Windows 下一般使用 MinGW-w64 或 Microsoft Visual CLinux 下使用 gcc。不同版本的 MATLAB 对编译器版本有具体兼容性要求版本请以实际安装为准本文重点演示通用思路不绑定具体版本号。5.2 模型的前置条件不是所有模型都能直接切换 SIL 模式。推荐满足以下条件求解器类型为固定步长在模型配置参数中将 Solver 设置为 fixed-step并选择合适的离散求解器。采样时间明确模型中所有模块都应尽量使用显式采样时间避免使用-1继承采样时间造成歧义。模块支持代码生成模型中不应包含仅用于可视化的 Scope 模块虽然 SIL 可以运行但建议在验证前移除或改为 To Workspace 记录也不应包含 Simulink 中不支持代码生成的解释型模块。信号数据类型明确尽量为输入输出信号设置明确的数据类型避免自动继承为 double 导致精度误差掩盖问题。5.3 验证编译器环境在首次使用 SIL 前建议先在 MATLAB 命令行执行以下命令检查编译器是否可用mex -setup如果系统提示没有找到编译器需要先安装 MATLAB 支持的编译器然后重新执行mex -setup将某个编译器设为默认。这一步很关键因为 SIL 模式需要把生成的 C 代码编译为动态库如果编译器配置不对SIL 根本无法启动。6. 核心操作将模型切换为 SIL 仿真模式6.1 总体流程概览在 Simulink 中运行 SIL 的总体流程并不复杂总共分为四步准备模型固定步长、离散求解器、明确数据类型。配置代码生成选择系统目标文件通常是 ERTEmbedded Real-Time。切换仿真模式在模型设置或仿真下拉菜单中切换到 Software-in-the-loop (SIL)。运行并对比先跑 MIL再跑 SIL最后对结果做一致性检查。6.2 配置代码生成打开模型的 Configuration Parameters快捷键 CtrlE在 Solver 面板中确认Type 设置为Fixed-stepSolver 选择discrete或ode8等固定步长求解器Fixed-step size 设置为实际需要的采样周期比如0.001。然后在 Code Generation 面板中确认System target file 选择ert.tlcEmbedded Real-Time如果暂时不需要嵌入式优化可以在 Optimization 中保持默认后续再按需调整。也可以直接使用 MATLAB 命令行脚本完成以上配置这样更方便自动化回归。% 文件路径configure_sil.m mdl sil_demo_pid; load_system(mdl); % 求解器配置 set_param(mdl, SolverType, Fixed-step); set_param(mdl, Solver, discrete); set_param(mdl, FixedStep, 0.001); % 代码生成配置 set_param(mdl, SystemTargetFile, ert.tlc); set_param(mdl, TargetLang, C); save_system(mdl);这段脚本把一个模型强制设置为固定步长、离散求解器并指定 ERT 作为代码生成目标。如果你的开发流程里有多个人协作建议把类似配置脚本纳入版本管理保证团队使用统一的代码生成配置。6.3 通过图形界面切换 SIL 模式配置完成后在 Simulink 模型窗口左上角的“仿真模式”下拉菜单中选择Software-in-the-loop (SIL)。不同 MATLAB 版本菜单位置略有差异但通常都在仿真按钮附近的下拉列表里。选择后点击“运行”Simulink 会先触发代码生成把模型编译为 C 代码再调用编译器生成可执行的 S-Function 动态库。首次运行耗时会明显偏长这是正常的之后如果模型没有变化通常会走增量编译速度会快很多。6.4 通过命令行切换 SIL 模式如果你希望用脚本控制 SIL 运行或者需要批量跑多组实验使用命令行是更好的选择。% 运行 MIL set_param(mdl, SimulationMode, Normal); simOut_mil sim(mdl, StopTime, 1.0); % 切换为 SIL 并运行 set_param(mdl, SimulationMode, Software-in-the-loop (SIL)); simOut_sil sim(mdl, StopTime, 1.0); % 切回普通模式避免影响后续操作 set_param(mdl, SimulationMode, Normal);这里需要强调的是set_param之后调用sim是 SIL 自动化的常用方式。你可以在一个循环里依次修改模型参数、切换仿真模式、采集数据最后统一对比。7. 完整示例闭环控制模型的 SIL 验证7.1 示例模型结构为了演示 SIL 的完整流程这里设计一个简单的离散闭环控制模型。模型结构如下输入Step 阶跃信号幅值为 1Step time 为 0Sum 模块计算给定值与反馈值的误差Discrete PID Controller经典离散 PIDP 设为 1.5I 设为 10D 设为 0.05采样时间 0.001sDiscrete Transfer Fcn一阶惯性环节的离散形式模拟被控对象采样时间 0.001sTo Workspace记录输出信号变量名设为yout保存格式为 Timeseries。在建模过程中被控对象的离散化可以通过 MATLAB 命令完成。假设原始连续对象是1/(s1)用 0.001s 采样周期离散化% 文件路径create_plant.m Ts 0.001; sys_c tf(1, [1 1]); sys_d c2d(sys_c, Ts, zoh); [num_d, den_d] tfdata(sys_d, v);先通过c2d获得离散传递函数系数再把num_d和den_d填到 Discrete Transfer Fcn 模块的 Numerator 和 Denominator 参数中。这一步的目的是让模型在固定步长离散求解器下运行为后续 SIL 对比消除求解器差异。7.2 模型配置脚本完成模型搭建后在 MATLAB 脚本中统一配置模型% 文件路径run_sil_verify.m mdl sil_demo_pid; load_system(mdl); % 配置求解器和代码生成 set_param(mdl, SolverType, Fixed-step); set_param(mdl, Solver, discrete); set_param(mdl, FixedStep, 0.001); set_param(mdl, SystemTargetFile, ert.tlc); set_param(mdl, TargetLang, C); % 运行 MIL set_param(mdl, SimulationMode, Normal); simOut_mil sim(mdl, StopTime, 1.0); % 运行 SIL set_param(mdl, SimulationMode, Software-in-the-loop (SIL)); simOut_sil sim(mdl, StopTime, 1.0); % 切回普通模式 set_param(mdl, SimulationMode, Normal);7.3 结果对比脚本运行完成后读取 MIL 和 SIL 的输出信号计算两者之间的绝对误差并给出判断结果。% 文件路径compare_results.m y_mil simOut_mil.yout{1}.Values.Data; y_sil simOut_sil.yout{1}.Values.Data; t simOut_mil.tout; err abs(y_mil - y_sil); max_err max(err); threshold 1e-6; if max_err threshold fprintf(SIL 验证通过最大误差为 %.2e\n, max_err); else [~, idx] max(err); fprintf(SIL 验证失败最大误差为 %.2e发生在 t%.4f s\n, ... max_err, t(idx)); figure; subplot(2,1,1); plot(t, y_mil, b, t, y_sil, r--, LineWidth, 1.2); legend(MIL, SIL); title(MIL 与 SIL 输出对比); subplot(2,1,2); plot(t, err, k, LineWidth, 1); title(绝对误差曲线); end这段代码的底层逻辑很简单先求每个采样点的绝对误差再判断最大误差是否小于阈值。阈值1e-6并不是一个通用标准实际项目中应根据控制精度和数据类型合理设置。如果模型中有 double 和 int16 混用的信号误差达到1e-2级别都可能正常。7.4 验证一个故意设计的问题为了让读者更直观地理解 SIL 的价值这里可以做一个简单的实验在控制器输出反馈通道上插入一个 Data Type Conversion 模块把 double 信号强制转换为uint16。这样相当于模拟了代码中常见的整型量化问题。在这种模型下再跑一遍 SIL 对比脚本你很可能会发现两条曲线并不完全重合而是存在一个恒定的量化误差带。这个误差带的大小就是 uint16 的量化步长。通过 SIL 验证你能很清晰地定位到“量化误差来源于哪个模块”而不是在台架测试时面对一堆数据无从下手。8. 运行结果与效果验证8.1 如何判断 SIL 验证通过SIL 验证通过的标准并不是“两条曲线看起来一样”而是“在约定的误差阈值下MIL 和 SIL 的最大误差小于阈值”。这个阈值的设定需要结合模型的数据类型和业务需求全 double 模型误差通常在 1e-10 到 1e-6 之间可以把阈值设为 1e-6含 single 信号误差可能在 1e-5 左右阈值可以适当放宽到 1e-4含整型转换误差取决于量化步长建议用量化步长的一半作为阈值含积分环节需要观察误差是否随时间积累不能只看单步误差。8.2 正常情况下的预期输出在配置正确、数据类型一致的情况下SIL 脚本运行结束后MATLAB 命令行通常会出现类似下面的输出SIL 验证通过最大误差为 3.72e-14这个结果说明模型生成的 C 代码与模型本身的行为高度一致差异基本来源于浮点舍入。此时可以放心进入后续的 PIL 或 HIL 验证。8.3 如果失败第一步看哪里SIL 对比失败时不要急着怀疑编译工具或自动生成代码大概率问题出在模型配置上。按以下顺序排查看最大误差发生在哪个时刻——如果发生在信号阶跃的瞬间可能是求解器步长或采样时间对齐问题看误差曲线是否是恒定量化误差——如果是检查模型里的 Data Type Conversion 和 Signal Conversion 模块看误差是否随时间线性增长——如果是检查模型中是否有积分器或者累加器再检查求解器和数据类型看 SIL 启动时是否有代码生成警告——如果有逐条阅读 warnings 中关于数据类型和优化设置的提示。这些排查顺序在多个项目中都验证过能覆盖绝大部分 SIL 失败场景。9. 常见问题与排查思路下面表格汇总了 Simulink 软件在环仿真 SIL 中最常遇到的问题以及对应的排查方式和解决方案。这些内容来自实际项目中的高频踩坑点建议收藏备用。问题现象可能原因排查方式解决方案切换 SIL 后仿真报错“Simulink Coder is required”没有安装代码生成相关授权尝试菜单 Code - Code Generation看是否报授权错误安装 Simulink Coder / Embedded Coder 授权编译失败提示找不到编译器C 编译器未配置或安装不完整在 MATLAB 命令行执行mex -setup安装受支持编译器并执行mex -setup指定默认编译器SIL 仿真结果与 MIL 明显不一致求解器未统一为固定步长或数据类型不一致打开 Configuration Parameters逐个检查 Solver 和 Data Type Override统一固定步长离散求解器检查模型中的类型转换模块SIL 运行速度很慢每次运行都重新生成并编译代码观察 MATLAB 命令窗口是否有 “Building with” 提示调整代码生成重建选项为 “If out of date or read only”。模型无法代码生成模型中包含不支持代码生成的模块使用 Code Generation Readiness 检查模型替换为支持代码生成的模块或用 SIL 只验证目标子系统误差在特定时间点出现尖峰模型存在事件触发逻辑、状态重置或限幅查看该时间点是否有 Saturation 或 Stateflow 状态切换检查饱和、触发、状态重置模块的参数设置SIL 模式下 Scope 模块不更新SIL 以 S-Function 方式运行图形刷新受限将 Scope 替换为 To Workspace再在 MATLAB 中绘图使用信号记录模块采集数据统一在脚本中可视化10. 最佳实践与工程建议10.1 从一开始就按“可生成代码”标准搭建模型SIL 能不能顺利跑通很大程度上取决于模型本身的质量。如果你在建模型阶段就使用离散求解器、固定步长、显式数据类型SIL 验证会顺畅很多。反之如果用变步长连续模型做算法验证到了 SIL 阶段才切换求解器很多问题会被淹没在求解器差异里难以定位。建议团队内部建立建模规范至少包含求解器类型、采样时间策略、数据类型规则、模块命名规则。这些规范看起来不起眼但能极大降低 SIL 验证的调试成本。10.2 建立 MIL 基线SIL 结果自动对比每次 SIL 验证都应该以同一个版本的 MIL 结果作为基线。换句话说先跑 MIL 并保存结果再跑 SIL最后用脚本自动对比。不要只凭肉眼看曲线一定要用数值计算误差。人眼判断在特征明显的误差下有效但遇到积分漂移或微小量化误差时很难靠谱。推荐把所有对比脚本保存为.m文件纳入版本管理。当模型版本更新时重新执行一次就能快速评估改动是否引入了新的代码行为差异。10.3 将 SIL 回归纳入日常开发流程如果团队迭代频繁建议把 SIL 回归测试做成半自动化流程。基本思路是每当模型或配置参数发生变更自动执行 MIL 和 SIL 仿真输出一致性报告。可以在 MATLAB 脚本中用for循环批量执行也可以借助 MATLAB 的 CI 集成能力。即使团队规模不大也至少要做到“模型变更后手动跑一次对比脚本”。这个习惯能避免很多本应在开发阶段发现的问题被带到台架测试阶段。10.4 注意数据类型的作用域和范围SIL 最能暴露的一类问题就是数据类型精度损失。建议在建模时就为关键信号设置合理的数据类型。具体来说控制器内部积分状态、误差计算建议保留 double 或 single。输出到执行机构或底层驱动的信号根据物理量范围和分辨率选择整型并尽量让量程覆盖整个过程范围。使用 Data Type Conversion 模块时必须有意识地考虑量化误差并评估该误差是否会影响控制精度。10.5 代码生成配置统一管理不同工程师使用不同的代码生成配置会导致 SIL 结果不可复现。更稳妥的做法是先通过脚本统一配置再保存和共享脚本。代码生成选项中的优化开关、ERT 选项、内存分配策略都应形成团队默认配置而不是每个工程师按个人习惯设置。10.6 不要用 SIL 替代 PIL 和 HILSIL 解决了“代码是否和模型一致”的问题但并没有解决“代码在目标处理器上是否能正确运行”的问题。目标平台的处理器字长、浮点运算差异、编译器优化、中断时序等只有通过 PIL 和 HIL 才能验证。建议把 SIL 当成嵌入式验证链中的第一道关卡通过之后仍然需要继续做后续验证。11. 总结与后续学习方向回到最初的问题模型仿真正常代码跑起来却不正常。SIL 的价值就是在不离开 Simulink 环境的情况下把模型结果和代码结果拉在一起做对比第一时间发现数据转换、求解器配置、代码生成设置带来的差异。它并不复杂但在基于模型设计的整个验证链条里位置非常关键。如果你打算继续深入建议按以下方向扩展把 SIL 结果和 Simulink Coverage 覆盖率分析结合起来评估模型中的执行路径是否都被测试到了把 SIL 验证脚本接入 MATLAB 的自动化测试框架建立可重复的回归用例集在 SIL 通过后尝试 PIL 验证感受目标处理器对代码行为的影响研究 Embedded Coder 的代码生成配置项理解每个优化开关对代码行为的影响。对做嵌入式控制开发的工程师来说尽早把 SIL 放进日常开发流程比在台架上烧一整天才发现代码问题要划算得多。建议你现在就拿一个已经能跑的 Simulink 控制模型按文章里的脚本跑一遍 MIL 和 SIL 对比看看你的模型和代码之间到底有多大差距。