Sviluppare in proprio o usare MCSA?
È una domanda legittima. MOCUS, BDD, minimizzazione dei cut-set — gli algoritmi FTA sono in letteratura dagli anni '70. Un team con background di sicurezza e competenze C++ può costruire un motore di alberi dei guasti. Questa pagina mostra cosa guida davvero la decisione: non gli algoritmi, ma tutto ciò che li circonda.
Lo sforzo non è nell'implementazione
Gli algoritmi sono il blocco di costo più piccolo. Il vero collo di bottiglia sta nella ISO 26262-8 Clausola 11: la qualifica dello strumento. Senza quella prova, lo strumento non può essere usato nel safety case.
-
Determinare il Tool Confidence Level
Derivare TCL1/2/3 dal Tool Impact (TI) e dalla Tool Error Detection (TD) — più alto è l'impatto, più impegnativo è il metodo di qualifica.
-
Scegliere un metodo di qualifica
Per TCL2/3, decidere fra „Increased Confidence from Use", „Validation of the Software Tool", „Development in Accordance with a Safety Standard" o „Evaluation of the Tool Development Process".
-
Produrre le evidenze
Piano di validazione, test corpus con evidenze di copertura, evidenze di regressione, tracciatura requisito-test, casi d'uso documentati e limitazioni note.
-
Ri-qualificare ad ogni modifica
Ogni bugfix, feature o upgrade del compilatore richiede almeno una delta-analysis; modifiche più ampie richiedono un giro completo di ri-qualifica.
-
Difendere lo strumento negli audit cliente
Gli assessor di OEM e Tier-1 si aspettano confini di casi d'uso documentati e un referente nominato per le domande sullo strumento durante l'assessment.
Sforzo realistico: diversi mesi-uomo per la qualifica iniziale, più la manutenzione continua per ciascuna release — indipendentemente da quanto velocemente si possano scrivere gli algoritmi stessi.
MCSA è qualificato
MCSA è disponibile come strumento di sicurezza qualificato — il lavoro di qualifica è stato fatto e viene mantenuto in operatività.
Qualificato secondo ISO 26262-8
MCSA v5.0.0 è qualificato secondo ISO 26262-8 Clausola 11. Lo scope di qualifica e i confini dei casi d'uso sono documentati.
Evidenze disponibili su richiesta
Rapporto di validazione, documentazione dei casi d'uso ed evidenze di regressione sono disponibili per clienti e assessor — sotto NDA dove richiesto.
Ri-qualificato ad ogni release
Ogni release MCSA passa per il giro di ri-qualifica definito prima del rilascio. Le nuove versioni raggiungono i clienti senza overhead di qualifica da parte loro.
Supporto strumento durante gli audit
Partecipiamo alle conversazioni con gli assessor e forniamo evidenze su casi d'uso, confini e limitazioni note — direttamente attraverso il tool developer.
Cosa offre MCSA tecnicamente
Espresso come outcome — non come catalogo di algoritmi, ma come ciò su cui ci si può affidare:
-
Input basato sull'architettura
Descrizione testuale e versionabile in FtaDSL con funzioni, port, interfacce (INT) e semantica di propagazione del guasto (OIM, letterali COND, tassi ISF/SF/TF).
-
Generazione automatica dell'albero dei guasti
Generato dall'architettura — nessuna manutenzione manuale dell'albero, nessun costo di sincronizzazione fra architettura e FTA.
-
Minimal cut-set fino all'ordine scelto
Con metriche KPI (FCI, RRW, IMP, SEN, priorità), marker SPOF e analisi common-cause per strutture transfer.
-
Validazione e interpretazione assistita da LLM
Verifica indipendente di plausibilità dell'input e assistenza nell'interpretare i risultati. L'analisi rimane deterministica e indipendente dall'LLM.
-
Riproducibile e auditable
Stesso input, stesso output. Ogni calcolo è tracciabile — un prerequisito per safety case e audit.
Cosa ottieni come cliente — oltre allo strumento
-
Expertise ingegneristica qualificata
Il tool developer è un functional safety engineer, non solo un software engineer. Le risposte di supporto arrivano dalla prospettiva della sicurezza.
-
Supporto alla modellazione
Aiuto nell'impostare la struttura FtaDSL, gli schemi OIM e nell'interpretare i primi risultati di cut-set — finché il know-how di modellazione non è interno.
-
Integrazione nei processi di sicurezza esistenti
MCSA si integra con la gestione dei requisiti, il tracing e il CI. Nessuna isola di strumenti.
-
Presenza in audit su richiesta
On-site durante le conversazioni con gli assessor se necessario — come tool owner, non come voce di marketing.
-
Opzioni di deployment
SaaS su mcsa.appliedfusa.de oppure installazione on-premise per ambienti riservati (air-gapped possibile).
Build vs. buy in sintesi
Niente caricature, nessuna storia a senso unico — le righe riflettono lo sforzo reale di progetti di sicurezza. Sviluppare in proprio è un'opzione legittima con costi nominabili.
| Aspetto | Sviluppo proprio | Usare MCSA |
|---|---|---|
| Implementazione algoritmica | Diversi mesi-uomo di lavoro C++ (MOCUS, BDD, minimizzazione). Gli algoritmi sono pubblicati — nessun rischio di ricerca. | Fatto, in uso live. |
| Qualifica strumento secondo ISO 26262-8 | Qualifica iniziale tipicamente 3–6 mesi: piano di validazione, test corpus, evidenze, documentazione. | Completata per v5.0.0; evidenze disponibili su richiesta. |
| Ri-qualifica per release | Responsabilità interna: delta-analysis più test di regressione ad ogni modifica. | Inclusa in ogni release. |
| Supporto agli audit | Gestito internamente dal team che conosce lo strumento — vincolo aggiuntivo di personale durante gli audit. | Gestito dal tool developer, on-site se necessario. |
| Expertise di modellazione (FtaDSL, OIM) | Va costruita in parallelo allo strumento — oppure acquisita esternamente. | Supporto diretto alla modellazione finché il know-how non è interno. |
| Time-to-first-result | Diversi mesi al primo risultato di cut-set qualificato. | Pochi giorni dopo l'impostazione del modello. |
| Manutenzione continua | Da prevedere internamente: bug, upgrade del compilatore, aggiornamenti della toolchain. | Parte del servizio. |
Quando sviluppare in proprio è comunque la scelta giusta
Build vs. buy non ha una risposta universale. Tre costellazioni in cui sviluppare in proprio è onestamente la strada migliore:
Un grande team di sicurezza interno con domanda a lungo termine
Un investimento di qualifica una tantum si ammortizza su decine di progetti. Se gestisci già un gruppo di safety tools che mantiene altri strumenti, un motore FTA è un'estensione coerente.
Una strategia di tool-platform già esistente
Se la tua organizzazione mantiene una toolchain di sicurezza in cui l'analisi FTA deve integrarsi (modello dati condiviso, single sign-on, CI condiviso), uno strumento interno è la scelta coerente.
Contesto di ricerca o accademico
Se prototipizzi algoritmi, pubblichi varianti o insegni agli studenti, ti serve il pieno controllo dello stack — una black-box qualificata è lo strumento sbagliato.
Se una di queste costellazioni si applica a te, vale comunque la pena fare una conversazione — a volte un uso parziale (MCSA come implementazione di riferimento durante lo sviluppo proprio) è il passaggio intermedio più economico.
Una conversazione informale o una demo?
In 30 minuti chiariremo se MCSA si adatta al tuo progetto — oppure spiegheremo perché no. Senza pressione di vendita.