Assistent für Systems Engineering & Anforderungsmanagement (MBSE)

Komplexe Produkte (Fahrzeuge, Maschinen, Flugzeuge, Medizin- und Energiesysteme) haben tausende Anforderungen, die über Dokumente, Anforderungswerkzeuge und Systemmodelle verteilt sind. Sie eindeutig, nachverfolgbar und konsistent zu halten, ist langsame Expertenarbeit. Ein LLM-Assistent entwirft und formuliert Anforderungen um, markiert Qualitätsmängel, schlägt Trace-Links vor und erzeugt oder erklärt Modellelemente, während der Ingenieur Autor der Unterlagen bleibt. Typischer Nutzen: schnellere Reviews und weniger spät entdeckte Spezifikationsfehler, nicht autonomes Entwerfen.

Problem & Nutzen

• Heute: Anforderungen kommen als Kunden-PDFs, Normen und E-Mails an. Ingenieure übertragen sie von Hand in ein Anforderungswerkzeug (IBM-DOORS-Familie, Siemens Polarion, Jama Connect, Codebeamer, PTC Windchill/Integrity), verknüpfen sie mit Modellelementen und Testfällen und prüfen sie gegen Richtlinien wie den INCOSE Guide to Writing Requirements [1]. Spät gefundene Mängel (Mehrdeutigkeit, fehlende Verifikationsmethode, widersprüchliche Werte) sind teuer.
• KI-Nutzen: (1) Extraktion von Anforderungskandidaten aus langen Dokumenten, (2) regel- und LLM-basierte Qualitätsprüfungen (Mehrdeutigkeit, Passiv, vage Begriffe, nicht atomare Sätze, fehlende Einheiten), (3) Umformulierung in Vorlagen wie EARS [2], (4) vorgeschlagene Trace-Links und Abdeckungslücken, (5) Auswirkungsanalyse bei Änderungsanträgen, (6) Zugriff auf das Modell in natürlicher Sprache („Welche Komponenten setzen Anforderung X um?“).
• Belege: Hersteller und INCOSE-Arbeitsgruppen berichten von Produktivitätsgewinnen in Pilotprojekten, uns ist aber keine neutrale, großangelegte Studie mit quantifiziertem Nutzen bekannt; messen Sie an Ihrer eigenen Ausgangsbasis.
• Wegbereiter: SysML v2 (OMG, mit textueller Notation und einer standardisierten REST/JSON-API) macht Modelle maschinenlesbar und für LLMs viel leichter les- und schreibbar als das rein diagrammbasierte SysML v1 [3][4].

Varianten

• Reiner Anforderungsassistent: Qualitätsprüfung, Umformulierung und Trace-Vorschläge in einem vorhandenen RM-Werkzeug.
• MBSE-Assistent: erzeugt/bearbeitet SysML-v2- oder Capella-Elemente, prüft die Zuordnung von Modell zu Anforderung.
• Ausschreibung zu Spezifikation: Compliance-Matrix und Anforderungsextraktion aus Anfragen (siehe DOC-015).
• Variante für Sicherheit/Regulierung: verknüpft Anforderungen mit Gefährdungen und Normen (ISO 26262, IEC 62304, DO-178C, EN 50126); der Assistent bereitet Nachweise vor, Menschen zeichnen ab.
• KMU / Start-up: schlanker Workflow mit Markdown/ReqIF + Git und einem LLM-Review-Bot.
• Verteidigung/Luftfahrt: gleiche Architektur, typischerweise vom Netz getrennt (Air-Gap); es gelten Exportkontrollauflagen.

So funktioniert es

1. sources (PDF/Word/ReqIF, standards, RM tool, SysML v2 / Capella model)
2. parsing + chunking (layout-aware, keep clause IDs)
3. indexing (embeddings + keyword + model-element graph)
4. LLM tasks: extract / rewrite (EARS) / quality-check / link / summarise / draft model text
5. deterministic validators (rule engine, SysML v2 parser/API, unit & range checks)
6. proposal queue in RM/MBSE tool (diff, rationale, source citation)
7. engineer review & approval
8. baseline, change record, audit log

• Retrieval über das Modell: Anforderungen, Blöcke, Ports und Schnittstellen bilden einen Graphen; hybrides Retrieval aus Vektorsuche und Graph liefert fundierte Antworten mit Quellenangaben.
• Erzeugung von Modelltext: LLMs schreiben textuelles SysML v2; Parser und API prüfen Syntax und Semantik, ungültige Ausgaben werden zur Korrektur zurückgegeben (Generieren-Prüfen-Schleife).
• Werkzeugzugriff: Agenten rufen RM-/MBSE-Werkzeuge über APIs oder MCP-Server auf [5]; Schreibzugriff ist auf den Status „Vorschlag“ begrenzt.
• Mensch-in-der-Schleife (Human-in-the-Loop): Jede Änderung ist ein Vorschlag; Freigabe, Baselining und Verifikationsabnahme bleiben bei namentlich benannten Ingenieuren.

Datenaufbereitung

Typische Quellen sind Anforderungsspezifikationen in Word/PDF/ReqIF, Kunden- und Normdokumente, das RM-Werkzeug (DOORS, Polarion, Jama), SysML- oder Capella-Modelle sowie Review-Kommentare in Mails oder Tickets. In einem KMU liegt vieles davon auf Dateiablagen und in alten Projektordnern, teils als Scans oder Tabellen mit uneinheitlichen IDs.

Typische Lücken: doppelte und unversionierte Dokumentkopien, Anforderungen ohne eindeutige IDs oder Trace-Links, gemischte Sprachen und Terminologie, gescannte Kundenspezifikationen, keine markierte „freigegebene Baseline“ und offener Zugriff auf vertrauliche Projekte.

Schritte der Aufbereitung: - Quellen pro Projekt inventarisieren und priorisieren; nur freigegebene Baselines verwenden (siehe PREP-001, PREP-002). - Scans und Altformate per OCR/Parsing umwandeln und dabei Klausel-IDs und Tabellen erhalten (PREP-006, PREP-007, DOC-014). - Ordner neu strukturieren und Metadaten wie Projekt, Version, Status ergänzen (PREP-009, PREP-010). - Ein Glossar mit Abkürzungen (PREP-015) und einen Referenzsatz gut formulierter Anforderungen (PREP-016) zusammenstellen. - Zugriffsrechte pro Projekt vor der Indexierung prüfen (PREP-023).

Werkzeuge: Docling oder ähnliche Parser, ReqIF-Export, ein Vektorindex. Rechnen Sie damit, dass etwa 40-50 % des Gesamtaufwands in die Datenaufbereitung fließen; der Modellteil ist der kleinere Anteil. Prüfen Sie die Bereitschaft mit GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg B, weil der Nutzen aus eigenen Prüfungen gegen Ihren Styleguide und Ihre Werkzeuglandschaft entsteht und die KI-Module der Hersteller noch jung sind; nutzen Sie stattdessen Zusatzmodule aus Weg A, wenn Sie bereits Polarion, Jama oder Codebeamer betreiben und das Modul passt.
• Großunternehmen: Weg C, weil Anforderungen und Systemmodelle Geschäftsgeheimnisse sind (oft exportkontrolliert) und eine gemeinsame interne LLM-Plattform viele Engineering-Anwendungsfälle bedient.
• Entwickler: Weg B, weil ReqIF-/REST-Export, ein Agent-Framework und die SysML-v2-API den Bau einer validierten Vorschlags-Pipeline beschleunigen.

Weg A — Kaufen (Standardsoftware)

• RM-/ALM-Plattformen mit KI-Funktionen: IBM Engineering Requirements Management DOORS Next, Siemens Polarion und Teamcenter, Jama Connect (Berater für Anforderungsqualität), Codebeamer (PTC), Visure Requirements (ES, EU), Innoslate (SPEC Innovations). Der Funktionsumfang ändert sich schnell; prüfen Sie aktuelle KI-Module und Bedingungen zur Datennutzung.
• MBSE-Werkzeuge: Dassault CATIA Magic / Cameo (SysML-v2-Unterstützung), Ansys SCADE und Systems-Werkzeuge, Eclipse Capella (Open Source, ursprünglich von Thales, FR) mit dem Obeo-Ökosystem (FR), Sparx Enterprise Architect, PTC Windchill Modeler.
• Wählen Sie A, wenn: Sie bereits eines dieser Werkzeuge betreiben; Assistenten der Hersteller sitzen am nächsten an Daten und Berechtigungsmodell.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Modelle: führende Reasoning-LLMs mit langem Kontext und strukturierten Ausgaben (Claude, GPT, Gemini; Mistral als EU-Anbieter), in EU-Regionen (z. B. Azure OpenAI EU, Google Vertex EU, AWS Bedrock Frankfurt).
• Stack: ReqIF-/REST-Export aus dem RM-Werkzeug, Dokument-Parsing (Docling, Mistral OCR), hybrider Index (OpenSearch, pgvector), Orchestrierung mit einem Agent-Framework, SysML-v2-API (Pilotimplementierung von Systems-Modeling) zur Validierung, Ergebnisse werden als Vorschläge zurückgeschrieben [4].
• Wählen Sie B, wenn: Sie werkzeugübergreifend eigene Prüfungen benötigen (Styleguide des Unternehmens, Domänenontologie).

Weg C — Selbst betreiben (Open Source)

• Modelle: Open-Weight-Reasoning-/Code-LLMs (Qwen3 / Qwen3-Coder, Mistral Large / Devstral, gpt-oss, Llama-Familie) über vLLM; Embeddings wie bge-m3 oder Qwen3-Embedding.
• Werkzeuge: Eclipse Capella [6], SysML-v2-Pilotimplementierung und Jupyter-Kernel [4], Syside/andere SysML-v2-Parser, Neo4j oder Apache AGE für den Modellgraphen, Docling fürs Parsing.
• Hardware: HW3 (eine GPU mit 48-141 GB) für ein Modell mit ca. 30-120 Mrd. Parametern und langem Kontext; HW4 für mehrere parallele Teams. Erforderlich für eingestufte, exportkontrollierte oder geheimnisgeschützte Projekte.

Weg D — Eigenes Training

Ein mittelgroßes Modell wird mit dem freigegebenen Anforderungskorpus der Organisation, dem Styleguide und angenommenen/abgelehnten Review-Kommentaren (Tausende Einträge) feingetunt, um die Einhaltung von Vorlagen und das Fachvokabular zu verbessern, oder um einen Klassifikator für die Vorhersage von Trace-Links zu trainieren. Lohnt sich meist erst, wenn RAG und Validatoren an ihre Grenzen stoßen; kuratieren Sie die Daten (nur freigegebene Baselines) und wahren Sie die Projektvertraulichkeit.

Stand der Technik (2026)

• Textuelles SysML v2 und seine API sind der entscheidende Wandel: LLM-Erzeugnisse lassen sich durch einen Parser statt per Augenschein validieren, und Werkzeughersteller bauen Assistenten darauf auf. Forschung zu LLM-erzeugtem SysML und zur Prüfung der Anforderungsqualität zeigt vielversprechende, aber uneinheitliche Ergebnisse; syntaktische Gültigkeit ist mit Korrekturschleifen erreichbar, semantische Korrektheit (richtige Architektur, richtige Zuordnung) nicht.
• Prüfung der Anforderungsqualität ist die reifste Aufgabe: Regelmaschinen plus LLM-Erklärungen treffen INCOSE-/EARS-Regeln gut; die Extraktion aus langen Ausschreibungen funktioniert mit menschlicher Prüfung.
• Rückgewinnung von Trace-Links mit Embeddings und Rerankern eignet sich für Vorschläge; die Präzision sinkt über Abstraktionsebenen hinweg, daher brauchen Vorschläge eine Bestätigung.
• Grenzen und Fehlerbilder: halluzinierte Anforderungen oder erfundene Zahlenwerte; stiller Verlust der Unterscheidung „shall/should“; plausible, aber falsche Zuordnungen; übersehene dokumentübergreifende Konflikte; Prompt Injection durch Lieferantendokumente; Übervertrauen („Automation Bias“) in Reviews. LLMs ersetzen weder Verifikation, Sicherheitsanalyse noch Abwägungen auf Systemebene.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (llm-reasoning + vector-db + knowledge-graph + ocr-docparse): DOC-015 Ausschreibungs- analyse, CODE-015 Anforderungen aus Stakeholder-Eingaben, DOC-013 technische Zeichnungen, KNOW-020 Teilewiederverwendung, LANG-022 technische Dokumentation.
• Nachgelagert: SCI-025 FMEA-/8D-Assistent (Verknüpfung von Gefährdungen und Fehlern), CODE-020 sicherheitskritische Software (Rückverfolgbarkeit von Anforderung zu Code zu Test), SCI-024 CAD-Copilot (Geometrie aus Anforderungen).
• Ein einziger selbst betriebener LLM-Server (HW3) plus ein hybrider Index kann all diese Fälle bedienen.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen für Aktivierung plus Change Management; Lizenzen pro Nutzer/Modul.
• Weg B: 3-6 Monate für einen produktiven Assistenten mit RM-Werkzeug-Integration und Evaluierungssatz.
• Weg C: 4-9 Monate inkl. GPU-Betrieb, Sicherheitshärtung und Evaluierung.
• Kostentreiber: Integration mit älteren RM-Werkzeugen, Aufbau eines Evaluierungssatzes, Inferenz mit langem Kontext, Prüfaufwand.
• Kennzahlen: Anteil der angenommenen/bearbeiteten KI-Vorschläge, Fehlerdichte der Anforderungen im Review, Durchlaufzeit des Reviews, Trace-Abdeckung (Anforderung zu Entwurf zu Test), Dauer der Auswirkungsanalyse bei Änderungen, in spätere Phasen durchgerutschte Fehler, Halluzinationsrate auf einem Referenzsatz.

Menschen & Veränderung

Beziehen Sie zuerst Geschäftsführung und Abteilungsleitung ein: Sie legen Umfang, Budget und die Regel fest, dass KI-Ausgaben immer nur ein Vorschlag sind. Holen Sie IT und die Datenverantwortlichen des RM-Werkzeugs und der Projektablagen früh für Exporte, Konten und Zugriffsrechte dazu; die IT-Sicherheit muss den Umgang mit vertraulichen oder exportkontrollierten Inhalten vor jedem Cloud-Weg prüfen (GUIDE-013).

Betriebsrat: meist abhängig vom Einzelfall. Der Assistent selbst bewertet keine Personen, aber Freigabeprotokolle und nutzerbezogene Nutzungsdaten machen das System objektiv zur Verhaltensüberwachung geeignet, daher greift häufig §87(1) Nr. 6 BetrVG; in jedem Fall ist der Betriebsrat nach §90(1) Nr. 3 rechtzeitig zu unterrichten und kann nach §80(3) einen Sachverständigen hinzuziehen. Beginnen Sie die Gespräche vor dem Pilotbetrieb (GUIDE-004).

Datenschutzbeauftragte(r): Anforderungsdokumente enthalten Namen von Autoren und Prüfern, binden Sie daher die/den Datenschutzbeauftragte(n) für den AVV und eine kurze DSFA-Vorprüfung ein (GUIDE-005).

KI-Kompetenz: Unterstützen Sie die Ingenieure mit einer kurzen Schulung zu Grenzen, halluzinierten Klauseln und Verifikation (GUIDE-006). Wählen Sie eine Pilotgruppe von 3-5 Ingenieuren in einem Projekt und lassen Sie sie die Fürsprecher sein (GUIDE-008, GUIDE-009). Typische Sorgen sind Kompetenzverlust und Haftung; begegnen Sie ihnen, indem Freigabe, Baselining und Abnahme bei namentlich benannten Ingenieuren bleiben.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Der Assistent selbst ist normalerweise ein minimales Risiko (internes Produktivitätswerkzeug, keine Anwendung nach Anhang III); die Pflicht zur KI-Kompetenz (Art. 4) gilt [7]. Das Produkt, das entwickelt wird, kann Hochrisiko sein (z. B. Sicherheitskomponente, Medizinprodukt, Maschinen nach Anhang I) und braucht eine eigene Konformitätsbewertung; der Assistent darf KI-erzeugte Inhalte in diesem Verfahren nicht verbergen. Reine Verteidigungssysteme fallen nicht in den Anwendungsbereich der Verordnung, Dual-Use möglicherweise schon. Keine Praxis nach Art. 5 ist betroffen.
• Funktionale Sicherheit und Normen: ISO 26262, IEC 61508, IEC 62304, DO-178C/DO-330 erwarten qualifizierte Werkzeuge oder unabhängige Verifikation; behandeln Sie LLM-Ausgaben als nicht vertrauenswürdig und halten Sie Review- und Verifikationsnachweise unabhängig vom Werkzeug.
• DSGVO: meist keine personenbezogenen Daten; Namen von Autoren/Prüfern und Lieferantenkontakte in Dokumenten zählen dazu; nutzen Sie einen AVV und EU-Hosting, wo Cloud-APIs zum Einsatz kommen.
• Geistiges Eigentum und Exportkontrolle: Spezifikationen sind Geschäftsgeheimnisse und können exportkontrolliert sein (Dual-Use, Inhalte im Sinne von ITAR/EAR); bevorzugen Sie Weg C oder vertraglich zugesichertes EU-Hosting ohne Datenspeicherung.
• Sicherheit: Prompt Injection über Dokumente; beschränken Sie Agenten auf Lesezugriff plus Schreiben von Vorschlägen.
• Gegenmaßnahmen: Quellenangabe pro Vorschlag, Validatoren, Audit-Log, versionierte Baselines, erneuter Lauf des Evaluierungssatzes bei jedem Modellwechsel.

Erste Schritte

1. Wählen Sie ein Teilsystem und exportieren Sie dessen Anforderungen (ReqIF/CSV) samt verknüpftem Modell und Tests.
2. Lassen Sie Qualitätsprüfungen (Regeln + LLM) über 200-500 bestehende Anforderungen laufen; vergleichen Sie mit früheren Review-Befunden.
3. Bauen Sie einen Referenzsatz aus 50-100 geprüften Anforderungen und Trace-Links, um Modelle und Prompts zu vergleichen.
4. Erproben Sie das Zurückschreiben „nur als Vorschlag“ im RM-Werkzeug; protokollieren Sie pro Vorschlag Annahme/Bearbeitung/Ablehnung.
5. Wenn Sie SysML v2 nutzen, ergänzen Sie vor der Skalierung die Generieren-Prüfen-Schleife gegen Parser/API.

Quellen

1. INCOSE — Guide to Writing Requirements — https://www.incose.org/products-and-publications/se-guide-to-writing-requirements
2. Alistair Mavin et al. — EARS (Easy Approach to Requirements Syntax) — https://alistairmavin.com/ears/
3. OMG — Systems Modeling Language (SysML) v2 specification — https://www.omg.org/spec/SysML/2.0/
4. Systems Modeling — SysML v2 Release (pilot implementation, API services, Jupyter) — https://github.com/Systems-Modeling/SysML-v2-Release
5. Model Context Protocol — https://modelcontextprotocol.io
6. Eclipse Capella — Open source MBSE solution (Arcadia method) — https://eclipse.dev/capella/
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. IBM — Engineering Requirements Management DOORS Next — https://www.ibm.com/products/doors-next
9. Siemens — Polarion ALM — https://plm.sw.siemens.com/en-US/polarion/