Lecture 5

Safety Analysis
FHA, HAZOP
 Introduction
• While designing a safety-critical system usually
several safety analysis techniques are applied
• The idea is to achieve completeness of safety
requirements, spot defects in the design and
amend it as early as possible in the
development process
• Each safety technique gives a different
perspective on system behaviour
• Potentially each of them brings a new insight on
system behaviour
 Today
Functional Hazard Assessment (FHA)

Hazard and Operability Study (HAZOP)

 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
 Hazard and operability studies
(HAZOP)
• Why: to identify all possible derivations from the
design’s expected operations and all hazards
associated with these deviations

• How: apply a list of guide words to designed functions

and identify invoked deviations. Next determine the
consequences of such deviations

• Information analyzed: The design intention of the

plant, potential deviations from the design intention,
the causes of these deviations from the design
intention, the consequences of such deviations
A flowchart of the HAZOP study
process
Possible guide words interpretation
Examples of HAZOP use
(hardware oriented)
 Evaluation of HAZOP
• “+”
• A simple, systematic approach which is easy to apply
• Encourages cross-disciplinary communication and
allows to find the problems overlooked by functional
teams working alone

• “-”
• Time consuming and labor-intensive approach
• Relies heavily on personal judgment
• Depends on the level of expertise of the team-
members
 Example: HAZOP, use cases and
security requirements
• The idea is similar to example of FHA: an
application of guide words to use cases to
derive security requirements
• The idea is to study use, abuse and
misuse (of use cases) for analysis of
security requirements
• Tailor HAZOP guide words to security
perspective
 HAZOP, use cases, security
• Actor: anything (anybody) that needs to
exchange information with the system
• Deviations from intent (e.g., it should not
allowed to process and approve payment)
may result in threats
• Consider potential or resources
 HAZOP: Actors Guidewords
in security
• Action/Intent
• NO : The action/intent does not take place.
• MORE : More action is achieved. This may be one of the
following:
– Sequential Repeat - the same actions take place repeatedly.
– Parallel Repeat - the same actions take place concurrently.
– Extreme intent - some scalar attribute of the action is affected
(e.g. extreme parameter values are used in service invocations).
• LESS : Less action is achieved than intended.
• AS WELL AS : Parallel action - as well as the intended
or normal action, some unexpected supplementary
actions occur or are intended.
• OTHER THAN : The action achieves an incorrect result.
Alternatively, the actor may use facilities for purposes
other than those intended, i.e. abuse of privilege.
 HAZOP: Actors Guidewords
in security (cont.)
• Capability
• – NO : Lack of the capability to perform the action.
• – MORE : More general capability, allowing more to be
achieved than intended.
• – LESS : Less general capability, allowing less to be
achieved than is required.
• – PART OF : The actor has only part of, or is missing a
specific part of the capability.
• – AS WELL AS : As well as the specific capabilities
required, the actor has other
• specific capabilities.
 Associations
• Associations of actors with use case model the
roles that interact with the system through the
functionality modelled in the use case.
• Interactions may represent the exchange of
information or invocation of system operations.
• We need a clear idea of which actors should be
able to access which use case for what purpose
• Covert channels can be thought of as
unintended associations.
 HAZOP: Association Guidewords in
security

• NO : Association does not/can not take place.

• MORE : Superfluous - Interface permits greater functionality to a
particular actor than is required. Association is not constrained as
required. Further divisions are:
– In-parallel with - More functionality is provided/occurs simultaneously
with the permitted ones.
– In-sequence with - More functionality provided/occurs before or after the
permitted ones.
• LESS : Interface permits less functionality to a particular actor than
is required. Association is over-constrained.
• AS WELL AS : Associations to a particular use case take place with
other actors
• as well.
• REVERSE : Interaction takes place in the reverse direction.
• OTHER THAN : Wrong association is defined. Swapping roles -
swapping of associations between actors or individuals.
 Use cases
• Use cases represent tasks that the system must
achieve on behalf of the associated actors. Use
case documentation includes pre-conditions,
post-conditions and sequence of actions.
• We can address the causes and effects of
variation by considering the deviations on each
step in the use case.
• Consider also deviations from pre- and post
conditions
 Use Case Elements Guidewords
• State (defined in a pre-condition or a post-condition)
• NO : The state or condition does not take place or is not
detected.
• AS WELL AS : Additional conditions apply. This may
mean that more stringent checks are made, or else a
more restrictive state results than is strictly required.
Errors of commission might be considered here.
• PART OF : Only a subset of the required conditions
apply. This might result from incomplete checks ,
incomplete implementation, or because the
consequences of system behaviour are not fully
understood.
• OTHER THAN : An incorrect condition applies. Perhaps
the wrong data is used.
 Use Case Elements Guidewords
• Action
• NO : No action takes place.
• MORE : More action is achieved. This may be one of the
following:
• Repeat - the same actions take place repeatedly.
• Superfluous - the system does additional actions to
those intended or required.
• LESS : Less is achieved than intended. For example, an
action is incomplete, or an action takes place for a
shorter time than required, or an action stopped earlier
than expected.
• OTHER THAN : An incorrect action takes place.
 Use Case Elements Guidewords
Sequence of Actions (scenarios)
LESS : Less is achieved than intended. For example, Drop - miss one or more
parts of action. Additionally, a sequence of action takes place for a shorter
time than required.
AS WELL AS : The sequence does the intended actions plus others.
REVERSE : The sequence of actions take place in reverse order (and other
outof-order concepts).
EARLY : The action sequence or its components takes place before it is
expected (timing).
LATE : The action sequence or its components takes place after it is expected
(timing).
BEFORE : The action sequence or its components happens before another
action that is expected to precede it.
AFTER : The action sequence or its components happens after another action
that is expected to come after it.
OTHER THAN : An incorrect action sequence takes place.
 Analysis
• The team systematically investigates each
use case element to identify deviation from
requirements.
• Each deviant is further investigated for
possible causes and effects.
 Analysis
The process has the following steps:
1. From a use case, identify and record:
– intent/action and capability of actors;
– associations between actors and use cases;
– components from use case description: pre-condition, main flow of events,
alternative flow of events (i.e. normal but perhaps less likely and exceptional/
error), post-condition.
2. Apply HAZOP guidewords with the appropriate interpretation, to each
element
identified in step 1, to suggest deviations.
3. Evaluate whether the identified deviations violate, or could violate, any
security
properties. Investigate possible causes of the deviations.
4. Identify consequences that may arise from the deviations (extract affected
assets from the identified consequences).
5. Categorise the deviations identified, and generalise each group.
6. Provide recommendations on the identified problems/threats.