Software is an absolutely integral part of our modern day-to-day lives. There is almost no aspect of life into which software has not permeated. And of course we justifiably get cross if the software we are using doesn’t work perfectly. But the consequences of software that isn’t doing what it is supposed to are far more severe in areas in which people’s lives depend on the reliability of software. In this context, we talk of safety-related software. Our article explains how this type of software can be implemented with state-of-the-art technologies.
Application areas and standards
Safety-related systems (also known as safety-critical or life-critical) are systems in which failures and malfunctions can have serious effects:
- People’s lives can be put in danger
- The environment can be harmed
- Goods are damaged or completely destroyed
- Vast commercial impact
Such safety-related systems are used for example in the transport industry (automotive construction, aviation, railways, aerospace), in medicine, infrastructure management (energy grids, nuclear power stations) and in the entertainment industry (roller coaster rides). Depending on the area of application, different standards define which particular safety regime applies (fail-safe, fail-secure, fail-operational etc.), which risk analyses and risk evaluations need to be performed, and it defines the necessary phases, methods, processes, validations and tests. Examples of such standards include IEC 61513 (Nuclear Power Plants), EN 50128 (Railway Applications), ISO 26262 (Road Vehicles) and DO-178C (Airborne Systems). Each of the standards offers different safety requirement levels. The appropriate requirement level for a particular system is chosen based on the corresponding risk assessment. With the aid of safety requirement levels, the requirements in terms of measures for fault prevention, fault control and the necessary documentation are defined. In the separate standards, the names given to the safety requirement levels and the ways in which they are handled differ: IEC/EN uses Safety Integrity Level (SIL), DO uses Design Assurance Level (DAL), while ISO uses Performance Level (PL) or Automotive Safety Integrity Level (ASIL).
Development of safety-relevant systems
A safety-related system includes the hardware, software and human aspects. At the start, this type of system was purely mechanical or electrical – there was no software component. This was followed by electronic systems, and software slowly but surely made its way into the domain of safety-related systems. As in many other areas, today it is the software that does the bulk of the work in these systems.
This development has necessitated a new approach to designing and building safety-related systems. Since a safe system needs to meet a certain safety requirement level, all its components need to be developed so that they are compliant with the relevant standard. It is also permissible to use already available (commercial) components if they meet at least the same safety requirements or are combined in such a way that the required safety requirement level can be met. In the case of software, this means that only programming languages, tools, operating systems and methods that are approved in accordance with the standard are permitted to be used. Specifically, this means that strongly typed programming languages like Ada, Modula-2 or Pascal are recommended. The choice of operating system is heavily limited (e.g. QNX, SafeRTOS, VxWorks etc.), and apart from this the selection of suitable tools and libraries is also very manageable. Before the software component started to dominate quite as much as it does now, this was not a problem. Anything that was not available as a commercial off-the-shelf product with a corresponding safety requirement level was simply developed in-house, so the entire scope of the functionality was implemented within the safety-related system.
As of today
Today, this approach is barely conceivable. The spread of software and its potential applications has practically exploded, and the use of open source components has not only become established, but is sometimes also an explicit requirement. Today, user interfaces are built with web technologies as standard, and Linux is the most commonly used operating system. Although the Linux Foundation launched the ELISA project in October 2018 (Enabling Linux In Safety Applications), one thing that all these new technologies and components share is that they are unable to fulfil any safety requirement levels. For this reason, a clear trend is currently evident that we need to identify the components of safety-related systems that absolutely have to be developed and certified in accordance with the applicable standards of functional safety. Suitable programming languages, tools, operating systems, methods and processes need to be provided for this. The remainder of the system is developed with modern, efficient technologies and agile methods. Even if these parts of the system are not required to meet a safety requirement level, they can be used to meet safety-related requirements. For example, during data entry it is possible to implement a multi-stage procedure in which the result after every stage is subjected to a test by the safe part of the system.
Paranor can offer long-standing expertise in the technologies and methods that are employed in safety-related systems and also in the latest web applications, and knows how to combine the two to best effect.
Are you interested? Please get in touch with us – we will be happy to offer personal advice.