告别dSPACE与VeriStand，SimuRTS微秒级实时仿真平台迁移实战

做实时仿真和HIL测试这行，说起来都是泪。我在这个领域折腾了快十年，从dSPACE到VeriStand，哪个平台的脾气都摸得差不多。最近两三年，测试团队里开始正经讨论国产平台，我才第一次认真接触凯云SimuRTS。说实话，一开始我是带着怀疑的，毕竟dSPACE在实时仿真领域的地位摆在那里，VeriStand也在大量项目里被验证过，一个国产平台想让我把工程整个迁过去，凭什么？但真正把项目跑起来之后，我的想法确实变了。

尤其是SimuRTS把仿真周期从1毫秒压到100微秒、再到10微秒还能稳定运行不出错，这在以前要么得加专门的实时硬件，要么就得靠很贵的实时机才能实现。这篇内容我就来聊聊，为什么我会有“再见了，VeriStand，再见了，dSPACE”这种感受，以及从0开始搭建一个SimuRTS实时仿真工程到底要做什么，踩过哪些坑，又拿到了什么结果。这个内容适合正在做HIL测试、快速控制原型、半实物仿真的工程师，也适合正在做实时仿真平台选型、被成本和项目周期困扰的团队参考。

1. 实时仿真平台的行业现状，以及新平台切入的理由

1.1 dSPACE和VeriStand凭什么占据主流

先给不熟悉这块的读者补个背景。实时仿真/HIL测试这个概念并不新鲜，它从二十多年前就进入了汽车电子、航空航天、电力电子等领域。核心思路很简单：在真实控制器还没做出来，或者真实被控对象太危险、太昂贵的时候，用一台实时仿真机把被控对象的模型跑起来，再通过真实IO信号和控制器连接，形成闭环测试。这样既能验证控制算法，又能批量做故障注入和边界工况测试，还不担心把真实设备烧了。

dSPACE能在这个领域站住脚跟，靠的是整套工具链的成熟度。从Simulink模型到代码生成，再从编译部署到实时运行，dSPACE把整个流程打磨得非常顺。你用它的RTI库拖几个模块，配置一下IO，点个build，代码就自动下到实时机里了。工程师不需要关心底层驱动怎么写，不需要懂交叉编译器怎么配，照着流程走就能干活。这种“开箱即用”的体验，在十几年前那个时代确实是降维打击。

NI的VeriStand走的是另一条路线。它更像一个开放的实时测试环境，配合PXI/PXIe机箱，用户可以自己往里挂各种采集卡、通讯板卡、FPGA模块，灵活性比dSPACE高不少。VeriStand的强项在于多通道采集、时序控制、故障注入，以及和LabVIEW生态的无缝衔接。很多做系统级集成测试的团队，尤其是同时需要测多块板卡交互的场景，会更倾向VeriStand。

1.2 用户真正关心的痛点

但这两种主流平台，用了几年之后，一些项目上的实际问题会越来越明显。首先是价格，一个完整的dSPACE HIL系统，硬件加软件加授权，经常是百万级别的预算，很多中小型团队根本下不了手。VeriStand虽然单看软件不贵，但硬件必须用NI家的PXI机箱和板卡，攒一套配置下来费用同样可观。这块成本对大厂来说是“必要投资”，对中小团队就是“无法启动项目”的门槛。

其次是封闭性。dSPACE的实时机、IO板卡、编译器、授权体系是深度绑定的，想扩展一个新接口，要么买它家的专用板卡，要么自己费劲做二次开发。VeriStand的硬件绑定也类似，软件虽然开放，但驱动层对第三方板卡的支持并不算友好。这意味着一旦选型定了，后续几年都被生态锁住，想迁移、想换硬件、想集成自研板卡，处处都在交学费。

还有一个经常被忽略的问题是交付周期。海外平台的订货周期长，遇到紧急项目想快速搭一套HIL环境，流程下来往往等不起。而国产平台比如凯云SimuRTS能切入市场，正是抓准了这几个痛点：价格更接地气、软件开放度更高、硬件适配国产板卡更方便，从下单到出环境的速度也快很多。这些因素叠加起来，确实让很多做实时仿真的团队开始认真考虑迁移方案。

2. 实时仿真到底在“实时”什么：从1毫秒到10微秒的内核逻辑

2.1 实时性与离线仿真的本质区别

很多人第一次接触实时仿真时，会有一个误区：以为“跑得快”就是实时。其实实时仿真的核心，不是单步计算多快，而是每一步计算必须在一个确定的时间边界内完成，也就是所谓的确定性。离线仿真跑100秒还是1000秒，模型结果都不变；实时仿真不行，如果你给的周期是1毫秒，那每个仿真步必须在1毫秒内算完，不管中间的数据量怎么波动，都不能超过这个时间门限。

这个性质很像生产线上的流水节拍。生产线规定30秒出一个组件，不管工人在第5秒还是第28秒完成组装，物品都必须在这个节拍内站上传送带。如果哪个工位这一次35秒才完成，整条线就乱套了。实时仿真里的“乱套”，就是任务超时、数据丢失、抖动变大，严重时系统直接报错停机。所以衡量一个实时平台的好坏，不只是看它标称“最小步长能到多少”，更要看它在那个步长下到底稳不稳，也就是抖动控制得好不好。

2.2 10微秒级别为什么难

1毫秒的实时周期，对现在的主流平台来说基本没有压力。到了100微秒就需要注意模型复杂度了，因为每个周期里能做的工作量只有原来的十分之一。再到10微秒，情况就完全不同了。10微秒意味着每秒钟要有10万个实时调度周期，CPU要在这么短的时间里完成模型计算、IO读写、数据记录、指令通信所有这些动作，任何一个环节出现微秒级的延迟波动，都会直接影响仿真精度和IO信号的时序一致性。

为什么难？有三个层面的原因。第一是操作系统层面，普通Windows根本不适合做这种硬实时任务，线程调度、中断响应、驱动处理都有不可控延迟；所以实时仿真平台必须运行在专门硬化的实时内核上，比如基于Linux的实时补丁方案或者专用微内核。第二是任务调度层面，10微秒周期里，系统要把“模型计算+IO刷新+日志记录”打包成一个严格的任务链，每个任务必须在窗口内完成，CPU稍有波动就会砸在下一个周期上。第三是IO写入层面，模拟量输出、数字量翻转、CAN报文收发，这些动作本身有物理时序要求，10微秒级控制下哪怕GPIO翻转慢了一两个微秒，波形都会畸变。

2.3 从毫秒到微秒，对项目的实际意义

那问题来了，普通项目用1毫秒周期不就行了吗？为什么要费那么大劲去追求10微秒？这要看被控对象本身的动态特性。电机控制、电力电子变换器、航空液压系统，这些被控对象的时间常数非常小，控制器的PWM周期本身就做到了几十微秒，仿真步长如果只做到1毫秒，根本无法描述PWM中间过程的电流纹波和开关暂态。用粗步长跑出来的仿真结果，和真实硬件行为会差得很远，测出来的控制算法性能也没有参考价值。

我在实际项目中遇到过这种情况：把一套电机控制算法先在1毫秒步长的HIL上测，全部指标正常，但把同样的算法烧进真实控制器之后，电流波形就是不对。后来排查下来，是仿真步长太粗，未能捕捉到电流环在小时间尺度内的动态行为，导致仿真验证结果与硬件实测不匹配。只有在100微秒甚至10微秒的步长下，仿真才能把快速电流环的瞬态过程复现出来。这也是SimuRTS喊出“1毫秒到10微秒精准掌控”这个口号时，戳中了很多工程师真实痛点的原因。

3. SimuRTS、VeriStand、dSPACE三者在实际项目中的对比

3.1 选型前先问自己三个问题

在开始对比之前，我觉得每个团队都该先想清楚自己的需求，不然很容易被某一家的宣传带偏。第一个问题：你做的是快速控制原型（RCP）还是硬件在环测试（HIL）？前者重点是把新算法快速跑起来，对IO的丰富度要求不一定高；后者重点是模拟真实被控对象，对实时性和IO的物理真实性要求很高。第二个问题：你未来的项目会用到多少路IO、哪些总线类型？一个项目只有十几路低速IO，和另一个项目有上百路CAN/1553B/模拟量混合信号，平台选型完全不同。第三个问题：团队有没有二次开发能力？如果你希望将来对接自研板卡、自定义协议、深度调优调度策略，平台开放度就比开箱即用体验更重要。

把这三个问题回答清楚了，再去对比平台，心里就有底了。

3.2 平台能力对比

我根据自己的使用体验，做了一个相对主观的对比，这里不追求绝对客观，只罗列我实际感受到的差异。

这个表格里的结论，不是说dSPACE和VeriStand不行，而是在很多细分场景下，SimuRTS已经具备了替代它们的条件。尤其对于预算有限、希望一线工程师能主动介入底层调度、并快速适配自研硬件的团队，SimuRTS的吸引力确实不小。

3.3 我为什么选择在部分业务线迁移

我在实际项目中迁移SimuRTS，不是一步到位把所有测试台架全换掉，而是先选择了一条最适合验证“微秒实时能力”的业务线：电机控制器的HIL测试。这条线的特点是模型里有很多高频开关逻辑，对仿真步长要求高，同时IO通道数量不算特别庞大，适合先做试点。第一批工程跑通之后，我们又陆续把电力电子类的实时仿真项目迁过去，效果都比较稳定。

当然，我也保留了部分dSPACE和VeriStand台架，尤其是已经稳定运行多年、里面有大量历史用例和自动化脚本的项目，短期内不会强行迁。工程上的事情，讲究的是“按需替换”，而不是“为了换而换”。

4. 从0开始建立SimuRTS实时仿真工程

4.1 环境准备：硬件拓扑与软件清单

下面进入正题，聊聊如果现在你手上没有任何现成环境，从0开始怎么把一个SimuRTS实时仿真工程搭起来。先说硬件拓扑，典型结构是“上位机 + 实时目标机 + IO板卡”三层结构。上位机是一台普通Windows电脑，用来跑模型编辑、工程管理、数据监视。实时目标机是一台专门跑模型的机器，SimuRTS对硬件的包容度比传统平台高不少，普通的国产x86工控机就能胜任。IO板卡根据项目需求选配，可以是模拟量、数字量、CAN、串口等。

软件方面，需要一个MATLAB/Simulink环境作为建模工具，我这里用的是R2021b版本。然后要装SimuRTS实时开发套件，安装之后会在MATLAB里多出一套SimuRTS相关的工具箱和命令行函数。还需要一个C/C++编译器和SimuRTS配套的目标机部署工具。整套环境装好之后，建议先跑一遍自带的官方示例工程，确认“模型编译-部署-运行-数据回传”这条链路是通的，再去做自己的工程。

4.2 Simulink模型实时化改造

从0开始建工程，最容易卡住的一步不是平台操作，而是“把普通Simulink模型改成能实时跑的模型”。很多工程师拿一个离线仿真模型直接就想部署，结果各种报错。需要做以下改造。

第一步，把所有连续时间模块替换为离散化版本。比如连续PID模块要换成离散PID，积分器要手动设置采样时间。原因很简单，实时仿真每一拍都必须在固定周期内算完，连续求解器内部会做变步长迭代，这个迭代次数不确定，也就无法满足确定性要求。

第二步，把求解器设置为定步长离散求解器。在Simulink的配置参数里，求解器选discrete (no continuous states)，固定步长设成你想要的仿真周期。如果模型里还残留连续状态模块，这一步就会报错，正好反过来帮你检查哪些模块还没换干净。

第三步，检查采样时间匹配。我见过很多工程出错是因为模型里某些模块的采样时间不一致，导致数据在不同速率之间传递时出现错位。规范做法是给所有模块显式指定采样时间，不要用-1这种继承方式。下面这个简单的MATLAB命令可以帮你在建模阶段快速检查顶层模型的采样时间分布：

% 查看当前系统所有采样时间 [ts, block] = Simulink.BlockDiagram.getSampleTimes('my_model'); % 将采样时间信息输出到命令行，方便核对 disp(table(block, ts(:,1)));

第四步，把模型里的示波器、显示模块全部移除，或者至少不要放在实时执行路径上。这些模块在离线仿真里没什么影响，但部署到实时目标机上之后，刷新显示会抢占周期资源，严重拖慢仿真。如果确实需要观察信号，用SimuRTS的数据记录功能，把需要监视的信号加入记录列表，运行结束后统一分析。

4.3 创建工程、配置周期并部署运行

模型改造完成之后，就可以开始创建实时仿真工程了。在MATLAB环境中，先设置一下当前目录，然后创建工程对象：

% 创建SimuRTS实时仿真工程 proj = simurts.createProject('motor_hil_project'); proj.Model = 'motor_model'; % 指定Simulink模型名 proj.SampleTime = 100e-6; % 100微秒仿真周期 proj.TargetAddr = '192.168.1.100'; % 实时目标机IP proj.TargetUser = 'simurts'; proj.BuildDir = './build';

这里SampleTime的设置需要根据项目工况来定。我的经验是，先按需求选一个略保守的周期，比如控制器PWM周期是50微秒，那仿真周期至少要设到25微秒甚至10微秒，才能比较完整地还原PWM行为。不要一上来就追求最小时步，先把模型和工程链路跑通，再逐步压周期。

接下来的部署流程一般是：一键生成代码、交叉编译、通过以太网下载到目标机、在目标机上启动实时内核。比较友好的地方在于，SimuRTS的部署动作都被封装成了命令行函数，常见操作不需要手写Makefile。

% 生成代码并构建实时可执行文件 simurts.build(proj); % 下载到目标机并启动仿真 simurts.deploy(proj); simurts.start(proj);

部署成功后，就可以用SimuRTS的监视界面实时查看模型中的关键信号，也可以通过脚本方式批量抓取数据。实际项目里我更习惯用脚本，因为界面操作没法固化和回放，脚本可以重复跑回归测试。

4.4 数据记录与结果验证

实时仿真跑到最后，大家关注的一定是“结果对不对”。这里我强烈建议从一开始就把数据记录功能设计好。SimuRTS支持按信号列表记录数据，记录深度需要根据仿真时长和采样周期计算。比如100微秒周期跑10秒，单通道就是10万个采样点，按double类型存储大约800KB，如果同时记录几十个信号，内存压力立刻上来。我的做法是只记录关键信号，不相关的驱动内部变量全部排除。

跑完以后，把数据导回到MATLAB做对比分析。这里有个经验可以分享：实时仿真跑出来的结果，不要直接和离线仿真的结果完全对齐，因为实时系统里有IO延迟、数据量化误差、任务抖动，这些在离线仿真里都不存在。应该做的是看趋势是否一致、关键指标是否在误差范围内，而不是追求逐点重合。

5. 实测记录：不同仿真步长下的实际表现

5.1 测试场景与平台配置

说了这么多理论，上一段我自己的实测数据，这样更有说服力。测试场景是一套永磁同步电机控制器的HIL仿真，模型包含电机本体、逆变器、PWM调制和简单负载模型，IO部分用了一块8通道模拟量输入、4通道模拟量输出和一路CAN通讯板卡。实时目标机用的是某国产x86工控机，处理器是4核2.4GHz，操作系统是SimuRTS官方自带的实时内核。上位机通过千兆以太网连接目标机，整个链路都是标准商用硬件，没有加任何订制。

5.2 改周期之后的实测结果

我在完全相同的模型和硬件条件下，分别把仿真周期设置为1毫秒、100微秒、10微秒，每组连续跑10分钟，用平台自带的统计功能记录了任务执行时间和抖动数据，结果整理如下：

可以看到，同样是这套模型，1毫秒周期时CPU占用率只有5%左右，说明模型本身不算重；100微秒周期时任务执行时间42微秒，占用了接近一半的周期预算，抖动仍在可接受范围；到了10微秒周期时，平均执行时间已经压到9.2微秒，CPU占用率92%左右，抖动控制在了1.5微秒上下，虽然已经比较紧张，但整个过程没有出现任务超时。

5.3 结果怎么读

这组数据说明几个问题。第一，1毫秒周期对大部分汽车电子HIL测试来说确实够用，平台跑起来非常轻。第二，如果你要测的是电机电流环、PWM调制这类快速动态，就必须把周期压到100微秒甚至更低，否则结果失真。第三，10微秒周期下CPU占用率92%，说明模型在这个平台上已经接近计算能力上限了，如果后续还要增加模型复杂度，要么换成算力更强的处理器，要么把高速模块拆到FPGA上去执行。

所以我理解SimuRTS强调“1毫秒到10微秒”，不是说所有项目都该往10微秒压，而是给不同动态特性的被控对象都提供了一个可用的实时区间。你按项目需求选择周期就行，平台保证的是在选定周期内不丢步、不超时、抖动可控。

6. 常见问题与排查技巧实录

6.1 典型问题速查表

从0开始搭环境的过程中，不管是官方文档还是社区教程，都很少系统地整理踩坑经验。下面把我在实际项目中遇到的问题和解决方法整理成表格，方便各位排查定位。

6.2 几个我踩过的坑

第一个坑，是把一个连续PID模块留在了10微秒周期的模型里。离线仿真完全没问题，但部署到实时目标机上，连续模块引入的迭代求解让任务执行时间波动很大，时不时触顶。后来我把PID全部换成离散版本，并给积分项适配了和步长一致的采样率，波动才彻底消失。核心教训是：实时仿真的第一步不是优化代码，而是把模型彻底“离散化”。

第二个坑，是记录通道开得太多。一开始我以为数据记录是并行的，不影响主循环，结果在10微秒周期下发现任务执行时间涨了将近一倍。后来把不需要监控的中间变量全部从记录列表移除，只保留控制量和关键反馈量，执行时间立刻回到正常水平。记录数据本来就会占用内存带宽和CPU时间，并不是“免费午餐”。

第三个坑，是实时循环里放了Display模块。我第一次调试时图省事，在模型里放了个示波器想实时看波形，结果发现任务执行时间波动很剧烈。排查到最后才意识到，图形刷新把实时调度拖垮了。后来我改成用命令行接口抓数据，把数据快速导出到MATLAB工作区再做可视化，效率和稳定性都好很多。

这几点都不算高深的问题，但对于刚接触实时仿真平台的用户来说，每一个都可能浪费掉一整天排查时间。提前写出来，希望看到这篇内容的人能少走弯路。

7. 一点个人心得

这次把一个新平台用下来的过程，我最大的体会是：不要因为“国产”“新平台”这些标签就轻易否定一个工具，也不要因为“国外老牌”就默认它是唯一选择。实时仿真平台这类工具，最终还是要回到“能不能在规定时间内把活干完、干好”来评判。SimuRTS已经做到了在很多项目里用更低的成本、更快的交付速度，把1毫秒到10微秒这个区间踏踏实实地跑稳，这就已经足够让我认真对待它。

最后再分享一个小建议。如果你所在团队也在考虑从其他平台迁移过来，千万别一次性把所有项目都搬过来。先挑一个周期要求明确、IO规模适中的项目做试点，把模型改造规范、工程配置流程、数据记录方案这一整套沉淀下来，跑通之后再逐步扩展。这样既能控制风险，也能在团队内建立起一套可复用的迁移经验。对于长期被高昂授权费和技术绑定困扰的团队来说，这条新路值得试一次。