Hello guys, welcome back to our blog. This article will discuss functional safety in software-defined vehicle architecture, functional safety challenges in software-defined vehicles, and safety mechanisms in modern SDV architecture.

Ask questions if you have any electrical, electronics, or computer science doubts. You can also catch me on Instagram – CS Electrical & Electronics

Functional Safety (ISO 26262) In Software-Defined Vehicle (SDV) Architecture

Functional safety is an essential domain within automotive engineering that ensures the safe functioning of systems, especially in the presence of faults. It involves designing systems that respond predictably and safely to errors or failures, preventing hazards to users and the environment. In modern automotive development, where vehicles are increasingly controlled by complex electronic systems and software, functional safety becomes critically important.

ISO 26262 is the international standard specifically developed for functional safety in the automotive industry. It provides a structured approach to identifying, assessing, and mitigating risks associated with electrical and electronic systems in vehicles. The standard spans the entire product lifecycle, from concept to decommissioning, ensuring safety across all phases of development and operation.

The implementation of ISO 26262 is built around the concept of a safety lifecycle, incorporating activities such as Hazard Analysis and Risk Assessment (HARA), the assignment of Automotive Safety Integrity Levels (ASILs), and development in accordance with safety goals. As vehicles evolve from mechanical machines to complex digital systems, ISO 26262 ensures that these innovations are introduced without compromising safety.

The Rise of Software-Defined Vehicles (SDVs)

The automotive industry is undergoing a transformation towards Software-Defined Vehicles (SDVs). In contrast to traditional vehicles, where functionality is tightly coupled with hardware, SDVs are defined by software, allowing for a higher degree of flexibility, scalability, and adaptability.

SDVs rely on centralized computing platforms, with domain or zonal controllers replacing the traditional distributed Electronic Control Unit (ECU) architecture. This centralized architecture enables:

Easier software updates through Over-the-Air (OTA) mechanisms
Continuous feature enhancement post-production
Simplified maintenance and diagnostics
Integration of advanced functionalities such as autonomous driving and predictive maintenance

Moreover, SDVs support DevOps-like workflows in automotive software, incorporating Continuous Integration/Continuous Deployment (CI/CD) practices. These software-defined capabilities introduce new paradigms but also create unprecedented challenges for ensuring system safety.

Challenges of Functional Safety in SDV Context

The software-centric nature of SDVs poses several unique challenges in the application of ISO 26262:

Continuous Evolution of Software: Unlike static systems, SDV software evolves over time. Ensuring safety across multiple versions and updates requires dynamic safety assessments.

Virtualization and Consolidation: The use of hypervisors and virtual machines in SDVs to isolate applications or operating systems complicates safety validation, requiring new verification methods.

Shared Computing Resources: Centralized computing platforms serve multiple domains (e.g., infotainment, ADAS, powertrain), increasing the complexity of fault isolation and resource partitioning.

Third-Party and Open-Source Software: Incorporating software from multiple vendors, including open-source components, introduces uncertainty in safety analysis and traceability.

AI/ML Algorithms: Advanced features like perception and decision-making in autonomous driving use non-deterministic AI/ML algorithms, which are inherently difficult to verify using traditional methods.

Cyber-Physical Systems: SDVs operate at the intersection of cyber and physical domains. Functional safety must be assured despite increasing exposure to cybersecurity threats.

These challenges necessitate evolving ISO 26262 practices, introducing new methodologies, and integrating cybersecurity standards like ISO/SAE 21434 into safety lifecycles.

ISO 26262 Overview and Key Parts Relevant to SDVs

ISO 26262 is divided into 12 parts, each addressing different aspects of functional safety. In the context of SDVs, the following parts are particularly critical:

Part 2: Management of Functional Safety – Establishes the framework and organization-wide practices required to ensure safety culture and governance.

Part 3: Concept Phase – Involves defining the system and conducting HARA to derive safety goals.

Part 4: Product Development at System Level – Translates functional safety requirements into system architecture.

Part 5: Product Development at Hardware Level – Addresses the design, verification, and validation of hardware components.

Part 6: Product Development at Software Level – Defines processes for software development, verification, and tool qualification, crucial for SDVs.

Part 8: Supporting Processes – Includes configuration management, change management, and tool qualification.

Part 9: ASIL-Oriented and Safety-Oriented Analyses – Guides the use of FMEA, FTA, and DFA for safety evaluation.

Part 11: Guidelines for Semiconductors – Pertinent due to the use of advanced SoCs in SDVs.

ISO 26262 follows the V-model, ensuring traceability from system requirements to implementation and testing. In SDVs, this traceability must extend to runtime software updates and cloud-based functionalities.

Safety Lifecycle Applied to SDVs

Applying ISO 26262’s safety lifecycle to SDVs involves tailoring each phase to the dynamic and software-intensive nature of the architecture:

Item Definition: In SDVs, the item may not be static. It includes software modules, communication services, and cloud-connected functions. The definition must consider variations introduced by OTA updates.

HARA (Hazard Analysis and Risk Assessment): HARA must evaluate the operational scenarios that may change dynamically. For instance, enabling autonomous driving via software post-sale introduces new hazard scenarios.

Functional Safety Concept: Safety goals must account for software interactions, user-configurable settings, and integration with cloud services.

Technical Safety Concept: Redundancy, watchdogs, and secure inter-partition communication are key architectural elements in SDVs.

Development and Integration: Emphasis is placed on modularity, traceability, and integration testing using virtual environments and Hardware-in-the-Loop (HiL) simulations.

Verification and Validation: Software must be rigorously tested for determinism, correctness, and fault tolerance using a combination of static analysis, model checking, and fault injection.

Production, Operation, and Maintenance: Safety extends beyond manufacturing. Tools for runtime monitoring, diagnostic logging, and rollback mechanisms are essential to maintain safety throughout the vehicle’s lifecycle.

ASIL Determination and Decomposition in SDVs

ASIL (Automotive Safety Integrity Level) classification helps determine the rigor of processes applied to a component or function. Determination is based on:

Severity (S): The potential harm caused by the hazard
Exposure (E): The frequency with which the operational condition occurs
Controllability (C): The ability of the driver or system to control the situation

In SDVs, ASIL determination may apply to software containers, service-based architectures, or even cloud APIs. Given the complexity, ASIL decomposition is often employed to break down high ASIL levels into lower-ASIL components with adequate independence and safety mechanisms.

For example, a safety-critical decision function (ASIL D) may rely on multiple ASIL B components protected by a monitor mechanism (e.g., watchdog, heartbeat).

Safety Mechanisms in Modern SDV Architectures

SDVs require a range of technical safety mechanisms that go beyond traditional ECU designs. Key strategies include:

Redundant Computation: Dual-core lockstep, time and value redundancy for mission-critical tasks.

Memory Protection and Virtualization: MPUs and hypervisors to separate memory and execution environments.

Health Monitoring: Runtime diagnostic frameworks to monitor software integrity and hardware performance.

Watchdog Timers: Reset systems upon software anomalies or stuck states.

End-to-End Communication Protection: Data consistency checks, cyclic redundancy checks (CRC), and secure transport.

Fail-Safe and Fail-Operational Modes: Graceful degradation strategies, ensuring essential functions remain operational.

These mechanisms are essential for meeting the stringent safety goals and supporting compliance with ISO 26262 in the high-performance environment of SDVs.

Role of AUTOSAR, Adaptive AUTOSAR, and Virtual ECUs

AUTOSAR plays a central role in enabling standardization and safety in automotive software. In SDVs:

Classic AUTOSAR is used for real-time control functions (e.g., powertrain, braking) where deterministic behavior is critical.
Adaptive AUTOSAR targets high-end processors and supports dynamic service-oriented applications, suitable for functions like automated driving and infotainment.

Both platforms provide standard interfaces, safety extensions, and guidelines compatible with ISO 26262. Virtual ECUs (vECUs) enable early-stage testing, software-in-the-loop (SiL) verification, and regression testing before actual hardware is available. This supports a front-loading approach to safety validation.

Cybersecurity vs. Functional Safety in SDVs

While functional safety ensures systems behave predictably in case of unintentional faults, cybersecurity addresses intentional threats from malicious actors. However, in SDVs, these domains are deeply interconnected.

A cybersecurity breach can trigger functional safety hazards. For instance, a compromised ADAS system may misinterpret surroundings, leading to unintended acceleration. Therefore, functional safety must be designed considering cybersecurity implications.

Standards like ISO/SAE 21434 help align cybersecurity practices with ISO 26262. Combined safety-security development practices include:

Threat and Risk Assessment (TARA) along with HARA
Secure boot and runtime integrity checks
Encrypted communication and authentication protocols

Conclusion and Future Outlook

As the automotive industry continues its shift toward software-defined platforms, functional safety remains a cornerstone of vehicle development. ISO 26262, while mature, must continue evolving to address the dynamic nature of SDVs, the incorporation of AI, and the convergence with cybersecurity.

In the future, we can expect:

Greater integration between ISO 26262 and ISO/SAE 21434
Development of safety extensions for AI-based functionalities
Broader adoption of tools that automate safety analysis, traceability, and validation
Cloud-based safety validation and continuous in-field safety monitoring

Ultimately, achieving functional safety in SDVs is not just a technical necessity but a foundational principle for customer trust, regulatory approval, and brand integrity.

This was about “Functional Safety (ISO 26262) In Software-Defined Vehicle (SDV) Architecture“. Thank you for reading.

Also, read:

About The Author

Chetan Shidling

Automotive | Technical Blogger | Engineer | Content Creator

See author's posts

Share Now