Software Defined Vehicles (SDVs)

Why Software Defined Vehicles (SDVs) are critical to support future mobility

While the term “Software Defined Vehicles” has many definitions, it generally refers to a vehicle that manages operations, adds functionality, and enables new features primarily through software. It is also helpful to think of a SDV as a vehicle design strategy to help enable intelligent mobility rather than one specific design. Either way, SDVs are gaining attention for their ability to provide the increased bandwidth needed to support the complex data transmission needs of future mobility.

Traditional vehicle architecture uses integrated hardware and software, which ties functionality and performance together. This format limits the ability to innovate and adapt to modern demands. SDVs decouple hardware and software functionalities to allow for continuous updates, enhanced customization, and improved performance. Once decoupled from hardware, software can move beyond auxiliary control to lead overall vehicle definition. As a shared resource, hardware will become accessible to various software applications. Although upgrading hardware is difficult, it will become necessary during the vehicle's life cycle to satisfy increasing functional requirements. The technical elements of the SDV ecosystem are detailed in Figure 1 [1].  SDVs have gained more interest as software becomes more important to enhance functionality, performance, service, and overall vehicle user experience.

Figure 1. Software Defined Vehicle (SDV) Ecosystem.

Two Key Challenges to SDV Adoption

Safety

Safety requirements pose a challenge when integrating applications of varying criticalities (e.g., multiple Automotive Safety Integrity Levels (ASILs)) because they require demonstrating the system’s suitability for its intended use through a comprehensive safety case.)

Safety systems can be classified as either “fail-silent”, which goes into a degraded or off state, or “fail-operational”, which continues to function to some extent even after a failure. When a distributed multi-core processor is used to integrate safety functions with mixed criticalities, the system must demonstrate the isolation, separation, and independence of the safety and non-safety functions. At this point, developing safety-related systems becomes challenging for developers since they must adhere to functional safety standards that are beginning to include specific requirements for multi-core devices but there are still some areas where the requirements are not complete (see ISO 26262-11:2018 [2]).

Integration of multi-core processors

The integration of multi-core Real-Time Operating Systems (RTOS) in the SDV environment plays a vital role in managing the complexity of intelligent Advanced Driver-Assistance Systems (ADAS) and Autonomous Driving System (ADS) to consolidate vehicle functionality into updatable software applications, simplifying vehicle architecture and enhancing connectivity and scalability.

The challenge is how to ensure real-time performance and predictability for safety-related applications. Due to the non-deterministic nature of multi-core processors (i.e., absence of symmetric multiprocessor scheduling (SMP)), sharing memory and resources between safety and non-safety tasks does present some difficulties.

For instance, the ISO 26262 safety standard [2] requires that, whenever a system integrates safety functions of mixed criticalities, there must be demonstrable Freedom from Interference (FFI) between these functions to prevent interference or a violation of the safety requirements of a function with higher ASIL caused by the failure of a function with lower ASIL.

The claim that multi-core systems must ensure FFI can be supported by virtualization technologies. However, virtualization usually falls short in terms of providing adequate prevention or detection of permanent or transient faults affecting the multi-core (ISO 26262-11:2018 § 5.4.2.2 [2]). In this context, FFI can be achieved with the support of strategies like hypervisors to create and isolate mixed-criticality execution environments, also known as the spatial independence safety mechanism.

The temporal (i.e., scheduling) independence for achieving FFI is another essential safety measure. The development of time-predictable software components provides a solid foundation for achieving temporal independence within the Worst-Case Execution Time (WCET) against temporal fluctuations. Additionally, methods like run-time monitoring diagnostic and time-constraint monitoring can be used to detect systematic and random errors.

The transition to Software Defined Vehicles represents a significant shift in the automotive industry, offering substantial benefits in terms of functionality, performance, and user experience. While this shift presents challenges, there are effective strategies to address these issues. Emphasizing the importance of adhering to ISO 26262 safety standards, this document outlines practical solutions such as the use of hypervisors and time-predictable software components to ensure FFI and real-time performance. By addressing these challenges and implementing the proposed solutions, OEMs and developers can pave the way for the successful adoption of SDVs, ultimately leading to more intelligent, scalable, and reliable vehicles.


HORIBA MIRA, a specialized team within HORIBA, provides pioneering engineering, research and test services with 75 years of experience developing some of the world’s most iconic vehicles.


Bibliography

Request for Information

Do you have any questions or requests? Use this form to contact our specialists.

* These fields are mandatory.

Corporate