Sketch2Simulation: Automating Flowsheet Generation via Multi Agent Large Language Models

Die Arbeit stellt ein Multi-Agenten-LLM-System namens Sketch2Simulation vor, das Prozessskizzen automatisch in ausführbare Aspen HYSYS-Simulationsmodelle umwandelt und dabei durch eine mehrstufige Architektur von Diagrammparsing bis hin zur Validierung eine hohe strukturelle und verbindungsbezogene Genauigkeit über verschiedene chemische Ingenieursfälle hinweg erreicht.

Das Wesentliche

Stellen Sie sich vor, Sie sind ein erfahrener Koch. Sie haben eine handgezeichnete Skizze eines neuen Rezepts von einem Kunden erhalten. Die Skizze ist etwas krumm, einige Zutaten sind nur mit Strichen angedeutet, und die Reihenfolge der Schritte ist nicht ganz klar.

Ihr Ziel ist es, aus dieser Skizze ein perfektes, funktionierendes Gericht zu kochen, das in einer hochmodernen, aber sehr strengen Küche zubereitet wird. Diese Küche (der Computersimulator) akzeptiert keine "vielleicht" oder "grob". Sie braucht exakte Grammangaben, präzise Temperaturen und eine lückenlose Anleitung. Wenn Sie einen Schritt falsch machen, explodiert die Küche (oder der Computer stürzt ab).

Das ist genau das Problem, das die Forscher in diesem Papier lösen wollen: Wie wandelt man eine unordentliche Handzeichnung in ein perfektes, lauffähiges Computermodell um?

Hier ist die Lösung, erklärt mit einfachen Analogien:

1. Das Problem: Die Sprache der Zeichnung vs. die Sprache des Computers

Früher musste ein Ingenieur die Zeichnung ansehen, sie verstehen, die Details erraten und dann alles mühsam manuell in einen Computer eingeben. Das war wie ein Dolmetscher, der stundenlang einen Dialekt in eine andere Sprache übersetzen musste, bei der jedes Wort eine strenge Grammatikregel hat. Ein kleiner Fehler, und das ganze Gericht war verdorben.

2. Die Lösung: Ein Team von Spezialisten (Die "Multi-Agenten")

Statt einen einzigen super-intelligenten Roboter zu bauen, der alles allein machen soll (was oft zu Fehlern führt, weil er überfordert ist), haben die Forscher ein Team aus vier verschiedenen Experten zusammengestellt. Man könnte es sich wie eine hochspezialisierte Küchenbrigade vorstellen:

• Der Beschreiber (Der "Kritische Beobachter"):
  Dieser Experte schaut sich die Skizze an und beschreibt sie laut und deutlich. "Ich sehe hier einen Tank, dort eine Pumpe und eine Leitung, die nach rechts führt." Er ist wie ein Künstler, der genau beschreibt, was er sieht, bevor er etwas tut.
• Der Extraktor (Der "Architekt"):
  Dieser nimmt die Beschreibung des ersten Experten und baut daraus ein Bauplan-Modell. Er ordnet die Dinge logisch an: "Okay, die Pumpe muss vor dem Tank stehen, nicht dahinter." Er erstellt eine saubere Liste aller Teile.
• Der Normalisierer (Der "Bürokrat"):
  Dieser ist der wichtigste für die Kompatibilität. Er sagt: "Moment, in deiner Zeichnung laufen drei Rohre direkt in eine Pumpe. Aber unser Computer-Kochtopf (der Simulator) kann nur ein Rohr pro Eingang akzeptieren." Dieser Experte fügt also automatisch Mischventile oder Zwischenstücke hinzu, damit die Regeln des Computers eingehalten werden. Er macht aus der "künstlerischen Skizze" einen "technischen Bauplan".
• Der Programmierer (Der "Handwerker"):
  Dieser Experte nimmt den sauberen Bauplan und schreibt den eigentlichen Code für den Computer. Er baut das Modell im Simulator (Aspen HYSYS) nach. Wenn der Computer sagt "Fehler!", analysiert dieser Experte den Fehler, korrigiert den Code und versucht es erneut.

3. Der "Koch-Check" (Validierung)

Zwischen jedem Schritt gibt es einen Qualitätskontrolleur.

• Schaut der Beschreiber wirklich das, was auf dem Bild ist?
• Stimmt der Bauplan mit der Zeichnung überein?
• Läuft das fertige Gericht im Simulator?

Wenn etwas schiefgeht, wird der Fehler sofort lokalisiert. War es der Beschreiber, der etwas falsch gesehen hat? Oder der Programmierer, der einen Befehl falsch geschrieben? Das System weiß genau, wo der Fehler liegt, und kann ihn beheben, ohne das ganze Projekt neu starten zu müssen.

4. Die Ergebnisse: Von der Skizze zum fertigen Modell

Die Forscher haben dieses Team an vier verschiedenen "Rezepten" getestet:

1. Ein einfaches Rezept: (Salzwasser reinigen) – Hier hat das Team alles perfekt gemacht. 100% Treffer.
2. Ein mittleres Rezept: (Kraftstoff reinigen) – Auch hier fast perfekt, selbst wenn die Zeichnung etwas unklar war.
3. Ein komplexes Rezept: (Öl-Verarbeitung) – Hier gab es kleine Missverständnisse bei den Rohren, aber das Gericht wurde trotzdem serviert.
4. Das Mega-Rezept: (Ein riesiges chemisches Werk mit vielen Rückführungen) – Das war die härteste Prüfung. Das Team hat es geschafft, ein funktionierendes Modell zu bauen, auch wenn die Zeichnung sehr überfüllt und verworren war.

Warum ist das so wichtig?

Stellen Sie sich vor, Sie könnten Ihre Handzeichnung auf ein Tablet werfen und sekundenschnell ein funktionierendes, sicheres und optimiertes chemisches Werk auf dem Bildschirm sehen.

• Kein mehr mühsames Tippen: Ingenieure müssen nicht mehr stundenlang Daten abtippen.
• Weniger Fehler: Der Computer liest die Zeichnung und prüft die Logik automatisch.
• Schnellere Innovation: Neue Ideen können sofort getestet werden, statt Tage zu warten, bis das Modell fertig ist.

Zusammenfassend:
Dieses Papier zeigt, wie wir künstliche Intelligenz nutzen können, um die Lücke zwischen einer krakeligen Handzeichnung und einem perfekten, lauffähigen Computermodell zu schließen. Es ist wie ein Team von genialen Übersetzern, Architekten und Handwerkern, die zusammenarbeiten, um aus einem einfachen Strichmännchen ein funktionierendes Kraftwerk zu bauen.

Technische Zusammenfassung

1. Problemstellung

Die Umwandlung von Prozessskizzen (Fließbildern) in ausführbare Simulationsmodelle stellt einen erheblichen Engpass im Bereich der Prozesssystemtechnik (PSE) dar. Dieser Prozess erfordert derzeit einen hohen manuellen Aufwand, spezifisches Expertenwissen für den jeweiligen Simulator und iterative Verfeinerungsschritte.

• Die Lücke: Bestehende Ansätze zur Diagramminterpretation (Computer Vision) enden meist bei der Extraktion von Graphen oder semantischen Darstellungen. Umgekehrt setzen Ansätze zur „Text-zu-Simulation"-Generierung strukturierte Eingaben voraus, nicht jedoch rohe visuelle Artefakte.
• Die Herausforderung: Prozessdiagramme enthalten oft implizite Informationen, unvollständige Beschriftungen oder nicht-standardisierte Symbole. Simulatoren wie Aspen HYSYS hingegen benötigen explizite, maschinenlesbare Definitionen von Einheiten, Strömungsverbindungen, Spezifikationen und Initialisierungsbedingungen. Die Lücke zwischen der visuellen Interpretation und der Erstellung eines simulator-kompatiblen Modells muss geschlossen werden.

2. Methodik: Multi-Agenten-System-Architektur

Das Paper stellt ein End-to-End-System vor, das auf einem koordinierten Multi-Agenten-Framework basiert, um Prozessdiagramme direkt in ausführbare Aspen HYSYS-Fließbilder zu konvertieren. Die Architektur ist in drei funktionale Schichten unterteilt, die durch einen zentralen Orchestrator gesteuert werden:

A. Schicht 1: Diagrammparsing und Interpretation

Diese Schicht wandelt das unstrukturierte visuelle Eingabebild in eine strukturierte Zwischenrepräsentation (Intermediate Representation, IR) um, die als gerichteter Graph $G=(V, E)$ (Einheiten und Ströme) definiert ist.

• Descriptor Agent (A1): Nutzt ein multimodales LLM (Gemini 3 Flash), um eine detaillierte textliche Beschreibung des Prozesses zu generieren. Es wendet einen „Self-Evaluation"-Mechanismus an, um die Konsistenz mit dem Bild zu prüfen.
• Extractor Agent (A2): Erstellt basierend auf dem Bild und der Beschreibung die JSON-basierte IR. Der Prozess erfolgt in zwei Durchläufen: Erst Identifikation der Einheiten, dann der Ströme und Verbindungen, um Topologie-Fehler zu minimieren.
• Normalization Agent (A3): Ein regelbasierter Agent, der die IR bereinigt. Er löst implizite Verbindungen auf (z. B. durch Einfügen von Mischern bei mehreren Einläufen) und konsolidiert komplexe Einheiten (z. B. Destillationskolonne mit Kondensator und Reboiler) zu simulator-kompatiblen Vorlagen.

B. Schicht 2: Simulation Model Synthesis

Diese Schicht übersetzt die IR in Python-Code, der über die COM-Schnittstelle (Component Object Model) mit Aspen HYSYS interagiert.

• Basis Agent (B1): Definiert den Simulationsfall (Fluid-Property-Package, Komponentenliste). Nutzt Retrieval-Augmented Generation (RAG), um extrahierte Materialnamen exakt mit der HYSYS-Datenbank abzugleichen.
• Instantiation Agent (B2): Erstellt das strukturelle Skelett des Fließbilds, indem er Knoten und Kanten des Graphen in HYSYS-Objekte übersetzt.
• Configuration Agent (B3): Stellt die topologischen Verbindungen her, indem er Ströme an die richtigen Ein- und Ausgänge der Einheiten anbindet.
• Execution Agent (B4): Führt das generierte Skript aus. Bei Fehlern analysiert ein LLM-Teil des Agents die Fehlerprotokolle und korrigiert den Code automatisch (Fixing-Loop).

C. Schicht 3: Multi-Level Validation

Validierung ist in den Workflow integriert, nicht nachgelagert.

• Beschreibungsvalidierung (A1.1): Ein separater Agent prüft, ob die generierte Beschreibung mit dem Originalbild übereinstimmt.
• Schema- und Prompt-Sicherungen: Erzwingen strukturierte JSON-Ausgaben und verhindern Halluzinationen.
• Ausführungsvalidierung: Der Simulator selbst dient als finaler Validator; nur ausführbare Modelle werden als erfolgreich betrachtet.

Modell-Strategie: Das System nutzt eine hybride Bereitstellung. Multimodale Aufgaben (Bildanalyse) laufen in der Cloud (Gemini 3 Flash), während die Code-Generierung und die proprietären Simulationsdaten lokal verarbeitet werden (Qwen2.5-Coder-7B und Qwen3-Coder-30B), um Datenschutz und Sicherheit zu gewährleisten.

3. Wichtige Beiträge

1. End-to-End-Architektur: Erstes System, das rohe visuelle Prozessdiagramme direkt in ausführbare Aspen HYSYS-Modelle umwandelt, ohne manuelle Zwischenstufen.
2. Strukturierte Zwischenrepräsentation (IR): Einführung einer graphbasierten IR, die als Brücke zwischen visueller Wahrnehmung und simulator-spezifischer Logik dient.
3. Multi-Agenten-Design: Demonstration, dass die Aufteilung komplexer Aufgaben auf spezialisierte Agenten (Interpretation, Synthese, Validierung) die Robustheit erhöht und Fehler lokalisierbar macht, im Gegensatz zu monolithischen LLM-Ansätzen.
4. Industrielle Relevanz: Der Fokus liegt auf Aspen HYSYS, dem Industriestandard, und nicht nur auf akademischen Prototypen.

4. Ergebnisse und Evaluation

Das System wurde an vier Fallstudien mit steigender Komplexität getestet:

1. Entsalzung (Einfach): Perfekte strukturelle Genauigkeit ($F1 = 1.00$) in allen Metriken (Einheiten, Ströme, Verbindungen, Materialien).
2. Merox-Veredlung (Mittel): Hohe Genauigkeit, erfolgreiche Rekonstruktion impliziter Verbindungen (z. B. zwischen Waschtank und Reaktor).
3. Atmosphärische Destillation (Komplex): Hohe Genauigkeit, leichte Abweichungen bei Seitenströmen, die auf Limitationen der HYSYS-Template-Schnittstelle zurückzuführen sind, nicht auf Interpretationsfehler.
4. Aromatenproduktion (Industrie-Skala, sehr komplex): Hohe strukturelle Treue ($F1 \approx 0.98$). Das System bewältigte dichte Rückführschleifen und komplexe Netzwerke erfolgreich, obwohl minimale Verbindungsfehler in stark verzweigten Bereichen auftraten.

Ablationsstudien:

• Das Entfernen des Normalisierungsagents oder das Zusammenfassen der Coding-Agenten führte zu signifikanten Genauigkeitsverlusten, besonders bei komplexen Diagrammen.
• Das Deaktivieren von RAG führte bei Mischungen zum kompletten Scheitern der Initialisierung, was die Notwendigkeit der Retrieval-basierten Komponentenzuordnung unterstreicht.
• Modellvergleich: Gemini 3 Flash zeigte überlegene Leistung im Vergleich zu Open-Weight-Alternativen (Qwen 3.5, Qwen 3-VL), insbesondere bei der räumlichen Reasoning und der Vermeidung von Halluzinationen bei dichten Annotationen.

5. Bedeutung und Ausblick

Die Studie beweist die Machbarkeit einer vollautomatischen „Skizze-zu-Simulation"-Pipeline. Sie zeigt, dass die größte Herausforderung nicht nur die visuelle Erkennung ist, sondern die Übersetzung von mehrdeutigen visuellen Strukturen in die strengen logischen und objektorientierten Constraints kommerzieller Simulatoren.

Limitationen und zukünftige Arbeiten:

• Das System ist empfindlich gegenüber Diagrammqualität (verdeckte Elemente, dichte Textüberlagerungen).
• Die Abhängigkeit von spezifischen Simulator-Schnittstellen (HYSYS COM) erschwert die Portabilität auf andere Plattformen.
• Zukünftige Arbeiten sollen sich auf robustere Handhabung von gescannten, unordentlichen Dokumenten, simulator-agnostische Zwischenformate und verbesserte Selbstkorrekturmechanismen konzentrieren.

Zusammenfassend stellt dieses Framework einen bedeutenden Schritt hin zur Digitalisierung und Automatisierung von Prozesssystemen dar, indem es die Lücke zwischen menschlicher Entwurfsgestaltung (Skizzen) und maschineller Ausführung (Simulation) schließt.