Date post: | 25-Dec-2015 |
Category: |
Documents |
Upload: | amelia-lawrence |
View: | 215 times |
Download: | 0 times |
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
1.1.2.2 3-Pulse Counter
Spurious count
HB failure External Note I IV
1.1.2.3 3-Pulse Counter
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
HB failure External Note I IV
1.1.3.3 HB Failure No output HB failure External Note I IV
1.1.4.1 Signal received
No continue output
HB failure External Note I IV
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
State Transition Diagrams - 2
State Transition Diagrams - 3
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