Skip to content

Software Entwicklung

Jump to bottom
mariuste edited this page May 20, 2026 · 4 revisions

On-Device Software & Firmware

Die Software-Architektur dieses Projekts ist zweigeteilt, um den unterschiedlichen Anforderungen an Echtzeitfähigkeit, Benutzeroberflächen und Rechenleistung gerecht zu werden. Ein zentrales Element für beide Welten ist die Fähigkeit zur Fernwartung (OTA), um die Flotte von über 30 Geräten effizient zu verwalten.

Over-The-Air Updates (OTA)

Bei einer Infrastruktur dieser Größenordnung ist der manuelle Zugriff auf die Hardware für Software-Updates ausgeschlossen.

  • Zentrales Deployment: Sowohl die RP2040-Firmware als auch die Docker-Container der Terminals müssen über ein zentrales Management-System aktualisiert werden können.
  • Sicherheits-Rollbacks: Jedes Update-Verfahren muss so konzipiert sein, dass das Gerät bei einem fehlgeschlagenen Update automatisch auf die letzte funktionierende Version zurückfällt.
  • Versionierung: Jedes Gerät meldet seine aktuelle Software-Version bei jedem API-Call an die easyVerwaltung, um den Flottenstatus transparent zu halten.

OTA-Fleet-Plan (in Arbeit)

Ein detaillierter OTA-Plan existiert unter firmware/projects/RFIDBOX_PoC/OTA_FLEET_PLAN.md:

  • Manifest-Server mit Channel-System (stable, beta, canary)
  • Plattform-spezifische Firmware-Pfade (esp32/0.1/, picow/1.0/)
  • A/B-Fallback für ESP32, Streaming-Dekompression für Pico W
  • Discovery via mDNS (rfidbox-*.local)

Embedded Firmware (Machine Nodes)

Die Firmware der Machine Nodes ist auf maximale Zuverlässigkeit und deterministisches Verhalten ausgelegt. Hier wird direkt mit der Hardware interagiert.

  • Technologie-Stack: C++ auf Basis von PlatformIO. Die Nutzung der RP2040-spezifischen PIO-Hardware (Programmable I/O) garantiert präzises Timing bei der Kommunikation mit RFID-Readern und Sensoren, unabhängig von der CPU-Auslastung durch Netzwerkaufgaben.
  • State-Machine Architektur: Die gesamte Logik ist als endlicher Automat implementiert. Dies verhindert undefinierte Zustände und sorgt dafür, dass die Maschine bei jedem Fehler (WLAN-Verlust, Sensorfehler) in einen definierten Sicherheitszustand wechselt.
  • Offline-Sicherheit: Falls die API nicht erreichbar ist, entscheidet der Node anhand lokaler Sicherheitsregeln, ob der Betrieb fortgesetzt werden darf oder die Maschine gesperrt wird.

Aktuelle Projekte

Projekt Status Hardware API Beschreibung
RFID_BOX_legacy ✅ Läuft ESP32 + MFRC522 Alte API (GET) PlatformIO-Migration der alten RFID-Box
RFID_BOX_easyVerwaltung 🔄 In Entwicklung ESP32 + MFRC522 Neue API (POST/JSON) easyAPI integriert, Login-Flow validiert (rfid-box/v0.1.0)
MachineNodes 🔄 In Entwicklung RP2040/Pico W + PN532 Neue API (POST/JSON) Modulare Node-Architektur

Migrationspfad

  1. RFIDBOX_PoC — Läuft auf alter Hardware (ESP32 + MFRC522) mit altem API-Design. Dient als Proof-of-Concept für PlatformIO.
  2. MachineNodes — Neue Architektur für RP2040 mit:
    • RFIDNode-Klasse (Zustandsmaschine)
    • Pn532Reader (PN532 via I2C)
    • ApiClient für neue REST-API
    • OtaUpdateManager für Fleet-Updates

OS-Based Applikationen (Terminals)

Auf den Smart- und Main-Terminals steht die Programmiererfreundlichkeit im Vordergrund. Wir nutzen bewährte Web-Standards, um die Einstiegshürde für neue Entwickler so gering wie möglich zu halten.

  • Web-Frontend im Kiosk-Modus: Die Benutzeroberfläche wird als moderne Webseite (HTML/JS/CSS) realisiert. Diese läuft auf dem Terminal in einem abgesicherten Browser-Kiosk-Modus. Dies erlaubt schnelles Prototyping und einfache Anpassungen des Designs ohne Cross-Compiling-Aufwand.
  • Containerisierung (Docker): Die gesamte Applikations-Logik und der Webserver werden in Docker-Containern gekapselt. Das garantiert, dass die Software auf jedem Raspberry Pi identisch läuft und Updates (via Docker Pull) absolut zuverlässig funktionieren.
  • Programmiererfreundlichkeit: Durch den Einsatz von Web-Technologien können auch Entwickler ohne Embedded-Erfahrung UI-Elemente gestalten oder API-Anbindungen implementieren.
  • Lokaler Cache: Ein lokaler Dienst sorgt dafür, dass kritische UI-Zustände gepuffert werden, damit das Terminal auch bei instabiler Internetverbindung flüssig reagiert.

API-Kommunikation & Datenverwaltung

Die Kommunikation zwischen Hardware und der easyVerwaltung erfolgt über eine strukturierte REST-Schnittstelle.

Aktuelle API (Legacy/PoC)

GET /machine_try_login/{token}/{name}/{id}/{uid}
  • Token in der URL (unsicher)
  • Kein JSON, kein strukturiertes Session-Management
  • Wird von RFIDBOX_PoC verwendet

Neue API (in Betrieb — validiert auf RFID_BOX_easyVerwaltung)

Spezifiziert in docs/reference/embedded-machine-client-requirements.md:

POST /api/service/machine/login
X-Service-Token: <token>
Content-Type: application/json

{
  "serviceId": "svc_lathe_01",
  "rfid": "04AABBCCDD11",
  "mode": "heartbeat"
}
  • Service-Token im Header (sicher)
  • Heartbeat-Modus für Dauersessions
  • Single-Modus für einmalige Aktionen
  • Klare Fehlercodes: QUALIFICATION_MISSING, SESSION_TIMEOUT, etc.
  • JSON-basiert mit ArduinoJson
  • Status-Reporting: Jedes Gerät sendet regelmäßig Telemetriedaten (Heartbeat, Uptime, Signalstärke) an das Backend.
  • Zentrale Logik: Die Hardware ist "dumm". Sie trifft keine eigenständigen Entscheidungen über Berechtigungen oder Preise, sondern setzt die Antworten der API ("Access Granted/Denied") physisch um.
  • Zentrales Logging: Fehlermeldungen der Hardware werden an einen zentralen Log-Server übertragen, um Probleme aus der Ferne diagnostizieren zu können, bevor ein Techniker vor Ort sein muss.

Clone this wiki locally