What intelligent transportation systems actually are

Intelligent transportation systems, or ITS, is the layer of sensing, computing, and communications laid over roads, vehicles, and transit so they can be measured and managed rather than just built and left to run. The federal government has funded a program on that premise since 1991, and the US Department of Transportation’s ITS Joint Program Office states its charter in those terms: research, develop, and operationally test ITS, and provide technical assistance in its nationwide application, with the aim of improving transportation safety, mobility, and efficiency through the integration of innovative technologies.

The label is broad enough to mean almost nothing in casual use. A traffic signal that retimes itself to demand is ITS. So is a transit agency’s real-time bus feed, a weigh-in-motion station on a freight corridor, a ramp meter, a tolling gantry, and a radio in a car that warns the driver about a vehicle in the blind spot. What ties those things together is not the hardware, which comes from dozens of vendors and generations. It is data moving between systems that were built separately and are owned by different agencies. That is the useful way to read the term: ITS is what happens when transportation infrastructure is instrumented and networked, and the hard part is almost always the networking.

That claim can be checked rather than asserted. The national reference architecture publishes its own catalog of the standards an ITS deployment can be built against, and we counted it: 304 standards, of which 253 appear in the view that describes how one system talks to another.

What the term actually covers

The scope is genuinely wide, and the best map of it is the national reference architecture the US uses to catalog ITS services. That catalog, ARC-IT, groups its service definitions into twelve service areas. Version 9.4, released in July 2026, holds 162 service packages in all. The list below is a fair picture of what practitioners mean when they say ITS.

Service area	Service packages	What it covers
Traffic Management	26	Signals, ramp meters, incident and work-zone management, traffic monitoring
Commercial Vehicle and Freight Operations	23	Freight, credentialing, electronic screening, safety inspection
Vehicle Safety	20	Collision avoidance and driver-assistance functions, largely connected-vehicle
Public Transportation	18	Fleet management, real-time information, fare payment, demand-response
Public Safety	15	Emergency call-taking, dispatch, responder coordination
Support	15	Shared services the other areas depend on, including positioning, security, and data distribution
Maintenance and Construction	12	Winter maintenance, fleet and asset management, work-zone systems
Sustainable Travel	11	Demand management, shared mobility, environmental monitoring
Traveler Information and Personal Mobility	9	Trip planning, traveler alerts, personal navigation
Parking Management	7	Parking availability, reservations, electronic payment
Weather	4	Road-weather data collection and dissemination
Data Management	2	Collecting, warehousing, and sharing ITS data

Two things stand out. Public transportation is one of the larger areas here, which is a fair reflection of why the program dropped its original highway-only name. And the single smallest area, data management, is the one everything else quietly leans on. The services are only as good as the data they can move.

The catalog also moves. Version 9.4 folded vehicle automation concepts into the architecture and added support for port community information systems. The result is an architecture where a service package called Low Speed Automated Driving for Predefined Routes sits under public transportation, next to fare collection and passenger counting.

What it looks like on the street

The abstraction is easier to hold onto with the actual objects in view. Every example below is ITS, and the useful way to read each one is by what it emits and who is waiting for it, rather than by what it is made of.

Deployment	What it senses or decides	What it produces	Who consumes it
Adaptive traffic signal	Vehicle presence and queue length at the stop bar	Timing plans, phase and cycle data	Traffic management center, neighboring signals
Ramp meter	Mainline speed and occupancy upstream	Release rate, mainline detector counts	Freeway management system
Transit vehicle tracking	Where a bus is, against which route and trip	Position, delay against schedule	Dispatch, rider apps, signal priority
Automatic passenger counters	Boardings and alightings per door per stop	Load by stop and time of day	Service planning, federal reporting
Weigh-in-motion station	Axle weight and spacing at highway speed	Weight records, overweight alerts	Enforcement, pavement management
Tolling gantry	A transponder or plate passing a point	Transaction records	Back office, interoperable toll hubs
Road weather station	Pavement temperature, moisture, visibility	Road weather observations	Maintenance dispatch, traveler alerts
Blind-spot warning radio	Another vehicle in a lane beside this one	A short-range safety message	The vehicle next to it

Read down the third column and the definition becomes concrete. In every case the sensing is comparatively easy and comparatively solved. What decides whether the deployment is worth anything is whether the fourth column can read the third, in the format and at the rate it arrives, from a system it did not procure.

Where the position data comes from

A large share of ITS runs on knowing where something is, and almost all of that comes from satellite positioning. This is common enough that ARC-IT does not treat it as a feature of any one service. It is a support service package, Location and Time, sitting alongside security and communications as shared plumbing every other area draws on.

Transit is the clearest case. A bus carries an onboard computer taking a satellite fix every few seconds. On its own that fix is a pair of coordinates and nothing more. The computer matches it to the route shape, works out which trip it is running and how far along, and compares that against the schedule. Only then does it have something worth publishing: a position and a delay against the timetable, which is what reaches a rider through GTFS-Realtime and what makes arrival predictions possible at all.

The failure modes come from the same place. A fix degrades in an urban canyon, disappears in a tunnel, and drifts when a vehicle is stopped, which is why onboard systems fall back to dead reckoning from odometer and heading. A vehicle whose position stops updating does not usually vanish from a rider app. It freezes in place, or it goes on generating a prediction after the bus is long gone, which is one of the four ways a ghost bus gets born.

The architecture that holds it together

ITS did not start with a plan for how the pieces would fit. It started with a mandate to make them fit. When Congress created the national program in the Intermodal Surface Transportation Efficiency Act of 1991, it required the Department of Transportation to develop standards and protocols that would promote compatibility across the systems states were about to build. Without that, every region would reinvent its own interfaces and none of them would talk to each other.

The answer was a national reference architecture: a shared vocabulary for the actors, the functions, the physical devices, and the messages that pass between them. The current version, the Architecture Reference for Cooperative and Intelligent Transportation (ARC-IT), organizes all of this into four views. Knowing them helps, because they map cleanly onto the questions a deployment has to answer.

ARC-IT view	The question it answers
Enterprise	Who are the organizations involved, and what agreements do they need with each other
Functional	What does the system have to do, as requirements independent of any product
Physical	Which systems and devices (the subsystems) provide those functions
Communications	How do those systems exchange information, and over which standards

The communications view is where the data layer lives, and it is the reason a reference architecture matters at all. A signal controller and a traffic management center can only cooperate if they agree on a message set. That agreement is what standards encode. NTCIP governs the conversation between a management center and field devices such as signals and message signs. TMDD governs center-to-center exchange, so one agency’s system can hand data to a neighbor’s. ARC-IT does not invent these standards. It says which ones belong on which link, so that a deployment is specified rather than improvised.

Most of the architecture is about formats

ARC-IT publishes its standards catalog as a set of tables: every standard in the architecture, then the subsets referenced in the communications, physical, and service-package views. We parsed those tables on 2026-08-21 and counted what is in them. The architecture references 304 distinct standards. Of those, 253 appear in the communications view and 33 in the physical view.

The two views overlap, so those are not disjoint piles, and the ratio between them is the argument of this article arrived at through ARC-IT’s own bookkeeping. The architecture needs roughly eight times as much shelf space for how ITS systems talk as for what they are made of.

ISO and the IETF lead the count because the catalog reaches all the way down to transport protocols and all the way out to international freight. ETSI and CEN are there because Europe standardized much of this in parallel and ARC-IT references both. SAE carries the connected-vehicle message sets. NTCIP is the one an American traffic engineer meets first, because it is what a signal controller procurement cites.

No agency implements 253 standards. It implements the handful its service packages call for, and then discovers that the vendor on the other side of an interface read a different revision of the same one. That is what interoperability work is, most days.

What ITS means in transit specifically

Transit is where this site spends its time, and it is a good test of whether the architecture describes anything real. ARC-IT’s public transportation area covers eighteen service packages, and they line up almost exactly with the systems an operations department already runs: vehicle tracking, fixed-route and dynamic operations, fare collection management, passenger counting, fleet management, traveler information, signal priority, connection protection, and now low-speed automated driving on predefined routes.

The communications view names seventeen standards for that work, and the shape of the list says more than the count does. Six are parts of CEN’s Transmodel, the European conceptual model for public transport. Six more are SIRI and NeTEx, the European exchange formats for real-time and scheduled service. One is NTCIP 1211, the signal control priority object definitions that let a late bus ask a signal for green. One is TCIP, the North American transit communications profile set.

The last four are the odd ones. GTFS, GTFS-Realtime, the GTFS-Flex extension, and the Transit ITS Data Exchange Specification are all in the catalog, and not one of them came out of a formal standards development organization. They came from an industry that needed a format and agreed on one in public. ARC-IT lists them next to ISO and CEN because a reference architecture eventually has to describe what agencies actually do, and what agencies actually do is publish GTFS.

The same story is running again a layer out. Shared mobility grew its own data stack the same way, and fare payment has been pulled into the card networks’ specifications rather than the transportation ones, which is why an open-loop tap behaves like a payments transaction and not like a transit one. Meanwhile the federal reporting obligation that shapes what agencies collect in the first place, the National Transit Database, predates all of it and was never designed to interoperate with any of it.

ITS, smart transportation, and C-ITS

ITS is the oldest of the three labels for this territory, and the most load-bearing. It is the term written into US federal programs, standards, architecture, and funding, so it is the one that appears in a procurement document and in a grant application. Outside the US the same field is usually called intelligent transport systems, singular transport, which is why ISO and CEN documents read slightly differently from FHWA ones.

Smart transportation, smart mobility, and smart city transportation are mostly planning and marketing language for the same instrumented, networked infrastructure. The framing differs: smart city work tends to start from a municipality and a set of civic goals, while ITS work tends to start from a corridor, a mode, or an agency’s operations. The technology underneath is largely the same, and a project can honestly be described either way depending on who is being asked for money.

Cooperative ITS, or C-ITS, is a genuine subset rather than a synonym. It is the part where vehicles, infrastructure, and other road users exchange messages directly with each other, instead of every device reporting upward to a center that decides things. It is why the current architecture has the word cooperative in its name, and it is the through-line of the last decade of the program.

From instrumented highways to connected vehicles

The program has moved through two broad eras. The first instrumented the infrastructure: detectors in pavement, cameras, ramp meters, management centers, and the standards to tie them together. The second turned the vehicles themselves into data sources and recipients, so that cars, infrastructure, and other road users can exchange short-range messages directly. The milestones below trace that shift.

The connected-vehicle turn is easiest to see in the 2015 pilots. The Department funded three sites, in New York City, Tampa, and Wyoming, with a combined $45 million in federal funding. New York’s was designed around roughly 8,500 vehicles and some 310 instrumented intersections, though the fleet actually equipped came in smaller. That is still the scale of moving from a lab demonstration to a working deployment on real streets. In 2017 the reference architecture caught up with the research: ARC-IT merged the older National ITS Architecture with the separate connected-vehicle architecture into one framework, so that traditional infrastructure ITS and connected vehicles could be planned from the same catalog.

What to watch

The current frontier is vehicle-to-everything, or V2X, the direct wireless link between vehicles, infrastructure, and other road users. In August 2024 the Department published a national plan to accelerate V2X deployment, its clearest signal yet that connectivity is the priority. The binding constraint is not the vehicles but the airwaves. In 2020 the Federal Communications Commission reallocated the 5.9 GHz band, moving the lower 45 MHz to unlicensed uses such as Wi-Fi and leaving the upper 30 MHz for transportation. How well V2X works within that narrower slice is an open question the plan itself flags, alongside funding and the difficulty of proving benefits from early deployments.

Automation is the other direction of travel, and the July 2026 architecture release is the tell: vehicle automation concepts now sit inside the reference architecture rather than alongside it. The Joint Program Office’s own priorities point the same way, listing artificial intelligence, automation, interoperable connectivity and spectrum, intersection safety, the ITS4US program aimed at complete trips for travelers of all abilities, and V2X deployment. This is a policy area that is still moving, so treat the specifics here as a snapshot of mid-2026.

The shape of the field has been stable for three decades, and the standards count is the evidence. Whatever the era’s headline technology, the work that decides whether a deployment functions is the work of getting the data to move.