Method for configuration persistence of embedded devices and related devices

Abstract

The embodiment of the present application provides a configuration persistence method of an embedded device and related equipment, which comprises the following steps: reading original serialized bytes of configuration data from a nonvolatile memory; performing field scanning on the original serialized bytes to obtain a field scanning result; storing original field bytes of an unknown state field to a corresponding hierarchical reserved storage area based on the field scanning result; decoding known fields based on current configuration field definition information to obtain configuration objects, and updating the known fields according to a configuration modification request; encoding the known fields of each message level during submission, and merging the original field bytes of the same message level to obtain merged configuration data, and then writing the merged configuration data back to the nonvolatile memory. Therefore, the unknown fields can be reserved during the configuration submission process, and the risk of field loss caused by re-encoding after firmware degradation is reduced.

Description

Technical Field

[0001] This invention relates to the field of embedded device firmware upgrades, and more particularly to a method, apparatus, electronic device, and storage medium for persistent configuration of embedded devices. Background Technology

[0002] Embedded devices typically need to store device configuration data locally, including product parameters, hardware parameters, operating parameters, and user configurations. To facilitate structured storage and version expansion of this configuration data, it can be stored in a serialized format in flash memory, electrically erasable programmable read-only memory (EEPROM), or other non-volatile memory. During firmware upgrades, higher firmware versions may add fields to the configuration field definition information, causing the configuration data in non-volatile memory to include fields not yet defined in lower firmware versions.

[0003] When reading configuration data, existing embedded devices typically decode the data based on the configuration field definitions corresponding to the current firmware version, and then re-encode and write back to non-volatile memory after modifying known configuration fields. For resource-constrained embedded devices, commonly used lightweight serialization encoding / decoding methods usually only decode and encode known fields in the current field definition information, while skipping unknown fields not defined in the current version during the decoding process. Therefore, when the device firmware is downgraded from a higher version to a lower version, if the lower version firmware modifies known fields and submits the configuration, the unknown fields written by the higher version firmware in the original configuration data are easily lost during the re-encoding and write-back process, making it impossible to recover this part of the configuration data when the device is subsequently upgraded to a higher version firmware.

[0004] Therefore, how to persistently retain unknown fields that are not defined in the current version during the process of an embedded device modifying and submitting known fields based on the current configuration field definition information is an urgent technical problem to be solved. Summary of the Invention

[0005] This invention provides a method for persistent configuration of embedded devices to solve the problem that unknown fields not defined in the current version are easily lost during decoding and re-encoding when resubmitting configuration data after firmware downgrade in existing embedded devices.

[0006] In a first aspect, embodiments of the present invention provide a method for persistent configuration of an embedded device, the method comprising the following steps: Read the raw serialized bytes corresponding to the configuration data from non-volatile memory; The original serialized bytes are subjected to field scanning processing to obtain the field scanning results; Based on the field scanning results, the original field bytes corresponding to the fields in the unknown state are stored in the corresponding hierarchical reserved storage area; Based on the current configuration field definition information, the fields with known states in the original serialized bytes are decoded to obtain a configuration object, and the known fields in the configuration object are updated according to the configuration modification request; When submitting the updated configuration object, the known fields in each message level are encoded to obtain the corresponding known field encoding results, and the known field encoding results are merged with the original field bytes corresponding to the same message level to obtain merged configuration data; The merged configuration data is written back to the non-volatile memory.

[0007] Optionally, the step of performing field scanning processing on the original serialized bytes to obtain the field scanning result includes: Read the field key value from the original serialized bytes; Based on the field key value, determine the field number and field type of the corresponding field; Based on the field number and the field type, the field is matched with the current configuration field definition information to obtain the field scanning result. The field scanning result includes one of the following: the known state, the unknown state, and the field type mismatch state.

[0008] Optionally, the step of matching the field number and field type with the currently configured field definition information to obtain the field scanning result includes: When the field number belongs to the field number defined in the current configuration field definition information, and the field type is consistent with the field type of the corresponding field in the current configuration field definition information, it is determined that the corresponding field is in a known state; When the field number does not belong to the field number defined in the current configuration field definition information, it is determined that the corresponding field is in an unknown state; When the field number belongs to the field number defined in the current configuration field definition information, and the field type is inconsistent with the field type of the corresponding field in the current configuration field definition information, the corresponding field is determined to be in a field type mismatch state.

[0009] Optionally, the step of storing the original field bytes corresponding to the fields in an unknown state to the corresponding hierarchical reserved storage area based on the field scan results includes: If the target field is determined to be in an unknown state based on the field scanning results, the starting position and ending position of the field key value of the target field are determined. The consecutive bytes between the start position of the field key value and the end position of the field are determined as the original field bytes corresponding to the target field; The original field bytes corresponding to the target field are appended and stored in the hierarchical reserved storage area corresponding to the message level where the target field is located.

[0010] Optionally, the step of decoding the fields with known states in the original serialized bytes based on the current configuration field definition information to obtain the configuration object includes: Based on the field number, field type, and field mapping relationship of the known fields in the current configuration field definition information, the fields in the known state in the original serialized bytes are deserialized to obtain the field assignment information corresponding to each known field; According to the configuration object structure defined by the current configuration field definition information, the assignment information of each field is written into the corresponding configuration member to obtain the configuration object.

[0011] Optionally, updating the known fields in the configuration object according to the configuration modification request includes: The configuration modification request is parsed to obtain the identifier of the field to be updated and the target field value corresponding to the identifier of the field to be updated; Based on the current configuration field definition information, the identifier of the field to be updated is matched to determine the target known field corresponding to the identifier of the field to be updated; Based on the mapping relationship between the known target fields and the configuration members in the configuration object, determine the target configuration member corresponding to the known target field; Write the target field value to the target configuration member to update the known fields in the configuration object.

[0012] Optionally, when submitting the updated configuration object, the known fields in each message level are encoded to obtain the corresponding known field encoding results, including: Based on the message hierarchy structure of the configuration object, determine multiple message levels to be encoded; For each message level, based on the current configuration field definition information, at least one field to be encoded in the message level that is in a known state is determined; Read the field assignment information corresponding to each of the fields to be encoded from the updated configuration object; According to the field number, field type and field assignment information of each field to be encoded, the fields to be encoded are serialized and encoded to obtain the known field encoding results corresponding to the message level.

[0013] Secondly, embodiments of the present invention also provide a configuration persistence device for an embedded device, the configuration persistence device for the embedded device comprising: The read module is used to read the raw serialized bytes corresponding to the configuration data from non-volatile memory; The scanning module is used to perform field scanning processing on the original serialized bytes to obtain the field scanning results; The storage module is used to store the original field bytes corresponding to the fields in an unknown state to the corresponding hierarchical reserved storage area based on the field scanning results; The decoding module is used to decode the fields with known states in the original serialized bytes based on the current configuration field definition information to obtain a configuration object, and update the known fields in the configuration object according to the configuration modification request; The update module is used to encode the known fields in each message level when submitting the updated configuration object, obtain the corresponding known field encoding results, and merge the known field encoding results with the original field bytes corresponding to the same message level to obtain merged configuration data; The retrieval module is used to write the merged configuration data back to the non-volatile memory.

[0014] Thirdly, embodiments of the present invention provide an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps in the configuration persistence method for embedded devices provided in embodiments of the present invention.

[0015] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the configuration persistence method for an embedded device provided in the embodiments of the present invention.

[0016] In this embodiment of the invention, the original serialized bytes of configuration data are read from non-volatile memory; a field scan is performed on the original serialized bytes to obtain the field scan result; based on the field scan result, the original field bytes of unknown state fields are stored in the corresponding level of reserved storage area; the known fields are decoded based on the current configuration field definition information to obtain the configuration object, and the known fields are updated according to the configuration modification request; upon submission, the known fields of each message level are encoded and merged with the original field bytes of the same message level to obtain merged configuration data, which is then written back to non-volatile memory. This allows unknown fields to be retained during the configuration submission process, reducing the risk of field loss due to re-encoding after firmware downgrading. Attached Figure Description

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

[0018] Figure 1 This is a flowchart of a configuration persistence method for an embedded device provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the configuration persistence device for another embedded device provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] like Figure 1 As shown, Figure 1 This is a flowchart of a configuration persistence method for an embedded device provided by an embodiment of the present invention. The configuration persistence method for the embedded device includes the following steps: 101. Read the raw serialized bytes corresponding to the configuration data from the non-volatile memory.

[0021] In this embodiment of the invention, the above-mentioned configuration persistence method for embedded devices can be applied to a configuration persistence platform for embedded devices. The configuration persistence platform for embedded devices has functions such as configuration persistence data processing, configuration persistence data transmission and reception, and configuration persistence data memory storage. It can be built based on a server or server cluster. The server or server cluster can be an electronic device with the capability to process configuration persistence data for embedded devices.

[0022] The configuration persistence platform of the aforementioned embedded device can read the original serialized bytes corresponding to the configuration data from non-volatile memory. This non-volatile memory can be flash memory, electrically erasable programmable read-only memory, or other memory that retains data even after power failure, used to store configuration content that needs to be retained long-term during the operation of the embedded device.

[0023] The aforementioned configuration data can refer to a set of data describing the operating status, hardware parameters, product parameters, and user-defined parameters of an embedded device. For example, in a network camera, the configuration data may include the device model, sensor name, infrared switching mode, rotation steps, binding flag, network connection parameters, and image acquisition parameters. It is understood that the configuration data can be encoded according to a protocol buffer serialization format and stored in non-volatile memory for continued use after the embedded device restarts, recovers from a power outage, or undergoes a firmware version switch.

[0024] The aforementioned raw serialized bytes refer to the raw byte stream formed after configuration data has been serialized and encoded, and is actually stored in non-volatile memory. It should be noted that these raw serialized bytes are not the field values ​​parsed by the current firmware version, but rather complete encoded data containing field keys, field types, field lengths, and field contents. After reading these raw serialized bytes, the configuration persistence platform of the embedded device can identify known and unknown fields based on the byte stream itself during subsequent processing, preventing the current firmware version from skipping unknown fields during decoding, which could lead to unrecoverable unknown fields.

[0025] For example, when an embedded device is downgraded from a higher firmware version to a lower firmware version, the configuration data in the non-volatile memory may contain fields added in the higher firmware version. After reading the original serialized bytes, the configuration persistence platform of the aforementioned embedded device can retain the original encoded form of the configuration data in memory, providing a data foundation for subsequent unknown field scanning, hierarchical storage, and merged write-back.

[0026] As one possible embodiment, the non-volatile memory may include a primary configuration partition and a backup configuration partition. The configuration persistence platform of the aforementioned embedded device can preferentially read the raw serialized bytes from the primary configuration partition, and read the raw serialized bytes from the backup configuration partition if the primary configuration partition read fails or a verification error occurs, thereby improving the reliability of the configuration reading process.

[0027] 102. Perform field scanning processing on the original serialized bytes to obtain the field scanning results.

[0028] In this embodiment of the invention, the above-mentioned field scanning process may be performed before decoding the configuration data, by sequentially reading and identifying each field in the original serialized bytes according to the field encoding rules of the serialization format, so as to determine the field number, field type, field position and message level corresponding to each field.

[0029] The above field scanning results can be used to characterize the recognition status of each field relative to the current configuration field definition information. If a field matches the current configuration field definition information, the field is in a known state; if a field fails to match the current configuration field definition information, the field is in an unknown state. Therefore, the configuration persistence platform of the aforementioned embedded device can distinguish between known and unknown fields before formal decoding, allowing known fields to participate in subsequent decoding and allowing unknown fields to enter the corresponding hierarchical retention storage area.

[0030] For example, in the downgraded operation scenario of the T23 network camera, the configuration data in the non-volatile memory can be pre-written by the higher version firmware, and includes future fields from the hardware configuration message and future fields from the operation configuration message.

[0031] After reading the original serialized bytes corresponding to future_full.bin, the configuration persistence platform of the aforementioned embedded device can perform field scanning processing before formal decoding. It identifies the binding flags that the current low-version firmware can recognize as known states, and identifies future fields in the hardware configuration message and the runtime configuration message as unknown states. Thus, the configuration persistence platform of the aforementioned embedded device can obtain field scanning results containing field states and message levels, providing a basis for subsequently storing unknown hardware configuration fields and unknown runtime configuration fields to their respective reserved storage areas.

[0032] 103. Based on the field scan results, store the original field bytes corresponding to the fields in the unknown state into the corresponding hierarchical reserved storage area.

[0033] In this embodiment of the invention, the aforementioned hierarchical reserved storage area may refer to the unknown field storage area formed according to the message hierarchy in the configuration data, which is used to store the original bytes of unknown fields scanned in different message hierarchies respectively, so as to avoid the unknown fields of different hierarchies from being mixed up during subsequent merging and writing back.

[0034] When the field scan result indicates that a certain field is in an unknown state, the configuration persistence platform of the aforementioned embedded device can determine the start and end positions of that field in the original serialized bytes and save the consecutive bytes from the field key value to the end position as the original field bytes. Since the original field bytes maintain the original encoded form of the field in non-volatile memory, lower-version firmware does not need to recognize the specific meaning of the field and can write it back as is when submitting configuration later.

[0035] For example, in a network camera scenario, configuration data can include top-level messages, product configuration messages, hardware configuration messages, and runtime configuration messages. When the configuration persistence platform for the aforementioned embedded device scans a future field in a hardware configuration message, it can save the original field bytes corresponding to that future field to the hardware configuration reserved storage area; similarly, when it scans a future field in a runtime configuration message, it can save the original field bytes corresponding to that future field to the runtime configuration reserved storage area. Thus, unknown fields in the hardware configuration message and the runtime configuration message can be saved separately, allowing for subsequent merging and writing back to the corresponding message level.

[0036] In one possible embodiment, the aforementioned hierarchical reserved storage area may include a top-level reserved storage area, a product configuration reserved storage area, a hardware configuration reserved storage area, and a runtime configuration reserved storage area. The configuration persistence platform for the embedded device may also set a length threshold for each hierarchical reserved storage area. If the cumulative length of the original field bytes stored in any hierarchical reserved storage area exceeds the length threshold, the configuration commit will be rejected to reduce the risk of unknown fields being truncated and written back.

[0037] 104. Based on the current configuration field definition information, decode the fields with known states in the original serialized bytes to obtain the configuration object, and update the known fields in the configuration object according to the configuration modification request.

[0038] In this embodiment of the invention, the aforementioned current configuration field definition information may refer to field definition content that the current firmware version can recognize, including field number, field type, field name, and the correspondence between the field and configuration members. It is understood that, since the current configuration field definition information only corresponds to the current firmware version, fields added in higher firmware versions but not yet defined in the current firmware version will not be included in the decoded and generated configuration object.

[0039] In this embodiment, fields in the original serialized bytes that are in a known state can be converted into configuration member values ​​that can be read and modified by the current firmware version, according to the current configuration field definition information.

[0040] The aforementioned configuration object can refer to a memory data object formed by decoding known fields, used to carry configuration content that can be recognized by the current firmware version, such as binding flags, infrared switching modes, rotation steps, etc.

[0041] The above configuration modification request can originate from user operations, business logic calls, or configuration change instructions during device operation, and is used to indicate the target field to be modified and the target field value.

[0042] In this embodiment, the target field value can be written into the corresponding known field in the configuration object according to the configuration modification request, so that the target known field in the configuration object is changed.

[0043] For example, older firmware versions can decode the binding flag in the original serialized bytes based on the current configuration field definition information to obtain a configuration object containing the binding flag. When a configuration modification request indicates that the binding flag be toggled, the configuration persistence platform of the aforementioned embedded device can update the binding flag in the configuration object without rewriting the hardware configuration unknown field and runtime configuration unknown field that have already been saved to the hierarchical reserved storage area.

[0044] In one possible embodiment, the configuration persistence platform of the aforementioned embedded device can also perform matching and verification on the fields to be modified in the configuration modification request before updating the configuration object. If the field to be modified is not included in the current configuration field definition information, the update of the configuration object is refused to be performed, so as to avoid the current firmware version accidentally modifying future fields that cannot be recognized.

[0045] 105. When submitting the updated configuration object, the known fields in each message level are encoded to obtain the corresponding known field encoding results. The known field encoding results are then merged with the original field bytes corresponding to the same message level to obtain the merged configuration data.

[0046] In this embodiment of the invention, the configuration persistence platform of the embedded device can encode the known fields in each message level when submitting the updated configuration object, obtain the corresponding known field encoding results, and merge the known field encoding results with the original field bytes corresponding to the same message level to obtain merged configuration data. The aforementioned known field encoding results can refer to the encoded bytes formed by re-serializing the fields defined by the current configuration field definition information in the configuration object according to the corresponding field number, field type, and field value. In other words, the known field encoding results reflect the configuration content that the current firmware version can recognize and allows to be modified. In this embodiment, within the same message level, the re-encoded known field encoding result can be concatenated with the original unknown field bytes pre-stored in the hierarchical reserved storage area. It should be noted that the above merging process does not parse, convert, or reassign the unknown field; instead, it places the unknown field back into its original corresponding message level while maintaining the original byte content of the unknown field unchanged. Therefore, even if the current firmware version cannot recognize the meaning of the unknown field, it can still retain the field content written by the higher version firmware when submitting configuration.

[0047] The aforementioned merged configuration data can refer to the complete serialized configuration data formed by the encoding results of known fields at each message level and the original field bytes of unknown fields at the corresponding level. It can include updated known fields, or unknown fields that are not defined in the current firmware version but have been retained as is.

[0048] For example, the configuration persistence platform of the aforementioned embedded device can first re-encode known fields such as binding flags, then merge the original field bytes of unknown fields pre-saved in the hardware configuration level into the hardware configuration message, and merge the original field bytes of unknown fields pre-saved in the runtime configuration level into the runtime configuration message. This achieves the goal of keeping the original bytes of future fields in the hardware configuration message and runtime configuration message unchanged while the binding flags are updated and persisted.

[0049] In one possible embodiment, after generating the merged encoded content corresponding to the sub-message, the configuration persistence platform of the above-mentioned embedded device can write the sub-message into the upper-level message according to the length-limited field format; for unknown fields in the top-level message, they can be appended to the encoding result of the top-level message after the known fields of the top-level message are encoded, thereby forming merged configuration data with clear hierarchical correspondence.

[0050] 106. Write the merged configuration data back to non-volatile memory.

[0051] In this embodiment of the invention, during the write-back process, the configuration persistence platform of the embedded device can first perform length verification, integrity verification, or partition status verification on the merged configuration data. After meeting the write conditions, the merged configuration data is written to the flash memory configuration partition. After the write-back is completed, the configuration persistence platform of the embedded device can reread the configuration data in the non-volatile memory and verify the reread configuration data to confirm that the update results of the known fields have been written to disk, and at the same time confirm that the original field bytes of the unknown fields have not changed.

[0052] After flipping the binding flag, the configuration persistence platform for the aforementioned embedded device can write back the merged configuration data, including the updated binding flag, the unknown hardware configuration field, and the unknown runtime configuration field, to the dual configuration partition. When the configuration data is loaded again after writing back, the binding flag retains its updated state, and the unknown hardware configuration field and the unknown runtime configuration field retain their original byte content before writing back, thus avoiding the loss of future fields written by the higher version firmware when submitting configurations for downgraded firmware.

[0053] In this embodiment of the invention, the original serialized bytes of configuration data are read from non-volatile memory; a field scan is performed on the original serialized bytes to obtain the field scan result; based on the field scan result, the original field bytes of unknown state fields are stored in the corresponding level of reserved storage area; the known fields are decoded based on the current configuration field definition information to obtain the configuration object, and the known fields are updated according to the configuration modification request; upon submission, the known fields of each message level are encoded and merged with the original field bytes of the same message level to obtain merged configuration data, which is then written back to non-volatile memory. This allows unknown fields to be retained during the configuration submission process, reducing the risk of field loss due to re-encoding after firmware downgrading.

[0054] Optionally, in the step of performing field scanning processing on the original serialized bytes to obtain the field scanning result, the field key value in the original serialized bytes can also be read; based on the field key value, the field number and field type of the corresponding field can be determined; according to the field number and field type, it can be matched with the currently configured field definition information to obtain the field scanning result. The field scanning result includes one of the following: the known state, the unknown state, and the field type mismatch state corresponding to the field.

[0055] In this embodiment of the invention, the aforementioned field key value may be the preamble encoding information of the field in the serialized byte stream, used to indicate the field number corresponding to the current field and the encoding type used by the current field. By reading the field key value, the configuration persistence platform of the aforementioned embedded device can determine the basic attributes of the current field in the byte stream without directly decoding the complete configuration object.

[0056] The aforementioned current configuration field definition information can be a set of configuration field definitions that the current firmware version can recognize, including field number, field type, message level to which the field belongs, and the correspondence between the field and configuration members. It is understandable that, since the configuration field definition information may differ between different firmware versions, fields added in higher firmware versions may not have corresponding definitions in lower firmware versions; therefore, matching and determining based on field number and field type is necessary.

[0057] In this embodiment, the field number and field type parsed from the field key value can be compared with the field number and field type recorded in the current configuration field definition information. If both the field number and field type match, the field is determined to be in a known state; if the field number cannot be found in the current configuration field definition information, the field is determined to be in an unknown state; if the field number can be found in a corresponding definition but the field type is inconsistent, the field is determined to be in a field type mismatch state.

[0058] Generally, the current configuration field definition information corresponding to lower firmware versions can identify fields such as binding flags. After reading the raw serialized bytes, the configuration persistence platform of the aforementioned embedded device can match the fields corresponding to the binding flags to a known state, and match the future hardware configuration fields and future runtime configuration fields written by higher firmware versions to an unknown state, thereby providing a basis for subsequent decoding of known fields and hierarchical storage of unknown fields.

[0059] Optionally, in the step of matching the field number and field type with the current configuration field definition information to obtain the field scanning result, the method further includes determining that the corresponding field is in a known state when the field number belongs to the field number defined in the current configuration field definition information and the field type is consistent with the field type of the corresponding field in the current configuration field definition information; determining that the corresponding field is in an unknown state when the field number does not belong to the field number defined in the current configuration field definition information; and determining that the corresponding field is in a field type mismatch state when the field number belongs to the field number defined in the current configuration field definition information and the field type is inconsistent with the field type of the corresponding field in the current configuration field definition information.

[0060] In this embodiment of the invention, the configuration persistence platform of the embedded device can match the field number and field type with the current configuration field definition information to obtain the field scanning result. If the field number can be found in the current configuration field definition information and the field type is consistent with the field type in the corresponding definition, then the configuration persistence platform of the embedded device determines that the field is in a known state.

[0061] If a field number is not included in the current configuration field definition information, the configuration persistence platform of the embedded device determines that the field is in an unknown state. Fields in an unknown state do not enter the current version's decoding process, but are saved as raw field bytes to the corresponding level's reserved storage area for subsequent merging and writing back.

[0062] If a field number can be found in the current configuration field definition information, but the field type is inconsistent with the field type in the corresponding definition, the configuration persistence platform of the embedded device determines that the field is in a field type mismatch state. A field type mismatch state indicates that the configuration data is abnormal or that the field encoding conflicts with the current definition. In this case, decoding can be stopped or the write-back can be rejected to prevent abnormal data from continuing to be persisted.

[0063] For example, in a network camera downgrade operation scenario, if the field number and field type of the bound flag match the current configuration field definition information of the lower firmware version, it is determined to be in a known state. However, the hardware configuration future field and runtime configuration future field added in the higher firmware version are determined to be in an unknown state because their field numbers are not included in the current configuration field definition information of the lower firmware version. If the field number of a certain field is the same as a field defined in the lower firmware version, but its field type is inconsistent with the definition in the lower firmware version, then the configuration persistence platform of the aforementioned embedded device can determine that field as a field type mismatch state.

[0064] Optionally, the step of storing the original field bytes corresponding to the field in an unknown state to the corresponding hierarchical reserved storage area based on the field scanning results further includes, if the target field is determined to be in an unknown state based on the field scanning results, determining the start position and end position of the field key value of the target field; determining the consecutive bytes between the start position and the end position of the field key value as the original field bytes corresponding to the target field; and appending the original field bytes corresponding to the target field to the hierarchical reserved storage area corresponding to the message level where the target field is located.

[0065] In this embodiment of the invention, the configuration persistence platform of the embedded device, when determining that the target field is in an unknown state based on the field scanning results, can determine the start and end positions of the field key value of the target field in the original serialized bytes. The start position of the field key value can be the position where the target field first appears in the byte stream, and the end position can be the position corresponding to the completion of reading the field content of the target field. By determining these two positions, the original range of the unknown field in the original serialized bytes can be completely defined.

[0066] The configuration persistence platform for the aforementioned embedded device can identify the continuous bytes between the start and end positions of the field key as the original field bytes corresponding to the target field. These original field bytes include both the field key and the field content of the target field, preserving the original encoded form of the target field when it was written by a higher firmware version. For unknown fields that the current firmware version cannot recognize, the configuration persistence platform does not need to parse the meaning of the field or regenerate its value; it only needs to truncate and save the data according to the original byte range.

[0067] The configuration persistence platform for the aforementioned embedded device can also append the original field bytes corresponding to the target field to the corresponding reserved storage area based on the message level where the target field is located. Appending storage can involve writing the original field bytes of the current target field to the existing original field bytes of unknown fields at the corresponding level, so that multiple unknown fields in the same message level can be retained together and merged back into the same message level during subsequent configuration submissions.

[0068] Optionally, in the step of decoding the fields in the known state of the original serialized bytes based on the current configuration field definition information to obtain the configuration object, the method further includes deserializing the fields in the known state of the original serialized bytes according to the field number, field type, and field mapping relationship of the known fields in the current configuration field definition information to obtain the field assignment information corresponding to each known field; and writing the field assignment information into the corresponding configuration member according to the configuration object structure defined by the current configuration field definition information to obtain the configuration object.

[0069] In this embodiment of the invention, the configuration persistence platform of the above-mentioned embedded device can perform deserialization processing on the fields in the known state in the original serialized bytes according to the field number, field type and field mapping relationship of the known fields in the current configuration field definition information, so as to obtain the field assignment information corresponding to each known field.

[0070] The above field mapping relationship can refer to the correspondence between field numbers and configuration members in the configuration object, which is used to determine which member position in the configuration object a certain field should be written into after decoding.

[0071] The aforementioned deserialization process refers to restoring the encoded field content in the original serialized bytes to field values ​​that the current firmware version can recognize. The field assignment information can be the specific field values ​​obtained after deserialization, such as numbers, strings, booleans, or enumeration values. After obtaining the field assignment information, the configuration persistence platform of the embedded device can write the field assignment information into the corresponding configuration members according to the configuration object structure defined by the current configuration field definition information, thereby obtaining the configuration object.

[0072] In one possible embodiment, in a network camera scenario, the lower firmware version can identify fields such as binding flag, infrared switching mode, and rotation steps. The configuration persistence platform of the aforementioned embedded device can write the field value corresponding to the binding flag to the binding configuration member of the configuration object, and write the field value corresponding to the infrared switching mode to the infrared configuration member of the configuration object, based on the field number and field mapping relationship.

[0073] For the hardware configuration future fields and runtime configuration future fields that have been identified as being in an unknown state, they will not participate in deserialization processing, nor will they be written to the configuration object. Instead, they will continue to be stored in the corresponding level of reserved storage area.

[0074] Optionally, the step of updating known fields in the configuration object according to the configuration modification request further includes parsing the configuration modification request to obtain the identifier of the field to be updated and the target field value corresponding to the identifier of the field to be updated; matching the identifier of the field to be updated based on the current configuration field definition information to determine the target known field corresponding to the identifier of the field to be updated; determining the target configuration member corresponding to the target known field according to the mapping relationship between the target known field and the configuration members in the configuration object; and writing the target field value into the target configuration member to update the known fields in the configuration object.

[0075] In this embodiment of the invention, the configuration persistence platform of the embedded device can parse the configuration modification request to obtain the identifier of the field to be updated and the corresponding target field value. Generally, the configuration items to be modified and the modified configuration values ​​can be extracted from the configuration modification request.

[0076] The above-mentioned field identifier can be used to indicate the field that needs to be updated this time, such as the binding flag, infrared switching mode, or rotation steps; the above-mentioned target field value can be the new value to be written to the field.

[0077] In this embodiment, the configuration persistence platform of the embedded device can match the identifier of the field to be updated based on the current configuration field definition information to determine the target known field corresponding to the identifier of the field to be updated. The target known field can be a field that has been defined and is allowed to be modified in the current firmware version. If the identifier of the field to be updated cannot match the current configuration field definition information, it means that the field does not belong to the known fields that the current firmware version can recognize, and the update can be rejected to avoid accidentally modifying unknown fields.

[0078] The aforementioned mapping relationship refers to the correspondence between known target fields and configuration members in the configuration object. After determining the known target fields, the configuration persistence platform of the embedded device can find the corresponding target configuration members according to the above mapping relationship and write the target field values ​​into the target configuration members, thereby completing the update of the known fields in the configuration object.

[0079] In one possible embodiment, when a configuration modification request is used to toggle the binding flag, the configuration persistence platform of the embedded device can parse the identifier of the field to be updated corresponding to the binding flag and the new binding status value. Since the binding flag is a known field that lower-version firmware can recognize, the configuration persistence platform of the embedded device can find the binding configuration member in the configuration object according to the mapping relationship and write the new binding status value to that binding configuration member. The hardware configuration future field and the runtime configuration future field are not known fields in the current configuration field definition information, and therefore do not participate in this update.

[0080] Optionally, the step of encoding the known fields in each message level to obtain the corresponding known field encoding results when submitting the updated configuration object further includes: determining multiple message levels to be encoded based on the message hierarchy structure of the configuration object; for each message level, determining at least one field to be encoded that is in a known state based on the current configuration field definition information; reading the field assignment information corresponding to each field to be encoded from the updated configuration object; and performing serialization encoding on each field to be encoded according to the field number, field type, and field assignment information to obtain the known field encoding results corresponding to the message level.

[0081] In this embodiment of the invention, when the configuration persistence platform of the embedded device submits an updated configuration object, it can determine multiple message levels that need to be re-encoded based on the message hierarchy structure of the configuration object. The message hierarchy structure can be consistent with the original organization of the configuration data, for example, including top-level configuration messages, product configuration messages, hardware configuration messages, and runtime configuration messages, so that subsequent encoding results maintain the original hierarchical relationship of the configuration data.

[0082] For each message level, the configuration persistence platform of the aforementioned embedded device can determine the fields to be encoded that are in a known state within that message level based on the current configuration field definition information, and read the field assignment information corresponding to each field to be encoded from the updated configuration object. Subsequently, the configuration persistence platform of the aforementioned embedded device performs serialization encoding according to the field number, field type, and field assignment information of each field to be encoded, to obtain the known field encoding result corresponding to that message level. The aforementioned known field encoding result only includes the field content that can be recognized and regenerated by the current firmware version, and does not include the original field bytes of the previously saved unknown fields.

[0083] In the T23 network camera scenario, after the binding flag is updated, the configuration persistence platform of the aforementioned embedded device can re-encode the running configuration message containing the binding flag to obtain the encoding results of the known fields in the running configuration message. For future fields in the hardware configuration message and running configuration message that cannot be recognized by the low-version firmware, they will not participate in this serialization encoding, but will be backfilled to the corresponding message level in the form of original field bytes in the subsequent merging process.

[0084] like Figure 2 As shown, this embodiment of the invention also provides a configuration persistence device 200 for an embedded device, the configuration persistence device 200 for the embedded device comprising: The reading module 201 is used to read the original serialized bytes corresponding to the configuration data from the non-volatile memory; Scanning module 202 is used to perform field scanning processing on the original serialized bytes to obtain field scanning results; Storage module 203 is used to store the original field bytes corresponding to the fields in an unknown state to the corresponding hierarchical reserved storage area based on the field scanning results; The decoding module 204 is used to decode the fields with known states in the original serialized bytes based on the current configuration field definition information to obtain a configuration object, and update the known fields in the configuration object according to the configuration modification request; The update module 205 is used to encode the known fields in each message level when submitting the updated configuration object, obtain the corresponding known field encoding results, and merge the known field encoding results with the original field bytes corresponding to the same message level to obtain merged configuration data. The retrieval module 206 is used to write the merged configuration data back to the non-volatile memory.

[0085] Optionally, the scanning module 202 described above is used for: Read the field key value from the original serialized bytes; Based on the field key value, determine the field number and field type of the corresponding field; Based on the field number and the field type, the field is matched with the current configuration field definition information to obtain the field scanning result. The field scanning result includes one of the following: the known state, the unknown state, and the field type mismatch state.

[0086] Optionally, the scanning module 202 described above is also used for: When the field number belongs to the field number defined in the current configuration field definition information, and the field type is consistent with the field type of the corresponding field in the current configuration field definition information, it is determined that the corresponding field is in a known state; When the field number does not belong to the field number defined in the current configuration field definition information, it is determined that the corresponding field is in an unknown state; When the field number belongs to the field number defined in the current configuration field definition information, and the field type is inconsistent with the field type of the corresponding field in the current configuration field definition information, the corresponding field is determined to be in a field type mismatch state.

[0087] Optionally, the aforementioned storage module 203 is used for: If the target field is determined to be in an unknown state based on the field scanning results, the starting position and ending position of the field key value of the target field are determined. The consecutive bytes between the start position of the field key value and the end position of the field are determined as the original field bytes corresponding to the target field; The original field bytes corresponding to the target field are appended and stored in the hierarchical reserved storage area corresponding to the message level where the target field is located.

[0088] Optionally, the above decoding module 204 is used for: Based on the field number, field type, and field mapping relationship of the known fields in the current configuration field definition information, the fields in the known state in the original serialized bytes are deserialized to obtain the field assignment information corresponding to each known field; According to the configuration object structure defined by the current configuration field definition information, the assignment information of each field is written into the corresponding configuration member to obtain the configuration object.

[0089] Optionally, the decoding module 204 described above is also used for: The configuration modification request is parsed to obtain the identifier of the field to be updated and the target field value corresponding to the identifier of the field to be updated; Based on the current configuration field definition information, the identifier of the field to be updated is matched to determine the target known field corresponding to the identifier of the field to be updated; Based on the mapping relationship between the known target fields and the configuration members in the configuration object, determine the target configuration member corresponding to the known target field; Write the target field value to the target configuration member to update the known fields in the configuration object.

[0090] Optionally, the aforementioned update module 205 is used for: Based on the message hierarchy structure of the configuration object, determine multiple message levels to be encoded; For each message level, based on the current configuration field definition information, at least one field to be encoded in the message level that is in a known state is determined; Read the field assignment information corresponding to each of the fields to be encoded from the updated configuration object; According to the field number, field type and field assignment information of each field to be encoded, the fields to be encoded are serialized and encoded to obtain the known field encoding results corresponding to the message level.

[0091] like Figure 3 As shown, this embodiment of the invention also provides an electronic device 300, including a processor, which can execute any of the above-described embedded device configuration persistence methods.

[0092] Specifically, it includes a processor 301 and a memory 302, as well as a computer program stored in the memory 302 and capable of running on the processor 301, which executes a method for persisting the configuration of an embedded device, wherein: The processor 301 executes the calculator program for the embedded device configuration persistence method stored in the memory 302, performing the following steps: Read the raw serialized bytes corresponding to the configuration data from non-volatile memory; The original serialized bytes are subjected to field scanning processing to obtain the field scanning results; Based on the field scanning results, the original field bytes corresponding to the fields in the unknown state are stored in the corresponding hierarchical reserved storage area; Based on the current configuration field definition information, the fields with known states in the original serialized bytes are decoded to obtain a configuration object, and the known fields in the configuration object are updated according to the configuration modification request; When submitting the updated configuration object, the known fields in each message level are encoded to obtain the corresponding known field encoding results, and the known field encoding results are merged with the original field bytes corresponding to the same message level to obtain merged configuration data; The merged configuration data is written back to the non-volatile memory.

[0093] Optionally, the processor 301 performs the field scanning process on the original serialized bytes to obtain the field scanning result, including: Read the field key value from the original serialized bytes; Based on the field key value, determine the field number and field type of the corresponding field; Based on the field number and the field type, the field is matched with the current configuration field definition information to obtain the field scanning result. The field scanning result includes one of the following: the known state, the unknown state, and the field type mismatch state.

[0094] Optionally, the processor 301 performs the matching based on the field number and the field type with the currently configured field definition information to obtain the field scan result, including: When the field number belongs to the field number defined in the current configuration field definition information, and the field type is consistent with the field type of the corresponding field in the current configuration field definition information, it is determined that the corresponding field is in a known state; When the field number does not belong to the field number defined in the current configuration field definition information, it is determined that the corresponding field is in an unknown state; When the field number belongs to the field number defined in the current configuration field definition information, and the field type is inconsistent with the field type of the corresponding field in the current configuration field definition information, it is determined that the corresponding field is in a field type mismatch state.

[0095] Optionally, the processor 301 executes the step of storing the original field bytes corresponding to the fields in an unknown state to the corresponding hierarchical reserved storage area based on the field scan result, including: If the target field is determined to be in an unknown state based on the field scanning results, the starting position and ending position of the field key value of the target field are determined. The consecutive bytes between the start position of the field key value and the end position of the field are determined as the original field bytes corresponding to the target field; The original field bytes corresponding to the target field are appended and stored in the hierarchical reserved storage area corresponding to the message level where the target field is located.

[0096] Optionally, processor 301 executes the process of decoding fields with known states in the original serialized bytes based on the current configuration field definition information to obtain a configuration object, including: Based on the field number, field type, and field mapping relationship of the known fields in the current configuration field definition information, the fields in the known state in the original serialized bytes are deserialized to obtain the field assignment information corresponding to each known field; According to the configuration object structure defined by the current configuration field definition information, the assignment information of each field is written into the corresponding configuration member to obtain the configuration object.

[0097] Optionally, the processor 301 performs the update of known fields in the configuration object according to the configuration modification request, including: The configuration modification request is parsed to obtain the identifier of the field to be updated and the target field value corresponding to the identifier of the field to be updated; Based on the current configuration field definition information, the identifier of the field to be updated is matched to determine the target known field corresponding to the identifier of the field to be updated; Based on the mapping relationship between the known target fields and the configuration members in the configuration object, determine the target configuration member corresponding to the known target field; Write the target field value to the target configuration member to update the known fields in the configuration object.

[0098] Optionally, when the processor 301 executes the step of submitting the updated configuration object, it encodes the known fields in each message level to obtain the corresponding known field encoding results, including: Based on the message hierarchy structure of the configuration object, determine multiple message levels to be encoded; For each message level, based on the current configuration field definition information, at least one field to be encoded in the message level that is in a known state is determined; Read the field assignment information corresponding to each of the fields to be encoded from the updated configuration object; According to the field number, field type and field assignment information of each field to be encoded, the fields to be encoded are serialized and encoded to obtain the known field encoding results corresponding to the message level.

[0099] This invention also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the embedded device configuration persistence method or the application-side embedded device configuration persistence method provided in this invention, and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0100] Those skilled in the art will understand that implementing all or part of the processes in the above embodiments can be done by a computer program instructing related hardware, and can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0101] The above description discloses only preferred embodiments of the present invention and should not be construed as limiting the scope of the present invention. Therefore, equivalent variations made in accordance with the claims of the present invention are still within the scope of the present invention.

Claims

1. A method for persistent configuration of an embedded device, characterized in that, Used in embedded devices, including: Read the raw serialized bytes corresponding to the configuration data from non-volatile memory; The original serialized bytes are subjected to field scanning processing to obtain the field scanning results; Based on the field scanning results, the original field bytes corresponding to the fields in the unknown state are stored in the corresponding hierarchical reserved storage area; Based on the current configuration field definition information, the fields with known states in the original serialized bytes are decoded to obtain a configuration object, and the known fields in the configuration object are updated according to the configuration modification request; When submitting the updated configuration object, the known fields in each message level are encoded to obtain the corresponding known field encoding results, and the known field encoding results are merged with the original field bytes corresponding to the same message level to obtain merged configuration data; The merged configuration data is written back to the non-volatile memory.

2. The method for persistent configuration of an embedded device as described in claim 1, characterized in that, The process of performing a field scan on the original serialized bytes to obtain the field scan result includes: Read the field key value from the original serialized bytes; Based on the field key value, determine the field number and field type of the corresponding field; Based on the field number and the field type, the field is matched with the current configuration field definition information to obtain the field scanning result. The field scanning result includes one of the following: the known state, the unknown state, and the field type mismatch state.

3. The method for persistent configuration of an embedded device as described in claim 2, characterized in that, The step of matching the field number and field type with the currently configured field definition information to obtain the field scanning result includes: When the field number belongs to the field number defined in the current configuration field definition information, and the field type is consistent with the field type of the corresponding field in the current configuration field definition information, it is determined that the corresponding field is in a known state; When the field number does not belong to the field number defined in the current configuration field definition information, it is determined that the corresponding field is in an unknown state; When the field number belongs to the field number defined in the current configuration field definition information, and the field type is inconsistent with the field type of the corresponding field in the current configuration field definition information, the corresponding field is determined to be in a field type mismatch state.

4. The method for persistent configuration of an embedded device as described in claim 1, characterized in that, The step of storing the original field bytes corresponding to fields in an unknown state to the corresponding hierarchical reserved storage area based on the field scan results includes: If the target field is determined to be in an unknown state based on the field scanning results, the starting position and ending position of the field key value of the target field are determined. The consecutive bytes between the start position of the field key value and the end position of the field are determined as the original field bytes corresponding to the target field; The original field bytes corresponding to the target field are appended and stored in the hierarchical reserved storage area corresponding to the message level where the target field is located.

5. The method for persistent configuration of an embedded device as described in claim 1, characterized in that, The step of decoding the fields with known states in the original serialized bytes based on the current configuration field definition information to obtain the configuration object includes: Based on the field number, field type, and field mapping relationship of the known fields in the current configuration field definition information, the fields in the known state in the original serialized bytes are deserialized to obtain the field assignment information corresponding to each known field; According to the configuration object structure defined by the current configuration field definition information, the assignment information of each field is written into the corresponding configuration member to obtain the configuration object.

6. The method for persistent configuration of an embedded device as described in claim 5, characterized in that, The step of updating known fields in the configuration object according to the configuration modification request includes: The configuration modification request is parsed to obtain the identifier of the field to be updated and the target field value corresponding to the identifier of the field to be updated; Based on the current configuration field definition information, the identifier of the field to be updated is matched to determine the target known field corresponding to the identifier of the field to be updated; Based on the mapping relationship between the known target fields and the configuration members in the configuration object, determine the target configuration member corresponding to the known target field; Write the target field value to the target configuration member to update the known fields in the configuration object.

7. The method for persistent configuration of an embedded device as described in claim 1, characterized in that, When submitting the updated configuration object, the known fields in each message level are encoded to obtain the corresponding known field encoding results, including: Based on the message hierarchy structure of the configuration object, determine multiple message levels to be encoded; For each message level, based on the current configuration field definition information, at least one field to be encoded in the message level that is in a known state is determined; Read the field assignment information corresponding to each of the fields to be encoded from the updated configuration object; According to the field number, field type and field assignment information of each field to be encoded, the fields to be encoded are serialized and encoded to obtain the known field encoding results corresponding to the message level.

8. A configuration persistence device for an embedded device, characterized in that, include: The read module is used to read the raw serialized bytes corresponding to the configuration data from non-volatile memory; The scanning module is used to perform field scanning processing on the original serialized bytes to obtain the field scanning results; The storage module is used to store the original field bytes corresponding to the fields in an unknown state to the corresponding hierarchical reserved storage area based on the field scanning results; The decoding module is used to decode the fields with known states in the original serialized bytes based on the current configuration field definition information to obtain a configuration object, and update the known fields in the configuration object according to the configuration modification request; The update module is used to encode the known fields in each message level when submitting the updated configuration object, obtain the corresponding known field encoding results, and merge the known field encoding results with the original field bytes corresponding to the same message level to obtain merged configuration data; The retrieval module is used to write the merged configuration data back to the non-volatile memory.

9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the configuration persistence method for an embedded device as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the configuration persistence method for an embedded device as described in any one of claims 1 to 7.

Images