Cold Chain Telemetry: Open Owasys Linux Gateway

The fleet ran around 600 refrigerated trailers, a mix of Carrier Vector and Thermo King SLXi reefer units, hauled by a mixed tractor pool. Onboard, every trailer carried its own miniature stack:

• A Carrier or Thermo King controller speaking its own proprietary serial protocol, paired with the OEM's cloud subscription.
• A separate GPS tracker on an Orbcomm- or Spireon-style platform, with its own SIM and its own dashboard.
• A standalone door sensor with another SIM and another monthly fee.
• For HACCP customers, a temperature data logger that only spoke USB at the depot.

Four devices per trailer. Four data plans. Four cloud platforms. Four invoices. Five different APIs to reconcile if anyone ever wanted to ask a question that touched more than one of them.

Vendor lock-in across the trailer. Every component came with a platform fee. Telemetry the operator was already paying connectivity for had to round-trip through the vendor's cloud before anyone could see it. The operator never held their own data. They held a subscription to a copy of it.

Multi-protocol fragmentation. Carrier's IntelliSet serial and Thermo King's DSR are not compatible. The GPS tracker spoke NMEA on a separate UART. The door sensor was 1-Wire. No off-the-shelf device natively spoke all of them, so the fleet stayed on four boxes per trailer to cover the same surface area.

Per-device cost that scaled with the fleet. Every trailer added four SIMs, four platform subscriptions, four invoices. A hundred more trailers meant four hundred more SIMs. Connectivity cost grew roughly linearly with fleet size. Operational value did not.

We replaced all four devices with a single Owasys owa4x running Debian Linux. The owa4x has the I/O footprint to cover everything a refrigerated trailer needs in one place:

• RS-485 and RS-232 UARTs, one for the reefer controller, one spare for an OBC, driver tablet, or future probe.
• CAN J1939, for engine and chassis data from the tractor.
• 1-Wire / I²C, for the door sensor and trailer-mounted probes.
• Internal multi-constellation GNSS.
• LTE Cat-4 cellular modem with dual SIM.
• Wide-range automotive DC input, sealed enclosure, full operating-temperature envelope.

The embedded software is ours to ship and the customer's to own. Data publishes via MQTT to their broker, they chose AWS IoT Core, but the contract is portable if they ever want to leave.

The technical achievement is in the embedded application, not the hardware. The owa4x has the ports; what made the consolidation work is software that understands every protocol the fleet actually uses, running together on a single board.

The implementation: one Linux process per protocol, each isolated and individually restartable. The reefer-controller adapter speaks both Carrier IntelliSet and Thermo King DSR on the same serial line, switched by configuration per trailer. The CAN process decodes J1939 PGNs from any J1939-compliant tractor. GPS, door state, and modem health all publish through the same MQTT topic hierarchy with a consistent schema.

When the customer adds a new reefer model in two years, they don't replace the gateway. They write or commission one more adapter.

The old stack polled. Every device reported on a fixed cadence whether or not anything had changed, so the cellular bill charged the same for an empty heartbeat as for a real event. On a refrigerated trailer most telemetry doesn't move between polls: the setpoint is stable, the door is closed, the truck is on the highway.

The new software publishes on state transitions: setpoint change, door open, alarm, geofence crossing, defrost cycle start. A periodic heartbeat covers the gaps so the platform knows the device is still alive. Across a one-hour window on a moving trailer, the new stack publishes a handful of events where the old stack would have sent dozens of full payloads.

Fifty trailers in the pilot, a representative mix of reefer brands and tractor pairings. We instrumented both old and new stacks in parallel for two months to catch any quiet data dependencies the field engineers had been relying on. Then full rollout over six months, depot by depot, retiring one vendor subscription per wave.

By month nine, every trailer was on Owasys hardware and the four original subscriptions were gone. The only ongoing cost on the trailer was the customer's own SIMs.

Per-trailer device count: 4 → 1. Less wiring, less power draw, fewer field-failure modes, faster installs at the depot.

Cloud ingestion volume down ~70%. Event-driven publishing replaces the polling loops of the old stack.

SIM and connectivity spend down ~40%. One SIM per trailer instead of three or four, on a carrier mix chosen for route geography rather than vendor convenience.

Platform subscription fees: eliminated. The reefer OEM's cloud is still there for warranty support; the customer no longer pays for it as a data path.

IP ownership. The embedded software, the data model, and the MQTT contract were all transferred at handover. There is no Melqart subscription on the trailer.

Cold chain doesn't have one big vendor lock-in. It has four: the reefer manufacturer, the tracker provider, the auxiliary sensor vendor, and (usually) the cloud platform attached to whichever of those was loudest at procurement. Each one charges for access to data the operator already paid the connectivity bill on.

An open Linux gateway clears all four at once. The hardware is open and supportable, tied to no one's roadmap. The software belongs to the customer. The protocols stay negotiable, because the code reading them is a Linux process, not closed firmware.

The pattern reproduces in any fragmented fleet space: construction equipment rental, waste collection, agricultural contractors. Cold chain is the cleanest example because the cost per trailer is the easiest to count.