BUCS seminar about HAZOP and UML Torgrim Lauritsen 09/02-04

BUCS seminar about HAZOP and UML

Torgrim Lauritsen

09/02-04

Overview

• Introduction to OO, UML and System safety analysis.

• Hazard analysis models and techniques• - FTA• - FMEA• - HAZOP• Conclusion and future work• Questions and discussion

Introduction

• There is an increasing interest in the use of an Object Oriented (OO) approach for developing software, and safety critical software systems too.

• The functionality of the system is realised by many objects collaborating through message passing to achieve a system function.

• OO systems have improved maintainability due to encapsulation, high cohesion and low coupling, and the facility for reuse through inheritance and design patterns.

• The Unified Modelling Language (UML) has become the a de-facto standard for modelling OO systems and is widely used throughout the software development industry.

• This was also the conclusion of the preliminary questionary investigation we did in the BUCS project autumn 2003.

System safety analysis - 1

• Hazard identification - identifies potential hazards in the system (deviation from the design)

• Risk assessment – evaluate how much of a threat each hazard are

• Preliminary system safety assessment (PSSA) - ensuring that a proposed design can meet its safety requirements and also with refining these safety requirements as necessary

• System safety assessment - producing the evidence that demonstrates the safety requirements have been met by the implementation.

• Safety case delivery - producing a comprehensive and defensible argument that the system is safe to use in a given context.

System safety analysis - 2• The primarily concern of system safety analysis is the management

of hazards:• - identification of hazards (possible failures)• - evaluation of possible techniques (isolate / avoid)• - elimination of the hazards (countermeasures)• - control through analysis, design and management procedures

• System safety vs. other safety approaches:its primarily emphasis on the early identification and classification of hazards so that corrective action can be taken to eliminate or minimize those hazards as part of the design process.

• Safety case: gather all the nessessary evidence to justify the system is safe.

Hazard analysis models and techniques

• Fault Tree Analysis (FTA)

• Failure Modes and Effects Analysis (FMEA)

• Hazard and operability analysis (HAZOP)

FTA - 1

FTA - 2

FTA - 3

• Table 1. Table of the hazardous class behaviour• Wow = Weight on wheels

State charts

• To identify more detailed derived safety requirements it is necessary to understand how the class may behave such that these conditions can occur.

• State charts (Figure 4)• Transitions in a state chart are of the general form

event [condition] / action.• The event triggers the state transition, boolean

expression • Apply guidewords to each of the elements of the relevant

transitions• Result (Figure 5)

FTA - 4

FMEA

• Failure Modes and Effects Analysis (FMEA) was introduced in 1954, and formalised in 1968.

• It is a technique for assessing the dependability of components and systems, in a safety perspective.

• The technique analyse and validates the items against reliability

• FMEA has been used with success in the process industy, in support of safety and reliability

• Consider failure modes of each part in a component (item)

• Easy to understand, and could decrease cost, and permit contraction of the development time

FMEA to Hardware items

The most important concepts of the FMEA process are: 1. Parts can fail in several modes, each of which can

produce different effects2. The failure effects depend on the level at which it is

detected (3 levels) 3. The failure effects could be masked or mitigated

(lowered) by compensating efforts / measures (redundancy, alarms, barriers)

4. The probability and severity of in-service failures can be reduced by monitoring provisions (built-in-test, supervisory systems)

• In addition to FMEA we could use other safety analysis techniques like FTA (Fault Trees Analysis) and HAZOP (HAZard and OPerability analysis)

FMEA to Software methods

• In object oriented software development, particularly where the UML methodology is employed

• The key here is that objects are uniquely characterized by their methods (sometimes called behaviors).

• A program in terms of methods, which provides a close analogue to the parts paradigm, used in FMEA.

• FMEA could give value to: • Component designer: find locations, effective/desirable • System engineer: shows failure effects • Project manager: allocate recources to vulnerability

areas• Logistic responsibility: planning test facilities

FMEA Worksheet

• Probability is missing here, but could be placed between failure and mission phase, and permit criticality assessment in FMEA.

Id.nr Item / functional identifi-cation

Items func-tion

Failure modes and causes

Mission phase / operational mode

Failure effects

*Local effects

*Next higher level

*End effects (System)

Failure Compensating

Severity class

Remarks

ss.mm.cc.ff

s=sub sys

m=major comp.

c=lower lev.

f=failure mode

Repeted for more than one failure modes

Task, job

Mode:

-Open

-Short

Cauce

-Ran-dom

-Over-load-Degra-dation

Different descrip-tions for each phase

Loc-al

The best place

to find failure

Next level

Sys-tem

Differ-ent

failures

Differ-ent effors

I

II

III

IV

Comm-ents

Use Case Diagram

Interval Generator

Counter

HB failure

Signal Received

Clock ticks

Continue

Environment

Negation

To establish loss of partnerAlternating

symbols = OK

FMEA WorksheetID Item /

functionFailure Mode & Causes

Local Failure effect

Failure Detection

Compensation Severity

1.1.1.1 Interval gen. No interval HB failure External Note I IV

1.1.1.2 Interval gen. Long interval

HB failure External Note I IV

1.1.2.1 3-Pulse Counter

No count HB failure External Note I IV


Spurious count



Spurious count

Spurious HB

External Note I II

1.1.3.1 HB Failure Does not send negotion

None External 3 pulse counter to signal recvd

1.1.3.2 HB Failure Spurious negation


1.1.3.3 HB Failure No output HB failure External Note I IV

1.1.4.1 Signal received

No continue output


1.1.4.2 Signal received

Spurious continue output

None External 3-pulse counter to HB failure

HAZOP

• The Hazop method is performed by a multidisciplinary team, and request the team members to think creatively about what undesirable incidents that could happen. A component may work well alone, but together with others it can arise undesirable situations.

• Guide words are used to stimulate to creatively thinking, so that most of the potential deviations are discovered.

• Hazop identify deviations from required behaviour or design intent (procedures and routine descriptions) that can lead to unwanted incidents, and identification of hazards caused by such deviations.

• Therefore we must also analyse deviations from intended behaviours from humans which are going to develop, manage / drive, maintain or use the business-critical tool.

• It is the attributes deviation from the design intention which is inspected in Hazop.

• The guidewords consider the behaviour of ”flows” between system components.

The hazop team• It is important to have a leader who could manage the team through the

process in a structured way.

• 1) Team leader• 2) Designer• 3) User• 4) Expert• 5) Secretary

• Information flow happens in different communications levels:• - between applications, • - between network components and • - between humans.

Entities and attributes • Attributes in software :

• - data/control flow - data storage: how much is used, speed in retrieval

• - data value - data rate• - relationship - process• - task - data to / from store• - disclosure - manipulation• - denial - confidentiality• - integrity - accessability, availability• - intentional - insider• - spamming - threat• - deviations

• After we have desided the attributes, we make a list over which enteties who has which attributes.

• Entities:• - Components, e.g hardware, software, mechanical and electronical components.• - Connections between components, which means transferring from one component to another,

e.g dataflow or flow of chemical fluid.

Analysis process

• 1) Choose one and one entity based on the design representation

• 2) For every entity, identify all attributes to the entitiy

• 3) For every attribute, use all guide words to identify deviation from the intention

• 4) For every deviation, examine causes and consequences

• 5) Repeat the process if there are still more representations

Guide words

Guide words Meanings Comments

NO or NOT Negation of these intentions Nothing happes

MORE or LESS Increases or decreases Quantities

AS WELL AS Qualitative increase Some intentions achieved, others are not

PART OF Qualitative decrease

REVERSE Opposite

OTHER THAN Substitution Something completely different happens

EARLY or LATE Related to the clock time

BEFORE or AFTER Related to order or sequence

Guide words• It is a challenge to find the correct guide words, they should be so generic that

they do not limits the ideas, but on the other hand (also) so specific that all deviations and threats are revealed / discovered.

• There are important to interpret the guide words in different ways when we use them on different systems.

• Combine more than one guide words with each attribute [Winther]

• Pre-guideword Attribute Of Comp. Due to Post-Guideword

Deliberate Manipulation Of Firewall Due to Insider

Unintential Denial Of Service Due to Technical failure

Pre-Guideword Attribute Post-Guideword

Deliberate

Unintentional

Disclosure

Manipulation

Denial

Of COMPONENT due to

Insider

Outsider

Technical failure

State Transition Diagrams - 1



Class Diagrams - 1

Class Diagrams - 2

Sequence diagrams - 1• Compared to class diagrams and statecharts, sequence diagrams are

imprecise,representing examples or instances of behaviour which could be more comprehensively and accurately defined in these other models.

• The main entities in a sequence diagram are objects and messages. • Objects have the following attributes:

(i) their (runtime) class; (ii) their lifetime.

• Messages have the following attributes: (i) data; (ii) time of occurrence; (iii) source object; (iv) destination object; (v) condition; (vi) delay; (vii) duration (in the case of synchronous messages).

Sequence diagrams - 2

Sequence diagrams - 3

Conclusion and further work

• Once the safety requirements for the classes in the system have been derived it is necessary to specify them.

• Use Object Constraint Language (OCL)

• UML / RUP

• In RUP – risk analysis included, how to use it?

Literature search

• ”Bruk av HAZOP for risikoanalyse av forretningsstøtte systemer” by Doreen Fossan Tumert, 2001

• ”FMEA as a validation tool for hardware / software systems” by Herbert and Myron Hecht, 2002

• ”An Approach to Designing Safety Critical Systems using the Unified Modelling Language” by Richard Hawkins, Ian Toyn, Iain Bate, 2003

• ”Safety and Security Analysis of Object-Oriented Models” by Kevin Lano, David Clark, and Kelly Androutsopoulos, Safecomp 2002

Documents

BUCS seminar about HAZOP and UML Torgrim Lauritsen 09/02-04