Software Safety Analysis

The safety management system discussed in Chapter 4 presents the need to include all aspects of system operations in the safety process. Software use and control is no exception. A software safety program should be an integral part of the system safety program. In fact, it would be dangerous to segregate software safety from the rest of the safety process. 

One of the most important software safety standards is the International Electrotechnical Commission lEC 61508, Functional Safety of Electrical/ Electronic/Programmable Electronic Safety-Related Systems. It applies to all industries that use safety-critical systems that are electronically or software controlled. It uses safety processes described in Chapter 4 and in other safety analysis 

Software requirements development As with all requirements development, software requirements development is performed early in the system s requirement phase. Requirements should be written that force the software developer to examine the system and identify any software commands that could cause the system to 

Top-level systems hazards analysis A system-level software safety analysis is conducted at this level. Safety-critical software is identified. Each software functional module is evaluated for hazards. 

Detailed design hazard analysis The software safety analysis is performed at the level of databases, files, and other algorithms. 

---

Software safety analysis reports are prepared by the software safety engineers of software design team based on IEEE 1228-1994 standard requirements in each software development phase. These reports are reviewed by the IV V teams. 

Reviewing internal V V reports, acquired software evaluation reports, software safety analysis reports, and Eaton s V V summary reports. 

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. 

An excellent reference source on the current developments in software safety analysis. Their publication. Computing Machinery, often features articles from top industry leaders on the subject of software safety. 

Y. Oh, J. Yoo, S. Cha, H.S. Son, Software safety analysis of function block diagrams using fault trees. Reliability Engineering and System Safety Elsevier (2005). www.sciencedirect.com. 

Software safety analysis is a very new technique, but it also has promise for nuclear plants. Much of plant processes are computer controlled, yet until recently, little attention has been given to spurious commanding or sneak paths in the commanding. Software safety tools could help identify these problems and offer solutions. 

A software safety analysis must be conducted whenever software is used to... 

Numerous software safety analysis tools are available. When you start to look at the large variety, you will quickly become overwhelmed. Remember that software safety analysis techniques are either top-down (from the systems level to the code level) or bottom-up (from the code level back up to the level of consequences on the system). Also, the various safety analysis techniques are more useful and applicable at particular levels of software development. 

Nothing has been said so far about the independent verification and validation (IV V) organization. Many feel that by virtue of having an IV V, the software systems will be safe. But as you can see, if the various levels of software safety analysis are not conducted, then the IV V activity will be meaningless. 

Shimeall, T. J., McGraw, R. J., and GUI, J. A. 1991. Software safety analysis in heterogeneous multiprocessor control systems. Proceedings Annual Reliability and Maintainability... 

Sneak circuit analysis is usually performed with complex computer codes and is very expensive. It only becomes cost-effective on subsystems that are safety critical, such as an aircraft control system. Obviously, sneak circuit analysis should be teamed with the software safety analysis tools discussed in Chapter 8. This is a very powerful combination, but not cheap, certainly, very important for the most safety-critical circuits of very high-risk systems. 

Keywrords STPA approach, software safety analysis, temporal logic, safety verification, formal verification methods. 

Fenelon, P. J. McDermid (1992). Integrated techniques for software safety analysis. lEE Colloquium on Hazard Analysis, 2/1-216. 

Fenelon, P., McDermid, J.A. An integrated toolset for software safety analysis. The Journal of Systems and Software 21(3), 279-290 (1993)... 

One important point is doing the Software Safety Analysis as part of the overall System Safety Assessment, and not as an independent task. During the FHA critical system functions and system hazards are identified and subsequently broken down to the hardware and software level. Based on the software architecture, potential software faults which might contribute to the system hazards are detected during the Software Safety Analysis. The results of the Software Safety Analysis must be considered at the system level as well. Thus, the Software Safety Analysis is an integrated element of the System Safety Assessment. 

Software safety analysis is another area where further study is required. In recent years, advances in computer technology have been increasingly used to fulfil control tasks to reduce human error and to provide operators with a better working environment in ships. This has resulted in the development of more and more software intensive systems. However, the utilisation of software in control system has introduced new failure modes and created problems in the development of safety-critical systems. The DCR-1996 has dealt with this issue in the UK offshore industry. In formal ship safety assessment, every safety-eritical system also needs to be investigated to make sure that it is impossible or extremely unlikely that its behaviour will lead to a catastrophic failure of the system and also to provide evidence for both the developers and the assessment authorities that the risk associated with the software is acceptable within the overall system risks (Wang (1997)). 

---