Selbst entwickeln oder MCSA nutzen?
Die Frage ist berechtigt. MOCUS, BDD, Cut-Set-Minimierung — die FTA-Algorithmen sind seit den 1970ern publiziert. Ein Team mit Safety-Hintergrund und C++-Kompetenz kann eine Fault-Tree-Engine bauen. Diese Seite legt offen, was bei der Entscheidung wirklich zählt: nicht die Algorithmen, sondern das Drumherum.
Der Aufwand liegt nicht in der Implementierung
Die Algorithmen sind der kleinste Aufwandsblock. Der eigentliche Engpass steht in ISO 26262-8 Clause 11: Tool Qualification. Ohne diesen Nachweis ist das Tool im Safety-Case nicht einsetzbar.
-
Tool Confidence Level bestimmen
TCL1/2/3 aus Tool Impact (TI) und Tool Error Detection (TD) ableiten — je höher der Impact, desto aufwendiger die geforderte Qualifikation.
-
Qualifikationsmethode wählen
Für TCL2/3 zwischen „Increased Confidence from Use", „Validation of the Software Tool", „Development in Accordance with a Safety Standard" oder „Evaluation of the Tool Development Process" entscheiden.
-
Evidenz erzeugen
Validierungsplan, Testkorpus mit Abdeckungsnachweis, Regressionsevidenz, Requirement-to-Test-Tracing, dokumentierte Use Cases und Known Limitations.
-
Re-Qualifikation bei jeder Änderung
Jeder Bugfix, jedes Feature, jeder Compiler-Wechsel erfordert mindestens eine Delta-Analyse; bei größeren Änderungen einen vollen Re-Qualifikationslauf.
-
Audit-Verteidigung beim Kunden
OEM- und Tier-1-Assessoren erwarten dokumentierte Use-Case-Abgrenzungen und einen verantwortlichen Ansprechpartner für Tool-Fragen im Assessment.
Realistischer Aufwand: mehrere Mensch-Monate für die initiale Qualifikation, laufender Pflegeaufwand pro Release — unabhängig davon, wie schnell die Algorithmen selbst implementiert sind.
MCSA ist qualifiziert
MCSA ist als qualifiziertes Safety-Tool verfügbar — die Qualifikationsarbeit ist geleistet und bleibt im Betrieb gepflegt.
Qualifikation nach ISO 26262-8
MCSA v5.0.0 ist nach ISO 26262-8 Clause 11 qualifiziert. Qualifikationsumfang und Use-Case-Abgrenzung sind dokumentiert.
Evidenz auf Anfrage einsehbar
Validation Report, Use-Case-Dokumentation und Regressionsnachweis stehen für Kunden und Assessoren bereit — unter NDA, wo nötig.
Re-Qualifikation pro Release
Jedes MCSA-Release durchläuft den definierten Re-Qualifikationslauf, bevor es ausgeliefert wird. Neue Versionen kommen ohne Zusatzaufwand auf Kundenseite.
Tool-Support während Audits
Wir begleiten Assessor-Gespräche und liefern Nachweise zu Use Cases, Boundaries und Known Limitations — direkt durch den Tool-Entwickler.
Was MCSA technisch leistet
Auf der Outcome-Ebene — nicht als Algorithmen-Liste, sondern als belastbarer Lieferumfang:
-
Architektur-basierte Eingabe
Textuelle, versionierbare FtaDSL-Beschreibung mit Funktionen, Ports, Schnittstellen (INT) und Fehlerfortpflanzungssemantik (OIM, COND-Literale, ISF/SF/TF-Raten).
-
Automatisierte Fault-Tree-Generierung
Aus der Architekturbeschreibung — keine manuelle Baum-Pflege, keine Synchronisierungs-Kosten zwischen Architektur und FTA.
-
Minimale Cut-Sets bis zur gewählten Ordnung
Mit KPI-Kennzahlen (FCI, RRW, IMP, SEN, Priorität), SPOF-Markierung und Common-Causes-Analyse bei Transfer-Strukturen.
-
LLM-gestützte Validierung und Interpretation
Unabhängige Plausibilitätsprüfung der Eingabe und Einordnung der Ergebnisse. Die Analyse selbst bleibt deterministisch und vom LLM unabhängig.
-
Reproduzierbar und prüfbar
Gleicher Input liefert denselben Output. Jede Berechnung ist nachvollziehbar — Voraussetzung für Safety-Case und Audit.
Was Sie als Kunde bekommen — über das Tool hinaus
-
Qualifizierte Ingenieurleistung
Der Tool-Entwickler ist Functional-Safety-Engineer, nicht nur Software-Ingenieur. Support-Antworten kommen aus der Safety-Perspektive.
-
Unterstützung beim Modellaufbau
Aufsetzen der FtaDSL-Struktur, OIM-Schemata, Interpretation der ersten Cut-Set-Ergebnisse — bis die Modellierungs-Kompetenz intern steht.
-
Integration in bestehende Safety-Prozesse
MCSA integriert sich in Requirement-Management, Tracing und CI. Keine isolierte Tool-Insel.
-
Audit-Begleitung
Bei Bedarf direkt im Assessor-Gespräch vor Ort — als Tool-Verantwortlicher, nicht als Marketing-Stimme.
-
Deployment-Optionen
SaaS auf mcsa.appliedfusa.de oder On-Premise-Installation für vertrauliche Umgebungen (air-gapped möglich).
Make-vs-Buy auf einen Blick
Keine Karikatur, keine One-Way-Story — die Zeilen entsprechen realen Aufwänden aus Safety-Projekten. Eigenentwicklung ist eine legitime Option mit benennbaren Kosten.
| Aspekt | Eigenentwicklung | MCSA nutzen |
|---|---|---|
| Algorithmus-Implementierung | Mehrere Mensch-Monate C++-Arbeit (MOCUS, BDD, Minimierung). Algorithmen publiziert — kein Forschungsrisiko. | Abgeschlossen, live im Einsatz. |
| Tool Qualification nach ISO 26262-8 | Initialqualifikation typischerweise 3–6 Monate: Validierungsplan, Testkorpus, Evidenz, Dokumentation. | Abgeschlossen für v5.0.0; Evidenz auf Anfrage einsehbar. |
| Re-Qualifikation pro Release | Interne Verantwortung: Delta-Analyse plus Regressionstest bei jeder Änderung. | Bei jedem Release inkludiert. |
| Audit-Support | Intern durch das Team, das das Tool kennt — zusätzliche Personalbindung während Audits. | Durch den Tool-Entwickler, bei Bedarf vor Ort. |
| Modellierungsexpertise (FtaDSL, OIM) | Muss parallel zum Tool aufgebaut oder extern zugekauft werden. | Direkter Support beim Modellaufbau, bis das interne Know-how steht. |
| Time-to-First-Result | Mehrere Monate bis zum ersten qualifizierten Cut-Set-Ergebnis. | Wenige Tage nach Modell-Aufbau. |
| Laufende Wartung | Intern budgetieren: Bugs, Compiler-Wechsel, Tool-Chain-Updates. | Bestandteil der Nutzung. |
Wann eine Eigenentwicklung trotzdem sinnvoll sein kann
Make-vs-Buy hat keine allgemeingültige Antwort. Drei Konstellationen, in denen Eigenentwicklung ehrlich das bessere Vorgehen ist:
Großes Inhouse-Safety-Team mit langfristigem Bedarf
Eine einmalige Qualifikations-Investition amortisiert sich über Dutzende Projekte hinweg. Wer bereits eine Safety-Tool-Gruppe hat, die andere Tools pflegt, kann eine FTA-Engine konsequent ergänzen.
Bestehende Tool-Plattform-Strategie
Wenn eine eigene Safety-Toolchain gepflegt wird, in die FTA-Analyse nahtlos eingebettet werden soll (Shared Data Model, Single-Sign-On, gemeinsame CI), ist ein eigenes Tool die konsistente Wahl.
Forschung oder akademisches Umfeld
Wer Algorithmen erprobt, Varianten publiziert oder Studierende ausbildet, braucht volle Kontrolle über den Stack — eine qualifizierte Black Box ist hier das falsche Werkzeug.
Falls eine dieser Konstellationen zutrifft, lohnt ein Gespräch trotzdem — manchmal ist eine Teilnutzung (MCSA als Referenz-Implementierung während der Eigenentwicklung) die wirtschaftlichere Zwischenlösung.
Unverbindliches Gespräch oder Demo?
Wir klären in 30 Minuten, ob MCSA zu Ihrem Projekt passt — oder begründen, warum nicht. Ohne Verkaufsdruck.