Applied FuSa

SAVE THE DATE - PLANNED START: 12.08.2025  12:00 PM CET NEW EPISODES EVERY OTHER WEEK !!!

Safety Culture - a topic that can be discussed for hours. What exactly is a Safety Culture? Must a specific Work Product be created? In this episode we examine in detail the ISO26262 requirements for Safety Culture in order to shed some light on the matter.

Hello and welcome to a first episode of “Applied FuSa,” a podcast for FuSa pragmatists. 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.

Hello and welcome to a new episode of “Applied FuSa,” the podcast for FuSa pragmatists! 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.

Hello and welcome to a new episode of “Applied FuSa,” a podcast for FuSa pragmatists. 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.

Interestingly, even 14 years after the release of the first version of ISO 26262, there are still no standardized templates for the Safety Plan and the Safety Case. What we often see instead are simple lists of the work products defined in the standard. However, it’s questionable whether such lists actually meet the ISO’s requirements for these two deliverables. At least in the case of the Safety Case, that’s likely not the case. 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.

Have you ever been asked to perform a HARA for an ADAS function — and found yourself wondering whether that really makes sense? 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.

According to ISO 26262, an impact analysis must be performed at the beginning of a project to identify work products that can be tailored, provided the project is based on a predecessor project. Differences between the two projects are assessed with respect to the following three categories: Changed requirements;Revised design; andNew integration environment. 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.

The strict separation of functional and technical safety concepts is one of the most important principles in functional safety—and for good reason. This not only affects the scope of the two work products but also their respective responsibilities and the impact this separation has on the efficiency of safety concepts.

Hello and welcome to a new episode of “Applied FuSa,” a podcast for FuSa pragmatists. Today we'll be talking about hierarchies of functions. What this is about, and why this topic is so enormously important for functional safety... You'll find out shortly.

Hello and welcome to a new episode of “Applied FuSa,” a podcast for FuSa pragmatists. 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.

Hello and welcome to another episode of “Applied FuSa,” a podcast for FuSa pragmatists. 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.

Hello and welcome to a new episode of “Applied FuSa,” a podcast for FuSa pragmatists. 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. 

Hello and welcome to a new episode of “Applied FuSa,” a podcast for FuSa pragmatists. 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?