The role of hardware and software in safety levels

The ultimate goal of any system developed to meet safety standards is not to pass all evaluation tests. Rather, the goal is to achieve a system that is practically safe. This means that if an error occurs in the system (because there is always the possibility of error), it does not put people at unacceptable risk.

However, human error exists at various stages of development and use, and it is unthinkable to create a completely secure system with zero risk. Therefore, the ultimate goal of designers and manufacturers of safe systems is to defend their product in case of unforeseen failures.

The best way to prove that the system is safe is to have a systematic proof that shows that the system is designed and built in such a way that most of the failure possibilities are predicted and its effects are compensated or reduced as much as possible.

The safety mechanisms that are selected for each identified risk can be very diverse. Just because of the use of programmable chips in the design of a system, not every risk can be solved with a bit of smart software and engineering. For example, if a system controls a laser cutter and there is a possibility that the central controller will act in a way that endangers the life of its user, there is no need to develop intelligent software to identify and eliminate this risk. A superior solution may be to place a physical shielding barrier around the laser. Even if this solution is not part of the functional safety requirements of the IEC6150 standard.

This is why there are different functional safety standards with specific target market criteria, each of which evaluates the safety process with an understanding of the risks and challenges ahead. For example, the question is "Is it appropriate to choose C programming language to use development software?". According to some experts, the answer is no and developers should move towards safe languages like ADA. However, the passage of time has shown that this argument is not very true. In fact, many COTS software products capable of supporting SIL3, such as some RTOSs, are developed in the C programming language. The important point is that when using C language, systematic processes should be used to reduce the risks associated with it. In fact, many of the insecure aspects of programming in C can be directly exploited using an RTOS and its underlying capabilities.

However, one kind of challenge for the RTOS developer is that the user, in developing his system (with safe application performance), may have to choose a specific compiler other than the one suggested by the developer. The question is, does using a different compiler than the one suggested by the developer cause the reliability of that RTOS to be lost? The answer is that it depends. Any compiler can be chosen if the vendor develops its certification process with a tool-independent perspective. This step only needs to analyze the impact of changing the compiler on RTOS reliability.

Anticipating this issue, along with in-depth knowledge and understanding of the software challenges in secure system design, can be of great value to any hardware and software supplier who has designed their products around the security standard.