Interface hazards analysis

Ensure that links with other hazards analyses are established. On a large facility, a single analysis usually covers only a relatively small fraction of the total process. Therefore, it is important to make sure that the connections between the different processes are properly analyzed, particularly with regard to plant utilities. [The important and difficult topic of Interface Hazards Analysis (IHA) is discussed later in this chapter.]... 

The effect of changes such as this can be analyzed using an Interface Hazards Analysis. 

Analyses are types of calculations but may be comparative studies, predictions, and estimations. Examples are stress analysis, reliability analysis, hazard analysis. Analyses are often performed to detect whether the design has any inherent modes of failure and to predict the probability of occurrence. The analyses assist in design improvement and the prevention of failure, hazard, deterioration, and other adverse conditions. Analyses may need to be conducted as the end-use conditions may not be reproducible in the factory. Assumptions may need to be made about the interfaces, the environment, the actions of users, etc. and analysis of such conditions assists in determining characteristics as well as verifying the inherent characteristics. (See also in Part 2 Chapter 14 under Detecting design weaknesses.)... 

Level 2 System Principles External interfaces Task analyses Task allocation Controls, displays Logic principles, control laws, functional decomposition and allocation Validation plan and results, System Hazard Analysis... 

Level 3 Blackbox Models Environment models Operator Task models HCI models Blackbox functional models Interface specifications Analysis plans and results. Subsystem Hazard Analysis... 

The first step in the acceptance process is the identification of the environment within which the pre-developed software will have to work. This environment is determined by the system-level safety function as described in the system requirements specification. Also the interface and performance requirements, as well as the safety category should be contained in the system requirements specification. This means, that during the establishment of the plant safety design base a risk and hazards analysis has been performed which rendered the categories of safety functions to be implemented by pre-developed software. This risk and hazard analysis - in spite of being out of the scope of I C engineering - has been taken as the first of four acceptance criteria that should be applied to pre-developed software independently of its safety category. 

One of the most valuable features of hazards analysis is that it brings together people with different skills and backgrounds this can lead to very fruitful brainstorming. It can also help flush out potentially hazardous assumptions, particularly at departmental interfaces. ( I thought that your department handled that. Oh really, I thought your people were taking care of it )... 

Most hazards analyses review a subset of a larger system. For example, a refinery hazards analysis team may carry out a hazards analysis on just the catalytic cracking unit, a pipeline company may analyze just the marine loading operations, or an offshore team may analyze just one platform in a larger complex. Yet these subsystems are part of larger systems, which means that hazards can be transferred to or from the other units across the interfaces. 

Again the process involves a preliminary hazard analysis to be done very early in the concept stage, followed by subsystem hazard analysis as subsystems are developed, systems hazard analysis that looks at interfaces between subsystems, and, finally, the operating hazard analysis, which tends to add the human element and evaluate procedures. 

Hazard identification is continued throughout the design stage and documented in the preliminary hazard analysis (PHA), subsystem hazard analysis (SSHA), and the system hazard analysis (SHA). Even though the primary purpose of these products is to analyze previously identified hazards and to determine the adequacy of controls, every effort should be made to continue to identify new hazards, especially those associated with interfaces and changes. 

The operating hazard analysis (OHA) is normally started and sometimes completed during this phase, even though, if adequate information is available, the OHA may be initiated in the design phase. Hazards associated with the human interface and with operating and maintenance procedures should be identified at this time. Project evaluation tree (PET) analysis is the preferred technique for performing OHAs. 

In all cases, a very important analysis and control effort should be initiated and, if sufficient data are available, completed during the production phase. The operating hazard analysis (OHA) focuses on the human interface with the end product. It examines the adequacy of maintenance and operating procedures and instructions and, if appropriate, the adequacy of the organization and training of maintenance and operations personnel. The recommended technique for completing the OHA is the project evaluation tree (PET) analysis. 

The operating hazard analysis (OHA) analyzes hazards associated with the maintenance and operation of the system, with emphasis on human factors, training and procedures, and the person-machine interface. The OHA is sometimes called the O SHA (operating and support hazard analysis). 

Chapter 3 presents introductory aspects of safety and human factors. Chapter 4 is devoted to methods considered useful to perform patient safety analysis. These methods include failure modes and effect analysis (FMEA), fault tree analysis (FTA), root cause analysis (RCA), hazard and operability analysis (HAZOP), six sigma methodology, preliminary hazard analysis (PFfA), interface safety analysis (ISA), and job safety analysis (JSA). Patient safety basics are presented in Chapter 5. This chapter covers such topics as patient safety goals, causes of patient injuries, patient safety culture, factors contributing to pahent safety culture, safe practices for better health care, and patient safety indicators and their selection. 

The second and more common hardware FMEA examines actual system assemblies, subassemblies, individual components, and other related system hardware. This analysis should also be performed at the earliest possible phase in the product or system life cycle. Just as subsystems can fail with potentially disastrous effects, so can the individual hardware and components that make up those subsystems. As with the functional FMEA, the hardware FMEA evaluates the reliability of the system design. It attempts to identify single-point failures, as well as all other potential failures, within a system that could possibly result in failure of that system. Because the FMEA can accurately identify critical failure items within a system, it can also be useful in the development of the preliminary hazard analysis and the operating and support hazard analysis (Stephenson 1991). It should be noted that FMEA use in the development of the O SHA might be somewhat limited, depending on the system, because the FMEA does not typically consider the ergonomic element. Other possible disadvantages of the FMEA include its purposefiil omission of multiple-failure analysis within a system, as well as its failure to evaluate any operational interface. Also, in order to properly quantify the results, a FMEA requires consideration and evaluation of any known component failure rates and/or other similar data. These data often prove difficult to locate, obtain, and verify (Stephenson 1991). 

Although software hazard analysis is a separate system safety teclmique and is discussed later in this chapter as such, a review of compiler and/or assembly languages as well as any applicable system reference manuals and interface control specifications is advisable during the SCA. Sneak risks have been discovered as a result of improper or inappropriate software command initiatives. 

Software Preliminary Hazard Analysis This type of analysis is used to identify software program routines that are considered to be safety-critical, and thus is conducted prior to software program coding. To perform the analysis, the analyst should make reference to any available system specifications, interface documentation, functional flow diagrams, software flowcharts, storage and file allocation specifications, and any other program descriptive information. 

It is common practice to identify the hazard control and follow up action as a part of hazard identification and preliminary hazard analysis (discussed in detail in the next chapter). In order to control hazard, one has to look for safety interfaces also. So, the following points need to form a part of initial hazard study especially for industrial or process plants, so that entire spectrum is well-covered ... 

A system is a part of the universe within a certain domain in space and time. What is an environment Outside the frontier of the system is the environment [1], Here, system shall have an identity, that is, deterministic. There shall be an external boundary to the system. An external boundary is determined by what aspect of system performance is of concern. This is stated here because for quantitative hazard analysis, boundary definition is extremely important. Also, the interface part needs to be considered (See Fig. V/3.0-l). The process definition for qualitative risk analysis is Qualitative Risk Analysis assesses the priority of identified risks using their probability of occurring, the corresponding impact [...] as well as other factors such as the time frame and risk tolerance [..On the contrary, quantitative risk analysis (QRA) as per DNV is Typically, a QRA can be defined as the formal and systematic approach of identifying potentially hazardous events, estimating the likelihood and consequences of those events, and expressing the results as risk to people, the environment or the husiness. ... 

The scope definition section requires the definition of the boundary of the process and equipment under control being assessed, together with its control system. Since in the majority of cases the input to LOPA is taken from preliminary hazard analysis or HAZOP, the scope is more or less otherwise developed from previous analysis. It is necessary to ensure that equipment under control and its environment are sufficiently understood along with scope and boundary including interface before detailed assessment commences. 

Operating and Support Hazard Analysis A system safety analytical technique (also know as the operational hazard analysis) which focuses primarily on the hazards associated with or caused/enhanced by the human/task interface of system operations. 

A system hazard analysis (SHA) does the same thing as an SSHA except that it identifies hazards across subsystem boundaries and interfaces. It looks at system-level hazards. An SHA also should list hazard controls and verifications. 

---