Integration Modelling of Process Industry Safety Initiativesmark/projects/dhm104_project.pdf• All...

of 94

Integration Modelling of Process Industry Safety

Initiatives

Author: David Huw Morgan

Supervisor: Dr Mark Nicholson

Project report submitted as part requirement for the Degree of Masters of Science in Safety Critical Systems Engineering

in the Department of Computer Science

at the University of York

September 2005

Number of words = 33,025, as counted by the Word word count command. This includes the body of the report and Appendix A.

of 94

Integration Modelling of Process Industry Safety Initiatives

Abstract

At present, the system safety activities in the process industry sector are not integrated. These activities are specified by safety standards and their relationship is represented by the traditional series lifecycle model in the standards. In practice, the safety activities during the operational period of a system tend to occur more simultaneously than sequentially. Due to this, an information model representation of the activities would more accurately illustrate the present situation. An information model has been developed to integrate the system safety activities during the operational phases. This information model has been subjected to a failure analysis to ensure the completeness of the model and to identify and quantify the possible information failures that would present a system safety risk. The impact of change and change propagation upon and within the model has also been assessed. The developed information model has been shown to reflect the activities associated with the actions of a chemicals manufacturing organisation. The application of established hazard analysis methods to an information model has identified a comprehension range of potential information failures. A proposed method of allocating critically ratings to information flows has been presented.

of 94

Table of Contents Chapter 1....................................................................................................................5

1.0 Introduction......................................................................................................5 1.1 Safe design, operation and maintenance..........................................................6 1.2 Motivation for this project ...............................................................................7

Chapter 2 (Literature Survey) ..................................................................................10 2.1 Data definition in the context of this research ...............................................10 2.2 Engineering Standards ...................................................................................10 2.3 Process industry standards .............................................................................11 2.4 The regulator, COMAH and IEC 61508........................................................13 2.5 A process specific standard: IEC 61511 ........................................................15 2.6 Outline compliance to IEC 61511..................................................................16 2.7 Legislative framework for accurate information systems..............................17 2.8 Information control ........................................................................................18 2.9 Information used during operation & maintenance .......................................19 2.10 Work Flow Lifecycles..................................................................................20 2.11 Lifecycles, Data and the Design Process .....................................................21 2.12 Adoption of the lifecycle principle in the process industry .........................23 2.13 Data and information models.......................................................................24 2.14 Data correctness and validity .......................................................................24 2.15 Data /Information flow ................................................................................27 2.16 Cost of data ..................................................................................................28 2.17 Collection of data.........................................................................................28 2.18 Process industry data....................................................................................28 2.19 Alternative structure / non chronological ....................................................31 2.20 Information Models and model representation ............................................32 2.21 Developed information models....................................................................35 2.22 Methods, techniques and tools definitions...................................................38 2.23 Activity integration ......................................................................................39 2.24 Control of the model ....................................................................................40 2.25 Change impact analysis of information models...........................................42 2.26 Literature survey review ..............................................................................44

Chapter 3 Integrated Model development................................................................45 3.1 Integrated Model development ......................................................................45 3.2 Identification of safety activities within the process industry .......................46 3.3 Integration of identified activities ..................................................................47 3.4 How the model responds to a change ............................................................50 3.5 The benefits of the integrated model .............................................................54

Chapter 4 Model validation .....................................................................................56 4.1 Information validation technique development .............................................56 4.2 HazOp analysis applied to information flows................................................56 4.2.1 Guide words development information flows.............................................56 4.2.2 Example / test run using identified guidewords..........................................58 4.3 HazOp review of the integrated model’s information flows. ........................63 4.3.1 Information Flow HazOp analysis results...................................................66 4.3.2 Hazop Output Review.................................................................................73 4.3.3 Hazop conclusions ......................................................................................74 4.4 HazOp Analysis validation ............................................................................74 4.4.1 Validation technique ...................................................................................75 4.4.2 Functional failure analysis of the information model .................................75

of 94

4.4.3 FFA output review ......................................................................................80 4.4.4 FFA conclusions .........................................................................................80 4.5 Information analysis technique comparison ..................................................80 4.6 Model completeness from analysis using both analysis techniques ..............81 4.7 Model improvement.......................................................................................81 4.7.1 Application of AEL to information flows...................................................81

Chapter 5 Conclusions and further work .................................................................85 5.1 Conclusions....................................................................................................85 5.2 Further work...................................................................................................86

References................................................................................................................88 Appendix a the integrated Model Data Kinds......................................................92 Acknowledgements..............................................................................................94

List of Figures

Figure 1 Causes of explosions associated with gas fired plant ......................................7 Figure 2 Root causes of incidents ................................................................................14 Figure 3 Data values and definitions ...........................................................................25 Figure 4 How data models deliver benefit ...................................................................32 Figure 5 How data models deliver system safety ........................................................33 Figure 6 Process Plant Engineering Activity Model....................................................35 Figure 7 PIEBASE model for technical work..............................................................36 Figure 8 The Safety related Activity Model (SAM)....................................................37 Figure 9 Change propagation patterns .........................................................................43 Figure 10 Initial safety initiative model......................................................................45 Figure 11 The developed integrated information model on page 49 ...........................48 Figure 12 The Regulator information loop on page 51................................................50 Figure 13 The integrity level information loop on page 52 .........................................50 Figure 14 A micro view of the integrity level determination activity .........................87

List of Tables Table 1 System safety activities in the Process Industry .............................................46 Table 2 process industry System Safety Information flows ........................................48 Table 3 The model change impact analysis .................................................................53 Table 4 Information flow HazOp potential guideword list..........................................57 Table 5 Trial Information flow HazOp ‘2.4 Integrity levels for hazards’ ...................60 Table 6 Trial Information flow HazOp ‘8.1 Approval to operator’.............................61 Table 7 Information flow HazOp final guideword list ................................................63 Table 8 Information flows from the development model for HazOp review ..............64 Table 9 Possible outputs for HazOp review ................................................................66 Table 10 Information Flow HazOp: 1.1 Hazard Log...................................................67 Table 11 Information Flow HazOp: 4.1 Actual demand rate ......................................69 Table 12 Information flow HazOp: 4.2 Actual occupancy and vulnerability..............70 Table 13 Information Flow HazOp: 9.2 Hazard consequences ..................................71 Table 14 Information flow HazOp: 9.3 Tolerable risk criteria ....................................72 Table 15 Functional failure analysis on the Integrity Level determination activity ....79 Table 16 AEL safety criticality (taken from CAP 670 SW 01 Appendix A) ..............82 Table 17 AEL criticality change due to Architectural & operational defences...........83 Table 18 AEL related to information flow criticality ..................................................83 Table 19 Reduction of information flow AELs ...........................................................84

of 94

Chapter 1

1.0 Introduction Society’s perception of the oil and chemical industry’s commitment to health, safety and the environment has been sharply influenced by the series of catastrophes that have occurred in recent times. Flixborough, Seveso, Bhopal, Mexico City, Piper Alpha, and Exxon Valdez are now an all too familiar litany of events and the basis of public concern. The first three of the incidents occurred in the chemical processing industry and all three occurred in a relatively short period, during the decade 1974 to 1984. A summary of each incident is given below. These have been directly extracted from [1]. June 1, 1974 - Flixborough UK: a caprolactam production unit had a release of cyclohexane resulting in an unconfined vapor cloud explosion. The incident caused 56 injuries off-site, as well as 36 injuries and 28 fatalities on-site. On-site, most of the property was severely damaged. The off-site damage was spread over 8 miles, involving over 2400 homes and businesses. July 10, 1976 – Seveso, Italy: the contents of a 2,4,5-trichlorophenol (TCP) reactor experienced an exothermic, runaway reaction, resulting in the lifting of a rupture disk. A plume containing TCP, caustic and approximately 1.75 kg dioxin was released, exposing the community to the toxic chemicals. While no permanent injuries or fatalities were reported, approximately 470 people suffered caustic burns, including more than 30 cases of chloracne. More than 4 square kilometers of agricultural land near the site was sterilized for years. December 2, 1984 – Bhopal, India: a cyanide release occurred due to the introduction of water into a methyl isocyanate storage tank. The release resulted in more than 2500 fatalities and 170,000 injuries. Thousands of the injured were seriously disabled, including long term respiratory and vision damage. There are moral and legal duties placed upon companies that must be satisfied. The legal duties relevant to the process industries and how these duties are derived from legislation are explored later. The public’s attitude is changing and increasing focus is placed on the health, safety and environmental performance of companies. Safety and environmental statistics are being reported together with financial aspects when companies make presentations regarding future targets and past performance. There is now a greater understanding of safety risk within society. This understanding is allowing the public to consider the benefits and dangers of industrial operations. One of the most notable are the operations associated with the chemicals process industry due to the occurrence of incidents summarised above. Safety of systems in any sector of industry including the oil refineries and the process industries depends upon a number of factors. A high level view of the three most important are: how a unit is designed, how it is constructed (i.e. the workmanship), and how it is operated and maintained.

of 94

It is impossible to safely operate equipment that is basically faulty in design and inadequately maintained; also it is virtually impossible to build facilities that are foolproof in the hands of improperly trained operators. Industry must provide properly designed facilities that can be safely operated by following normal operating procedures. Maintenance of these facilities is essential for continued safe operation. All systems that can present a risk to people or the environment should be designed to operate as safely as practicable. This involves the assessment of risks judged against the consequence of incidents and the cost of avoidance. One method of achieving this is to design out the source of any unsafe actions, components or hazards, by designing a system that this inherently safe. There will always be a balance between designing out all the anticipated risks, the practicality of doing this and the cost associated with achieving this aim. This is why the concept of a risk-based philosophy such as “As Low As Reasonably Practicable” (ALARP) has been developed. A definition of ALARP is given on the HSE website as “you must do everything that can be done to reduce a risk to its lowest possible level, except that you don’t have to do something where its cost is clearly excessive, compared to the size of the risk reduction” [2]

1.1 Safe design, operation and maintenance The outline objective of a safe design is to deliver a design where: • All hazards have been identified, assessed, understood and documented. • Every opportunity to minimise the risks at source have been identified, considered

and, where practicable, implemented. • A practical strategy to manage each of the primary risk drivers has been developed

and agreed with those who will have to implement it. • An effective and reliable combination of measures to implement the strategy has

been put in place. • These objectives are achieved for the whole lifetime of the system. In short, it is a design that is acceptably safe to build, operate and to remove or demolish. In the ideal situation a system would have an incident free existence or lifecycle. An argument that is used in the process industries to counter the risk of hazards is that the technical integrity for the operations must be assured. Technical integrity can be summarised by and is concerned with those processes that provide soundness in the design, quality in the manufacture, clarity in the operating procedures, and effective communication of the requirements to all participants and suppliers in the industry. The aim is to make sure that process facilities do not fail in such a way that has potential safety consequences. The parallels here with reliability requirements and targets cannot be ignored. A reliable system will generally be a safe one and will be an efficient system to operate.

of 94

1.2 Motivation for this project Robust information exchange between engineering tools is an area of concern for many industry sectors. Possible problems that could occur are the loss of specification or accuracy when information is transferred across engineering discipline boundaries, between departments and during information transmittal between organisations. As the number of tools and techniques developed for addressing different engineering activities increases then the problem over compatible data exchange interfaces increases. A data or information model would define the communication paths across interfaces and so allow analysis of the information flows. This analysis would then identify possible vulnerabilities and mitigation for these vulnerabilities. It is felt that such an approach based upon the safety engineering practices in the process industry would be beneficial. At present little work in information modelling for this industry sector has taken place. Once an information model has been developed and a failure analysis has been completed then a method to assign criticality to the data paths will be explored. Management activities should ensure that information and communication are controlled in a suitable manner indicative of the processes being carried out. In the safety-engineering field, this means that safety management should ensure that controls are in place to maintain the integrity of information according to the level of risk associated with the work. A study by the HSE [3] into the causes of explosions associated with gas-fired plant found that the vast majority of failures resulting in an accident were due to safety management failures. The chart below presents the results of this study:

[3]

Figure 1 Causes of explosions associated with gas fired plant

In this study approximately 70% of failures were attributed to Process safety management. As management has an influence over information and communication then any improvement in information usage will reduce the possibility of process safety management failures resulting in accidents.

of 94

The development of a model to represent the latter lifecycle phases (such as operation, or maintenance) is one aim of this project. This will be achieved by research into information and data models and also the safety- engineering initiatives required in the process industry sector. There are a number of activities that must be accomplished to ensure safe operation of a process facility. It is felt that there will be enormous benefit in reviewing these activities from an information modeling perspective with the aims of integrating them via the information flows that must take place. The format of the information flows will be defined and reviewed to identy any flows not recognized at present. Once a model has been developed then this model will be tested to establish its robustness against errors and change. An analysis will be completed of the developed model to identify potential errors that could occur in the information flows. An information flow model would also provide a method whereby the traceability of a design decision could be followed. A defined and controlled flow of information can provide a retrospective audit path in case of an incident or regulator audit.

A number of areas or activities must be addressed or completed to allow a system to evolve from concept to operations. A simplified list would be:

1. Concept/feasibility 2. Requirements and specification 3. Preliminary design 4. Hazard and risk analysis 5. Safety allocation 6. Manufacture / build / configure 7. Installation and testing 8. Operation, maintenance and modification 9. Disposal

These activities are chronological in nature and due to this are often represented in a lifecycle model. The lifecycle is a series arrangement and progression through the model is achieved by completion of work activities before the following activity can be started. Although progression through the lifecycle model does continue whilst using partial or provisional information. This necessitates the need for a feedback to incorporate more detailed information into the design. Through experience and research it has been found that the latter phases of a lifecycle frequently operate in parallel. The parallel activities do not necessarily fit into the chronological or series lifecycle model. During the operational phase it is common to have activities such as maintenance and modification being under taken by different teams at the same time. The control and flow of information between these concurrent activities is essential to the successful outcome of the activities and to ensure technical integrity and therefore safety are not compromised. The plans and procedures that form a part of the system provide an orderly basis for planning the work in a manner that avoids potential problems. The monitoring functions that are part of the quality system provide assurance that work processes are conducted in accordance with the procedures. During the development and documenting of the safety lifecycle system the definition of technical interfaces are of

of 94

paramount importance. Although producing quality work is the responsibility of each person assigned to a project team, the organisation has to be in place to support that work. This requires the definition of all roles, responsibilities and communication paths. The integrated model will allow the definition of communication paths to be fully defined. This will include the format of the communication, the source and then destination of the information. The criticality of the information should also be included, as this will determine the impact of change, justify the cost of the data and the accessibility to external regulators. The integration of the safety related activities forms the research subject for this project. It was felt that there would be great benefit in analysing the safety related activities within the process industry, determining the inputs and output of each and using this information to develop an integrated information model. The control of changes and sensitivity of the model to these changes and inaccuracies / errors in the information flows could then also be reviewed. The assessment of change impact would also provide the industry with a tool to assess changes at an earlier stage than is currently available. An analysis into the potential errors within the information model would provide evidence as to the completeness of the model.

of 94

Chapter 2 (Literature Survey) A number of elements will be reviewed in this chapter. Firstly it will demonstrate the requirements of the standards and legislation for robust communication and information models. It will review the concept of safety lifecycles to explore the possibility of an alternative form of representation for safety system activities. The factors that determine information or data integrity will be reviewed. This will lead to the affects of change and the assessment of change impact upon an information model, which will be developed for consideration during the analyses carried out in chapter 4.

2.1 Data definition in the context of this research There have been a number of papers produced that identify the issues and propose solutions to the problem of data integrity within safety systems. The focus of the majority of this research has been concerned with the data processed by a software system. The data referred to in this project will be data and information required to operate, maintain and modify a safety system. It is the engineering information used by humans beings in their work activities associated with maintaining acceptability safe process facilities.

2.2 Engineering Standards Engineering Standards have a central role in delivering technical integrity by providing a recognised and competent foundation of engineering experience and a vehicle for consistent communication. An information model can define the communication associated with the safety systems. By review of the relevant safety standards, it is intended to demonstrate that the requirement of safety system information models is recommended, although the standards may not specifically refer directly to information models. This chapter also develops the linkage between legislation and the use of standards. It will be shown that this linkage then provides justification for the development and use of safety system information models to control risk and maintain adequately safe systems. In many countries legal requirements make it necessary to apply recognised codes and standards in all applications relevant to safety. In many instances regulatory authorities are required to formally approve a safety case for an installation or system that could present a hazard. Demonstration that appropriate standards have been followed is an important part of any safety case. Standards assist the engineer to achieve the acceptable level of technical integrity. Leveson sums up the value of standards as “codes of practice and standards are one of the principle ways that engineers organise lessons learned and effective solutions in a form that can be easily digested and passed forward” [4]

of 94

Many standards overlap and duplicate each other. A clear view on the standards to be adopted by the facility must be set out at the outset of an operating strategy. This should not be done in isolation but should take into account the following:

International requirements National requirements (e.g. local legislation) Appropriateness to the technology Chemical procedures and codes of practice Regulator expectation

Standards define the criteria for materials, products, processes and services in precise authoritative and publicly available documents. They embrace product and performance specifications, codes of practice, management systems, methods of testing, measurement, analysis and sampling, guides and glossaries. Standards set up principles and systems of work to:

• Facilitate design and manufacture • Establish safety criteria • Promote quality with economy • Assist communication • Inspire confidence in manufacturer and user

National and international standards are not created by governments. The standards are created by the users of the standards. These are normally the companies in the relevant industries but also professional and academic institutions work to produce practical and workable standards.

2.3 Process industry standards The main piece of legislation that governs the activities of the chemicals industry is the Control of Major Accidents Hazards regulations 1999 (COMAH) [2]. These regulations came into force on 1st April 1999 and are implemented under the Seveso II Directive. This directive was put in place as a result of the Italian Seveso incident described earlier in section 1.0. The COMAH regulations are enforced by a competent authority (CA) In England and Wales the CA is the Health and Safety Executive and the Environment Agency and the Health and Safety Executive and the Scottish Environment Protection Agency in Scotland. The purpose of the regulations are “to prevent and mitigate the effects of those major accidents involving dangerous substances, such as chlorine, liquefied petroleum gas, explosives and arsenic pentoxide which can cause serious damage/harm to people and/or the environment. The COMAH Regulations treat risks to the environment as seriously as those to people.” [2].

The focus of the regulations is the preparation of a safety report or safety case. The contents of this report, as stated on the HSE website [2] are:

1. A policy on how to prevent and mitigate major accidents; 2. A management system for implementing that policy; 3. An effective method for identifying any major accidents that might occur;

of 94

4. Measures (such as safe plant and safe operating procedures) to prevent and mitigate major accidents;

5. Information on the safety precautions built into the plant and equipment when it was designed and constructed;

6. Details of measures (such as fire-fighting, relief systems and filters) to limit the consequences of any major accident that might occur; and

7. Information about the emergency plan for the site. This is also used by the local authority in drawing up an off-site emergency plan.

COMAH schedule 4 specifically includes control systems. The salient points quoted directly from the Control of Major Accident Hazards Regulations 1999 that refer to factors under consideration of this project, communication of information, are as follows: Schedule 4 Part 1: PURPOSE OF SAFETY REPORTS are: 1 demonstrating that a major accident prevention policy and a safety management system for implementing it have been put into effect in accordance with the information set out in Schedule 2; 2 demonstrating that major accident hazards have been identified and that the necessary measures have been taken to prevent such accidents and to limit their consequences for persons and the environment: 3 demonstrating that adequate safety and reliability have been incorporated into the design and construction operation and maintenance of any installation, equipment, and infrastructure connected with its operation that are linked to major accident hazards within the establishment: 4 demonstrating that on-site emergency plans have been drawn up and supplying information to enable the off-site plan to be drawn up in order to take the necessary measures in the event of a major accident; 5 providing sufficient information to the competent authority to enable decisions to be made in terms of the siteing of new activities or developments around populated establishments. “[5] It is items 3 and 5 of this schedule that provide the framework within which the scope of an information model should be developed. The demonstration that the safety systems have been designed, constructed, operated and maintained correctly dictates that these activities are completed. Adequately providing sufficient information to the CA and within an organization is critical to the approval for the operation of any hazardous installation. This develops the requirement of an information model that will achieve these objectives. It is essential that the safety report is maintained and kept up to date. The safety report must also be reviewed and revised if any changes or modifications to the chemical facility are undertaken, the method in which it is operated changes or if new data or information becomes available. The report has to be reviewed on a regular basis. At present this is every five years even if there have not been any modifications as detailed previously The safety report can then be considered a significant document to argue the safety case of a company’s procedures facilities.

of 94

An information model would assist in the assessment of change or modifications to the facility. A change impact analysis could be completed more thoroughly once all of the activities and dependencies between the system safety activities are defined.

2.4 The regulator, COMAH and IEC 61508 The HSE have produced a publication entitled “Safety Assessment Report Manual”. The purpose of this document is to assist chemical facility operators in producing and maintaining COMAH reports. This document contains specific details concerning control systems. It states that “systems should be designed in accordance with an appropriate standard or code” [6] The CA views the IEC standard 61508 as providing a valuable means by which to assess the suitability of a facilities risk reduction approach. As the standards are risk based it has a number of advantages over previous safety standards, which were mainly prescriptive in nature. A number of these advantages of IEC 61508 over previous standards or engineering guidance are given in [7]. These are: - Embracing current best practice to aid demonstration of ‘Due Diligence’ to mitigate legal risks; - Understanding the implications of complying with IEC 61508 to aid mitigation of commercial risk; - Minimizing engineering, capital and operating costs on projects by utilising the risk-based approach; - Demonstrating the capability to provide a marketing advantage. The above advantages are from an engineering contractor’s perspective but are also valid for an end user or an operator. The HSE have used the IEC 61508 standard as a benchmark when assessing COMAH reports submitted by chemical facility operators. This then establishes the significance of the standard. The standard is being held up as a recognised code of practice and the CA is utilising it as an assessment tool. The operators of hazardous installations should then also be basing their safety instrumented system (SIS) philosophy upon the standard to which it will be audited. The position of the HSE when assessing COMAH reports and using IEC 61508 as a recognised code of practice is that “The safety report should describe how safety- related systems have been designed to ensure safety and reliability” [8] This area of technical assessment is carried out by the HSE’s Electrical &Control Engineering Inspectors who look for the following:

–Relationships between main accident hazard risk reduction requirements and required safety integrity of safety instrumented systems (SIS)

– Evidence of systematic determination of required safety integrity levels (SIL)

– Demonstration of how the required SILs have been achieved – Information on requirements for proof testing; maintenance; configuration

/ change control etc.

of 94

From the HSE statements it is apparent that the adoption and implementation of the IEC 61508 standard can contribute in no small part to achieving compliance with the COMAH regulations. As the IEC 61508 standard is not linked to a European directive then it is not mandatory and so its use cannot be insisted upon by the CA. If the standard is not being utilized by a company then the operating organization must demonstrate that the safety standards utilized are as least as good as IEC 61508. If the CA is using a standard to assess the safety cases and also holds the principles of the standard in making their assessments then adopting the same standard will result in cost savings and a less arduous audit by the regulator. In addition, any corrective action recommendations demanded by the CA will be based upon the practice outlined in the IEC 61508 standard. HSE field inspectors are “increasingly using IEC 61508 as a core element of their work on safety” [8]. The HSE Board Statement makes this very clear “IEC 61508 will be used as a reference standard for determining whether a reasonably practicable level of safety has been achieved when E/ E/ PE systems are used to carry out safety functions. The extent to which Directorates/ Divisions use IEC 61508 will depend on individual circumstances; whether any sector standards based on IEC 61508 have been developed and whether there are existing specific industry standards or guidelines” [9] It can be seen that by distilling down from European law and directives to UK legislation in the form of the COMAH regulations and using the CA’s view of the IEC 61508 standard that there is a direct relationship between the functional safety of electrical/electronic/ programmable electronic safety-related systems and compliance with legislation. This forms the baseline and motivation for adoption of referenced standards and the need for achieving satisfactory adherence with the IEC standards. Another motive for this project is initiated by the HSE by the information presented in the 1995 HSE publication entitled “Out of control”[10]. Within this document there is presented the results of a study into over 30 incidents that occurred in the UK. The root causes of these incidents have been investigated and it was found that the sources of failure were due to errors in: specification, design, implementation, installation and commissioning, operation, maintenance and modification. The relevant proportions of each source of failure are presented below:

Figure 2 Root causes of incidents

of 94

All of these errors can be classified as systematic as defined by IEC 61508 “failure related in a deterministic way to a certain cause, which can only be eliminated by a modification of the design or of the manufacturing process, operational procedures, documentation or other relevant factors” [11] These faults are introduced by human involvement. This then provides another justification of the use of a safety standard that specifies the controls necessary to minimize systematic errors. It should also be noted that if the IEC 61508 lifecycle had been in existence the period over which the incidents, analysed by the HSE in Out of Control, occurred then these errors would have been introduced throughout all phases of the 61508 safety lifecycle. It is felt that improved defined paths of communication and control of this information will defend against the source of a majority of errors highlighted above. A safety system information model will provide a method of defining the paths of safety system data and information flows.

2.5 A process specific standard: IEC 61511 As IEC 61511 is the process sector specific standard for safety instrumented systems (SIS) then we shall consider this standard in future for this report. A disadvantage of the standard IEC 61508 is the fact that it is a generic standard. This results in organisations having to interpret this standard, relate it to their own industry sector and then produce company specific procedures for achieving the requirements of the generic standard. This disadvantage is some what removed by publication of the process industry’s specific standard IEC 61511 as this relates directly to the targeted sector. A process industry vocabulary is also used throughout IEC 61511, which helps companies adopt the standard and relate it to their own company standards and specifications. Safety instrumented systems (SIS) have been used for many years within the process sector. The original approach was prescriptive with standards (for example, API RP 14C in the offshore sector) stating the specific equipment to use for a particular process application. In recent years, the increased complexity of new applications and the complexity of new equipment becoming available for use have made the prescriptive approach insufficient. This is particularly the case where programmable equipment with complex failure modes is used for safety applications. The international community recognised the need for new standards, and the International Electro technical Commission (IEC) developed a new generic standard that adopted a risk-based approach. The standard IEC 61508 (Functional Safety of Electrical/ Electronic/Programmable Electronic Safety-related Systems) was published in seven parts between 1997 and 2000. Before IEC 65108 was published, a need was recognised for a process sector standard and work commenced on IEC 61511 (Safety Instrumented Systems for the Process Industry Sector). IEC 61511 applies the generic standard IEC 61508 to process industries. It also incorporates experience from national and industry standards, such as ISA S84.01. Since publication of IEC 61508, the process sector has had significant experience in the application of the risk-based approach.

of 94

The risk-based approach tailors equipment to the needs of the application and has significant safety and economic benefits. This approach does, however, demand more management, competency, planning, and technical judgment during all stages of realisation, from initial hazard and risk assessment through to operation, maintenance, and modification.

2.6 Outline compliance to IEC 61511 Management of SIS operations and maintenance should be in accordance with recognized standards such as IEC 61511. To fulfill the requirements a baseline of requirements for the management of the SIS activates should include: 1. Ensure that installed equipment is suited for its current service and is in a safe condition to operate. 2. Confirm that new equipment has been designed, constructed, installed, and tested according to good engineering practices and that documentation to this effect is available. 3. Ensure compliance with national statutory regulations applicable to design, inspection, testing, certification, operation, and modification of SIS equipment. 4. Have an organisation in place with responsibilities allocated for ensuring that the integrity of the facility is maintained in accordance with relevant statutory regulations. These activities are chronological in nature and due to this are often represented in a series lifecycle model. A lifecycle can be thought of as a ‘framework’ arrangement where by the activities are structured and segregated into distinct phases. The advantage of this from a safety engineering view is that all activities relating to the safety elements can be planned and completed in a methodical way. The results of each phase can be tested or verified before the next phases are started. This introduces breakpoints into the process that will allow the compliance to the requirements to be verified and confirmed. The activities become the phases of the lifecycle with each phase having inputs and outputs. This infers that there is an interface between each phase and so some form of data or information must pass from one phase to the other. This defines that the life cycle can be considered as an information model. The success of the activities completed during the lifecycle depends upon the accurate and timely delivery of data via these information flows. The safety system information model developed as part of this project will not be represented in a chronological order. During the operational phases of a system other activities are also completed. These being maintenance, modification, testing and auditing. All of the activities associated with the operation of a system can occur at any time. Therefore, these activities are not restricted to a series arrangement. A continuous form of model where the start point can be any activity would more accurately represent the safety system activities that are implemented in practice. By connecting each activity with the relevant information flows, it can be assured that by following each flow to and from the activity that all the other activities required to complete the task will be completed.

of 94

The information model with provide a roadmap of activities that must be completed. In the series lifecycle this is achieved by starting at the early phases and following through a single pre-determined series of activities until completion. It is felt that the continuous model will provide increased efficiency as in some situations not all of the activities would have to be exercised.

2.7 Legislative framework for accurate information systems The importance of coordinating activities and of communicating information is well defined and understood by the engineering community. There are number of legislative requirements and code of practices that mandate the requirement for integration and communication. The basis of safe work in the UK is the Health and Safety at work Act 1974. It is important to state the intention of this act as it has a number of requirements that are applicable to the aims of this project. A concise definition is given in the HSE’s publication “Out of Control” “This act places duties on employers and others to secure the health, safety and welfare of persons at work, and to protect the public from the risks arising from work activities. Specific responsibilities are placed on employers, the self-employed and employees. The Act also places duties on designers, manufacturers, importers and suppliers to ensure that the equipment for use at work is designed and manufactured so as to be, so far as is reasonably practicable, safe and without risk to health when used cleaned and maintained etc” [10] Under the European Commission, a number of directives relating to safety and health have been introduced. Regulations have been introduced into the UK to put into operation these EC directives ‘The Management of Health and Safety at work Regulations 1992’ is one regulation. Within this regulation there is set out the obligations of workers to co-ordinate activities. Co ordination must involve the communication of information that can be aided by the adoption of an information model. All professional engineers should belong to the Engineering Council. This organisation sets out to establish the codes of practice under which professional engineers should conduct their activities. The Engineering Council establishes the code of conduct under which engineers manage risk. The railway’s industry publication commonly known as the ‘Yellow Book’ [12] lists four obligations from the Engineering council’s code of practice document that detail the need for communication and transfer of information. These are:

1. Communicate effectively with colleagues, both up and down the chain of responsibility, to help ensure that the risk management activities are sufficiently comprehensive and understood.

2. Endeavour to raise the awareness of potential hazards and risk issues among your colleagues.

3. Seek to ensure that all those involved with a project are aware of any risks to which they may be exposed, of any relevant limitations inherent in the design or operating procedures, and of any implications for their conduct

4. Discuss the reasons for incidents and near misses with your colleagues, so that lessons can be learnt.

of 94

It is clear that one aspect of safety engineering that is critical to satisfactory results is the timely sharing of accurate information. Hourtermanns referred to the process industries but his statement is true in many industry sectors when referring to safety information “safety information needs to be available throughout the life of a manufacturing process. Safety decisions need not only be made during design but also during operation, maintenance, repair and other phases (the lifecycle approach). There is a need to be able to design a safe process upfront and to maintain safety through the remaining lifecycle phases;” [13]. This sentiment instills the importance of safety related information and communication. The ineffective use and communication of safety related information will have impacts upon safety risk and system safety. The communication between the life cycle phases can extend across a number of organisations. It is common for a project to be such a scale that a single organisation does not have the resources, skills or tools to complete all activities. This fact is recognised in the Railway’s Yellow book “safety issues do not respect organisational boundaries. Effective communication and co-ordination are often needed to resolve them” [12]. The information model should be able to manage the information flows within and between organisations. The potential change impacts across organisational boundaries would provide great benefit. To maintain the integrity of communication and information the effects of any change in that information must also be communicated. The change control aspect of information transfer will be reviewed and covered later.

2.8 Information control Another important aspect of information transfer is that the method of communication must be auditable, which relies heavily on some form of change control. This auditability should be at an appropriate level compared to the criticality being assigned to the activities of the lifecycle phase. This criticality is determined by the potential hazard consequences and probability of occurrence. If the source and so the creditability of data cannot be established then the system safety activities could not be relied upon. Any revisiting of the design process due to an operational incident will highlight any deficiencies in data. To alleviate this risk a rigorous and robust information system should be established. The development of such a system has a cost associated with it but this is recognised and justified by Leveson “ although setting up a comprehensive and usable information system can be time consuming and costly, such a system is crucial to the success of safety efforts, and resources invested in it will be well spent” [4]. Leveson goes further and states Kjellan’s observation that “an effective safety information system ranked second only to top management concern about safety in discriminating between safe and unsafe companies …” [4]

of 94

Storey and Faulkner have studied the role of data in safety related systems. They have stated the main reasons for data errors. These are:

• Data is often not subjected to any systematic hazard or risk analysis. • Data is often poorly structured, making errors more likely to be

produced and harder to detect. • Data is often not subjected to any form of verification.

[14] It is important to reiterate that the data to which Storey and Faulkner refer is the data being processed by the safety system. This project sets out to use the methods used to address the integrity of safety related data processed by software and the information required to maintain and operate a safety system.

2.9 Information used during operation & maintenance In the operational phase of any system a subset of complete lifecycle activities must be completed. A safety management system is used based upon the requirements in the safety care. An uncontrolled deviation from this condition could then invalidate any assumptions or analysis completed in the earlier design phases of the system. These activities are common to many industry sectors. The list below is a summary relevant to the process industries:

1. Maintenance 2. Testing 3. Failure reporting 4. Modification 5. Audit and verification 6. Regulator inspection and approval / action for improvement

Operational and maintenance activities must provide the requirements of: people, practices, procedures and levels of competence, that are essential to meet the intent of the safety management plans. They must also operate within any boundaries determined during the design and development processes. All systems must be tested, inspected, maintained and operated so that they achieve their required performance, primarily safety but also environmental and financial constraints. An organisation must have demonstrable evidence that these activities are being implemented correctly. A definition of safety management is given by Houtermans: “The underlying attribute of the safety management function is a thorough and integrated understanding of the process. In practice safety management will deal with having the right people, with the right knowledge using the right tools for the organizations situation” [13] What is missing from this definition is the fact the right tools must be integrated correctly to ensure a cost effective safety process. Different initiatives / work methods are employed to achieve a result. All activities rely on various processes to be executed to allow the result or output to be produced.

of 94

Interestingly the requirement for the right tools is introduced here. A review of the safety initiatives in the process industry has highlighted the number of commercially available tools available. It would seem that the trigger for these tools was the publication of IEC 61508. It was recognized by a number of users and manufacturers that there were opportunities to develop tools which would simplify compliance to the requirements of IEC 61508. There were gaps in the techniques used within the process industries, i.e. loop PFD assessments, analytical proof test frequency determination techniques and integrity level assessments / documentation to name a few. Various initiatives have been developed to address certain areas of safety engineering activities within the process industries. A review of these initiatives has shown them to be disparate. Therefore, an information model would allow these initiatives to be integrated.

2.10 Work Flow Lifecycles The concept of a design lifecycle is not a characteristic of the system safety engineering discipline alone. The adoption of a lifecycle demonstrates that there is a clear and defined route that the design process or organisation will follow. This has a number of advantages in that there should be no stages omitted from the development process. Procedures should be simplified as the flow of the lifecycle determines the order in which activities must be completed. Other standards follow a similar lifecycle concept. The quality principle and standards utilise a lifecycle approach to demonstrate the process for transfer from one activity to another. The established quality standard ISO9000 has a number of lifecycles to set out the processes for different applications. The lifecycle can be regarded as a series of stages linked by information transfers. The lifecycle actually represents the route from one activity to another in a consistent and rational approach. The lifecycle features in many published system safety standards. A few of these standards based upon the lifecycle approach are:

1. International Electrotechnical commission (IEC) 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems

2. IEC 61511 Functional safety – Safety instrumented systems for the process industry sector

3. IEC 62061 Safety of machinery Functional safety of safety-related electrical, electronic and programmable electronic control systems-First Edition (lifecycle is split into two. The front end cycle is referred as “Workflow of SIL assignment process” [15] and the reminder is referred to as “Workflow of the SRECS design and development process”[15]

4. IEC 61513 Nuclear power plants — Instrumentation and control for systems important to safety — General requirements for systems (System safety life cycle)

5. EN 50126 The specification and demonstration of reliability, availability, maintainability and safety for railway applications – Part 0 dependability

6. ISA S84.01 Application of Safety Instrumented Systems for the Process Industries.

of 94

It has been shown in a number of studies that by applying a safety lifecycle approach a reduction in costs relative to previous uncoordinated work patterns can be achieved. This is stated by Scharpf “the safety process of ‘plan, do and review’ significantly reduces wasteful over-design of safety system, as well as limiting unsafe under-design by a very efficient process” [16]

2.11 Lifecycles, Data and the Design Process The development of a safety system can be compared to the development of any product. The objective of a perfect design process is to achieve the final design right first time. Getting the design right first time with no iteration is the economic solution. This calls for many factors to be accomplished but most importantly the availability of fault free data at the time when it is required is essential. This is not the case in many applications. The development of safety systems work is frequently started on preliminary information or the best information available at that time. This necessitates the need for feedback to revisit a phase of the development process to ensure that the latest or more accurate data is used and that the system will confirm to its original specification. This feedback necessity then suggests that the design will not be right first time. The system development must be an iterative process. This concept has been described as a ‘fuzzy’ stage of development. Lopez clarifies this early design process based on preliminary information as “a phase with a high degree of uncertainty in which decision must be taken based to a certain extent on assumptions or the expectations of experts” [17] The need for feedback is also critical to learn lessons from any incidents that have occurred during the operational phases of any other systems. Leveson sets out the case for information feedback “a crucial aspect of any management system is the feedback of information on which to base future decisions. Information can be used to describe, to diagnose, to compare, to evaluate and to improve. For example, a safety information system can provide the information necessary:

1. to detect trends and deviations that presage an accident 2. to evaluate the effectiveness of safety controls and standards 3. to compare models and risk assessments with actual behaviour 4. to identify and control hazards 5. to improve designs and standards. [4]

These aspects all relate to the improvement of the system safety performance. Another advantage of information feedback is to improve efficiencies and cost effectiveness. Learning lessons would reduce wasted effort, provide improvement in safety performance, and so avoid possibly very large financial burdens. Within the UK cost of accidents have been estimated at a figure of 10 – 15 £billon, 1.75% - 2.75% of UK’s GDP. [18]

of 94

Information feedback can create a problem with communication and information flow. The operator of a plant would most probability not be the organisation that had designed and built the facility. As most incidents will occur after commissioning then there should be a feedback mechanism from the user / operators to the designers and the manufacturers of equipment. Alternatively, the designers and/or the builders of a process facility may not want to know about incidents, as these will identify possible omissions in design. This attitude then breaks the feedback loop and the benefit from learning lessons. As well as defining what information will be required and the format of the data that will flow through the system safety information model the party responsible for providing the data must be identified. This then raises the issues of resourcing and competence. For this project, the competence of those completing an activity will be assumed sufficient whilst developing the integrated information model. A lack of competence will be considered during the information model failure analysis, as it is felt that a lack of competence will form a potential source of data errors. As suggested earlier the required level of accuracy of data may not be available at the correct time. As data becomes more dependable and credible then certain lifecycle phases must be revisited to ensure the design is based upon best available information. If estimated data is used then a method to ensure that the lifecycle phase based upon incomplete data is revisited. This fact must be made very clear to the personnel working on the project. The rework / feedback required to improve data integrity must be written into any design contract. If not then the rework may occur or could be viewed by a contractor as an extra and outside of the original contract. This omission will comprise system safety. The lifecycle can be compared to the design process for a product. The methods to be used in the design process or lifecycle phases should be defined. This is identified by Lopez-Mesa and Grante “In order for the design processes to provide support in engineering practice, it is useful to specify the possible design methods that can be used in the different phases. It is also helpful for academia and industry as a way to detect possible gaps in design methodology, and to gain understanding about the information flow that can exist between methods” [19]. It is intended that the information model will allow specification of the design methods or in the context of this project the safety activities. By identifying the inputs to, the required outputs from and the function of each activity then a specification of each individual component within the model can be developed. The model could also be used to identify any gaps in the safety system processes available to the target industry sector. As mentioned in the introduction the safety standards have linkage to legislation even if the standard itself is not mandatory. It can be concluded that the inclusion of lifecycles in the range of safety standards demonstrates that the concept of the lifecycle process to control the work activities in achieving an adequately safe system is acceptable. What is not obvious is that the structures of the presented lifecycles in the standards are correct or optimised. The standards IEC 61508 and 61511 do permit an alternative lifecycle structure if the requirements of the standards can be show to be achieved.

of 94

IEC 61511 recognizes the fact that the suggested lifecycle can be modified or restructured in alternative forms. A reason for this is given in the standard “this restructuring can be beneficial if it allows safety activities to be better integrated into the normal project procedures [20]. Other reasons for an alternative format of lifecycle are be due to the following:

1. The organisational structure of the organisation i.e. different companies could be responsible for different activities, locations of the activities could vary and be spread across a number of countries

2. The experience profile of the organisation, the personnel could have an extensive knowledge using a suitable but different workflow or project activity plan that does not necessarily fit the published lifecycle structures.

An essential element of an alternative or restructured life cycle or safety system information model is that all the requirements of the standard are satisfied and a safe system is designed, built and operated to an adequately safe level. A well-documented method for ensuring compliance is to ensure that the data passed from one lifecycle activity to another is correctly specified to ensure the safety requirements flow from the early stages to the final stage. The standard IEC 61511 has included clause 6 to ensure if a different lifecycle approach to that set out in the standard is adopted then inputs and outputs of each lifecycle phase are clearly defined and that these data or information flows contain all the essential attributes required to deliver a safe system. Table 2 of IEC 61511 part 1 lists the input and outputs of each lifecycle phase. It also states that in section 6.2.2 “each phase of the safety life cycle shall be defined in terms of its inputs, outputs and verification activities” [21]. Again information flows into and out of the activities are essential for achieving the aims of the standard. The definition, control and change impact of these flows within a safety related information model will minimise risks to system safety. The model developed here will allow these actions to be completed.

2.12 Adoption of the lifecycle principle in the process industry From discussion and research two aspects concerning lifecycles have became known when IEC 61508 (or 61511) was being developed and published. The first was of an acceptance of the lifecycle approach as the most efficient and structured methods to manage and direct activities associated with safety system development. The second was how a lifecycle approach could be integrated into the company’s normal work patterns. The second observation is obviously coupled with the concern ‘How much is this new approach going to cost?’. Over the past few years, there has been an acceptance of the lifecycle process and users are now beginning to see that lifecycles and adoption of IEC 61508 / 61511 are actually providing cost savings. A formalised system of work, although at first seems cumbersome and expensive, will offer cost savings. These are mainly due to installing and maintaining a design that is fit for purpose.

of 94

If the hazard is assessed as SIL 1 then the safety system design and maintenance simply have to comply with SIL 1 requirements. One company’s approach pre IEC 61508 was to classify any hazards that could result in harm or injury to an individual as Class 1. It then followed that all Class 1 SIFs must conform to company guidelines. In this case, the guideline stipulated field architecture must be 1oo2 or 2oo3 and tested every 12 months. By adoption of the IEC standards, it can be shown that a 1oo1 systems being proof tested less than once per year will conform to the requirements of SIL 1. The cost saving between different SIF integrity levels for the installation and operational phases have been reviewed elsewhere. This cost model could be used to build a financial case for improving system architecture to extend proof test intervals. The cost model could be included in the integrated model. This will allow assessment of the cost penalty of data errors which result in excessive risk reduction facilities being implemented, i.e. building a 1oo2 voting architecture as opposed to a 1oo1 voting SIF architecture.

2.13 Data and information models The ISO standard 10303-1:1994 contains two definitions that will be used to define what is meant by data and information models within this project. These definitions are: Data a representation of information in a formal manner suitable for communication, interpretation, or processing by human beings or computers. [22] Information model a formal model of a bounded set of facts, concepts or instructions to meet a specified requirement [22] As mentioned in section 2.1 it is the data processed by human beings that will be considered in this project. As the IEC standards 61508/11 specially refers to the inputs and outputs then this suggests that there must be information flows between the activities of the safety lifecycle. The verification activities are included to check that the correct output from a phase is delivered. The information flows between the activities that have a large affect on the results of the work processes. It is the information flows that are verified to ensure the standard is complied. This infers that it is the information flows that are most critical in achieving system safety.

2.14 Data correctness and validity There are a number of definitions that attempt to identify the factors that govern data quality or integrity. Data definition work that has been carried out under the STEP umbrella by the European Process Industries Step technical Liaison Executive (EPISLE). This organization has been involved with the development of a number of data models and has recognized the need to establish good practice in the development of data models. It is fortunate that this work has been concerned with the process industry sector.

of 94

One area of their work has been to develop guidelines on how to produce high quality data models. These guidelines have been published in the document “Developing high quality data models” [23]. A purpose of EPISLE’s work has been to standardize information exchange for the design, construction, operation and maintenance of process plant. A standard form of information transfer would be a requirement of any information model. The diagram below is taken from [23] and plainly shows the important properties of data and also the relationship or classification of these attributes between data definition and data values.

[23]

Figure 3 Data values and definitions

Below is a list of data properties for which requirements need to be met are: definition related properties

relevance: the usefulness of the data in the context of your business. clarity: the availability of a clear and shared definition for the data. consistency: the compatibility of the same type of data from different

sources. content related properties

timeliness: the availability of data at the time required and how up to date that data is.

accuracy: how close to the truth the data is. finally related to both are:

completeness: how much of the required data is available. accessibility: where, how, and to whom the data is available or not available

(e.g. security). cost: the cost incurred in obtaining the data, and making it available

for use.

of 94

Other published lists of data properties portray a similar pattern: DO200A list the following as elements of data quality: 1. The accuracy of the data 2. The resolution of the data 3. The confidence that the data is not corrupted while stored or in transit (assurance level) 4. The ability to determine the origin of the data (traceability) 5. The level of confidence that the data is applicable to the period of (its) intended use (timeliness) 6. All of the data needed to support the function is provided (completeness) 7. The format of the data meets the user’s requirements. List from [24] The validity of data is essential in the safety engineering context. There have been a number of papers covering the analysis of data within safety critical systems [14,24,26]. A number of these papers suggest that data is such an important element that it should be considered as a critical entity along with hardware and software elements of a system. Storey and Faulkner set out this principle “Unfortunately, the various standards and guidelines that relate to the production of critical systems are concerned almost exclusively with methods of ensuring the ‘safety’ of the hardware and the executable portions of the software of a system, and say almost nothing about the nature, production or testing of the data “ [26]. As systems become almost exclusively computer based the quantity of data demanded by the design, operation and maintenance has grown enormously. The introduction of programmable based safety systems has triggered a requirement of data demands that are still evolving. In the process industry the scale and complexity of protection systems has grown considerably over the last 10 years. There are numerous techniques that have been developed to establish the hazard and risk potential of traditional system components of hardware and software. Similar techniques for the review of data or information used by the traditional safety system components are being developed. The results of these analysis methods provide an indication or measure of data integrity. Failing to achieve the level of data integrity must signify a failure of the data and the requirement for some form of corrective action. Data integrity can be determined by the format of the information, the accuracy of the information and the control of the information. The ultimate aim must be the provision of information that is of comparable quality or integrity to that of the application in which it is being used. Not achieving the required level of integrity can have negative consequences, too low and safety would be compromised, too high then excessive resources and costs are consumed during the mid and latter lifecycle processes of a safety system. The importance of correct data use and methods is stated by Scharfe and Goble “The process industry is faced with a clear need for rigorous, documented safety analysis based on solid techniques and solid data” [25]. This statement is made while referring to the process industry but their observation is valid for any engineering activity whether that activity is safety related or not.

of 94

A recommendation from Storey and Faulkner is that “data should be described by an appropriate data model that is self-sufficient, clear, analysable and unambiguous” [14] An essential element to safety engineering is the identification of suitable methods and techniques that can be utilised in each lifecycle phase. This element of the planning process has, by the author’s experience, been omitted and only addressed as the particular lifecycle phase has commenced. The information model will identify the components that must be addressed during modification, maintenance or auditing activities. This identification will allow the quantification of the work required so allowing adequate resource to be sourced. This resource allocation can be taken into account competencies to ensure that the risk to system safety is minimised. The identification of activities is undertaken in chapter 3.2.

2.15 Data /Information flow The IEC 61508 standard does not stipulate how information and data should be communicated during the system safety lifecycle process. The inputs and outputs for each lifecycle phase are listed in the standard. So it is left to the user of the standard to devise the methods, format and controls of any data transfer between the stages of the lifecycle. This data transfer between lifecycle phases can be compared with data transfers or interfaces within software. Leveson states “software has no physical connections, and logical connections are cheap and easy to introduce. Without physical constraints, complex interfaces are as easy to construct as simple ones, perhaps easier” [4]. This analogy has been made so that when the integrated model is being developed the information flows or interfaces should be kept as simple as possible. There maybe a tendency to introduce over complex formats of data exchange which they could introduce failure or fault mechanisms. Over complexity will also increase costs unnecessarily. Story and Faulker summarise this necessary as “Data should be structured to facilitate verification, and to permit fault removal and fault detection techniques to be used” [14]. When considering data or information used to design, operate or maintain a system then other factors should be introduced into the data structure. Storey and Faulker suggest that “any data that is relevant to the operation of a safety critical system should be considered as part of the overall system and developed accordingly” [14]. This must include engineering design data that will be used in the integrated information model. The conclusions of this research work will be reviewed in detail later but can be summarized the paper by Storey and Faulkner entitled “Data the forgotten system component “ [27]. In this paper, and others by the same authors, the principle states that safety standards concentrate on the software and hardware aspects but do not necessarily include data integrity in the requirements. Of course if the system is assured to be of a high integrity then the use of low integrity information will compromise the system’s performance and present a safety risk. Observations and conclusions from this work will be used later.

of 94

2.16 Cost of data There must be a balance between the cost of data and the integrity of that data. Not all data can be sourced, analysed or verified uniformly. A distinction has to be made as to where a finite resource can be utilized to maximise effect and efficiency. This balance is set up in most standards where the level of review and analysis is matched to the level of hazard that is related to the data. As an example throughout IEC 61508 the level of rigour applied to the safety process is greater for the higher integrity levels. The higher the level of rigor the more detailed and higher the required accuracy of information obtained, i.e. data of greater integrity. The safety of an overall system must depend upon the integrity of the information used to produce, operate and maintain that system. It would be beneficial if the developed integrated model could provide some guidance as to which safety activities should have relatively more attention and those that should demand less intense effort. It is felt that once the developed model has been subjected to a failure analysis then the result of this analysis will allow the apportionment of effort to be realised.

2.17 Collection of data Data must always be collected and mechanisms put in place to ensure data is gathered correctly. The use and interpretation of data must also be correct. Leveson highlights the need to understand any information that is collected “No matter how the information is collected, understanding its limitations and inaccuracies is important. Simply collecting information is not enough – the information must be accurate and timely and it must be disseminated to the appropriate people is a useful form. [4]. There are three other aspects relating to information apart from accuracy in a previous statement from Leveson. These are timely availability and dissemination to the appropriate people/team/organisation and the information must be in a suitable form. These aspects will have to be considered when the integration model is developed. The failure to achieve any will be reviewed and the impact of failure assessed. This will then provide evidence as to the robustness of the model to information flow failures and how these failures could present a risk to system safety.

2.18 Process industry data To allow the development of an integrated model it is worth identifying what type of data or information is used in the process industry. As stated previously the data or information that will be used to integrate the activities or components within the information model is engineering design data. Traditionally, engineering information is divided into two basic types: 1. Documents, which typically include drawings, specifications, manuals and general reports 2. Data, which comprise values, held in a structured format, often in spreadsheets or databases

of 94

Data can also be classified as either static or dynamic. Dynamic information must be alerted and updated to reflect the current state of the plant or process. There will be a number of legal requirements that stipulate that the dynamic information is maintained. For the process industry this is as mandated in the UK by the COMAH regulations as detailed in chapter 2. Dynamic data must be subjected to management of control procedures to ensure that the most up to date version is available to the user’s organisation or regulator as required. The safety value of dynamic information is how accurately it represents the actual system, out of date information when related to safety can have an extremely invalidating effect upon the safety case. Static Information on the other hand is never updated during the life of the system. The information is used at a certain phase during the lifecycle and remains valid for the remainder of the lifecycle. Dynamic information requires more formal information management than static information and generally has a greater frequency of access, hence it should have a more sophisticated information form [28]. From the above definition it can be seen that the majority of information designated as safety related data will be dynamic information and hence the information flows within the integrated model will be prone to the potential errors of dynamic information. Within the process industry there are a large number of types of information. The scope of process engineering information is wide and to list all types used is not required here. The list below gives the types of documents that are used in the process industry that have a safety or technical integrity relationship. It is acknowledged that this is not exhaustive. It is assumed that the list is sufficient for the purpose of the project and that process instrumentation and fire & gas (F&G) devices are both included as instrumentation.

1) Process Flow Diagrams (PFDs) 2) Process and Instrument Diagrams (P&ID’s) 3) Loop Diagrams 4) Single Line Diagrams (SLDs) 5) Cause and effect diagrams 6) General Arrangements, plot plans for plant and buildings 7) Isometrics 8) Equipment Specifications 9) Equipment operating manuals 10) Installation, testing and commissioning procedures 11) Study reports, including safety cases, philosophies, etc. 12) Design calculations 13) Operating procedures 14) Maintenance procedures 15) Process data (i.e. design conditions typically shown on a process data

sheet) 16) Equipment data (i.e. data typically shown on mechanical and instrument

data sheets) 17) Lists (i.e. typically of process equipment data) 18) List of safety related devices 19) Manpower resource levels and competencies

of 94

20) Quality plan 21) Equipment criticality ratings 22) Health and safety program 23) Hazop review and report 24) Critical instrument list, specifications and calculations 25) FMEA, equipment failure information 26) Hazardous area classification 27) Design change control procedures and records 28) Design deviation report

These types can be classified into document kinds. A document kind is defined as “the type of document defined with respect to its specified content of information and form of presentation” [29]. The standard IEC 61508 Part 1lists the document kinds that are used within appendix A ‘Example documentation structure’ of the standard. The complete list from this appendix is given below: Specification - specifies a required function, performance or activity (for example requirements specification); Description - specifies a planned or actual function, design, performance or activity (for example function description); Instruction - specifies in detail the instructions as to when and how to perform certain jobs (for example operator instruction); Plan - specifies the plan as to when, how and by whom specific activities shall be performed (for example maintenance plan); Diagram - specifies the function by means of a diagram (symbols and lines) representing signals between the symbols; List - provides information in a list form (for example code list, signal list); Log - provides information on events in a chronological log form; Report - describes the results of activities such as investigations, assessments, tests etc. (for example test report); Request - provides a description of requested actions that have to be approved and further specified (for example maintenance request). These basic document kinds can be modified by prefixing them with an additional descriptor, i.e. design, test or review could be added to specification to form documents such as design specification, test specification etc. The advantage of classifying the process industries related information into document kinds is that it would allow the most appropriate form of data transfer and change control to be determined, i.e. a specification could require a different form of change control compare to a plan. The document kinds will help to define the information flows within the integrated safety model. An attribute that should be added to each data type is the criticality of the data to the system safety performance. The criticality of data is defined as the extend to which the system safety risk is dependant upon the integrity of the data.

of 94

The consequences against which a SIS will provide risk reduction are defined as commercial, environmental or safety. In is report we will focus on safety performance as this will indirectly capture the sensitivity of the data to commercial and environmental consequences. The allocation of a criticality rating to each information flow will be carried out after the fault analysis. It is anticipated that this analysis will aid the establishment of data criticality ratings. Appendix A lists the information flows as idenitfied to form the integrated model and classifies them into the data kinds as defined in IEC 61508 Part 1 appendix A.

2.19 Alternative structure / non chronological An integrated model will allow entry into the system safety process at any point and so the methods or components of the model could be used at any time. The lifecycle activities, as presented in standards such as IEC 61508 & 61511 are chronological in nature and due to this are often represented in a series or one after another form. It gives the impression that the next stage cannot be started until the current stage is totally completed. The series lifecycle also suggests that there is a single route that can be followed, i.e. after phase x phase y must follow. It also suggests that each activity within a phase is stand-alone. There is a possibility that full advantage may not be realised from each method or tool available to the safety practitioners at each phase. This is highlighted by Lopez-Mesa and Grante “Most of the engineering design methods and almost all of the safety-related methods are developed and used as stand-alones. The results from methods used in earlier design phases are frequently forgotten and not used as inputs in later phases. Engineering practice is also characterized by the use of numerous methods in some design phases, but few, if any, in others” [19]. There are three issues raised in the above reference all of which as relevant to the development of a system safety information model. Firstly the observation that safety-related methods are used a stand-alones. This project will propose a model that will integrate safety initiatives available to the process industry. The second is that results from methods use in earlier phases are not always used at a later date. An integrated model should be able to lessen the impact of this issue by not relying on a chronological order of representation. The information flows from each initiative or activity will be clearly apparent. These information flows could interface with a number of activities. The appropriate section of work processes can be followed to achieve the task required. The third is that the early design phases utilise numerous methods and processes but the later phases are not always adequately supported by tools and methods. This information model will allow any gaps in the available tools to be identified and will and suggest the format of the tools required to fill the gaps. Using information throughout the lifecycle phases is also captured by Houtermans “Safety information needs to be available throughout the life of a manufacturing process. Safety decisions need not only be made during design but also during operation, maintenance, repair and other phases (the lifecycle approach). There is a need to be able to design a safe process upfront and to maintain safety through the remaining lifecycle phases”. [13]

of 94

2.20 Information Models and model representation The information modeling is a relatively new concept. Around ten years ago very few companies utilized information to its best advantage. Information modelling was not a widely understood concept as companies would either printout or scan documentation without regard to how these pieces of information should interact with each other. Today most companies realize the value of efficiency operated information systems. An effective and comprehensive information model is critical to most of today’s business activities. The benefits of information modeling are beginning to be realised in the system safety engineering field. An information management system that will provide benefits to a company must be built upon a workable information model. This is true of a business information system or an engineering information system. An information model can also provide benefits for information exchange if the information must be shared within a large organization or shared between different organizations. Information associated with process plants is often highly fragmented. As each activity usually requires a different discipline then the information is distributed over a number of departments. To facilitate safe and efficient operation of a process unit these departments will for example be: engineering, operations, safety, maintenance and commercial. Each department will require to control, manage and maintain the information that is required to carry out its function. There can be a danger through this data fragmentation that information is not disseminated efficiently. A risk to system safety could result if the data became invalid through lack of robust management of change procedures. A representation of how a data model can provide the basis for and deliver benefit for business processes is given in [23]. This diagram is shown below:

Figure 4 How data models deliver benefit

This diagram clearly identifies the principle that a data models can deliver benefits to the whole organisation. If the business related references are changed to system safety then the benefit of information models to system safety become clearly apparent.

of 94

Figure 5 How data models deliver system safety

The data or information model must have a number of properties to ensure that the model is used and that the model will be beneficial. The model must:

1. Not be over complex and so difficult to use. 2. Be clear and unambiguous. 3. Allow changes to occur in a controlled manner. 4. Be flexible so that it can itself adapt to changing business process and regulatory demands.

Leveson recognizes important of information flow and states that “Communication paths and information need to be explicitly defined” [4]. Leveson also recognizes that in large projects the information flow can be nonexistent or limited. The reason for this is given that the development organization is often totally divorced from the safety organization [4]. The integrated model will allow the information flows between organisations to be identified and so the organisations should not be divorced. The HSE have discovered that for incident investigation then the supply chain and information sharing is impeded by industry fragmentation [30]. Another example of information transfer breakdown was stated in the official report on the Kings cross fire. It stated “Little exchange of information or ideas between departments and still less cross fertilization with the other industries and outside organizations” [4]. These examples highlight safety related issues with information and should be addressed and solved by the adoption of an integrated information system. Information exchange and so modelling is also applicable to the transfer of information between engineering activities. Support tools and techniques are extensively being used to carry out engineered activities including the safety engineering domain. The development of engineering support tools and the exchange of information have the opportunity to become more efficient. This is emphasized by a paper on the future of systems engineering data exchange “Data exchange is an essential stepping stone to achieving a grander vision of any systems engineering environment formed from an interoperable set of heterogeneous commercially available design tools” [31]. This statement is in line with the objective of this project.

of 94

One definition of an information model is a framework for organizing content but also the transfer of this content between stakeholders. The framework of an information model should also allow it be reused in a number of applications. The analysis of information will allow control of the information between each activity and stakeholder. To ensure success of information transfer and control, rules must be set up on how the form of the information should be presented. Also if the information model is to be generic with possible uses across industry sectors then the context in which the information model is to used must be established. This work will concentrate on a process industry sector related model. An information model should be modular in its construction. This will allow the model to adapt to different applications by either being extended to cover new activities or to contract and become fit for purpose. Also modularity of the model will allow the model to become more detailed and focused as required. There has been large volume of work to define the format of information exchange in the engineering field. Work on the standardisation of information exchange and integration has been ongoing for a number of years. In design and production sectors of industry development of standards for information exchange have taken place under an initiative called ‘STEP’ (STandard for Exchange of Product model data). The result of this work has resulted in the publication of an ISO standard ISO 10303 “industrial automation systems at integration, data representation and exchange”. This standard sets out guidelines by which the exchange of product information during manufacture can be standardized. The advantages of a standard form for information exchange are:

1. Improved quality of information exchange 2. Standardisation allows globalization of exchange 3. Products are becoming more and more complex so requiring more complex

data to manufacture them 4. Major products such as ships and aircraft have a life expectancy of decades

and so product data must be retrievable for this duration. [32]

These advantages are valid for all sectors of industry where engineering activities must be integrated to achieve the ultimate goal. A derivative of the STEP initiative has been developed for the Process Industries called PISTEP (Process Industries STandard for Exchange of Product model data). The drivers for this work were to design and build chemical plants in less time and at a lower cost, reduce downtime for maintenance and improve safety, environment and quality performances. There has been a large amount of work to define a standard for information exchange within the process industries. This work has been international although segregated through different countries efforts. Under this initiative a number of information models have been created.

of 94

2.21 Developed information models

One of these information models is called the Process Plant Engineering Activity Model (PPEAM). This model, modified by the Norwegian oil industry association, is shown in the figure below. The figure is taken from [33]

Figure 6 Process Plant Engineering Activity Model

This model focuses on the process plants asset life-cycle including technical information. It starts from the initial design of concept of the plant and follows activities through to decommissioning. The process plant engineering activities model is limited to showing information flow only. For this reason, the model is a high-level view in the context of this project. The model does give a good indication of the quantity of information that must flow during the lifecycle of a typical process. One issue is that the model does not show how changes to the process plants after commissioning are achieved and controlled. An important omission of this model is that it does not indicate the requirement or involvement with regulatory bodies.

of 94

The information model being developed as part of this project must include the omission identified in the PPEAM, i.e. how modifications are completed post commissioning and regulator involvement. An update of this process plant engineering activity model developed by an international group of senior executives from the process industries is called the PIEBASE (Process industry Executive for achieving Business Advantage using standards for data Exchange). The objective of this model is to “deliver a roadmap that identifies the data exchange standards required for the process industries” [34]. The PIEBASE model will provide a common understanding of the process required and information requirements of all engineering activities within the processes industries. Developed for the process industries this model can be applied to engineering activities in other industry sectors. As the PIEBASE model has been developed by executives it takes a wider view that not only concentrates on engineering activities. The model can be applied to business activities also. The PIEBASE model can be used or presented in two ways:

1. A simple outline of the activities to help plan and report progress during project delivery but also to increase awareness of the work.

2. A formal representation where focus is placed on the correctness and completeness of technical detail of work and detailed planning.

It is the second method of representation that will be considered for use in this project. The model uses a template approach for all activities. This template consists of three steps: 1. Manage, 2. Do, 3. Provide resources. This template is shown in the diagram below.

Figure 7 PIEBASE model for technical work

of 94

The two main advantages of this model are that it does not only consider the engineering activity alone. Within the model there is recognized a need to manage the activity. This management can be considered as quality control but also change control or change impact analysis. The other benefit of this model is that it considers resources. Not only have sufficient resources to be available to achieve the activity but this resource must be deemed competent to complete the activity. The attributes of the above model that have been identified reflect the factors that govern current systems safety engineering. These should be included in the model belong developed although their inclusion may be internal to the individual model activities. There is also a model that unites safety related activities that has been developed by Knegtering in [35]. This model has been developed through industry surveys, review of IEC 61508 part 1 and review of management theory. The Safety related Activity Model (SAM) is shown below:

Figure 8 The Safety related Activity Model (SAM)

The inputs and outputs required to achieve the activity safely are described below: – Objective(s): What is the purpose of the safety-related activity? – Output information: What are the needed results, outcome or information? – Competence of persons: Requirements concerning the competencies of the involved persons. – Tools & Methods: Tools, methods, techniques, equipment and other aids. – Input information: Required input information and documentation. – Requirements: Limiting conditions, e.g. procedures and work instructions. – Documentation: Any required information that needs to be documented.

[35] Although this model is intended for the process industries it is felt that the number of inputs and outputs to and from the activity could over complicate the safety systems integration model being developed as part this project. As an example it is felt that the requirements or standards under which the activity is being carried out do not necessarily have to input into the activity separately.

of 94

At the beginning of a project the standards to which the project is being built will be stated, therefore do not need to be in reiterated throughout the lifecycle. Also the objective of an activity should be clear once the actual activity has been allocated. i.e. preliminary hazard analysis will be the object of a HAZOP study (see chapter 4.2). This could also be the case of the input to the model of ‘tools and methods’, i.e. the tools used for a PHA would be the HazOp principle. To develop the integrated model a simplified approach will be used. This will consider each activity as a simple box for representation in the model. It may be deemed necessary when the model has been developed or during analysis that the model should be expanded to show functionality similar to those models shown above.

2.22 Methods, techniques and tools definitions To allow the development of a system safety information model based upon relevant tools and methods it is worth firstly defining what is meant by these terms. Firstly, we will set out the definition of a method, as a method will use a tool to achieve its objective. For the purpose of this report, the following definitions will be used. A dictionary definition of a tool is “a device or implement used to carry out a particular function or a thing used to help perform a job”. For this project, the definition for a tool will be “a device used to help perform a particular function. The definition of a method is not as clear as there has been numerous research activities associated with the development and use of methods for most activities. The definition to be used in the remainder of this report is defined by Hubka “Methods are systems of methodical rules that determine classes of possible procedures and actions that are likely to lead on a planned path to the accomplishment of a desired aim.” [36]. This definition is taken from the design engineering field and can be simulated directly to the workflow process required for following a safety life cycle. The concept of ‘methodical rules’ and ‘planned path’ have significant relevance. It must be emphasized that selection of the methods and techniques will not in itself provide any benefit to the safety development process. The achievement of satisfactory safety goals will depend upon the correct selection and the correct use of these tools. The correct use of tools will be determined by the correct integration of tools. In an integrated model the selected tools must work together and it is unlikely that a single tool will achieve all the requirements demanded of the standards. “There are no magic tools that will solve problems automatically” [13]. As well as correct integration of tools correct operation of the tools will also dependant upon:

1.Competence of individuals who will be using the tools 2.The levels of risks that must be reduced. The integrity of tools must match the

integrity of all the other aspects of safety engineering and risk management. 3.Other tools that the organization is utilizing. There will be benefits if the new

tools can be integrated with existing tool, i.e. some SIF evaluation tools can import information directly for the hazard analysis tools. This reduces the probability of error when assessing whether SIFs can comply with the requirements of the standards. There is a suite of tools available that will integrate the HazOp exercise, IL determination and SIF evaluation.

of 94

The availability of methods and techniques to complete an activity will influence how an organization achieves its objectives and could also determine the structure of work flow patterns. If tools are available off the shelf then these tools will be allocated to the engineers. It would be expected that the performance of these tools will be of an acceptable quality to as to achieve the objective of the task completely. If there are no tools available then companies will have two choices: 1. Produce in house techniques to accomplish the task

2. Engage an external consultant to provide the necessary techniques or even skills shortage.

The system safety information model could assist in the development of user requirements or a specification for new tools to fill any gaps in the system safety process. As owner / operator companies are starting to adopt the new standards that cover programmable systems these companies are developing their own internal procedures for compliance. There are also a number of commercial organisations offering various tools and techniques for addressing the requirements and to demonstrate compliance with the standards.

2.23 Activity integration The use of commercially available tool and techniques has significant benefits in terms of financial savings and consistency across the industry sector. If numerous and diverse organisations are exercising the same suite of tools then these tools will have a greater client experience base from which to enhance their tools. In addition, these tools can be designated as ‘proven in use. The available methods and techniques must be integrated as no one method or activity will achieve all aims of safety lifecycle process related to the chemicals industry or any other sector to which IEC 61508 is applicable. To maximise the effectiveness of operation and maintenance functions these various methods require some plan to allow integration. The integration then produces interfaces between each method or activity within the model across which information must be transferred.

The integrated information model could then be used to improve the efficiency of ensuring that an acceptable level of safety is assured for a safety system. Summers states that of the seven bad engineering practices in SIS design number seven is “Focusing on capital costs and not lifecycles costs” [1]. In a growing competitive environment then cost efficiency is a major factor when operating any process plant.

The artefact being developed as part of this project will be used as an information model and not strictly as a traditional lifecycle. This will be evident by the fact that the information model should have no start or end as defined in a traditional lifecycle, for example the IEC 61508 part 4 safety lifecycle. The model developed here will be a continuous process and entry into the model can be made at any point dependant upon what action is to be executed.

of 94

The integrated model should be able to utilize available or COTS initiatives. This will reduce costs by ensuring that the assurance of system safety during the operational lifecycle of is as efficient as possible. An operating organisation should not be in the position of developing ‘in house’ applications to ensure compliance to an international standard. It would be expected that there are sufficient organizations to provide the developed of tools that can be used to satisfy the various phases of the safety lifecycle

2.24 Control of the model This section outlines how the change control could be accomplished and the difficulties involved with implementing a change control method relevant to an information model. Change control theory has been well documented and researched over the last few decades. This is mainly due to the extensive use and development of software during this time. It is assumed that change control discussed in this section is relevant to the integrated information flow model being developed. The importance of control is highlighted by Knegtering & Rouvroye in their paper ‘How to use life-cycle models for process safety management’. They state “A review of recent studies on incidents and accidents shows problems regarding the quality of information and related technological solutions. Therefore adequate control of quality of safety related information seems to be of essential important if realization of an acceptable safety level is to be achieved” [36] The reasons for change can be divided into two categories: generic and application specific. Generic changes would affect all systems within the process industry sector while application specific would only affect a single plant or design of chemical process. There are a large variety of reasons for change that can be expected during the life of a process plant. These can be broken down into a number of categories:

1. Regulatory expectation (generic change) This could be due to an investigation into a previous incident and the standards and legislation may remain unchanged. The evidence required by the regulator may have to be more rigorous or equipment used in a safety context may have to be changed if initial data proves to be incorrect. This change can also be caused by a change of the regulator with differing expectations to the original regulator.

2. Legal provisions changes. (generic change) If legislation changes then current practices would have to change in line with the new legislation, e.g. the targets for tolerable risk may change. The question of whether retrospective compliance is required would have to be addressed and is usually not required by the regulator.

3. Modifications to the asset are being made by the facility owners. (application specific change) This is most likely the greatest cause of change. There are a number of reasons for plant modification:

a. Increase efficiency b. Reduce environmental impact

of 94

c. Equipment repalcement due to obsolesce d. Increased automation to reduce manpower e. Technological advancement f. Increase in the maintenance downtime to improve availability g. Change of process chemistry, alteration to feedstock, increasing the

operating envelope. 4. Existing safety systems do not provide adequate risk reduction (application

specific change) If a current legacy system cannot be relied upon to reduce the risks of the operation to tolerable levels then an improved safety system must be utilized.

A change control system should be able to manage all categories of change and provide an auditable trail for the reason of the change, how it was implemented and the update of any plant specific data repository throughout the safety system’s lifecycle. The features of a robust and effective change control system are:

1. Simplicity 2. Auditable / traceable 3. Adaptability 4. Allow closure

The categories of changes listed above for the process industry are diverse and are initiated by a variety of stakeholders. It then follows that the effect of each change will be different during the activities required to design, build, operate and maintain a facility. A change event could occur at any time or enter the lifecycle at different points. A mechanism to deal with change therefore has to be extremely robust and constantly available to react and minimise the change effects throughout the lifecycle. The impact upon the risk to system safety should also be assessed. In systems safety engineering the concept of control is often related to configuration management. This becomes more relevant with the development and extensive use of programmable safety systems in all sectors of industry. To establish the framework of model control part 4 of IEC 61508 will be used to extract certain salient definitions. “Configuration management: The discipline of identifying the components of an evolving system for the purposes of controlling changes to those components and maintaining continuity and traceability throughout the lifecycle” [11] The objectives of configuration management are clearly listed in the railway’s industry ‘yellow book’. The definition of configuration management presented implies that configuration management should:

1. Uniquely identify each version of each item 2. Record the history and status of each item 3. Record the parts of each item (if it has any) 4. Record the relationships between the items.

[12]

of 94

The control of an activity can be achieved by controlling the inputs to and outputs from that activity. If the output from an activity fails its verification then this is due to one or more of the following:

1. The inputs to the activity were not correct 2. The tools, methods or techniques used to complete the activity were not

selected correctly for the application. 3. The competence of the individual completing the task was insufficient.

This control will have the tendency to become more complex in the integrated model being developed as part of this project as a number of outputs from one entity could transfer to a number of other entities within the model. Technical integrity is at risk throughout the entire lifecycle of an asset and modifications can undermine the original design intent to such a degree that the technical integrity is compromised. The full detail of how to develop the most practical form of change control for this model will be left for further work and is so outside the scope of this project. Suggestions of how the control of changes could be achieved will be briefly discussed after the model has been subjected to the failure analysis. The facility to forecast the potential impact of a change would allow the assessment of potential risk to system safety.

2.25 Change impact analysis of information models It is reasonable to assume the change impact analysis within the integrated model can be compared with the change impact analysis used for software due to the analogy of continuous operation/execution and the multi pathed nature of both software and the integrated model. It is inevitable that changes will occur that will affect the model and so could potentially have a damaging effect to the system safety that is being assured by the use of the information model. A concept that is well defined for change management is the effect of change propagation [38]. As the integrated model will be continuous and multi-pathed system then changes will more readily propagate through this model compared to a traditional series lifecycle model. This is because the integrated model will have numerous information flows or paths for each activity. The change effects will have multiple impacts. A change affecting one activity will propagate to a number of other activities. If a change occurred in a series model then the immediate effect of the change would be experienced in a single activity immediately following the source of the change. In this case, there is a reasonable chance that the change would be identified and addressed before a group of activities could be affected.

of 94

The issue with change propagation is that this “type of change impact which is most difficult to predict and control” [38]. There are two types of change propagation that could occur within an information model: direct and indirect. Direct is the type of propagation expected within a series lifecycle model where the previous activity affects the next activity. Indirect propagation will be the most difficult to assess as this type of propagation depends upon the dependencies within the model. A change in one activity will not only affect the next activity but all activates into which the affected output information flows. The change propagation within an information model or system can have a number of different patterns. These patterns are described as avalanche, blossom and ripples. These are best shown in a form graphical form. The diagram below is taken from [39]

Figure 9 Change propagation patterns

Any changes that affect the integrated model would be expected to be classed as having a ripple effect. Two definitions of a ripple effect are: “The effect caused by making a small change to a system that affects many other parts of the system [40] “The phenomenon in which a change in one part of the software causes a change in another part of the software through a dependency that had not been considered by the instigator of the change” [41]. The second definition is important as it provides a justification for developing an integrated information model of system safety activities. At present within the process industry, no information model exists for the operational phases and so change impact cannot be assessed easily. The dependencies between the distinct activities are generally not well defined or even apparent to all individuals working on system safety within an organisation. Once the safety system information model has been defined and developed then there should be no dependencies that will not be known to the instigator of changes. This will then help to assess the impact of changes to the safety system and allow quantification of the risk to system safety proposed the potential change.

of 94

The patterns of change propagation depend upon the dependencies between the individual entities within the system and the nature of each entity. Information models with numerous and complex dependencies will have a greater exposure to change propagation than a simple model. The change propagation nature of an entity or component within the model is defined as how the change is passed on or how the change affects other components within the system. Within the paper [38] there are defined three types of change behaviour for each component:

1. Carriers: propagate as many changes as they are impacted by 2. Absorbers: propagate fewer changes then they are impacted by 3. Multipliers: propagate mode changes then they are impacted by. [38]

It can be concluded from these definitions that the change behaviour of a component has a large bearing on how the change would affect the safety objective of an information model. To minimise the change effects it would be preferable to have more absorbers than multipliers within the system. This would have the effect of damping out the ripple effects of change. Once the safety information model has been developed, it will be subject to a change impact analysis. This will determine the sensitivity of the model to various changes. During this analysis the nature: carrier, absorber or multiplier, of each effected activity will be reviewed. If an activity could be modified to alter its behaviour from a multiplier to an absorber or carrier then a suitable method of modification will be assessed.

2.26 Literature survey review Effective information flow and communication are specified by numerous safety standards and these standards have direct linkage to legislation. The subject of data or information integrity is generally not well mandated in these safety standards. The focus of the system safety approach is to concentrate on the hardware and software aspects of a system and omits the requirement for data integrity. The information used during the various safety activities must be validated as failure and errors with this data can have similar affects to those of hardware or software failure. The development of a system safety information model will allow the engineering information to be assessed and subjected to a failure analysis. The integrity requirements can then be assigned to these information flows. Change propagation and change impact upon the on the system safety processes can also be assessed using such a model. The system safety process is frequently depicted in the safety standards as a series or chronological lifecycle. The activities during the operation of a system are continuous and the traditional lifecycle does not represent these work processes as well as it should. A continuous model of the activities during the operational period of a system would more closely reflect the state of the process industry practice. Therefore, the development of an information model that allows the definition of information integrity and assessment of change impact in a continuous form would address the deficiencies identified during the research of this project.

of 94

Chapter 3 Integrated Model development

3.1 Integrated Model development The first part of the design activity is to produce an information model that will allow the aims of this project to be satisfied. The information model must closely reflect industry practice and therefore reflect the activities under review. The model must also be of a suitable format to allow adequate analysis and evaluation to be completed. The following section covers the process taken to develop the system safety integrated information model. An early brain storming session quickly produced a model that reasonably represented the safety related activities of a major chemicals manufacturer in the UK. This early model representation is shown in figure 10 below:

Figure 10 Initial safety initiative model

Although this model seemed complete, further investigation and review revealed that the model was insufficient. The development of this model had been based upon the methods and techniques used as opposed to the most efficient use of information or resources. The methods and techniques employed in this provisional model were dictated by the commercial packages available. It was concluded that basing the model design around commercially available tools would not provide the most accurate representation of the system safety process. Due to this, the above model was not developed further. The most effective model would be produced by analysing the fundamental steps required to achieve system safety and then integrating these in an information model.

of 94

3.2 Identification of safety activities within the process industry A review of work processes currently carried out in the process industry was completed. This review included analysing the activities carried out by various departments in developing, delivering, operating and maintaining a process facility. The analysis included the following activities: 1. Observation of the operation of a chemicals company activities during the operation and maintenance phases. 2. Discussion with a number of safety consultants who are utilised by the operating companies. 3. A literature survey to review existing and potentially new methods. 4. Reference to two process and one oil sector company procedures. This review resulted in the activities in the table below being identified as being the most consistently performed during the safety related work in the process industry sector.

Activity Summary of activity Hazard assessment Identify the hazards Integrity level determination Assign integrity levels to the identified hazards SIF loop assessment Ensure that loop design and proof test interval are

consistent to maintain the level of risk reduction demanded by the integrity level

Plant performance monitoring Ensure plant (process facility) operates as anticipated during the design phases.

Modifications Implementing enhancements to the process facility. Testing Carrying out proof testing to return the SIFs to

original condition. Regulator approvals Seek and obtain regulator approval to operate. Operating repository Maintain a depositary of all data related to

operating, process description, operating envelope, chemistry, inventories, risk criteria, mechanical integrity of vessels etc.

Table 1 System safety activities in the Process Industry

These match reasonably closely to the lifecycles as present in IEC 61508 and 61511. This provides evidence that the list of identified activities is accurate. Two activities do not appear on the typical safety lifecycle. These are ‘regulator approval’ and ‘operating depository’. The reason why ‘regulator approval’ has been identified is that it is felt by the personnel working in the process industry that a large amount of time and effort goes into achieving the objective of this activity. A similar argument holds true for the ‘operating depositary’. A large amount effort is expended in ensuring that all the records and data regarding the facility are up to date. This ‘operating depositary’ activity groups all of the separate activities listed above into one component to simplify the final integrated information model.

of 94

3.3 Integration of identified activities In order to integrate these activities into an information model the flows between the activities must be identified. This has been achieved by listing the possible information flows that form inputs and outputs of an activity. An exercise was then completed whereby the information flows were used to link the activities. The output information flows were individually reviewed and a decision, based upon the research listed above, was made as to where the output flow should be an input to a separate activity. In some instances, the output flow formed inputs into two separate activities. The nomenclature used has been to number the activities and then to number each output information flow based upon the source of the link, i.e. activity number 3 has outputs 3.1, 3.2, 3.3 etc but may have inputs 1.3, 6.3 and 12.7 from activities numbered 1, 6 and 12. Assumptions that have been used during the development of the integrated model are listed below:

1. There will be no information flows that originate and end at the same activity. i.e. the proof testing activity could have a feedback loop back to itself. This feedback would allow enhancement of test procedures. It is acknowledged that this activity occurs but as it is limited to a single activity. All activities should have a self-contained evaluation and improvement process and this will not be represented in the integrated model.

2. External data that is utilised by an activity, such as manufacturer’s reliability data, is not shown in the integrated model. These information flows could be shown as a single entry arrow . It is expected that the category of this type of data would be static.

3. Hazard consequences include safety, environmental and commercial impacts if any hazards become accidents. These categories of hazard will not be distinguished in the model.

4. Information flows have been generalised for clarity. For example, 9.1 ‘process details’ would contain numerous aspects concerning the process plant facility.

5. For the model developed it is assumed that the required competency to complete each initiative is present. A lack competency will cause error in data and this will be explored in the failure analysis of the integrated model later.

of 94

The following table was developed using the technique described in steps 1 to 5 above. Activity Inputs Outputs

9.1 Process description 1.1 Hazard log 1 Hazard assessment 5.1 Possible new hazards 1.1 Hazard log 2.1 Estimated demand rate 9.3 Tolerable risk criteria 2.2 Provisional SIF / instrument

loop design 9.2 Hazard consequences 2.3 IL for each hazard 4.2 Occupancy and vulnerability

2 Integrity level determination

4.1 Actual demand rate 2.3 Integrity levels for each hazard

3.1 Test frequency

2.1 Estimated demand rate 3.2 Loop architecture 2.2 Provisional loop design 3.3 Cause and effects charts 4.1 Actual demand rate

3 SIF loop assessment

4.3 Actual Reliability data 9.4 maintenance interval

6.1 Failure rate in test 4.1 Actual demand rate 4.2 Actual occupancy /

vulnerability 4.3 Reliability data

4 Plant monitoring

4.4 incident reports 5 Modification

7.2 Design change recommendation from regulator 9.1 Process details

5.1 Possible new hazards 5.2 Revised process details

6 Testing

3.1 Test frequency 3.2 Loop architecture 3.3 Cause and effect drawings

6.1 Failure rate in test 6.2 Return to (almost) original condition 6.3 test regime and results

7 Regulator approval 6.3 test regime and results 1.1 Hazard log 8.1 Competency records 4.4 incident reports 2.3 IL for each hazard

7.1 Approval to operate 7.2 Recommendation for change to hardware 7.3 Recommendation for change to management systems

8 Compliance audit, competency and assurance to operate

6.2 Return to (almost) original condition 7.1 Approval to operate

8.1 Competency records

9 Current operating regime

7.3 Recommendation for change to management systems 5.2 Revised process details

9.1 Process details 9.2 Hazard consequences 9.3 Tolerable risk criteria 9.4 Maintenance interval

Table 2 process industry System Safety Information flows

The integrated information model of safety activities from the process industry sector was then developed using this table.

Figure 11 The developed integrated information model on page 49

of 94

1 Hazard Assessment

2 Integrity Level determination


4 Plant monitoring

5 Modification to facility

6 ProofTesting

7 RegulatorApproval

8 Compliance Audit, competency and assurance to

operate

3.3 Cause &Effect chart

1.1 Hazard Log

2.3 IntegrityLevels forhazards

2.1 EstimatedDemand

rate

2.2 ProvisionalSIF loop

architecture

3.1 Testfrequency

4.1 ActualDemand

rate

5.1 PossibleNew hazard

4.3 Actual reliability

6.1 Test failures

3.2 Loop architecture

6.3 Test regime and

result

7.2 Recommendation

to change hardware

4.2 Actual occupancy

& vulnerability

7.1 Approval to operate

1.1 Hazard log


4.4 Incidentreports

6.2 Return to (almost)

original condition

9 Current operatingregime including

Process description. Chemistry, design

Envelope, company policy

9.1 Process details

9.1 Process details

5.2 Revised process details

9.3 Tolerable

risk criteria

9.2 Hazard consequences

9.4 Maintenance

Interval

7.3Recommendation

to change Management systems

4.1 Actual Demand rate

8.1 Competency

records

of 94

3.4 How the model responds to a change As the model represents the operational phases of a system in detail then the effects of change can readily be assessed. An initial review of the model’s response to a change concluded that a change would have serious implications. This was because the model is similar to a complex multivariable control system. It would appear that each activity has a number of inputs and outputs and that all these interconnections interact. A change in any one data flow would require modification to other flows or activities to ensure that the system safety is not comprised. By reviewing the model in detail, it becomes apparent that there are two main feedback loops in operation. These feedback loops will be referred to as: The Integrity loop and The Regulator loop and are briefly described below: 1. The Regulator loop This loop is wide ranging and includes organisations outside of the direct facility operating regime. The loop can consist of either 4 or 5 activities. For regulator recommendations to management systems, four activities should be included: 9 Current operating regime

1 hazard assessment 2 Integrity level determination 7 regulator approval 5 Modification to facility. For changes to physical items 5 activities should be included: 9 Current operating regime 1 hazard assessment 2 Integrity level determination 7 regulator approval 5 Modification to facility. 2. Integrity level loop This loop consists of four activities: 2 IL determination 3 SIF loop assessment 6 Proof testing 4 Plant monitoring This loop could be split into two loops, the main loop detailed and an additional minor loop containing three activities 3 SIF loop assessment 6 Proof testing 4 Plant monitoring 3 SIF loop assessment. The main loos have been superimposed on the integrated model and shown in the following figures.

Figure 12 The Regulator information loop on page 51

Figure 13 The integrity level information loop on page 52

of 94

1 Hazard Assessment



4 Plant monitoring


6 ProofTesting

7 RegulatorApproval


operate


1.1 Hazard Log


2.1 EstimatedDemand

rate


architecture

3.1 Testfrequency

4.1 ActualDemand

rate



6.1 Test failures


6.3 Test regime and

result

7.2 Recommendation

to change hardware


& vulnerability


1.1 Hazard log


4.4 Incidentreports


original condition




9.1 Process details

9.1 Process details


9.3 Tolerable

risk criteria


9.4 Maintenance

Interval

7.3Recommendation



8.1 Competency

records

1. The Regulator loop

of 94

1 Hazard Assessment



4 Plant monitoring


6 ProofTesting

7 RegulatorApproval


operate


1.1 Hazard Log


2.1 EstimatedDemand

rate


architecture

3.1 Testfrequency

4.1 ActualDemand

rate



6.1 Test failures


6.3 Test regime and

result

7.2 Recommendation

to change hardware


& vulnerability


1.1 Hazard log


4.4 Incidentreports


original condition




9.1 Process details

9.1 Process details


9.3 Tolerable

risk criteria


9.4 Maintenance

Interval

7.3Recommendation



8.1 Competency

records

2. Integrity level loop

of 94

The reason for assessing the integrated model in terms of information or feedbacks loops is that it allows comparison to be made with control engineering principles. This will then allow an assessment to be made as to which changes could potentially result in the greatest impacts and so which flows require the more rigorous control or the most level of attention when being developed. To demonstrate this one feedback loop will be reviewed and subjected to a number of changes that could occur during the operational phase. A variety of changes will be selected to demonstrate the sensitivity of the loop to different changes. The change will not be limited to information flows within the loop but will also include input flows or external disturbances to the information loop. The potential change impact will also be assessed. The loop that will be reviewed will be the Integrity Level loop. The table below presents the review of example changes: Description of change

Type of change (Internal / external)

Summary of possible outcomes / impacts of change

Sensitivity of the loop to the change

Change Impact on the objective of the integrated information model

Notes

9.2 Hazard consequences become more severe

External 1. Higher integrity levels 2. Higher frequency of test interval 3. More SIFs required 4. Higher fault tolerance requirements

High sensitivity Reasoning: 1. A high number of outcomes /impacts 2. Changes effects external activities, i.e. higher integrity levels would be available to the regulator

A higher level of assurance must be applied through the model to ensure an adequate level of risk reduction is implemented.

This change would be similar to the tolerable risk criteria becoming more stringent

3.1 Test frequency decrease due to plant maintenance interval being extended

Internal 1. Better SIF equipment 2. Increase in diagnostics 2. Increase in SIF redundancy

Low sensitivity Reasoning: 1. Change only has an effect on the field equipment installed to implement the SIF.

Improved SIF required to maintain required PFD with less proof testing.

4.2 Actual occupancy reducing due to increase in automation requiring less operator activity in the exposed areas

Internal 1. Possible lower integrity levels 2. Reduce in test frequency 3. De-classification from a safety requirement

Medium sensitivity Reasoning: 1. Occupancy would have to reduce drastically to allow a significant decrease in the risk reduction required. 2. Unlikely that no occupancy could be achieved.

In reality, a reduced test frequency would be used, as it is very unlikely that if the SIF was redundant that equipment would be removed.

Table 3 The model change impact analysis

of 94

From the review above a number of observations can be made: 1. Changes do have different consequences upon the functions within the model 2. Changes external to the identified information loops but internal to the model can have the most change impact. It also follows then that external changes to the model would have the most significant effect on the model as a whole. For example, a change in legislation would alter the regulator expectation. This could result in a failure to obtain an approval to operate. 3. Some changes have a low consequence but these consequences can jump thresholds of severity and have greater change impact potential. Therefore a large insensitive change could have a greater impact compared a small sensitive change. For example a small worsening of the hazard consequence could be absorbed into the model and not require any corrective action but a doubling of the required test frequency may result in a total re-design of the SIF architecture, test procedures, cause and effect chart etc. By reviewing the model and analysing the affects of change to the integrity loop, it is concluded that the change propagation characteristics of an activity or component within the model cannot be changed. This characteristic is determined by the nature of the activity. To alter an activity from a propagation characteristic of ‘multiplier’ to ‘absorber’ would change the method by which the activity is integrated into the model. This modification of activities would be valid if it were completed before total integration of the model. It is felt that to alter an activity to become an absorber would require modification of the output information flows. This could be identified in a provision information model which could then be enhanced by changing the propagation characteristics of some activities.

3.5 The benefits of the integrated model The model gives a macro view of the safety related activities required during the operational phases of a process facility. The model could be converted into a generic model with only a few minor changes. The model should provide an outline specification for a new activity if an addition was required to the model. The interfaces and objective of a new activity could be developed from the model by reviewing the adjacent activities. The location within the model of the new activity can be determined by comparison of the new activities input/output information flows and then best fitting these to the established information flows within the model. The system safety model will allow stakeholders to be identified and areas of responsibility to be defined and then allocated. These areas of responsibility could be shown by various methods, colour coding the activity boxes, enclosing areas of responsibility in circles or clouds. An attribute of ownership that could be omitted by this approach would be the allocation of responsibilities for the information flows. Allocation of responsibilities to the activities would be a simply task.

of 94

The owner or responsible party in an organisation would be decided through the disciplines of the stakeholders of each activity. For example, the instrumentation department who are responsible for the SIF loop assessment and proof testing activities, the process engineers would be responsible for the integrity level determination activity. The difficulty would be experienced when responsible parties must be identified for the information flows. For example, which department would be responsible for the provisional SIF loop architecture information flow? This is an output of an activity controlled by the process discipline but is used as an input by the instrumentation discipline. As the model identifies these flows, the action of allocating stakeholders for activities and information flows can be completed at an early stage in the facility’s operational life. The model will allow the impact of changes to be assessed and assist to minimise the impact of change, i.e. it should be apparent from the model what elements the change will have an effect on, who would be affected, how the change would shunt data or propagate around the model. In summary, the model allows the safety activities to be represented in a clear and unambiguous way. An assessment of the impact of changes can be quickly assessed. The allocation of responsibilities can be completed. The absorption of any new activities into the model can be reviewed and implemented more efficiently. The model will also allow any possible omissions in the system safety work be identified and addressed.

of 94

Chapter 4 Model validation

4.1 Information validation technique development The requirement for a hazard analysis of configuration data has been identified by Faulkner, Bennett, Pierce and Johnston. In their paper entitled ‘The Safety Management of Data-driven Safety-Related Systems’: “The correct functioning of these data-driven systems is dependent on the correctness of the configuration data, just as it is dependent on the correctness of the software code. Errors in the configuration data can lead, in safety-related systems, to hazards and possibly to accidents.” also “Hazard analysis should consider the problems produced by incorrect data alongside problems associated with faults within hardware and software” [42] It is acknowledged that the data referred to in both of these extracts is software data but for the purpose of this project this statement is also relevant to engineering data. The review of the model must focus not only what has been included but what may have been missed and to identify any gaps. It should also be noted that Lopez-Mesa and Grante highlight the need to gain understanding about the information flows that can exist between methods. This is the one characteristic of the process related safety system development that this project is principally concerned with. An analysis of the developed model should be completed to quantify its correctness in the context of process safety assurance. One aspect of this analysis will be to assess whether the model will defend against, avoid undertaking or warn the practitioner if bad practices are being implemented. As a basis the seven bad practices identified by Summer [1] will be considered during the failure analysis. The seven bad engineering practices in SIS design are:

1. Believing that, if something is not specifically stated, either "shall do" or "shall not do," in the standards, you do not have to worry about it

2. Thinking that meeting the minimum requirements means the process is safe and the SIS is compliant with the standard

3. Ignoring the importance of good engineering practice 4. Designing systems that meet safety requirements but not economic protection

requirements 5. Focusing only on SIL and not on preventing nuisance trips 6. Neglecting the human factors 7. Focusing on capital cost and not lifecycle costs

4.2 HazOp analysis applied to information flows

4.2.1 Guide words development information flows To evaluate the completeness and integrity of the model some form of analysis is required. This analysis will focus on the information flows within the developed integrated model. This analysis should identify the possible errors that could occur and the effect of data errors in any information flow. An assessment after the analysis will consider the plausibility of any errors and faults identified. The analysis technique chosen that will satisfy this task is the HazOp technique.

of 94

The HazOp technique is a flow based analysis and is extensively used within the process industries. The use of this technique is justified in this context for both of these reasons. There has been extensive work to apply the HazOp technique to software-based systems. It is this work together with the traditional HazOp technique upon which an assessment method will be developed. The book System Safety: Hazop and software Hazop presents a set of guidewords for use with software using data flow diagrams [43]. The integrated model analysis will consider the use of this set of guidewords presented in this book and will extend the guide word list as presented in the paper [44]. This paper describes the development of a hazard analysis to aid software design. Within this paper, a set of guidewords have been proposed and used successfully for software-based systems. The table below lists the guidewords taken from both of these references. The table also provides details on how each guideword will be interpreted and applied to a data or information flow. This explanation was felt necessary as the two methods used apply the guideword to data processed by a computing system, in this project the information flows are not processed data but are in the majority engineering design information. Guideword How the guideword will apply

to an information flow. Example Guide words

taken from None Not supplied at all /

unavailable- Information not available for legacy systems

More Too detailed Hazard log containing possible incident that are not actually plausible hazards

Less Too brief Lack of a thorough review missing possible failure modes

Part of Incomplete/not finished/ preliminary

Design data used early in the lifecycle

Reverse A logic reverse. Approval being granted when it has not.

Other than Wrong due to incorrect specification / standards/

Using ISA standard instead of IEC standard.

Early Preliminary data / data not substantiated (data infancy)

As less

Late Out of date / data age expired Risk criteria used has been rejected by regulator

Before As ‘early’ in this context After As ‘late’ in this context

System Safety: HazOp and software HazOp [43]

Coarse incorrect

Wrong method / wrong results Inexperience causes gross errors in design

Subtle incorrect

Right method / wrong results

A development of hazard analysis [44]

Table 4 Information flow HazOp potential guideword list

of 94

4.2.2 Example / test run using identified guidewords To evaluate the effectiveness of the HazOp technique and to evaluate the combining of the two HazOp approaches a test run or trial analysis will be completed. The usefulness of guidewords will be assessed by reviewing the possible errors identified. To ensure this trail is comprehensive two diverse types of information flows from the model have been chosen to test the proposed HazOp technique. The first information flow chosen is the ‘2.3 Integrity levels for hazards’. This consists of various different states and targets and can be compared to an analogue signal. The other information flow is ‘7.1 Approval to operate’. This data has one of two states, approval or disapproval, and so can be compared to a digital signal.

of 94

1. Information flow ‘2.3 Integrity levels for hazards’ (output from activity number 2 Integrity level determination to activity number 3 SIF loop assessment) Guideword Cause(s) Consequence(s) Note None (omission*)

1. Missing input into IL determination 2. Legacy system has never been subjected to an IL review

Work should not continue without ILs. Further work on preliminary ILs creates the possibility of over expenditure or inadequate risk reduction

If too opportunistic then design will not be adequate and not mitigate risks or gain regulator approval, if too conservative lifecycle costs will be excessive

More Not possible Data will be discreet levels, 1,2,3,4 Less 1. Integrity level supplied but not

categorised as Safety, Environmental, Commercial 2. Inexperienced team 3. Incorrect data used

1. None, highest integrity level will be assigned to the hazard 2&3 Risk that incorrect integrity level will be assigned or/and hazards will not be identified

Part of Preliminary levels supplied Useless confirmed then consequence as None

Reverse Not possible integrity levels have more than two states

N/A The IL can not be reversed

Other than 1. Incorrect method used risk graph as opposed to LOPA, 2. Incorrect risk criteria

1&2 As ‘part of’

Early (*) As ‘part of’ above As ‘part of’ above Late (*) 1. Assessment based on old hazard

list 2. Invalidated technique by

Over complex design as SIF would be included to mitigate hazards that do not exist (best). No SIF for hazards that are

Mitigating against risk that don’t exists does not have a safety impact, not mitigating has obvious safety impacts

of 94

company procedures (risk graph) 3. Invalid data used

present.

Coarse incorrect (detectable in the DJP paper but not in this context until further into lifecycle or re-review)

Set to high due to use of a conservative determination method (risk graph) Set too low

Possibility that platform / procedures and regulator will not support / grant approval facilities (argument) for a SIL 4 hazard As part of

Detectable errors should not flow through the model too far if suitably experienced people

Subtle incorrect (non detectable)

Causes of subtle errors that are non-detectable have been identified by the other guidewords.

Expensive or inadequate mitigation

Table 5 Trial Information flow HazOp ‘2.4 Integrity levels for hazards’

2. Information flow ‘7.1 Approval to operator’ (From 7 regulator approval to 8 Compliance audit, competency and assurance to operate) Guideword Cause(s) Consequence(s) Note None (omission*)

1. Inadequate hazard log 2. Inadequate IL assessments for hazards identified

1&2 Process facility can not operate Regulator has served an prohibition notice

More Not possible Can not achieve excess approval Less 1. Approval granted but with

recommendations for action / 1. Recommendation actions must be addressed and resubmitted for approval

Regulator has served an improvement notice

of 94

change. Part of As ‘less’ above Reverse Breakdown in communication:

1. Receive approval when no approval has been granted by regulator 2. Receive not approved when regulator has granted approval

1. Possibility of operating unsafe facility 2. Financial losses due to suspension of operation when not required

The information flow can be considered as a digital signal and so a reversal of logical is possible.

Other than 1. Approval granted by assessment using ‘wrong’ standards

Not feasible with experienced regulator. Could be an issue in cultures where the level of regulation and standards are developing.

Early (*) Approval recommended on preliminary information but final approval awaiting data finalisation

Possibility of not achieving approval when final data is available

Late (*) Facility receives approval late due to communication problems at regulator’s / facility’s premises

Financial losses due to potential loss of revenue

Coarse incorrect

As Reverse

Subtle incorrect

Covered by other guidewords

Table 6 Trial Information flow HazOp ‘8.1 Approval to operator’

of 94

The test run of the two diverse data flows has provided guidance as to which guidewords would be of most benefit when analysing the integrated model information paths. The combination of the traditional process related HazOp guidewords and the software design HazOp guidewords have been justified by the test scenarios above. From the trial assessment, the following observations have been made in relation to the development of a guideword list applicable to the integrated information model. The guideword of ‘part of’ is covered by two other guidewords. In the first scenario the ‘early’ guideword would have captured the potential error and in the second scenario the guideword ‘less’ would have captured the potential errors that would have been identified by ‘part of’. Therefore ‘part of’ will not be used for the integrated information model review. No possible faults have been identified by the ‘more’ guideword. In the traditional HazOp the ‘more’ guideword related to excess quantity beyond design conditions. In this context, it is not expected that more information will cause a problem with the safety function of the model and so ‘more’ will not be included. Although it is acknowledged that too much information may slow progress ‘more’ does not include incorrect or misleading data. There maybe a situation where the guideword ‘more’ could be related to having a parameter value higher than it should have been. In this situation the guideword ‘Other than’ will be used to identify errors in value as opposed to quantities of information. The guidewords ‘before’ and ‘after’ will be covered by the guidewords ‘early’ and ‘late’. The guideword ‘Subtle incorrect’ covered the analysis that is being completed. The information flow HazOp is being conducted to identify the effect and consequence on the model from errors in information. To allow the analysis to be completed it must be assumed that the possible errors have been undetected and the information containing errors is being utilised by different activities within the model. Therefore, in this review the guideword ‘‘Subtle incorrect’ will not be used as it is felt the other guidewords will be adequate and are intended to identify exactly this type of error. An interesting aspect has been raised during this test run. It was not anticipated that the traditional process related guidewords would be applicable when applied to information flows. The test run HazOp has identified a number of potential errors or incidents that could occur by using the combined list of process and system HazOp guidewords. The most unexpected here was the application of the guideword ‘reverse’. The usefulness of the guideword is apparent in traditional HazOp reviews when considering fluids flows and discrete logic where a reversal of the intention is the condition of concern or hazard. The application of this guideword to an approval notice is comparable to logic where a reversal infers the opposite. Therefore, a reverse approval is actually disapproval.

of 94

The full list of guidewords together with the appropriate interpretation of guidewords for use in this context / applied to data flows in the integrated model is given below: Guideword Guideword interpretation for this study

(how the guideword will be applied to an information flow

Example

None (omission*)

Not supplied / unavailable Data related to a legacy systems

Less Too brief / Incomplete / not finished / Insufficient data recorded from plant performance upon which a decision can be made

Reverse A logic reverse Regulator approval being perceived as being granted when it has not.

Other than Wrong due to incorrect specification / standards/ mis-specification / error in quantity

Use of incorrect tolerable risk criteria

Early (*) Preliminary data / data not substantiated (data infancy)

Preliminary information at an early stage

Late (*) Out of date / data age has expired Coarse incorrect

Wrong method / wrong results Use of risk graph if LOPA is the mandated method of IL determination

Table 7 Information flow HazOp final guideword list

4.3 HazOp review of the integrated model’s information flows. This section exercises the HazOp technique using the guidewords developed applicable to an integrated model. To limit and so focus the scope of the work in this project it has been decided that a review of all the information flows shown in the integrated model would not provide great benefit. If is felt that there could be a repeat of issues highlighted by the same guidewords and this would increase the reports volume for little benefit. To validate the model and the definition of information flows applicable guidewords, the information flows to and from a single initiative will be completed. It is expected that the review will:

1. Provide an insight into the method of a Hazop based review of information flows. These information flows being data used by humans to develop and engineer systems.

2. Provide evidence on the validity of the developed integrated information model.

3. Highlight the areas in the safety related work process where errors could have serious consequences and pose a risk to system safety.

4. Offer areas of potential improvement to either eradicate the possible errors or minimise the effect of these errors on the safety integrity of the platform upon which the model could be applied.

of 94

An activity from the integrated model must be selected that will satisfy most completely the requirements above. A review of the model has concluded that the information flows to the activity ‘2 Integrity Level Determination’ will provide the most valuable results. There a two reasons for this selection. An error in the integrity level determination could result in either of the following scenarios: 1. Inadequate risk reduction measures being put in place. For example, the hazard maybe wrongly assessed as a SIL 1 where it should have been assessed as SIL 2 .The SIF implemented will nominally then be designed to have a PFD in the range of 0.1 to 0.01. If actual hazard should have been assessed as a SIL 2 then the minimum PFD for the SIF must be 0.01. Therefore, the level of risk reduction is an order of magnitude too low. 2. Conversely an integrity level set too high will incur an unnecessary high financial burden on the operating organisation. A study has been conducted by a major chemicals manufacturer that estimates the additional lifetime costs of implementing a systems with different integrity levels. This study has showed that operating a SIL 3 system compare to a SIL 2 for the whole lifetime of the system would result in a financial penalty of $200,00 [45]. It may also cause unnecessary attention from the regulator, i.e. the facility may appear to be more hazardous than it actually is if the majority of hazards are assessed to be SIL 3. Although reason 1 has the most serious safety implications, for many companies the additional cost for the lifetime of the system will also be a significant driver to ensure errors are not introduced into the system safety development process. As part of the HazOp analysis the affects of the input data flows on the activity’s output data flows will be considered. This will provide a view on the robustness of the model. If any errors on the outputs are deemed to have significant effect then the effects of these errors on the effectiveness of the model will be reviewed. The information flows that will be subjected to a HazOp analysis using the guidewords developed are shown in the table below. Information flow identifier Input information Flow Name 1.1 Hazard log 4.1 Actual demand rate 4.2 Actual occupancy and vulnerability 9.2 Hazard consequences 9.3 Tolerable risk criteria

Table 8 Information flows from the development model for HazOp review

A brief explanation of each of these information flows is required to set the context for the HazOp analysis. It is not intended to provide a complete review, as there are numerous publications available that describe these elements in full. This will provide the justification for including the information flow within the model and will also establish the evidence for the information flow and identify the stakeholder.

of 94

Hazard Log (1.1) The hazard log is used across all industry sectors and is a means to list, track and control hazards. It should be actively managed and be maintained throughout the life of the system. As new hazards are identified these should be added to the log. Any operation that involves a risk element should have a hazard log so that evidence of the management of safety can be demonstrated. The party responsible for the hazard log should be a person who is identified by an organisation as accountable to the relevant industry regulator. The process industry does involve risk and so a hazard log must form part of the safety assurance policy and is a fundamental component of the COMAH regulations. Demand rate (actual) (4.1) The demand rate is the expected frequency at which the protection system is likely to be required to operate which is the expected frequency that the hazard will occur. This is the expected frequency that unsafe conditions will be experienced. In the process industry, demand rate is defined as “number of times per year that a hazardous situation would occur in the absence of a safety instrumented function.” This information is important, as it will be used to determine the integrity of each hazard. A hazard that occurs frequently will require a higher level of protection to ensure that the hazard frequency is reduced to the tolerable risk criteria. For the initial integrity level, determination the expected or estimate demand rate will be used. Once the facility has been in operation for some time then the integrity determination exercise should be repeated using the actual or experienced demand rate. This requirement is stated in IEC 61508 part 1 clause 6.2.1 j “assessing whether the demand rates and failure rates during operation and maintenance are in accordance with assumptions made during the design of the system”. The operating and maintenance plan should include procedures for monitoring actual demand rates and reliability figures to ensure that assumptions made during design are actually realised during operation. The plant management would be responsible for ensuring that this information is collected and that the integrity level assessment are validated as required by the regulator. Occupancy and vulnerability (actual) (4.2) This information is also used in the integrity level determination. The probability of an accident occurring is related to whether there are any people exposed to the hazard and if individuals are exposed then would these exposed individuals be harmed if the accident occurred. The higher the occupancy and vulnerability then the worst the hazard and so a higher integrity level would be assigned. Although IEC 61508 does not specifically require that the occupancy and vulnerability be validated from the estimated figures used in the original integrity level determined it seems good practice to ensure that the original assessment is still valid when real hard data becomes available. The plant management would be responsible for collecting and communicating this information

of 94

Hazard consequences (9.2) This information can be included in the hazard log once the hazard assessment activity has been completed. In the integrated model, the hazard consequences have been kept separate to the hazard log to highlight the fact that these can change and are derived from the integrity of design for the process vessels and the inventory contained within the chemical plant. The most senior chemical engineer would be responsible for this information. Tolerable risk criteria (9.3) This is the level of risk at which the management are comfortable to operate the facility. In broader terms, it is the risk that is accepted in a given context based on the current values of society. It is the risk that remains present after all reasonable precautions have been implemented or the risk remaining after protective measures have been taken. It is the most senior management who should be accountable for defining and accepting the tolerable risk criteria for an organization. If the information flow into the chosen activity is also an input in a separate activity than the effect on the other activity will also be identified. This will be limited to the consequence on the other activity and will be noted, in brackets, the Notes / recommendations column of the Hazop tables. Of the information flows in table @@ above two are also inputs into other activities: 4.1 Actual demand rate is an input into 3. SIF loop assessment and 1.2 hazard log is an input into 8 Regulator approval.

The possible output information that could be affected by errors in the input flow to Integrity level assessment shown in the table below: Information flow identifier Output information Flow Name 2.1 Estimated demand rate 2.2 Provisional SIF loop architecture 2.3 Integrity levels for hazards

Table 9 Possible outputs for HazOp review

4.3.1 Information Flow HazOp analysis results

of 94

Table 10 Information Flow HazOp: 1.1 Hazard Log

1. Information Flow : 1.1 Hazard Log Data kind : List HazOp Number

Guideword A. Cause(s) B. Consequence(s) C. Notes / Recommendation

1 None A1.1 HA not carried out A1.2 Requirement for HA not recognised/ included in work processes

B1.1 No hazards would be identified to which an integrity level could be assigned. No integrity levels would not allow the rest of the model to operate as compliance to IEC 61508/61511 could not be demonstrated B1.2 Not anticipating a hazard analysis is a serious omission and will cause problems for the safety compliance of the whole facility. A late HA will cause the analysis to be rushed and so not conducted in a thorough way. There is a probability that hazards will not be identified and so will not be mitigated against.

C1.1 The absence of a hazard analysis is not anticipated with systems that adopt the recent IEC standards 61508 / 61511. This could be an issue with legacy safety shutdown systems whereby the original hazard analysis may not be available or may never have been conducted. C1.2 This would not be accepted by the regulator.

2 Less A2.1 Inadequate HA method A2.2 Inexperienced HA team A2.3 Insufficient time to complete HA

B2.1 An inadequate HA method may not identify all of the hazards associated facility or operation. B2.2 An inexperienced team may not identify all the hazards. B2.3 As B1.2 for a rushed HA

C2.1 Insufficient risk mitigation would be implemented C2.2 as C2.1

3 Reverse Not possible 4 Other than A4.1 as A2.1 5 Early A5.1 Preliminary data if all

exposure / vulnerability calculations not completed

B5.1 The hazard analysis may be based upon preliminary information. Although this will give an indication of the hazards present, it may either identify too many or too few hazards.

C5.1 as C2.1

6 Late A6.1 As A1.2, A2.1, A2.2, A2.3

A6.2

7 Coarse incorrect

A7.1 As A2.1, A2.2, A2.3

8 Subtle incorrect

A8.1 As A2.2, A2.3 A8.2

of 94

2. Information Flow : 4.1 Actual demand rate Data kind : Report / log HazOp Number


1 None A1.1 No plant monitoring regime in existence A1.2 Information not supplied A1.3 No demands have occurred A1.4 Data lost A1.5 Monitoring the incorrect section of plant

B1.1 Integrity level cannot be validated therefore not compliant with standards. B1.2 as B1.1 B1.3 as B1.1 but should raise concern B1.4 as B1.1 B1.5 An integrity level would be validated (or not validated) using the wrong data.

C1.1 Validation of integrity level is required by IEC 61508 and IEC 61511 (A demand rate is required to allow SIF loop assessment) C1.3 Although this is the intention of a high integrity installation it is unforeseeable that no demands will occur. It would be expected that human error during operation would introduce a demand for some period of time. Recommendation would be to check the monitor system effectiveness. C1.4 This should only occur once where by a more rigorous procedure / control should be implemented to ensure that data is not lost again C1.5 This could lead to incorrectly validated integrity levels and result in inadequate or excessive risk reduction measures.

2 Less A2.1 Some spurious trips have to been missed and not recorded A2.2 The definition of a demand is not correct A2.3 Incorrect understanding of data using wrong units i.e. demands per week in place of demands per month.

B2.1 The integrity levels will be validated to be lower than what should be specified. B2.2 The integrity level could be validated either higher or lower than what should be specified, direction error cannot be determined from this review. B2.3 s B2.2

C2.1 Insufficient risk reduction measures will be implemented and so hazards could lead to accidents more readily. (A lower than actual demand rate would also result in the proof test frequency being calculated as being too low in the SIF loop assessment activity) C2.2 as C1.5

3 Reverse Not possible 4 Other than A4.1 As A1.5

A4.2 As A2.2 A4.3 Incorrect specification of a demand results in too many demands being recorded

B4.3 The integrity levels will be validated to be higher than what should be specified

C4.3 Excessive risk reduction would be employed resulting in over expenditure and also possible unjustified scrutiny from the regulator.(SIF loop assessment would result in an over engineered solution than what would be required)

of 94

Table 11 Information Flow HazOp: 4.1 Actual demand rate

5 Early A5.1 Insufficient time has past to allow a valid demand rate to be measured. A5.2 Extrapolated demand rate from limited operating experience

B5.1 Measured demand rate could be lower than actual demand rate experienced after a suitable duration of operation B5.2 as B2.2

C5.1 as C1.5

6 Late A6.1 Integrity level determination has been confirmed without using the actual demand rate A6.2 Demand rate was recorded during a previous operating regime.

B6.1 as B1.1 B6.2 as B2.2

7 Coarse incorrect

A7.1 Inaccuracies due to reasons above that are grossly larger than expected

B7.1 mainly as B2.2 but detected C7.1 It would not be expected that no demands occur and so the data cannot be grossly lower than expected.

8 Subtle incorrect

A8.1 Inaccuracies not undetected and utilised

B8.1 As B2.2 but not detected

of 94

Table 12 Information flow HazOp: 4.2 Actual occupancy and vulnerability

3. Information flow :4.2 Actual occupancy and vulnerability Data kind : Report / log

HazOp Number Guideword A. Cause(s) B. Consequence(s) C. Notes / Recommendation 1 None A1.1 No plant monitoring regime in

existence A1.2 Information not supplied A1.3 Data lost A1.4 Monitoring the incorrect section of plant

B1.1 Integrity level cannot be validated therefore may not (see note) compliant with standards. B1.2 as B1.1 B1.3 ad B1.1 B1.4 An integrity level would be validated (or not validated) using the wrong data.

C1.1 IEC 61508 part 1 clause 6 does not specify that occupancy levels should be revisited after a period of operation but as occupancy has an effect on integrity level then this information should be used to ensure that assumptions made during design are actually realised during operation. C1.4 This could lead to incorrectly validated integrity levels and result in inadequate or excessive risk reduction measures.

2 Less A2.1 Individuals are exposed to the hazard more frequently than reported A2.2 Incorrect specification of occupancy

B2.1 The integrity levels will be validated to be lower than what should be specified. B2.2 as B2.1

C2.1 Insufficient risk reduction measures will be implemented and so hazards could lead to accidents more readily

3 Reverse Not possible 4 Other than A4.1 as A1.4 5 Early A5.1 Insufficient time has past to allow a

valid demand rate to be measured.

B5.1 Occupancy could be assumed higher or lower than would be the case after a suitable duration of operation.

C5.1 This could lead to incorrectly validated integrity levels and result in inadequate or excessive risk reduction measures

6 Late A6.1 Integrity level determination has been confirmed without actual demand rate A6.2 Occupancy was measured during a previous operating regime

B6.1 as B1.1 B6.2 as B5.1

7 Coarse incorrect

A7.1 Incorrect calculations result in zone of vulnerability too extensive, i.e. the whole site and surrounding landscape

B7.1 This gross over estimate would be detected during the integrity level determination.

C7.1 It is unusual to have SIL3 hazards in the process industry and vitality unheard to have SIL 4, (check David Smith’s book on this)

8 Subtle incorrect

A8.1 Numerous causes captured above.

of 94

Table 13 Information Flow HazOp: 9.2 Hazard consequences

4. Information Flow : 9.2 Hazard consequences Data kind : Description HazOp Number


1 None A1.1 Plant maybe total benign and not contain hazards A1.2 Hazard consequence review/study not carried out A1.3 data lost A1.4 Information not supplied

B1.1 No requirement for a safety philosophy if no hazards are present B1.2 Integrity levels cannot be determined if the consequence of a hazard developing into an accident is not assessed. B1.3 as B1.2 B1.4 as B1.2

C1.1 Very unlikely in an industry context C1.2 Activity can not be completed C1.3 This should only occur once where by a more rigorous procedure / control should be implemented to ensure that data is not lost again

2 Less B2.1 Incorrect assessment leads to a lower hazard potential than actually exists B2.2 Chemistry changes and this change introduces new more serious consequences B2.3 An inexperienced team do not correctly calculate the consequences

B2.1 The integrity levels will be validated to be lower than what should be specified. B2.2 The integrity levels will be validated to be higher than what should be specified. B2.3 The team could over or under qualify the integrity levels

C2.1 Insufficient risk reduction measures will be implemented and so hazards could lead to accidents more readily C2.2 Excessive risk reduction would be employed resulting in over expenditure and also possible unjustified scrutiny from the regulator C2.3 This could lead to incorrectly validated integrity levels and result in inadequate or excessive risk reduction measures

3 Reverse Not possible 4 Other than A4.1 Hazard consequences supplied

for a different process A4.1 as B1.2

B4.1 An integrity level would be validated (or not validated) using the wrong data

C4.1 as C2.3

5 Early Not anticipated C5.1 The hazard potential is a calculated figure and should be available even if plant is not yet built.

6 Late Not anticipated C6.1 Integrity level cannot be determined without the hazard consequences

7 Coarse incorrect

A7.1 Incorrect hazard assessment results in an extensive estimate of hazard, i.e. the whole site and surrounding landscape

B7.1 This gross over estimate would be detected during the integrity level determination.

C7.1 It is unusual to have SIL3 hazards in the process industry and vitality unheard to have SIL 4

8 Subtle incorrect A8.1 Numerous causes captured above

of 94

Table 14 Information flow HazOp: 9.3 Tolerable risk criteria

5. Information flow : 9.3 Tolerable risk criteria Data kind : Report

HazOp Number


1 None A1.1 Not supplied by management A1.2 Concept of risk not recognised A1.3 Management refuse to accept that there is a risk associated with operations.

B1.1 Integrity levels cannot be quantified and assigned to hazards. B1.2 as B1.1 B1.3 as B1.1

C1.1 This blocks further progress to achieving a demonstrable safe system and compliance to the IEC standards.

2 Less A2.1 The tolerable risk being set too low A2.2 Tolerable risk criteria not established for all possible consequences, i.e. omission of environmental risk targets A2.3 Risk criteria change and become more stringent

B2.1 The integrity levels will be quantified to be lower than what should be specified B2.2 It would not be possible to assign an integrity level to all hazards B2.3 as B2.1

C2.1 The regulator would have an acceptable band of tolerable risk criteria and would expect compliance, e.g. HSE R2P2 criteria. C2.2 Incomplete data available to 3 SIF loop assessment and for regulator approval.

3 Reverse Not possible 4 Other than A4.1 Tolerable risk set too high and in

excess of regulator expectation B4.1 The integrity levels will be quantified to be higher than what should be specified

B1.4 Excessive risk reduction would be employed resulting in over expenditure and possible unjustified scrutiny from the regulator.

5 Early A5.1 Inadequate review and discussion by management concerning the implications of setting the tolerable risk criteria

B5.1 The risk targets maybe too high or too low for the industry sector under review.

C5.1 Management must recognise the importance of risk acceptance and of setting realistic risk targets as these are the fundamental building block for the demonstrated safety and ALARP.

6 Late A6.1 as A1.1 A6.2 as A1.2 A6.3 as A1.3

7 Coarse incorrect

A7.1 Management not understanding the tolerable risk concept

B7.1 Incorrect integrity levels been determined.

C7.1 This would be detected if outside of the acceptable risk range published by the HSE in R2P2 document.

8 Subtle incorrect

A8.1 as above

of 94

4.3.2 Hazop Output Review Common consequences caused by the error or fault in information flow as identified in the information flow HazOp are listed below:

1. An integrity level could not be assigned to a hazard. 2. The integrity level would either be set or validated too low 3. The integrity level would be set or validated too high 4. The fault would cause the integrity level to be set incorrectly higher or lower

than required. With a number of failures the direction of this error could not be determined by the HazOp process.

5. Data on legacy systems may not be available or if available would most likely be out of date.

6. Inexperience of individuals will create a lack of thoroughness resulting in omissions that may well be the vital issues in the context of safety assurance. The more difficult or obscure hazard scenarios may not be identified by an inexperienced team

It has been found that the majority of errors are concerned with the integrity level assignment. There is no surprise as the activity being reviewed was the Integrity level determination. An observation made by the review is that the errors or faults result in both over and under specification. A corrective action that could eliminate these errors would be to benchmark a facility’s integrity levels against a similar facility. A company internal benchmark would be of greatest benefit as the fundamental building blocks upon which integrity levels are developed would be the same, i.e. tolerable risk criteria for the organisation. Although the criteria for setting the integrity level would vary between organisations, integrity level assignments should still be at the same level within an industry sector. For example, the safety integrity level for a turbine overspeed trip should be the same across an industry sector as the probability and consequence of such a hazard should remain unchanged. The only likely source of deviation would be the classification of a commercial integrity level (CIL). The cost of replacement of an on shore turbine compared with an off shore turbine would be vastly different and could result in a higher criticality for offshore installations. As the IEC standards do not cover or specify commercial protection than this difference will not be of interest to the regulator. A benchmarking exercise would provide a check / control for the errors numbers 2, 3, and 4 above. Currently the IEC safety standards relevant to the process industry are based upon the integrity levels. Within this industry sector, it is unlikely that this will change in the near future. It is acknowledged that the MOD has moved away for the integrity level concept. The impact on the integrated model if integrity levels were abandoned by the IEC standards could form a subject for further works.

of 94

4.3.3 Hazop conclusions 1. Inexperience features more in calculation / review type activities than measurement / monitoring activities. This is because monitoring activities can be fully defined by procedures. Activities involving calculation or review rely on competence and judgement to a much greater extent. 2. An error resulting in the incorrect assignment of an integrity level has two effects, both of which are financially unattractive. If an integrity level is assigned higher than it should be then the financial impact should be more readily apparent. The lifetime costs of the facility would be much higher than anticipated. If the integrity level has been assigned to a lower level than required then the additional financial burden only becomes apparent if an accident occurs. In addition, if the integrity levels were under specified the regulator may not agree with the assigned integrity levels and require further work. 3. The competency and experience of the team should capture the errors identified by the HazOp guidewords ‘grossly incorrect’. 4. Benchmarking across the industry would help in ensuring that safety objectives are in the right area. 5. The HazOp guidewords ‘subtle incorrect’ and ‘coarse incorrect’ did not work as well as expected in full HazOp. 6. Reverse guideword does not feature regularly as most information flows are not two state and so cannot be judged to be opposite or reverse. 7. Guideword ‘more’ maybe should have being included with hindsight. This guideword could have been used to identify excesses in the numerical value of the data as opposed to an excess in the quantity of information flowing. 8. The tolerable risk criteria is a fundamental building block for the safety philosophy and so must receive adequate attention and acceptance by senior management. Error in this information would have one of the most serious change impacts and jeopardize the safety risk of the system under development. 8. Subtle incorrect is really covered by the other guidewords as the other guidewords cover the fact that an error in the information flow exists and so has been detected, the HazOp explores the consequence of these errors.

4.4 HazOp Analysis validation To validate the HazOp review conducted on the information flows then a second and diverse analysis should be completed. A review technique aimed at the activity as opposed to the information flows would achieve a truly diverse set of results. A comparison of these results against the outputs from the HazOp should provide some correlation.

of 94

If a correlation can be demonstrated then this would then provide a validation of the HazOp technique applied to information flows and so therefore validate the results of the HazOp analysis. This validation can then be used to develop an argument on the completeness of the model and to address issues, which could be resolved to provide a more complete model for the information flows and system safety.

4.4.1 Validation technique A review of techniques available to identify failures in the integrated model has been conducted. During this review, the following methods were considered: SNEAK analysis[46], SHARD [44] and functional failure analysis (FFA) [47]. FFA was chosen because of the following reasons: 1. It is a relatively simple process 2. It is a method that will examine the correct operation or functioning of the activities within the model. This will provide the diversity in failure analysis required. 3. The FFA principle can span a number of technologies and so the use of the technique within an information model context is valid. 4. The FFA technique can be applied at both a high and low level of detail in a system design. To conduct a functional failure analysis on the Integrity level determination activity then failures in the outputs will be explored. A failure in the function of the integrity level determination will manifest itself in the activity output. The suggested functional failures categories of a) function not provided, b) function provided when not required and c) malfunction, [47] are not readily applicable to information flows. The failure categories that will be used in the information activity FFA will not be defined. Alternatively, any causes of how the information could be incorrect will be considered. The functions listed are those outputs from the activity as shown in the developed information model. The phase during which the failure could occur is not of concern in the context of the integrated model as the model represents the operational stage containing the operation, maintenance and modification activities. The phase column will not be included in the following FFA.

4.4.2 Functional failure analysis of the information model The table below shows the FFA on the Integrity Level determination activity.

of 94

Function Failure

condition (of output information flow)

Effect of integrated model / safety assurance of facility

Classification Safety / Commercial

Target probability

2.3 Integrity Levels for hazards

2.3.1 Integrity level set too high

The level of risk reduction implemented will be in excess of the level of risk reduction actually required. This results in excess expenditure in: 1. Installation of addition safety devices 2. Additional maintenance of the SIF for the life of the system 3. Possibly additional staffing costs are a more competent workforce must be engaged to ensure the systems integrity in maintained and assured. This failure could also cause unnecessary attention of the industry regulator.

No safety consequences as the system will be of a higher integrity than what is actually required. / Commercially the classification would be more expensive than required

Reasonably probable As human nature is to err on the side of caution, inexperience could result in over specification

2.3.2 Integrity level set too low

The risk reduction methods would be insufficient to mitigate against the actual hazard potential present. This failure mode is very serious.

Hazardous. There is a probability that the hazards identified could lead to an accident. / Commercially this failure could be beneficial as the lifetime costs would be less and so allowing a greater profit to be returned from the facility. This is only true if the hazards do not progress to an accident

Probable It is felt that if hazards have been identified by the Hazard assessment activity then there should be sufficient experience within the organisation and across the industry sector to assign the integrity level correctly. It is in this scenario

of 94

where great financial losses would be experienced

where a benchmark of integrity level allocation should be made to reduce this probability to remote.

2.3.3 Hazards not assigned an integrity level

This failure is similar in nature to the failure above except that the hazards are not assigned an integrity level and would have no risk reduction applied to them as opposed to some. Therefore, the probability of an accident is much higher.

Catastrophic An unmitigated hazardous would be present. / Commercially extremely damaging if an accident occurs.

Remote The omission of a serious hazard up to the point of integrity level determination is felt to be remote. In the process industry as elsewhere the system / facility would be subjected series of hazard identification techniques i.e. PHA, HazOp,

2.3.4 No integrity level assigned

It is considered that this failure could not occur. If a hazard were passed from the Hazard assessment activity then it would be assessed by the integrity level determination activity. There is a probability that the hazard log could be corrupted but this failure is associated with data storage / interchange that is not with the scope of this project. If a hazard did not have an integrity level assigned to it than the consequence or probability of the hazard would have been considered acceptable. A cause of this could be the result of an incorrect input to the integrity level determination activity, i.e. the tolerable risk criteria being too high. The tolerable risk failure

None

of 94

mode would have consequences on all failures identified above and will be discussed later.

2.2 Provisional SIF loop architecture

2.2.1 Inadequate SIF design

The effect of this failure is similar to ‘2.3.2 Integrity level set too low’ above, as inadequate risk reduction would be employed. Although it is felt that this failure would have a higher probability to being detected. There would be a greater population that would recognise the architectural requirements of high SIL system as compared to the number of people would have the skills to interrupt the hazard attributes and assign an integrity level. For example if a hazard was assigned a high SIL then certain requirements of fault tolerance are required etc. A hazard assessed as SIL 3 being protected against by a simplex system should be identified at some stage, if not by the regulator.

Hazardous / Commercially extremely damaging it accident occurs.

Reasonably remote

2.2.2 Excessive loop design

This failure mode would result in excess risk reduction and the associated additional costs that would be experienced during the system’s lifetime. Again the detection of this failure would have a reasonable probability of success due to the reason given above

No safety consequences as the system will be of a higher integrity than what is actually required. / Commercially the classification would be more expensive than required

Reasonably remote

2.2.3 No loop design

This could only occur if there were either no hazards or the hazard had been assessed to have no safety requirement, the issues are as those described in ‘2.3.4 No integrity level assigned’ above

None or debatable

2.1 2.1.1 Demand If the demand rate was estimated to be too low then Hazardous as there two Probable

of 94

Estimated Demand rate

rate too low there is a probability that SIF loop design could be inadequate. Also the proof test interval of the SIF would be set too infrequent which would result in a greater probability of the SIF not operating when required.

potential affects of this single failure mode. / Commercially damaging if accident occurs

At this stage because of a lack of operating experience but the probability of this failure would reduce as the plant monitoring activity would provide the actual demand rate.

2.1.2 Demand rate too high

This failure would have the opposite effects to those identified above

No safety consequences / Commercially could be very expensive if the proof interval was very frequency then this would result in excessive downtime and lost profit. In addition, the excessive interference with the devices in the safety system increases the probability of a human error that could leave the system in an unsafe condition.

Probable as above.

2.1.3 No demand rate

A demand rate must be provided based initially on the best estimated and substantiated later.

Table 15 Functional failure analysis on the Integrity Level determination activity

of 94

4.4.3 FFA output review The following observation can be made from the results of the information model FFA. 1. The incorrect assignment of the integrity level is a potential failure as mechanisms to introduce there failures have been identified by the FFA analysis. 2. The integrity levels can be set either too high or too low. 3. The skills and experience of the people involved can introduce failures. 4. The probability that certain errors would be detected has been recognised.

4.4.4 FFA conclusions There are a number potential functional failures of the integrity level determination activity that are directly attributed to errors or incorrect inputs to the activity Competency levels of individuals engaged in the activity can create errors in the operation of this activity or component. The assessment of probability is an added feature over and above that found from the HazOp and adds context into which the criticality of each failure can be considered. Why the HazOp does not normally officially assess probability is not understood. By considering the function of an activity then the implication of failures or errors on other activities are more readily identified, i.e. the effect of demand rate on the proof test interval.

4.5 Information analysis technique comparison The diverse analysis techniques have identified a number of identical failures or potential errors in the information flows of the integrated model. As the majority of failure modes and causes of these failures modes are similar then it can be concluded that a thorough review of the model has been completed. The absence of any probability assessment in the HazOp analysis does not allow an as full as possible assessment of the potential failures. The probability element of the FFA helped in considering further the effects and the likely hold of the failure being detected. Even though the FFA is a simpler and quicker process compared to the HazOp technique the FFA provided same results. The reason for this is that the FFA technique can adequately be applied at a high level and does not depend on a low-level detailed analysis. The HazOp technique relies on a more detailed review to identify potential problems.

of 94

4.6 Model completeness from analysis using both analysis techniques The model, as far as the Integrity level determination activity, has been shown to be complete. The errors or failures identified in both analysis techniques are contained within the model. No failure causes have been shown to be derived from an omission in the model. This concludes that the information flows to and from the activity under review have been incorporated into the model and therefore complete. The failures that have been identified would be caused by errors in information flowing around the model and are not due to the construction of the model. The consequences of these failures are directly relatable to the relative positions of the information flows or activities in the other activities or components, i.e. errors in tolerable risk criteria amplify themselves throughout the model and have the potential to invalidate the complete safety assurance process. Comparison here can be made with the traditional safety lifecycle where errors in the early stages can have greater impact than errors later although this is not true in every scenario. The criticality of data should be recognised as a measure of the potential impact of data errors on the system safety process. A concept that should be considered when assessing the information is the contribution to the failures from common cause sources. The stakeholders for the information flows have not been determined from the model. Further work should identify the impact of any common causes errors with the assessment of Beta factors if a single individual or department are stakeholders in more than one activity. To avoid the potential failures associated with the information flows then the confidence in the accuracy of data within these information flows must be established. A method to defend against this could be the adoption of Assurance Evidence Levels (AEL) to the information flows within the model. The definition of AELs is given as “the level of confidence a data component will possess” [48] which matches the observations and vulnerabilities identified so far this is project. A review of AEL use and allocation has been completed and a proposal for the use of AELs in an information flow application is presented later.

4.7 Model improvement

4.7.1 Application of AEL to information flows SW01 of CAP 670 uses the concept of Assurance Evidence Levels (AEL) to “relate the criticality of the software safety requirement to the depth and strength of the evidence for the assurance of its correct operation” [49]. This can be related to the confidence levels of the information flows within the integrated information model. The depth and strength of evidence for software functionality can be translated and related to the data consistency, completeness and accuracy within each information flow of the integrated model.

of 94

Appendix A of SW 01 provides guidance for the identification of AELs. This guidance states “the strength and depth (rigour) of ‘that’ assurance argument is driven by the safety criticality of the software safety requirement” [49]. It is valid to associate the qualities of data to the safety critically of the application. This is an established principle but is stated here to reinforce the relationship between AELs / software correctness and AELs and data correctness. Appendix A of SW 01 contains two tables that allow the assignment of AELs. The provisional allocation of an AEL is made using table 1. This is achieved by relating the worst-case consequence of a failure (or the hazard) to one of the five available AELs. The more severe the consequence then the higher the AEL is allocated. The higher AEL assigned then the strength and rigour of the evidence must be provided to a greater level. Characteristic AEL 1 AEL 2 AEL 3 AEL 4 AEL 5

SRC Severity No Slight Major Large Complete Classification immediate reduction in reduction in reduction in loss of scheme in effect on safety safety safety safety ATM safety margins margins margins margins (ESARR 4)

Relationship to No effect on Increased Loss of Serious loss A UK the Mandatory ATC ATC separation of reportable Occurrence workload workload Significant separation accident Reporting ATC Serious

ATC Actual risk

Scheme (CAP overload overload of collision 382) Significant Serious degradation degradation of ground of ground based based system system

Relationship to N/A N/A C- No risk of B - Safety A - Risk of

the UK Airport collision not assured collision Board, Risk categories

Table 16 AEL safety criticality (taken from CAP 670 SW 01 Appendix A)

These AELs can be reduced if it can be argued that other facilities are available to mitigate against the worst case consequences used to assign the AEL. If there are architectural and operation defences that can mitigate the hazards then the assigned AEL can be reduced. This principle demonstrates a defence in depth principle. A similar concept is used in both IEC 61511 by reducing integrity levels if the equipment used in the SIF can be proven in use. The AEL safety criticality modification criteria are given in table 2 of Appendix A of SW 01 and are shown below.

of 94

Reduction of AEL -1 -2 -3 -4 Characteristic Number of strength of defensive layers

Requirement is monitored

Requirement is met independently in a redundant channel

At least two forms of mitigation which are not part of the requirement

Many forms of mitigation such that a failure of the requirement is extremely unlikely to result in the hazard

The probability of the failure of all architectural and operational defenses

10-2/hr 10-3/hr 10-5.hr 10-7/hr

Table 17 AEL criticality change due to Architectural & operational defences

Both tables 1 and 2 from SW01 appendix A have been reviewed and modified so that the concept of AELs can be applied to information flows in a similar manner to safety software components described in SW 01. The information flow related version of table 1 is presented below. The original table in SW 01 contains three characteristics or sets of guidewords to help in the understanding of the potential hazards. It is felt that these definitions aid the allocation of AELs and a similar principle will be used in the information flow related version of the table. It is felt that by distinguishing between the two most common forms of integrity level determination techniques then the table will be much easier to interpret. Therefore the effect on integrity level as determined by a risk graph approach and the effect on target PFD of the SIS as determined by Layer Of Protection Analysis (LOPA) will be incorporated into the table. Characteristic AEL 1 AEL 2 AEL 3 AEL 4 AEL 5

Effect on Integrity level if IL determined using risk graph method

Data error causes IL to increase by 1

Data error causes IL to reduce by 1or increase by 2

Data error causes IL to reduce by 2 or increase by 3

Data error causes IL to reduce by 3 or increase by 4

Data error results in a hazard not be identified or/and not allocated an IL

Effect on integrity level if IL (PFD target) determined by LOPA method

Data error causes PFD to reduce by 1 order of magnitude

Data error causes target PFD to increase by 1 order of magnitude or decrease by 2 orders of magnitude

Data error causes target PFD to increase by 2 orders of magnitude or decrease by 3 orders of magnitude

Data error causes target PFD to increase by 3 orders of magnitude or decrease by 4 orders of magnitude

Data error results in a hazard not be identified or/and not allocated a target PFD for the SIS

Table 18 AEL related to information flow criticality

of 94

The table above shows how errors or failures in an information flow that increase the integrity level result in commercial loss not a reduction in safety coverage would be assigned a lower AEL then errors or failures in an information flow that decrease the integrity levels which would cause a reduction in safety coverage or risk reduction. It can be seen from the table above that that highest information flow AEL is allocated to the most serious failure identified during the information flow HazOp. A hazard not identified or not allocated an integrity level is a hazard that exists with no mitigation and would pose a serious risk to the system safety. An information flow version of SW01 table 2 is presented below. The AEL reduction criteria are based upon the independence incorporated into the generation of the data and the originality or uniqueness of the system development to the designer / engineers involved in the system safety process. The scope of AEL reduction has been limited as it is felt that the benefit of independence and past experience / competence of individuals can only provide a limited amount of defence against data errors. Therefore a maximum reduction if information AEL that can be achieved is 3. Reduction of AEL

-1 -2 -3

Characteristic

Independence

Data is checked by same team but different individual or the originating team’s leader

Data is checked by different team but within the same organisation

Data is checked by a team from a different organisation

Novelty of application

Similar work on a different process system has been carried out by the organisation in the last two years

Similar work on a similar process system has been carried out by the same team in the last two years

Similar work on a similar process system has been carried out by this team immediately before this application

Table 19 Reduction of information flow AELs

of 94

Chapter 5 Conclusions and further work

5.1 Conclusions The system safety integrated model can be used to improve the efficiency of the work processes associated with the safety related areas of the chemical process industry. Utilising the integrated model would result in a more efficient system safety approach during the operational phases. This is because the traditional series lifecycle does not reflect the pattern of activities that are completed during this phase. The continuous interacting nature of the developed information model more closely imitates the operational activities. The model could also be made generic and so could be adapted for use in other industry sectors. This transformation to a generic model would most likely involve the translation of the information flow terminology rather than changes to the activities or components within the model. The structure of the model is relevant to system safety in many contexts. The integrated model has been reviewed against the operational activities of a chemicals facility. The feedback from this activity is that the integrated model closely matches the engineering activities of an operating process facility. It was felt that the traditional lifecycle representation of activities was more suited to project activities / new builds. The reason for this is that the traditional safety lifecycle can be compared to a project lifecycle. A full HazOp review of the complete integrated model would highlight the critical areas where the most serious errors in the information flows would occur. These errors should then be quantified and addressed. This may require an additional independent activity being carried out in parallel with the original activity. This is analogous to the concept of fault tolerance. If the failure of a link is critical then an addition channel can be used. Two information flows could be reviewed to detect failures. Of course to establish which flow was in error three channels should be used and a possible two out of three vote used as a check to determine the correct data path. It is felt that the cost involved would be excessive but this principle does highlight another benefit of the integrated model. For example, an inexperienced team assigning integrity levels could result in insufficient risk reduction being established. This quick review should allow management to allocate resources efficiently. The integrated model will allow information to be managed for the whole life of the facility. As the model is a continuous type model then information created during the early stages of design can enter the model and then this information can be re-used and kept updated as modifications are completed. Safety information must be available and managed so that it can be reused at anytime during the lifetime. In this respect the information model would form a valuable tool in the assurance of system safety compliance to standards, regulations and legislation.

of 94

The integrated model provides a straightforward assessment method of the impact that changes can have on the operating integrity of the process facility from a system safety perspective. By identifying the origin of a change then the integrated model can be used to trace the paths of impact throughout the model. By completing a change impact analysis then the changes can be planned and the potential effects of change can be assessed before the changes are implemented. The model itself becomes a tool, which will allow a change impact analysis to be completed. Change impact analysis can have great benefit in understanding the consequences of any changes. For changes that are intentional then change impact analysis can provide the evidence and justification of whether a change should be implemented. The model would also allow assessment of simultaneous change propagation throughout the system safety processes. Traditionally change impact analysis has been carried out manually but there are many automated change impact tools that are being developed for software. It is felt that the integrated model developed here could form the basis for automation of change impact analysis associated with system safety. The information model can also be an aid in the training of personnel unfamiliar with the system safety field. It is felt that by presenting the activities and information flows in this form then the safety assurance work process becomes almost self-explanatory. The additional of stakeholders to the model would further increase the effectiveness of the model as a training aid. The application of traditional failure analysis methods has been proven valid for use with information systems. A diverse approach to failure analysis has provided evidence that the model is reasonably complete and that each analysis method can be used in this context. The failure analysis of the information model using the HazOp and FFA techniques have identified a number of issues that have proven to present a risk to system safety. Overall, the developed information model has been shown to be a valuable tool in the management of system safety. Within the process industry sector the model will ensure that safety risk is maintained through improved information control and change impact assessment.

5.2 Further work The information model can be enhanced by the additional of other risk reduction technologies. A diverse range of risk reduction measures should be added to the model to provide a complete model with which to review safety implications. At present the model focuses solely on the risk reduction provided by a SIS, other risk reduction measures include relief valves, escape routes and bunding should be integrated into the information model. A completed assessment of the potential risk to system safety from information failures could then be completed. The volume of information required to complete an information link should be quantified to ensure sufficient resources are available to not only generate the data but also to be able to utilise the data when it is received as input to an activity.

of 94

The model should be subjected to a full case study. This would produce two evaluations: a. how well the model works, b. the improvement gained through the use of the model. Competency and training should be included within the model to maintain or ensure the effectiveness of staff. All of the components within the model rely upon the correct execution of each activity. If the competency of all individuals involved in the model can be assured then fewer failures in information would be experienced. The information flows within the model could be compared to the input and output channels to a safety system. If a critical failure could result in lost of function then the notation of fault tolerance could be introduced. The redundancy of information flows would provide some defence against data errors and failures. It could also be possible to estimate a common cause failure measure or beta factor for the information flows depending upon training and experience. Although an early assumption in the development was made not to include any feedback loops within an activity, it is felt that some activities should be expanded to show the detail of each. The models presented in section 2.22 have feedback loops that indicate the iterative nature of development work. For example, the SIF loop assessment activity within the developed information model could be represented at a micro level as shown below:

Figure 14 A micro view of the integrity level determination activity

An interactive web based model could provide links from the overall macro integrated model to more detailed micro activities within each activity. The information flows within these micro models should also be subjected to failure mode analysis as developed as part of this project.

of 94

References

Ref Title Author Location Publisher Year 1 Avoid Bad Engineering Practices in Safety Instrumented System

Design Summers A. E. INTECH 1999

2 www.hse.gov.uk 3 Explosions in gas-fired plant. Kay, D UK HSE Books 1997 4 Safeware, system safety and computers Leveson N.G. Addison Wesley 1995 5 COMAH regulations HSE UK HSE 6 COMAH SAFETY REPORT ASSESSMENT MANUAL HSE UK http://www.hse.gov.u

k/hid/land/comah2/ MARCH 2005

7 IEC 61508 – A Practical Approach to its application in the process industry

Charmock C. AMEC

8 An HSE field inspector’s perspective on IEC 61508 Madden, J UK HSE 9 HSE Board paper B/ 00/ 105 HSE 23

February 2000

10 Out of control HSE UK HSE BOOKS 1995 11 Functional safety of electrical/electronic/programmable

electronic safety-related systems - Part 4 : definitions and abbreviations

IEC 2002

12 Engineering safety management issue 3 Yellow book 3 London Railtrack 2000 13 Safety Management Tools and Techniques Houtermans M.J.M. The

Netherlands Risknowlogy 2004

14 The Role of safety Data in Safety-Related Systems Storey, N, Faulkner, A 15 IEC 62061 Safety of machinery Functional safety of safety-

related electrical, electronic and programmable electronic control systems

IEC 2005

16 61508 and 61511, What is an Operations Company Supposed to Do?

Scharpf E. 2004

of 94

17 Selection and use of engineering design methods using creative design methods

Lopez-Mesa B Germany Lulea University of technology

2003

18 The cost of accidents at work – HSE, HS(G)96, 1997, ISBN 0 7176 1343 7

19 Exploring Design Processes for Safety-Critical Systems Designed as Combinations of ‘Off The Shelf’ Solutions

Lopez-Mesa B. and Grante C.

Stockholm International Conference on Engineering Design

2003

20 BS EN 61511-2 Functional safety Safety instrumented systems for the process industry sector Part 2: Guidelines for the application of IEC 61511-1

IEC 2003

21 BS EN 61511-1 Functional safety Safety instrumented systems for the process industry sector Part 1: Framework, definitions, system, hardware and software requirements

IEC 2003

22 BS ISO 10303-1 Industrial automation systems and integration – Product data representation and exchange – Part 1: Overview and fundamental principles

British Standard 1999

23 Developing High Quality Data Models Matthew West UK European Process Industries STEP Technical Liaison Executive

1996

24 Data: An often-ignored component of safety-related systems

Storey, N, Faulkner, A

UK

25 State-of-the-art safety verification Scharpf E.W., Goble W. G. 2000 26 The Role of Data in Safety-Related Systems Storey, N, Faulkner, A

UK

27 Data — The Forgotten System Component? Storey, N, Faulkner, A

Journal of System Safety,

2003

28 Process Industries Data Handover Guide – Part 1 Sheila Lewis/Alan Thomson European Process 1998

of 94

Industries STEP Technical Liaison Executive

29 IEC 61355: Classification and Designation of Documents for Plants, Systems and Equipment

IEC 1997

30 Learning from incidents involving E/E/PE systems Part 1 - Review of methods and industry practice

PG Bishop, RE Bloomfield, LO Emmet C Johnson, W Black V Hamilton, K Koorneef

HSE 2003

31 The Future Systems Engineering Data Exchange Standard STEP AP-233: Sharing the results of the SEDRES Project

Johnson J, Luise F, Loeuillet J-L, Inderst M, Nilsson B, Torne A, Candy L, Harris D

32 ISO 10303- STEP A key standard for the global market Mason H. ISO 2002 33 Management of Oil & Gas Industry Data

http://www.posccaesar.com/Licyfim/licyfim-frameofreference-pistep-030123-v1.pdf

34 PIEBASE Activity Model Executive Summary 2005 35 Safety lifecycle management in the process industries Knegtering B Eindhoven CIP data Library 2002 36 How to use lifecycle models for Process Safety Management? Knegtering B., Rouvroye J. Honeywell 2002 37 Usability in Industry of Methods from Design Research Bylund N, Grante C, Lopez-

Mesa B. Stockholm International

Conference on Engineering Design

2003

38 AIRCRAFT COMPONENTS IMPACT ANALYSIS: STATE OF THE ART

Arnaud RIVIERE

VIVACE Consortium Members.

2004

39 Change and Customisation in Complex Engineering Domains,

C.M. Eckert, W. Zanker, P;J. Clarkson,

Research in Engineering Design (15)1,

2004

40 Domain Specific Dependencies Quan Li US THE UNIVERSITY OF CALGARY http://sern.ucalgary.c

1998

of 94

a/ 41 Change Management in Families of Safety-Critical Embedded

Systems Zo Rachael Stephenson UK University of York

2002

42 The Safety Management of Data-driven Safety-Related Systems Faulkner A.G., Bennett P.A., Pierce R.H., Johnston I.H.A., Storey N.

43 System safety : Hazop and Software Hazop Redmill, F,, Chudleigh M.,Ctmur, J.

UK Wiley 1999

44 A development of hazard analysis to aid software design Pumfrey, D.J and McDermid UK York University 45 Specification of Reliability for

Safety Related Systems on Process Plants

Jacklin, R UK Sheffield University

2002

46 SSA: System Safety Analysis , MSc SCSE module notes UK University of York

2003

47 Hierarchically Performed Hazard Origin and Propagation Studies

Papadopoulos Y., McDermid J.

Springer Verlag 1999

48 Strategies for the Management of Data-Intensive Safety-Related

Systems Storey, N, Faulkner, A

UK

49 CAP 670 Air Traffic Services Safety Requirements ISBN 0 11790 429 5

CAA UK CAA 2005

of 94

Appendix a the integrated Model Data Kinds The table below shows the process industry-engineering document types allocated to the relevant document kind as listed in 61508. Document name Document

kind Information flow as the developed integrated model which comprises of the document type

Explanation / notes

Process Flow Diagrams (PFDs)

Diagram 9.1 process details

Process and Instrument Diagrams (P&ID’s)

Diagram 9.1 Process details

Loop Diagrams Diagram 3.2 Loop architecture Single Line Diagrams (SLDs)


Cause and effect diagrams

Specification / diagram

3.3 Cause and effect chart

General Arrangements, plot plans for plant and buildings


Isometrics Diagrams 9.1 Process details Equipment Specifications

Specification 4.3 Reliability data

Equipment operating manuals

Installation, testing and commissioning procedures

Instruction 6.3 test regime

Study reports, including safety cases, philosophies, etc.

Report 9.3 Tolerable risk criteria 9.2 Hazard consequences 1.1 hazard log

Various Design calculations

Specification 3.1 test frequency 2.3 Integrity levels (if using LOPA)

Operating regime and procedures

Report & Instruction

4.2 Occupancy and vulnerability 4.1 Demand rate 9.4 maintenance interval

Maintenance procedures Instruction 3.1 Test frequency 6.5 test regime

Process data (i.e. design conditions typically shown on a process data sheet)

Specification 9.1 Process details

Equipment data (i.e. data typically shown on

Specification 2.2 Provisional SIF loop architecture

of 94

mechanical and instrument data sheets)


Process equipment data Specifications 9.2 Hazard consequences

List of safety related devices

List 1.1 hazard log 2.3 Integrity levels for hazards 3.3 Cause and effect charts

Manpower competencies

Report 8.1 Competency records

Manpower resource levels

Plan 9.1 Process details 4.2 Actual occupancy and vulnerability

Quality plan Plan All Equipment criticality ratings

Report 9.2 hazard consequences

Health and safety program

Description 2.3 Integrity levels for hazards 4.4 Incident reports 6.3 test regime

Hazop study Report 1.1 Hazard log Critical instrument list, List 3.3 Cause and effect chart FMEA, equipment failure information

Description 9.2 Hazard consequences 6.1 test failures

Hazardous area classification

Diagram 9.2 Hazard consequences

Design change control procedures and records

Instruction 5.2 Revised process details

Design deviation report Report 5.2 revised process details

of 94

Acknowledgements I would like to thank my project supervisor, Dr Mark Nicholson, for his guidance, help and encouragement throughout this project and the MSc. I would also like to express my appreciation and thanks to my wife Linda, without whose help, patience and support I could not have completed this course.

Integration Modelling of Process Industry Safety Initiativesmark/projects/dhm104_project.pdf• All...

Documents

Transcript of Integration Modelling of Process Industry Safety Initiativesmark/projects/dhm104_project.pdf• All...