Runnability-Prognose: Formatwechsel mit minimalen Anfahrtrissen

Das echte Ausmaß des Problems

Formatwechsel sind eine der konzentriertesten Risikophasen in der Papierproduktion. In den ersten zwei bis fünf Minuten nach einem Wechsel — wenn Zugkraft, Feuchteprofile und Maschinengeschwindigkeit neu einpendeln — liegt die Risswahrscheinlichkeit um ein Vielfaches über dem Normalbetrieb.

Was ein einzelner Anfahrriss kostet, ist gut dokumentiert: Laut einer Vernaio-Fallstudie, die auf Voith-Produktionsdaten basiert, liegt der Richtwert bei rund 1.500 Euro pro Bandriss — gerechnet aus Stillstandszeit, Ausschusskosten und Neuanfahraufwand. Bei drei Rissen täglich an 250 Betriebstagen im Jahr entspricht das einem Jahreskostenrisiko von über einer Million Euro pro Maschine. Eine separate Praxisstudie an einem mittelgroßen Werk mit 850 Tonnen Tageskapazität beziffert die jährlich wiederbeschaffbaren Produktionsverluste durch Bandrisse auf 3,4 Millionen Dollar — und erreichte nach 14 Monaten eine 72-prozentige Reduktion.

Dabei ist der finanzielle Schaden nur die sichtbare Hälfte. Die unsichtbare Hälfte ist der Wissensverlust. In der Papierindustrie stehen viele Werke vor demselben demografischen Problem: Die Generation, die ihre Maschinen durch jahrzehntelange Schichtarbeit so gut kennt wie die eigene Handschrift, geht in den nächsten zehn Jahren in Rente. Was sie mitnimmt, ist kein Dokumentationsversagen — es ist strukturell implizites Wissen, das sich in Echtzeit-Parameterkombinationen, situativen Anpassungen und Mustererkennung zeigt, nicht in Handbüchern.

Für Formatwechsel ist das besonders folgenreich:

• Jeder Formatwechsel ist ein anderes Experiment. Breite, Grammatur, Fasersorte, Retentionsmittelkonzentration, Tageszeit, Temperatur der Presspartie — alles beeinflusst, wie die Maschine auf den Übergang reagiert.
• Die Freiheitsgrade sind hoch. Theoretisch gibt es Tausende möglicher Parameterkombinationen beim Anfahren nach einem Wechsel — erfahrene Operatoren reduzieren diesen Raum intuitiv auf das handhabbare Fenster.
• Das DCS hilft dabei wenig. Leitsysteme zeichnen auf, was passiert ist — aber sie sagen nicht, welche Parametereinstellung beim nächsten Übergang von 80 auf 60 g/m² bei der aktuellen Fasercharge am sichersten ist.

Mit vs. ohne KI — ein ehrlicher Vergleich

Die Reduktionszahlen stammen aus Vernaio/Voith (55% Durchschnitt, bis zu 87%) und einer Oxmaint-Praxisstudie (72% über 14 Monate). Eigene Ergebnisse hängen stark von Maschine, Datenbasis und Formatspektrum ab.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5)
Jeder verhinderte Anfahrriss spart 15–30 Minuten Stillstand plus die Zeit für Reinigung, Neueinzug und das Wiederanfahren auf Betriebsgeschwindigkeit. Bei vier bis sechs Formatwechseln täglich und einem typischen Rissvorkommen von ein bis zwei Ereignissen pro Woche ist der Effekt greifbar — nicht so dramatisch wie ein verhindeter Nasspartieriss (der 2–6 Stunden kostet), aber konsistent und häufig. Die 4 ist gerechtfertigt: knapp unter der Papierbandriss-Vorhersage, die bei den schwereren Rissen ansetzt.

Kosteneinsparung — mittel (3/5)
Der Richtwert von 1.500 Euro pro verhindertem Bandriss ist real, aber das Szenario ist spezifischer als bei anderen Anwendungsfällen in dieser Branche: Es geht um Anfahrtrisse nach Formatwechseln — einer von mehreren Risstypen. Wer hauptsächlich Risse in der Nasspartie oder durch Filzverunreinigung hat, profitiert hier weniger. Die 3 spiegelt: realer Hebel, aber enger Wirkungsbereich im Vergleich zu Dampfoptimierung oder Bleichmittelreduktion.

Schnelle Umsetzung — mittel (3/5)
Das klingt zunächst besser als die generelle Papierbandriss-Vorhersage (die auf 2 kommt), weil Formatwechsel geplante Ereignisse sind — keine Zufallsausfälle. Die historischen Daten sind strukturierter, die Ereignislabels einfacher zu setzen. Aber: Man braucht mindestens 12 Monate Historian-Daten mit ausreichend vielen Formatwechselereignissen und eine Datenbasis, in der Formatwechselzeitpunkte auch tatsächlich im DCS markiert sind. Wer das hat, kommt in 8–12 Wochen zum Pilotmodell. Wer es nicht hat, braucht zuerst Monate Dateninfrastruktur.

ROI-Sicherheit — mittel (3/5)
Anfahrtrisse lassen sich zählen und die Reduktion ist messbar. Aber die Attribution bleibt schwierig: Hat das System geholfen, oder hat die neue Fasercharge einfach besser gepasst? Die Kausalität zwischen Modellempfehlung und ausgebliebenen Rissen braucht konsequentes Logging — wer hat die Empfehlung befolgt, wer nicht, und was war das Ergebnis? Ohne dieses Tracking bleibt der ROI-Nachweis weich.

Skalierbarkeit — mittel (3/5)
Das Modell ist maschinenspezifisch. Transferlernansätze für gleiche Maschinentypen sind im Forschungsstadium erprobt, in der Industrie aber noch kein Standard. Wer drei identische Maschinen im Werk hat, kann das Modell als Startpunkt nutzen — aber es braucht maschinenindividuelle Kalibrierung. Identisch mit dem Skalierbarkeits-Score der Papierbandriss-Vorhersage — beide Anwendungsfälle teilen diese strukturelle Begrenzung.

Richtwerte — stark abhängig von Formatspektrum, Maschinenausstattung und Datenverfügbarkeit.

Was das System konkret macht

Der technische Kern ist ein Machine Learning-Klassifikationsmodell, das auf historischen Anfahrdaten trainiert wird. Das Modell lernt, welche Parameterkombinationen beim Anfahren nach einem Formatwechsel mit rissfreiem Betrieb korrelieren — und welche mit erhöhter Risswahrscheinlichkeit.

Konkret sieht das so aus:

Trainingsdaten: Das DCS-Historian-System enthält für jeden Formatwechsel der vergangenen 12–24 Monate die vollständigen Parameterspuren: Maschinengeschwindigkeit zu jedem Zeitpunkt, Zugkraft an jedem Messstrang, Dampfdruck in der Trockenpartie, Feuchtequerprofile, Siebpartie-Wasserablauf, Retentionsmittelzugabe. Dazu kommt die Information, ob danach ein Riss aufgetreten ist und wann.

Das Modell lernt Muster, keine Regeln. Der entscheidende Unterschied zum klassischen Prozess-Know-how: Ein erfahrener Operator kann vielleicht drei oder vier Parameter gleichzeitig im Blick behalten. Das ML-Modell analysiert 50–150 Prozessgrößen simultan und findet Interaktionsmuster, die kein Mensch intuitiv erkennen würde — zum Beispiel: „Bei Faserfeuchte über 72 % und gleichzeitigem Wechsel auf schmäleres Format ist die Risswahrscheinlichkeit in den ersten 90 Sekunden dreimal höher, wenn die Zugkraft an Strang 4 um mehr als 3 % über dem gleitenden Mittelwert liegt.”

Empfehlung vor dem Wechsel. Das System liefert dem Operator vor dem Formatwechsel eine konkrete Empfehlung: welche Startparameter für Geschwindigkeit, Zugkraft und Feuchtigkeit bei der aktuellen Maschinensituation und Fasercharge am sichersten sind. Das ist kein Befehl — es ist ein Assistenz-Hinweis, den der Operator annehmen oder begründet überschreiben kann.

Protokollierung. Jede Entscheidung — Empfehlung befolgt, Empfehlung überschrieben, Riss aufgetreten oder nicht — fließt zurück in die Datenbasis und verbessert das Modell über Zeit.

Die Warnung kann laut akademischer Forschung bis zu 60 Minuten vor einem Bandriss ausgegeben werden — in der Praxis ist bei Formatwechseln eher eine Vorlaufzeit von 5–15 Minuten realistisch und ausreichend.

Sensordaten und DCS-Anbindung: Was wirklich gebraucht wird

Das ist die Sektion, die in Verkaufsgesprächen oft fehlt und später den Projektverlauf bestimmt. Ein ML-Modell für Formatwechsel-Runnability braucht keine neue Sensorik — aber es braucht sauber aufgezeichnete historische Daten. In der Praxis fehlt genau das häufiger als erwartet.

Minimalanforderung für ein funktionierendes Modell:

Typische DCS-Anbindungsszenarien:

• AVEVA PI (früher OSIsoft): Beste Ausgangslage. AVEVA PI archiviert Zeitreihendaten hochfrequent und ermöglicht direkte Abfragen per REST-API oder OPC-UA. Wenn PI im Einsatz ist, ist die Datenankunft gelöst — die Arbeit liegt in der Auswahl und Bereinigung der relevanten Tags.
• Siemens PCS 7 / S7 via OPC-UA: Häufige Konfiguration in deutschen Werken. Die OPC-UA-Anbindung ist standardisiert, aber die Historisierungstiefe variiert stark je nach Leitsystemkonfiguration. Viele ältere Installationen speichern nur 30 oder 90 Tage Detailhistorie — für das Training zu wenig.
• Keine zentrale Historisierung: In kleineren Werken mit Batch-DCS-Systemen werden Prozessparameter nur für aktuelle Produktionsläufe gepuffert, aber nicht langfristig archiviert. Hier ist der erste Schritt kein ML-Projekt — sondern die Einführung eines Historians oder einer Time-Series-Datenbank wie InfluxDB.

Der häufigste Datenfehler: Formatwechselzeitpunkte sind nicht im DCS geloggt. Das klingt trivial, ist aber ein reales Problem: Wenn der Wechsel von 80 auf 60 g/m² um 13:42 Uhr stattfand, aber im System kein Event-Tag gesetzt wurde, kann man die Zeitreihe der Prozessparameter nicht korrekt dem Wechsel zuordnen. Ohne saubere Ereignisstempel gibt es keine Trainingsdaten — nur Rauschen.

OPC-UA-Integration-Realität: Das Protokoll ist standardisiert, die Implementierung ist es nicht. Verschiedene DCS-Hersteller haben unterschiedliche Semantik für Alarms, Events und Historydaten. Eine OPC-UA-Anbindung, die auf dem Papier trivial aussieht, kann in der Praxis 2–4 Wochen Integrationsarbeit bedeuten — besonders wenn ältere Leitsysteme keinen nativen OPC-UA-Server mitbringen und ein Wrapper nötig wird.

Konkrete Werkzeuge — was wann passt

Die Toollandschaft für Runnability-Prognose reicht von OEM-integrierten Plattformen bis zu Open-Source-Eigenentwicklungen. Die richtige Wahl hängt davon ab, wie viel Maschinenkompetenz du intern oder beim Anbieter brauchst — und wie viel Kontrolle du über das Modell haben willst.

Voith MillOne — wenn die Maschine von Voith stammt
Der direkteste Weg für Voith-Maschinen: MillOne bringt branchenspezifische Vormodelle und eine direkte Maschinenintegration mit. Voith-Serviceingenieure kalibrieren das System auf eure historischen Daten — ohne dass ihr eigene Data-Science-Kapazität braucht. Kosten: ausschließlich auf Anfrage, Enterprise-Segment. Stärke: kein Wissensaufbau intern nötig; Schwäche: starke Anbieterabhängigkeit.

Seeq — wenn ihr einen Historian habt und selbst analysieren wollt
Seeq verbindet sich direkt mit AVEVA PI, Honeywell PHD und InfluxDB und ermöglicht es Prozessingenieuren ohne Data-Science-Hintergrund, Parameterkorrelationen visuell zu explorieren. Der Seeq Data Lab ermöglicht darüber hinaus Python-ML-Modelle auf historischen Prozessdaten — der Weg von der Korrelationsanalyse zum trainierten Klassifikationsmodell ist damit in einer Plattform möglich. Kosten: ca. 1.000–1.200 USD pro Nutzer und Jahr, kein deutschsprachiger Support.

KNIME Analytics Platform — kostenloser Einstieg für Teams mit IT-Affinität
Die Desktop-Version ist dauerhaft kostenlos und Open Source. Für ein erstes Pilotmodell auf exportierten Historian-Daten (CSV oder Datenbank-Export) ist KNIME ohne Programmierkenntnisse nutzbar. Einschränkung: Keine native Echtzeit-DCS-Anbindung — Daten müssen als Batch exportiert und importiert werden. Als Explorationswerkzeug geeignet; für den Produktivbetrieb reicht KNIME allein nicht aus.

Azure Machine Learning + AVEVA PI — für Teams mit Cloud-Infrastruktur
Wer bereits auf Azure setzt und AVEVA PI als Historian hat, kann historische Prozessdaten über die PI Web API exportieren, in Azure Data Lake ablegen und dort mit Azure ML trainieren. Komplexer als Seeq, aber maximale Flexibilität beim Modellbau und vollständige Kontrolle über die Modelllogik. DSGVO-konform über EU-Azure-Regionen. Kosten: variabler Compute-Aufwand plus PI-Lizenz.

Open-Source-Stack (Python + InfluxDB + scikit-learn) — maximale Kontrolle, maximaler Aufwand
Für Werke, die volle Unabhängigkeit wollen und intern Entwicklerkapazität haben: InfluxDB sammelt die Prozessdaten lokal on-premise, Python mit scikit-learn oder LightGBM übernimmt Modelltraining und Vorhersage. Lizenzkosten nahe null; Implementierungsaufwand hoch. Nur geeignet, wenn ein Automatisierungstechniker oder Data Engineer intern verfügbar ist.

Zusammenfassung: Wann welcher Ansatz

• Voith-Maschine, kein internes Data-Science-Team → Voith MillOne
• Historian vorhanden, Ingenieure wollen selbst analysieren → Seeq
• Erkundungsphase, kein Budget → KNIME Desktop
• Azure-Infrastruktur, interne IT-Kapazität → Azure ML
• Volle Kontrolle, eigenes Team → Open-Source-Stack (InfluxDB + Python)

Operator-Akzeptanz: Wenn der Maschinenführer das System ignoriert

Das ist der Punkt, an dem mehr Projekte scheitern als an der Technologie. Ein Runnability-Prognose-System ist nur dann wirkungsvoll, wenn der Operator die Empfehlung auch befolgt. Und das ist keine Selbstverständlichkeit.

Das Grundproblem: Erfahrene Maschinenführer haben über Jahre ein feines Gespür für ihre Maschine entwickelt. Ein System, das ihnen sagt, welche Parameter sie einstellen sollen, empfinden viele zunächst als Infragestellung ihrer Kompetenz — nicht als Unterstützung. Das ist menschlich verständlich und systematisch vorhersehbar.

Was in der Praxis passiert:

• Empfehlungen werden in der Einführungsphase zwar angezeigt, aber stillschweigend ignoriert — der Operator stellt die Parameter nach gewohnter Methode ein.
• Wenn das System in einem Fall “liegt” (Riss trotz Warnung oder kein Riss trotz Warnung), wird dieser Einzelfall überproportional als Beweis gegen das System interpretiert.
• In Werken mit gutem Betriebsklima nutzen erfahrene Operatoren das System als Kontrollwerkzeug für ihre eigene Intuition — in Werken mit Vertrauensdefizit gegenüber der Unternehmensführung wird es als Kontrollinstrument wahrgenommen.

Was konkret hilft:

Erstens: Erfahrene Operatoren in die Modellvalidierung einbinden. Wenn Christiane Maders Fachwissen Teil der Qualitätskontrolle des Modells ist — wenn sie Fälle markieren kann, wo das Modell falsch liegt und warum — ist sie Mitautorin des Systems, kein Passagier. Das ist die wichtigste Investition in die Akzeptanz.

Zweitens: Das System als Lernwerkzeug framen, nicht als Entscheidungsautomat. Die Empfehlung ist kein Befehl. Sie ist eine Destillation der besten historischen Anfahrten — und der Operator soll sie bewusst annehmen oder begründet überschreiben. Überschreibungen werden geloggt und sind wertvolles Feedback für das Modell.

Drittens: Transparenz über die Modellogik. Operatoren akzeptieren Empfehlungen leichter, wenn sie verstehen, warum das System zu dieser Einschätzung kommt. “Das Modell empfiehlt 82 % Geschwindigkeit, weil die aktuelle Faserfeuchte von 74 % bei den letzten sechs vergleichbaren Wechseln mit erhöhter Risswahrscheinlichkeit korrelierte” — das ist nachvollziehbar. “Das Modell sagt Geschwindigkeit 82 %” — das ist eine Black Box.

Wann das Modell neu trainiert werden muss

Runnability-Modelle haben eine Halbwertszeit. Wer das ignoriert, bekommt nach 12–18 Monaten ein System, das selbstbewusst falsche Empfehlungen gibt — weil sich die Realität der Maschine verändert hat.

Was Modellrelevanz abbaut:

• Neue Faserquellen. Wenn die Altpapierzusammensetzung sich ändert — anderer Lieferant, andere Sortierqualität, mehr Kunststoffverunreinigung — verhalten sich Zugkraft und Feuchte beim Anfahren anders als in den Trainingsdaten. Das Modell ist auf die alte Faserbasis kalibriert.
• Maschinen-Upgrades. Ein neuer Filz, neue Siebpartie, neue Walzenbeschichtung — jede mechanische Änderung beeinflusst, wie die Maschine auf Parametereinstellungen reagiert. Das Modell weiß davon nichts.
• Saisonale Einflüsse. In manchen Werken reagiert die Maschine im Sommer anders als im Winter — Luftfeuchtigkeit, Temperatur in der Halle, Wassertemperatur in der Aufbereitung. Wenn das Trainingsset nur Winterdaten enthält, ist das Modell für den Sommer suboptimal.
• Neue Formate. Für Grammaturen oder Breiten, die im Trainingsset kaum vertreten waren, hat das Modell wenig Erfahrung und gibt unsichere Empfehlungen — oft ohne das transparent zu kommunizieren.

Empfohlene Retraining-Trigger:

In der Praxis sollte eine namentlich verantwortliche Person — Prozessingenieur oder OT-Verantwortlicher — diese Prüfung im Kalender haben. Der häufigste Fehler: Das Modell wird einmal eingeführt und läuft ohne Pflege weiter, bis die Empfehlungen so schlecht werden, dass die Operatoren aufhören, es zu nutzen.

Datenschutz und Datenhaltung

Runnability-Prognose-Systeme verarbeiten ausschließlich Maschinendaten — Prozessparameter, Zeitreihen, Produktionsparameter. Personenbezogene Daten spielen im Kern keine Rolle. Der DSGVO-Aufwand ist damit gering im Vergleich zu HR- oder Kundendatenprojekten.

Relevante Datenschutzaspekte:

• Schichtdaten-Verknüpfung: Wenn das System Riss-Ereignisse mit der Schicht (also implizit mit bestimmten Operatoren) verknüpft, entsteht eine Leistungsauswertung — auch wenn das nicht beabsichtigt ist. Das sollte mit dem Betriebsrat abgestimmt werden, bevor Logs mit Schicht-IDs angelegt werden.
• Datenhosting bei Cloud-Lösungen: Voith MillOne und Seeq bieten EU-Datenhosting; Azure ML über EU-Azure-Regionen. InfluxDB Open Source läuft on-premise — vollständige Kontrolle, kein Datenaustritt.
• AVV bei Cloud-Tools: Auch für reine Maschinendaten ist ein Auftragsverarbeitungsvertrag (Art. 28 DSGVO) nötig, sobald Daten an einen Cloud-Anbieter übertragen werden — falls irgendeine Personenbeziehbarkeit (z. B. Schichtpläne) mitfließt.
• Betriebliche Mitbestimmung: Das Einführen eines Systems, das Empfehlungen an Operatoren gibt und deren Entscheidungen protokolliert, kann mitbestimmungspflichtig sein. Informiere den Betriebsrat frühzeitig — das verhindert Eskalationen in der Einführungsphase.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

Die Kosten hängen vor allem daran, ob Historian-Daten bereits vorhanden und sauber sind oder erst aufgebaut werden müssen.

• Wenn Historian vorhanden (AVEVA PI oder äquivalent): 20.000–60.000 Euro für Datenanalyse, Modellentwicklung, Pilottest und Operator-Interface. Tendenz nach oben bei vielen DCS-Systemen oder Datenqualitätsproblemen.
• Wenn kein Historian vorhanden: Erst Historian-Einführung (InfluxDB on-premise: 5.000–15.000 Euro Einrichtung durch Integrator), dann Modellentwicklung. Gesamtaufwand: 6–12 Monate, 35.000–80.000 Euro.
• OEM-Plattform (Voith MillOne): Preise auf Anfrage, aber orientiere dich an sechsstelligen Beträgen über Vertragslaufzeiten — inklusive Betrieb und Modellpflege durch Voith.

Laufende Kosten (monatlich)

• Seeq: ca. 80–100 Euro/Nutzer/Monat (1.000–1.200 USD/Nutzer/Jahr)
• Azure ML: abhängig von Compute, oft 200–600 Euro/Monat für ein Modell mit wöchentlichem Retraining
• Open-Source-Stack: nur Infrastruktur und Ingenieurzeit, oft unter 200 Euro/Monat

Was du dagegenrechnen kannst

Konservatives Szenario: Eine Maschine mit 2 Anfahrtrissen pro Woche bei Formatwechseln. Bei ~1.500 Euro Kosten pro Riss: 156.000 Euro Jahreskostenrisiko durch Anfahrtrisse. Wenn das System 35 Prozent davon verhindert: ~55.000 Euro Einsparung pro Jahr. Das amortisiert ein 50.000-Euro-Pilotprojekt in unter 12 Monaten — im realistischen Bereich.

Für die Entscheidung wichtiger als die Hochrechnung: Wie oft wechselt eure Maschine das Format, und wie oft entsteht dabei ein Riss? Wenn du das nicht weißt, ist der erste Schritt nicht das Modell — es ist das Monitoring.

Drei typische Einstiegsfehler

1. Ohne saubere Ereignisstempel ins Modell-Training starten.
Das häufigste technische Scheitern: Der Historian enthält Prozessparameter, aber Formatwechsel-Zeitpunkte wurden nie systematisch als Events markiert. Das Ergebnis: Man kann die Zeitreihen nicht korrekt den Formatwechseln zuordnen, und das Modell trainiert auf Rauschen statt auf Signal. Lösung: Bevor irgendein Modell gebaut wird, sicherstellen, dass alle künftigen Formatwechsel mit Zeitstempel, Ausgangs- und Zielgramatur im DCS protokolliert werden — und für die Vergangenheit aus Produktionsprotokollen nacherfassen, soweit möglich.

2. Das Modell einführen, ohne die Operatoren einzubinden.
Runnability-Prognose funktioniert nur, wenn die Empfehlungen auch befolgt werden. Wer das System ausrollt, ohne die Maschinenführer in die Validierung einzubinden, bekommt ein System, das läuft — aber niemanden, der es nutzt. Der Widerstand ist selten offen, aber er ist da. Lösung: Mindestens zwei erfahrene Schichtführer als “Modell-Reviewer” benennen, bevor das System scharfgestellt wird. Sie testen die Empfehlungen in der Pilotphase und geben Feedback, welche Situationen das Modell noch nicht gut abdeckt.

3. Modellpflege als “technisches Nachher” behandeln.
Die Einführung gelingt, der Pilot sieht gut aus, das Modell läuft. Dann passiert sechs Monate nichts — bis der Lieferant wechselt oder ein Umbau stattfindet. Das Modell gibt weiter Empfehlungen auf Basis veralteter Trainingsdaten. Operatoren merken, dass die Empfehlungen schlechter werden, nutzen das System immer seltener, und irgendwann ist es de facto tot — aber niemand hat es offiziell abgeschaltet. Lösung: Modell-Verantwortung vor dem Go-live namentlich zuweisen. Wer prüft vierteljährlich die Modellgüte? Wer löst einen Retraining-Prozess aus? Diese Fragen müssen vor dem ersten Produktivtag beantwortet sein.

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

Ein Runnability-Prognose-System ist kein Autopilot. Es ist ein Assistenzsystem — und der Unterschied ist entscheidend für realistische Erwartungen.

Was passiert:
Das System lernt aus historischen Formatwechseldaten und schlägt beim nächsten Wechsel Startparameter vor. Die Operatoren, die das System konsequent nutzen, berichten nach einigen Wochen, dass sie weniger nach Gefühl einregeln müssen — besonders bei unbekannten Kombinationen (neue Fasercharge + ungewöhnliches Format). Junge Maschinenführer profitieren überproportional: Das Modell komprimiert Jahre an implizitem Erfahrungswissen in eine konkrete Empfehlung.

Was nicht passiert:
Das System ersetzt erfahrene Operatoren nicht. Es ersetzt auch nicht das Situationsbewusstsein in der Schicht. Wenn eine Maschine mechanisch nicht in Ordnung ist — eine abgenutzte Walze, ein Filz am Ende seiner Lebensdauer, ein Leckage-Problem in der Nasspartie — dann verschlechtert sich die Runnability unabhängig von den Startparametern. Das Modell erkennt diese Ursachen nicht und kann sie nicht kompensieren.

Was Wochen dauert, nicht Tage:
Operator-Vertrauen. In den ersten zwei bis vier Wochen werden Empfehlungen häufig hinterfragt oder ignoriert. Das ist normal und kein Zeichen für Systemversagen. Das Vertrauen wächst mit jeder korrekt vorhergesagten Risssituation — und durch transparente Kommunikation, wenn das Modell einmal daneben liegt und warum.

Widerstandsmuster:
Drei Reaktionen treten zuverlässig auf: Die “Das kann keine Maschine besser wissen als ich”-Haltung (Antwort: Einbindung in Validierung, nicht Überzeugungsdiskussion). Die “Das funktioniert bei uns sowieso nicht”-Pauschalskepsis (Antwort: Pilotphase explizit befristen, Erfolgskriterien vorab definieren). Das Schweigen — Empfehlung nicht aktiv abgelehnt, aber nicht umgesetzt (Antwort: Logging zeigt es, frühzeitiges Gespräch mit Schichtleitung).

Realistischer Zeitplan mit Risikohinweisen

Ehrliche Einschätzung zum Zeitplan: Wer exzellente Historian-Daten hat und intern Prozessingenieure mit Python-Kenntnissen, kann nach 8 Wochen einen ersten Piloten haben. Wer Datenaufbereitung unterschätzt, ist in Woche 8 noch bei der Ereignismarkierung. Plan lieber 12 Wochen für den Pilot — und setze explizit Erfolgskriterien fest, bevor der Pilot beginnt (z. B. “Wenn das System in der Pilotphase 3 von 5 Rissen korrekt vorhersagt, gehen wir in die Einführung”).

Häufige Einwände — und was dahintersteckt

„Unsere Maschinenführer kennen die Maschine besser als jedes KI-System.”
Das stimmt — für die Kombinationen, die sie persönlich erlebt haben. Das Modell kennt alle Kombinationen aus 12–24 Monaten Betrieb auf dieser Maschine, von allen Schichten, bei allen Faserchargen. Das ist kein Wettbewerb, sondern eine Ergänzung: Der Operator bringt Situationsbewusstsein, das Modell bringt statistische Tiefe. Das Problem ist nicht Kompetenz, sondern Kapazität — kein Mensch kann gleichzeitig 80 Prozessparameter in ihrer Kombination im Blick haben.

„Wir haben zu wenige Risse, um ein Modell zu trainieren.”
Das ist ein echtes Ausschlusskriterium — kein Einwand. Wenn eure Maschine weniger als 1–2 Anfahrtrisse pro Monat hat, reichen die Trainingsdaten eines Jahres nicht aus, um ein zuverlässiges Modell zu bauen. Das bedeutet nicht, dass die Prognose grundsätzlich nicht funktioniert — es bedeutet, dass die Datenbasis noch zu dünn ist. Lösung: Erst Daten sammeln, dann Modell bauen. In der Zwischenzeit lohnt sich die manuelle Analyse vergangener Rissereignisse mit Seeq.

„Das rentiert sich für uns nicht, wir haben nur eine Maschine.”
Hängt von der Rissfrequenz ab, nicht von der Maschinenanzahl. Bei einer Maschine mit 2–3 Anfahrtrissen pro Woche bei Formatwechseln ist das Jahreskostenrisiko über 150.000 Euro — ein Pilotprojekt für 30.000–50.000 Euro rechnet sich. Bei einer Maschine, die selten wechselt und noch seltener reißt, stimmt das Argument: Dann ist Erfahrungswissen der günstigere Weg.

Woran du merkst, dass das zu dir passt

• Ihr macht mindestens 3–5 Formatwechsel pro Woche und habt dabei regelmäßig 1–2 Anfahrtrisse — genug Ereignisse für ein Training, genug Kosten für einen klaren ROI
• Eure erfahrensten Maschinenführer gehen in den nächsten 5 Jahren in Rente, und ihr habt das implizite Wissen noch nicht gesichert
• Im DCS-Historian liegen 12+ Monate Prozessparameter mit minutengenauer oder sekündengenauer Auflösung vor — das ist die Grundvoraussetzung für alles
• Ihr führt aktuell Formatwechsel nach internen Tabellen oder Bauchgefühl durch, ohne systematische Parameterempfehlung

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

1. Weniger als 1 Anfahrriss pro Monat bei Formatwechseln. Die Trainingsdatenbasis ist zu dünn. Man braucht genug negative Ereignisse (Risse), um ein Modell zu unterscheiden. Bei seltenen Ereignissen ist man drei bis vier Jahre an einer Maschine, bevor genug Daten vorhanden sind — und dann hat sich die Maschine schon wieder verändert.

2. Kein DCS-Historian mit mehr als 90 Tagen Historientiefe. Ohne archivierte Prozessparameter gibt es nichts zu analysieren. Der erste Investitionsschritt ist dann eine Historian-Infrastruktur (InfluxDB on-premise oder AVEVA PI), kein ML-Modell. Das ist ein 3–6-Monate-Projekt vor dem Projekt.

3. Formatwechsel werden im DCS nicht als Events geloggt (kein Zeitstempel, kein Grammatur-Label im Historian). Ohne diese Labels ist der Abgleich von Prozessdaten und Riss-Ereignissen nicht möglich. Auch hier: Erst die Datengrundlage schaffen, dann modellieren.

Das kannst du heute noch tun

Bevor du auch nur über ein Modell nachdenken kannst, musst du wissen, was eure Maschine tatsächlich macht. Starte mit einer einfachen Auswertung in Seeq oder einem CSV-Export aus dem Historian:

• Wie viele Formatwechsel habt ihr pro Monat?
• Bei wie vielen davon kam es zu einem Anfahrriss?
• Welcher Formatwechsel-Typ (z. B. breiter → schmäler, schwerer → leichter) ist am häufigsten betroffen?

Wenn du keinen Historian hast, der diese Fragen beantworten kann: Das ist das erste Ergebnis — und der erste konkrete Schritt. Wenn du einen Historian hast: Nutze den folgenden Prompt, um eine erste KI-unterstützte Analyse zu starten.

Quellen & Methodik

• Vernaio / Voith Group (2024): „Preventing Sheet Breaks in the Papermaking Process” — Fallstudie auf Basis von Voith-Produktionsdaten. Kernergebnis: 55 % durchschnittliche Reduktion der Bandrisse (bis zu 87 %), geschätzte Jahreseinsparung 979.000 Euro pro Maschine bei 1.500 Euro Kosten pro Riss und 3 Rissen/Tag. URL: vernaio.com/success-stories/preventing-sheet-breaks
• Oxmaint (2024): „Case Study: Paper Mill Reduces Production Breaks 72%.” Praxisfall: Werk mit 850 Tonnen Tageskapazität (Containerboard), 72 % Reduzierung in 14 Monaten, 3,4 Mio. USD zurückgewonnene Produktionswert, 399.000 USD Investment, 680 % ROI. URL: oxmaint.com/case-study
• „The Break Point: A Machine Learning Approach to Web Breaks in Paper Mills” (Springer, 2023): Forschungsarbeit zur ML-basierten Bandrissvorhersage in Tissue-Maschinen, 86 % Klassifikationsgenauigkeit. DOI: 10.1007/978-3-031-20788-4_5
• Timo Ahola, Universität Oulu: „Intelligent Estimation of Web Break Sensitivity in Paper Machines” — Dissertation, Grundlagenarbeit zu CBR-Ansätzen und Fuzzy-Logik für Riss-Sensitivitätsindikatoren. URL: oulurepo.oulu.fi
• Kostenrichtwert 1.500 Euro pro Bandriss: Industrierichtwert, übereinstimmend zitiert in Vernaio-Fallstudie und IPPTA-Fachpublikation (2024). Bezieht sich auf eine Maschine mit 800 Tonnen Tageskapazität (W&P-Papier) — höhere Kapazität oder teurere Sorten erhöhen den Wert proportional.
• Concept Drift in ML-Modellen: ScienceDirect, „From concept drift to model degradation: An overview on performance-aware drift detectors” (2022). Grundlage für Retraining-Empfehlungen. DOI: 10.1016/j.knosys.2022.109002
• Klassenimbalance und Bandriss-Prognose: Ahola-Dissertation und Springer-Kapitel; beide berichten über das typische 1:50- bis 1:200-Ungleichgewicht zwischen Riss- und Normal-Klasse in Paper-Mill-Daten.

Du willst wissen, ob euer Historian die nötigen Daten enthält und welche Formatwechsel-Kombinationen bei euch am risikoreichsten sind? Meld dich — das können wir in einem kurzen Gespräch klären.