„Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.“

Antoine de Saint-Exupéry— Schriftsteller, Pilot und offenbar verkappter Systems Engineer.

Was für die Literatur gilt, gilt erst recht für die Welt der Normen, Anforderungen und Sicherheitsanalysen: Die Arbeit des Ingenieurs ist vollendet, wenn man nichts mehr weglassen kann. Klingt einfach. Ist es nicht. Denn in der Praxis passiert seit Jahrzehnten das genaue Gegenteil.

Kapitel 1: Der überfüllte Schreibtisch

Stellen Sie sich einen Ingenieur vor. Nennen wir ihn Stefan. Stefan sitzt an seinem Schreibtisch und versucht, eine sicherheitskritische Anlage zu dokumentieren. Vor ihm:

• Drei verschiedene Excel-Dateien für die FMEA — keine davon aktuell
• Ein Word-Dokument mit 847 Anforderungen, davon mindestens 120 Duplikate
• Fünf Normen, die sich in Teilen widersprechen
• Ein Legacy-Tool, das seit 2009 nicht mehr aktualisiert wurde
• Und die leise Angst, dass beim letzten Audit niemand gemerkt hat, dass Requirement REQ-0412 und REQ-0587 exakt dasselbe sagen — nur anders formuliert

Stefan ist kein schlechter Ingenieur. Stefan ist ein typischer Ingenieur. Denn das Problem liegt nicht bei Stefan. Das Problem liegt im System.

In der Welt des Requirements Engineering und der funktionalen Sicherheit hat sich über Jahrzehnte eine Komplexitätsschicht über die andere gelegt. Neue Normen kamen hinzu, ohne dass alte entrümpelt wurden. Neue Tools wurden eingeführt, ohne dass alte abgelöst wurden. Und neue Anforderungen wurden geschrieben, ohne zu prüfen, ob sie nicht längst existieren — nur eben drei Ordner weiter in einer anderen Datei.

Kapitel 2: Das unsichtbare Gift — Duplikate, Widersprüche, Ballast

Reden wir über das, worüber niemand gerne redet: den Zustand der Normlandschaft.

Duplikate: Der stille Produktivitätskiller

In einem typischen Anforderungsdokument mit 500+ Requirements finden sich erfahrungsgemäß 15–25% Duplikate. Nicht wortwörtlich identisch — das wäre zu einfach. Sondern semantisch: Dieselbe Anforderung, nur anders formuliert. Von verschiedenen Personen. Zu verschiedenen Zeitpunkten. In verschiedenen Dokumenten. Jedes Duplikat erzeugt redundanten Testaufwand, inkonsistente Traceability und Verwirrung beim Audit.

Normwidersprüche: Wenn Standards sich gegenseitig sabotieren

Wer gleichzeitig nach IEC 61508, ISO 26262 und branchenspezifischen Normen arbeitet, kennt das Phänomen: Norm A fordert X, Norm B fordert Nicht-X, und Norm C schweigt dazu — was im Audit als „nicht erfüllt“ gewertet wird. Das ist kein Randproblem. Das ist Alltag. Und kein Excel-Sheet der Welt löst es.

Überflüssiges: Features, die niemand braucht

Tools im Bereich Safety und Requirements Engineering leiden an derselben Krankheit wie Enterprise-Software im Allgemeinen: Feature-Bloat. Jedes Release bringt neue Funktionen, die von 5% der Nutzer gewünscht und von 95% ignoriert werden. Das Ergebnis ist eine Oberfläche, die aussieht wie ein Cockpit einer Boeing 747 — nur ohne die Pilotenlizenz, die man bräuchte, um sie zu bedienen.

Kapitel 3: Der aufgeräumte Workspace — Die OTSM-Philosophie

Jetzt stellen Sie sich Stefan ein Jahr später vor. Gleicher Schreibtisch. Gleiches Projekt. Aber ein völlig anderes Bild:

Ein System. Eine Quelle der Wahrheit. Alles an seinem Platz.

Das ist die Vision von OTSM — Operational Technology Systems Management. Nicht noch ein Tool mit noch mehr Features. Sondern ein radikal aufgeräumter Ansatz, der genau das liefert, was Ingenieure wirklich brauchen. Nicht mehr. Nicht weniger.

Die Basics — aber die richtig

OTSM konzentriert sich auf das, was wirklich zählt:

Anforderungen, die eindeutig sind. Nicht 847 Stück in drei Dateien, sondern dedupliziert, validiert und rückverfolgbar — durch intelligente Duplikaterkennung, die semantische Ähnlichkeiten erkennt, nicht nur Wortgleichheit.

FMEA, die lebt. Keine statische Excel-Tabelle, die beim dritten Reiter schon veraltet ist, sondern ein integrierter Prozess, der direkt mit den Anforderungen und der Simulation verknüpft ist.

Simulation als Herzstück. Nicht als nettes Add-on, sondern als Kern des Systems — die Simulation Engine, die prüft, validiert und vorhersagt, bevor der erste Prototyp gebaut wird.

Normenharmonisierung statt Normenchaos. OTSM unterstützt parallel sinvolles Requirements Engineering. SOPHIST, INCOSE und die Erweiterung

1. welche Kraft,
2. zwischen welchen Elementen,
3. wie viel Kraft,
4. geprüft womit.

Widersprüche werden sichtbar gemacht, nicht unter den Teppich gekehrt.

Kapitel 4: Revolution durch Vereinfachung

„Revolution“ klingt nach Barrikaden und brennenden Fackeln. Die Revolution, die OTSM anstrebt, ist leiser — aber nachhaltiger:

Schritt 1: Ausmisten

Automatische Duplikaterkennung identifiziert semantisch identische Anforderungen. Nicht auf Knopfdruck löschen — sondern dem Ingenieur zeigen, was doppelt ist, und die Entscheidung dem Menschen überlassen. Technologie als Werkzeug, nicht als Vormund.

Schritt 2: Harmonisieren

Normen und Standards werden nicht einfach nebeneinander gelegt, sondern aktiv auf Widersprüche geprüft. Wo sich IEC 61508 und ISO 26262 in die Quere kommen, macht OTSM den Konflikt transparent — mit klaren Handlungsempfehlungen.

Schritt 3: Fokussieren

Jede Funktion in OTSM muss eine Frage bestehen: „Braucht der Ingenieur das täglich?“ Wenn nein, fliegt es raus. Oder wird optional. Aber es verstopft nicht die Oberfläche. Das Boeing-747-Cockpit wird zum Tesla-Cockpit: Ein Screen. Die richtigen Informationen. Zur richtigen Zeit.

Schritt 4: Validieren

Die Simulation Engine — das Herzstück von OTSM — sorgt dafür, dass Vereinfachung nicht auf Kosten der Sicherheit geht. Jede Reduktion wird simuliert, jede Änderung validiert. Weniger Komplexität, gleiche Sicherheit. Das ist der Deal.

Kapitel 5: Nachhaltig einfach

Vereinfachung ist kein einmaliger Akt. Sie ist eine Disziplin. OTSM ist so konzipiert, dass Einfachheit kein Zustand ist, der beim nächsten Release wieder verloren geht, sondern ein Prinzip, das in die Architektur eingebaut ist:

• Automatische Duplikaterkennung bei jedem neuen Requirement — bevor es im System landet, nicht nachher
• Kontinuierliche Normenprüfung — wenn eine neue Norm-Version erscheint, werden bestehende Anforderungen automatisch auf Konflikte geprüft
• Lückenlose Traceability — von der Anforderung über die FMEA bis zur Simulation, alles nachvollziehbar, alles rückverfolgbar
• Human-in-the-Loop — KI schlägt vor, der Mensch entscheidet. Keine Blackbox, kein Autopilot, kein blindes Vertrauen

Die Kunst des Weglassens — ein Fazit

Die besten Systeme sind nicht die mit den meisten Features. Die besten Systeme sind die, bei denen jedes Feature seinen Platz hat und kein einziges überflüssig ist.

OTSM steht für eine unbequeme Wahrheit: Komplexität ist kein Qualitätsmerkmal. Sie ist ein Symptom. Ein Symptom dafür, dass niemand den Mut hatte, zu fragen: „Brauchen wir das wirklich?“

Die Antwort ist öfter „Nein“ als uns lieb ist. Und genau darin liegt die Revolution.

—Überflüssiges weg. Nur die Basics. Aber die richtig. —

OTSM —

Revolution durch Vereinfachung. Nachhaltig.