Memory partitioning and implemented functional safety mechanisms

1. Application software

In the AUTOSAR architecture, the application software is located above the RTE and consists of interconnected AUTOSAR SWCs. These components atomically encapsulate various components of the application software function.

Figure 1: Application software

AUTOSAR SWC is hardware independent , and therefore can be integrated into any available ECU hardware. To facilitate information exchange within and within the ECU, AUTOSAR SWC communicates only via RTE.

AUTOSAR SWC contains many functions and variables that provide internal functionality. The internal structure of AUTOSAR SWC, namely its variables and function calls, is hidden from public view through header files. Only external RTE calls will take effect on the public interface.

##Figure 2: SWC

AUTOSAR SWC also contains functions that must be called at runtime. These C functions are called Runnables in AUTOSAR.

Runnables cannot be executed by themselves; they must be assigned to an executable entity of the OS. Such allocations can be performed by inserting function calls of Runnables into the OS task body.

Runnables are then executed cyclically and/or event-driven in the context of the caller OS-Task. The allocation of tasks by Runnables is performed according to Figures 3 and 4.

​

Figure 3: AUTOSAR layered software architecture-Runnables mapping

2. OS-Applications

Figure 4 shows an explanation of the relationships in Figure 3. According to this diagram, Runnables in AUTOSAR SWC are assigned to OS tasks.

Figure 4: Mapping of SWC to OS-Applications

AUTOSAR OS-Applications are a collection of OS objects (such as tasks, ISRs, schedules, counters, and alarms) that form a cohesive functional unit. All objects belonging to the same OS-Applications can access each other.

OS objects in OS-Applications may belong to different AUTOSAR SWCs. RTE implements a memory area that all members of OS-Applications have unrestricted access to facilitate efficient communication between SWCs.

There are two categories of OS-Applications:

1. Trusted OS-Applications: "Allow trusted OS-Applications to Run with monitoring or protection features disabled at runtime. They may have unrestricted access to memory and APIs of OS modules. Trusted OS-Applications are not required to enforce their timing behavior at runtime. When supported by the processor, they Allowed to run in privileged mode.
2. Untrusted OS-Applications: "Untrusted OS-Applications are not allowed to run with monitoring or protection features disabled at runtime. They restrict access to memory, restrict access to the OS module's API, and enforce its timing behavior at runtime. They are not allowed to run in privileged mode when the processor supports it.

3. Communication and code sharing

According to Figure 4 and Figure 3, one OS-Applications can contain multiple AUTOSAR SWCs and associated Runnables. Only Runnables are allowed to directly access variables and perform function calls in their respective SWCs.

SWC's internal function calls and variables are not publicly available to other SWCs because their definitions are not provided by the header files of the external interfaces, so direct communication through variables and execution of other SWCs cannot be planned. code.

In Figure 5, the code sharing example illustrates this. Code sharing is only allowed within a SWC and is not allowed to be shared between SWCs of an OS-Application. Communication with other SWCs should be performed via RTE. Runnable4 may not be able to perform functions belonging to SWC2.2.

​

Figure 5: Code sharing in OS-Applications

4. Memory partition in application software

The application software in AUTOSAR ECU can be composed of safety-related SWC and non-safety-related SWC. Interference-freeness between SWCs with different ASIL levels should be ensured in accordance with the requirements of ISO26262.

AUTOSAR OS is immune to memory-related failures by placing OS-Applications into exclusive memory areas. This mechanism is called memory partitioning. OS-Applications are protected from each other because code executed in the memory partition of one OS-Application cannot modify other memory areas. The corresponding requirements in the AUTOSAR OS specification are shown in Table 1.

##Table 1: Memory partitions of AUTOSAR OS- OS-Applications

Application software can be composed of SWCs with different ASIL levels. However, SWCs with different ASIL ratings should not be assigned to the same OS-Applications. Memory partitioning does not provide interference immunity between SWCs assigned to the same OS-Applications. The OS only prevents other OS-Applications from performing incorrect access. Does not prevent a faulty SWC from modifying memory areas of other SWCs in the same OS-Applications.

Note: For more information about task-level partitioning, see Subsequent Partitioning.

5. Memory Partitioning in SWC

Mixed ASIL SWC may be composed of Runnables with different ASIL ratings, so a support is needed that does not interfere between these Runnables execution environment. It is not possible to execute different Runnables of a SWC in different memory partitions for the following reasons:

Memory partitions are executed at the OS-Applications level. As shown in Figure 3 and Figure 4, a SWC can only be allocated to one OS-Applications, so there is only one memory partition. In addition, SWC Runnables can only be called by a task of OS-Applications.

As shown in Figure 6, SWC Runnables cannot be distributed to tasks of multiple OS-Applications.

Figure 6: SWC and partitions

Memory partitions cannot be used Separate Runnables in the same SWC. If it is necessary for the SWC to contain Runnables with different ASILs, and these Runnables need to be executed independently without interference, then memory partitioning at the OS-Applications level is not enough, memory partitioning must be performed at the task level. The method is shown in Figure 7.

Figure 7: Task-level partitioning

and task-level memory Partition-related requirements are listed in Table 2 of the AUTOSAR OS specification. The use of the weak word "may" indicates that the implementation of task-level partitioning is optional for AUTOSAR OS. Therefore, not every AUTOSAR OS implementation supports task-level memory partitioning.

Table 2: AUTOSAR OS Requirements – Task-Level Memory Partitioning

6. Implementation of Memory Partitioning

Various technical security concepts can be implemented at the system and software levels using the memory partitioning mechanism.

Figure 8 shows a possible implementation, while all base software modules are executed in a trusted/monitored mode memory partition (highlighted in red in Figure 8). Some SWCs are logically grouped and placed in separate non-trusted/user-mode memory partitions (highlighted in green). The selected software module belongs to the same trusted/managed mode memory partition as the base software module (see the fourth SWC highlighted in red in Figure 8). There may be multiple untrusted/user-mode partitions, each containing one or more SWCs.

The execution of SWCs in the untrusted/user-mode memory partition is restricted and cannot modify other memory areas, while the execution of SWCs in the trusted/monitor memory partition is not restricted.

Modern microcontrollers used for safety-related applications support memory partitioning through dedicated hardware (Memory Protection Unit (MPU)).

Note: It is assumed that memory slicing will be implemented on a microcontroller with MPU or similar hardware capabilities.

With typical MPU implementations, an untrusted application can be allowed access to multiple partitions of the microcontroller's address space. Access control is defined as a combination of read, write, and execute access. MPU configuration is only allowed in monitor mode.

Note: In some microcontroller implementations, the MPU is integrated into the processor core. Therefore, the MPU only controls access to the associated core. Other bus masters (such as DMA controllers and other cores) are not controlled by this segmented MPU instance.

The following table and use cases illustrate a set of possible scenarios when the configuration of the memory protection unit is derived from system requirements. NOTE: This table may not be complete for the capabilities of the specific hardware device being used.

Table 3: Memory protection configuration scheme​

Icon description:

X – Protection required

O – Optional protection

Note: From a performance perspective, there may be side effects due to bus contention, interface arbitration, etc.

Use Case 1: SWC is in the same partition.

• SWCs in the same partition can access each other's RAM areas and therefore potentially corrupt each other's memory contents.
• By definition, SWC cannot access peripherals because they should not know about the underlying microcontroller architecture. When SWC is allowed direct access to peripheral devices, an insecure system may be created.
  Use Case 2: SWC in different partitions.
• SWCs in different partitions cannot access each other's RAM areas and therefore cannot corrupt each other's memory contents.
• By definition, SWC cannot access peripherals because they should not know about the underlying microcontroller architecture. When a SWC is granted direct access to a peripheral device, a potentially insecure system can be created.
  Use Case 3: MCAL Driver
• MCAL driver is a collection of functions, such as read/write/initialization. They must be executed by another entity, such as BSW or CDD. See Figure 8 for details.
• The MCAL driver requires read/write access to the peripheral space of the corresponding peripheral hardware module. Depending on the hardware architecture, a monitor mode of the processor may also be required.

2.1.3 Detection and Response

Functional Safety Mechanism Memory partitioning provides protection by restricting access to memory and memory-mapped hardware. Code executed in one partition cannot modify the memory of another partition. Memory partitions can protect read-only memory segments, as well as protect memory-mapped hardware. Additionally, SWCs executed in user mode have restricted access to CPU instructions, such as reconfiguration.

The memory partitioning mechanism can be implemented with the support of microcontroller hardware (such as memory protection unit or memory management unit). The microcontroller hardware must be properly configured by the OS to detect and prevent incorrect memory accesses. Then monitor the execution of SWC in the untrusted/user-mode memory partition.

If there is a memory access violation or CPU instruction conflict in a non-trusted/user-mode partition, the erroneous access will be blocked and the microcontroller hardware will throw an exception. OS and RTE eliminate erroneous software partitions by performing a partition shutdown or restarting all software partitions of this partition.

Note: The actual response of the OS can be configured through the protection hook implementation. See the OS SWS[i] documentation for more details.

Note: The AUTOSAR document "Application-Level Error Handling Instructions"[ii] provides additional information on error handling. In the documentation, it is explained how error handling is performed and where the required data (e.g. substitute values) can be obtained from. Additionally, this document provides detailed instructions (User Manual) on how to perform OS-Applications/Partition termination and restart in AUTOSAR.

2.1.4 Limitations

1. Memory partitions of SWCs with the same ASIL rating.

The ISO26262 standard requires immunity between SWCs of different ASIL levels [iii]. However, the standard does not require interference immunity between SWCs with the same ASIL rating.

Allows the use of OS-Applications composed of a large number of SWCs. If a single SWC causes a conflict that causes an entire memory partition to be shut down or rebooted, all other functioning SWCs for this memory partition will also be affected.

#2. Memory partitioning is not available for trusted OS-Applications.

The execution of trusted/monitored mode memory partitions is not controlled by the OS and some MMU/MPU hardware implementations.

#3. Task level does not support memory partitioning.

#The implementation of task-level partitioning is not required for AUTOSAR OS implementation. Therefore, interference immunity in OS-Applications may not be supported.

#4. Performance loss due to memory partitioning.

Depending on the architecture of the application software and the implementation of the microcontroller hardware and OS, using memory partitions can reduce performance. This penalty increases with the number of context switches performed per time unit.

5. No basic software partition.

The current specification for the base software does not specify memory partitioning for base SWCs with different ASIL levels from different vendors.

The above is the detailed content of Memory partitioning and implemented functional safety mechanisms. For more information, please follow other related articles on the PHP Chinese website!