Concepts, Terminology and Safety Lifecycle

1. Concepts, Terminology and Safety Lifecycle

2. Overview • Terminology • Safety • System context • Accidents • Hazards • Failures • Life cycle

3. Safety 1 “this is obviously some strange usage of the word safe that I was not previously aware of” Douglas Adams Hitch Hiker’s Guide To The Galaxy • no commonly accepted set of terms • define key terms, consistent with ARP 4754 / 4761 usage • influenced by BS 4778

4. Safety 2 Safety is concerned with physicalartefacts • an artefact is unsafe if it causes unacceptable harm, e.g. loss of life or environmental damage • only physical systems can cause this sort of harm • information (computer) systems can only cause harm indirectly Course will consider systems in aircraft context

5. Environment • physical, e.g. weather • peer platforms, e.g. other aircraft • people, e.g. passengers Platform – largest engineered artefact • e.g. ship, aircraft, tank Operators– humans • controlling, e.g. pilot • monitoring, e.g. ATC Physical Context

6. Accidents 1 Wish to prevent or reduce accidents • accident – unintended event or sequence of events leading to harm – death, injury, environmental or material damage • e.g collision between train and road vehicle at a level crossing Observations • unintended – only collateral damage of weapons • harm – some definitions exclude injury, or • material damage (most exclude money) Also • incident – event which significantly degrades safety margins, but does not lead to an accident

7. Accidents 2 Definition from ICAO: • “Aircraft accident” means an occurrence associated with the operation of an aircraft that takes place between the time any person boards the aircraft with the intention of flight until such time as all such persons have disembarked, in which any person suffers death or serious injury as a result of being in or upon the aircraft or by direct contact with the aircraft or anything attached thereto, or by direct exposure to jet blast, or the aircraft receives substantial damage. • serious injury – hospitalisation for more than 48 hours, fractures (except fingers, toes, nose), severe laceration, internal injury, 2nd degree burns, exposure to infectious substances or harmful radiation. • death – within 30 days of accident • substantial damage – Damage or structural failure that adversely affects the structural strength, performance or flight characteristics of the aircraft

8. Accident Risk In assessing potential accidents, examine: • severity – assessment ofextent of harm • how many people are likely to be killed / injured? • extent of environmental damage? • probability – probability (or rate of occurrence) of events that create the accident • risk – expression of the possibility / impact of an accident in terms severity and probability Note: acceptability of risk a complex issue • but in civil aerospace, framework for risk acceptance well established • and mapped to hazards

9. D = 1700 m S = 154 knots T = 12 s Full braking D = 2800 m S = 70 knots T = 30 s? Full braking Warsaw Accident 1 LH2904 Okecie, Warsaw, 14th September 1993(A320 Warsaw — approximate analysis) D = 750 m S = 170 knots T = 0 s No Braking 2800 metres

10. Warsaw Accident 2 A320 Warsaw • accident – aircraft hit earth wall near end of • runway (and ensuing fire) Consequences– effects of accident • human – loss of two lives including co-pilot; 54 • injuries (hospitalised) • material – hull (aircraft) loss

11. Hazards Accidents arise from hazards • hazard • “an accident waiting to happen” • physical condition of platform that threatens the safety of personnel of the platform, i.e. can lead to an accident • a condition of the platform that, unless mitigated, can develop into an accident through a sequence of normal events and actions • examples: • oil spilled on staircase • failed train detection system at an automatic railway level crossing • loss of thrust control on a jet engine • safety process structured around hazards, as there will generally be far fewer hazards than potential accidents • e.g. “loss of braking” in car – one hazard, thousands of accidents

12. Hazard Identification In defining platform, carry out • hazard identification– identifying those situations (hazards) which could lead to an accident under credible conditions • techniques employed include • brainstorming • hazardous materials studies • identification of energy sources and containment • often initial hazard list known • checklists • this is especially true of civil aerospace • but beware of complacency!

13. Hazard Assessment 1 Investigate hazard risk factors: • hazard probability – probability (or rate of occurrence) of events that create the hazard • hazard severity – assessment ofextent of harm; several ways to determine this: • most severe potential accident • most likely potential accident • “expected” outcome, factoring in probability that hazard will develop into each potential accident • also need to factor in probability that hazard will develop into accident WARNING: Standards vary, and many are unclear! • hazard risk – product of hazard probability and hazard severity

14. Hazard Assessment 2 Hazard risk factors: qualitative or quantitative? • hazard severity Examples: • quantitative: number of deaths • qualitative classification: catastrophic, major, minor, negligible • hazard probability Examples: • quantitative: 1 per 1,000,000 operations, 1 per 900 hours • qualitative classification: frequent, improbable, incredible • hazard risk Examples: • quantitative: expected deaths per operational hour • qualitative: hazard risk index (HRI)

15. Warsaw Accident 3 Hazard • travelling fast down runway, without braking Environment • weather – strong winds, veered from cross to tail winds in final approach; raining heavily • runway – standing water (caused aquaplaning) • ATC – didn’t inform pilots of shift in wind direction Other conditions • landed long and “hot” (i.e. faster than normal – 170 knots) • earth wall ... Risk factors (N.B. judgemental): • severity – (only) major? • probability – incredible?

16. System and Environmental Hazards Two distinct groups of hazards: System (Internal) Hazards • arise from causes within the system • imply that something has gone wrong • component or equipment failures • human failures • process failures (design, manufacturing, maintenance…) Environmental (External) Hazards • arising from external threats • imply either threat has been misjudged • e.g. pilot flying into storm • or beyond anticipated / manageable limits • e.g. collapse of “earthquake-proof” buildings

17. Faults and Failures System hazards are caused by faults or failures, where • failure is an event • fault is a state resulting in inability of an item to perform its intended function IMPORTANT: definition of failure used in this course is vis a vis intent – what is really needed for safety • not the specification • not the design • not the original behaviour of the system (this is reliability view)

18. Structures • non-functional platform components e.g. wing spar, car chassis Systems • multi-technology functional platform components, e.g. brakes and steering system (BSCU) Note: distinction not always clear cut Platform Decomposition Platform

19. Units – pumps, stepper motors, valves, thermocouples, etc. Computing systems and software System Decomposition Systems

20. Warsaw Accident 4 A320 Warsaw – Platform Airframe – “on ground” at T=0 • one main landing gear compressed, other not; aircraft banked due to expected cross-wind Weight on Wheels (WoW) Expected Cross Wind

21. Spoilers 40% Brakes 40% Rev. Thrust 20% Warsaw Accident 5 A320 Warsaw — Systems (approx.) WS AG WoW L R LGCIU SEC2 WS L R BSCU RA Pilot Interface FADEC Commands

22. Warsaw Accident 6 Landing Gear Control & Interface Unit (LGCIU) • landing gear extension, retraction, etc • synthesises AG (Air / Ground Transition) & WS • AG = WoW > 12 tonnes (both LG) • WS = Wheel Spinning > 72 knots (either LG) Spoiler Elevator Computer Secondary (SEC2) • deploys spoilers, etc Full Authority Digital Engine Controller (FADEC) • controls engine, & deploys thrust reversers Brakes and Steering Control Unit (BSCU) • nosewheel steering, all braking and ABS

23. Warsaw Accident 7 Logic – distributed amongst systems • apply thrust reversers – AG true • apply air and wheel brakes – WS true or (RA true (radio alt < 10 feet) and AG true) System Conditions • AG (weight on both wheels) = False • WS (wheels spinning > 72 knots) = False • Alt (less than 10 feet) = True • major systems – LGCIU, SEC2, BSCU – all functioned to specification • no braking – air brakes, thrust reversers or wheel brakes

24. Warsaw Accident 8 Operators (pilot) • misjudged conditions for landing • but incomplete information about wind Overall cause: complex circumstances • behaviour of aircraft systems • (procedure based) pilot actions • state of airport, and • (lack of) information from ATC • combined to produce unsafe result

25. Classes of Failure Different classes of failure • systematic – failures due to flaws in design, manufacture, installation, maintenance. Items subjected to the same conditions fail consistently • random – failures due to physical causes – a variety of degradation mechanisms N.B. Random failures are a result of design decisions Normally treat design and physical failures separately, giving requirements in different terms • random – failure rates • systematic – in terms of integrity levels – freedom from flaw or corruption

26. Causal Analysis In designing systems we need to carry out • causal analysis – determining potential causes of failures, and their likelihoods Causal analysis • spans multiple technologies • considers physical interaction, e.g. electro-magnetic interference, as well as logical interactions BEWARE: • treatment of systematic failures varies across industries / nationalities

27. Systems in a Product Lifecycle • Systems are developed to satisfy multiple constraints • performance • functionality, speed, etc. • dependability • safety, availability, etc. • maintainability • cost • recurring and non-recurring, or lifecycle • other constraints • weight, power consumption … • environmental, recycling • usability • Also need to satisfy multiple stakeholders

28. Stakeholders • A stakeholder is an individual or organisation • who has a “stake” in the success of the product / system • Perception and acceptability of product varies • a stakeholder will represent one or more constraints • what is “optimal” for one stakeholder won’t be for another • indeed there may be explicit conflicts • thus trade-offs have to be made to get an agreed design • For a complex product stakeholders include • designers • safety engineers • maintainers • operators • marketing …

29. Trade-offs 1 Many factors must be balanced (traded off) to meet customers’ needs

30. Trade-offs 2 Key safety-related trade-offs • safety – safety • identifying ‘least worst’ failure modes – particularly important when there is no safe state • safety – availability • often directly in conflict when there is a safe state • safety – cost (whole life, includes maintenance) • economic balance of risk and benefit • safety – complexity • is the addition of safety systems worth the increase in complexity that will result (and effect on cost, availability…) • Management issue as it involves money, liability ...

31. Trade-offs - A320 Example • Consider the function “decelerate aircraft on the ground”. Chosen solution • A320 now requires less weight on wheels to set AG • modification available from 1991 for “passenger comfort”, now become a mandatory change • Lufthansa procedures changed • different aircraft configuration, to give pilots more chance to control the problem • More generally, no one “obviously right” solution • several alternatives credible, and worthy of further investigation • so far as we can ascertain all the major aircraft manufacturers use different strategies for deciding on air-ground transition! • In general, chosen design will be a compromise • each stakeholder trying to ease their tasks!

32. System Lifecycle Models • Various “models” have been developed to aid management of system development • they have evolved over time • more recent models try to deal with concurrency, multiple constraints, evolution, and so on • e.g. spiral models, model based design approaches Note: all models are simplifications • reality is always much more messy

33. Systems Engineering Life-Cycle (From INCOSE)

34. Simple V Model Systems version of model Validation • shows validation explicitly • basis for safety linkage

35. Safety Life Cycle 1 Safety Process

36. Safety Life Cycle 2 Major activities during development: • Preliminary Hazard Identification (PHI) • accidents and associated hazards • Functional Hazard Analysis (FHA) • causes of hazards, risks and derived safety requirements • Preliminary System Safety Analysis (PSSA) • allocating requirements to systems and units • System Safety Analysis (SSA) • confirming that design meets requirements

37. Safety Life Cycle 3 Integrated Design and Safety Processes

38. Safety Life Cycle 4 Safety analyses feed back into design process • hazard identification (consequence analysis) – requirements to prevent (eliminate), reduce or mitigate hazards • causal and consequence analysis – evaluation of design (trade-offs) – often predictive, i.e. produced before full design data available • analysis / design links – how analysis results influence design development and option selection

39. PHI FHA SSA PSSA ARP 4754 Safety Lifecycle • Currently undergoing redrafting

40. IEC 61508 Safety Lifecycle • Currently undergoing redrafting • (parts 1-4 out for review)

41. Summary We have introduced • model of artefacts • environment, platform, systems, equipments / units and computing systems • key terms • hazard, failure, etc • classes of safety analysis • hazard identification, effects analysis, causal analysis • lifecycle models and key activities • PHI, Risk Assessment, PSSA, SSA