ISO 15143-3: what a mixed machine fleet hands over through the interface, and what it does not

The document's full title is ISO/TS 15143-3:2020, Earth-moving machinery and mobile road construction machinery, Worksite data exchange, Part 3: Telematics data. The TS in the name is the first piece of information: it is a Technical Specification, not an International Standard, and does not carry the consensus status of an ISO standard. The second edition is dated January 2020 and replaces the first of 2016; the foreword names as the main change a normative Annex E that sets out the process for adding new data elements to the specification. It was prepared by Technical Committee ISO/TC 127, Earth-moving machinery, Subcommittee SC 3, and the foreword expressly thanks the Association of Equipment Manufacturers and the Association of Equipment Management Professionals for their prior work. Hence the trade name AEMP 2.0: the second version of the association's 2016 specification became the ISO template, and most manufacturers and fleet platforms still call the interface by that name.

The introduction says in two sentences what the document is for. It is a data schema for data transmitted directly from the equipment manufacturer or provider to the equipment owner, in a standardised format, for the use of owners with mixed fleets. And: its goal is to give end users direct access to their own fleet data, not to enable third parties to aggregate data across end users. The second sentence matters to any service provider who wants to pull machine data for its customers: the specification is written for the owner, and whoever pulls on the owner's behalf does so under the owner's mandate, not by right of their own.

Clause 1 sets out what is covered: the communication schema for providing mobile machinery status data from a telematics provider's server to customer applications over the Internet. The data is collected on the machine by telematics data-logging equipment and stored on the provider's server; the document describes the requests to that server and the responses containing the specified data elements, for the analysis of machine performance and machine management in operation and maintenance. It applies to self-propelled earth-moving machinery as defined in ISO 6165 and mobile road construction machinery as defined in ISO 22242, provided they carry location and time instrumentation.

Then comes the sentence that fixes its reach. The specification is not applicable to on-board data collection, to the on-board communication protocol such as CAN bus, or to the wireless transmission of the machine data to the provider's server after collection at the data logger. The interface therefore only begins once the data is already with the manufacturer or telematics provider. What happens on the machine, how often it transmits, over which network and with what delay, is not in this document and differs from maker to maker. The introduction describes the mechanism: the customer application sends HTTPS GET requests to the server, and the server responds with an equipment information document whose vocabulary the specification defines. A GET is a read path. A path by which the application tells the machine anything is not part of the specification.

Clause 11 of the specification lists the data elements one by one, each with a timestamp, a unit of measure, a request endpoint and a response schema. In the document's order: machine header information with make, model and equipment ID; last known location with date, latitude, longitude and altitude, plus an endpoint for the location time series; operating hours; cumulative fuel used, marked in the document as preferred; fuel used in the preceding 24 hours, marked as an alternative and expressly not preferred; cumulative distance travelled; caution-code reference number; cumulative idle operating hours; fuel remaining ratio; percent of DEF remaining; engine condition; digital input state; cumulative power take-off hours; average daily engine load factor; peak daily speed; cumulative load count; cumulative payload total; cumulative non-productive regeneration hours; cumulative idle non-operating hours. The clause closes with a section for data field descriptions of codes unique to each system.

Two observations on that list. First, almost every value is cumulative. The specification delivers counter readings, not events: it says how many load cycles a machine has had since commissioning and how many tonnes it has moved in total, and anyone who wants to derive a shift, a trip or an empty run from that has to pull the counters at short intervals and take the differences themselves. Second, everything a machine is doing at this moment is absent: no boom angle, no bucket content, no drive command, no sensor image. That is not a gap but a design decision; that data lives on board, and on board is where the scope ends before it begins.

The specification fixes the vocabulary, not the commercial terms. Those sit with the manufacturer, and Caterpillar has published them in a two-page German-language brochure with the document number PGDJ0444-01 from 2020, which serves here as the example because it is public and states numbers. According to it, access via the API to ISO 15143-3 is tied to a paid telematics subscription and covers every machine connected through Product Link. Retrieving data through the API carries a one-off fee, with up to 10,000 calls per day. A snapshot is the last reported value of a machine or fleet at a point in time; a time series comprises all known values over a specified period of up to two weeks for a single piece of equipment. The brochure lists twelve of the specification's data types and assigns each either to the snapshot or to the time series, among them header data, last known location, operating hours, cumulative fuel, idle hours, fuel ratio, engine condition, load count, payload totals and fault codes. Retrieved data may be stored indefinitely on the customer's own system.

Three numbers in that brochure shape every application built on it. Two weeks of time series per call means that anyone who wants a history over months must pull regularly and archive themselves; the specification and the manufacturer both expressly expect that. Ten thousand calls a day is enough for a medium fleet at minute intervals, but it is a budget that an application with many machines and many data types has to plan around. And the subscription is the precondition without which the interface stays empty: a machine without an active telematics subscription does not appear, whichever standard the API conforms to. That other manufacturers serve the interface too is the state of the trade; German fleet-management platforms list Liebherr, Bomag, Hamm, Hitachi and Volvo among the supported makers. That list comes from the platforms, not from the manufacturers themselves, and terms such as subscription, call limits and time windows have to be checked per manufacturer; the Caterpillar numbers apply to Caterpillar.

When a robot, an autonomous vehicle or a retrofit kit for an excavator arrives on such a site, two data worlds exist there side by side. The existing fleet reports counter readings to its manufacturers' servers, and from there the operator pulls them via ISO 15143-3 with whatever delay the manufacturer builds in. The robot or the autonomy system has an interface of its own that works in real time and in both directions: jobs in, state out. For driverless transport vehicles in halls that is VDA 5050; for outdoor machines it is the interface of the system supplier. Bringing both into one picture is an integration task, and it starts with the sober finding that the existing side only reads, and only with latency.

That decides what the interface is good for. For utilisation, for matching operating hours against service intervals, for the question of which machine burned how much fuel idling yesterday, it was made, and the cumulative payload and load-count values can be differenced into trips and empty runs at short polling intervals, to the accuracy the manufacturer gives its scale. For coordination on the ground, for where the dumper is right now while the autonomous excavator loads, it was not made: the last known location is a single data point from the manufacturer's server, and the specification does not say how old it is. Anyone who wants to coordinate existing machines and autonomous systems on one site needs sensing on the site or on the machines themselves; the telematics interface is the wrong place for that, and a supplier who offers it for that has not read the scope.

werob is a manufacturer-independent systems integrator and none of the manufacturers named here is a confirmed partner; Caterpillar and the makes listed by fleet platforms appear as publicly documented market examples. What werob settles in a specification for such a site is which data from the existing fleet is actually available, by which path, with what latency and under whose subscription, before a robot system is planned beside it. That is interface work, not a product feature.

From the specification and the brochure follows a short list that goes to a site manager, a fleet manager or the dealer before anything is connected. First: which machines in the fleet have an active telematics subscription at all, and with which provider? Without a subscription there is no data, and on rented machines the rental company often holds it. Second: who is the contracting party to the API, and on whose behalf does a service provider pull? The specification is written for the owner. Third: which of the twenty data elements does the manufacturer actually deliver, and which as snapshot, which as time series? The specification allows subsets, and Caterpillar's brochure lists twelve. Fourth: how long is the retrieval window, how high the call limit, and who archives? Two weeks and ten thousand calls are Caterpillar's numbers; other manufacturers state their own. Fifth: what delay lies between machine and server? That is in no specification and no brochure and can only be measured in operation. Sixth: what happens to the retrieved data when the service provider or the dealer changes? The brochure says it may be stored indefinitely on the customer's own system; that presupposes there is one.

The statements on the specification come from the publicly available preview text of ISO/TS 15143-3:2020 (foreword, introduction, clause 1 and the table of contents with the data elements of clause 11), read in September 2026; the schemas and endpoint definitions of the main body sit behind the paywall and are not reproduced here. The figures on subscription, fee, call limit and time window come from the Caterpillar brochure API gemäß ISO 15143-3 (AEMP 2.0), document number PGDJ0444-01, 2020, and apply to Caterpillar; whether they are unchanged in 2026 the brochure does not say, and a contract should fix the current terms rather than refer to it. The list of further manufacturers serving the interface comes from the websites of German fleet platforms, not from the manufacturers, and was not checked per manufacturer. On latency and transmission interval none of the sources read makes a statement; this article claims nothing about them except that they are to be measured. No figure on this page is werob's own, and werob has not connected any of the interfaces named here for a customer reported on here.