加载中...


"你们这实时仿真软件,最坏情况延迟能到多少微秒?"在某工业控制设备的验收测试现场,凯云的技术工程师被客户连续追问了三次。这个问题看似简单,却是决定一套HIL系统能否真正满足被测件时序要求的"及格线"。
带着同样的疑问,我们拿到了SimuRTS——这款被凯云定位为"国产实时仿真内核"的软件产品,用连续一周的高强度测试,回答了它到底值不值得选这个灵魂拷问。


在正式开测之前,有必要先把很多工程师对实时仿真软件的认知误区捋清楚。
很多初次接触HIL测试的工程师会问:"我现在的离线仿真模型跑一次才几秒钟,实时化之后会不会更快?"这是一个根本性的概念混淆。实时仿真的核心约束不是"快",而是"确定性"——模型必须在严格精确的时间步长内完成计算并输出结果,这个步长通常在微秒到毫秒量级,与真实物理世界的时序保持一致。
SimuRTS的设计逻辑正是围绕这个确定性展开。它不是追求让模型跑得飞快,而是确保模型在每一个时间片内都能按时完成任务,哪怕负载突然飙升,也能通过优先级调度保证关键任务的实时响应。
半实物仿真测试平台是一个完整的系统,实时内核只是其中一环。一套能真正交付使用的HIL系统,还需要信号接口硬件(IO板卡)、通信协议支持(CAN、RS422、以太网等)、以及与上层测试软件的数据交互能力。
凯云的策略是将SimuRTS与ETest测试平台深度整合,形成"内核+外壳"的完整解决方案。SimuRTS负责模型实时运算的确定性保证,ETest负责测试用例编排、信号激励生成、数据采集分析。这种组合在实际项目中的适配效率,远比单独采购裸内核再自己集成要高出不少。
这是最容易被供应商宣传带偏的一点。CPU主频固然重要,但决定实时性的关键在于系统调度策略、内存访问延迟、以及中断响应机制的综合表现。单纯堆CPU核心数而不优化调度算法,往往适得其反。
凯云在SimuRTS的技术白皮书中特别提到了"确定性调度引擎"的概念,声称通过优先级继承协议防止优先级反转,并通过CPU亲和性绑定将实时任务锁定在特定核心上运行。这套机制是否真的有效,我们后续会通过压力测试来验证。
为了确保评测结论的可信度,我们搭建了一套标准化的测试环境,并设计了三个维度的测试用例。
考虑到很多客户实际部署时的选型困惑,我们特意测试了两种典型配置组合:

| 组件 | 配置方案A(入门级) | 配置方案B(性能级) |
|---|---|---|
| CPU | Intel i7-9700(8核@3.0GHz) | Intel Xeon W-2295(18核@3.0GHz) |
| 内存 | 32GB DDR4 ECC | 64GB DDR4 ECC |
| 实时操作系统 | Linux PREEMPT_RT补丁 | Linux PREEMPT_RT补丁 |
| IO板卡 | PCIe多功能采集卡 | PCIe高速DAQ模块 |
这里要特别说明为什么选择Linux PREEMPT_RT而不是裸机RTOS。凯云的技术文档显示,SimuRTS基于Linux内核构建,选择PREEMPT_RT补丁的原因是它在保证实时性的同时,能兼顾Linux生态的丰富工具链和驱动支持。对于需要对接大量工业协议的HIL场景,这个选择是务实的。

我们在配置方案B上运行了一个典型的控制回路模型(采样周期1ms),在正常运行、50%负载注入、100%负载注入三种状态下各采集了4小时数据。以下是统计结果:
| 测试状态 | 平均时间偏差 | 最大时间偏差 | 抖动标准差 |
|---|---|---|---|
| 正常负载 | +0.8μs | +12.3μs | 2.1μs |
| 50%负载注入 | +1.2μs | +18.7μs | 3.4μs |
| 100%负载注入 | +2.5μs | +31.2μs | 5.8μs |
几个值得关注的点:首先,所有测试状态下最大时间偏差都控制在100μs以内,这对于1ms采样周期的控制模型来说完全在可接受范围内。其次,即使注入100%满负载,时间偏差也从未出现过负值(即模型从未"超前"于真实时间),这说明SimuRTS的调度策略是偏保守的,优先保证不会超时。
72小时连续压力测试期间,没有出现任何一次超时情况。用测试工程师的话说:"跑了一整夜,中间去接水的时候看了一眼示波器,模型输出和外部时钟的对齐精度一直在小数点后三位晃悠。"
这项测试模拟的是外部硬件中断触发后,模型需要多快给出响应。我们用信号发生器产生一个上升沿脉冲,同时用示波器监测触发信号和模型输出信号的时差。
在配置方案A(入门级)上的测试结果:
在配置方案B(性能级)上的测试结果:

坦白说,这些数据放在国产实时仿真软件里是相当有竞争力的。对比dSPACE的Scalexio系统(公开资料可查的延迟指标在5μs量级),SimuRTS在高配置方案下已经非常接近。当然,Scalexio的测试环境和我们的未必完全一致,这个对比仅供参考。
多任务调度是考验实时内核功力的关键场景。我们设计了一个"陷阱测试":三个仿真任务A、B、C优先级依次降低,但在特定条件下,低优先级任务C会持有某个共享资源,导致高优先级任务A被阻塞。如果系统没有优先级继承机制,就会发生优先级反转,导致A任务响应超时。
测试方法是在任务C运行时人为注入一个延时,模拟它意外卡住的情况。开启SimuRTS的优先级继承协议后,A任务的响应时间从理论上的无限大降回了正常范围(<20μs)。关闭该协议后,A任务果然出现了数百微秒的响应延迟。

这个测试验证了SimuRTS的优先级继承机制是真实有效的。对于需要在同一套系统里同时运行飞控模型、动力系统模型、机电耦合模型的复杂场景,这个功能直接决定了系统能否稳定运行。

光有实验室数据还不够,我们找了三个有代表性的客户场景来验证SimuRTS在实际项目中的表现。
某汽车零部件供应商在开发电动助力转向控制器时,需要在硬件在环平台上验证控制算法的有效性。他们之前用的一套进口方案,模型和控制器之间的信号同步经常出问题,换了凯云的ETest+SimuRTS组合之后,测试效率提升了约40%。
项目负责人反馈,SimuRTS的确定性调度让他们能放心地把采样周期压到500μs级别,而不用像以前那样留出大量余量来应对时序抖动。"以前调参数要跑两遍才能确认结果,现在一次过。"
协作机器人厂商在研发六轴机器人控制器时,需要实时仿真机械臂的动力学模型。机械臂模型的计算量随关节角度变化波动很大,对实时内核的稳定性要求极高。
SimuRTS在连续72小时不间断测试中表现稳定,模型的计算周期始终保持在1ms以内,关节力矩输出和实际物理信号的同步误差小于5μs。项目团队最终用这套平台完成了从算法验证到控制器定型的大部分测试工作。
某科研院所在做卫星姿控系统的半实物仿真时,对平台的可靠性和扩展性有严格要求。SimuRTS的分布式架构允许通过多台计算节点扩展仿真规模,这个特性在他们的大系统仿真项目中派上了用场。

同时,凯云提供的本地化技术支持是他们最终选择国产方案的重要原因——进口平台的服务响应周期通常需要2-3周,而凯云工程师可以现场配合调试,"有什么问题当场解决"。
经过这轮全面评测,我们对SimuRTS的目标用户画像算是清晰了。

回到文章开头那个问题:SimuRTS到底值不值得选?

从这次实测来看,SimuRTS的核心性能指标已经达到了"好用"的基准线——时间确定性在微秒级、多任务调度机制完善、与ETest的整合降低了使用门槛。对于大多数工业控制、机器人、航空航天科研等领域的HIL测试需求,这套方案的性价比是实实在在的。
当然,我们也要客观承认差距。在一些极致性能指标和生态丰富度上,国产实时仿真软件与国际头部产品仍有追赶空间。但这个差距正在以肉眼可见的速度缩小。
某客户在验收报告里写过一句话,我觉得放在这里挺合适:"以前觉得国产HIL平台只能'凑合用',现在发现有些地方已经'够用了',再过几年,说不定就是'真好用'了。"
这大概就是国产半实物仿真测试平台当前的真实写照吧。

最后分享几个测试过程中遇到的小插曲。
第一次跑100%负载测试时,我们担心系统会过热,结果发现SimuRTS的CPU亲和性绑定机制把负载均匀分布到了特定核心上,风扇转速比预期稳定很多。
在做多任务调度测试时,我们故意注入的"陷阱"任务差点把测试环境的文件系统搞挂——低优先级任务持有共享资源后,如果实时内核没有保护机制,很可能引发死锁。SimuRTS的优先级继承协议及时介入,化解了这次人为制造的"危机"。
还有一个小惊喜:SimuRTS的错误日志记录相当详细,出现异常时会精确记录是哪一行模型代码、哪个时间步、产生了什么偏差。这对排查复杂仿真中的偶发问题非常有帮助,比某些进口软件含糊的报错信息强太多。
整体来说,这是一次超出预期的评测体验。凯云咨询作为深耕国产测试仿真领域多年的团队,确实在这套产品上下了真功夫。
