Cutting Through the Complexity of Transit Vehicle Communication

A breakdown of the major vehicle communication protocols used across public-transit fleets, mapped to the OSI model, and what each one means for maintenance and operations.

Carolyn Rusin

August 14, 2026

Min Read

Modern transit fleets generate more diagnostic and operational data than ever before, yet many operators still struggle to turn that information into clear, actionable insight. A bus may show a fault on the dashboard, but the underlying data available through the vehicle's communication systems often feels incomplete, inconsistent or difficult to interpret.

The challenge isn't a lack of data. It's the complex ecosystem of communication protocols that govern how systems inside a bus, tram or depot vehicle exchange information. As fleets become more electrified, more connected and more software-driven, understanding these protocols is essential for reliable operations, efficient maintenance and informed decision-making.

This guide explains the major communication standards used in transit fleets — CAN, J1939, UDS, OBD-II, FMS and VDV 238 — and how they fit into the OSI model that defines modern vehicle communication.

Are These Protocols the Same as Telemetry?

Technically speaking, no. Telemetry is the data itself; the information a vehicle sends to your systems. Protocols like CAN, J1939, UDS, OBD-II, FMS and VDV 238 are the communication standards that define how that data is structured and accessed.

Together, these standards form the foundation of modern fleet telematics.

Why Transit Fleets Face Extra Complexity

Transit operators rarely manage a single type of vehicle. Instead, they run fleets that span multiple manufacturers, different generations of hardware and a wide range of propulsion technologies, including diesel, hybrid, battery-electric, hydrogen fuel-cell and trolley or rail-based electric systems.

Each vehicle type brings its own communication behavior and diagnostic standards: a diesel bus may rely heavily on J1939, an electric bus may expose most of its data through UDS and proprietary battery-management messages, and a tram may use VDV 238 for operational subsystems.

For maintenance and operations teams, understanding these differences is essential. The mix of OEMs, vehicle ages and propulsion types creates a varied data environment. Knowing how each system communicates helps teams improve maintenance planning, reduce downtime, support electrification, integrate real-time data into dispatching and enhance both safety and passenger experience.

Breakdown of the Major Standards You'll Encounter

CAN 2.0A and CAN 2.0B

Controller Area Network (CAN) is the foundational communication layer inside nearly every modern bus or tram. It defines the physical and data-link behavior that allows electronic control units (ECUs) to communicate in real time.

CAN 2.0A uses 11-bit identifiers.
CAN 2.0B uses 29-bit identifiers.

CAN itself only covers OSI layers 1–2: voltage levels, bit timing, arbitration, identifiers and error handling. Everything above those layers is defined by higher-layer protocols such as J1939, UDS and OBD-II.

J1939

Built on top of CAN, J1939 is the dominant standard for heavy-duty vehicles, including buses. It defines how messages are structured, how parameter groups are organized and how standardized data points are interpreted. In other words, J1939 is the dictionary that tells you what each CAN message means.

Key components include:

J1939-21 — transport protocol (BAM and connection-mode), segmentation and reassembly.
J1939-81 — network management and address claiming.

For transit fleets, J1939 provides consistent access to engine, drivetrain and emissions-related diagnostics across different OEMs.

Unified Diagnostic Services (UDS)

UDS is used for deep diagnostics and ECU communication. It enables reading and clearing fault codes, running component tests and accessing advanced diagnostic data.

UDS is bus-agnostic. It runs over:

CAN via ISO-TP
DoIP
LIN
FlexRay

This makes UDS essential for modern electric buses, battery systems, inverter diagnostics and advanced safety components.

OBD-II

OBD-II is the regulatory diagnostic standard for passenger cars, but it also appears in some light-duty transit vehicles and support fleets. It provides standardized fault codes and emissions-related data, making it useful for smaller service vehicles, though it is more limited than J1939 or UDS.

Fleet Management System Standard (FMS)

FMS is a manufacturer-independent interface created by European truck and bus OEMs. It provides standardized access to operational data such as fuel consumption, engine load, vehicle speed and driver behavior metrics. FMS ensures consistent data across mixed bus fleets, especially when integrating with depot systems or scheduling platforms.

VDV 238

VDV 238 is a public-transport-specific data standard widely used in European bus fleets. It defines how to access operational signals such as door states, passenger counters, HVAC systems, accessibility features and other transit-specific components. VDV 238 acts as a bridge between the vehicle and the broader transit ecosystem, enabling integration with dispatching, passenger information systems and depot operations.

Looking for how these standards map to the OSI model layer by layer? The full protocol matrix is in the panel on the right.

OSI Model Context for Vehicle Communication

Layer 1: Physical

Defines voltage levels, bit timing, wiring, termination and bus speed. Physical-layer issues often appear as intermittent communication faults, dropped frames or bus-off conditions.

Layer 2: Data Link

Controls arbitration, identifiers, error handling and frame structure. Most “raw CAN” behavior lives here.

Layer 3–4: Network and Transport

Higher-layer protocols define how messages are organized and transported. J1939-21 handles transport (BAM and connection-mode), and ISO-TP segments and reassembles UDS and OBD-II messages. These layers determine whether large diagnostic messages arrive intact.

Layer 5–7: Session, Presentation and Application

This is where diagnostic logic lives. UDS defines diagnostic sessions, security access, fault reading and component tests, while OBD-II provides a constrained subset of UDS-style services. These layers define how technicians retrieve faults and run tests.

Why OSI Layers Matter for Transit Fleets

Understanding the OSI model directly affects how transit operators diagnose issues, integrate data and maintain mixed fleets.

Diagnosing Communication Failures

Knowing which OSI layer a problem originates from helps teams pinpoint root causes faster, whether it's wiring, arbitration, segmentation or diagnostic-session behavior.

Supporting Electric Buses

Electric buses rely heavily on higher-layer protocols such as UDS for battery management, inverter diagnostics and thermal control.

Ensuring Reliable Data Flow

Transport-layer behavior determines whether multi-frame diagnostic messages arrive intact. Poor segmentation can lead to incomplete data or misinterpreted faults.

Driving Maintenance Workflows

Application-layer protocols define how technicians read faults, run tests and clear codes. Understanding these layers helps teams build consistent workflows across diesel, hybrid and electric fleets.

What This Means for Transit Operations

Together, these protocols unlock the data needed to monitor vehicle health, reduce unplanned downtime, optimize energy use for electric fleets, improve safety, support predictive maintenance and integrate real-time information into depot and scheduling systems.

No single protocol provides everything a fleet needs, so operators must combine multiple data sources to get a complete operational picture.

How Capte Supports Transit Fleets

Transit operators don't need to master every protocol to benefit from the data they provide, but they do need tools that can interpret these standards consistently across diverse vehicles.

At Capte, we work with CAN, J1939, UDS, OBD-II, FMS and VDV 238 each day. By simplifying access to these communication layers, we help operators turn raw vehicle data into reliable operational insights that support maintenance, dispatching and electrification strategies.

Navigating the Challenge

These communication standards may be complex, but they're the key to unlocking reliable maintenance insights, streamlined operations and smarter decision-making. With a platform designed specifically for public-transport fleets, operators can turn raw vehicle data into meaningful action and keep their networks running at their best.

Reference

Country-by-country timelines

Operator & regulator information current to late 2025. Dates do shift — confirm with each operator before final procurement.

ActivePlannedClosedNever

France

Operator	2G	3G
Orange	End-2026	End-2028
Bouygues	End-2026	End-2029
SFR	End-2026	End-2028
Free	Never	Active

All three legacy operators aligned on 2G by end-2026. 2026 is the working deadline.

Belgium

Operator	2G	3G
Proximus	End-2027	Closed
Orange BE	End-2030	Jul 2025
Telenet	End-2027	Dec 2024

3G is gone. 2G has a longer runway — one of the few viable medium-term 2G markets.

Netherlands

Operator	2G	3G
KPN	Dec 2027	Apr 2022
Vodafone	End-2026	Feb 2020
Odido	Jun 2023	Aug 2026

KPN extended 2G to Dec 2027 for M2M/IoT — breathing room on KPN SIMs.

Luxembourg

Operator	2G	3G
POST	End-2026	Oct 2022
Orange LU	End-2030	End-2025
Tango	Active	Jan 2024

3G essentially over. 2G diverges — POST fastest, Orange alive to 2030.

Switzerland

Operator	2G	3G
Swisscom	Apr 2021	End-2025
Sunrise	Jan 2023	Jun 2025
Salt	Dec 2020	Active

2G is gone. Any 2G device in Switzerland is already offline.

Italy

Operator	2G	3G
TIM	End-2029	Oct 2022
Vodafone	Active	Feb 2021
WINDTRE	Active	End-2025
Iliad	Never	Never

Later than most of W. Europe — one of the more permissive markets, for now.

Germany

Operator	2G	3G
Telekom	Jun 2028	Jun 2021
Vodafone	End-2030	Closed
O2	Active	Nov 2021

3G fully closed. Vodafone keeps 2G for IoT to 2030 — Telekom 2028 is the binding date.

Spain

Operator	2G	3G
Movistar	Active	2026
Vodafone	Active	Closed
Orange ES	End-2030	End-2027
Yoigo	Active	Active

2G still broadly available — Orange the only firm closure date so far.

Great Britain

Operator	2G	3G
EE	From 2029	Dec 2024
Vodafone	During 2030	Feb 2024
VM O2	Oct 2025	End-2025
Three	Never	Closed

2G timing varies widely — O2 first, EE last. Depends on the SIM in the device.

United States

Operator	2G	3G
AT&T	Jan 2017	Feb 2022
T-Mobile	Active	Jul 2022
Verizon	Closed	Dec 2022

Migration has already happened — or the device is dark.

Canada

Operator	2G	3G
Bell	Closed	Early 2027
Rogers	Closed	Aug 2025
TELUS	May 2017	Mar 2026

2G closed nationwide; 3G in active shutdown — effectively gone by end-2027.

Singapore

Operator	2G	3G
Singtel	Apr 2017	Nov 2024
StarHub	Apr 2017	Nov 2024
M1	Apr 2017	Jul 2024

A closed chapter. Equipment must be on 4G LTE or 5G.

China

Operator	2G	3G
China Mobile	Limited	Dec 2020
China Telecom	End-2025	Closed
China Unicom	Sep 2023	End-2025

2G unreliable for new deployments. Plan on 4G LTE as the baseline.

Saudi Arabia

Operator	2G	3G
STC	Mixed	Dec 2022
Mobily	Active	Active
Zain	Active	Active

3G shut at STC; Mobily & Zain run both. Verify per operator footprint.

WeCapte v6x

Capture, decode, and transmit vehicle data in real time with a telemetry device built for reliable fleet monitoring

Learn more about the WeCapte v6x →

Not sure how exposed your fleet is?

We'll map your hardware against the shutdown timeline for every country you operate in.

Free Fleet Exposure Assessment →

Help Center

Common questions about CAN, J1939, UDS, OBD‑II, FMS, and VDV 238, and how these standards fit into the OSI model for transit vehicle communication.

Frequently Asked Questions

Does FMS replace J1939 or OBD-II?

No — FMS is a separate, manufacturer-independent interface layered on top of these protocols. It standardizes access to operational data like fuel consumption, engine load, and driver behavior across mixed OEM fleets, making it easier to integrate with depot and scheduling systems, but it doesn't substitute for the underlying diagnostic protocols.

What does the OSI model have to do with vehicle diagnostics?

The OSI model's layers map directly onto how vehicle protocols are structured: CAN covers the physical and data-link layers, J1939's transport layer handles message segmentation, and UDS/OBD-II define the session and application layers where actual diagnostic logic — fault reading, clearing codes, running tests — takes place. Knowing which layer a problem originates from helps teams pinpoint root causes faster.

Which protocol should I use to diagnose an electric bus?

UDS is typically the primary protocol for electric buses, since it supports the deep diagnostics needed for battery management, inverter diagnostics, and thermal control — areas that J1939 and OBD-II don't cover in the same depth.

What is VDV 238 used for?

VDV 238 is a public-transport-specific data standard used mainly in European bus fleets. It provides access to operational signals — door states, passenger counters, HVAC, accessibility features — and acts as a bridge between the vehicle and broader transit systems like dispatching and passenger information.

Why do transit fleets need so many different communication protocols?

Transit fleets rarely run one type of vehicle. A mixed fleet of diesel, hybrid, battery-electric, hydrogen fuel-cell buses, and trams each expose data differently — a diesel bus leans on J1939, an electric bus relies more on UDS, and a tram may use VDV 238 for operational subsystems. No single protocol covers every vehicle type or use case.

Is UDS the same as OBD-II?

No. OBD-II is a constrained, regulatory diagnostic standard for passenger cars and some light-duty vehicles. UDS is a broader, bus-agnostic diagnostic protocol (it can run over CAN, DoIP, LIN, or FlexRay) used for deep diagnostics, fault clearing, and component testing — including in electric buses and battery systems where OBD-II doesn't reach.