1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance

2 Lecture Objectives Safety Engineering Approach Language of Hazard Analysis Requirements in Safety Lifecycles

3 Safety Engineering Approach Hazard analysis technique to determine the safety aspects of the system Early in the development process, then Monitoring safety throughout the product development process; and Ensuring that there is enough evidence to build a safety case at the end of the product development process.

4 Safety Engineering Approach Requirements Analysis and Product Definition Exploratory analyzes in the form a preliminary hazard analysis (PHA). The hazards, potential situations that can cause harm or environmental damage The potential cause list. Good understanding of the safely aspects of the software prior to going into the design and implementation phases.

5 Safety Engineering Approach Design and Implementation Phase A deductive Approach – starts with potential situations of harm and works back to design or implementation elements. An inductive Approach – Starts from components or subsystems failures and Works back through sub-systems to see if hazard result is used to verify the safety elements in the design.

6 Safety Engineering Approach Defending in Depth - System that must defend against situations of harm Must be ultra-reliable or There must be sufficient redundancy Thus, safety related subsystem failure does not lead to safety related system failure.

7 Language of Hazard Analysis Hazards needs to be identified and assessed as early in the development life cycle as possible. First step – hazard identification Process of identifying those situations which could lead to an accident under credible situations. Using done as part of brainstorming methods.

8 Language of Hazard Analysis Hazards in turn are casued by failures or failure modes. Failures – are unintended or states of the system that can lead to a hazard. Failure mode – identify specific classes of failures

9 Language of Hazard Analysis Error – unintended states of the system that can lead to failure. Flaw – design/program defects that give rise to errors when certain conditions are activated. Fault – events that result when a flaw is activated.

10 A Case Study – The Okecie Accident Occurred because of an accident sequence. Plane landed 750m down the runway and traveling at 170 knots instead of the more usual 150 knots in torrential rain and heavy winds. Aircraft failed to brake in time and hit an earthen wall at the end of the runway and burst into flames.

11 A Case Study – The Okecie Accident

12 A Case Study – The Okecie Accident In normal conditions – A320 does not need a 2.8 KM runway to stop; Even in torrential rain it can land safely and stop in under 1500m. Consequences of the accident were assessed to be major, but not catastrophic.

13 A Case Study – The Okecie Accident Weather factors are believed to have contributed to the accident, Strong winds veered from a cross-wind to a tail-wind on final approach. It was raining heavily. Air Traffic Control (ATC) did not inform the crew of the change in wind direction.

14 A Case Study – The Okecie Accident

15 A Case Study – The Okecie Accident AG is true if (WoW > 12 tonnes) and wheels spinning > 72 Km/hr) or (wheels spinning > 72 km/hr and radio alt < 10 ft) AG  ‘at ground’ WoW  ‘weight on wheels’ & Function of both wheels Standing water on the runway caused the aircraft to Aquaplane while braking and wheels were not spinning at The required rate to activiate the braking logic.

16 A Case Study – The Okecie Accident AG = False (weight on both wheels) WS = False (wheels spinning at > 72 KM/hr) Radio Alt = True (radio altimeter) Logic was implemented correctly but the system failed. This is quite probability a failure in requirements.

17 A Case Study – The Okecie Accident Isolate the error, flaw and faults Error – was the assignment AG = False Flaw – we required AG = WoW > 12 tones for both wheels Failure – arose because the flaw was triggered in condition of wind and water on the runway.

18 Requirements in Safety Lifecycles

19 Requirements in Safety Lifecycles Initial Hazard List – the list of known hazards in the domain or a list of hazards obtained from similar systems or prior versions etc. Preliminary Hazard Analysis (PHA) Determining potential hazards for the new system as well as The causes of failure leading to these hazards

20 Requirements in Safety Lifecycles Consequence Analysis – we work from design elements to hazards. Is predictive in nature and is carried out before the design is completed. Used to provide information into the design processes and is aimed to choosing between design alternatives. Event trees, failure modes and effects analysis (FMEA) etc.

21 Requirements in Safety Lifecycles Causal Analysis – typcially performed top-down. Working from hazards to design or model element. Fault tree are the classic technique.

22 Key points Hazard analysis technique to determine the safety aspects of the system Hazards needs to be identified and assessed as early in the development life cycle as possible. The safety lifecycle consists of a number of activities which are aimed at determining and verifying the safely functions of the system.