Software has become the defining element of modern vehicles. Features no longer remain fixed at the time of production but evolve through continuous over the air updates. This shift brings a new challenge for safety: how can we guarantee that every change still preserves the protection promised to drivers and passengers?
ISO 26262 standard continues to provide the foundation, but the Software Defined Vehicle requires these principles to be applied in a more dynamic way.
Functional Safety can no longer be treated as a one-time certification. It becomes an ongoing process with continuous ECU testing, and monitoring. The shift in architecture from distributed ECUs to zonal architecture also warrant new ways of looking at safety.
Functional Safety in Traditional Vehicles: The Pre-SDV Era
In conventional vehicles, safety responsibilities are distributed across many ECUs. Each ECU is designed for a defined function such as braking, airbag deployment, or power steering.
Functional safety responsibilities are localized and relatively stable. Here’s why:
- ECU centric design: Each ECU handles a specific function such as braking ECU or steering ECU.
- Static software: Updates are rare and mostly minor, so safety certification remains valid for the full lifecycle.
- One time validation: Safety goals are defined during design, tested before production, and then considered fixed.
- Clear boundaries: Hazards and countermeasures are tied to individual ECUs, making traceability straightforward.
This approach works well when software is static, and hardware boundaries are clear. Hazards are identified during design, Automotive Safety Integrity Levels (ASIL) are assigned, and safety mechanisms are built into each ECU.
Automotive ECU validation confirm that the required safety goals are met. After production, only minimal software changes occur, so the safety argument does not need constant revision.
The next step is to look at how Functional Safety is dealt with in SDVs. And for that, understanding the architecture choices, continuous validation processes, etc. is important.
Why Software Defined Vehicles Change the Equation
In the case of traditional vehicles, safety responsibilities were clearly tied to individual ECUs. Each unit was validated as per ISO 26262 standard once during development and then remained unchanged for the rest of the vehicle’s life. This approach worked because the architecture was stable, and the software rarely evolved.
Software Defined Vehicles change this context.
SDVs replace this model with centralized and zonal compute platforms that consolidate functions which were once spread across many ECUs. They also introduce continuous over-the-air updates that can alter system behaviour long after production. This means that safety cannot be treated as a one-time event.
When functions share the same compute platform, isolation and resource management become essential. A timing error or resource conflict in one application can influence another, including safety critical tasks.
Over the air updates add further complexity since new code may alter interfaces, timing budgets, or dependencies across domains. The safety case must therefore remain active, with new evidence generated for every release.
This transformation does not replace ISO 26262 but changes how compliance is achieved. Safety is now a property of the entire architecture and update process rather than of isolated ECUs.
Here’s a comparison table to show the contrast in the implementation of functional safety in legacy architecture vs SDVs.
| Aspect | Traditional Vehicles | Software Defined Vehicles |
| System structure | Distributed ECUs, each tied to a single function | Zonal controllers and central compute hosting multiple functions |
| Software updates | Rare and minor | Frequent, over the air, feature-rich |
| Functional Safety model | One time certification per ECU | Continuous assurance across architecture and updates |
| Traceability | Clear, limited to ECU level | Complex, spans SoC vendor, middleware, cloud, and applications |
| Failure isolation | Localized to ECU | Requires partitioning, safety islands, and strong resource management |
Role of Architecture and ISO 26262 Compliance in SDVs
When vehicles relied on many small ECUs, safety was managed inside each unit. SDVs run on shared platforms made up of zonal controllers and central computers. This system-level shift has a direct impact on how ISO 26262 is applied.
Why Architecture Matters
In SDVs, safety depends less on isolated components and more on how the whole system is organized. If steering, braking, and infotainment system share the same compute platform, the design must make sure that faults in one area cannot affect the others. This is where system-level partitioning and strong architectural rules become essential.
Some key measures include:
- Separating safety-critical and non-safety tasks so that they do not interfere with one another.
- Ensuring that system resources like memory and communication buses are managed fairly and predictably.
- Designing safe fallback modes, so the vehicle can still protect passengers if one part of the system fails.
Continuous Validation
The biggest change with SDVs is that software does not stop evolving once the car leaves the factory. Over-the-air updates bring new features but also new risks. Each update must show that it does not compromise safety.
This requires:
- Regular regression testing across the entire vehicle system.
- Scenario-based validation to cover unusual or edge cases.
- A process for rolling back updates safely if issues are detected.
Shared Responsibility Across the Ecosystem
ISO 26262 compliance is no longer the job of a single supplier. It now involves the SoC vendor, the middleware provider, the cloud platform that delivers updates, and the application developer. Safety must be proven at the system level, with each party contributing evidence that their piece fits securely into the bigger picture.
Conclusion
Functional Safety has always been essential in automotive development, and that does not change with Software Defined Vehicles. What changes is the way safety is demonstrated. For OEMs and suppliers, the key takeaway is that Functional Safety in SDVs is not a fixed milestone but an ongoing responsibility. By approaching safety at the system level, by coordinating closely across the ecosystem, and by building processes that keep safety evidence current, the industry can deliver vehicles that remain both innovative and dependable
