OpenODC: Public Evidence Platform for Automated-Driving Boundaries

OPENODC: A PUBLIC EVIDENCE PLATFORM FOR AUTOMATED DRIVING ODC

Yuxin Zhang

Automated Driving Safety Joint Lab

State Key Laboratory of Automotive Chassis Integration and Bionics, Jilin University

May 2026

Open with the central issue: operating boundaries must be specific, evidenced, and comparable.

Agenda

01What ODC Is
02GB/T 45312-2025 Standard Context
03The Missing Public ODC Data Layer
04OpenODC Methodology and Platform Framework
05Summary and Contribution

Use a formal agenda for a conference setting.

Agenda

01What ODC Is
02GB/T 45312-2025 Standard Context
03The Missing Public ODC Data Layer
04OpenODC Methodology and Platform Framework
05Summary and Contribution

Enter the first section by grounding ODC in engineering boundary questions.

01 · What ODC Is

ODC as an Engineering Boundary

Operational design conditions cannot be reduced to “highway supported” or “city supported”. They require road, traffic, weather, object, digital-information, human, and vehicle states to be specified.

Where can the feature be activated?
What happens in work zones, flooding, weak lane markings, or poor visibility?
Does the boundary come from a manual, an official page, an operating rule, or inference?

ObjectADS feature, operating service, or market version UnitODC element, parameter range, and combination EvidenceSource type, version, and verification date

Define ODC as an engineering boundary object, not as a marketing claim.

Concept Separation

ODC vs. Automation Level

Object	Main question	Relation to ODC
L2 assistance	The driver remains responsible for supervision and takeover.	ODC describes use conditions, not permission to stop supervising.
L3 automation	The system performs the DDT within limited conditions.	ODC must be tied to exit, takeover, and fallback behavior.
L4 driverless operation	The system operates within a domain or operating rule set.	Geofence, weather, road, and permits become core boundaries.

OpenODC does not rank capability. It asks how clearly public sources describe the boundary.

Prevent the AD leaderboard misunderstanding.

Agenda

01What ODC Is
02GB/T 45312-2025 Standard Context
03The Missing Public ODC Data Layer
04OpenODC Methodology and Platform Framework
05Summary and Contribution

Enter the second section by explaining how the standard aligns ODC elements.

02 · National-Standard Context

GB/T 45312-2025: ODC Expression Framework

The standard decomposes automated-driving operational design conditions into structured elements and asks for permitted / not-permitted states, element associations, and exit behavior.

§5.4.aODC elements

§5.4.bPermitted / not permitted

§5.4.cElement associations

§5.5Exit behavior outside allowed conditions

InputGB/T 45312 element list and clause requirements TransformAllowed states, associations, and exit behavior OutputReviewable, comparable, exportable ODCDocument

7ODC categories

144standard elements

2025publication year

The standard gives OEMs, researchers, test bodies, and regulators a common object of discussion.

Standard Taxonomy

ODC Taxonomy: 7 Categories, 144 Elements

Road Infrastructure Objects Weather Digital information Personnel state Vehicle state

Structured

Turns “highway”, “city”, “parking”, and “robotaxi” into authorable fields.

Traceable

Each item should point back to a source, version, and evidence date.

Comparable

Different systems can be aligned on the same element coordinates.

Make the standard visible as an actual taxonomy, not only a citation.

From Standard to Data

ODCDocument as Structured Standard Data

Standard requirement	OpenODC field
ODC elements	`elements[]`
Permitted / not permitted	`requirement`, `parameters`
Element associations	`associations[]`
Exit behavior	`exit_behavior`
Public-source evidence	`source`, `evidence_refs[]`
Boundary combinations	`boundary_combinations[]`

ODCDocument identity elements[] associations[] boundary_combinations[] review_status evidence_as_of metadata

The reusable asset is the data contract; the pages are views over it.

Agenda

01What ODC Is
02GB/T 45312-2025 Standard Context
03The Missing Public ODC Data Layer
04OpenODC Methodology and Platform Framework
05Summary and Contribution

Enter the third section by moving from standard syntax to public-data gaps.

03 · Industry Gap

The Missing Public ODC Data Layer

Owner manualsBoundaries appear across warnings, limits, and notices.

Official pagesFeature claims are visible, but parameters and version boundaries are often incomplete.

Operating rulesL4 robotaxi domains depend on permits, areas, time windows, and policies.

Third-party testsUseful observations, but must remain separate from official evidence.

What the missing public layer causes

Consumers cannot understand real system boundaries.
Researchers cannot build comparable samples easily.
Test bodies cannot reuse evidence and version records.
Standard language does not flow into tooling.

Shared schemaSamples, matrices, and exports use the same field semantics. Evidence versioningSource, evidence date, market region, and software version remain explicit. Review workflowSeparate community_reviewed, vendor_confirmed, and public-source gaps.

The standard gives syntax. Public evidence still needs curation, verification, and maintenance.

OpenODC Positioning

Evidence-Oriented Positioning of OpenODC

OpenODC is an open ODC data platform. Unless a record is marked vendor_confirmed, it is a community extraction from public sources.

Current default status community_reviewed

Reviewed against public sources, but not equivalent to OEM confirmation.

No capability ranking

No replacement for OEM ODC systems

No replacement for ISO 21448 / ISO 26262 safety cases

No packaging inference as official disclosure

This slide states the project’s credibility boundary.

Agenda

01What ODC Is
02GB/T 45312-2025 Standard Context
03The Missing Public ODC Data Layer
04OpenODC Methodology and Platform Framework
05Summary and Contribution

Enter the fourth section by introducing OpenODC assets, methodology, and combination boundaries.

Current State

Current Data Assets and Site Views

6high-confidence public samples

144GB/T ODC elements

346element-level references

97official / manual / government-backed items

60granular boundary combinations

5core user views

Move from concept to concrete project assets.

Sample Library

Unified Modeling Across Automation Levels

L2Tesla FSD (Supervised), US

L2Tesla assisted driving, China

L2AITO M9 · Huawei ADS 4

L2XPENG XNGP · P7+ 2026

L4Baidu Apollo Go Wuhan robotaxi

L4Pony.ai Gen-7 robotaxi

Show that the platform already carries concrete samples across ADAS and robotaxi domains.

How to Read a Sample

Evidence, Confidence, and Public Gaps

Manual-backed Official statement Community curated Inferred Public-source gap Structural category

Field	Purpose
`requirement`	Permitted, not permitted, structural, or unknown.
`source.type`	Separates official, manual, test, curation, and inference.
`confidence`	Marks high, medium, or low confidence.
`evidence_refs[]`	Stores URL, page, section, or excerpt references.
`boundary_combinations[]`	Captures typical boundaries where multiple elements co-occur.

Coverage is not vendor disclosure rate. Public gaps remain visible.

Comparison

144-Element Cross-System Matrix

ODC element	Tesla FSD US	Huawei ADS 4	XPENG XNGP	Baidu Apollo	Pony.ai robotaxi
Road type	Public coverage	Public coverage	Public coverage	Operational domain	Operational domain
Weather	Manual limits	Partial official evidence	Partial public evidence	Operating-rule linked	Operating-rule linked
Weak lane markings	Manual limit	Limited public evidence	Limited public evidence	Public gap	Public gap
Exit / takeover	Driver supervision	Driver supervision	Driver supervision	Safety operator / remote support	Safety operator / remote support

The comparison is about public boundary clarity, not which system is more capable.

The matrix value is visible even without opening the website.

Vendor Intake Workbench

From Public Sources to Review Packages

1Paste public or sanitized source text

2Map it into a 144-element ODC draft

3Mark provenance, gaps, and confidence

4Export CSV / Markdown review packages

The site is not only for display; it also models the contribution workflow.

04 · Method

Data Governance Principles of OpenODC

01

Standard-first

JSON Schema is the contract; web pages, matrices, and exports are derived views.

02

Provenance-first

30 sourced entries are better than 80 unsourced entries.

03

Semantics-first

L2, L3, and L4 can share elements, but their meanings differ.

04

Version-first

Software version, market region, and evidence date must be preserved.

Schema validationFields, enum values, evidence links, and combinations must be machine-checkable. Evidence auditOfficial, manual, government, test, and inferred sources must not be mixed. Version trackingThe same model or service can have separate records by market and version.

These principles are the reusable part of the project.

Boundary Combinations

Boundary Combinations and Coupled Scenarios

ODC tables decompose real roads into individual elements, but risk often appears when multiple boundary conditions stack together.

Rain / fog / glare

Worn lane markings

Work-zone rerouting

Driver distraction

This is not four independent cells. It is one combined-boundary problem.

Why add a second layer

Users experience combined conditions, not single table cells.
Engineering review needs activation, exit, and takeover boundaries.
SOTIF analysis needs trigger-condition candidates.

This is where OpenODC goes beyond a plain ODC table.

boundary_combinations[]

Field Semantics of boundary_combinations[]

01related_element_ids

Which ODC elements appear together.

02relation_to_odc

inside / outside / boundary / unknown.

03expected_response

Suppress activation, trigger exit, takeover, or not disclosed.

04evidence_level

Official, manual, operating rule, or public gap.

Important boundary

OpenODC records only public-source-supported typical combinations. It supports user explanation, engineering review, and research modeling, but does not replace OEM SOTIF analysis.

Keep the scope precise: structured public evidence, not certification.

From ODC to Trigger Candidates

OpenODC for SOTIF and Road Data

OpenODC Declared boundary

Turns public ODC statements, provenance, and boundary combinations into auditable structured data.

DRIVEResearch Real-road exposure

Uses aerial naturalistic-driving data to estimate how often boundary conditions appear and how their parameters distribute.

ROAM Outcome evidence

Records L4 robotaxi anomalies, boundary exceedance, remote interventions, and operational outcomes.

Together they connect declared boundary, real exposure, and operational outcome: OpenODC explains how a system boundary is stated, DRIVEResearch estimates how often those conditions occur in real traffic, and ROAM shows what happens near or beyond the boundary.

OpenODC DRIVEResearch ROAM

Place OpenODC inside the wider AD safety tooling stack.

Agenda

01What ODC Is
02GB/T 45312-2025 Standard Context
03The Missing Public ODC Data Layer
04OpenODC Methodology and Platform Framework
05Summary and Contribution

Enter the final section by closing with the contribution path.

05 · Summary and Contribution

Toward Public ODC Infrastructure

ODC names the boundary. The standard aligns the boundary. OpenODC makes the boundary publicly verifiable.

Join → GitHub →

Submit samplesAdd a public-source-verifiable ODC sample.

Add combinationsTurn typical boundary conditions into trigger candidates.

Review with institutionsImprove standards mapping, data quality, and terminology.

Confirm as vendorsMove community_reviewed records toward vendor_confirmed.

OpenODC
turns automated-driving boundaries from scattered prose into public evidence.

Keep the contribution path as a single slide.

Automated-driving perception and scenario data

Thank You for Your Attention

Yuxin Zhang

Automated Driving Safety Joint Lab

State Key Laboratory of Automotive Chassis Integration and Bionics, Jilin University

Homepage Lab OpenODC WeChat: 张玉新-AutoZYX

Close with contact points only.