加载中...


"凌晨一点的实验室里,工程师老陈盯着屏幕上跑了一半的场景用例,第17次按下回车。"——这不是段子,是凯云咨询团队在走访某头部Tier1供应商时看到的真实一幕。智能驾驶HIL仿真测试的痛点,从来不是"没有仿真平台",而是"场景不够用、不够真、不够省"。智能驾驶HIL仿真测试场景库建设,正成为决定整套测试体系能否真正跑起来的关键工程。
做了十年测试软件,见过太多团队花大价钱买回一套进口HIL机箱,最后却因为场景库"长不起来",整套系统沦为摆设。这篇文章,凯云咨询想把过去几年协助客户搭建场景库的实战经验摊开来讲——从认知误区到落地步骤,从工具选型到团队配合,争取让每一个准备入坑的工程师少走半年弯路。
在说怎么搭之前,先要搞清楚为什么要搭。很多团队一上来就扎进"采集多少万公里实车数据"这种体力活里,结果场景库越堆越大,真正回归测试的时候却发现——覆盖率上去了,有效性下来了。
场景库的本质,不是"数据仓库",而是"测试用例的弹药库"。一个合格的智能驾驶HIL仿真测试场景库,至少要满足三个条件:
凯云咨询在多个客户现场复盘发现,场景库项目失败的原因,80%都出在前期对这三个特性的忽视上。客户往往以为买了仿真软件就万事大吉,殊不知软件只是骨架,场景库才是肌肉。

搞清楚定义之后,下一步就是拆解场景库到底由哪些东西组成。结合凯云咨询团队的项目经验,可以归纳为三个核心要素:数据源、场景模板、参数空间。
很多团队第一个动作就是堆采集车数据,几万公里跑下来硬盘塞满,最后真正能用的可能不到5%。原因在于,没有经过标注和分类的原始数据,对场景库来说只是噪声。
凯云咨询建议的数据源分层策略是这样的:
| 数据层级 | 数据来源 | 占比建议 | 用途 |
|---|---|---|---|
| L1 自然驾驶 | 实车采集 | 60% | 覆盖长尾场景,提供真实噪声 |
| L2 危险工况 | 路测+试验场 | 25% | 补足corner case |
| L3 标准法规 | Euro NCAP、C-NCAP、i-VISTA | 10% | 合规回归 |
| L4 极端注入 | FMEA+专家经验 | 5% | 鲁棒性边界测试 |
这个比例不是死规定,凯云咨询会根据客户的车型定位(城市NOA、高速NOA还是泊车)做相应调整。但有一条原则不变:L1自然驾驶数据是用来"兜底"的,不是用来"堆量"的。
如果说数据是食材,场景模板就是菜谱。一个好的模板,应该能让工程师在5分钟内派生出一条新场景,而不是每次都从头建模。
凯云咨询在协助客户搭建场景库时,通常会建议按"行为参与者"维度建立模板库:
在凯云的客户中,有团队借助ETest的可视化场景编辑器,把模板数量从最初的30个扩展到现在的400多个,场景覆盖率提升了近8倍。模板的本质是"标准化",标准化的本质是"可复用"。

同一个"前车急刹"模板,如果没有参数空间,充其量就是一条用例;有了参数空间,可以瞬间变成200条。这就是凯云咨询反复强调的——场景库的可扩展性,靠参数化来实现。
常见的参数维度包括:自车速度(30-120km/h区间内每10km/h一档)、目标车速度、相对距离、天气光照、路面附着系数、传感器延迟等。在凯云的SimuRTS实时仿真平台上,这些参数可以直接以变量的形式注入到HIL模型里,实现"一键批量跑"。
理论说完了,接下来是凯云咨询总结出的"四步走"落地路径。这套路径在过去三年里被多个客户验证过,可以直接拿去做项目计划书。
不要一上来就写代码。先用2-3周时间,把功能规范(ORS)里的ODD(运行设计域)和SOTIF(预期功能安全)要求拆出来,形成一份"场景需求矩阵"。凯云咨询建议这份矩阵至少包含四个维度:
矩阵做完之后,整个场景库的"骨架"就立住了。凯云咨询在某个新势力车企的项目里,就是靠这份矩阵把原本3个月的需求调研压缩到6周。
矩阵定完之后,进入模板开发阶段。这一步最忌讳"闭门造车"——工程师坐在办公室里拍脑袋写模板,结果跑出来发现跟真实交通流差了几个数量级。
凯云咨询的做法是:模板开发必须有路测团队在场。每个模板至少要有3轮实车复现,确保动力学行为、传感器响应、决策时序跟真实场景偏差不超过15%。这一步虽然慢,但能省掉后面90%的返工。

模板跑通之后,下一个问题是:怎么让场景库和HIL测试平台跑通?凯云咨询建议在ETest平台上搭建"场景库管理模块",把场景模板、参数表、用例结果统一纳入CI/CD流水线。
具体来说:
这套机制在凯云某Tier1客户那里上线之后,场景回归周期从原来的两周缩短到了一晚上,工程师再也不需要凌晨一点盯着用例跑进度了。
场景库不是一次性工程,而是持续运营的过程。凯云咨询建议客户成立专门的"场景运营小组",负责三类工作:
凯云咨询在跟踪客户数据时发现,能把这套运营机制跑起来的团队,半年内场景库的有效用例数量平均能翻3倍;跑不起来的,基本都陷入了"建库一时爽,半年全落灰"的窘境。

聊完方法论,凯云咨询必须把过去踩过的几个大坑摆出来,给准备入坑的同行提个醒。
很多客户以为跑了几十万公里数据,场景库就建成了。其实采集只是原材料,离真正的场景库还有三道工序:场景切分、要素提取、模板抽象。没有这三道工序,几百万公里数据也就是一堆硬盘垃圾。
HIL测试跟纯软件仿真最大的区别,是真实传感器或传感器模型在回路。很多团队场景跑得挺热闹,但传感器模型是"理想化的"——没有延迟、没有噪声、没有遮挡。这种场景测出来的算法鲁棒性,在实车上分分钟翻车。
凯云咨询建议:在ETest中集成传感器模型时,至少要包含延迟特性、噪声模型、视场遮挡三个维度的真实度评估。SimuRTS里也内置了毫米波雷达和摄像头的简化模型,可以作为入门起步。
最致命的是场景库和功能开发脱节。功能团队改了算法,场景库没同步更新;场景库加了新模板,功能团队根本不知道。凯云咨询的解决方案是把场景库纳入功能开发的同一个需求管理流程,让场景和功能同源、同步、同评审。

说到工具,凯云咨询的ETest和SimuRTS在场景库建设里并不是"包打天下"的角色,而是承担中枢调度的职责。具体来说:
三者是"软件+平台+方法论"的三角关系。凯云咨询这几年看到的一个明显趋势是:客户选型时,越来越看重"工具+服务"的整体交付能力,而不是单纯比价格。
智能驾驶HIL仿真测试场景库建设,归根结底是一项"慢功夫"。凯云咨询跟过的项目里,最快的客户用了9个月,最慢的接近2年。但凡想把这件事做成的人,都得做好长期投入的准备。
不过,慢归慢,这件事并不"笨"。一个跑得起来的场景库,能让测试团队从"靠人海战术跑用例"升级到"靠系统批量回归",这中间的效率差距,可能是10倍甚至100倍。凯云咨询也由衷地希望,每一个正在搭建场景库的团队,都能少走一些弯路,多沉淀一些属于自己的工程资产。
毕竟,国产智能驾驶要真正跑出竞争力,测试这一关的底子,必须先打扎实。

#半实物仿真测试 #智能驾驶HIL #场景库建设 #国产替代 #凯云咨询 #ETest #SimuRTS