EN 
DE 
A holistic approach and a thorough understanding of the details are essential when it comes to creating functionally safe systems. Software integrity can be achieved through structured and targeted methods and techniques.
Functional safety is part of the general concept of safety. The very word itself implies that this refers to systems that must "function" because a failure of these systems could lead to unsafe systems.
Here, as so often, the motto applies: "Something always has to happen before anything happens." International standards ensure that we arrive at demonstrably safe systems. Even though standards are not laws, they are considered a reference in court to assess whether a system was built according to the current "state of science and technology.".
Basic standard defines the life cycle of systems
What do the relevant standards say, and which standard is valid for the developer? Market-specific standards take precedence over generic standards. In industrial settings, IEC 61508 is the basic standard, upon which numerous specific standards have been developed. Nevertheless, this basic standard also stands on its own and should be applied when no specific standard exists.
Figure 2: IEC 61508 as a basic standard
At the heart of the basic standard is a defined system lifecycle, divided into several phases, each with corresponding requirements, as well as defined artifacts that must be created to comply with the standard. The lifecycle encompasses the "birth" of the system through a corresponding concept all the way to its "death," i.e., decommissioning or shutdown.
The standard acknowledges that there is no 100% safety standard.
Another key instrument is the assessment of safety through risk and the potential reduction of risk to a "socially acceptable level." This involves first analyzing all possible hazards that could emanate from the system and then evaluating the risk. This risk is calculated as the product of the probability of the hazard occurring and the severity of the resulting injuries. The more a risk needs to be reduced (to a socially acceptable level), the higher the requirements that the standard places on safety-relevant systems.
The requirements are categorized into so-called integrity levels. IEC 61508 defines four levels, SIL 1–4, with the latter entailing the highest requirements. The standard acknowledges that there is no such thing as 100% safety. However, it specifies, via the integrity levels, which measures must be taken to ensure that the safety-related functions (those that ensure the system's safety) function correctly.
Figure 2: Safety integrity level according to IEC 61508
The documentation – the heart of the matter
What requirements does the standard specify? Essentially, it's about preventing errors. This necessitates understanding different classes of errors. The primary distinction is between random and systematic errors. Random errors (e.g., component failure) are often simply referred to as hardware errors. These errors cannot truly be predicted or prevented; their occurrence can only be reduced through appropriate component selection and system design measures.
In contrast, systematic errors (those caused by humans) can be reduced by working in a structured and process-oriented manner. This entails correspondingly high demands on documentation, management, and verification in all phases of the lifecycle. Engineers often only see the significant effort involved and unfortunately overlook the actual reason and benefits.
Define your own requirements
But the standard doesn't just set requirements; it also requires the user to define their own. For every safety-relevant function, requirements for the function itself, as well as for its integrity, must be documented and implemented. Following the two basic failure classes, a distinction can be made between hardware integrity and systematic integrity requirements, which are, however, defined within the standard itself, depending on the required SIL (Safety Integrity Level). For the actual system design, in addition to the requirements for systematic and hardware integrity, requirements regarding the handling of detected failures and data communication also play a role.
For hardware integrity, two sets of requirements come into play: On the one hand, there is compliance with specifications for random hardware failures, and on the other hand, compliance with architectural constraints. The latter can be achieved via two so-called paths or routes (1H or 2H). Route 2H refers to architectures that have already been proven in operation, but for which additional requirements are placed on minimum values for the so-called Hardware Fault Tolerance (HFT). Route 1H ultimately means that development is carried out according to the standard, and verification is provided for two measures, namely the HFT and the SFF (Safe Failure Fraction), the values of which must be met depending on the SIL to be achieved.
Achieving software integrity through structured and targeted methods
A similar principle applies to systematic integrity, compliance with which can be achieved by following three different routes (1S, 2S, or 3S). Route 1S means developing according to the standard, Route 2S refers to proven operational reliability, and Route 3S and its related requirements apply to the use of pre-built software that was not developed according to the standard.
When functional safety is to be ensured via software on programmable devices, further measures apply, which must be taken depending on the required SIL (Safety Integrity Level). Since there are no random errors in software, these measures aim to prevent systematic errors. The problem should therefore be tackled at its root, and software integrity should be achieved through structured and targeted methods and techniques.
Figure 3: Software integrity through structured and goal-oriented methods
Validating software tools
The good news here is for all those who already develop software in a structured and process-oriented way, meaning they apply generally accepted software engineering practices. In this case, the additional effort is minimal. Creating a software architecture, as well as software design and module design, are also among these best practices.
What may be new, however, is the need to take a closer look at the software tools used to implement the software. Depending on the potential impact of errors in these tools, validations must be performed to ensure that the use of these tools does not lead to increased failure rates of safety-relevant software functions.
Verification and validation through appropriate testing are essential. Since software is frequently modified, it is necessary to incorporate such changes into software development via a specifically defined process. This process can be self-defined, but it must ensure, for example, that only approved change requests are actually implemented and that an impact analysis determines which phases of the lifecycle are affected by such changes. Only in this way can it be ensured that the system as a whole continues to be developed securely.
Training allows for efficient onboarding and rapid implementation
Functional safety, therefore, largely involves applying best practices and implementing the requirements of standards in a structured manner. Reading standards is no easy task. It's easy to lose sight of the big picture, and the language used in the standards texts doesn't allow for easy interpretation.
A compact training The most important points allow for efficient training and rapid implementation.
Further information
MicroConsult Training & Coaching on the topic Quality, Safety & Security
MicroConsult expertise in the areas of quality, safety & security
MicroConsult Training & Coaching on the topic of Testing and Debugging
MicroConsult expertise in testing and debugging
MicroConsult Training & Coaching on the topic of process management
