Crane Monitoring Retrofit for a Mixed Mobile Fleet

A European crane rental operator runs a mixed mobile crane fleet across three depots. The machines span several generations and OEMs. J1939 on the engine and drivetrain carries the diagnostics: error codes, fuel level, subsystem temperatures and operating hours. Load-cell weight and tilt come over CANopen, and where a crane had no usable tilt signal, a tilt sensor had to be retrofitted. When a crane reported a fault, the maintenance team sent someone to read the codes and download the datalogger on site. The operator wanted to diagnose before anyone travelled, with the same load, tilt and utilization numbers from every chassis, on a screen they control.

Two earlier pilots had stalled, both built on closed gateway platforms. Data left the cab, then stopped at a vendor portal. Adjusting an alert threshold or redefining a KPI meant a paid change request and a release cycle measured in months. The operator owned the machines. It did not own the telemetry pipeline, which is the part that decides what the fleet manager actually sees each morning.

Four constraints shaped the architecture, and the brief was blunt: none of them were negotiable.

IP stays with the operator. The gateway software, the data schema, and the dashboards had to be auditable and portable. If Melqart walked away, the operator would keep running the fleet unchanged, with the source, the schema definitions, and the deployment scripts in their own repository.

Two buses on the same chassis. J1939 frames carry boom angle, hoist speed and engine load, along with error codes, fuel level, subsystem temperatures and operating hours. CANopen carries the load cell and the tilt sensor, retrofitted where the crane had none. Both had to resolve to one normalized record per crane per second, with the GPS position attached, under a single canonical schema, so a 2008 lattice-boom and a current all-terrain unit report utilization the same way.

The datalogger has to be reachable. Each crane keeps a detailed onboard datalogger. Reading it meant a trip to the cab, so the gateway had to make it downloadable remotely.

Connectivity is not a given. Quarry pits and indoor builds drop to 2G or to no signal for hours. The pipeline had to buffer on the gateway, ship the backlog on reconnect, and never silently drop a frame during a lift. A gap in coverage cannot become a gap in the lift record.

The deployed stack is deliberately boring, and that is the point. Each crane carries an Owasys gateway terminating J1939 and CANopen, with GPS on board. A small acquisition daemon reads both buses, applies a per-unit calibration table (every load cell has its own offset and span), and writes one normalized record into a local time-series buffer before any network is touched. The buffer, not the broker, is the system of record at the edge. The same gateway brokers access to the crane's onboard datalogger, so maintenance downloads it from the office.

From there an MQTT publisher ships records over cellular to a broker the operator hosts in their own VPC. MQTT carries the per-second records with quality-of-service set so an interrupted session resumes from the buffer rather than losing whatever was in flight. A stream worker fans the data two ways: into a Postgres database with the TimescaleDB extension for the dashboards, and into an object store for long-term raw archives. No SaaS portal sits in the path. Every component runs in the operator's account, and every record has a documented schema and a named owner.

OTA updates land over a signed channel. The operator can pin a firmware version or roll a whole depot from their own console without calling us. A gateway swap takes a field engineer roughly fifteen minutes, helped by a pre-flashed image and a wiring loom that mirrors the OEM service connector, so the unit drops onto existing pins rather than into a soldering job.

The rollout ran as three depots in sequence, never a single big-bang across the fleet.

Depot A (weeks 1–3): twelve cranes across three OEM generations. The goal was to prove the calibration tables, the buffer behavior, and the cellular tail under real lifts rather than on a bench. Everything ran instrumented. Every dropped frame was logged and reviewed daily, and the few we found traced to wiring, not to the pipeline.

Depot B (weeks 4–7): thirty cranes, including the units without a usable tilt signal. Those received a retrofitted tilt sensor on the CANopen network, calibrated with the operator's lead mechanic in the loop against known boom positions. No IP left the operator.

Depot C (weeks 8–11): the remaining fleet. By now the work was mechanical: fit, flash, calibrate, walk away. Depot crews provisioned new units themselves, and our role had shifted from installing to answering the occasional question.

The operator runs their own KPI dashboard, so the numbers below are theirs. We report them as they were communicated back twelve weeks after the last depot went live.

• Time to first telemetry on a newly retrofitted crane: under 30 minutes, including calibration.
• Frame loss under 2G or no-service conditions: 0% within a 24-hour window, owing to local buffering and resume-on-reconnect.
• Lift-event capture rate, with load-cell weight, tilt, and boom angle correlated to a single timestamp: ~99.3% across the fleet.
• Time to ship a new alert threshold to the whole fleet: same day, with no vendor change request.

For maintenance, the bigger change sits outside this list. Error codes, subsystem temperatures and fuel level are read remotely, and the datalogger is downloaded from the office before anyone decides to drive out.

The fleet utilization KPI is the operator's to publish, not ours. The dispatcher's note is the one that mattered to us: “the number we read on the screen is the number we trust at the morning meeting.” That sentence is the brief restated: a feed they believe, because they own how it is built.

This project shaped our crane remote diagnosis offer, but there is no one-size kit behind it. There is an architecture pattern, a specific hardware choice, a normalized schema, and an engagement that handed the whole stack to the operator's team. The next operator who asks for a crane retrofit gets a program shaped by their fleet and their constraints, not a re-skin of this one. The mix of buses, the depot count, and the connectivity gaps will differ, and the design follows from those facts.

What the operator kept after handover: the gateway IP, the schema, the dashboards, the runbooks, and the right to walk away. What they did not keep: a dependency on any vendor, us included.