Datenerfassung in der Fertigung

Eine reale Fertigungsumgebung ist ein Flickenteppich. Steuerungen verschiedener Hersteller, verschiedener Generationen und verschiedener Protokolle stehen nebeneinander — eine Siemens S7 auf dem einen Skid, eine Allen-Bradley SPS auf dem nächsten, Modbus-Energiezähler und Frequenzumrichter in der Unterstation, IO-Link-Sensoren an der Verpackungslinie, CNC-Werkzeugmaschinen in der Werkstatt und BACnet-Steuerungen für die Gebäude-HLK. Fast nichts davon wurde dafür entworfen, Daten mit irgendetwas anderem zu teilen.

Die Aufgabe der Datenerfassung in der Fertigung besteht darin, vertrauenswürdige, benannte und mit Zeitstempel versehene Messwerte von all diesen Geräten zu erhalten und an einem Ort zusammenzuführen — ohne die Anlage neu zu verkabeln, Steuerungen auszutauschen oder SPS-Programme umzuschreiben. In der Praxis bedeutet das, das native Protokoll jedes Geräts zu sprechen, rohe Register und Tags in benannte technische Werte mit Einheiten zu verwandeln, ein Qualitätssignal anzuhängen, damit Sie wissen, ob ein Messwert vertrauenswürdig ist, und dies zuverlässig am Edge zu tun, selbst wenn das Netzwerk ausfällt.

IronFlock löst dies mit einer Familie leichtgewichtiger, am Edge bereitgestellter Collector-Apps — eine pro Protokollfamilie. Jede läuft als gewöhnlicher Docker-Container auf jedem Linux-Gateway, erkennt automatisch, was sie kann, normalisiert rohe Adressen in benannte Werte, puffert über Ausfälle hinweg und streamt alles in die Zeitserien-Datenbank Ihres Projekts. Jeder Collector wird vollständig im Browser konfiguriert und wird mit einem Demo-Modus ausgeliefert, sodass Sie das vollständige Erlebnis evaluieren können, bevor überhaupt Hardware angeschlossen ist.

Die Brownfield-Realität

Es gibt kein einzelnes Protokoll, das eine ganze Fertigung abdeckt. Die praktische Frage lautet stets „Welcher Collector liest meine Anlage aus?” Die folgende Tabelle ordnet die Anlagen, die Sie wahrscheinlich vorfinden, dem Collector zu, der sie handhabt.

Modbus und OPC UA funktionieren heute, ebenso IO-Link, MTConnect und BACnet. Die Siemens-S7- (S7comm) und Allen-Bradley- (EtherNet/IP) Treiber des Industrial Collector basieren auf der Apache-PLC4X-Engine und werden gerätübergreifend validiert — S7-1200/1500-Steuerungen können heute bereits über ihren integrierten OPC-UA-Server ausgelesen werden.

Wo IronFlock-Collectoren denselben Ansatz teilen

Welches Protokoll Sie auch erfassen, alle fünf Apps arbeiten unter der Haube auf die gleiche Weise. Sie schreiben in dieselben projektspezifischen Datenbanktabellen (gateways, assets, datapoints, measurements, assetstatus), puffern Messwerte lokal und leiten sie der Reihe nach weiter, sobald die Verbindung zur Plattform wiederhergestellt ist, isolieren jedes Gerät, sodass eine nicht erreichbare Maschine niemals die anderen blockiert, und werden live im Browser konfiguriert — ohne Konfigurationsdateien oder Neustarts. Dies gilt unabhängig davon, wie IronFlock bereitgestellt wird — als Managed Cloud, Private Cloud oder als vollständig offline betriebene On-Premises-Appliance. Jede der folgenden Seiten wiederholt diese gemeinsamen Eigenschaften, sodass sie für sich allein stehen kann.

Bekannte Einschränkungen

Für manche Altanlagen gibt es noch keinen direkten Weg. Ältere Allen-Bradley MicroLogix / SLC (PCCC über DF1), reine Profibus-Zellen ohne freien Ethernet-Port, Anlagen, die nur von einem Werks-DCS aus betrieben werden, und Anlagen ganz ohne digitale Steuerung (rein festverdrahtet) benötigen ein Gateway, eine Protokollbrücke oder eine Sensornachrüstung. Wenn Sie unsicher sind, ob Ihre Anlage abgedeckt ist, nehmen Sie Kontakt auf — wenn ein Gerät Modbus oder OPC UA spricht, funktioniert es heute mit ziemlicher Sicherheit, und neue Treiber und Profil-Pakete werden auf Anfrage hinzugefügt.

Die Collectoren

• Industrial Collector — eine App für die gesamte Fertigung: Siemens S7, Allen-Bradley, Modbus und OPC UA nebeneinander, mit einem Katalog vorab zugeordneter Anlagenprofile.
• IO-Link Collector — IO-Link-Master und intelligente Sensoren mit automatischer Erkennung und automatischer IODD-Dekodierung über HTTP, OPC UA oder MQTT.
• Modbus Collector — die leichtgewichtigste Möglichkeit, die riesige installierte Basis an Modbus-Messgeräten, -Antrieben und -Steuerungen auszulesen.
• MTConnect Collector — CNC-Werkzeugmaschinen und Anlagen in der Werkhalle über den offenen MTConnect-Standard, mit Erkennung ohne Konfiguration.
• BACnet Collector — Gebäudeautomation, HLK und Energiesysteme über BACnet/IP, mit automatischer Netzwerk- und Punkterkennung.

Wohin die Daten fließen

Jeder Collector speichert seine Messwerte in der privaten Zeitserien-Datenbank Ihres Projekts, wo sie dem Rest der Plattform sofort zur Verfügung stehen: Fragen Sie sie ab und modellieren Sie sie über das Data Backend, visualisieren Sie sie live in IoT-Dashboards und SCADA-Boards und überwachen Sie sie mit der Alarme-App für SMS-/E-Mail-Benachrichtigungen. Um Geräte online zu bringen und diese Apps zu installieren, siehe IoT-Geräteverwaltung und App-Verwaltung.

Von der Erfassung zur Erkenntnis: ein typisches Implementierungsmuster

Die Extraktion ist das Fundament, nicht das Ziel. Niemand will Register und Tags — Werke wollen OEE-Kennzahlen, Frühwarnungen, bevor eine Spindel ausfällt, Energie pro Teil, einen Schichtbericht, der sich selbst schreibt. Der typische IronFlock-Einsatz besteht daher aus zwei sauber getrennten Schichten:

Schicht 1 — Erfassen. Installieren Sie die zu Ihren Anlagen passenden Collector-Apps auf den Gateways direkt daneben und ordnen Sie Ihre Maschinen im Browser zu. Von diesem Zeitpunkt an sammeln sich benannte, mit Zeitstempel und Qualitätskennzeichen versehene Messwerte kontinuierlich in der standardisierten Datenbank Ihres Projekts an — jedes Projekt erhält dieselbe, sodass sich ein Collector überall identisch verhält, wo er installiert wird, und der Projekteigentümer einen zentralen Punkt bekommt, an dem er alles Erfasste einsehen kann. Darin liegen die Daten jeder App in einem eigenen isolierten Schema: ein einziges, wachsendes Gut, das Ihnen gehört — standardmäßig privat pro App.

Schicht 2 — Nutzen. Installieren Sie (oder entwickeln Sie) die Apps, die aus diesen Messwerten Entscheidungen machen, und lassen Sie sie die Daten der Collectoren über den App-übergreifenden Datenzugriff lesen:

• Eine fertige OEE-Dashboard-App konsumiert Maschinenzustände und Produktionszähler und liefert Verfügbarkeit, Leistung und Qualität pro Linie — live an der Wand, ohne ein einziges Integrationsmeeting.
• Eine Predictive-Maintenance-App trainiert auf Monaten von Vibrations-, Strom- und Temperaturhistorie, die die Collectoren bereits gesammelt haben, und bewertet dann den Live-Stream, um das Lager zu melden, das zu driften begonnen hat.
• Energieanalysen verknüpfen den Verbrauch der Modbus-Zähler mit den Produktionszählern der Maschinen und berichten Energie pro Teil, Leerlaufverluste und Lastspitzenrisiken.
• Reporting- und Qualitäts-Apps lesen dieselben Tabellen und füllen Schichtbücher, Chargenprotokolle und Audit-Trails automatisch.
• Eine Node-RED-Laufzeit (oder eine beliebige allgemeine Werkbank) deklariert, dass sie alle Projektdaten mit einer einzigen Wildcard konsumiert, und entdeckt dann die verfügbaren Tabellen zur Laufzeit — so kann eine Fachkraft Flows über jeden Collector und jede Analyse-App in der Fertigung hinweg verdrahten, ohne für jede einzelne eine Integration zu schreiben.

Jede konsumierende App deklariert, welche Collector-Daten sie benötigt — eine bestimmte Liste oder - app: "*" für alles — und Sie genehmigen oder widerrufen diesen Zugriff pro Projekt mit einem Schalter — stets schreibgeschützt. Da jeder IronFlock-Collector dasselbe Tabellenschema schreibt (gateways, assets, datapoints, measurements, assetstatus), funktioniert eine für einen Collector geschriebene konsumierende App mit allen: Dem OEE-Dashboard ist es gleich, ob die Maschinenzustände über S7, Modbus, MTConnect oder IO-Link eingetroffen sind.

Das Ergebnis ist eine Architektur, die mit Ihnen wächst, statt Sie einzusperren: Beginnen Sie mit einem Collector an einer Linie, ergänzen Sie Analyse-Apps, wenn Sie so weit sind, tauschen oder erweitern Sie jede Schicht unabhängig — und wenn fertige Apps nicht passen, entwickeln Sie Ihre eigene konsumierende App auf Basis der Daten, die Sie bereits erfassen.