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.

Dias et al. (2023) klassifizierten Bandrisse an einer Tissue-Papiermaschine mit 86 Prozent Genauigkeit und schätzen, dass sich die Produktionsverluste damit um bis zu 6.000 Tonnen im Jahr senken ließen, dazu 100.000 Liter Wasser am Tag. Das ist das Potenzial laut Studie, keine gemessene Einsparung, und 86 Prozent Genauigkeit sagen bei seltenen Ereignissen wenig darüber, wie viele Risse tatsächlich erkannt werden (mehr dazu im Abschnitt zum seltenen Ereignis). Der Anbieter Vernaio rechnet für einen Kunden aus der Voith-Gruppe mit rund 1.500 Euro je Riss bei drei Rissen am Tag.

Was ein Riss bei euch kostet, rechnet ihr so: Minuten Stillstand mal Tonnen je Minute mal Deckungsbeitrag je Tonne, plus Ausschuss beim Wiederanfahren, plus Verschleiß an Filzen und Sieben. Entscheidend ist der Deckungsbeitrag. Ein Wert von 600 Euro je Minute, wie er für mittlere Maschinen kursiert, entspricht bei 600 bis 1.000 Tonnen am Tag 860 bis 1.440 Euro je Tonne, also ungefähr dem Verkaufspreis, nicht dem Verlust. Weil Papiermaschinen oft rund um die Uhr ausgelastet laufen, ist entgangene Tonnage dort tatsächlich verlorener Absatz, bewertet wird sie aber mit dem, was nach Faser, Energie und Chemie übrig bleibt.

Wie groß der Unterschied ist, zeigt IBS PPG: Der Dienstleister nennt eine Papierfabrik, die ihre Bandrisse um 40 Prozent senkte und dadurch 8.200 Tonnen im Jahr mehr produzierte, bewertet mit 820.000 Euro, also rund 100 Euro je Tonne. Wichtig für diesen Use Case: IBS erreichte das mit Kamerasystemen, Randbeschnitt, Messtechnik und Maschinenaudits, nicht mit einer ML-Vorhersage. Der Fall zeigt, was weniger Risse wert sein können, nicht, dass eine Vorhersage sie liefert.

Viele Papierfabriken haben dennoch kein Vorhersagesystem. Ein Grund: An Maschinen mit wenigen Rissen sind Bandrisse zu selten, 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

¹ Vernaio nennt für den Voith-Kunden 55 Prozent weniger Risse im Schnitt, bis zu 87 Prozent; ob live gemessen oder rückblickend berechnet, legt der Anbieter nicht offen. Dias et al. (2023) messen keine Reduktion, sondern eine Klassifikationsgenauigkeit, und die 40 Prozent bei IBS PPG stammen aus Mess- und Maschinentechnik, nicht aus einer Vorhersage. ² Ein Alarm verhindert nichts. Ob ein Riss ausbleibt, hängt an der Gegenmaßnahme, meist Geschwindigkeit senken oder Zug und Feuchte nachregeln, und daran, ob die Vorwarnzeit dafür reicht.

Einschätzung auf einen Blick

Zeitersparnis, sehr hoch (5/5) Jeder verhinderte Bandriss spart Stillstand, Minuten beim einfachen Riss, Stunden beim schweren mit Filzwechsel, und der Mannschaft die hektischste Arbeit der Schicht: Reinigung, Überführung, Wiederanfahren. An Maschinen mit mehreren Rissen am Tag ist das der größte tägliche Zeithebel dieser Branche. Die Arbeitszeit der Mannschaft ist allerdings ohnehin bezahlt; Geld bringt vor allem die gewonnene Maschinenzeit.

Kosteneinsparung, sehr hoch (5/5) An einer ausgelasteten Papiermaschine ist jede Minute Stillstand verlorene Tonnage, und Papiermaschinen laufen oft rund um die Uhr. Gerechnet wird aber mit dem Deckungsbeitrag, nicht dem Verkaufspreis: IBS PPG bewertet 8.200 Tonnen Mehrproduktion mit 820.000 Euro, Vernaio einen Riss mit 1.500 Euro. Bei drei Rissen am Tag sind das 3 mal 365 mal 1.500 Euro, rund 1,6 Millionen Euro Risskosten im Jahr, und schon ein Teil davon ist viel Geld. Bei vier Rissen im Monat sind es 72.000 Euro im Jahr, davon lässt sich ein System mit laufenden Kosten kaum bezahlen. Höchstwert deshalb nur für Maschinen mit vielen Rissen.

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 müssen einzeln sorgfältig annotiert werden, und an Maschinen mit wenigen Rissen kommen Beispiele nur langsam zusammen. Eine Maschine mit vier Rissen pro Monat sammelt in sechs Monaten erst 24; ohne annotierte Historie braucht sie für die 50 bis 80 Beispiele aus dem Abschnitt zum seltenen Ereignis ein bis knapp zwei Jahre. Dazu kommen Sensorintegration, OPC-UA-Anbindung, Edge-Hardware-Beschaffung und Validierungsläufe. Keines dieser Projekte geht in sechs Wochen produktiv.

ROI-Sicherheit, niedrig (2/5) Zwei Unsicherheiten liegen übereinander. Was ein Riss kostet, schwankt enorm, von 1.500 Euro im Vernaio-Fall bis zu Nächten wie der oben. Und wie viele Risse ein Modell im Betrieb tatsächlich verhindert, legt keiner der zitierten Anbieter mit einer offenen Live-Messung dar. Ab etwa zwei Rissen pro Woche reichen Trainingsdaten und Nutzen meist für eine positive Rechnung (siehe unten). Darunter fehlen positive Trainingsbeispiele und Geld zugleich, und der ROI kollabiert, bevor er sich rechnen kann.

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, wie viel Aufwand es spart, lässt sich vorab nicht seriös beziffern.

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. Physikalisch plausibel sind vor allem die folgenden Signale; welche an eurer Maschine tatsächlich Vorlaufzeit liefern und welche erst ausschlagen, wenn der Riss unvermeidlich ist, zeigt erst die Auswertung eurer eigenen Risse.

Zugkraftmessung (Bahnspannung), der naheliegendste 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 mögliches Rissmuster: Die Zugkraft steigt über mehrere Minuten leicht an, fluktuiert dann stärker als üblich (erhöhte Varianz), bevor sie abrupt kollabiert. Wie viele Minuten Vorlauf das bei euch gibt, ist eine empirische Frage; Vernaio nennt für seinen Fall Warnungen bis zu 60 Minuten vorher.

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. Zwischen den Partien ist ein Zug, also eine kleine Geschwindigkeitsdifferenz, bewusst eingestellt, damit die Bahn gespannt bleibt. Warnsignal sind Abweichungen von diesem eingestellten Zug über mehrere Minuten. Die Geschwindigkeiten kennt die Antriebssteuerung ohnehin, oft müssen sie nur mitgeschrieben werden. 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. Deutliche lokale Abfälle gegenüber dem Sollwert sind ein Kandidat für erhöhtes Rissrisiko an genau dieser Position; ab welcher Abweichung es kritisch wird, zeigen eure Daten.

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. Deshalb sagt auch eine Genauigkeit wie die 86 Prozent aus der Studie von Dias et al. allein nichts darüber, wie viele Risse erkannt werden. Fragt nach Trefferquote (Recall) und Fehlalarmrate.

Die Fehlalarmrate gehört gegen die Rissfrequenz gerechnet: Ein Monat hat rund 4.300 Zehn-Minuten-Fenster (720 Stunden mal 6). Schlägt das Modell in nur einem Prozent der normalen Fenster falsch an, sind das 43 Fehlalarme im Monat gegenüber vier echten Rissen. Selbst wenn es alle vier erkennt, ist nicht einmal jeder zehnte Alarm echt, und jeder Alarm, auf den jemand die Geschwindigkeit senkt, kostet Tonnage.

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.

Als grobe Orientierung der Redaktion, nicht als belegter Wert: etwa 50–80 annotierte Riss-Ereignisse pro Maschine, die unter verschiedenen Betriebsbedingungen aufgetreten sind. Bei zwei Rissen pro Woche, knapp neun im Monat, bedeutet das sechs bis zehn Monate Datensammlung. Bei vier Rissen pro Monat 12–20 Monate, 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. Oft bleiben zwischen Alarm und Riss nur wenige Minuten. 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. Siemens bietet Apps, mit denen trainierte Modelle direkt auf dem Edge-Gerät laufen; welche App aktuell welche Modellformate annimmt, prüft ihr laut unserer Toolseite am besten im Siemens-Marketplace, das Angebot ändert sich laufend. Modelle werden in Python entwickelt und über das Industrial Edge Management auf die Maschine ausgerollt. Listenpreise für Hardware und Lizenzen veröffentlicht Siemens nicht, die Kosten kennt ihr erst mit einem Angebot.

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: Für Azure ML selbst verlangt Microsoft keine Gebühr, bezahlt werden die Rechenzeit zum normalen Azure-VM-Preis, etwa 0,266 US-Dollar je Stunde für eine Linux-VM vom Typ DS3 v2 in der Region Germany West Central, und die mitgenutzten Dienste wie Blob Storage und Container Registry. Was vierteljährliches Retraining eines Zeitreihenmodells kostet, zeigt der Azure-Preisrechner.

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 OPC-UA-Quellen über ein Datenquellen-Plugin einbinden, prüft dabei dessen Lizenz, Plugins haben unterschiedliche. Alarme schickt Grafana an Benachrichtigungskanäle; einen Alarm im Leitsystem-HMI ersetzt das nicht. Vorteil: keine Cloud-Abhängigkeit, keine Lizenzkosten für den Open-Source-Kern, 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 die DSGVO, sondern der Schutz ihrer Geschäftsgeheimnisse, der die Anforderung an On-Premises-Datenhaltung treibt. Nach § 2 Nr. 1 GeschGehG ist eine Information nur dann als Geschäftsgeheimnis geschützt, wenn ihr sie durch angemessene Geheimhaltungsmaßnahmen schützt; wer Prozessdaten ohne Vertrag in fremde Clouds gibt, riskiert diesen Schutz.

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 Werks- und Maschinenkennungen vorher aus den Rohdaten entfernt werden und der Vertrag die Nutzung eurer Daten regelt
• 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: Laufen Schichtpläne oder Bedienerkennungen mit, ist vor dem Produktivbetrieb ein AVV (Auftragsverarbeitungsvertrag nach Art. 28 DSGVO) nötig; für reine Maschinendaten schützt ein Vertrag mit Geheimhaltungs- und Nutzungsklauseln. 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 (Industrie-PC): 3.000–8.000 Euro, Richtwert der Redaktion; Siemens selbst nennt keine Listenpreise
• OPC-UA-Anbindung und DCS-Integration (Systemintegrator, 5–15 Tage): 10.000–25.000 Euro
• Datenaufbereitung und Modellentwicklung (6–9 Monate): intern durch ein Data-Science-Team oder extern per Angebot, kommt zu den übrigen Posten hinzu
• Laufende Kosten (Rechenzeit fürs Retraining, Edge-Lizenzen, Wartung): 1.000–3.000 Euro/Monat

Szenario A zusammen: 13.000–33.000 Euro für Hardware und Integration, plus Modellentwicklung, plus 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): 4–6 Monate intern, extern per Angebot
• Laufende Kosten: minimal (eigene Infrastruktur), nur Betriebsaufwand

Szenario B zusammen: 2.000–4.000 Euro Hardware plus 4–6 Monate Entwicklungsarbeit

Die ROI-Rechnung, vorsichtig Was ein Riss bei euch kostet, rechnet ihr mit euren eigenen Zahlen, wie oben beschrieben: Stillstandsminuten, Tonnen je Minute, Deckungsbeitrag je Tonne, Ausschuss und Verschleiß. Als belegten Anhaltspunkt nehmen wir die 1.500 Euro je Riss aus dem Vernaio-Fall und nehmen an, dass das Modell samt Gegenmaßnahme 40 Prozent der Risse verhindert.

• Vier Risse im Monat: 4 mal 0,4 mal 1.500 Euro sind 2.400 Euro im Monat. Die laufenden Kosten von 1.000–3.000 Euro fressen das ganz oder fast ganz auf, die Einrichtung verdient sich nicht zurück.
• Zwei Risse pro Woche, knapp neun im Monat: 9 mal 0,4 mal 1.500 Euro sind rund 5.400 Euro, abzüglich laufender Kosten bleiben rund 2.400–4.400 Euro im Monat. Hardware und Integration aus Szenario A (13.000–33.000 Euro) sind damit nach drei bis 14 Monaten bezahlt, die Modellentwicklung kommt obendrauf.
• Drei Risse am Tag wie im Vernaio-Fall, rund 90 im Monat: 90 mal 0,4 mal 1.500 Euro sind 54.000 Euro im Monat. Hardware und Integration sind in unter einem Monat Produktivbetrieb bezahlt, auch eine aufwendige Modellentwicklung in wenigen Monaten.

Teurere Risse verschieben die Schwelle nach unten: Kostet ein Riss bei euch wegen langer Stillstände das Zehnfache, reichen entsprechend weniger. Dazu kommen die Kosten der Gegenmaßnahme: Jeder Alarm, auf den der Maschinenführer die Geschwindigkeit senkt, kostet Tonnage, auch wenn er ein Fehlalarm war. Und das Modell braucht 6–12 Monate zum Reifen, in dieser Zeit sind Trefferquote und Fehlalarmrate noch nicht, wo sie sein sollen.

Wann die Rechnung nicht aufgeht: Unter etwa zwei Rissen pro Woche 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 regelbasierten Alarmsystemen (“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 zwei oder mehr Bandrisse pro Woche, und die Maschine ist ausgelastet
• 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 zwei Rissen pro Woche im Jahresschnitt: Dann kommen Trainingsbeispiele zu langsam zusammen, bei vier Rissen im Monat dauert es ohne annotierte Historie ein bis knapp zwei Jahre, und selbst mit SMOTE und kostensensitivem Training bleibt die Basis dünn. Vor allem sparen die verhinderten Risse bei 1.500 Euro je Riss kaum die laufenden Kosten ein (Rechnung oben). Wer trotzdem investiert, bekommt ein System, das entweder zu viele Fehlalarme produziert oder echte Risse übersieht, in beiden Fällen ohne Return. Ausnahme: Einzelne Risse sind bei euch so teuer, dass wenige verhinderte die Rechnung tragen.

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, Lourenço, Silva und Moniz (2023), “The Break Point: A Machine Learning Approach to Web Breaks in Paper Mills”: Springer Proceedings in Mathematics & Statistics, Band 411 (Operational Research, APDIO-Kongress 2021). Tissue-Papiermaschine als Fallstudie. Riss-Klassifikation mit 86 % Genauigkeit (Accuracy); laut Abstract ließen sich die Produktionsverluste damit um bis zu 6.000 Tonnen Papier im Jahr und der Wasserverbrauch um 100.000 Liter am Tag senken, ein geschätztes Potenzial, keine gemessene Einsparung. URL: https://link.springer.com/chapter/10.1007/978-3-031-20788-4_5
• Vernaio, “Preventing Sheet Breaks in the Papermaking Process”: Anbieter-Fallstudie mit der Voith Group als Kunde. 1.500 Euro je Riss, drei Risse am Tag, im Schnitt 55 % weniger Risse (bis zu 87 %), 979.000 Euro Einsparung, Warnungen bis zu 60 Minuten vorher; ob live gemessen oder rückblickend berechnet, bleibt offen. URL: vernaio.com
• IBS PPG (ibs-ppg.com), “Reduce web breaks and broke on paper machines”: Referenzbeispiele des Dienstleisters, darunter 40 % weniger Bandrisse, 8.200 Tonnen Mehrproduktion und 820.000 €/Jahr. Erreicht mit Kamerasystemen, Randbeschnitt, Tambourwechsel-Systemen und Audits, nicht mit ML-Vorhersage. URL: https://www.ibs-ppg.com/en/save-resources/reduce-web-breaks-and-broke
• Seltene-Ereignis-ML: Shyalika, Wickramarachchi und Sheth, “A Comprehensive Survey on Rare Event Prediction”, ACM Computing Surveys 57(3), 2024. Überblick über Klassenimbalanz-Probleme und gängige Gegenmaßnahmen. URL: https://dl.acm.org/doi/10.1145/3699955
• Alarmmüdigkeit und False Positives: Hermansa et al., “Sensor-Based Predictive Maintenance with Reduction of False Alarms, A Case Study in Heavy Industry”, MDPI Sensors 22(1), 226 (2022). Die Methode reduzierte Fehlalarme gegenüber reiner Ausreißererkennung um durchschnittlich 90,25 %, an Brechern und Portalanlagen, nicht an Papiermaschinen. 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”, Dissertation, Universität Oulu (2005). Frühe Arbeit zur Vorhersage der Rissempfindlichkeit. Semanticscholar: https://www.semanticscholar.org/paper/Intelligent-estimation-of-web-break-sensitivity-in-Ahola/e64268781770d24bd2ce5ed9ae06c751e5367c29
• Edge vs. Cloud-Latenz: Reis, “Lightweight Signal Processing and Edge AI for Real-Time Anomaly Detection in IoT Sensor Networks”, MDPI Sensors 25(21), 6629 (2025). Latenzwerte und Energie-Effizienz-Vergleiche Edge vs. Cloud. URL: https://www.mdpi.com/1424-8220/25/21/6629
• Geschäftsgeheimnis: § 2 Nr. 1 GeschGehG, gesetze-im-internet.de, abgerufen am 19.09.2026.
• Tool-Preise und Spezifikationen: Toolseiten der Redaktion; Siemens und AVEVA nennen keine Listenpreise, InfluxDB und Grafana sind im Open-Source-Kern kostenlos, Azure ML rechnet nach Rechenzeit ab. Die Richtwerte für Industrie-PC und Integration sowie die 40 Prozent verhinderter Risse in der Rechnung sind Annahmen der Redaktion.

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.