Software teams meet the Design Assurance Level as a fact handed to them: this is Level B, plan accordingly. Where it came from is usually opaque, which makes it hard to tell a level that is genuinely required from one that is an artefact of how the system was drawn.

This is the chain that produces it, in plain terms, and the two places a software team can legitimately influence the answer.

The question the safety process is answering

The whole apparatus exists to answer one question: what happens to the aircraft if this function goes wrong, and have we made that sufficiently unlikely? Everything else — the acronyms, the assessments, the levels — is bookkeeping in service of that.

It runs top-down, from the aircraft to the system to the item, and the software level falls out at the bottom.

The aircraft safety-assessment chain: FHA, PSSA and SSA allocating DAL down to software, with CCA alongside CCA Common Cause Analysis (alongside) FHA Functional Hazard Assessment PSSA Preliminary System Safety Assessment SSA System Safety Assessment DAL allocation Software DAL flows down to development
The assessment chain. Software receives a level; it does not choose one.

FHA: what breaks, and how badly

The Functional Hazard Assessment lists the aircraft's functions and asks, for each failure condition, how severe the effect would be. It is done at aircraft level first and then at system level, and it happens early — before there is a design to assess, which is precisely the point.

Severity is classified on a fixed scale, and each class carries a target for how improbable that failure condition must be.

Severity Effect on aircraft and occupants Must be no more frequent than
Catastrophic Would prevent continued safe flight and landing Extremely improbable (of the order of 10⁻⁹ per flight hour)
Hazardous Large reduction in safety margins; serious or fatal injury to a small number of occupants Extremely remote (10⁻⁷ to 10⁻⁹)
Major Significant reduction in safety margins; occupant discomfort, possibly minor injuries Remote (10⁻⁵ to 10⁻⁷)
Minor Slight reduction in safety margins; routine crew workload increase Probable (more frequent than 10⁻⁵)
No safety effect No effect on operational capability or crew workload No target
Severity classes and their probability targets. These are the transport-category figures; other aircraft categories use different targets, so check the certification basis that actually applies to your programme.

PSSA: allocating the requirement downward

The Preliminary System Safety Assessment takes the failure conditions from the FHA and works out what the architecture must do to meet them. It is where the assurance levels are actually allocated to the items that implement each function — the hardware, and the software.

This is the step that decides your DAL. It is also, crucially, done against a proposed architecture, which means the answer depends on a design that is still changeable.

SSA: showing it actually came out that way

The System Safety Assessment is the closing argument: given the design as built, were the objectives from the FHA met? Alongside it, Common Cause Analysis checks the assumption that everything the architecture treats as independent really is — that two channels do not share a power supply, a connector, or a software component nobody noticed they had in common.

Assessment Produced by When What it settles
FHA (aircraft, then system) Safety, with systems Earliest — before design How severe each failure condition is
PSSA Safety, with systems Against the proposed architecture What the architecture must do; the assurance level for each item
CCA Safety Alongside PSSA and SSA Whether things assumed independent actually are
SSA Safety Against the design as built Whether the objectives were met
Who produces what, and roughly when.

Architecture is the lever — the only real one

If a level looks too high for the function, the productive response is not to argue about the level. It is to change the system so that software failure no longer produces the severe outcome on its own.

How architecture lowers a software assurance level: a single function whose failure leads directly to a severe effect carries DAL A, but the same function protected by an independent monitor that must also fail before the effect occurs carries only DAL C — architecture, not negotiation, is what lowers the DAL No monitor Function Software item Severe effect Hazardous failure DAL A High assurance With monitor Function Monitor Severe effect Only if BOTH fail DAL C Reduced assurance Independence lowers the function's own DAL The monitor still needs its own independent assurance
An independent monitor means a software error alone no longer produces the severe effect, so the level allocated to that software can fall.

Monitors, partitioning, dissimilarity and hardware interlocks all work the same way: they break the path from a single software error to the hazardous outcome. What matters is that the mitigating element is genuinely independent — a monitor that shares the processor, the compiler and the requirements set with the thing it monitors is not buying you what you think it is, and Common Cause Analysis exists to catch exactly that.

The economics are brutal and worth stating plainly: this conversation costs almost nothing during the PSSA and is close to impossible once code exists and the architecture is frozen.

Derived requirements travel back up

The chain is not purely one-way. Requirements invented during software design — decisions with no parent requirement above them, which DO-178C calls derived requirements — must be given back to the safety process, because the people who assessed the hazards could not have accounted for something the software team had not invented yet.

What a software team should actually do

  1. Ask to see the FHA and PSSA. Not to challenge them, but because they contain the assumptions your software is expected to honour. Teams routinely build to a level without ever reading why it is that level.
  2. Raise architectural concerns before the PSSA is baselined. That is the window; it closes quietly.
  3. Track the assumptions. A PSSA typically assumes things about your software — that it detects a condition, or fails in a particular direction. Those are requirements even when they are not written as such.
  4. Schedule the derived-requirements feedback. Put it in the plans with a name against it.
  5. Expect the level to move. If the safety assessment changes, your level and your plans change with it. Plan for one revision rather than being surprised by it.

Frequently asked questions

What is the difference between an FHA and a PSSA?

The FHA identifies failure conditions and classifies how severe they are, before there is a design. The PSSA takes those and determines what a proposed architecture must do to satisfy them, including allocating assurance levels to items. The FHA asks how bad; the PSSA asks what we must therefore do.

Why doesn't software get a failure probability like hardware does?

Because software failures are systematic, not random. A design error is present in every copy and will occur whenever the triggering condition arises, so there is no rate to measure. Development assurance substitutes rigour of process and evidence for a probability that cannot be assigned.

Can a software team get its DAL lowered?

Not directly, and not by negotiation. It changes when the system architecture changes such that software failure no longer leads to the severe effect on its own — a monitor, a partition, dissimilarity. That is a systems and safety conversation, and it has to happen before the architecture is frozen.

What is Common Cause Analysis for?

To test the independence the architecture is relying on. If two channels are claimed to be independent but share a power supply, a connector, a development team or a software library, they can fail together and the safety argument collapses. CCA looks for exactly those shared paths.

Do the probability figures apply to every aircraft?

No. The figures usually quoted come from the transport-category requirements. Other categories use different targets, and your certification basis determines which apply. Confirm against the basis for your actual programme rather than the numbers most often repeated online.

If a level looks wrong for your architecture, the time to say so is now rather than at SOI #2 — get in touch.