Functional Safety Concept acc. to ISO 26262:2018

After hazard analysis and risk assessment, the Functional Safety Concept (FSC) is the next logical step in controlling faults in automotive electronic systems. This is because it defines what needs to be done to achieve FS goals on the vehicle architectural level.

Back to funktional safety
FSC at a glance

You can download the comprehensive information on the functional safety concept in our free whitepaper.

Practitioners often ask ...

  • what actually distinguishes a FSC from a set of FS requirements?
  • is a FSC more than the sum of all safety requirements?
  • how do I know if I have enough safety measures in place for my project
  • how do I know if I have too many safety measures?
  • how do I know if  my FS measures are too expensive?

As much as possible in a short paper like this, I’ll give you answers to these questions.

At the beginning I will explain what the functional safety concept is. Then I’ll address what it must specify. This is followed by notes on how to assess whether sufficient FS requirements are specified, plus explanations on the creation process of FSC. Finally, I summarize the most important lessons for you.

We're here for you

Need support with a key project? We’re your first port of call when it comes to management consulting and improvement programmes in electronics development.

Steffen Herrmann and the sales team

FSC acc. to ISO 26262. Part 3 – Clause 3.7

Part three of ISO 26262 is about the functional safety concept. Under clause 7 there are requirements, the result of which is a work product simply called the functional safety concept. You’ll have learned this in my previous video on the concept phase.

Now, take a closer look at the definition of this work product in the following figure. The functional safety concept must provide a specification on how safety goals will be achieved for a specific item. This item is something like a feature that the carmaker wants to install in a vehicle, for example adaptive cruise control. The expectation is that the functional safety concept provides sufficient and convincing arguments as to how safety goals are met.

In specific terms, the functional safety concept consists of functional safety requirements. For example, this could be a requirement that the adaptive cruise control system must be switched off in a controlled manner after x seconds if there is no reliable information as to whether a driver still has their hands on the steering wheel. Or that the automatic park assist system can only be activated when the vehicle is stationary.

A note: at this level, be careful not to already expect certain technical solutions to be defined. This comes on the level of the technical safety concept.

Safety requirements are not enough by themselves, however, as we know from ISO 26262. The term mentioned in this respect is additional information – or associated information. Reviewers and assessors expect concepts and requirements to be described in a comprehensible way. So, with our example, it could be explained how the carmaker arrived at ‘x seconds’ and what assumptions underlie this.

Each functional safety requirement must be specifically assigned to the vehicle components in which it is implemented. In our example, this would mean that the steering wheel with its control unit is assigned a hands-on-steering-wheel mechanism with a specific ASIL.

And then the FSC must describe how vehicle components interact. So, for example that communication – between the control unit used for adaptive cruise control and the hands-on-steering-wheel ECU – must be implemented safely with an ASIL. Or that the adaptive cruise control unit does not automatically reactivate vehicle control when the hands-on-steering-wheel control unit reports back with reliable information after a longer period of time.

At this point, I would like to note two initial lessons

  • The functional safety concept is created on a vehicle level, so it’s the carmaker’s responsibility. Creating it requires an understanding of how vehicle components interact. Suppliers are usually given the functional safety requirements they must implement in their systems and components on an individual basis.
  • As authors of the functional safety concept, you must explain in an understandable way how each individual safety goal will be achieved.

I would now like to explain which questions must be answered by the FSC. These are:

  • What strategy is used in the development project to avoid faults later in the vehicle as far as possible?
  • What must be provided multiple times and independently in the vehicle to cope with failures of individual components?
  • How – and how quickly – must vehicle technology detect relevant faults, i.e. those that could lead to hazardous situations?
  • How must detected faults be reacted to? So, for example, to which safe state must the vehicle technology switch and how quickly? If a timely change is not possible, what does a transition state with as little risk as possible look like? This could be, for example, slow braking of the vehicle. This is referred to as fail-safe and fail-operational.
  • What displays and prompts must drivers receive in the event of failures in order to avoid accidents and injuries themselves?
  • What criteria are used to validate safety – i.e., how will it later be judged that FS goals have been met?
  • If these questions are answered comprehensibly and completely in such a way that the FS goals are achieved with the concept, then you have created a good FSC.

Let’s note a third important lesson

You must have addressed the interrelationships of technical faults, FS mechanisms and driver behavior in the FSC.

But now the really interesting question: how do you know if you already have enough safety requirements for the ASIL? For example, are two separate sensors required? Do I need a second power supply for an actuator for a certain transition period? What criteria must messages meet between two control units? There are rarely standard answers to such questions.

Some clues

  • Various vehicle type approval regulations contain concrete demands, such as the mechanical connection between the steering wheel and the wheels.
  • If applicable, use proven industry concepts and solutions, such as the E-Gas monitoring concept.
  • In automotive, it is sufficient if there is a single mechanism or an expected driver reaction that results in no one being hurt in the event of an electrical/electronic problem. In other words, single redundancy, a shutdown mechanism or an emergency operation is generally sufficient, unlike in aircraft design, for example. Or put another way: in justified exceptional cases, there may not even be a safety mechanism for a possible single-point fault.
  • And what about dual-point faults, i.e. faults that can only lead to the violation of a safety goal in combination with another fault? In this case, it is expected that they are detected, perceived and repaired within a reasonable period of time.
  • Then, ISO 26262 contains clear specifications in part 5 with regard to random hardware failures.
  • However, it’s not entirely clear regarding systematic failures. Message communication will always be protected against typical failure modes. Safety-related data must be protected against unauthorized access and bit errors. Sufficient performance of the microcontrollers must help to ensure that information about the vehicle status is available in a timely manner.
  • Often, a rule of thumb can be useful: look at the tables in annex D of hardware part 5 of ISO 26262. For ASIL C and D safety goals, choose measures with high, 99%, diagnostic coverage with respect to directly hazardous faults. For ASIL B, measures with medium, 90%, diagnostic coverage are sufficient.

At this point, I would like to capture three further lessons

  • ISO 26262 does not offer a universally valid safety concept. This is why there are many possible solutions open to you as authors.
  • There is no binding and universally valid answer to the question regarding which safety measures must be implemented for which application or which ASIL. Ultimately, this question is answered by a combination of requirements within ISO 26262, by vehicle type approval regulations, and by industry practice. Also, the safety assessor must agree with suggested solutions.
  • There should be no single-point faults, and dual-point faults should only occur intermittently.

OK, it’s probably now obvious that you can’t come up with a functional safety concept by brainstorming. You need to adopt a systematic approach and involve a whole variety of people. I will now shed some light on this aspect.

First of all, there is the concept itself, which is currently ‘work in progress’. You have to describe how individual safety goals will be achieved.

Don’t forget that it’s important to document relevant assumptions.
Then we have the central element of the functional safety concept: the set of functional safety requirements.

The criteria for safety validation must be specified.

Adopting a systematic approach includes assigning functional safety requirements to different elements of the vehicle architecture. This is to clarify the context within which each requirement is implemented.
And then comes what is perhaps the most important aspect when it comes to working systematically. You have to perform safety analyses. By using FMEAs and fault tree analyses, and by understanding dependencies between faults or proving independences between different architectural elements, you can ensure not only that the functional safety concept is adequate, but also that it’s complete.

This leads me to another lesson I want to capture

You must use safety analyses to underpin the safety concept.
Back to our systematic way of working. One essential tip must not be overlooked: your working methods will never be 100% sequential. There are always dependencies. When you’re working on one topic, it influences another. For example, adding an important safety mechanism may result in changes to the safety analysis and the architecture.

To complete the picture, it should be mentioned that your FSC must be subjected to a review and receive official confirmation after completion. Independent persons are called in. They apply checklists and experience to verify and confirm that the concept meets expectations.

Let’s keep two important points in mind
Creating a functional safety concept is an iterative process that takes you through the concept, requirements, architecture and analyses.

You need to have your finished functional safety concept confirmed independently.

Management of functional safety video

ISO 26262:2018 Part 2

In this tutorial, you'll look at how functional safety management spans the entire safety lifecycle - at the organizational level, in projects, and post-production.

Key learnings

So now you know a little more about FSCs and how to assess whether you have included enough safety features.

  • The FSC is created on a vehicle level, which is why it is the responsibility of the car maker.
  • As authors of the FSC, you must explain in an understandable way how each individual FS goal is to be achieved.
  • You must have addressed the interrelationships of technical faults, FS mechanisms and driver behavior in the FSC.
  • ISO 26262 does not offer a universally valid FSC, which is why there are many possible solutions open to you as the author.
  • There is no binding and universal answer to the question of which safety measures must be implemented for which application and which ASIL.
  • There should be no single-point failures and dual-point failures should only exist for a limited time.
  • You must use safety analyses to underpin the FSC.
  • Creating a FSC is an iterative process of concept, requirements, architecture and analyses.
  • You must have the completed FSC confirmed by an independent party.

So, if you work for a carmaker, it remains for me to wish you success in compiling your functional safety concept.

If you work for a supplier, hopefully you now have a better understanding of what to expect from the manufacturer in the areas that overlap with your products.

  • Improving your processes to keep them up to date with the latest safety standards – also so you can develop and sell reliable, available, maintainable and functional products
  • Designing and rolling out safety management systems
  • Conducting safety audits to confirm that your safety management fulfils relevant requirements
  • Knowing for certain if a supplier really can provide you with the right components
  • Building the capability to assess the functional safety of electronic systems and components 
  • Building the capability to provide staff training on all aspects of functional safety

Download White paper