Aus deinem Architektur- und Fehlermodell: Fehlerbaum (IEC 61025), FMEA, priorisierte Cut-Sets, Common-Cause und Bericht. Vier Wege zum Modell — Editor, Chat, Quellcode oder Simulink.
Deterministische Engines — sie rechnen, sie raten nicht.
Das Problem
FTA und FMEA von Hand sind langsam und fehleranfällig.
Sicherheitsanalysen entstehen heute in Tabellen und Zeichenwerkzeugen — manuell gepflegt, schwer aktuell zu halten, kaum reproduzierbar.
01Jede Architekturänderung bricht den Fehlerbaum — die Pflege frisst Wochen.
02Cut-Sets, Common-Cause und Priorisierung werden von Hand kuratiert und veralten.
03Reviews stolpern über inkonsistente Tabellen statt über echte Sicherheitsfragen.
Der Kern
Vier Wege zum Modell, eine deterministische Analyse.
Wie du zum Modell kommst, ist deine Wahl. Was hinten herauskommt, ist immer dasselbe: ein Fehlerbaum nach IEC 61025 und eine FMEA — gerechnet, nicht geraten.
Im Studio schreiben Live
Modell direkt im Studio-Canvas als FtaDSL/FmeaDSL schreiben — strukturiert, versionierbar, sofort prüfbar.
Aus Prosa erzeugen Live
rfChat erzeugt die DSLs aus deiner Beschreibung. Du formulierst den Fall in Worten, das Modell entsteht strukturiert.
Aus dem Code rekonstruieren Pilot
rfRecover rekonstruiert das Modell aus deinem Quellcode. Heute im Pilot — der Einstieg für bestehende Codebasen.
Aus dem Simulink-Modell Live
Lade ein .slx hoch, wähle im Chat die Fehlfunktion — die Architektur wird gelesen und in FTA überführt. Unten ausprobierbar.
münden in FtaDSL / FmeaDSL → FTA + FMEA
Auf eine Kachel klicken zum Starten · „?“ für Details
Das Ziel ist der Kern: ein Fehlerbaum (mcsa + fta-render) und eine FMEA. Die vier Wege sind nur, wie du dort hinkommst.
Was du bekommst
Ehrlich gestaffelt: was heute geliefert wird — und was kommt.
Geliefert — der FTA/FMEA-Kern
Live
Heute real und live.
→Fehlerbaum nach IEC 61025Symbolik strikt nach IEC 61025, als SVG und PDF — sauber gesetzt, prüffähig.
→Priorisierte Cut-Set-ListeMinimal-Cut-Sets, nach Relevanz geordnet.