CAN Bus and OBD Fleet Data: A Practical SA Guide

Published: 30 June 2026
Updated: 29 October 2026

CAN bus and OBD fleet data is the stream of engine, drivetrain and fault information your vehicles already broadcast every second. For South African fleet operators it is one of the most underused assets in the business. Your trucks report coolant temperature, oil pressure, fuel use, transmission temperature and diagnostic trouble codes, yet many fleets only look at location and speed. Used properly, this data tells you which vehicle is heading for a breakdown weeks before the dashboard warning light comes on.

This guide explains what CAN bus and OBD-II are, how heavy vehicles differ from bakkies and light commercials, which parameters actually predict failures, how to prioritise fault codes, and how to turn diagnostic data into maintenance work orders rather than another unread report. For the wider picture of connecting tracking and vehicle data to your business systems, see our pillar guide to telematics integration.

What Is CAN Bus and OBD-II in Fleet Vehicles?

CAN bus (Controller Area Network) is the communication network inside a modern vehicle. It lets the electronic control units talk to each other without dedicated wiring between every component. In a typical heavy truck, the CAN bus links:

• the engine control module
• the transmission controller
• the anti-lock braking system
• the instrument cluster
• the exhaust aftertreatment system (DPF and AdBlue/DEF on newer engines)
• the telematics unit

Every time the engine adjusts fuel injection, the gearbox shifts or the ABS intervenes, that event is visible on the network.

OBD-II (On-Board Diagnostics II) is the standardised diagnostic interface that gives external tools access to vehicle data. It was originally designed for emissions testing, but it has become the common connection point for diagnostic tools and many telematics devices on light vehicles.

Heavy vehicles and light vehicles speak different dialects

Many SA fleets run a mix of prime movers, rigid trucks and bakkies, so it helps to know the difference:

• Heavy commercial vehicles generally use the SAE J1939 protocol on the CAN bus. J1939 defines standard parameter groups for things such as engine temperatures, fluid pressures and transmission data, which means a telematics device can read the same core parameters across different truck brands.
• Light commercials and bakkies generally use the OBD-II diagnostic standard. It provides live engine data, stored and pending fault codes, freeze-frame data captured at the moment a fault occurred, and vehicle identification data.

A good telematics device and platform will read both and present them in one view, so your workshop does not have to juggle two systems for one fleet.

How CAN Bus Telematics Works

A telematics unit either plugs into the diagnostic port or connects directly to the CAN bus wiring. From there:

1. Capture: the device reads CAN messages continuously.
2. Processing: raw signals are converted into usable metrics such as litres per 100 km, engine load or coolant temperature.
3. Transmission: data is sent over the cellular network, or stored on the device and sent later where there is no signal.
4. Analysis: your fleet platform compares readings with each vehicle's baseline and with alert thresholds.
5. Action: alerts go to the right person, and ideally create a maintenance task automatically.

A common surprise is that the hardware already in your trucks captures far more than your subscription shows you. Many devices read full engine data, but basic tracking packages only surface location, speed and ignition status.

The Parameters That Predict Failures

You do not need hundreds of data points to get value. Start with the parameters that give early warning of expensive failures.

| Parameter | What a worrying trend can indicate | Typical response |
|---|---|---|
| Coolant temperature | Cooling system losing efficiency: degraded coolant, sticking thermostat, fouled radiator, water pump or fan clutch wear | Inspect cooling system before summer peaks and long climbs |
| Engine oil pressure | Bearing wear, oil pump wear, wrong viscosity or fuel dilution | Oil analysis and inspection; stop the vehicle on a critical low |
| Oil temperature | Oil breakdown or heavy duty cycles | Review service interval and oil grade |
| Transmission oil temperature | Clutch slip, heavy load cycles, cooler problems | Check fluid condition and loading practices |
| Intake manifold pressure and temperature | Air filter restriction, turbo or intercooler issues | Filter inspection, especially in dusty mining environments |
| Aftertreatment status (DPF, AdBlue/DEF) | Failed regenerations, sensor faults, dosing problems | Workshop visit before derate occurs |
| Battery voltage | Charging system or battery failure | Test alternator and battery |
| Fuel rate and level | Theft, leaks, injector problems or poor driving | Reconcile with fuel cards and trip data |

Read trends, not single readings

The absolute figure matters less than the trend for that specific vehicle under similar conditions. A coolant reading that is normal for a loaded truck climbing Van Reenen's Pass on a hot afternoon may be a concern for the same truck idling at a Gauteng depot. Effective interpretation means:

• Establishing a baseline for each vehicle under typical routes and loads, using at least 30 days of data.
• Watching the direction of travel. A truck that used to cruise at a stable temperature and now runs consistently several degrees hotter under the same conditions is losing cooling efficiency.
• Adding context. Was the vehicle climbing, idling, loaded or empty when the reading occurred?
• Cross-checking parameters. Rising coolant temperature with normal oil pressure points towards a cooling issue. The same temperature rise with falling oil pressure suggests a more serious internal engine problem.

Always use the engine manufacturer's specifications for normal operating ranges and alarm thresholds rather than generic figures.

Recognise the classic patterns

• Gradual creep: a slow rise in temperature or slow fall in oil pressure over weeks, usually wear or degradation. Schedule an inspection.
• Sudden spikes: sharp jumps, often on gradients, which can mean coolant loss, a stuck thermostat or fan failure. Act quickly.
• Hunting: readings swinging between normal and high, which can point to air in the cooling system, a failing thermostat or the early stages of head gasket trouble.

Vehicle Fault Code Monitoring for SA Fleets

Diagnostic trouble codes are the early warnings your vehicles give you for free. Heavy vehicles report faults through J1939 diagnostic messages, while light vehicles use the familiar OBD-II codes. For example, a generic P0171 code means the engine management system has detected a lean fuel mixture on bank 1. It might come from an air leak, a failing sensor or a fuel delivery problem. Caught early it is usually a modest repair. Ignored, it can lead to rough running and damage to other components.

Pending codes are your best opportunity

On OBD-II vehicles, pending codes represent faults the control unit has detected but not yet confirmed or shown on the dashboard. Many operators only react to active codes and miss this window entirely. Configure your platform to capture pending codes and review them on a schedule.

Prioritise codes so alerts do not get ignored

The fastest way to make a team ignore diagnostics is to send every alert to everyone. Classify codes by severity:

Critical - stop safely and investigate:

• oil pressure warnings
• coolant over-temperature
• brake system faults
• steering system faults
• transmission failure codes

High priority - schedule within 48 hours:

• aftertreatment faults (DPF, AdBlue/DEF)
• turbocharger anomalies
• fuel system pressure faults
• cooling fan failures

Monitor and schedule at next service:

• sensor calibration codes
• minor emissions deviations
• pending codes without symptoms
• intermittent communication faults

South African conditions that drive fault codes

• Dust and heat load up air filters and cooling systems, particularly on mine and gravel roads.
• Fuel quality problems can trigger fuel system and injector faults.
• Overloading stresses drivetrains, brakes and suspensions.
• Long gradients and altitude changes between the coast and the Highveld put sustained load on cooling systems and gearboxes.

Over time, fault code history across the fleet shows patterns: a model with a recurring sensor problem, a route that consistently produces cooling faults, or a driver whose vehicles throw more drivetrain codes than others.

Using CAN Bus Data Beyond the Workshop

Fuel management and theft prevention

Engine-level fuel rate and tank level data can be compared with fuel card transactions and tank dip readings. When a fuel card shows a full fill but the tank level barely moves, or the level drops while the vehicle is parked, you have a lead to investigate. Track litres per 100 km by vehicle, route and driver, idling time and fuel used while stationary.

Driver behaviour

Harsh braking, aggressive acceleration and over-revving all show up in the data. That gives coaching conversations an objective basis: rather than vague feedback, you can show a driver how their harsh braking events per 100 km compare with the fleet average, and track improvement. Our guide to AI fleet management covers how pattern analysis makes this coaching more targeted.

Condition-based maintenance

Fixed service intervals were designed for fleets with no real-time engine information. With CAN bus data, you can adjust intervals to actual duty cycles. A truck running light loads on good roads may justify longer oil change intervals within the manufacturer's guidance, while a tipper on dusty mine roads may need shorter ones. Our guide to preventive maintenance for SA fleets explains how to combine time, kilometre, engine hour and condition triggers.

From Data to Work Orders: Making It Actionable

Data that nobody acts on creates work instead of saving it. The value appears when diagnostic data drives your maintenance process automatically.

A practical diagnostic-driven workflow looks like this:

1. Define thresholds for each critical parameter and code category.
2. Automate alerts to the driver and fleet controller for critical events, and to the workshop for scheduled work.
3. Create the job automatically with the code, readings, location and operating conditions attached.
4. Check parts for the likely repair before the vehicle arrives.
5. Schedule intelligently around trips and workshop capacity.
6. Flag roadworthiness where a fault affects brakes, steering or other safety systems so the vehicle is not dispatched until cleared.
7. Track outcomes so you know whether the intervention prevented the predicted failure.

This is where fleet management software that combines telematics data with maintenance, trips and compliance records earns its keep. In T-ERP, a critical fault can open a maintenance job against the vehicle, while service plans run on kilometres and engine hours and the vehicle's history builds a timestamped trail for audits. That trail matters for RTMS accreditation, where operators need to show systematic vehicle maintenance, and for mining work, where trackless mobile machinery maintenance records are scrutinised under the Mine Health and Safety Act framework.

If you want to see how this would map to your vehicle mix, you can schedule a consultation with our team.

Getting Started: A Four-Step Rollout

Step 1: Audit your current capability. Ask your provider which parameters are captured, how fault codes are displayed, whether historical engine data is stored and what integration options exist for maintenance systems.

Step 2: Start with high-value vehicles. Begin with long-haul prime movers, haul trucks or vehicles on critical contracts, where a breakdown hurts most.

Step 3: Establish baselines. Collect at least 30 days of data per vehicle covering normal temperatures, pressures, fuel use by route and load, and which fault codes appear and clear without intervention.

Step 4: Configure a small set of meaningful alerts. Start with critical temperature and oil pressure alerts, active powertrain and brake codes, and aftertreatment failures. Add more only once the team is reliably acting on the first set.

Common Challenges and Mistakes

• Older vehicles with limited data. Older trucks may broadcast fewer parameters. Aftermarket sensors, such as fuel flow meters or gearbox temperature sensors, can fill critical gaps.
• Connectivity in remote areas. Choose devices that store and forward data, and consider depot Wi-Fi downloads or satellite options for vehicles that spend long periods out of coverage. Cross-border routes add further recovery risk, so pre-trip fault scans matter more.
• Data overload. You do not need high-frequency logging of every parameter. Sensible sampling captures trends without flooding your systems.
• Ignoring pending codes and only reacting once a warning light is on.
• Missing context, such as a fault code recorded without the operating conditions at the time.
• One threshold for every vehicle. An older high-kilometre truck behaves differently from a new one; thresholds should reflect age and duty cycle.
• Overreacting to single readings. One high reading is a data point; a sustained pattern is a problem.
• Driver resistance. Frame monitoring around safety and fairness. Data that catches a brake fault early, or clears a driver of a false accusation, builds trust.

Conclusion

CAN bus and OBD fleet data is already flowing from every modern vehicle you run. The operators who benefit are those who capture the right parameters, read trends against each vehicle's baseline, prioritise fault codes sensibly and connect diagnostics directly to maintenance work orders.

Start with the parameters that predict expensive failures: coolant temperature, oil pressure, transmission temperature, aftertreatment status and fault codes, including pending codes. Establish baselines, set a small number of meaningful alerts, and make sure every alert has an owner and a workflow behind it. Do that, and diagnostic data becomes a maintenance plan rather than a report nobody reads.

Sources

• Road Transport Management System (RTMS) - self-regulation scheme that expects documented vehicle maintenance practices
• Road Traffic Management Corporation - national road traffic regulator for SA

---

The information in this article is for general guidance only. Regulations and requirements may change - always verify current requirements with the relevant South African regulatory authority.

Frequently Asked Questions

What is the difference between CAN bus and OBD-II for fleet vehicles?

CAN bus is the internal network that lets a vehicle's electronic control units share data. OBD-II is the standardised diagnostic interface that gives external tools access to vehicle data, mainly on light vehicles. Heavy trucks generally use the J1939 protocol over CAN bus, which offers more detailed heavy-vehicle parameters. A good telematics platform reads both and shows them in one view.

What CAN bus data should a fleet monitor first?

Start with coolant temperature, engine oil pressure, transmission oil temperature, aftertreatment status, battery voltage, fuel rate and fault codes, including pending codes. These give the earliest warning of expensive failures. Review them as trends against each vehicle's own baseline rather than as single readings, and use the manufacturer's specifications for alarm thresholds.

Can I add CAN bus monitoring to older trucks?

Usually, but with limits. Older vehicles may broadcast fewer parameters, so some data will be missing. Aftermarket sensors such as fuel flow meters, gearbox temperature sensors or brake monitoring can fill critical gaps. Ask your telematics provider which parameters are available for each specific make, model and year in your fleet before deciding what to retrofit.

How often should diagnostic data be reviewed?

Critical fault codes and alarms should trigger immediate alerts with same-day action. Trend data such as coolant temperature and oil pressure is best reviewed weekly per vehicle. A monthly fleet-wide review comparing every vehicle against its baseline helps catch slowly deteriorating units and recurring faults by model or route before they cause breakdowns.

How does CAN bus data help with RTMS compliance?

RTMS accreditation expects operators to show systematic vehicle maintenance and safety management. Diagnostic logs provide timestamped evidence of when faults were detected, how quickly they were handled and what was done. When that data feeds directly into work orders and vehicle history, you have an audit trail ready for RTMS assessments and customer audits.

My system only tracks location. How do I get engine data?

Ask your provider whether your installed devices already read CAN bus or OBD data that your subscription does not display. Many devices capture full engine data but basic packages hide it. If the hardware supports it, a software upgrade may be enough. If not, consider a device that reads full diagnostics and integrates with your maintenance system.