Event management method, device and equipment for electric energy surface facing object and medium

Abstract

The invention relates to the technical field of intelligent electric energy meters, in particular to an event management method, device and equipment for an electric energy surface facing object and a medium. Events of an intelligent electric energy meter are abstracted into independent event objects, and overall packaging is carried out in an object mode; the event object metadata comprises four core components including an event attribute structural body, an object attribute table, an object method table and an event object base structure, and declarative definition and automatic management of events are achieved through a series of designed structural bodies, virtual method tables and configuration tables. The invention relates to an intelligent electric energy meter event processing technology which can reduce the coupling degree of event processing logic and business codes, improve the hardware / protocol adaptation flexibility, optimize the memory resource management efficiency and reduce the event expansion cost so as to support the sustainable development of an intelligent power grid.

Description

Technical Field

[0001] This invention relates to the field of smart energy meter technology, and specifically to an event management method, device, equipment, and medium for energy meters. Background Technology

[0002] With the advancement of the energy internet construction, the demand for lean operation and maintenance, rapid fault response, and electricity consumption behavior analysis capabilities of the smart grid, as the core carrier of energy transmission and management, is increasing. Smart meters, as key terminal devices connecting the smart grid to the user side, have evolved from traditional single-function electricity metering instruments into "terminal neural nodes" integrating electricity metering, electricity consumption information collection, and grid status perception. They need to capture various events (such as voltage sags, power overloads, abnormal electricity consumption, three-phase imbalances, etc.) in real time during grid operation and user electricity consumption, and reliably record and promptly report event information to the grid electricity consumption information collection system.

[0003] Such event information is core data support for advanced applications in the power grid: for example, voltage sag event records can trace power supply quality issues, providing a basis for fault location and repair; abnormal electricity consumption event analysis can identify abnormal behaviors such as electricity theft and equipment failure, ensuring power grid safety; monitoring related events based on load characteristics (such as peak-valley load surges) can assist the power grid in formulating demand-side response strategies and optimizing power resource allocation; simultaneously, event data can also provide data references for electricity market settlement and power grid planning and upgrades. Therefore, the "reliable recording" and "timely reporting" of smart meter events directly determine the accuracy, effectiveness, and real-time performance of advanced smart grid applications.

[0004] Currently, the event processing implementation of traditional smart meters is limited by early technical architecture and design concepts, resulting in many drawbacks that can no longer meet the needs of continuous upgrades in smart grids. Specifically, these drawbacks are reflected in the following aspects: The high coupling issue is prominent, resulting in poor system flexibility. Traditional electricity meters exhibit deep coupling between their event processing logic and specific business code related to metering operations, data storage, and communication reporting. For example, the logic for determining voltage exceedance events is directly embedded in the current / voltage sampling code of the electricity metering module; the logic for allocating the storage address for event records is intertwined with the initialization code of the Flash memory; and the frame structure assembly logic for event reporting is bound to the parsing code of communication protocols such as DL / T 645. This coupling leads to a rigid system architecture: when a new event type needs to be added or the threshold for existing events needs to be modified, simultaneous modifications are required in multiple parts of the code within the metering, storage, and communication modules. This not only increases development difficulty but also makes it easier to introduce vulnerabilities due to linked code modifications, severely impacting the stability of the core functions of the electricity meter.

[0005] Insufficient scalability and difficulty in adapting to technological evolution mean that the hardware platform and communication protocols of smart grids are constantly being upgraded: At the hardware level, electricity meters are upgrading from low-end platforms based on 8-bit microcontrollers to high-performance platforms based on 32-bit ARM cores to support concurrent processing of more event types; at the communication level, they are evolving from traditional narrowband Internet of Things (NB-IoT) communication to 5G edge computing communication to achieve low-latency reporting of event data, while communication protocol specifications are also constantly being updated. However, the design of traditional event management modules is strongly tied to specific hardware platforms and communication protocols.

[0006] Resource management is inefficient, and the utilization rate of non-volatile memory (RAM) is low. Smart meters use limited capacity (typically 4KB-64KB) of non-volatile memory (RAM, such as EEPROM and Flash) for storing event records, making it a scarce hardware resource. Traditional event recording uses a "fixed array + static allocation" management method: a fixed-size storage area is pre-allocated for each preset event type, and the storage address is fixed. This method has significant drawbacks: firstly, when a certain type of event occurs infrequently, the pre-allocated storage area remains idle for a long time, resulting in wasted memory resources; secondly, when a large number of similar events suddenly occur, the pre-allocated area is quickly exhausted, and subsequent events cannot be stored, leading to incomplete event records.

[0007] The expansion costs are high and the R&D efficiency is low. When adding a new event type, a full-process module development and testing process is required for that event: First, an event status detection module needs to be developed, which collects real-time data such as current, voltage, and power from the electricity meter and designs a dedicated event judgment algorithm; second, an event recording and storage module needs to be developed, which designs the storage format for the event and adjusts the static allocation strategy of the memory to reserve storage space; finally, an event protocol reporting module needs to be developed, which adds a reporting field for the event to the frame structure of the existing communication protocol to achieve communication adaptation with the electricity information collection system. The above development process involves multiple independent modules, with an average development cycle of 2-4 weeks; at the same time, in order to ensure the metering accuracy, storage stability, and communication reliability of the electricity meter, multi-dimensional testing is required. Summary of the Invention

[0008] To overcome the shortcomings of existing technologies, this application provides a smart energy meter event management method, apparatus, device, and medium for object-oriented events, aiming to reduce the coupling between event processing logic and business code, improve hardware / protocol adaptation flexibility, optimize memory resource management efficiency, and reduce event expansion costs, thereby supporting the continuous development of smart grids.

[0009] The technical means adopted by this invention to solve its technical problem is: an event management method for an electrical energy surface towards an object, the improvement of which is that the method includes: Step S1: After the system is powered on, the predefined event object metadata is loaded and parsed. The configuration data of the predefined event is read from the memory. If the data is invalid, the preset default value is used for initialization, so that the event object enters the ready state. The event object metadata includes an event attribute structure, an object attribute table, an object method table, and an event object base structure. Step S2: When an event triggering condition is detected, a unified event recording interface is called. The general recording function is located by querying the virtual method table associated with the event attribute structure. Based on the predefined record storage information, the event-related information is stored in the memory in a circular queue. Step S3: In response to an external query command, the object identifier in the command is mapped to a specific event object and its object attribute table. The event record is retrieved from the memory and assembled into a protocol message for reporting using the read method specified in the object attribute table. Step S4: In response to external configuration instructions, the parameters are validated using the write method specified in the object property table, the memory running value is updated, and the data is persisted to the storage. Step S5: In response to an external reset command, call the reset method defined in the object method table, clear the event record queue in memory, and reset the relevant status flags and counters.

[0010] The event attribute structure described in the above technical solution encapsulates all attributes and behaviors of an event type, and its fields include at least: The control block manages the enabling and state of events and contains pointers to the addresses of critical state data in RAM and NVM. The status identifier block points to a dynamically updated variable used to record the current status of the event in real time, such as whether the event is in the occurrence state and the cumulative occurrence time; The configuration parameter block is used to define the behavior parameters for event determination, and contains pointers to runtime parameters, NVM storage information, and default configuration parameters; Record storage information blocks are used to manage the storage scheme of event records in NVM, including the starting address, single record size, and storage depth; The associated data table defines other related data that need to be frozen and saved synchronously when an event occurs; The event determination function set contains a set of predefined function pointers for implementing pluggable logic for determining the start and end conditions of events. Event identifier metadata is used for protocol reporting, status query and event identification, and supports automatic triggering of status word setting and active reporting when an event occurs.

[0011] The object attribute table described in the above technical solution establishes a standardized access channel for various data resources of the event object, and each entry contains: Attribute identifiers are used to uniquely identify a function point in a communication protocol; The first virtual method table pointer points to a set of generic functions for operating on the attributes of this class; Event type, used to distinguish the processing logic and protocol behavior of different types of events; The first associated parameter points to the event attribute structure where the specific data of this attribute is located.

[0012] The object method table described in the above technical solution encapsulates various dynamic operations that the event object can perform, and each entry contains: The method identifier is used to uniquely identify the method to be invoked in the communication protocol; The second virtual method table pointer points to a general function that implements the specific logic of the method; The second associated parameter points to the target event attribute structure operated on by this method.

[0013] The event object base structure described in the above technical solution serves as a metadata container for event objects, used to integrate attribute tables and method tables, and includes: A pointer to the property list, which points to the metadata table of all properties of this event object; A method list pointer that points to the list of all callable methods of the event object; The list size field is used for safe traversal of the list; Attributes to be loaded flag: Used to identify attributes that need to be preloaded from memory during system initialization, optimizing the startup process.

[0014] The process of initializing using preset default values ​​in step S1 of the above technical solution includes: First, check the validity of the data in main memory and the system flag. If it is valid, use the data directly from the memory. If the main memory data is invalid, try to read the data from the main memory address. Retry a maximum of 3 times, and verify the integrity through CRC check after each read. If reading the main memory address fails, attempt to read the data from the backup memory area, retrying 3 times and verifying each time. If both the main and backup reads fail, load the default parameters or cleared values ​​into the main memory according to the default value table pointer.

[0015] The parameter validity verification in step S4 of the above technical solution includes parameter range checking to ensure that the configuration parameters meet the requirements of the event determination logic.

[0016] The technical means adopted by this invention to solve its technical problem is: an event management device for an electrical energy surface towards an object, characterized in that the device comprises: The event object encapsulation module is used to load and parse the predefined event object metadata after the system is powered on, read the configuration data of the predefined event from the memory, and initialize it with the preset default value if the data is invalid, so that the event object enters the ready state. The event handling module is used to call a unified event recording interface when an event trigger condition is detected. By querying the virtual method table associated with the event attribute structure, the module locates the general recording function and stores the event-related information into the memory in a circular queue according to the predefined recording storage information. The protocol interface module is used to respond to external query commands, map the object identifier in the command to the specific event object and its object attribute table, retrieve the event record from the memory through the read method specified in the object attribute table, and assemble it into a protocol message for reporting. The event configuration module is used to respond to external configuration commands, and after validating the parameters through the write method specified in the object property table, update the memory running value and persist it to the storage. The event reset module is used to respond to external reset commands by calling the reset method defined in the object method table, clearing the event record queue in memory, and resetting the relevant status flags and counters.

[0017] The technical means adopted by this invention to solve its technical problem is: a device, comprising: at least one processor and at least one memory, wherein, The memory stores program instructions or code; The program instructions or code are loaded and executed by the processor, enabling the electronic device to implement the power surface-to-object event management method as described above.

[0018] The technical means adopted by the present invention to solve its technical problem is: a medium on which program instructions or code are stored, the program instructions or code being loaded and executed by a processor to realize the event management method of the electrical energy surface to the object as described above.

[0019] The beneficial effects of this invention are: ① Improved modularity and maintainability: Event types exist as self-contained modules, with data, configuration, and behavior highly cohesive, supporting independent development, debugging, and testing, effectively reducing software complexity and maintenance costs; ② Scalability optimization: Adding a new event type only requires defining an event attribute structure instance and populating the attribute table and method table. Common operations such as adding, deleting, modifying, querying, and reporting are automatically handled by the existing virtual method table mechanism, which fully complies with the "open / closed principle". ③ Enhanced protocol and standard compatibility: The architecture inherently supports the mapping between event objects and standard communication protocol data object models. By modifying the configuration data, it can be adapted to different protocols or regional specifications, thereby improving the product's market adaptability. ④ Improved resource management efficiency: Avoiding the low utilization problem of traditional static array storage, the system can dynamically and accurately define the size and storage depth of a single record in the record storage information block according to the related object attribute list configured by the user on site; combined with the space reclamation mechanism, it can achieve precise pre-allocation of storage space, support custom record length for different events, and the storage space utilization rate can approach 100%; ⑤ Reliability assurance: Critical configurations and records are persistently stored in memory and can be automatically restored from default values, effectively resisting unexpected power outages or data tampering; standardized event handling processes ensure the determinism and reliability of response behavior, reducing the risk of abnormal system states; ⑥ Improved Ease of Operation and Maintenance: Provides a complete and unified remote diagnostic and configuration interface. The main station can query event records, modify event judgment thresholds, and test event reporting functions, significantly improving on-site operation and maintenance efficiency. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating an event management method for an electrical energy surface to an object, as shown in an embodiment of the present invention. Figure 2 This is a schematic diagram illustrating the overall architecture of event object metadata in an embodiment of the present invention; Figure 3 This is a table showing the attributes and methods of 24 types of event objects in the 698 protocol as illustrated in an embodiment of the present invention; Figure 4 This is a flowchart illustrating initialization using preset default values, as shown in an embodiment of the present invention. Figure 5 This is a structural diagram of an event management device for an electrical energy surface to an object, as shown in an embodiment of the present invention; Figure 6 This is a structural block diagram of a device according to an embodiment of the present invention. Detailed Implementation

[0021] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0022] The following will clearly and completely describe the concept, specific structure, and technical effects of the present invention in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the scope of protection of the present invention. Furthermore, all connections / linkages involved in the patent do not simply refer to direct contact between components, but rather to the ability to form a better connection structure by adding or reducing connecting accessories according to specific implementation conditions. The various technical features in this invention can be combined interactively without contradicting each other.

[0023] like Figure 1 As shown, this invention provides an event management method for an object-oriented power meter, applied to a smart power meter, the method comprising: Step S1: After the system is powered on, the predefined event object metadata is loaded and parsed. The configuration data of the predefined event is read from the memory. If the data is invalid, the preset default value is used for initialization, so that the event object enters the ready state.

[0024] The event object metadata includes an event attribute structure, an object attribute table, an object method table, and an event object base structure.

[0025] This application abstracts each event of a smart energy meter into an independent "event object" and encapsulates them as an object. The event object metadata includes four core components: an event attribute structure (EvtObj_t), an object attribute table (EvtObjAttr_t), an object method table (EvtObjMeth_t), and an event object base structure (IcBase_t). Through a series of designed structures, virtual method tables, and configuration tables, the application achieves declarative definition and automated management of events.

[0026] The event attribute structure (EvtObj_t) completely encapsulates all attributes and behaviors for each event type, integrating scattered event management elements into a self-contained entity; the object attribute table (EvtObjAttr_t) establishes a unified and standardized access mechanism for the internal sub-attributes of the event object, achieving separation of interface and implementation; the object method table (EvtObjMeth_t) encapsulates various executable operations of the event object; and the event object base structure (IcBase_t) integrates the aforementioned metadata into a complete "event object" that can be uniformly identified and managed by the system.

[0027] By adopting a declarative design approach, new event types can be added simply by defining them without modifying the core framework, which greatly improves development efficiency. At the same time, the system's reliable operation under various abnormal conditions is ensured through fine-grained management of non-volatile memory and an automatic recovery mechanism.

[0028] The design ultimately achieves the goals of high cohesion, low coupling, easy expansion, and easy maintenance. It has significant advantages such as extremely high modularity and maintainability, excellent scalability, strong protocol and standard compatibility, efficient resource management capabilities, high reliability, and convenient operation and maintenance. It significantly reduces the development and maintenance costs of smart meter event management and improves the reliability and flexibility of the system.

[0029] In one possible implementation, the event attribute structure encapsulates all attributes and behaviors of an event type, and its fields include at least: The control block (.Ctrl) is used to manage the enabling and status of events. It contains a pointer (value) to the location of critical status data in main memory (RAM), the storage address (addr) and size (size) in the NVM memory. This ensures that the critical running state of an event is not lost after a power failure and can be recovered from the previous state, thereby guaranteeing the continuity, reliability and traceability of event management.

[0030] The status identifier block (.Status) points to a dynamically updated variable used to record the current status of the event in real time, such as whether the event is in the occurrence state and the cumulative occurrence time. It provides a direct memory access interface for real-time monitoring and quick judgment of event status, which significantly improves the efficiency of event status query and processing.

[0031] The configuration parameter block (.Config) is used to define the behavior parameters for event judgment (such as threshold, delay time). It not only contains pointers (value) to the running parameters in memory and storage information (addr, size) in the NVM, but also specifically contains a pointer to the default configuration parameters (dftv), ensuring that the default configuration parameters can be automatically restored when the configuration parameter data is corrupted or uninitialized.

[0032] The Record storage information block (.Record) is used to manage the storage scheme of event records in the NVM memory, including the starting address (sddr) of the event record storage area, the size of a single record (size), and the maximum number of storage records (depth, i.e., the circular queue depth), which realizes fine-grained and pre-allocated management of storage resources.

[0033] The associated data table (.Road) defines other related data (such as voltage, current, power, etc. at that time) that need to be frozen and saved synchronously when an event occurs. This field stores the address, size, quantity, and default value of the associated object table in memory, enabling the management of storage resources and ensuring automatic recovery to default parameters in the event of data corruption.

[0034] Traditional methods often use fixed-size static arrays to store records. To avoid overflow, the attribute lists (Roads) of associated objects differ for different events, typically reserving a large amount of space, resulting in low utilization. This invention, within the Record storage information block, allows the system to dynamically and precisely define the size and depth of a single record based on the user-configured attribute list (Road). Combined with a space reclamation mechanism, this achieves precise pre-allocation of storage space. This method allows different events to define drastically different record lengths according to their actual needs, giving the system extremely high flexibility. In practical applications, the memory space utilization rate can approach 100%.

[0035] The event detection function set contains a group of predefined function pointers, including event start condition determination (EventCheckStart), event end condition determination (EventCheckEnd), checking whether the determination is disabled (IsEventCheckDisable), and obtaining delay parameters (GetEventDelayTime). These functions decouple event-specific determination logic from the general management framework through standardized interfaces, forming pluggable strategy units. This not only enables the configurability of event detection business but also serves as the core mechanism supporting the polymorphic operation of event objects.

[0036] Event identifier metadata includes the unique object identifier (.Oad) corresponding to the event, the corresponding bit in the meter status word (.Mrsw), the event type code (.type), etc., which are used for protocol reporting, status query and event identification, and support automatic triggering of status word setting and active reporting when the event occurs.

[0037] In one possible implementation, such as Figure 2 As shown, the object attribute table establishes standardized access channels for various attributes of the event object, and each entry contains: An attribute identifier (.attr) is used to uniquely identify a function point in a communication protocol; it is an abstraction of a function command, such as... Figure 3 As shown, for example, in the 24 event categories, "2" represents "reading or setting the associated object table", "3" represents "reading the current event record count", and "5" represents "reading or modifying configuration parameters".

[0038] The first virtual method table pointer (.vmt) points to a set of generic function sets (VMT) for operating on this type of attribute (e.g., EvtRoadTblVmt). This generic function set (VMT) contains standard method function pointers (such as Read, Write, Draw) for this type of attribute, defining "what to do".

[0039] Event type (.type) identifies the type of the event, such as 24 types of events or 7 types of events, and is used to distinguish the processing logic and protocol behavior of different types of events.

[0040] The first associated parameter points to the event attribute structure where the specific data of this attribute resides—that is, its parent event attribute structure (such as &objOverCurrAttr). This pointer provides the addressing basis for the specific data in the general methods of the aforementioned general function set VMT (defined in the Config, Record, and other fields of ObjAttr_t), indicating "who to do it to".

[0041] The object attribute table is the core scheduling hub and metadata mapping table that implements all externally accessible functions of the event object. It abstracts various data resources of the event (such as configuration parameters, event records, and reporting) into attributes with a unified interface, and perfectly supports core business functions such as remote parameter configuration, querying and copying event records, and event reporting through a standardized access process.

[0042] In one possible implementation, the object method table encapsulates various dynamic operations that the event object can perform, with each entry containing: A method identifier (.attr) is used to uniquely identify the method to be invoked in a communication protocol; for example... Figure 3 As shown, for example, in category 24, event 1 represents "reset" and event 4 represents "add associated object".

[0043] The second virtual method table pointer points to a generic function (such as EventResetMethVmt, EventAddRoadMethVmt) that implements the specific logic of the method. This function is generic, and its behavior is adapted through associated parameters.

[0044] The second associated parameter points to the target event attribute structure operated on by this method. This pointer also provides the addressing basis for the specific data of the general methods in the virtual method table mentioned above (defined in the Config, Record, and other fields of ObjAttr_t), thereby executing the correct operation for the specific event.

[0045] By using the object method table, proactive operations that may occur during event management (such as resetting or adding associated attribute tables) are decoupled from specific business logic. The "behavior" and "data" of the event are separated and centrally defined as standardized callable interfaces, which is the key to realizing intelligent management and remote interaction of event objects.

[0046] In one possible implementation, the event object base structure serves as a metadata container for the event object, used to integrate the attribute table and method table, and includes: The attribute list pointer (.attr_list) points to the metadata table of all attributes of the event object (e.g., objOverCurrAttrTbl[]); A method list pointer that points to a list of all callable methods of the event object (e.g., objOverCurrMethTbl[]). The list size fields (.attr_list_size, .meth_list_size) are used for safe traversal of the list; Attributes to be loaded (.attr_load): Used to identify attributes that need to be preloaded from non-volatile memory (NVM) during system initialization, optimizing the startup process.

[0047] The base structure of the event object acts as a metadata container or descriptor for the event object, serving as the final bridge between the specific implementation of the event object and the upper-level general management framework. The system does not need to concern itself with how the complex attributes and methods inside the event are defined; it can obtain all the entry points for operating the entire event object simply by accessing this base structure.

[0048] In one possible implementation, such as Figure 4 As shown, the process of initializing using preset default values ​​in step S1 includes: First, check the validity of the data in main RAM and the system flag. If it is valid, use the data in main RAM directly. If the data in main RAM is invalid, try to read the data from the non-volatile memory (NVM) main memory address. Retry a maximum of 3 times, and verify the integrity through CRC check after each read. If the main memory address read fails, attempt to read the data from the non-volatile memory (NVM) backup storage area, and repeat the process 3 times with verification. If both the main and backup reads fail, load the default parameters or cleared values ​​into the main memory RAM according to the default value table pointer.

[0049] The configuration parameter block (.Config) function first checks if the data in RAM is valid and if the system flags are normal. If the conditions are met, the data in RAM is used directly, skipping NVM reads and improving efficiency. If the RAM data is invalid, it attempts to read data from the NVM's main memory address (addr), retrying up to 3 times, verifying data integrity after each read using a check function (such as CRC check). If reading from the main memory fails, the function continues to attempt to read from the backup memory area, also performing 3 attempts and checks. This dual-memory design further enhances data reliability. If all read attempts from the main memory and backup fail, a decision is made based on the passed default value table pointer (dftv). If the pointer is valid, the default value is copied to RAM; if invalid, the configuration memory area is zeroed, ensuring the system has a known and safe initial state.

[0050] Step S2: When an event trigger condition is detected, a unified event recording interface is called. The general recording function is located by querying the virtual method table associated with the event attribute structure. Based on the predefined record storage information, the event-related information is stored in the memory in a circular queue.

[0051] Specifically, when an event trigger condition is detected, the event management method provided in this application does not process it directly, but instead calls a unified event recording interface. This interface locates a general recording function by querying the virtual method table (VMT) associated with the event attribute structure. Based on the information defined in the Record block of ObjAttr_t (including the starting address addr in memory, the size of a single record size, and the storage depth depth), the recording function automatically and reliably stores the timestamp of the event occurrence, the instantaneous state, and related data (other object data associated through the Road block) into a designated area of ​​memory predefined by the Record block, using a circular queue or other methods.

[0052] Step S3: In response to an external query command, the event record is retrieved from memory and assembled into a protocol message for reporting, based on the object identifier in the command and mapped to the specific event object and its object attribute table. The event record is then retrieved from memory and assembled into a protocol message for reporting using the read method specified in the object attribute table.

[0053] Specifically, taking the instruction to read event records issued by the master station as an example, the protocol parsing layer maps the object identifier (Oad) in the instruction to the specific event object and its attribute table. Then, through the read method (such as EvtRecVmt) within the general function set VMT specified in the attribute table, it retrieves the requested event record from the circular record queue of the memory and assembles it into a message format conforming to the communication protocol for reporting. The entire process is transparent to the application program, achieving a unified access interface.

[0054] Step S4: In response to external configuration instructions, the parameters are validated using the write method specified in the object property table, and then the memory running value is updated and persistently stored in the storage.

[0055] Specifically, taking a write configuration command issued by the master station (such as modifying event delay judgment parameters) as an example, the system receives the command through the write method in the general function set VMT, and first performs validity verification on the parameters (such as range check). After the verification passes, it not only updates the running value pointed to by the configuration parameter block pointer in main memory, but also writes the new parameter to the memory address specified by its starting address in the configuration parameter block, realizing persistent storage of configuration parameters and power failure protection, ensuring that the configuration takes effect immediately and is valid for a long time.

[0056] In one possible implementation, the parameter validity check includes a parameter range check to ensure that the configuration parameters meet the requirements of the event determination logic.

[0057] Step S5: In response to an external reset command, call the reset method defined in the object method table, clear the event record queue in memory, and reset the relevant status flags and counters.

[0058] Specifically, the master station can call the Reset method (such as EventResetMethVmt) defined in the object's method table. This method clears the event's record queue in memory, resets the head and tail pointers of the queue, and resets the relevant status flags and counters (such as the current record count) in the object's attribute table to their initial states, achieving efficient event record management. This approach avoids the lengthy erasure process of physical blocks in memory and the resulting storage overhead, thus significantly improving system response speed and the flexibility of event management.

[0059] Through the above workflow, this invention automates and modularizes each stage of event handling, significantly reducing the development and maintenance costs of smart meter event management and improving the system's reliability and flexibility.

[0060] The following are embodiments of the apparatus described in this application, which can be used to execute the event management method for an object-oriented power supply according to this application. For details not disclosed in the apparatus embodiments of this application, please refer to the method embodiments of the event management method for an object-oriented power supply according to this application.

[0061] Please see Figure 5 This application provides an event management device 60 for an electrical energy surface object, the device 60 including: an event object encapsulation module 601, an event processing module 602, a protocol interface module 603, an event configuration module 604, and an event reset module 605.

[0062] The event object encapsulation module 601 is used to load and parse predefined event object metadata after the system is powered on, read the configuration data of the predefined event from the memory, and initialize the event object with a preset default value if the data is invalid, so that the event object enters the ready state. The event handling module 602 is used to call a unified event recording interface when an event triggering condition is detected. By querying the virtual method table associated with the event attribute structure, it locates the general recording function and stores the event-related information into the memory in a circular queue according to the predefined recording storage information. The protocol interface module 603 is used to respond to external query commands, map the object identifier in the command to the specific event object and its object attribute table, retrieve the event record from the memory through the read method specified in the object attribute table, and assemble it into a protocol message for reporting. Event configuration module 604 is used to respond to external configuration instructions, and after validating the parameters through the write method specified in the object property table, update the memory running value and persist it to the storage. The event reset module 605 is used to respond to an external reset command by calling the reset method defined in the object method table, clearing the event record queue in the memory, and resetting the relevant status flags and counters.

[0063] It should be noted that the above-described event management device for an object-oriented power supply surface is only illustrated by the division of the functional modules described above. In practical applications, the functions can be assigned to different functional modules as needed. That is, the internal structure of the event management device for an object-oriented power supply surface will be divided into different functional modules to complete all or part of the functions described above. These modules can be embedded in hardware or independent of the processor in a computer device, or stored in software in the memory of a computer device, so that the processor can call and execute the operations corresponding to each module.

[0064] Furthermore, the above embodiments of the power surface object-oriented event management device and the power surface object-oriented event management method belong to the same concept, and the specific way in which each module performs operations has been described in detail in the method embodiments, and will not be repeated here.

[0065] Please see Figure 6 This application provides an electronic device 4000.

[0066] exist Figure 6In this design, data interaction between the processor 4001 and the memory 4003 can be achieved through at least one communication bus 4002. This communication bus 4002 may include a path for transmitting data between the processor 4001 and the memory 4003. The communication bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus 4002 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0067] Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one unit, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of this application.

[0068] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc. The memory 4003 may be a ROM (Read Only Memory) or other type of static storage device capable of storing static information and instructions, RAM (Random Access Memory) or other type of dynamic storage device capable of storing information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program instructions or code in the form of instructions or data structures and accessible by the electronic device 400, but not limited thereto.

[0069] The memory 4003 stores program instructions or code, and the processor 4001 can read the program instructions or code stored in the memory 4003 through the communication bus 4002.

[0070] When the program instructions or code are executed by the processor 4001, they implement an event management method for an object-oriented power supply surface in the above embodiments.

[0071] Furthermore, this application embodiment provides a storage medium storing program instructions or code, which is loaded and executed by a processor to implement an event management method for an electrical energy surface facing an object as described above.

[0072] This application provides a computer program product, which includes program instructions or code. The program instructions or code are stored in a storage medium. The processor of the electronic device reads the program instructions or code from the storage medium, loads and executes the program instructions or code, so that the electronic device implements an event management method for an electrical energy surface facing an object as described above.

[0073] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. An event management method for an object-oriented power meter, applied to a smart power meter, characterized in that, The method includes: Step S1: After the system is powered on, the predefined event object metadata is loaded and parsed. The configuration data of the predefined event is read from the memory. If the data is invalid, the preset default value is used for initialization, so that the event object enters the ready state. The event object metadata includes an event attribute structure, an object attribute table, an object method table, and an event object base structure. Step S2: When an event triggering condition is detected, a unified event recording interface is called. The general recording function is located by querying the virtual method table associated with the event attribute structure. Based on the predefined record storage information, the event-related information is stored in the memory in a circular queue. Step S3: In response to an external query command, the object identifier in the command is mapped to a specific event object and its object attribute table. The event record is retrieved from the memory and assembled into a protocol message for reporting using the read method specified in the object attribute table. Step S4: In response to external configuration instructions, the parameters are validated using the write method specified in the object property table, the memory running value is updated, and the data is persisted to the storage. Step S5: In response to an external reset command, call the reset method defined in the object method table, clear the event record queue in memory, and reset the relevant status flags and counters.

2. The event management method for an object-oriented electrical energy surface according to claim 1, characterized in that, The event attribute structure encapsulates all attributes and behaviors of an event type, and its fields include at least: The control block manages the enabling and state of events and contains pointers to the addresses of critical state data in RAM and NVM. The status identifier block points to a dynamically updated variable used to record the current status of the event in real time, such as whether the event is in the occurrence state and the cumulative occurrence time; The configuration parameter block is used to define the behavior parameters for event determination, and contains pointers to runtime parameters, NVM storage information, and default configuration parameters; Record storage information blocks are used to manage the storage scheme of event records in NVM, including the starting address, single record size, and storage depth; The associated data table defines other related data that need to be frozen and saved synchronously when an event occurs; The event determination function set contains a set of predefined function pointers for implementing pluggable logic for determining the start and end conditions of events. Event identifier metadata is used for protocol reporting, status query and event identification, and supports automatic triggering of status word setting and active reporting when an event occurs.

3. The event management method for an object-oriented electrical energy surface according to claim 1, characterized in that, The object attribute table establishes standardized access channels for various data resources of the event object, and each entry contains: Attribute identifiers are used to uniquely identify a function point in a communication protocol; The first virtual method table pointer points to a set of generic functions for operating on the attributes of this class; Event type, used to distinguish the processing logic and protocol behavior of different types of events; The first associated parameter points to the event attribute structure where the specific data of this attribute is located.

4. The event management method for an object-oriented electrical energy surface according to claim 1, characterized in that, The object method table encapsulates various dynamic operations that the event object can perform, and each entry contains: The method identifier is used to uniquely identify the method to be invoked in the communication protocol; The second virtual method table pointer points to a general function that implements the specific logic of the method; The second associated parameter points to the target event attribute structure operated on by this method.

5. The event management method for an object-oriented electrical energy surface according to claim 1, characterized in that, The aforementioned event object base structure serves as a metadata container for event objects, used to integrate attribute tables and method tables, and includes: A pointer to the property list, which points to the metadata table of all properties of this event object; A method list pointer that points to the list of all callable methods of the event object; The list size field is used for safe traversal of the list; Attributes to be loaded flag: Used to identify attributes that need to be preloaded from memory during system initialization, optimizing the startup process.

6. The event management method for an object-oriented electrical energy surface according to claim 1, characterized in that, The process of initializing using preset default values ​​in step S1 includes: First, check the validity of the data in main memory and the system flag. If it is valid, use the data directly from the memory. If the main memory data is invalid, try to read the data from the main memory address. Retry a maximum of 3 times, and verify the integrity through CRC check after each read. If reading the main memory address fails, attempt to read the data from the backup memory area, retrying 3 times and verifying each time. If both the main and backup reads fail, load the default parameters or cleared values ​​into the main memory according to the default value table pointer.

7. The event management method for an object-oriented electrical energy surface according to claim 1, characterized in that, The parameter validity verification in step S4 includes parameter range checking to ensure that the configuration parameters meet the requirements of the event determination logic.

8. An event management device for an electrical energy surface facing an object, characterized in that, The device includes: The event object encapsulation module is used to load and parse the predefined event object metadata after the system is powered on, read the configuration data of the predefined event from the memory, and initialize it with the preset default value if the data is invalid, so that the event object enters the ready state. The event handling module is used to call a unified event recording interface when an event trigger condition is detected. By querying the virtual method table associated with the event attribute structure, the module locates the general recording function and stores the event-related information into the memory in a circular queue according to the predefined recording storage information. The protocol interface module is used to respond to external query commands, map the object identifier in the command to the specific event object and its object attribute table, retrieve the event record from the memory through the read method specified in the object attribute table, and assemble it into a protocol message for reporting. The event configuration module is used to respond to external configuration commands, and after validating the parameters through the write method specified in the object property table, update the memory running value and persist it to the storage. The event reset module is used to respond to external reset commands by calling the reset method defined in the object method table, clearing the event record queue in memory, and resetting the relevant status flags and counters.

9. A device, characterized in that, include: At least one processor, at least one memory, wherein, The memory stores program instructions or code; The program instructions or code are loaded and executed by the processor, causing the electronic device to implement the event management method for electrical energy surface-to-object as described in any one of claims 1 to 7.

10. A medium having program instructions or code stored thereon, characterized in that, The program instructions or code are loaded and executed by the processor to implement the event management method for electrical energy surface-to-object as described in any one of claims 1 to 7.

Images