ODC，“ADS湾”的带头大哥

发布时间：2022-09-13 11:46:07 【来源：十一号组织】

　　来源 | 十一号组织

　　知圈 | 进“底盘社群”请加微yanzhi-6,备注底盘

　　编者按：

　　在半年前的《 ODC，自动驾驶法力的边界》这篇文章中，笔者主要从构建框架、组成元素等理论层面对ODC展开了一番业余点评。但与不同等级自动驾驶的关系、如何应用于不同功能开发，笔者囿于当时浅薄的认知，未敢妄议。本篇对ODC的关注点从理论层面走向应用层面，并以行车和泊车场景两个典型功能为例，介绍一种可行的ODC的使用案例，为ODC从纸面走向地面做了一些有益的科普。

　　—11号线人

　　"ADS湾"的带头大哥

　　随着越来越多的玩家加入ADS（Automated Driving System，自动驾驶系统）这个赛道，各地政府也密集出台了一些政策法规，用于指导和规范ADS市场。2020年11月，北京市发布了《自动驾驶车辆道路测试管理实施细则（试行）》；2021年7月，工信部联合公安部和交通运输部，发布了《智能网联汽车道路测试与示范应用管理规范》；2022年6月，成都市发布了《成都市智能网联汽车道路测试与示范应用管理规范实施细则（试行）》。上海市、长沙市、重庆市……。

　　面对堆在电脑内这如山一般的各种细则，笔者“消化不良”了。这些文件中，尤其让我迷惑的是所谓的“ODC”，以及与ODC总是结伴出现的ODD、DDT、OEDR、MRM等一大串术语。他们就像“ADS湾”的古惑仔一样：在自动驾驶这块地盘上，他们不点头，大家就干不成事情。那作为ADS从业者，要吃这碗饭，必须要和这群“江湖大哥们”搞好关系。而第一步就是找ODC这位大哥拜码头。

　　“ADS湾”的古惑仔们

　　下面从名词解释的角度介绍一下ODC及其相关的术语。

　　ODC：Operational Design Condition，设计运行条件，设计自动驾驶系统时确定的适用于其功能运行的各类条件的总称，包括设计运行范围、车辆状态、驾乘人员状态、交通条件、营运条件以及其他必要条件。

　　ODD：Operational Design Domain，设计运行范围，是ODC的子集，为设计自动驾驶系统时确定的适用于其功能运行的外部环境条件。通俗的理解就是一组带有属性的元素，系统设计时定义好各功能适用的元素属性，系统道路运行时实时测定这些元素属性值（天气属性、道路属性、目标物属性等），从而判断系统是否处于可运行的安全范围之内。

　　DDT：Dynamic Driving Task，动态驾驶任务，指驾驶车辆所需的所有感知、决策和执行等行为（车辆横/纵向运动控制），不包括策略性功能（行程规划、目的地和路径选择等）。

　　DDT fallback：动态驾驶任务接管，设计自动驾驶系统时，当发生系统性的失效，发生导致系统不工作的故障或出现超过系统原有的运行设计范围之外的情况时，需给出最小化风险的解决路径。

　　DDT fallback-ready user：动态驾驶任务后援用户，指当自动驾驶系统工作时，可以识别自动驾驶系统发出的介入请求和明显的DDT相关的车辆故障，并执行接管的用户。

　　OEDR：Object and Event Detection and Response，感知与判断/周边监控，是DDT的子任务，对车辆纵向运动方向操作、通过对物体和事件检测、认知归类和后续响应，达到对车辆周围环境的监测和执行对应操作、车辆运动的计划还有对外信息的传递（即根据需要完成DDT和/或DDT接管）。

　　MRM：Minimum Risk Manoeuvre，最小化风险策略，是指自动驾驶系统在出现系统性的失效（导致系统不工作的故障）或者出现超过系统原有的运行设计域（ODD）的情况下，所采取的最小化风险的解决路径，以保障自动驾驶车辆在运行过程中安全。这套策略可在自动驾驶系统要求人工接管而未得到响应的情况下自动执行，也可在面临严重碰撞风险或车辆故障情况下自动执行。

　　ODC最忠诚的跟班--ODD

　　ODC是自动驾驶系统在满足ODD外部环境的基础上，系统安全启动和运行所需要的进一步满足的内部条件，比如车辆状态、驾乘人员状态以及其他必要条件。

　　（1） ODD：自动驾驶系统安全启动和运行的外部环境条件。不同自动驾驶系统启动、运行的外部适用范围不一样：如高速下的自动驾驶系统，A系统只能在白天启动和运行，B系统能够在白天和晴朗的夜晚启动和运行。自动驾驶系统在启动时需要判断当前所处的环境，如是否黑夜，从而判断能否启动该自动驾驶功能。在运行时需要识别是否超出该ODD，从而判断该自动驾驶系统能否安全运行。因此，在定义自动驾驶系统的设计运行条件时，需要明确自动驾驶系统能够安全启动和运行的外部环境条件。

　　（2） 驾乘人员状态：驾乘人员包括驾驶员/动态驾驶任务后援用户和乘客。为使自动驾驶系统及时被接管，需要对动态驾驶任务后援用户进行监测，要求动态驾驶任务后援用户的状态满足接管的条件，如不存在疲劳、酒驾等状态；为使驾乘人员满足基本的安全要求，需要对驾乘人员进行监测，如安全带监测；为使自动驾驶系统能够安全运行，需要对乘客抢夺自动驾驶设备的行为进行监测。

　　（3） 车辆状态：包括车辆速度和功能状态（包括软硬件状态）。车辆速度包括激活速度范围，通过激活速度范围判断此刻自动驾驶系统是否能够被激活。另一方面，自动驾驶系统启动、运行的前提条件之一是车辆状态能够达到自动驾驶系统的安全启动和运行的要求。如高速下的自动驾驶系统需要具备功能自检能力，并在启动前需要进行功能自检，要求感知功能状态、定位功能状态和计算功能状态等满足系统设计要求。

　　只有当上述ODD、驾乘人员状态、车辆状态等全部条件都满足的时候自动驾驶系统才能正常启动和安全运行。相反，欠缺任何一个前提条件，该自动驾驶系统都有可能无法启动或者无法安全运行（包括运行时功能降级），或者导致动态驾驶任务后援用户因接管不及时而造成危险。

　　ODC如何决定自动驾驶等级的划分？

　　自动驾驶等级和ODD设计域的关系如下表所示。

　　L0：应急辅助，不能持续执行DDT中的车辆横向/纵向运动控制。

　　L1：驾驶辅助，在限定的ODD内系统和驾驶员共同执行DDT中的车辆横向/纵向运动控制。

　　L2：部分自动驾驶，在限定的ODD内系统能持续地执行DDT中的车辆横向/纵向运动控制，但OEDR由驾驶员完成。

　　L3：有条件自动驾驶，要求在限定的 ODD 内能够完成所有的 DDT，但是要求驾驶人员时刻准备着应对，无人驾驶系统在系统失效或者超出 ODD 范围时发出的需求驾驶员介入的请求。但是标准中也要求系统能够在发出驾驶员介入请求后驾驶员介入前能够继续控制汽车几秒的时间。

　　L4：高度自动驾驶，要求系统在 ODD 内不止能完成 DDT 还要能够应对系统失效，无需驾驶员介入。

　　L5：完全自动驾驶，全工况无人驾驶，无需定义ODD，能够完成所有的 DDT 以及处理 DDT fallback。

自动驾驶等级和ODD设计域的关系

　　ODC在ADS系统设计中的大显身手

　　下文以行车和泊车场景的两个典型功能NOP和HPP，简单列出其ODD要求。

　　（1）NOP-高速导航自动驾驶ODC

　　（2）HPP-记忆泊车ODC

　　小结

　　将ODC称为“ADS湾”的带头大哥不过是戏称，其实ODC法规更像是一部穷尽所有元素的字典，各厂家在设计ADS功能时可以从字典中查找相应的元素并定义自己功能的设计运行条件。查字典不难，难的是设计的ADS系统在运行时如何准确识别出这个元素并量化这个元素，以便决策是继续激活系统还是执行最小风险策略，从而有效增强ADS功能的用户体验度，增加产品在中国这个日益内卷的汽车市场的竞争力。

上一篇：“擎朗智能”获中国机器人智能评价系统首张「综合智能cL3等级证书」
下一篇：最后一页