P4-DevOps – Knowledge Based Generative Engineering (KBGE)

Praktiken & Prozesse, KI

Mit P4-DevOps adressieren wir zwei  große Herausforderungen in der Produktentwicklung:

  1. Den Nachweis der Prozesskonformität bei der Einhaltung aller relevanten Prozessnormen und gesetzlichen Regelwerken. Dafür müssen die Prozessnormen auf den Entwicklungsprozess abgebildet werden (Traceability) und als Nachweise müssen während der Produktentwicklung Dokumente erstellt und abgelegt werden.
  2. Die effektive Einbindung von „Generativer KI“ in den Entwicklungsprozess zur Verbesserung, Automatisierung und Beschleunigung der Produktentwicklung. Hierfür müssen der Entwicklungsprozess und seine Artefakte komplett digitalisiert werden.

Den ersten Punkt adressieren wir in P4 mit der Einführung von P4-DevOps Multiple Process Conformity (MPC) durch Conformity Mapping. Wir haben uns bewusst für offene, non-binäre Datenformate, wie JSON, YAML und Markdown entschieden, damit Ihre Daten weiterhin Ihnen gehören und Sie diese beliebig nutzen können (Kein Vendor-Lock-in). Außerdem lassen sich dadurch alle Dokumente  und Datenelemente in Git-Repositories ablegen und wie Software-Code versionieren, vergleichen (diff) und vereinigen (merge). Wir nennen dies ProcessAsCode.

Der ProcessAsCode-Ansatz hilft uns auch bei der zweiten Herausforderung: KIs (LLMs) verstehen Dokumente aus Klartext außerordentlich gut und generieren diese mit hoher Qualität und Präzision (bei kleinen definierten Aufgaben und entsprechenden Prompts). Daher sind textbasierte Daten und Programmiersprachen heute das bevorzugte Einsatzfeld von LLMs. In P4 nutzen wir non-binäre Datenformate daher nicht nur für Prozessbeschreibungen und Produktdokumente, sondern auch zur Beschreibung des Produkts und seiner einschränkenden und beschreibenden Regeln. Dafür nutzt P4 die Systembeschreibungssprache SysML v2 aus dem Bereich des Model-based Systems Engineering (MBSE). Aus unserer Sicht eine ideale Ergänzung!

Der Clou für die Beschleunigung und Automatisierung ist die Nutzung des P4-Vorgehensmodells (P4-Activity Workflow), das auf der „wissensbasierten Produktentwicklung“ basiert (Knowledge-based Product Development, KBPD). Neben einem klaren iterativ-inkrementellen Vorgehensmodell zum Wissens- und Erkenntnisgewinn, hat P4 als zentralen Treiber dafür das Konzept der Knowledge Gaps (K-Gaps) eingeführt. Dadurch wird sichergestellt, dass der Lösungsraum zuerst genügend aufgeweitet wird (divergent Exploration, Set-based Concurrent Engineering) und erst dann, gemäß den Einschränkungen und Qualitätsattributen zu einer oder wenigen Design-Optionen eingeengt wird (convergence).

Die Generierung von Design-Optionen (aka System-Concepts) wird aus folgenden Datenquellen gespeist:

  • externe öffentlich zugängliche Datenbanken mit Design-Prinzipien, Designvorschlägen von Bauteilherstellern, Materialdaten, Fertigungstechnologien, etc.
  • zugekaufte Datenquellen mit Materialeigenschaften, Daten über Lebensdauer und Alterung von Bauteilen und Materialien, Simulationsdaten und Tools.
  • interne Daten aus früheren Produktentwicklungen, sowie Ergebnisse von Simulationen und Experimenten. Genau diese Daten machen den Erfahrungsschatz des Unternehmens aus und sichern diesem einen Vorsprung gegenüber Mitbewerbern. Hierfür müssen diese Daten aus den Köpfen der Ingenieure wiederverwendbar abgelegt werden.

Einschub: Menschliche Schwächen, die Hindernisse in der Produktentwicklung darstellen:

  • Menschen horten Wissen, um sich gut zu fühlen („Ich weiß das besser“) und sich sicher zu fühlen („Ich bin unersetzlich“). Wenn eine Mitarbeiterin das Unternehmen verlässt, ist damit auch ihr Erfahrungsschatz verloren.
  • Menschen haben ein begrenztes Gedächtnis (in Relation zu Computern). Die heutigen Komplexität in der Produktentwicklung macht es für einen einzelnen Ingenieur unmöglich „alles“ zu wissen.
  • Wir alle sind Problemlöser. Menschen denken gerne in Lösungen und engen den Lösungsraum zu früh ein, häufig ohne das Problem vollständig verstanden zu haben.
  • Menschen wollen kreativ sein, nicht dokumentieren. Das Dokumentieren wird meist als Belastung und Hindernis empfunden, und daher  oft auf „später“ verschoben. „Später“ wird es aber nicht besser, sondern noch schlimmer.

Für alle genannten Punkte hilft die Unterstützung oder Vollautomation durch KI.

Die Vision: Die vollautomatische Systementwicklung

Bei der Betrachtung des P4-Workflows fällt auf, dass er nicht nur sehr gut für die Bearbeitung durch Menschen geeignet ist, sondern auch für KI-Agenten. Die Idee dabei ist, dass die Agenten gesteuert durch ihre Prompts und Ausführungsregeln, auch die Einschränkungen vorgegeben bekommen, die durch regulatorische Bestimmungen oder vorgegebenen Systemeigenschaften bestimmt werden (z.B. Kosten, Masse, Ausschlüsse von Materialien und Herstellungsverfahren). Außerdem helfen die Knowledge-Gaps und ihr Risikoeinfluss, die Reihenfolge der Simulationen, Untersuchungen und deren Bewertungen festzulegen. Dadurch lässt sich schneller entscheiden, ob die betrachtete Design-Optionen verworfen oder weiter optimiert werden sollte. Als erfreulichen „Nebeneffekt“ erstellen KI-Agenten gleich die benötigte Dokumentation (nach Template-Vorgabe) und erzeugen dadurch Nachvollziehbarkeit, Verständlichkeit und sie befüllen unsere Knowledge-Base.

Der Ablauf

  1. Menschen definieren die Produktvision, die Zielmärkte und Nutzer.
  2. Menschen definieren die Randbedingungen.
  3. Der Requirement-Agent übersetzt Stakeholder Needs in System-Requirements.
  4. Der Design-Agent bildet mehrere Lösungsoptionen (System-Concepts), inkl. der Zerlegung in Module und Schnittstellen. Hierfür nutzt er externes Wissen (Internet, Datenbanken) und internes Wissen aus der Knowledge-Base.
  5. Der Risk-Agent bewertet die Lösungsoptionen, erstellt eine Liste von Knowledge-Gaps und priorisiert diese anhand ihres Risk-Impact.
  6. Spezialisierte Tool-Agenten führen Simulationen zum Schließen der Knowledge-Gaps durch.
  7. Design- und Risk-Agent bewerten die Ergebnisse gegen die Randbedingungen und entscheiden über Verwerfen oder Verfeinern
  8. Die besten Lösungsoptionen werden den Menschen zur Entscheidung vorgelegt.
  9. Die entworfene Architektur aus Modulen und Interfaces wird nun Modul für Modul optimiert. Ggf. sind weitere „Systemschleifen“ notwendig, wenn die Moduloptimierungen nicht erfolgreich sind.

Herausforderungen

  • Die Voraussetzung für einen automatischen Ablauf ist die klare und eindeutige Beschreibung der Funktionen und Randbedingungen (Schritt 2 der obigen Liste). Die Randbedingungen unterteilen sich in „harte“ Constraints (verpflichtende Elemente, Fähigkeiten und Eigenschaften; Ausschlüsse und Grenzwerte), sowie „weiche“ Qualitätsattribute (nicht-funktionale Eigenschaften, NFRs), die nach Vorgabe auszubalancieren oder zu optimieren sind. Hierzu zählen Herstellkosten, Materialkosten, Gewicht, Robustheit, Langlebigkeit, Reparierbarkeit, Energie-Effizienz. Zur Beschreibung dieser Regeln nutzt P4 SysML v2, das sowohl grafisch als auch in Textform dargestellt werden kann. Die eigentliche Herausforderung besteht aber darin, dass der Product-Owner sich auf einen bestimmten Satz an Regeln festlegt, wobei gerade zu Beginn des Systementwurfs Bereichsangaben (Ranges) vorteilhaft und möglich sind. Wichtig ist, dass für Schritt 7 die nötigen Prioritäten oder Gewichte definiert sind, um Lösungsoptionen gegeneinander zu bewerten.
  • Für die Generierung der Lösungsoptionen in Schritt 4 benötigt der Design-Agent umfassenden Zugriff auf Referenzdesigns und deren Eigenschaften. In der Regel ist zu Beginn auch die interne Knowledge-Base noch nicht ausreichend gefüllt.
  • In Schritt 6 werden geeignete Simulationen oder anderweitige Analyse-Werkzeuge benötigt. Z.B. kann das dynamische Systemverhalten durch die Simulation von Finite-State-Machines (FSM) erfolgen. Natürlich wird das Bauen und Testen von Prototypen ab einem bestimmten Design-Reifegrad notwendig, was die Design-Iterationen verlangsamt.

Modul-Optimierung

Zur Optimierung von Lösungsoptionen auf Modulebene lassen sich weitere moderne Techniken einsetzen, z.B. das Logic-based Computational Engineering Model (LCEM) für das Modul-Design, die Simulation, der Bewertung der Ergebnisse, des Verwerfens oder Verbessern von Optionen. Durch den Einsatz von generativen Fertigungsmethoden werden darüber hinaus neue, fraktale Designs möglich, die an natürlich gewachsene Strukturen erinnern. Ein gutes Beispiel dafür ist das Raketentriebwerk von Leap71. Denkbar sind auch z.B. analoge Chip-Designs, wobei der Chip-Compiler alle Eigenschaften des Halbleiters berechnen, simulieren und optimieren kann.