Software Safety

There have been numerous accidents that were either induced by software errors or faults or software was a heavy contributor. Just a few examples from IEEE s Reliability Society 2009 Annual Technology Report (Wong et al 2009) are as follows  

Probably, one of the biggest nonevents (thankfully) was the year 2000 (Y2K) software scare that resulted in nothing. For those who may not remember, it was the fear that once we entered the Y2K, our industrial control systems would fail. The concern was that those industrial systems controlled by software or microprocessors that used formal dates as part of their operations would fail due to the hardware industrial system failing from the year changeover in 2000. Think about the industrial systems that we are dependent on electricity (not just to give us power but also to power our computer and software systems), clean water and water distribution, healthcare, ATM (cash dispense machines), air traffic control, pumping gas into your car, and millions of other everyday examples. Y2K did create a lot of fear and expense, which demonstrated how little we understood of our own industrial control systems. It also emphasized the importance of software safety and that software systems are used to control industrial systems, and we need to look at both to be sure that the industrial system operates safely. Today, the significant uptick in cyber attacks on industrial control systems further makes the point. 

And of course, accidents are much worse if created on purpose. We are now much more at risk of any type of accidents resulting from software-controlled systems because of our trend toward open, interconnected, and networked systems. Throw into that cloud computing and mobile technology (mobile devices are now very common in troubleshooting industrial systems), and we can see that software is much more important to safety today than just a few years ago. Probably, one of the best examples is the new trend in smart cities, putting an entire city s control under software and cyber systems. 

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  

Software itself is not a hazard. Software cannot be safe or unsafe. Like hardware, software can either support or mitigate a hazardous situation. Software and its systems are enablers to safe or unsafe conditions. 

---

Temperature measurement is achieved by means of a remote IR sensor beneath the lower outer surface of the vessels. The operation limit of the IR sensor is 400 °C, but it is regulated by the software safety features to 280 °C as the operation limits of the materials used are around 300 °C. For additional control, temperature measurement in a reference vessel by means of an immersed gas-balloon thermometer is available. The operational limit of this temperature probe is 310 °C, making it suitable for reactions under extreme temperature and pressure conditions. 

Human expertise in complex systems is constantly changing and a New Paradigm for software safety assurance is considered. As the development of Safety Critical Systems is guided by standards, the standards are to be updated3. In what follows we present a general view of how the development of safe software systems is currently practiced and show two specific solutions aimed at efficient support of the efforts. Responsibility of organizations, processes and culture, not just efforts of specific members of the organizations, is emphasized. 

An evidence-based approach, without precluding the use of existing standards, is defended by [R. A. Weaver, (2003)], where arguments to reflect the contribution of software to system safety are required. The software safety arguments are based on categorization of evidence, which is largely independent of the development process. 

Wingate, G.A.S., Smith, M., and Lucas, P.R. (1995), Assuring Confidence in Pharmaceutical Software, Safety and Reliability of Software Based Systems, First Annual ENCRESS Conference, Bruges, Belgium, September. 

Engineering controls (hardware, software, safety interlocks) have been added to control automated loading, firing, and product gas cleanup. 

Schoitsch, Erwin "Software Safety and Software Quality Assurance in Real Time Applications". Computer Physics Communications, 50 (1988) 169-211. 

The criteria 1 to 8 may be reduced, especially those requiring full application of lEC 60880. Quality assurance shall divide the development and the modification phases of the software safety life cycle into specified activities. These activities shall include all what is necessary to achieve the required software quality, to verify that this quality is achieved, and to provide objective evidence to that effect. ... 

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. 

Prior to development of the application software, the user provides a process risk and hazard assessment which is used to identify the software safety requirements in terms of the safety instrumented functions and their SIL. Once the decision to implement the safety instrumented functions in software is made, any conflicts, discrepancies and omissions in the safety requirements specification which come to the attention of the software designers should be addressed. One example might be the effect of the order of execution of the safety instrumented functions within the software. Another example would be the response of the application software as it relates to energy outages. 

The application software safety requirements should be developed as a traceable response to the SIF safety requirements specification. Factors to be addressed include ... 

Determine the proper execution order of the networks and logic, within each program and the execution sequence and desired execution rates of all the application programs. Confirm that the execution rates of the application programs are consistent with the required process response times from the software safety requirements specification. 

The application software safety requirements specification will include ... 

In this step, all functions of the safety requirements specification are allocated to system components, functions or software. Safety integrity requirements will determine the appropriate... 

Non-module Equipment Instruments, Hardware and Software Safety Protection Safety Protection Cabinets... 

Software System Safety Handbook, 2010. Joint Services Computer Resources Management Group U.S. Navy, U.S. Army, and the U.S. Air Force, Joint Services Software Safety Committee, Joint Services System Safety Panel. Electronic Industries Association, G-48 Committee. https //acc.dau.miPCommunityBrowser.aspx id=683698. 

Principles of the AOP 52 draft on software safety for the ammunition domain... 

ABSTRACT The draft document of the NATO allied ordnance publication (AOP) 52 gives guidance on software safety design and assessment of ammunition-related computing systems. The content of the draft is reviewed and compared with the lEC 61508 standard for functional safety of electrical/electronic/programmable electronic (E/E/PE) systems. We discuss the overall development model, the safety-lifecycle model and proposed techniques and measures. We also investigate whether the functional safety concept of lEC 61508 is incorporated in the document. 

The AOP 52 uses in chapter 3 the software safety criticality index (SSCI) to determine the level of rigor that is necessary for testing and analysis that has to be performed by the software and safety development team. It also dictates the level of scrutiny that is necessary during requirements definition, design implementation and validation of safety-related requirements. 

NATO. 2007. Guidance on Software Safety Design and Assessment of Munition-Related Computing Systems. 

Safety instrumented systems (SIS) play a major part in industrial risk management as risk reduction measures. The main European standard for functional safety of SIS, denoted electrical / electronic / programmable electronic (E/E/PE) safety-related systems, is the EC 61508 (lEC, 2005a). The second edition will soon be adopted in 2009 (EC, 2009). Objectives are to enable the design of SIS, and the development of apphca-tion sector standards. Such examples are EC 61511 (lEC, 2004) for process industry, and EC 62061 (EC 2005b) for machinery. One of the main contributions of EC 61508 is to consider the overall system and software safety life cycle. The standard fi amework, with the corresponding normative parts and subclauses, is ... 

Williamson, G. 1997. Software safety and reliability. IEEE Potentials 16 (4) 32-36. 

As we progress into the new century there are both opportunities and challenges. Qpportunities present themselves in the form of (1) the potential of integrating system software safety with control engineering to more closely achieve a level of intrinsic safety and (2) the proliferation of system safety as a discipline in other parts of the world. The challenges we face include the... 

Finally, there is a general lack of expertise in the area of software system safety. Not only are there grossly insufficient numbers of qualified system safety engineers with software safety credentials but also very few recognized textbooks, seminars, university programs, or competent consultants are available. The lack of technical competence in this area seems to span the entire system safety community. 

The specification of the requirements for (apphcation) software safety for each subsystem is derived from ... 

---