Issues in developing software for safety critical systems

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.

Testing is an essential part of any aero engine development programme. Combinations of flight and safety critical hardware and software are tested on various platforms before integrating on engine. Extensive tests are carried out to exercise the engine in various modes to ensure reliable performance. One of the vital element of on board safety critical embedded controller software is control algorithms also known as Control Law (CLAW). The Control Laws are coded in C language by the Software House and are extensively tested with the participation of the Independent Verification and Validation (IV & V) group. Various validation techniques are emoloyed before onboard safety critical software flies. A method known as Non- Real Time (NRT) testing is adopted to test the on board safety critical code. In this paper a new approach to conduct NRT testing is addressed. This method helped engine house for formal clearance of onboard safety critical software. The new approach i.e. Gray Box Non-Real Time (NRT) Testing methodology is deployed to cater various tests (normal & Stress) on the Target Control Law (On-board Software). It is a Gray-Box- End to End functionality testing technique without any execution time constraint (Frame by Frame execution) which allows testing of Target Control Law (On-board Software) with static/dynamic inputs, which could cause a system failure and trap the defect.

A study and analysis of software errors has been carried out. The present study analyzed approximately 400 errors of safety critical Navigation system software in 10 project variants. Framework used was: (i) Identification of types and severity of errors (ii) Gathering errors from error database and categorizing them according to the type and severity (iii) Recognition of the pattern and deriving the relation to software change rationale (iv) Proposing the error prevention guidelines for software requirements specification and code implementation for future software projects as a part of Software Quality Assurance (SQA) process. The main aim is to propose the error prevention guidelines that are practical to be implemented despite the project schedules. This is considered valuable outcome of the Independent Verification and Validation (IV&V) effort carried out for this safety critical embedded software.

It is my great pleasure to welcome you to the 4th International ACM SIGSOFT Symposium on Architecting Critical Systems (ISARCS 2013). ISARCS is a symposium dedicated to architectural design for dependable, safe and secure systems. It provides an exclusive forum for exchanging views on the theory and practice of architecting critical systems. A critical system is characterized by the perceived severity of consequences that system failures may cause. In that respect, in addition to appropriate development methods, techniques and tools, a critical system also requires the provision of assurances that it is able to fulfill its specified service. As software systems continue to pervade every facet of our daily lives, our dependence on their safety, security, availability, and reliability grows. It has become increasingly clear that the architecture of a critical software system plays a crucial role in fulfilling its dependability requirements. This has called for effective methods, techniques, and tools that take architectural concerns into consideration during the design, construction, testing, maintenance, and upgrade of such systems. The aim of ISARCS is to bring together different communities in order to create a forum in which the different expertise collaborate in providing a comprehensive view on how to construct critical systems from the architectural perspective. This year, ISARCS is again part of the federated event CompArch, together with "QoSA 2013: 9th International ACM SIGSOFT Conference on the Quality of Software Architectures," "CBSE 2013: 16th International ACM SIGSOFT Symposium on Component-Based Software Engineering," and "WCOP 2013: 18th International Doctoral Symposium on Components and Architecture". ISARCS call for papers attracted 12 submissions that were reviewed thoroughly by an international program committee. Following an online discussion phase, 5 long and 2 short papers were accepted for inclusion in the proceedings and presentation at the conference. The federated event also includes 3 keynotes that are highly relevant to the challenges of architecting critical systems.

The demand for reliable critical software system is increasing in exponential way. In critical software system reliability is considered as an important quality factor. Reliability itself depends on various factors. To develop reliable critical software system it is very important to evaluate reliability in active and efficient manner. Soft Computing techniques are effective in assessment of models. The main objective of this study is to develop a reliability model that is based on important factors. The secondary objective is to evaluate the model by using fuzzy logic/soft computing. Since multiple factors have impact on reliability so fuzzy logic will help to provide specific solution for imprecise and ambiguous concepts by converting vague information into a good judgmental model Critical software system selection is a complex task. Four factors are considered to evaluate the reliability. Then the evaluation results are validated by using defuzzification. The proposed model can be implemented for various applications in an effective manner.

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.

The model driven architecture (MDA) is an approach to software engineering in which models are systematically developed and transformed into code. This paper discusses some of the issues which would need to be overcome when attempting to certify a safety critical design or software developed with the MDA approach, partially based on our experience with an avionics software case study. We particularly focus on the need to certify MDA artefacts and produce a compelling system safety case

The numerous benefits of automatic application code generation are widely accepted within the software engineering community. A few of these benefits include raising the abstraction level of application programming, shorter product development time, lower maintenance costs, and increased code quality and consistency. Surprisingly, code generation concepts have not yet found wide acceptance and use in the field of programmable logic controller (PLC) software development. Software engineers at the NASA Kennedy Space Center (KSC) recognized the need for PLC code generation while developing their new ground checkout and launch processing system. They developed a process and a prototype software tool that automatically translates a high-level representation or specification of safety critical application software into ladder logic that executes on a PLC. This process and tool are expected to increase the reliability of the PLC code over that which is written manually, and may even lower life-cycle costs and shorten the development schedule of the new control system at KSC. This paper examines the problem domain and discusses the process and software tool that were prototyped by the KSC software engineers.

This paper summarizes the main conclusions and recommendations from a Working Group on “Open Source Software and Dependability”. The Group was launched in the framework of a cooperative structure, a Network for Dependability Engineering, and gathered representatives often academic and industrial organizations.Key wordsOpen source softwareCOTScritical systemscertificationwrappingvalidation

Application stress testing applies the concept of computer network penetration testing to software applications. Since software applications may be attacked - from inside or outside a protected network boundary - they are threatened by actions and conditions which cause delays, disruptions, or failures. Stress testing exposes software systems to simulated cyber attacks, revealing potential weaknesses and vulnerabilities in their implementation. By using such testing, these internal weaknesses and vulnerabilities can be discovered earlier in the software development life cycle, corrected prior to deployment, and lead to improved software quality. Application stress testing is a process and software prototype for verifying the quality of software applications under severe operating conditions. Since stress testing is rarely - if at all - performed today, the possibility of deploying critical software systems that have been stress tested provides a much stronger indication of their ability to withstand cyber attacks. Many possible attack vectors against critical software can be verified as true threats and mitigated prior to deployment. This improves software quality and serves as a tremendous risk reduction for critical software systems used in government and commercial enterprises. The software prototype models and verifies failure conditions of a system under test (SUT). The SUT is first executed in a virtual environment and its normal operational modes are observed. A normal behavior model is generated in order to predict failure conditions based on attack models and external SUT interfaces. Using off-the-shelf software tools, the predictions are verified in the virtual environment by stressing the executing SUT with attacks against the SUT. Results are presented to testers and system developers for dispensation or mitigation.

Error propagation analysis is a consolidated practice to gain insights into error modes and effects that pertain to the activation of faults in software systems. A variety of approaches, such as architecture-based, source code instrumentation and variable tracing, have been proposed so far to address software error propagation analysis. Although valuable, existing approaches entail a substantial degree of system internals’ knowledge, visibility and code manipulation that is not well-suited for real-life production environments. This paper proposes an empirical analysis of error propagation. We specifically address the challenges in using fault data and error events in the logs, which are a convenient byproduct of the system’s execution. The approach puts forth the construction of error reporting graphs. We apply the approach to 2,042 failure data points from two real-world critical systems from the Air Traffic Control domain by a top industry provider. The approach contributes to develop a deep understanding on error modes and propagation paths, which can be leveraged by practitioners to make informed decisions on the placement of error detection mechanisms.

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. >

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.

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.

Evidence-Based Software Engineering (EBSE) focuses on understanding and delivering software engineering practices, tools and techniques that qualitatively and quantitatively provide value. The principles of EBSE underpin safety critical software engineering practices: when we build a safety critical software system, we must, in parallel, deliver evidence that the steps we have taken and the artefacts that we build will lead to an acceptably safe system. In safety critical software engineering, traceability plays a vital role. This talk will explore some of the different applications and uses of traceability in this context, and will suggest ways in which Model-Driven Engineering can provide solutions (e.g., through standardised approaches for describing safety arguments and evidence), as well as new challenges.