To define the operational scope of autonomous driving, an Operational Design Domain (ODD) is established. The ODD specifies the conditions under which autonomous driving functions effectively and those under which it does not, essentially setting the 'operational boundaries' for the vehicle.

These boundaries may encompass specific conditions such as weather patterns, road types, times of day, geographical locations, traffic scenarios, and the clarity of road markings. By delineating these conditions, engineers can grasp the system's utmost capabilities, thereby streamlining testing and refinement processes. It also equips users, regulators, and emergency responders with knowledge about scenarios necessitating manual intervention or degraded parking, ensuring preparedness for such eventualities.

How to Define the ODD of an Autonomous Driving System

The ODD for autonomous vehicles is not arbitrarily set by engineers; rather, it is determined based on the autonomous driving system's inherent capabilities. These capabilities are rooted in sensors, perception algorithms, localization/mapping, decision-making, and control mechanisms.

The initial step in defining the ODD is to quantify these capabilities, including the sensor's effective detection range in adverse weather or low-light conditions, localization accuracy sans high-precision maps, the minimum braking distance required during emergency stops, and the decision-making module's response time at complex intersections. These metrics are all quantifiable.

Once these technical parameters are clarified, the question of 'under what conditions can it operate?' can be translated into specific external conditions. This enables the formulation of clear requirements, such as the maximum visibility distance for autonomous driving or the maximum snow depth for degraded operation.

The ODD must also articulate operational prerequisites, including whether operation is confined to closed test roads, the necessity of a safety operator, and operational time constraints, such as daylight hours only. Furthermore, it must delineate procedures for scenarios where the ODD is exceeded, encompassing immediate driver takeover prompts, automatic parking in secure locations, or reduced speed with remote assistance. Only by defining these strategies and boundary conditions can the ODD be truly actionable.

Defining the ODD entails Requirements Analysis (needs assessment), measuring and documenting the capability thresholds of each module, mapping these thresholds to environmental conditions, and ultimately crafting a verifiable ODD document. This document should encompass both qualitative descriptions and quantitative metrics. For instance, the ODD should not merely state 'operable at night' but should specify operability under nighttime conditions with illumination intensity exceeding X and road marking visibility surpassing Y. These precise stipulations provide benchmarks for testing and verification.

ODD Verification, Testing, and Operational Oversight

Defining the ODD is merely the initial step. The subsequent step is to substantiate that autonomous driving is genuinely safe within the specified ODD conditions. This can be achieved through three primary methods: simulation, closed-course real-vehicle testing, and phased on-road trials.

Simulation enables the rapid exploration of a broad spectrum of scenarios to theoretically assess algorithmic performance. However, simulation models have inherent limitations and must be complemented by real-vehicle testing. Closed courses facilitate precise control over variables to validate vehicle behavior in boundary scenarios. To better mirror real-world traffic conditions, verification must be conducted in stages on actual roads, progressively increasing mileage and scenario complexity.

During verification, clear metrics must be employed to ascertain whether the ODD is fulfilled. Perception performance should be evaluated based on detection distance, miss rate, and false positive rate under varying weather and lighting conditions. Localization performance should consider drift and relocation time. Decision-making and control should be assessed based on braking distance, following error, and steering response time. Only after testing these metrics against ODD conditions can it be determined whether the ODD requirements are satisfied.

When evaluating the ODD, the vehicle must incorporate a real-time ODD assessment module to continuously ascertain whether the current environment remains within permissible limits. If signs of boundary transgression are detected, degraded operation or takeover prompts should be promptly triggered. Post-event data retrieval and boundary event replay analysis should be conducted, utilizing on-road data to refine simulation models and enhance algorithms.

How Should the ODD Be Adjusted in Line with Technological Progress?

As technology advances, the ODD can be incrementally expanded based on empirical evidence. However, any expansion must be substantiated by data. A prudent strategy is to proceed in stages, initially verifying new scenarios in simulations, followed by real-vehicle verification in closed courses, and then conducting small-scale trial operations within confined ranges. Ultimately, full-scale expansion can ensue after accumulating sufficient on-site data and passing safety assessments. Each step of ODD expansion must possess a quantitative foundation, such as ensuring that the perception miss rate under novel weather conditions does not surpass a predetermined threshold and that the abnormal recovery time of the control system adheres to requirements. Only by meeting these quantitative thresholds can the ODD boundaries be extended.

Software iterations involving ODD expansion necessitate meticulous caution. Each upgrade must undergo regression testing to guarantee that existing scenarios remain secure. Over-the-air (OTA) updates should not serve as a pretext for risk-taking. Software updates entailing ODD expansion should initially be validated in a limited number of vehicles and controlled areas before broader deployment. Additionally, a swift rollback capability and explicit version management must be ensured to facilitate immediate restoration to a previous stable version in the event of issues.

During ODD expansion, regulatory and user notification considerations must also be factored in. Numerous regions impose specific regulatory prerequisites for autonomous driving, and any substantial ODD expansion should be reported in advance. Users should be kept apprised transparently, enabling passengers to comprehend the current ODD, when manual takeover may be required, and when degraded parking may transpire. Transparency is not only a safety obligation but also a requisite step to foster public trust.

A more cautious approach should be adopted towards ODD expansion. Even if laboratory and simulation results are promising, ODD should not be hastily introduced into extreme or edge scenarios during operations. Expansion should initially occur in scenarios supported by data and mature response strategies. For instance, if substantial mileage and verification data for daytime highway driving are available, and key perception and control metrics meet requirements at night, low-traffic nighttime highway scenarios can be gradually incorporated, with contingency plans in place.

Final Thoughts

The ODD should be perceived as a safety pledge rather than a limitation. The value of the ODD lies not in describing the autonomous driving system's capabilities as expansively as possible but in clearly defining controllable aspects and managing uncontrollable risks. Subsequently, with the support of data and verification, it can be gradually expanded in a stepwise and traceable manner. This approach safeguards user safety while affording time for technological maturation and societal trust.

-- END --