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.

Capte Editorial

Min Read

Close-up of a modern transit bus dashboard showing multiple digital displays with diagnostic and vehicle data readouts.

Key Takeaways

Rail vehicles run IEC 61375, not CAN — a telematics approach assuming CAN everywhere misses half a mixed fleet.
OBD-II covers only light-duty vehicles (shuttles, vans); a 40-ft bus uses HD-OBD instead, via J1939-73.
For electric buses, the data barrier is contractual access, not technical capability — VDV 238 makes that access requirable in procurement.

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 while the data available through the vehicle's communication systems remains incomplete, inconsistent or difficult to interpret.

The challenge isn't a lack of data. It's the ecosystem of communication protocols that governs how systems inside a bus or tram exchange information — and, increasingly, the question of who is contractually entitled to read them. As fleets become more electrified, more connected and more software-driven, understanding these standards is essential for reliable operations, efficient maintenance and informed procurement.

This guide covers the standards you will actually meet in a transit fleet — CAN and CAN FD, J1708/J1587, J1939, UDS, OBD-II and HD-OBD, FMS, VDV 238, and the rail and charging standards that sit alongside them — and where each one lands in the OSI reference model.

Why Transit Fleets Face Extra Complexity

Transit operators rarely run a single type of vehicle. A typical fleet spans multiple manufacturers, several hardware generations and a range of propulsion technologies — diesel, hybrid, battery-electric, hydrogen fuel-cell, trolleybus and light rail.

Each brings its own communication behavior:

A diesel bus exposes engine, after treatment and drivetrain data through J1939, with fault codes delivered as J1939-73 DM1 and DM2 messages.
An older bus still in mid-life service may run SAE J1708/J1587 rather than CAN — a serial standard that predates J1939 and remains common on pre-2007 vehicles.
A battery-electric bus broadcasts its high-voltage data — state of charge, cell voltages, pack temperature, contactor state — cyclically on CAN, but usually through proprietary or manufacturer-extended parameter groups rather than published ones.
A tram or light-rail vehicle does not primarily use CAN at all. Rail vehicles are built around IEC 61375, the Train Communication Network, using MVB, WTB or an Ethernet Train Backbone. CAN appears only inside individual subsystems.

That last distinction matters more than it looks. Bus and rail assets in the same depot speak fundamentally different network families, and a telematics approach that assumes CAN everywhere will silently miss half the fleet.

Isometric technical illustration showing data communication protocols for diesel, hybrid, electric, hydrogen fuel-cell buses, and light rail systems.

The Major Standards You'll Encounter

CAN and CAN FD

Controller Area Network is the foundation of almost every modern road vehicle. Defined in ISO 11898-1 (data link and physical signalling) and ISO 11898-2 (high-speed transceiver), it specifies bit timing, arbitration, identifiers and error handling — and nothing about what the messages mean.

Classical CAN frames use either an 11-bit standard identifier or a 29-bit extended identifier, with an 8-byte payload. Controllers described as CAN 2.0B handle both formats; 2.0A controllers handle only the 11-bit form. J1939 requires the 29-bit extended format, running at 250 kbit/s under J1939-11/-15, or 500 kbit/s under J1939-14.

CAN FD raises the payload to 64 bytes and accelerates the data phase, which is why it is increasingly common in electric drivetrains and battery systems where the classical 8-byte frame became a real constraint.

CAN covers OSI layers 1 and 2 only. Everything above is the job of a higher-layer protocol.

J1939

Built on CAN, J1939 is the dominant standard for heavy-duty road vehicles. It is best understood as the dictionary that tells you what each CAN message means. The parts that matter operationally:

Key SAE J1939 standard parts and their roles
Part	Role
J1939-11 / -15 / -14	Physical layer (250 kbit/s; -14 defines 500 kbit/s)
J1939-21	Data link and transport protocol (BAM and connection-mode), segmentation and reassembly
J1939-31	Network layer — bridges and routers between segments
J1939-71	Vehicle application layer — the PGN and SPN definitions themselves
J1939-73	Diagnostics — DM1 active faults, DM2 stored faults, SPN/FMI fault coding, memory access via DM14–DM18
J1939-81	Network management and address claiming

‍

J1939-73 is the part most often overlooked, and it explains a common point of confusion: heavy-duty vehicles already have a native diagnostic layer. Fault reading on a diesel bus does not require UDS.

One caveat worth stating plainly: J1939's standardisation is real but partial. Manufacturer-specific PGNs and proprietary parameters are widespread, and OEM-specific fault definitions sit alongside the standard SPN/FMI set. J1939 gets you consistent access to the common core, not to everything.

Unified Diagnostic Services (UDS)

UDS (ISO 14229) is a session-based, request/response diagnostic protocol. A tester requests, an ECU answers. It handles diagnostic session control, security access, fault code reading and clearing, data-identifier reads, routine control, actuator tests and ECU reprogramming.

It is transport-agnostic by design:

CAN — ISO 14229-3, over ISO 15765-2 (ISO-TP)
Automotive Ethernet — ISO 14229-5, over DoIP (ISO 13400)
FlexRay — ISO 14229-4
LIN — ISO 14229-7
K-Line — ISO 14229-6

UDS and J1939 are not subsets of one another. They are independent standards solving different problems: J1939 broadcasts operational data continuously to whoever is listening; UDS answers targeted diagnostic questions on demand. They do interact — many heavy-duty ECUs implement UDS services over J1939 transport, and ISO 27145 (WWH-OBD) deliberately bridges the two by carrying J1939-style SPN/FMI fault data inside UDS services — but that is layering, not nesting.

For transit fleets, UDS is a workshop and depot-tooling protocol. It is how a technician runs a component test or reflashes a controller. It is not how continuous operational data reaches your telematics platform.

OBD-II and HD-OBD

This distinction causes more wasted effort than any other on this list.

OBD-II (SAE J1979 / ISO 15031-5, over ISO 15765-4) is the emissions diagnostic mandate for light-duty vehicles — in the US, those at or below 14,000 lb GVWR. In a transit organisation, that means cutaway shuttles, paratransit vans, supervisor vehicles and maintenance trucks. It is not present on a 40-foot bus.

HD-OBD is the heavy-duty equivalent, required by CARB and phased in from the 2010 model year. It is built on J1939-73, so heavy-duty emissions diagnostics arrive as J1939 messages, not as OBD-II modes.

WWH-OBD (ISO 27145) is the world-harmonised approach used under Euro VI. This is the one case where the "OBD over UDS" description is accurate — WWH-OBD uses UDS services to carry the diagnostic payload.

Fleet Management System Standard (FMS)

FMS is a manufacturer-independent interface originating with European truck and bus OEMs. Critically, it is a read-only gateway exposing a defined subset of J1939 parameter groups on a separate connector — deliberately isolated from the vehicle's control network so third-party equipment cannot write to it.

It provides consistent access to fuel consumption, engine load, vehicle speed, odometer, axle weights and driver-behaviour signals. Bus-FMS, the transit-specific extension, adds signals that matter in service: door status, stop request, kneeling, and bus-specific state information.

FMS is the clearest genuine subset relationship in this article: FMS is a curated slice of J1939, not a separate protocol family.

VDV 238

VDV 238:2023, Vehicle data in buses in public transport, is a recommendation from the Verband Deutscher Verkehrsunternehmen, the German association of public transport operators.

It exists for a specific reason. The FMS bus dataset was designed around combustion vehicles and does not cover what an electric bus operator needs to see — state of charge, cell-level data, charging behaviour, thermal management, energy consumption. Meanwhile OEMs have had a commercial interest in keeping raw CAN data closed and steering operators toward their own native monitoring platforms.

VDV 238 addresses this by requiring that a defined dataset be accessible directly from the vehicle's CAN bus, giving operators a standards-based position in procurement rather than a negotiation with each manufacturer. It is best described as an emerging standard increasingly written into European tenders, rather than a universally deployed one.

Note the scope boundary: VDV 238 concerns vehicle data. Passenger information, ticketing and on-board IT integration are the domain of IBIS-IP (VDV 300 series) and the ITxPT framework, which run over IP and Ethernet rather than CAN.

The Charging and Depot Layer

For electrified fleets, vehicle protocols are only half the picture. Depot operations also depend on ISO 15118 for vehicle-to-charger communication, OCPP between chargers and back-office systems, and SAE J3105 or OppCharge for pantograph and opportunity charging. Energy planning that ignores this layer will not survive contact with a real depot.

Architecture diagram showing CAN 2.0A/2.0B as the physical layer feeding J1939, UDS, and OBD-II at the application layer, then J1939 and VDV 238 at the fleet-operations layer, connecting a transit bus to a fleet management platform.

Mapping to the OSI Reference Model

The OSI model does not define vehicle communication — it is a reference model that these standards can be mapped onto. Used that way, it is a genuinely useful diagnostic tool.

Vehicle communication layers, components, and typical failure symptoms
Layer	What lives here	Typical failure symptom
1 — Physical	CAN transceivers, twisted pair, termination, bit timing, bus speed (ISO 11898-2, J1939-11/-14/-15); J1708 serial	Intermittent faults, dropped frames, bus-off conditions, missing termination
2 — Data Link	CAN arbitration, identifiers, framing, error handling (ISO 11898-1); J1939-21	Bus errors, priority inversion, unexpected frame loss under load
3 — Network	J1939-31 bridging and routing; gateway segmentation between vehicle and telematics networks	Data present on one segment but not another
4 — Transport	J1939-21 transport protocol (BAM, connection-mode); ISO 15765-2 for UDS and OBD-II; DoIP	Truncated multi-frame messages, incomplete DTC lists, misread parameters
5–7 — Session / Presentation / Application	J1939-71 parameter definitions; J1939-73 diagnostics; UDS sessions, security access and routines; J1979 OBD-II modes	Blocked security access, unsupported services, faults readable by OEM tooling but not by yours

Layers 5 and 6 are largely vestigial in vehicle networking; in practice, session management is folded into the application-layer protocol itself.

Isometric illustration of a transit depot with multiple bus models and a light-rail vehicle parked near charging stations and maintenance garage bays, representing a mixed-OEM fleet sharing one depot.

Why This Matters in Practice

Diagnosing communication failures. Knowing which layer a symptom originates from is the difference between chasing a wiring fault and chasing a security-access permission. A truncated fault list is a transport-layer problem. A bus-off condition is physical.

Supporting electrification. The constraint on electric bus data is rarely technical capability — it is access. Operational battery data is broadcast on CAN, but usually in proprietary parameter groups whose definitions are not published. The question to ask an OEM during procurement is not "does it have CAN?" but "which parameter groups are documented, and are they contractually available to us?" VDV 238 exists to make that question answerable.

Ensuring reliable data flow. Transport-layer behaviour determines whether multi-frame diagnostic messages arrive intact. Poor segmentation handling produces incomplete data that looks like a vehicle fault.

Driving maintenance workflows. Application-layer protocols determine how technicians read faults, run tests and clear codes — and those differ meaningfully between a J1939-73 diesel bus and a UDS-based electric drivetrain. Consistent workflows across a mixed fleet require tooling that abstracts the difference.

What This Means for Transit Operations

No single protocol delivers everything a fleet needs. A realistic operational picture combines J1939 for drivetrain and emissions, UDS for deep diagnostics and reprogramming, FMS or VDV 238 for standardised operational data, IBIS-IP or ITxPT for on-board IT, IEC 61375 for rail assets, and OCPP and ISO 15118 for charging.

The practical implication is that protocol strategy belongs in procurement, not just in the workshop. Data access is far cheaper to secure in a tender than to negotiate after delivery.

How Capte Supports Transit Fleets

Operators do not need to master every standard to benefit from the data behind it — but they do need tools that interpret these standards consistently across a fleet that was never designed to be uniform.

At Capte we work across CAN and CAN FD, J1708/J1587, J1939, UDS, OBD-II and HD-OBD, FMS and VDV 238, translating raw vehicle data into operational insight that supports maintenance planning, dispatching and electrification strategy.

Navigating the Challenge

These standards are complex, but the complexity is navigable and the payoff is concrete: fewer unplanned failures, better-informed procurement, and a fleet that reports on itself in a language your teams can actually read.

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 →

See how a non-invasive CAN bus connection protects your fleet

Capte's CAN-Guard Probe reads CAN bus data without splicing a wire — avoiding the warranty and security questions a wired connection raises. Contact Capte to talk through your fleet's setup.

Ask Capte →