1. 项目概述为什么我们需要在SIL仿真中记录信号在基于模型的设计流程里软件在环仿真Software-In-The-Loop SIL是一个承上启下的关键环节。它介于纯模型仿真和硬件在环测试之间核心任务是把从Simulink模型自动生成的C代码放到一个贴近目标机的环境中去执行验证生成代码的逻辑功能是否与原始模型一致。听起来很美好但实际操作过的工程师都知道一旦模型生成的代码跑起来如果内部信号“看不见、摸不着”调试过程就会像在黑暗里修手表——无从下手。这就是Test Points测试点这个看似简单的功能在SIL仿真中变得无比重要的原因。简单来说这个项目的核心就是利用Simulink中的Test Points功能在SIL仿真过程中高效、精准地记录我们关心的内部信号为后续的调试、分析和验证提供数据支撑。它解决的痛点非常直接在SIL阶段我们无法像在模型仿真中那样随意用Scope或者Outport来观察每一个信号尤其是那些深埋在子系统内部、并非设计为对外输出的中间变量。如果没有Test Points我们可能需要反复修改模型接口添加大量的临时输出端口仿真完再删掉过程繁琐且容易出错。而Test Points提供了一种“非侵入式”的信号观测方法让你在不改变模型接口和功能逻辑的前提下给关键信号打上“标记”在SIL仿真时自动记录它们的数据。这不仅仅是方便调试。从工程实践来看系统性的信号记录是进行自动化测试、生成测试报告、进行模型与代码一致性比对Back-to-Back Testing的数据基础。无论是验证控制算法的动态响应还是排查一个只在特定编译优化级别下出现的数值问题完整、可靠的信号日志都是你唯一的“证据链”。因此掌握如何使用Test Points进行SIL信号记录是每个从事嵌入式软件模型开发与测试工程师的必备技能。接下来我将结合我多年的项目经验从设计思路到实操细节再到避坑指南为你完整拆解这个过程。2. 核心思路与Test Points工作机制解析2.1 Test Points与普通信号的本质区别很多刚开始接触的工程师会混淆Test Points和普通的信号线。在Simulink画布上它们看起来可能差不多但背后的语义和编译处理逻辑天差地别。一个普通的信号比如连接加法器输出和增益模块输入的线它的存在意义就是传递数据。Simulink在生成代码时会根据优化规则决定它的“命运”它可能被优化掉如果下游逻辑允许可能被嵌入到一个表达式里成为临时变量也可能被赋予一个实际的变量名。但无论如何它的“能见度”很低在生成的代码中很难被稳定地定位和访问。而一个被设置为Test Point的信号则完全不同。当你右键点击一条信号线选择“属性”然后勾选“Test Point”时你实际上是在向Simulink的代码生成器Simulink Coder/Embedded Coder发出一个强指令“此信号非常重要必须为其在生成的代码中保留一个独立的、具有全局或文件作用域的变量并且确保在SIL仿真模式下我能获取到它的运行时数据。”这个指令带来的连锁反应是代码生成优化豁免该信号对应的变量不会被优化消除即使从纯功能角度看它是冗余的。变量显式化它会在生成的代码通常是model_private.h和model.c中获得一个明确的变量名例如model_DW.Integrator_DSTATE。接口暴露Simulink会为SIL仿真框架创建访问这些变量的接口使得外部测试环境如Test Harness或SIL Runner能够周期性地读取这些变量的值。数据记录挂钩当配置了信号记录Signal Logging并启动SIL仿真时仿真引擎会自动将这些Test Point变量的值按时间步长记录下来生成数据集。所以Test Point是一种“设计时”的声明它牺牲了一点微小的代码效率增加了一个变量换取了“调试时”巨大的可视性和可控性。这是一种典型的以空间内存换时间调试时间的工程权衡。2.2 SIL仿真中信号记录的架构设计理解了Test Point是什么我们再来看看它在SIL仿真数据记录中的位置。整个数据流的架构可以这样理解模型层Simulink工程师在模型中标记关键信号为Test Points。这些信号可能包括控制器内部的状态如积分器状态、观测器估计值、故障诊断标志位、复杂的中间计算结果等。代码生成与编译层Embedded Coder根据配置生成包含Test Point变量声明的C代码。然后使用指定的编译器如GCC for ARM TI C28x Compiler将代码编译成可在宿主机你的PC上运行的可执行文件或库。注意SIL仿真编译时通常会关闭一些激进的优化如-O0或-O1以确保调试信息的完整性和变量可访问性。仿真执行与数据记录层Simulink的SIL仿真块通常是一个Model Block配置为SIL模式或专用的SIL测试工具会加载并执行编译好的代码。仿真引擎在每一个时间步长调用生成的代码步进函数如model_step()并在调用前后通过预先注入的接口读取所有被标记为记录状态的Test Point变量值。数据存储与分析层记录下来的时间序列数据被保存到MATLAB的基础工作空间Workspace中的一个结构体变量里默认名称通常是logsout。这个数据集和普通模型仿真记录的数据格式完全一致你可以用同样的方法绘图、分析、计算性能指标或者与模型仿真的结果进行自动化比对。这个架构的优势在于一致性。你在SIL阶段分析信号的方法和你在MIL阶段完全一样工具链是连贯的减少了学习成本和工具切换带来的误差。3. 实操流程从模型配置到数据导出3.1 步骤一在模型中正确设置Test Points这是所有工作的起点但也是最容易出错的地方。设置本身很简单但“设置在哪里”和“如何管理”很有讲究。1. 标记单个信号在Simulink模型中找到你需要记录的关键信号线。右键点击信号线选择“属性”。在弹出的对话框中你会看到“信号属性”标签页。勾选“Test Point”选项。你可以同时在这里给它起一个更有意义的“记录名称”这个名字将直接作为后期logsout数据集中该信号的名字强烈建议修改。比如一个来自PID控制器积分状态信号可以命名为Ctrl.PID.Integrator_State。2. 批量管理与查看对于大型模型手动一个个设置效率太低。Simulink提供了一个强大的工具模型浏览器。打开方式在Simulink菜单栏点击“视图” - “模型浏览器”或者直接按CtrlH。在模型浏览器中切换到“信号”视图。这里会列出模型中所有的信号。你可以通过筛选列快速找到所有“Test Point”属性为“off”或“on”的信号。你可以在这里批量选择多个信号右键选择“属性”统一修改它们的Test Point属性。这对于管理成百上千个信号至关重要。3. 一个关键配置Test Point与信号记录的解耦这里有一个非常重要的细节勾选“Test Point”并不意味着信号会自动被记录。Test Point只是让信号“可被记录”。是否真正记录由另一个独立的配置控制信号记录Signal Logging。 你需要确保该信号的“记录”属性也是打开的。同样在信号属性对话框或模型浏览器中找到“Log signal data”选项并勾选。更常见的做法是在模型配置中统一设置。实操心得我习惯使用一个清晰的命名规范来管理Test Points。例如所有用于调试的Test Point信号其记录名前缀加DBG_所有用于验收测试比对的加VAL_。这样在后期处理logsout数据时可以很容易地用find(strncmp({logsout{1}.Values.Name}, DBG_, 4))这样的命令快速筛选出需要的信号组。3.2 步骤二配置模型的代码生成与仿真参数模型内部的信号标记好后需要在模型配置参数中进行“总开关”式的设置。打开配置参数窗口快捷键CtrlE。设置代码生成在“代码生成”类别下确保“系统目标文件”选择的是支持SIL仿真的目标例如ert.tlcEmbedded Coder或grt.tlcGeneric Real-Time。ert.tlc功能更全是工业级项目的首选。点击“报告”子项确保“创建代码生成报告”是勾选的。这份报告对于查找Test Point对应的变量名非常有帮助。设置信号记录总开关在“数据导入/导出”类别下找到“信号记录”选项。你必须勾选“记录信号数据”。这里记录的就是所有勾选了“Log signal data”的Test Point信号。你可以指定记录数据的变量名称默认logsout和存储格式建议使用Dataset格式它是现代Simulink版本推荐的标准格式比旧式的ModelDataLogs更易用。配置SIL仿真模式如果你打算用一个顶层模型来封装并仿真你的控制器模型这是常见做法你需要将控制器模型块Model Block的“仿真模式”设置为“软件在环SIL”。更直接的方式是在配置参数的“硬件实现”中设置好你的目标硬件设备例如ARM Cortex-M然后在“代码生成”-“接口”中将“软件在环SIL”的仿真模式选为“普通”。之后你可以直接点击模型上的“运行”按钮Simulink会自动执行SIL仿真。3.3 步骤三执行SIL仿真并获取数据配置完成后点击运行按钮。你会注意到与普通模型仿真不同SIL仿真会先触发一个“代码生成与编译”的过程。状态栏会显示“Generating code...”和“Building ‘model’...”。编译成功后仿真才会开始执行。仿真结束后数据会自动记录到工作空间。在MATLAB命令窗口输入whos你应该能看到一个名为logsout的变量或者你自定义的名字。它是一个Simulink.SimulationData.Dataset对象。访问数据示例% 查看记录了哪些信号 logsout % 获取第一个信号的数据假设第一个信号是你关心的 sig1 logsout.get(1).Values; % sig1 是一个 timeseries 对象 time sig1.Time; data sig1.Data; % 或者按名称获取 pid_state logsout.getElement(Ctrl.PID.Integrator_State).Values; % 绘图 plot(pid_state.Time, pid_state.Data); xlabel(Time (s)); ylabel(State Value); title(PID Integrator State during SIL Simulation); grid on;现在你就可以像分析普通仿真数据一样对这些来自真实生成代码运行的信号进行各种分析了。3.4 步骤四自动化与集成进阶在工程项目中SIL测试通常是自动化测试流水线的一部分。你需要脚本化整个过程。% 示例自动化SIL仿真与数据比对脚本 model myController; load_system(model); % 1. 配置为SIL模式 set_param([model /Controller_Model], SimulationMode, Software-in-the-loop (SIL)); % 2. 设置仿真停止时间等参数 set_param(model, StopTime, 10); % 3. 运行SIL仿真 simOut sim(model, ReturnWorkspaceOutputs, on); % 4. 获取SIL数据 logsout_sil simOut.logsout; % 5. 可选运行一次普通模型仿真MIL作为基准 set_param([model /Controller_Model], SimulationMode, Normal); simOut_mil sim(model, ReturnWorkspaceOutputs, on); logsout_mil simOut_mil.logsout; % 6. 自动化比对关键信号 sig_name Ctrl.PID.Integrator_State; ts_sil logsout_sil.getElement(sig_name).Values; ts_mil logsout_mil.getElement(sig_name).Values; % 计算差异例如最大绝对误差 err ts_sil.Data - ts_mil.Data; max_abs_err max(abs(err)); fprintf(信号 [%s] 的MIL与SIL最大绝对误差为 %e\n, sig_name, max_abs_err); % 可以设置一个容差阈值进行自动判断 tolerance 1e-6; if max_abs_err tolerance disp(✅ SIL测试通过。); else disp(❌ SIL测试失败误差超限。); end通过这样的脚本你可以将SIL信号记录和比对集成到持续集成CI系统中每次代码更新后自动验证功能一致性。4. 高级技巧与深度避坑指南4.1 Test Points对生成代码的影响与优化权衡启用Test Points会增加生成代码的ROM和RAM占用因为它阻止了优化并引入了额外的全局变量。在资源极其受限的嵌入式目标上比如某些8位或16位MCU这可能会成为问题。应对策略选择性标记只对你当前调试阶段真正关心的核心信号打Test Point而不是“以防万一”地标记所有信号。问题解决后可以考虑移除部分Test Point标记。使用条件编译Embedded Coder支持基于自定义存储类Custom Storage Class, CSC和宏定义的条件编译。你可以创建一个CSC使得Test Point变量只在定义了DEBUG或SIL_TEST宏时才被生成和编译。这样在生成用于最终产品发布的代码时这些调试变量会被完全移除。这需要更深入的代码生成配置知识通常通过设计数据对象Simulink.Signal并将其与一个自定义的存储类例如ImportedExtern或GetSet关联来实现并在存储类头文件中使用#ifdef包裹变量声明。分组记录不要每个步长都记录所有信号。对于一些变化缓慢的信号可以在Simulink Test中配置触发条件记录或者通过脚本在后期对数据进行降采样处理。4.2 多速率系统与异步数据记录在复杂的控制系统中模型往往包含多个不同的采样速率多任务。例如一个快速内环控制是1ms一个慢速状态观测器是10ms。当你在SIL仿真中记录信号时所有Test Point信号默认会按照基础采样率进行记录吗答案是否定的。关键点Simulink的信号记录机制会尊重每个信号自身的采样时间。一个在10ms任务中计算的信号即使你在1ms的基础步长下运行SIL仿真它仍然只会在10ms的整数倍时间点上被记录。这保证了数据的真实性。可能遇到的问题当你试图将SIL记录的数据与模型仿真数据对齐比对时如果两者的时间向量不完全一致由于浮点数精度或不同的仿真解算器设置直接相减可能会出错。解决方案使用resample函数或同步操作将两个timeseries数据同步到同一个时间向量上再进行比较。% 将SIL数据重新采样到MIL数据的时间点上 ts_sil_resampled resample(ts_sil, ts_mil.Time); % 然后再计算误差4.3 信号数据类型与存储的陷阱这是最隐蔽的坑之一。如果你的Test Point信号在模型中是布尔型boolean、枚举型enum或者是小整型如int8在生成的C代码中它们通常会被提升为int类型进行处理出于CPU字长对齐和运算效率考虑。但在SIL仿真记录数据并传回MATLAB时这个类型转换可能会发生信息丢失或 misinterpretation。案例一个uint8类型的计数器信号范围0-255。在生成的代码中它可能用一个int16变量存储。如果记录接口处理不当MATLAB中收到的数据可能是int16类型。当你将其与模型中同为uint8的仿真数据比对时直接比较会因数据类型不同而失败或者需要显式转换。排查与解决始终检查记录到logsout中信号的数据类型class(ts_sil.Data)。在模型中使用Data Type Conversion模块来显式控制信号在模型边界处的数据类型有时可以改善这一问题。在比对前在脚本中统一进行数据类型转换data_sil cast(ts_sil.Data, like, ts_mil.Data);4.4 大型模型信号记录的性能与管理当模型非常庞大有上千个需要记录的Test Points时会面临两个挑战仿真速度变慢和数据文件巨大。性能优化建议按需记录利用Simulink Test或脚本针对不同的测试用例动态启用/禁用不同组的信号记录。不要在一个测试中记录所有信号。使用数据字典管理将Test Point信号的定义名称、数据类型、Test Point属性在Simulink数据字典中统一管理。这样可以在模型和多个测试用例之间共享配置避免散落在各个模块中难以维护。流式记录与存储对于超长时间仿真如耐久性测试不要试图将全部数据保存在内存的logsout中。可以配置Simulink将数据实时流式存储到磁盘文件如MAT文件或TDMS文件。这需要在仿真配置中设置Simulink.SimulationData.DatasetRef或使用To File模块但后者不如Test Points灵活。后期处理脚本化编写标准的后处理脚本自动从logsout中提取关键性能指标如超调量、稳定时间、RMS误差并生成测试报告。避免每次都手动打开庞大的数据文件进行绘图分析。5. 常见问题排查与实战案例5.1 问题速查表问题现象可能原因排查步骤与解决方案SIL仿真后工作空间没有logsout变量。1. 模型配置中未勾选“记录信号数据”。2. 信号本身未勾选“Log signal data”。3. 仿真因错误而提前终止。1. 检查Configuration Parameters Data Import/Export Signal logging。2. 在模型浏览器中检查关键信号的记录属性。3. 检查MATLAB命令窗口是否有报错。logsout中存在信号但数据全为零或为空。1. Test Point信号在生成的代码中被意外优化掉了。2. 信号所在的分支在仿真条件下未被执行如被使能子系统或触发子系统包裹。1. 检查代码生成报告搜索该信号名确认是否有对应变量。2. 检查模型逻辑确保包含Test Point的模块在当前仿真条件下是激活的。SIL仿真运行速度异常缓慢。1. 记录了过多信号尤其是高带宽信号。2. 编译优化级别过低如-O0。3. 宿主机性能不足。1. 减少不必要的信号记录。2. 在SIL配置中尝试使用-O1或-O2优化需确保不影响调试。3. 考虑将部分记录改为触发式或降采样。MIL与SIL仿真结果存在微小数值差异。这是正常现象。原因包括1. 浮点数运算顺序不同模型仿真与C代码。2. C编译器浮点精度/舍入模式与MATLAB不同。3. 模型与代码使用了不同的数学库函数。1. 首先确认差异是否在可接受的容差范围内如1e-10量级。2. 使用reltol和abstol进行相对/绝对误差比较而非直接判等。3. 检查模型中是否有关键算法对运算顺序敏感。无法在代码生成报告中找到某个Test Point信号。1. 该信号可能被上游的“Signal Specification”或“Bus Creator”等模块的属性覆盖。2. 信号位于被配置为“内联”的子系统中。1. 检查信号流路径上所有模块的代码生成相关属性。2. 尝试将该子系统设置为“非内联”Function packaging 设为Nonreusable function或Reusable function。5.2 实战案例调试一个只在SIL中出现的积分饱和问题我曾经遇到一个典型的案例一个电机位置控制器在模型仿真中表现完美但进行SIL仿真时在特定大指令输入下会出现异常的积分饱和导致系统震荡。排查过程现象确认对比MIL和SIL的误差积分器状态信号已设为Test Point发现SIL仿真中积分器的增长速度和最终饱和值明显高于MIL。初步分析差异指向积分环节。检查了积分器的初始条件、上下限均一致。深入追踪在积分器前有一个计算误差和增益的乘积。我将乘积模块的输出也设为Test Point。发现关键对比发现SIL仿真中这个乘积结果在某个时间点出现了MIL仿真中没有的微小正向尖峰。正是这个持续累积的微小差异导致了积分器的提前饱和。根因定位进一步追溯发现产生误差的模块是一个“量化”模块模拟传感器分辨率。在MIL仿真中该模块使用双精度浮点。而在生成的代码中为了效率相关变量被定义为单精度浮点float。由于从双精度到单精度的转换以及C语言中浮点乘法的舍入方式与MATLAB不同导致了那个微小尖峰的出现。解决方案在模型中对量化模块的输出显式添加一个Data Type Conversion模块强制其输出为单精度single。这样MIL仿真也使用单精度进行计算与SIL环境保持一致。重新进行MIL/SIL仿真比对差异消失积分饱和问题解决。经验总结这个案例清晰地展示了Test Points在定位“模型-代码一致性”问题中的威力。它帮助我们将一个模糊的“行为不一致”问题逐步定位到具体的信号、模块乃至数据类型的差异。没有这些内部信号的记录我们可能需要在生成的C代码中手动添加printf语句效率低下且侵入性强。而Test Points提供了一条清晰、非侵入式的调试路径。