Build your own, or use MCSA?
It is a fair question. MOCUS, BDD, cut-set minimisation — FTA algorithms have been in the literature since the 1970s. A team with safety background and C++ skills can build a fault-tree engine. This page lays out what really drives the decision: not the algorithms, but everything around them.
The effort is not in the implementation
The algorithms are the smallest cost block. The real bottleneck sits in ISO 26262-8 Clause 11: tool qualification. Without that evidence, the tool cannot be used in the safety case.
-
Determine the Tool Confidence Level
Derive TCL1/2/3 from Tool Impact (TI) and Tool Error Detection (TD) — the higher the impact, the more demanding the qualification method.
-
Choose a qualification method
For TCL2/3, decide between „Increased Confidence from Use", „Validation of the Software Tool", „Development in Accordance with a Safety Standard", or „Evaluation of the Tool Development Process".
-
Produce the evidence
Validation plan, test corpus with coverage evidence, regression evidence, requirement-to-test tracing, documented use cases and known limitations.
-
Re-qualify on every change
Every bugfix, feature, or compiler upgrade demands at least a delta analysis; larger changes need a full re-qualification pass.
-
Defend the tool in customer audits
OEM and Tier-1 assessors expect documented use-case boundaries and a named responsible contact for tool questions during the assessment.
Realistic effort: several person-months for the initial qualification, plus ongoing upkeep for each release — independent of how fast the algorithms themselves can be written.
MCSA is qualified
MCSA is available as a qualified safety tool — the qualification work has been done and is maintained in operation.
Qualified per ISO 26262-8
MCSA v5.0.0 is qualified according to ISO 26262-8 Clause 11. Qualification scope and use-case boundaries are documented.
Evidence available on request
Validation report, use-case documentation, and regression evidence are available for customers and assessors — under NDA where required.
Re-qualified on every release
Every MCSA release runs through the defined re-qualification pass before shipping. New versions reach customers without qualification overhead on their side.
Tool support during audits
We sit in on assessor conversations and provide evidence on use cases, boundaries, and known limitations — directly through the tool developer.
What MCSA delivers technically
Stated as outcomes — not as an algorithm catalogue, but as what you can rely on:
-
Architecture-based input
Textual, version-controllable FtaDSL description with functions, ports, interfaces (INT), and fault-propagation semantics (OIM, COND literals, ISF/SF/TF rates).
-
Automated fault-tree generation
Generated from the architecture — no manual tree maintenance, no sync cost between architecture and FTA.
-
Minimal cut sets up to the chosen order
With KPI metrics (FCI, RRW, IMP, SEN, priority), SPOF markers, and common-causes analysis for transfer structures.
-
LLM-assisted validation and interpretation
Independent plausibility check of the input and assistance with interpreting the results. The analysis itself stays deterministic and independent of the LLM.
-
Reproducible and auditable
Same input, same output. Every calculation is traceable — a prerequisite for safety case and audit.
What you get as a customer — beyond the tool
-
Qualified engineering expertise
The tool developer is a functional safety engineer, not just a software engineer. Support answers come from the safety perspective.
-
Modelling support
Help with setting up the FtaDSL structure, the OIM schemas, and interpreting the first cut-set results — until the modelling know-how exists in-house.
-
Integration into existing safety processes
MCSA integrates with requirements management, tracing, and CI. No isolated tool island.
-
Audit presence on request
On-site during assessor conversations if needed — as tool owner, not marketing voice.
-
Deployment options
SaaS on mcsa.appliedfusa.de or on-premise installation for confidential environments (air-gapped possible).
Build vs. buy at a glance
No caricature, no one-way story — the rows reflect real effort from safety projects. Building your own is a legitimate option with nameable costs.
| Aspect | Build your own | Use MCSA |
|---|---|---|
| Algorithm implementation | Several person-months of C++ work (MOCUS, BDD, minimisation). Algorithms are published — no research risk. | Done, live in use. |
| Tool qualification per ISO 26262-8 | Initial qualification typically 3–6 months: validation plan, test corpus, evidence, documentation. | Completed for v5.0.0; evidence available on request. |
| Re-qualification per release | Internal responsibility: delta analysis plus regression testing on every change. | Included with every release. |
| Audit support | Handled internally by the team that knows the tool — additional staff binding during audits. | Handled by the tool developer, on-site if needed. |
| Modelling expertise (FtaDSL, OIM) | Must be built up in parallel with the tool — or bought in externally. | Direct modelling support until the know-how is in-house. |
| Time-to-first-result | Several months to the first qualified cut-set result. | A few days after the model is set up. |
| Ongoing maintenance | Budget internally: bugs, compiler upgrades, toolchain updates. | Part of the service. |
When building your own is still the right call
Build vs. buy has no universal answer. Three constellations in which building your own is honestly the better path:
A large in-house safety team with long-term demand
A one-time qualification investment amortises across dozens of projects. If you already run a safety tools group maintaining other tools, an FTA engine is a consistent extension.
An existing tool-platform strategy
If your organisation maintains a safety toolchain that FTA analysis must embed into (shared data model, single sign-on, joint CI), an in-house tool is the consistent choice.
Research or academic context
If you prototype algorithms, publish variants, or teach students, you need full control over the stack — a qualified black box is the wrong instrument.
If one of these constellations fits you, a conversation is still worthwhile — sometimes partial use (MCSA as a reference implementation during your own development) is the more economical intermediate step.
An informal conversation or a demo?
In 30 minutes we will clarify whether MCSA fits your project — or explain why it does not. No sales pressure.