Industrielle Konnektivität: der praktische Leitfaden für Fertigungsunternehmen

Eine neue Lackierlinie in einem Automobilwerk geht an einem Montag in Betrieb. Am Freitag aktualisiert sich das OEE-Dashboard in der Spätschicht nicht mehr. Die Linie produziert. Die Daten, die das belegen, kommen nicht an. Die Ursache: drei ältere SPS, die niemand sauber an die Datenschicht angebunden hat.

Eine kleine Geschichte, ein großes Problem. Solange diese Daten fehlen, sieht die Produktion nicht, wie die Linie läuft, die Instandhaltung geht blind in die nächste Schicht, und das Controlling rechnet die Schichtproduktivität von Hand nach. Jeder dieser Punkte kostet Geld. Zusammen erklären sie, warum industrielle Konnektivität von der IT-Warteliste auf die Agenda der Geschäftsführung mittlerer und großer Fertigungsunternehmen gerückt ist.

Industrielle Konnektivität ist die Integrationsschicht, über die Maschinen, Sensoren, Steuerungen und IT-Systeme in der Fertigung Betriebsdaten zuverlässig und in standardisierter Form austauschen, herstellerübergreifend und protokollunabhängig. Für Industrieunternehmen aus Automobilbau, Luftfahrt, Pharma und Konsumgüterindustrie ist sie die Grundlage für Echtzeitentscheidungen, vorausschauende Instandhaltung, Compliance und Kostenkontrolle. Dieser Leitfaden erklärt, was industrielle Konnektivität ist, woran Projekte bei Altanlagen und an der Grenze zwischen IT und OT scheitern und welche Protokolle und Technologien zählen. Anschließend geht es darum, wie Sie Anbieter bewerten, den Business Case aufbauen und ein Rollout so aufsetzen, dass es Industrie-4.0- und IIoT-Anwendungsfälle trägt, statt die lange Liste stecken gebliebener Pilotprojekte zu verlängern.

Was industrielle Konnektivität wirklich bedeutet

Industrielle Konnektivität ist die Integration von Geräten, Maschinen und Software in der Fertigung, sodass Daten in standardisierter, nutzbarer Form zwischen ihnen fließen. Sie liegt unter jeder Smart-Factory-Initiative, wie auch immer der Prospekt sie nennt.

In der Praxis verbindet sie vier Gruppen von Ausrüstung. Ganz unten die Feldgeräte: Sensoren, Antriebe, Scanner. Darüber die Steuerungen: SPS, DCS, CNC. Darüber die Leitebene: SCADA, HMI, Historian. An der Spitze die Unternehmens-IT: MES, ERP, Analytik, Cloud. Aufgabe der Konnektivitätsschicht ist es, diese vier Gruppen miteinander sprechen zu lassen, ohne dass das Integrationsteam denselben Übersetzer zweimal schreibt.

Vom Büronetz unterscheidet sie das Umfeld. Die Hardware muss Hitze, Vibration, Staub und elektromagnetische Störungen aushalten, und die Daten sind betrieblich: aktuelle Prozesswerte, Alarme und Maschinenzustände, auf deren Basis Entscheidungen in Sekunden fallen, nicht nach dem Quartalsreview.

Warum das Thema jetzt auf der Agenda der Geschäftsführung steht

Drei Dinge haben das Thema aus der Automatisierungsabteilung in den Sitzungssaal geholt.

Digitalprogramme scheitern regelmäßig an der Konnektivitätsschicht. Die Untersuchung von McKinsey mit dem Global Lighthouse Network des Weltwirtschaftsforums ergab, dass mindestens 70 % der Fertigungsunternehmen im Pilot-Fegefeuer feststecken: Digitalinitiativen, die sich im Pilot bewähren und nie auf den gesamten Werksverbund skalieren.

Die Operations-Praxis von McKinsey nennt die Ursache die letzte Meile zwischen IT und OT und verweist darauf, dass ein typisches mittelgroßes Werk über 200 Anlagen verschiedener Lieferanten betreibt, jede mit eigener Plattform und eigenem Protokoll. Ein Pilot für vorausschauende Instandhaltung, der mit 50 Tags funktioniert, bleibt bei 50.000 Tags über drei Werke stehen. Das Modell ist nicht das Problem. Die Datenleitungen sind es. Eine Geschäftsführung, die eine Runde Digitalinvestitionen freigegeben hat, ohne Rendite zu sehen, stellt vor der nächsten härtere Fragen.

Die Kosten schlechter Konnektivität sind messbar. Der Siemens-Report True Cost of Downtime 2024 beziffert die Verluste durch ungeplante Stillstände bei den 500 größten Unternehmen der Welt auf rund 1,4 Billionen US-Dollar pro Jahr, also 11 % des Umsatzes, nach 8 % im Jahr 2019. Im Automobilbau kostet eine stehende Linie bis zu 2,3 Millionen US-Dollar pro Stunde. Die ABB-Umfrage Value of Reliability zeigt, dass zwei Drittel der Industrieunternehmen mindestens einmal im Monat einen ungeplanten Stillstand erleben, zu typischen Kosten von rund 125.000 US-Dollar pro Stunde.

Ein erheblicher Teil dieser Stillstände geht auf Daten zurück, die das Team gebraucht, aber nicht rechtzeitig bekommen hat. Ein Werk, das die Frage „Warum ist die Ausbeute an Linie 3 letzte Woche eingebrochen?“ erst nach zwei Tagen Spurensuche beantworten kann, trifft jede betriebliche Entscheidung langsamer und teurer als nötig. Werke, die in Minuten antworten, verkürzen die MTTR, verbessern die Erstdurchlaufquote und geben Ingenieurzeit für Arbeit frei, die sich auszahlt.

Kunden und Regulierer fragen nach. Große Abnehmer aus Automobil und Pharma verlangen von Lieferanten heute den Nachweis von Cybersicherheit, Rückverfolgbarkeit und Kontrolle über den Datenaustausch. In der EU kommt die Regulierung hinzu: die NIS2-Richtlinie, in Deutschland umgesetzt durch das NIS2UmsuCG und das BSIG. Was NIS2 für OT-Netze bedeutet, behandeln wir gesondert. Wo auch immer Sie produzieren: Ein Werk, das keine auditierbaren Datenflüsse von der Maschine bis in die Cloud vorweisen kann, verliert Ausschreibungen, die es früher über den Preis gewonnen hat.

Wie funktioniert industrielle Konnektivität?

Industrielle Konnektivität funktioniert so: Eine Middleware übersetzt die proprietären Protokolle der Geräte in ein gemeinsames Format und reicht die Daten über standardisierte, herstellerneutrale Schnittstellen an die übergeordneten Systeme weiter. Ein Integrationspunkt statt eines eigenen Treibers für jedes System.

Auf der Feldebene sprechen die Geräte den Dialekt, den der Hersteller gewählt hat: Modbus TCP, EtherNet/IP, PROFINET, IO-Link und Dutzende mehr. Eine Konnektivitätsplattform betreibt Treiber, die jeden Dialekt in ein einziges internes Datenmodell übersetzen, und stellt es nach oben über zwei herstellerneutrale Standards bereit: OPC UA für industrielle Client-Server-Kommunikation und MQTT mit Sparkplug B für Publish-Subscribe und die Cloud. Über dieselben Schnittstellen veröffentlichen Roboter, CNC-Maschinen und andere automatisierte Anlagen ihre Zustandsdaten neben dem Rest der Linie, sodass nachgelagerte Systeme ein zusammenhängendes Bild sehen statt eines Dutzends Herstellersilos.

Das Ergebnis: SCADA, MES, Historian und Cloud-Analytik beziehen dieselben Werksdaten über einen Integrationspunkt, statt jeweils eine eigene Treiberbibliothek zu pflegen. Diese Entkopplung ist das gesamte wirtschaftliche Argument. IT und OT streiten nicht mehr über den Datenzugriff, sondern teilen die Daten.

Sechs Protokolle für 90 % der Fertigung

Protokoll	Ebene	Typischer Einsatz
Modbus TCP / RTU	Gerät	ältere SPS, Antriebe, Energiezähler
EtherNet/IP	Gerät, Steuerung	Allen-Bradley- / Rockwell-Umgebungen
PROFINET	Gerät, Steuerung	Siemens und europäische Umgebungen
IO-Link	Sensor	intelligente Sensoren und Aktoren
OPC UA	Datenebene	herstellerneutraler OT/IT-Austausch
MQTT (Sparkplug B)	IIoT-Ebene	Edge-to-Cloud, Unified Namespace

Sechs Protokolle decken rund 90 % einer typischen Fertigung ab. Die ersten vier erledigen die kurzen Gespräche zwischen Steuerungen und Geräten. OPC UA und MQTT tragen kontextualisierte Daten über die OT/IT-Grenze. Moderne Architekturen nutzen beides, mit einer Konnektivitätsplattform in der Mitte, die übersetzt.

Beim Transport bleibt Industrial Ethernet der Standard unter den für Industrieumgebungen ausgelegten Netzwerklösungen, mit Gigabit-Verbindungen und niedriger Latenz für zeitkritische Anwendungen. Funk (privates 5G, Wi-Fi 6) übernimmt, wo Kabel unpraktisch sind, und Edge Computing schließt zeitkritische Regelkreise lokal, während die Cloud die Langzeitanalytik übernimmt. Welche Mischung auch immer: IIoT-Lösungen müssen IT und OT verbinden und unter rauen Bedingungen interoperabel bleiben. Das Netz muss Daten zuverlässig übertragen, trotz Hitze, Störungen, Spannungseinbrüchen und allem, was ein Werk sonst noch aufbietet.

Warum es so schwer ist

Schwierig sind nicht die Kabel und nicht die Protokolle. Schwierig ist die betriebliche Realität.

Anlagen aus den 1990er-Jahren

Ein typischer europäischer Hersteller betreibt Produktionsanlagen aus den Neunzigern. Die SPS läuft, der OEM existiert nicht mehr, das Protokoll ist nicht dokumentiert. Konnektivitätsplattformen verdienen ihr Geld damit, Treiber für diese Waisen mitzubringen: Die Linie bleibt in Betrieb, während sich die Datenschicht um sie herum modernisiert.

Die Kluft zwischen IT und OT

Die IT optimiert auf Vertraulichkeit und Patch-Zyklen. Die OT optimiert auf Verfügbarkeit und einen fünfjährigen Änderungsstopp. Beide haben in ihrem Zuständigkeitsbereich recht, und beide liegen falsch, wenn sie ihr Regelwerk über die Firewall hinweg anwenden. Erfolgreiche Projekte behandeln das als Koordinationsproblem, nicht als Technologieproblem.

Die Bedingungen in der Halle

Ein Schaltschrank im Stahlwerk läuft bei 50 °C, mit Störpegeln, die einen Consumer-Switch in wenigen Wochen zerstören. Ein erheblicher Teil der IIoT-Projekte scheitert nicht, weil die Architektur falsch war, sondern weil das Netz wie für ein Büro spezifiziert wurde.

Die Angriffsfläche

Jedes Feldgerät mit Netzwerkadresse vergrößert die Angriffsfläche, und Kunden prüfen das zunehmend im Audit. Die Zeit, in der ein Air Gap als Sicherheitsstrategie galt, endete ungefähr dann, als er aufhörte, real zu sein.

Die Kosten eines Fehlers sind konkret: Stillstände, verworfene Chargen, verpasste Lieferungen und verlorene Ausschreibungen führen öfter, als man zugibt, auf eine Konnektivitätsschicht zurück, die nie sauber entworfen wurde.

Was verlässliche Konnektivität für die Digitalisierung der Produktion bringt

Sobald Daten zuverlässig fließen, werden die Anwendungsfälle möglich, die die Investition in Digital Manufacturing rechtfertigen.

Vorausschauende Instandhaltung macht aus Schwingungs-, Temperatur- und Stromwerten Frühwarnungen und ersetzt die Wartung in festen Intervallen durch zustandsbasierte Eingriffe; eine bessere Datenerfassung an vernetzten Anlagen verbessert die Entscheidungen in Instandhaltung und Produktion. Die Siemens-Studie schreibt der Verbreitung vorausschauender Instandhaltung zu, dass die ungeplanten Stillstände eines großen Werks von 39 Stunden pro Monat im Jahr 2019 auf 27 Stunden im Jahr 2024 gesunken sind, der Hauptgrund, warum die Gesamtkosten der Stillstände nicht explodiert sind, obwohl jede verlorene Stunde teurer wurde.

Produktionsüberwachung mit OEE in Echtzeit gibt der Werksleitung ein aktuelles Bild der Leistung statt eines Berichts von gestern früh, legt Engpässe offen und beschleunigt Rüstvorgänge. Prozessoptimierung wird messbar, weil die Daten, die sie speisen, über Maschinen und Standorte hinweg konsistent sind.

Dieselbe Datenschicht versorgt die neueren Anwendungsfälle. Digitale Zwillinge, virtuelle Abbilder physischer Anlagen, brauchen Echtzeitkonnektivität, um Leistung zu spiegeln und zu simulieren. Vernetztes Energiemonitoring senkt Energiekosten und Emissionen. Vernetzte Bildverarbeitung und Sensorik erkennen Qualitätsdrift, bevor sie zu Ausschuss wird, und vernetzte Sicherheitssysteme können automatisierte Anlagen verlangsamen oder stoppen, wenn Personen einen definierten Bereich betreten.

Genau das meinen die Leute, wenn sie von Industrie 4.0 oder dem industriellen Internet der Dinge sprechen. Das Etikett wechselt alle paar Jahre. Die Anforderung nicht: ein zuverlässiger, sicherer, herstellerneutraler Weg, Daten zwischen Maschinen, Systemen und den Menschen zu bewegen, die in industriellen Prozessen entscheiden.

Wie Sie den Business Case rechnen

Ein Business Case für Konnektivität ruht auf drei Zahlen, die Ihr Finanzteam prüfen kann, nicht auf einer Technologievision.

Ihre Stillstandskosten pro Stunde. Nehmen Sie eine repräsentative Linie, multiplizieren Sie den verlorenen Durchsatz mit dem Deckungsbeitrag und addieren Sie unproduktive Arbeitszeit, Expressfracht und Vertragsstrafen. Die meisten Werke, die diese Übung sauber machen, stellen fest, dass die tatsächliche Zahl zwei- bis dreimal so hoch ist wie im Instandhaltungsbericht, weil indirekte Kosten (Ausschuss beim Wiederanlauf, Ausbeuteverlust beim Hochfahren, Teile mit Aufpreis) nie im Stillstandsprotokoll auftauchen. Landet Ihre Zahl in der Nähe des ABB-Medians von 125.000 US-Dollar pro Stunde, zahlt schon eine bescheidene Reduzierung der Vorfälle die Konnektivitätsschicht mehrfach zurück.

Ihre Ingenieurstunden für manuelles Datenschaufeln. Zählen Sie die Stunden, die Ihre Prozessingenieure, Instandhaltungsplaner und Analysten jeden Monat damit verbringen, Daten zwischen Systemen zu exportieren, abzugleichen und neu einzutippen. In unseren Projekten ist das regelmäßig der größte versteckte Posten: Ein mittelgroßes Werk, das 200 bis 400 Ingenieurstunden im Monat für manuelle Datenleitungen verbrennt, ist normal, und das sind Ihre teuersten und am schwersten zu findenden Leute, die Arbeit erledigen, die eine Middleware-Lizenz für einen Bruchteil der Kosten übernimmt.

Ihre stecken gebliebene Initiative. Wenn ein Programm für vorausschauende Instandhaltung, Qualitätsanalytik oder Energie bereits genehmigt ist und an der Datenschicht hängt, erbt die Konnektivitätsinvestition den Business Case dieses Programms. Sie finanzieren keinen neuen Wert; Sie geben Wert frei, den die Geschäftsführung bereits unterschrieben hat.

Legen Sie diese drei Zahlen zusammen, und der Business Case schreibt sich meist von selbst. Was Konnektivitätsvorhaben scheitern lässt, ist nicht eine schwache Wirtschaftlichkeit; es ist die Darstellung des Projekts als Infrastrukturausgabe statt als Schlüssel zu Renditen, auf die sich die Organisation bereits festgelegt hat.

Die Einführungsreihenfolge, die funktioniert

Die meisten Konnektivitätsfehlschläge sind Reihenfolgefehler. Das Muster, das funktioniert, ist in Automobil, Konsumgütern und Pharma dasselbe und besteht aus sechs Schritten.

1. Audit (2 bis 3 Wochen). Erfassen Sie, was Sie tatsächlich haben: jede datenerzeugende Anlage, ihr Protokoll, ihren Verantwortlichen und den Ort, an den ihre Daten derzeit gehen (oder nicht gehen). Diesen Schritt überspringen die meisten Organisationen, und deshalb beschreiben ihre Architekturdiagramme ein Werk, das es nicht gibt. Das Ergebnis: ein Inventar der Anlagen und Datenflüsse plus eine Liste nicht verwalteter Geräte, von denen niemand wusste, dass sie im Netz sind. Ohne Produktionsstillstand.

2. Architektur (2 bis 4 Wochen). Legen Sie das Zielmuster fest, bevor Sie Software auswählen. Für die meisten Hersteller mit mehreren Standorten ist dieses Muster der Unified Namespace: eine einzige, zentrale Datenschicht als eine Quelle der Wahrheit für jedes System, an die sich jeder Datenproduzent und -konsument einmal anbindet, statt Punkt-zu-Punkt-Integrationen zu pflegen. Definieren Sie hier Ihre Namenskonventionen und Datenmodelle, denn sie nachzurüsten, wenn 10.000 Tags live sind, ist eine elende Arbeit. Halten Sie die Zielarchitektur modular, um Herstellerabhängigkeit zu vermeiden und Raum für Erweiterungen zu lassen.

3. Plattformauswahl (1 bis 2 Wochen). Erst jetzt erstellen Sie die Shortlist der Software, gemessen an Audit und Architektur statt an einer Herstellerdemo. Der Abschnitt unten erklärt, worin sich die wichtigsten Plattformen unterscheiden.

4. Pilot (4 bis 8 Wochen). Eine Linie oder eine Zelle, aber ausgelegt als Ausschnitt der Zielarchitektur, nicht als Wegwerflösung. Der Pilot muss die Namenskonventionen, das Sicherheitsmodell und die Übergabe an das Team beweisen, das ihn später betreibt, denn diese drei Dinge brechen beim Skalieren. Ein Pilot, der nur beweist, dass „Daten fließen können“, beweist nichts, was Sie nicht schon wussten.

5. Rollout (6 bis 12 Wochen je Standort). Führen Sie Standort für Standort mit den Vorlagen ein, die der Pilot validiert hat. Hier zahlt sich die frühere Disziplin aus: Mit festen Konventionen und Modellen ist jeder weitere Standort Konfigurationsarbeit, keine Entwurfsarbeit, und die Fernkonfiguration wird zum praktikablen Weg, Geräte über Standorte hinweg auszurollen und zu verwalten.

6. Governance (dauerhaft). Weisen Sie die Verantwortung für den Namensraum, den Zertifikatslebenszyklus und das Änderungsmanagement zu. Konnektivität ist kein Projekt, das endet; sie ist eine Schicht, die jede darauf gebaute Anwendung überlebt.

Halten Sie die Reihenfolge ein, und die operative Effizienz steigt, während sich Ihre Leute auf Wertschöpfung statt Nacharbeit konzentrieren. Vertauschen Sie sie (typischerweise, indem Sie bei Schritt 3 beginnen, weil eine Herstellerdemo überzeugend war), und Sie landen bei den 70 % im Pilot-Fegefeuer.

Acht Fragen an den Anbieter

Bevor Sie etwas unterschreiben, stellen Sie der Shortlist diese Fragen. Die Antworten trennen produktionsreife Plattformen von Laborlösungen.

1. Welche der Protokolle aus unserem Audit unterstützen Sie nativ, und welche erfordern Individualentwicklung? Verlangen Sie die Treiberliste schriftlich, keinen Prozentwert.
2. Was passiert bei 50.000 Tags über drei Standorte? Verlangen Sie einen Referenzkunden in dieser Größenordnung, keine Benchmark-Folie.
3. Wie ist die Sicherheit standardmäßig gelöst: Zertifikate, Verschlüsselung, Benutzerauthentifizierung? „Konfigurierbar“ ist nicht dasselbe wie „standardmäßig aktiv“.
4. Was macht das Lizenzmodell beim Skalieren? Modelle je Tag, je Treiber, je Server und im Abonnement ergeben völlig unterschiedliche Fünfjahreskosten; modellieren Sie Ihren Zielbestand, nicht den Pilot.
5. Wie gehen Sie mit unseren Alt- und Waisenanlagen um? Nennen Sie die konkreten SPS aus den 1990ern aus Ihrem Audit und beobachten Sie die Reaktion.
6. Wie sehen Updates und Patches auf der OT-Seite aus? Eine Plattform, die sich nicht ohne Produktionsstopp patchen lässt, übersteht kein Sicherheitsaudit.
7. Wer implementiert, und wer leistet Support um zwei Uhr nachts? Eine Plattform ist nur so gut wie der Integrator und die Supportkette dahinter.
8. Wie sieht der Ausstieg aus? Wenn auf die Frage „Wie bekommen wir unsere Datenmodelle heraus?“ Schweigen folgt, kaufen Sie Abhängigkeit, keine Konnektivität.

Kepware oder Ignition: die Wahl der Plattform

Die Softwarekategorie hinter all dem ist Middleware für industrielle Konnektivität. Zum Markt gehören Kepware (Velotic), Ignition (Inductive Automation), HighByte, Cogent DataHub und AVEVA PI System. Für mittlere bis große Hersteller, die eine herstellerneutrale Architektur aufbauen, decken in der Praxis zwei Plattformen die meisten Entscheidungen ab, und genau diese beiden implementiert TT PSC selbst.

Kepware ist Konnektivitäts-Middleware im engsten Sinn. Es übersetzt über 150 Industrieprotokolle in einen einzigen Datenstrom und stellt ihn über OPC UA, MQTT, REST und direkte Cloud-Konnektoren bereit. Es gewinnt, wenn breite Abdeckung von Altanlagen, ein produktionsreifer OPC-UA-Server und eine Topologie im Vordergrund stehen, die vom Ein-Server-Pilot bis zur standortübergreifenden UNS-Architektur skaliert, ohne Neubau.

Ignition ist breiter angelegt: Konnektivität plus SCADA, HMI, Alarmierung und Reporting in einer Plattform, mit Lizenzierung ohne Tag-Limit. Es gewinnt, wenn eine einzige Plattform für Konnektivität und Visualisierung gefragt ist, besonders auf der grünen Wiese oder wenn ein in die Jahre gekommenes SCADA ersetzt werden soll.

Die ehrliche Antwort auf „welches?“ hängt vom vorhandenen Bestand ab. Ein auf Allen-Bradley standardisiertes Werk mit sauberer Trennung zwischen Konnektivität und SCADA ist meist ein Fall für Kepware. Ein regionaler Konsumgüterhersteller, der Lieferanten über fünf Standorte konsolidiert, ist meist ein Fall für Ignition. Viele reale Bestände nutzen beides.

TT PSC ist Kepware-Integrator und autorisierter Reseller im Partnerprogramm von Velotic sowie Inductive-Automation-Integrator der Stufe Gold. Wir implementieren beide Plattformen in Automobilbau, Konsumgüterindustrie, Pharma und diskreter Fertigung in Großbritannien, der DACH-Region, Skandinavien, Benelux, Frankreich und Polen. Die Empfehlung, die ein Kunde von uns bekommt, folgt der Passung zum Bestand, nicht der Lizenzmarge.

Wo Sie anfangen

Industrielle Konnektivität ist der Punkt, an dem die meisten Programme zur digitalen Transformation entweder gelingen oder ins Stocken geraten, und der Unterschied liegt selten an der Plattform. Er liegt an der Reihenfolge: Audit, Architektur, Plattformauswahl, Pilot, Rollout, Governance. TT PSC begleitet Hersteller über diese gesamte Sequenz als beratender Partner, nicht nur als Reseller.

Wenn Ihre Digital- oder KI-Initiative an der Datenschicht hängt, beginnt das Gespräch bei Ihrer aktuellen Architektur: was Sie haben, was Sie verbinden wollen und wo der Engpass tatsächlich liegt. Wenn Sie ein Kepware-Rollout planen, decken unsere Lizenzierungs- und Implementierungsleistungen den gesamten Weg von der Dimensionierung bis zum Produktivbetrieb ab. Und wenn Sie in der EU produzieren und OT-Sicherheit auf Ihrer Compliance-Agenda steht, dauert ein kostenloser NIS2-Readiness-Check zehn Minuten und zeigt Ihnen, wo Sie stehen.