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
I would now like to explain which questions must be answered by the FSC. These are:
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.
At this point, I would like to capture three further lessons
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.