Pexon Consulting | 11 Min. Lesezeit | 20.06.2026
TL;DR
Ein Predictive Maintenance Foundation Model sagt Maschinen-Anomalien voraus, ohne dass Sie jahrelang Ausfalldaten sammeln mussten. Time-Series Foundation Models wie TimesFM 2.5 und Chronos-2 prognostizieren Sensorverläufe zero-shot — also ohne Training auf Ihren Daten. Wir bei Pexon setzen sie für das kalte Startproblem ein, wenn klassisches ML mangels Fehlerhistorie scheitert. Klassische Modelle bleiben überlegen, sobald genug Ausfälle dokumentiert sind.
Das Problem: Keine Ausfälle, kein Trainingsdatensatz
Der typische Predictive-Maintenance-Pitch setzt voraus, was die meisten Werke nicht haben: einen Berg dokumentierter Ausfälle. Ein klassisches ML-Modell lernt aus Mustern, die einem Defekt vorausgingen. Wenn eine Anlage drei Jahre ohne nennenswerten Stillstand läuft, gibt es schlicht nichts zu lernen.
Genau hier scheitern die meisten Projekte. Rund 70 Prozent des Aufwands eines Predictive-Maintenance-Projekts gehen in Data Engineering, und ein brauchbares Modell braucht Fehlerbeispiele — die fehlen, weil gut gewartete Maschinen selten ausfallen. Das ist das Henne-Ei-Problem der Branche: Man braucht Ausfälle, um Ausfälle vorherzusagen.
Die Kosten dahinter sind real. Unplanbare Stillstände kosten in High-Output-Sektoren wie Automotive und Aerospace zwischen 260.000 und 420.000 US-Dollar pro Stunde, global summiert sich ungeplanter Anlagenstillstand auf rund 50 Milliarden US-Dollar jährlich. Der Markt für Predictive Maintenance wächst entsprechend von 18,9 Milliarden US-Dollar (2026) Richtung 82 Milliarden bis 2031. Trotzdem bleibt für viele Mittelständler der Einstieg verbaut — nicht am Budget, sondern an der Datenlage.
Wir sehen das bei Werkleitern und Instandhaltungsleitern fast wöchentlich: Die Bereitschaft ist da, der Use Case ist klar, aber das erste Gespräch endet bei „Wir haben keine sauberen historischen Ausfalldaten.“ Time-Series Foundation Models drehen genau diese Reihenfolge um.
Was ein Time-Series Foundation Model anders macht
Ein Time-Series Foundation Model (TSFM) ist auf Milliarden von Zeitreihen-Datenpunkten vortrainiert und prognostiziert neue Reihen zero-shot — ohne ein einziges Beispiel aus Ihrem Werk. Das funktioniert wie ein Sprachmodell für Zahlenreihen: Es hat aus Energie-, Verkehrs-, Wetter- und Finanzdaten gelernt, wie Zeitreihen sich typischerweise verhalten, und überträgt dieses Muster auf Ihre Schwingungs-, Temperatur- oder Stromaufnahme-Kurve.
Die zwei dominierenden offenen Modelle, mit denen wir aktuell arbeiten:
Der entscheidende Unterschied zur klassischen Predictive Maintenance: Sie brauchen keine Ausfälle im Trainingsset. Das Modell prognostiziert den erwarteten Normalverlauf eines Sensors. Weicht die tatsächliche Messung signifikant von der Prognose ab, ist das Ihr Anomalie-Signal — ohne dass das Modell je einen echten Defekt gesehen hat. Diese prognosebasierte Anomalieerkennung ist der Mechanismus, der das kalte Startproblem löst.
In der Praxis bedeutet das: Sie ziehen ein paar Wochen SCADA- oder IoT-Daten, lassen das Modell den nächsten Horizont vorhersagen und vergleichen mit der Realität. Keine Trainings-Pipeline, kein MLOps-Setup, kein Labeling. Das ist der Grund, warum wir TSFMs als Einstiegsmechanismus einsetzen, nicht als Endausbau.
Zero-Shot-Forecast in der Praxis: Code
So sieht ein Zero-Shot-Forecast mit TimesFM 2.5 aus. Der Code lädt das vortrainierte Modell und prognostiziert den nächsten Horizont — ohne jedes Training auf Ihren Daten. In der Realität ersetzen Sie die synthetischen Eingaben durch Ihre tatsächlichen Sensorzeitreihen (z.B. Lagertemperatur, Schwingungs-RMS).
import numpy as np
import timesfm
# Vortrainiertes Modell laden — kein Training auf eigenen Daten nötig
model = timesfm.TimesFM_2p5_200M_torch.from_pretrained(
"google/timesfm-2.5-200m-pytorch",
torch_compile=True,
)
# Forecast-Konfiguration: Kontextlänge, Horizont, Quantile für Unsicherheit
model.compile(
timesfm.ForecastConfig(
max_context=1024, # bis zu 1024 historische Messpunkte
max_horizon=256, # so weit in die Zukunft prognostizieren
normalize_inputs=True,
use_continuous_quantile_head=True, # Konfidenzbänder statt nur Punktwert
fix_quantile_crossing=True,
)
)
# Hier würden zwei echte Sensor-Zeitreihen stehen
point_forecast, quantile_forecast = model.forecast(
horizon=12,
inputs=[
np.linspace(0, 1, 100), # Beispiel: leicht steigender Trend
np.sin(np.linspace(0, 20, 67)),# Beispiel: periodisches Signal
],
)
# point_forecast.shape -> (2, 12) Punktprognose je Reihe
# quantile_forecast.shape -> (2, 12, 10) 10 Quantile = UnsicherheitsbandDer zweite Schritt ist die Anomalie-Logik: Liegt die echte Messung außerhalb des Quantil-Bands (z.B. über dem 90.-Perzentil-Verlauf), schlägt das System Alarm. Hier eine minimale Variante:
import numpy as np
# Annahme: gemessene Werte und die prognostizierten Quantile für denselben Horizont
gemessen = np.array([0.91, 0.93, 0.97, 1.08, 1.21]) # echte Sensorwerte
unteres_band = quantile_forecast[0, :5, 1] # z.B. 10. Perzentil
oberes_band = quantile_forecast[0, :5, 8] # z.B. 90. Perzentil
# Anomalie = Messung verlässt das prognostizierte Konfidenzband
anomalie = (gemessen > oberes_band) | (gemessen < unteres_band)
if anomalie.any():
print(f"Abweichung in {anomalie.sum()} von {len(gemessen)} Schritten — Inspektion einplanen")Das ist kein Spielzeug — es ist exakt das Muster, mit dem ein Pilot in wenigen Tagen erste Signale liefert. Der Code läuft auf einer einzelnen GPU; TimesFM verarbeitet über 300 Forecasts pro Sekunde.
Wann zero-shot — und wann klassisches ML besser ist
Hier kommt die unbequeme Wahrheit, die Anbieter-Whitepaper gern verschweigen: Ein Foundation Model ist nicht automatisch besser. Bei der reinen Anomalieerkennung mit ausreichend Historie schlagen gut etablierte klassische Verfahren die vortrainierten Modelle in unabhängigen Benchmarks bei Effektivität, Laufzeit und der Fähigkeit, einzelne Fehlertypen zu unterscheiden, weiterhin statistisch.
Unsere klare Empfehlung: Nutzen Sie den TSFM, um aus dem Nichts heraus zu starten, und migrieren Sie auf ein spezialisiertes Modell, sobald Sie genug echte Ausfälle gesammelt haben. Das ist kein Entweder-oder, sondern eine Reihenfolge.
Ein zweiter wichtiger Punkt: Zero-shot heißt nicht „fertig“. Ein Modell, das im Labor 90 Prozent Genauigkeit zeigt, kann im Produktivbetrieb durch Saisonalität, Schichtbetrieb und Produktionsschwankungen deutlich abfallen. Deshalb validieren wir jeden Piloten gegen echte Betriebsdaten, bevor jemand eine Wartung danach plant. Wer das überspringt, baut Vertrauen auf einer Laborzahl auf.
Was Sie für den Einstieg brauchen
Die gute Nachricht für Instandhaltungs- und IoT-Verantwortliche: Sie brauchen weniger, als die meisten Anbieter behaupten. Statt monatelang neue Sensorik zu verkabeln, reicht in den meisten Fällen, was schon da ist.
Konkret prüfen wir am Anfang vier Dinge:
- Vorhandene Sensorquellen — SCADA, OPC-UA, bestehende IoT-Plattform. Schwingung, Temperatur, Stromaufnahme reichen oft.
- Datenfrequenz und -kontinuität — TimesFM 2.5 nutzt bis zu 16k Kontextpunkte; mehr kontinuierliche Historie schlägt mehr Sensoren.
- Anbindung an eine Datenplattform — damit die Prognosen nicht in einem Notebook versanden, sondern in Dashboards und Alerts landen.
- Klar definierter erster Anwendungsfall — eine Anlage, ein Fehlerbild, ein messbares Ziel. Kein werksweiter Rollout im Schritt eins.
Den dritten Punkt unterschätzen viele. Ein Forecast ist nur so nützlich wie der Weg, auf dem er beim Schichtleiter ankommt. Wir koppeln die Modelle deshalb direkt an eine bestehende Datenplattform — wie wir es im risikoarmen Datenplattform-Pilot mit Microsoft Fabric beschreiben — statt ein isoliertes ML-Tool danebenzustellen. Die KI-Wertschöpfungskette für die Fertigung zeigt, wo Predictive Maintenance in den größeren Bauplan passt.
Für den Datenfluss selbst nutzen wir meist eine AI-ready Datenplattform auf Microsoft Fabric, weil Sensor-Ingest, Forecast-Job und Alerting dort in einer Pipeline zusammenlaufen — ohne dass Sie drei Tools integrieren müssen.
Kosten und Zeitrahmen
Der Reiz von zero-shot liegt im Wegfall der teuersten Phase: dem monatelangen Sammeln und Labeln von Ausfalldaten. Ein klassisches Projekt braucht 3-6 Monate Data Engineering, bevor das erste Modell überhaupt rechnet. Mit einem Foundation Model verschiebt sich der erste belastbare Forecast auf wenige Tage.
Das macht Predictive Maintenance zu einer der KI-Investitionen mit dem klarsten Return-Profil im industriellen Umfeld. Werke berichten von 10-40 Prozent niedrigeren Wartungskosten und 70-90 Prozent weniger ungeplanten Stillständen — wobei diese Zahlen den ausgereiften Endzustand beschreiben, nicht den ersten Piloten. Wir kommunizieren das bewusst nüchtern: Der Pilot liefert das Signal und den Business Case, der Vollausbau liefert die Einsparung.
Unser Vorgehen ist ein 6-Wochen-Pilot auf einer Anlage mit vorhandenen Daten. Am Ende steht eine validierte Aussage, ob die Anomaliesignale für Ihre Maschine tragen — bevor Sie über Sensorik-Investitionen oder einen werksweiten Rollout entscheiden. Wer Predictive Maintenance bislang am Datenmangel aufgeschoben hat, hat damit einen Weg, der diese Woche beginnen kann. Den größeren strategischen Rahmen, warum gerade der Mittelstand hier aufholen sollte, haben wir in KI in der Fertigung für den Mittelstand ausgeführt.
Wer das Verfahren technisch nachvollziehen will: Der Code und die Modelle sind offen — das TimesFM-Repository von Google Research enthält Beispiele, Checkpoints und Benchmarks.
Häufig gestellte Fragen
Was kostet ein Predictive-Maintenance-Pilot mit einem Foundation Model?
Der größte Kostenblock klassischer Projekte — Monate an Datenengineering — entfällt, weil zero-shot kein Training braucht. Ein erster validierter Pilot auf einer Anlage liegt deutlich unter einem Vollprojekt, weil weder neue Sensorik noch eine MLOps-Pipeline nötig sind. Die Modelle selbst (TimesFM 2.5, Chronos-2) sind open source und kostenlos; relevant sind Compute und Integration.
Funktioniert Predictive Maintenance wirklich ohne historische Ausfalldaten?
Ja, aber mit einer Einschränkung. Ein Time-Series Foundation Model prognostiziert den erwarteten Normalverlauf eines Sensors und meldet Abweichungen davon als Anomalie — dafür braucht es keine vergangenen Defekte. Was es nicht kann: bestimmte Fehlertypen voneinander unterscheiden. Das lernt erst ein spezialisiertes Modell, sobald echte Ausfälle dokumentiert sind.
TimesFM oder Chronos-2 — welches Modell ist besser?
Kommt auf die Datenlage an. TimesFM 2.5 hat mit 16k einen sehr großen Kontext und eignet sich für lange, einzelne Sensorreihen. Chronos-2 ist stärker, wenn Sie Kovariaten wie Schichtplan oder Anlagenlast zero-shot einbeziehen wollen oder mehrere Reihen gemeinsam prognostizieren. In Piloten testen wir oft beide gegen dieselben Daten.
Wie viele Daten braucht das Modell mindestens?
Wenige Wochen kontinuierlicher Sensordaten reichen für erste Signale, weil das Modell bereits vortrainiert ist. Mehr lückenlose Historie hilft mehr als zusätzliche Sensoren — TimesFM 2.5 verarbeitet bis zu 16.000 Messpunkte Kontext. Wichtig ist Kontinuität: viele Lücken verschlechtern die Prognose stärker als eine kürzere, saubere Reihe.
Ersetzt ein Foundation Model unser klassisches ML-Modell?
Nein, es löst ein anderes Problem. Sobald Sie genug echte Ausfälle gesammelt haben, schlägt ein spezialisiertes klassisches Modell den zero-shot-Ansatz in der Regel bei Genauigkeit und Laufzeit. Der sinnvolle Weg ist eine Reihenfolge: zero-shot zum Start, klassisches ML im Vollausbau. Das Foundation Model verschafft Ihnen die Zeit, bis die eigene Datenbasis trägt.
Nächster Schritt
Wenn Sie Predictive Maintenance bisher am fehlenden Ausfalldatensatz aufgeschoben haben: Ein Readiness-Check klärt in einem strukturierten Gespräch, ob Ihre vorhandenen Sensordaten für einen Zero-Shot-Piloten ausreichen — bevor Sie in Sensorik oder Modelle investieren.
Verwandte Themen
