Produktionsdaten visualisieren: vom Maschinensignal zum Shopfloor-Dashboard

Produktionsdaten visualisieren heißt, Signale aus Steuerungen und Sensoren so aufzubereiten, dass eine Schicht, eine Fertigungsleitung oder eine Instandhaltung daraus eine Entscheidung ableiten kann. Technisch braucht das vier Schichten: Erfassung, Transport über einen MQTT-Broker, eine Zeitreihendatenbank und ein Dashboard. Dieser Artikel benennt den Stack konkret – mit Abtastraten, Aufbewahrungsfristen, einer ehrlichen Grenzbeschreibung für Grafana und Gestaltungsregeln für einen Hallenmonitor, den die Schicht auch liest.

Was heißt „Produktionsdaten visualisieren“ konkret?

Die Antwort hängt davon ab, wer die Daten lesen soll. Hinter der Aufgabe „Produktionsdaten visualisieren“ stecken in der Praxis drei verschiedene Aufträge mit drei verschiedenen Anforderungen. Wer sie in einem einzigen Shopfloor-Dashboard vermischt, bekommt eine Anzeige, die für niemanden richtig ist: zu träge für die Schicht, zu grob für die Instandhaltung, zu detailliert für die Geschäftsleitung.

Daraus folgt der gesamte Aufbau. Ein Hallenmonitor braucht Livewerte und eine Datenbank, die den letzten Wert in Millisekunden liefert. Ein Analyse-Dashboard braucht saubere Aggregate über Wochen und einen Bezug zu Auftrag und Schicht. Ein Monatsbericht braucht vor allem Definitionen, die sich nicht von Monat zu Monat ändern. Welche Kennzahlen dafür überhaupt taugen und wie Verfügbarkeit, Leistung und Qualität sauber definiert werden, steht in OEE berechnen: Formel, Rechenbeispiel und Datenquellen.

Die vier Schichten des Stacks

Wer Maschinendaten visualisieren will, braucht einen Stack aus vier Schichten mit klar getrennten Aufgaben: Erfassung, Transport, Speicherung, Darstellung. Die Trennung sorgt dafür, dass ein neuer Sensor, eine andere Datenbank oder ein zweites Dashboard nicht den Rest des Systems anfasst – und dass jede Schicht einzeln getestet und ausgetauscht werden kann.

1. 01

   Erfassung: Steuerung, Sensor oder Terminal

   Die Daten kommen aus der Steuerung über OPC UA oder herstellerspezifische Protokolle, aus nachgerüsteten Sensoren oder aus einer Terminaleingabe. Auch Bestandsmaschinen ohne Schnittstelle lassen sich anbinden. Das Mittelstand-Digital Zentrum Chemnitz beschreibt in seinen Retrofit-Grundlagen, wie nachgerüstete Sensoren Betriebszustände erkennen. Von dort gehen die Werte über Protokolle wie MQTT oder OPC UA an übergeordnete Systeme. Ohne diese Schicht gibt es nichts zu visualisieren; mit einer schlechten liefert jedes Dashboard falsche Zahlen. Was automatisch aus der Maschine kommt und was Menschen buchen, trennt BDE oder MDE? Unterschied, Datenquellen und Reihenfolge.

2. 02

   Transport und Entkopplung: der MQTT-Broker

   Ein MQTT-Broker entkoppelt Erzeuger und Verbraucher. Die Maschine publiziert einmal; Datenbank, Dashboard und später ein MES abonnieren, ohne dass die Steuerung davon etwas merkt. Wer die Topics strukturieren will, kann auf die Sparkplug-Spezifikation der Eclipse Foundation zurückgreifen: Sie definiert einen MQTT-Topic-Namensraum, das Payload-Format und das Session-State-Management für IIoT-Anwendungen (Version 3.0 vom 21. Oktober 2022). Wird diese Schicht übersprungen, schreibt jeder Kollektor direkt in die Datenbank – das funktioniert bei drei Maschinen und zerfällt bei dreißig. Wie ein werksweiter Namensraum aussieht, zeigt Unified Namespace: Architektur mit konkretem ISA-95-Topic-Schema.

3. 03

   Speicherung: die Zeitreihendatenbank

   Eine Zeitreihendatenbank speichert Messwerte mit Zeitstempel und ist darauf optimiert, letzte Werte schnell zu liefern und Zeiträume zu verdichten. InfluxDB 3 Core etwa beschreibt sich in der eigenen Dokumentation als Datenbank zum Sammeln, Verarbeiten, Transformieren und Speichern von Ereignis- und Zeitreihendaten. Die Abfragen sollen laut derselben Dokumentation schnell genug für Dashboards und interaktive Oberflächen antworten. Ohne diese Schicht zeigt das Dashboard nur, was gerade passiert – und nichts von gestern.

4. 04

   Darstellung: das Dashboard

   Das Dashboard ist die sichtbare Spitze, technisch aber die austauschbarste Schicht. Grafana kann laut eigener Dokumentation Metriken, Logs und Traces abfragen, visualisieren, mit Alarmen versehen und erkunden – unabhängig davon, wo die Daten gespeichert sind. Wer die drei Schichten darunter sauber gebaut hat, kann das Dashboard-Werkzeug wechseln, ohne die Erfassung anzufassen.

Ob eine Maschine über OPC UA oder MQTT angebunden wird, ist eine Frage der Schnittstelle, nicht der Visualisierung; OPC UA oder MQTT? Entscheidungsleitfaden für die Maschinenanbindung behandelt sie ausführlich. Beide Wege münden am Ende in denselben Broker und dieselbe Datenbank.

Abtastrate, Aggregation und Aufbewahrung

Wie oft gemessen werden muss, hängt vom Signaltyp ab, nicht vom Wunsch nach möglichst vielen Daten. Zustandswechsel – läuft, steht, rüstet, Störung – werden ereignisgesteuert erfasst: ein Datensatz pro Wechsel mit Zeitstempel, sonst nichts. Analogwerte wie Temperatur, Druck oder elektrische Leistung werden zyklisch abgetastet, und zwar so schnell, wie die Physik des Prozesses es verlangt. Eine Ofentemperatur ändert sich in Minuten, ein Spindelstrom in Millisekunden.

Rohdaten kurz, Aggregate lang – das ist die Grundregel der Aufbewahrung. Zeitreihendatenbanken bringen dafür eigene Mechanismen mit. TimescaleDB ergänzt Zeitreihenfunktionen in PostgreSQL und materialisiert mit Continuous Aggregates zeitlich verdichtete Sichten. Diese werden laut Dokumentation im Hintergrund automatisch aktualisiert, sobald neue Daten eintreffen, und lassen sich abfragen wie normale Tabellen. Wie elektrische Leistung dem einzelnen Auftrag zugeordnet wird und welche Rolle der Lastgang des Netzbetreibers spielt, behandelt Energiemonitoring in der Produktion: Messkonzept, Lastgang und Maschinenbezug.

Ein Rechenbeispiel zur Größenordnung: Angenommen, eine Halle hat 20 Maschinen mit je 10 zyklischen Prozesswerten, abgetastet mit 1 Hz. Das sind 200 Werte pro Sekunde, also 17,28 Millionen Messwerte pro Tag und rund 6,3 Milliarden pro Jahr. Auf Minutenmittel verdichtet bleiben 288 000 Werte pro Tag – ein Sechzigstel. Wie viel Speicher das in Byte belegt, hängt von Kompression und Datenbank ab; die Größenordnung zeigt aber, warum niemand Rohdaten mit 1 Hz über Jahre vorhalten sollte.

Zeitreihendatenbank oder klassische Datenbank?

Eine dedizierte Zeitreihendatenbank für die Produktion ist die richtige Wahl, wenn viele Tags mit hoher Rate ankommen und die Abfragen überwiegend Zeitverläufe sind. Eine relationale Datenbank – meist PostgreSQL – ist die richtige Wahl, wenn Produktionsdaten mit Aufträgen, Schichten, Artikeln und Personal verknüpft werden müssen. Dazwischen liegt mit TimescaleDB eine dritte Option, die Zeitreihenfunktionen in PostgreSQL nachrüstet. Vier Kriterien entscheiden.

Ein konkretes Beispiel dafür, warum Editionsgrenzen geprüft gehören, ist InfluxDB 3 Core, die quelloffene Ausgabe. Sie ist laut Dokumentation auf Echtzeit-Monitoring und aktuelle Daten ausgelegt. Die Konfigurationsdokumentation nennt mit Standardeinstellungen einen Abfragehorizont von bis zu 72 Stunden. Für längere Zeiträume verweist InfluxData auf die Enterprise-Ausgabe (Dokumentationsstand September 2026). Für einen Hallenmonitor reicht das; für ein Analyse-Dashboard über Quartale nicht. Solche Grenzen stehen selten im Angebot, aber immer in der Dokumentation.

Zur Datenhoheit: Produktionsdaten enthalten Taktzeiten, Ausschussquoten und Auslastung – Informationen, die kein Betrieb ungeprüft in eine fremde Cloud geben sollte. Alle genannten Systeme lassen sich on-premise oder bei einem Hoster in der EU betreiben. Entscheidend ist weniger der Standort als die Frage, wer Backup, Updates und Zugriffsrechte verantwortet und ob die Daten jederzeit in einem offenen Format exportiert werden können.

Grafana in der Produktion: was gut geht und wo es aufhört

Grafana ist für Zeitreihen, Alarmierung und Hallenmonitore ein sehr gutes Werkzeug – und für alles, was Eingaben, Freigaben oder Auftragslogik braucht, das falsche. Beides ist keine Wertung, sondern folgt daraus, wofür die Software gebaut ist. Laut Grafana-Dokumentation dient sie dazu, Metriken, Logs und Traces abzufragen, zu visualisieren, zu alarmieren und zu erkunden, gleich wo sie gespeichert sind; Datenquellen werden über ein Plugin-System angebunden.

Die Grenze verläuft also nicht zwischen gut und schlecht, sondern zwischen Anzeigen und Bearbeiten. Sobald eine Schicht einen Stillstandsgrund nachtragen, ein Meister einen Wert freigeben oder ein Auftrag einer Maschine zugeordnet werden soll, braucht es eine Anwendung mit Datenmodell, Rollen und Änderungshistorie. Ein bewährtes Muster ist beides nebeneinander: Grafana für Zeitreihen und Alarme, eine eigene Anwendung für Erfassung, Auftragsbezug und Berichte – auf derselben Datenbank.

Ein Hallenmonitor, den die Schicht auch liest

Ein Hallenmonitor wird aus fünf bis zehn Metern Entfernung im Vorbeigehen gelesen – das bestimmt jede Gestaltungsentscheidung. Was in dieser Situation nicht in drei Sekunden erfassbar ist, wird nicht gelesen. Ein typisches Muster des Scheiterns: ein großer Bildschirm mit zwei Dutzend Kacheln, deren Zahlen niemand plausibilisieren kann und die nach zwei Wochen niemand mehr ansieht.

Was das kostet – und was Open Source nicht kostenlos macht

Open Source spart Lizenzkosten, keinen Betrieb. Grafana OSS ist laut Grafana Labs kostenlos und selbst zu hosten, Grafana Enterprise fügt kommerzielle Funktionen hinzu. Grafana Cloud ist eine von Grafana Labs vollständig verwaltete Plattform mit kostenlosem Einstiegstarif und kostenpflichtigen Stufen. InfluxDB 3 Core ist die quelloffene Ausgabe von InfluxDB 3, mit den oben beschriebenen Grenzen. Keines dieser Systeme ist nach der Installation fertig. Lizenzmodelle und Editionsgrenzen ändern sich zudem regelmäßig – die Angaben in diesem Artikel entsprechen dem Dokumentationsstand September 2026 und gehören jährlich geprüft.

• —Betrieb der Datenbank: Backup, Wiederherstellungstest, Überwachung von Speicherplatz und Schreiblast. Eine Zeitreihendatenbank ohne Monitoring fällt genau dann aus, wenn die Halle voll läuft.
• —Update- und Patch-Zyklen für Broker, Datenbank und Dashboard – jede Komponente hat ihren eigenen Release-Takt und ihre eigenen Breaking Changes.
• —Hardware oder Hosting in der EU, einschließlich Netzwerksegmentierung zwischen Maschinennetz und Büro-IT.
• —Modellierung: Tag-Namensraum, Schichtkalender, Zustandsdefinitionen – der eigentliche Aufwand, der in keiner Lizenz steckt.
• —Zuständigkeit im Betrieb: eine benannte Person je System und je Dashboard, mit Stellvertretung.
• —Schulung der Schicht und der Meister – nicht in der Bedienung, sondern in der Bedeutung der Zahlen.
• —Exit: Export der Rohdaten und Aggregate in ein offenes Format, getestet, bevor er gebraucht wird.

Typische Fehler beim ersten Dashboard

Die meisten Fehler beim ersten Produktionsdashboard liegen nicht in der Software, sondern in den Definitionen darunter. Sie fallen erst auf, wenn die Zahlen auf dem Monitor mit der Erfahrung der Schicht kollidieren.

Nicht synchronisierte Zeitstempel

Steuerung, Edge-Gerät und ERP laufen mit drei Uhren. Weichen sie um Minuten ab, wandert ein Stillstand in die falsche Schicht oder den falschen Auftrag. Abhilfe: eine gemeinsame Zeitquelle per NTP, Zeitstempel in UTC speichern, Anzeige in Lokalzeit.

Fehlende Einheiten

Ein Wert 42 ohne Einheit ist kein Messwert. Die Einheit gehört an das Signal, nicht in die Kachelbeschriftung – sonst zeigt das nächste Dashboard bar als kPa.

Stillstand als Nullwert

Wenn die Maschine nichts sendet, ist der Wert nicht 0, sondern unbekannt. Wer Lücken mit Nullen füllt, senkt Mittelwerte und erzeugt Stillstände, die es nicht gab. Lücke speichern, Lücke anzeigen.

Kennzahl ohne Bezugszeit

„Ausbringung 812“ – seit wann? Jede Kennzahl trägt ihren Zeitraum. Schichtwechsel und Pausen müssen im Kalender hinterlegt sein, nicht im Kopf des Meisters.

Dashboard ohne Eigentümer

Ein Dashboard ohne benannte Person veraltet in Monaten: Maschinen werden umbenannt, Signale verschoben, Kacheln zeigen Konstanten. Eigentümer, Prüfintervall und Änderungshistorie gehören zu jedem Board.

Bericht aus Rohdaten

Ein Monatsbericht, der bei jedem Aufruf aus 1-Hz-Rohdaten gerechnet wird, dauert lange und liefert leicht abweichende Zahlen, sobald Nachzügler eintreffen. Berichte kommen aus festgeschriebenen Aggregaten.

Fazit: Definitionen zuerst, Werkzeuge danach

Produktionsdaten visualisieren ist vor allem Definitionsarbeit; die Werkzeugwahl ist der kleinere Teil. Wer Zielgruppe, Signaltypen, Aufbewahrung und Zustandsdefinitionen festgelegt hat, baut den Stack aus Erfassung, MQTT-Broker, Zeitreihendatenbank und Grafana in überschaubarer Zeit auf. Er weiß dann vorher, an welcher Stelle Grafana aufhört und eine eigene Anwendung mit Auftragsbezug, Nacherfassung und Freigaben beginnt.

Der sinnvolle nächste Schritt ist klein: eine Linie, sechs Kacheln, zwei Wochen Parallelbetrieb neben der bisherigen Zählung. Wenn Sie dabei Unterstützung bei Datenmodell, Stack oder dem Übergang zur eigenen Anwendung brauchen, beschreibt die Seite Datenvisualisierung für die Produktion, wie ralwo dabei vorgeht.