Das Problem
Die Daten sind in der Steuerung vorhanden: Zustände, Zähler, Temperaturen, Störungen. Nutzen kann sie aber nur, wer an der Anlage steht. Für Service, Produktentwicklung und Ihre Kunden sind sie unsichtbar.
Erste Versuche enden oft als Pilot an einer Maschine: ein Skript, eine Datenbank, ein Dashboard. Sobald die zweite Anlage dazukommt, die Verbindung abbricht oder jemand einen Wert umbenennt, hält die Lösung nicht mehr.
So kommen Maschinendaten per OPC UA in die Datenbank
Am Anfang steht das Datenmodell: welche Werte, mit welchen Namen, Einheiten und Zeitstempeln, für welche Anlagentypen. Das legen wir mit Ihren Entwicklern fest, bevor wir Code schreiben.
Ein Python-Dienst auf dem Edge-Gerät liest die Werte per OPC UA aus der Steuerung, oder die Steuerung schickt sie per MQTT. Die Nachrichten gehen über einen Message-Broker (RabbitMQ oder ein MQTT-Broker) weiter. Telegraf schreibt sie in eine Zeitreihen-Datenbank, Grafana zeigt sie an. Eine REST-Schnittstelle (FastAPI) stellt die Daten Ihren anderen Systemen bereit.
Das funktioniert für Maschinen, die bei Ihren Kunden stehen, genauso wie für eigene Anlagen und Module, die Sie selbst überwachen wollen.
Seit 12. September 2026 müssen Hersteller neu in Verkehr gebrachter vernetzter Produkte den Nutzern laut Data Act Zugang zu den erzeugten Daten ermöglichen. Ob Ihr Produkt darunter fällt, klären Sie rechtlich. Technisch ist eine Datenpipeline mit Schnittstelle die Grundlage dafür.
Was Sie bekommen
- ein dokumentiertes Datenmodell für Ihre Anlagentypen
- die Erfassung auf dem Edge-Gerät, mit Pufferung bei Verbindungsverlust
- Message-Broker, Zeitreihen-Datenbank und Dashboards
- eine Schnittstelle für ERP, Service-Software oder Kundenportale
- Code und Konfiguration in Ihrem Repository
Grenzen
Wir lesen Daten aus der Steuerung, wir programmieren sie nicht. Fehlt eine Schnittstelle, Sensorik oder Verkabelung, übernehmen das Ihre SPS-Leute oder unser Partner aus der Automatisierungstechnik.