14.04.2026
Beitrag

MBSE-Methoden im Detail: SysML, RFLP und die Architektur modellbasierter Entwicklung.

Systeme werden komplexer und der Überblick geht schnell verloren. Wir zeigen, wie MBSE mit SysML und dem RFLP‑Ansatz Anforderungen, Funktionen, Logik und Geometrie klar strukturiert – und wie Engineering‑Teams fundierter entscheiden.
Riccardo Terrasi
Das Wichtigste in Kürze.

 

  • MBSE schafft eine strukturierte Sicht auf komplexe Systeme – von der Anforderung bis zur Umsetzung.
  • SysML dient als zentrales Modellierungsmittel für Anforderungen, Funktionen und Zusammenhänge.
  • Der RFLP‑Ansatz trennt bewusst Anforderungen, Funktionen, logische und physische Architektur.
  • Durchgängige Modelle verbessern Nachvollziehbarkeit, Konsistenz und Entscheidungsqualität.
  • MBSE unterstützt Teams dabei, Änderungen früh zu bewerten und Risiken gezielt zu reduzieren.

Wer in einem modernen Unternehmen für Prozesse und Systeme verantwortlich ist, spürt es im Alltag: Produkte werden komplexer, Projekte werden enger getaktet, Anforderungen ändern sich häufiger. Gleichzeitig wächst der Abstimmungsaufwand zwischen den Teams.

Vielleicht kennen Sie Situationen wie diese: Ein Kunde ändert spät im Projekt eine Anforderung. Konstruktion, Elektronik, Software und Produktion versuchen nachzuziehen. Dokumente werden angepasst, Excel-Listen verschickt, Präsentationen aktualisiert. Wochen später tauchen dennoch Unklarheiten auf: Was gilt eigentlich? Welche Version ist die richtige?

Genau an diesem Punkt setzt Model-Based Systems Engineering (MBSE) an. In unserem ersten Beitrag haben wir die Grundlagen beschrieben: Was MBSE ist, warum Dokumentenchaos zum Risiko wird und wieso ein zentrales Systemmodell heute zur strategischen Fähigkeit wird.

In diesem zweiten Teil richten wir den Fokus auf Praxis und Methoden: Wie ist MBSE technisch aufgebaut? Was leistet die Modellierungssprache SysML? Und vor allem: Welchen konkreten Nutzen hat das für Qualität, Termine und Kosten in Ihrem Unternehmen?

Event: Model Driven Engineering Day, am 6. Mai in Stuttgart.

Erleben Sie beim Model‑Driven Engineering Day am 6. Mai 2026 in Stuttgart, wie Model‑Based Systems Engineering (MBSE) und Model‑Driven Engineering komplexe Entwicklungsprozesse beherrschbar machen. Freuen Sie sich auf praxisnahe Einblicke, reale Anwendungsbeispiele und den Austausch mit Expert:innen aus Industrie und Entwicklung.

Jetzt informieren und dabei sein!

Zum Event

Vom Dokumentenstapel zum Systemmodell.

Traditionell werden Systeme über eine Vielzahl von Dokumenten beschrieben: Lasten- und Pflichtenhefte, Spezifikationen, Zeichnungen, Excel-Listen, Präsentationen. Jede Abteilung pflegt eigene Stände, oft mit eigener Terminologie. Änderungen werden per E-Mail kommuniziert. Die Folge:

  • Informationen sind verteilt und schwer auffindbar.
  • Inkonsistenzen bleiben unentdeckt.
  • Späte Änderungen verursachen hohen Aufwand und Risiko.

MBSE dreht diesen Ansatz um. Statt hunderte Dokumente zu pflegen, entsteht ein konsistentes Systemmodell als „Single Source of Truth“. Anforderungen, Funktionen, Systemarchitektur und Verknüpfungen werden modelliert und logisch verbunden. Ändert sich etwas Wesentliches, zeigt das Modell, wo überall Auswirkungen entstehen – vom Subsystem bis zur Komponente. Die Frage für Sie lautet: Wollen Sie Entscheidungen weiterhin auf Basis vieler Einzeldokumente treffen – oder auf Basis eines durchgängigen Systembildes?

Die Struktur hinter MBSE: RFLP als Ordnungsrahmen.

Damit ein Systemmodell in der Praxis steuerbar bleibt, braucht es Struktur. Ein in der Industrie etablierter Ansatz ist der RFLP-Ansatz. Er gliedert die Systembeschreibung in vier Perspektiven:

  • R – Requirements (Anforderungen).
    Was soll das System leisten? Welche gesetzlichen, kundenspezifischen und internen Vorgaben gelten?
  • F – Functional (Funktionalität/Verhalten).
    Welche Funktionen erfüllt das System? In welcher Reihenfolge laufen Abläufe? Wie reagieren Komponenten auf Signale und Zustände?
  • L – Logical (logische Struktur).
    Wie ist das System logisch aufgebaut? Welche Subsysteme, Baugruppen oder Steuergeräte gibt es, wie hängen sie zusammen?
  • P – Physical (physische Struktur).
    Wie sieht die konkrete technische Umsetzung aus? Welche Teile, Stücklisten, CAD-Modelle und Elektronikkomponenten realisieren die Logik?

Diese vier Sichten werden nicht nur für das Gesamtsystem modelliert, sondern hierarchisch, also vom System über Subsysteme bis hin zu einzelnen Komponenten. So entsteht ein roter Faden durch die gesamte Produktstruktur. Für Fertigungsunternehmen bedeutet das konkret:

  • Anforderungen werden gezielt bis in die Stückliste verfolgt.
  • Änderungen an Komponenten lassen sich bis zu den betroffenen Funktionen und Anforderungen zurückverfolgen.
  • Produktions- und Qualitätsverantwortliche bekommen früh ein klares Bild, welche Auswirkungen Designentscheidungen später auf die Fertigung haben.

SysML: Die gemeinsame Sprache für komplexe Systeme.

Ein Modell braucht eine Sprache. Im MBSE-Umfeld hat sich die Systems Modeling Language (SysML) etabliert. SysML ist ein standardisierter Notationssatz, mit dem Systemingenieur:innen Anforderungen, Funktionen, Strukturen und Verhalten grafisch beschreiben.Warum ist das wichtig für Sie als Entscheider:in?

1
Eindeutigkeit statt Interpretationsspielraum.

Jede Form, jede Linie im SysML-Diagramm hat eine definierte Bedeutung. Das reduziert Missverständnisse, gerade wenn viele Disziplinen zusammenarbeiten.

2
Grafik statt Textwüste.

Ein Zustands- oder Aktivitätsdiagramm lässt Mitarbeitende in Sekunden erkennen, wie ein System reagiert. Ein reiner Text beschreibt dasselbe Verhalten oft auf vielen Seiten – und wird nicht vollständig gelesen.

3
Rückverfolgbarkeit im Modell.

SysML erlaubt es, Anforderungen mit Funktionen, logischen und physischen Elementen zu verknüpfen. Damit entsteht die Traceability, die viele Normen für funktionale Sicherheit und Cybersecurity heute verlangen.

Aktuell wird in der Praxis überwiegend mit SysML Version 1 gearbeitet (mit Releases bis 1.7). Parallel dazu setzt sich schrittweise SysML Version 2 durch. Unternehmen werden diese neue Version übernehmen, sobald Tools sie vollständig unterstützen und Migrationspfade geklärt sind.

Für Sie entscheidend: Wer heute mit SysML Version 1 arbeitet, baut Kompetenzen auf, die sich später auf Version 2 übertragen lassen. Die Investition bleibt also gültig.

Simulation: Verhalten prüfen, bevor es teuer wird.

Ein technischer Mehrwert von MBSE ist die Möglichkeit, das Modell nicht nur zu dokumentieren, sondern auch ausführen und simulieren zu können.

Beispiel: In einem Zustandsdiagramm wird beschrieben, wie ein System von „Sleep“ in „Exploration“ wechselt, wenn ein bestimmtes Signal anliegt und genug Energie vorhanden ist. Eine Simulation dieses Diagramms zeigt in Echtzeit, ob das Verhalten korrekt spezifiziert ist. Fehler fallen damit in der Konzeptphase auf – und nicht erst im Endtest oder im Feld.

Zusätzlich können Strukturinformationen aus dem Systemmodell in Simulationswerkzeuge exportiert werden. So basieren Simulationsmodelle auf derselben Architektur wie das reale System. Das reduziert Medienbrüche und Abstimmungsaufwand zwischen Systemarchitektur, Simulation und späterer Umsetzung. Die Frage dahinter: Was kostet es Ihr Unternehmen, wenn ein Fehler erst im realen Einsatz auftritt – und wie viel günstiger wäre es, diesen Fehler im Modell abzufangen?

Zusammenarbeit im Team: Ein Modell, viele Rollen.

MBSE entfaltet den größten Nutzen, wenn das Systemmodell für alle relevanten Rollen zugänglich ist: Systemarchitektur, Entwicklung, Software, Elektronik, Fertigungsplanung, Qualität. Moderne Tools unterstützen dies mit:

  • zentralen Modellservern mit Versionierung und Berechtigungen
  • parallelem Zugriff mehrerer Nutzender auf dasselbe Modell
  • Weboberflächen, über die auch Nicht-Modellierende Diagramme einsehen und kommentieren können
  • Integrationen in PLM-Plattformen, die MBSE-Modelle mit Anforderungen, CAD-Daten und Stücklisten verknüpfen

Für Fertigungsunternehmen bedeutet das:

  • Produktionsverantwortliche sehen im Modell früh, welche Baugruppen kritisch sind.
  • Änderungswünsche aus der Fertigung können direkt im Kontext der Systemarchitektur bewertet werden.
  • Management-Entscheidungen basieren nicht nur auf Projektreports, sondern auf einer strukturierten, technischen Sicht des Produkts.

MBSE einführen: klein starten, strategisch denken.

MBSE ist kein Projekt, das „nebenbei“ läuft. Es verändert Arbeitsweisen, Rollenprofile und Schnittstellen. Gleichzeitig muss der Einstieg nicht groß und riskant sein. Erfolgreiche Unternehmen gehen pragmatisch vor:

  • Pilotprojekte wählen: zum Beispiel ein neues Produkt, ein komplexes Subsystem oder eine sicherheitskritische Baugruppe.
  • Klare Ziele definieren: Wollen Sie vor allem Rückverfolgbarkeit herstellen? Die Architektur stabilisieren? Simulationen früher integrieren?
  • Methodik, Sprache und Tool sauber verzahnen: RFLP-Methode, SysML und ein geeignetes MBSE-Tool bilden gemeinsam das Fundament.
  • Mitarbeitende begleiten: Training ist wichtig, noch wichtiger ist Coaching im Projektalltag. So entsteht echte Routine.
  • Change Management aktiv gestalten: MBSE verändert Zuständigkeiten. Wer definiert Anforderungen? Wer verantwortet die Systemarchitektur? Wer pflegt das Modell? Diese Fragen sollten beantwortet sein.

Als Management haben Sie hier eine zentrale Aufgabe: Rahmenbedingungen schaffen, Prioritäten setzen und dafür sorgen, dass MBSE nicht als „IT-Projekt“ wahrgenommen wird, sondern als strategische Weiterentwicklung Ihrer Entwicklungs- und Fertigungsorganisation.

Fazit: MBSE als Hebel für zukunftsstarke Fertigung.

Model-Based Systems Engineering ist kein theoretischer Ansatz, sondern ein pragmatisches Werkzeug, um komplexe Produkte sicher zu entwickeln und zu fertigen. Für Entscheider:innen in Fertigungsunternehmen bietet MBSE drei zentrale Mehrwerte:

1
Bessere Entscheidungen.

Ein konsistentes Systemmodell liefert ein klares Bild der Zusammenhänge. Auswirkungen von Änderungen werden früher sichtbar.

2
Weniger Risiko in späten Phasen.

Traceability, Simulation und strukturierte Architektur reduzieren Überraschungen kurz vor SOP (Start of Production) oder im Feld.

3
Effizientere Zusammenarbeit.

Teams arbeiten auf Basis derselben Systembeschreibung. Medienbrüche und Doppelarbeiten gehen zurück.

Die entscheidende Frage lautet daher nicht, ob MBSE relevant ist. Sondern: Wie lange kann sich ein Fertigungsunternehmen leisten, komplexe Systeme ohne konsistentes Systemmodell zu entwickeln? Wir unterstützen Sie gern dabei, die ersten Schritte zu planen: von der Auswahl eines geeigneten Pilotprojekts über den methodischen Rahmen bis zur Verzahnung mit Ihrer bestehenden PLM-Landschaft. Kontaktieren Sie uns jetzt!

Riccardo Terrasi
Riccardo begeistert sich für technische Innovationen rund um Cloud, KI und Automatisierung. In seinen Beiträgen zeigt er, wie diese Entwicklungen schon heute die Welt des Engineerings prägen und richtet sich an alle, die nicht nur Lösungen suchen, sondern auch Systeme und Ideen verstehen wollen.
alle Beiträge
CATIA PLM & Zusammenarbeit

Sie haben Fragen? Sprechen Sie uns an!

Ihre Zufriedenheit hat oberste Priorität. Wenn Sie Informationen benötigen, Unklarheiten haben oder spezifische Anliegen besprechen möchten, zögern Sie nicht, uns zu kontaktieren
+ 49 7132 387 68 222