Safety Requirements Specification Research Articles

Guidelines for the development of a critical software under emergency.

Context:During the first wave of the COVID-19 pandemic, an international and heterogeneous team of scientists collaborated on a social project to produce a mechanical ventilator for intensive care units (MVM). MVM has been conceived to be produced and used also in poor countries: it is open-source, no patents, cheap, and can be produced with materials that are easy to retrieve.Objective:The objective of this work is to extract from the experience of the MVM development and software certification a set of lessons learned and then guidelines that can help developers to produce safety–critical devices in similar emergency situations.Method:We conducted a case study. We had full access to source code, comments on code, change requests, test reports, every deliverable (60 in total) produced for the software certification (safety concepts, requirements specifications, architecture and design, testing activities, etc.), notes, whiteboard sketches, emails, etc. We validated both lessons learned and guidelines with experts.Findings:We contribute a set of validated lessons learned and a set of validated guidelines, together with a discussion of benefits and risks of each guideline.Conclusion:In this work we share our experience in certifying software for healthcare devices produced under emergency, i.e. with strict and pressing time constraints and with the difficulty of establishing a heterogeneous development team made of volunteers. We believe that the guidelines will help engineers during the development of critical software under emergency.

An Investigation of Knowledge Gaps of Graduate Students Regarding Safety-Critical Systems Development: A Controlled Experiment

<italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Contribution:</i> This article details the conduction of an experiment to investigate the knowledge that computer science graduate students have about safety-critical systems development, in particular, safety requirements specifications. Future research directions are also discussed. <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Background:</i> Safety-critical systems have been increasingly used in many critical domains, requiring a rigorous development process as well as certification by regulatory agencies. However, it is not clear whether computer science courses deliver adequate education for students to develop such systems. Experimental research with these students could provide evidence on whether they have the minimum knowledge necessary to develop safety-critical systems. This type of research presents several advantages, such as reproducibility, high-level control, and specific conclusions, but has not been widely adopted to verify learning issues. <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Research Question:</i> How to measure the understanding of students on safety-critical systems development? <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Methodology:</i> A controlled experiment was conducted with computer science graduate students in which they prepared safety requirements specifications. Three variables, i.e., understandability of the tasks, accuracy of the specifications, and effort required, were analyzed. <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Findings:</i> This experiment made it possible to explicitly measure the effect of understandability on accuracy and effort. Our experimental scenario revealed that most graduate students do not know about safety engineering. Hence, it is paramount to rethink computer science curricula to include basic safety engineering concepts and how software-engineering-specific knowledge should be considered in the development of these systems. Besides, software architecture must receive special attention, as it is the backbone of all software-based systems, including safety-critical systems.

Why a run-to-fail strategy is not good practice for SIS?

The Maintenance & Reliability engineers understand pain area that the portion before the “flat” part of the “Bathtub” is where a high number of premature failures can occur: commonly referred to as “infant mortality”. One of the fundamentals of the Probability of Failure on Demand (PFDavg) calculations in SIL verification analysis, is the concept of a constant failure-rate during useful life of the equipment. Probabilistic calculations assume that the failure rate of the devices used in a Safety Instrumented System (SIS) remains constant during the “flat” (constant failure rate) portion of the “bathtub” curve. Most manufacturers will perform stringent testing to weed-out, weaker units that could fail prematurely, leading to unwanted warranty claims. When equipment reaches to flat portion of it’s lifetime called as “wear-out” phase then the failures start to rise dramatically & then the integrity of the Safety Instrumented Functions (SIF) is compromised. During the Operation and Maintenance phase of the SIS, periodic performance assessments need to be made in order to ensure the as-designed, installed and commission SIS and its SIFs, still meet the performance requirements of the Safety Requirement Specification (SRS) [1]. Using a run-to-fail strategy will not enable the SIFs to meet the performance requirements once wear-out occurs. This paper will explain why a run-to-fail strategy is not good practice for a SIS, which will lead to the de-graded performance of the SIFs. This paper addresses both the design and operational impacts of a run-to-fail strategy.

Software requirements testing approaches: a systematic literature review

Testing a software system is an important step approach to ensuring quality, safety, and reliability in safety-critical systems (SCS). Several authors have published new approaches to improve the processes of testing safety requirements taking into consideration existing processes that seek to improve techniques and contribute positively with software developers. This article aims to investigate the main approaches to requirements testing, particularly focusing on safety requirements in the context of SCS. We investigated how these approaches have been developed and what contributions they provide to academia and industry. We evaluated the pros and cons of the approaches and how they related to the joint work of requirements engineers and testers. We performed a systematic literature review (SLR), selecting 53 papers published between 1990 and 2018. Our research was conducted according to the guidelines proposed by Kitchenham and Biolchini. The results of this SLR point out to the new research related to the software and safety-critical systems testing. The results show issues in the integration of requirements engineers with the application test team and gaps in the approaches found, particularly in the applications of the techniques in the industry setting. Moreover, several approaches are presented to solve problems and help to prevent future problems. The results of this research point to the main approaches to requirements testing and their use in academia and industry, as well as the advantages and disadvantages. The shortcomings allow us to suggest new research in safety-critical systems in the scope of validation, verification, specification, and testing of safety requirements, as well as to integrate test teams with requirements engineers in order to get better results. Based on the results, we suggest future studies for improvements in the requirements testing techniques to improve the integration of safety requirements and test cases.

Simulation System for the Wendelstein 7-X Safety Control System

The Wendelstein 7-X (W7-X) Safety Instrumented System (SIS) ensures personal safety and investment protection. The development and implementation of the SIS are based on the international safety standard for the process industry sector, IEC 61511. The SIS exhibits a distributed and hierarchical organized architecture consisting of a central Safety System (cSS) on the top and many local Safety Systems (lSS) at the bottom. Each technical component or diagnostic system potentially hazardous for the staff or for the device is equipped with an lSS. The cSS is part of the central control system of W7-X. Whereas the lSSs are responsible for the safety of each individual component, the cSS ensures safety of the whole W7-X device. For every operation phase of the W7-X experiment hard- and software updates for the SIS are mandatory. New components with additional lSS functionality and additional safety signals have to be integrated. Already established safety functions must be adapted and new safety functions have to be integrated into the cSS. Finally, the safety programs of the central and local safety systems have to be verified for every development stage and validated against the safety requirement specification. This contribution focuses on the application of a model based simulation system for the whole SIS of W7-X. A brief introduction into the development process of the SIS and its technical realization will be give followed by a description of the design and implementation of the SIS simulation system using the framework SIMIT (Siemens). Finally, first application experiences of this simulation system for the preparation of the SIS for the upcoming operation phase OP 1.2b of W7-X will be discussed.

Safety integrity level verification for safety-related functions with security aspects

Abstract The article is devoted some important issues of the functional safety analysis, in particular the safety integrity level (SIL) verification of safety functions to be implemented within the distributed control and protection systems with regard to cyber security aspects. The procedure for functional safety management includes hazard identification, risk analysis and assessment, specification of overall safety requirements and definition of safety functions. Based on risk assessment results the safety integrity level (SIL) is determined for consecutive safety function. These functions are implemented within industrial control system (ICS) that consist of the basic process control system (BPCS) and/or safety instrumented system (SIS). Determination of required SIL related to required risk mitigation is based on semi-quantitative evaluation method. Verification of SIL for considered architectures of BPCS and/or SIS is supported by probabilistic models with appropriate data and model parameters including cyber security-related and uncertainty aspects. A method based on quantitative and qualitative information is proposed for SIL verification with regard of the evaluation assurance levels (EAL), the security assurance levels (SAL) and the number of protection rings described in the SeSa methodology. A method for SIL verification, based on so called differential factor is presented.

Safe operation sequences: a generation approach based on iterative refinements and abstractions of timed automata

Operation procedure engineering for complex and critical systems aims to provide action sequences satisfying safety requirements specifications. If automatic generation of procedure seems to be interesting for this purpose, the limit of the use of formal generation approaches is classically the combinatorial explosion induced by the size and the number of required models. This article addresses this issue by proposing an iterative approach for the generation of safe operation sequences, using timed automata, and based on reachability analysis. The originality of this approach is to combine a bottom-up framework to build progressively system models by abstraction, and a top-down iterative action sequence generation.

A structured and systematic model-based development method for automotive systems, considering the OEM/supplier interface

The released ISO 26262 standard for automotive systems requires to create a hazard analysis and risk assessment and to create safety goals, to break down these safety goals into functional safety requirements in the functional safety concept, to specify technical safety requirements in the safety requirements specification, and to perform several validation and verification activities. Experience shows that the definition of technical safety requirements and the planning and execution of validation and verification activities has to be done jointly by OEMs and suppliers. In this paper, we present a structured and model-based safety development approach for automotive systems. The different steps are based on Jackson's requirement engineering. The elements are represented by UML notation extended with stereotypes. The UML model enables a rigorous validation of several constraints. We make use of the results of previously published work to be able to focus on the OEM/supplier interface. We illustrate our method using a three-wheeled-tilting control system (3WTC) as running example and case study.

Auditing IPLs-using safety critical functions manuals

The three criteria for an independent layer of protection (IPL) are effectiveness, independence, and auditability. The effectiveness and independence of an IPL typically are evaluated as part of a Layer of Protection Analysis (LOPA), and normally are confirmed by the time the LOPA is finalized. Auditability, on the other hand, is typically not addressed during the LOPA, and frequently is not addressed until someone is charged with the task of actually auditing the IPL, assuming that even occurs. For a Safety Instrumented Function (SIF) with a Safety Integrity Level to be installed in a Safety Instrumented System (SIS), the requirements for auditing are listed in the standards such as IEC 61511 and ANSI/ISA S84 and the relevant information is contained in a Safety Requirements Specification (SRS). However, an SRS for an SIS does not address IPLs that are not SIFs: administrative functions, noninstrumented functions, and nonrated control functions, even though they are also critical to assuring sufficient risk reduction for specific hazards. The auditability, and hence the auditing, of IPLs not installed in an SIS too often becomes an afterthought. A Safety Critical Functions Manual (SCFM) can pick up where the SRS leaves off. It defines requirements for testing, maintenance, and training for IPLs not included in the SIS. The very act of creating an SCFM forces the issue of auditability to be addressed, and defines the items that need to be audited. While an SCFM could manifest itself in different ways, it generally can be expected to include datasheets which address the operation, testing, maintenance, and training requirements for each safety critical function. Although it would be analogous to an SRS, an SCFM typically would be simpler. The article includes a discussion of an approach to SCFMs that has been successful at a number of different organizations for documenting and maintaining those safety critical IPLs that are not already covered by one of the SIS standards. © 2014 American Institute of Chemical Engineers Process Saf Prog 34: 228–236, 2015

HASILT: An intelligent software platform for HAZOP, LOPA, SRS and SIL verification

Incomplete process hazard analysis (PHA) and poor knowledge management have been two major reasons that have caused numerous lamentable disasters in the chemical process industry (CPI). To improve PHA quality, a new integration framework that combines HAZOP, layer of protection analysis (LOPA), safety requirements specification (SRS) and safety integrity level (SIL) validation is proposed in this paper. To facilitate the integrated work flow and improve the relevant knowledge management, an intelligent software platform named HASILT has been developed by our research team. Its key components and functions are described in this paper. Furthermore, since the platform keeps all history data in a central case base and case-based reasoning is used to automatically retrieve similar old cases for helping resolve new problems, a recall opportunity is created to reduce information loss which has been cited many times as a common root cause in investigations of accidents.

Deriving fault-detection mechanisms from safety requirements

Safety requirements are an important artifact in the development of safety critical systems. They are used by experts as a basis for appropriate selection and implementation of fault detection mechanisms. Various research groups have worked on their formal modeling with the goal of determining if a system can meet these requirements.In this paper, we propose the application of formal models of safety requirements throughout all constructive development phases of a model-driven development process to automatically generate appropriate fault detection mechanisms. The main contribution of this paper is a rigorous formal specification of safety requirements that allows the automatic propagation, transformation and refinement of safety requirements and the derivation of appropriate fault detection mechanisms. This is an important step to guarantee consistency and completeness in the critical transition from requirements engineering to software design, where a lot of errors can be introduced into a system by using conventional, non-formal techniques.

Is it really an independent protection layer?

Layer of protection analysis (LOPA) is a simplified chemical process risk assessment tool that is used to determine if sufficient independent protection layers (IPLs) are in place to meet an organization's risk tolerance criteria for a particular hazardous scenario. LOPA can determine how much additional risk reduction is needed for the scenario and can help in specifying the additional protection layers. The Center for Chemical Process Safety books, Layer of Protection Analysis—Simplified Process Risk Assessment (Center for Chemical Process Safety, Layer of Protection Analysis: Simplified Process Risk Assessment, American Institute of Chemical Engineers, New York, NY, 2001) and Guidelines for Safe and Reliable Instrumented Protective Systems (Center for Chemical Process Safety, Guidelines for Safe and Reliable Instrumented Protective Systems, American Institute of Chemical Engineers, New York, NY, 2007), identify required attributes of independent protective layers. In more than 15 years experience working with LOPA, I have frequently observed confusion about these attributes among LOPA analysts, protection layer implementers, and operations personnel (Study and Champion, Process Saf Prog 28 (2009), 300–307). Therefore, this article discusses the characteristics of IPLs, gives examples to avoid confusion and misapplication of the characteristics, gives an easily remembered phrase to screen candidate IPLs, and provides sample tools to confirm IPL compliance with the characteristics. The article discusses the importance of a safety requirements specification for safety-instrumented functions and proposes analogous documentation for other IPLs. The article gives guidance to determine when protection layers or scenarios require more detailed analysis such as event tree analysis or fault tree analysis. analysis. © 2011 American Institute of Chemical Engineers Process Saf Prog, 2011

A SUBJECTIVE SAFETY AND COST BASED DECISION MODEL FOR ASSESSING SAFETY REQUIREMENTS SPECIFICATIONS

This paper presents a subjective safety and cost based modeling approach for evaluating safety requirements specifications in the study of safety-critical software. In the approach fuzzy set modeling and evidential reasoning are combined to assess both the safety associated with and the cost incurred in each option of safety requirements specifications. Both safety and cost estimates are combined to obtain the preference degree associated with each option of safety requirements specifications for selecting the best one. An example is presented to demonstrate the proposed approach for safety based on decision-making in safety requirements analysis of safety critical software development.

Analysis of safety‐critical software elements in offshore safety studies

“The offshore installations and wells (design and construction, etc.) regulations” (DCR) requires that all safety‐critical elements in both the system and software domains be assessed and evaluated. In this paper, following a brief review of offshore system (application) safety analysis, offshore software safety analysis is introduced. It is followed by a study of combining offshore system safety analysis with software safety analysis. The typical standards for the development of safety‐critical systems in several industrial sectors are discussed with particular reference to formal methods. A generic offshore software safety analysis framework is proposed with discussions. Formal methods for producing safety requirements specifications are then discussed. A case study is used to demonstrate safety requirements modelling for safety‐critical software development. Finally recommendations for further development in offshore software safety analysis are given.

System with Defined Level of Safety

The paper deals with basic methods of analysis and synthesis of fail-safe systems. The fail-safe system is a system whose operation is in compliance with safety requirement specification and is required not to be incidental after a considered fault has occurred. Property of "being fail-safe" can be reached by applying various fail-safety techniques (inherent fail-safety, reactive fail-safety and composite fail-safety or their combinations) discussed in this paper. Fulfilling safety requirement specification must be proved (by written certificate) through appropriate qualitative and quantitative analysis of failure effects (incidental, systematic, environment effects) to system operation.

Applicability of SIGNAL in safety critical system development

This paper concerns the specification of functional and safety requirements of a safety critical system independently, and subsequent validation of the integrated requirements in the synchronous data-flow formalism SIGNAL. The SIGNAL language provides a unified framework for hierarchical development of systems by refinement of specifications. Validation of specifications can be realised through a formal calculus based on the semantics of the language or through functional simulation. In this context, the research reported attempts safety management in critical real-time systems in an application–independent manner. This is based on the possibility of identifying low and high risk states in a system and expressing its functional behaviour as transitions between pairs of states of different levels of risk. Safety requirements become conditions prohibiting low to high risk transitions, or forcing high to low risk transitions in a timely manner. A safety module, which is in charge of ensuring that these conditions are observed at run-time, is developed in SIGNAL to explore the applicability of the SIGNAL language to safety-critical design and to establish both the feasibility and the extent of managing safety concerns in an application–independent manner.

A subjective methodology for safety analysis of safety requirements specifications

This paper presents a methodology for subjective safety analysis of safety requirements specifications of software for safety-critical systems. The methodology incorporates fuzzy set modeling and evidential reasoning to assess the safety associated with safety requirements specifications. Three basic parameters-failure likelihood, consequence severity, and failure consequence probability are used to analyze a safety rule in terms of membership functions. The subjective safety description associated with the safety rule is then mapped back to the defined safety expressions which are also characterized in terms of membership functions. Such a mapping results in the production of the safety evaluation associated with the safety rule. The information produced for all safety rules can then be synthesised using an evidential reasoning approach to obtain the safety evaluation associated with the safety requirements specifications. The developed methodology is capable of dealing with multiple safety analysts who make judgements on each safety rule. A case study based on a train-set crossing is used to demonstrate the methodology.

Response to “the formal specification of safety requirements for storing explosives”

Abstract This short communication is a response to [MuS93] investigating their ACS system specification. The main point in this paper is that executing specifications can be used as a feasible way of validating them. It is essential to have tool support which enables one to write a generally not executable specification, and then prototype (parts of) it directly in the specification language, without translating it into some other prototyping language.

The formal specification of safety requirements for storing explosives

Abstract In this paper we consider the current practices involved in the storage of explosive articles and substances. In the spirit of Defence standard 00-55, we formalize the safety requirements of the ACS software which is used to manage certain MOD holdings in the United Kingdom using the specification language VDM. We also prove some properties of these safety requirements and comment on a similar OBJ3 specification.