Architecture
OpenITS sits above the device-level protocols. Devices keep speaking what they speak; OpenITS defines what their state and events mean once they are behind a gateway.
The layers
OpenITS separates what the data means from how it moves and where it runs:
- The models. Versioned YANG describing each service domain and a companion notifications tree. This is the standard.
- A binding. The mapping of those models onto a transport (REST, RESTCONF, gNMI, or an event stream). Bindings are generated from the model, not hand-written.
- A deployment. Actual running software. Vikasa, the open source reference implementation, is one valid deployment; it is not part of the standard.
The gateway boundary
Field devices continue to speak their native protocols: NTCIP over SNMP, SAE J2735 over V2X, vendor serial dialects. A gateway (edge poller) sits in front of them and translates device state into OpenITS models. Everything north of the gateway speaks OpenITS; everything south is unchanged. This is what lets a shared model coexist with decades of installed equipment.
Transport bindings
Because the model carries no transport opinion, the same signal-controller state can be served as a REST resource, streamed over gNMI, or published as a CloudEvent, all generated from one source of truth. An agency binds OpenITS to whatever it already runs; conformance is about carrying the model faithfully, not about adopting a particular pipe.
+ vendor augments
The Vikasa stack
Vikasa’s collector, vikasa-collector, binds the models to CloudEvents over NATS: it polls roadside devices, translates their state into the OpenITS event model, and publishes typed events. It exists to prove the models carry real device state end to end, not to prescribe a stack. Any faithful binding conforms.