Parameter management method and device of electric energy meter

Abstract

The invention provides an electric energy meter parameter management method and device, and belongs to the technical field of electric energy meter parameter management. The parameter management method of the electric energy meter comprises the following steps: S1, defining a plurality of unified structural bodies corresponding to a plurality of applications respectively, wherein the unified structural bodies are used for packaging application parameters; s2, a plurality of unified structural bodies are stored respectively; and S3, reading the corresponding unified structural body during power-on initialization. All application parameters are defined in a unified mode, configuration centralization is achieved, the parameters are not dispersed in all functional modules any more, and the unified management and maintenance efficiency is improved; data integrity is guaranteed, parameter damage caused by power failure or interference is prevented through CRC check and double backup storage, and reliability is improved; unified structural body storage is adopted, the storage space is saved, the memory is controllable, and resources are efficiently utilized; and applications are dynamically amplified, and application parameters are newly added only by expanding a default parameter table without modifying storage logic.

Description

Technical Field

[0001] This invention relates to the field of electricity meter parameter management technology, and more specifically, to a method and apparatus for managing electricity meter parameters. Background Technology

[0002] In the application of electricity meters, parameter configuration management is a core element to ensure stable system operation. Current software systems widely use EEPROM / Flash for parameter configuration management, performing initial configuration based on system flags upon power-up. However, default parameters in existing systems are often scattered across application C files for different functions, with parameters interspersed in areas unrelated to their own functions, resulting in high coupling. These parameters are often hard-coded as global variables in the system initialization function, and the storage space allocated to them is relatively disorganized. As electricity meter functions become increasingly complex and the number of parameters grows, maintainability becomes paramount.

[0003] Taking serial port baud rate configuration as an example, the current methods for managing electricity meter parameters mainly include: 1. Macro definition + global variable: Default values ​​are defined by macros and assigned to global variables during initialization, then directly written to a fixed address in EEPROM; 2. Distributed structure storage: Each functional module defines its own parameter structure, packages the parameters into structures, and stores them independently; 3. Key-value database storage: Lightweight databases are used to manage parameters, such as embedded SQLite. The current methods for managing electricity meter parameters have the following problems: 1. Weak scalability: Adding a new module requires modifying multiple code entries, sometimes even the main program logic, resulting in high maintenance costs; 2. Distributed default value management: Parameters are defined independently for each module, and default values ​​are scattered across different files, requiring individual loading during power-on initialization; 3. High coupling: Parameters are strongly coupled with business logic; modifying a parameter may affect other modules, hindering development division of labor and independent verification; 4. Performance bottleneck: Low parameter retrieval efficiency, such as traversing parameter linked lists, impacts system startup speed. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a method and apparatus for managing the parameters of an electricity meter.

[0005] Firstly, this application provides a method for managing the parameters of an electricity meter, comprising the following steps: S1: Define multiple unified structures corresponding to multiple applications, and the unified structures are used to encapsulate application parameters; S2: Stores multiple unified structures separately; S3: Read the corresponding unified structure during power-on initialization.

[0006] Preferably, the application parameters include an identifier (ID) element, a CRC check element, and multiple functional parameter elements.

[0007] Preferably, step S2 specifically includes: alternately writing multiple unified structures into two sectors to perform dual backup storage of multiple unified structures; in step S3, if the data of the preset unified structure in one sector is incorrect, the data corresponding to the preset unified structure is read in the other sector.

[0008] Preferably, step S3 specifically includes: S31: Load multiple unified structures; S32: Obtain the current identifier ID element corresponding to the current application, and obtain the target unified structure from multiple unified structures based on the current identifier ID element; S33: Perform CRC check on the target unified structure; S34: If the CRC check is correct, load the data of the target unified structure and assign the data to the variable corresponding to the current application.

[0009] Preferably, the loading of the data of the target unified structure in step S34 specifically includes: if the CRC check is correct, obtaining the offset address corresponding to the target unified structure, and loading the data of the target unified structure based on the offset address.

[0010] Secondly, embodiments of this application provide a parameter management device for an electricity meter, including a configuration module, a first storage module, and a reading module; The configuration module is used to define multiple unified structures corresponding to multiple applications, and the unified structures are used to encapsulate application parameters. The first storage module is used to store multiple unified structures respectively; The reading module is used to read the corresponding unified structure during power-on initialization.

[0011] Preferably, the application parameters include an identifier ID element, a CRC check element, and multiple functional parameter elements; the first storage module is an EEPROM or Flash.

[0012] Preferably, the first storage module is used to alternately write multiple unified structures into two sectors to perform dual backup storage of the multiple unified structures; The reading module is used to read the data corresponding to the preset unified structure in another sector if there is an error in the data of the preset unified structure in one sector.

[0013] The reading module includes a first loading unit, a first identification unit, a first verification and judgment unit, and a first assignment unit; The first loading unit is used to load multiple unified structures; The first identification unit is used to obtain the current identifier ID element corresponding to the current application, and to obtain the target unified structure from multiple unified structures based on the current identifier ID element; The first verification and judgment unit is used to perform CRC verification and judgment on the target unified structure; The first assignment unit is used to load the data of the target unified structure if the CRC check is correct, and assign the data to the variable corresponding to the current application.

[0014] The first assignment unit includes: if the CRC check is correct, obtaining the offset address corresponding to the target unified structure, and loading the data of the target unified structure based on the offset address.

[0015] The beneficial effects of this invention are as follows: all application parameters are uniformly defined, realizing centralized configuration, no longer scattered in various functional modules, thus improving the efficiency of unified management and maintenance; data integrity is guaranteed, and parameter damage caused by power outages or interference is prevented through CRC check and dual backup storage, thus improving reliability; a unified structure storage is adopted, saving storage space, making memory controllable and resources efficiently utilized; applications can be dynamically expanded, and adding new application parameters only requires expanding the default parameter table without modifying the storage logic. Attached Figure Description

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

[0017] Figure 1 A flowchart illustrating a parameter management method for an electricity meter provided in an embodiment of this application; Figure 2 A schematic diagram of the structure of a parameter management device for an electricity meter provided in an embodiment of this application; Figure 3 This is a flowchart illustrating the process of reading parameters with a unified structure, modifying parameters, and caching new CRC in a parameter management method for an electricity meter provided in this application embodiment. Figure 4 This is a flowchart illustrating the process of mounting multiple applications in a parameter management method for an electricity meter provided in this application embodiment. Detailed Implementation

[0018] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0019] In the following description, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The following description provides multiple embodiments of this application, which can be substituted or combined with each other. Therefore, this application can also be considered to include all possible combinations of the same and / or different embodiments described. Thus, if one embodiment includes features A, B, and C, and another embodiment includes features B and D, then this application should also be considered to include embodiments containing one or more other possible combinations of A, B, C, and D, even if such embodiments are not explicitly described in the following text.

[0020] The following description provides examples and does not limit the scope, applicability, or examples set forth in the claims. Changes may be made to the function and arrangement of the described elements without departing from the scope of this application. Various processes or components may be appropriately omitted, substituted, or added to the examples. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Furthermore, features described with respect to some examples may be combined into other examples.

[0021] Please see Figure 1 . Figure 1 This is a flowchart illustrating a parameter management method for an electricity meter according to an embodiment of this application. In this embodiment, the method includes the following steps: S1: Define multiple unified structures corresponding to multiple applications, and the unified structures are used to encapsulate application parameters; S2: Stores multiple unified structures separately; S3: Read the corresponding unified structure during power-on initialization.

[0022] In this embodiment, multiple unified structures are defined, each corresponding to a different application or operating mode. Each application has different parameters, and the unified structure is defined according to the parameter requirements of each application. The parameters of these multiple unified structures are different.

[0023] In the embodiments of this application, the technology used in this invention relates to the fields of computer technology, electronic information engineering technology, and embedded system technology, and particularly to structure pointers, SOC memory remapping, MCU memory management, and EEPROM / Flash data reading and writing. Specifically, it is applied to the programming method for configuring default parameters of multiple applications in an energy meter, and can be extended to other programming schemes that have default parameter applications and require efficient and reliable management of configuration parameters.

[0024] In one possible implementation, the application parameters include an identifier ID element, a CRC check element, and multiple functional parameter elements.

[0025] In the embodiments of this application, reliable and efficient parameter management is achieved through the following technical means: 1. Structured parameter definition: Use a unified structure to encapsulate each application parameter, including elements such as app_id, function parameters, and CRC checksum.

[0026] Example: typedef struct { uint16_t app_id; / / Application identifier uint32_t param1; / / Function parameter 1 uint16_t param2; / / Function parameter 2 uint16_t crc; / / CRC16 checksum AppParams.

[0027] 2. Storage architecture is layered, defining three layers: Default layer: Default parameter array statically initialized at compile time (stored in ROM); Runtime layer: Current parameters persisted in EEPROM / Flash (supports dynamic updates); Cache layer: Active parameters loaded in RAM (accelerates access). In the structured parameter definition, the listed instance structures define parameter variables. These variables operate at various levels of the storage architecture, essentially abstracting variables during structuring and then materializing them at each level.

[0028] 3. A secure storage mechanism is introduced, featuring dual-backup storage: Data is written alternately to two sectors to prevent data corruption due to write interruptions. Storage is based on data importance; dual backups typically store data in two sectors of the EEPROM. If data in one sector is corrupted, the other sector is read. A unified structure is alternately written to both sectors, ensuring all contents of the unified structure are written. CRC checksum: Automatic rollback to default value occurs upon checksum failure.

[0029] 4. Dynamic compatibility handling, field mask marking: supports optional parameters (such as setting unused fields to zero).

[0030] In one possible implementation, step S2 specifically includes: alternately writing multiple unified structures into two sectors to perform dual backup storage of multiple unified structures; in step S3, if the data of a preset unified structure in one sector is incorrect, the data corresponding to the preset unified structure is read from the other sector.

[0031] In this embodiment, dual-backup storage involves alternately writing to two sectors to prevent data corruption due to write interruptions. Storage is based on the importance of the data; dual backups typically store data in two sectors of the EEPROM. If data in one sector is corrupted, the other sector is read. A unified structure is alternately written to both sectors, ensuring that the entire content of the unified structure is written.

[0032] In one possible implementation, step S3 specifically includes: S31: Load multiple unified structures; S32: Obtain the current identifier ID element corresponding to the current application, and obtain the target unified structure from multiple unified structures based on the current identifier ID element; S33: Perform CRC check on the target unified structure; S34: If the CRC check is correct, load the data of the target unified structure and assign the data to the variable corresponding to the current application.

[0033] In this embodiment, step S33 specifically includes: performing a CRC check before reading during a read operation; updating the checksum after writing data during a write operation; and checking the data checksum during device power-on initialization. If the checksum fails, the device automatically reverts to the default value as follows: if a checksum error is detected during power-on, the default value corresponding to the unified structure already stored in the EEPROM / Flash is read and assigned to the initial variable.

[0034] In one possible implementation, loading the data of the target unified structure in step S34 specifically includes: if the CRC check is correct, obtaining the offset address corresponding to the target unified structure, and loading the data of the target unified structure based on the offset address.

[0035] In this embodiment, each functional module only needs to read the data of the corresponding segment through a fixed offset address. The data of the corresponding segment refers to the data at the corresponding position in the unified structure. All data is allocated to different addresses, and the data in each segment corresponds to the structure data of its respective application. In the unified structure, each parameter corresponds to a fixed offset address. The parameter can be read through this fixed offset address, and the structure parameter and the storage address have the same alignment length.

[0036] In the embodiments of this application, see Figure 3The process includes the following steps: system power-on initialization; loading the parameter structure array from EEPROM / Flash; verifying the CRC / version number or loading default parameters and writing them to EEPROM; using EEPROM parameters and caching them in RAM; runtime parameter access (querying by ID); parameter modification request; updating the RAM cache and calculating the new CRC; differential writing to EEPROM (optional dual backup). Using EEPROM parameters and caching them in RAM: During the initialization phase of each application, EEPROM data is sequentially delivered to the application's runtime parameters (i.e., RAM data) according to the application ID, allowing the application to run normally. During the initialization phase of each application, default parameters are loaded and written to EEPROM. Parameter modification request: Modification is performed based on the application's runtime status. For example, if a function switch is disabled by default, but "enabled" is written via communication with the host computer during operation, a parameter modification request will be generated. After modification, the verification is updated and then stored in EEPROM. The function will be enabled by default upon the next restart. Update RAM cache and calculate new CRC: This is modified based on the application's operational status. For example, a certain function switch may be disabled by default. During operation, "enabled" is written via communication with the host computer, triggering a parameter modification request. After modification, the checksum is updated and stored in EEPROM. Upon the next restart, the function will be enabled by default. Specifically: Modification request -> Host computer sends data -> System receives data and assigns it to RAM -> Update CRC -> Updated data and checksum are stored in EEPROM. Differential writing to EEPROM: Differential is a differential algorithm called by the system, capable of efficiently handling data range updates and queries.

[0037] In the embodiments of this application, 1. Multiple sets of parameter structures are defined in an independent project module, each corresponding to a different application ID or running mode; the parameters of each application are different, and the respective structures are defined according to the parameter requirements of different applications. Here, the parameter structures between multiple sets are different.

[0038] 2. All structure arrays are pre-stored in a specified area of ​​EEPROM or Flash (such as a specific address range or logical block); 3. After power-on, the system automatically identifies the current application identifier ID, loads the corresponding structure data from Flash, and assigns it to runtime variables; 4. If storage is invalid or recognition fails, the system can revert to default values ​​or enter the exception handling process. The determination of invalid storage is as follows: Before storage, multiple checks are performed: At the chip level, it checks whether the chip register status is in a write state or whether the registers after writing are correct; if any abnormality is found, the storage is deemed invalid. At the application level, permission checks are performed before storage; if there is no permission to write, the storage is invalid. The determination of recognition failure is as follows: Recognition failure indicates a data verification error or an application verification error. The exception handling process is as follows: The system is reset and initialized again. If multiple exceptions are detected, the system will remain in an abnormal state, and all application functions will not function properly.

[0039] In addition, it can be used in conjunction with CRC checksums, dual backup areas, and automatic recovery mechanisms to improve system reliability and maintainability. These mechanisms are complementary to the points mentioned above. EEPROM storage and data rollback can be used in conjunction with CRC checksums and dual backups, while anomalies can be used in conjunction with automatic recovery mechanisms (i.e., reset).

[0040] In the embodiments of this application, see Figure 4 The process includes the following steps: system power-on; system initialization; determining whether application 1 is mounted; if application 1 is mounted, reading its default parameters from EEPROM / Flash; if application 1 is not mounted, determining whether application 2 is mounted; if application 2 is mounted, reading its default parameters from EEPROM / Flash; if application 2 is not mounted, determining whether subsequent applications are mounted; until application N-1 is not mounted, determining whether application N is mounted; if application N is mounted, reading its default parameters from EEPROM / Flash; if application N is not mounted, returning to system initialization. The default parameters are the application parameters.

[0041] In the embodiments of this application, compared with the prior art, the present invention has the following significant advantages in terms of centralization and structuring: (1) All default parameters are defined in a unified configuration module, such as the app_cfg.c file, and are organized using a unified structure; (2) The unified structure data is clearly laid out in EEPROM or Flash; (3) Each functional module only needs to read the data of the corresponding segment through a fixed offset address.

[0042] In this application embodiment, to ensure high maintainability of parameter configuration and module independence in the software design of the present invention, the following key design strategies are adopted: (1) Centralized parameter management structure: All default parameters are uniformly defined in the configuration module, realizing centralized configuration, no longer scattered in various functional modules, thus improving the efficiency of unified management and maintenance.

[0043] (2) Nested Structures and Module Boundary Division: By defining nested structures, parameters of modules such as communication, metering, control, and display are aggregated together, and the field order and alignment are strictly controlled within the internal structures to facilitate direct mapping of memory blocks and improve access efficiency. The specific definition of nested structures is as follows: First, a large structure .para is defined, and then parameter structures such as .comm_para, .emu_para, .ctrl_para, and .display_para are defined within this structure. Different parameter structures can also define their own required data structures, thereby achieving nesting.

[0044] (3) Address offset mapping and mapping table driving: During system boot, the parameter offset table is used to load the corresponding parameters according to the module definition, avoiding hard-coded addresses and improving flexibility and platform adaptability.

[0045] (4) Configuration Verification and Recovery Mechanism: Each configuration group includes a CRC checksum field. The system performs integrity verification before loading; if it fails, it rolls back to the factory default area or redundant backup area. This ensures system robustness. The integrity verification is as follows: The last member variable in the structure of each application group is used to indicate the CRC checksum. When the system loads, this value is compared to verify whether it is complete and consistent. If it fails, the parameter data is rolled back to the factory default area or redundant backup area.

[0046] (5) Runtime visibility and debugging interface: During operation, the loaded configuration content is output via serial port / debugging port, facilitating on-site debugging and version verification; specific debugging commands are supported to query the source and integrity status of the current configuration. Querying the source and integrity status of the current configuration specifically includes: each parameter has its own corresponding Obis communication command, which can be read through serial port tools to parse the source and integrity of the data.

[0047] In this application embodiment, (1) the pre-configuration mechanism of the default parameter array of the structure: supports multiple application IDs to map multiple sets of default parameters; (2) Layout of the structure in EEPROM / Flash: including ID index, data body, CRC check, etc.; (3) Separation mechanism for default parameters and runtime parameters: The parameter loading logic is driven by configuration data; the separation mechanism for default parameters and runtime parameters specifically includes: default parameters refer to data structures stored in EEPROM or FLASH, while runtime parameters refer to RAM data currently running in various applications. By abstracting the default parameter structure, runtime parameter variables in various applications can be defined, thus achieving separation between the two. The parameter loading logic driven by configuration data specifically includes: during parameter loading, only the structure variables of the default configuration parameters are scanned to complete the loading; (4) Automatic power-on matching mechanism: Automatically select the correct configuration item through device ID / mode ID; The automatic selection of the correct configuration item through device ID / mode ID specifically includes: different applications will assign different IDs to the corresponding configuration item parameters. When powered on, the IDs are scanned in sequence. If the ID belongs to the application, the correct configuration parameter is selected for the application. (5) Configure fault tolerance mechanism: Supports CRC check, abnormal parameter repair or restoration to factory default; Abnormal parameter repair specifically includes: if the check is found to be incorrect, the default value already stored in EEPROM is read out and assigned to the initial variable. The recovery process is consistent with the logic of rolling back the default value. Restoring to factory default specifically includes: if the check is found to be incorrect, the default value already stored in EEPROM is read out and assigned to the initial variable. The factory default data is the data that has been repaired after the error.

[0048] The beneficial effects and advantages of the present invention or technology as described in the embodiments of this application are as follows: 1. Improved reliability: Ensures data integrity by using CRC checksum and dual backup storage to prevent parameter corruption due to power outages or interference; can be designed for self-recovery from failure, automatically reverting to default parameters when checksum fails, ensuring the system is always up-to-date.

[0049] 2. Optimized maintenance efficiency: Centralized and structured management of data, with all application parameters indexed uniformly by app_id, avoiding scattered definitions.

[0050] 3. Efficient resource utilization: The system storage has been optimized, and the use of structure array storage saves EEPROM space; memory is controllable, and an on-demand loading mechanism has been introduced to reduce RAM usage.

[0051] 4. Flexibility for expansion: Dynamically expand applications; adding new application parameters only requires expanding the default parameter table, without modifying the storage logic.

[0052] The following will be combined with the appendix Figure 2 This application provides a detailed description of a parameter management device for an electricity meter according to an embodiment. It should be noted that the appendix... Figure 2 The device shown is a parameter management device for an electricity meter, used to perform the functions described in this application. Figure 1 The methods shown in the embodiments are for illustrative purposes only, illustrating the parts relevant to the embodiments of this application. For specific technical details not disclosed, please refer to this application. Figure 1 The example shown.

[0053] Please see Figure 2 , Figure 2 This is a schematic diagram of the structure of a parameter management device for an electricity meter provided in an embodiment of this application. Figure 2 As shown, the system includes a configuration module 201, a first storage module 202, and a reading module 203; The configuration module 201 is used to define multiple unified structures corresponding to multiple applications, and the unified structures are used to encapsulate application parameters. The first storage module 202 is used to store multiple unified structures respectively; The reading module 203 is used to read the corresponding unified structure during power-on initialization.

[0054] In this embodiment, the configuration module 201 defines multiple unified structures, each corresponding to a different application or operating mode. Each application has different parameters, and the unified structure is defined according to the parameter requirements of each application. The parameters of the multiple unified structures are different. Multiple unified structures are defined in the configuration module, each corresponding to a different application ID or operating mode; all unified structures are pre-stored in a designated area of ​​the first storage module; after power-on, the reading module automatically identifies the current application identifier ID, loads the corresponding structure data from Flash, and assigns it to runtime variables. If storage is invalid or identification fails, the default value can be returned or an exception handling process can be entered.

[0055] In one possible implementation, the application parameters include an identifier ID element, a CRC check element, and multiple functional parameter elements; the first storage module is an EEPROM or Flash.

[0056] In this embodiment, the first storage module 202 can be an EEPROM or a Flash, and all unified structures can be stored in a designated area of ​​the EEPROM or Flash (such as a specific address range or logical block). In one possible implementation, the first storage module 202 is used to alternately write multiple unified structures into two sectors to perform dual backup storage of the multiple unified structures. The reading module 203 is used to read the data corresponding to the preset unified structure in another sector if there is an error in the data of the preset unified structure in one sector.

[0057] In this embodiment, dual-backup storage is used: two sectors are written alternately to prevent data corruption due to write interruptions. Storage is based on the importance of the data; dual backups are typically stored in two sectors of the EEPROM. If the data in one sector is corrupted, the other sector is read. A unified structure is written alternately to both sectors, ensuring that the contents of the unified structure are written.

[0058] In one possible implementation, the reading module 203 includes a first loading unit, a first identification unit, a first verification and judgment unit, and a first assignment unit; The first loading unit is used to load multiple unified structures; The first identification unit is used to obtain the current identifier ID element corresponding to the current application, and to obtain the target unified structure from multiple unified structures based on the current identifier ID element; The first verification and judgment unit is used to perform CRC verification and judgment on the target unified structure; The first assignment unit is used to load the data of the target unified structure if the CRC check is correct, and assign the data to the variable corresponding to the current application.

[0059] In this embodiment, the first verification and judgment unit specifically includes: performing a CRC check before reading during a read operation; updating the checksum after writing data during a write operation; and judging the data checksum during device power-on initialization. If the checksum fails, it automatically reverts to the default value as follows: if a checksum error is detected during power-on, the default value corresponding to the unified structure already stored in EEPROM / Flash is read and assigned to the initial variable.

[0060] In one possible implementation, the first assignment unit includes: if the CRC check is correct, obtaining the offset address corresponding to the target unified structure, and loading the data of the target unified structure based on the offset address.

[0061] In this embodiment, the first assignment unit only needs to read the data of the corresponding segment through a fixed offset address. The data of the corresponding segment refers to the data at the corresponding position in the unified structure. All data is allocated to different addresses, and the data on each segment corresponds to the structure data of its respective application. In the unified structure, each parameter corresponds to a fixed offset address. The parameter can be read through this fixed offset address, and the structure parameter and the storage address have the same alignment length.

[0062] Those skilled in the art will clearly understand that the technical solutions of the embodiments of this application can be implemented by means of software and / or hardware. In this specification, "unit", "module" and "part" refer to software and / or hardware that can independently complete or cooperate with other components to complete a specific function, wherein the hardware may be, for example, a field-programmable gate array (FPGA), an integrated circuit (IC), etc.

[0063] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0064] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0065] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0066] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0067] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0068] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0069] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0070] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of embodiments of this disclosure upon considering the specification and practicing the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described herein. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A parameter management method for an electricity meter, characterized in that, Includes the following steps: S1: Define multiple unified structures corresponding to multiple applications, and the unified structures are used to encapsulate application parameters; S2: Stores multiple unified structures separately; S3: Read the corresponding unified structure during power-on initialization.

2. The parameter management method for an electricity meter as described in claim 1, characterized in that, The application parameters include an ID element, a CRC check element, and multiple functional parameter elements.

3. A parameter management method for an electricity meter as described in claim 1 or 2, characterized in that, Step S2 specifically includes: alternately writing multiple unified structures into two sectors to perform dual backup storage of multiple unified structures; in step S3, if the data of the preset unified structure in one sector is incorrect, the data corresponding to the preset unified structure is read in the other sector.

4. The parameter management method for an electricity meter as described in claim 2, characterized in that, Step S3 specifically includes: S31: Load multiple unified structures; S32: Obtain the current identifier ID element corresponding to the current application, and obtain the target unified structure from multiple unified structures based on the current identifier ID element; S33: Perform CRC check on the target unified structure; S34: If the CRC check is correct, load the data of the target unified structure and assign the data to the variable corresponding to the current application.

5. The parameter management method for an electricity meter as described in claim 4, characterized in that, The specific steps in step S34 for loading the data of the target unified structure include: if the CRC check is correct, obtaining the offset address corresponding to the target unified structure, and loading the data of the target unified structure based on the offset address.

6. A parameter management device for an electricity meter, characterized in that: It includes a configuration module, a first storage module, and a read module; The configuration module is used to define multiple unified structures corresponding to multiple applications, and the unified structures are used to encapsulate application parameters. The first storage module is used to store multiple unified structures respectively; The reading module is used to read the corresponding unified structure during power-on initialization.

7. The parameter management method for an electricity meter as described in claim 6, characterized in that: The application parameters include an ID element, a CRC check element, and multiple functional parameter elements; the first storage module is an EEPROM or Flash.

8. A parameter management method for an electricity meter as described in claim 6 or 7, characterized in that, The first storage module is used to alternately write multiple unified structures into two sectors to perform dual backup storage of multiple unified structures; The reading module is used to read the data corresponding to the preset unified structure in another sector if there is an error in the data of the preset unified structure in one sector.

9. The parameter management device for an electricity meter as described in claim 7, characterized in that: The reading module includes a first loading unit, a first identification unit, a first verification and judgment unit, and a first assignment unit; The first loading unit is used to load multiple unified structures; The first identification unit is used to obtain the current identifier ID element corresponding to the current application, and to obtain the target unified structure from multiple unified structures based on the current identifier ID element; The first verification and judgment unit is used to perform CRC verification and judgment on the target unified structure; The first assignment unit is used to load the data of the target unified structure if the CRC check is correct, and assign the data to the variable corresponding to the current application.

10. The parameter management device for an electricity meter as described in claim 9, characterized in that: The first assignment unit includes: if the CRC check is correct, obtaining the offset address corresponding to the target unified structure, and loading the data of the target unified structure based on the offset address.

Images