Resume
Dette blogpost præsenterer arkitekturen og de centrale designprincipper bag en sikker IoT-gateway skrevet i Rust. Systemet forbinder STM32-baserede edge-enheder med cloud-analyse via MQTT, SQLite WAL-persistens, OpenTelemetry traces og Prometheus-metrics. Den viser, hvordan man bygger pålidelighed, observability og sikkerhed ind fra starten — med praktiske indsigter fra virkelige projekter.
Introduktion
At bygge IoT-systemer, der både kan skaleres sikkert og køre stabilt i drift, er en af de største tekniske udfordringer. Jeg har set virksomheder miste kritisk telemetri, opleve data-gaps eller kæmpe med softwareopdateringer, fordi pålidelighed og observability først blev tænkt ind for sent.
Som en del af mit konsulent arbejde hos Combotto.io satte jeg mig for at bygge en Rust-baseret IoT-gateway, der demonstrerer, hvordan man forbinder STM32-edge-enheder til cloud-infrastruktur med indbygget pålidelighed, observability og sikkerhed — de samme arkitekturprincipper jeg anvender, når jeg auditerer og hardener produktions-IoT-infrastrukturer for kunder.
Dette indlæg gennemgår system-designet fra edge til cloud og viser konkrete implementeringsstrategier, arkitektur-viewpoints og erfaringer fra reelle deployment-scenarier.
Baggrund – Designfilosofien
Inspireret af arkitekturperspektiverne hos Rozanski og Woods [1] — såsom sikkerhed, performance & skalerbarhed, tilgængelighed og robusthed — arbejder jeg med IoT-gateway-design ud fra samme tankegang. For at opnå produktionskvalitet og møde kunders forventninger, lægger jeg vægt på tre styrende perspektiver:
- Pålidelighed: Hver besked skal overleve netværksfejl (WAL + retry-logik).
- Observability: Traces og metrics skal tydeligt vise, hvad systemet foretager sig.
- Sikkerhed: Fra autentificering af enheder til krypteret telemetri og hardening.
Disse perspektiver former, hvordan jeg strukturerer IoT-systemer end-to-end — fra embedded enheder i felten, gennem gateway-laget, til analyse- og monitoreringssystemerne i skyen.
Arkitekturoverblik — Fra edge til cloud
Dette afsnit gennemgår arkitekturen for Rust IoT-gatewayen (edge-to-cloud) og beskriver context & scope samt de funktionelle elementer, deres ansvar og grænseflader.
Context & Scope
For at forstå gatewayens kontekst og afgrænsning bruges et Context Viewpoint-diagram til at vise systemrelationer og interaktioner med eksterne aktører, når der designes med fokus på pålidelighed, observability og sikkerhed. Diagrammet viser et edge-to-cloud setup, hvor en STM32-sensor kommunikerer med en edge MQTT-broker. Edge-brokeren kommunikerer med Rust-gatewayen via en MQTT-klient, som abonnerer på de emner STM32-sensoren publicerer data til. MQTT-klienten persisterer data i en write-ahead log (WAL-kø) og sender dem derefter videre mod cloud-laget.
Gatewayen er skrevet i Rust og kører som en enkelt containeriseret instans på en edge-host (x86/ARM). Gatewayen indeholder ingest-funktioner mod devices, en holdbar kø, behandling, cloud-publisering og observability.
Eksterne services / aktører
Systemet interagerer med flere eksterne aktører og services:
- Enheder (STM32-sensorer): publicerer telemetri via MQTT og modtager control-beskeder.
- Cloud Backend-services:
- Analytics Service (HTTP/gRPC ingest)
- S3 (objektstorage til arkivering)
- Prometheus (scraper metrics)
- Tempo/OTLP Collector (modtager traces)
- Grafana (visualiserer metrics og traces)
- Operator/Admin: interagerer via Admin API og logs.
Disse eksterne systemers interne detaljer er uden for scope.
Demo video af gateway med gennemgang af edge-to-cloud data flow
Videoen nedenfor giver indblik i hvordan arkitekturen virker i virkeligheden med gennemgang af hele edge-to-cloud dataflowet ved brug af fysiske STM32-enheder. Netværksafbrydelser introduceres bevidst for at vise, hvordan gateway'en absorberer fejl, buffer telemetri robust og genoptager leveringen uden datatab.
Funktionelle elementer & ansvar
De funktionelle elementer består af deployerbare Rust-services/crates samlet i én containeriseret gateway-binær, organiseret som moduler.
Et Functional Viewpoint-diagram blev udarbejdet for visuelt at beskrive de funktionelle elementer med grænseflader og ansvar.
Her er en liste over de funktionelle elementer for Rust IoT-gatewayen – Ingest Plane.
MQTT Telemetry Client
Opretholder en robust MQTT-session for at ingest’e telemetri fra enheder og håndtere control-beskeder.
- Forbinder til edge MQTT-broker (lokal eller embedded) med konfigureret Client ID og credentials; vedligeholder sessionen og keep-alive.
- Abonnerer på telemetri- og control-emner (I1A & I6).
- Parser payloads (JSON/Protobuf), validerer format og sender videre til Ingest Router.
- Anvender QoS=1 semantics med automatisk reconnect og exponential backoff.
Ingest Router
Normaliserer indkommende telemetri og beriger den med gateway-metadata før holdbar persistens.
- Validerer/normaliserer payload (schema-version, størrelse, obligatoriske felter).
- Beriger med gateway_id, receive_ts, correlation_id.
- Producerer et kanonisk record og appender det til WAL-køen.
HTTP Server
Tilbyder en simpel ingest-vej for enheder/services, der ikke kan tale MQTT.
- POST /ingest/{device_id} accepterer JSON payload; autentificerer/autoriserer anmodningen (I1b).
- Genbruger samme validerings- og enrich-flow som MQTT (Ingest Router).
- Appender records til WAL og returnerer success med correlation id.
Config & Secrets
Gatewayen bruger et lagdelt konfigurationssystem, hvor defaults kan overrides af filer, miljøvariabler og CLI-flags. Dette giver sikker håndtering af secrets og fleksibel konfiguration på tværs af miljøer.
- Indlæser config via env/files → strongly typed config.
- Håndtering af certifikater/nøgler (I4).
Admin & Health API
Giver operativ indsigt og kontrol gennem et letvægts HTTP-interface.
- Eksponerer endpoints for liveness
/healthz, readiness/readyz, metrics/metricsog version/version(I2). - Integrerer med Prometheus og monitoreringsværktøjer til automatiske scrapes og alerts.
- Gør det muligt for operatører og CI/CD-pipelines at verificere tilstand før deployment eller genstart.
Control Plane
Muliggør styring af enheder og MQTT på edge-laget gennem pålidelig routing og politikker.
- Håndterer indkommende kommandoer via MQTT-emner (konfigurationsopdateringer, tests, osv.).
- Persisterer/anvender konfiguration og publicerer control-beskeder til enhederne.
Telemetry (Observability)
Telemetry indsamler systemets outputdata — logs, traces og metrics — som bruges til observability: forståelse af systemets interne tilstand via dets udgående data. Gatewayen anvender OpenTelemetry til tracing, Prometheus til metrics og struktureret JSON logging for yderligere indsigt.
- Tracing: spans for ingest, WAL append, publish, retry; eksporteret via OTLP til Tempo/collector.
- Metrics: Prometheus
/metricsendpoint (ingest rate, queue depth, publish success %, latency, CPU/memory IO). - Logging: strukturerede JSON-logs.
WAL Queue (Holdbar buffer)
Pålidelighed bygger på princippet om, at hver besked skal overleve netværksfejl. For at garantere at-least-once delivery bruges en append-only SQLite write-ahead log (WAL). Dette giver crash-safe recovery og idempotente retries — ideelt i edge-miljøer.
- Append-only WAL for at-least-once delivery.
- Status: Enqueued → InFlight → Acked/Dead.
- Kompaktering & retention.
- Backpressure thresholds.
- Crash-safe recovery.
- Idempotency keys.
Dispatcher
Koordinerer ingest ved at hente batches fra WAL-køen og håndtere flowet automatisk og pålideligt.
- run_dispatcher: hent N, markér InFlight.
- Kører publish(); planlægger retries.
- Ack’er WAL ved success.
Fanout
En FanoutSink<T> muliggør broadcast til flere downstream-sinks. Dette giver isolering af fejl per sink og muliggør levering til f.eks. S3, MQTT eller Kafka parallelt.
- Broadcast til flere sinks.
- Per-sink fejlisolering.
- Understøtter: S3, MQTT, Kafka.
Recovery Tools
Dashboards og værktøjer til at hjælpe operatører med incident-håndtering.
- Requeue eller eksport af dead-lettered meddelelser; understøtter replay.
- Diagnostik for mislykkede publishes og WAL-inkonsistenser.
Interfaces
Her er en liste over grænseflader for Rust IoT-gatewayen – Ingest Plane.
I1a. MQTT Telemetry Ingest
- Protocol: MQTT
- Topics: Subscribes:
devices/{device_id}/telemetry - QoS: 1 (at-least-once). Retain = false.
- Payload: JSON/Protobuf (konfigurerbart)
- Errors: invalid schema
I1b. HTTP JSON Ingest
- Protocol: HTTP
- Endpoint: POST
/ingest/{device_id} - Payload: JSON
- Errors: invalid schema
I2. Admin HTTP API
GET /healthz→ 200/500GET /readyzGET /metricsGET /version
I3. Observability Export
- Tracing: OTLP/HTTP → Tempo
- Metrics: Prometheus scrape
- Logs: stdout
I4. Config & Secrets
- Inputs: env vars
- Contract: typed schema med defaults.
I5. Local persistence (Lokal WAL)
- DB: SQLite WAL
- Durability: fsync + checkpoint.
I6. Control topics
- Device commands via MQTT
Deployment Viewpoint — Rust IoT Gateway (Edge → Cloud)
At designe IoT-systemer, der kører stabilt i felten, kræver mere end et funktionelt design. Deployment Viewpoint beskriver, hvor hvert element kører, hvordan komponenterne kommunikerer, hvilken infrastruktur der er nødvendig, og hvordan sikkerhed, pålidelighed og observability håndhæves i drift.
Dette afsnit forklarer det operative miljø for Rust IoT-gatewayen — fra STM32-enheder i felten, til MQTT-broker og gateway-containeren på edge-host’en, og videre til skybaserede observability- og analytics-services.
Runtime Platform & Deployment Topologi
På hvert site publicerer STM32-enheder telemetri over MQTT til en edge MQTT-broker, der kører på en Docker-host. En Rust-gateway-container konsumerer beskederne, persisterer dem i en lokal SQLite WAL og videresender dem sikkert via TLS til cloud analytics og observability services (Prometheus, Grafana, Tempo, Analytics, S3).
I den aktuelle reference-deployment er denne edge-host en Raspberry Pi 5 (4 GB RAM). Den er kraftig nok til at køre gateway-containeren, lokal WAL-storage og broker side om side, samtidig med at den holder footprintet lille nok til edge-installationer on-site.
Tabellen nedenfor viser komponenterne i runtime-platformen, deres containere, storage, porte og noter — mappet fra de funktionelle elementer.
| Component | Container | Storage | Ports | Notes |
|---|---|---|---|---|
| STM32 devices (B-L475E-IOT01A1) | Bare-metal firmware (ingen container) | On-board flash (firmware + config) | MQTT over TLS via Wi-Fi (client only) | Publicerer signeret telemetri til edge MQTT-broker ved brug af mTLS klientcertifikater. |
| Edge MQTT Broker | eclipse-mosquitto:2 | /mosquitto (config, certs) | 8883/tcp | mTLS; topic-ACLs for enheder og gateway. |
| Rust Gateway container | combotto/gateway:TAG | /data (SQLite WAL) | 8080/tcp | /metrics, /healthz, /readyz, /version; MQTT + HTTP ingest |
| Prometheus | Managed service eller prom/prometheus (Docker) | Lokal disk / managed storage | 443/tcp eller 9090/tcp | Scraper gatewayens /metrics og lagrer tidsserier. |
| Grafana | Managed service eller grafana/grafana (Docker) | Lokal disk / managed storage | 443/tcp eller 3000/tcp | Dashboard for Prometheus metrics og Tempo traces. |
| Tempo | Managed service eller grafana/tempo (Docker) | Object storage (S3/MinIO) eller lokal disk | 443/tcp eller 3200/tcp | Distribueret trace-lagring; tilgås via Grafana. |
| OTLP Collector | Managed service eller otel/opentelemetry-collector (Docker) | Stateless | 4317/4318/tcp, 443/tcp | Modtager OTLP-telemetri, batcher den og videresender til Tempo. |
| Analytics API | Backend service (Kubernetes / VM / Docker) | Application DB / data lake | 443/tcp | Modtager telemetri fra gatewayen over HTTPS (idempotent ingest). |
| S3 / Object Storage | Managed S3-kompatibelt storage | Bucket pr. miljø | 443/tcp | Valgfri offload/arkivering af telemetri. |
Runtime Platform Model Diagram
Runtime-platformmodellen beskriver den konkrete hardware og eksekveringsmiljøer, som hoster gatewayens funktionelle elementer. Modellen er organiseret i edge, gateway-host og cloud-noder.
Edge Site Nodes
| Processing node | Execution environment | Deployed artifacts | Notes / sizing |
|---|---|---|---|
| STM32 devices (B-L475E-IOT01A1) | STM32L475VG MCU, Arm Cortex-M4 @ 80 MHz, 128 KB SRAM, 1 MB Flash. Bare-metal eller RTOS-baseret firmware. Onboard sensorer: IMU, magnetometer, barometer, fugt/temperatur, ToF, mikrofoner m.m. | Firmware der sampler sensor-data, publicerer MQTT over TLS og lytter på control-emner. | Begrænset RAM/Flash betyder lille local buffering og begrænsede protokolstakke. Pålidelighed håndteres primært af MQTT broker + Rust Gateway WAL. |
| Edge MQTT Host (Raspberry Pi 5 eller industrial PC) | Linux (Ubuntu 24.04), ARMv8 eller x86-64, 2 vCPU, 4 GB RAM, Docker ≥ 24. | eclipse-mosquitto:2 container, TLS-certifikater og ACLs. | Typisk co-located med gatewayen; Raspberry Pi 5-referenceopsætningen holder footprintet kompakt og bevarer stabil Wi-Fi til STM32 boards. |
Valget af B-L475E-IOT01A1 (80 MHz, 128 KB RAM) påvirker gateway-designet markant: enheden kan ikke lave dybe køer eller tunge protokoller, så holdbarhed og retry-mekanismer flyttes til edge-broker + Rust Gateway WAL — et typisk mønster i constrained IoT.
Gateway Host Node
| Processing node | Execution environment | Deployed artifacts | Notes / sizing |
|---|---|---|---|
| Rust Gateway Host | Raspberry Pi 5 (4 GB RAM) eller separat industri-PC, 4 vCPU, 4-8 GB RAM, SSD ≥ 50 GB | combotto/gateway:TAG container, config, SQLite WAL under /data | Hoster ingest plane: MQTT, HTTP ingest, WAL, Dispatcher, Fanout, Admin API og telemetri. Raspberry Pi 5-deploymenten er den aktuelle referenceopsætning; WAL-størrelse afhænger af ingest-rate og forventet outage-vindue. |
I små installationer ligger MQTT broker og gateway på samme host. I større miljøer kan de separeres for bedre isolation.
Cloud / Datacenter Nodes
| Processing node | Execution environment | Deployed artifacts | Notes / sizing |
|---|---|---|---|
| Observability Node | Managed Grafana stack eller Kubernetes cluster | Prometheus, Tempo, OTLP Collector, Grafana | Samler metrics, traces og visualisering; konfigureres efter SLO’er. |
| Analytics API Node | Kubernetes deployment eller VM-pool | analytics-api container med ingest endpoint | Modtager telemetri via TLS; idempotent ingest forhindrer duplikater ved replay. |
| Object Storage Service | Managed S3-kompatibelt storage | Buckets: telemetry-offload, telemetry-archive | Langtidslagring/kompliance; omkostningsdrevet. |
Modellen nedenfor binder de funktionelle elementer sammen med deres konkrete runtime-lokationer:
- MQTT Client, Ingest Router, HTTP Server, WAL Queue, Dispatcher, Fanout, Admin API, Config & Secrets, Telemetry → kører i Rust Gateway-containeren.
- Control Plane interagerer med MQTT broker og STM32-enheder.
- Observability eksport (traces, metrics, logs) går til cloud Observability Node.
- Sinks (Kafka/S3/MQTT) sender downstream til Analytics API eller Object Storage.
Network Nodes & Communication Links
Ud over runtime-platformen beskriver Deployment Viewpoint også netværkslaget: hvordan komponenterne kommunikerer på tværs af edge-cloud-grænsen. Diagrammet viser sikre telemetristrømme fra STM32 → MQTT broker → Rust Gateway → cloud, samt protokoller, porte og trust boundaries.
Fra prototype til konsulentprodukt
Over de seneste måneder er denne gateway udviklet fra en teknisk prototype til fundamentet for mit konsulentarbejde hos Combotto.io — hvor jeg hjælper teams med at designe sikre, pålidelige og observerbare IoT-infrastrukturer.
Ved at gøre prototypen til en genbrugelig referencearkitektur bruger jeg den nu som blueprint i audits, hardening-sprints og længerevarende reliability-partnerskaber med kunder, der har brug for sikre edge-to-cloud flows.
Hvis du bygger noget tilsvarende og ønsker ekstern sparring, tilbyder jeg:
- Audit: Gennemgang af eksisterende IoT-dataflows og reliability-setup.
- Hardening Sprint: Kort, fokuseret forløb med forbedring af sikkerhed og observability.
- Reliability Partnership: Løbende samarbejde om at skalere jeres system sikkert.
Konklusion
At bygge IoT-systemer, der både er stabile og sikre, kræver mere end kode — det kræver de rette arkitekturperspektiver fra dag ét.
Denne Rust-baserede IoT-gateway fungerer som min referencearkitektur for, hvordan man forbinder embedded enheder med cloud-infrastruktur på en sikker og pålidelig måde. Jeg udvikler den løbende som en del af mit arbejde i Combotto.io.
Hvis du arbejder med connected devices og vil styrke data-pålidelighed, hardene telemetri-paths eller skalere med ro i maven, er du velkommen til at tage kontakt — jeg deler gerne indsigter eller hjælper dit team.
- Rozanski, Nick og Woods, Eoin. Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives (2nd Edition). Addison-Wesley, 2012.