6 Min. Lesezeit

Edge-Computing in der Fabrik ist keine Glaubensfrage zwischen Cloud und Werk, sondern eine Frage, welche Entscheidung auf welche Latenz, welche Datenmenge und welche Verantwortung trifft. Genau an dieser Linie entscheidet sich, ob eine Werks-Architektur in fünf Jahren noch trägt oder zum stillen Umbauprojekt wird.

VerwandtCloud Repatriation 2026: Hybrid-Architektur im CIO-Blick  /  Reboot Germany: Drei Entscheidungen die im Board bleiben

In vielen Werken läuft heute (Stand April 2026) eine Mischung aus gewachsenen SPS-Landschaften, einem zentralen MES und einer Cloud-Plattform, die vom Konzern vorgegeben wurde. Die Diskussion, die in den letzten Jahren häufig geführt wurde – Cloud oder Edge – war dabei selten hilfreich. Parallel hat sich die Konvergenz von IT und OT als eigenes Betriebsthema etabliert, das bei jeder Edge-Diskussion mit am Tisch sitzt. Wer zu lange zugehört hat, ging entweder mit einer Cloud-Erstversorgung für jede Linie nach Hause oder mit der Idee, jede Steuerung brauche ihren eigenen Rechenknoten. Beides ist in der Fabrikrealität falsch.

Sinnvoller ist eine Frage, die näher an der Werkshalle liegt: Welche Entscheidung muss wo getroffen werden, damit die Linie läuft, wenn das Netz zuckt und der Konzern-Cloud-Hub in Frankfurt eine Minute nicht antwortet? Und welche Entscheidung darf zentral fallen, weil sie langsamer, teurer und größer zu denken ist – etwa Planung, Qualitätsanalyse über Werke hinweg oder die Freigabe eines neuen Steuerungsparameters?

Was Edge-Computing in der Industrie heute wirklich meint

In der Industrie bedeutet Edge-Computing nicht „ein kleiner Server im Schaltschrank“, sondern eine Schicht, die zwischen Automatisierungstechnik und IT-Plattform liegt. Sie nimmt Sensordaten, Steuerungssignale und Bildströme entgegen, verarbeitet einen Teil davon vor Ort – zum Beispiel für Closed-Loop-Regelung, Anomalie-Erkennung oder visuelle Qualitätsprüfung – und leitet nur das weiter, was zentral wirklich gebraucht wird.

Technisch steckt dahinter eine Kombination: industrielle PCs oder Edge-Gateways, ein Container-Laufzeitumfeld, eine Anbindung an OPC UA oder Feldbus-Protokolle, eine Verbindung zur Unternehmens-IT und ein Konzept, wie Software-Updates bis in die Werkshalle kommen. Cloud-Anbieter und Automatisierungshersteller bieten dazu eigene Plattformen an; die Bandbreite reicht von AWS Outposts, Azure Local oder Google Distributed Cloud Edge bis zu Industriesuiten von Siemens, Bosch Rexroth oder Beckhoff. Welche Plattform passt, ist keine Geschmacksfrage, sondern hängt an der Automatisierungslandschaft, die schon da ist. Teile dieser Frage überschneiden sich mit dem, was im Edge-Computing-Ausblick 2026 als Datensouveränitäts-Diskussion geführt wird.

Die ehrliche Beschreibung dieses Trends: Edge-Computing ist in den meisten Werken nicht die glänzende neue Architektur, sondern die Konsequenz daraus, dass Steuerungsrechner, Bildverarbeitungssysteme und zentrale Plattformen nicht mehr alle in den gleichen Topf passen. Der spannende Teil ist nicht das Deployment, sondern die Frage, welche Entscheidung man welchem Teil des Systems zutraut.

Quelle: IoT Analytics, Industrial IoT Market Overview, 2024

Drei typische Architekturmuster – und wo sie scheitern

In der Praxis begegnen einem im Industrie-Umfeld im Wesentlichen drei Muster. Keines davon ist per se richtig oder falsch, sie haben nur sehr unterschiedliche Konsequenzen für Betrieb, Investition und Risiko.

Architektur-Muster scheitern selten an der Technologie. Sie scheitern dort, wo niemand beschrieben hat, welche Entscheidung welches System treffen darf, wenn das Netz fünf Minuten weg ist oder der Maschinenbau sonntags um drei einen Patch will.

1. Cloud-zentral mit dünnem Edge. Steuerung bleibt weitgehend in den bestehenden SPS. Die Edge-Schicht dient als Sammler, leitet Daten verschlüsselt in die Cloud, dort findet Analyse, MES-Logik und Visualisierung statt. Das funktioniert dort gut, wo Echtzeit-Anforderungen moderat sind und die Netzverfügbarkeit hoch ist, etwa in Montagelinien mit klar definierten Taktzeiten.

2. Edge-autonom mit Cloud-Zentrale. Die Linie läuft vollständig auch ohne Cloud-Verbindung weiter, Modelle für Qualitätsprüfung oder Predictive Maintenance laufen lokal, die Cloud erhält Aggregate und übernimmt Training und Weiterverteilung. Dieses Muster ist typisch für Prozesse mit hoher Datenrate und geringer Toleranz für Ausfälle, etwa visuelle Inspektion oder sicherheitsrelevante Funktionen.

3. Hybrid mit klarer Verantwortungsgrenze. Edge übernimmt Steuerung und zeitkritische Analyse, Cloud übernimmt übergreifende Planung, Werks-Benchmarking und KI-Training. Das klingt wie ein Kompromiss, ist aber in der Realität das anspruchsvollste Muster – weil die Grenze zwischen beiden Welten sauber dokumentiert, getestet und betrieben werden muss.

Die typische Schwachstelle aller drei Muster ist nicht die Technologie, sondern die Annahme, man könne sich nachträglich entscheiden, wer welche Schicht betreibt. Wenn Produktion, IT und externer Dienstleister die Verantwortung für denselben Edge-Cluster teilen, ohne dass geklärt ist, wer im Ernstfall patcht, neustartet oder eskaliert, kippt die Architektur lange vor dem ersten Hardware-Ausfall.

Pros und Cons: Cloud-zentral gegen Edge-autonom

Weil bei Investment-Vorlagen oft genau diese zwei Extreme gegeneinander gestellt werden, lohnt ein nüchterner Seitenvergleich. Die Wahrheit liegt fast nie an einem der beiden Enden, aber die Trade-offs werden in Gremien selten ausgesprochen.

Ein Beispiel aus einem anonymisierten Projekt in der Zulieferindustrie macht das konkret: Eine Linie mit visueller Qualitätsprüfung wurde zuerst rein cloud-basiert geplant, weil der Konzern bereits eine Plattform vorgab. Nach dem ersten Pilotlauf war klar, dass die Latenz für die Auswurflogik nicht verlässlich unter 80 Millisekunden zu halten war. Die finale Architektur entschied sich für Edge-Autonomie an der Linie, mit Aggregat-Daten in der zentralen Plattform. Die Technologie war sekundär; die Entscheidung war eine über Verantwortung: Wer betreibt die Linie, wenn das Netz weg ist? Die Antwort musste vor der Architektur stehen.

Ein zweites Muster aus der Praxis: In einem Mehrwerke-Verbund wurde das hybride Modell ausgeschrieben, weil es am flexibelsten wirkte. Nach zwölf Monaten Betrieb zeigte sich, dass die Grenze zwischen lokalem Entscheid und zentraler Freigabe an drei verschiedenen Stellen gezogen war – je nach Werk und je nach Team, das zuerst lieferte. Der teuerste Posten war nicht die Hardware, sondern die sechs Monate, die eine übergreifende Governance-Gruppe brauchte, um die Verantwortungs-Schnittstelle nachträglich zu standardisieren. Hätte man sie vor der Ausschreibung gezogen, wären die gleichen Entscheidungen in Wochen gefallen, nicht in Quartalen.

Was bei Edge-Investments systematisch übersehen wird

Edge-Computing in der Industrie wird in Gremien meist als Technologie-Thema behandelt. Das ist der erste strukturelle Fehler. Wer nur über Plattformen, Lizenzen und Anbieter redet, übersieht drei Dinge, die später genau so teuer werden wie die Hardware.

Das gilt umso mehr, wenn ein Werks-Projekt parallel zu Portfolio-Konsolidierungen auf Konzernebene läuft – ein Thema, das viele CIOs aktuell unter dem Stichwort Vendor-Consolidation bearbeiten. Wer auf Konzernebene reduziert, aber im Werk stillschweigend neue Plattformen duldet, baut die Komplexität nur um.

Die Lebenszykluskosten der Werks-Hardware. Edge-Knoten sind kein Server im klimatisierten Rechenzentrum, sondern stehen im Werk, oft über Jahre. Kühlung, Staub, Vibration, Wartungsfenster, Verfügbarkeit von Ersatzteilen nach sieben Jahren – all das fehlt in den meisten Business-Cases, die auf drei Jahre gerechnet sind. Eine IT-Kalkulation mit 36 Monaten passt nicht zu einem Anlagen-Lifecycle von zehn bis fünfzehn Jahren.

Gerade bei Werks-Hardware lohnt ein Blick auf eine zweite Rechnung, die viele IT-Budgets 2027 bereits zeigen: Ein wachsender Anteil der IT-Ausgaben fließt in den Betrieb bestehender Systeme, nicht in Neues. Edge im Werk verstärkt diesen Effekt, wenn die Anschaffung nicht mit einem klaren Betriebskonzept verbunden wird.

Die OT-Security-Realität. Sobald Edge-Systeme an Steuerungen angedockt werden, wird aus einer isolierten Automatisierungszelle ein vernetztes System mit allen bekannten Risiken. NIS2 macht das in der EU jetzt regulatorisch sichtbar, die Frage nach Trennung von IT und OT, Patch-Zyklen und Incident-Response im Werk wird dadurch nicht einfacher, sondern bepreisbar. Wer das nicht im Investitionsantrag verankert, reicht einen unvollständigen Business-Case ein.

Wie solche Organisationsfragen rund um neue Technologie-Layer sortiert werden, ist inzwischen eine eigene Governance-Disziplin – siehe Diskussion um den Chief AI Officer und seine Mandate. Für Edge in der Industrie gilt das Gleiche: Technologie ohne klares Mandat bleibt Projekt, wird aber nie Betrieb.

Die Frage, wer es betreibt. Viele Werke haben heute weder ein IT-Team mit OT-Erfahrung noch ein Automatisierungsteam mit Container-Know-how. Die Lücke dazwischen wird gern als „machen wir später über einen Dienstleister“ weggebucht. Das stimmt in ruhigen Jahren. In einem Incident-Szenario zwischen 03:40 Uhr und dem ersten Kaffee der Schicht ist es der teuerste Satz, den eine Organisation unterschreiben kann.

CIO-Checkliste für Edge-Investment-Entscheidungen

Diese fünf Schritte ersetzen keine Architektur-Diskussion, aber sie sorgen dafür, dass die Diskussion an der richtigen Stelle geführt wird – bevor ein Anbieter den Termin übernimmt.

Fazit

Edge-Computing in der Industrie ist kein neues Architektur-Mantra, sondern die Folge davon, dass Fertigung, IT und Cloud-Plattformen nicht mehr in die gleichen Schubladen passen. Die ehrliche C-Level-Frage lautet deshalb nicht „wie viel Edge?“, sondern: Welche Entscheidung darf welches System treffen, wenn die Umstände ungemütlich werden? Wer diese Linie sauber zieht, macht aus Edge keine Religionsdebatte, sondern eine nachvollziehbare Investition. Wer sie vermeidet, zahlt den Preis später – leise, aber zuverlässig.

Häufige Fragen

Quelle Titelbild: Pexels / Freek Wolsink (px:34222005)