Industrielle Time-Series-Datenplattform: von Maschinendaten zur Entscheidung

Ihre Maschinen produzieren seit Jahren Daten. Steuerungen melden Zustände, Sensoren liefern Vibration, Temperatur und Druck im Sekundentakt, Anlagen quittieren jeden Takt. Und trotzdem sitzt die Instandhaltung am Montagmorgen vor einer Excel-Datei, die jemand von Hand aus drei Systemen zusammenkopiert hat.

Die Lücke liegt selten bei den Daten – sie liegt bei der Plattform dazwischen. Zwischen einem MQTT-Broker, der zuverlässig Nachrichten verteilt, und einem Dashboard, das eine Entscheidung stützt, steht eine Time-Series-Datenplattform: ein System, das Maschinendaten in hoher Frequenz aufnimmt, verlustfrei speichert, verdichtet und so bereitstellt, dass eine Abfrage über zwei Jahre in Millisekunden beantwortet wird.

Dieser Artikel beschreibt diese Plattform von oben: welche Schichten sie hat, welche Architekturentscheidungen wirklich zählen, wo Projekte kippen und wann sich der Eigenbau lohnt. Grundlage ist ein reales Integrationsprojekt mit HiveMQ als Broker und TigerData – der Plattform hinter TimescaleDB – als Time-Series-Datenbank.

Warum eine Time-Series-Plattform kein Data Warehouse ist

Ein Data Warehouse ist auf Geschäftsvorfälle ausgelegt: überschaubare Zeilenzahl, komplexe Joins, tägliche Ladeläufe. Maschinendaten funktionieren anders. Eine mittelgrosse Anlage erzeugt Millionen Messwerte pro Tag, jeder davon winzig, alle nach demselben Muster: Zeitpunkt, Signal, Wert.

Daraus folgen andere Anforderungen: Schreibpfade müssen Batch-Inserts im Sekundentakt aushalten. Abfragen laufen fast immer über Zeitfenster. Alte Daten müssen automatisch verdichtet, komprimiert und irgendwann gelöscht werden. Und die Plattform muss mit Datenqualität umgehen, die niemand kontrolliert – Geräte senden, was sie senden.

Genau dafür gibt es spezialisierte Engines. TigerData erweitert PostgreSQL um Hypertables, inkrementelle Rollups und Kompression, ohne die relationale Welt zu verlassen. Sie behalten SQL, Joins und Ihr bestehendes BI-Werkzeug – und bekommen Time-Series-Eigenschaften obendrauf.

Die Architektur in fünf Schichten

1. Quelle – Maschinen, Steuerungen, Sensoren

Am Anfang steht die Frage, welche Signale überhaupt relevant sind. Wer alles anschliesst, was ein Protokoll spricht, hat nach drei Monaten ein teures Datengrab. Der Einstieg ist eine Datenlandkarte: welche Anlagen, welche Signale, welche Frequenz, welcher Nutzen.

2. Broker – HiveMQ und der Unified Namespace

MQTT ist im industriellen Umfeld der De-facto-Standard, weil es leichtgewichtig ist und mit instabilen Netzen umgehen kann. Der Broker entkoppelt Sender und Empfänger: Die Maschine muss nicht wissen, wer zuhört.

Damit das nicht im Topic-Wildwuchs endet, braucht es eine Konvention. Ein Unified Namespace definiert eine hierarchische Topic-Struktur fester Tiefe, in der die Position im Pfad die Bedeutung trägt. Diese Struktur ist später Ihr Schlüssel in der Datenbank – sie sauber zu definieren ist die billigste Investition im ganzen Projekt.

3. Ingestion – roh landen, nicht unterwegs transformieren

Hier fällt die wichtigste Entscheidung. HiveMQs Enterprise Extension für PostgreSQL ist auf Durchsatz gebaut: Sie bündelt viele MQTT-Nachrichten zu einem einzigen mehrzeiligen INSERT in eine einfache Zieltabelle. Genau das wollen Sie bei Volumen – aber es heisst auch, dass der Schreibpfad nicht gleichzeitig transformieren kann.

Die Konsequenz: Die Ingestion bleibt dumm und schnell, die Transformation passiert später in der Datenbank. Also ELT statt ETL. Das ist der Punkt, an dem fast jedes Team zuerst falsch abbiegt – wir haben ihm einen eigenen Artikel gewidmet: ELT statt ETL: Warum Sie rohe MQTT-Daten zuerst landen sollten.

4. Speicher und Verdichtung – TigerData

In der Datenbank passiert das eigentliche Engineering: Ein geplanter Job zieht Rohzeilen batchweise aus der Landing-Tabelle, archiviert sie unverändert, parst sie, löst Identitäten auf und schreibt typisierte Messwerte in Hypertables. Was er nicht verarbeiten kann, landet mit Begründung im Dead-Letter.

Auf dieser Basis übernimmt die Datenbank die Verdichtung: Continuous Aggregates rechnen Minuten-, Stunden- und Tageswerte inkrementell hoch, Compression schrumpft ältere Chunks, Retention räumt automatisch auf. Details dazu im Artikel Time-Series-Schema auf TigerData.

5. Präsentation – Grafana, Power BI und Co.

Die Darstellungsschicht bleibt dünn. Semantik gehört in die Datenbank: Views, die Fakten mit Identitäten verbinden und Kennzahlen korrekt berechnen. Das Dashboard fragt nur ab. So ist die Bedeutung Ihrer Daten an einer Stelle testbar statt über dreissig Panel-Definitionen verstreut – ein Prinzip, das auch bei Power BI in der Industrie den Unterschied macht.

Die vier Fehler, an denen solche Projekte scheitern

• Transformieren im Schreibpfad. Wirkt sauber, blockiert aber den Durchsatz und macht jede Schemaänderung zum Ingest-Risiko.
• Das Schema zu früh festzurren. Zustandsmeldungen und Ereignisse ändern ihre Form. Wer sie sofort normalisiert, baut sich eine Migrations-Tretmühle. Der Ausweg: Schema-on-Read für unsaubere IoT-Payloads.
• Keine Verlustkontrolle. Wenn niemand weiss, ob eine Nachricht angekommen und verarbeitet wurde, ist jede Auswertung eine Behauptung. Siehe Dead-Lettering und Reconciliation.
• Dashboards auf Rohdaten. Funktioniert im Pilot mit drei Wochen Historie und bricht im zweiten Jahr. Rollups sind kein Optimierungsschritt für später, sondern Teil des Entwurfs.

Selber bauen oder Plattform kaufen?

Die ehrliche Einordnung: Wenn Sie zehn Maschinen überwachen und nie mehr wollen, kaufen Sie die Plattform. Wenn Maschinendaten Grundlage für Predictive Maintenance, Qualitätsanalysen und Kennzahlen über Werke hinweg werden sollen, brauchen Sie offenen Zugriff auf Ihre eigenen Daten – und dann rechnet sich der Eigenbau meist schon im zweiten Jahr.

Praxis: drei Ausgangslagen

Industrie und Logistik

Ein Sortier- oder Fertigungssystem meldet Vibration, Motorströme und Taktzeiten. Die Plattform speichert Rohsignale kurz, Minuten-Rollups lange – und liefert damit die Basis für Anomalieerkennung und OEE-Auswertungen über mehrere Linien hinweg.

Öffentlicher Verkehr

Fahrzeuge liefern Beschleunigungs-, Positions- und Zustandsdaten über instabile Mobilfunkverbindungen. MQTT puffert, wenn die Verbindung abreisst, die Plattform gleicht Zeitstempel ab und macht Fahrten vergleichbar – etwa für Komfortmessungen nach EN 12299.

Öffentliche Verwaltung und Infrastruktur

Gebäudeleittechnik, Energiezähler und Umweltsensoren senden im Minutentakt. Hier zählt Datensouveränität: TigerData läuft auf Schweizer Infrastruktur oder im eigenen Rechenzentrum – ein Argument, das in Ausschreibungen regelmässig den Ausschlag gibt.

Betrieb: was in den Tutorials fehlt

Eine Time-Series-Plattform ist kein Projekt, das fertig wird. Drei Realitäten, die wir jedem Kunden vorab sagen:

• Speicher ist die bindende Ressource, nicht Disk. Auf kleinen Managed-Instanzen konkurrieren Compression, Retention, Rollup-Refresh und Ihr eigener Transformationsjob um denselben Arbeitsspeicher. Hintergrundjobs müssen budgetiert und zeitlich versetzt werden.
• Lizenzen gehören zur Verfügbarkeit. Läuft die Lizenz der Ingest-Extension ab, stoppt der Datenfluss – der Broker läuft weiter. Von aussen sieht das exakt wie ein Datenausfall aus. Überwachen Sie es.
• Managed heisst weniger Stellschrauben. Die klassischen PostgreSQL-Memory-Parameter tunt die Plattform selbst. Ratschläge aus der Self-Hosted-Welt greifen hier nicht.

In vier Phasen zur Plattform

• Phase 1 – Signale definieren (2–3 Wochen). Datenlandkarte, Topic-Konvention, Auswahl der ersten Anlage. Kein Code.
• Phase 2 – Durchstich (4–6 Wochen). Broker, Landing-Tabelle, Transformationsjob, erste Hypertable, ein Dashboard. Ein Signaltyp, Ende zu Ende.
• Phase 3 – Härten (4–8 Wochen). Dead-Letter, Reconciliation, Rollups, Compression, Retention, Alarmierung.
• Phase 4 – Skalieren (laufend). Weitere Anlagen, weitere Standorte, Anbindung an MLOps für Modelle im Dauerbetrieb.

Wie Substring Sie unterstützt

Eine Time-Series-Plattform ist kein Datenbankprojekt – sie ist ein Datenplattform-Projekt mit harten Echtzeitanforderungen. Genau dort liegt unsere Kernkompetenz: operative Datensysteme bauen, Datenplattformen konzipieren und Modelle in Produktion bringen.

Wir begleiten Industrieunternehmen, Verkehrsbetriebe und Verwaltungen in der Schweiz über den ganzen Weg – von der ersten Datenlandkarte über Broker und Schema bis zum laufenden Betrieb.

Sie überlegen, ob sich eine eigene Time-Series-Plattform für Ihre Anlagen lohnt? → Kontakt aufnehmen – wir schauen uns Ihre Signale an und sagen Ihnen ehrlich, ob Eigenbau oder Zukauf der richtige Weg ist.

Weiterführende Glossar-Artikel

• ELT statt ETL – warum rohe MQTT-Daten zuerst landen müssen
• Time-Series-Schema auf TigerData – Hypertables, Continuous Aggregates, Compression, Retention
• Dead-Lettering und Reconciliation – keine Nachricht unbemerkt verlieren
• Schema-on-Read für IoT-Payloads – JSONB speichern, typisiert lesen
• Unified Namespace (UNS) – die Topic-Struktur als Fundament
• Manufacturing Data Architecture – die Gesamtsicht auf Fertigungsdaten