Case study
One operating picture across every traffic management center
A dozen traffic management centers on different ATMS vendors, one statewide operating picture. Veodyn federates the centers instead of replacing them.
The setup
Picture a state with a dozen regional traffic management centers. Each district runs its own systems. One TMC is on one vendor's ATMS, the next district is on another, an older corridor is on something a contractor stood up years ago. Each has its own camera network, its own detectors, its own signal controllers.
The state wants one thing: a single operating picture. When a crash closes a freeway in one district and traffic backs up into the next, the two TMCs should see the same incident, on the same map, at the same time. The governor's office wants one statewide dashboard. The traveler information system wants one feed, not twelve.
The data problem
Today the state has two bad options.
It can rip out every district ATMS and standardize the whole state on one platform. That is years of work, tens of millions of dollars, and a political fight with every district that likes the system it has.
Or it can commission a custom aggregation project that reaches into all twelve centers and pulls their data into one place. That is the more common path, and it works until a district upgrades its ATMS, changes a feed, or adds a camera network. Then the custom integration breaks and someone has to re-wire it. The state ends up maintaining a brittle middle layer forever.
Neither option lets the districts keep what they have while the state gets the picture it needs.
The Veodyn architecture
Veodyn federates the centers instead of replacing them. Each TMC runs a node alongside its existing ATMS. The node speaks the center-to-center standards the ATMS already exports. The hub normalizes every node into one statewide layer and exposes it through a single open API and an AI query surface. The statewide dashboard calls one endpoint, not twelve. From that layer it reads:
- Incidents and events (TMDD) so every district sees the same crash, closure, and response status in real time
- Signal and device status (NTCIP) so arterial conditions show up next to freeway conditions
- Camera metadata and detector volumes so operators can find the nearest working camera regardless of which district owns it
- Weather and road condition feeds stitched in alongside, where the agency publishes them
All of it normalized across every center in the state. The districts keep their own ATMS, their own staff, their own workflows. What changes is that their data now lands in one consistent statewide layer instead of a dozen incompatible ones.
What the statewide layer can do
Each capability is powered by a feed Veodyn already federates.
| The capability | What powers it |
|---|---|
| Statewide situational awarenessone map, every district | TMDD incidents plus NTCIP signal status, normalized across centers. |
| Cross-district incident coordinationa closure in one district visible to its neighbor | Real-time TMDD event feeds shared across nodes. |
| One traveler information feed511, apps, signs all reading the same source | Normalized incident and device data through one open API. |
| Find-the-nearest-camera across district lines | Federated camera metadata, not siloed per center. |
| Statewide performance reportingclearance times, closure duration | Event and device history through the analytics surface. |
We don't replace your ATMS
Veodyn is the exchange layer, not the ATMS.
Each district's ATMS still controls its signals, its ramp meters, its message signs, its cameras. The vendors that run those systems keep running them. Veodyn sits above, takes what each center already exports, and makes it one normalized, queryable statewide picture. Each district keeps its vendor and its workflow. The state stops paying to re-integrate twelve centers every time one of them changes.
Why no vendor owns the picture
Because each center owns its node and the data layer is open, no single ATMS vendor owns the statewide picture. Add a district, it joins the same normalized layer. A district swaps its ATMS vendor next procurement cycle, and the statewide feed does not notice. That is the difference between a custom aggregation project that breaks on every upgrade and a federation that absorbs change as a matter of course.
See it on your network
Tell us which centers and ATMS vendors your state runs, and we will map the fit. Book a call.
More solutions
Other programs Veodyn makes possible, walked end to end. Or browse all solutions.
- Regional coalition · multimodal Regional rewards One rewards program across a dozen operators
- State DOT · transit data Statewide transit feed One current GTFS feed for the whole state
- State DOT · multi-jurisdiction Local federation Cities join without giving up their data
- Grant-funded mobility · continuity The pilot cliff Integrations that outlive the grant