Memory stack in AUTOSAR

Before delving into NVM, it’s important to understand the concept of a memory stack and how NVM fits into this context within the AUTOSAR framework. Imagine the memory stack as a library’s storage system, where each book represents a piece of data that needs to be stored, cataloged, and retrieved efficiently. In this analogy, the memory stack in AUTOSAR is the librarian that manages this system, ensuring that essential information is preserved across power cycles and system resets.

Just as a librarian ensures that important books are safely stored and readily accessible, the memory stack in AUTOSAR manages data storage and retrieval. It ensures that critical information remains intact even when the system is turned off or restarted. This section will provide an overview of the memory stack, introduce the significance of NVM, and explain its integration within the memory stack to enhance system reliability and data integrity. We will explore the structure and functionality of the memory stack, detailing its layers and modules, and then discuss the different types of NVM blocks and their specific use cases. By the end of this section, you will have a comprehensive understanding of the memory stack’s architecture, its components, and how it ensures data availability and integrity in automotive systems.

Significance of non-volatile memory in AUTOSAR

The memory stack safeguards vital data and configurations throughout power cycles and system resets. In an electronic control unit (ECU), it is usually needed to preserve critical information, such as vehicle settings, calibration parameters, diagnostic trouble codes (DTCs), and other indispensable data necessary for optimal operation. Similarly, the need to retrieve stored information persists after power cycles. To ensure seamless storage and maintenance of such data, the BSW incorporates an NVM stack, which can utilize electrically erasable programmable read-only memory (EEPROM) or flash memory for storage. Certain configurable settings control how and when data is written to and read from memory. These settings determine whether data is written immediately after it changes or deferred until the system shuts down and whether data is automatically retrieved at startup or only when specifically requested. The NVM stack manages these configurations to ensure data integrity and availability, making sure that critical information is securely stored and accessible when needed.

Understanding the memory stack

The memory stack in AUTOSAR consists of several layers and modules, each serving a specific purpose in managing non-volatile data storage and retrieval. Figure 9.1 illustrates the architecture of the memory stack in an AUTOSAR ECU, showing the interaction between different layers and components involved in managing NVM:

Figure 9.1 – Memory stack architecture

In the following subsections, we will discuss the functionality of each module within a layer in brief.

Service layer

Within the service layer, the non-volatile random access memory (NVRAM) Manager module serves as the core component of the memory stack in AUTOSAR. It provides standardized interfaces and services for managing NVM operations within the AUTOSAR framework.

Key functionalities of this layer include data block management, read and write operations, and error handling.

The NVM module acts as an interface between upper-layer SWCs and the underlying hardware, abstracting the complexities of NVM management.

Abstraction layer

In embedded devices, data storage can occur in emulated flash or an external EEPROM. The Flash EEPROM Emulation (FEE) and EEPROM Abstraction (EA) modules in AUTOSAR serve to abstract the lower storage devices, offering a standardized interface for managing data storage in embedded devices. These modules not only manage read/write/erase operations but also ensure reliability and efficient utilization of storage resources. Both provide interfaces for read, write, erase, and block management tasks and wear leveling.

The Memory Abstraction Interface (MemIf) abstracts the underlying FEE and EA modules, acting as a routing layer to their functions as it shall provide an abstraction from the number of underlying FEE or EA modules and provide upper layers with a virtual segmentation on a uniform linear address space.

MCAL

EEPROM and flash memory are integral components of the Microcontroller Abstraction Layer (MCAL). The EEPROM driver provides services for reading, writing, and erasing data blocks. Internal drivers directly access microcontroller hardware within the MCAL, while external drivers use handlers (typically serial peripheral interface (SPI)). Both types have identical functional requirements and APIs.

Figure 9.2 illustrates the interaction between the memory stack modules on the flow of write operations from the NVM module through the NVM and FEE modules, and ultimately to the FLS module, which handles the actual writing process to NVM in case the underlying physical memory is emulated flash memory.

Figure 9.2 – Memory stack architecture

Next, we will explore the storage object types of NVM, examining their roles and how they contribute to the realization of the functionality of the NVM operations.

Storage objects

The NvmM module defines fundamental storage units known as blocks or NVRAM blocks. These blocks act like individual compartments in a storage facility where your NVM data is securely stored and organized. Just as each compartment in a storage facility keeps your items safe and easily retrievable, these blocks ensure that your data remains intact and accessible even when the power is turned off. Figure 9.3 defines the basic storage objects.

Figure 9.3 – Memory stack architecture

The NvmM module’s component model defines four types of basic storage objects, which constitute the NVRAM block management types: the NV block, RAM block, ROM block, and Administrative block. Each of these blocks serves a specific function and collectively realizes the basic storage objects. We will discuss these in brief:

• RAM block: This provides temporary storage for active data, to be accessed/used directly by a user example Application.
• NV block: This handles non-volatile data storage, in the physical device flash or EEPROM.
• ROM block: This provides default data for the NV block as provided by the application, in case an error occurs reading a block.
• Administrative block: This manages metadata and control information, such as block ID, block size, and so on. It is not accessible to any other module outside the NvmM.

In the preceding section, we discussed storage objects. These block types can be combined in different configurations to create various types of NVRAM blocks. In the following section, we will cover the various block management types in NVRAM. A typical NVRAM block comprises one or more NV blocks that are allocated in physical storage, such as EEPROM or flash memory, an optional RAM block associated with the application and synchronized with the NV block, and an optional ROM block to store default data. Understanding these blocks is helpful for efficient memory management and ensuring the integrity and longevity of stored data in automotive applications.

Block types

By the end of this section, you will understand the characteristics and use cases of Native NVRAM blocks, Redundant NVRAM blocks, and Dataset NVRAM blocks, along with their importance in maintaining data integrity and system reliability.

Native NVRAM block type

This is the simplest form of an NVRAM block, consisting of a single instance of an NV block, a RAM block, a ROM block, and an Administrative block. This block stores non-critical information that does not require redundancy, data integrity is not as critical, and data can be easily reconstructed if lost.

Use case: Consider an automotive ECU for a vehicle infotainment system storing configuration parameters that control user settings, such as audio volume, display brightness, and preferred radio stations. These settings are easy to recreate or reset to default if lost, making native blocks suitable for this purpose due to their simplicity and minimal overhead.

Redundant NVRAM block type

Redundant blocks provide an additional layer of data protection by maintaining multiple copies of the same data. Thus, two NV blocks are used to realize this type. This redundancy ensures that even if one copy becomes corrupted or lost, the system can still retrieve the data from another copy.

Use case: In safety-critical systems, such as an electronic brake system (EBS), where data integrity is paramount, redundant block management is required. Two copies of the NV block are maintained to ensure redundancy. For instance, if one copy of the brake calibration data becomes corrupted due to a fault, the EBS ECU can switch to the redundant copy, thereby maintaining continuous operation without compromising safety.

Dataset NVRAM block type

Dataset blocks are more complex and involve managing multiple versions of the data. These blocks allow the storage of different datasets within the same NVRAM block, each representing a different version or state of the data. This is particularly useful for applications that need to keep track of historical data or configurations, providing the ability to revert to previous states or compare different datasets.

Use case: In an automotive climate control system, a dataset block management approach can be employed to store personalized air conditioning temperature settings for different users of the car. Each user can have their preferred temperature settings saved as a separate dataset. When a user enters the car and selects their profile, the climate control system retrieves and applies their preset temperature from the corresponding dataset block.

Managing block types

Managing block types effectively is crucial for extending the EEPROM lifespan and ensuring data safety. Since each memory location has physically limited write cycles, it’s important to choose block types wisely based on write frequency and data importance. Strategic selection of block types helps maintain data integrity and maximizes memory longevity.

After discussing the various types of NVRAM blocks, it is important to understand how these blocks are accessed.

Block properties

We will define how these blocks can be read and written, focusing on two of the most common parameters that can be configured: NvMSelectBlockForReadAll and NvMSelectBlockForWriteAll:

• NvMSelectBlockForReadAll: The read_all flag, when enabled, indicates whether the block can be included in a read all operation, where all NVM blocks are read sequentially. This is useful for initializing the system state by reading all necessary configuration data at once.

  Behavior: If the read_all flag is enabled for a block, the NVM module will read all data stored within that block:

• NvMSelectBlockForWriteAll: The write_all flag, when enabled, indicates whether the block can be included in a write all operation, where all NVM blocks are written sequentially. This is beneficial for saving the current state of the system by writing all relevant data to NVM at once usually during shutdown.
• NvMNvBlockLength: This is a configuration parameter that defines the size of an NVM block in bytes. This parameter specifies how much data the block can store, determining the memory allocation for that block within the NVM. The size of the block is crucial for ensuring that it can hold all necessary information and align with the memory layout and management strategies of the system.

NvM Block Descriptor configuration parameters

For more detailed information about the configuration parameters, you can refer to the NvM AUTOSAR specifications, such as release R20-11, specifically section 10.2.3 NvMBlockDescriptor. This section provides comprehensive insights into the various parameters and their configurations.

In the following table, we will discuss the API provided by NvmM for accessing an NV Block:

API	Description
NvM_ReadBlock	Reads data from a specified data block in NVM.
NvM_WriteBlock	Writes data to a specified data block in NVM.
NvM_SetRamBlockStatus	Sets the status of a RAM block, indicating whether it is valid.
NvM_GetErrorStatus	Retrieves the error status of a specified block.
NvM_ReadAll	Request for reading all for all blocks marked for “read all”.
NvM_WriteAll	Request for writing all data marked for “write all”.

Table 9.1 – NvmM API functions and descriptions

In the next section, let’s explore an example of how the memory stack is utilized in an ECU.

Use case

Scenario: In an automotive ECU responsible for engine control, there’s a crucial need to store calibration parameters persistently across power cycles. These parameters include fuel injection timing, ignition timing, and air-fuel ratio settings, which directly impact engine performance and emissions control. The ECU interacts with a SWC, let’s call it EngineControlSWC, to manage these calibration parameters. The SWC utilizes functions provided by the NVM module to read and write calibration data.

NVM configuration: The NVM module is configured with multiple data blocks, each serving a specific purpose. For this use case, let’s consider a native block management approach. There’s one NVM block dedicated to storing all calibration parameters. Additionally, the read_all flag is selected for this block, ensuring that all calibration parameters are read during startup. Similarly, the write_all flag is chosen, indicating that all blocks marked for write_all will be written during shutdown.

Startup sequence: Upon system startup, the following sequence of events takes place:

1. EngineControlSWC initializes its data structures and registers with the NVM module.
2. EngineControlSWC requests the NVM module to read all calibration parameters stored in the designated data block.
3. Since the read_all flag is selected, the NVM module reads all calibration parameters from the block and provides them to EngineControlSWC.
4. EngineControlSWC utilizes the retrieved calibration parameters for engine control algorithms and initialization routines.

Shutdown sequence: During system shutdown, the following sequence of events takes place:

1. EngineControlSWC finalizes its operations and prepares for shutdown.
2. EngineControlSWC requests the NVM module to write all calibration parameters back to the designated data block.
3. As the write_all flag is chosen, the NVM module writes all calibration parameters to the block, ensuring that all changes made during runtime are persistently stored.
4. The NVM module confirms the successful completion of the write operation, allowing EngineControlSWC to proceed with the shutdown process.

Figure 9.4 shall show how this process or flow shall go.

Figure 9.4 – Abstract sequence diagram for NVM usage in a system

Explanation: The selection of the read_all flag ensures that all calibration parameters are read during startup, guaranteeing that the ECU has access to the latest configuration.

Similarly, choosing the write_all flag ensures that all changes made during runtime are written back to NVM during shutdown, maintaining data integrity across power cycles.

By utilizing NVM in this manner, EngineControlSWC ensures that calibration parameters remain consistent and reliable, contributing to optimal engine performance and emissions control.

Now that we have understood the NVM stack and the components of NVM, it is essential to explore the mode manager for BSW. Understanding the BSWM is crucial as it plays a vital role in managing the various modes of operation within the automotive software architecture.