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: some expose a standard J1939 CAN bus, others offer only analog load-cell and tilt outputs, and a handful speak a proprietary CAN dialect with no public documentation. The operator wanted the same load, tilt, and utilization numbers from every chassis, on a screen they control, without committing the fleet to one OEM telematics product or one cloud silo.

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.

Three 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 protocols on the same chassis. On newer units, J1939 frames carry boom angle, hoist speed, and engine load over CAN. Older units have no bus worth reading: load-cell weight and tilt arrive as analog voltages off the sensor wiring. Both had to resolve to one normalized record per crane per second, under a single canonical schema, so a 2008 lattice-boom and a current all-terrain unit report utilization the same way.

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 open-Linux gateway terminating J1939 over CAN alongside the analog load and tilt inputs. A small acquisition daemon reads both sources, 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.

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 behaviour, 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 proprietary-CAN units. We reverse-engineered the relevant frames with the operator's lead mechanic in the loop, decoding boom angle and hoist signals against known physical positions, then taught the dialect to the acquisition daemon. No OEM was contacted, and 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, owed 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.

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.

There is no “crane monitoring system” to buy at the end of this. 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 programme shaped by their fleet and their constraints, not a re-skin of this one. The mix of protocols, 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.