The deliverable is a worksheet, and the worksheet is the least interesting thing in it. What the programme actually receives is a scope, a set of budgets, a set of levels and a set of constraints on an architecture that does not exist yet.
1. The list of failure conditions
Every condition, with its phase and its annunciation state, and the merge rationale behind the ones that were combined. This list is the safety scope of the programme: a condition that is not on it will not have a fault tree, will not have a budget, and will not be verified. Nothing downstream can recover an omission here, which is why completeness is worth more than precision at this stage.
2. A classification per condition, with its evidence
The class, and the effect description it was drawn from. A classification travelling without its effect column is an assertion, and it will be re-argued every time the design changes, by people who no longer remember why it was set.
3. The quantitative objectives
| Output | Form | Used by |
|---|---|---|
| Probability objective | Average per flight hour, and per flight at the stated average flight length | The fault tree top event |
| At-risk time | Where the condition is severe only in a defined window | The conversion from a probability to an item rate |
| Average flight length | One number for the whole programme | Everything that converts between per flight and per hour |
4. The qualitative requirements
The no-single-failure rules, and the independence claims they imply. These bind harder than the numbers and they bind earlier: they are architecture constraints, available while the architecture is still a sketch, and they are the part of the assessment that most often changes a design.
5. Development assurance levels
A level for each function, the functional failure set behind it, and the independence argument where the level was shared out. The argument is part of the output, not a working note: it is a claim about how two developments were kept apart, and it is examined as one.
6. The verification plan
Which fault tree, which test, which analysis will show each condition compliant. This column is what turns an assessment into a certification plan, and it is the column that reveals whether anybody has thought about how the harder classifications will actually be demonstrated.
What the FHA does not support
- It is not a design. It constrains architectures and chooses none. Any statement about how many channels are needed is a PSSA conclusion that has borrowed an FHA's authority.
- It is not a probability calculation. No number in it is computed; every number in it is looked up from a class. A classification cannot be argued from a failure rate.
- It is not a hazard log. It covers functional failures, not every hazard: fire, structural failure and external events reach the safety case through other routes.
- It does not survive an architecture change on its own. Allocating functions to shared items creates conditions that did not exist before, which is precisely why there is a system-level assessment as well as an aircraft-level one.
- It cannot be graded until service. The only real check on a classification is what happens when the condition occurs in the field, which is FRACAS's contribution to the safety process and the reason service events are read back into the assessment.