# What intelligent transportation systems actually are

> Intelligent transportation systems is a broad label that hides a precise idea. What ITS covers, what it looks like on the street, and why 253 of the 304 standards in the national architecture are about nothing but getting data from one system to another.

Published 2026-07-13, updated 2026-08-21 by Nick Sawinyh.
Explainer in Interoperability.
Canonical: https://its-feed.com/articles/what-are-intelligent-transportation-systems/
Keywords: intelligent transportation systems, intelligent transport systems, ITS, intelligent transportation systems examples, smart transportation, ARC-IT, connected vehicles, transit data, interoperability

---

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](https://www.its.dot.gov/about/) 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](https://www.arc-it.net/html/servicepackages/servicepackages-areaspsort.html), groups its service definitions
into twelve service areas. [Version 9.4](https://www.arc-it.net/), 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](https://its-feed.com/articles/what-is-gtfs-realtime/) and what makes
[arrival predictions](https://its-feed.com/articles/how-real-time-arrival-predictions-work/) 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](https://its-feed.com/articles/ghost-buses/) 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](https://highways.dot.gov/public-roads/summer-1994/ivhs-architecture-program-systematic-approach-progress), 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](https://www.arc-it.net/html/architecture/architecture.html) 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](https://www.arc-it.net/html/standards/standards.html) 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.

![Horizontal bar chart of standards bodies in ARC-IT's communications view: ISO 37, IETF 35, ETSI 23, CEN 22, SAE 17, NTCIP 15, 3GPP 11, IEEE 9, ANSI 7, UN/EDIFACT 5, and 72 standards in everything else.](https://its-feed.com/charts/what-are-intelligent-transportation-systems-standards-by-body.png)

*No single body publishes more than about 15 percent of the communications catalog, and the tail is long: 72 of the 253 sit outside the ten largest, most of them appearing once. Source: ITS Feed count of the ARC-IT 9.4 standards catalog (arc-it.net), 2026-08-21. Bodies read from each standard's ARC-IT short-name prefix; method in research/data/arcit_standards.py.*

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](https://its-feed.com/articles/transit-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](https://its-feed.com/articles/what-is-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](https://its-feed.com/articles/shared-mobility-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](https://its-feed.com/articles/open-loop-tap-to-pay/) 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](https://its-feed.com/articles/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.

![Timeline of US intelligent transportation systems milestones from 1991 to 2024: ISTEA establishes the program in 1991, renamed ITS in 1994, first National ITS Architecture in 1996, three Connected Vehicle pilots funded in 2015, ARC-IT released in 2017, and the National V2X Deployment Plan in 2024.](https://its-feed.com/charts/what-are-intelligent-transportation-systems-timeline.png)

*Nineteen years separate the first national architecture (1996) from the connected-vehicle pilots (2015): the long infrastructure era, before the vehicles themselves joined the network. Source: US DOT (ISTEA 1991; FHWA; ITS JPO Connected Vehicle Pilots; ARC-IT; National V2X Deployment Plan, 2024).*

The connected-vehicle turn is easiest to see in the [2015 pilots](https://www.itskrs.its.dot.gov/briefings/executive-briefing/connected-vehicle-pilot-deployment-program-2024-update). 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](https://www.arc-it.net/documents/arcit-cvria-nia71.pdf) 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](https://highways.dot.gov/newsroom/usdot-releases-national-deployment-plan-vehicle-everything-v2x-technologies-reduce-death), 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](https://www.fcc.gov/document/fcc-modernizes-59-ghz-band-improve-wi-fi-and-automotive-safety-0),
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](https://its-feed.com/articles/ai-in-transit/), 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.

## Frequently asked questions

### What are intelligent transportation systems?

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 US Department of Transportation has run a federal ITS program on that premise since 1991, aimed at improving transportation safety, mobility, and efficiency through the integration of innovative technologies.

### What are examples of intelligent transportation systems?

A traffic signal that retimes itself to demand, a transit agency's real-time bus feed, a ramp meter, a weigh-in-motion station on a freight corridor, a tolling gantry, a road weather station, and an in-car radio that warns about a vehicle in the blind spot are all ITS. What ties them together is that each one produces data another system is expected to act on.

### What is ARC-IT?

ARC-IT is the US reference architecture for intelligent transportation systems: the framework that defines how ITS components exchange data, so systems from different vendors and agencies can fit together. Version 9.4, released in July 2026, catalogs 162 service packages across twelve service areas.

### What do intelligent transportation systems use GPS for?

Almost anything that reports where something is. A transit vehicle's onboard computer takes a satellite fix, matches it to a route and a schedule, and publishes the result as a position and a prediction. ARC-IT treats positioning as shared infrastructure rather than a feature of any one service, under a support service package called Location and Time.

### Is smart transportation the same as ITS?

They overlap heavily and are often used interchangeably. ITS is the older term and the one written into US federal programs, standards, and funding, so it is what appears in procurement documents. Smart transportation and smart mobility are usually planning or marketing language for the same instrumented, networked infrastructure, often framed around a city rather than a corridor.

### What is C-ITS?

Cooperative ITS is the subset where vehicles, infrastructure, and other road users exchange messages directly with each other rather than only reporting upward to a management center. It is the idea behind vehicle-to-everything communication, and it is why the current US reference architecture has the word cooperative in its name.

---

Source: ITS Feed, https://its-feed.com/articles/what-are-intelligent-transportation-systems/
ITS Feed is an independent editorial site on the data and technology layer of transportation, published by the team at Veodyn. Figures trace to the sources linked inline.
Site index for agents: https://its-feed.com/llms.txt