Markt&Technik: Mr. Fromm, why is functional safety becoming increasingly important in embedded systems?

Peter Fromm: At this point, I would like to quote the development manager of a major chip manufacturer, who asked at the embedded world conference a few years ago: "Are there still embedded systems without safety?" With a grin, he followed up with the answer: "Yes, but there are fewer of them."

A strong driver here is the increasing performance of modern embedded controllers. At the beginning of my career, every variable and therefore every byte of memory requirement was scrutinized to see if it was really necessary. CPU time was a similarly critical resource. This has now changed significantly, and today's embedded developers can easily implement more complex algorithms that are increasingly taking on safety-relevant tasks. One prominent example is modern advanced driver assistance systems (ADAS) in the automotive sector. But similar trends can also be observed in medical technology, agriculture, automation and even building technology.

How do you define functional safety (FuSi)?

The key point here is certainly the following: if the operation of a system can endanger the environment and, in particular, people, higher reliability requirements must be placed on this system.

Ultimately, there are three central requirements:

• Avoiding systematic errors in design and implementation - this is often a process requirement.
• Recognizing and handling stochastic errors - this is primarily an architectural requirement.
• Proving the safety case - i.e. creating a comprehensible, technical argument as to why the system is safe.

Do you have a specific example of this?

In my view, we need to consider both safe system functions and protective functions. In the case of safe system functions, traditional - often mechanical - solutions are replaced by electronic systems. One example of this is "X-by-Wire" systems. The main aim here is to use the new technology to achieve at least as high a level of reliability as the traditional approach.

In the case of protective functions - examples include an airbag, the anti-lock braking system (ABS) or electronic stability program (ESP) - the system makes an active decision in critical situations and decides for the human operator. What is often dangerous here is not the failure of the system, but the faulty activation in a non-critical situation. A sad example of this is Boeing's Maneuvering Characteristics Augmentation System (MCAS) - the technology mistakenly took over control of the aircraft due to incorrect sensor values and serious flaws in the system architecture, leading to an accident.

What standards should developers know if they want to create code for FuSi applications?

From a software perspective in particular, the safety standards do not contain much that is new compared to a Capability Maturity Model Integration (CMMI) or Spice-based process. Ultimately, the developer must always comply with the standard that applies to the relevant domain. The basic standard IEC 61508 is a good starting point, but contains rather abstract specifications in relation to software development; ISO 26262 is more specific here.

What other points should developers bear in mind?

Ultimately, regardless of the standard, it is important to develop the safety functions systematically based on a risk analysis. At architecture level, the developer must then find a solution that implements the safety function with sufficient reliability. The key parameters here in almost all standards are the "mean time to failure" of the individual components, diagnostic coverage and hardware architecture or redundancy.

In my view, the most important thing, in addition to knowledge of the safety standards, is therefore a very good understanding of the system and architecture as well as close cooperation between software and hardware developers.

Is it usually enough to test software, or do you suggest further measures?

If you look at the economic side of a safety project, you can see that a systematic testing process is often a supposed main driver of costs. Safety standards do not place particularly high demands on the test process. However, developers must document and test systematically.

In practice, the use of automated Processor-in-the-Loop (PIL) or Hardware-in-the-Loop (HIL) tests is therefore recommended. This is because a systematic test specification can quickly add up to several 10,000 test cases, even for small safety functions. In addition, all tests usually have to be run through again in full during a re-test.

In the automotive sector, MISRA rules are used in an attempt to avoid errors during programming. What do the MISRA rules achieve and where is there a need to catch up?

MISRA is certainly one of the better programming standards and reduces the C/C++ language scope to a safe and well-defined subset - which is also shown by the fact that this standard is used in many areas outside the automotive sector and has now even found its way into the curriculum of technical degree courses.

Especially when I use MISRA as a software developer during development, I can eliminate weaknesses in the code before the review. But even MISRA is not a silver bullet. In particular, design errors in the code and other more complex problems cannot be found with it. The human expert review is therefore still necessary and important. However, the focus of the review can then be placed on the "exciting" problems.

Which tools do you recommend to developers to create and test software code according to all aspects of functional safety?

The question of the toolchain certainly depends on the complexity of the project. Our experience in current projects shows that a model-based approach can be worthwhile. This allows developers to meet the high requirements for quality, documentation and traceability while at the same time developing the software in incremental or iterative cycles in an agile manner.

As part of a project within the German government's Central Innovation Program for SMEs (ZIM), we have developed a holistic yet lightweight tool at the Department of Electrical Engineering and Information Technology at Darmstadt University of Applied Sciences, which has now been successfully used in the first safety projects. In terms of model-based system engineering, it supports the process areas of requirements, hardware and software architecture, code generation of the runtime environment as well as testing and traceability between all artifacts.

What three tips would you give a developer regarding safety requirements?

The most important tip is definitely to plan sufficient resources and time. Due to the higher requirements for architecture development as well as testing and documentation, the effort involved in a safety project quickly doubles, even at the lower safety integrity levels.

The second tip would be: Understand the technical meaning of the safety standard and try to implement it sensibly instead of following the standard letter for letter.

And last but not least: external advice or support is helpful, especially if this is your first safety project.