Software-Defined Vehicles Are Changing the Game for Functional Safety

 

here’s a major shift happening in the automotive world. As vehicles become more software defined, flexible, updateable, and connected, the way we think about functional safety has to change too.

If you’ve worked with ISO 26262, you know it’s built around systems that don’t change much after production. But that’s not today’s reality. Modern vehicles are constantly evolving, sometimes overnight, thanks to over the air updates. That’s exciting, but it’s also challenging when you’re responsible for making sure those updates don’t compromise safety.

Here’s a look at how this transformation is reshaping what functional safety means in practice.

Software Updates Don’t Wait for Safety Sign Off

In the past, safety functions were frozen long before a vehicle hit the road. Now, it’s common for a vehicle to get new features or behavior months (or years) after production.

The old assumption that a system stays fixed no longer holds.

So every update now raises the question: What could this change break?

• Safety cases have to be flexible and updateable
• Change impact analysis is becoming part of the release pipeline
• Post deployment monitoring is starting to play a bigger role

We’re moving from one time certification to continuous assurance.

More Software, More Complexity

With SDVs, we’re seeing a shift to centralized computing platforms, where one controller might handle everything from ADAS to infotainment. That’s efficient, but risky.

Now, safety critical and non critical software are living side by side on shared hardware.

That means:

• Stronger partitioning is essential (using hypervisors, safety islands, etc.)
• Teams need to coordinate more tightly across software layers
• You can’t assume isolation, you have to build it in

This added complexity makes safety analysis a lot more nuanced. But it also makes collaboration between teams even more important.

Fast Software Delivery Meets Slow Safety Processes

Engineering teams want to ship software fast. And customers expect regular updates. But safety reviews and validation cycles haven’t always kept up with that pace.

This tension is real.

That’s where we’re starting to see the rise of “Safety DevOps”, tools and processes that bring safety into CI/CD pipelines. It’s still early, but here’s what’s working:

• Automating traceability and safety evidence generation
• Running safety tests in every build
• Building safety reviews into the sprint cycle, not after the fact

It’s a mindset shift: safety isn’t a gate at the end, it’s part of the flow.

Cybersecurity Is Now a Safety Concern

With vehicles increasingly connected, a cyber vulnerability can turn into a safety hazard. Imagine a spoofed sensor signal or a hijacked update. That’s no longer just a data breach, it’s potentially a crash.

This has made cybersecurity and safety inseparable.

Teams are now:

• Combining threat analysis with safety analysis
• Cross referencing ISO 26262 with ISO 21434
• Looking at system level impacts of security failures

The message is clear: safety can’t ignore security anymore.

Third Party Software Is Part of the Equation

We’re all relying more on middleware, open source stacks, and third party software. But functional safety still demands control, traceability, and a deep understanding of failure modes.

This raises tough questions:

• Can we trust external code to meet our ASIL targets?
• What happens when that code updates on its own schedule?

Some ways teams are dealing with this:

• Wrapping uncertified code with safety monitors
• Defining strict interface requirements
• Being extra clear about software ownership and responsibilities

It’s not perfect, but it’s progress.

You Can’t Test Everything in the Real World Anymore

With SDVs, there are just too many edge cases and combinations to test everything physically. That’s why simulation is playing a bigger role in safety validation.

Digital twins, scenario libraries, and automated test frameworks are becoming essential.

The tricky part is proving that your virtual testing is enough:

• Are the scenarios realistic?
• Are the tools validated?
• Can you show equivalence to real world behaviour?

Safety engineers and simulation teams are working more closely than ever to make it all count.

Wrapping It Up

Functional safety isn’t going away, it’s just changing shape.

In a world of software defined vehicles, the goal stays the same: keep people safe. But the way we get there looks very different. It means adapting standards, changing how we work, and rethinking how we build confidence in systems that are always evolving.

It’s a challenge, but it’s also an opportunity to modernize safety for the vehicles of tomorrow.

Let’s Talk

If you’re working on SDVs, functional safety, or anywhere at the intersection of software and safety, I’d love to hear how you’re approaching these challenges. Are there tools, methods, or mindset shifts that have worked well for you?

Let’s share notes. Drop a comment or feel free to reach out to dcourtney@akkar.com