A Design Method for NvM Storage Systems Based on AUTOSAR Architecture

Abstract

This application relates to a design method for an NvM storage system based on the AUTOSAR architecture, including module configuration using the MCAL configuration tool EB tresos Studio and the AUTOSAR configuration tool ISOLAR-AB, and adopts dual address hardening to solve the problem of storage data address correspondence failure caused by compilation. It also employs the collaborative logic of CRC check and redundant storage to locate the time node of power failure, and restores the system step by step according to the main block → backup block → ROM default value to ensure normal system operation.

Description

Technical Field

[0001] This application relates to the field of automotive data storage, and more specifically, to a design method for an NVM storage system based on the AUTOSAR architecture. Background Technology

[0002] The NvM (Non-Volatile Manager) storage system is used to manage and maintain all NV data within the Electronic Control Unit (ECU). During the power-down process, the ECU writes the running values ​​of the NV data from the RAM (Random Access Memory) block to the Flash memory, and during the power-up process, it reads the values ​​of the NV data from the Flash memory back to the RAM block.

[0003] Statistics show that approximately 37% of abnormal ECU restarts in automobiles are directly related to corrupted NVM data. Traditional solutions suffer from two major technical flaws:

[0004] (1) Insufficient power failure protection mechanism: If an abnormal power failure occurs during the writing process of Flash, it will cause the Flash data to be corrupted and the Flash data will be read as abnormal values ​​after power-on, thus causing the system to run abnormally.

[0005] (2) Rigid address management: The address allocation of traditional NV data in RAM blocks depends entirely on the linking order of the project files involved in the compilation. When the linking order changes or NV variables are added / deleted during development, the memory mapping table needs to be manually adjusted. Otherwise, it will cause a chain reaction of address offsets and lead to address misalignment. Summary of the Invention

[0006] To overcome at least one deficiency in the prior art, this application provides a design method for an NvM storage system based on the AUTOSAR architecture.

[0007] Firstly, a design method for an NvM storage system based on the AUTOSAR architecture is provided, including:

[0008] Configure the sector partitioning of Flash using the FLS module of the MCAL configuration tool EB tresos Studio;

[0009] Use the FEE module of the MCAL configuration tool EB tresos Studio to configure the data block container size when emulating an EEPROM in Flash.

[0010] Use the MemIf module of the AUTOSAR configuration tool ISOLAR-AB to generate the storage space abstraction interface;

[0011] The AUTOSAR configuration tool ISOLAR-AB uses the NvM module for storage data block management, including: reading NV data upon power-on and storing NV data to Flash upon power-off;

[0012] In the linker file, define the memory regions with the same address and size configuration as the RAM and ROM blocks in the NvM module, and determine the address mapping relationship between the RAM and ROM blocks;

[0013] Multiple static arrays are pre-allocated in the RAM block, each corresponding to a data type; the total size of the multiple static arrays is fixed and completely occupies the RAM space reserved for NV data, with multiple bytes reserved at the end of the RAM space for storing CRC check codes;

[0014] Define the customRead and customWrite services, assign an index to each user-defined NV variable in an array of the corresponding data type, and record the mapping relationship between NV variables and index positions through a mapping table.

[0015] In one embodiment, the method further includes configuring the NvM module as follows:

[0016] Configure a RAM Block Address configuration item for each NvM Block, which is the base address of the NV variable in RAM at runtime;

[0017] Configure a ROM Default Address configuration item for each NvM Block, which is the storage address in ROM where the default value of the Nv variable is stored;

[0018] Configure a CRC configuration for each NvM Block, i.e., specify the CRC check type;

[0019] Configure the NvM Block's properties to Redundant, meaning that each NvM Block will contain a primary block, a backup block, and a log block.

[0020] In one embodiment, power-on reading of NV data includes:

[0021] Call NvM_ReadAll to read multiple arrays of data stored in Flash into their corresponding arrays;

[0022] The customRead service is called to traverse the mapping table and copy the values ​​in the array to the user variables according to the mapping relationship in the mapping table. When the program runs, it directly uses the user variables for read and write operations. The user variables are global variables. If the user modifies the value of the user variable, the modified value is written back to the corresponding array through the customWrite service before power-off.

[0023] In one embodiment, power-down storage of NV data includes:

[0024] Call the customWrite service, traverse the mapping table, and copy the values ​​of user variables into the corresponding arrays;

[0025] Call NvM_WriteAll to write the entire array to Flash.

[0026] In one embodiment, power-on reading of NV data includes:

[0027] Step S11: Read the data from the main block and perform CRC verification;

[0028] Step S12: If the CRC check passes, use the data from the main block; if the CRC check fails, check the log.

[0029] Step S13: If the log indicates that the last write was interrupted, then read the backup block and perform a CRC check on the backup block.

[0030] Step S14: If the CRC check passes, the main block is repaired using the data from the backup block, and data is read from the main block into RAM; if the CRC check fails, the ROM default value is restored to RAM.

[0031] In one embodiment, power-down storage of NV data includes:

[0032] Step S21: Record a log entry WRITE_START in the log block to indicate the start of the write operation;

[0033] Step S22: Write the main block, including data and CRC checksum;

[0034] Step S23: The main block performs CRC verification. If the verification passes, proceed to step S24; if the verification fails, proceed to step S25.

[0035] Execute step S24 to write the backup block. The backup block is CRC checked. If the check passes, log WRITE_DONE is recorded to indicate that the write was successful. If the check fails, log WRITE_SECONDARY_FAIL is recorded to indicate that the backup block write failed.

[0036] Step S25: Log WRITE_PRIMARY_FAIL, indicating that the primary block write failed.

[0037] Compared with the prior art, this application has the following beneficial effects:

[0038] (1) This application adopts dual address fixation. It adopts the "memory pool" design concept, predefines static arrays of fixed size according to data type to realize physical layer fixation, and then establishes a fixed correspondence between user variables and array elements through a mapping table to realize logical layer fixation. Finally, ReadAll / WriteAll is used to read and write the memory pool as a whole to avoid address offset problems. The addition or removal of variables only affects the mapping table and does not change the position of existing variables. Moreover, changes in the compilation and linking order have no effect, thereby solving the problem of the failure of the storage data address correspondence caused by compilation.

[0039] (2) This application adopts a multi-level data verification mechanism. It uses the collaborative logic of CRC check and redundant storage to locate the time node of power failure and restore the system step by step according to the main block → backup block → ROM default value to ensure normal system operation. Attached Figure Description

[0040] This application can be better understood by referring to the description given below in conjunction with the accompanying drawings, which, together with the detailed description below, are incorporated in and form part of this specification. In the drawings:

[0041] Figure 1 A schematic diagram of the power-on reading process is shown;

[0042] Figure 2 A schematic diagram of the power-down write process is shown;

[0043] Figure 3 A diagram illustrating the data reading verification mechanism is shown.

[0044] Figure 4 A diagram illustrating the data write verification mechanism is shown. Detailed Implementation

[0045] Exemplary embodiments of the present application will be described below with reference to the accompanying drawings. For clarity and brevity, not all features of the actual embodiments are described in the specification. However, it should be understood that many embodiment-specific decisions can be made in the development of any such actual embodiment to achieve the developer’s specific objectives, and these decisions may vary as the embodiments differ.

[0046] It should also be noted that, in order to avoid obscuring this application with unnecessary details, only the device structure closely related to the solution according to this application is shown in the accompanying drawings, while other details that are not closely related to this application are omitted.

[0047] It should be understood that this application is not limited to the described embodiments by virtue of the following description with reference to the accompanying drawings. In this document, embodiments may be combined with each other, features may be substituted or borrowed between different embodiments, and one or more features may be omitted in one embodiment, where feasible.

[0048] This application provides a design method for an NvM storage system based on the AUTOSAR architecture, which mainly includes the following steps:

[0049] Step 1: Module configuration.

[0050] Use the FLS module of the MCAL configuration tool EB tresos Studio to configure the sector division of the Flash memory; the FLS module interacts directly with the Flash hardware and provides the upper layer with Flash read, write, erase and other operation interfaces.

[0051] MCAL, part of the AUTOSAR foundational software, provides upper-level software modules with access to microcontroller hardware resources. EB Tresos Studio is a classic AUTOSAR software development environment primarily used for developing the foundational software (BSW) for electronic control units (ECUs). It relies on a consistent, single-tool environment to develop ECU foundational software through the AUTOSAR open system architecture. The FLS module, located in the storage abstraction layer of the AUTOSAR architecture, acts as a bridge between upper-level software (such as NVRAM managers and flash EEPROM emulation modules) and the underlying Flash hardware. By providing standardized APIs, it allows ECUs from different vendors to access various Flash devices using a unified interface, thereby improving software portability and reusability.

[0052] Use the FEE module in the MCAL configuration tool EB tresos Studio to configure the data block container size when emulating EEPROM in Flash. The FEE module improves Flash storage lifespan by emulating EEPROM (Electrically Erasable Programmable read-only memory) read and write modes.

[0053] FEE is an abbreviation for Flash EEPROM Emulation, which is a module that uses Flash memory to simulate the function of EEPROM.

[0054] The MemIf module of the AUTOSAR configuration tool ISOLAR-AB is used to generate the storage space abstraction interface. The MemIf module provides a unified read, write, and status management interface to the upper layer for the FEE module.

[0055] MemIf is an abbreviation for AUTOSAR Memory Abstraction Interface, which is a memory abstraction interface module.

[0056] The AUTOSAR configuration tool ISOLAR-AB uses the NvM module for storage data block management, including reading NV data upon power-on and storing NV data to Flash upon power-off, ensuring no data loss upon power-off. It provides services such as NVRAMreadBlock, writeBlock, readAll, and writeAll for single or batch NvM block read and write operations, and supports mechanisms such as CRC data verification and redundant data storage. An NvM block is the smallest logical data unit managed by the AUTOSAR NvM module.

[0057] The following configuration is required in the NvM module:

[0058] ① Configure a RAM Block Address configuration item for each NvM Block, which is the base address of the NV variable in RAM at runtime;

[0059] ② Configure a ROM Default Address configuration item for each NvM Block, which is the storage address in ROM where the default value of the Nv variable is stored;

[0060] ③ Configure a CRC configuration for each NvM Block, that is, specify the CRC check type to verify data integrity;

[0061] ④ Configure the NvM Block's properties to Redundant, meaning that each NvM Block will contain a Primary Block, a Secondary Block, and a Log Block.

[0062] Associate the initialization functions and main functions of the above-mentioned modules with the corresponding tasks to complete the scheduling.

[0063] Step 2: Dual address solidification.

[0064] In the linker file, define memory regions with the same address and size configuration as the RAM and ROM blocks in the NvM module, and determine the address mapping relationship between the RAM and ROM blocks. The RAM section is used for runtime NV data storage, with the NOLOAD attribute to prevent initialization at startup, and the load address needs to be specified using the AT keyword. The ROM section is used to store default values, with the READONLY attribute.

[0065] In the user-defined file, the `#pragma` section forces variable positioning. Multiple static arrays are pre-allocated in the RAM block, each corresponding to a data type (e.g., uint8 array, uint16 array, float array, etc.). The total size of these static arrays is fixed and completely occupies the RAM space reserved for NV data. Several bytes (e.g., 4 bytes) are reserved at the end of the RAM space to store the CRC checksum, providing support for a multi-level data verification mechanism. The CRC checksum is also written to Flash as NV data. The CRC verification method involves calculating the CRC of all data within the NvM Block except for the last 4 bytes, and comparing the calculated result with the CRC of the last 4 bytes.

[0066] Define the `customRead` and `customWrite` services, assigning an index to each user-defined NV variable in an array corresponding to its data type, and recording the mapping relationship between NV variables and index positions through a mapping table. In AUTOSAR's NVM module, the `customRead` and `customWrite` services are extended interfaces for handling special data transformation needs. `customWrite` is used to convert runtime data in the RAM block to the storage format before data is written to the NVM; `customRead` is used to convert the storage format data in the NVM to the runtime format after data is read into RAM.

[0067] In one embodiment, Figure 1 The diagram illustrates the power-on read process, which involves reading NV data upon power-on, including:

[0068] Call NvM_ReadAll to read multiple arrays of data stored in Flash into their corresponding arrays;

[0069] The customRead service is called to traverse the mapping table and copy the values ​​in the array to the user variables according to the mapping relationship in the mapping table. When the program runs, it directly uses the user variables for read and write operations. The user variables are global variables. If the user modifies the value of the user variable, the modified value is written back to the corresponding array through the customWrite service before power-off.

[0070] In one embodiment, Figure 2 The diagram illustrates the power-down write process, which stores NV data upon power-down, including:

[0071] Call the customWrite service, traverse the mapping table, and copy the values ​​of user variables into the corresponding arrays;

[0072] Call NvM_WriteAll to write the entire array to Flash.

[0073] Because the array size is fixed and each variable is assigned a specific index within that array, adding or deleting a variable does not affect the positions of other variables. Adding a variable simply involves adding a record to the mapping table, assigning an unused index in the array of the corresponding data type, and defining it in the user variable. Deleting a variable simply involves removing the record from the mapping table, and the array position corresponding to that index will no longer be used. In other words, adding or removing user variables only affects the mapping table and does not change the positions of existing variables in the array, thus ensuring address stability.

[0074] The above embodiments macroscopically implement the functions of power-on read and power-off write, but in reality, a multi-level data verification mechanism is required during the reading and writing process to ensure reading and writing security.

[0075] Log blocks are used to determine whether an operation has been completed completely, thus deciding whether a backup block needs to be used. The backup block exists as the "last correct version" of the primary block. When a write interruption is detected (the log only shows WRITE_START), and the backup block's CRC checksum passes, the data in the backup block is trusted, and the primary block is restored using it.

[0076] The principles of the multi-level data verification mechanism are: ① CRC first: CRC verification is performed immediately after data is written to ensure the correctness of physical storage; ② Log post-log: Logs are only recorded after the operation is completed, and the logs serve as proof of the operation's integrity; ③ Recovery hierarchy: Recovery is performed in the order of main block → backup block → ROM default value, with each level progressively downgrading.

[0077] Specifically, Figure 3 A diagram of the data read verification mechanism is shown. (See attached diagram) Figure 3 Power on and read NV data, including:

[0078] Step S11: Read the data from the main block and perform CRC verification;

[0079] Step S12: If the CRC check passes, use the data from the main block; if the CRC check fails, check the log.

[0080] Step S13: If the log indicates that the last write operation was interrupted, then read the backup block and perform a CRC check on the backup block. Here, if the log shows that the most recent operation was WRITE_START but not WRITE_DONE, it means that the last write operation may have been interrupted by an abnormal power outage, and the power outage occurred during the writing of the main block area.

[0081] Step S14: If the CRC check passes, the data from the backup block is used to repair the main block, and data is read from the main block into RAM; if the CRC check fails, both the main block and the backup block may be physically damaged, and the ROM default value is restored to RAM.

[0082] Specifically, Figure 4 A diagram illustrating the data write verification mechanism is shown below. Figure 4 Power-down storage of NV data, including:

[0083] Step S21: Record a log entry WRITE_START in the log block to indicate the start of the write operation;

[0084] Step S22: Write the main block, including data and CRC checksum;

[0085] Step S23: The main block performs CRC verification. If the verification passes, proceed to step S24; if the verification fails, proceed to step S25.

[0086] Execute step S24 to write the backup block. The backup block is CRC checked. If the check passes, log WRITE_DONE is recorded to indicate that the write was successful. If the check fails, log WRITE_SECONDARY_FAIL is recorded to indicate that the backup block write failed.

[0087] Step S25: Log WRITE_PRIMARY_FAIL, indicating that the primary block write failed.

[0088] In summary, this application has the following technical effects:

[0089] (1) This application adopts dual address fixation. It adopts the "memory pool" design concept, predefines static arrays of fixed size according to data type to realize physical layer fixation, and then establishes a fixed correspondence between user variables and array elements through a mapping table to realize logical layer fixation. Finally, ReadAll / WriteAll is used to read and write the memory pool as a whole to avoid address offset problems. The addition or removal of variables only affects the mapping table and does not change the position of existing variables. Moreover, changes in the compilation and linking order have no effect, thereby solving the problem of the failure of the storage data address correspondence caused by compilation.

[0090] (2) This application adopts a multi-level data verification mechanism. It uses the collaborative logic of CRC check and redundant storage to locate the time node of power failure and restore the system step by step according to the main block → backup block → ROM default value to ensure normal system operation.

[0091] The above descriptions are merely various embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A design method for an NvM storage system based on the AUTOSAR architecture, characterized in that, include: Configure the sector partitioning of Flash using the FLS module of the MCAL configuration tool EB tresos Studio; Use the FEE module of the MCAL configuration tool EB tresos Studio to configure the data block container size when emulating an EEPROM in Flash. Use the MemIf module of the AUTOSAR configuration tool ISOLAR-AB to generate the storage space abstraction interface; The AUTOSAR configuration tool ISOLAR-AB uses the NvM module for storage data block management, including: reading NV data upon power-on and storing NV data to Flash upon power-off; In the linker file, a memory region with the same address and size configuration as the RAM block and ROM block in the NvM module is defined, and the address mapping relationship between the RAM block and the ROM block is determined. Multiple static arrays are pre-allocated in the RAM block, each array corresponding to a data type; the total size of the multiple static arrays is fixed and completely occupies the RAM space reserved for NV data, and multiple bytes are reserved at the end of the RAM space for storing CRC check codes; Define the customRead and customWrite services, assign an index to each user-defined NV variable in an array of the corresponding data type, and record the mapping relationship between NV variables and index positions through a mapping table.

2. The method as described in claim 1, characterized in that, The method further includes configuring the NvM module as follows: Configure a RAM Block Address configuration item for each NvM Block, which is the base address of the NV variable in RAM at runtime; Configure a ROM Default Address configuration item for each NvM Block, which is the storage address in ROM where the default value of the Nv variable is stored; Configure a CRC configuration for each NvM Block, i.e., specify the CRC check type; Configure the NvM Block's properties to Redundant, meaning that each NvM Block will contain a primary block, a backup block, and a log block.

3. The method as described in claim 1, characterized in that, The power-on reading of NV data includes: Call NvM_ReadAll to read multiple arrays of data stored in Flash into their corresponding arrays; The customRead service is invoked to traverse the mapping table and copy the values ​​in the array to the user variables according to the mapping relationship in the mapping table. During program execution, the user variables are used directly for read and write operations. The user variables are global variables. If the user modifies the value of the user variables, the modified value is written back to the corresponding array through the customWrite service before power-off.

4. The method as described in claim 1, characterized in that, The power-down storage of NV data includes: Call the customWrite service, traverse the mapping table, and copy the values ​​of user variables to the corresponding arrays; Call NvM_WriteAll to write the entire array to Flash.

5. The method as described in claim 1, characterized in that, The power-on reading of NV data includes: Step S11: Read the data from the main block and perform CRC verification; Step S12: If the CRC check passes, use the data from the main block; if the CRC check fails, check the log. Step S13: If the log indicates that the last write was interrupted, then read the backup block and perform a CRC check on the backup block. Step S14: If the CRC check passes, the main block is repaired using the data from the backup block, and data is read from the main block into RAM; if the CRC check fails, the ROM default value is restored to RAM.

6. The method as described in claim 1, characterized in that, Power-down storage of NV data, including: Step S21: Record a log entry WRITE_START in the log block to indicate the start of the write operation; Step S22: Write the main block, including data and CRC checksum; Step S23: The main block performs CRC verification. If the verification passes, proceed to step S24; if the verification fails, proceed to step S25. Execute step S24 to write the backup block. The backup block is CRC checked. If the check passes, log WRITE_DONE is recorded to indicate that the write was successful. If the check fails, log WRITE_SECONDARY_FAIL is recorded to indicate that the backup block write failed. Step S25: Log WRITE_PRIMARY_FAIL, indicating that the primary block write failed.

Images