Functional Safety

Expert Perspectives: Integrating Safety of Intended Functionality (SOTIF) Into the Automotive Requirements Engineering Process

By |
People talking to each other with a stack of books to discuss the topic of SOTIF for automotive requirements engineering.

In this blog, we’ll recap a section of our recent Expert Perspectives video, “Integrating Safety of Intended Functionality (SOTIF) Into the Automotive Requirements Engineering Process” – Click HERE to watch it in it entirety.

Expert Perspectives: Integrating Safety of Intended Functionality (SOTIF) Into the Automotive Requirements Engineering Process

Welcome to our Expert Perspectives Series, where we showcase insights from leading experts in complex product, systems, and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future of their fields.

In this episode, we speak with Dr. Hasan Ibne Akram on the topic of Integrating Safety of Intended Functionality (SOTIF) Into the Automotive Requirements Engineering Process.

Watch this video to learn more about:

  • The differences between SOTIF and functional safety
  • How to define and manage safety requirements addressing system limitations and edge cases
  • How to conduct a hazard analysis and risk assessment to cover intended functionality

Below is a preview of our interview. Click HERE to watch it in its entirety.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Automotive

Kenzie Ingram: Welcome to Our Expert Perspective series where we showcase insights from leading experts in complex product systems and software development, covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future in their fields. I’m Kenzie Ingram, your host.

And today I’m excited to welcome Dr. Hasan Ibne Akram, an entrepreneur, computer scientist, book author, and CEO of engineering service company Matrickz based in Munich, Germany. With more than 17 years of experience in the automotive industry and working for two of the major German automotive OEMs, Dr. Akram brings a wealth of knowledge to this conversation. Today, we’re excited to showcase a discussion between Matt Mickle, Jama Software’s Director of Automotive Solutions, and Dr. Akram, on integrating safety of intended functionality, also known as SOTIF into the automotive requirements engineering process. Without further ado, I’d like to welcome Dr. Akram and Matt Mickle.

Matt Mickle: Thanks everyone for joining us today. My name is Matt Mickle. I’m the Director of Solutions for Automotive and Semiconductor at Jama Software. And I’m joined here today by Dr. Hasan Ibne Akram. Thanks very much for joining us today and answering some questions around integrating SOTIF into the automotive requirements engineering process. Dr. Akram, maybe we could start by just you telling us a little bit about yourself and your history with SOTIF and other industry standards and just a little bit about your background.

Dr. Hasan Ibne Akram: Absolutely. Thank you so much, Matt, for having me here. It’s amazing that we are having this conversation because this is very relevant today.
So my background in automotive started way back in 2005. So I was still a student, but I really wanted to go for a start-up. And back then, I landed a project with Continental. It was a braking system calculation project, and that’s how I got into automotive. And kept doing automotive stuff ever since.

And then, when I started my safety journey, I actually had no clue. So the first encounter to safety was a long time ago when I was actually working at a [inaudible 00:02:30] OEM as an external consultant. I was more responsible for the software. And during the lunch break, the functional safety colleague of that OEM, and in German, we call it FuSi, Funktionale Sicherheit, we used to call it FuSi. So I asked him, “What FuSi, the thing that you’re doing all the time? What is it about?” And quite condescendingly, he said, “We assume that whatever you guys are doing over there, every line of code, everything that you will do will go wrong.”

RELATED: Jama Connect® for Automotive

Akram: That was kind of like a light bulb moment for me. “Wow, that’s interesting. What happens when everything goes wrong? What do we do?” That was really my genesis of the functional safety journey. And SOTIF didn’t exist back then, was doing ISO 26262. And during my PhD, I was specialized in automotive cybersecurity, so cybersecurity and functional safety, I really wanted to bring them together.

And then, we realized, the automotive industry realized that, hey, there is something missing. Because with traditional safety, the definition of traditional safety is all about malfunction, if something goes wrong. Even when we’re doing security, it’s beyond malfunction, it’s all about attack now.Now comes autonomous vehicle, kind of like ADAS’s features, active distance control, automated emergency brake, active cruise control, and different levels of autonomy, Level 1, Level 2. The definitions came much later, but the idea of SOTIF was, hey, there’s something inherently required, there’s something required, something missing, inherently missing in the current standard because there can be hazards beyond malfunction.

It’s all about intention and this is where SOTIF was created, that we will talk about safety of the intended functionality. And my involvement, like you wanted to ask, my involvement with all these standards, I was following these standards before from the very ideas because the community is very, very close community. All the safety people in my podcast, I had Hans-Leo Ross, I had people who are the… Hans-Leo Ross even showed the birth certificate of ISO 26262 because he literally wrote the first lines and everything of ISO 26262. And I was privileged to be around these people who are actually shaping the future of these standards and how the engineering work will be done in the autonomous vehicle sphere and safety will be defined. So yeah.

RELATED: The Impact of ISO 26262 on Automotive Development

Mickle: Nice. Well, that must’ve been quite enthralling at the time. So you mentioned that there was this gap sort of missing for functional safety and that SOTIF sort of filled that gap. Could you describe some of the key differences that are there between the standards?

Akram: Absolutely. So the key difference is, like I said, there was a gap. The gap was pretty evident, we’re talking about malfunction. If there is a fault, that fault would lead to a hazard, that’s ISO 26262, that’s traditional functional safety.

Now, what happens if there is nothing wrong in the vehicle, no malfunction, and we still have a hazard? So let me give you a metaphor. Imagine that you have a knife and you bought the knife. Your intention is to chop vegetables. So it’s a very sharp knife. The functionality is great, you’re chopping the vegetable, there is no malfunction, you’re chopping the vegetable. Now, by mistake, unintentionally, you cut your finger with it, it’s a hazard. Now, there is no malfunction still in the knife, the knife is 100 percent functional, it’s your intention that was to chop vegetables, but somehow, unintentionally, you cut your finger. And that’s where the safety of the intended functionality came in.

The famous example of such hazard is this high profile Tesla incident that happened, I don’t know, five, six years ago, where in a junction, because of the lighting condition, Tesla’s ADAS system could not recognize a truck that was passing the junction. And the driver happened to be watching Harry Potter and he didn’t pay attention. And this was fatal, I mean, the driver died. This was such a fatal accident. And there was nothing wrong in Tesla’s ADAS functionality, it’s just that this certain condition, there was no malfunction, this certain condition was not trained, and the ADAS system was not able to detect under certain lighting condition.

And that was the reason, but when we entered, when we started with this, it turned out vastly complex, the whole sphere of SOTIF, when you’re talking about the environment. I’ve just given you one example. So the environment is theoretically infinite. There can be infinite situations and there can be situations that we don’t know about. And the fact of the matter is, we don’t know what we don’t know. When you know something, you can take measure, that’s traditional ISO 26262. Now, we have this unknown unknown. You don’t even know what you don’t know. So that makes it extremely challenging and that’s why the whole process of autonomous vehicle development is going to be a continuous development process, we’ll have to continuously learn and incorporate safety and all those.

THIS HAS BEEN A PREVIEW OF OUR VIDEO AND TRANSCRIPT –
CLICK HERE TO WATCH THIS INTERVIEW IN ITS ENTIRETY:
Expert Perspectives: Integrating Safety of Intended Functionality (SOTIF) Into the Automotive Requirements Engineering Process

Matt Mickle
Latest posts by Matt Mickle (see all)