Time to Read 2 min
Functional safety is surrounded by some myths, often it is not clear what needs to be done at all or there are other misconceptions. We try to dispel the following misconceptions here:
We did an FMEDA, Now the Product is Safe!
Development for functional safety is about avoiding and uncovering faults in the product. There are two types of faults: systematic and random faults.
The random faults are calculated and minimized in quantitative (i.e. failure rate based) FMEA variants (FMEDA, FMECA...) for the hardware components. However, this is only a vanishingly small portion of functional safety tasks.
The larger part deals with systematic faults of the software and also of the hardware, i.e. with minimizing development errors. This is done by requirements management, reviews, tests and much more. If a product is promoted as safe because an FMEA was performed, then there is still a long way to go until the product is really functionally safe.
In the End, we Take the Product to the TÜV, and They put the Sticker on it!
In discussions about functional safety, the opinion sometimes arises that you can develop the product "as normal" or even take an existing product. Then you do some documentation, go to the notified body of choice and they then give you a "SIL sticker".
In reality, there are so many additional activities that need to be done that the product is actually re-developed. And most importantly, you should plan for functional safety from the beginning, because its requirements affect the entire system design, software design, and even hardware design.
The Product is Finished, so Let us Make it Safe!
A similar situation occurs when the requirement for functional safety only arises after the product has already been fully developed. Or an existing product should now be sold with a SIL, a PL.
In almost all cases such a situation means to develop the product completely new, because many aspects of functional safety affect the hardware and software architecture, e.g. isolation of channels from each other, software architectures without "hidden data flow", even the choice of programming language and components (unfortunately nothing works without the manufacturer's safety manual, so you can only use a limited selection). Therefore it makes more sense to include functional safety in the project from the beginning, so there are no massive corrections at the end.
What can be worthwhile on the other hand are rapid prototypes or functional samples to minimize risks. These also allow safety aspects (e.g.: is the computing power sufficient for the safety mechanisms?) to be clarified in advance.
We have MISRA and Code Coverage, so our Software is Safe!
If you look at marketing material for software (operating systems, libraries...) or embedded products, statements from startups and also from open source projects, you will find the claim that the software is functionally safe. This is because the MISRA coding rules have been followed, full Code Coverage has been achieved with unit tests or the software meets other metrics (such as maximum Cyclomatic Complexity).
These activities are necessary, but by far not sufficient to make a software safe. To avoid systematic errors, many additional activities and especially reviews are required...
No Comments