For decades, aerospace safety assessments (Functional Hazard Assessments, Preliminary System Safety Assessments, System Safety Assessments) have been produced the same way: a senior safety engineer reads the System Design Description, builds a hazard table in a spreadsheet, traces failure modes manually, and iterates through review cycles until sign-off. The process works. It has delivered certified aircraft for forty years. It also costs hundreds of thousands of euros per program and takes months where weeks would suffice.
ARP4761 safety assessment automation changes this equation. Not by replacing the engineer, but by eliminating the 80% of the process that is mechanical, error-prone, and does not require engineering judgement.
What ARP4761 actually requires
ARP4761 (now ARP4761A, revised in 2023) defines the accepted means of compliance for showing that an aircraft system meets the safety requirements of ARP4754A. It mandates a structured process:
- FHA: identify all failure conditions at the aircraft and system level, classify their severity (Catastrophic, Hazardous, Major, Minor), assign Development Assurance Levels
- PSSA: derive safety requirements for each system and subsystem, allocate probability budgets, construct fault trees
- SSA: verify that the implemented system meets the derived safety requirements
For a full breakdown of what an FHA contains under ARP4761A, including what each entry must address and where reviews most commonly fail, see our dedicated guide.
The standard specifies what must be demonstrated. It does not specify how the engineer gets there. This is the gap that automation addresses.
What "automation" does and does not mean
A common misconception is that automated safety assessment means a model generates the FHA and the engineer signs it. This is not what responsible automation looks like, and it is not what the standard would support.
What automation actually means in the ARP4761A context:
Automated drafting. The system reads the SDD, identifies functions and failure modes consistent with the document's own definitions, and generates a first-draft FHA table, with full traceability and rationale for every entry. The engineer reviews each row, modifies or rejects as required, and advances to the next step only after explicit sign-off.
Automated consistency checking. The system cross-references FHA classifications against PSSA allocations, flags DAL mismatches, identifies hazard entries with no corresponding PSSA mitigation, and surfaces logical contradictions across documents. This replaces hours of manual cross-referencing per review cycle.
Automated impact analysis. When the SDD changes, for instance a new architecture decision or a revised failure mode, the system traces the change across the entire document set, identifies every affected safety requirement, and flags items that require engineer review. This replaces the fragile manual impact analysis that currently consumes a disproportionate share of safety engineer time.
In each case, the engineer retains full ownership. The output is a draft. The decision to accept, modify, or reject every entry is made by a qualified safety engineer. The automation compresses the time required to produce a defensible first draft and catch systematic errors: it does not remove the human from the loop.
Why the window is open now
Three things converged in 2024 and 2025 that make this practically achievable for the first time:
Large language models capable of structured reasoning over technical documents. Earlier NLP systems could extract text but not reason about the relationships between failure modes, severity classifications, and DAL allocations. Current models can. The limiting factor is no longer model capability; it is the engineering framework around the model.
ARP4761A's updated guidance on tool qualification. The 2023 revision provides clearer guidance on what constitutes a tool under DO-178C and DO-330, and how tool qualification requirements apply to software that supports (but does not replace) engineering judgement. This reduces the regulatory ambiguity that had slowed adoption.
Cost and schedule pressure on smaller teams. Aircraft programs increasingly rely on smaller, specialized engineering teams rather than large in-house safety departments. A team of three safety engineers cannot manually produce FHA, PSSA, and SSA for a complex avionics system in the time available. Automation is not a luxury for these teams; it is a prerequisite for being able to bid on programs at all.
What engineering ownership looks like in an automated process
The concern raised most frequently by safety engineers encountering automated drafting tools is whether they are still the responsible party, or whether the system has effectively taken over the assessment.
Under a correctly implemented automation workflow, the answer is unambiguous: the engineer is the responsible party at every step. The practical implications:
- Every automated output is explicitly labelled as a draft pending engineer review
- No step advances without explicit engineer sign-off
- Every entry carries the rationale generated by the system and the modifications made by the engineer
- The final document is the engineer's document, and the tool's role is analogous to a drafter who prepares the first version for the responsible engineer to review and approve
This is the same relationship that exists between a structural analysis tool and the stress engineer who runs it. The tool does not eliminate engineering responsibility. It concentrates engineering effort on the decisions that require engineering judgement.
The practical difference
An FHA for a complex avionics system, say a flight control computer with 40 to 60 functions, currently requires a senior safety engineer to spend 4 to 8 weeks producing a first draft that is accurate enough to survive an initial peer review. With automated drafting, the same first draft is produced in 2 to 5 days. The engineer spends those days reviewing, correcting, and refining, not constructing the table from scratch.
The downstream effect on the full program is larger. Because the first draft is produced faster and with fewer systematic errors, the review cycles are shorter, the iteration loops are tighter, and the probability of discovering a critical error at design freeze, when it is most expensive to fix, is substantially lower.
This is what ARP4761 safety assessment automation means in practice. Not artificial intelligence replacing engineering judgement. Engineering effort concentrated where it matters, with the mechanical work handled by a system that does not make transcription errors.
evidion is building the safety assessment automation platform for aerospace. If you are a safety engineer or safety organisation interested in the pilot programme, join the waitlist.