Agenten für Produktionslinien: Vertrauenswürdige Entscheidungen in Echtzeit

Zusammenfassung

09:14 Uhr, Mitte der Schicht. Der Füller fällt aus. Dem Linien-Manager bleiben Minuten, nicht Stunden, bevor nachgelagerte Anlagen leerlaufen. Das Team weiß mechanisch bereits, was zu tun ist. Die Fragen, die mehr Zeit in Anspruch nehmen, betreffen die Planung. Können wir das Schichtziel noch erreichen? Ist es günstiger, danach die Geschwindigkeit zu erhöhen oder Überstunden anzuordnen? Trat dieselbe Störung an dieser Linie schon einmal auf, und wie hat die vorherige Schicht darauf reagiert?

Die Daten zur Beantwortung aller drei Fragen sind bereits vorhanden, verteilt über PLCs, SCADA, MES, ERP und LIMS.

ProdLine CoPilot wurde genau für dieses Zeitfenster entwickelt. Er liest den Live-Zustand aus der Databricks Data Intelligence Platform, leitet die Frage an einen Fachexperten weiter und führt die zugrunde liegenden Berechnungen durch (Planwiederherstellung, Materialverbrauch, Qualitätsrisiko). Der zurückgegebene Plan wurde anhand von 1.000 Planungsszenarien getestet, um Kosten, Überstunden und Service optimal abzuwägen. Der Linien-Manager wählt aus. Das System entwirft die Dokumente (Arbeitsauftrag, Sperrung, Planungsnotiz) zur Freigabe.

Das eigentliche Problem: datenreich, aber erkenntnisarm

Eine typische CPG-Verpackungslinie (Flaschenabfüllung, Dosenabfüllung, Snacks, Kosmetik) umfasst 15–20 Maschinen. Wenn ein Füller oder Etikettierer stoppt, überbrücken Puffer nur wenige Minuten, bevor die Linie leerläuft und die Produktion weit unter die Nennleistung fällt. Eine OEE auf Weltklasse-Niveau liegt bei fast 85 %; viele Werke bewegen sich eher im niedrigen bis mittleren 70er-Bereich. Bei 500 Kartons/Stunde im 24/5-Schichtbetrieb und 10 € Deckungsbeitrag pro Karton entspricht ein OEE-Punkt etwa 300.000 € pro Jahr. Schließen Sie eine Lücke von 10 Punkten auf einer einzigen Linie, sind Sie schnell im niedrigen Millionenbereich. Bei einem Werk mit einem Dutzend Linien summiert sich das rasch.

Die Daten zur Schließung dieser Lücke sind bereits vorhanden:

• PLCs und SCADA streamen Telemetriedaten im Subsekundentakt.
• MES erfasst jeden Mikrostopp, Hauptstopp, jede Sperrung und jedes Rüstzeit-Protokoll.
• ERP enthält Bestände und Produktionspläne.
• LIMS verwaltet die Qualitätsergebnisse.

Diese Systeme kommunizieren nicht miteinander. Und die Personen, die Antworten benötigen (Linien-Manager, Schichtleiter, Planer), schreiben oft kein SQL.

Das Muster ist bekannt: zuerst Berichte zum Schichtende, am nächsten Morgen die Abfrage durch Analysten und schließlich ein RCA-Meeting 24 Stunden nach dem Ereignis. Und das alles, während die Entscheidung zur Behebung (Geschwindigkeit, Überstunden, CIP) bereits während der Schicht getroffen werden musste.

Das Streamen von OT-Daten an Databricks ist nicht nur ein einfaches Dashboard-Upgrade. Die Zusammenführung von OT mit MES, ERP und LIMS in einem einzigen verwalteten Lakehouse ermöglicht es Agenten, den Live-Zustand zu analysieren, unter realen Bedingungen zu optimieren und Empfehlungen noch während der Schicht statt im Nachhinein auszusprechen.

Echtzeit-Streaming: Vom morgendlichen Bericht zum Signal während der Schicht

Früher musste man eine komplexe Infrastruktur auf Kafka-Niveau (Broker, Partitionen, Consumer-Gruppen) einrichten, nur um Werksdaten zu übertragen. Zerobus Ingest ersetzt dies. Es ist push-basiert und serverlos. Alles, was gRPC- oder REST-Aufrufe senden kann (PLC-Gateway, Historian-Connector, Edge-Box), schreibt Zeilen direkt in Delta-Tabellen in Unity Catalog.

Keine Broker, keine Partitionen; Sie skalieren, indem Sie einfach mehr Verbindungen öffnen. Kombinieren Sie dies mit Lakeflow Spark Declarative Pipelines und dem standardmäßigen Bronze-, Silver- und Gold-Medaillon-Layout für Telemetrie, Qualitätssignale, Ereignisse und Bestände.

MES, ERP und LIMS werden in größeren Abständen übertragen als die OT-Daten im Subsekundentakt (Spiegelung, Batch oder CDC), aber sie liegen direkt neben den OT-Tabellen in einem einzigen verwalteten Katalog statt in einem separaten Data Warehouse.

Sobald die Daten erfasst sind, speisen dieselben Tabellen SQL, Genie, AI Search, Model Serving und Agenten – mit einer gemeinsamen Lineage unter Unity Catalog. Prädiktive Signale, Planwiederherstellung und nachgelagerte Analysen lesen alle aus diesen verwalteten Tabellen. Jede neue Funktion greift somit auf die vorhandene Kopie zu, anstatt eine eigene bereitzustellen.

Zerobus + Delta ermöglicht die Datenerfassung in Beinahe-Echtzeit mit Latenzzeiten im einstelligen Sekundenbereich, verwaltet unter Unity Catalog. Für die Live-Benutzeroberfläche in dieser Demo schreibt der Producer auch direkt in Lakebase: eine Abkürzung, um schon heute ein Echtzeit-Gefühl zu vermitteln, aber kein langfristiges Muster. Das Lesen im Millisekundenbereich auf denselben Delta-Tabellen wird künftig von Lakehouse//RT übernommen, dem Echtzeit-Warehouse von Databricks auf dem Lakehouse.

Warum Databricks

Viele Werke führen Berichte an einem Ort und Modelle an einem anderen aus, sodass für die Linie selbst mehrere Versionen der Wahrheit über verschiedene Systeme hinweg existieren. Diese Aufteilung beeinträchtigt Copilots während der Schicht:

• Bei jeder Übergabe zwischen Systemen entstehen Latenzen.
• Teams müssen hohen Abstimmungsaufwand betreiben, um Datenextrakte abzugleichen.
• Berechtigungen zwischen Datenquellen weichen voneinander ab.

Das Lakehouse auf Databricks schließt diese Lücke an jedem dieser drei Punkte. Es gibt nur eine einzige Kopie der Daten (offenes Delta auf Cloud-Speicher, kein separater Extrakt pro Workload). Die Governance erfolgt direkt auf dieser Kopie in Unity Catalog, sodass die Berechtigungen des Analysten und des Agenten aus derselben Quelle stammen. Zudem laufen Streaming, SQL, KI und Serving auf einer gemeinsamen Basis, sodass der morgendliche Bericht und der Live-Bildschirm dieselben Zahlen anzeigen.

Fachexperten und Optimierungstools lesen dieselben verwalteten Tabellen, die auch Ihre Pipelines pflegen. Es gibt keine separate KI-Datenbank.

Aufbau eines Agentensystems für Produktionslinien

Der Orchestrator

Der Orchestrator ist der zentrale Einstiegspunkt. Er nimmt eine Frage in natürlicher Sprache entgegen, lädt den aktuellen Zustand aus Unity Catalog (Maschinen, Ereignisse, Ablaufplan, Bestand, Qualität, Einschränkungen) und leitet das Anliegen an den richtigen Fachexperten weiter.

Jeder Aufruf liest den neuesten UC-Zustand, bevor das LLM startet. Das System empfiehlt und entwirft Dokumente (Tickets, Freigaben, Schichtnotizen). Die Ausführung verbleibt beim Linien-Manager, der Qualitätsabteilung und der Instandhaltung.

Das Kurzzeit-Gesprächsgedächtnis liegt in Lakebase, der Korpus vergangener Vorfälle in AI Search. Model Serving stellt die Modelle bereit und MLflow protokolliert jeden Aufruf.

Warum ein Team von Spezialisten und nicht ein einziger großer Agent?

Ein einzelner generischer Agent vereinfacht zu stark oder verliert den Fokus. Ausfallzeiten-RCA, Bestände und Ablaufplan-Berechnungen erfordern unterschiedliche Daten und mathematische Modelle. Ein Team von Spezialisten sorgt dafür, dass jeder Prompt fokussiert und jedes Tool genau auf die Frage ausgerichtet bleibt.

Beispielsweise verbraucht der Ausfallzeiten-Analyst keinen Kontext für Bestandstabellen, und der Planoptimierer ruft keine Rohdaten von Qualitätsprüfungen ab, wie es der Qualitätsspezialist tun würde.

Tools, die die Spezialisten tatsächlich aufrufen

Spezialisten rufen eine kleine, feste Auswahl an Tools auf. SQL-Abfrage und Genie Space führen verwaltete Lesezugriffe durch, genau wie der Rest des Unternehmens. Der Calculator führt OEE-, Wiederherstellungs- und Bestandsabbau-Berechnungen in Python (NumPy und Pandas) über Telemetriedaten aus Databricks SQL durch. Ein Anomaly Detector berechnet den Z-Score und den Interquartilsabstand (IQR) über rollierende Fenster direkt auf diesen Tabellen. Plan & Constraints enthält die linienspezifischen Geschwindigkeitsbegrenzungen, CIP-Fenster, Rüstregeln und Überstundenregelungen. Similar Cases ruft historische Vorfälle aus Databricks AI Search ab.

Weiterleitung an einen echten Solver, nicht nur an einen Chat

Viele Copilots in der Fertigung sind nur dünne LLM-Wrapper. ProdLine leitet Anfragen über natürliche Sprache an echte Solver weiter (wie sie auch von Operations-Research-Teams verwendet werden).

Human-in-the-loop: Schließen Sie den Kreis ohne zusätzlichen Aufwand

Nichts wird ohne die Freigabe durch einen Menschen ausgeführt. Der Linienmanager ist für die Wiederherstellung verantwortlich, die Qualitätsabteilung für Sperrung und Freigabe und die Instandhaltung für den Arbeitsauftrag. Es geht darum, die kognitive Belastung durch das Hin- und Herspringen zwischen Tabellenkalkulationen, Funkgeräten und Dashboards zu verringern, nicht darum, den Produktionsleiter zu ersetzen.

Es muss drei Fragen in weniger als einer Minute beantworten: Was passiert gerade, was sind die realistischen Optionen und was kostet jede Option in Bezug auf Durchsatz, Überstunden, Qualität und Service?

Freigabestufen (konzeptbedingt):

Die aktuelle Demo deckt die Argumentations- und Empfehlungsschleife ab. Der nächste Schritt besteht darin, den Kreislauf mit System-Rückschreibungen (Write-backs) zu schließen, die alle als Entwürfe und nicht als automatische Steuerung konzipiert sind.

Die Übergabe an das CMMS ist ein Entwurf für einen Arbeitsauftrag (diagnostizierter Fehler, empfohlener Umfang, Sollzeit, benötigte Teile), den der Planer einplanen kann. Für die Qualitätssicherung erhalten das QMS und das LIMS ein vorausgefülltes Abweichungsprotokoll (Charge, Maschine, Proben-IDs, Schweregrad, empfohlene Maßnahme), das der Qualitätsleiter prüft und freigibt. MES und das Advanced Planning and Scheduling (APS)-System übernehmen einen Entwurf für ein Zeitplan-Update mit Geschwindigkeitsanpassungen, Überstunden, Reihenfolgeänderungen und der Begründung für die Wiederherstellung, der für die Schichtausführung zurückgeschrieben wird.

Die Rückverfolgbarkeit folgt demselben Fahrplan: Jede Empfehlung speichert ihre Eingaben, Annahmen, Einschränkungen, den Genehmiger und das Ergebnis durchgängig (End-to-End) und unterstützt so die Übergabe zwischen den Schichten sowie die kontinuierliche Verbesserung.

Von der Pilotlinie zum Multi-Plant-Betrieb

Der schwierigste Teil eines Multi-Plant-Rollouts sind die Daten, nicht die KI. Jedes Werk hat seine eigenen Maschinen, SOPs und LIMS-Schemata. Was das zweite Werk zu einer Ergänzung statt zu einem Parallelprojekt macht, ist die darunter liegende Streaming-Schicht: Jedes Werk nutzt dasselbe Zerobus-Muster, Medallion-Layout und dieselbe Unity Catalog-Governance, mit eigenen Tabellen und einem eigenen Genie Space unter einem dedizierten Namespace.

Die Optimierer bleiben parametrisiert. Eine line_constraints-Tabelle steuert Geschwindigkeitsgrenzen, Überstundenlimits, CIP-Fenster und Umrüstungen. Eine Änderung der Daten ändert also das Verhalten, ohne dass ein erneutes Deployment erforderlich ist.

Dieselbe Grundlage finanziert den nächsten Anwendungsfall. Energie und Nachhaltigkeit nutzen dieselbe Telemetrie, die Lieferantenqualität baut auf dem LIMS-Join auf und die Sicherheit basiert auf dem Event-Stream. Jedes neue Projekt nutzt die Infrastruktur, die das erste bereits bezahlt hat, anstatt eine parallele Plattform aufzubauen.

Jetzt loslegen

Klonen Sie das Code-Repository und führen Sie databricks bundle deploy in Ihrem eigenen Workspace aus. Um Ihre eigenen Werksdaten zu verwenden, richten Sie den Producer auf Ihren Historian statt auf den Simulator aus; Zerobus, das Medallion-Layout, die Agenten-Tools und die Human-in-the-loop-Entwürfe bleiben unverändert. Öffnen Sie prodline_copilot_film.html in einem Browser für eine zweiminütige animierte Einführung, bevor Sie klonen.

Sind Sie daran interessiert, Ihren eigenen Assistenten zur Linienüberwachung zu entwickeln, und möchten mehr erfahren? Wenden Sie sich an Ihren Databricks-Kundenbetreuer. Ein Databricks-Spezialist kann Ihnen auch dabei helfen, die Integration von OT, MES, ERP und LIMS in ein einziges, kontrolliertes Lakehouse zu planen.

Glossar

In diesem Beitrag verwendete Akronyme, alphabetisch sortiert.

• APS – Advanced Planning & Scheduling
• CDC – Change Data Capture
• CIP – Clean-In-Place (Reinigungszyklus auf einer Produktionslinie)
• CMMS – Computerized Maintenance Management System
• CPG – Consumer Packaged Goods
• ERP – Enterprise Resource Planning
• IQR – Interquartile Range (Interquartilsabstand)
• LIMS – Laboratory Information Management System
• LLM – Large Language Model
• MES – Manufacturing Execution System
• MILP – Mixed-Integer Linear Programming (Gemischt-ganzzahlige lineare Programmierung)
• OEE – Overall Equipment Effectiveness (Gesamtanlageneffektivität)
• OT – Operational Technology (die systemseitige Betriebstechnik im Werk im Gegensatz zur IT).
• PLC – Programmable Logic Controller (Speicherprogrammierbare Steuerung, SPS)
• QMS – Quality Management System
• RCA – Root Cause Analysis (Ursachenanalyse)
• SCADA – Supervisory Control And Data Acquisition
• SOP – Standard Operating Procedure (Standardarbeitsanweisung)

Verwandte Databricks-Blogs

• Entwicklung von Near-Real-Time-Apps: Zerobus und Lakebase
• Aufbau von Managed Enterprise AI Frameworks
• Maximierung des ROI in der Fertigung
• So erstellen Sie digitale Zwillinge für betriebliche Effizienz
• Schneller Einstieg in die Datenmodellierung mit Databricks Industry Data Models

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag