ROAM
Outcome side
L4 Robotaxi Operations Anomaly Management — incident database, scenario taxonomy, reference architecture. Answers "what went wrong".
Website →Aligned with GB/T 45312—2025
OpenODC
Open Platform for Automated Driving
Operational Design Conditions
An open registry that makes ADS operational design conditions transparent, comparable, and machine-readable.
What is OpenODC
OpenODC is an open-source platform for defining, comparing, and browsing ODC (Operational Design Condition) declarations for Automated Driving Systems. It is rigorously aligned with the Chinese national standard GB/T 45312—2025 Intelligent and connected vehicles — Operational design condition for automated driving system.
① ODC Gallery
Public sample library — filter by automation level, source, or keyword. Each record carries transparent provenance (vendor-confirmed / community-extracted / demo-only).
Browse Samples →
② ODC Editor
Hierarchical tree picker + parameter inputs + live JSON preview. Export to JSON / Markdown / clipboard / browser local storage. Browser-based, no login required.
Open Editor →
③ Multi-View Renderer
One ODC document, two lenses: developer (full hierarchy + JSON) and consumer (plain-language permission cards).
View Example →
④ ODC Compare
Side-by-side diff of 2–4 ODC declarations. Green = both permit; red = both deny; amber = disagreement. Spot capability boundary differences at a glance.
Start Comparing →
⑤ ODC Schema
The data foundation of the whole platform: the full GB/T 45312—2025 hierarchy as a machine-readable JSON Schema and TypeScript types — 144 atomic elements across 7 categories, plus every quantitative scale (12 wind levels, 4 rain levels, 4 visibility tiers, etc.).
View on GitHub →
⑥ Vendor Workbench
OEMs and Tier-1s manage ODCs across in-development, pre-release, and shipped functions in one workspace. When a function reaches SOP, its ODC can be published to the OpenODC public gallery with one click — supporting internal R&D collaboration while contributing to industry standardization.
Try the demo → Phase 4 · MVP
Why this exists
Three industry realities
- Each OEM declares ODCs in its own format — regulators and third-party labs cannot make like-for-like comparisons
- Consumers can't see the actual operating boundary — sales pitches stop at "L2" or "L3"; the limits surface only after an incident
- GB/T 45312—2025 defines the full hierarchy, but the standard itself ships no machine-readable counterpart
OpenODC's position
Not a replacement for an OEM's internal ODC tooling. In fact, OEMs already tell drivers "when the system can be used and when it can't" — in owner manuals and in-vehicle tutorials, sometimes in considerable detail.
The problem: every OEM uses its own format, its own categories, its own terminology. There is no shared convention — consumers switching brands must relearn the boundaries from scratch, and regulators or third-party labs have no common handle for side-by-side evaluation.
OpenODC provides a unified, machine-readable format and a public sample library, making ODCs queryable, comparable, and reusable. Open data first; expect OEMs to follow once the format becomes the industry default.
Current status (v0.2.0 · Phase 0–3 shipped)
- Phase 0: Full transcription of GB/T 45312—2025 (144 elements / 7 categories) + JSON Schema + TypeScript types
- Phase 0: Quantitative scales captured as reusable enums (wind, rain, snow, visibility tiers, lighting)
- Phase 0: Standard Appendix A L3 expressway example fully transcribed to JSON
- Phase 1: Public sample gallery with filtering by level / source / keyword
- Phase 1: Web editor — hierarchical tree, live JSON, multi-format export
- Phase 2: Dual-view renderer (developer / consumer)
- Phase 2: Multi-document Compare (diff view, 2–4 documents)
- Phase 3: GitHub PR template + CI auto-validation (ajv-cli + element_id reference check)
- Apache 2.0 (code) + CC BY 4.0 (data) licenses
- Phase 4: Vendor self-service authoring + Supabase backend (planned)
- Phase 4: ROAM linkage (link incidents to involved vehicle's declared ODC)
- Phase 4: ISO 34503 / BSI PAS 1883 international mapping
Mapping to the standard
| GB/T 45312—2025 clause | OpenODC counterpart |
|---|---|
| §5 General requirements | ODCElement definition in schema/odc.schema.json |
| §6.1 ODC base element hierarchy | Tree under schema/categories/*.json |
| §6.2 ODD (road / infra / targets / weather / digital) | Five odd_*.json category files |
| §6.3 Driver and passenger state | personnel_state.json |
| §6.4 Vehicle state | vehicle_state.json |
| §5.4.b Permitted / not permitted | requirement: 'permitted' | 'not_permitted' |
| §5.4.c Element associations | associations[] field |
| §5.5 Exit behavior for not-permitted elements | exit_behavior field |
| Appendix A example | data/examples/gb45312-appendix-a-l3-highway.json |
| Tables 5–14 quantitative scales | schema/enums/quantitative_scales.json |
How to participate
For OEMs and AD suppliers
Submit an officially-endorsed ODC declaration for one of your vehicles or functions. We mark it vendor_confirmed and rank it as the authoritative entry for that record.
For third parties, researchers, journalists
Extract ODCs from public materials (owner manuals, regulatory filings, third-party tests). Mark provenance honestly. Submit via PR to enter the community_reviewed tier.