THE TRUCK DATA WAS ALWAYS LATE. And for a global heavy truck brand, "late" has a specific cost.

A dealer in Southeast Asia submits a warranty claim. The OEM's platform shows the vehicle's engine data from three days ago. The service team doesn't know if the fault is active or resolved. They schedule a technician anyway. The technician arrives. The fault cleared itself two days prior.

That appointment cost money. The customer waited unnecessarily. The complaint goes into the system.

Multiply this by a fleet of vehicles distributed across dozens of markets, each operating under different emissions regulations, each generating data that arrives late, incomplete, or in formats the platform can't parse correctly.

This was the operational reality for one of the world's most recognized heavy truck manufacturers — a brand with a reputation built on engineering precision, running on data infrastructure that couldn't keep up.

THE CLIENT

A globally recognized heavy truck manufacturer with significant market presence across Asia, Europe, and emerging markets. Their vehicles carry a reputation for safety and durability that takes decades to build.

Their telematics data infrastructure did not match that reputation.

TWO PROBLEMS. ONE ROOT CAUSE.

The complaints coming in from dealers and fleet operators pointed to two separate issues. They had the same source.

Problem one: Vehicle maintenance and service response was slow and disjointed. When a vehicle triggered a fault or required scheduled maintenance, the data reaching the service platform was delayed. Dealers were working with stale information. Appointment scheduling was reactive and often wrong. Customer complaint rates on service responsiveness stayed persistently high.

Problem two: The OEM's global carbon compliance monitoring was unreliable. Different markets operate under different emissions regulations. The system couldn't accurately identify which regulatory environment a given vehicle was operating in. Data that should have enabled precise regional compliance management was producing ambiguous outputs that required manual verification to resolve.

The instinct is to treat these as separate problems requiring separate fixes. They weren't.

Both failures traced back to the same architectural flaw: the data transmission layer between the vehicle's onboard systems and the OEM platform was introducing delay, data loss, and format inconsistency at scale. The problem wasn't what data was being collected. It was how it was getting from the vehicle to the people who needed to act on it.

THE DECISION THAT WENT AGAINST INDUSTRY CONVENTION

When the engineering team mapped the transmission architecture, the standard industry solution was available and obvious: implement MQTT or Kafka-based transmission protocols. Both are widely adopted. Both have large support ecosystems. Both would have been defensible choices.

We recommended against both.

Here's the reasoning.

MQTT and Kafka are intermediary-dependent architectures. Data moves from the vehicle to a broker layer, then to the platform. Each hop introduces latency. In stable, controlled environments with predictable network quality, this is manageable. In the real operating environment for this client — vehicles across Southeast Asia, the Middle East, and other markets with inconsistent cellular coverage, varying network protocols, and regulatory data handling requirements — each intermediary hop was a point where data could be delayed, dropped, or corrupted.

The alternative was a full-stack device-side parsing and direct reporting architecture. Instead of sending raw data to a broker for processing, the onboard device parses and encrypts the data locally, then transmits it directly to the OEM platform in the exact format the platform expects.

The trade-off: this approach requires deeper device-level development. The hardware has to be smarter. The firmware has to handle what the broker layer used to handle. Development time goes up. The device itself is more complex.

The result: fewer transmission hops, lower latency, no intermediary failure points. Data arrives at the platform in the correct format without requiring transformation on receipt.

For a manufacturer whose service quality depends on acting on accurate vehicle data in near real time, the trade-off was worth making.

WHAT ACTUALLY GOT BUILT

The hardware: a custom 4G hardwired device — the VF95 — developed specifically for this truck series. CAN bus interface for direct access to the vehicle's data network. Encrypted chipset handling local data security before transmission. RS-485 port reserved for future expansion without requiring hardware replacement.

The software: full-stack protocol implementation matching the OEM's proprietary data format exactly. The device doesn't send generic telematics data and ask the platform to interpret it. It sends data pre-formatted to the OEM's specification, covering engine RPM, VIN, fuel consumption, idle state, braking data, and odometer readings — all encrypted, all transmitted directly.

The development process ran six months from project initiation to field deployment. Software and hardware teams worked in parallel. Testing covered extreme operating conditions: high temperature, low temperature, rough terrain, marginal network environments. The device had to work reliably across the OEM's full vehicle range, not just the models in the initial deployment scope.

THE NUMBER THAT MATTERS MOST

20,000 units shipped.

Zero return-to-manufacturer repairs.

That number deserves a moment. In hardware manufacturing, a zero defect return rate across 20,000 units in field deployment is not a target. It is an outcome that requires six months of engineering discipline, multi-environment stress testing, and the kind of quality control that doesn't show up in a spec sheet.

For the OEM's procurement and engineering teams, this number answers a question they would otherwise have to ask: does this device actually hold up in the conditions our vehicles operate in?

The answer is documented across 20,000 data points.

WHAT CHANGED

THE ARCHITECTURE QUESTION WORTH ASKING

If your vehicle data is passing through an intermediary broker before reaching your platform — MQTT, Kafka, or any equivalent — you have introduced latency and failure points between your vehicles and your ability to act on what they're telling you.

For most use cases, this is an acceptable trade-off.

For a manufacturer running service operations across markets where network reliability varies, and compliance obligations where data accuracy is a regulatory requirement, the question is whether 'acceptable' is good enough.

GET THE TECHNICAL DETAILS

For engineering and implementation teams: Download the Veyloc VF95 Hardware Technical Specification Includes CAN bus interface documentation, encryption chipset specifications, RS-485 expansion port protocols, and OEM-format data packaging implementation guide. → [Download VF95 Technical Spec Sheet (PDF)]