Experience with the application of HAZOP to computer-based systems J. A. McDermid , M. Nicholson , D. J. Pumfrey and P. Fenelon British Aerospace Dependable Computing Systems Centre and High Integrity Systems Engineering Group, Department of Computer Science, University of York, Heslington, York YO1 5DD, U.K. email jam mark djp pete@minster.york.ac.uk Abstract— This paper summarises the experience gained from application of Hazard and Operability Stud- ies (HAZOP) and related techniques to four computer-based systems. Emphasis is placed on working practices and the in- tegration of HAZOP-style analysis into a safety-oriented li- fecycle. Two of the case studies are described in some de- tail. An industrial study is used to investigate working prac- tices, highlighting a number of areas of concern with the tra- ditional team approach. A second example is described using an alternative process known as Software Hazard Analysis and Resolution in Design (SHARD), showing its effective- ness on a technology demonstrator case study. This example also demonstrates the integration of our approach with other techniques such as our Failure Propagation and Transforma- tion Notation (FPTN) and Software Fault Trees. I. I NTRODUCTION At COMPASS ’94 we presented a paper [1] which de- scribed a method of software safety analysis based on ideas drawn from the process industries’ Hazard and Operability Studies (HAZOP) [2][3]. Since that conference, we have had the opportunity to attempt practical application of these ideas to a number of real systems. This paper summarises the ex- perience we have gained. For one of the systems studied, we also show how this type of analysis is integrated into a safety- oriented development lifecycle. HAZOP is described as a system of imaginative anticipa- tion of hazards, which uses a set of guide words to prompt a team of analysts to consider the hazard potential of various deviations from the expected behaviour of a system. We con- sidered that these guide words, combined with an emphasis on flows rather than processes made HAZOP an interesting basis for developing a safety analysis technique for software. The work described in the paper we presented last year con- centrated on the technical aspects of the method — in particu- lar, the selection of guide words. The application of HAZOP to software is too recent an idea for there to be “tried and trus- ted” guide words, and we were unable to find any accessible incident databases which would have allowed us to develop or test sets of guide words by examination of real failures. In- stead, we proposed the use of a set of guide words based on research into the classification of software failures [4]. A further goal of our work was to show how a closer in- tegration could be achieved between hazard and safety ana- lysis and design. In particular, we wanted to show how early analysis could be used to drive the design process, suggest- ing modifications and improvements or providing justifica- tion for a particular option. In the case study work, we have sought both to test and re- fine the technical aspects of the technique, and also to study different ways of working, to determine whether the team approach favoured by the chemical industry is appropriate for the systems development environment. The “traditional” team HAZOP approach is summarised in figure 1. There is relatively little work carried out in advance of the study meet- ing except for preparation of the necessary information. The effort is concentrated in the meeting itself, where an iterative process of identifying, examining and recording deviations is carried out for every information flow in the design. Our early work led us to believe that there were two major potential drawbacks to this approach: 1. It was clear that a team approach is expensive, and we were not convinced that the cost could be justified by the potential benefits. 2. The team brief is only to identify hazards, and not to sug- gest specific actions to rectify problems. This is a rather narrower brief than we considered to be ideal. This led us to propose an alternative approach, in which ana- lysis becomes an integrated part of system development. This new method was christened Software Hazard Analysis and Resolution in Design (SHARD), to avoid confusion with “tra- ditional” HAZOP. In this new approach, the majority of the analysis becomes an individual, rather than a team, task. As each part of the system design is produced, it is the responsibility of either the designer, or a single independent assessor, to conduct an analysis, based on the principles of HAZOP. This analysis must either be shown to justify the design proposal, or im- pose a number of emergent requirements which must be sat- isfied later in design development. If it is clear from the analysis that design revisions are required, these are imple- mented immediately, and the analysis repeated as necessary.