Structures Public Evidence
Maps owner manuals, official pages, app operating rules, government notices, and third-party tests to the 144 ODC elements in GB/T 45312—2025.
METHOD / STANDARD
Methodology
OpenODC measures how clearly public sources describe operational boundaries. It is not a safety certification and it does not rank automated-driving capability.
What OpenODC Does
Measures Gaps
Separates official evidence, owner-manual evidence, community extraction, inference, and elements that are not clearly stated in public sources.
Enables Comparison
Compares vehicles, functions, and automation levels through the same element vocabulary instead of comparing product names.
ODC and ODD
ODD usually describes the roads, environment, traffic, speed, geography, and other conditions in which an Automated Driving System is designed to operate. GB/T 45312—2025 provides an ODC element hierarchy that turns those boundaries into a checklist that can be authored, validated, and compared. OpenODC implements that checklist as JSON Schema and web tooling.
| System Type | Meaning in OpenODC | Main Risk |
|---|---|---|
| L2 driver assistance | Feature availability and exit / suppression conditions; the driver continuously supervises the dynamic driving task | Misreading “available” as “system responsible” |
| L3 conditional automation | The boundary under which the ADS performs the dynamic driving task, plus fallback-ready user responsibilities | Declaring road and weather while omitting fallback conditions |
| L4 robotaxi / ADS | Service operating boundary, usually including geofence, operating hours, weather, remote assistance, permit scope, and app rules | Misreading a pilot geofence as nationwide capability |
ODC and Road Rules
ODC describes the conditions in which a function is designed to operate, but it does not by itself answer how an actor should behave in a specific traffic situation. Road rules add behavioral obligations, prohibitions, legal subjects, and applicability boundaries. The scenario and evidence layer then turns that semantic relation into a reviewable engineering object. OpenODC provides traceability; it does not automatically determine vehicle compliance or accident responsibility.
Describe roads, facilities, environment, traffic actors, and system states: where and when the function operates.
Record required or prohibited behavior, the legal subject, and applicability from public sources.
Define triggers, expected responses, and candidate evidence so the engineering interpretation can be reviewed.
Limitations of the ODC Table
An ODC table is a necessary starting point for transparency, but it is not the full safety boundary of a driving system. Roads, weather, lane markings, objects, and speed are single-element projections of a high-dimensional real-world scene. Real-road risk often emerges when several elements appear together, so allowed single-element ranges must not be multiplied into an assumed safe combined boundary.
| Layer | How OpenODC Handles It | Boundary Reminder |
|---|---|---|
| Single ODC element | The main table remains element-based: permitted / not permitted, parameter range, and evidence | Shows whether public sources explain the element |
| Element association | Keeps explicit primary / dependent element constraints from the standard structure | Shows whether there is an explicit cross-element rule |
| Boundary combination | Adds a lightweight layer for a small number of public-source-supported combined boundaries | Shows why single-element coverage is not enough |
Boundary Combinations and Trigger Conditions
OpenODC does not try to become a full SOTIF analysis platform. It only marks typical combined boundaries that are already visible in public sources. For consumers, these are “boundary combinations.” For developers, they can be treated as trigger-condition candidates.
Not Exhaustive
Each sample lists only a few high-value combinations, such as bad weather + unclear markings, construction + temporary lanes, or geofence + app runtime rules.
Not a Vendor Safety Case
Boundary combinations are extracted from public sources or clearly marked community analysis. They indicate gaps and verification entry points, not SOTIF conclusions.
Connects Communication and Testing
Consumers see when extra caution is needed; developers see which combinations can become test scenarios or trigger-condition analyses.
Relationship with ROAM / DRIVEResearch
An element-by-element ODC table can only answer whether a single factor is publicly stated. Real trigger conditions are usually combined: rain carries a very different risk meaning when it appears together with darkness, glare, worn lane markings, construction detours, or driver distraction. OpenODC therefore keeps a lightweight combined-boundary layer and leaves heavier exposure assessment and anomaly-outcome analysis to complementary projects.
| Question Layer | Project | Role of Boundary Combinations |
|---|---|---|
| What boundary is declared or publicly evidenced? | OpenODC | Connects single ODC elements into traceable combination candidates with sources and public gaps |
| How often do these combinations occur in real traffic? | DRIVEResearch | Estimates occurrence frequency, parameter distributions, and human-driving baselines from naturalistic data |
| What happened near or beyond the boundary? | ROAM | Uses remote-operation anomalies, incidents, and interventions to identify combinations that deserve priority |
Evidence Levels
| Tag | Meaning | Counts Toward Coverage |
|---|---|---|
| Official statement | Vendor website, official press release, official configuration table, or official robotaxi operating rule | Yes, highest confidence |
| Owner manual | Owner manual or product manual explicitly states the condition, threshold, or warning | Yes, highest confidence |
| Community extraction | Public sources support a directional interpretation but not a complete quantitative threshold | Yes, but source traceability is required |
| Inferred | Derived from architecture, regulation, domain knowledge, or indirect public evidence | Yes, but it is never treated as vendor disclosure |
| Not clearly stated | No public source explicitly states the element | No; this is a gap |
| Structural | A parent node in the standard hierarchy; the actual judgment is made in child elements | No substantive coverage |
Coverage Metric
The Gallery coverage number is not a vendor disclosure rate. It is the number of GB/T elements for which OpenODC can build a public-source explanation: official statements + owner manuals + community extraction + inference. The UI also shows the number of elements not clearly stated in public sources so gaps are not mistaken for capability.
Reference Standards
- GB/T 45312—2025: National Public Service Platform for Standards Information
- GB/T 40429—2021: National Public Service Platform for Standards Information
- ISO 34503:2023 Road vehicles — Taxonomy for ODD: ISO
- ASAM OpenODD: ASAM
- NHTSA Levels of Automation: NHTSA