自动驾驶中常提的ODD是个啥？

[首发于智驾最前沿微信公众号]在自动驾驶中，经常会听到一个概念，那就是ODD。所谓ODD，全称为Operational Design Domain，中文常译为“运行设计域”或者“作业域”。直观一点理解，ODD就像自动驾驶系统的“活动许可书”，它明确告诉车辆在哪些环境、什么路况、什么速度范围、哪类交通参与者出现时，系统被允许接管驾驶任务。简单理解下，把自动驾驶想象成一个选手参赛的场地，ODD就是比赛的赛场范围，把赛道、天气、时间、交通规则和可接受风险都写清楚，超出赛场范围就不能比赛，必须交还方向盘或进入安全停车程序。

ODD在自动驾驶中有多重要？

ODD并不是一个学术上的概念，而是对自动驾驶来说非常重要的技术基础。自动驾驶汽车并不是万能的，任何感知、预测与决策系统都有能力边界。ODD明确了这些边界，做到两个核心目的，一是为系统设计、测试和验证提供清晰的规范，二是为运营和监管提供可量化的安全管理口径。没有清晰ODD，就无法回答“系统到底能在哪儿安全运行？”、“什么时候需要人工接管？”以及“出了事故是谁负责？”这些关键问题。

对于自动驾驶来说，ODD的存在指导了传感器选型和算法设计。如果目标ODD包含复杂的城市断续流和夜间雨雪，感知系统需要更强的低能见度性能和冗余传感器。测试团队也要据此有针对性地生成测试场景和仿真用例，避免在不适合的场景下盲目跑量产测试，降低风险与成本。从监管与产品角度来看，ODD让监管机构、车企和用户之间达成共识，如果产品说明书上说明某系统在高速公路白天、限速120km/h、晴朗或轻云情况下可用，那么在隧道或暴雨里使用该功能就属于违规或被警告的行为，这也为自动驾驶事故问责提供了清晰的限制条件。

如何设计自动驾驶ODD？

想要做好自动驾驶ODD，并不是简单地罗列规则，而是要把“可测量、可验证、可执行”的条件写出来。首先空间维度要明确，要包含地理与道路特征，例如是否限定为高速公路、城市主干道、住宅区或停车场；道路类型要写清楚是否允许未划分车道、单行道或交叉复杂路口。对于时间维度也需要说明时段限制，是仅限白天，还是黄昏或全天候都可以使用？环境维度更是考虑的关键，应该把天气（晴、雨、雪、雾、风）、光照（白天、夜间、隧道）、路面状态（干燥、湿滑、结冰）等用可以量化的指标表达，例如在能见度大于多少米、路面摩擦系数在多少范围内、降水强度阈值在多少内等条件下，才可以使用自动驾驶。交通流与参与者等因素也要作为ODD设计的考虑因素，要说明是否支持行人密集区、非机动车混行、公共交通车辆或施工路段。车辆自身能力也要写清楚，其中就要包含最高许可速度、加速/制动极限、车道保持精度、传感器盲区、定位精度甚至地图依赖性。对于基础设施与服务的依赖关系更需要列明，例如是否要求高精地图，是否需要车路协同单元（RSU）或持续的网络连接等。

对于ODD的描述应该有明确的数值或规则，不应该模糊化使用场景。写“适用城市道路”不如写“在道路宽度≥6米、车道线清晰可见、车辆定位精度小于±0.5米的城市主干道上运行”。这样的表达既便于场景化落地，也便于测试与监管量化验证。对于一些难以人工精确定义的条件，可以引入“可测条件替代项”，例如把“能见度良好”替换为“前向摄像头在10米处可识别行人轮廓的概率≥95%”，把模糊感性的要求变成可测指标。

对于ODD的设计并不是一成不变的，随着传感器升级、算法优化和运营积累，自动驾驶汽车会出现“扩域”的需求。这种扩域必须经过严谨的工程验证流程，并在文档中给出清晰的版本控制和生效时间，避免“功能自治”导致的合规与安全问题。

把ODD落地的实践要点

想把设计好的ODD落地，需要与自动驾驶生产的各阶段紧密对接。设计阶段的工作是把ODD转化为系统需求与测试需求。系统架构师会根据ODD决定冗余策略，如哪类感知需要冗余传感器、如何在传感器失效时做能力退化。感知算法团队要根据ODD设定的最大允许速度、车道宽度与行人密度设计检测与跟踪策略。决策规划则要考虑最坏情况边界并定义“最小风险条件”，也就是当系统判断已超出ODD时要立刻采取如将车缓慢并线到紧急车道、减速至停车并发出警示，或者要求人工接管等动作。

在验证阶段要使用仿真及实地测试来验证ODD的准确性。仿真用于覆盖罕见边界场景、极端天气与复杂交叉口组合，这能在安全成本可控的条件下暴露系统薄弱点。实地测试需要在明确的ODD范围内执行并且记录大量运行数据，用这些数据评估系统在真实流量与噪声环境下的稳定性与误判率。需要注意的是，针对ODD的验证不能只关注平均性能指标，还必须审视边缘情况下的行为，评估系统在低概率但高后果的场景下的处置方案。在安全工程上通常会引进场景覆盖矩阵和场景优先级策略，把重点放在高风险高暴露的场景上反复验证。

为了能让自动驾驶真实落地，对于ODD的部署与运营同样关键。运营团队要把ODD规则嵌入到产品说明、用户界面与远程监控系统中。用户在启用自动驾驶功能前应该明确看到当前环境是否满足ODD。车端应具备连续的ODD状态监测能力，能够在边缘接近时提前告警，留下“平滑交接”时间窗，而不是在危险时刻突然放手，出现0.1 S退出智驾的极端情况。对于车队运营方，还需要建立ODD版本管理、运行日志及事故追溯链路，确保在事故调查时能还原功能是否按ODD运行，以及是否因为扩域而带来不可接受的风险。

对于软件频繁OTA的现在，ODD管理其实会更复杂。任何扩域或能力修正通过OTA下发前，都应有专门的合格评定流程，其中要包含仿真回归、闭环实车验证与分批灰度发布。产品在说明中也应标注软件版本对应的ODD版本，用户与监管机构才能明确知道某次功能启用时车辆的真实运行边界。

ODD的常见误区、挑战与未来趋势

对于很多厂家来说，会把ODD简单理解为“市场宣传的使用场景”，于是只把语义宽泛、模糊的文字写到用户手册里，导致自动驾驶系统使用的边界不清、责任模糊。还有一些厂家会把ODD视为“上线前的合格项”，而忽视了持续运营中的监控与更新。其实ODD的真实作用在于两个方向，一是把人类的模糊描述转化为可测指标，二是在边界附近做出既安全又可接受的用户体验。

其实从技术上说，感知与定位误差、不确定性度量与决策的鲁棒性都是ODD设计时需要考虑的因素。即便在同一条道路上，不同天气或不同施工状态也会导致系统表现大相径庭。如何把这些动态变化纳入ODD描述，并在运行时自动评估环境是否满足ODD，需要更加成熟的不确定性估计方法、在线健康检测和多模态冗余设计。

随着自动驾驶技术的越来越成熟，更细粒度的“动态ODD”与“按场景授权”的能力或将得到应用。动态ODD指的是系统能够在运行中基于实时观测对某些ODD条件做出短期允许或拒绝决策，如在能见度略差但前方交通稀疏的高速路段允许短期降低速度后继续运行。这要求系统在保证安全冗余的前提下拥有更精细的风险估计能力。如果未来车路云协同得到落地，当路侧单位提供施工信息、可变限速或高精度定位服务时，车辆可以获得额外的ODD许可，反之则收紧运行权限。

审核编辑 黄宇