Decoupling means the separation of functions. In SDV development, it refers to the separation of software and hardware or the separation of software with different safety or security levels.

This article looks at the background to why the decoupling of safety functions is needed and explains how it is achieved.

Why decoupling of safety functions is essential

The term "Software-Defined Vehicle" (SDV) frequently comes up at automotive trade shows and industry seminars.

The Mobility DX Strategy formulated by Japan’s Ministry of Economy, Trade and Industry (METI) and Ministry of Land, Infrastructure, Transport and Tourism defines SDVs as "next-generation automobiles that continuously update their functions through cloud communication to realize new value not found in conventional automobiles, such as advanced driving functions”.

As the phrase "automobiles that continuously update their functions" suggests, software development for the vehicles of the future will not end when mass production starts. Rather, it will require the continuous addition and update of after-market software through OTA (“Over-the-Air”).
This is why SDV is often described as the "smartphone-ization of automobiles”.

However, automobiles and smartphones have different requirements. Not least of these is that vehicles require a high level of safety.

One example is how map data on smartphones is frequently updated. In rare cases, problems in this data update process may cause the application to stop working, or even worse, an entire system shutdown.
In automobiles, however, the shutdown of such applications is not acceptable, even if it only involves map data. This is not only because it puts the system itself out of service, but also because it may endanger the lives of passengers if autonomous driving systems are among the users of the map data.
It is vital that basic vehicle control functions such as those for driving, turning, and stopping continue to work correctly even if the map application is not behaving as intended.

This is why the decoupling of safety functions that directly affect the lives of passengers from other functions is essential for vehicles in the SDV era.

How decoupling is achieved

The following are two ways in which safety functions are decoupled from other functions. 

The first is the decoupling of safety functions at the CPU level.
Most recent chips are heterogeneous, meaning they have a mix of CPU architectures.
An Arm-architecture CPU chip, for example, may have both an Arm Cortex-R CPU designed for control processing and an Arm Cortex-A CPU for executing high-level functions.

This heterogeneous chip configuration ensures a high degree of decoupling by providing choice in the allocation of processors for safety functions and other processing.

In the above Arm example, safety functions such as driving, turning, and stopping are allocated to the Arm Cortex-R processor and high-level functions such as navigation and infotainment are allocated to the Arm Cortex-A processor. This physically decouples safety functions from these other functions.

On the other hand, physical decoupling at the CPU level reduces the flexibility of system configuration.
As in the examples below, mixing safety and other functions on the same processor poses problems:

• CPU resources used for safety functions have excess capacity, making it desirable to  　implement other functions on the same CPU.
• Since the CPU resources for safety functions are not sufficient, it is desirable to implement 　some safety functions on the CPU intended for high-level functions.

Accordingly, a second decoupling method is used to decouple safety and other functions at the software level.
In this example, eSOL’s  eMCOS^® RTOS is used for OS-level decoupling.

The functional safety standard for automotive applications (ISO 26262) defines the following three forms of interference that require decoupling for safety reasons:

1. Timing and Execution
2. Memory
3. Exchange Information.
   
   

eMCOS provides mechanisms for preventing timing and execution interference as well as memory interference.
(The exchange of information is not dealt with here as it refers to communication between applications and is generally provided at the platform layer.)

Timing and execution interference is prevented by the following method.
eMCOS provides three types of scheduling for decoupling safety processing from other processing in terms of temporal separation. These are priority-controlled scheduling, which assigns priorities to threads, processes, and other processing units and gives priority to high-priority processing; hierarchical scheduling, which divides multiple threads into hierarchical groups and assigns different scheduling policies or execution times to each group; and round-robin scheduling, which assigns a certain amount of waiting time to processes and virtual machines in turn.

Memory interference, meanwhile, is prevented as follows.
Standard methods for decoupling memory space include the use of an MMU to separate process execution spaces and the use of virtualization extensions such as hypervisors for virtual machine isolation. In addition to these, eMCOS can also isolate system services such as device drivers and middleware from the OS.
While system services and the OS are commonly allocated to the same memory space, the risk of doing this is that a failure in a system service may affect the OS that provides the decoupling functions.
For example, a failure caused by a vulnerability in the network stack could affect the operating system and, in the worst case, cause an entire system shutdown.
To improve overall system security, eMCOS allocates system services and the OS to separate memory spaces, thereby providing a configuration in which the OS is not affected by failures or vulnerabilities in the system services.

While this software-level decoupling of safety and other functions is less isolated than physical CPU-level decoupling, it provides more flexibility for system configuration.

Conclusion

This article has explained the background to why safety function decoupling is necessary for SDVs and how this is achieved in practice.

Leveraging its world-class in-vehicle software technology and many years of experience in real-time OS development, eSOL offers unique "full stack engineering solutions" for heterogeneous, safety- and mission-critical system development.

We can make flexible proposals to meet your needs, so please feel free to contact us if you are considering this option.