Open data models for ITS, decoupled from transport
A vendor-neutral, versioned data model for roadside infrastructure: signal controllers, message signs, sensors, and V2X. Carry it over REST, RESTCONF, gNMI, or an event stream. The model is the contract; the transport is your choice.
A shared data model for ITS, plus Vikasa, the open source implementation that proves it runs.
The models are the standard: a vendor-neutral description of what a signal controller, a message sign, or a weather station is and what it reports. How those models move on the wire is deliberately left open. Bring your own transport.
The open standard
Versioned YANG models, a notifications tree, an immutable content-addressed registry, governance and extension rules. All of it independent of any protocol.
Models repository →The Vikasa implementation
Vikasa is an open source implementation that runs the models end to end: its collector polls real devices and publishes typed events. Proof the models work, not a required stack.
Vikasa collector →ITS data is invisible across agency and vendor boundaries.
NTCIP carried the industry for more than thirty years: it got roadside devices talking and gave agencies a shared vocabulary. But it was built for per-device SNMP polling, and its data still lives in per-vendor MIBs and one-off per-agency integrations. That legacy has a cost. Agencies can't build cross-jurisdiction analytics, vendors rebuild the same integration fifteen times, and researchers can't generalize their findings.
Per-vendor data shapes
The same concept at different OIDs, with subtly different semantics. Code that reads one doesn't read the other.
Per-agency surface
A unified view is hand-rolled against one agency's vendor mix. Not portable, and the dashboards don't generalize.
Models tied to transport
Cross-agency standards bind data to one protocol, so the model can't outlive the pipe it shipped on.
Schema drift
A new field breaks consumers silently. No registry, no versioning discipline, no proof that anyone implements it the same way.
Three decisions that make it different.
The model outlives the pipe
Bind a data model to one transport and it can't outlive that transport, which is what happened when NTCIP built on SNMP. OpenITS picks YANG precisely because it has no transport opinion.
The standard is the schema
Not a PDF that implementations trail behind. The YANG modules and their immutable registry snapshots are the standard; a PDF, if any, is the derived artifact. CI refuses a content change without a revision bump.
Constraints live with the data
MUTCD timing rules (yellow ≥ 3s, red ≥ 3s, min-green ≥ 5s) are YANG must expressions, declared once and validated at every boundary, not re-implemented per consumer.
9 service domains modeled today.
Each domain is a YANG model plus a companion notifications module, and all 9 publish a typed event surface today. New domains land through the contributor process.
Common modules carry scalars and cross-cutting events every domain reuses: types, nema-common, and shared fault / mode / comm-health event families.
Signal-control alone models phase, detector, pedestrian, preemption, overlap, coordination, TSP and TSAM events. Across the catalog that is 70 typed event types, each its own schema-versioned message.
One model. Any binding.
The YANG models are the source of truth. Everything else (wire formats, APIs, documentation, validation) is derived. Pick the binding that fits your deployment; the contract stays the same.
+ vendor augments
Vendors ship fast. The core stays stable. Proven ideas graduate.
Four tiers, one graduation rule. Augments add nodes without touching core; deviations tighten constraints for a jurisdiction; nothing surprising can appear in the standard without going through the model.
Core
TSC-owned. The minimum every conforming implementation must support, with 2-year deprecation windows on breaking changes.
Augments
Vendor or agency additions in their own namespace. Add nodes; never modify core. A consumer that doesn't load them simply ignores the extra fields.
Deviations
TSC-reviewed constraint refinements. "In our jurisdiction the rule is this, not the maximum-permissive set." For example, stricter MUTCD timing.
Proprietary
Vendor-internal modules on a separate subject prefix, outside conformance. Keep the IP you want; keep it out of the standard.
The graduation rule
When three independent organizations (at least one an operator) ship the same augment wire-compatibly, and the TSC passes a graduation motion, it folds into the next minor revision of core, with attribution preserved. The core is what the industry has converged on; nothing lands by fiat.
A contract clause, not a marketing claim.
A conformance kit checks that an implementation carries the model faithfully. Claims name a profile so everyone knows exactly what was verified. The target is a public artifact, so there's no per-vendor negotiation of what "conformant" means.
The Vendor's product SHALL conform to OpenITS core for the {service} service at revision {YYYY-MM-DD} or later, and SHALL provide a conformance report produced by the OpenITS conformance kit, dated within 90 days of contract execution.
Four audiences, one model.
Agencies & operators
Write RFPs against a testable conformance bar instead of one vendor's surface. Carry majority weight on the models that matter to you.
Product vendors
Implement one model, ship to many customers. Extend in your own namespace today; earn core inclusion when the market converges.
Integrators & analytics
One consumer codebase reads every conforming agency and vendor. The code that reads one conforming agency reads any other, unchanged.
Researchers
An immutable, content-addressed registry keeps a pinned revision valid for years. ARC-IT annotations inherit the federal vocabulary.
Vikasa's collector, speaking the models.
vikasa-collector is Vikasa's edge poller. It reads roadside devices over SNMP, gNMI and ATSPM sources, translates their state into the OpenITS event model, and publishes typed events to NATS. That is the proof the models carry real device state, end to end.
The Vikasa stack (collector plus NATS) is one valid deployment that produces the models in the field. It is a proof point, not part of the standard.
Browse every model, event and field, plus the generated AsyncAPI description of the event surface, current with every release.
Browse the reference →Content-addressed, immutable YANG + Protobuf snapshots. A schema cached in 2026 still validates in 2032.
Open the registry →Role-specific paths for operators, vendors, integrators and contributors, plus Vikasa's collector.
Read the guide →Standing on OpenConfig's shoulders.
OpenITS owes a real debt to OpenConfig, whose work bringing vendor-neutral, model-driven management to networking was the inspiration for this project. The operators and vendors who built it paved the road. We're grateful, and we're carrying that spirit to the road network.
Operator-weighted, by design.
A nine-seat Technical Steering Committee (five operators, two vendors, one integrator, one community) gives operators majority weight on model-changing decisions. Vendors hold real seats and propose augments; they cannot ratify changes over operator objection.