Viele Digitalisierungsprojekte in der Produktion beginnen im kleinen Rahmen. Zunächst wird eine einzelne Maschine angebunden, ausgewählte Datenpunkte werden erfasst und in einem Dashboard dargestellt. Eine solche Testinstallation zeigt schnell, ob sich Energieverbräuche, Maschinenzustände oder Stillstände besser auswerten lassen. Pilotprojekte erfüllen damit eine wichtige Aufgabe: Sie beweisen, dass ein Anwendungsfall technisch funktioniert. Ob sich dasselbe System wirtschaftlich und organisatorisch auf viele Maschinen übertragen lässt, ist damit noch nicht beantwortet. Was während der Erprobungsphase überschaubar bleibt, wird beim Roll-Out schnell komplex.
Aufgaben kommen hinzu
Mit wachsender Zahl der angebundenen Maschinen verändern sich die Anforderungen. Edge-Geräte müssen reproduzierbar in Betrieb genommen, Konfigurationen dokumentiert und Softwarestände gepflegt werden. Gleichzeitig braucht es klare Regeln für Benutzerrechte, Updates, Datensicherheit und den laufenden Betrieb. Ein System skaliert erst, wenn sich weitere Maschinen nach einem wiederholbaren Verfahren anbinden und betreiben lassen. Gerade in gewachsenen Produktionsumgebungen treffen unterschiedliche Maschinengenerationen, Steuerungen, Sensoren und Kommunikationsprotokolle aufeinander. Eine Anlage liefert Daten über OPC UA, eine andere über Modbus TCP, eine dritte nur über digitale Signale. Hinzu kommen unterschiedliche Variablennamen, Einheiten und Datenformate. In einer ersten Testinstallation lassen sich solche Unterschiede noch individuell lösen. Beim Roll-Out führen sie jedoch schnell zu Sonderlösungen, mehrfacher Pflege und Abhängigkeiten vom Wissen einzelner Personen. Skalierbarkeit verlangt daher keine identischen Maschinen, sondern einheitliche Regeln für Anbindung, Konfiguration und Verwaltung.
Standards statt Einzelsysteme
Für einen Maschinentyp kann ein Template festlegen, welche Datenquellen angebunden werden, wie Messwerte bezeichnet werden, welche Berechnungen lokal erfolgen und an welche Zielsysteme die Informationen gehen. Bei der Inbetriebnahme werden nur noch Parameter wie IP-Adresse, Maschinenkennzeichen oder Standort ergänzt. Das verkürzt die Installation und reduziert Abweichungen zwischen den Anlagen. Aus einer individuellen Konfiguration wird ein reproduzierbarer Prozess. Auch das Datenmodell muss diesem Prinzip folgen. Ein Maschinenzustand kann an der Quelle als Zahl, Text oder digitales Signal vorliegen. Für übergeordnete Anwendungen sollte er dennoch einheitlich als ‚produktiv‘, ‚bereit‘, ‚Stillstand‘ oder ‚Störung‘ interpretierbar sein. Dasselbe gilt für Stückzahlen, Energieverbräuche, Auftragsinformationen und Zeitstempel. Die Datenquelle bleibt maschinenspezifisch, die bereitgestellte Information folgt einer gemeinsamen Struktur. Erst dadurch lassen sich Kennzahlen über Maschinen, Linien oder Standorte hinweg vergleichen. Ohne einheitliches Datenmodell entstehen viele Dashboards, aber keine durchgängige Datengrundlage.
Edge wird Teil der Produktions-IT
Während der ersten Erprobungsphase gilt ein Edge-Gerät häufig als lokales Hilfsmittel. Im Roll-Out wird es jedoch zum dauerhaft betriebenen Bestandteil der IT- und OT-Infrastruktur. Jedes Gerät benötigt daher eine eindeutige Identität, dokumentierte Software- und Konfigurationsstände, geregelte Zugriffsrechte sowie kontrollierte Kommunikationswege. Updates können bei einer größeren Edge-Flotte nicht dauerhaft manuell verteilt werden. Gleichzeitig dürfen sie nicht ungeprüft auf allen produktiven Systemen landen. Nötig sind Freigabeprozesse, Testgruppen und ein Rückweg auf den vorherigen Stand, der auch dann trägt, wenn ein Update fehlschlägt. Technisch lässt sich das absichern, indem ein Gerät zwei vollständige Systemabbilder vorhält. Das Update wird in den gerade inaktiven Bereich geschrieben, erst danach schaltet das Gerät um. Startet der neue Stand nicht sauber, fällt es automatisch auf den vorherigen zurück. Die Edge-Plattform Siineos von In.Hub arbeitet nach diesem Prinzip. Je mehr Komponenten im Einsatz sind, desto wichtiger wird eine zentrale Übersicht. Sie zeigt, welche Geräte erreichbar sind, welche Anwendungen laufen und ob Konfigurationen noch dem festgelegten Standard entsprechen. Eine Managementebene führt Geräte, Softwarestände, Benutzerrechte, Verbindungen und Fehlermeldungen zusammen. Dazu ergänzt Hub-CX400 die Siineos-Plattform um eine zentrale Ebene, über die Geräte, Anwendungen und Datenbestände zusammengeführt und verwaltet werden können.
Brownfield bleibt heterogen
Besonders anspruchsvoll ist die Skalierung im Brownfield. Dort unterscheiden sich Maschinen in Baujahr, Steuerungstechnik, Schnittstellen und Dokumentationsstand. Ein Roll-Out muss deshalb mehrere Wege der Datenerfassung zulassen. Moderne Maschinen können über standardisierte Protokolle angebunden werden. Bei älteren Anlagen sind zusätzliche Sensoren, digitale Signale, Zählerimpulse oder Messgeräte erforderlich. Das Hub-SE100 von In.Hub wird dafür zwischen Sensor und Steuerung geschleift: Das Signal läuft unverändert zur Steuerung weiter und wird dabei zusätzlich erfasst. Alternativ arbeitet das Modul als autarker Sensorknoten oder bindet Impuls- und Zählersignale an. Für Energie- und Mediendaten steht das Edge-Modul Hub-EN200 zur Verfügung. Ob überall dasselbe Gerät steckt, spielt dabei eine geringere Rolle. Wichtiger ist, dass unterschiedliche Erfassungswege in einer gemeinsamen Datenstruktur zusammenlaufen und nach denselben Regeln betrieben werden.
Modularität statt Inselsysteme
Bei einer ersten Umsetzung werden Datenerfassung, Verarbeitung, Visualisierung und Analyse häufig eng miteinander verbunden. Für den Roll-Out ist eine modulare Architektur sinnvoller. Die physische Erfassung sollte von der späteren Nutzung getrennt werden, damit dieselben Daten für mehrere Anwendungen zur Verfügung stehen. Maschinenzustände und Stückzahlen können so für OEE-Auswertungen, Stillstandsanalysen und Produktionsberichte genutzt werden. Energieinformationen lassen sich mit Zustandsdaten kombinieren und zugleich an ein Energiemanagementsystem oder eine SQL-Datenbank übergeben. SQLxConnect übernimmt innerhalb der Siineos-Umgebung die strukturierte Übergabe aufbereiteter Daten an bestehende SQL-Systeme, ohne dass für jede Maschine ein eigenes Schnittstellenprojekt entstehen muss. Für einen neuen Anwendungsfall muss so nicht automatisch eine neue Infrastruktur entstehen.
Skalierung braucht klare Verantwortung
Neben der Technik entscheidet die Organisation über den Erfolg. Produktion, Instandhaltung, Automatisierung und IT verfolgen unterschiedliche Anforderungen. Daher muss klar geregelt sein, wer Hardware und Betriebssystem verantwortet, Anwendungen freigibt, Konfigurationen pflegt, Zugriffe verwaltet und auf Störungen oder Sicherheitsmeldungen reagiert. Auch Cybersecurity muss Teil der Architektur sein. Jedes Gerät und jede Verbindung erweitert die Angriffsfläche. Notwendig sind begrenzte Kommunikationswege, sichere Authentifizierung, minimale Zugriffsrechte, nachvollziehbare Änderungen und ein geregelter Umgang mit Sicherheitsupdates. Wenn ab Dezember 2027 die Hauptpflichten des Cyber Resilience Act greifen, dürfen Produkte mit digitalen Elementen in der EU nur noch in Verkehr gebracht werden, wenn sie definierte Sicherheitsanforderungen erfüllen. Für ein Roll-Out-Projekt, das heute geplant wird, ist das kein fernes Datum. Edge-Geräte, die jetzt in die Produktion gehen, laufen dort typischerweise fünf bis zehn Jahre. Wie lange es für ein Gerät noch Sicherheitsupdates gibt und wie diese in den Betrieb kommen, gehört deshalb in die Auswahl und nicht in die spätere Betriebsphase. Wer im Pilot nur auf den Funktionsumfang schaut, entscheidet unbemerkt auch über die Wartbarkeit der nächsten Jahre.
Wirtschaftlichkeit durch Wiederholbarkeit
Der Nutzen einer Testinstallation zeigt sich etwa in geringerem Energieverbrauch, weniger Stillstand oder reduziertem manuellem Aufwand. Beim Roll-Out kommt die Wirtschaftlichkeit der Umsetzung hinzu. Ein Beispiel aus der Praxis: In einer Roboterzelle stieg die Gesamtanlageneffektivität nach der Anbindung von 82 auf 90 Prozent. Der Energieverbrauch der Zelle sank um 28 Prozent, das entspricht rund 3.000 Euro im Jahr. Die Umsetzung dauerte etwa neun Stunden. Für den Roll-Out sagt die Umsetzungszeit mehr aus als die Einsparung. Neun Stunden für eine Zelle sind vertretbar. Fallen dieselben neun Stunden bei jeder weiteren Maschine erneut an, sind es bei 40 Maschinen rund 360 Stunden Engineer-ing, bevor die erste standortweite Auswertung steht. Läuft die Anbindung dagegen über ein Template, bleibt pro Maschine nur die Inbetriebnahme mit wenigen Parametern. Somit ist ein erfolgreiches Pilotprojekt zwar ein wichtiger erster Schritt, der Weg zum skalierbaren System jedoch noch weit. Denn wie schnell die erste Maschine angebunden ist, sagt insgesamt recht wenig aus. Der Maßstab ist die zweite, die zehnte und die hundertste.
