// blog # AEMP 2.0 Explained: Mixed-Fleet Telematics Standard What AEMP 2.0 is, supported data fields, how it unifies OEM feeds and integration steps for heavy-equipment fleets. Updated 14 Aug, 2025 [← All posts](https://www.autopi.io/blog/) The AEMP 2.0 Telematics Standard, introduced by the Association of Equipment Management Professionals in 2012, standardized **telemetry data formats** and interfaces for construction equipment, improving interoperability, reducing integration work, and giving fleet owners a consistent view of mixed OEM assets. The AEMP 2.0 Telematics Standard is a reference model for how heavy equipment data is exposed, exchanged, and consumed. It promotes structured data sharing and transparency between OEM platforms, third party systems, and end users. In practice, it replaces one-off data feeds with a predictable schema that can support utilization reporting, cost analysis, and advanced automation. As telematics technology has evolved, the AEMP 2.0 model has been refined and adopted in [telemetry](https://www.autopi.io/glossary/telemetry/) standards work, most notably in ISO 15143-3. These iterations reflect a continuous improvement process: aligning OEMs on a common payload, cleaning up ambiguities, and extending the specification as new use cases appear. The result is a stable baseline that equipment managers can rely on for long lived, standards based integrations. ## What is the AEMP Telematics Standard? The AEMP Telematics Standard, now formalized as ISO 15143-3:2020, defines how worksite and equipment data for earthmoving and mobile road construction machinery is exposed over a web service interface. The first public AEMP specification was published in 2010 as version 1.0 and updated to version 2.0 in 2016 for broader commercial deployment across OEM telematics platforms. The standard focuses on the exchange of worksite data using [telematics](https://www.autopi.io/blog/what-is-telematics/) with [GPS](https://www.autopi.io/blog/what-is-gps/) and [onboard diagnostics](https://www.autopi.io/blog/what-is-obd-2/) as primary inputs. For fleet managers operating mixed fleets, it provides a uniform way to consume OEM telematics feeds into a single system instead of maintaining separate connectors per brand. By submitting the specification to the International Organization for Standardization (ISO), AEMP ensured that the model could be used globally by manufacturers, equipment users, and integrators without proprietary lock-in. Key characteristics of the AEMP and ISO 15143-3 model: - **Uniform data format:** Defines a common JSON and XML payload structure for key parameters such as position, hours, fuel, and machine status. - **Vendor neutral integration:** Works across multiple OEM portals and third party [fleet management systems](https://www.autopi.io/blog/what-is-fleet-management/) using the same field names and types. - **Simplified aggregation:** Reduces custom mapping and makes it possible to merge data from multiple monitoring systems into a single data lake or application. - **Structured acquisition:** Specifies which parameters are required, which are optional, and how often they should be delivered, which improves downstream analytics quality. - **Operational tracking:** Covers core metrics such as location, utilization, fuel, and engine state that underpin maintenance, planning, and security use cases. - **Extensible monitoring:** Supports additional parameters such as temperature, motion, and discrete input states without changing the overall interface model. According to Stan Orr, President and CSO of AEMP, standardizing the way data is exposed allows equipment managers to consolidate information into a single view, improve productivity, and reduce the cost of connecting new assets. With a consistent schema, managers and contractors can retain control over their data sources, select the tools they prefer, and configure dashboards and reports to match the operational questions they need to answer. ## Overview of ISO 15143-3 Standard The ISO 15143-3 standard specifies a web service protocol for the exchange of telematics data in construction and road machinery. It describes how key operational parameters should be formatted, transported, and accessed so that data from different OEMs can be interpreted in the same way by a downstream system. The objective is to establish a universal [communication protocol](https://www.autopi.io/glossary/communication-protocol/) that covers data types, frequency, access methods, and error handling. By defining these elements, ISO 15143-3 ensures that telematics data remains compatible and machine readable across diverse equipment brands and telematics platforms. In practical terms, ISO 15143-3 improves telematics system functionality by enabling consistent data exchange and interoperability. Fleet managers can aggregate feeds into a single platform, align KPIs across brands, and support maintenance and planning decisions with a coherent dataset rather than fragmented exports. The table below summarizes the standard along four dimensions that are relevant for equipment and fleet managers. | Standard Purpose | Data Types Covered | Operational Benefits | Global Impact | | --- | --- | --- | --- | | Defines a common language for telematics data in earthmoving and construction machinery. | Operating hours, location, fuel usage, machine state and health indicators. | Simplifies interpretation of OEM data and reduces custom mapping per brand. | Serves as a shared reference model for OEMs, integrators, and fleet platforms. | | Standardizes the communication of equipment telemetry over a web service interface. | Includes specifications for [data transmission](https://www.autopi.io/glossary/data-transmission/) methods, polling models, and access protocols. | Enables seamless aggregation and analysis across mixed equipment fleets. | Improves interoperability between manufacturer portals and third party applications. | | Aligns with the original AEMP 2.0 model and formalizes it as an international standard. | Focuses on consistent field definitions and units so that KPIs are comparable across brands. | Supports accurate and timely information for maintenance, planning, and utilization reporting. | Encourages a more data driven approach to equipment management worldwide. | | Provides a stable foundation that OEMs can extend with proprietary signals when needed. | Permits optional KPIs in addition to the core set defined by the standard. | Reduces integration risk when fleets add new brands or equipment types. | Sets a benchmark for future telematics standards in adjacent sectors. | | Extends the reach of AEMP 2.0 by encoding it in an ISO framework. | Can coexist with OEM specific APIs where deeper brand specific data is required. | Improves consistency in monitoring machinery performance and operational efficiency. | Drives innovation in analytics, maintenance, and automation built on standardized feeds. | Upgrade your fleet with AutoPi and AEMP 2.0 Combine the AutoPi Telematics Unit with ISO 15143-3 endpoints to obtain a single, near real time view of utilization, fuel, and fault codes across every OEM brand in your fleet. [ Upgrade Your Fleet Management ](https://www.autopi.io/software-platform/fleet-management/) [ Shop Devices ](https://shop.autopi.io/products/autopi-telematics-unit-cm4-4g-lte-edition) ## Crucial Data Endpoints Defined by ISO 15143-3 ISO 15143-3 (AEMP 2.0) defines five primary parameters that every mixed brand construction fleet should ingest as a minimum. Delivered in a common JSON schema, these values support preventive maintenance, fuel cost analysis, and geofenced security use cases in a consistent way across OEMs. - **Location:** Latitude, longitude, and timestamp allow managers to track asset position in real time, enforce geofences, validate deployment, and react quickly to theft or unauthorized use. - **Operational hours:** Cumulative engine on time provides a more accurate basis for service intervals and warranty compliance than calendar schedules alone. - **Total fuel consumed:** Lifetime fuel burn enables cost per hour and cost per unit of production calculations and supports emissions and sustainability reporting. - **Fuel used in the last 24 hours:** Short term consumption trends highlight abnormal increases caused by leaks, excessive idling, or misuse and provide near real time input for cost control. - **Total distance travelled:** Odometer equivalent values support depreciation models, lease and rental agreements, and validation of relocation or transport billing. Beyond the core set, ISO 15143-3 defines a larger group of optional KPIs that sharpen productivity and maintenance analytics. Examples include idle analysis, engine load metrics, and payload statistics. - **Cumulative idle operating hours:** Quantifies engine wear and fuel waste when machines run without productive work. - **Fuel remaining ratio:** Percentage of tank capacity that enables refuelling plans at site instead of returning machines to depot. - **Percent of DEF remaining:** Reduces derate events on Tier 4 and Stage V engines by alerting operators before DEF drops to critical levels. - **Engine condition:** Aggregated health flags derived from temperature, pressure, and fault severity to speed triage. - **Digital input state:** Captures the state of PTO, beacons, or attached implements via discrete inputs for more precise duty cycle analysis. - **Cumulative PTO hours:** Separates auxiliary system wear, such as hydraulic pumps or generators, from overall engine hours. - **Average daily engine load factor:** Indicates whether machines are consistently underloaded or overloaded and supports right sizing decisions. - **Peak daily speed:** Identifies unsafe movements between work zones and supports enforcement of site speed policies. - **Cumulative load count:** Counts bucket or truck bed cycles for production benchmarking and component life modelling. - **Cumulative payload total:** Aggregated tonnes moved for cost per tonne and fuel per tonne metrics. - **Cumulative non productive regeneration hours:** Measures time spent in DPF regeneration to support operator training and duty cycle optimization. - **Cumulative idle non operating hours:** Captures key on, engine off time where electrical loads such as HVAC and lighting are active. Capturing these endpoints through an AEMP 2.0 compliant API and forwarding them to [AutoPi Cloud](https://www.autopi.io/software-platform/cloud-management/) gives fleet managers a single, normalized telemetry feed for mixed OEM assets. This simplifies analytics, improves decision quality, and reduces the overhead of working with multiple proprietary data formats. ## Why AEMP 2.0 Is Essential for Your Mixed Fleet In construction, mining, and heavy civil projects, profitable operation depends on how well equipment is utilized, maintained, and relocated between jobs. Certified equipment managers need a complete view of machine status across sites, including running state, utilization, and fault conditions. Without a standardized data model, building this view across several OEMs becomes a continuous integration project. [ Start Boosting Your Efficiency ](https://www.autopi.io/sales-inquiry/) Consider a portfolio that spans multiple sites and OEMs. With AEMP 2.0 and ISO 15143-3, a manager can query a single interface to see whether an excavator is operating, idling, or stopped on one site while checking fuel status and open faults on a loader at another site. Dispatch, maintenance, and planning teams work from the same normalized dataset instead of reconciling screenshots and spreadsheets. Most Original Equipment Manufacturers provide telematics portals, but field coverage, data depth, and export formats differ by brand. Aggregating this data into one actionable view for a mixed fleet is difficult and does not scale well when the number of units increases. As fleets grow into the hundreds or thousands of assets, a standards based interface becomes a prerequisite for reliable reporting and automation. The AEMP 2.0 model addresses this complexity. It enables [fleet managers](https://www.autopi.io/glossary/fleet-manager/) to monitor their entire fleet through a unified data contract, independent of how many OEMs or equipment types are involved. By standardizing endpoints, AEMP 2.0 and ISO 15143-3 make it possible to build dashboards, alerts, and reports that work for the full fleet instead of for a single brand. In practice, this standardization leads to measurable improvements. For example, fleets can identify underutilized equipment and reduce rental or lease dependencies, move machines between projects with better data, and align maintenance windows with actual usage. It also makes it easier to implement data driven strategies for fuel reduction, emissions reporting, and capital planning based on reliable [fleet data](https://www.autopi.io/business-solutions/fleet-data-management/) rather than estimates. AEMP 2.0 Compatibility Integrate AEMP 2.0 for unified fleet data interfaces AutoPi supports AEMP 2.0 and ISO 15143-3 to standardize data access across mixed vendor machinery fleets. Use a consistent API surface for location, utilization, machine status, and fault information and reduce the effort required to connect new OEMs or applications. [ Explore AutoPi Fleets ](https://www.autopi.io/software-platform/fleet-management/) [ ← Back to all posts ](https://www.autopi.io/blog/) // hardware ## Choose hardware for your integration Compare Mini, CAN-FD Pro and TMU CM4 by vehicle data access, interfaces and custom software needs. [Compare devices →](https://www.autopi.io/hardware/compare/) ###### Hardware ## Choose your evaluation device Start with the hardware your project needs. Software and connectivity terms differ by device and purchase option. Prices below exclude VAT, duties, shipping and optional accessories. CAN-FD Pro In stock · ships tomorrow ### Dual CAN-FD data logger High-throughput raw frame capture on two independent CAN-FD channels. On-device DBC decoding, ASAM MDF4 output, J1939 native support and hardware-encrypted data signing - all on a Raspberry Pi CM4. → 2× CAN-FD · >3,000 fps/channel · 5 Mbps → 4 GB LPDDR4 · 32 GB eMMC + USB expansion → NXP SE051 · Tailscale SSH · Docker · S3 sync → 12–35 V DC · J1939 · OBD-II · 4G/LTE + GPS From EUR 599. AutoPi software included without a subscription. Cellular SIM and data purchased separately. [Order CAN-FD Pro](https://shop.autopi.io/products/autopi-can-fd-pro) [Learn more](https://www.autopi.io/hardware/autopi-canfd-pro/) Mini In stock · ships tomorrow ### Fleet telematics & OBD-II OBD-II and supported EV telemetry with GPS and built-in 4G/LTE. Check your exact vehicle, required signals and regional variant; installation and configuration needs vary. → OBD-II / K-Line · EV parameters · GPS tracking → 4G/LTE Cat 1 · BLE · internal antennas → −40°C to +85°C · CE/UKCA/E-Mark/RoHS → 10–30 V DC · compact · fleet-ready out of box EUR 129 + EUR 6/month for SIM and Cloud, with a 12-month minimum. First-year minimum: EUR 201. Includes 100 MB/month. [Order Mini](https://shop.autopi.io/products/autopi-mini) [Learn more](https://www.autopi.io/hardware/autopi-mini/) TMU CM4 In stock · ships tomorrow ### Edge compute platform Raspberry Pi CM4-based telematics unit for custom software stacks. Run Docker containers, Python services and CAN-FD logging on the same device - managed remotely via AutoPi Cloud. → BCM2711 CM4 · 1 GB LPDDR4 · 8 GB eMMC → 2x CAN or CAN-FD variant · Docker · Python · SocketCAN → NXP SE051 · Tailscale · WiFi · BT 5.0 · GPS → 12–35 V DC · 4G/LTE Cat 4 · IP67 option From EUR 235 with the SIM and Cloud subscription option: EUR 6/month, 12-month minimum. Also available without a subscription; select your interface and payment option in the shop for the price. [Order TMU CM4](https://shop.autopi.io/products/autopi-telematics-unit-cm4-4g-lte-edition) [Learn more](https://www.autopi.io/hardware/autopi-tmu-cm4/) [Compare all devices →](https://www.autopi.io/hardware/compare/) // related ## More posts you'll like [ View all → ](https://www.autopi.io/blog/) Raspberry Pi DIY #### Build a Raspberry Pi Touchscreen Car Computer (Step-by-Step) Assemble a Pi-based carputer with touchscreen, power, mounting and software setup. Parts list, wiring tips and configuration for a reliable in-car sys ... [ Learn More → ](https://www.autopi.io/blog/build-a-raspberry-pi-touch-screen-car-computer/) Guides #### J1939 Explained (2025): PGNs, SPNs & Heavy-Duty Diagnostics Learn J1939 basics‚ PGNs, SPNs, addressing and tools for heavy-duty trucks and machinery. Examples and troubleshooting tips included. [ Learn More → ](https://www.autopi.io/blog/j1939-explained/) Guides #### CAN Bus Explained (2025): Frames, Arbitration & Tools Understand identifiers, arbitration, error handling and analyzers used in automotive systems. Practical examples and diagrams. [ Learn More → ](https://www.autopi.io/blog/can-bus-explained/) // contact ## Still have questions? Get in touch with us - we're ready to answer any and all questions. // send a message We aim to reply within one business day. Or email [sales@autopi.io](mailto:sales@autopi.io).