Edge Computing in der Produktion: Greengrass & Outposts

Warum Edge Computing in der Fertigung unverzichtbar wird

Die vernetzte Fabrik produziert Datenmengen, die cloudbasierte Architektur allein nicht bewältigen kann. Eine moderne CNC-Anlage erzeugt bis zu 2.000 Messwerte pro Sekunde. Ein Qualitätsprüfsystem mit High-Speed-Kamera liefert 120 Frames pro Sekunde in 4K-Auflösung. Das sind Datenströme, die weder wirtschaftlich noch technisch vollständig in die Cloud übertragen werden können — und es oft auch nicht sollten.

Drei Treiber machen Edge Computing in der Produktion zur strategischen Notwendigkeit:

1. Latenzanforderungen: Sicherheits-PLCs erfordern Reaktionszeiten unter 10 ms. Ein Round-Trip in die Cloud und zurück dauert mindestens 20–100 ms — zu langsam für Echtzeit-Steuerung und visuelle Qualitätsprüfung auf der Linie.
2. Netzwerkunabhängigkeit: Produktionsanlagen müssen bei WAN-Ausfall weiterarbeiten. Edge-Geräte mit lokalem Processing halten den Betrieb aufrecht, selbst wenn die Cloud-Verbindung unterbrochen ist.
3. Datenresidenz und Compliance: Produktionsdaten, Maschinensignaturen und teils personenbezogene Daten (Schichtpläne, Bedieneridentifikation) dürfen unter DSGVO und Betriebs-Compliance-Anforderungen Deutschland nicht verlassen. Lokale Verarbeitung ist damit in vielen Fällen nicht nur sinnvoll, sondern geboten.

Dazu kommt wirtschaftliche Vernunft: Bandbreite und Cloud-Compute für Rohdaten sind teuer. Edge Computing filtert, aggregiert und komprimiert Daten vor der Übertragung — nur relevante Events und Zusammenfassungen erreichen die Cloud.

Begriffsklärung: Die wichtigsten Technologien

Edge Computing

Verarbeitung von Daten an oder in unmittelbarer Nähe der Entstehungsquelle — auf der Maschine, am Gateway in der Produktionshalle oder im Shopfloor-Rechenzentrum — anstatt zentral in der Cloud. Reduziert Latenz, schont Bandbreite und ermöglicht offline-fähige Anwendungen.

AWS IoT Greengrass V2

Open-Source Edge-Runtime von AWS (Apache 2.0), der auf Linux-basierter Industrie-Hardware läuft. Er bringt AWS-Dienste wie Lambda, ML-Inferenz, lokale Nachrichtenübermittlung (MQTT) und Secrets Management direkt auf das Gerät. Greengrass V2 verwendet ein komponentenbasiertes Deployment-Modell — jede Funktion ist eine eigenständige, versionierte Komponente, die über AWS IoT Core verwaltet wird.

Greengrass Component

Die Basiseinheit in Greengrass V2. Eine Komponente enthält Code (Lambda, Container, nativer Prozess), eine Rezept-Datei (YAML/JSON mit Dependencies, Lifecycle-Hooks, Parameter-Schema) und optionale Artefakte (Modell-Dateien, Konfiguration). Komponenten werden im AWS IoT Greengrass Catalog verwaltet und können auf Geräte-Flotten deployt werden.

AWS Outposts

Ein vollständig konfiguriertes AWS-Infrastruktur-Rack (42U oder kleinere Formfaktoren), das AWS physisch im Rechenzentrum oder in der Fabrikhalle des Kunden installiert und betreibt. Outposts bieten dieselben EC2-Instanztypen, EBS, RDS, ECS, EKS und weitere Dienste wie in der AWS-Region — mit nativer Integration und einheitlicher API. Die Verwaltung erfolgt über die AWS Console wie bei regulären AWS-Diensten.

Amazon SageMaker Neo

Kompilierungs- und Optimierungs-Service für ML-Modelle. Neo kompiliert Modelle aus TensorFlow, PyTorch, MXNet, Keras, ONNX und XGBoost für spezifische Ziel-Hardware: NVIDIA Jetson, Intel Atom, ARM Cortex-M, Raspberry Pi, x86-64. Das Ergebnis ist ein hardware-optimiertes Modell, das weniger Speicher benötigt und schneller inferenziert — ohne GPU, nur CPU oder NPU.

Lambda@Edge

AWS-Dienst zum Ausführen von Lambda-Funktionen in CloudFront Edge Locations — nicht zu verwechseln mit Greengrass auf IoT-Geräten. Lambda@Edge ist für Web-Anwendungen konzipiert (Request/Response-Manipulation), nicht für industrielles IoT. In Fertigungsumgebungen wird der Begriff "Edge" fast immer im IoT-Kontext (Greengrass, Outposts) verwendet.

Outpost Rack

Die Standard-Formfaktor-Variante von AWS Outposts: ein 42U-Rack mit AWS Nitro System, Netzwerk-Hardware und vorinstallierten AWS-Diensten. AWS übernimmt Lieferung, Installation, Betrieb und Updates. Für kleinere Deployments gibt es AWS Outposts Server (1U/2U) mit einem reduzierten Dienst-Portfolio.

AWS IoT Greengrass V2: Architektur und Funktionsweise

Greengrass V2 transformiert jedes Linux-Gerät (x86-64, ARM, NVIDIA Jetson) in einen vollwertigen AWS-Edge-Knoten. Der Kern ist der Nucleus — ein systemd-Dienst (oder Init-Prozess), der auf dem Gerät läuft und die Kommunikation mit AWS IoT Core verwaltet.

Die Architektur folgt einem Hub-and-Spoke-Modell:

1. Greengrass Core Device: Das Gateway-Gerät in der Fabrik — oft ein Industrie-PC oder ein dediziertes IoT-Gateway. Es führt den Nucleus aus, hostet Komponenten und kommuniziert nach oben mit AWS IoT Core via MQTT/HTTPS und nach unten mit angebundenen Leaf-Devices.
2. Leaf Devices: Sensoren, Kameras, SPS/PLCs, die über MQTT mit dem Core Device kommunizieren. Sie benötigen kein Greengrass selbst — lediglich MQTT-Konnektivität.
3. Komponenten-Deployment: Über AWS IoT Core oder die CLI werden Deployment-Dokumente erstellt, die definieren, welche Komponenten in welcher Version auf welche Geräte-Gruppe deployt werden. Greengrass lädt Artefakte aus S3, verifiziert Checksums und startet die Komponenten gemäß Lifecycle-Definition.
4. Local IPC: Komponenten kommunizieren untereinander über einen lokalen Message-Bus (AWS IoT Greengrass IPC) — ohne Umweg über die Cloud. Das ermöglicht deterministische Latenz für Komponent-zu-Komponenten-Kommunikation.

Für die Fertigung besonders relevant sind drei Greengrass-Fähigkeiten: Stream Manager für die Pufferung und geordnete Übertragung von Zeitreihendaten auch bei instabiler Verbindung, Secret Manager Integration für sichere Credential-Verwaltung ohne Hardcoding, und Docker Container Support für die Ausführung containerisierter Anwendungen am Edge.

AWS Outposts in der Fabrik: Vollständige Cloud-Infrastruktur on-Premises

AWS Outposts adressiert einen anderen Anwendungsfall als Greengrass: Workloads, die echte Server-Ressourcen, Datenbanken, Container-Orchestrierung oder spezifische AWS-Services benötigen, aber aus Compliance- oder Latenzgründen nicht in der Region laufen dürfen.

Typische Outposts-Workloads in der Fertigung:

• MES (Manufacturing Execution System) auf EC2 mit RDS — volle SQL-Datenbank on-Premises, mit AWS-nativer Backup- und Monitoring-Integration
• ECS/EKS-Cluster für Fertigungs-Applikationen mit kurzen Latenzanforderungen zur Shopfloor-Anbindung
• Bildverarbeitungs-Workloads mit GPU-Instanzen (G4dn auf Outposts), die zu rechenintensiv für Edge-Geräte, aber zu latenzempfindlich für die Region sind
• SCADA-Systeme und Historian-Datenbanken mit regulatorischen Datenresidenz-Anforderungen

AWS ist für den physischen Betrieb verantwortlich: Hardware-Wartung, Firmware-Updates, Kapazitäts-Monitoring. Der Kunde ist für Netzwerk-Konnektivität (dedizierte Leitung zur AWS-Region), physische Sicherheit und Kühlung verantwortlich. Der Service Link — die Verbindung zwischen Outpost und der AWS-Heimat-Region — ist für Management-Plane-Operationen erforderlich, der Data-Plane läuft jedoch auch bei Service-Link-Ausfall weiter.

Entscheidungsmatrix: Greengrass V2 vs. AWS Outposts

Die Wahl zwischen Greengrass und Outposts ist keine Entweder-oder-Entscheidung — viele reife Fertigungs-Architekturen nutzen beide. Dennoch hilft folgende Matrix bei der initialen Einordnung:

ML-Inferenz an der Edge: SageMaker Neo und Greengrass

Das leistungsstärkste Anwendungsszenario für Greengrass in der Fertigung ist die Ausführung von ML-Modellen direkt auf der Maschine — ohne Cloud-Round-Trip. Typische Use Cases:

• Visuelle Qualitätskontrolle: Klassifikation von Produktionsfehlern (Kratzer, Risse, Fehlartikel) auf einem Edge-Gerät mit Kamera-Anbindung — Entscheidung in unter 50 ms, bevor das Produkt die Prüfstation verlässt
• Anomalie-Erkennung auf Zeitreihendaten: Vibrations- und Temperaturmuster einer CNC-Anlage werden lokal durch ein LSTM- oder Autoencoder-Modell analysiert; Alarm wird lokal ausgelöst
• Predictive Quality: Inline-Vorhersage der Endprodukt-Qualität auf Basis von Prozessparametern — Werkzeugverschleiß, Spindellast, Vorschubrate — noch während der Bearbeitung

Der Workflow mit SageMaker Neo und Greengrass folgt vier Schritten:

1. Modell trainieren: In SageMaker Studio oder extern (Jupyter, lokales Training). Exportformat: SavedModel (TF), TorchScript (PyTorch), ONNX oder XGBoost-Pickle.
2. Modell kompilieren: In SageMaker Neo das Ziel-Device angeben (z.B. "jetson_nano", "ml_c5" für x86-CPU). Neo optimiert Operator-Fusion, Quantisierung und Kernel-Auswahl. Ausgabe: komprimiertes Modell-Archiv (.tar.gz) in S3.
3. Als Greengrass-Komponente paketieren: AWS-verwaltete Komponente aws.greengrass.SageMakerEdgeManager übernimmt Modell-Download, Versionierung und Lifecycle. Alternativ: eigene Komponente mit DLR (Deep Learning Runtime) für direktes Modell-Loading.
4. Deployment: Über AWS IoT Core wird das Deployment-Dokument auf die Ziel-Gerätegruppe angewendet. Greengrass lädt Artefakte, startet die Inferenz-Komponente und exponiert einen lokalen gRPC-Endpunkt für andere Komponenten.

Amazon Kinesis Video Streams (KVS) ergänzt dieses Szenario: Edge-Kameras streamen über den KVS Edge Agent lokal auf das Greengrass-Gerät. Dort läuft die ML-Inferenz. Nur annotierte Clips (Fehlerfunde, Anomalien) werden in die Cloud gesendet — Bandbreiten-Einsparung von bis zu 95 % gegenüber vollem Video-Upload.

Greengrass V1 → V2 Migration: Deadline Juni 2026

AWS hat angekündigt, dass AWS IoT Greengrass V1 am 30. Juni 2026 das End-of-Support erreicht. Ab diesem Datum werden keine Security-Patches, Bug-Fixes oder neue Features mehr für V1 veröffentlicht. Unternehmen, die Greengrass V1 in der Produktion betreiben, müssen bis dahin migriert sein.

Greengrass V2 ist keine inkrementelle Aktualisierung — es ist eine architektonische Neuentwicklung. Die wichtigsten Unterschiede:

Empfohlener Migrations-Prozess für Fertigungsbetriebe:

1. Inventar aufnehmen (Woche 1–2): Alle Greengrass V1 Core Devices identifizieren, Lambda-Funktionen katalogisieren, Abhängigkeiten und Konnektoren dokumentieren.
2. Pilot-Device auswählen (Woche 3–4): Ein unkritisches Gerät in einer Lab-Umgebung als erstes Migrations-Ziel. V1 und V2 können nicht auf demselben Gerät koexistieren — vollständiger Ersatz nötig.
3. Komponenten entwickeln (Woche 5–10): Lambda-Funktionen aus V1 zunächst als "Legacy Lambda-Komponenten" in V2 wrappen (schnell, aber keine neuen V2-Features). Parallel: Neuentwicklung als native V2-Komponenten für kritische Workloads.
4. Rollout in Wellen (ab Woche 11): Deployment-Gruppen in AWS IoT Core nutzen, um Geräte in Batches zu migrieren. Monitoring über CloudWatch Device Advisor. Rollback-Mechanismus pro Deployment-Dokument vorbereiten.
5. Validierung und Go-Live: Parallelbetrieb von V1 (auf anderen Geräten) und V2 für mindestens 4 Wochen vor der Abschaltung von V1-Instanzen.

Storm Reply Perspektive: Edge-Strategien für deutsche Fertigungsbetriebe

Storm Reply begleitet deutsche Fertigungsunternehmen bei der Implementierung von AWS Edge-Architekturen — von der Strategie bis zur Pilotanlage. Unsere Erfahrung aus Projekten der letzten drei Jahre zeigt drei wiederkehrende Muster:

Muster 1 — Greengrass als Integrations-Gateway: Ältere Anlagen (Baujahr vor 2015) mit proprietären Protokollen (PROFINET, OPC-UA, Modbus) werden über einen Greengrass-Core-Device mit OPC-UA-Bridge-Komponente angebunden. Der Industrial Data Lake in S3 empfängt normalisierte Zeitreihendaten, unabhängig vom Herstellerprotokoll. ROI typisch innerhalb von 12 Monaten durch konsolidiertes Condition Monitoring.

Muster 2 — Edge-KI für visuelle Qualitätskontrolle: Inline-Kameras mit Greengrass und Neo-kompilierten Modellen ersetzen manuelle Sichtprüfung. Implementierungsdauer: 8–12 Wochen für Pilot, 4–6 Monate für vollständigen Rollout. Fehlerrate-Reduktion von 30–60 % gegenüber manuelle Prüfung ist erreichbar.

Muster 3 — Outposts für MES-Modernisierung: Mittelständler mit bestehenden MES-Systemen auf veralteter On-Premises-Hardware migrieren auf Outposts. Sie behalten Datenresidenz und niedrige Latenz zur Shopfloor-Anbindung, gewinnen aber AWS-native Services (CloudWatch, Secrets Manager, IAM) und eine Exit-Strategie in die Cloud.

Storm Reply ist AWS Premier Consulting Partner mit Spezialisierung auf Industrial IoT und Manufacturing. Unser Migrations-Assessment für Greengrass V1 → V2 dauert zwei Wochen und liefert einen vollständigen Migrations-Plan mit Risikobewertung und Aufwandsschätzung.

Regulatorik: NIS2, Cyber Resilience Act und DSGVO

Edge Computing in der Fertigung bewegt sich im Schnittfeld dreier regulatorischer Anforderungen, die 2024 und 2025 scharf werden:

NIS2 (Network and Information Security Directive 2): Die NIS2-Richtlinie, die seit Oktober 2024 in deutschem Recht umgesetzt ist, verpflichtet Unternehmen kritischer Infrastruktur und "wichtige Einrichtungen" (Umsatz >50 Mio. EUR, 250+ Mitarbeiter oder niedrigere Schwellen für kritische Sektoren), ihre OT-Netzwerke in das Information-Security-Management einzubeziehen. Greengrass-Geräte im Produktionsnetz sind OT-Assets und müssen in das Asset-Inventory, Patch-Management und Incident-Response-Prozesse aufgenommen werden. AWS IoT Device Defender übernimmt Security Monitoring für Greengrass-Geräte und lässt sich in SIEM-Systeme integrieren.

Cyber Resilience Act (CRA): Der CRA (in Kraft seit 2024, Übergangsfrist bis 2027) stellt Anforderungen an Hersteller vernetzter Produkte — Security-by-Design, Vulnerability-Disclosure und Patch-Verpflichtungen über den gesamten Produktlebenszyklus. Für Fertigungsunternehmen, die eigene Greengrass-Komponenten entwickeln und deployen, entsteht eine Sorgfaltspflicht: SBOM (Software Bill of Materials), Dependency-Tracking und Update-Prozesse müssen dokumentiert werden. AWS bietet Inspector und CodeArtifact für SBOM-Generierung.

DSGVO und Datenresidenz: Produktionsdaten sind in der Regel keine personenbezogenen Daten — aber Ausnahmen existieren: Bediener-Identifikation an Maschinen, Schichtpläne, Zugangsdaten. Diese Daten dürfen Deutschland nicht verlassen. Greengrass Local Processing und Outposts garantieren physische Datenresidenz. Wer zusätzlich AWS-Region eu-central-1 (Frankfurt) für Cloud-Anteile nutzt, erfüllt auch technisch die DSGVO-Anforderungen für grenzüberschreitende Datenübertragungen.

Vorteile und Herausforderungen im Überblick

Häufige Fragen (FAQ)

Was ist der Unterschied zwischen AWS IoT Greengrass und AWS Outposts?

AWS IoT Greengrass V2 ist ein leichtgewichtiger Edge-Runtime, der auf vorhandener Industrie-Hardware läuft und AWS-Dienste wie Lambda, ML-Inferenz und lokale Nachrichtenübermittlung an die Maschine bringt. AWS Outposts ist ein vollständiger AWS-Infrastruktur-Rack im eigenen Rechenzentrum oder der Fabrik — mit denselben EC2-Instanztypen, RDS, ECS und EKS wie in der Cloud. Greengrass eignet sich für latenzarme Steuerungsaufgaben direkt an der Maschine; Outposts für komplexe Workloads, die echte Server-Ressourcen und volle AWS-API-Kompatibilität benötigen.

Was ändert sich bei der Migration von Greengrass V1 zu V2?

Greengrass V1 erreicht am 30. Juni 2026 sein End-of-Support. Greengrass V2 bringt ein komponentenbasiertes Deployment-Modell (statt fester Lambda-Funktionen), verbesserte Fleet-Provisioning-Mechanismen, einen neuen Nucleus-Core als Systemdienst und native Integration mit AWS IoT Jobs. Lambda-Funktionen aus V1 lassen sich als Legacy Lambda-Komponenten in V2 weiterbetreiben — jedoch ohne die neuen Lifecycle-Hooks und Dependency-Features zu nutzen. Eine vollständige Neuentwicklung als native V2-Komponenten ist für neue Projekte empfohlen.

Wie funktioniert ML-Inferenz mit SageMaker Neo an der Edge?

Amazon SageMaker Neo kompiliert trainierte ML-Modelle (TensorFlow, PyTorch, MXNet, ONNX) für die Zielhardware — NVIDIA Jetson, Raspberry Pi, ARM Cortex, x86 — und optimiert dabei Speicherbedarf und Inferenz-Latenz. Das kompilierte Modell wird als Greengrass-Komponente paketiert und über Greengrass-Deployments auf beliebig viele Edge-Geräte verteilt. Latenz unter 10 ms für Bildklassifikation und Anomalie-Erkennung sind damit auch auf leistungsschwacher Industrie-Hardware erreichbar.

Welche Regulatorik gilt für Edge-Daten in der Fertigung?

NIS2 (ab Oktober 2024 in deutschem Recht) verpflichtet Unternehmen kritischer Infrastruktur und wichtige Einrichtungen, auch OT-Netzwerke in ihr Sicherheitsmanagement einzubeziehen. Der Cyber Resilience Act stellt Anforderungen an vernetzte Produkte — Greengrass-Geräte gelten als connected devices. Die DSGVO fordert Datenresidenz: Produktions- und Personendaten, die lokal an der Maschine verarbeitet werden, dürfen Deutschland oder die EU nicht verlassen. AWS Outposts und Greengrass Local Processing ermöglichen beide Datenverarbeitung ohne Daten-Transfer in die Cloud.

Quellen und weiterführende Informationen

• Bitkom: IoT in der Industrie — Treiber und Hemmnisse 2024, Berlin 2024
• AWS: AWS IoT Greengrass V2 Developer Guide, docs.aws.amazon.com/greengrass/v2/developerguide/
• AWS: AWS Outposts User Guide, docs.aws.amazon.com/outposts/latest/userguide/
• AWS: Amazon SageMaker Neo — Compile and Deploy Models, docs.aws.amazon.com/sagemaker/latest/dg/neo.html
• Bundesamt für Sicherheit in der Informationstechnik (BSI): NIS-2-Umsetzungsgesetz, bsi.bund.de
• Europäische Kommission: Cyber Resilience Act (EU) 2024/2847