Functional Safety: How Do I Start?

Time to Read 4 min

You know that you probably have to do “just something” for functional safety. The question that arises now is: how do you start?

Before the actual development, two aspects of the certification should be clarified, namely the certification basis and the safety goals, then also the actual function of the product without functional safety.

Certification Base

The first thing is to clarify what the regulatory requirements are. On one hand these may be regulations from authorities (EU, EASA, FDA, etc.), on the other hand these may be the standards that are derived from these requirements or that otherwise apply in the targeted markets. For components of a larger system, this information is often prescribed by the customer.

The certification base often consists of just a few standards at the beginning, but it becomes more detailed as you become more familiar with the topic. Typically, there is no way around intensive research of the standards.

This information is best documented in a “certification base” as a basis for development. This document can also contain the other regulatory requirements such as EMC, fire protection, etc.

Safety Goals / Safety Functions

Now the safety objectives need to be clarified. In many cases, you will have to derive these yourself.

This is done with a safety analysis of the entire product, with a HARA (Hazard Analysis and Risk Assessment), usually in the form of an FMEA (Failure Mode and Effects Analysis), the details of which are often specified by the applicable standards. The safety objectives, sometimes also formulated as safety functions (input-processing-output), result from this, e.g. „If the voltage at the STO input drops, the motor will no longer generate torque”.

It has proven useful to formulate the safety objective in the affirmative, i.e. what must be ensured, not what should not happen. For example, „The sensor provides the correct position values” instead of „The sensor does not provide any incorrect position values”. In this case, it is easier to define what a correct value, for example 1% deviation from full scale, is than to define what all incorrect values could be.

For many standards, each safety objective must be assigned a safety level, e.g. SIL (Safety Integrity Level), ASIL (Automotive Safety Integrity Level), PL (Performance Level) etc.

Sometimes the safety objectives and safety levels are already specified by the standard, for example in aviation. Or they are specified by the customer based on the analysis and architecture of their system. Even in these cases, a few questions should be clarified that have a significant impact on the development. For example, an STO function (Safe Torque Off) is often defined. It is then worth clarifying what the input signal that triggers the STO looks like. A command on a field bus leads to a completely different architecture than an STO input on a connector. In the first case, secure software must also be developed in addition to the electronics, with the resulting massive additional effort.

Since each safety objective increases the effort required, it makes sense to have as few safety objectives as possible, only as many as necessary.

Main Function and Technology: Prototypes

You can skip this part if you already have an existing product or functioning prototypes. This is if these are compatible with the resulting safety architecture (see below).

If you are not yet sure about the function, its implementation and its performance, we recommend that you first build functional models (“rapid prototypes”) to test the actual product functions. You can create the prototypes more quickly without the documentation and processes that functional safety requires. And above all, you can reduce the number of changes during safe development, which would mean a much greater effort than changes to a functional prototype.

When realizing the functional prototype, be aware of any restrictions that may arise from the certification basis or the safety objectives. For example, in the selection of components or the choice of technology, including programming languages. If you do not take these into account, not all findings from the prototype can be reused for safe development.

Are you unsure? Talk to us, we can support you in all three areas!

Andreas Stucki

Do you have additional questions? Do you have a different opinion? If so, email me  or comment your thoughts below!