ML-gestützte Brennprozess-Optimierung in der Keramikindustrie

Das echte Ausmaß des Problems

Die Keramikproduktion — Fliesen, Sanitärkeramik, technische Keramik, Feuerfestmaterial — ist eine der energieintensivsten Fertigungsbranchen. Der Brennprozess macht je nach Produkt 40–70 % der gesamten Produktionsenergie aus. Ein mittelgroßer Keramikfliesenhersteller mit zwei Tunnelöfen verbrennt täglich 5.000–15.000 m³ Erdgas — bei einem Gaspreis von 0,08–0,12 €/kWh sind das 3.000–10.000 € täglich allein für den Brennofen.

Dazu kommt der Ausschuss. Industrieerhebungen zeigen typische Ausschussraten im Keramikbrand von 3–8 % für Standard-Feinsteinzeug; bei anspruchsvolleren Produkten (Sanitärkeramik, technische Keramik, Dünnfliesen) steigen diese auf 5–15 %. Die Ursachen:

• Rohstoffcharge-Variabilität: Ton, Feldspat, Kaolin — natürliche Materialien mit variierendem Feuchtegehalt und chemischer Zusammensetzung. Kein Lieferant liefert exakt dieselbe Charge zweimal.
• Temperaturdrift im Ofen: Verschleiß an Brennerköpfen, Änderungen im Luftstrom bei Außentemperaturschwankungen, Ablagerungen auf Ofenrollen — all das verschiebt das Temperaturprofil graduell, bis es messbar im Ausschuss ankommt.
• Verlust von Expertenwissen: Die Einstellung des Brennprofils ist eine Kombination aus dokumentierten Sollwerten und mündlich tradierter Korrekturerfahrung. Wenn erfahrene Brennmeister das Unternehmen verlassen, steigt die Ausschussrate in den Folgemonaten nachweislich — weil die übernehmenden Teams diese impliziten Korrekturen nicht kennen.

Eine 2024 veröffentlichte Modellierungsstudie in Computers & Chemical Engineering zeigt, dass optimierte Tunnelofensteuerung die Ausschussrate bei veränderlichen Produktionsanforderungen um bis zu 35 % senken und gleichzeitig den Energieverbrauch um 8–12 % reduzieren kann — ohne eine einzige Komponente am Ofen auszutauschen.

Mit vs. ohne KI — ein ehrlicher Vergleich

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5) Die Zeitersparnis beim Brennmeister ist real — manuelle Zonenkorrektur und Einstellanpassung bei Chargenwechsel fallen weg oder werden deutlich vereinfacht. Aber das ist nicht der Haupttreiber dieses Anwendungsfalls. Der Brennmeister spart vielleicht eine bis zwei Stunden täglich, was verglichen mit der vollständigen Entlastung durch Inline-Qualitätsprüfung bescheiden ist. Der echte Wert liegt in der Kostendimension.

Kosteneinsparung — sehr hoch (5/5) Das ist der stärkste Hebel in dieser Kategorie: ML-Brennprozessoptimierung reduziert gleichzeitig Ausschusskosten (vermiedenes Schlechtmaterial) und Energiekosten (weniger Gasverbrauch). Für einen mittelgroßen Hersteller mit zwei Tunnelöfen und heutigem Energiepreisniveau summieren sich beide Effekte auf 100.000–400.000 € Einsparung pro Ofenlinie und Jahr — kein anderer Anwendungsfall dieser Kategorie bewegt so viel Geld.

Schnelle Umsetzung — sehr niedrig (1/5) Der ehrlichste Wert im ganzen Radar. Zehn bis achtzehn Monate sind für einen produktiven Piloten realistisch — und das ist kein Pessimismus, sondern Erfahrungswert. Der ML-Ansatz braucht historische Daten aus eurem spezifischen Ofen, euren Produkten und euren Rohstoffen. Diese Daten müssen zuerst systematisch gesammelt, bereinigt und mit den Ausschusskennzahlen korreliert werden. Wer das nicht eingeplant hat, wacht nach vier Monaten auf und stellt fest, dass das Modelltraining noch nicht begonnen hat.

ROI-Sicherheit — mittel (3/5) Der Nutzen ist real und messbar — aber der Nachweis braucht eine sorgfältige Baseline. Die Ausschussrate vor dem System muss dokumentiert sein, die Energieverbrauchsdaten je Brenneinheit ebenso. Nur dann lässt sich nach sechs Monaten ML-Betrieb der Vergleich ziehen. In der Praxis gibt es immer konfundierende Variablen: Rohstoffqualität ändert sich, ein erfahrener Brennmeister geht, die Nachfrage nach bestimmten Produkten schwankt. Diese Effekte von der ML-Wirkung zu trennen, erfordert methodisch sorgfältige Auswertung — und schränkt die Sicherheit ein.

Skalierbarkeit — hoch (4/5) Ein trainiertes Modell für Ofenlinie 1 kann als Ausgangspunkt für Linie 2 dienen — wenn beide ähnliche Produkte brennen und ähnliche Ofengeometrien haben. Das Feintuning bleibt erforderlich, aber der Grundaufwand für Linie 2 ist deutlich kleiner als für Linie 1. Mehrwertige Skalierbarkeit entsteht außerdem über die Wissens-Archivierung: Das Modell kodiert das Brennmeister-Wissen in übertragbarer Form.

Richtwerte — stark abhängig von Ofentyp, Produktmix, Rohstoffvariabilität und Datenqualität der SCADA-Historik.

Was das Modell konkret macht

Der technische Ansatz baut auf dem auf, was im SCADA-System ohnehin schon aufgezeichnet wird: Zonentemperaturen, Brennerdrücke, Durchsatzgeschwindigkeit, Restfeuchte des Grünkörpers, Außentemperatur. In den meisten modernen Tunnelöfen liegen diese Daten als Zeitreihen vor — manchmal für Jahre zurück, wenn die Historik nicht überschrieben wurde.

Ein Machine Learning-Modell — typischerweise Gradient Boosted Trees oder ein LSTM-Netz für Zeitreihendaten — lernt aus diesen historischen Daten einen Zusammenhang: Welche Kombination aus Eingangsparametern (Chargenzusammensetzung, Feuchte, Außentemperatur) erfordert welches Temperaturprofil (Zone 1–n), um eine Ausschussrate unter einem bestimmten Schwellenwert zu bleiben?

Das Modell liefert dann für jeden neuen Brand eine Empfehlung: “Für diese Rohstoffcharge bei dieser Feuchte: Zone 5 auf 1.142 °C, Zone 6 auf 1.156 °C, Zone 7 auf 1.149 °C.” Das ist entweder eine Empfehlung auf dem Display des Brennmeisters (Advisory-Modus) oder ein direkter Sollwert-Signal an die SPS (Closed-Loop).

Was das Modell voraussetzt

Das Modell kann nur lernen, was in den Daten steckt. Das bedeutet:

• Ausreichende Datenbasis: Mindestens sechs bis zwölf Monate historische Produktionsdaten mit korrespondierenden Ausschusskennzahlen. Wer nur drei Monate Daten hat, bekommt ein Modell, das saisonale Effekte nicht versteht.
• Verknüpfte Ausschusserfassung: Die Ausschussrate muss zu jedem Brand erfasst und mit dem Zeitstempel verknüpft sein. In vielen Betrieben gibt es die Ausschusszahl pro Tag oder Woche — aber nicht pro Brand. Das muss vor dem ML-Projekt geändert werden.
• Saubere Chargendaten: Rohstofflieferungen müssen mit dem Zeitpunkt ihrer Verwendung im Ofen verknüpft sein. Wenn Chargenprotokolle auf Papier im Büro liegen, müssen sie erst digitalisiert werden.

Diese Voraussetzungen klingen einfach — in der Praxis dauert ihre Umsetzung drei bis sechs Monate. Das ist der größte Zeitfresser im Projekt.

Konkrete Werkzeuge — was wann passt

Azure ML — Microsofts Cloud-ML-Plattform, EU-Hosting in West Europe verfügbar. Gut für Teams, die Python-Kenntnisse haben und ein offenes, flexibles System wollen. Stärke: starke Zeitreihen-Bibliotheken, gute Visualisierungen für Feature-Importance, faire Kosten bei mittlerem Datenvolumen. Anforderung: Ein Datenanalyst oder Data Engineer im Team, der die Pipeline aufbaut. Laufende Kosten: 500–2.000 €/Monat je nach Rechenvolumen.

DataRobot — AutoML-Plattform, die aus historischen Prozessdaten automatisch das beste Vorhersagemodell auswählt. Stärke: Kein vollständiges Data-Science-Team nötig; erfahrene Prozessingenieure können DataRobot bedienen. Feature-Importance-Berichte zeigen, welche Prozessparameter den stärksten Einfluss auf Ausschuss haben — wertvoller Nebeneffekt für die Prozessverbesserung. Einschränkung: Hohe Lizenzkosten, kein deutschsprachiger Support. EU-Hosting möglich. Sinnvoll ab ca. 50+ Mio. € Jahresumsatz.

Siemens Insights Hub — Industrielle IoT-Plattform, die SCADA-Daten aus dem Ofen direkt erfasst und für Analytics-Anwendungen bereitstellt. Besonders geeignet, wenn ihr bereits Siemens-Automatisierungstechnik einsetzt. Insights Hub übernimmt die Datenaggregation — das ML-Modell kann dann in Azure ML oder Python entwickelt und über die API angebunden werden. Vorteil: EU-Hosting, gut integriert in Siemens-Ökosystem. Nachteil: Teuer, wenn ihr nicht ohnehin Siemens-Infrastruktur nutzt.

Python + Open-Source (scikit-learn, LightGBM, Prophet) — Für Teams mit Data-Science-Kompetenz intern die flexibelste und günstigste Option. Kein Vendor-Lock-in, vollständige Kontrolle über Modell und Daten. Nachteil: Braucht mindestens eine Person mit ML-Erfahrung. Hosting kann auf eigenem Server oder Azure EU-Region erfolgen.

Zusammenfassung: Wann welcher Ansatz

• Siemens-Infrastruktur vorhanden → Insights Hub für Datenaggregation + Azure ML für Modell
• Kein Data-Science-Team, Budget vorhanden → DataRobot
• Python-Know-how intern → scikit-learn + Azure ML
• Unter 20 Mio. € Umsatz → Open-Source-Python-Pilot zuerst, bevor Lizenzkosten entstehen

Datenqualität als Voraussetzung

Dieser Anwendungsfall hat eine harte Datenvoraussetzung, die über Erfolg und Misserfolg entscheidet — mehr als die Werkzeugwahl.

Was ihr braucht:

Die häufigste Erkenntnis zu Beginn eines Projekts: Die Daten sind da — aber nicht in der Granularität, die das ML-Modell braucht. Das ist kein Showstopper, aber es bedeutet drei bis sechs Monate Vorlaufarbeit: SCADA-Historian verlängern, Chargendaten digitalisieren, Ausschussprotokoll brandspezifisch umstellen.

Diese Vorarbeit ist unabhängig vom ML-Einsatz wertvoll. Unternehmen, die diese Daten systematisch erfassen, verbessern ihre Brennprozesse bereits messbar — noch bevor ein ML-Modell läuft.

Datenschutz und Datenhaltung

Brennprozessdaten enthalten keine personenbezogenen Daten. Die relevante Schutzfrage ist auch hier das Betriebsgeheimnis: Temperaturprofile, Rohstoffkombinationen und Ausschussparameter sind prozesstechnisches Know-how mit Wettbewerbsrelevanz.

Für den ML-Betrieb empfiehlt sich:

• On-Premise oder EU-Cloud: Trainings- und Inferenzdaten sollten das Unternehmensnetzwerk nicht verlassen. Azure ML in der EU-Region (West Europe) oder ein eigener Server sind die üblichen Optionen.
• Trennung von OT und IT: Das SCADA-System sollte keine direkte Internetverbindung haben. Datentransfer zwischen OT und ML-System über eine gesicherte DMZ mit definierten Übertragungsprotokollen.
• Zugriffsprotokollierung: Wer hat Zugang zu den Modellen und den historischen Produktionsdaten? Für Industriespionage-Risiken ist das eine reale Überlegung, besonders bei Spezialkeramiken mit proprietären Rezepturen.

Falls ein externer ML-Dienstleister die Modellentwicklung übernimmt: Einen Auftragsverarbeitungsvertrag (DSGVO Art. 28) abschließen und sicherstellen, dass der Anbieter die Daten ausschließlich für das Projektvorhaben nutzt — nicht für das Training eigener generischer Modelle.

Was es kostet — realistisch gerechnet

Projektkosten (einmalig)

• Datenaufbereitung und Historisierung (intern oder extern): 20.000–50.000 €
• ML-Modellentwicklung und Validierung (extern begleitet): 30.000–80.000 €
• SPS/SCADA-Integration der Empfehlungsschnittstelle: 10.000–30.000 €
• Interne Projektzeit (Prozessexperten, IT): 3–6 Personenmonate

Laufende Kosten (jährlich)

• Azure ML oder DataRobot Lizenz: 6.000–24.000 € je nach Nutzungsvolumen
• Modell-Review und Nachtraining bei Produktionswechseln: 10.000–20.000 €
• Systempflege und Schnittstellen-Wartung: 5.000–15.000 €

Was du gegenzurechnen kannst Für einen Hersteller mit zwei Tunnelöfen, Jahresgasverbrauch 8 Mio. m³ und 4% aktueller Ausschussquote:

• Gaseinsparung 8 %: ca. 640.000 m³ × 0,09 €/m³ = 57.600 € jährlich
• Ausschussreduktion 30 %: Bei 3 Mio. € Ausschusskosten/Jahr = 900.000 € jährlich

Gesamtpotenzial: knapp 1 Mio. € — bei Gesamtinvestitionskosten von 100.000–180.000 € ergibt sich ein theoretischer Amortisationszeitraum von drei bis sechs Monaten nach Produktivbetrieb. In der Praxis ist ein realistisches Szenario bei 40–50 % des theoretischen Nutzens anzusetzen — wegen konfundierender Variablen und Modellreife — also ca. 400.000–500.000 € im ersten Jahr.

Tipp für die Investitionsfreigabe: Fangt mit einem einzigen Ofen an. Der ROI eines Piloten an Ofen 1 ist in sechs Monaten belegbar und liefert das beste Argument für den Rollout auf Ofen 2 und 3.

Drei typische Einstiegsfehler

1. Die Datenvorarbeit unterschätzen und direkt mit dem Modell anfangen. Fast jedes Projekt, das frühzeitig scheitert, hat das Problem hier: Ein ML-Anbieter wird beauftragt, bekommt die SCADA-Daten aus den letzten drei Monaten — und stellt nach zwei Wochen fest, dass die Ausschussdaten nicht brandspezifisch, die Chargendaten nicht digital und die Temperaturdaten in der entscheidenden Phase wegen eines Sensorausfalls lückenhaft sind. Das Modelltraining beginnt sechs Monate später als geplant. Lösung: Vor dem Kick-off des ML-Projekts einen einmonatigen Daten-Audit durchführen. Was ist vorhanden, in welcher Qualität, in welcher Granularität? Erst dann starten.

2. Den Brennmeister nicht einbinden — und dann vom Brennmeister bekämpft werden. Das ML-Modell trifft Empfehlungen, die manchmal der jahrzehntelangen Erfahrung des Brennmeisters widersprechen. Wenn das Modell an einem Tag empfiehlt, Zone 8 um 8 Grad zu senken, und der Brennmeister weiß aus Erfahrung, dass das bei dieser Luftfeuchtigkeit nicht stimmt — und Recht hat — verliert das Modell dauerhaft seine Akzeptanz. Lösung: Den Brennmeister von Anfang an als Experten einbinden. Nicht das Modell präsentieren, sondern gemeinsam erarbeiten. Die historischen Daten zeigen, dass der Brennmeister in 73 % der Fälle richtig lag und das Modell in 81 % — nicht das Modell gegen den Menschen, sondern beides kombiniert.

3. Das Modell in der Produktion laufen lassen, ohne Monitoring. ML-Modelle driften. Wenn ein Rohstofflieferant gewechselt wird und die neue Charge andere Eigenschaften hat als alle bisherigen, kann das Modell danebenzuliegen beginnen — ohne es zu “merken”. In einem Closed-Loop-System (direkter Sollwert an die SPS) kann das zu erhöhtem Ausschuss führen, ohne sofort als Modellversagen erkannt zu werden. Lösung: Modell-Performance monatlich messen — vorhergesagte vs. tatsächliche Ausschussrate. Wenn die Abweichung über eine definierte Schwelle steigt: Alarm, kein automatisches Eingreifen, bis das Modell nachtrainiert wurde.

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

Das ML-Projekt hat zwei Phasen, die sich in der Erfahrung grundlegend unterscheiden: die Entwicklungsphase ist oft enthusiastisch, die Übergabe in den Routinebetrieb oft enttäuschend.

In der Entwicklungsphase sehen alle das Potenzial: Die historischen Daten zeigen klare Zusammenhänge zwischen Prozessparametern und Ausschuss. Das Modell liefert im Backtest beeindruckende Vorhersagegenauigkeit. Alle glauben, dass in zwei Monaten der Ausschuss um die Hälfte sinkt.

Dann beginnt der Produktivbetrieb. Und der Alltag trifft auf das Modell:

• Ein Sensor fällt drei Tage aus — das Modell bekommt fehlerhafte Inputs und gibt fragwürdige Empfehlungen
• Ein neuer Brennmeister interpretiert die Empfehlungsanzeige anders als vorgesehen
• Die Ausschussrate steigt einen Monat nach Go-Live leicht an, weil ein Rohstoffwechsel das Modell überfordert

Diese Störungen sind keine Projektsscheitern — sie sind normale Anlaufphänomene. Aber ohne ein strukturiertes Monitoring-Konzept und eine klare Verantwortlichkeit (“Wer ist der Modell-Owner?”) werden sie als Beweis genommen, dass “KI nichts taugt”.

Was konkret hilft:

• Advisory-Modus vor Closed-Loop: Mindestens drei Monate lang nur Empfehlungen anzeigen, kein automatischer Sollwert
• Wöchentliche Kurzreviews zwischen Brennmeister und Datenanalysten: Was hat das Modell empfohlen, was war das Ergebnis?
• Feste Zuständigkeit: Eine Person (intern oder extern) ist für die Modellqualität verantwortlich und reagiert auf Driftanzeichen

Realistischer Zeitplan mit Risikohinweisen

Kritischer Punkt: Wer mit einem Piloten beginnt, sollte mindestens sechs Monate nach Go-Live warten, bevor er den ROI bewertet. In den ersten Monaten ist das Modell noch nicht auf alle Chargen-Varianten getroffen — die Leistung verbessert sich mit jeder neuen Situation, die das System durchläuft.

Häufige Einwände — und was dahintersteckt

„Unsere Brennmeister haben das immer selbst im Griff.” Stimmt — solange sie da sind. Das ist genau das Problem. Jede Abhängigkeit von Einzelpersonen mit implizitem Wissen ist ein Unternehmensrisiko. ML-Brennprozessoptimierung ist kein Angriff auf die Kompetenz des Brennmeisters — es ist die Sicherung dieser Kompetenz für den Fall, dass er krank, im Urlaub oder in Rente ist.

„Unsere Prozessdaten sind nicht sauber genug.” Das ist der häufigste Einwand — und der am meisten vorgeschobene. Kein industrielles Unternehmen hat perfekte Daten. Das ML-Modell lernt auch aus unvollständigen Daten, sofern die relevanten Variablen grundsätzlich vorhanden sind. Was nicht geht: komplett fehlende Zielvariablen (keine Ausschusserfassung je Brand) oder Sensoren, die seit Jahren fehlerhafte Daten liefern. Beides lässt sich in ein bis drei Monaten beheben.

„Das haben wir alles schon in unserem Leitsystem.” SCADA-Systeme speichern Ist-Werte — sie optimieren nichts. Der Unterschied ist fundamental: Das SCADA zeigt, was war. Ein ML-Modell empfiehlt, was sein sollte. Diese Funktion existiert in keinem Standard-Leitsystem, das wir kennen.

Woran du merkst, dass das zu dir passt

• Deine Ausschussrate schwankt stark zwischen Rohstoffchargen — manchmal 2 %, manchmal 8 % — und du weißt nicht systematisch, warum
• Dein Gasverbrauch je gebrannte Einheit variiert von Monat zu Monat ohne klare Erklärung
• Du hast erfahrene Brennmeister, die demnächst in Rente gehen, und niemanden mit vergleichbarem impliziten Wissen als Nachfolge
• Dein SCADA-System zeichnet seit mindestens zwei Jahren Prozessdaten auf — die Historik ist die Trainingsgrundlage

Wann es (noch) nicht passt — drei harte Ausschlusskriterien:

1. Du hast weniger als 12 Monate hochaufgelöste Prozessdaten. Ein ML-Modell, das mit drei bis sechs Monaten Daten trainiert wird, lernt keine saisonalen Muster und reagiert schlecht auf unbekannte Chargen-Kombinationen. Die Qualität des Modells ist direkt proportional zur Qualität und Tiefe der Trainingsdaten. Beginne mit Daten sammeln und komme in einem Jahr wieder.

2. Keine interne Person, die das Modell dauerhaft betreut. Ein ML-Modell im Produktionsbetrieb ist keine Software, die man einmal installiert und vergisst. Es braucht monatliches Monitoring, Nachtraining bei Chargenwechseln, Anpassung bei Produktänderungen. Ohne eine feste Zuständigkeit — intern oder über einen dauerhaften Wartungsvertrag mit einem externen Anbieter — wird das System nach 12–18 Monaten zur schwarzen Box, die niemand mehr versteht.

3. Dein Produktionsmix wechselt so häufig, dass du täglich unterschiedliche Keramiktypen brennst. Je größer die Varianz im Produktmix, desto mehr Daten braucht das Modell pro Produkttyp. Bei sehr hoher Varianz ist der Trainingsaufwand proportional größer — und der ROI entsprechend unsicherer. Für Kleinserienhersteller mit mehr als zehn verschiedenen Produkttypen lohnt sich erst ein Pilot für die drei umsatzstärksten Produkte.

Das kannst du heute noch tun

Bevor du eine Technologieentscheidung triffst: Starte einen Daten-Audit. Prüfe für die letzten zwölf Monate:

1. Liegen brandspezifische Ausschussquoten vor — nicht nur Tages- oder Wochensummen?
2. Welche SCADA-Daten werden aufgezeichnet, wie lange wird die Historik gespeichert?
3. Sind Rohstoffchargen digital mit dem Zeitpunkt ihrer Verwendung verknüpft?

Wenn alle drei Fragen mit “ja” beantwortet sind, habt ihr die Voraussetzungen für ein ML-Pilotprojekt. Wenn nicht: startet mit dem Aufbau dieser Datenbasis — die Investition lohnt sich unabhängig vom späteren ML-Einsatz.

Für eine erste Einschätzung, ob ML für eure spezifischen Daten funktionieren kann:

Quellen & Methodik

• Energieanteil Brennprozess 40–70%: Thermal Analysis and Energy Efficiency Improvements in Tunnel Kiln for Sustainable Environment, MDPI Processes 2021; eigene Einschätzungen aus Branchenberichten.
• Modellierungsstudie Tunnelkiln: Arvanitidis & Kostoglou, „Modeling, optimization and control of a ceramic tunnel kiln for consistent product quality under changing production demands”, Computers & Chemical Engineering (2024), DOI 10.1016/j.compchemeng.2024.108540.
• Energieeinsparung 8–12%: Siemens AG, „AI Kiln Solution For Optimized Control” (IEEE 2023, öffentlich als PDF verfügbar); Carbon Re, „AI in Cement” White Paper (2023) — Übertragbarkeit auf Keramik begrenzt, Größenordnung vergleichbar.
• Ausschussraten Keramikindustrie: CeramForge, „Quality Control in Industrial Ceramics Production” (2024); InTouch-Quality, „Ceramic Inspection and Quality Control Standards” (2023); eigene Erfahrungswerte aus Branchenprojekten.
• ML-Ansatz Zeitreihen: Azure ML-Dokumentation (Stand April 2026); DataRobot-Produktdokumentation (Stand April 2026).