Functional Hazard Assessment

1. Functional Hazard Assessment

2. Overview Functional Hazard Assessment • Purpose / place in lifecycle Functional Failure Analysis • Concept • Failure Categories • Effects and Contributing Factors • Making it worthwhile

3. Functional Hazard Assessment FHA is name for a family of analyses which • are predictive and target setting • explore effects of failures of system components • are carried out once a system design has been proposed, and may be repeated at each subsequent level of design decomposition Primary aims • assess overall acceptability of design • identify which functions of the system contribute to hazards identified by the PHI • sets targets for subsequent design and assessment

4. Functional Hazard Assessment – Techniques • Functional Failure Analysis (FFA) • Studies projected failure modes of system functions • Common in Aerospace applications • HAZOP • Based around deviations from intended behaviour of components and flows • Standard technique in process, offshore oil/gas production and nuclear industries - also used for fuel, hydraulic systems • Increasingly used for software (DEF STAN 00-58) • Sneak Analysis • Many variants for different technologies • Originated in USA - widely used within Boeing • Best published method descriptions from European Space Agency

5. Functional Failure Analysis – Concept From a suitable representation, select functions in turn: • Define purpose and behaviour of function • Produce FFA tables • consider hypothetical failure modes in 3 categories: • loss of function • function provided when not required • incorrect operation of function • determine effects • note any environmental and / or operational contributing factors • determine, record (and justify) associated risk factors: • severity, probability budget • Record any new hazards in Hazard Log

6. Simple FFA Example

7. Design Representations 1 For initial FHA, only need list of functions - but simple functional hierarchy diagram is better basis Levels can be developed as required for analysis

8. Design Representations 2 • Can perform FFA from any representation which identifies function • Mechanical drawings (for simple systems) • Function Block Diagrams • Reliability Block Diagrams • Many requirements notations, especially for software • Software design notations • vary in suitability • data / function oriented notations (e.g. Yourdon, MASCOT) good • object-oriented more difficult • But BEWARE • must consider whole function, not just contribution of one technology

9. Example of Function Identification Consider car cruise control system • What is / are primary function(s)? Maintain selected vehicle speed • What are secondary functions? Maintain speed • using throttle control • using brakes • using gear selection Engage / disengage cruise control Select speed • What do FFA failure categories suggest when applied to these functions?

10. Failure Categories 1 Function not provided • easy to interpret for responsive function • care required with continuous / periodic function – may need to consider effects of different cases individually:

11. Failure Categories 2 Function provided when not required • also easy to interpret for responsive functions • not applicable to continuous functions (those which are always required), e.g. Air Traffic Control “Maintain Separation” Incorrect operation of function • “catch-all” – hard to be certain of completeness • often requires decomposition to lower level for satisfactory understanding of implications • typical examples • asymmetry • substitution of other function • incomplete function • timing (e.g. too slow)

12. Operation Phases • What the (sub-)system is doing at the time of failure will have a major influence on effects • e.g. for car • “no braking” unimportant if already stopped • “asymmetric braking” meaningless unless braking actually in progress • But beware that loss of function (if it persists) will affect subsequent phases • “no braking” doesn’t matter on motorway – but at next junction… • Example: for aircraft analysis, operation phase will usually be interpreted as flight phase

13. Flight Phase Civilian / transport operation flight phases Don’t forget • ground phases – maintenance – fuelling – boarding / loading – taxi • emergency phases – go-around – rejected take-off (RTO) • extra phases for military aircraft – low level flying – (simulated) combat

14. Environment Environmental conditions may alter effects of failure • e.g. safety effect of “loss of anti-lock” on car brakes will be much more serious on wet / icy road • Environment includes people, other systems… • may impose extra demands (that tractor advert!) • may increase risk (e.g. more people exposed) • Relevant environmental considerations affected by phase • e.g. runway conditions only need to be considered in ground phases • Environment for sub-systems includes other sub-systems on platform • and their operating modes, failures...

15. Co-incident Failures • Aim of FFA not to produce detailed investigation of combinations of failures leading to hazard… • … but generally need to take account of certain important classes of failure, e.g. • loss of support functions • power supply • hydraulics • emergency configurations • engine out • situations where failure has an obvious common cause with related functions or systems • failures of mitigating / protective functions • response from operator or other (sub-)systems

16. Warnings • Effects of failure may be different if operator is warned (annunciation) • e.g. civil aviation safety analysis procedures regard landing with annunciated brake failure as a less severe hazard than the same physical failure with no warning to pilots • May actually need to regard warning as a separate function • what is the effect of warning when no actual failure?

17. Risk Factors • Failures are assigned a severity based on the hazard(s) which they cause or contribute to • “Budgeted” probability can then be assigned on basis of hazard severity and acceptable risk • This is a complex process • pessimistically, may assign budget on basis of all failures independent and sufficient to cause hazard • but this may end up with impossible target probabilities • realistically, may need to recognise effects of contributing factors • may need to carry out fault tree or other decomposition to achieve realistic budgets

18. Getting Value from FFA • FFA should add value to process • improve understanding of system and hazards • provide useful input to design... • so • conduct at appropriate stage in process • be clear what output should be • identify safety effects clearly • provide a set of meaningful, useful recommendations • avoid over-complication • do not • regard it a “write only” exercise Comments actually apply to all analyses...

19. FFA Summary Advantages • simple principles • can (should) bridge technologies Disadvantages • easy to produce lots of output with poor structure and little value • not suited to some types of computer / control system where information is more important than function Better to do it well, with insight, at high level, than merely mechanically at more detailed level