Introduction
OpenITS is an open standard for how Intelligent Transportation Systems infrastructure describes itself. Vikasa, an open source implementation, provides the working code that proves the standard runs.
What OpenITS is
OpenITS is a vendor-neutral data model for roadside infrastructure, plus the tooling and conventions around it. The standard is OpenITS; the working code that proves it is Vikasa, an open source implementation:
An open standard
The YANG data models, versioning rules, subject conventions, governance, and extension framework, describing ITS infrastructure independent of any transport.
The Vikasa implementation
Open source code any operator can deploy, from Vikasa: an edge poller, a central ingest service, a conformance harness, and tooling to add device classes without forking.
A specification you can't run is a specification you can't trust; an implementation without a documented contract is vendor lock-in waiting to happen. That is why OpenITS (the standard) and Vikasa (the implementation) develop side by side.
Who it's for
OpenITS targets four audiences, each with a concrete reason to care.
Transportation agencies (operators)
- A vendor-neutral data model, so an RFP need not be written around one vendor's surface.
- A concrete conformance bar, so vendor claims are testable.
- A governance seat: operators carry majority weight on model-changing decisions.
Product vendors
- A model you implement once and ship to many customers.
- An augment mechanism for vendor-specific extensions that doesn't require forking the standard.
- A graduation path: when three independent organizations adopt your extension, it folds into core with attribution preserved.
Integrators & analytics builders
- One consumption pattern for any conforming agency or vendor: the code that reads one conforming agency reads any other, unchanged.
- A schema registry that lets consumers cache and validate payloads without runtime fetches.
Researchers & standards practitioners
- An immutable, content-addressed registry so referenced revisions stay valid for years.
- ARC-IT alignment annotations on every model, inheriting the federal architecture vocabulary.
What ships in the repository
Each service domain is wired end-to-end today, mapped to the device-level standard it models. This table is generated from the model catalog, so it stays in step with every release.
| Service | Domain | Reference standard |
|---|---|---|
| signal-control | Actuated signal controllers | NTCIP 1202 |
| dms | Dynamic message signs | NTCIP 1203 |
| ess | Environmental sensors / RWIS | NTCIP 1204 |
| rsu | Roadside V2X units | NTCIP 1218 |
| ramp-metering | Freeway ramp meters | NTCIP 1207 |
| perception | Machine-vision / detection | vendor augments |
| traffic-sensor | Volume / speed / occupancy | NTCIP 1209 |
| reversible-lane | Reversible / managed lanes | lane-control |
| cctv | CCTV / PTZ cameras | NTCIP 1205 |
Each service ships a YANG model, a companion notifications module, per-event Protobuf, an immutable registry snapshot, conformance cases, and ARC-IT flow annotations. A scaffolding tool takes a new service from ~16 file touches to one command plus five hand-edits.
What OpenITS is not
- Not a replacement for NTCIP / SAE / IEEE. OpenITS sits above those standards; devices still speak them. OpenITS defines what their state and events mean once they're behind a gateway.
- Not tied to a transport. The models are the contract. Carry them over REST, RESTCONF, gNMI, or an event stream. Vikasa's implementation is just one valid binding.
- Not a video transport. CCTV metadata flows through OpenITS; the video itself rides the operator's existing network with out-of-band URLs.
- Not a SaaS. OpenITS is a specification; Vikasa is an open source implementation of it. Operators run their own infrastructure; hosted offerings can build on top, but the standard doesn't assume one.
How to read the rest
Pick by role, or read straight through:
- Operator: Why OpenITS → Conformance → Getting started.
- Vendor: Architecture → Extension model → Conformance → Getting started.
- Developer: Architecture → Extension model → Getting started.
- Standards practitioner: Standards alignment → Extension model → Governance.