Connecting Your VMS Fleet to State ATMS Platforms: A System Integrator’s Reference

NTCIP 1203 conformance gets a VMS fleet talking to a Transportation Management Center in general terms — it doesn’t mean the fleet is ready for a specific state’s Advanced Traffic Management System (ATMS). For connecting VMS fleet to state ATMS platforms, the practical onboarding step comes down to which software the state actually runs, and that varies more than most procurement documents admit.

This guide assumes the fleet already meets baseline NTCIP 1203 conformance — for object definitions, PICS documentation, and security hygiene, see our companion guide to connecting mobile VMS with TMC systems. The focus here is what changes once a specific state platform enters the picture.

What Changes When You Connect a VMS Fleet to a Specific State ATMS Platform?

Every major state ATMS speaks NTCIP, but each platform layers its own polling frequency, event-ID convention, and message-table sync logic on top. The table summarizes the platforms system integrators encounter most often on US projects; the sections below go deeper on each.

Platform	Operator / Region	Data Exchange Focus	What to Verify Before Onboarding
Lonestar™	Texas DOT	District-level command & status distribution	Which district deployment governs the site
SunGuide®	Florida DOT	Cross-TMC incident & signal data, FL511 feed	Which FDOT District instance applies
OHGO	Ohio DOT	Camera, incident, and road-weather data	Winter event-feed linkage to message priority
Open TMS	PennDOT	Centralized statewide command & status	Single statewide integration point, not district-by-district
TRANSCOM OpenReach	NY/NJ/CT tri-state region	Regional multi-agency incident data sharing	Confirm this is the intended platform, not PennDOT’s Open TMS
IRIS	Caltrans (select districts)	Open-source device control & status	Which Caltrans district, and whether it runs IRIS or a separate system
TransSuite®	TransCore, multi-agency	Standard NTCIP object exchange	Platform-specific acceptance test process

Platform names reflect publicly documented information as of mid-2026. Agencies periodically rebrand or replace these systems — confirm the current name with the agency before scoping a project.

Connecting to Texas Lonestar™ ATMS

Operator: Texas DOT · Model: District-level, consolidating toward a single cloud system · Verify: Which deployment tier governs the project site

Lonestar ATMS VMS integration connects TMCs to field devices — dynamic message signs, detectors, CCTV cameras — through software that has run Texas DOT’s traffic management centers for roughly two decades. Districts have historically run separate Lonestar™ deployments, though the state is consolidating toward a single cloud-based system, so an integrator should confirm which tier the target district currently runs before scoping status and command mapping.

Connecting to Florida SunGuide® ATMS

Operator: Florida DOT · Model: Multi-district, 15 TMCs statewide, currently version 9.0 · Verify: Which District’s SunGuide instance governs the site

SunGuide VMS integration covers software that Florida DOT’s Districts and toll authorities run across 15 Transportation Management Centers statewide, exchanging signal timing, congestion, and incident data between TMCs and feeding Florida’s FL511 traveler system. FDOT’s own Version Description Document confirms SunGuide 9.0 as an actively tracked release, not a static legacy system. SunGuide’s early development leveraged Texas DOT’s own ATMS investment, though the two platforms have since diverged. Because SunGuide runs per-District, confirm which District instance governs the deployment site before mapping device status reporting.

Connecting to Ohio OHGO

Operator: Ohio DOT · Model: Statewide, camera/incident/road-weather consolidation · Verify: Winter event-feed linkage to message priority

OHGO VMS integration connects field devices to Ohio DOT’s statewide traveler information and traffic management platform, consolidating camera feeds, incident data, and road-weather conditions into one system — relevant for winter deployments where message priority often depends on weather-linked feeds rather than incident reports alone. ODOT actively maintains the platform: recent updates added multi-route construction handling and dangerous-slowdown alerts, evidence the state keeps extending it rather than leaving it static.

Connecting to Pennsylvania’s Open TMS

Operator: PennDOT · Model: Centrally hosted, statewide · Verify: Not to be confused with TRANSCOM’s OpenReach

Pennsylvania’s PennDOT runs Open TMS, a centralized, web-based ATMS platform hosted by the agency and accessible from every regional and district TMC. Because it’s centrally hosted rather than run as separate district instances, PennDOT Open TMS integration typically goes through one statewide integration point rather than a district-by-district process.

This is a different system from TRANSCOM OpenReach, a regional data-sharing platform TRANSCOM operates for the New York, New Jersey, and Connecticut tri-state area. A system integrator quoting a Northeast US project should confirm which one the client means before scoping the work.

Connecting to California’s District-Level Systems and Multi-State Commercial Platforms

Operator: Caltrans (varies by district) · Model: No single statewide platform · Verify: Which system the specific district runs

Caltrans does not run one single ATMS statewide. Several rural districts run IRIS, an open-source platform originally developed by Minnesota DOT and adopted by Caltrans District 10 to lower deployment cost, while other districts run separate commercial systems — so Caltrans IRIS VMS integration for a multi-district fleet requires confirming which platform each district actually runs.

Not every agency builds its own ATMS. Many mid-size counties and regional authorities instead run TransSuite®, a TransCore product. Deployments are actively maintained — a regional planning agency’s October 2025 meeting record shows a partner agency on TransSuite version 25.1.3, with a further update scheduled. TransSuite VMS integration and district- or state-built platforms rely on the same underlying NTCIP objects, but a fleet split across both still needs separate onboarding and acceptance testing for each.

What System Integrators Should Verify Before Any State ATMS Onboarding

Our team fields a recurring question before onboarding: does the ATMS pull device status and GPS location automatically once the VMS reports over NTCIP 1203, or does the fleet need a custom mapping layer? The answer depends on how the platform expects data structured, not on the sign hardware. Before onboarding a VMS fleet to any state ATMS platform, confirm:

• Which NTCIP object groups the platform actually polls, not just the full PRL the sign supports
• The event-ID or incident-tagging convention the platform expects
• The GPS and device-status reporting interval the district or state requires
• The acceptance test process the agency runs before allowing the sign onto the live network

Because Optraffic’s Web System already exposes the full NTCIP 1203 object set, integrators skip building a proprietary bridge before this checklist even starts — the remaining work is platform-specific mapping, not baseline protocol support.

Conclusion

Connecting VMS fleet to state ATMS platforms means treating each region as its own onboarding project, even with a fully NTCIP 1203-conformant fleet. Lonestar™, SunGuide®, OHGO, Open TMS, TRANSCOM’s OpenReach, Caltrans’s IRIS, and TransSuite® each structure data differently, and confirming those differences before acceptance testing saves a system integrator from a failed field trial. Optraffic builds NTCIP 1203 object support into everyVMS trailerby default, so the fleet side stays constant across every region an integrator operates in.

FAQ

---

See how the Optraffic Web System delivers full NTCIP 1203 object support for VMS fleets operating across multiple states.

Related reading:

• NTCIP 1203 Compliance for Roadside Variable Message Signs
• Understanding NTCIP: The Protocol Suite for Traffic Management
• Mobile VMS Strategies for Highway Congestion Mitigation