Kristian Marheim Abrahamsen

A software tool for reuse of experience in HazOp

Department of Computer and Information Science, NTNU Autumn 2003

TDT4735 Software Engineering, Depth Study

Supervisor: Tor Stlhane

Abstract

TDT4735 Autumn 2003 Abrahamsen

Abstract

TDT4735 Autumn 2003 Abrahamsen

Abstract Most safety critical systems being produced today include software components. If these systems fail the result can be disastrous. Being aware of what hazards such systems have before they are produced can reduce the risks related to them. HazOp is a technique that helps an organization detecting hazards. Up to present, there are no computer programs which have been produced to support an organizations reuse of experience in previous HazOps. In this project I discuss the motivation and need for such a software tool. After looking at what functionality this program should contain, functional and non functional requirements are listed. Some program use examples will be illustrated by screenshots of windows filled with information. Further work for this project will be implementing a program that satisfies the requirement specification and do some tests to see what benefit it will have in an organization.

Contents

Preface This project report contains the contribution from Kristian Marheim Abrahamsen during autumn of 2003. The report discusses the need of a software tool that supports experience reuse from previous HazOps. I had some hardware problems during this project which made it difficult to implement the program. I planned to use Microsoft Visual .NET, but my machine started to reboot frequently without any warning. At date, this happened almost every minute. If it had not been for this problem, I could have implemented more of the program. I would like to thank my supervisor Tor Stlhane for giving very helpful advices, constructive criticism and motivating meetings. ________________________________ Kristian Marheim Abrahamsen Trondheim, Norway. November 28, 2003

Contents

Contents 1. Introduction ..................................................................................................................... 1

1.1 Hazards identification and methodology....................................................................... 1 1.2 HazOp.......................................................................................................................... 1 1.3 Purpose of this project.................................................................................................. 2 1.4 Project structure ........................................................................................................... 2

2. HazOp and Practice ......................................................................................................... 3 2.1 Initiating the study ....................................................................................................... 3 2.2 Planning the study........................................................................................................ 3 2.3 Conducting the study meetings..................................................................................... 4 2.4 Dealing with follow-up work ....................................................................................... 5

3. The Software Tool............................................................................................................ 7 3.1 Improvement of HazOp by use of existing knowledge.................................................. 7 3.2 Program information base ............................................................................................ 9 3.3 Relevant information.................................................................................................. 10

4 Requirement Specification.............................................................................................. 12 4.1 Functional and non-functional requirements............................................................... 12 4.2 Functional Requirements............................................................................................ 13

4.2.1 Main functions for the software tool .................................................................... 13 4.2.2 Selecting Project.................................................................................................. 13 4.2.3 Storing information ............................................................................................. 14 4.2.4 Editing Category Dialog Box............................................................................... 16 4.2.5 Finding Information ............................................................................................ 17 4.2.6 Design representation category............................................................................ 18 4.2.7 Group Selection................................................................................................... 20 4.2.8 Detected hazards ................................................................................................. 22

4.3 Non Functional requirements ..................................................................................... 23 5 Implementation ............................................................................................................... 26 6. Program use examples ................................................................................................... 27

6.1 Design representation category................................................................................... 27 6.2 Group selection category............................................................................................ 28 6.3 Detected hazards category.......................................................................................... 29

7. Conclusion ...................................................................................................................... 30 8. Suggested further work ................................................................................................. 32 9. References ...................................................................................................................... 33 Glossary.............................................................................................................................. 35

1. Introduction

TDT4375 Autumn 2003 Abrahamsen

List of figures Figure 2-1 Outline of the HazOp meeting process taken from [3].7 Figure 3-1 Project and knowledge base..9 Figure 3-2 Information Overload..10 Figure 4-1 Use case diagram for main program functions14 Figure 4-2 Use case diagram for Select project.15 Figure 4-3 Use case diagram for Store information..16 Figure 4-4 Use case diagram for Editing a category dialog box...17 Figure 4-5 Use case diagram for Find information..18 Figure 4-6 Use case diagram for Store inforamtion about design representation.....20 Figure 4-7 Use case diagram for Store information about group selection..21 Figure 4-8 Use case diagram for Store information about detected hazards22 Figure 6-1 Example of the Design representation dialog box29 Figure 6-2 Example of the Group selection dialog box..30 Figure 6-3 Example of the Detected hazards dialog box31

List of tables Table 2-1 HazOp meeting sheet taken from [3]..5 Table 4-1 Use case for Select project14 Table 4-2 Use case for Store information..15 Table 4-3 Use case for Editing a category dialog box...16 Table 4-4 Use case for Find information..18 Table 4-5 Use case for Store inforamtion about design representation.19 Table 4-6 Use case for Store information about group selection..21 Table 4-7 Use case for Detected hazard dialog box..23

1. Introduction

TDT4375 Autumn 2003 1 Abrahamsen

1. Introduction Some systems can have serious impact on their environment if they fail. For example if a control system for a nuclear power plant fails, the consequences for the people and environment around it can be disastrous. According to [1], Major disasters, particularly in the oil, nuclear and chemical spheres, have stimulated attention on risk reduction to protect the environment and human safety. These systems often contain software components. It is necessary to know how and why a system can fail to reduce the risk it poses to the environment. In this context we focus on system hazards. Hazards, accidents, and risks are all subjects that are tightly coupled. I will use the following definition of hazard in this project:

A hazard is a set of conditions, or a state, that could lead to an accident, given the right environmental trigger or set of events. An accident is the realization of the negative potential inherent in a hazard. [2]

Being aware of what hazards a system might present, and dealing with these problems is therefore crucial.

Society can always try to avoid taking risks. In many cases this is the right thing to do, but sometimes the trade off can be too high. To gain something you usually have to risk something.

( ) and so we learn to live with the inherent risks that surround us, because the cost of avoidance just seems simply too high. However, as technology becomes more and more ubiquitous, with more of that technology controlled by software, a greater portion of the risk we face is ultimately in the hands of software engineers. [2]

1.1 Hazards identification and methodology There exist several methodologies and techniques for identifying risks and hazards in systems. Some of the most common are What If?, Interaction Analysis, Zonal Analysis, Checklists, Fault Mode and Effect Analysis (FMEA) and H