BUCS seminar about HAZOP and UML

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

2. Overview • Introduction to OO, UML and System safety analysis. • Hazard analysis models and techniques • - FTA • - FMEA • - HAZOP • Conclusion and future work • Questions and discussion

3. 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.

4. 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.

5. 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.

6. Hazard analysis models and techniques • Fault Tree Analysis (FTA) • Failure Modes and Effects Analysis (FMEA) • Hazard and operability analysis (HAZOP)

7. FTA - 1

8. FTA - 2

9. FTA - 3 • Table 1. Table of the hazardous class behaviour • Wow = Weight on wheels

10. 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)

11. FTA - 4

12. 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

13. FMEA to Hardware items The most important concepts of the FMEA process are: • Parts can fail in several modes, each of which can produce different effects • The failure effects depend on the level at which it is detected (3 levels) • The failure effects could be masked or mitigated (lowered) by compensating efforts / measures (redundancy, alarms, barriers) • 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)

14. 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

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

16. Use Case Diagram Clock ticks Interval Generator Continue Signal Received Environment Counter Negation HB failure To establish loss of partner Alternating symbols = OK

17. FMEA Worksheet

18. 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.

19. 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.

20. 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.

21. 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

22. Guide words

23. 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]

24. State Transition Diagrams - 1

25. State Transition Diagrams - 2

26. State Transition Diagrams - 3

27. Class Diagrams - 1

28. Class Diagrams - 2

29. 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).

30. Sequence diagrams - 2

31. Sequence diagrams - 3

32. 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?

33. 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