## TL;DR

SysML v2 erhöht **Formalisierung** und **Präzision**. Das bringt uns, erkenntnistheoretisch gedacht, näher an belastbare Aussagen über Systeme: Wir können den Gegenstand aus mehreren Perspektiven genauer beschreiben und prüfen. Die Komplexität bleibt, wird aber bearbeitbarer: durch klare Abstraktionsebenen, nachvollziehbare Beziehungen und maschinenprüfbare Aussagen. Der Preis sind eine steile Lernkurve und mehr Verantwortung in der Tool‑Schicht. Entscheidend bleibt ein gemeinsames Vokabular und menschenlesbare Repräsentationen aus dem Modell.

- Wo erkennst du diese Muster wieder?
- Wo stellst du dir einen entscheidungszentrierten Ansatz hilfreich vor?
- Welche Erfahrungen hast du mit ähnlichen Konzepten gemacht?

## Warum SysML v2 für mich ein Schritt Richtung „Wahrheit“ ist

Ingenieurarbeit ist Annäherung: Je präziser wir beschreiben, desto besser werden unsere Fragen und die deren Antworten. SysML v2 liefert dafür die Mittel: explizite Typen, Beziehungen, Constraints, API‑Zugriff. Damit verschiebt sich der Schwerpunkt vom Zeichnen zur Erkenntnisarbeit: weniger Deutungslücken, mehr prüfbare Behauptungen. Wichtig bleibt die Bodenhaftung: SysML v2 bringt uns näher an robuste Aussagen, während die Realität selbst der Maßstab bleibt.

## Abstraktion: Gewinn und Preis

Abstraktion hilft, große Systeme zu strukturieren. Gleichzeitig schafft sie Abstand zu darunter liegenden Details. In der Software ist das normal. Im Systems Engineering ist der Abstand naturgemäß größer, weil unsere „Laufzeit“ die Welt ist (Physik, Nutzung, Lieferkette, Zeit). Mein Punkt: SysML v2 begrenzt das Black‑Box‑Risiko, indem Intention, Annahmen, Randbedingungen und Evidenz sichtbar und prüfbar gemacht werden.

## Product‑Features, Eigenschaften und Capabilities

In meiner Denktradition beginne ich beim Produktversprechen:

- **Product‑Feature**: technologie‑neutral aus Kundensicht („Was soll der Nutzen sein?“).
- **Eigenschaften** (Leistung, Quality‑ und Regulatory‑Aspekte): messbare Erwartungen und Pflichten.
- **Capability**: ergibt sich aus der Kombination von Product‑Feature und Eigenschaften. Sie beschreibt, wozu das Produkt in der Welt befähigt ist.

Hinweis zur Benennung im Modell: Weil „feature“ in SysML v2 bereits anders belegt ist, können ProductFeature, PerformanceAttribute, QualityAttribute und RegulatoryAttribute als eigene Domänen‑Typen verwendet werden. Das hält die Semantik sauber.

### Beispiel Heckklappe

- **Product‑Feature**: „Heckklappe öffnen“
- **Eigenschaften** (Auszug): „Öffnungszeit ≤ 1,5 s“, „MTBF ≥ … Stunden“, „Einklemmschutz gemäß gesetzlichen Vorgaben“
- **Capability**: „Schnelles, sicheres Öffnen der Heckklappe unter definierten Bedingungen“

## Von Product‑Feature zu Funktion und Varianten

Aus Product‑Feature + Eigenschaften leiten sich Funktionen ab (nicht mehr technikneutral). Für die Heckklappe z. B.:

- Mechanisch per Griff
- Elektrisch per Fernbedienung
- „Kick“-Sensor unter dem Stoßfänger

Varianten bleiben beherrschbar, wenn Schnittstellen stabil sind und Unterschiede parametrisiert werden, statt Klassen zu vervielfachen. So entstehen Kataloge (Product‑Features, Eigenschaften, Funktionen), aus denen sich Konfigurationen zusammenstellen lassen. Wie Bibliotheken in der Software.

## Vier Ebenen im SysML‑v2‑Modell

1. **Intent‑Schicht**: ProductFeature, Eigenschaften (Performance/Quality/Regulatory), Use‑Cases.
2. **Funktionale Schicht**: Was das System tut (Zustände, Aktionen, Sequenzen).
3. **Logische Schicht**: technologiearme Struktur (Rollen wie Controller, Sensor, Schnittstellen).
4. **Physische Schicht**: reale Komponenten, Stückliste, konkrete Ports.

**Explizite Relationen** sorgen für Nachvollziehbarkeit:

- ProductFeature/Eigenschaft → Requirement: refine
- Requirement → Funktion: derive/trace
- Funktion → Logik/Physik: perform/realize
- Komponente → Requirement: satisfy
- Constraint/Test → Requirement: verify

Diese Kette macht Aussagen prüfbar für Qualität, Compliance, Safety, Security, Materialqualität, Supply‑Themen und mehr.

## Kommunikation: Sichten statt PowerPoint‑Kopie

Ein Großteil jedes Projekts ist **Kommunikation**. Statt statischer Folien arbeiten wir am Live‑Modell und erzeugen Sichten für die aktuelle Fragestellung – deterministisch, wiederholbar, versionierbar:

- **Product‑Feature‑Narrativ**: Nutzen, relevante Requirements, aktive Funktionsvariante, betroffene Teile, Evidenz.
- **Variant‑Delta**: zeigt nur Unterschiede zwischen Konfigurationen.
- **Allocate‑Sicht**: Funktion ↔ logische und physische Elemente inkl. Schnittstellen.
- **Evidence‑Sicht**: Satisfy/Verify‑Kette für Audits.

Vorteil: Keine zweite Wahrheit neben dem Modell. Wer tiefer oder höher gehen will, kann drill‑down/drill‑up machen, ohne Medienbruch.

## Lernkurve und die „Priesterschaft“ – warum Tools die Brücke sind

Die Lernkurve ist hoch. Nicht jede/r wird die komplette SysML‑Syntax beherrschen. Das ist realistisch. Tools werden zur Benutzeroberfläche des Modells:

- Kontrollierte Sprache (Controlled Natural Language, CNL): bewusst eingeschränkte, formal strukturierte Satzmuster mit festen Slots (z. B. „[Komponente] soll [Eigenschaft] [Grenzwert] unter [Bedingung] erfüllen.“). Diese Texte binden direkt an Modellobjekte und sind dadurch maschineninterpretierbar und für Menschen lesbar.
- Typisierte Formulare mit Einheiten- und Bereichsprüfungen.
- LLM als Vorschlagsmotor: Freiform‑Eingabe → prüfbarer Änderungs‑Patch; Übernahme nur nach menschlicher Bestätigung im Formular.
- Semantische Diffs: „1,5 s → 1,3 s“ statt Rohsyntax.

Wunsch an die Sprachebene: Reine SysML‑„Dokumentations‑Strings“ können heute keine Modellvariablen dynamisch einbetten. Deshalb braucht es generierende Views/Templates, die Text aus Modellwerten rendern (Anker statt Kopien). So bleibt es konsistent und gut lesbar.

## Governance als Pflege der Bedeutung

Wenige, kanonische Sichten statt Wildwuchs, Pre‑Merge‑Prüfungen (Typen, Einheiten, vollständige Traces, ...), klar geregelte Aktionen (Grenzwertänderungen, Variantenfreigaben, Safety‑Entscheide). Diese Regeln sichern die Bedeutung des Modells im Betrieb.

## Was SysML v2 leisten kann

SysML v2 macht Aussagen schärfer, Beziehungen explizit, Varianten beherrschbar und Kommunikation kohärenter. Die Welt bleibt widerspenstig. Genau deshalb brauchen wir eine Sprache, die präzise ist und Evidenz mitliefert.

## Schluss

Für mich ist SysML v2 ein **Präzisionswerkzeug**. Es bringt uns näher an belastbare Aussagen, weil Product‑Features und Eigenschaften gemeinsam Capabilities definieren und sich bis zu Funktionen, Architektur und Hardware durchverfolgen lassen. Der Gewinn: eine **kommunizierbare, prüfbare Kette** vom Produktversprechen bis zur verifizierten Umsetzung.