Telematics Edge Application

Rust, Embedded Linux, CAN bus, RTOS, MQTT, TLS

The Problem

Pierce Manufacturing needed a way to collect, encrypt, and transmit vehicle telematics data from their fire apparatus in the field. The system had to:

• Read data from multiple CAN buses in real time
• Encrypt and filter it at the edge
• Transmit it over cellular to the cloud
• Be secure by design - the hardware unit is field-accessible for service, but application-level access has to go through authentication

No existing off-the-shelf solution met all the constraints. So I designed and built one from scratch.

The Architecture

The system has two main layers:

Data-point collector (RTOS, HCS12) A dedicated microcontroller running a real-time OS. Its only job: aggregate sensor data from multiple CAN buses and present it over a dedicated channel to the application processor. This separation means the real-time data collection is never blocked by higher-level operations (encryption, cloud connectivity).

Edge application (Rust, embedded Linux) The main application runs on an embedded Linux board. It reads data from the collector, applies business logic (filtering, aggregation), encrypts it, and transmits it to the cloud over cellular. Written in Rust for memory safety and reliability —- a crash in the field means losing telemetry on an active emergency vehicle.

Key Design Decisions

Security as the primary constraint. The hardware is in a service-accessible location on the truck. The application processor had to be locked down — authenticated access only, encrypted storage for credentials, TLS for all network communication. No unauthenticated debug interfaces in production.

Rust over C++ for the edge application. Memory safety without a GC, strong type system, and the embedded ecosystem was mature enough. The telematics workload is I/O-bound (CAN → encrypt → transmit), not compute-bound, so Rust's zero-cost abstractions fit naturally.

Separate collector for real-time data. Rather than having the Linux application talk to CAN controllers directly (which introduces scheduling latency), a dedicated RTOS microcontroller handles the real-time bus access. This also isolates the timing-critical path from the complexity of the Linux networking stack.

The Debugging That Shaped It

Two bugs found during development became design inputs for the next-generation architecture:

Wig-wag light timing failure. A 10ms RTOS task handling both timer updates and CAN queue processing would occasionally overrun, skipping the timer tick. The fix (moving the timer to a 1ms task) was simple, but the root cause - CAN queue processing could exceed its timeslice on trucks with many options - became a sizing requirement for the next controller.

CAN message corruption. A race condition in the vendor's CAN driver - a mutex released between copying message ID and message data - caused occasional spliced messages on ~5% of trucks. Reproduced on a bench running hand-crafted CAN traces for days. Patched the driver and rolled out to all active customers.

What I Learned

This was the kind of project I love - figuring out the goals, finding the pain points, and assembling the right technology to address them. Every decision had a reason, and every constraint came from an actual operational need rather than a theoretical requirement.

The two years from concept to production taught me that the hardest part of embedded systems design isn't the code - it's the boundary between hardware and software, the real-time constraints, and the security model that has to survive physical access.