这家公司，竟然解决了这些困扰智能驾驶测试很久的难题

事故背后“隐秘的角落”

2021年9月底，一辆鲁L牌照的车辆在高速上追尾挂车的视频在网络上得到了广泛传播。

近期这类事故之所以频频发生，一方面是因为有些厂商存在夸张宣传和概念混淆的问题，另一方面，也有业内很多人士认为，当前智能驾驶辅助的功能测试验证出了问题。

根据视频，涉事车辆没有明显减速，直接撞上前面的挂车。

其官方的回复是“根据后台检测的行车数据，进行了初步的分析，在发生碰撞前，系统的前车识别及车辆控制，安全带震动提示，车辆预警，AEB等功能均处于正常工作状态。”

如果真如其所说的“AEB功能正常”，那为什么没有提前急刹呢？

这就涉及到AEB的性能定义了。

事实上，车企在进行AEB功能定义时，会设定一个触发条件，如果自车速度和前车的速度各自超过一定的范围，系统就可能不会触发AEB功能进行紧急制动。

此外，Euro NCAP和C-NCAP的测试标准中，也均未对自车车速过高时（C-NCAP自车车速最高60km/h，Euro NCAP最高80km/h）的AEB功能做出要求，而且只规定了目标车（前车）速度为20km/h的测试工况。

所以，根据媒体报道事故中的情况，当自车车速120km/h，前方卡车速度为60km/h时，即使“AEB功能正常”，AEB也很可能是覆盖不了的，系统可能仅仅给了预警，而没有采取紧急制动来避免该次事故。

也就是说，不论厂商宣传自己AEB的速度覆盖范围有多少，由于法规没有要求，而车厂做了什么测试，测试结果的一致性如何，谁也不能保证。

这时，也会有人问，事发时车主开启了NGP，NGP的功能是比ACC（自适应巡航）还要高级的（功能上有覆盖），难道ACC功能也不能避免类似事故吗？

说实话，还真不能。

在ACC功能下，为保证高速下的舒适性和安全性，当车辆行驶速度高于20m/s（即72km/h）时，ACC系统不能进行紧急刹车——最大的制动减速度被限定在不超过3.5m/s^2（ISO 15622-2018），也就是说，即使感知系统能够准确无误地识别出物体，ACC也无法避免事故的发生。

而事发时的驾驶员，显然并不知道这一点。

从媒体公布的信息看，涉事车主由于过度信赖车辆的NGP系统，认为其能够识别到前方的大货车并能够避免事故的发生，从而错失了接管车辆的最佳时期，进而导致事故的发生。

这起事故也并非唯一，另一品牌的车辆近期也接连出现两起事故，都是前方有车辆，自车直接撞了上去，一次是横在路边的面包车，另外一次是高速公路养护车辆。

实际用户在使用时，会预估所谓的“L3级”智能驾驶系统（NOP/NGP）是有能力处理该类场景的，但是实际上系统并不具备该能力，也就是说用户对系统的功能预期，和实际系统能实现的功能之间，有一条巨大的鸿沟。

除了L2的驾驶辅助功能被驾驶员“滥用”产生安全事故外，L3相关法规的进展，也让真正的L3级自动驾驶变得“近在咫尺”，随时而来的是问题和挑战。

2020年，欧洲通过了有关自动车道保持系统（Automated Lane Keeping System，简称“ALKS”）的规定（以下简称“UN-R157法规”），这是全球范围内首个针对L3自动驾驶功能决议的具有约束力的国际法规，于2021年1月份生效。

德国也通过上述法规落地，2022年上半年奔驰两款新车搭载该功能，并被允许能够在德国高速公路，以最高60公里/小时的速度（交通拥堵时）实现有条件自动驾驶，驾驶员可以“脱手脱眼”。一旦超出限定条件，车辆会提前发出警告，提示司机接管，驾驶员需要在10秒内接管车辆。如果驾驶员不能及时接管，车辆会逐渐减速，直至停止。

如果在使用该系统时发生了事故，是谁来负责呢？很简单，如果是系统问题引起的，则是车企的责任，如果是驾驶员无视系统警告发生了事故，则是司机的责任。

此时，摆在车企面前的难题是：如何保证系统的功能能覆盖符合条件的所有场景，而不会出现“漏网之鱼”，即不会出现系统不能覆盖，也没有及时识别并退出（驾驶员也没能接管）的危险场景。

据报道，使用奔驰 L3 系统需要符合以下条件：高速公路堵车，时速60公里以下，有高清地图，车道清晰，没有隧道和施工路段，没有极端天气。

也就是说，系统不仅要考虑到对自身软硬件的功能，还需要全面考虑不同天气、光照条件，需要考虑所有相关交通场景（如其他车辆cut-in等）来保证整体功能安全，如何保证呢？

这显然是个新问题，也是个极难解决的问题。

那这个问题该如何解决呢？

拿着旧地图，永远找不到新大陆。这时候，我们需要引入预期功能安全（SOTIF）的概念。

预期功能安全（SOTIF）的思想启示

SOTIF，即 Safety of The Intended Functionality（预期功能安全），ISO/PAS 21448中对于预期功能安全是这样定义的：由于预期功能的功能不足（功能受限）或者合理可预见的人为误用造成的危害，而不存在不合理的风险（absence of unreasonable risk due to hazards resulting from functional insufficiencies (performance limitations) of the intended functionality or from reasonably foreseeable misuse by persons），其中关键词是功能不足（功能受限）和人为误用。

功能不足，指的是超出系统性能限制的事件，比如极端工况下的传感器功能限制、算法功能不足等；人为误用，指的是不以预期的方式使用系统，如驾驶员过度相信系统的功能、未能将手放在方向盘上、未对对预警及时响应等。

可能大家看到这个描述还不是很清晰，我们可以进一步分析下：

以ADAS系统为例，按照系统功能表现是否正常，可以分为4类情况：

在危险场景介入（正常触发）
在非危险场景介入（误触发）
在危险场景不介入（漏触发）
在非危险场景不介入（正常关闭）

第1、4种情况下系统工作正常，没有风险，而在第2、3种情况系统工作异常，有风险，而SOTIF要解决的问题就是误触发和漏触发的问题。

要有效避免误触发和漏触发，首先需要对所有场景进行识别并分类，确定哪些场景下系统的功能能够正常触发（此时状态安全，safe），哪些场景下系统功能不能正常触发（此时状态不安全，unsafe，需要驾驶员及时接管车辆）。

如果不能够进行准确识别分类的话，就会出现上文中发生过的事故：驾驶员以为系统能够正常触发，所以没有及时接管车辆，而实际上系统既没有触发功能从而避免事故发生，也没有进行功能退出，从而造成惨祸的发生。

那如何对场景进行分类呢？

SOTIF将所有的场景，按照Known（已知）/Unknown（未知）和安全（即系统能够正确触发功能，Safe）/不安全（即系统不能正确触发功能，Unsafe）两个维度，划分成四个部分：

SOTIF对所有场景的分类

对于系统而言，区域1（Known safe scenarios）和区域4（Unknown safe scenarios）是不用担心的，真正需要担心的是区域2（Known unsafe scenarios）和区域3（Unknown unsafe scenarios）。

所以SOTIF的目标就是：最大可能减小区域3和区域2的面积，最大化区域1的面积。

针对减少区域3（Unknown unsafe scenarios）的面积，SOTIF也没有更细节的方法，只是建议通过大量的开放道路测试和仿真测试等持续积累数据，尽可能地将Unknown scenarios变成Known scenarios，不断将检测到的危险场景移动到区域2，从而将减小区域3。

针对减少区域2（Known unsafe scenarios）面积，SOTIF建议通过安全分析，识别出风险场景，针对风险场景开发应对的策略（如请求驾驶员接管或者功能降级使用等），再采取技术设计手段，对已知场景进行针对性的持续系统优化。如通过仿真或者实车测试来进行测试验证，和传统的V模型开发理念差不多，最终通过系统的不断优化，从而将场景转移到区域1中。

一开始，区域2和区域3的面积可能会很大，从而潜在风险太大，但是随着SOTIF对系统的不断优化，区域2和3的面积逐渐变小，并最终达到一个可以证明这些区域足够小，小到潜在风险可以被接受的状态。

开发过程中，区域2/3面积将减小，区域1面积将增大

虽然SOTIF的思想非常具有指导意义，但是ISO/PAS 21448中，更多的是定性分析，缺少定量分析的可实施措施，这就给SOTIF的具体落地增加了困难。

至今为止，法规也是严重滞后的，Euro NCAP和C-NCAP中只定义了AEB简单功能的测试规范，并且，这还不是强制标准。

除了法规严重滞后外，也没有行业规范来告诉大家应该如何进行自动驾驶系统的开发和测试验证。

而实际情况是，NGP功能、NOP功能，虽然还只是L2级别，但经常被消费者误以为可以“解放双手”，自然不能仅仅以C-NCAP来自己要求。

在行业标准和国家法规严重缺位的当下，有担当的车企，应该本着对用户负责的精神，更积极地探索如何对自动驾驶系统进行更充分的测试和验证。

“基于场景测试”的新思路

L2及以下的自动驾驶功能，一般只采用“基于需求的测试”（Requirement based test），L3的自动驾驶功能通常为许多L2功能的组合，但由于从L2到L3的升级过程中，部分驾驶责任由人转到了系统，自然对L3的系统功能就有了更高的要求，不仅要考虑到对自身软硬件的需求，还需要全面考虑不同天气、光照条件，需要考虑所有相关交通场景来保证整体功能安全，新的测试方法也应运而生。

为此，SOTIF引入了一种新的“基于场景的测试”（Scenario based test）。

场景描述了不同情境（scenes）之间的时间关系，情境又是外界环境、交通物理设施（路面、交通灯等）和其他交通参与者（行人、车辆等）、自车的驾驶情况及其相互关系的描述。

场景既是描述复杂交通情形的重要方法，也是对传统基于用例（use case）和基于需求的测试（Requirement based test）的补充。

增加场景的定义，可以确保在自动驾驶系统开发过程中的准确测试验证，还可以改善系统开发在V模型中从左到右的可追溯性。

所以，随着“基于场景的测试”的广泛应用，测试用例将会更加具体，更加细化，测试的工作量也会急剧上升。

另一方面，随着行业发展，法规也会越来越严格，法规中的测试用例也会越来越多。

当前仅AEB有法规标准，后续法规还会继续增加对新功能的测试（如ACC/TJA等），每增加一项测试功能，都会新增一系列的测试用例。

除了新增的项目外，已有的法规项目，也会根据实际发生的交通事故，抽象为各种认证规范，继续更新到法规的测试用例中去。

以上还仅仅是新车上市前的法规认证，更不用说每次系统的OTA。

不少监管机构都抱怨过OTA升级，因为“每一次OTA升级后，理论上都是一辆新车”，而监管机构对此是无法监管的，于是形成了监管漏洞。

不过，工信部近期发布了《关于加强智能网联汽车生产企业及产品准入管理的意见》，其明确规定，后续将OTA升级功能纳入监管范围内。

所以车企每OTA一个版本，都要进行相关的认证测试。

考虑到测试认证的工作量，业内有人认为，后续的OTA的测试可能是企业提交自测报告（仿真测试为主，实车测试为辅），然后法规认证试验中，除了必做的常规认证外，并非将所有的测试用例全部做一遍，而是随机从中抽取用例进行测试，用以确认企业提交自测报告的真实性和一致性。

综上，随着行业的发展，自动驾驶系统从只需满足L2级别的特定功能要求，到后续扩展到有条件自动驾驶（所谓的“L3”）或高度自动驾驶（L4）系统等需要满足各类场景的功能需求，会导致汽车测试与验证的场景数量以几何级数增加，且实际场景因天气、道路、交通参与者、工况等因素的多变而具有复杂性、随机性和不确定性，测试与验证的复杂度也会增加很多，也对测试体系发起了很大的挑战。

那么，当前行业里有哪些测试验证手段？能否满足接下来的需求呢？

测试手段盘点

自动驾驶汽车在正式投产之前，必须进行充分的功能安全和性能安全测试验证，以确保用户和公众的安全。按测试对象来区分的话，可以把这些测试验证分为模块级、子系统级和整车级的测试验证，其测试过程也是一步步进行。

模块级测试，主要验证单个模块的性能及可靠性，如VCU模块；子系统级测试主要验证某个子系统的性能和可靠性等，如定位系统；整车级测试，主要在整车环境下进行各种专项试验（如AEB）和耐久试验等。

一般来说，问题发现得越早，解决问题的成本也越低，模块级和子系统级的试验能够提早发现问题，而整车级试验，则是车企进行各种测试验证和验收的“终极考试”，也是各种法规认证的试验方式。下面，我们重点讨论整车级测试验证。

自动驾驶系统的整车级测试验证，可以分为硬件和软件两个系统的测试。

自动驾驶的硬件测试，和传统系统的测试差异不大，有很多成熟的经验可供参考，最大的差异点和难点是软件系统。

一方面，由于自动驾驶是“基于场景的测试”，需要特定场景触发（如天气、交通流等）才能进行进行测试；另一方面，基于传感器的硬件系统和基于深度学习的算法系统，存在很大不确定性，尤其是遇到极端天气和周围环境。这进一步加大了测试的难度。

所以需要探索，如何更好地构建整车级的自动驾驶软件系统测试验证体系。

按照V模型的开发流程，可以把测试验证方案分为软件仿真测试（MiL/SiL）、台架测试（HiL）、封闭道路测试（ViL/RiL）和开放道路测试（RiL）等方式。

自动驾驶软件开发流程

软件仿真测试，包括模型在环（MiL）和软件在环（SiL），可以快速验证模型的算法策略和功能逻辑，提前发现系统缺陷和故障，极大降低了后期故障排查的成本，具有效率高、成本低的优势，缺点就是只能验证宏观逻辑，真实性低。所以，软件仿真测试在前期的算法系统开发阶段中发挥了重要作用，但也还需要真实性更高的测试方法，尤其是涉及到安全的试验和涉及到认证的试验。

台架测试，也是开发期间的重要测试手段，硬件在环（HiL）能够将软件搭载硬件进行测试，真实性较仿真更进一步。硬件在环（HiL）通常被用来做系统集成测试，验证自动驾驶车辆环境感知等重要模块的功能有效性。HiL测试通过后，还需要进行车辆在环(ViL）测试，将自动驾驶系统集成到真实车辆中，构建模拟道路、交通场景以及环境因素，实现自动驾驶功能验证、自动驾驶系统与整车其他系统的匹配及集成测试。

针对自动驾驶系统功能的台架ViL试验，当前业内仍有一些问题亟待解决：

当前ViL台架还是以纵向运动的功能测试为主，如ACC/AEB等，对于车辆横向运动的功能测试（如车道保持（LKA）、自动变道(LCA）等），仍有一定难度；
ViL台架上感知环节的输入，多来自于外界注入（如仿真软件输出），真实性仍有不足；
因为车辆仍旧在台架或者转鼓上，没有和地面进行真实接触，所以在车辆动力学方面仍有一定差距。

开放道路测试是高等级自动驾驶的重要测试手段，因为有真实感知环节输入和交通流参与，真实性最高，但是由于测试数据大部分是无效数据，测试重复性差，测试成本最高、效率最低，且安全性最低，万一发生交通事故，稍有处理不慎还会有舆情风险，所以一般将开放道路用于发现corner case的场景，然后将该场景沉淀下来，并到仿真系统和台架、封闭道路上进行测试验证。

封闭试验场，由于风险可控，真实性较高，在整车级功能测试中发挥了重要作用，尤其是法规认证试验（如AEB），更是必须在试验场封闭道路上进行。

当前测试手段优势及局限性对比

不过，测试场的封闭道路测试也有不少痛点。

最大的痛点，就是由于对车辆和周边环境（如目标物）的高要求，测试效率不高，比如需要在试验前布置目标物，单单布置一个可以遥控的假人，光零件组装就要花一个小时，中间涉及到无数的线束和传感器，当天完成试验后，收起来还得一个小时；还要在测试中满足测试车辆和目标物之间合理的速度、距离和光线、天气的要求。

如果在测试AEB时，撞到了假人，还得重新安置假人，如果不幸撞坏了，那么全部人都得在现场等，直到新的假人送到，这无疑是效率的“黑洞”。

并且，这种封闭测试场的场地，尤其是高速工况的测试，由于要考虑到“加速-测试-减速”，所以租用的场地也必要足够大才行，场地的租用费用不菲（每小时几千块），所以效率低下就会伴随着高昂的成本。

此外，考虑到目标物的布置和协同成本，封闭道路测试一般只适用于简单场景，如果目标物数量增加，布置、协同成本将大幅上升，测试效率直线下降。

如果很不幸，测试不能通过，需要现场调试软件，那更是需要从头再来一遍。

而如果运气不好，遇到了雨雪等坏天气，那还得等，等到天气合适为止，这对测试人员来说无疑是一种的巨大煎熬。

于是，就会有人想，是否可以把封闭道路试验放在室内？这样，就可以一天24小时一周7天无间断地测试了。

最直接的想法，就是在室内修建长跑道，来替代室外跑道，实际上，位于瑞典的AstaZero就是这么干的，他们在室内构建了700米长，40-60米宽的测试跑道，可以一年365天、一天24小时不间断测试，不过能找到这么大的室内场地，也真的不容易。

而一家中国的测试公司，则既利用了有限的室内空间进行测试，同时又可以构建更丰富的环境和场景。

VTEHIL的优势

这家中国公司叫做测迅，他们的方案叫做VTEHIL（Vehicle Traffic Environment Hardware in Loop，实车交通环境在环测试平台），就是通过在室内场地构建模拟的周边环境变化以及目标物移动，来进行智能驾驶车的测试。

VTEHIL主要由6部分组成，如下图所示：

测迅VTEHIL方案介绍

其中，1处为11自由度的测试车辆道路负载模拟平台，其主体为一个可以实现水平旋转和横向移动的转鼓平台，可实现车辆（Vehicle）在环；2处为模拟交通参与目标物，如行人、自行车和车辆等，可以模拟相对复杂的交通流（多个目标物），可实现交通流（Traffic）在环；3处为灯光雨雾环境模拟系统，可以模拟极端天气（如不同的光线亮度和雨雾天气），可实现环境（Environment）在环；4处为C-V2X信号模拟系统；5处为交通信号标识；6处为被测车辆。

那么VTEHIL有哪些优势呢？

首先，测试效率大大提升，VTEHIL由于位于室内，环境完全受控，可以24小时连续测试，也省掉了测试前后的道具布置和道具恢复的时间，而且，由于目标物都通过程序精确控制，车辆也一直在转鼓上匀速行驶，也能够大大减少测试中反复调整车辆和目标物的速度、距离的时间。

据测迅的工作人员介绍，“一款车型在VTEHIL 上完成C-NCAP中AEB相关测试，只要一天左右，而实际道路测试中，在天气良好、一切顺利的前提下，至少也要两三天，相比之下，VTEHIL的测试效率提升了数倍”。

其次，VTEHIL可以模拟极端天气（如不同的光线亮度和雨雾天气）和相对复杂的交通流（多个目标物），实现环境和交通流的在环，从而可以实现相对复杂的基于场景的测试。

再次，VTEHIL也解决了一般ADAS台架测试的几个问题，如通过负责模拟的旋转和横向移动，可以实现被测车辆的横向角度偏转和位移，从而解决车辆横向控制的问题；再比如，其交通参与目标物都是真实的假人假车，也避免了传统台架中传感器通过信号虚拟注入的不足。

不过，由于被测车辆在转鼓上，和车辆在真实道路上行驶仍存在车辆动力学的差异，对此，测迅CTO吕济明博士介绍道：“测迅通过和业内好的车辆动力学仿真系统合作，可以很好地仿真被测车辆的车辆动力学，此外，也可以通过实车道路测试数据来校正测试平台的控制参数（如制动距离等），来进一步缩小车辆在VTEHIL上的表现和在真实道路上的差距。”

VTEHIL和其他测试方法的对比

可见，在真实性上，VTEHIL和封闭道路测试相比，只在道路环境上略有差异，其他要素完全相同，并且相比之下，VTEHIL的测试效率和场景可扩展性上（极端天气和复杂交通流）的优势更加明显。

因此，VTEHIL有望在高等级自动驾驶系统的开发测试过程中发挥重要作用，而且后续如果被国家机构接受后，还可以作为认证试验的重要手段。

在被问及VTEHIL是否能够代替封闭道路测试时，吕博士给了否定的答案，并补充道：“其实VTEHIL和封闭道路测试是相互补充的。VTEHIL更适合直路场景，尤其是速度高的场景。因为高速场景对场地要求更高，且有一定的危险性，所以直路场景下VTEHIL是很好的测试手段。现实当中，车辆大多数时间也是行驶在直路上。

至于路口场景，由于道路结构和交通参与者的相对运动关系复杂，直接在封闭测试场内测试效果更好，而其他坡道、隧道、弯道等场景，由于和道路特征密切相关，更是只能在测试场内进行测试。”

VTEHIL的Cut-in测试

VTEHIL的避让场景测试

测迅是一家什么样的公司

测迅是谁？

这是一家成立于2017年的创业公司，目前主要提供智能驾驶整车级测试解决方案。其管理团队具有多年的测试行业的从业经验。CEO李晓英曾在外资测试公司工作十多年，CTO吕济明博士学术背景浓厚，师从郭孔辉院士；还吸引了德国资深专家Rainer Hoffmann加入并担任CSO（首席战略官），负责公司战略及国外市场的开拓。

测迅作为一家成立5年多的测试行业的初创公司，能做出VTEHIL，这让九章智驾产生了浓厚的兴趣。

带着好奇，九章智驾和测迅团队进行了深入的沟通，为方便阅读，下文将采用问答的形式。

定位和愿景

九章智驾：测迅的定位和愿景是什么？

测迅CTO吕济明博士：测迅的定位是做一家提供智能驾驶整车级测试完整解决方案的服务商，愿景是做智能驾驶安全测试技术的引领者。

关于整车级测试，测迅的业务范围主要包括两部分：一部分是封闭试验场的道路测试服务，这部分由于工具链比较成熟，测迅主要以代理国外的测试工具（如4active和GeneSys）和封闭试验场的运营为主；另一部分是试验室内的整车测试，测迅独创了VTEHIL测试方法。

测迅整车级测试方案演示

九章智驾：怎么会想到要做VTEHIL呢？

吕济明博士：一方面，因为我们自己也做封闭道路测试服务，在实际业务中遇到了很多痛点，在思考如何解决这些痛点；另一方面，也是因为一些车企客户和认证检测机构客户对主动安全测试的需求。

我们调研了现有的技术方案，发现国内外在该领域都没有特别好的解决方案，于是我们花了数年时间，开发出了VTEHIL，将试验室和封闭道路道路测试结合起来，能有效解决高等级自动驾驶测试验证认证中的痛点。

业务协同和进展

九章智驾：测迅目前在开展多项业务，这些业务之间有协同性吗？

吕济明博士：这些业务都围绕着整车级测试来进行的。一部分是试验场内的服务，一部分是试验室内，主要是VTEHIL。

九章智驾：能否介绍一下，测迅近期中标的几个测试场项目？

测迅CEO李晓英：在过去的一年里，我们成功拿下了两个非常重要的项目。

其一，我们在2022年3月拿下了一汽的国际招投标项目——智能驾驶环境模拟测试系统项目，该项目建设了一个300米长的实验室，可实现各种复杂的测试场景，比如各种路面光线变化、V2X全环境模拟等；

其二，在9月，我们中标了武汉智能网联汽车测试场运营服务项目，该项目占地1300多亩，是T5级测试场与F2赛道相结合的封闭测试场，并拥有10个测试区。

注：包括办公运维区、高速及极限性能测试区、极端环境测试区、城市交通场景测试区、乡村交通场景测试区、自动泊车测试区、山区交通场景测试区、多功能测试区、城市高架匝道交通场景测试区、极限竞速测试区（F2赛道）

武汉智能网联汽车测试场航拍图

企业文化

九章智驾：您在创立测迅之前，曾在外企工作多年，这份工作经验对您创办测迅有什么帮助？

李晓英：我是学经管专业的，又在外企工作多年，所以很清楚管理体系和企文化的重要性。

我们从公司成立伊始，就特别注意建立管理制度，也形成了严谨规范、国际视野、有温度的企业文化。

九章智驾：测迅作为一家测试公司，很容易成为传统工程师向自动驾驶转型的一个跳板，工作几年后就跳到其他公司去，在招聘的时候会不会有一些顾虑？

李晓英：没有啊，当跳板也很正常，而且我们还会很欢迎。因为一般来说，员工跳槽后会去车企，去了车企就成了我们客户了，还是合作伙伴。但是希望一开始能够说坦诚说清楚，这样的话，我们对你的培养计划会有调整，因为不同的岗位会有不同的“技能点”，如果要去车企的话，需要有全局的把握，这样就可以安排你去当项目经理，甚至你想去哪家车企，跟这个客户相关的业务，我可以交给你负责，这样就会“双赢”；如果不说的话，我把你作为基础员工来培养，可能工作了两年，还只接触过一小部分业务，技能还没学全就走了，那就是“双输”了。

九章智驾：通过之前的接触，我对测迅超强的执行力印象很深刻，能分享下为什么测迅执行力这么强么？

李晓英：测迅的名字，其实就是“测试迅速”的意思。“迅速”从哪里来，就是从执行力上来。

我们最大的价值就是帮客户省时间，所以对客户和市场的反应要“迅”；别的工具使用繁复耗时，我们的工具简单高效，这也是“迅”；一项任务，其他友商解决要三天，我们如果只要一天，这更是“迅”；决策扁平，充分授权同事可以自己做主，这也是“迅”。

人生苦短，我们不浪费自己和他人的时间在无谓的地方，这些都是“迅”的体现，也是公司执行力的体现。

参考文章：

1.论文：Test Method for Measuring the Simulation-to-Reality Gap of

Camera-based Object Detection Algorithms for Autonomous Driving

2.https://www.zhihu.com/question/291745181/answer/1187253184

3.https://www.astazero.com/astazero-dry-zone/

4.https://new.qq.com/omn/20211213/20211213A0DDUQ00.html

5.https://mp.weixin.qq.com/s/uxvsZ5jGbYW9Pa7L9WgPSQ