View
1
Download
0
Category
Preview:
Citation preview
Lecture 7
Safety Analysis: Failure Modes and Effect Analysis
(FMEA) Functional Hazard Assessment (FHA)
Failure Modes and Effect Analysis
FMEA is a well-known inductive safety analysis technique For each system component it defines its possible failure modes, local and system effect of component failures, as well as detection and recovery procedures. FMEA table fields Component – name of a component Failure mode – possible failure modes Possible cause – possible cause of a failure Local effects – caused changes in the component behaviour System effect – caused changes in the system behaviour Detection – determination of the failure Remedial action – actions to tolerate the failure
2
Example of hardware-oriented FMEA
Failure modes and effect analysis (FMEA) • Why: to identify contribution of components failures to
system failure
• How: progressively select the individual components or functions within a system and investigate their possible modes of failure
• Information analyzed: possible failure modes, possible causes, local and system effect, how to fix (remedial actions)
What is the proper level?
• Depends at which design stage: might be very general might be very detailed
• Hardware – To off-the-shelf components – Or field-replaceable assemblies for which failure modes
are available
• Software as a single component – Failure modes as worst possible effects
– Does not include human
Example: sluice gate control system
6
insideoutside room
door2door1
Pressure sensors
Opened door sensors Closed door sensors
Door motors
Pressure chamber pump
insideoutside room
door2door1
Door position sensors
Sluice connects areas with dramatically different pressures. It is unsafe to open a door unless the pressure is levelled between the connected areas. The purpose of the system is to operate doors safely by adjusting the pressure in the room.
Example: Failure mode “contradictory sensor data” for Door1
Example: Failure mode “out of predicted range”
Evaluation of FMEA • “+” • Allows to identify redundancy, single-point
failure, inspection points and how often the system needs to be serviced
• Technique is complete • “-” • Time consuming • Does not consider effect of multiple or
common-cause failures
Some notes about FMEA
Very often hardware-oriented FMEA formulates software requirements very vaguely, e.g., “modify software to detect failure”.
How to do it better? Find a common model, i.e., the model which
would be a middle-hand between safety analysis and software requirements
Functional Hazard Assessment (FHA)
• The FHA allows us to identify hazards at a functional level and correspondingly derive safety requirements.
• The FHA process consists of five steps: – Identification of all functions associated with the level
under study. – Identification and description of failure conditions
associated with these functions. – Determination of the effects of the failure condition. – Classification of failure effects on the system. – Assignment of requirements to the failure conditions to be
considered at the lower level.
Identification of failure conditions
• An identification of failure conditions can be done systematically by applying the following guidewords:
• - Loss of function • - Function provided when not required • - Incorrect operation of function.
Issues to be addressed
• How to describe functionality so that it will be easy to use in FHA?
• What is the proper level for the analysis? • Often FHA results in derivation of new
functional requirements: How to integrate them into already existing requirements?
Use case model
• We identify users of the system and the tasks which they must undertake with the system
• Actor (= User in UML notation ) – is a user in a particular role. – is external to the system. – interacts and places demands on the system.
• A use case is a task which an actor needs to perform with the help of the system
Use cases as input for FHA
• use cases clearly define system’s functions • use case diagrams explicitly show
interdependencies between use cases by means of associations
Documenting details of use cases
• Borrow copy of book A BookBorrower presents a book. The system check that the potential borrower is a member of the library, and that s/he does not already have the maximum permitted number of books on loan. This maximum is 6 unless the member is a staff member, in which case it is 12. If both checks succeed, the system records that this library member has this copy of the book on loan. Otherwise it refuses the loan.
• Note: description is in third-person, active-voice English
• Use case: Borrow copy of book • Actors: Book borrower (BB) • Purpose: Capture book borrowing • Overview: BB arrives at the checkpoint.The
system check that the potential borrower is a member of the library, and that s/he does not already have the maximum permitted number of books on loan. If both checks succeed then loan is allowed, otherwise it is refused.
• Type: primary and essential • Cross References (other resources which are
needed to implement the use case. e.g. some system functions)
Example
Use case diagram
• Use case Aspirate
• Brief description This use case defines system’s reaction on the operator’s command “aspirate l units of liquid from plate p”. It includes positioning of the operating head over the required plate, pumping the liquid in the pipette and reporting success or failure of the execution
• Includes use cases “Move to X position”, “Move to Y position”, “Move to Z position”, “Pump”
• Preconditions Operator chooses command Aspirate l units from plate p, the system is fault free
• Postconditions The amount of liquid in the pipette is increased by l units, the head is positioned over the plate p and success is reported. Otherwise failure is reported
• Typical flow of events • 1. Verify that p is a valid plate ID. If the verification fails then A_Failure1 in
alternative cause of events, else calculate X, Y- coordinates of plate p. • 2. Execute use cases “Move to X position”, “Move to Y position”. • 3. If execution of use cases “Move to X position”, “Move to Y position” failed then
A_Failure 2 in alternative flow of events else if execution of use cases “Move to X position” and “Move to Y position” succeeded then execute use case “Move to Z position”.
• 4. If use case “Move to Z position” failed then A_Failure 3 in alternative flow of events else if execution of the use case “Move to Z position” succeeded then execute use case “Pump”
• 5. … • Alternative flow of events • A_ Failure1: Prompt message “Incorrect plate ID p.” Cease automatic execution
mode. • A_Failure2: If the execution of the use case “Move to X position” failed then cease
automatic mode of execution, revert to the operator’s control, prompt message “Moving to X position has failed”.
Use case Move to X position Brief description This use case defines reaction on the command “Move to X
position”. As a result of the execution of the use case either the operating head is brought to X position and success is reported or failure is reported.
Includes none Preconditions None Postconditions The operating head is placed at the position X or failure is reported Typical flow of events Check that xmin ≤X ≤ xmax, if not X_Failure1 in alternative flow of events Check current x-position. If current x-position equals X then report success of execution. Otherwise move operating head to X position. Check current x-position. If current x-position equals X then report success of
execution else X_Failure2 in alternative flow of events Alternative flow of events X_Failure1. Prompt message “Input parameter X is outside of valid range” X_Failure2. Prompt message “Loss of precision of X movement”
Conducting FHA
• Each element of use case description – Pre-conditions, – Guard-conditions, – System responses – Post-conditions
• Is identifies and recorded in the analysis table • For each element we apply the guide words
Example of FHA
• Example from domain of engine control. • Deceleration is a core aircraft function. • Control of reverse thrust is a part of it. • It is decomposed and allocated to sub-systems • of aircraft • As a result identification of failure of a single function
(reverse thrust direction) result in discovery a new functional requirement
System level use case diagram
Decelerate on landing scenario
System level scenario
Example of extracting new functional requirements
• Element Airframe status =on ground (precondition) • Guideword Commission • Deviation On ground detected when not true • Possible Causes System failure, invalid airframe data; data transmission
failure • Use Case Effect Reverse thrust implemented when precondition not
satisfied • Real World Effect Thrust reverser deployed when not on ground; loss of
controlled flight • Severity Catastrophic • Integrity Constraints Assign on ground detection reliability; validate
airframe data; specify data sampling rate • New Safety Requirements Disallow thrust reverser when airframe not on
ground; detect inadvertent deploy…
Example of extracting integrity constraints (guide word omission)
• Element Thrust reverser state = in transit (guard condition) • Guideword Omission • Deviation Thrust reverser state= in transit not detected when true • Possible Causes System failure, invalid thrust reverser data; data
transmission failure • Use Case Effect Engine thrust demand not commanded to thrust limit
when guard condition satisfied • Real World Effect Engine thrust exceeds thrust limit; structural damage
to thrust reverser; loss of controlled deceleration on landing • Severity Catastrophic • Integrity Constraints Assign thrust reverser state detection reliability;
validate thrust reverser data; specify data sampling rate
Example of extracting integrity constraints (guide word value)
• Element Thrust reverser state = in transit (guard condition) • Guideword Value • Deviation Thrust reverser state= in transit detected as thrust reverser =
deployed • Possible Causes System failure, invalid thrust reverser data; data
transmission failure • Use Case Effect Engine thrust demand not commanded to thrust limit
when guard condition satisfied • Real World Effect Engine thrust exceeds thrust limit; structural damage
to thrust reverser; loss of controlled deceleration on landing • Severity Catastrophic • Integrity Constraints Assign thrust reverser state detection reliability;
validate thrust reverser data; specify data sampling rate
FHA: conclusions
• FHA provides a systematic way to identify hazards caused by incorrect provision of system functions
• FHA can be applied at different levels of design, e.g., you can try to apply FHA to overall use cases, e.g., to investigate what happens when use case provided incorrectly, or when not expected, or not provided when expected
Recommended