For years the safety case lived in a different building from the architecture model. Systems engineers built their structure in SysML or Capella, and safety engineers rebuilt a parallel picture of the same system in fault trees and FMEA spreadsheets, by hand, usually late, usually from a PDF. When the design changed, the two pictures drifted apart. Model-based safety analysis is the attempt to close that gap by letting both teams work off one model. With the December 2023 release of SAE ARP4761A, that approach finally has a recognized place in aerospace practice.
What MBSA actually means
Model-based safety analysis (MBSA) is an approach where system and safety engineers share a common system model rather than maintaining separate artifacts. You take the architecture model, extend it with a fault model that describes how components fail and how those failures propagate, and then generate the safety analysis from that combined description. Instead of drawing a fault tree by hand, you derive it.
The payoff is consistency. When the failure logic lives in the model, a fault tree and an FMEA become two views of the same underlying data, not two documents that someone has to reconcile. It also makes scenario analysis tractable: you can simulate how the system behaves under different combinations of faults and see which ones lead to a hazardous outcome, which is hard to do thoroughly with static spreadsheets.
This is not a brand-new research idea. Formalisms like AltaRica and tools like xSAP have supported automated safety assessment for years. What changed recently is that the industry standards caught up.
Why ARP4761A is the inflection point
ARP4761 is the document aerospace teams use to demonstrate compliance with airworthiness rules like 14 CFR 25.1309 and EASA CS-25.1309. It defines the safety assessment process: Functional Hazard Assessment, Preliminary System Safety Assessment, System Safety Assessment, and Common Cause Analysis. It works alongside ARP4754B, which covers development assurance.
The 2023 revision, ARP4761A, did two things that matter here. First, it formally introduced model-based safety assessment as a recognized method alongside the traditional ones like fault tree analysis. Second, it put more weight on aircraft-level analysis, adding explicit sections for Aircraft Functional Hazard Analysis, Preliminary Aircraft Safety Assessment, and Aircraft Safety Assessment, and spelling out how the aircraft level and system level relate.
That combination is the real signal. A certification-relevant standard now describes MBSA as an acceptable way to do the work, which gives engineering managers cover to invest in it. ARP4761A is one of the first comprehensive industry standards to incorporate detailed MBSA guidance, and the fact that it sits inside the certification path is what moves it from interesting to fundable.
Where it connects to your MBSE model
The whole premise depends on a model good enough to attach failure behavior to. That means a clean functional and physical architecture, defined interfaces, and traceable allocation of functions to components. If your architecture model is already disciplined, MBSA extends it. If it's a loose collection of diagrams, the fault model has nothing solid to attach to.
In practice the architecture usually lives in one tool and the safety analysis in another, with a defined exchange between them. Teams build the structure in environments like Dassault Cameo Systems Modeler, Eclipse Capella, or Dalus, then feed that architecture into dedicated safety tooling such as Ansys medini analyze or a Capella add-on like Safety Architect. The link between the two is the thing that makes or breaks the workflow. If the architecture and the failure model share identifiers and stay synchronized, the safety case updates when the design does. If the connection is a manual export, you've reintroduced the drift you were trying to eliminate, just with extra steps.
This is also where the digital thread argument shows up. A failure mode that traces back to a specific function, which traces to a requirement, which traces to a verification activity, is far more useful during a certification review than a standalone fault tree. The value isn't the diagram. It's the connective tissue.
What it won't solve
MBSA does not replace safety engineering judgment, and treating it as automation is the fastest way to get burned. The model only knows the failure modes you put into it. If an engineer doesn't think to model a particular degradation path or a subtle common-cause coupling, no amount of automated fault-tree generation will surface it. Garbage in, certified-looking garbage out.
The tooling story is also less mature than vendors suggest. Standards harmonization across ARP4761A, ARP4754B, and the various modeling and safety tools is still uneven, and getting two tools to exchange a fault model cleanly often involves custom glue code, brittle APIs, and a lot of configuration management to make sure both sides are talking about the same baseline. Specifying the exact configuration of the datasets you're linking is not a nice-to-have here; mismatched baselines quietly invalidate the analysis.
There's a skills gap too. MBSA sits at the intersection of systems modeling and safety analysis, and engineers who are genuinely fluent in both are rare. Adopting it usually means pairing a modeler with a safety specialist for a while until the practices settle, which is a real cost that doesn't show up in a tool demo.
And it's not free of certification risk. A novel method still has to satisfy the certification authority. The standard recognizing MBSA helps, but you still have to show that your specific use of it is rigorous, repeatable, and produces evidence an assessor will accept. Early adopters should expect more conversation with their authority, not less.
How to start without overcommitting
The sensible entry point is a single subsystem with well-understood failure behavior, not a whole aircraft. Build the fault model on top of an architecture you already trust, generate a fault tree, and compare it against the one your safety team produced by hand. The discrepancies are the most valuable output of the whole exercise: they tell you where your architecture model is ambiguous and where your manual analysis made assumptions nobody wrote down.
From there, the work is mostly about the connection between tools and about configuration discipline, not about the modeling formalism itself. Get the exchange reliable and the baselines pinned, and the analysis becomes something you can rerun on every design change instead of something you redo before every milestone.
Bottom line
ARP4761A didn't invent model-based safety analysis, but it gave it a recognized seat in the aerospace certification process, and that's what makes 2026 a reasonable time to take it seriously. The technique earns its keep when your architecture model is disciplined enough to carry failure behavior and when the link between modeling and safety tools is tight enough to stay honest as the design moves. It won't do the thinking for you, and it won't certify itself. Treated as a way to keep one source of truth instead of two drifting documents, it's a real improvement. Treated as a button that prints a safety case, it'll let you down at the worst possible moment.