Abstract: OpenODC is an open-source project that turns the Chinese national standard GB/T 45312-2025 (Intelligent Connected Vehicles — Operational Design Conditions for Automated Driving Systems) into a machine-readable public dataset. It currently includes a 144-element ODC schema, six public sample profiles (Tesla FSD Supervised, Tesla China ADAS, Huawei Qiankun ADS 4, Apollo Go Wuhan operations, XPeng XNGP, Pony.ai Gen-7 Robotaxi), a coverage matrix, dual developer-/consumer-views, and a planned OEM-evidence workbench. This post is both the project’s origin note and a public invitation — including the explicit option to hand the project off to a more suitable steward, free of charge.
When an OEM tells me their intelligent-driving system “works everywhere in the country,” the first thing I want to ask is not where it can drive.
I want to ask:
- Where can it not drive?
- Which weather forces a handover?
- What does the system actually do in construction zones, standing water, faded lane markings, sensor occlusion?
Those questions don’t sell as well as “drives anywhere on a road,” “parking-spot to parking-spot,” or “all-scenario.”
But safety usually lives precisely in those corners that don’t sell well as headlines — and certainly not in the small print at the bottom-right of a deck slide 😅.
1. What Even Is ODC?
Operational Design Conditions (ODC) include the Operational Design Domain (ODD), occupant state, and vehicle state.
The Chinese national standard GB/T 45312-2025 — Intelligent Connected Vehicles — Operational Design Conditions for Automated Driving Systems lays this out in detail (an official commentary is linked at the bottom).
Skip the standardese. In plain language, ODC is a boundary checklist:
- What roads, what speeds, what weather, what lighting, what traffic-participant conditions is this function designed to be used in?
- What conditions discourage use, what should trigger degradation, what should prompt a driver handover, and what has the manufacturer never made public?
What consumers really need is not just “this function is powerful.”
They need: “under what conditions should this function not be relied on?”
That’s the starting point for OpenODC.
2. What Is OpenODC?
OpenODC is currently a one-person weekend open-source project (link at the bottom).
What it tries to do is straightforward: take the operating boundaries scattered across all kinds of public materials and put them on one queryable, comparable, traceable open table.
It is not an intelligent-driving leaderboard. It is not an intelligent-driving leaderboard. It is not an intelligent-driving leaderboard.
Nor is it a safety certification.
It only answers a more basic question:
How clearly do public materials actually describe a function’s operating boundary?
For example: of Tesla FSD Supervised, what limitations can you find in the U.S. owner’s manual?
For example: for Tesla’s ADAS in the China market, what conditions are spelled out in the Chinese owner’s manual?
For example: for Apollo Go’s Robotaxi pilot in Wuhan, what ODD boundaries can be supported by the government’s pilot rules and other public materials?
This information used to live scattered across owner’s manuals, official sites, configuration tables, government notices, operations rules, and disclaimers. OpenODC’s contribution is putting them inside one frame.
3. What OpenODC Has Done So Far
3.1 A machine-readable schema for the standard
The 144 ODC elements from GB/T 45312-2025, made machine-readable. Meaning ODC stops being PDF prose and starts being something you can validate, compare, render, and export.
3.2 A public sample library
Six profiles so far:
- Tesla FSD Supervised (U.S.)
- Tesla China ADAS
- Huawei Qiankun ADS 4
- Apollo Go Wuhan pilot
- XPeng XNGP
- Pony.ai Gen-7 Robotaxi
These were AI-assisted picks, covering a few “intelligent-driving systems” with relatively complete public information.
To be clear: none of these are official manufacturer ODC declarations. They are high-confidence drafts reconstructed from public materials. Every key element traces back, where possible, to an owner’s manual, an official web page, a government operations rule, or an explicitly labelled inferred source.
3.3 A horizontal coverage matrix
The 144 standard elements crossed against the sample profiles, side-by-side — so you can see which elements are covered by public materials, which are gaps, and which are merely inferences.
3.4 A dual developer-/consumer-view
- Developer view: full hierarchy, JSON, and standard clauses preserved.
- Consumer view: plain-language — when to use, when not to use, what conditions might trigger an exit.
3.5 An OEM-evidence workbench (in design)
A more sensible long-term flow is not a vendor engineer hand-filling 100+ rows of a static template, but rather:
Import materials → automatically extract a draft ODC table → flag the supporting sentences, page numbers, thresholds, and unspecified items → let the OEM confirm which fields can be made public.
OpenODC does not want to be a safety certification. It does not want to be an intelligent-driving leaderboard. What it really wants to be is a public coordinate system:
- One standard.
- One evidence rule set.
- One machine-readable format.
- One continuous-update mechanism.
What deserves to be open-sourced is not the conclusion — it is the boundaries, the evidence, and the update mechanism.
4. This Idea Has Been Sitting On the Shelf Too Long
I contributed to several sections of GB/T 45312. Already during the drafting workshops I had a strong feeling: ODC, if it stays inside a standard PDF, has value — but it’s still one step short of being usable by the industry day-to-day. (Many other standards probably share this fate.)
Standards solve “how it should be defined.” What the industry wrestles with daily is a different question:
- For a particular vehicle’s highway NOA, can it be used in a construction zone or not?
- For a Robotaxi opening operations in a particular city, how clearly do public materials describe the geofence, the weather limits, and the remote-assistance boundary?
- The owner’s manual says “rain, snow, and fog may affect function” — when mapped to ODC elements, is that a quantified weather threshold, a speed cap, a lane-marking-occlusion criterion, or an exit behaviour?
Reading the standard alone won’t answer those.
I had wanted to build OpenODC even back then.
But honestly, I kept putting it off.
The reason was simple. I have no web-design background and no dedicated team. One person doing teaching and research, working on production-vehicle projects, juggling many exploratory interests — and also turning 144 ODC elements into a website with sample library, editor, and comparison matrix? That used to look unrealistic.
5. AI Killed the Starting-Cost. The Real Hurdle Is Still Ahead.
OpenODC actually got moving largely because AI tooling has matured.
Page layout, language toggle, JSON rendering, sample filtering, matrix construction, link checking, mobile responsiveness — all the stuff that used to eat enormous time can now be done by talking with Claude Code.
But once it was up, I saw something more clearly: the website was never the hard part.
The real hurdle is the underlying logic and long-term governance.
For L2 ADAS, “ODC” describes the function’s applicable conditions — the driver remains responsible for the dynamic driving task. For L3 / L4 AD, “ODC” describes the conditions under which the system takes over the dynamic driving task within a defined operational domain.
Get this wrong and a beautiful page is just well-designed misinformation.
A note on terminology: “intelligent driving” (智驾) is not a precise technical term. In this post it stands for “L2 ADAS plus L3/L4 AD” together. Traditional L2 ADAS has relatively simple operating conditions, usually defined by the OEM per function and not strictly required to follow GB/T 45312-2025 (which targets L3 and above). But today’s L2 combined-driving features are getting “increasingly capable” — personally I think it’s worth using the ODC standard to define their applicable conditions too.
The forthcoming mandatory national standard Intelligent Connected Vehicles — Safety Requirements for Combined Driving Assistance Systems explicitly states: vehicle manufacturers shall describe ODC elements of their systems and functions in accordance with GB/T 45312.
AI lowered the cost of building the website. It did not lower the cost of understanding the boundary.
6. We Have a Skeleton — and the Gap Is Visible
OpenODC currently has six public profiles, covering L2 ADAS and L4 Robotaxi.
It maps the GB/T 45312-2025 ODC framework onto 144 elements and tries to attach public evidence to each profile.
So far the site has 346 evidence citations in total, 97 of which are high-confidence items sourced from official documents, owner’s manuals, or government materials.
But the number I care about most is not 346 or 97.
It’s zero.
Zero manufacturer-confirmed profiles.
This isn’t a criticism of anyone. On the contrary, it shows OpenODC is still a public draft and a methodology validation. The community can reconstruct profiles from public materials, but a long-term-credible platform ultimately needs manufacturer confirmation, institutional review, and continuous updates.
And that is not something one person can carry.
7. Open to Co-Build — and to Hand Off
If there is a suitable individual, team, professional society, research institute, evaluation lab, open-source organization, or even a single company willing to maintain OpenODC long-term, I am happy to hand the project over completely, free of charge.
That includes the repository, the site structure, the sample library, the schema, the tooling, the methodology notes, and the maintenance roadmap — I’m fully ready to support a transition.
I don’t want this to rot on my shelf as a permanent half-finished project. If a more suitable organization can carry it forward, that would be the best outcome.
But there are a few non-negotiables:
- Stay open.
- Evidence first.
- No intelligent-driving capability leaderboards.
- No marketing vehicle for any single company.
- Don’t write L2 ADAS up as “autonomous driving.”
- Don’t repackage “public-material coverage” as “manufacturer disclosure rate.”
As long as these floors hold, OpenODC’s best home was never going to be “an AutoZYX personal project.”
8. Who I’m Looking For
If you’ve worked on standards and you know how much downstream pain a single mistranslated term can cause — I’d like you to come.
If you’ve worked on intelligent-driving development and you know that boundaries, handover conditions, and exit strategies aren’t a few sentences you toss off — I’d like you to come.
If you’ve worked on functional safety, SOTIF, test and evaluation, simulation, or data engineering and you know “evidence” and “inference” can’t be smushed together — I’d like you to come.
If you’re at a professional society, evaluation lab, research team, open-source community, or company and you think this project could live with you long-term — let’s talk directly.
You don’t need to commit a lot up front.
A single sample, one source citation, one term translation, one bug fix is a fine place to start.
Entry Points
OpenODC site: openodc.autozyx.com
OpenODC on GitHub: github.com/AutoZYX/OpenODC