Memory Stack Overview

Micael Coutinho,Wed Nov 09 2022 • autosar bsw mem

The ability to read and write data persistently over multiple driving cycles is crucial for ECU functions. Learn how the Autosar memory stack works here

During the lifecycle of a vehicle, there are many variables that need to be written and read persistently. This ranges from calibrating a new sensor or actuator after replacing a defective one, storing and reading out error memory every time a vehicle is serviced, among other things. We already explored one way to change parameters in runtime, through calibration (you can read about this process here, in our article Calibration Overview (opens in a new tab)), but this is only available during development, and it requires you to re-Flash your ECU for the parameter set to persist, which is not an option all the time.

So, one might be wondering, can we not use non-volatile RAM to achieve this? And the answer is a resounding yes. The question is, with all the protection mechanisms present in the OS, and the indirection Autosar allows, how do we use the NVRAM properly within the layered architecture? This is a precious resource that needs special care, as, for example, there is a very limited number of writing cycles, in comparison with other types of memory, and there is the need to verify this data is valid, with checksums, for instance. Of course, this is just not limited to RAM. One might also want to write to Flash memory in runtime, without the possibility to re-Flash your ECU. The same problem arises, we need a mechanism to do this the "Autosar" way, with levels of abstraction that make these functionalities seamless at the application layer.

Now that we know the reason why one needs the memory stack, it's time to check its main components:

Modules involved in the Autosar memory stack { w: 393, h: 660 }

Modules involved in the Autosar memory stack

In the picture, you can see all the modules involved in the memory mapping, from the place where you decide to use non-volatile memory in a Software Component to how it maps to the EEPROM and Flash memories within your ECU. Lucklily, the memory stack is a bit less complicated than the communication stack (which we covered on the article Communication Stack Overview (opens in a new tab), if you want to take a look), but it's still present in all Autosar-based ECU's, even if your application layer does not require them. Let's go through all the modules, one by one, to make this statement clear:

Software Component (SW-C) - The SW-C wants to store persistent data, or read it, through the NvData ports (we already explained all the ports and interfaces available in Autosar in the article Types of Interfaces and Ports (opens in a new tab), if you want to take a look). All you need to do is express the need to read or write data persistently. You don't care about anything else.
RTE (Run-Time Environment) - Makes the bridge between the application layer and the BSW.
NvM (Non-volatile RAM Manager) - Handles all the requests to read and write EEPROM and Flash memory. The name can be a bit misleading, but yes, you can use Flash memory through here. Moreover, you don't care about it at this point. It ensures the data storage and maintenance according to the automotive requirements, providing services to synchronous and asynchronously read, write and manage non-volatile data. Aside from Software Components, multiple BSW modules can use the NvM module to implement some of their features. Two examples are the DEM (Diagnostic Event Manager), which stores event memory and freeze frames through the NvM module (you can learn more about the DEM in our article DEM Overview (opens in a new tab)) and in the resume mode for XCP, where the current dynamic configuration in use can be stored persistently and started right away a few power cycles later, without needing to reconfigure, which can be a long and tedious process (you can learn more about the resume mode and XCP here, in What is XCP (opens in a new tab)).
MemIf (Memory Abstraction Interface) - Allows the NvM to access different memory abstraction modules, without needing to know which one. It uniformizes everything, when it comes to the NvM, to provide abstraction on the number of FEE or EA modules, creating a virtual segmentation and a linear and uniform address space, for the NvM. Then, it takes care of inferfacing with the memory modules below, EA and FEE.
EA (EEPROM Abstraction) and FEE (Flash EEPROM Emulation) - Abstracts you from the device specific addressing scheme and segmentation, providing a virtual addressing scheme and segmentation, abstracting you from the EEPROM and Flash EEPROM drivers and memories.

After this overview of the memory stack, we hope it helped you understand the modules involved. In the near future, we'll look at them in greater detail, specially the NvM, which is the module you are most likely to deal with directly, as the other modules are usually automatically configured by your Autosar tooling provider.

Author: Micael Coutinho (opens in a new tab)

References: