Case Study: Maximizing Fleet Utilization Across 3 Regions

An industrial equipment OEM ran assets across three regions and could not say, with confidence, how hard any of them were working. Telemetry was already deployed. The problem was what it produced: numbers nobody trusted. Each region defined "in use" and "idle" a little differently, so a utilization figure from one depot meant something else at the next.

The gateway under all of it was a closed platform. Raw data stayed behind the vendor's API, every new alert or report became a change request, and each change request had a price and a place in the vendor's roadmap rather than the OEM's. A threshold tweak that should take an afternoon took a quarter. Licensing and per-feature fees kept climbing while the actual capability sat still.

Operationally it was messier still. Connectivity varied site to site, from solid 4G at a service hub to intermittent coverage at remote deployments. Different subcontractors ran different regions to different conventions. The result was usage reporting that could not anchor a real decision about where to send a machine or when to service it.

The brief was specific. Move to an open embedded Linux gateway the OEM would own outright: source code, build images, and the data those gateways produced, with no layer left behind a vendor's API.

One definition of utilization had to hold across all three regions. If a KPI meant the same thing at every depot, the cross-region arguments stopped and asset-allocation decisions could rest on it. Maintenance signals and alert thresholds had to be editable by the OEM's own team, in days, not filed as a paid request against someone else's release schedule.

And it had to scale without drama. Repeatable provisioning, predictable data pipelines, and an onboarding sequence a technician could follow at the next depot without a Melqart engineer on site.

Melqart Systems delivered an open embedded Linux gateway stack with the OEM holding the codebase. The team had full access to the edge software: read it, change it, rebuild the image, push it over the air. Nothing about the field layer required a call to a vendor.

The gateways spoke the protocols the fleet actually used. CAN bus (J1939) off the drivetrain and engine controllers, digital and analog I/O for switches, levels, and sensor lines that never reached the bus, and external sensors wired in where a signal was missing. A mixed fleet of mobile equipment, support vehicles, and specialized machines came onto one acquisition layer. Each gateway buffered locally and forwarded on reconnect, so a lapse in coverage delayed data instead of dropping it.

One telemetry schema sat over the whole fleet. Field names, units, and the formulas behind every KPI were defined once and owned by the OEM. Those definitions were versioned, so when "engine hours" or "idle" changed, the change was explicit and dated rather than a silent drift between regions. That single contract is what made a number from one depot comparable to a number from another.

On top sat one operational view for dispatch and maintenance: live asset status, utilization KPIs, idle detection, and exception alerts that fired only when something needed a person. Weekly and monthly aggregates exported straight out, no spreadsheet surgery required.

Dispatch felt it first. One screen now showed every asset as available, in use, or idle, drawn from the same definitions everywhere. The standing argument about whose numbers were right simply ended, and a decision that used to take a round of phone calls took a glance.

Because the figures held across regions, machines moved to where they earned their keep. An asset sitting idle in one region while another paid to rent the same thing got caught early, and that overlap closed. Maintenance gained something it never had under the closed platform: it could retune an alert threshold itself, directly in the gateway stack, the same day a pattern showed up in the field. No ticket, no wait for a vendor release. Servicing lined up with how the machines were actually used, unplanned downtime fell, and availability rose.

Delivery ran in three phases, deliberately small at the start. Weeks one to three were a pilot: a representative slice of assets across all three regions, instrumented to capture a baseline. Real utilization, real downtime patterns, real dispatch delays, the numbers that would later say whether anything had improved.

Weeks four to eight scaled the rollout depot by depot and region by region, each install following the same provisioning steps so the tenth gateway went on like the first. Role-based dashboards arrived in this window, one cut for dispatch, one for operations, one for maintenance, each showing the data that role acts on and little else.

Weeks nine to twelve were about signal quality. Thresholds were tuned to cut alert noise, the weekly KPI reports were locked into a template, and workflows moved to exception-first: the system stayed quiet until something genuinely needed attention, then escalated. Less to watch, nothing important missed.

After full rollout and the optimization period, the customer reported roughly a 25% increase in asset utilization. It came from fewer idle machines, faster allocation calls, and rentals that no longer covered for assets already sitting unused elsewhere. A trusted, shared definition of utilization was doing the work.

Dispatch tightened up. With one agreed view of asset status, the back-and-forth fell away and assets moved across depots faster, with less confusion about what was actually available.

Vendor dependency dropped sharply. Alert and KPI changes that once waited a quarter now shipped in days, because the OEM made them. Per-feature change fees and the recurring licensing line went away, and the telematics stack moved on the OEM's roadmap instead of someone else's. The clearest lesson was that the win came from better signals and a shared operational truth, not from collecting more data.

Owning the gateway IP carried the project. With full control of the edge stack, the OEM could change it on its own schedule, which is what turned a quarterly wait into a same-day fix.

The single telemetry schema did the quiet, structural work. One set of definitions across the fleet meant no two dashboards disagreed and no two regions argued about a KPI.

Exception-first workflows kept the system livable. Nobody had to babysit a dashboard; the system asked for attention only when it was warranted, which is what makes a setup like this last past the first month.

Connectivity-resilient design held trust together. Local buffering and store-and-forward transport meant a coverage gap delayed data rather than losing it, and a telematics system that quietly drops readings is one operators stop believing.

Measure before you change anything. Without a baseline captured in the pilot, the 25% improvement would have been a claim, not a result. The pilot's early numbers are what let the team prove the change rather than assert it.

Owning the edge is what buys speed. Because the OEM held the stack, changes landed in days instead of waiting on a vendor release, a difference no proprietary platform offered.

KPIs only count if they match how people work. Metrics that mirrored the dispatch workflow got used every day; metrics that did not were quietly ignored, whatever their dashboard looked like. Fit the telemetry to the process, and the investment pays back.

For any OEM running assets across multiple sites, the pattern here repeats. Start from an open gateway stack you own, which settles the IP question and ends the lock-in before it starts.

Define the telemetry schema once, so a number means the same thing in every region and there is nothing left to dispute. Then build the dashboards around the dispatch workflow rather than around the data, so the telemetry drives decisions instead of sitting unread.

Keep the alerting exception-based. Attention goes to what needs action, not to a wall of green tiles, and that is what keeps a fleet telematics system useful long after launch, while it is still doing real work on utilization and uptime.