Confirmation Measures, which means Confirmation Review, Audits and Assessments. In today's episode, we'll examine their significance and how to implement them in practice. We'll pay special attention to the topic of Level of Independence. Do audits and assessments always have to be conducted by external providers? Are internal auditors and assessors independent enough? These are questions we will answer.

Tool evaluation and qualification… there is hardly any other task in the FuSa universe that has caused so much uncertainty. At least, that’s the impression gained from many internal and external discussions (for instance, at FuSa conferences and workshops). Actually, the topic is not that complicated. But the devil is very much in the details. We will illustrate this using the example of compiler evaluation.

We will also share a few suggestions on how the effort involved can be significantly reduced.

Release for Production Report is a work product that is created at the end of a product development process to authorize a safety-related product for production.

ISO 26262 specifies only five requirements for the Release for Production in Part 2, Section 6.4.13, which will be presented in this episode. In addition, we will also answer the question:

Who should own the Release for Production Report?

In this episode, we will answer one of the most crucial questions in any safety-related project: How do I know that my product is sufficiently safe? And what exactly is the difference between compliance and achievement of functional safety?

Note: The scope of this episode is limited to the safety of a supplier's design. In addition, non-technical requirements like compliance with standards still apply, of course. 

Functions are often broken down into sub-functions. A typical reason for this is that it can be easier to implement sub-functions rather than the complete function.

This strategy is relevant to functional safety for two reasons:

1. Depending on how the function is broken down into sub-functions, the ASIL of the sub-functions may be reduced; and

2. The usually lower complexity of sub-functions not only reduces the validation effort but also the risk of failure.

In ISO 26262, this type of breakdown is referred to as requirements decomposition, provided the sub-functions meet certain criteria — for instance, complete independence. In this episode, we will present the exact requirements for such a requirements decomposition in detail, explore its benefits, and discuss its limitations.

What’s actually the difference between functions and systems? And why is this relevant for functional safety at all? Is it enough to have requirements documents for either functions or systems, or are both always needed? Simple questions, with simple answers — but far-reaching consequences.

In this episode, we will not only introduce the method itself, but also explain why an impact analysis makes sense not just at the beginning of a project.

In this episode, we’ll start by explaining what a HARA is all about, and then show why HARAs don’t make sense for every type of function.

In today’s episode, we’ll take a completely different approach—by presenting a solution that integrates both work products. In other words, a deliverable that serves as both a Safety Plan and a Safety Case.

The DIA, or Development Interface Agreement, is often used as a document whose sole purpose is to allocate responsibility for FuSa work products between customer and supplier. Who is supposed to develop what, and in what form – if any – should the results be exchanged. That’s it.

That’s it? Does that really meet the requirements of ISO 26262? Or do those requirements perhaps go beyond that? Let’s take a closer look.

The role of the Functional Safety Manager (FSM) established itself shortly after the first version of ISO 26262 was published in 2011. Usually, this role is explicitly assigned in safety-relevant projects—meaning a single employee takes on the role of FSM.

And yet, to our surprise, the role of the FSM is not defined anywhere in ISO 26262.

“What??”

You heard that right: The role of Functional Safety Manager does not exist in ISO 26262. But there is the role of Safety Manager.

“Isn’t that the same thing?”

No, not really.

In this episode, we will compare the role of the Safety Manager with the widely established role of the FSM. We will also look at if and how ISO 26262 defines responsibilities and accountabilities for work products like the Safety Plan, the Development Interface Agreement (DIA), and the Safety Case.

Today, we’re providing a general overview of the motivation, goals, and fundamental approaches to functional safety. The aim is to create a common starting point for all listeners—whether you’re a complete beginner or a seasoned expert.