Die Diskussion über Edge Computing in Unternehmensumgebungen dreht sich tendenziell um Kosten – lokale Verarbeitung zur Reduzierung von Cloud-Rechnungen, Filterung von Daten am Edge, um nicht zu übertragen, was nicht übertragen werden muss. Im industriellen Kontext ist diese Formulierung falsch. Edge Computing in einer Fabrik ist keine kostenoptimierte Entscheidung mit einer praktikablen Alternative in der Cloud. Für eine Vielzahl industrieller Anwendungen erfüllt die zentralisierte Cloud-Architektur einfach nicht die betrieblichen Anforderungen – zu hohe Latenz für die Prozesssteuerung, zu hohes Datenvolumen für eine kontinuierliche Übertragung, inakzeptable Netzwerkabhängigkeit für kritische Vorgänge. Die Frage ist nicht, ob Edge oder Cloud günstiger ist. Die Frage ist, welche Anwendungen eine lokale Verarbeitung als nicht verhandelbare funktionale Anforderung erfordern und wie die Edge-Infrastruktur zu ihrer Unterstützung skaliert werden kann.
Was bedeutet Millisekunden-Latenz in der Produktionslinie?
Industrielle Prozesssteuerungssysteme – SPS, DCS, Bildverarbeitungssysteme – arbeiten mit Zeitzyklen, die von Mikrosekunden für die Bewegungssteuerung bis zu mehreren zehn Millisekunden für die Steuerung chemischer Prozesse reichen. Die Round-Trip-Latenz zu einem Rechenzentrum in derselben Stadt beträgt bei günstigen Netzwerkbedingungen typischerweise zwischen 5 und 20 Millisekunden. Bei Netzwerkbedingungen mit Jitter oder bei einem geografisch weit entfernten Rechenzentrum kann es leicht 50 Millisekunden überschreiten.
Bei einem Computer-Vision-System einer Inspektionslinie, das fehlerhafte Teile aussortieren muss, bevor das Teil zur nächsten Station gelangt, muss die Entscheidungslatenz mit der Liniengeschwindigkeit kompatibel sein. Ein Linienzyklus von 200 Millisekunden pro Teil ergibt ein Zeitfenster für die Kamera zum Erfassen, das Modell zum Verarbeiten und das Senden des Ablehnungssignals an den Aktuator. Subtrahieren Sie die Bildaufnahmezeit, die Betätigungszeit des Aktuators und den Sicherheitsspielraum, kann das Verarbeitungsfenster weniger als 50 Millisekunden betragen. Keine öffentliche Cloud-Architektur bietet diese Latenz zuverlässig und konsistent.
Die gleiche Argumentation gilt für kollaborative Robotersteuerungssysteme, Not-Aus-Systeme, die auf Sensoranalyse basieren, und alle Anwendungen, bei denen physische Aktionen von Echtzeitalgorithmusentscheidungen abhängen. In diesen Fällen ist Edge Computing nicht vorzuziehen – es ist zwingend erforderlich. Die Kosten einer Entscheidung mit übermäßiger Latenz sind kein veraltetes Dashboard. Es handelt sich um ein defektes Teil, das die Prüfung bestanden hat, um ein Gerät, das nicht zum richtigen Zeitpunkt gestoppt wurde, oder um einen Vorgang, der das Netzwerk unterbrochen hat.
Das Datenvolumenproblem, das die Mathematik löst
Eine hochauflösende industrielle Inspektionskamera mit 30 Bildern pro Sekunde erzeugt je nach Komprimierung und Auflösung etwa 1 bis 3 Gigabyte Daten pro Stunde und Kamera. Eine Anlage mit fünfzig Inspektionskameras erzeugt zwischen 50 und 150 Gigabyte pro Stunde. In einem Monat im Zweischichtbetrieb sind das zwischen 24 und 72 Terabyte Video. Die kontinuierliche Übertragung dieses Volumens in die Cloud ist keine Frage der Bandbreite – es gibt Betriebe, die über die entsprechende Bandbreite verfügen. Es handelt sich um Cloud-Speicher- und Verarbeitungskosten, die schnell ungerechtfertigt werden, wenn die überwiegende Mehrheit der aufgenommenen Bilder aus fehlerfreien Teilen besteht und keiner Analyse bedarf.
Das Modell, das funktioniert, ist Inferenz am Rande: Das Computer-Vision-Modell läuft auf lokaler Hardware, verarbeitet jeden Frame und erzeugt nur das Ergebnis – genehmigt oder abgelehnt, mit einem gewissen Maß an Sicherheit –, anstatt das vollständige Bild zu übertragen. Bilder von abgelehnten oder wenig vertrauenswürdigen Teilen können zur menschlichen Überprüfung und Neuschulung an die Cloud gesendet werden. Das Ergebnis ist, dass die Übertragung in die Cloud von Gigabyte pro Stunde auf Megabyte pro Stunde ansteigt und die Daten, die die Cloud erreichen, für die Analyse und Modellverbesserung von Wert sind.
Ein ähnliches Profil haben Hochfrequenz-Schwingungssensoren zur Anlagenzustandsanalyse. Die Abtastung mit 10 kHz – notwendig, um einige Kategorien mechanischer Defekte zu erkennen – erzeugt Datenmengen, die eine kontinuierliche Übertragung nicht rechtfertigen. Sinnvoll ist es, die relevanten Metriken – Frequenzspektrum, Amplitude in bestimmten Bändern, Zustandsindizes – lokal zu berechnen und nur diese berechneten Indikatoren zu übertragen, wobei die vollständige Zeitreihe im lokalen Speicher für eine tiefergehende Analyse bei Bedarf verfügbar ist.
Industrielle Edge-Architektur: Was den Stack ausmacht
Die industrielle Edge-Umgebung ist kein Linux-Rack-Server. Es handelt sich um eine Hierarchie der Rechenkapazität, die zwischen den Geräten und der Cloud verteilt ist, wobei auf jeder Ebene unterschiedliche Verarbeitungsebenen stattfinden.
Auf der nächsten Geräteebene befinden sich Protokoll-Gateways – Geräte, die Industrieprotokolle wie Modbus, Profibus, EtherNet/IP und OPC-UA in Formate übersetzen, die der Rest des Stacks nutzen kann. Bei diesen Gateways handelt es sich häufig um spezielle Hardware – Moxa, Advantech, Siemens SIMATIC – mit Firmware, die für die industrielle Umgebung entwickelt wurde: erweiterte Betriebstemperatur, lüfterlos, zehnjähriger Komponentenlebenszyklus. Die Kosten pro Einheit sind höher als bei gleichwertiger IT-Hardware in der Verarbeitungsspezifikation, aber die Anforderungen an die Zuverlässigkeit in einer industriellen Umgebung rechtfertigen den Unterschied.
Eine Schicht darüber liegen Edge-Server – Hardware, die alles von robusten Industrie-PCs bis hin zu kompakten GPU-Racks zur Ableitung von Computer-Vision-Modellen ausführen kann. Dabei hängt die Wahl der Hardware von der Rechenlast ab. Für die Verarbeitung von Zeitreihen und die Berechnung von Wartungsindikatoren reicht ein Prozessor mit geringer Leistung aus. Für die Hochfrequenz-Computer-Vision-Modellinferenz werden in den Designspezifikationen Industrie-GPUs wie der Nvidia Jetson AGX oder Nvidias eigene A2000-Reihe aufgeführt.
Auf Softwareebene besteht bei den meisten industriellen Edge-Architekturen die größte Lücke bei der Frage der Orchestrierung – wie Anwendungen bereitgestellt, aktualisiert und überwacht werden, die auf Dutzenden oder Hunderten von Edge-Knoten ausgeführt werden. Kubernetes funktioniert, aber seine betriebliche Komplexität in OT-Umgebungen kann für Teams ohne umfassende Erfahrung in der Container-Orchestrierung übermäßig sein. Plattformen wie Azure IoT Edge, AWS Greengrass und Balena bieten einfachere Abstraktionen und native Integration mit entsprechenden Cloud-Diensten, erzeugen jedoch eine Anbieterbindung, die im Kontext des Projekts evaluiert werden muss.
Physische und logische Sicherheit in einer Fabrikumgebung
Industrielles Edge-Computing fügt Umgebungen, die für den isolierten Betrieb konzipiert sind, eine Angriffsfläche hinzu. Ein Edge-Server in der Fabrikhalle ist eine zugängliche physische Hardware, die mit dem OT-Netzwerk verbunden ist und häufig von IT-Mitarbeitern verwaltet wird, die keinen routinemäßigen physischen Zugang zum Raum haben. Dadurch entstehen Risiken, denen das zentralisierte Rechenzentrums-Sicherheitsmodell nicht Rechnung trägt.
Physische Sicherheit beginnt beim Gehäuse – Industrie-Racks mit Schlössern und Öffnungsüberwachung sind keine Paranoia, sondern gängige Praxis für jegliche Computerausrüstung in einem unkontrollierten Zugangsbereich einer Anlage. Die Verwaltung des physischen Zugriffs auf Hardware umfasst die Kontrolle darüber, wer USB anschließen, Datenträger entfernen oder Hardware zurücksetzen kann.
Logische Sicherheit in einer Edge-Umgebung erfordert, dass jeder Edge-Knoten für die Kommunikation mit der Cloud authentifiziert wird – zertifikatbasierte Authentifizierung, nicht gemeinsame statische Anmeldeinformationen. Firmware- und Software-Updates müssen digital signiert werden, um die Installation schädlicher Software zu verhindern. Das Netzwerksegmentierungsmodell sollte den Zugriff des Edge-Servers über die Systeme hinaus beschränken, die er zum Funktionieren benötigt – es gibt keinen Grund dafür, dass ein Computer-Vision-Inferenzserver Zugriff auf das HR-System des Unternehmens hat.
So dimensionieren und budgetieren Sie die Edge-Infrastruktur
Der häufigste Fehler bei der industriellen Edge-Budgetierung besteht darin, nur die Kosten der Server-Hardware zu berechnen und alles drumherum zu ignorieren: die OT-Netzwerkinfrastruktur, die angepasst werden muss, um den neuen Datenverkehr zu unterstützen, die strukturierte Verkabelung, die in Umgebungen installiert werden muss, die nicht dafür ausgelegt sind, das unterbrechungsfreie Stromversorgungssystem, um sicherzustellen, dass der Edge-Knoten bei einem Stromausfall keine Daten verliert, und die Engineering-Kosten für die Inbetriebnahme und Integration in bestehende Systeme.
Eine Faustregel für industrielle Edge-Projekte besteht darin, die Gesamtbetriebskosten der Edge-Hardware in den ersten zwei Jahren auf das Zwei- bis Dreifache der Kosten der Hardware selbst zu veranschlagen. Der Unterschied umfasst Installation, Integration, Schulung des Betriebsteams und den anfänglichen Anpassungszyklus, der für jede neue Implementierung erforderlich ist. Ab dem dritten Jahr stabilisieren sich die Betriebskosten bei etwa 15 bis 25 % der jährlichen Hardwarekosten, hauptsächlich für die Softwarewartung und den vorbeugenden Austausch von Komponenten mit begrenzter Lebensdauer wie USV-Batterien und -Festplatten.
Lesen Sie auch
- Edge Computing: Warum Computing die Cloud verlässt und sich den Daten annähert
- Edge Computing: Warum verteilte Verarbeitung Ihre Architektur neu definieren wird
- Edge Computing-Architektur: Strategien für die verteilte Verarbeitung
- Inferenz am Rande: Wenn KI auf dem Gerät ausgeführt wird, ist dies sinnvoller als in der Cloud
- Städte als Labor: Wenn der städtische Raum zur Testplattform wird
- Autonomes Rechnen: wenn das System sich selbst korrigiert, bevor Sie den Fehler bemerken