Functional hazard assessment with AI: ARP4761A, AC 25.1309

A functional hazard assessment is the systematic, top-down evaluation of an aircraft's or a system's functions that identifies the failure conditions of each function, determines their effects by flight phase and operating condition, classifies the severity of each effect, and records the assumptions and the rationale behind every classification. Under ED-135 and SAE ARP4761A, both of December 2023, it is done at aircraft level and at system level, and its classifications set the safety objectives the design has to meet. AI can make an FHA more complete and more consistent: it can check the function list against the requirements, enumerate failure modes and flight phases so that none is skipped, keep effect statements and classifications consistent across hundreds of rows, and extract the assumptions that hide inside them. It cannot classify a failure condition for you. The classification is the judgement the certification basis requires the applicant to make, it is the first thing the authority reads, and it stays with the engineer who signs the worksheet.

What the standard expects an FHA to produce

ED-135 describes the aircraft functional hazard assessment as a systematic, comprehensive evaluation of the aircraft functions defined at the beginning of development. It identifies and classifies the failure conditions associated with each aircraft-level function, and its stated goal is to identify each failure condition clearly together with the rationale for its severity classification. It should also identify the assumptions about aircraft and crew mitigations that limit a classification, such as operating limits, crew information and operating procedures. The system functional hazard assessment does the same for each system once aircraft functions have been allocated, including the aircraft-level functions the system fulfils, and the two exchange failure conditions in both directions.

Appendix A of ED-135 sets out the aircraft FHA as six activities: gather the inputs, review and confirm that the aircraft-level functions are complete, determine the failure conditions of each function, determine the effects of each failure condition considering flight phases, operational and environmental conditions and crew awareness, assess and classify the severity of each effect, and capture and confirm the assumptions. The outputs are four documents: the function list and decomposition with the discussion needed to understand each function's scope, the worksheet with every failure condition, its effects in each flight phase and its classification, the list of assumptions, and the list of substantiation references used to show that the failure conditions and effects are correct and complete.

Two sentences in the standard matter for anyone thinking about tooling. Functions are to be described by what they accomplish, not by the means envisaged to implement them, so "provide thrust" rather than "engine". And the standard warns against assuming a severity classification while identifying failure effects, because the assessment becomes incomplete when the analyst focuses on preconceived outcomes. Both are exactly the disciplines a well-built assistant can enforce and a rushed team tends to skip.

The classification scale and why it is a judgement

Failure conditions are classified as Catastrophic, Hazardous, Major, Minor or No Safety Effect by comparing the effect statement with the definitions in the applicable guidance. For large aeroplanes that guidance is AC 25.1309-1B, issued by the FAA on 30 August 2024, and AMC 25.1309 in CS-25 on the EASA side. The advisory circular pairs each class with a probability objective, which is what turns a classification into a design requirement.

The definitions are short and the effects are not. Whether the loss of a function in a given phase leaves the crew "unable to fully accomplish required tasks" or merely with "a significant increase in workload" depends on the aircraft, its automation, the annunciation, the procedures and the assumed crew response. That is engineering and operational judgement, it is written down as rationale, and it is defended in front of the authority by the person who made it. An assistant that returns a class without the definition it matched and the effect statement it matched against is not helping.

Where FHAs go wrong

• The function list is incomplete or written as implementation. "Engine" instead of "provide thrust" hides the failure conditions of every other way thrust could be lost. ED-135 requires consistency between the functions analysed and the aircraft functional requirements, which is a check that can be automated.
• Flight phases are skipped. A failure condition that is Minor in cruise is often Hazardous on approach. Rows with an effect stated for one phase and silence for the others are the most common gap in a worksheet.
• Classifications are assumed first and effects written to fit. The standard warns against this explicitly. It shows up as effect statements that read like the definition of the class rather than a description of what happens.
• Assumptions stay inside the effect statement. "Crew recognises the condition and selects the alternate source" is an assumption about annunciation and procedure that must be listed, validated and, later, shown in the aircraft flight manual. If it stays inside the sentence it is never validated.
• The same effect gets different classes. Across three hundred rows written by four engineers over a year, identical effects drift into different classifications. Reviewers rarely find all of them by reading.
• A previous aircraft's FHA is reused unexamined. ED-135 permits reuse only when functions and failure conditions are re-examined for similarity of function, operation and environment.

What AI can propose and what the engineer decides

Each of the six AFHA activities has a mechanical part and a judgement part. The mechanical part is derivation from controlled inputs, and that is what a language model working from those inputs with citations does well. The judgement part stays where the standard puts it.

The conditions that make these proposals trustworthy are the four described in Can AI be trusted for aviation compliance documentation?: the assistant works only from a controlled corpus that holds the certification basis, the guidance and the standard at the revisions agreed for the project, together with the design description and the requirements; every proposal cites its source; users cannot alter that corpus; and every accepted or rejected proposal leaves a record of who decided. For an FHA the last condition has a specific meaning: the worksheet's rationale column is written by the engineer, not pasted from the proposal.

Unmanned aircraft

The FHA method carries over to unmanned aircraft, the effects do not. EUROCAE ED-279 of October 2020 sets out a UAS-level FHA process that defines the functions and flight phases of an unmanned system, identifies functional failure modes and their applicability, generates the FHA table, then reviews the generic result against the specific configuration and operation and accounts for design and operational mitigations. It also reviews how ED-135 applies to unmanned aircraft. The earlier EUROCAE ER-010 of 2013 records why the transport category severity and probability objectives cannot simply be transferred: the people at risk are on the ground and in other aircraft, and airworthiness and operational aspects are interrelated. For an assistant this means the corpus for a UAS FHA holds a different guidance set, and the effect statements are about the remote crew, third parties and containment. Where the aircraft operates in the specific category, the FHA and the SORA assessment inform each other and neither replaces the other.

How Wingman360 Teammate applies this

The FHA workflow in Wingman360 Teammate starts from the design description, the function list and the requirements the organisation has ingested, together with the guidance and standard at the agreed revision. It proposes the failure conditions of each function, drafts the effect statements by flight phase, proposes a classification for each with the definition it matched cited, extracts the implied assumptions, and produces the worksheet in the organisation's template for engineering review. Engineers accept, edit or reject every row and write the rationale themselves; the system signs nothing. The same knowledge base answers questions about the certification basis during the assessment, so the FHA and the answers share one controlled source. Each deployment is dedicated and single-tenant, in the organisation's own cloud or on-premise, with a local model option so that design data does not leave the network.