Functional Safety Concept acc. to ISO 26262:2018

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.