Building a Rust Orchestration Framework for Heterogeneous IoT + ML Systems

The central problem in edge AI is that the devices that generate the most valuable data are the ones furthest from where ML models live. A temperature sensor on I2C, a smartphone over BLE, and a laptop over TCP/IP speak completely different languages — and no existing framework speaks all three while also enabling ML gradient exchange between them.

This post walks through the architecture of the Cognitive Mesh Orchestration Framework v0.1 — a Rust prototype I built as the proof-of-concept for my PhD research proposal.

The Core Insight: Gradients Are Just Payloads

The key architectural decision that makes everything work is treating ML gradients as a first-class payload type alongside conventional data bytes. Most distributed ML frameworks treat the communication layer as a transport concern below the ML logic. We inverted this.

``rust

pub enum Payload { Data(Vec), // sensor readings, commands Gradient(Vec), // ML gradient vector WeightDelta(Vec), // federated weight update Control(String), // ping, register, ack } `

Once you have a Payload enum, you can wrap it in a typed Envelope and route it through any protocol — I2C, BLE, or TCP/IP — without the upper layers knowing or caring which transport was used.

The Five-Crate Architecture

The workspace is split into five crates with strict upward-only dependencies:

- cm-hal — Hardware Abstraction Layer. Protocol-agnostic CmTransport traits. No ML logic.

- cm-broker — Message Broker. Envelope format + routing engine. No agent logic. - cm-agent — Agent Layer. Local training, gradient exchange, FedAvg. No protocol knowledge. - cm-weights — Final Weighted Interface. Cross-layer routing registry. - cm-node — Simulation binary. Three nodes, eight rounds, 98.2% loss reduction.

The key rule: each layer can only import the layer below it. cm-agent never imports cm-hal. cm-hal never imports cm-broker. This is enforced by the Cargo dependency graph.

The Simulation Results

Running cargo run --bin cm-sim simulates three nodes — one I2C IoT node, one BLE mobile node, one TCP laptop — learning the function y = 2·x₀ + 3·x₁ + 1 through federated learning without sharing raw data.

Loss dropped from 9.45 → 0.17 across 8 rounds. The mobile node's final prediction on the test input was 6.162 against an expected 6.0 — 2.7% error from gradient exchange alone.

## Moving to Real Hardware

This is where the architecture pays off. Replacing simulated I2C with real Raspberry Pi I2C is three lines:

`rust

// Swap this: let transport = SimI2cTransport::new(0x48, bus.clone());

// For this (same trait, real hardware): let i2c = rppal::i2c::I2c::new().unwrap(); let transport = RpiI2cTransport::new(0x48, i2c); `

The broker, agent, and weighted interface layers are completely unchanged. The architecture isolates the hardware concern exactly where it belongs.

What's Next

The next step is extending cm-agent` to use a real PyTorch HAR model via a Python FFI bridge — replacing the linear regression placeholder with a neural network classifying WiFi CSI human activity data across a real Raspberry Pi + Android + laptop mesh over the CWC 5G testbed.

The full source is available at github.com/cognitive-mesh-lab/cognitive-mesh.