Does Software Have to Be Ultra Reliable in Safety Critical Systems?

Issues in developing software for safety critical systems

The failure of such systems leads to the catastrophic effects, including injury or death to humans, and harm to the environment. Petri nets (PNs) have been widely used for verification and validation of real-time systems. However, the existing approaches do not consider the critical aspects of reliability and safety that include nonliveness, deadlock, stability, and throughput. In this paper, we introduce these as metrics of reliability and safety for safety critical real-time systems. This paper also proposes an innovative methodology for analysis of nonliveness, deadlock, stability, and throughput metrics by linear programming using PN modeling. The application of the proposed techniques has been validated by applying it on four different safety critical systems, running in six nuclear power plants and shown for reactor protection system.

Validation and Verification are necessary in the life cycle of any safety-critical software system. It answers the question of “are we building the right product?” It's very important to be able to decide if its outputs are correct and system meets specifications, failing to do so can result in loss of human lives or huge financial loss. V&V process and its planning must start early in SDLC (Software Development Life Cycle). Both aspects are essential, If specifications are met that doesn't mean it's correct and vice versa. There are different V&V techniques available for different stages of the SDLC. In this paper I will analyze different V&V techniques available for critical software systems and will conduct a survey, which will produce results showing which techniques are best for safety-critical software systems.

Two factors influencing the design and development of avionics software are: (1) the cost of verification, validation and certification; (2) migration of avionics functionality from hardware to software, to decrease the weight and power consumption of the avionics. These two factors are inherently at odds. Lowering the development costs of engineering software for safety critical systems, while providing the abstractions necessary to build systems of ever increasing complexity, is key to achieving these two goals. Middleware seems to be the ideal vehicle to reach these goals. Middleware is used to isolate the core application from the underlying distributed system and is constructed using object-oriented techniques. This has the benefit of increasing software reuse and minimizing the code that is verified to various safety criticality levels when the underlying system microprocessor and network are changed. The middleware that meets the criteria placed on safety critical software is faced with many challenges.

Ontario Hydro has had experience in designing and qualifying safety critical software used in the reactor shutdown systems of its nuclear generating stations. During software design, an analysis of system level hazards and potential hardware failure effects provide input to determining what safeguards will be needed. One form of safeguard, called software self checks, continually monitor the health of the computer on line. The design of self checks usually is a trade off between the amount of computing resources required, the software complexity, and the level of safeguarding provided. As part of the software verification activity, a software hazards analysis is performed, which identifies any failure modes that could lead to the software causing an unsafe state, and which recommends changes to mitigate that potential. These recommendations may involve a re-structuring of the software to be more resistant to failure, or the introduction of other safeguarding measures. This paper discusses how Ontario Hydro has implemented these aspects of software design and verification into safety critical software used in reactor shutdown systems. >

We live in a world in which our safety depends on software-intensive systems. This is the case for the aeronautic, automotive, medical, nuclear, and railway sectors as well as many more. Organizations everywhere are struggling to find cost-effective methods to deal with the enormous increase in size and complexity of these systems, while simultaneously respecting the need to ensure their safety. Consequently, we're witnessing the ad hoc emergence of a renewed discipline of safety-critical software systems development as a broad range of software engineering methods, tools, and frameworks are revisited from a safety-related perspective. The rise of these complex, critical systems has spawned several recent initiatives to promote reuse, both of the technical artifacts and the artifacts and procedures that certify their suitability for use in safety-related contexts. One unmistakable trend is a strong interest in applying model-driven engineering techniques to safety-critical systems development over the entire life cycle.

Purpose The purpose of this study is to provide a method for designing the software for a process control system that avoids difficulties that lead to safety problems. Design/methodology/approach Design of real-time software for safety critical programmable equipment systems (PES) such as process control or shutdown systems needs to be approached quite differently compared to any other software. It must be designed by those who understand the equipment system not by software engineers who do not. Following the ‘Piper Alpha’ disaster in the North Sea in the late 1980s, it was realised that the software of safety critical PES, such as the shut-down system on an oil rig, was proving very unreliable. Earlier hardwired relay-based shut-down systems were designed by process control engineers who understood the functions the equipment was required to perform; however, by the 1980s, such systems had been replaced by PES designed by system analysts who did not understand the technologies involved. The safety critical real-time software for a programmable equipment system will only be reliable when it is designed by control engineers who understand the functions it has to perform. Findings Bottom-up design of software is necessary to avoid safety issues and this can only be achieved using object-oriented methods. Originality/value This paper describes an entirely original idea of the author based on experience of managing the design and construction of the process control, emergency shut-down and fire and gas and communication systems for a major oil and gas platform in the North Sea around the time of the Piper Alpha disaster.

We show how residual faults and failures and time to next failure can be used in combination to assist in assuring the safety of the software in safety critical systems like the NASA Space Shuttle Primary Avionics Software System.

The ever increasing need for energy resources creates complex health and safety challenges in petroleum and petrochemical companies and human participation is crucial to the management of health and safety particularly in K-Refinery and Petrochemical companies (K-RPC). The research set out to differentiate management safety performance behaviour into two different types, assess the impact of employee and management safety participation on overall safety performance and to evaluate the impact of employees’ safety knowledge/perception on compliant behaviour in K-RPC. Methods employed in the assessment are the Mann Whitney U Test, Correlation Analysis and descriptive statistics. The results suggested that there is no difference in mean ranking between management and employees regarding the level of management commitment, indicating a high level of participation. A significant negative correlation was found between employees’ safety knowledge and safety compliant behaviour, which implies a low practical application of safety knowledge gained through training. Therefore, though management participation in safety issues in K-RPC is perceived to be high, this commitment did not impact on the overall levels of safety performance in K-RPC. Hence, the manner in which participation in work-related safety is exhibited has an overwhelming impact on safety performance. When participation takes the form of directives rather than direct and true active involvement during work operations, the empowering safety leadership which is a fundamental drive to the attainment of an incident-free work will be missing.

Designing reliable interactive software is hard, and designing usable reliable interactive software is even harder. Experience shows that many interactive systems exhibit recurring characteristics that require in addition evolvability, assessability and certify-ability especially when safety critical systems are concerned. This tutorial projects into the future previous work we have done over the last 15 years around a Petri nets-based notation and a CASE tool supporting it, for addressing such aspects of interactive software development.The course covers the roles formal notations can play in the interactive systems' development process: how they provide complete and unambiguous descriptions of these systems,how they handle system complexity,how they can fit with interactive systems development processes (highly iterative)and how they contribute too to the implementation activities.Such elements will be addressed first by providing an historical perspective of formal descriptions techniques in the field of interactive systems and then by focusing on the Interactive Cooperative Objects notation and its CASE tool PetShop.The tutorial will also address the new challenges for formal description techniques for interactive systems in order to address on an equal basis various (generally conflicting) properties such as Safety, Usability, Reliability and Evolvability.The audience will learn on concrete examples the advantages and drawbacks of using formal description techniques for various kinds of interactive systems including WIMP, post-Wimp and multimodal interaction techniques. The examples will be taken from various industrial domains including cockpits, satellite ground segments and Air Traffic Control.

There is an increased use of software in safety-critical systems; a trend that is likely to continue in the future. Although traditional system safety techniques are applicable to software intensive systems, there are new challenges emerging. In this report we will address four issues we believe will pose challenges in the future. First, the nature of safety is continuing to be widely misunderstood and known system safety techniques are not applied. Second, our ability to demonstrate (certify) that safety requirements have been met is inadequate. Third, modeling and automated tools, for example, code generation and automated testing, are introduced in a hope to increase productivity; this reliance on tools rather than people, however, introduces new and poorly understood problems. Finally, safety-critical systems are increasingly relying on data (configuration data or databases), incorrect data could have catastrophic and widespread consequences.

Verification of safety critical and control systems of Nuclear Power Plants using Petri nets

Software for safety-critical systems must deal with the hazards identified by safety analysis in order to make the system safe. Building a safety-critical software requires special procedures to be used in all phases of the software development process. In this work, we have dealt with safety analysis techniques such as failure modes and effects analysis (FMEA) and fault tree analysis (FTA)-based safety-critical approach towards to development of an integrated automotive safety critical system from a safety perspective. A proposal of software safety architecture and software safety lifecycle has developed here using some important safety techniques. A new software development lifecycle with an integration approach, i.e., Agile-V model is proposed. Driver assistance system like ACCS is a safety critical system which is helpful to prevent accidents by reducing the workload on the driver. The basic design and functionality of ACCS is done with the safety command of bypassing to braking system when needed. As a safety approach for some limitations we have introduced an integrated architecture using fuzzy logic which has less failure cases and improves efficiency. The basic design and functionality of braking system is done with ABS and without ABS so that stopping distance also decreases.

Software for safety-critical systems must deal with the hazards identified by safety analysis in order to make the system safe. Building a safety-critical software requires special procedures to be used in all phases of the software development process. In this work, we have dealt with safety analysis techniques such as failure modes and effects analysis (FMEA) and fault tree analysis (FTA)-based safety-critical approach towards to development of an integrated automotive safety critical system from a safety perspective. A proposal of software safety architecture and software safety lifecycle has developed here using some important safety techniques. A new software development lifecycle with an integration approach, i.e., Agile-V model is proposed. Driver assistance system like ACCS is a safety critical system which is helpful to prevent accidents by reducing the workload on the driver. The basic design and functionality of ACCS is done with the safety command of bypassing to braking system when needed. As a safety approach for some limitations we have introduced an integrated architecture using fuzzy logic which has less failure cases and improves efficiency. The basic design and functionality of braking system is done with ABS and without ABS so that stopping distance also decreases.

The progressively dominant role of software in safety-critical systems raise concerns about the software dependability. There are limited mature practices and guides for assessing software dependability and analyzing system-level hazards triggered by software anomalies. A problem is that faults, errors, and failures that represent software anomalies, albeit with different natures, are usually used indistinctly to predict software dependability, leading to unsolid results. The lack of such consensual conceptualization also leads to poor interoperability between supporting tools, and, consequently, difficulties in anomaly management and software maintenance. Anomaly analysis and management is more tough for safety-critical software due to its higher complexity and the safety-critical nature. The complex context of safety-critical software causes difficulties in determining the evolution/propagation path of software anomalies and the impact on system safety. To capture the nature of safety-critical software and support an understanding of mechanisms of software anomalies and associated hazards, we propose three reference ontologies: Safety-critical Software Ontology, Software Fault Ontology and Software-failure-induced Hazard Ontology, which are built based on international standards, guides, and relevant conceptual models. We also discuss the relationships among them. That will facilitate a better understanding of the software anomaly mechanisms and the design of intervening/mitigation solutions. We demonstrate how these ontologies can help analyze software problems of real-world safety-critical systems.