Systems, Functions and Safety

Automating many processes in our society took up the pace in the last couple of decades. One of the major aspects of that automation is digitization, integration, and the proliferation of complex software. Many industries which were considered dangerous, such as chemical plants, rail, automotive, etc., are now being engulfed in modern hardware and software development paradigms in which all the safety-critical tasks are handed over to digital sensors and various microcontrollers. In this chapter, we introduce the notion of safety-critical systems to a wide engineering audience, mostly targeting software and hardware engineers. By starting this interesting safety journey, our hopes are high that the understanding of all the challenges there are in this exciting world would help them mitigate any issues which may arise from incorrect processes and incorrect designs, which are usually transferred from noncritical industries without too much thinking.

Vast majority of system failures can be attributed to us, developers, not knowing what the system should do and how specifically some functions need to be performed. The field of requirements engineering is, unfortunately, neglected in many projects, and the requirements are looked at as being “the necessary evil” and the afterthought in the sense of filling up paperwork for audits. In this chapter, we would demystify the role of requirements and the high-level system specification and how it shall be done properly. We would emphasize the selection of stakeholders for the requirement elicitation process and further prioritization and expression of the requirements. Understanding the importance of the requirements is essential to pinpoint the very origins of system safety and how the safety can start to be regarded inherently.

System safety is a well-researched field with well-established terminology. To be able to correctly design for safety, we need to understand hazards and their associated risk. Each hazard may lead to an incident or an accident. The risk associated with each hazard can and needs to be assessed and quantified. In this chapter, we would lay out a procedure for assessing hazards, quantifying risk, and iterating the design until the hazards are removed or risk is reduced to the acceptable level. Our technical systems, therefore, can (and must!) be assessed for safety from the earliest project stages, starting from ideation, through requirements definition, then design and implementation, verification and validation, all the way into deployment and decommissioning.

Including safety in all phases of a system development project is required to ensure an inherent view of safety, designing all safety prescriptions from the start in a proactive way, instead of a reactive approach where fixes are only applied following the recorded incidents or accidents. Being proactive about safety is an essential consideration in system safety engineering today. This chapter introduces the required ground for having safety considerations and all relevant safety processes built into the project development life cycle. Each phase of the inherent safety process is detailed, and connections are made with the traditional processes in engineering and project management, emphasizing the need for proactive safety from the inception of the project idea (pre-project phase) all the way into deployment. Artifacts produced in each phase, as well as the traceability that needs to be maintained among them, are laid out. Additionally, important sub-processes are algorithmically defined, with specific actions prescribed to bring the risks down to the tolerable zone.

Functional safety is a subset of system safety in which active measures are sought to ensure the safety of a system. Typically, functional safety deals with the definition and assessment of a safety subsystem implementing safety functions. Safety functions are used to detect errors or other anomalies in the system operation and act by bringing the system to the safe state in which harm or damage can no longer occur (e.g., cutting off the power, applying brakes). This chapter introduces the main concepts and architectures in the field of functional safety, with the correct positioning of the equipment under control (EUC), EUC control system, safety-related system, and the safety functions and key principles upon which they operate. Important early insights into how safety-related system is evaluated and its safety integrity proven are also given, by introducing the requirements for systematic safety integrity as well as for the safety integrity against random system failures.

Safety functions are among the most important considerations in modern safety applications and are specifically prescribed in the functional safety area. Various functional safety standards provide steps that are necessary to be followed in order to define safety functions correctly. The process starts from the conceptualization of the system, in which the system scope is defined including system definition, system delineation, the definition of equipment under control (EUC), and EUC control system (ECS). The previous step is necessary to perform hazard and risk analysis, in which hazards, hazardous events, and situations are identified and related to faults, reasonably foreseeable misuse, or malicious actions. Each hazard is evaluated according to the standard applicable to the analyzed system, and its risk is quantified and classified according to that standard. Finally, each hazard needs to be addressed by one or more safety functions, which shall prevent or mitigate one of the aspects of the hazard (e.g., probability, exposure). Safety functions are designed to monitor (measure, evaluate) aspects of interest to the actuation of the hazard and to intervene in case monitored values are observed to have undesired values. Risk classification is transferred to the safety integrity requirement of the safety functions, which need to be compliant with this requirement in terms of their definition, design, implementation, and verification standpoints. In this chapter, an exemplary process is carried out concerning the requirements of functional safety for machinery, having in mind standards IEC 62061 and ISO 13849.

Safety integrity is the property of a system that provides safety-relevant operations, describing their resilience to dangerous failures. In functional safety, each safety function that is defined needs to comply with the safety integrity requirements, which are based on the safety integrity level allocated to the safety function following the hazard analysis and risk assessment. This chapter lays out typical safety integrity requirements, concerning two big groups: safety integrity against random failures and safety integrity against systematic failures. Safety integrity against random failures is then thoroughly introduced, including the definition of all relevant metrics for quantification, such as failure probability, reliability, failure rate, mean time to failure (MTTF), etc.

Safety integrity parameters for individual components can be usually extracted from manufacturer data sheets directly. However, in the case of complex configurations consisting of many components combined, safety integrity needs to be calculated by using various methods. In this chapter, we introduce the notion of the composite system and discuss how safety integrity parameters, such as failure rates and reliability, can be calculated for series, parallel, and combined configurations. An appropriate mathematical apparatus would be given, to enable calculations of final safety integrity parameters for typical configurations using reliability block diagrams (RBDs).

When designing a safety-related system, and especially its safety functions, we use a combination of components that exhibit certain reliability properties. Those properties limit the final safety integrity metrics and often disable the achievement of the targets required by the functional safety standards (e.g., reliability required for a certain ASIL). In this chapter, we discuss various methods which are at our disposal to improve the safety integrity of our safety designs. Some of the methods we would analyze include burn-in testing, component derating, respecification, static and dynamic redundancy, and component diversification.

Formal proof of system safety is usually required before it can be signed off for deployment. A set of arguments (claims) used to prove the system safety is called a safety case. Safety case addresses all the safety integrity requirements defined by the respective standards and provides evidence that those requirements have been fulfilled. Many requirements include measurable indicators, some of which were discussed in previous chapters, such as reliability and failure rates. However, additional sets of measures may be prescribed by the standards, such as diagnostic coverage (DC), safe failure fraction (SFF), and more. This chapter discusses the required sets of claims for the safety case, including the description of those additional measures. Finally, the safety is contrasted with the availability, as one of the most important dependability requirements for the system.

Each safety-critical system which is addressed with the provisions of functional safety usually contains a safety-related system (SRS) implementing a variety of safety functions that can bring the system to the safe state in case of any malfunction. Hazard and risk assessment yields scores which are then transferred to the safety integrity requirement of the safety functions, which need to be compliant with this requirement in terms of their definition, design, implementation, and verification standpoints. In this chapter, an exemplary process commenced in Chap. 6 is finalized concerning the requirements of functional safety for machinery, having in mind standards IEC 62061 and ISO 13849. Each safety function is assessed according to its relevant metrics, such as mean time to failure/failure rate, diagnostic coverage and hardware fault tolerance (redundancy) configurations, and final safety integrity level calculated and evaluated with the initial requirement to decide if the implementation is compliant with the safety prescriptions.

Technical systems are increasingly designed, developed, and deployed all around us. Digitization of various industries, including automotive, industrial plants, smart cities, and space programs, is heavily underway, prepping the systems with sophisticated hardware and software. Complex algorithms are mostly modeled in software where the overall complexity grows tremendously. Throughout the previous 11 chapters, we dissected what is needed to correctly design and verify systems for safety. However, there are several more considerations apart from only technical items which need to be regarded in the safety context. In this chapter, therefore, we are going to compile a full safety checklist as a final reference and a great starting point for designing any safety-critical system.