Software hazard analysis system hazards

Based on the results of the PHA, recommendations made by 30% review boards, and guidance provided in the system safety program plan, detailed hazard analyses are made of specified (critical) subsystems. The techniques for these SSHAs are as outlined in the system safety program plan or as selected by the SSWG. Failure modes and effects analysis (FMEA) and/or fault tree analysis (FTA) are generally the techniques of choice. Software hazard analysis, common cause analysis, and/or sneak circuit analysis may also be appropriate. 

Software hazard analysis is extremely important and will be of growing importance in the future. The software hazard analysis effort should parallel the system safety program for system hardware, be a life cycle effort, and use a combination of methods and approaches. 

To illustrate this point, this chapter addresses two system safety analytical methods that have been developed as a result technological improvements the sneak circuit analysis and the software hazard analysis. Each is briefly discussed here to demonstrate its applicability and utility in the practice of industrial safety and health. 

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 hazard analysis (SWHA) is a system safety analytical technique whose primary function is to systematically evaluate any potential faults in operating system and applications software requirements, codes, and programs as they may affect overall system operation. The purpose of the SWHA is to ensure that safety specifications and related operational requirements are accurately and consistently translated into computer software programs. In this regard, the analysis will verify that specific operational safety criteria, such as failsafe or fail-passive, have been properly assimilated into operational software. The SWHA will also identify and analyze those computer software programs, routines, or functions that may have direct control over or indirect influence on the safe operation of a given system. Also, in the operation of the computer software command function, there is a potential that the actual coded software may cause identified hazardous conditions to occur or inhibit a desired function, thereby creating additional hazard potential. 

SHOLIS (Chapman, 2000) is a software-based system that advises ship s crew on the safety of helicopter operations under various scenarios. The software was developed in accordance with DEF STAN 00-55 (Issue 2). A software hazard analysis was performed and on this basis certain parts of the software were designated as safety-critical. Safety critical software was formally specified using Z, developed in Spark Ada, and a partial correctness performed of the code against the specification. Information Flow analysis was used to demonstrate functional separation of critical and non-critical software. Freedom from run-time exceptions was demonstrated for all code. Static analysis of I/O usage, memory and timing was used to show separation of non-functional properties. Finally, proof that the system s top-level safety properties were maintained by the software was carried out. 

Software Hazard Analysis A system safety analytical technique whose function is to evaluate potential faults in both operating system and applications software requirements, codes, and programs as they may effect overall system operation. 

There are numerous software safety tools on the market, some quite good. And you can even take some of our current tools and use them for analyzing software systems. The most common ones are software hazard analysis, software fault tree analysis, and software FMECA. These are good starts, but insufficient to do the job completely. However, before you can attack the problem of software safety, a few facts should be stated first ... 

Architectural design analysis Once the requirements phase has been completed, the software team passes on to the top-level systems design. As the design is laid out, the criticality analysis tracking system is updated with the new, more detailed information. This is performed primarily through software hazard analysis. Another tool is software FMEA. 

The handbook additionally provides an extensive overview and comparison of commercially available computer systems and software for chemical emergency planning. This section provides technical guidance for hazard analysis and identification implementing regulatory requirements and descriptions of computer applications and systems applicable under SARA Title III. 

May 1996 FDA 483 Failure to identify and analyze the system/software critical functions. No documented risk assessment and hazard analysis was done. .. ... 

The most widely used existing hazard analysis techniques were developed fifty years ago and have serious limitations in their applicability to today s more complex, software-intensive, sociotechnical systems. This chapter describes a new approach to hazard analysis, based on the STAMP causality model, called STPA (System-Theoretic Process Analysis). 

Software need not be treated any differently than the other parts of the system. Most safety-related software problems stem from requirements flaws. The system requirements and system hazard analysis should be used to determine the behavioral safety constraints that must be enforced on software behavior and that the software must enforce on the controlled system. Once that is accomplished, those requirements and constraints are passed to the software developers (through the black-box requirements specifications), and they use them to generate and validate their designs just as the hardware developers do. 

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. 

The digital safety systems were developed and installed to Kashiwazaki-Kariwa Unit 6 and 7 for the first time in Japan, based on these over 10 years experience of digitization of I C systems. In the development and application process of the digital safety systems, the methodology to prove its reliability were discussed such as QA/QC including V V procedures, the hazard analysis described in this paper etc.. The hazard analysis was performed in order to fully re-evaluate reliability of the digital safety systems. The results of the hazard analysis by FTA shows that the hazards latent in the software lifecycle, were extracted and verified completely. In this paper, the policies for application of the digital safety system are described to enhance its reliability. 

After the PHA is complete, first subsystem hazard analysis (SSHA) and, if required, system hazard analysis (SHA) are performed. Depending on the nature and complexity of the end product and the results of the PHA, SSHAs may be performed on all subsystems or just on selected critical subsystems. Unlike MIL-STD-882B, software analyses are not generally identified separately. If applicable, preliminary software hazard analysis is part of the PHA. Software should be treated as a subsystem and, if further software analysis is required, an SSHA can be performed on the software. 

The recommended techniques for preliminary hazard analysis are energy trace and barrier analysis (ETBA) and failure modes and effects analysis (FMEA). Recommended techniques for system and subsystem hazard analyses are FMEA, fault tree analysis (FTA), common cause analysis, sneak circuit analysis (for electrical, electronic, and some hydraulic or pneumatic circuits) and, of course, software hazard analysis for software. 

Hazard analysis The functions, steps, and criteria for design and plan of work, which identify hazards, provide measures to reduce the probability and severity potentials, identify residual risks, and provide alternative methods of further control (SSDC) a process of examining a system, design, or operation to discover inherent hazards, characterizing them as to level of risk and identifying risk-reduction alternatives (APR 800-16) the determination of potential sources of danger and recommended resolutions in a timely manner for those conditions found in either the hardware/software systems, the person-machine relationship, or both, which cause loss of personnel capability, loss of system, or loss of life or injury to the public (NSTS 22254). 

Subsystem hazard analysis (SSHA) As described in NHB 1700.1 (Vl-A) and this document. The SSHA is to identify hazards to personnel, vehicle and other systems caused by loss of function, energy source, hardware failures, personnel action or inaction, software deficiencies, interactions of components within the subsystem, inherent design characteristics such as sharp edges, and incompatible materials, and environmental conditions such as radiation and sand (NSTS 22254). 

Elahi, B. J., Safety and Hazard Analysis for Software-Controlled Medical Devices, Proceedings of the 6th Annual IEEE Symposium on Computer-Based Medical Systems, 1993, pp. 10-15. 

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. 

Software Fault Hazard Analysis Similar in concept and structure to the system hazard analysis (SHA), which is conducted on system hardware, the software fault hazard analysis will analyze and evaluate a computer software program to identify critical areas in the programming that may contribute to or directly cause a hazard risk. Such risks may be due to an undetected hardware failure or incorrect inputs into the operation of the system software. The software FHA will also attempt to uncover any probable errors that can possible develop in the software after system activation. 

---