Monday morning, the fuel card receipts are spread across your desk, the mileage figures in your fleet system don't quite agree, and a driver has just called to report an engine warning light. You've got vehicles out on the road, a service schedule to protect, and compliance records that need to stand up to scrutiny. The question is how to obtain dependable vehicle information without asking drivers to write down every detail or fitting a separate sensor for every measurement.
That's where CAN bus comes in. It's the vehicle's internal messaging network, allowing electronic control units to share information across a common wiring system. For a UK fleet manager, however, the useful question isn't only what is CAN bus. It's which CAN data your vehicle exposes, where you should connect to it, and whether FMS, a behind-tachograph harness, or OBD-II is the right route for your fleet.
Table of Contents
- What Is CAN Bus in Plain English for Fleet Managers
- How the In-Vehicle Network Works
- The Standards That Run on Top of CAN
- What CAN Bus Data Tells Your Telematics Platform
- Choosing Your Integration Method on UK Vehicles
- Compatibility and Installation Checks Before You Roll Out
- Security, Privacy and Known Limitations
- Recommended Next Steps for Fleetalyse Customers
What Is CAN Bus in Plain English for Fleet Managers
CAN stands for Controller Area Network. The word “bus” describes a shared communication pathway. Rather than running a separate cable from every electronic system to every other system, the vehicle uses a common network so its electronic control units, or ECUs, can exchange messages.
An ECU is a small computer that manages a particular vehicle function. One may control the engine, another the gearbox, another the braking system, while others handle the dashboard, doors, lighting, or body equipment. The CAN bus gives these computers a common way to publish and receive information.
A useful comparison is the vehicle's internal internet, although CAN is much simpler and more tightly controlled. The engine ECU can publish engine speed, the gearbox ECU can use that information to choose a gear, and the dashboard can display a warning when another ECU reports a problem. A telematics device connected in read-only mode can listen to relevant messages and forward selected values to fleet software.
Why the history still matters
Bosch introduced CAN at the SAE congress in February 1986, and it was standardised as ISO 11898 in 1993, as recorded by the CAN in Automation history of CAN technology. The Mercedes-Benz W140 S-Class became the first production car to use CAN by 1991, helping establish the protocol as a foundation for vehicle electronics.
That long history matters because CAN isn't a short-lived telematics feature. It's part of the vehicle architecture that manufacturers, diagnostic equipment makers, bodybuilders, and fleet technology suppliers have built around for decades. In the UK, electronically recorded vehicle data also sits alongside formal compliance activity. The DVSA MOT history service covers cars, motorcycles, and vans in Great Britain since 2005, while HGVs, trailers, buses, and coaches have records in Great Britain since 2018, according to the CAN technology history reference.
Practical rule: CAN bus is the vehicle's internal network. Telematics hardware is the listener and translator, not the network itself.
For a fleet, that distinction prevents a common buying mistake. CAN doesn't automatically provide every signal from every vehicle. The available information depends on the vehicle, its protocol, its gateway settings, and the connection method used.
How the In-Vehicle Network Works
A lorry climbing a hill may need its engine, gearbox, braking system and dashboard to share information at the same moment. The CAN bus provides the shared communication route, while each electronic control unit, or ECU, contributes as a connected node. The engine controller is one node, the ABS controller another, and so on.
The network uses two physical wires, CAN High and CAN Low. They form a differential pair, so the receiving equipment compares the electrical behaviour of both wires rather than relying on one signal alone. That arrangement helps communication remain dependable around alternators, motors, injectors and other sources of electrical noise.
Nodes, messages, and shared access
Each ECU sends short messages when it has information to share. A message may carry engine speed, vehicle speed, coolant temperature or a status such as “fault present”. The network does not require one central computer to ask every ECU a separate question.
CAN is broadcast-based. Every connected node can hear the traffic, then accepts the messages relevant to its own task. The gearbox can use engine-speed information, while a door controller can ignore it. A telematics device uses the same listening principle, collecting selected messages without interrogating each ECU individually.
Every message carries an identifier. It labels the message and helps set its priority. If two ECUs start transmitting together, CAN arbitration allows the higher-priority message to continue. The other ECU waits, then tries again, so the messages do not clash and become unusable.
Why speed and protocol settings matter
The electrical connection alone is not enough. Heavy vehicles commonly use 250 kbit/s, while passenger cars commonly use 500 kbit/s, as described in the Astra Telematics compatibility note. A telematics unit set to the wrong bus speed may see traffic but fail to decode it.
UK implementation is covered by BS ISO 11898, which adopts ISO 11898-1:2015 for road vehicles. The standard describes the data-link layer and physical signalling used for digital information exchange, as outlined in the BS ISO 11898 preview.
For a fleet operator, the practical point is simple. CAN is the vehicle's shared conversation, and the telematics unit is the listener and translator. The device still needs the right connection, bus-speed setting and decoding rules, whether it is fitted through an FMS interface, a behind-tachograph harness or an OBD-II socket. That choice determines which messages the platform can turn into useful fleet data.
The Standards That Run on Top of CAN
A telematics unit can be connected to the correct wires and still fail to produce useful data. The reason is that vehicles use different data languages over CAN. J1939, FMS, and OBD-II are separate standards and profiles, each suited to particular vehicle types and information needs.
J1939 and FMS for commercial vehicles
J1939 is widely used in heavy-duty vehicles, including HGVs, buses, coaches, and plant. It defines how vehicle parameters are identified and arranged, using terms such as PGNs and SPNs. The complete network may contain far more information than a fleet operation requires, so the telematics device needs suitable decoding and access.
FMS, or Fleet Management System, is a fleet-surveillance profile built around J1939 and used by major European truck manufacturers. It commonly expects extended 29-bit CAN identifiers at 250 kbit/s. That arrangement can provide a consistent route to fuel, speed, odometer, engine-hour, and diagnostic signals, provided the vehicle exposes the interface and the device is configured for it.
For an HGV fleet, an FMS connection is often the clearest starting point. It usually avoids tapping directly into the wider vehicle network and presents data intended for fleet applications. Availability still varies by vehicle specification, model, and installation route.
OBD-II for lighter vehicles
OBD-II is the familiar diagnostic standard found on many cars and vans. Its connector can make installation straightforward, but it is not a universal replacement for FMS. The available parameters may be narrower and can vary between vehicle models. A van requiring basic mileage or diagnostic information may suit OBD-II, while a mixed fleet may need different connection methods for different vehicle groups.
| Standard | Typical UK vehicle | Data depth | Best for |
|---|---|---|---|
| J1939 | HGVs, buses, coaches, and plant | Broad heavy-vehicle network data, depending on access and decoding | Detailed commercial-vehicle integration |
| FMS | European HGVs and commercial vehicles with an FMS interface | Standardised fleet-surveillance data | Cross-brand fleet telemetry through a supported port |
| OBD-II | Cars and many vans | Diagnostic and legislated parameter data, varying by model | Quick installation on lighter vehicles |
The practical choice is the standard that exposes the signals your operation needs. UK public-sector procurement guidance treats CAN-bus, OBD, plug-in devices, and tachograph-adjacent telematics as distinct categories, as shown in the Crown Commercial Service RM6315 agreement. That distinction matters when selecting between an FMS interface, a behind-tachograph harness, and an OBD-II socket. Two devices fitted to different vehicles may therefore deliver different data, even when both are described as CAN-compatible.
What CAN Bus Data Tells Your Telematics Platform
CAN data becomes valuable when it changes a fleet decision. A fuel figure can be compared with a transaction record, an odometer can trigger a maintenance task, and a diagnostic code can help a workshop prepare before the vehicle arrives.
Fuel rate and total fuel used can help you compare actual vehicle consumption with fuel-card activity and journey records. That can highlight unexplained discrepancies, excessive idling, or a vehicle that needs investigation. It doesn't prove misconduct on its own, but it gives the transport team a stronger starting point than relying on receipts and driver recollection.
The true odometer reading is useful for mileage-based servicing, vehicle replacement decisions, and checking whether a reported journey matches the vehicle's recorded use. Engine hours add another perspective where mileage isn't enough, particularly for vehicles or equipment that spend long periods working while stationary.
Turning signals into operational action
| CAN bus signal | Fleet decision enabled | Typical standard |
|---|---|---|
| Fuel rate and fuel used | Review consumption, idling, and fuel-card discrepancies | FMS or J1939 |
| Odometer | Set service triggers and verify mileage records | FMS, J1939, or supported OBD-II |
| Engine RPM and load | Coach driving style and investigate excessive revving | J1939 or FMS |
| Pedal position | Build eco-driving feedback and driver scorecards | Vehicle-dependent J1939 or FMS |
| Engine hours | Assess asset utilisation where mileage is incomplete | FMS or J1939 |
| Diagnostic trouble codes | Prioritise workshop checks and maintenance planning | J1939, FMS, or supported OBD-II |
RPM, engine load, throttle position, and related driving signals can support feedback on harsh events, speeding context, excessive revving, and idling. The platform should present these values in a way that helps a manager coach drivers, rather than producing a stream of technical readings.
For a practical explanation of how telematics values are interpreted in fleet operations, see this UK fleet manager's guide to telematics unit data.
Compliance perspective: Accurate mileage and driving-time information from CAN can support DVSA record-keeping, FORS and earned-recognition audits, and the resolution of manual log disputes. It complements tachograph data, rather than replacing the legal records and controls that apply to the operation.
CAN data isn't guaranteed to include every item in the table. Signal availability varies by make, model, year, ECU software, protocol, and connection point. That's why the integration method must be chosen before you promise a particular report to the fleet.
Choosing Your Integration Method on UK Vehicles
There are three practical routes you'll encounter when connecting telematics to UK HGVs, vans, and mixed fleets. Each gives a different balance between installation effort, data depth, access, and vehicle compatibility.
FMS port
For an HGV with a supported FMS interface, start there. The port is commonly a standardised six-pin connection positioned behind a headlight or passenger-side panel, although the exact location depends on the manufacturer and vehicle configuration.
An FMS connection usually provides a manufacturer-approved, read-only selection of J1939 fleet data. That may include fuel, mileage, speed, engine hours, and selected diagnostics. It avoids disturbing the calibrated tachograph and can give installers a clean connection, but it won't necessarily expose every bodybuilder or drivetrain signal.
Behind-tachograph harness
A behind-tachograph harness is an OEM-grade loom connected around the tachograph feed. It can be appropriate when an HGV lacks a usable FMS port or when the operation needs deeper data, such as PTO status, brake-switch information, or more detailed diagnostic trouble codes.
This route needs a competent fitter. The harness must not interfere with the tachograph, its calibration, or its existing wiring. It also needs careful vehicle-specific configuration, because a physically neat installation can still produce poor data if the protocol, bus speed, or identifier mode is wrong.
OBD-II adapter
OBD-II is usually the practical option for cars and vans. It's quick to fit and avoids a more involved loom installation, but the accessible data can be limited to the parameters exposed through the vehicle's diagnostic implementation. On many newer vehicles, the connection is read-only for safety, and access restrictions can vary.
| Fleet situation | Sensible starting point | Main caution |
|---|---|---|
| Supported HGV | FMS port | Data is standardised but selective |
| HGV without suitable FMS access | Behind-tachograph harness | Fitment and tachograph protection matter |
| Van or car | OBD-II | Parameter availability varies |
| Mixed fleet | Vehicle-by-vehicle audit | One cable type won't suit every asset |
The simple decision rule is FMS first for HGVs, behind-tachograph access where deeper data or vehicle compatibility requires it, and OBD-II for vans and cars. Before choosing self-install or hardwired equipment, compare the practical considerations in this guide to self-install telematics versus hardwired installation.
Compatibility and Installation Checks Before You Roll Out
A fleet operator discovers halfway through a rollout that several vans expose different CAN data from the approved integration. The units power up, yet the platform cannot read the required signals. Avoid that delay by checking each vehicle before ordering equipment.
Build the vehicle record
Record the make, model, build year, vehicle category, and Euro emission class for every asset. Group HGVs, vans, plant, passenger cars, trailers, and electric vehicles separately. A mixed fleet rarely has one suitable connection method.
Check the ECU arrangement and tachograph model as well. The drivetrain, body equipment, and tachograph installation can affect which signals are available and where an installer can connect without disturbing existing systems.
Confirm the protocol and connection
Ask the supplier or installer:
- J1939 support: Does the vehicle broadcast the heavy-duty parameters required?
- FMS interface: Is an FMS 2.0 or FMS 3.0 interface present, and has the manufacturer enabled the gateway?
- OBD-II access: Is the connector available, and does it expose the parameters the platform needs?
- Connector location: Can the fitter reach the FMS, diagnostic, or tachograph connection without unnecessary trim removal?
- Existing equipment: Is another telematics unit, camera, or bodybuilder system already reading the CAN network?
A live power connection does not prove compatibility. Check the battery voltage profile, permanent live, ignition sense, fuse location, connector pinout, CAN High and CAN Low polarity, and bus termination. Incorrect wiring or configuration can leave a device powered but unable to decode messages.
For practical fitting guidance, review this van telematics installation best-practice guide.
Protect the vehicle and operation
Before work starts, document the tachograph condition and calibration. Check for PTO equipment, bodybuilder CAN messages, lift systems, refrigeration units, and other additions that may use a separate network.
Electric vehicles and newer vans can have different gateway behaviour or restricted diagnostic access. An older compatibility list may therefore give the wrong answer for a current asset. Use a current vehicle lookup and validate the proposed method on the exact make, model, and configuration.
This audit helps decide whether an FMS connection, behind-tachograph harness, or OBD-II adapter fits each vehicle, rather than forcing one installation approach across the fleet.
Security, Privacy and Known Limitations
Connecting to CAN bus doesn't give a telematics platform magical visibility of every electronic system. It provides access to the messages available at that connection point, provided the device supports the correct protocol and the vehicle allows those messages to be read.
Many fleet installations are read-only, which is the safer default. A read-only device listens to data but doesn't send control commands back into the vehicle network. That still doesn't mean every signal is available. Brake pressure, engine torque, advanced driver-assistance data, and bodybuilder information may be restricted, encrypted, absent from the diagnostic bus, or available only through a bespoke request.
Treat CAN data as vehicle-specific
Signal availability can change between manufacturers, model years, ECU software versions, and vehicle configurations. Some readings update regularly, while others appear only when requested. Older vehicles may expose only a limited set of diagnostic parameters.
That creates a reporting risk. A platform may display a blank value, stale value, or estimated value if the integration hasn't been validated for the specific vehicle. Fleet managers should ask which values are directly read from CAN, which are calculated, and which are unavailable.
Control physical and personal-data risk
The FMS or OBD connector can be physically accessible to drivers, contractors, or third parties. Use tamper-evident seals where appropriate, secure the device firmware, control access to the dashboard, and protect any harness routed behind the tachograph.
CAN-derived driver behaviour data can also become personal data when it's linked to an identifiable driver. Under UK GDPR and relevant driver-monitoring requirements, your policy should state which signals you record, who can access them, why you need them, and how long you retain them. Brief drivers before rollout, explain the purpose, and give managers a consistent process for reviewing disputed events.
CAN bus telematics can provide dependable vehicle-state information, but only within the boundaries set by the vehicle, the interface, the software, and your data policy.
That balanced view is more useful than promising complete visibility. CAN can strengthen maintenance, fuel, mileage, and evidence workflows. It can't guarantee a particular signal across every asset.
Recommended Next Steps for Fleetalyse Customers
A workable CAN rollout begins with an accurate asset list. Don't start by ordering one connector type for the whole fleet. Start by recording each vehicle's make, model, year, vehicle category, ECU arrangement, tachograph model, existing telematics equipment, and the signals your team needs.
Build the scope before selecting hardware
Use four decisions to turn that list into an installation plan:
- Audit every asset. Group vehicles by HGV, van, plant, car, trailer, or EV, then record the technical details that affect compatibility.
- Request a compatibility review. Confirm whether each asset suits an FMS cable, a behind-tachograph harness, or an OBD-II device. Ask specifically about fuel, odometer, engine hours, diagnostic codes, and any driver-behaviour values you intend to use.
- Agree the data scope. Prioritise the information that supports a real decision, such as fuel rate, true odometer, diagnostic trouble codes, and driving behaviour. Treat optional signals as a later requirement unless your workshop or compliance process already depends on them.
- Phase the rollout. Begin with the highest-mileage or most operationally important HGVs, validate the readings, and then extend the approach to vans and mixed assets.
A phased approach gives your team time to check data accuracy, installation time, driver feedback, workshop usefulness, and report consistency. It also prevents a small compatibility issue on one vehicle family from disrupting the entire programme.
Complete the governance checks
Before fitting hardware, involve the people who will use and manage the data. The compliance manager should review the operator licence workflow, tachograph relationship, audit requirements, and driver communications. IT should approve device security, user permissions, firmware management, and retention rules. The workshop should confirm that fault codes, mileage, and service triggers are presented in a form they can act on.
Fleetalyse provides GPS tracking, remote tachograph downloads, driver-behaviour options, and CAN data integration for selected fuel, odometer, and diagnostic information. Its HGV connection routes include FMS cable interfaces and behind-tachograph harnesses, while lighter vehicles can be assessed for suitable plug-in equipment.
The final output should be a vehicle-by-vehicle schedule, not a generic promise that “CAN is supported”. It should state the connection method, expected signals, installation owner, validation checks, driver briefing, and the person responsible for approving each asset.
If you're planning a CAN bus rollout, visit Fleetalyse to discuss your HGV, van, or mixed-fleet requirements. Their team can help assess suitable FMS, behind-tachograph, or plug-in connections and align CAN data with tracking, tachograph, maintenance, and compliance workflows.