Support multi-scenario embedded system parameter security storage method and device

Abstract

This application relates to a method and apparatus for securely storing embedded system parameters supporting multiple scenarios. The method includes: constructing a metadata mapping table, which stores metadata for multiple parameters, including the physical storage address of the parameters in the storage medium, the memory variable address in the running memory, and the range of valid values; based on the metadata mapping table, determining an initialization scenario according to predefined trigger conditions, and initializing multiple parameters; during system runtime, responding to operation requests for the parameters, validating the parameters according to the range of valid values, and performing corresponding read and write operations between the memory variable address and the physical storage address. This method enables centralized management of embedded parameters, flexible adaptation to multi-scenario initialization, and secure storage throughout the entire process.

Description

Technical Field

[0001] This application relates to the field of embedded technology, and in particular to a method and apparatus for securely storing embedded system parameters that supports multiple scenarios. Background Technology

[0002] In embedded systems, especially in industrial control and IoT devices, there are numerous configuration parameters that need to be retained even after power loss. These parameters are typically stored in external non-volatile storage media and loaded into the running memory for program use during system startup. To achieve parameter persistence and initialization management, traditional solutions usually involve hard-coding the storage address for each parameter and distributing the logic for reading, verifying, and writing different types of parameters throughout the code.

[0003] However, in traditional parameter storage schemes, parameter management logic is highly coupled with business code and is defined in a scattered manner. When the system needs to initialize in various scenarios, such as using default values ​​upon first power-on, loading historical values ​​during normal startup, or resetting during fault recovery, the hard-coded information related to parameter attributes and the corresponding processing functions must be modified in multiple places. This not only leads to low development and maintenance efficiency but also easily causes serious problems such as address conflicts, data type parsing errors, and loading of abnormal values ​​due to omissions or mismatches, directly affecting the reliability and stability of the embedded system's startup and operation.

[0004] Therefore, how to solve the problem of poor system maintainability caused by the decentralized parameter management logic, and provide an embedded parameter storage solution that can achieve centralized management of parameter attributes, flexible adaptation of initialization strategies, and full-process security, has become a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0005] Therefore, it is necessary to provide a method and apparatus for secure storage of embedded system parameters that supports multiple scenarios to address the aforementioned technical problems.

[0006] Firstly, this application provides a method for securely storing embedded system parameters that supports multiple scenarios, including:

[0007] Construct a metadata mapping table, which stores metadata for multiple parameters. The metadata includes the physical storage address of the parameter in the storage medium, the memory variable address in the running memory, and the range of legal values.

[0008] Based on the metadata mapping table, the multiple parameters are initialized. The initialization includes determining the initialization scenario according to predefined triggering conditions, and performing corresponding parameter initialization operations based on the initialization scenario and the metadata mapping table.

[0009] When the system is running, in response to an operation request for the parameter, the parameter is validated according to the range of valid values, and corresponding read and write operations are performed between the memory variable address and the physical storage address.

[0010] In one embodiment, determining the initialization scenario based on predefined triggering conditions and performing corresponding parameter initialization operations based on the initialization scenario and the metadata mapping table includes:

[0011] If the preset factory identifier in the storage medium is a specific value, the first factory shipment scenario is triggered, and the default values ​​of all parameters are written to the corresponding physical storage address.

[0012] If the hardware version number in the storage medium is inconsistent with the current hardware version number of the embedded system, the hardware version adaptation scenario is triggered, the parameters that match the current hardware version are selected, and their default values ​​are written to the corresponding physical storage address.

[0013] If a fault signal is present in the storage medium, a fault recovery scenario is triggered, and the parameters in the backup storage address are written to the corresponding physical storage address.

[0014] If a partition identifier is present in the triggering conditions, a partition update scenario is triggered. Based on the received instructions, parameters belonging to the partition identifier are filtered, and their default values ​​are written to the corresponding physical storage address.

[0015] In one embodiment, before performing a corresponding read / write operation between the memory variable address and the physical storage address, the method further includes:

[0016] Obtain the range of valid values ​​for the parameter from the metadata mapping table;

[0017] Determine whether the parameter is within the range of valid values;

[0018] If the value is within the legal range, then read and write operations are performed on the parameter.

[0019] If the value exceeds the range of valid values, an error flag is returned.

[0020] In one embodiment, determining whether the parameter is within the range of valid values ​​includes:

[0021] Obtain the data type identifier, valid minimum value, valid maximum value, hardware version mask, and preset hash value of the parameter from the metadata mapping table;

[0022] The parameter is validated based on the data type identifier.

[0023] The parameters are range-checked based on the legal minimum and legal maximum values;

[0024] Based on the current hardware version number of the system and the hardware version mask, the parameters are subjected to hardware adaptation verification;

[0025] The parameters are subjected to hash integrity verification based on the preset hash value.

[0026] In one embodiment, the method further includes:

[0027] When a firmware upgrade or parameter structure change is detected, the historical parameter values ​​in the physical storage address are formatted and migrated according to the hardware version mask.

[0028] In one embodiment, the read / write operation between the memory variable address and the physical storage address further includes:

[0029] Obtain the data type identifier of the parameter from the metadata mapping table;

[0030] When a read operation is performed, the read function corresponding to the data type identifier is called to read the parameter value from the physical storage address;

[0031] When a write operation is performed, the write function corresponding to the data type identifier is called to write the parameter value to the memory variable address.

[0032] In one embodiment, the physical storage address further includes a primary storage address and a backup storage address, and the corresponding read / write operation between the memory variable address and the physical storage address further includes:

[0033] Based on the main storage address, read and write operations are performed on the parameters;

[0034] If the read / write operation fails, the operation will switch to the backup storage address.

[0035] If both the read and write operations based on the primary storage address and the backup storage address fail, the default value will be used as the read and write result for this parameter.

[0036] In one embodiment, the storage medium includes a parameter change log area, and the corresponding read / write operation between the memory variable address and the physical storage address further includes:

[0037] When writing the parameter to the storage address, at least one of the following is recorded in the parameter change log area: the original value of the parameter before writing, the changed value after writing, and the writing timestamp.

[0038] Secondly, this application also provides a secure storage device for embedded system parameters that supports multiple scenarios, including:

[0039] The mapping construction module is used to construct a metadata mapping table, which stores metadata for multiple parameters. The metadata includes the physical storage address of the parameter in the storage medium, the memory variable address in the running memory, and the range of legal values.

[0040] An initialization module is used to initialize the plurality of parameters based on the metadata mapping table. The initialization includes determining an initialization scenario according to predefined triggering conditions, and performing corresponding parameter initialization operations based on the initialization scenario and the metadata mapping table.

[0041] The storage control module is used to, during system operation, respond to operation requests for the parameters, validate the parameters according to the range of valid values, and perform corresponding read and write operations between the memory variable address and the physical storage address.

[0042] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in any one of the first aspects above.

[0043] The aforementioned method and device for secure storage of embedded system parameters across multiple scenarios centrally manage embedded system parameters through a metadata mapping table. This allows for parameter modification directly by altering the metadata without modifying the underlying code, avoiding issues such as address conflicts and type mismatches caused by inconsistent changes to scattered underlying code. Furthermore, the built-in initialization mode identifier in the metadata flexibly adapts to the initialization requirements of various scenarios, including first power-on, normal startup, and fault recovery, within the same framework, enhancing the system's adaptability and flexibility to different operating states. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 This is an application environment diagram of an embedded system parameter secure storage method supporting multiple scenarios in one embodiment;

[0046] Figure 2This is a flowchart illustrating a method for securely storing embedded system parameters that supports multiple scenarios in one embodiment.

[0047] Figure 3 This is a flowchart illustrating the parameter initialization steps in one embodiment;

[0048] Figure 4 This is a flowchart illustrating the parameter verification steps in another embodiment;

[0049] Figure 5 This is a structural block diagram of an embedded system parameter secure storage device that supports multiple scenarios in one embodiment. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] The embedded system parameter secure storage method supporting multiple scenarios provided in this application embodiment can... Figure 1 Executed in the embedded system, Figure 1 This is a system architecture block diagram of an embedded system parameter secure storage method supporting multiple scenarios, according to some embodiments of this application. For example... Figure 1As shown, the system includes a controller 10, a storage medium 20, and a host computer 30. The controller can be a microcontroller unit (MCU), an embedded microprocessor (MPU), or a system-on-a-chip (SoC), and internally includes running memory and program memory. The program code and metadata mapping table of the method described in this application are stored in its program memory and executed by its processor to complete logic such as parameter initialization, runtime management, and secure storage. The storage medium 20 is connected to the controller 10 and is a non-volatile storage device used to persistently store the various parameter values ​​managed by the controller. Specifically, it can be an electrically erasable programmable read-only memory (EEPROM), ferroelectric RAM (FRAM), or flash memory chip, etc. The specific storage location of the parameters in this medium is defined by the physical storage address in the metadata mapping table. The host computer 30 can be a personal computer, an industrial touchscreen, or a mobile device, etc. The device connects to the controller 10 via a communication interface and is used to send parameter modification commands to the controller 10 or query the current parameter status. When a parameter is modified via the host computer, the controller 10 will be triggered to execute the process of storing data in response to parameter changes as described in this application.

[0052] In one exemplary embodiment, such as Figure 2 As shown, a method for securely storing embedded system parameters supporting multiple scenarios is provided, including the following steps:

[0053] Step S201: Construct the metadata mapping table.

[0054] During system development, all parameters requiring persistent management need to be determined based on the system's functional requirements. The attribute set of each parameter is defined as a metadata mapping table. Each record in this mapping table is a piece of metadata and is associated with at least the following data: the physical storage address of the parameter in the storage medium, the memory variable address in the controller's running memory, the data type identifier indicating its data format (such as 8-bit integer, 32-bit floating-point number, etc.), the range of legal values ​​for the parameter, and the default value that ensures the system can start.

[0055] Step S202: Initialize multiple parameters based on the metadata mapping table.

[0056] When an embedded device system boots up, parameters need to be initialized. The requirements for parameter initialization vary depending on the different boot stages. Therefore, initialization involves determining the initialization scenario based on predefined trigger conditions and performing corresponding parameter initialization operations based on the initialization scenario and metadata mapping table. Trigger conditions may include, but are not limited to, factory identifiers read from a specific memory address, the current hardware version number obtained through hardware pin levels, externally input fault recovery signals, or partition update commands.

[0057] The initialization scenarios can include the first-time factory shipment scenario where all parameters need to be set to factory default values, the partition update scenario where only some parameters need to be updated, the hardware version adaptation scenario where adaptive parameters need to be selected and loaded due to hardware version changes, and the fault recovery scenario where recovery from backup data is prioritized. After determining the initialization scenario, the controller performs the initialization operation matching the selected specific scenario based on the requirements of the selected specific scenario and the metadata mapping table.

[0058] Specifically, the controller iterates through the metadata mapping table. For each metadata record, based on the strategy indicated by the initialization scenario, it determines the initialization source for each parameter and writes the final determined parameter value to the corresponding memory variable address, enabling the system to enter a runnable state. The initialization source includes historical values ​​in physical storage addresses and the inherent default values ​​of device parameters.

[0059] For example, if the policy is to load a default value, the default value associated with the metadata is written to the memory variable address associated with the record; if the policy indicates to load a stored value, the current stored value is read from the physical storage address according to the data type identifier associated with the metadata and written to the memory variable address.

[0060] Step S203: During system operation, in response to the operation request for the parameter, the parameter is validated according to the range of valid values, and corresponding read and write operations are performed between the memory variable address and the physical storage address.

[0061] This step is triggered when a parameter value in the running memory changes due to user configuration, program calculations, or other reasons during system operation. Before performing read / write operations, the controller also needs to perform pre-validation on the data based on the valid value range in the metadata mapping table. Taking a parameter write operation as an example, the controller first determines whether the value to be written is within its valid value range. If the validation passes, the controller will call the corresponding underlying write function based on the data type identifier in the metadata, and write the read parameter value to the storage medium according to the physical storage address associated in the record. If the validation fails, the controller will terminate the operation and optionally return an error message.

[0062] The aforementioned method for secure parameter storage in embedded systems, supporting multiple scenarios, separates parameter management from the business logic of parameter usage by introducing a metadata mapping table. When system requirements change, parameter configuration can be uniformly performed simply by modifying the metadata mapping table, improving development and maintenance efficiency and system flexibility. By defining initialization strategies for different application scenarios, developers no longer need to write different initialization code for different scenarios; they can control the initialization behavior of each parameter simply by configuring the metadata mapping table.

[0063] In some embodiments, such as Figure 3 As shown, determining the initialization scenario based on predefined triggering conditions, and performing the corresponding parameter initialization operation based on the initialization scenario and the metadata mapping table includes the following steps:

[0064] Step S301: Determine that the preset factory identifier bit in the storage medium is a specific value.

[0065] Step S302: If the factory flag is a specific value, the first factory shipment scenario is triggered, and the default values ​​of all parameters are written to the corresponding physical storage address.

[0066] The controller reads the preset factory default flag from the storage medium. This flag is a specific value stored at a fixed address, used to persistently record whether the device has completed its initial factory initialization. If the factory default flag is a specific value, it indicates that the device has not undergone factory initialization, thus triggering the first-time factory initialization scenario. In this scenario, for all parameters, the controller writes the default values ​​defined in its metadata to the corresponding physical storage address and updates the factory default flag. For example, when the device is first powered on, the factory default flag is 0xFF; after writing the default value, it will be updated to 0xAA.

[0067] Step S303: Determine whether the hardware version number in the storage medium is consistent with the current hardware version number of the embedded system.

[0068] In step S304, if they match, the hardware version adaptation scenario is triggered, parameters that match the current hardware version are selected, and their default values ​​are written to the corresponding physical storage address.

[0069] The controller reads its historical hardware version number from the storage medium and simultaneously obtains the current hardware version number of the current system by reading the hardware version identification circuit. It should be noted that the hardware version number is used to identify the version of the device's hardware circuit. Different versions may correspond to different parameter sets or parameter valid ranges. Therefore, by comparing the version numbers, it is possible to detect whether the device hardware has changed, thereby triggering a hardware version adaptation scenario.

[0070] For each parameter, the controller checks its metadata for a hardware version mask, which defines the range of hardware versions that the parameter is compatible with. The controller only writes the default value of parameters whose hardware version mask matches the current hardware version to the physical storage address. Specifically, a match can be determined by performing a bitwise AND operation between the current hardware version number and the mask.

[0071] Step S305: Determine if there is a fault signal in the storage medium.

[0072] In step S306, if a fault signal exists, a fault recovery scenario is triggered, and the parameters in the backup storage address are written to the corresponding physical storage address.

[0073] The fault signal can originate from a software fault identifier returned when reading or verifying the storage medium fails, or from a level signal indicating a hardware circuit fault input. When a fault recovery scenario is triggered, the controller first attempts to read data from the backup address of the parameters. The backup address is a redundant storage address pre-allocated in other physical areas of the storage medium. If the read is successful, this value is used to restore the system. If the read fails, a default value is written to the backup address as the new recovery baseline.

[0074] Step S307: Determine if a partition identifier exists in the triggering conditions.

[0075] In step S308, if a partition identifier exists, a partition update scenario is triggered. Based on the received instruction, parameters belonging to the partition identifier are filtered, and their default values ​​are written to the corresponding physical storage address.

[0076] The partition identifier is a label in the metadata used to logically group parameters, such as the system parameter area and the user configuration area. If a partition identifier exists in an externally received command or internal state, only the parameters within that specific partition are updated. Specifically, the controller filters all parameters belonging to that partition in the metadata mapping table, performs initialization operations, and writes their default values ​​or values ​​attached to the command to their corresponding physical storage addresses. Parameters in other partitions remain unchanged.

[0077] In this embodiment, by differentiating the initialization scenarios, the embedded device can automatically select different parameter loading strategies in different scenarios, which significantly improves the adaptability of the system and solves the problem that the initialization logic of the traditional solution is fixed, requiring code modification to switch scenarios, and the initialization strategy does not match the actual needs.

[0078] It is understandable that in industrial environments, parameters stored in storage media such as EEPROM may exceed their limits due to electromagnetic interference, unexpected power outages, etc. (e.g., port numbers exceeding the valid range). In traditional solutions, parameters are simply verified during writing or rely entirely on application-layer verification, and abnormal data is directly used during initial loading, which can easily lead to system malfunctions or crashes.

[0079] In some exemplary embodiments, various parameter validity verification methods are defined before writing parameter values ​​to the storage medium during parameter initialization, and during other parameter read / write phases. Specifically, these include the following steps:

[0080] Step S401: Obtain the range of valid values ​​for the parameters from the metadata mapping table.

[0081] The range of legal values ​​can be a set of values ​​in the metadata that includes the minimum and maximum legal values.

[0082] Step S402: Determine whether the parameter is within the legal value range.

[0083] The controller compares the parameter value to be loaded or stored with the value in the valid value range.

[0084] Step S403: If the value is within the legal range, then read and write the parameter value.

[0085] In step S404, if the value exceeds the valid range, an error flag is returned.

[0086] If the verification passes, the controller will continue with the subsequent process, completing the data transfer and format conversion between the memory variable address and the physical storage address. If the verification fails, the current read / write operation will terminate, and an error flag will be returned. This flag can be a predefined error code, used to indicate to the user the specific reason for the operation failure.

[0087] Furthermore, in an exemplary embodiment, a multi-layered progressive verification structure is used to implement the verification step before reading and writing. For example... Figure 4 As shown, specifically, it includes the following steps:

[0088] Step S501: Obtain the data type identifier, valid minimum value, valid maximum value, hardware version mask, and preset hash value of the parameter from the metadata mapping table.

[0089] The data type identifier specifies the data type of the parameter, such as an 8-bit unsigned integer or a 32-bit floating-point number. The hardware version mask defines the range of hardware versions that the parameter is compatible with. The preset hash value is a threshold set for hash integrity verification of the parameter.

[0090] Step S502: Perform type validation on the parameters based on the data type identifier.

[0091] Based on the standard storage length corresponding to the data type in the metadata mapping table, the data length of the parameter value is compared with this standard length. If they match, it means the parameter matches its declared type, and the process proceeds to the next level of verification. If they do not match, the read / write process is interrupted.

[0092] Step S503: Perform range verification on the parameters based on the valid minimum and valid maximum values.

[0093] The parameter value is compared with the legal minimum and maximum values ​​defined in the same metadata record to determine if it falls within the legal range. If it falls within the legal range, the process proceeds to the next level of verification; otherwise, the read / write process is interrupted.

[0094] Step S504: Perform hardware compatibility verification on the parameters based on the current hardware version number and hardware version mask of the system.

[0095] The current hardware version number and hardware version mask are defined as described above and are obtained by the controller calling the hardware interface function. A bitwise AND operation is performed on the current hardware version number and the hardware version mask to compare them. If the result of the bitwise AND operation is not 0, it indicates that the current hardware version falls within the version set compatible with this parameter, the verification passes, and the process proceeds to the next level of verification. If the verification result is 0, it means that the current hardware is incompatible with this parameter, and the read / write procedure is interrupted.

[0096] Step S505: Perform hash integrity verification on the parameters according to the preset hash value.

[0097] To verify whether the data has been accidentally modified, a hash integrity check is also required on the parameters. Typically, only parameters whose length exceeds a given range (e.g., 2 bytes) are checked. During execution, the controller uses a predefined hash algorithm to calculate the actual hash value of the parameter and compares it with a preset hash value. If they match, all checks pass. If they don't match, it indicates that the data has been corrupted or illegally modified, the check fails, and the read / write process is interrupted.

[0098] In the above steps, each failed validation step returns a specific reason for the failure, allowing developers to quickly pinpoint the source of the error. This four-layer progressive validation system comprehensively verifies the standardization, validity, and compatibility of parameters, overcoming the limitations of traditional, single-method validation. All validation rules are stored in metadata format, allowing validation strategies to be adjusted by updating the metadata mapping table without modifying the underlying source code, thus improving the system's configurability and scalability.

[0099] Specifically, the data length defines the number of contiguous storage units occupied by this parameter. When the parameter is a composite type such as an array or structure, this field ensures that the system can correctly handle the continuous read and write of its multi-unit data. The validity constraint flag is a flag used to indicate whether the system needs to perform a validity check on the parameter's value based on a preset range. The minimum and maximum valid values ​​together constitute the valid range of values ​​used for verification.

[0100] The extended metadata provides guidelines for parameter validation in the system. When the validity restriction flag is enabled, the system can validate the parameters according to the corresponding validation rules.

[0101] In an exemplary embodiment, performing a corresponding read / write operation between the memory variable address and the physical storage address further includes the following steps:

[0102] Step S601: Obtain the data type identifier of the parameter from the metadata mapping table.

[0103] Step S602: When performing a read operation, the read function corresponding to the data type identifier is called to read the parameter value from the physical storage address.

[0104] Specifically, the controller selects and calls the read parameter corresponding to the data type from the metadata mapping table, converts it to the corresponding data type, and obtains the stored value of the parameter.

[0105] Step S603: When performing a write operation, call the write function corresponding to the data type identifier to write the parameter value to the memory variable address.

[0106] Similarly, the corresponding dedicated write function is selected and called to write the stored value read and converted in step S602 to the memory variable address in the running memory pointed to by the metadata record.

[0107] In this embodiment, by storing data type identifiers as metadata and having the controller automatically associate and call the corresponding underlying functions, parameter access operations are decoupled from specific data types. This solves the problem of data parsing chaos caused by manual matching errors and allows for the addition of new data types to the system through extended function mapping relationships without modifying the upper-level initialization process framework, thereby improving code reliability and maintainability.

[0108] In one embodiment, the physical storage address of the storage medium includes two independent and physically isolated storage locations: a primary storage address and a backup storage address. The primary storage address is used for parameter access under normal circumstances; the backup storage address serves as a redundant copy and is typically located in another independent physical block of the storage medium. For example, the address space of the EEPROM is divided into a low address region and a high address region, and a backup address with a fixed offset is mapped to the primary address of each parameter. The fault-tolerant read / write operation in this embodiment includes the following steps:

[0109] Step S701: Perform read and write operations on the parameters based on the main storage address.

[0110] When a read / write request for a certain parameter is received, the system first attempts to perform the operation based on the main storage address. For a read operation, the system reads the raw data byte stream from the main address and performs the data verification as described above; for a write operation, the controller writes the valid data to the main address after completing the pre-verification.

[0111] In step S702, if the read / write operation fails, the system switches to the backup storage address to perform the read / write operation.

[0112] In step S703, if both the read and write operations based on the primary storage address and the backup storage address fail, the default value is used as the read and write result for this parameter.

[0113] If the operation fails after trying both the primary storage address and the backup storage address in sequence, the default value will be extracted from the metadata of this parameter and used as the read / write result. Furthermore, the number of retries and the retry interval can be defined for failed read / write operations, such as setting 3 retries to prevent single read / write failures due to bus conflicts.

[0114] This embodiment avoids data loss due to single-point physical damage by using primary and backup address redundancy, thus improving data recoverability. The automatic fault switching mechanism and default value fallback mechanism ensure the fault tolerance and reliability of the system.

[0115] In one exemplary embodiment, the parameter initialization phase further includes, when a firmware upgrade or parameter structure change is detected, format conversion and migration of historical parameter values ​​in the physical storage address based on the hardware version mask.

[0116] It's understandable that version management is necessary when system firmware upgrades or parameter structure definitions change, based on the corresponding version number. Specifically, the controller first reads the historical values ​​of the parameters from the storage medium and compares the hardware version mask in the current metadata record of the parameter with the historical version information associated with its stored value. This information can be stored together in a physical storage address or a specific area. If the version numbers are inconsistent, it indicates that the historical value is incompatible with the target value structure of the firmware.

[0117] At this point, based on predefined version migration rules, the historical parameter values ​​read from the physical storage address are formatted and migrated. This conversion may include data type conversion, field splitting or merging, and numerical scaling.

[0118] This embodiment solves the problem of historical configuration data loss or parsing errors caused by incompatibility of parameter structures between old and new versions during system firmware iteration upgrades by introducing version management and automatic migration mechanisms, thus ensuring the continuity and availability of configuration information before and after system upgrades.

[0119] In another exemplary embodiment, a parameter change log area is also partitioned on the storage medium. When the system responds to a change in parameters in memory and triggers a write operation to the storage medium, the controller performs additional logging operations simultaneously with or after writing the new parameter value to its target physical storage address. Log information includes, but is not limited to: the original value before writing, the changed value after writing, and the write timestamp.

[0120] By recording parameter change logs, it is possible to trace the historical changes of parameters, which is beneficial for system fault diagnosis, status backtracking, or security auditing, thereby improving the maintainability and security of the system.

[0121] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0122] Based on the same inventive concept, this application also provides an apparatus for implementing the above-described method for securely storing embedded system parameters supporting multiple scenarios. The solution provided by this apparatus is similar to the implementation described in the above method. Therefore, the specific limitations in one or more embodiments of the secure storage apparatus for embedded system parameters supporting multiple scenarios provided below can be found in the limitations of the method described above, and will not be repeated here.

[0123] In one exemplary embodiment, such as Figure 5 As shown, an embedded system parameter secure storage device 800 supporting multiple scenarios is provided, including:

[0124] The mapping construction module 801 is used to construct a metadata mapping table. The metadata mapping table stores metadata for multiple parameters, including the physical storage address of the parameter in the storage medium, the memory variable address in the running memory, and the range of legal values.

[0125] The initialization module 802 is used to initialize multiple parameters based on the metadata mapping table. The initialization includes determining the initialization scenario according to predefined trigger conditions, and performing the corresponding parameter initialization operation based on the initialization scenario and the metadata mapping table.

[0126] The storage control module 803 is used to respond to operation requests for parameters during system operation, verify parameters according to the range of valid values, and perform corresponding read and write operations between memory variable addresses and physical storage addresses.

[0127] The modules in the aforementioned embedded system parameter secure storage device supporting multiple scenarios can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independently of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0128] In one exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the program implements any of the embedded system parameter secure storage methods described in the above embodiments.

[0129] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0130] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0131] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for securely storing embedded system parameters supporting multiple scenarios, characterized in that, The method includes: Construct a metadata mapping table, which stores metadata for multiple parameters. The metadata includes the physical storage address of the parameter in the storage medium, the memory variable address in the running memory, and the range of legal values. Based on the metadata mapping table, the multiple parameters are initialized. The initialization includes determining the initialization scenario according to predefined triggering conditions, and performing corresponding parameter initialization operations based on the initialization scenario and the metadata mapping table. When the system is running, in response to an operation request for the parameter, the parameter is validated according to the range of valid values, and corresponding read and write operations are performed between the memory variable address and the physical storage address.

2. The method according to claim 1, characterized in that, The step of determining the initialization scenario based on predefined triggering conditions, and performing corresponding parameter initialization operations based on the initialization scenario and the metadata mapping table, includes: If the preset factory identifier in the storage medium is a specific value, the first factory shipment scenario is triggered, and the default values ​​of all parameters are written to the corresponding physical storage address. If the hardware version number in the storage medium is inconsistent with the current hardware version number of the embedded system, the hardware version adaptation scenario is triggered, the parameters that match the current hardware version are selected, and their default values ​​are written to the corresponding physical storage address. If a fault signal is present in the storage medium, a fault recovery scenario is triggered, and the parameters in the backup storage address are written to the corresponding physical storage address. If a partition identifier is present in the triggering conditions, a partition update scenario is triggered. Based on the received instructions, parameters belonging to the partition identifier are filtered, and their default values ​​are written to the corresponding physical storage address.

3. The method according to any one of claims 1-2, characterized in that, Before performing corresponding read / write operations between the memory variable address and the physical storage address, the method further includes: Obtain the range of valid values ​​for the parameter from the metadata mapping table; Determine whether the parameter is within the range of valid values; If the value is within the legal range, then read and write operations are performed on the parameter. If the value exceeds the range of valid values, an error flag is returned.

4. The method according to claim 3, characterized in that, The step of determining whether the parameter is within the range of valid values ​​includes: Obtain the data type identifier, valid minimum value, valid maximum value, hardware version mask, and preset hash value of the parameter from the metadata mapping table; The parameter is validated based on the data type identifier. The parameters are range-checked based on the legal minimum and legal maximum values; Based on the current hardware version number of the system and the hardware version mask, the parameters are subjected to hardware adaptation verification; The parameters are subjected to hash integrity verification based on the preset hash value.

5. The method according to claim 4, characterized in that, The method further includes: When a firmware upgrade or parameter structure change is detected, the historical parameter values ​​in the physical storage address are formatted and migrated according to the hardware version mask.

6. The method according to claim 1, characterized in that, The step of performing corresponding read / write operations between the memory variable address and the physical storage address further includes: Obtain the data type identifier of the parameter from the metadata mapping table; When a read operation is performed, the read function corresponding to the data type identifier is called to read the parameter value from the physical storage address; When a write operation is performed, the write function corresponding to the data type identifier is called to write the parameter value to the memory variable address.

7. The method according to claim 1, characterized in that, The physical storage address also includes a primary storage address and a backup storage address, and the corresponding read / write operation between the memory variable address and the physical storage address further includes: Based on the main storage address, read and write operations are performed on the parameters; If the read / write operation fails, the operation will switch to the backup storage address. If both the read and write operations based on the primary storage address and the backup storage address fail, the default value will be used as the read and write result for this parameter.

8. The method according to claim 1, characterized in that, The storage medium includes a parameter change log area, and the corresponding read / write operation between the memory variable address and the physical storage address further includes: When writing the parameter to the storage address, at least one of the following is recorded in the parameter change log area: the original value of the parameter before writing, the changed value after writing, and the writing timestamp.

9. A secure storage device for embedded system parameters supporting multiple scenarios, characterized in that, The device includes: The mapping construction module is used to construct a metadata mapping table, which stores metadata for multiple parameters. The metadata includes the physical storage address of the parameter in the storage medium, the memory variable address in the running memory, and the range of legal values. An initialization module is used to initialize the plurality of parameters based on the metadata mapping table. The initialization includes determining an initialization scenario according to predefined triggering conditions, and performing corresponding parameter initialization operations based on the initialization scenario and the metadata mapping table. The storage control module is used to, during system operation, respond to operation requests for the parameters, validate the parameters according to the range of valid values, and perform corresponding read and write operations between the memory variable address and the physical storage address.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

Images