Kontext
Ein Tracker, der tagelang Energie sparen soll, hat andere Anforderungen als einer, der während des Trainings laufend Positionen sendet. Das Team untersuchte deshalb unterschiedliche GNSS- und Mobilfunkmodi sowie Wege für kleine und größere Datenmengen.
Ansatz
Ich arbeitete an der Mikrocontroller-Firmware und der Integration mit AWS IoT Core und Lambda. Die übrige Web- und Cloud-Architektur beschreibe ich als Teamleistung, nicht als individuelle Implementierung.
System
- Tracker: Arduino MKR Zero mit ATSAMD21G18 (ARM Cortex-M0+), GNSS, Sensorik und Quectel BG96 für GSM, LTE-M und NB-IoT
- Firmware: Echtzeit- und Stromsparmodus, Deep Sleep, MQTT und HTTP
- Kleine Datenmengen: HTTP/API Gateway; größere Messströme: AWS IoT Core und MQTT
- Cloud: Mode Handler Lambda, SQS als Puffer und Data Handler Lambda
- Team-Websystem: Vue.js, Node.js/Express und MongoDB/Mongoose mit REST-API und wiederholtem Positionsabruf
Technische Entscheidungen
- Übertragungsweg und Standortstrategie nach Datenvolumen und Nutzungsszenario wählen.
- Die asynchrone Fire-and-Forget-Verarbeitung durch SQS entkoppeln, damit Nachrichten nach dem Ende einer Lambda-Ausführung nicht verloren gehen.
- JWT, Passwort-Hashing mit Salt, Autorisierungsmiddleware und Ressourcenbesitz im Team-System berücksichtigen.
Was nicht funktioniert hat
Die erste asynchrone Verarbeitung konnte Daten verlieren, wenn der Prozess endete, bevor die ausstehenden Arbeiten abgeschlossen waren. SQS gab den Nachrichten einen dauerhaften Puffer. Das Projekt untersuchte unterschiedliche Übertragungsarten; die Dokumentation belegt keine produktiven Flotten- oder Geschäftszahlen.
Ergebnis
Der dokumentierte Systementwurf verbindet zwei Tracker-Modi mit HTTP/API Gateway oder AWS IoT Core/MQTT und einer entkoppelten Verarbeitung über Lambda und SQS. Die Webanwendung zeigt Positionen, Strecken und Geofences.
Was ich mitgenommen habe
Die Queue war keine Architekturdekoration. Sie löste einen konkreten Fehlerfall: Eine Nachricht brauchte einen Ort, an dem sie warten konnte, bis der nächste Verarbeitungsschritt sie tatsächlich übernommen hatte.
Mein Beitrag
Mein Beitrag laut CV: C/C++-Mikrocontroller-Firmware sowie Integration mit AWS IoT Core und AWS Lambda. Vue, Node.js/Express, MongoDB, Authentifizierung und Deployment gehören zur Teamarchitektur; ich schreibe sie mir nicht pauschal allein zu.
Zwei Wege durch die Cloud
Der Tracker konnte wenige Daten über HTTP/API Gateway senden. Bei größeren Messmengen war MQTT über AWS IoT Core vorgesehen. Ein Mode Handler leitete die Daten je nach Modus weiter. Für den Verarbeitungspfad nahm SQS Nachrichten an; ein Data Handler konnte sie unabhängig von der ursprünglichen Ausführung abarbeiten.
Warum die Queue hineinkam
Der erste Fire-and-Forget-Ansatz startete asynchrone Arbeit und beendete den Prozess, ohne auf alle ausstehenden Schritte zu warten. Wenn die Ausführung endete, konnten Daten verloren gehen. Mit SQS blieb die Nachricht bestehen, bis ein weiterer Handler sie verarbeitete und bestätigte.
Webanwendung im Team
Das Gesamtsystem umfasste ein Vue.js-Frontend, Node.js/Express, MongoDB mit Mongoose und REST-APIs. Die Oberfläche zeigte Tracker, Strecken, Geofences und Messwerte; Positionen wurden wiederholt abgefragt. Die Dokumentation beschreibt außerdem JWT, gehashte Passwörter, Autorisierung, getrennte Docker-Container und einen AWS-EC2-Betrieb.