Mit P4-DevOps adressieren wir zwei große Herausforderungen in der Produktentwicklung:
- 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 Dokumente erstellt und abgelegt werden.
- 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: KI (LLMs) verstehen Dokumente aus Klartext außerordentlich gut und generieren diese mit hoher Qualität und Präzision (mit 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 (insbesondere Experten) denken gerne in (ihnen bekannten) Lösungen. Menschen engen den Lösungsraum zu früh ein.
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.
Der Ablauf
- Menschen definieren die Produktvision, die Zielmärkte und Nutzer.
- Menschen definieren die Randbedingungen.
- Der Requirement-Agent übersetzt Stakeholder Needs in System-Requirements.
- 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.
- Der Risk-Agent bewertet die Lösungsoptionen, erstellt eine Liste von Knowledge-Gaps und priorisiert diese anhand ihres Risk-Impact.
- Spezialisierte Tool-Agenten führen Simulationen zum Schließen der Knowledge-Gaps durch.
- Design- und Risk-Agent bewerten die Ergebnisse gegen die Randbedingungen und entscheiden über Verwerfen oder Verfeinern
- Die besten Lösungsoptionen werden den Menschen zur Entscheidung vorgelegt.
Zur Optimierung von System-Concepts lassen sich weitere moderne Techniken einsetzen, z.B. das Logic-based Computational Engineering Models (LCEM) zur Modul-Simulation, der Bewertung der Ergebnisse, des Verwerfens oder Verbessern von Optionen.