Home/Insights/Concrete Truck Monitoring

Concrete Truck Monitoring

Edge telemetry for concrete delivery fleets: drum rotation, hydraulic pressure, GPS, water-tank usage, and ambient conditions per truck, with MQTT to an operator-hosted broker. Multi-site retrofit with an ISO 15143-3 (AEMP 2.0) adapter.

Illustrative image: concrete mixer truck pouring on a construction site

What the field looked like

Ready-mix concrete has a hard time budget. From the moment water meets cement, drum rotation, hydraulic drum-drive load, water added from the truck tank, and ambient temperature and humidity all push on slump, the cure window, and whether the batch is accepted on site. A multi-country operator ran its delivery fleet on manual logs and the occasional plant-side test, which meant quality drift surfaced at the pour, where there is nothing left to do about it.

The brief was narrow. Surface the measured signals per truck in real time (drum rotation speed and direction, hydraulic drum-drive pressure, GPS position, water-tank usage, ambient temperature and humidity), ship them edge-first, and feed a partner AI platform that closes the loop on mix design. No talk of transformation. The question was whether a rejected batch could be caught before it left the depot.

The signals that tell the quality story

The acquisition stack on each truck reads the channels that matter for delivery quality and operations:

  • Drum rotation: speed and direction of the mixer drum.
  • Hydraulic pressure: pressure at the hydraulic motor driving the drum.
  • GPS: truck position throughout the delivery.
  • Water-tank usage: a sensor that detects when water is taken from the truck water tank.
  • Ambient temperature and humidity: environmental conditions around the truck.

Older trucks without native sensors get retrofit units fitted to match the OEM-equipped fleet. One schema covers every chassis, so analytics never have to branch on vintage.

From drum to delivery: the data path

Each truck carries an Owasys open Linux gateway running an acquisition daemon. Where the drivetrain exposes it, the gateway reads J1939 over CAN; for older units, it falls back to analog inputs through a sensor module. Raw frames are calibrated against a per-unit table, normalized to one record per second per truck, and written to a local time-series buffer.

Analytics run on the gateway itself. Slump estimates, mixing efficiency, and rolling temperature trends are computed without a cloud round trip. Critical conditions (temperature out of band, drum stall) fire local alerts in under a second. Everything else streams over MQTT to a broker the operator hosts, where a stream worker forwards aggregates to the partner AI platform through an ISO 15143-3 (AEMP 2.0) compliant adapter.

The buffer holds 24 hours of records. A depot connectivity drop costs no drum rotation, load, or discharge-event data: the buffer drains on reconnect.

  1. Truck01Drum and chassis signalsJ1939 over CAN where the drivetrain exposes it, analog inputs through a sensor module on older trucks.
  2. Truck02Owasys gatewayCalibrates against a per-unit table and normalizes to one record per second per truck.
  3. Truck03Edge analytics and bufferSlump estimate, mixing efficiency and temperature trends on the gateway; local alerts in under a second; 24 hours of records buffered.
  4. Operator04Operator-hosted brokerEverything else streams over MQTT to a broker the operator runs.
  5. Operator05Partner AI platformA stream worker forwards aggregates through an ISO 15143-3 (AEMP 2.0) compliant adapter.
Alerts fire on the truck. The operator owns the broker, so changing the AI partner leaves the data path where it is.

Rollout: pilot, then depot-by-depot

Pilot (weeks 1–3): twelve trucks at one depot, spanning two chassis vintages. This locked the calibration tables, measured edge-side alert latency, and proved the MQTT and ISO 15143-3 (AEMP 2.0) contract against the partner platform.

Rollout (weeks 4–9): the remaining depots in waves. Once a Melqart engineer had certified the first ten trucks at a depot, the depot crew ran the rest of the installs. Each install was the same: pre-flashed gateway, a wiring loom that mirrors the OEM service connector, calibration against plant references.

Optimization (weeks 10–14): the partner AI platform pulled live data, and the operator's quality team tuned thresholds until alert noise dropped to actionable events only.

What changed for operations

The operator's quality team reports a measurable drop in rejected batches at the pour, because edge alerts catch out-of-band conditions before delivery. Dispatch and plant teams now reason about utilization and quality from one dataset instead of reconciling spreadsheets after the fact.

Two outcomes matter past the headline:

  • The partner AI platform gets clean inputs. Continuous, normalized telemetry across the fleet means the ML team is no longer fighting data quality on top of model quality.
  • The operator owns the pipeline. The acquisition daemon, the schema, and the broker all sit inside the operator's account. Change the AI partner and the data path stays exactly where it is.

Why it works as a pattern

The architecture moves to any time-sensitive cargo: specialty chemicals, perishables, anything with a quality window measured in minutes. An edge gateway with a local buffer, a normalized per-asset schema, MQTT to an operator-hosted broker, exception-first alerts. The vertical changes. The shape does not.

Build your industrial telemetry solution.

Discuss embedded gateway delivery, telemetry pipelines, and customer-owned IP with our team.