J1939 to Fleet Portal: How Telematics Data Travels

A fleet manager opens a portal and sees a row per machine: operating hours, fuel used, a location, an alert or two. An engineer standing at that machine sees a CAN bus carrying parameter groups at fixed intervals, a gateway that samples some of them, and a modem that uplinks whatever survived. Both are looking at the same machine. Neither is looking at the same data.

What happens in between decides whether the numbers in that row can be billed against, scheduled against, or used to settle a dispute. The path has three hops and one standard, and the standard governs only the last hop. Why these networks matter commercially, and what is arriving beside J1939 on these machines, belongs to vehicle networks in construction and mining equipment. This article stays inside the data path.

What the Machine Actually Says

Parameter Groups, Not Signals

SAE J1939 is the application layer that heavy off-highway and commercial diesel machines run on top of CAN. Two structural facts explain most of what follows.

First, J1939 uses the 29-bit extended CAN identifier rather than the 11-bit one, and that identifier is not an arbitrary label. It encodes a priority, a source address for the controller that sent the message, and the Parameter Group Number, the PGN, that says what the message contains.

Second, data is organised into parameter groups rather than individual signals. A parameter group is a fixed layout of related values that travel together in one message. Inside it, each value has a Suspect Parameter Number, the SPN, and its own definition covering how the raw integer on the wire scales into an engineering value. Engine speed, percent load, coolant temperature, instantaneous fuel rate and total engine hours each have an SPN, and several of them share a group.

Most of this traffic is broadcast rather than requested. Controllers put their groups on the bus at intervals set by the standard, fast for values another controller must act on, slow for accumulators such as total hours and total fuel. A listener joining mid-shift gets the fast groups almost immediately and waits longer for the slow ones, which is worth knowing before anyone concludes from a short capture that a parameter is missing. Trouble codes ride the same mechanism through their own message types, so a fault reaches a portal without anyone querying the machine.

Bit rate is commonly 250 kbit/s on established machine platforms and 500 kbit/s where the traffic justifies it, the two speeds the SAE physical-layer documents in the family are written for, but neither is the constraint that matters downstream. That one is set by the gateway.

Why the Bus Looks Similar across Brands

Machines from different manufacturers speak a similar language because none of them designed it: engine, transmission and aftertreatment suppliers ship J1939 interfaces and the machine builder integrates around them. That is what makes a third-party telematics unit possible at all, and also its limit. Standard parameters travel between brands; manufacturer-specific groups, where much of the hydraulic and implement data lives, do not.

The Off-Road Family Member

J1939 is a family of documents rather than one, and the off-road document in it, SAE J1939-02, carries an agricultural and forestry machinery title rather than an earth-moving one. Its existence is still the part worth carrying: the off-road world did not invent a separate protocol, it profiled the one the trucks already used. A bench built for commercial vehicle work therefore transfers to these machines with less rework than teams expect.

The Gateway Hop, Where Data Becomes a Record

Something on the machine turns broadcast frames into records. Call it the gateway, factory-fitted or added later. It does four things, and each is a place where a number changes.

It selects. Only parameters on its list are uplinked; the rest of the bus is seen and discarded. A parameter that was never selected does not exist downstream, and no portal configuration will recover it.

It samples. Bus rate and uplink rate differ by orders of magnitude, so a value that moves continuously gets reduced to one number per reporting period. Whether that number is the last sample before the uplink, a mean over the interval, or a peak is a design decision inside the gateway, rarely documented where the fleet team can read it. Two gateways with identical inputs and different reduction rules publish different numbers, and neither is malfunctioning.

It derives. Idle time, utilisation, load factor and distance travelled are usually not broadcast as such. They are computed from raw parameters plus a rule about what counts as idle or working. Two suppliers can publish different idle percentages from the same feed and both be right about their own definition.

It converts and timestamps. Every SPN is a raw integer that becomes an engineering value through its resolution and offset; applied twice, or not at all, the result is a wrong number that still looks plausible. Timestamps are the same class of problem. A record can be stamped from the gateway’s clock, from a satellite fix, or by the server on arrival, and records buffered through a connectivity gap may or may not carry the time they were captured.

This hop is where a programmable telematics unit earns its place. A closed unit reports what its supplier chose, in the form the supplier chose; a programmable one lets an engineering team see the frames the gateway saw. Our AutoPi TMU CM4 deep dive walks through one device of that class, a Linux computer with raw frame access through SocketCAN and room to run decoding logic on the machine; the product page carries its ratings. The uplink half of this hop is connectivity engineering of the kind our industrial IoT practice covers. That is a category point, not a portal recommendation: whether a given unit publishes into a standardised fleet API is a question for its supplier.

The Portal Level, and What the Standard Does Not Cover

ISO/TS 15143-3:2020, titled “Earth-moving machinery and mobile road construction machinery, Worksite data exchange, Part 3: Telematics data”, is the specification the industry usually calls AEMP 2.0, after the Association of Equipment Management Professionals. A third-party explainer, flagged as such in the references, describes it as a common data format that lets a mixed fleet be retrieved into a single portal, covering more than twenty parameters including machine serial number, location, operating hours and fuel used.

The problem it solves is real: without it, a contractor running machines from four manufacturers gets four portals, four schemas and no reliable way to compare a number in one against the same number in another. With it, one API contract covers the yard.

What stays upstream of the standard matters just as much, and it is the part that goes missing in procurement conversations. Its title places it at the worksite data exchange layer, and the record it describes is a server-side artefact. Everything that happened before the record existed remains with the machine and gateway implementation:

• which parameter group on the bus a value came from,
• whether an uplinked value is an instantaneous sample, an average, or the last reading before transmission,
• how a derived field such as idle time was computed, and what clock produced the timestamp,
• what became of records buffered through a loss of connectivity.

A portal record carries none of that lineage. Two feeds can disagree about the same machine on the same day with nothing at portal level to say which is right, not because the exchange format failed at its job, but because the disagreement lives in a layer it was never positioned to reach.

Validating the Path End to End

Treating the portal as the measurement is the mistake. The measurement happens on the bus; the portal shows a report about it, several transformations downstream. Checking one against the other is not complicated. It is simply rarely done.

1. Establish ground truth on the bus. Capture while the machine runs a known cycle. Decoding J1939 on top of CAN is ordinary bench work, and the PicoScope automotive protocol decode post covers frame-level J1939 decode alongside the other vehicle buses. Record wall-clock start and stop against the same reference you will use to query the portal.
2. Get everything onto one time base. Portal record time, gateway sample time and bus frame time are three clocks unless somebody deliberately made them one. Where a timestamp is applied decides what it can prove, and multi-bus capture and timestamp correlation works through the classes of timestamp and how a common time base gets built.
3. Compare accumulators before instantaneous values. Total hours and total fuel are monotonic counters, so the delta across a window is comparable end to end without any assumption about sampling. If the deltas agree and the instantaneous values do not, the discrepancy is sampling or derivation, not decoding.
4. Then compare something that moves. Pick a parameter that changes within the reporting interval. Disagreement is expected here, and its size and sign tell you what the gateway is really doing to the value, which no datasheet provides.
5. Force the edge cases. Interrupt the uplink and restore it, and see whether the portal backfills, reorders or silently drops. Restart the machine mid-window and see whether counters reset. Run the cycle close to a derivation threshold and see which side the idle classifier chooses.

Discrepancies almost always trace back to scaling, an averaging window, a derivation rule, a timestamp source, or a buffered backlog. None is exotic, and all are invisible from the portal alone.

Why This Lands Differently in India

Contractors and miners rarely run a single manufacturer’s equipment, which is why the CII-BCG report on the sector argues that equipment players will need interoperable, API-enabled platforms that work across mixed fleets (Source: CII-BCG, Pressing the Throttle, July 2026, p. 25). The same report tells Indian manufacturers to treat digital capability “as part of the machine, not an optional add on”, naming reliable sensors and connectivity among the things that phrase has to mean (Source: CII-BCG, Pressing the Throttle, July 2026, p. 25).

The report does not discuss test instrumentation, so what follows is our inference rather than its claim: reliability of that kind is established by measurement, not by design intent. A mixed fleet raises the stakes on this seam, because the comparison the standard enables is only as trustworthy as the least-validated gateway in the yard. A machine whose feed is quietly wrong does not look wrong. It looks like a machine performing differently from its neighbours, and it gets managed that way until somebody checks the bus.

Where GSAS Fits

GSAS Micro Systems is an engineering partner, and on telematics work the useful contribution sits at the seam rather than at either end. We help teams put a capture on the machine’s bus, establish the ground truth a portal record ought to agree with, align the clocks so the comparison means something, and characterise what a gateway is doing to a parameter before it becomes a row in a report. That is bench work during development and field work during commissioning, on the same evidence. Our construction and mining practice covers the vehicle-network and validation side of these machines, and application engineering runs from our offices in Bengaluru, Hyderabad, Chennai, Pune, Mumbai and Delhi NCR.

Tell us which parameters your portal publishes and which machines they come from when you request a quote, and the reply will be a capture and correlation plan for the path in between.

References

• ISO/TS 15143-3:2020, Earth-moving machinery and mobile road construction machinery, Worksite data exchange, Part 3: Telematics data (punctuation adapted house-style), ISO.
• SAE J1939-02, Agricultural Forestry Off-Road Machinery Control and Communication Network (title per the DOI record; punctuation adapted house-style), DOI 10.4271/j1939-02_202311.
• SAE J1939-21, Data Link Layer; SAE J1939-71, Vehicle Application Layer; SAE J1939-11 and J1939-15, Physical Layer, 250 Kbps; SAE J1939-14, Physical Layer, 500 Kbps. Cited at title level for the identifier, parameter and bit-rate structure described above.
• syniotec, “Understanding AEMP 2.0”: https://syniotec.com/understanding-aemp-2-0/ (third-party explainer, not a normative source; used here only for the plain-language description of what the format covers).
• Confederation of Indian Industry and Boston Consulting Group, “Pressing the Throttle: How India’s Mining and Construction Equipment Industry can support domestic ambitions and become a global force”, July 2026, p. 25.