Human Factors, and Software Safety

The business of every art is to bring something into existence. 

Know then thyself, presume not God to scan, the proper study of Mankind is Man. 

Three nonsafety tools are used in safety analysis failure modes, effects, and criticality analysis (FMECA) human factors analysis and software analysis. Because these techniques are extremely helpful in finding eqnipment failures, human errors, and software mistakes, safety engineers have coupled them to their safety analyses. It is definitely worthwhile to understand how these tools can benefit you. 

---

Where loss of control could lead to severe consequences, the integrity of the basic process control system and the protective safeguards must be designed, operated and maintained to a high standard. Industry standards such as ANSI/ISA-S84.01 (1996) and IEC 61508 (2000) address the issues of how to design, operate and maintain safety instrumented systems such as high temperature interlocks to achieve the necessary level of functional safety. The scope of these standards includes hardware, software, human factors and management (HSE 2000). 

It specifies system architecture, hardware configuration, application software (user and integrator of SIS), and system integration, requirements for safety instmment functions (SIFs) including human factor, and safety life cycle. It also specifies the techniques and measures for SIL. 

HAZOP and wAat-iJ/safety checklists, two of the most common safety methods in the chemical industry, are explained. Sample process problems, which engineers face every day at work, are shown. Other safety tools, such as fault tree analysis, failure modes and effects analysis, human factors safety analysis, and software safety, are explained. Examples of the use of these tools are also presented. 

Abstract Competence plays an important role in ensuring functional safety. Safety-related systems rely on a complex mix of hardware, software, human factors and safety management systems. This paper takes a look at the requirements for such a Competence Management System, and gives information on a practical approach to competence implemented by Invensys Rail (UK). 

Vilkomir S.A., Kharchenko V.S. An "Asymmetric" Approach to the Assessment of Safety -Critical Software During Sertification and Licensing// Proceeding of the ESCOM - SCOPE 2000 Conference "PROJECT CONTROL THE HUMAN FACTOR", Munich, Germany, 18-20 April, 2000, pp. 467-475. 

Section 3.6 Synthesis. Includes the approach and methods to transform the fimctional architecmre into a design architecture (hardware, software, and humans to support the system life cycle), to define alternative system concepts, to define physical interfaces, and to select preferred product and process solutions. Describes how requirements are eonverted into detailed design specifications for hardware, software, human engineering, manpower, personnel, safety, training, and interfaces. Approaches and methods for the engineering areas, quahty factors, and engineering specialty areas in Section 3.2 are also defined. In addition, nondevelopmental items and parts control are included. 

Reliability and Safety Data Collection and Analysis Fault Identification and Diagnostics Maintenance Modelling and Optimisation Structural Reliability and Design Codes Software Reliability Consequence Modelling Uncertainty and Sensitivity Analysis Safety Culture Organizational Learning Human Factors... 

The issue related to this UML modeling tools is that its usage for Human Factors Practitioners and Safety analysts is not so immediate because it is meant to be used primarily by software developers. Furthermore no support is provided for guiding the task analysis interview process. 

At the 1993 International System Safety Conference, the then Chief of Air Force Safety in his keynote presentation said that the two challenges for the 90s were in software system safety and in human factors. This was true then, and it is today, more than ten years later. 

In the absence of a holistic approach to system safety assessment, it is tempting to concentrate safety assessment effort on what we understand or think we understand (such as hardware and software) and to adopt a head in the sand approach to the human factors which are often perceived as too difficult. Humans are often the major causal factor for hazards in safety-related systems (Sandom 2002) and yet human failures often don t receive proportionate attention in safety analyses. On the other hand, human operators also often provide substantial mitigation between... 

An important feature of Figure 7 is that the high-level design must take into consideration the human factors in the initial allocation of Safety Functions. Too often, this decision is based upon technical csqiability and the human is allocated whatever functionality can t be implemented in hardware or software, regardless of the suitability of the human to undertake the resultant tasks. 

The process for the specification of human subsystem safety requirements is no different to software or hardware although it is ai uably considerably harder due to the difficulties associated with the immense scope and variety of issues affecting the reliable performance of human tasks. This paper has examined issues relating to the consideration of human subsystem safety and has outlined the scope and activities necessary for a comprehensive human factors safety analysis. A pragmatic method was introduced that advocates the application of focused Human Factors techniques to the assurance of safety for human subsystems. 

The relative difficulties associated with the specification, implementation, validation and verification of human safety requirements, compared with safety requirements for hardware and software, should not be underestimated and this paper has not addressed many of these difficulties in detail. However, this paper has outlined a high-level approach for a focused and integrated application of Human Factors analyses for the specification and realisation of human subsystem safety requirements. 

Fault Tree Analysis (FTA) is a well known and widely used safety tool, implementing a deductive, top down approach. It starts with a top level hazard, which has to be known in advance and "works the way down" through all causal factors of this hazard, combined with Boolean Logic (mainly AND and OR gates). It can consider hardware, software and human errors and identifies both single and multiple points of failure. Both a quantitative and qualitative analysis is possible. 

One last transformation of the hazard analysis technique that is worth investigating is the operations and support hazard analysis (O SH A). Most hazard analyses (and safety analyses, in general) are directed toward uncovering hardware design problems however, this is not the intent of an O SHA. Simply put, an O SHA identifies and evaluates the hazards associated with the operations of a system. As with all hazard analyses, it looks at hardware systems, software, facilities, support equipment, procedures, personnel, operating environment, natural environment, human-machine interfaces, and other interfaces, but with the telling difference of how all of these factors relate to the operation of the system by people. The O SHA is a very useful technique to understand how operations-focused hazards impact the system. It is not a human factors analysis. See Chapter 8 for more on human factors analysis. 

Chapters 5 through 9 describe the different safety analysis tools available. Hazard Analysis, H AZOF, What-If, Fault Tree Analysis, Failure Modes, and Effects Analysis, Human Factors, Software Safety, and other safety tools are described with realistic worked examples. The chapters detail how to use them, give examples, describe common mistakes in using them, and also provide best practices and tips of how to apply them judiciously. 

A Hohstic approach to the analysis is the second principle. From a systems perspective, safety is an emerging properly of a system. When analysing the system, all elements of said system must be taken into consideration (software, hardware, human factors, socio-political influences and envirorunental issues, to mention some) throughout the life... 

---