Tworzyć samemu czy używać MCSA?
To uczciwe pytanie. MOCUS, BDD, minimalizacja cut-setów — algorytmy FTA są w literaturze od lat 70. Zespół z tłem safety i umiejętnościami C++ może zbudować silnik drzew błędów. Ta strona pokazuje, co naprawdę napędza decyzję: nie algorytmy, ale wszystko wokół nich.
Wysiłek nie leży w implementacji
Algorytmy to najmniejszy blok kosztów. Prawdziwym wąskim gardłem jest ISO 26262-8 Clause 11: kwalifikacja narzędzia. Bez tych dowodów narzędzie nie może zostać użyte w safety case.
-
Określenie Tool Confidence Level
Wyprowadzić TCL1/2/3 z Tool Impact (TI) i Tool Error Detection (TD) — im wyższy impact, tym bardziej wymagająca metoda kwalifikacji.
-
Wybór metody kwalifikacji
Dla TCL2/3 wybór między „Increased Confidence from Use", „Validation of the Software Tool", „Development in Accordance with a Safety Standard" lub „Evaluation of the Tool Development Process".
-
Wytwarzanie dowodów
Plan walidacji, test corpus z dowodami pokrycia, dowody regresji, traceability wymaganie-test, udokumentowane przypadki użycia i znane ograniczenia.
-
Re-kwalifikacja przy każdej zmianie
Każdy bugfix, feature lub upgrade kompilatora wymaga przynajmniej delta-analizy; większe zmiany wymagają pełnego cyklu re-kwalifikacji.
-
Obrona narzędzia w audytach klienta
Assessorzy OEM i Tier-1 oczekują udokumentowanych granic przypadków użycia i wskazanej osoby odpowiedzialnej za pytania o narzędzie podczas assessmentu.
Realistyczny wysiłek: kilka osobomiesięcy na początkową kwalifikację plus bieżące utrzymanie dla każdego release'u — niezależnie od tego, jak szybko można napisać same algorytmy.
MCSA jest skwalifikowany
MCSA jest dostępny jako skwalifikowane narzędzie safety — praca kwalifikacyjna została wykonana i jest utrzymywana w eksploatacji.
Skwalifikowany według ISO 26262-8
MCSA v5.0.0 jest skwalifikowany zgodnie z ISO 26262-8 Clause 11. Zakres kwalifikacji i granice przypadków użycia są udokumentowane.
Dowody dostępne na żądanie
Raport walidacji, dokumentacja przypadków użycia i dowody regresji są dostępne dla klientów i assessorów — pod NDA tam, gdzie wymagane.
Re-kwalifikowany przy każdym release
Każdy release MCSA przechodzi zdefiniowany cykl re-kwalifikacji przed wydaniem. Nowe wersje docierają do klientów bez narzutu kwalifikacji po ich stronie.
Wsparcie narzędzia podczas audytów
Uczestniczymy w rozmowach z assessorami i dostarczamy dowody na przypadki użycia, granice i znane ograniczenia — bezpośrednio przez tool developera.
Co MCSA dostarcza technicznie
Wyrażone jako outcomes — nie jako katalog algorytmów, ale jako to, na czym można polegać:
-
Wejście oparte na architekturze
Tekstowy, wersjonowalny opis FtaDSL z funkcjami, port'ami, interfejsami (INT) i semantyką propagacji błędu (OIM, literały COND, współczynniki ISF/SF/TF).
-
Automatyczna generacja drzewa błędów
Generowane z architektury — żadnej ręcznej konserwacji drzewa, brak kosztu synchronizacji między architekturą a FTA.
-
Minimalne cut-sety do wybranego rzędu
Z metrykami KPI (FCI, RRW, IMP, SEN, priorytet), markerami SPOF i analizą common-cause dla struktur transferowych.
-
Walidacja i interpretacja wspierana przez LLM
Niezależne sprawdzenie wiarygodności wejścia i wsparcie w interpretacji wyników. Sama analiza pozostaje deterministyczna i niezależna od LLM.
-
Reprodukowalne i auditable
To samo wejście, to samo wyjście. Każde obliczenie jest śledzialne — warunek dla safety case i audytu.
Co dostajesz jako klient — poza narzędziem
-
Kwalifikowana ekspertyza inżynieryjna
Tool developer to functional safety engineer, nie tylko software engineer. Odpowiedzi supportu pochodzą z perspektywy safety.
-
Wsparcie modelowania
Pomoc w ułożeniu struktury FtaDSL, schematów OIM i interpretacji pierwszych wyników cut-set — dopóki know-how modelowania nie jest in-house.
-
Integracja z istniejącymi procesami safety
MCSA integruje się z zarządzaniem wymaganiami, tracingiem i CI. Brak izolowanej wyspy narzędziowej.
-
Obecność audytowa na żądanie
On-site podczas rozmów z assessorami w razie potrzeby — jako tool owner, nie jako głos marketingowy.
-
Opcje wdrożenia
SaaS na mcsa.appliedfusa.de lub instalacja on-premise w środowiskach poufnych (możliwy air-gap).
Build vs. buy w skrócie
Bez karykatury, bez jednostronnej historii — wiersze odzwierciedlają realny wysiłek z projektów safety. Tworzenie samemu jest legitymizowaną opcją z możliwymi do nazwania kosztami.
| Aspekt | Tworzyć samemu | Używać MCSA |
|---|---|---|
| Implementacja algorytmów | Kilka osobomiesięcy pracy w C++ (MOCUS, BDD, minimalizacja). Algorytmy są opublikowane — brak ryzyka badawczego. | Zrobione, w użyciu live. |
| Kwalifikacja narzędzia wg ISO 26262-8 | Początkowa kwalifikacja zwykle 3–6 miesięcy: plan walidacji, test corpus, dowody, dokumentacja. | Zakończona dla v5.0.0; dowody dostępne na żądanie. |
| Re-kwalifikacja per release | Odpowiedzialność wewnętrzna: delta-analiza plus testy regresji przy każdej zmianie. | Zawarte w każdym release. |
| Wsparcie audytów | Obsługiwane wewnętrznie przez zespół, który zna narzędzie — dodatkowe związanie zasobów podczas audytów. | Obsługiwane przez tool developera, on-site w razie potrzeby. |
| Ekspertyza modelowania (FtaDSL, OIM) | Trzeba budować równolegle z narzędziem — albo nabyć zewnętrznie. | Bezpośrednie wsparcie modelowania, dopóki know-how nie jest in-house. |
| Time-to-first-result | Kilka miesięcy do pierwszego skwalifikowanego wyniku cut-set. | Kilka dni po skonfigurowaniu modelu. |
| Bieżące utrzymanie | Przewidzieć budżetowo wewnętrznie: bugi, upgrade kompilatora, aktualizacje toolchain. | Część usługi. |
Kiedy tworzenie samemu jest mimo wszystko właściwym wyborem
Build vs. buy nie ma uniwersalnej odpowiedzi. Trzy konstelacje, w których tworzenie samemu jest uczciwie lepszą drogą:
Duży wewnętrzny zespół safety z długoterminowym zapotrzebowaniem
Jednorazowa inwestycja kwalifikacyjna amortyzuje się na dziesiątkach projektów. Jeśli już prowadzisz grupę safety tools utrzymującą inne narzędzia, silnik FTA jest spójnym rozszerzeniem.
Istniejąca strategia tool-platform
Jeśli Twoja organizacja utrzymuje toolchain safety, w który analiza FTA musi się wpasować (wspólny model danych, single sign-on, wspólny CI), narzędzie wewnętrzne jest spójnym wyborem.
Kontekst badawczy lub akademicki
Jeśli prototypujesz algorytmy, publikujesz warianty lub uczysz studentów, potrzebujesz pełnej kontroli nad stosem — skwalifikowana czarna skrzynka to niewłaściwy instrument.
Jeśli któraś z tych konstelacji do Ciebie pasuje, rozmowa i tak ma sens — czasami częściowe użycie (MCSA jako referencyjna implementacja podczas własnego rozwoju) jest bardziej ekonomicznym etapem przejściowym.
Niezobowiązująca rozmowa lub demo?
W 30 minutach wyjaśnimy, czy MCSA pasuje do Twojego projektu — albo wytłumaczymy, dlaczego nie. Bez presji sprzedażowej.