Papierbandriss-Vorhersage: Risse erkennen bevor sie passieren

Das echte Ausmaß des Problems

Bandrisse gehören zu den kostspieligsten Ereignissen, die eine Papierfabrik regelmäßig erlebt. Ihre Tücke liegt nicht nur in ihrer unmittelbaren Wirkung, sondern in der Häufung versteckter Folgekosten: Der direkte Stillstand ist bezifferbar. Die Energiekosten für das Wiederanfahren, der Ausschuss in der Wiederhochfahrphase, die Schichtkosten für die Reinigungsmannschaft, und der Verschleiß an Filzen und Sieben durch unnötige Stop-Start-Zyklen, sind es viel seltener.

Laut Dias et al. (2023) in ihrer Springer-Studie zu ML-basierter Bandriss-Vorhersage bei Tissue-Papiermaschinen entsprach allein die Produktionsverlustrate durch Bandrisse bei der untersuchten Anlage bis zu 6.000 Tonnen Papier pro Jahr. Die untersuchte Maschine war nicht außergewöhnlich schlecht, sie lag im Normalbereich für Anlagen ohne prädiktives System. Industrieberichte sprechen für Schreibpapier-Maschinen bei 50 Rissen pro Monat von rund 12 Stunden Stillstand monatlich und 500 Tonnen Produktionsverlust.

Die finanziellen Auswirkungen hängen stark von der Maschinenklasse ab:

• Kleines Format (Spezialitäten, 200–400 t/Tag): 200–500 €/Minute Kapazitätswert. Ein Riss mit 3-Stunden-Stillstand: 36.000–90.000 Euro.
• Mittlere Anlage (Schreib- und Druckpapier, 600–1.000 t/Tag): 500–900 €/Minute. Ein typischer Riss: 90.000–162.000 Euro.
• Großanlage (Verpackung, 1.500–2.500 t/Tag): 1.000–2.000 €/Minute. Ein schwerer Riss mit 6-Stunden-Stillstand: bis zu 720.000 Euro.

Dokumentiert in IBS-PPG-Praxisberichten erzielte eine Papierfabrik durch eine 40-prozentige Reduktion ihrer Bandrisse 820.000 Euro jährliche Mehrproduktion, gleichzusetzen mit 8.200 zusätzlichen Produktionstonnen pro Jahr. Das ist kein theoretischer Wert: Es ist eine dokumentierte Kenngröße aus einer realen Anlage.

Dennoch haben die meisten Papierfabriken heute noch kein Vorhersagesystem. Warum? Weil Bandrisse zu selten sind, um mit klassischer Statistik erfasst zu werden, und zu selten, um schnell genug ML-Trainingsdaten zu sammeln. Das macht diese spezifische Anwendung technisch herausfordernder als die meisten Predictive-Maintenance-Szenarien.

Mit vs. ohne KI, ein ehrlicher Vergleich

¹ Basierend auf Dias et al. (2023) und IBS-PPG-Praxisberichten; tatsächliche Reduktionsrate hängt von Ausgangszustand und Modellqualität ab. ² Risse, die trotz Warnung nicht verhindert werden, entstehen meist durch Operator-Nichtreaktion oder zu kurzen Vorlaufzeiten.

Einschätzung auf einen Blick

Zeitersparnis, sehr hoch (5/5) Jeder verhinderte Bandriss eliminiert 2–6 Stunden Produktionsstillstand vollständig. Das ist die direkteste Zeitersparnis, die ein KI-System im Produktionsumfeld erzeugen kann: nicht wenige Minuten täglich, sondern ganze Schichten am Stück. In der Papierindustrie gibt es keinen anderen KI-Anwendungsfall mit vergleichbarem Zeiteffekt je verhinderten Ereignis. Höchstwert in dieser Kategorie ist gerechtfertigt.

Kosteneinsparung, sehr hoch (5/5) 500–2.000 Euro pro Minute Maschinenstillstand, das ist keine theoretische Größe. Bei einer mittleren Anlage entspricht ein einziger verhinderter Riss dem Monatsbeitrag eines Dutzend Mitarbeitenden. Die IBS-PPG-Praxisberichte zeigen 820.000 Euro Jahreseinsparung durch 40 % weniger Risse. Einzige Einschränkung: Das gilt für Anlagen mit ausreichender Rissfrequenz. Bei Maschinen mit weniger als einem Riss pro Monat relativiert sich die Kostenkalkulation drastisch.

Schnelle Umsetzung, niedrig (2/5) Bis zu einem verlässlichen Modell vergehen realistisch 6–12 Monate, nicht wegen technischer Hürden, sondern wegen der Datenlage: Bandrisse sind seltene Ereignisse, und jedes einzelne muss sorgfältig annotiert werden. Eine Maschine mit vier Rissen pro Monat benötigt mindestens sechs Monate, um genug Beispiele für ein robustes Training zu sammeln. Dazu kommen Sensorintegration, OPC-UA-Anbindung, Edge-Hardware-Beschaffung und Validierungsläufe. Keines dieser Projekte geht in sechs Wochen produktiv.

ROI-Sicherheit, mittel (3/5) Die Wirtschaftlichkeit ist nur dann sicher, wenn die Ausgangssituation passt. Für Anlagen mit drei oder mehr Rissen pro Monat ist der ROI klar positiv, Trainingsdaten reichen aus, die verhinderten Risse übersteigen die Systemkosten schnell. Für Anlagen mit weniger als einem Riss pro Monat funktioniert das Modell nicht zuverlässig: Es fehlen einfach genug positive Trainingsbeispiele. Der ROI kollabiert dann, bevor er sich rechnen kann. Die mittlere Bewertung spiegelt diese Abhängigkeit wider.

Skalierbarkeit, mittel (3/5) Das trainierte Modell kennt genau eine Maschine. Papiermaschinen sind individuell, gleiche Hersteller, gleiche Papiersorte, aber andere Filze, andere Walzenpositionen, andere Wasserchemie. Ein Modell, das an Maschine 1 hervorragend funktioniert, muss an Maschine 2 von Grund auf neu trainiert werden. Wer mehrere Maschinen ausrüstet, kauft sich mehrere parallele Projekte, nicht eine skalierbare Lösung. Transfer-Learning kann helfen, reduziert den Aufwand aber nur um etwa 30–50 % (Schätzwert aus Praxisberichten).

Richtwerte, stark abhängig von Maschinenklasse, Rissfrequenz und vorhandener Sensorinfrastruktur.

Was das System konkret macht

Das System besteht aus drei miteinander verbundenen Schichten: Datenerfassung, Mustererkennung und Alarmierung.

Schicht 1, Datenstrom in Echtzeit Alle relevanten Sensoren entlang der Nasspartie und Trockenpartie liefern ihre Messwerte über OPC-UA an ein lokales Edge-System oder einen Historian. Je nach vorhandener Infrastruktur sind das 20 bis 80 Sensoren: Zugkraftmesszellen zwischen den Pressen, Feuchtemessbalken quer zur Maschinenrichtung, Geschwindigkeitsdifferenzen zwischen Sieb-, Pressen- und Trockenpartie, Flächengewichtsscanner, Papiertemperatur, Dampfdruck in den Zylindern. Die Abtastrate liegt typischerweise bei 1–10 Hertz, schnell genug, um subtile Veränderungen zu erfassen, ohne die Datenmengen ins Unhandliche wachsen zu lassen.

Schicht 2, Das ML-Modell Das Modell lernt aus historischen Daten, wie die Sensorwerte in den Stunden vor einem tatsächlichen Riss aussehen, und wie sie sich von normalem Betrieb unterscheiden. Der technische Ansatz: entweder ein Machine Learning-Zeitreihenmodell wie LSTM (Long Short-Term Memory), das mehrdimensionale Zeitreihen auf Muster hin untersucht, oder Isolation Forest, ein Anomalieerkennungsalgorithmus ohne explizites Riss-Label-Training. In der Praxis werden meist beide Ansätze kombiniert: Isolation Forest für die schnelle Anomalieerkennung, LSTM für die präzise Risikoabschätzung.

Schicht 3, Alarmierung in der Prozesskette Das Modell gibt einen Risikowert aus, eine Zahl zwischen 0 und 1. Überschreitet dieser Wert eine konfigurierbare Schwelle (typischerweise 0,7 oder höher), wird ein Alarm ausgelöst. Dieser Alarm muss den Operator innerhalb von Sekunden erreichen, nicht in einer E-Mail, sondern als Popup auf dem HMI-System, als akustischer Alarm im Maschinengang oder als Nachricht auf dem Schichtführer-Tablet. Wie dieser Alarm in die bestehende Leittechnik integriert wird, ist oft die kritischere Herausforderung als das Modell selbst.

Welche Sensorsignale wirklich warnen

Nicht alle Sensoren sind gleich nützlich für die Bandriss-Vorhersage. Die Forschungsliteratur und Betreibererfahrungen zeigen ein konsistentes Bild, welche Signale tatsächlich Vorlaufzeit liefern, und welche erst dann ausschlagen, wenn der Riss bereits unvermeidlich ist.

Zugkraftmessung (Bahnspannung), der zuverlässigste Vorläufer. Bandrisse entstehen, wenn die lokale Papierqualität die anliegende Spannung nicht mehr trägt. Zugkraftmesszellen zwischen den Pressen erfassen diese Spannung in Echtzeit. Ein typisches Rissmuster: Die Zugkraft steigt über mehrere Minuten leicht an, fluktuiert dann stärker als üblich (erhöhte Varianz), bevor sie abrupt kollabiert. Das Modell erkennt dieses Muster oft 5–8 Minuten vor dem Riss.

Feuchteverteilung quer zur Maschinenrichtung, der kritische Begleiter. Lokale Feuchteabfälle an einem Rand oder in der Mitte sind ein starker Prädiktor. Wenn eine Seite der Bahn deutlich trockener wird als die andere, entsteht laterale Spannung, ein physikalischer Vorläufer von Randabrissen. Feuchtemessbalken mit 40–100 Messpunkten quer zur Maschinenbreite sind hier die entscheidende Datenquelle.

Geschwindigkeitsdifferenz zwischen Partien, sensitiv für Formatfehler. Wenn die Trockenpartie schneller läuft als die Nasspartie oder umgekehrt, baut sich Längsspannung auf. Kleine Differenzen von 0,1–0,3 % sind normal, systematische Abweichungen über mehrere Minuten sind ein Warnsignal. Diese Signale sind besonders bei Formatwechseln und Geschwindigkeitsanpassungen relevant.

Flächengewichtsscanner, Qualitätsindikator mit Vorlaufcharakter. Lokale Flächengewichtsabweichungen zeigen dünnere Querschnitte an, die mechanisch schwächer sind. Ein Flächengewichtsabfall von mehr als 3–5 % gegenüber dem Sollwert an einer bestimmten Stelle korreliert mit erhöhtem Rissrisiko an genau dieser Position.

Was weniger hilfreich ist: Dampfdruck und Zylindertemperaturen reagieren meist zu träge und zu indirekt, um als primäre Prädiktoren zu dienen. Sie sind gute ergänzende Features, aber kein verlässlicher Vorlaufsignal für Bandrisse.

Das Problem mit dem seltenen Ereignis

Bandriss-Vorhersage ist kein Standard-Predictive-Maintenance-Problem, es ist ein Seltene-Ereignis-Problem, und diese Kategorie ist in der Praxis erheblich schwieriger als sie zunächst wirkt.

In einem normalen Betrieb läuft eine Papiermaschine vielleicht 720 Stunden pro Monat. Bei vier Rissen im Monat gibt es also vier Ereignisse unter 720 Betriebsstunden. Das entspricht einem Verhältnis von etwa 1 Riss-Stunde zu 180 Normal-Stunden. Bei einem Datenabtast-Intervall von einer Sekunde entstehen auf der Zeitachse: etwa 14.400 “Riss-nahe” Datenpunkte, gegenüber etwa 2,6 Millionen “Normal”-Datenpunkten.

Dieses extreme Ungleichgewicht, fachlich als Klassenimbalance bezeichnet, verleitet ein unbehandeltes ML-Modell dazu, einfach immer “Normal” vorherzusagen. Das klingt ironisch, ist aber statistisch rational: Wer immer “Normal” sagt, liegt 99,4 % der Zeit richtig. Ein Modell mit 99,4 % Accuracy, das nie einen Riss vorhersagt, ist wertlos.

Die gängigen Gegenmaßnahmen sind bekannt, aber mit Nebenwirkungen verbunden:

• SMOTE (Synthetic Minority Oversampling): Erzeugt synthetische Riss-nahe Datenpunkte durch Interpolation. Funktioniert gut als Ergänzung, sollte aber nie die einzige Maßnahme sein, synthetische Rissmuster unterscheiden sich von echten.
• Kostensensitives Training: Das Modell bestraft falsch klassifizierte Risse stärker als falsch klassifizierte Normal-Phasen. Verschiebt den Schwellwert zugunsten von Sensitivität, erhöht aber gleichzeitig die Falschalarme.
• Sliding-Window-Labeling: Die Datenpunkte in einem definierten Zeitfenster vor dem Riss (z.B. 10 Minuten) werden alle als “Risikozone” gelabelt. Das erhöht die Anzahl positiver Trainingsbeispiele erheblich, führt aber dazu, dass auch Phasen ins Label kommen, die sich eigentlich erholt hätten.

Die Konsequenz für die Praxis: Ein Bandriss-Vorhersagemodell ohne ausreichend Trainingsdaten ist schlimmer als kein Modell, es erzeugt Falschalarme, die das Bedienteam abstumpfen lassen (Alarmmüdigkeit), und verhinderte Risse werden überbewertet, weil echte Nicht-Risse mit in die Vorhersagestatistik einfließen.

Die Mindestdatengrundlage, die erfahrungsgemäß robuste Modelle ermöglicht: etwa 50–80 annotierte Riss-Ereignisse pro Maschine, die unter verschiedenen Betriebsbedingungen aufgetreten sind. Bei vier Rissen pro Monat bedeutet das 12–20 Monate Datensammlung. Bei einem Riss pro Monat: 4–7 Jahre.

Edge vs. Cloud, warum die Entscheidung über Warnung oder Schweigen entscheidet

Die Architekturentscheidung zwischen Edge-Deployment und Cloud-Anbindung ist bei der Bandriss-Vorhersage keine akademische Frage, sie ist produktionskritisch.

Das Zeitfenster ist knapp. Das Modell hat 3–8 Minuten zwischen Alarm und Riss. Selbst im besten Fall. Wenn die Sensordaten erst in die Cloud hochgeladen, dort ausgewertet und der Alarm zurückübermittelt werden muss, verliert man bei normalen Latenzen (50–200 ms pro Roundtrip, plus Netzwerklatenz und Cloud-Verarbeitungszeit) keine dramatischen Millisekunden, aber Netzwerkinstabilitäten in Produktionsumgebungen können Verbindungsunterbrechungen von Sekunden bis Minuten verursachen. In einem 5-Minuten-Fenster sind drei Minuten Verbindungsausfall 60 % des verfügbaren Reaktionszeitraums.

Edge-Deployment löst das Problem. Ein Edge-Computer direkt an der Papiermaschine, typischerweise ein industrieller IPC oder ein Siemens Industrial Edge-Gerät, empfängt die Sensordaten lokal, führt das Modell lokal aus und gibt den Alarm direkt an die Maschinensteuerung. Latenzen von unter 50 Millisekunden sind realistisch. Netzwerkunterbrechungen zum Rechenzentrum haben keine Auswirkung auf die Echtzeitfunktion.

Hybride Architektur für die Praxis:

• Edge: Echtzeit-Scoring, Alarm-Ausgabe, lokale Datenpufferung
• Cloud / AVEVA PI System / Siemens Insights Hub: Modell-Training auf historischen Daten, Modell-Update-Deployment auf Edge, Langzeit-Archivierung für Retraining, maschinenübergreifende Analysen

Der Modellwechsel, wenn ein neu trainiertes Modell das alte auf dem Edge-Gerät ersetzt, kann über das zentrale Geräteverwaltungssystem ausgerollt werden, ohne Produktionsunterbrechung.

Die Integration in das DCS/MES ist die eigentliche Hürde. Das Modell mag technisch fertig sein. Aber wenn der Alarm als HMI-Popup auf dem Operatorbildschirm erscheinen soll, braucht man eine OPC-UA-Schreibverbindung in die Leittechnik. Die meisten DCS-Systeme in Papierfabriken (Honeywell Experion, ABB 800xA, Siemens PCS7 oder neuere) unterstützen OPC-UA als Schnittstelle, aber die Konfiguration dieser Verbindung erfordert Leittechnik-Kenntnisse und in der Regel die Einbeziehung des DCS-Herstellers oder eines zertifizierten Systemintegrators.

Konkrete Werkzeuge, was wann passt

Die richtige Toolkette hängt von der vorhandenen Infrastruktur ab. Es gibt keinen universellen Stack, wohl aber gut bewährte Kombinationen.

AVEVA PI System, wenn ein Historian bereits vorhanden ist In den meisten größeren Papierfabriken ist ein AVEVA PI System (früher OSIsoft) bereits im Einsatz, oft als Historian für Prozessdaten. PI System speichert Zeitreihendaten mit sehr hoher Effizienz und hat OPC-UA-Interfaces für alle gängigen DCS. Das ML-Modell kann auf PI-Daten trainiert werden; der historische Datensatz für Riss-Ereignisse ist oft bereits vorhanden, nur nicht ausgewertet. Einschränkung: PI ist kein ML-Training-Tool. Die Analyse-Schicht muss separat gebaut werden (Python, Azure ML oder ähnliches).

Siemens Industrial Edge, für das Edge-Deployment Bei Siemens-Steuerungen (S7, PCS7) ist Industrial Edge die naheliegendste Edge-Plattform. Der “AI Inference Server” als App erlaubt das Ausführen von ONNX-Modellen direkt auf dem Edge-Gerät. Modelle werden in Python entwickelt, als ONNX exportiert und über das Industrial Edge Management auf die Maschine ausgerollt. Einstiegskosten ab 2.000–3.000 Euro für die Hardware, zuzüglich Lizenzkosten.

Azure Machine Learning, für das Modell-Training Training und Validierung des Vorhersagemodells auf historischen Daten. Azure ML bietet Python-Notebooks, automatisches Hyperparameter-Tuning und Modell-Registry, wichtig für die Versionierung der Modelle, die auf Edge-Geräte ausgerollt werden. Kosten: typischerweise 100–500 Euro/Monat für Trainingsläufe.

InfluxDB + Grafana, für schlanke On-Premises-Setups Für Fabriken ohne existierende IIoT-Plattform: InfluxDB als lokaler Zeitreihen-Historian, Grafana als Visualisierungs- und Alarm-Frontend. Beides Open Source, betreibbar auf einem einfachen Server in der Fabrik. Grafana kann direkt OPC-UA-Quellen einbinden (über Plugin) und Alerts als HMI-ähnliche Popups ausgeben. Vorteil: keine Cloud-Abhängigkeit, keine Lizenzkosten, volle Datensouveränität. Nachteil: kein fertiges ML-Framework, das Modell muss als Python-Skript neben InfluxDB betrieben werden.

Siemens Insights Hub, für Mehrmaschinen-Setups Wenn mehrere Papiermaschinen im Werk oder an mehreren Standorten ausgerüstet werden sollen, bietet Insights Hub die werksübergreifende Datenzusammenführung und Analytics-Plattform. Jede Maschine hat ihr eigenes Modell, aber die Training-Pipelines und Dateninfrastruktur werden zentral verwaltet. Sinnvoll ab drei oder mehr Maschinen.

Zusammenfassung: Wann welcher Ansatz

• PI System bereits vorhanden → Datengrundlage nutzen, ML separat aufbauen
• Siemens-Steuerung → Industrial Edge + AI Inference Server
• Kein Budget für Plattformlizenzen, Siemens-unabhängig → InfluxDB + Grafana + Python
• Mehrere Maschinen, Enterprise-Budget → Insights Hub als Zentrale

Datenschutz und Datenhaltung

Die Sensorströme einer Papiermaschine enthalten in der Regel keine personenbezogenen Daten im DSGVO-Sinne, Temperatur, Feuchte, Zugkraft und Geschwindigkeit sind Maschinendaten, keine Personendaten. Die DSGVO-Relevanz entsteht erst dann, wenn Schichtpläne, Bedienerkennnummern oder Betriebstagebücher mit den Sensordaten verknüpft werden.

Was jedoch immer zu beachten ist: Produktionsdaten als Betriebsgeheimnis. Die Sensor-Rohdaten einer Papiermaschine beschreiben den Prozess in einer Detailtiefe, die Rückschlüsse auf Rezepturen, Qualitätsparameter und Produktionsgeheimnisse zulässt. Für viele Papierfabriken ist es deshalb nicht DSGVO, sondern Wettbewerbsrecht, das die Anforderung an On-Premises-Datenhaltung treibt.

Empfehlungen für die Datenhaltung:

• Training auf historischen Daten: Kann in der Cloud (z.B. Azure Machine Learning mit EU-Hosting) durchgeführt werden, wenn die Daten dort pseudonymisiert werden (keine Werks-IDs, keine Maschinen-Seriennummern in den Rohdaten)
• Echtzeit-Inferenz (Edge): Auf jeden Fall On-Premises, Sensor-Rohdaten verlassen die Anlage nicht
• Historian-Archiv: AVEVA PI System oder InfluxDB On-Premises für maximale Datensouveränität
• Cloud-Anbieter: Falls Cloud-Komponenten genutzt werden: AVV (Auftragsverarbeitungsvertrag nach Art. 28 DSGVO) vor Produktivbetrieb abschließen. Azure Machine Learning und Siemens Insights Hub bieten AVVs an.

Was es kostet, realistisch gerechnet

Die Kostenkalkulation hängt maßgeblich davon ab, welche Infrastruktur bereits vorhanden ist.

Szenario A, PI System + Edge-Neuprojekt (typisch für mittlere Fabrik)

• Edge-Hardware (Siemens IPC oder vergleichbar): 3.000–8.000 Euro
• OPC-UA-Anbindung und DCS-Integration (Systemintegrator, 5–15 Tage): 10.000–25.000 Euro
• Datenaufbereitung und Modellentwicklung (6–9 Monate, internes Data-Science-Team oder externer Partner): 30.000–70.000 Euro
• Laufende Kosten (Azure ML für Retraining, Edge-Lizenz, Wartung): 1.000–3.000 Euro/Monat

Gesamtinvestition Szenario A: 45.000–105.000 Euro Einmalinvestition + laufende Kosten

Szenario B, InfluxDB + Open-Source-Stack (für schlanke On-Premises-Lösung)

• Server-Hardware (industrieller Server): 2.000–4.000 Euro
• InfluxDB + Grafana: Open Source, keine Lizenzkosten
• Entwicklungsaufwand (Python-Modell, OPC-UA-Integration): 20.000–50.000 Euro (extern) oder 4–6 Monate intern
• Laufende Kosten: minimal (eigene Infrastruktur), nur Betriebsaufwand

Gesamtinvestition Szenario B: 25.000–55.000 Euro

Die ROI-Rechnung, konservativ Ausgangssituation: Mittlere Maschine, 600 €/Minute Kapazitätswert, vier Risse pro Monat, durchschnittlich 3 Stunden Stillstand je Riss.

Monatliche Rissverluste bisher: 4 × 180 Minuten × 600 €/Minute = 432.000 Euro/Monat.

Bei 40 % Reduktion durch das Modell: 1,6 Risse verhindert pro Monat = 172.800 Euro gespart.

Amortisationszeit für Szenario A: 45.000–105.000 Euro ÷ 172.800 €/Monat = 0,3–0,6 Monate nach Produktivbetrieb.

Das klingt fast zu gut, und im optimistischen Szenario ist es das auch. Realistisch ist: Das Modell braucht 6–12 Monate zum Reifen, in dieser Zeit sind die Präzision und Recall noch nicht optimal. Und vier Risse pro Monat ist eine relativ hohe Rate, viele Maschinen liegen darunter. Aber selbst bei einer Rissrate von einem Riss pro Monat und 40 % Reduktion: 0,4 verhinderte Risse × 108.000 Euro = 43.200 Euro/Monat gespart. Der ROI ist auch dann unter einem Jahr.

Wann die Rechnung nicht aufgeht: Unter einem Riss pro Monat werden zwei Probleme gleichzeitig akut: Das Modell hat zu wenig Trainingsdaten und die verhinderten Risse sparen zu wenig ein, um Projektkosten und laufende Kosten zu decken.

Vier typische Einstiegsfehler

1. Mit zu wenig Riss-Historie starten. Der Reflex: “Wir haben die Sensordaten der letzten zwei Jahre, das reicht bestimmt.” Das Erste, was dann beim Datensichten passiert: Die Risse sind nicht annotiert. Niemand hat für jedes Ereignis sauber vermerkt, wann genau der Riss war, an welcher Stelle und unter welchen Umständen. Das macht die vorhandenen Rohdaten für Training unbrauchbar, bis sie aufwendig rückwirkend gelabelt werden, oft Monate manueller Arbeit durch jemanden, der die Maschinenlogs kennt.

Lösung: Bevor ML-Entwicklung beginnt, ein sauberes Riss-Ereignisprotokoll aufbauen. Datum, Uhrzeit, Position (Nasspartie / Pressenpartie / Trockenpartie), Papiersorte, Maschinendrehzahl zum Zeitpunkt des Risses. Dieses Protokoll ist die Voraussetzung für jedes Modell.

2. Den Alarm zu hoch oder zu niedrig kalibrieren. Zu empfindlich kalibriert, Alarmgrenzwert 0,5 statt 0,7, und das System löst mehrfach pro Schicht aus. Nach zwei Wochen ignoriert das Bedienteam die Alarme (“Das ist wieder einer dieser Fehlalarme”). Das ist die Alarmmüdigkeit, und sie ist der häufigste Grund, warum gut funktionierende Modelle trotzdem keinen Nutzen bringen. Zu unempfindlich kalibriert, und das System übersieht echte Risse.

Die richtige Kalibrierung ergibt sich aus dem konkreten Betrieb, nicht aus einer theoretischen Optimierung des F1-Score. Ein Startpunkt: 0,75 als Schwellwert, mit wöchentlicher Überprüfung in den ersten drei Monaten. Wer drei Wochen lang keinen Fehlalarm hatte, kann den Schwellwert senken. Wer täglich Fehlalarme sieht, muss ihn erhöhen oder das Modell nachbessern.

3. Die Integration in die Leittechnik unterschätzen. Das ML-Modell ist fertig, es gibt einen Risikowert aus. Aber wie kommt dieser Wert auf den Operatorbildschirm? In vielen Projekten wird das als “technisches Detail” am Ende geplant. In der Realität ist es die aufwendigste Phase: OPC-UA-Schreibrechte in den DCS beantragen (braucht Hersteller-Support und Sicherheitsfreigabe), HMI-Bildschirm konfigurieren, Alarmmanagement in das bestehende Alarmsystem integrieren, Schnittstelle zum Schichtprotokoll aufbauen. Plant mindestens zwei Monate für diese Phase ein, realistisch eher drei.

4. Das Modell einmalig trainieren und sich darauf verlassen. Das ist der Fehler, der still passiert. Ein Modell, das auf Daten von 2024 trainiert wurde, kann im Frühjahr 2026 schlechter sein, weil ein neuer Lieferant andere Faserchargen liefert, weil ein Filzaustausch die Pressencharakteristik verändert hat, oder weil die Fahrstrategie für ein neues Papierprodukt andere Betriebspunkte erzeugt. Das Modell kennt diese Veränderungen nicht.

Etabliert deshalb von Anfang an einen Retraining-Rhythmus: Neues Riss-Ereignis → annotieren → in Trainingsdatensatz aufnehmen → Modell vierteljährlich neu trainieren und mit dem alten vergleichen. Wer keinen Prozessverantwortlichen für das Modell benennt, eine Person, die das Retraining veranlasst und die Modellperformance überwacht, hat nach 18 Monaten ein veraltetes System, das mit Zuversicht auf veränderte Betriebsbedingungen reagiert.

Was mit der Einführung wirklich passiert, und was nicht

Die technische Inbetriebnahme ist in der Regel das Geradlinigste an diesem Projekt. Die menschlichen Herausforderungen sind subtiler.

Das Kontrollparadox bei Maschinenführern. Erfahrene Maschinenführer wie Tobias Gruber haben über Jahre ein feines Gespür für ihre Maschine entwickelt. Ein System, das jetzt Risiken berechnet und Alarme auslöst, bevor sie selbst etwas wahrnehmen, kann sich bedrohlich anfühlen, nicht weil sie das System ablehnen, sondern weil es implizit aussagt: “Die Maschine kommuniziert mit dem Computer besser als mit dir.” Diese Erfahrung ist real und sollte ernst genommen werden.

Was hilft: Maschinenführer nicht als Empfänger des Systems positionieren, sondern als dessen Experten. In der Kalibrierungsphase sind ihre Einschätzungen der entscheidende Maßstab: Stimmt der Alarm mit dem, was sie gespürt hätten? War es ein echter Riss-Vorläufer oder Maschinenlärm? Ihr Urteil formt das Modell, und wer das System mitgebaut hat, verteidigt es.

Das Schichthandover-Problem. Das System alarmiert um 3:17 Uhr. Der Maschinenführer reagiert, senkt die Geschwindigkeit, der Alarm erlischt. Um 6:00 Uhr Schichtwechsel, der Folgeführer weiß von der Episode nichts, wählt die Geschwindigkeit wieder hoch. Das Schichtprotokoll-System muss so gestaltet sein, dass Alarm-Ereignisse und Maschinenreaktionen sauber dokumentiert und an den Nachfolger übergeben werden. Das ist kein technisches Feature, das ist ein Prozess, der vor dem Go-Live festgelegt werden muss.

Die 90-Tage-Frustrationskurve. In den ersten drei Monaten wird das Modell Fehlalarme produzieren. Das gehört dazu, das ist die Phase, in der es aus dem realen Betrieb lernt. Wenn das Team nicht darauf vorbereitet ist, verliert es nach dem dritten oder vierten Fehlalarm das Vertrauen. Kommuniziert explizit: “Das System wird in den ersten drei Monaten noch nicht perfekt sein. Jeder Fehlalarm hilft, es besser zu machen.”

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

“Unsere Maschinendaten sind proprietär, die können wir nicht in die Cloud geben.” Das ist kein Einwand gegen das Projekt, sondern ein Argument für eine bestimmte Architektur. Wie im Abschnitt zur Edge-Deployment-Entscheidung beschrieben: Das Echtzeit-Scoring läuft auf lokaler Edge-Hardware an der Maschine. Nur die Modell-Training-Pipeline berührt optional Cloud-Infrastruktur, und auch das kann On-Premises auf eigenen Servern erfolgen. Das Datenschutz-Argument ist legitim; es schränkt die Architekturoptionen ein, macht das Projekt aber nicht unmöglich.

“Wir haben das schon versucht, das hat nie zuverlässig funktioniert.” Das ist der häufigste und ernsteste Einwand, und er ist meist berechtigt. Frühere Versuche mit Regelwerk-basierter Alarmsysteme (“wenn Zugkraft über X, Alarm auslösen”) scheitern systematisch, weil die Grenzwerte nicht kontextabhängig sind: Was bei hoher Geschwindigkeit kritisch ist, ist bei niedriger normal. Ein ML-Modell, das Kontext mitberücksichtigt, ist strukturell anders. Aber: Wenn der frühere Versuch daran scheiterte, dass nicht genug Trainingsdaten annotiert waren, dann hilft auch ein besseres Modell zunächst nicht. Erst die Datengrundlage prüfen.

“Das System sagt uns, wann wir bremsen müssen. Aber Bremsen kostet auch Produktion.” Das ist der relevanteste wirtschaftliche Einwand. Wenn das Modell einen Alarm auslöst und der Maschinenführer die Geschwindigkeit um 5 % senkt, kostet das Produktion, auch wenn der Riss nicht passiert wäre. Die Kalibrierungsarbeit ist deshalb entscheidend: Ein Alarm sollte nur dann ausgelöst werden, wenn die Risswahrscheinlichkeit das Produktionsverlustrisiko durch Abbremsen überwiegt. Ein gut kalibriertes Modell empfiehlt “Geschwindigkeit senken”, nicht “sofort stoppen”, das macht den Eingriff deutlich weniger teuer als einen tatsächlichen Riss.

Woran du merkst, dass das zu dir passt

Signale, dass die Zeit reif ist:

• Eure Maschine hat im Schnitt drei oder mehr Bandrisse pro Monat
• Ihr habt OPC-UA-Datenzugriff oder einen AVEVA-PI-Historian mit historischen Sensordaten aus mindestens 12 Monaten
• Es gibt einen Maschinenführer oder Prozessverantwortlichen, der die Riss-Ereignisse rückwirkend für die letzten zwei Jahre annotieren kann
• Euer IT/OT-Team oder ein Systemintegrator ist in der Lage, die DCS-Anbindung für den Alarm-Output zu übernehmen
• Die Maschine läuft im Mehrschichtbetrieb, Nachtschicht-Risiken sind besonders relevant, weil weniger Senior-Personal verfügbar ist

Drei harte Ausschlusskriterien, wer das noch nicht angehen sollte:

1. Unter 2 Rissen pro Monat im Jahresschnitt (Mindestdaten): Das rare-event-ML-Problem ist dann nicht lösbar. Selbst mit SMOTE und kostensensitivem Training fehlen schlicht genug echte positive Trainingsbeispiele für ein verlässliches Modell. Wer trotzdem investiert, bekommt ein System, das entweder zu viele Fehlalarme produziert oder echte Risse übersieht, in beiden Fällen ohne Return.

2. Keine digital zugänglichen Sensordaten (keine OPC-UA, kein DCS-Datenexport): Wenn Sensordaten nur auf analogen Anzeigestreifen oder in proprietären Steuerungsloggern ohne externen Zugriff vorliegen, ist der erste und teuerste Schritt die Sensornachrüstung. Das ist ein eigenständiges Infrastrukturprojekt, das das ML-Projekt um 12–24 Monate und erhebliche Kosten vorausgeht. Erst Infrastruktur aufbauen, dann ML-Vorhersage.

3. Kein dauerhafter Prozessverantwortlicher für Modell-Pflege: Wer das Modell einmalig einführt und dann sich selbst überlässt, hat nach 18 Monaten ein System, das auf neue Betriebsbedingungen (Filzwechsel, neue Fasercharge, Geschwindigkeitserhöhung) nicht kalibriert ist. Stale-Modelle erzeugen Fehlalarme oder übersehen echte Risiken. Ohne namentlich benannte Person mit Zeitkontingent für Retraining und Kalibrierung ist das Ergebnis mittelfristig ein Vertrauensverlust beim Bedienteam, und ein abgeschaltetes System.

Das kannst du heute noch tun

Der einfachste erste Schritt kostet nichts und dauert eine Stunde: Setzt euch zusammen und bewertet eure Ausgangsdatensituation. Beantwortet diese vier Fragen:

1. Wie viele dokumentierte Bandrisse hatten wir im letzten Jahr, und sind Datum und Uhrzeit der Ereignisse maschinenlesbar verfügbar?
2. Welche Sensordaten werden von unserer Maschinensteuerung aufgezeichnet, und wie lange wird der Verlauf archiviert?
3. Haben wir OPC-UA-Datenzugriff, und wer im Haus kennt die Schnittstellen der DCS?
4. Wer könnte als interner Projektverantwortlicher die Riss-Annotation und Modellpflege langfristig übernehmen?

Wenn ihr auf alle vier Fragen konkrete Antworten habt, auch wenn einige unbequem sind, seid ihr bereit für ein erstes technisches Assessment. Wenn zwei oder mehr Fragen mit “wissen wir nicht” beantwortet werden, ist die Datengrundlage-Arbeit der sinnvollere erste Schritt als die KI-Entwicklung.

Für das technische Assessment könnt ihr einen Systemintegrator oder ein Data-Science-Team anfragen. Gebt ihnen dabei so viel Kontext wie möglich. Hier ist ein Prompt, der euch hilft, die Ausgangssituation strukturiert zu beschreiben:

Quellen & Methodik

• Dias et al. (2023), “The Break Point: A Machine Learning Approach to Web Breaks in Paper Mills”: Springer Nature, in: Lecture Notes in Networks and Systems, Band 541 (2023). Tissue-Papiermaschine als Fallstudie. ML-Ansatz zur Riss-Klassifikation mit 86 % Accuracy. Dokumentierter Produktionsverlust: bis zu 6.000 Tonnen Papier/Jahr und 100.000 Liter Wasser/Tag an der untersuchten Anlage. URL: https://link.springer.com/chapter/10.1007/978-3-031-20788-4_5
• IBS-PPG Praxisberichte (ibs-ppg.com), “Reduce web breaks and broke on paper machines”: Dokumentierte Fallstudie mit 820.000 €/Jahr Einsparung durch 40 % Reduktion der Bandrisse (8.200 Tonnen Mehrproduktion/Jahr). URL: https://www.ibs-ppg.com/en/save-resources/reduce-web-breaks-and-broke
• Riss-Häufigkeit und Produktionsverlust: “Minimize Sheet Breaks in Paper Machine using Data Analytics”, IPPTA Technical Paper 2024 (ippta.co). Angabe: 50 Risse/Monat → 12 Stunden Stillstand + 500 Tonnen Produktionsverlust bei einer 800-TPD-Maschine.
• Seltene-Ereignis-ML: “A Comprehensive Survey on Rare Event Prediction”, ACM Computing Surveys (2024). Überblick über Klassenimbalanz-Probleme in der Industrie und gängige Gegenmaßnahmen. URL: https://dl.acm.org/doi/10.1145/3699955
• Alarmmüdigkeit und False Positives: “Sensor-Based Predictive Maintenance with Reduction of False Alarms, A Case Study in Heavy Industry”, MDPI Sensors (2022). Methode reduzierte Fehlalarme um 90,25 %. URL: https://www.mdpi.com/1424-8220/22/1/226
• Sensor-Signale für Bandriss-Vorhersage: Ahola, Timo: “Intelligent estimation of web break sensitivity in paper machines”, PhD-Dissertation, Universität Oulu (2003). Frühe Arbeit zur neuronalen Netz-basierten Vorhersage. Semanticscholar: https://www.semanticscholar.org/paper/Intelligent-estimation-of-web-break-sensitivity-in-Ahola/e64268781770d24bd2ce5ed9ae06c751e5367c29
• Edge vs. Cloud-Latenz: “Lightweight Signal Processing and Edge AI for Real-Time Anomaly Detection in IoT Sensor Networks”, MDPI Sensors (2025). Latenzwerte und Energie-Effizienz-Vergleiche Edge vs. Cloud. URL: https://www.mdpi.com/1424-8220/25/21/6629
• Tool-Preise und Spezifikationen: Veröffentlichte Angaben der jeweiligen Anbieter (AVEVA, Siemens, InfluxData, Grafana Labs, Microsoft Azure), Stand April 2026.

Du willst wissen, ob eure Datenlage für eine Bandriss-Vorhersage ausreicht, und welcher Projektansatz in eurem konkreten Setup realistisch ist? Meld dich, das klären wir gemeinsam in einem kurzen Gespräch.