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. In addition, the actual function of the product without functional safety.

Certification Base

First of all, the regulatory requirements should be clarified. These may be regulations from authorities (EU, EASA, FDA, etc.), but also 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, i.e. the system integrator.

Often, the certification basis initially consists of just a few standards. As soon as you start dealing with the topic, it becomes more detailed. Typically, there is no way around intensive research into 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) for the entire product or subsystem to be developed (i.e. not a component FMEA, as in an FMEDA, for example), 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, then the motor reduces its torque to less than 30 Nm within 500 ms”.

It has proven useful to formulate safety objectives in the affirmative, i.e. to describe what must be ensured rather than 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 is (e.g. 1% deviation from full sccale) 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/system integrator in their risk analysis based on the architecture of their system and the environment in which it is used.

In both cases, the questions that have a significant impact on the development, such as the definition of the interfaces, should be clarified in advance. 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 as a static, digital 24 V signal. In the first case, safe software must be developed in addition to the electronics, resulting in massive additional costs.

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

Main Function and Technology: Prototypes

You can omit this part if you already have a product or functioning prototypes that 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”) that you can use to test the actual functions of the product. You can create prototypes more quickly because you can dispense with the level of documentation and the development processes required by the functional safety standards. This reduces the number of changes during safe development, which involve much higher effort than changes to a functional prototype.

When realizing the functional model, 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. The aim is to ensure that you can use the findings of the functional model as closely as possible for the development according to functional safety standards. If you do not take them into account, then not all the knowledge gained 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!