[首發于智駕最前沿微信公眾號]在自動駕駛中，經常會聽到一個概念，那就是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許可，反之則收緊運行權限。