What Is Model-Based Safety Analysis?

Safety analysis has a consistency problem. On most large programs, the fault tree for a given system lives in one document, the FMEA lives in another, and the system architecture that both of them are supposed to describe lives in a SysML model or, worse, a third document. When the architecture changes — and it always changes — someone has to remember to update all three, in the right order, without introducing contradictions. On programs with hundreds of subsystems and thousands of failure modes, that process breaks down systematically.

Model-based safety analysis (MBSA) addresses this by making the architecture model the authoritative source. Instead of creating safety artifacts independently and then reconciling them against the design, MBSA derives those artifacts directly from a formal system model. The fault tree is generated from the model. The FMEA is populated from the model. Reliability block diagrams are computed from the model. When the architecture changes, the safety analysis updates with it, because the analysis and the architecture are the same artifact viewed through different lenses.

This is not a subtle process improvement. It is a structural change in how safety engineers relate to systems engineers, and it has significant implications for how programs are organized, what tools they use, and where requirements management fits in the workflow.

Core Concepts

What Makes an Analysis “Model-Based”

A safety analysis is model-based when it meets three conditions. First, the system under analysis is represented in a formal, machine-readable language with defined semantics — not a diagram, not a Word document, but a notation the toolchain can parse, query, and reason about. Second, safety properties — failure modes, propagation paths, fault conditions — are defined as attributes or annotations within that same model rather than in separate documents. Third, safety artifacts (fault trees, FMEAs, Markov chains, FMEDA reports) are generated algorithmically from the model rather than authored manually.

The practical consequence: a change to a component’s failure rate, a new redundancy path added by a systems engineer, or a revised functional allocation all propagate automatically into downstream safety calculations. The safety engineer’s job shifts from maintaining documents to building and validating the model.

This is categorically different from using a model as a communication aid or a drawing. A block diagram in Visio that someone uses to think through a fault tree is not MBSA. A system model authored in AltaRica from which a tool automatically generates the minimal cut sets is.

AltaRica and AADL: The Two Dominant Formal Languages

Two formal languages dominate the MBSA landscape in aerospace and automotive. They were designed for different problems and operate at different levels of abstraction, but both are genuinely deployed on production programs.

AltaRica was developed specifically for safety analysis. It models systems as networks of automata — components with discrete states and transition rules — and is particularly suited to expressing failure propagation and reconfiguration logic. The language has a direct mathematical relationship to fault trees and Markov chains, which means tools like Isograph, OpenAltaRica, and OSATE Safety Annex can compute those artifacts automatically. AltaRica is the dominant choice on European civil aviation programs, and its use is explicitly encouraged in EASA guidance material related to ARP4761A.

AADL (Architecture Analysis and Design Language) takes a broader scope. It was standardized by SAE and is used to model both the software and hardware architecture of safety-critical embedded systems — processors, buses, tasks, threads, and their timing and resource properties. The Error Model Annex (EMV2) extends AADL with failure behavior semantics, allowing it to serve as an MBSA substrate. AADL is common on U.S. aerospace and defense programs and is recognized by the FAA as a valid analysis approach under certain certification frameworks.

Neither language is beginner-friendly. Both require dedicated tooling, trained practitioners, and deliberate integration with the broader MBSE environment. Organizations that succeed with MBSA invest in that infrastructure before they need it, not during a certification campaign.

The Relationship Between MBSA and MBSE

MBSE and MBSA are often conflated, but the distinction is important. MBSE (model-based systems engineering) is concerned with defining what a system is: its functions, components, interfaces, requirements, and operational scenarios. The canonical MBSE output is a system architecture model, typically in SysML or a domain-specific variant.

MBSA is concerned with what can go wrong with that system and what the consequences are. It queries the MBSE architecture model for the information it needs — component boundaries, redundancy topology, interface dependencies — and adds failure behavior on top of it.

The relationship is directional: MBSE produces the architecture that MBSA analyzes. Good MBSE practice makes MBSA tractable. Poor MBSE practice — incomplete interface definitions, ambiguous functional allocations, missing redundancy specifications — creates gaps that safety engineers have to fill manually, which reintroduces the document problem MBSA was supposed to solve.

This directional dependency is why the MBSE-MBSA integration point is one of the most consequential tool selection decisions a program makes. If the MBSE environment and the MBSA environment cannot exchange model data without manual transcription, the consistency benefit largely evaporates.

Regulatory Context: Why Programs Are Adopting MBSA Now

MBSA is not new — AltaRica has been in research use since the late 1990s. What has changed is regulatory pressure and program scale.

Civil aviation is the clearest case. ARP4761A, the SAE recommended practice for safety assessment of civil airborne systems, explicitly acknowledges model-based methods as valid approaches to FHA, PSSA, and SSA. The standard does not mandate MBSA, but it does require that safety analyses be consistent with the system architecture and traceable to system requirements. On a modern commercial aircraft program with millions of components and thousands of failure conditions, maintaining that consistency manually is not credible. Certification authorities are increasingly scrutinizing the consistency and completeness of safety analyses, and programs that can demonstrate automated consistency through MBSA have a measurable advantage in the certification process.

Automotive follows a parallel trajectory under ISO 26262 and, for software-defined systems, ISO/SAE 21434. ISO 26262 requires FMEA and FTA as part of the functional safety concept and technical safety concept phases. It does not prescribe MBSA, but it does require traceability between safety requirements, the safety concept, and the design — a requirement that model-based methods satisfy more reliably than document-based ones. Tier-1 suppliers are increasingly requiring MBSA-capable tools from their own suppliers as a condition of program award.

Space and defense programs, particularly those under DO-254 for airborne electronic hardware and MIL-STD-882 for system safety, are adopting MBSA at the program level for similar reasons: scale, complexity, and the cost of certification finding resolution late in development.

The Upstream Layer: Requirements and MBSA

MBSA operates on system architecture models. But every architecture model is built to satisfy requirements — functional requirements, performance requirements, safety requirements — that precede the architecture in the development sequence. This upstream layer, the definition of what the system must do and what it must not do, is where the quality of downstream MBSA is largely determined.

A well-structured requirement for a flight control system does not just say “the system shall provide roll control.” It specifies the failure conditions under which roll control must be maintained, the tolerable hazard rates for each failure condition, and the independence requirements for redundant paths. These attributes become the formal safety requirements that the MBSA model is built to satisfy. If they are ambiguous, inconsistent, or untraced to the hazard analysis that generated them, the MBSA model is built on a weak foundation.

This is the gap that requirements platforms designed for hardware and systems engineering are built to close. Flow Engineering, which structures requirements as connected nodes in a graph rather than rows in a document, is designed specifically to carry this upstream context. A requirement in Flow Engineering is not an isolated sentence — it is a node connected to the hazard it mitigates, the functional architecture it constrains, the verification method that will validate it, and the system component that implements it. That connected structure is precisely what an MBSA toolchain needs as an input: not a list of text strings, but a semantic graph of what the system must do and why.

When safety requirements come from a platform that enforces this structure, MBSA tools receive better inputs. Failure mode coverage is more complete because the hazard-to-requirement traceability is explicit. Requirement changes are visible to the safety team because the graph shows what depends on what. Certification evidence is stronger because the link from hazard analysis through safety requirement through architecture model through verified test is continuous and documented.

Flow Engineering does not perform safety analysis — it does not compute fault trees or calculate failure rates. Its role is to provide the structured, traceable upstream layer that makes MBSA productive rather than painful. That division of responsibility is appropriate. The requirement to “provide roll control under two simultaneous hydraulic failures with a probability of no greater than 10⁻⁹ per flight hour” is a statement about what the system must do. Whether a given architecture satisfies that requirement under all failure combinations is the question AltaRica or AADL answers. Both questions matter. Neither tool should try to answer both.

Where to Start

Organizations approaching MBSA for the first time face a real sequencing problem. The methods are mature, the tools exist, and the regulatory benefits are clear — but the organizational and modeling investment is substantial. A few practical observations from programs that have made this transition successfully:

Start with the hazard analysis, not the architecture model. The most valuable early investment in MBSA is a structured, tool-supported hazard analysis with explicit traceability to safety requirements. This gives the MBSA model a clear set of properties to satisfy and makes the eventual model-building exercise tractable.

Choose a formal language based on your certification path, not on tool availability. AltaRica and AADL EMV2 are not interchangeable. AltaRica is better suited to failure propagation and functional safety analysis; AADL is better suited to hardware-software integration analysis. Your certification authority’s expectations should drive the choice.

Invest in the MBSE-MBSA integration point early. If your MBSE environment cannot export architecture data in a format your MBSA tool can import without manual transcription, plan the integration work before the safety campaign begins, not during it.

Treat requirements structure as a first-class MBSA input. The quality of your safety requirements — their specificity, their traceability to hazards, their connection to the architecture they constrain — determines the quality of your MBSA model. A requirements platform that enforces graph-connected structure is not a nice-to-have; it is part of the MBSA infrastructure.

MBSA is not a shortcut. It is a more rigorous, more consistent, more scalable approach to safety analysis than the document-based alternative. Programs that adopt it correctly will find that certification campaigns are faster, architecture changes are less expensive, and the safety case is more defensible. Programs that adopt it superficially — buying MBSA tools without building the upstream requirements and MBSE infrastructure to feed them — will find that they have added tool complexity without adding analytical rigor. The method is sound. The infrastructure around it is what determines whether it works.