Cyber-physische Systeme mit OPAIRS®: Maschinen und Sensoren on-premise anbinden

Eine KI, die nur Dokumente und Geschäftsdaten kennt, sieht die Fertigung von außen. Was an der Maschine passiert – Temperaturverläufe, Taktzeiten, Stillstände, Prüfergebnisse –, steht in Steuerungen und Sensoren und wird oft gar nicht dauerhaft gespeichert. Cyber-physische Systeme schließen diese Lücke: Die physische Anlage liefert Daten, die Software wertet sie aus, und Menschen entscheiden auf dieser Grundlage.

OPAIRS erweitert die Plattform deshalb um die Maschinenebene. Das Modul OPAIRS Connect Machine liest Maschinen- und Sensordaten aus der Fertigung und schreibt sie in eine PostgreSQL-Datenbank. Das OPAIRS® Dashboard und die OPAIRS-KI-Plattform lesen von dort. Alles läuft on-premise in Docker, ohne Cloud-Dienste. Wichtig zur Einordnung: Die Daten fließen in eine Richtung, von der Maschine in die Plattform. Das Modul liest nur; es schreibt nichts in Steuerungen zurück. Ziel der Daten ist heute PostgreSQL; die Integration in den OPAIRS® Datalake läuft und soll voraussichtlich bis Q3/2027 abgeschlossen sein.

Maschinen auf unterschiedlichen Ebenen

Eine Fertigung ist selten einheitlich. Neben neuen Anlagen mit eigenem OPC-UA-Server stehen ältere Steuerungen, Energiezähler am Modbus und einzelne Sensoren. Das Modul setzt auf benthos-umh, eine Industrie-Distribution von Benthos beziehungsweise Redpanda Connect, und deckt damit mehrere Ebenen ab:

• Sensorebene: ifm IO-Link-Master (zum Beispiel AL1350 und AL1352). Angeschlossene Sensoren werden anhand ihrer Gerätebeschreibung (IODD) automatisch in benannte Messgrößen zerlegt, etwa port1.Temperature. Auch IO-Link-Sensoren, die per Bluetooth Mesh über die Basisstation EIO404 angebunden sind, werden berücksichtigt.
• Steuerungsebene: Siemens S7 (S7-300/400/1200/1500), Beckhoff TwinCAT 2/3 über ADS (nach Symbolnamen; der Konnektor wird in der Dokumentation noch als experimentell geführt), Modbus TCP für Zähler, Umrichter und einfache SPS sowie EtherNet/IP für Rockwell ControlLogix, CompactLogix und Micro820.
• Maschinenebene: OPC UA als Standardweg moderner Maschinen, mit Zeitstempel der Quelle und Qualitätsstatus je Wert.
• Gateway- und Leitebene: Sparkplug B über MQTT sowie MQTT, HTTP, SQL und Dateien, etwa für MES, Datenbanken oder CSV-Exporte.

Nicht direkt anbindbar sind Fanuc FOCAS, Heidenhain DNC, Mitsubishi MC und Omron FINS. Dort bleibt der Weg über einen OPC-UA-Server der Maschine oder über ein Gateway. ERP-Anbindungen sind nicht Teil dieses Moduls; sie laufen über die übrigen Datenpfade der Plattform.

Vier Dienste, ein Datenweg

Vom Sensor in die Datenbank

Der Connector führt eine Pipeline aus: Quelle lesen, in das Zeilenformat der Datenbank umformen und mit einem reinen Schreibbenutzer in PostgreSQL ablegen. Eine Pipeline ist eine YAML-Datei; neue oder geänderte Pipelines brauchen keinen neuen Build. Die Datenbank läuft als eigener Dienst, ein Wartungsdienst legt alle fünf Minuten Partitionen an, räumt nach der Aufbewahrungsfrist auf und berechnet Minutenwerte. Nur für IO-Link kommt der IODD-Mirror dazu. Das OPAIRS® Dashboard und die KI-Plattform lesen mit einem eigenen Lesebenutzer.

Qualität statt Rauschen: Rohdaten, Minutenwerte und Qualitätsstatus

Jeder Messwert landet mit Zeitstempel, Maschine, Signalname, Wert und Qualitätsangabe in der Rohdatentabelle, die täglich partitioniert wird. Daraus entstehen Minutenwerte mit Mittel, Minimum, Maximum und Stichprobenzahl. Standardmäßig bleiben Rohdaten 30 Tage und Minutenwerte 400 Tage erhalten; beide Fristen sind einstellbar.

Die Qualitätsangabe stammt aus der Quelle: OPC UA meldet je Wert Good, Uncertain oder Bad. In die Minutenwerte fließen nur gute Werte ein, die übrigen zählt eine eigene Spalte. So verfälschen Störungen die Mittelwerte nicht und bleiben trotzdem sichtbar. Bei Quellen ohne Qualitätsangabe, etwa Modbus und S7, bleibt das Feld leer, und die Werte gelten als gut.

Die Datenbank ist reines PostgreSQL ohne Erweiterungen. Auf Kompression und Continuous Aggregates von TimescaleDB wird bewusst verzichtet, weil diese Community-Funktionen nicht unter einer Open-Source-Lizenz stehen, sondern unter der Lizenz des Herstellers (Timescale License, heute Tiger Data License). Der Preis dafür ist klar: Rohdaten werden kurz aufbewahrt, Minutenwerte lang. Werte mit Zeitstempel in der Zukunft, etwa durch eine falsche Uhr an der Quelle, werden gespeichert, aber nicht aggregiert.

IO-Link auch ohne Internet

IO-Link-Sensoren beschreiben sich über eine Gerätebeschreibung, die IODD. Das Plugin lädt sie standardmäßig über das Internet aus einem Spiegel des IODDfinders. Der Dienst iodd-mirror beantwortet genau diese Abfragen selbst und liefert die IODDs aus einem lokalen Ordner, als ZIP oder XML. Neue Dateien sind nach spätestens einer Minute aktiv, ein Neustart ist nicht nötig. Fehlt für einen Sensor die IODD, schaltet der Connector auf Rohdaten um und läuft weiter. Damit lässt sich IO-Link auch in Anlagen ohne Internetzugang betreiben, und Sensoren werden trotzdem automatisch erkannt.

Von der Maschine ins OPAIRS® Dashboard

Das OPAIRS® Dashboard liest mit einem Lesebenutzer, der nichts schreiben darf. Im Modul liegt ein fertiges, importierbares Dashboard „OPAIRS Connect“ mit fünf Reitern: Übersicht, CNC, Spritzguss, Montage und Rohdaten. Oben lassen sich Zeitraum (Standard: letzte Woche) und Anlage filtern; das Dashboard aktualisiert sich jede Minute.

Übersicht: Laufzeit, iO-Quote und Qualitätsprobleme

Die Übersicht fasst die Lage der Fertigung zusammen: Anlagen mit Daten, Laufzeitanteil, iO-Quote in Montage und Spritzguss und die Zahl der Werte mit Qualitätsproblem. Dazu kommen der Laufzeitanteil je Anlage und im Verlauf je Bereich sowie eine Tabelle mit dem aktuellen Stand jeder Anlage.

Fachreiter: CNC, Spritzguss und Montage

Jeder Bereich zeigt die Größen, die dort zählen: bei CNC Spindeldrehzahl, Temperatur, Leistung und Vibration, im Spritzguss Werkzeug- und Massetemperatur, Zykluszeit, Einspritzdruck und die Gründe für Teile, die nicht in Ordnung sind, in der Montage Schraubdrehmoment, Leckrate, Einpresskraft, Isolationswiderstand und die iO-Quote je Linie.

Der Agent im Dashboard

Über ein Chat-Fenster am Rand des Dashboards beantwortet der Agent OPAIRview Fragen zu den Daten der Plattform, direkt im OPAIRS® Dashboard und ohne Wechsel in ein anderes Werkzeug. Die Antwort ist gegliedert: eine Kernaussage, die Belege aus den verwendeten Quellen wie Dokumenten, Wiki-Seiten und Knowledge Graph und ein ausdrücklicher Hinweis darauf, was nicht gefunden wurde.

Für Dashboards ohne echte Maschine bringt das Modul eine Demo mit: neun simulierte Anlagen (drei CNC-Maschinen, zwei Spritzgussmaschinen und vier Montagestationen) mit Schichtbetrieb, Störungen und iO/NiO-Prüfungen, auf Wunsch mit sieben Tagen Historie. So lässt sich der ganze Weg bis ins Dashboard zeigen und prüfen, bevor die erste echte Anlage angeschlossen ist.

Heute PostgreSQL, künftig im OPAIRS® Datalake

Heute schreibt der Connector die Maschinendaten in eine eigene PostgreSQL-Datenbank. Von dort lesen das OPAIRS® Dashboard und die KI-Plattform. Parallel läuft die Integration in den OPAIRS® Datalake, in dem die übrigen Datenquellen der Plattform zusammenlaufen. Nach heutiger Planung soll sie voraussichtlich im dritten Quartal 2027 abgeschlossen sein.

Ein Zeitplan ersetzt keinen Test: Für die Integration sind durchgehend Tests mit echten Maschinendaten nötig. Simulatoren und Demo-Anlagen zeigen, dass der Datenweg technisch funktioniert, aber nicht, wie sich echte Steuerungen, Störungen und Signalnamen verhalten.

Datenhoheit bis an die Maschine

• Standardmäßig ist kein Port nach außen offen. Freigaben erfolgen nur gezielt und intern.
• Getrennte Rollen: Der Connector darf nur schreiben, das Dashboard nur lesen.
• Der Connector braucht Netzwerkzugang zu den Maschinen, aber kein Internet. Nur der erste Build benötigt Internetzugang; für Kundenumgebungen ohne Internet werden die fertigen Images übertragen.
• Es gibt keine Verbindung zu den Servern von UMH und keine Cloud-Dienste.

Damit gilt das Prinzip der Plattform, dass Daten im Haus bleiben, auch für die Maschinenebene. Gerade Maschinendaten verraten viel über Auslastung, Ausschuss und Taktzeiten.

Vom Messwert zur Prognose

Maschinendaten sind Zeitreihen, und Zeitreihen sind der Stoff für Prognosen. Die Minutenwerte mit Mittel, Minimum, Maximum und Qualitätsstatus liegen in PostgreSQL, einem der Quellsysteme, die der OPAIRS SQL-Agent erschließt. Daraus ergibt sich die Kette, die wir im Beitrag zum Prognose-Dienst beschrieben haben: Der SQL-Agent holt die Reihe, der Prognose-Dienst rechnet Prognose und Backtest, und das Ergebnis kommt mit Modellwahl, Güte und Warnungen zurück in den Chat: https://opairs-systems.com/insights/opairs-forecasting-zeitreihenprognose-on-premise

Der Prognose-Dienst bündelt Statistikmodelle (ETS, Theta, ARIMA) und die Foundation-Modelle Chronos-Bolt und TiRex-2 hinter einem Endpunkt und läuft vollständig lokal auf der CPU des Servers, die Grafikkarten bleiben für die Sprachmodelle frei. Welches Modell zum Zug kommt, entscheidet ein Backtest gegen eine einfache Baseline. Schlägt kein Modell diese Baseline, liefert der Dienst die Prognose trotzdem, markiert sie aber ausdrücklich als nicht validiert. Gerade bei verrauschten Maschinenreihen ist das wertvoll: Ein Dienst, der offenlegt, wann er seiner Prognose nicht trauen darf, schützt vor falscher Sicherheit.

Fragen, die sich damit an Maschinendaten stellen lassen:

• Wie entwickelt sich der Energiebedarf einer Anlage in den nächsten Tagen, und wann entstehen Lastspitzen?
• Wie verläuft eine Größe, die über die Schicht driftet, etwa ein steigendes Schraubdrehmoment durch Verschleiß, und wann würde ein Grenzwert erreicht?
• Wie verändern sich Laufzeitanteil oder Auslastung einer Linie über die kommenden Wochen?

Zur Einordnung: Das ist der vorgesehene Weg, keine fertige Integration. Der Prognose-Dienst ist bisher auf öffentlichen Zeitreihen geprüft; eine Prüfung mit echten Produktionszeitreihen steht noch aus. Der Prognose-Dienst ist Open Source unter Apache-2.0: https://github.com/OPAIRS/opairs-forecast

Danksagung

Die Protokollanbindung leistet benthos-umh der UMH Systems GmbH (Apache-2.0, https://github.com/united-manufacturing-hub/benthos-umh). Übernommen wurden nur die Konnektoren, nicht Kubernetes, Management Console, eingebettetes Redpanda und TimescaleDB. Dazu kommen Redpanda Connect, PostgreSQL, der IODDfinder der IO-Link Community als Quelle der Gerätebeschreibungen und Microsoft OPC PLC (https://github.com/Azure-Samples/iot-edge-opc-plc) als Testserver. Die Lizenzen und Nutzungsbedingungen, insbesondere der IODD-Dateien der Gerätehersteller, sollten vor einem Einsatz geprüft werden.

Teil der OPAIRS-Plattform

Auf der OPAIRS-Plattform ergänzt Connect Machine die bestehenden Datenpfade für ERP, Dokumente und Datenbanken um die Maschinenebene. Damit bekommt die Pipeline, die wir in „Industrial AI Pipeline: Von Daten zur KI-Empfehlung“ beschrieben haben, eine weitere Quelle: https://opairs-systems.com/insights/opairs-pipeline-von-daten-zu-entscheidungen

Gesucht: echte Maschinendaten aus der Fertigung

Simulatoren und Demo-Anlagen zeigen, dass der Datenweg funktioniert. Ob er im Alltag trägt, zeigen nur echte Anlagen. Für die Integration in den OPAIRS® Datalake und für Prognosen auf Maschinendaten sucht OPAIRS deshalb Partner, die den Weg an eigenen Steuerungen und Sensoren prüfen möchten: über OPC UA, Siemens S7, Beckhoff TwinCAT, Modbus oder IO-Link, für Prognosen idealerweise mit mindestens zwei Jahren Historie je Maschine. Die Daten bleiben dabei im eigenen Haus beziehungsweise unter der Kontrolle des Partners.

Für technische Zusammenarbeit, gemeinsame Validierung oder Industrieprojekte: office@opairs-systems.com