Software hazard analysis

Software Hazard Analysis, or SWHA, is a system safety analytical technique whose primary function is to systematically evaluate any potential faults in both operating system and applications software requirements, codes, and programs as they may effect 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 fail-safe or fail-passive, have been properly assimilated into operational software. The SWHA will also identify and analyze those computer software programs, routines, or functions which 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. 

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. 

The analysis effort for software should address both software requirements and the software codes and programs. Both operating system and applications software should be included. 

Unfortunately, the state of the art in software hazard analysis appears to be woefully lagging. Even though traditional hazard analysis techniques like fault tree analysis and tailored versions of operating hazard analysis may be applied to the evaluation of software, validated, specific methods of software hazard analysis appear lacking. 

Ironically, the most promising methods of analyzing software are software packages specifically designed to perform software hazard analyses and diagnostic features built into critical software programs. 

System Safely for the 21 Century The Updated and Revised Edition of System Safety 2000, by Richard A. Stephans 

---

Task section 100—program management and control Task section 200—design and evaluation Task section 300—software hazard analysis... 

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. 

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. 

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. 

The system safety analysis techniques known separately as sneak circuit analysis and software safety analysis have been developed in an effort to address these concerns over system safety and reliability assurance. Although various types of sneak hazards can be identified by analysis, and a variety of software hazard analysis techniques are commonly used, each method is concerned primarily with the same essential objective explained throughout this text hazard risk elimination or reduction to acceptable levels. 

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. 

---