扫码加入

  • 正文
  • 相关推荐
申请入驻 产业图谱

如何设计好自动驾驶ODD?

01/26 10:18
238
加入交流群
扫码加入
获取工程师必备礼包
参与热点资讯讨论

 

为确定自动驾驶的可使用范围,会给自动驾驶设置一个运行设计域(Operational Design Domain,ODD)。ODD的作用就是用来明确自动驾驶在什么情况下能工作,在什么情况下不能工作,给车设定“工作范围”。

这个范围可以包括天气、路型、时间、地理区域、交通状况、道路标线是否完好等明确的条件。明确这些条件可以让工程师知道系统的最大能力在哪里,便于测试和改进;还能让用户、监管方和应急人员知道车在什么情况下会要求人工接管或降级停车,可以在需要接管时有心理准备。

怎么确认一个自动驾驶系统的ODD

自动驾驶汽车的ODD并不是由工程师直接划定一个范围就可以确定,需要依托自动驾驶系统的能力来决定。自动驾驶系统的关键能力来自传感器、感知算法、定位/地图、决策与控制。

确认ODD的第一步是把这些能力用能量化的方式说清楚,传感器在雨天或夜晚的有效探测距离是多少,定位在路边没有高精地图时的精度是多少,急刹时车辆需要的最短制动距离是多少,决策模块在复杂路口需要多长时间作出安全判断,等等都是量化的指标。

这些技术参数一旦明确,就能将“在什么情况下能开”转换成具体的外部条件,从而可以明确能见度小于多少米就不能自动驾驶、路面积雪深度超过多少就必须降级等具体的要求。

ODD还要明确如是否必须在封闭细分的测试道路运行,是否需要随车安全员,是否只允许白天运营等具体的运营要求。更要把超出ODD时怎么办写清楚,是马上提示驾驶员接管、还是自动找安全地点停车、亦或是降速并等待远程辅助。只有把这些策略和边界条件一并定义,才能让ODD真正可以执行。

确认ODD要先做需求分析,接着要测量并记录各个模块的能力边界,然后把这些边界映射到环境条件,最后形成可检验的ODD文档。这个文档要既有定性的描述,也要有量化指标。举个例子,ODD不能只写“夜间可行”,而要写清在光照强度大于X、路面标线可见度大于Y的夜间环境下可以工作。有了这些具体的规定,测试和验证才有标准可依。

ODD的验证、测试与运行监控

把ODD规定好了只是第一步,接下来要做的是要证明在规定的ODD条件下自动驾驶是否真正安全,其可采用仿真、封闭场地实车测试和分阶段的上路试验这三种方式验证。

仿真可以快速覆盖大量场景,检验算法在理论上的表现,但仿真模型有局限性,需要用实车测试来补强。封闭场地可以精确控制变量,验证车辆在某些边界场景下的行为是否符合预期。为了更贴合实际的交通情况,必须在真实道路上分阶段、受控地验证,并逐步增加里程和场景复杂度。

验证过程中要用明确的度量指标来判断是否满足ODD。感知性能要看在不同天气和光照下的检测距离、漏检率和误检率;定位性能要看漂移、重定位时间;决策控制要看制动距离、跟车误差、转向响应时间等。将这些指标和ODD条件一一对应并测试后,才能决定ODD是否满足要求。

在评估ODD时,车端要有实时的ODD评估模块,持续判断当前环境是否仍在允许范围内,一旦发现有超出边界的征兆,应立即触发降级或提示接管。事后要有数据回传和边界事件回放分析,把上路数据作为修正仿真模型和改进算法的依据。

ODD应如何根据技术发展调整?

随着技术进步,ODD可根据实际慢慢放宽,但任何扩展都要有证据支撑。比较稳妥的做法就是分阶段推进,可先在仿真里验证新增场景,再在封闭场地做实车验证,然后在有限范围内小规模上线试运行,最后在收集到足够现场数据并通过安全评估后再全面放开。ODD的每一步的放宽都要有量化依据,比如在新增天气下的感知漏检率不超过某个阈值,控制系统的异常恢复时间符合要求等。只有满足这些量化门槛,才能把ODD的边界向外扩。

涉及ODD扩展的软件迭代需要非常慎重。每次升级都要做回归测试,确保旧的场景仍然安全。OTA不能成为风险放纵的理由,涉及ODD扩展的软件更新应先在少量车辆和受控区域内验证,确认没问题后再放大范围。同时要保证有快速回滚能力和明确的版本管理,出现问题时能立刻恢复到先前稳定版本。

在扩展ODD的过程中,还要考虑监管和用户告知等因素。很多地区对自动驾驶有具体监管要求,任何重要的ODD扩展都应该先报备。对用户则要做到透明,乘客要能清楚知道当前车辆处在什么ODD、什么时候可能要求人工接管、何时会降级停车。透明化不进是安全责任,也是赢得公众信任的必要步骤。

对于ODD的扩展应采取更加保守的态度。即使实验室和仿真已经表现得很好,也不要急于在运营中把ODD扩展到极端或边缘场景。应先扩展到那些能用数据支持且有成熟应对手段的场景。如已经有白天高速的大量里程和验证数据的前提下,在夜间感知和控制的关键指标满足要求时,可以考虑逐步加入低流量夜间高速场景,并且要有应急退路。

最后的话

对于ODD,应将其当成安全承诺,而不是束缚。ODD的价值不在于把自动驾驶系统的能力写得越宽就越好,而在于把能控制的部分说清楚、把不可控的风险管理好,然后在数据与验证的支撑下,有步骤、可回溯地慢慢扩展。这样既保护了用户安全,也为技术成熟和社会信任争取时间。

相关推荐