Eine Wahrheit, alle Sichten

Das Versprechen und die Rechnung

Modellbasiertes Systems Engineering (MBSE) hat ein gutes Versprechen: Das Modell ist die Quelle der Wahrheit, alle Dokumente sind nur Sichten darauf. Wer dieses Versprechen einlöst, hat keine widersprüchlichen Stände mehr, keine veralteten Spezifikationen, keine Doppelpflege.

In der Praxis wird dieses Versprechen selten eingelöst. Der Grund ist einfach: In den etablierten Werkzeugen ist das Diagramm die Arbeitsfläche. Der Ingenieur malt Blöcke, zieht Verbindungslinien, ordnet an — und das eigentliche Modell entsteht als Nebenprodukt dieser Zeichnung. Damit dreht sich das Versprechen um: Statt „ein Modell, viele Bilder" entsteht „viele Bilder, die zum Modell werden sollen". Und jedes Bild ist ein Artefakt, das gepflegt, versioniert, abgestimmt und synchron gehalten werden muss.

Das kostet an drei Stellen Geld, jeden Monat, in jedem Projekt:

• Doppelpflege. Anforderung im Requirements-Werkzeug, Funktion im Funktionsmodell, Struktur im Architekturmodell, Fehler in der FMEA — dieselbe Sache, in vier Werkzeugen erfasst und aufeinander abgeglichen.
• Drift. Sobald zwei Artefakte dasselbe beschreiben, laufen sie auseinander. Wer hat den aktuellen Stand? Meist niemand vollständig. Der Abgleich ist ein eigener, nie endender Aufwand.
• Werkzeug-Zeremonie. Ein erheblicher Teil der Zeit fließt nicht in Ingenieursarbeit, sondern in die Bedienung der Modellierungsumgebung: Diagramme sauber halten, Layer synchron halten, Notation korrekt halten.

Für große Konzerne mit eigenen MBSE-Abteilungen mag sich das rechnen. Für den Mittelstand — Firmen mit fünfzig bis fünfhundert Mitarbeitern — ist es Overhead, der den Einstieg in sauberes Systems Engineering blockiert. Genau hier setzt OTSM an.

Der Kern: eine Datenbasis, aus der die Bilder fallen

OTSM löst das Versprechen ein, das MBSE gibt — nur konsequenter. Der Ingenieur pflegt keine Diagramme. Er pflegt Daten: Bausteine und ihre Verbindungen. Die Bilder — Architekturdiagramm, Funktionsnetz, FMEA-Baum, Requirements-Liste — werden aus diesen Daten erzeugt, nicht gezeichnet.

Der Unterschied ist nicht kosmetisch. Er ist der ganze Punkt:

Wenn das Bild aus den Daten generiert wird, kann es nicht von den Daten abweichen. Drift ist strukturell ausgeschlossen — nicht durch Disziplin, sondern durch Bauart.

Es gibt keine „veraltete Version des Diagramms" mehr, weil es keine gepflegte Version des Diagramms mehr gibt. Es gibt nur den aktuellen Datenstand und seine aktuelle Darstellung. Ändert sich ein Baustein, ändern sich alle Sichten, die ihn zeigen, im selben Moment.

Das Fundament dafür ist bewusst klein. Alles, was in einem Produkt, einem Bauteil, einer Organisation wichtig ist, lässt sich in fünf Sorten von Bausteinen einordnen:

BausteinBeantwortetBeispiel (Bremse)

Ziel

Wofür? Für wen?

„Sichere Autos für Autofahrer"

Funktion

Was tut es?

„Bremsmoment erzeugen"

Lösung

Womit ist es gemacht?

„Scheibenbremse aus Stahl"

Merkmal

Wie wird es gemessen?

„Bremsweg ≤ 40 m"

Kontext

Wann gilt es?

„trockene Straße, 100 km/h, volle Beladung"

Diese fünf reichen — für ein Bauteil ebenso wie für eine Abteilung, eine Behörde, ein Gesetz. Die Bausteine hängen über wenige, klar definierte Verbindungen zusammen: Eine Funktion verfeinert ein Ziel. Eine Lösung realisiert eine Funktion. Ein Merkmal misst eine Funktion. Ein Kontext gilt für eine Funktion. Mehr Grammatik braucht es nicht.

Aus genau dieser einen, verbundenen Datenbasis entstehen alle Fachsichten als Projektion. Der Geschäftsführer sieht Ziele, der Architekt Funktionen, der Konstrukteur Lösungen, der Prüfer Merkmale, der Compliance-Verantwortliche den Kontext — dieselben Bausteine, verschiedene Sprachen. Kein zweites Modell, keine zweite Wahrheit.

Der Ingenieur arbeitet weiter, wie er denkt

Ein häufiger, berechtigter Einwand gegen Methoden lautet: Ich muss meine Arbeitsweise dem Werkzeug unterordnen. Bei OTSM ist es umgekehrt.

Der Ingenieur zerlegt sein System so, wie er es ohnehin tut: oben die grobe Struktur — Hardware, Software, Mechanik — darunter die Komponenten, immer feiner. Das ist seine natürliche Denkweise, und sie bleibt die Grundstruktur. Die Funktionen, die diese Komponenten erbringen, die Anforderungen an sie und ihre Fehlerbetrachtung werden als Aspekt darübergelegt — nicht als getrennte, parallel zu pflegende Modellwelt.

Das ist der entscheidende methodische Kniff, und er hat einen soliden theoretischen Namen: die querschneidende Sorge (die Funktion, die Anforderung, der Fehler) wird nicht in eine eigene Zerlegung gezwungen, sondern über die natürliche Struktur gewoben. So entgeht man dem klassischen Problem, dass jede Disziplin ihre eigene Zerlegung anlegt — und am Ende N Zerlegungen, N Wahrheiten und N Driftquellen entstehen.

Praktisch heißt das: kürzere Einarbeitung, weniger Widerstand, schnellere Akzeptanz. Der Ingenieur lernt kein neues Weltbild. Er schreibt auf, was er tut — und das System setzt Baustein-Art, Verbindung und Reifegrad im Hintergrund korrekt dahinter.

Für Methodiker

Das Prinzip ist Multi-Dimensional Separation of Concerns: eine Basis-Zerlegung (die physische/Komponenten-Achse) plus mehrere gewobene Aspekte (Funktion, FMEA, Anforderung, Compliance). Die Sicht einer Rolle ist eine Projektion über einem gemeinsamen Knotenbestand mit typisierten Kanten — keine Sicht erfindet Kanten, sie filtert aus den vorhandenen. Eine Abhängigkeit, die im Modell nicht steht, ist ein Fehler, keine Sicht.

Reifegrad statt Modell-Ebenen-Zoo

Klassisches MBSE trennt vier Ebenen — Anforderungen, Funktion, Logik, Physik (RFLP) — und pflegt sie als getrennte Modell-Layer, die am Ende wieder aufeinander alloziert werden müssen. Das ist ein Umweg, der wieder zusammenläuft: Die logische Architektur muss auf die physische abgebildet werden, in einem eigenen, fehleranfälligen Schritt.

OTSM braucht diese getrennten Ebenen nicht. „Logisch" und „physisch" sind keine verschiedenen Modelle, sondern Reifegrade desselben Bausteins — der Grad, zu dem man sich schon festgelegt hat:

1. Funktion beschrieben — lösungsneutral. „Es muss bremsen." Noch keine Entscheidung, womit. Das ist die logische Ebene.
2. Merkmale an die Funktion — dimensioniert. „Bremsweg ≤ 40 m." Der Soll-Rahmen steht, die Sache selbst ist aber noch nicht gewählt. Immer noch logisch, nur bemaßt.
3. Gerät gewählt — physisch. Jetzt liegt ein konkretes Bauteil mit realen Ist-Werten vor.

Der Übergang von logisch zu physisch ist damit kein Modellwechsel, sondern eine Soll-trifft-Ist-Wende: Das Merkmal trägt den Soll-Wert (die Anforderung an die Funktion), die Gerätewahl bringt den Ist-Wert (die Eigenschaft des konkreten Teils). Verifikation ist dann der Abgleich beider — im selben Baustein, ohne Layer-Wechsel.

Für den Kunden bedeutet das: Sie modellieren keine vier Ebenen. Sie beschreiben einen Baustein und lassen ihn reifen. Die Wiederverwendung über Produktvarianten hinweg bleibt erhalten, weil die Funktion trägerunabhängig beschrieben ist — dieselbe Funktion kann in Variante A auf ein anderes Bauteil abgebildet werden als in Variante B, ohne dass etwas doppelt entsteht.

Für Methodiker

Realisierungs-Domäne (Software / Hardware / Mechanik) und Reifegrad (Funktion → Dimensionierung → Gerät) sind zwei orthogonale Achsen, nicht dieselbe. Ein Baustein kann als «Software» klassifiziert und trotzdem lösungsneutral sein. Das Merkmal ankert an der Funktion, nicht am Element — ein nicht-funktionales Requirement ist ein Merkmal, das eine Funktion dimensioniert. Requirements-Sicht und FMEA-Sicht zeigen dasselbe Merkmal, nur unterschiedlich gerendert.

Die FMEA arbeitet für Sie — sie ist kein Zusatzaufwand

In vielen Organisationen ist die FMEA eine ungeliebte Pflichtübung: ein separates Dokument, das nach der eigentlichen Entwicklung nachgezogen wird und sofort veraltet. Bei OTSM ist die FMEA keine Nacharbeit, sondern eine Quelle — sie erzeugt Anforderungen, statt sie nur zu kommentieren.

Die Struktur der FMEA bildet nämlich fast Spalte für Spalte den Innenraum eines Ablaufs ab:

FMEA-Element Was daraus im System wird

Funktion (etwas hat gewirkt)

der normale Schritt im Ablauf

Fehlerart / Merkmal außerhalb des Rahmens

die Bedingung, die eine Sonderbehandlung auslöst — der Detektionspunkt

Fehlerfolge

die Schwere, das „warum es zählt"

Reaktion / Entdeckung

die Handlungsschritte für den Sonderfall

Vermeidungsmaßnahme

eine neue Anforderung

Der letzte Punkt ist der eigentliche Hebel. Eine Vermeidungsmaßnahme — „wir brauchen einen zusätzlichen Sensor", „ein Signal muss zurückgemeldet werden" — ist kein Notizzettel, der irgendwo abgelegt und vergessen wird. Sie fällt als neue Bausteine in dieselbe Datenbasis zurück: eine neue Lösung, die eine neue Detektions-Funktion realisiert, ein neues Merkmal, das sie misst. Die FMEA wird damit zum Anforderungs-Motor, der das Modell weiterentwickelt — und weil alles in einer Datenbasis liegt, sind diese neuen Anforderungen sofort in Spezifikation, Architektur und Prüfplanung sichtbar.

Ein Detail, das die Methode ehrlich hält: Nicht jede Verzweigung ist ein Fehler. „Antrag genehmigt" und „Antrag abgelehnt" sind beide gültige Ausgänge, keiner davon eine Fehlerart. Solche legitimen Alternativen bleiben Teil des normalen Ablaufs; die FMEA legt sich als Overlay darüber und markiert nur, welche Zweige fehlergetrieben sind. So gehen weder die Geschäftsvarianten noch die Fehlerbetrachtung verloren.

Keine Drift — und Reviews, die nicht mehr stattfinden müssen

Der größte versteckte Kostenblock im Engineering ist nicht die Erstellung, sondern das Konsistenthalten. Genau diesen Block räumt die Datenkonsistenz aus.

Weil jede Sicht aus derselben Quelle projiziert wird, kann ein Plan nicht gegenüber dem Prozess veralten, aus dem er erzeugt wird. Eine Änderung wirkt einmal und schlägt in alle betroffenen Darstellungen durch. Die typische Frage „welches ist die aktuelle Version?" entfällt, weil es nur eine gibt.

Das verändert auch die Natur von Reviews. Klassische Design-, FMEA- und Architektur-Reviews sind zentrale Ereignisse: Man friert einen Stand ein, versammelt Leute, protokolliert. Wenn die Daten aber immer konsistent und immer aktuell sind, wird das große Review-Ereignis überflüssig. An seine Stelle tritt ein permanenter Zustand: Jeder Verantwortliche einer Sicht sieht jederzeit den aktuellen Stand, die seit seinem letzten Blick relevanten Änderungen und die offenen Bestätigungen. Bestätigungen und Beanstandungen werden am Baustein festgehalten und sind unveränderlich — ein Audit-Trail entsteht nebenbei. Das klassische Review-Protokoll wird bei Bedarf als Sicht gerendert, nicht doppelt gepflegt.

Für Sie heißt das konkret: Die Vorbereitung eines Audits schrumpft von „alle aktuellen Versionen aller Dokumente heraussuchen und exportieren" auf „Stand ziehen, Sicht abrufen". Die Belegkette ist eingebaut, nicht nachträglich rekonstruiert.

Was ehrlich bleibt: drei Nähte, die kein Werkzeug wegzaubert

Ein seriöses Whitepaper verschweigt die Grenzen nicht. OTSM entfernt den akzidentellen Aufwand — Diagramme malen, Ebenen doppelt pflegen, Dokumente synchron halten, Notation zelebrieren. Den essenziellen Engineering-Aufwand kann kein Werkzeug entfernen; OTSM macht ihn aber sichtbar, statt ihn zu verstecken. Drei Stellen bleiben echte Arbeit:

1. Uneinigkeit über die Zerlegung. Solange eine Person eine Struktur anlegt, ist alles glatt. Sobald zwei Ingenieure denselben Teil unterschiedlich schneiden, liegt ein echter Architektur-Dissens vor. OTSM erfindet hier keine Scheinlösung — es macht den Widerspruch sichtbar und zwingt zur Auflösung. Das ist ein Vorteil gegenüber Werkzeugen, in denen zwei divergierende Modelle stillschweigend nebeneinander bestehen; die Entscheidung selbst bleibt aber Ingenieursarbeit.

2. Funktionen, die über mehrere Komponenten laufen. Die interessanten — und für die Fehlerbetrachtung wichtigen — Funktionen sind oft nicht an einem Bauteil, sondern über mehrere verteilt (und eine Komponente wirkt in mehreren Funktionen). OTSM bildet diese Viele-zu-viele-Beziehung ab, statt sie auf „eine Funktion pro Bauteil" zu vereinfachen. Das Modellieren dieser Verteilung ist Denkarbeit — aber sie ist der Ort, an dem systemische Fehler entstehen, und deshalb genau richtig investiert.

3. Die Schnittstellen an den Nähten. Wenn jeder in seinem Teilbereich arbeitet, ist die Kopplung zwischen den Bereichen die Stelle, an der die gefährlichen Fehler sitzen — das „ein Signal muss zurückkommen" aus der FMEA. OTSM behandelt die Schnittstelle als eigenes Objekt mit zwei Verantwortlichen, damit die Naht nicht zwischen zwei Zuständigkeiten durchfällt. Die Schnittstelle sauber zu vereinbaren bleibt Aufgabe der Beteiligten; das Werkzeug sorgt dafür, dass sie nicht vergessen wird.

Diese drei Punkte sind kein Nachteil von OTSM — sie sind die echte Substanz von Systems Engineering. Der Gewinn liegt darin, dass Ihre Leute ihre Zeit auf diese drei Fragen verwenden, statt auf das Pflegen von Diagrammen und das Jagen von Inkonsistenzen.

Was das konkret spart

Der Nutzen entsteht nicht aus einem einzelnen Effekt, sondern aus dem Wegfall mehrerer Kostenblöcke gleichzeitig:

• Keine Doppelpflege. Anforderung, Funktion, Struktur, Fehler und Prüfung leben in einer Datenbasis. Eine Eingabe, alle Sichten aktuell.
• Keine Drift-Korrektur. Der nie endende Abgleich zwischen Werkzeugen entfällt, weil es die getrennten Stände nicht mehr gibt.
• Weniger Werkzeuge. Requirements-Tool, Funktionsmodell, Architektur-Tool und FMEA-Tabelle laufen auf einem Substrat zusammen — weniger Lizenzen, weniger Integrationsaufwand, weniger Schnittstellen zwischen Werkzeugen.
• Schnellere Einarbeitung. Ingenieure behalten ihre natürliche Zerlegung; sie lernen kein Diagramm-Handwerk.
• Audit auf Knopfdruck. Belegkette und Historie sind eingebaut; die Vorbereitung schrumpft vom Tage-Projekt zur Abfrage.

Für ein mittelständisches Unternehmen ist das der Unterschied zwischen „Systems Engineering ist zu teuer für uns" und „wir arbeiten methodisch sauber, ohne eine eigene MBSE-Abteilung zu unterhalten".

Fair gegenüber MBSE — und ehrlich über den eigenen Fokus

OTSM ist nicht anti-modellbasiert. Im Gegenteil: Es ist modellbasierter als der Diagramm-getriebene Ansatz, weil es das MBSE-Kernversprechen — eine Quelle, viele Sichten — tatsächlich einlöst, statt es an der Zeichenoberfläche zu verraten.

Wo klassisches SysML echten Wert liefert, den OTSM für sein Zielsegment nicht braucht: In sehr großen, über viele Disziplinen und Standorte verteilten Organisationen ist das abgestimmte Diagramm eine ausgehandelte gemeinsame Sprache zwischen Teams, die verschiedene Teile beitragen. Dieser Verhandlungswert ist real. Für Firmen mit fünfzig bis fünfhundert Mitarbeitern greift er aber kaum — dort überwiegt der Overhead bei weitem den Nutzen. Genau für dieses Segment ist OTSM gebaut: die volle methodische Strenge von Requirements Engineering und FMEA, ohne den Modell-Zoo, den man dafür bisher glaubte kaufen zu müssen.

Dieses Whitepaper beschreibt die methodische Grundlage von OTSM. Für eine Demonstration an einem Ihrer eigenen Systeme oder Prozesse sprechen Sie uns an.