Mixed-Fleet Telematics: How to Unify Data From Every Equipment Brand With ISO 15143-3 (AEMP 2.0)

Mixed-fleet telematics means seeing every machine you own in one place, whatever brand it is. For most contractors that is harder than it sounds. A fleet with Caterpillar, John Deere, Komatsu and Volvo machines has four telematics portals, four logins and four data formats.

The industry's answer is a standard called ISO 15143-3, widely known as AEMP 2.0. This guide explains what the standard covers, what data you get, how the API works, and how to design a system that unifies it.

The Problem: One Portal Per Brand

Modern heavy equipment ships with built-in telematics. Each manufacturer sends that data to its own cloud and shows it in its own portal, such as Caterpillar VisionLink, John Deere JDLink, Komatsu KOMTRAX or Volvo CareTrack.

That works if you run one brand. Most fleets do not. Without a common format, fleet managers end up:

• Logging into several portals every day
• Copying engine hours into spreadsheets for maintenance planning
• Building separate reports per brand
• Missing fault codes because nobody checked the right portal

The result is the question we often hear from operations teams: "Which machines are actually working, and which need service?" It should take seconds to answer. Without unified data it takes hours.

What Is ISO 15143-3 (AEMP 2.0)?

ISO 15143-3 is an ISO Technical Specification. Its full title is Earth-moving machinery and mobile road construction machinery, Worksite data exchange, Part 3: Telematics data. The current edition is ISO/TS 15143-3:2020.

It defines a communication schema for moving machine status data from a telematics provider's server to customer applications over the internet. In plain terms, it is a shared API contract. If two manufacturers both implement it, your software can read both in the same way.

Where AEMP fits in

The Association of Equipment Management Professionals (AEMP) wrote the first version of the standard so equipment owners could escape single-brand portals. The second version, developed together with the Association of Equipment Manufacturers (AEM), became the basis of the ISO specification. That is why you will see "AEMP 2.0" and "ISO 15143-3" used for the same thing.

What the standard does not cover

The scope is deliberately narrow. ISO 15143-3 covers the server-to-application step only. It does not cover:

• How data is collected on the machine
• On-board protocols such as CAN bus
• The wireless link from the machine to the manufacturer's server

It also applies to earth-moving machinery and mobile road construction machinery. Road vehicles and small tools are outside its scope.

What Data You Get

Each manufacturer decides which metrics its machines report. Published implementations, such as Proemion's ISO 15143-3 API, expose metrics including:

Metric	What it tells you
Location	Latest GPS position of the machine
Cumulative operating hours	Engine hours, the basis for maintenance and utilization
Cumulative idle hours	Hours the engine ran without working
Cumulative fuel used	Total fuel consumed
Fuel remaining ratio	Current fuel level as a percentage
DEF remaining	Diesel exhaust fluid level
Distance	Distance travelled, for machines that move between sites
Engine condition	Whether the engine is running
Faults and caution codes	Diagnostic codes, often in SPN and FMI format
Cumulative load count	Number of loads, for haulers and loaders
Average daily engine load factor	How hard the engine works on average

Older or smaller machines may report only a few of these. Always check per model.

How the API Works

Implementations vary in detail, but the documented ones share a common shape.

• Protocol: HTTPS with a REST-style interface.
• Authentication: OAuth 2.0, using an access token from the provider.
• Response format: XML. Some providers say JSON may follow later.
• Fleet snapshot: A paged list of all machines with their latest values.
• Time series: Per-machine history for each metric over a time range.
• Identifiers: Machines are found by PIN or VIN, or by make, model and serial number.
• Paging: The server sets the page size, and responses include links to the next page.

Volvo Construction Equipment, for example, publishes an AEMP 2.0 API that it describes as compliant with ISO 15143-3:2020.

Reference Architecture for Unified Fleet Visibility

Here is the design we use when building a mixed-fleet data layer.

1. One connector per manufacturer

Each OEM has its own endpoint, credentials and quirks. Build a small connector for each. It handles authentication, paging, retries and rate limits, and returns raw records.

2. A normalisation layer

Convert every record into one internal model. This is where most of the work is.

• Key every machine on PIN or VIN, not on name. Names change; identifiers do not.
• Convert units such as litres and gallons, or kilometres and miles.
• Store cumulative values as received, then calculate daily deltas yourself. That way a missed poll does not lose data.
• Map fault codes to a common severity scale so alerts work the same across brands.

3. A time-series store

Engine hours and fuel are time-series data. Store them in a way that makes daily, weekly and per-job rollups cheap. PostgreSQL with sensible indexes works for most fleets. Very large fleets may need a dedicated time-series database.

4. The rest of the fleet

Add other sources for assets the standard does not reach:

• Road vehicles: OBD-II or J1939 telematics devices, or a telematics platform's API.
• Older machines: aftermarket GPS and hour-meter trackers.
• Trailers, attachments and tools: low-cost GPS trackers or Bluetooth tags.

5. Applications on top

With one data model, the useful features become simple queries:

• Utilization by machine, model, site or project
• Maintenance due by engine hours, across every brand
• Fault alerts that open work orders automatically
• Fuel and idle reports per job for costing

Common Pitfalls

• Assuming every OEM reports every metric. Coverage varies by brand, model and year.
• Polling too often. Many endpoints update a few times a day. Over-polling wastes quota.
• Trusting snapshots alone. Use time-series endpoints to fill gaps after outages.
• Ignoring identifier mismatches. The same machine can appear with different serial formats across systems.
• Forgetting access set-up. Each OEM account must grant API access, which can take weeks.

Build or Buy?

Buy if your fleet platform already connects to all your manufacturers and you only need dashboards and maintenance. Many construction and telematics platforms offer this.

Build if you need mixed-fleet data inside your own systems, such as an ERP, a data warehouse or a custom operations platform, or if no vendor covers your exact mix of brands. A focused connector layer is usually a modest project. The larger effort is the normalisation and the applications on top.

Ortem builds custom fleet platforms and integration layers, including multi-OEM telematics. See our fleet management software development services. For the buying side, read our guide to construction fleet management software.