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.