Edge Computing: Rechenleistung am Rand – Nutzen und Betriebslast

Edge Computing verlagert Rechenleistung näher an den Ort, an dem Daten entstehen. Der Grund ist fast immer derselbe: Die Zeit, die Daten für den Weg in die Cloud brauchen, ist für die Anwendung zu lang – oder die Datenmenge ist zu groß, um sie vollständig zu übertragen.

Wann Edge sinnvoll ist

1) LATENZ unter 10 ms erforderlich
   - Maschinensteuerung, Robotik, Sicherheitsabschaltung
   - Augmented Reality, Fahrerassistenz
   - Echtzeit-Bildverarbeitung in der Produktion
   # Ein Weg in die Cloud kostet 20-100 ms. Bei einer
   # Maschine, die in 5 ms reagieren muss, ist das
   # unbrauchbar.

2) DATENMENGE zu gross fuer die Uebertragung
   - Kameras: 4K/60fps = etwa 12 GB pro Minute
     # 900 GB pro Stunde pro Kamera - unbezahlbar zu
     # uebertragen und meist sinnlos (95 % uninteressant)
     # Loesung: Am Rand auswerten, nur Ereignisse uebertragen
   - Sensoren mit hoher Abtastrate (Schwingungsanalyse)

3) DATENSCHUTZ und Souveraenitaet
   - Personenbezogene Videodaten verarbeiten, ohne sie
     zu uebertragen (Datensparsamkeit!)
   - Anlagen, in denen Daten das Werk nicht verlassen
   - Regulierte Branchen mit Vorgaben zum Verbleib

4) VERFUEGBARKEIT
   - Die Anlage muss auch ohne Internet arbeiten
   - Ausfall der Verbindung darf die Produktion nicht stoppen

WANN EDGE NICHT SINNVOLL IST:
   - Die Latenz der Cloud ausreicht (die meisten Faelle!)
   - Die Datenmengen klein sind
   - Der Betriebsaufwand am Rand (siehe unten) den
     Nutzen uebersteigt
   # Edge ist teuer im Betrieb. Wer es nur "weil modern"
   # einsetzt, zahlt fuer Aufwand ohne Nutzen.

Die Architektur

Ebene 1: Geraete / Sensoren
  Kameras, Sensoren, Steuerungen, Aktoren
  # Oft schon vorhanden, oft nicht updatefaehig!
  # Das ist ein Sicherheitsproblem: Ein Sensor von
  # 2015 bekommt keine Sicherheitsupdates mehr.

Ebene 2: Edge-Knoten (am Rand, in der Naehe der Geraete)
  Kleiner Server (x86 oder ARM), oft luefterlos
  Aufgaben:
    - Daten filtern, aggregieren, vorverarbeiten
    - Erste Auswertung (Modell laeuft lokal!)
    - Pufferung bei Verbindungsabbruch
    - Zeitkritische Regelung
  # Zwischenspeicherung ist PFLICHT: Bei
  # Verbindungsabbruch muss der Knoten weiterarbeiten
  # und spaeter nachliefern.

Ebene 3: Zentrale (Cloud oder eigenes Rechenzentrum)
  Aufgaben:
    - Langzeitanalyse und Schulung der Modelle
    - Verwaltung aller Edge-Knoten (Flottenmanagement)
    - Zusammenfuehrung ueber Standorte hinweg
    - Berichte, Dashboards
  # WICHTIG: Modelle werden hier trainiert und
  # dann auf die Knoten verteilt. Das Training
  # gehoert NICHT auf den Rand (zu wenig Rechenleistung).
  # Das Auswerten (Inferenz) gehoert auf den Rand.

Der Datenfluss:
  Sensor -> Edge-Knoten -> (gefiltert) -> Cloud
            ^
            lokale Entscheidung, wenn Latenz zaehlt

Was nach oben geht, sollte stark reduziert sein:
  Aggregierte Werte statt Rohdaten
  Nur Ereignisse statt Dauerstrom (Ausnahmen)
  Kuerzere Aufbewahrung am Rand (Speicher ist knapp)

Technische Umsetzung

# Hardware
#   x86 (Intel NUC, kleine Server) - vertraute Umgebung
#   ARM (Raspberry Pi, Jetson) - sparsam, oft mit GPU
#   Industrielle Steuerungen (SPS, IPC) - robust, aber
#     oft geschlossene Software
#
# Betriebssystem
#   Besser: unveraenderliche, abbildbasierte Systeme
#   (Container-OS wie balenaOS, Flatcar, K3s auf
#    schlankem Linux)
#   # Wichtig: Das System muss FERNAKTUALISIERBAR sein
#   # und im Fehlerfall auf eine bekannte gute Version
#   # zurueckfallen (A/B-Partitionen!).
#   # Ein Edge-Knoten, den man nur vor Ort aktualisieren
#   # kann, wird nicht aktualisiert.

# Werkzeuge
#   K3s / MicroK8s    Kubernetes in klein (gut fuer
#                     viele Knoten zentral verwalten)
#   Docker Compose    bei wenigen Knoten ausreichend
#   Balena            Flottenmanagement mit
#                     Fernaktualisierung und Fernzugriff
#   Azure IoT Edge,
#   AWS IoT Greengrass  Anbieterloesungen

# Beispiel: Container mit Ressourcengrenzen auf einem
# Edge-Knoten
#   services:
#     erfassung:
#       image: registry/erfassung:1.4.2
#       restart: unless-stopped
#       environment:
#         - LATENZ_SCHWELLE_MS=8
#         - PUFFER_DIR=/var/puffer
#       volumes:
#         - puffer:/var/puffer        # persistenter Puffer!
#       deploy:
#         resources:
#           limits:
#             cpus: '1.5'
#             memory: 512M
#       healthcheck:
#         test: ["CMD", "/app/health"]
#         interval: 30s
#       logging:
#         driver: json-file
#         options:
#           max-size: "20m"            # sonst volllaeuft der Knoten
#           max-file: "3"
#   # Ohne Protokollgrenze laeuft jede Speicherkarte irgendwann voll.
#   # Ohne persistenten Puffer gehen bei Verbindungsabbruch
#   # Daten verloren - der haeufigste Ausfallgrund im Betrieb!

# Fernaktualisierung mit Rueckfallebene (A/B)
#   Partition A: laufendes System
#   Partition B: neue Version wird geschrieben
#   Nach erfolgreichem Start: B wird aktiv
#   Startet B nicht: automatischer Rueckfall auf A
#   # Ohne diese Mechanik wird ein fehlerhaftes Update
#   # zum Vor-Ort-Einsatz.

Die harten Teile im Betrieb

1) SICHERHEIT AM RAND
   # Ein Edge-Knoten steht an einem Ort, an den
   # Unbefugte physisch gelangen koennen.
   Massnahmen:
     - Festplattenverschluesselung (Diebstahl!)
     - Gesicherter Start (UEFI Secure Boot, signierte
       Abbilder)
     - Keine unnoetigen Dienste, minimale Angriffsflaeche
     - Ausgehende Verbindungen einschraenken
       (der Knoten ruft an, nicht umgekehrt!)
     - Zertifikate je Knoten (nicht ein gemeinsamer Schluessel!)
     - Keine Standardkennwoerter (Zigarettenautomat-Falle)
   # Die Regel: Der Knoten wird als UNSICHERER Standort behandelt.

2) AKTUALISIERUNG
   # Ohne Fernaktualisierung und Rueckfall ist jeder
   # Knoten eine Zeitbombe: Wenn eine Schwachstelle
   # bekannt wird, kann man sie nicht schliessen.
   - Signierte Aktualisierungen (nicht aus dem Netz!)
   - Rollout in Stufen (erst 1 %, dann mehr)
   - Automatischer Rueckfall bei Fehlstart
   - Ueberwachung: Welche Knoten laufen mit welcher Version?
   # Die Versionsübersicht ist die wichtigste Kennzahl.
   # Knoten mit veralteter Version sind das offene Fenster.

3) UEBERWACHUNG
   # Wer ueberwacht die Ueberwachung? Ein Knoten, der
   # ausfaellt, meldet nichts - das ist kein Alarm,
   # das ist ein Blindfleck.
   - Herzschlag mit Zeitueberschreitung (fehlt er -> Alarm!)
   - Systemwerte: Temperatur, Speicher, Auslastung,
     Schreibzyklen der Speicherkarte (SD-Karten sterben!)
   - Groesse des Puffers
   - Zustand der Verbindung
   # Ohne Herzschlag mit Zeitueberschreitung merkt man
   # den Ausfall eines Knotens erst, wenn die Daten fehlen.

4) KOSTEN
   # Edge ist im Betrieb teuer:
   - Reisekosten bei Hardwareausfall
   - Ersatzteilbevorratung
   - Unterschiedliche Standorte mit unterschiedlichen
     Bedingungen (Temperatur, Feuchtigkeit, Strom)
   # Fuer 10 Knoten ist der Aufwand vertretbar.
   # Fuer 1000 Knoten braucht es ein Flottenmanagement
   # - sonst ist es nicht beherrschbar.

5) AUSFALL VON GERAETEN
   # Edge-Knoten sterben. Vorher fragen:
   - Was passiert bei Ausfall? (Produktionsstopp? Datenverlust?)
   - Gibt es Ersatzgeraete mit gleicher Konfiguration?
   - Wie lange dauert der Austausch?
   # Die Antwort bestimmt, ob Redundanz noetig ist.

Prüfliste

  1. Ist der Nutzen beziffert (Latenz, Datenmenge, Datenschutz) – oder ist „Edge“ eine Modeentscheidung?
  2. Können die Knoten aus der Ferne aktualisiert werden?
  3. Gibt es eine Rückfallebene bei fehlerhaften Aktualisierungen (A/B)?
  4. Sind die Aktualisierungen signiert?
  5. Gibt es genau einen Knoten-spezifischen Schlüssel (kein gemeinsames Geheimnis)?
  6. Werden Daten bei Verbindungsabbruch gepuffert – mit Grenze?
  7. Ist eine Übersicht vorhanden, welcher Knoten welche Version fährt?
  8. Gibt es einen Herzschlag mit Zeitüberschreitung (Ausfall = Alarm)?
  9. Sind Protokoll- und Speichergrenzen gesetzt (kein Volllaufen)?
  10. Ist die Hardware physisch geschützt (Verriegelung, Diebstahlschutz)?
  11. Ist der Ausfall eines Knotens durchgespielt – inklusive Ersatz?
  12. Sind die laufenden Betriebskosten bekannt (Reisen, Ersatzteile, Personal)?

Häufige Fehler

  1. Keine Fernaktualisierung. Der Knoten läuft mit der Version, mit der er geliefert wurde. Ein Sicherheitsproblem, das nicht behoben werden kann.
  2. Kein Rückfall bei fehlerhaftem Update. Ein abgebrochenes Update macht einen Vor-Ort-Einsatz nötig – möglicherweise bei jedem Standort.
  3. Kein Puffer. Bei kurzer Netzunterbrechung gehen Daten verloren. Der häufigste Ausfallgrund.
  4. Kein Herzschlag mit Zeitüberschreitung. Ein ausgefallener Knoten meldet nichts – und fällt nicht als Ausfall auf.
  5. Gemeinsamer Schlüssel für alle Knoten. Der Verlust eines Knotens kompromittiert alle.
  6. Protokolle ohne Größengrenze. Die Speicherkarte läuft voll, der Knoten steht.
  7. SD-Karten als Dauerlösung. Sie haben begrenzte Schreibzyklen. Bei Dauerbetrieb mit Protokollen und Puffern sterben sie innerhalb von Monaten. Industrielle Karten oder NVMe verwenden.
  8. Netz umgekehrt gedacht. Der Knoten sollte ausgehend verbinden (kein offener eingehender Zugang). Ein eingehender SSH-Zugang auf einem Knoten in einer fremden Halle ist ein Einfallstor.
  9. Trainingsdaten am Rand. Das Modelltraining gehört in die Zentrale. Am Rand nur die Auswertung.
  10. Betriebsaufwand unterschätzt. Zehn Standorte klingen nach Pilotprojekt, sind aber ein Betrieb mit Reiseplan.

Verwandte Grundlagen: Edge Computing, Container, Container-Sicherheit, IoT.