Zuerst zugeben, was Sie noch nicht vorhersagen können
Die ehrliche Antwort auf „Können wir Predictive Maintenance machen?“ lautet meistens: noch nicht — und nicht so, wie Sie es meinen. Was Sie mit ziemlicher Sicherheit können, ist Zustandsüberwachung, und in den meisten Werken hebt die den Großteil des vorhandenen Nutzens, zu einem Bruchteil der Kosten. Das ist kein Trostpreis. Es ist der richtige erste Schritt, und ihn zu überspringen ist der zuverlässigste Frühindikator für ein Projekt, das als Dashboard endet, das niemand öffnet.
Die Verwirrung ist eine Definitionsfrage, und sie ist teuer. „Predictive Maintenance“ steht für drei verschiedene Dinge mit völlig unterschiedlichem Datenhunger: zu wissen, dass eine Maschine jetzt gerade außerhalb ihres zulässigen Fensters läuft; zu wissen, dass sie sich anders verhält als sie selbst sonst; und zu wissen, dass sie in ungefähr N Tagen ausfällt. Nur das Dritte ist Vorhersage. Nur das Dritte braucht gelabelte Ausfälle. Das Erste braucht einen Sensor und eine Zahl. Unter den Anwendungsfällen, die vorhersagen und markieren, ist dies der datenhungrigste.
Drei Stufen: Überwachen, Auffälligkeiten, Vorhersage
Verkauft werden die drei als ein Produkt. Es sind drei getrennte Engineering-Probleme mit drei getrennten Datenrechnungen — und Sie durchlaufen sie der Reihe nach, ob Sie das geplant haben oder nicht.
Zustandsüberwachung — die Stufe, die alle überspringen
Sie messen eine Größe, die mit dem Zustand korreliert — Schwinggeschwindigkeit, Lagertemperatur, Motorstrom, Partikelzahl im Öl — und schlagen Alarm, wenn sie ihr Band verlässt. Kein Modell. Häufig überhaupt kein maschinelles Lernen. Für rotierende Maschinen liefert Ihnen die ISO 20816 (Nachfolgerin der ISO 10816) fertige Bewertungszonen für Breitband-Schwingungen nach Maschinenklasse; der „Algorithmus“ ist eine Tabelle, die andere über Jahrzehnte validiert haben. Das ist ein Vorzug, keine Blamage: erklärbar, gegenüber einem Auditor vertretbar, und ab Tag eins wirksam statt nach einem Jahr Datensammeln.
Der Grund, hier anzufangen, ist nicht nur der Preis. Zustandsüberwachung zwingt Sie, genau die Probleme zu lösen, die das ML-Projekt ohnehin erledigt hätten: Daten von der SPS herunterbekommen, sie konsistent mit Zeitstempeln versehen, festlegen, wer beim Alarm angerufen wird — und herausfinden, dass der Alarm elfmal pro Schicht auslöst, weil niemand daran gedacht hat, dass die Maschine montags erst warmläuft. Lösen Sie das mit einem Grenzwert, dann hat das Modell später, falls Sie es dann noch wollen, überhaupt einen Ort zum Leben.
Anomalieerkennung — nützlich und regelmäßig überverkauft
Anomalieerkennung braucht keinen einzigen gelabelten Ausfall. Füttern Sie sie mit ein paar Monaten Normalbetrieb, und ein Isolation Forest oder ein Autoencoder lernt die Form des Üblichen und markiert Abweichungen davon. Das ist wirklich nützlich, und dort sitzt der ehrlichste Teil des ML-Nutzens im Werk.
Seien Sie aber präzise, was Ihnen das sagt: dass sich etwas verändert hat. Nicht was, nicht ob es zählt, nicht wann es weh tut. Markiert werden der neue Bediener, die neue Rohmaterialcharge, die geänderte Rezeptur und der Nachmittag, an dem die Halle 34 °C erreicht hat — alles echte Anomalien, keine davon ein Defekt. Ohne Betriebskontext neben dem Sensorstrom (welches Produkt, welche Last, welche Schicht) haben Sie einen teuren Veränderungsmelder gebaut.
Der Fehlermodus ist hier sozial, nicht technisch. Ein Alarm ohne vorgeschriebene Reaktion wird zuerst ignoriert, dann stummgeschaltet, dann gelöscht. Bevor jemand einen Schwellwert justiert, beantworten Sie: Wer schaut hin, wenn er auslöst, und was darf diese Person daraufhin tun? Lautet die Antwort „da würden wir mal draufschauen“, ist das Projekt bereits tot — es weiß es nur noch nicht.
Vorhersage — was sie tatsächlich verlangt
Echte Vorhersage — Restlebensdauer, „diese Spindel hat noch etwa drei Wochen“ — ist überwachtes Lernen. Sie braucht Run-to-Failure-Verläufe: die Sensorhistorie bis zum Ausfall, mit diesem Ausfall gelabelt, oft genug wiederholt, dass sich das Muster vom Rauschen trennt. Wie viele genug sind, hängt davon ab, wie konsistent der Ausfallmechanismus ist — aber eins ist keine Zahl, und drei auch nicht.
Und hier die Falle, die die Datenmenge stillschweigend gleich zweimal halbiert: Es muss pro Ausfallmechanismus sein. Eine Pumpe fällt durch Lagerverschleiß aus, durch Dichtungsverschleiß, durch Kavitation und durch Laufraderosion. In den Daten sehen diese vier nicht im Entferntesten gleich aus; es sind vier getrennte Vorhersageprobleme. Zwanzig Pumpenausfälle auf vier Mechanismen verteilt sind fünf Beispiele pro Fall. Ihre zwanzig lösen sich in dem Moment auf, in dem Sie sauber segmentieren.
Warum gelabelte Ausfälle bei Predictive Maintenance der Engpass sind
Jetzt die unbequeme Rechnung. Ein Zulieferer mit 40 CNC-Maschinen und ordentlicher Instandhaltung erlebt vielleicht eine Handvoll ungeplanter Spindelausfälle pro Jahr. Über drei Jahre vorgehaltener Daten sind das etwa ein Dutzend Ereignisse, verteilt über mehrere Maschinentypen und mehrere Ausfallmechanismen. Daraus lernt kein Modell ein belastbares Muster, und kein Feature Engineering rettet das. Was zu dem Satz führt, den im Vertriebsgespräch niemand ausspricht: Ihre gute Instandhaltung ist genau das, was Vorhersage statistisch unmöglich macht. Die Werke mit genug Ausfalldaten zum Lernen sind die Werke, die zuerst ihre Instandhaltung reparieren sollten.
Daraus folgt strukturell etwas, das mehr wert ist als jeder Modellierungstipp: Predictive Maintenance ist ein Flottenproblem, kein Maschinenproblem. Wenn Sie 40 Maschinen betreiben, kommen die Ausfälle womöglich nie zusammen. Wenn Sie 800 bauen und die bei Ihren Kunden laufen, haben Sie Ausfallereignisse aus 800 Maschinen einer Baureihe mit derselben Sensorik — und die Rechnung dreht sich um. Deshalb sind die Unternehmen, bei denen das wirklich trägt, häufiger Maschinenbauer, die es als Service verkaufen, als die Werke, die es einkaufen. Wenn Sie als Maschinenbauer abwägen, ob Sie Ihren Bestand instrumentieren: Das ist ein weit besser fundiertes Vorhaben als derselbe Aufwand in einer einzelnen Fabrik. Und wenn Sie die Fabrik sind, ist der ehrliche Zug womöglich, es beim Lieferanten einzufordern statt selbst zu bauen.
Selbst wo die Ausfälle da sind, sind die Labels schlechter als gedacht. Sie liegen im Instandhaltungssystem — SAP PM, Maximo oder eine geteilte Tabelle — und der Zeitstempel eines Auftrags ist der Moment, in dem ein Techniker das Ticket geschlossen hat, nicht der, in dem die Maschine zu degradieren begann. Der Mechanismus steht als Freitext drin: „Lager getauscht“. Ein brauchbarer Labelsatz heißt: Jemand, der diese Maschinen kennt, rekonstruiert Ereignis für Ereignis, was tatsächlich passiert ist und wann. Planen Sie diese Person namentlich ein. Diese Rekonstruktion ist das Projekt — dieselbe unglamouröse Arbeit, die das Vorbereiten von Daten für KI immer bedeutet.
Ihre Sensordaten sind dünner, als Sie denken
Zwei Dinge gehen schief, bevor überhaupt eine Zeile Modellcode entsteht — und beide sind irreversibel.
Abtastrate. Ein Wälzlager meldet sich auf seinen Schadensfrequenzen und deren Harmonischen — von einigen hundert Hertz bis in den Kilohertz-Bereich. Nyquist verlangt, dass Sie über dem Doppelten der höchsten Frequenz abtasten, die Sie sehen wollen; Hüllkurvenanalyse will deutlich mehr Reserve als das. Ihre SPS protokolliert die Antriebstemperatur alle fünf Sekunden als Mittelwert. Die Signatur, die Sie bräuchten, wurde nie abgetastet. Sie können sie nicht nachträglich herausfiltern, nicht interpolieren, und kein Modell holt sie zurück. Wenn die Antwort Schwingungsdaten im Kilohertz-Bereich verlangt, lautet die ehrliche Auskunft „wir montieren Beschleunigungssensoren und sprechen uns in einem Jahr wieder“ — nicht „probieren wir es mal mit dem, was da ist“.
Vorhaltezeit. Alle sagen, sie hätten zehn Jahre Daten. Fast niemand hat sie. Historian- und SCADA-Systeme — AVEVA PI, InfluxDB, was auch immer mit der Linie kam — halten üblicherweise 30 bis 90 Tage in voller Auflösung und verdichten danach auf Stunden- oder Tagesmittel, um Platz zu sparen. Zehn Jahre Stundenmittel sind hier zehn Jahre nichts: Der Transient, den Sie suchen, steckt im Mittelwert und ist weg. Jemand sollte sich im Historian einloggen und die Retention-Policy nachlesen, bevor irgendjemand ein Angebot schreibt. Eine Viertelstundenfrage, die mehr dieser Projekte beendet hat als jedes technische Review — und besser jetzt gestellt als drei Wochen im Piloten.
Ein dritter, leiserer Punkt: Die Daten müssen zusammenführbar sein. Sensorstrom im Historian, Aufträge im SAP, Produktionsplan woanders, alle mit unterschiedlichen Uhren. Von OPC UA an der Maschine zu einer Tabelle zu kommen, in der eine Zeile eine Maschinenstunde ist — mit Last, Produkt und der Information, ob ein Ausfall folgte — das ist der Großteil der Arbeit, und genau der Teil, der in keiner Demo vorkommt.
Was ich nicht bauen würde
Ich würde kein Restlebensdauer-Modell auf weniger als ein paar Dutzend sauberen Beispielen eines Ausfallmechanismus anpassen. Nicht, weil es nicht ginge — es geht, und es sieht auf Ihren Trainingsdaten prächtig aus —, sondern weil Sie eine Zahl ausliefern würden, deren Konfidenzintervall Sie nicht ehrlich berechnen können, und weil jemand danach echte Stillstandszeit einplant.
Ich würde nicht alles instrumentieren. Nehmen Sie die Maschine, bei der eine Stunde Stillstand Geld kostet, das jemand beziffern kann, und bei der der Ausfallmechanismus bekannt und wiederkehrend ist. Wenn Ihnen niemand sagen kann, was eine Stunde auf dieser Linie kostet, haben Sie keinen Business Case, sondern ein Interesse.
Und ich würde ein Modell nicht leichtfertig in den Sicherheitskreis hängen. Ein Wartungshinweis, der Maschinen nach Risiko sortiert, ist im Sinne des EU AI Act unauffällig. Eine KI-Komponente, die eine Maschine selbstständig als Sicherheitsfunktion abschaltet, ist etwas anderes: als Sicherheitsbauteil einer Maschine unter der Maschinenverordnung (EU) 2023/1230 kann sie in der Hochrisiko-Kategorie landen, mit allem, was an Konformitätsbewertung daran hängt. Halten Sie das Modell beratend und die Verriegelung klassisch, dann stellt sich die Frage gar nicht. Das ist keine Rechtsauskunft — es ist eine Entwurfsentscheidung, die Ihnen erspart, eine zu brauchen.
Wo Tippel ins Spiel kommt
Der sinnvolle erste Auftrag ist hier kein Modell. Es ist ein strukturierter Durchgang durch Ihren Historian, Ihr Instandhaltungssystem und eine Stunde mit der Person, die die Maschinen wirklich kennt — mit vier Fragen: Welcher Ausfallmechanismus? Wie viele gelabelte Fälle davon existieren? Was wird in welcher Auflösung vorgehalten? Und was ändert sich, wenn ein Alarm auslöst? Das ist der KI-Readiness-Check, gerichtet auf die Werkshalle — Festpreis, zeitlich begrenzt, am Ende ein Go/No-Go. Manchmal lautet das Urteil „bauen Sie die Vorhersage“. Häufiger lautet es „dieses Jahr Zustandsüberwachung, fangen Sie an, richtig abzutasten, und schauen wir in zwei Jahren wieder auf die Vorhersage, wenn es etwas zu lernen gibt“ — günstiger jetzt zu hören als später zu entdecken.
Meist endet es auch mit einem Entwurf, bei dem die Daten bleiben, wo sie sind. Sensorströme und Instandhaltungsaufträge sind Produktionsdaten; das Modell kann auf einem Rechner in Ihrem eigenen Netz laufen, was intern in der Regel leichter zu vertreten ist, als Maschinentelemetrie in den Cloud-Mandanten eines Dritten zu schicken. Wenn Sie herausfinden möchten, auf welcher Stufe Sie tatsächlich stehen, nehmen Sie Kontakt auf.