A service function modularization loading method and system of a smart electric energy meter

Abstract

This invention discloses a method and system for modular loading of business functions in smart meters, relating to the field of smart meter technology. The method includes: constructing a function slice library; decomposing all business functions of the smart meter into multiple atomic-level function slices; storing each function slice in a unified code pool; receiving business function requirement descriptors and parsing them into several subtasks; matching corresponding function slices according to each subtask and dynamically generating an execution flow graph; the scheduler retrieving the corresponding function slices from the unified code pool on demand according to the execution flow graph and executing them in the execution buffer; and releasing the execution buffer after execution. This invention, through atomic-level function slices and a unified code pool, eliminates the need for pre-allocating fixed storage subspaces, enabling dynamic orchestration and on-demand loading of smart meter business functions, effectively improving storage space utilization and functional expansion flexibility.

Description

Technical Field

[0001] This application relates to the field of smart energy meter technology, and in particular to a method and system for modular loading of business functions of a smart energy meter. Background Technology

[0002] With the deepening of smart grid construction, smart meters have evolved from traditional single energy metering devices into comprehensive terminal devices integrating multiple business functions such as metering, communication, control, monitoring, and analysis. To meet the needs of flexible expansion of business functions and on-demand deployment in different application scenarios, modular design of smart meters has become the mainstream technology direction in the industry.

[0003] In existing technologies, modular solutions for smart meters mainly fall into two categories: hardware modularization and software modularization. Hardware modularization solutions (such as Chinese patent CN109270342B) support the insertion, removal, and identification of external functional modules by setting physical expansion module interfaces. This type of solution relies on physical hardware interfaces, and its expansion capability is limited by the number of interfaces and the internal space of the meter. Furthermore, functional changes require the replacement of hardware modules, resulting in high costs, poor flexibility, and difficulty in meeting the needs of rapid software function iteration.

[0004] Modular software solutions (such as Chinese patent CN110119281A) divide the electricity meter application into multiple software modules according to function, and divide the storage space into several fixed subspaces. Each module is stored in its corresponding subspace, and functional updates are achieved by replacing module files during upgrades. However, this type of solution has the following shortcomings: First, it requires pre-dividing fixed storage subspaces, and each module is statically bound to the storage location, resulting in low storage space utilization. Second, the functional modules are pre-compiled complete units, and functional changes must be made by replacing the entire module, resulting in coarse-grained upgrades and insufficient flexibility. Third, the upgrade process requires a complete "backup-erase-write-restore" process, making it difficult to guarantee business continuity. Fourth, each module occupies fixed storage resources exclusively, lacking a priority-based dynamic resource allocation mechanism, resulting in insufficient reliability of core business function execution under resource-constrained conditions. Summary of the Invention

[0005] To overcome the shortcomings of the prior art, this application provides a modular loading method and system for the business functions of a smart energy meter. By decomposing the business functions into atomic-level function slices and realizing dynamic orchestration and scheduling during runtime, the method improves storage space utilization, functional expansion flexibility, and business continuity.

[0006] To achieve the above objectives, this application proposes the following technical solution: Firstly, this application provides a method for modularly loading the business functions of a smart energy meter, including: Step S10: Construct a functional slice library, decompose all business functions of the smart energy meter into multiple atomic-level functional slices, each functional slice is the smallest executable unit of the business function, and each functional slice is stored in the unified code pool of the smart energy meter. Step S20: Receive the business function requirement descriptor, parse the requirement descriptor through the function orchestration engine, and decompose it into several sub-tasks; Step S30: Match the corresponding function slice in the function slice library according to each subtask, and the function orchestration engine dynamically generates an execution flow graph based on the matching result; In step S40, the scheduler retrieves the corresponding function slices from the unified code pool as needed and executes them in the execution buffer according to the execution flow graph. After the slices are executed, the execution buffer is released.

[0007] Furthermore, in step S10, the construction of the functional slice library includes the following detailed steps: Step S101: Perform functional semantic analysis on all business functions of the smart energy meter, identify the smallest indivisible business operation unit contained in each business function, and define each of the smallest business operation units as a functional slice. Step S102: Configure slice metadata for each functional slice. The slice metadata includes: slice identifier, execution logic code segment, input / output contract, dependency declaration, and resource tag. The resource tag indicates the minimum memory required for the functional slice to run, the minimum CPU time, and the priority value. The priority value is an integer between 0 and 9, with a higher value indicating a higher priority. Step S103: Store the execution logic code segments of all functional slices in the unified code pool in the form of source code level or intermediate code level, and store the slice metadata of each functional slice in the slice index table; the unified code pool does not pre-divide fixed storage subspaces, and each functional slice shares a unified storage space.

[0008] Furthermore, step S20 includes the following detailed steps: Step S201: Receive a structured business function requirement descriptor, wherein the requirement descriptor defines the input parameters, expected output, and constraints of the required business function; Step S202: The function orchestration engine performs lexical and syntactic analysis on the requirement descriptor and extracts the functional semantic elements therein. Step S203: The function orchestration engine decomposes the business function requirements into several sub-tasks with logical temporal relationships based on the function semantic elements, and records the dependencies between each sub-task.

[0009] Furthermore, step S30 includes the following detailed steps: Step S301: The slice matching engine queries the functional slice library for matching functional slices based on the functional semantics of each subtask. The matching criteria include the degree of matching between the functional semantics of the subtask and the input-output contract of the slice, as well as the compatibility between the dependency relationships between subtasks and the dependency relationship declarations of the slices. Each subtask matches one or more candidate functional slices. Step S302: When a subtask matches multiple candidate functional slices, the slice matching engine performs a comprehensive evaluation based on the resource tags of each candidate functional slice and the current resource status of the system, and selects the functional slice with the best resource consumption as the matching result. Step S303: The execution flow orchestrator constructs a directed acyclic graph as the execution flow graph based on the matching results of all subtasks, with each functional slice as a node and the data dependencies between functional slices as edges. Step S304: The execution flow orchestrator performs dependency conflict detection and circular dependency detection on the directed acyclic graph to ensure that the execution flow graph is acyclic and can be executed in parallel.

[0010] Furthermore, step S40 includes the following detailed steps: Step S401: The scheduler determines the execution order of each functional slice according to the topological order of the execution flow graph; Step S402: Before executing the current functional slice, the scheduler queries the resource tag of the functional slice and obtains the current available resource status of the system from the resource monitor; Step S403: When the available resources of the system meet the resource tag requirements of the functional slice, the scheduler retrieves the execution logic code segment of the functional slice from the unified code pool to the execution buffer and executes the functional slice. Step S404: When the currently available resources of the system do not meet the resource tag requirements of the functional slice, the scheduler suspends the execution of the functional slice, adds the functional slice to the waiting queue, and resumes execution after the system resources are released. In step S405, after the function slice is executed, the scheduler immediately releases the execution buffer occupied by the function slice and passes the execution result as input to the function slice corresponding to the subsequent node of the function slice in the execution flow graph.

[0011] Furthermore, in step S404, when multiple functional slices compete for limited execution resources, the scheduler allocates execution resources in descending order of priority value. Only when all functional slices with a priority value greater than that of the current functional slice have finished executing and released their execution buffers, does the current functional slice obtain execution resources and resume execution. When the available resources of the system are lower than the preset resource shortage threshold, the scheduler performs degraded execution on function slices with priority values ​​lower than 5. The degraded execution means that the scheduler adopts a simplified execution mode for the function slices that are degraded. The simplified execution mode includes reducing the sampling frequency, reducing the number of iterations, or using an approximate algorithm instead of an exact algorithm.

[0012] Secondly, this application provides a modular loading system for the business functions of a smart energy meter, comprising: Functional slice library construction unit: used to decompose all business functions of smart energy meters into multiple atomic-level functional slices. Each functional slice is the smallest executable unit of business functions, and each functional slice is stored in the unified code pool of smart energy meters. Functional requirement parsing unit: Used to receive business functional requirement descriptors, parse the requirement descriptors through the functional orchestration engine, and decompose them into several sub-tasks; Slice matching and execution flow orchestration unit: used to match the corresponding functional slice in the functional slice library according to each subtask, and the functional orchestration engine dynamically generates the execution flow graph according to the matching result; Dynamic scheduling execution unit: used to retrieve the corresponding function slices from the unified code pool as needed and execute them in the execution buffer according to the execution flow graph, and release the execution buffer after the slices are executed.

[0013] Thirdly, this application also provides a modular loading device for the business functions of a smart meter, the modular loading device for the business functions of a smart meter comprising: a memory, a processor, and a modular loading program for the business functions of a smart meter stored in the memory and executable on the processor, wherein the modular loading program for the business functions of a smart meter implements the above method when executed by the processor.

[0014] Fourthly, this application also provides a computer program product, which includes a business function modular loading program for a smart energy meter. When the business function modular loading program for the smart energy meter is executed by a processor, it implements the above-mentioned method.

[0015] This application discloses the following technical effects: This invention abandons the existing technical convention of pre-dividing fixed storage subspaces and statically binding modules to storage locations. Instead, it uses a unified code pool to store all functional slices, eliminating the need to reserve fixed storage space for each business function module of the smart meter. Each functional slice shares a unified storage area, and storage space can be dynamically allocated according to actual usage. This avoids the problem of wasted or insufficient storage space caused by varying module sizes and dynamic changes, making it suitable for embedded environments of smart meters where storage resources are limited.

[0016] Existing technologies use complete compiled modules as functional units, requiring the replacement of the entire module file for any functional change. This invention further decomposes business functions into atomic-level functional slices, dynamically generating various business function variants through different combinations of these slices. During function updates, only the changed individual functional slices need to be updated as incremental patches, eliminating the need for a complete replacement.

[0017] Furthermore, this invention achieves slice-level grayscale updates through mechanisms such as incremental patch writing to idle areas, instantaneous pointer redirection switching, and old version retention and rollback. Simultaneously, a dynamic scheduling mechanism based on functional slice resource tags and real-time system resource status ensures that high-priority core services receive priority execution resources when resources are scarce, fundamentally guaranteeing the reliable operation of the electricity meter's core functions. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a method for modularly loading the business functions of a smart energy meter, as provided in an embodiment of this application.

[0019] Figure 2 The directed acyclic graph execution flow graph provided in the embodiments of this application.

[0020] Figure 3 This is a schematic diagram of the structure of a modular loading system for the business functions of a smart energy meter, provided in an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description of this application will be provided in conjunction with the accompanying drawings. The described embodiments should not be considered as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] Example 1: This application provides a method for modularly loading the business functions of a smart energy meter, such as... Figure 1 As shown, the method includes: Step S10: Construct a functional slice library, decompose all business functions of the smart energy meter into multiple atomic-level functional slices, each functional slice is the smallest executable unit of the business function, and each functional slice is stored in the unified code pool of the smart energy meter.

[0023] Taking a multi-core modular smart energy meter based on the IR46 international recommendation as an example, its business functions typically include: fundamental energy metering, harmonic energy metering, voltage monitoring, current monitoring, power monitoring, power factor calculation, frequency measurement, voltage loss event recording, current loss event recording, phase loss event recording, and remote fee control, among dozens of other functions. Functional semantic analysis is performed on each of these business functions to identify the smallest indivisible business operation unit. Taking the remote fee control business function as an example, it is decomposed into the following smallest business operation unit: Operation Unit A: Parses the remotely issued fee control instruction frame and extracts fields such as instruction type (closing / opening), target table number, operation timestamp, and security authentication code; Operation Unit B: Verifies the legitimacy of the instruction source by comparing the MAC or digital signature; Operation Unit C: Query the current account balance status (normal / outstanding / overdraft); Operating Unit D: Calculates the current electricity price based on the tariff scheme; Operation Unit E: Determines whether the current balance meets the closing conditions or whether the arrears have reached the tripping threshold; Operating unit F: Outputs relay control signals (closing / opening); Operation Unit G: Records expense control operation events (including operation time, operation result, and balance before and after the operation); Operation unit H: Generates a fee control operation response frame and reports it to the master station.

[0024] Each smallest operational unit is defined as a functional slice, and the aforementioned operational units A to H correspond to functional slices S_A to S_H, respectively. Similarly, the above decomposition operation is performed on all operational functions to ultimately form a set of functional slices covering all operational functions of the electricity meter.

[0025] Taking the functional slice S_A (parsing the cost control instruction frame) as an example, configure the following slice metadata: Slice identifier: Slice_FcCtrl_CmdParse_v2.1.3, where FcCtrl represents the remote cost control service domain, CmdParse represents the instruction parsing operation, and v2.1.3 is the version number; Execution logic code segment: Parsing function code stored in C language intermediate code form. The input of this function is the pointer to the original message data buffer and the message length, and the output is the parsed instruction structure; Input and output contracts: Input contract {msgBuf: byte

[256] , msgLen: uint8, encType:uint8}, which is the original message buffer msgBuf (maximum 256 bytes), message length msgLen, and encryption type identifier encType; Output contract {cmdType: uint8, targetMeterNo: byte[8], timeStamp: uint32, authCode: byte

[16] , result: uint8}, which includes instruction type cmdType, target table number targetMeterNo, timestamp timeStamp, authentication code authCode, and parsing result status code result; Dependency declaration: This slice is the starting slice of the remote cost control execution flow graph and does not depend on other slices; Resource tags: {minRAM: 512 bytes, maxExecTime: 5ms, priority: 3}, minRAM indicates that at least 512 bytes of RAM are required to run, the maximum execution time maxExecTime does not exceed 5 milliseconds, and the priority is level 3 (0-9, the larger the value, the higher the priority).

[0026] The execution logic code segments of all functional slices are stored as C language intermediate code in a unified code pool of the smart meter. This unified code pool is a contiguous FLASH storage area, the size of which is determined by the meter's hardware configuration. This unified code pool does not pre-allocate any fixed-size storage subspaces; all functional slices share the entire storage area. The slice metadata for each functional slice is stored in a slice index table. This slice index table is stored in RAM and loaded from FLASH during system startup, supporting fast lookup and matching.

[0027] The unified code pool management module maintains a free block linked list, recording all available free storage areas. When a new or updated feature slice needs to be stored, the free block linked list allocates sufficient contiguous storage space using the First-Fit algorithm. When a feature slice is discarded, the storage space it occupied is reclaimed and merged into the free block linked list.

[0028] Step S20: Receive the business function requirement descriptor, parse the requirement descriptor through the function orchestration engine, and decompose it into several sub-tasks.

[0029] Taking the smart meter's requirement to execute the business function "the master station issues a remote fee control closing operation command through a remote communication channel" as an example, the system receives the requirement descriptor for this business function. This requirement descriptor uses a JSON structured format, recording the unique identifier of the business function, defining the input parameters required to execute the function (original message, message length, and encryption type), defining the expected output type (relay control signal), and defining the constraints for business execution (maximum latency of 200 milliseconds, high security level).

[0030] After receiving the above JSON descriptor, the function orchestration engine first calls the JSON parser to perform lexical analysis on the descriptor, breaking down the JSON text into a sequence of lexical units, including: object start character {, string key value funcId (unique function identifier), string value RemoteFcCtrl_On (executes remote fee control closing operation instruction), array start character [, etc.

[0031] Then, syntax analysis is performed, and a syntax tree is constructed according to the JSON syntax rules. The root node of the syntax tree is the functional requirement object, and its child nodes include the funcId node, the funcName (business function description) node, the input (input parameter) node, the output (output parameter) node, and the constraints (constraints) node.

[0032] The functional semantic elements are extracted from the syntax tree, including: function type is remote prepaid closing operation, input parameter type is encrypted message, output parameter type is relay control signal, and constraints include a maximum delay of 200ms and a high security level. Based on these extracted functional semantic elements, the function orchestration engine calls the pre-stored business process template library to decompose the remote prepaid closing operation business function requirement into several sub-tasks with logical temporal relationships, including: Subtask T1: Parse the encrypted message, extract the plaintext data of the instruction, corresponding to function slice S_A; Subtask T2: Verify the legality of the instruction source, corresponding to function slice S_B; Subtask T3: Query the current account balance status, corresponding to function slice S_C; Subtask T4: Calculate the electricity price under the current rate, corresponding to function slice S_D; Subtask T5: Determine whether the closing conditions are met, corresponding to function slice S_E; Subtask T6: Output relay closing signal, corresponding to function slice S_F; Subtask T7: Record cost control operation events, corresponding to function slice S_G; Subtask T8: Generate a response frame, corresponding to function slice S_H.

[0033] Simultaneously record the dependencies between the above subtasks: T1→T2→(T3∥T4)→T5→T6→(T7∥T8), where ∥ indicates parallel execution and → indicates sequential dependency.

[0034] Step S30: Match the corresponding function slice in the function slice library according to each subtask, and the function orchestration engine dynamically generates an execution flow graph based on the matching result.

[0035] In this embodiment, based on the functional requirement parsing result obtained in step S20, the slice matching engine sequentially obtains each subtask T1 to T8, and queries the functional slice library for a matching functional slice for each subtask. Taking subtask T1 parsing encrypted messages as an example, the matching process is as follows: Extract the functional semantic keywords of subtask T1: parse, encrypt message, extract instructions; perform multi-dimensional matching in the slice index table: first, match the input and output contracts. The input of subtask T1 is an encrypted message, and the output is a plaintext instruction structure. Search the slice index table for slices whose input contract contains an encrypted message and whose output contract contains an instruction structure; further, filter according to dependencies. Subtask T1 is the starting subtask, so the dependency declaration of the selected functional slices must be empty; After the above matching, there are two candidate functional slices in the slice index table: Candidate functional slice S_A: specifically for parsing DL / T 645-2007 protocol messages, with complete matching of input and output contracts and empty dependency declarations; Candidate functional slice S_A2: a general message parsing slice that supports multiple protocol formats but has lower parsing efficiency, with partial matching of input and output contracts; Based on the matching degree, S_A has a matching degree of 100%, and S_A2 has a matching degree of 70%. Functional slice S_A is selected as the matching result of T1.

[0036] Using the same matching process described above, for subtask T3, querying the balance status, functional slice S_C is obtained; for subtask T4, calculating the electricity price, functional slice S_D is obtained. For subtask T5, determining the closing condition, two candidate functional slices are matched: Candidate functional slice S_E1: Standard closing condition judgment slice, resource label is {minRAM: 256 bytes, maxExecTime: 2ms}; Candidate functional slice S_E2: Enhanced closing condition judgment slice (including anti-jitter and multi-check logic), resource label is {minRAM: 512 bytes, maxExecTime: 8ms}.

[0037] The current available system resources are obtained from the resource monitor: the current available RAM is 768 bytes, the CPU load rate is 45%, and the resource requirements of both candidate function slices meet the current available resources.

[0038] The slice matching engine further evaluates each candidate functional slice based on the principle of optimal resource consumption, using the following resource consumption scoring formula:

[0039] in, Indicates the first Resource consumption score for candidate function slices; the lower the score, the better the resource consumption. Indicates the first The minimum amount of memory required for each candidate feature slice is read from the resource tag of that slice; This indicates the total amount of RAM currently available in the system, provided in real time by the resource monitor. Indicates the first The longest execution time (in microseconds) of each candidate function slice is read from the resource tag of that slice; The base time unit is 1000 microseconds (i.e., 1 millisecond), which is used to make the execution time dimensionless so that it can be compared with memory usage on the same order of magnitude. and These are the weighting coefficients for memory usage and execution time, respectively. , In this embodiment, considering that RAM resources are scarcer than CPU time in the embedded environment of a smart energy meter, the following settings are made: =0.7, =0.3.

[0040] Substitute the resource tag parameters of S_E1 and S_E2 into the above formula for calculation: S_E1 resource consumption rating: =0.7×256 / 768 +0.3×2000 / 1000= 0.833; S_E2 resource consumption score: =0.7×512 / 768 +0.3×8000 / 1000 =2.867; Compare the two resource consumption scores. S_E1 has a lower resource consumption score, indicating that it consumes resources better under the current system resource conditions. Therefore, the slice matching engine selects the functional slice S_E1 as the matching result for subtask T5.

[0041] The resource consumption scoring mechanism described above achieves optimal utilization of system resources while meeting functional requirements, thus avoiding system bottlenecks caused by resource-intensive slices when resources are scarce.

[0042] The execution flow orchestrator constructs a directed acyclic graph (DAG) as the execution flow graph, using each functional slice as a node and the data dependencies between functional slices as edges, based on the matching results of all subtasks. Figure 2 As shown, the execution flow graph in this embodiment includes 8 nodes N1 to N8, each node corresponding to functional slices S_A to S_H respectively; among them, there is no data dependency between N3 and N4, and between N7 and N8, and they can be executed in parallel; N5 can only start execution after N3 and N4 have been executed, forming a synchronization convergence point, and the direction of the arrow on the directed edge indicates the direction of data transmission.

[0043] The execution flow orchestrator performs the following checks on the generated execution flow graph: Cyclic dependency detection: The Kahn algorithm (topological sorting algorithm) is used to detect the existence of cycles in the directed graph. The algorithm process includes: calculating the in-degree of all nodes and adding all nodes with an in-degree of 0 to a queue; removing nodes from the queue and decrementing the in-degree of all their successor nodes by 1; if the in-degree of a successor node becomes 0, adding it to the queue, and repeating the above process until the queue is empty; if the number of visited nodes is less than the total number of nodes, a cycle exists in the execution flow graph. In this embodiment, all 8 nodes were successfully visited, and there is no cyclic dependency.

[0044] Dependency Conflict Detection: Checks whether there are data conflicts (i.e., incompatible output data formats) between two or more predecessor nodes that a node depends on. The execution stream orchestrator compares the output contract {balance: int32,status: uint8} of N3 with the output contract {price: uint16, rateNo: uint8} of N4. The two data formats are different and do not conflict. N5 can accept both as inputs, so the dependency compatibility check passes.

[0045] In step S40, the scheduler retrieves the corresponding function slices from the unified code pool as needed and executes them in the execution buffer according to the execution flow graph. After the slices are executed, the execution buffer is released.

[0046] After obtaining the execution flow graph, the dynamic scheduler uses a topology sorting algorithm to determine the execution order of each functional slice. In this embodiment, the determined topology execution order is: N1→N2→(N3∥N4)→N5→N6→(N7∥N8), where N3 and N4 can be executed in parallel, and N7 and N8 can be executed in parallel.

[0047] Taking the execution of function slice S_A as an example, the scheduler performs the following operations before execution: Query the resource tag of S_A from the slice index table: {minRAM: 512 bytes, maxExecTime: 5ms, priority: 3}; call the resource monitor to get the current available resource status of the system: the current available RAM is 2048 bytes, and the CPU utilization rate is 35%; compare the resource requirements with the available resources: 512 bytes ≤ 2048 bytes, and the CPU load is lower than the preset busy threshold (80%), so the resource conditions are met.

[0048] Since the resource conditions are met, the scheduler performs the following operation: Read the code segment of S_A (starting address 0x1000, length 1024 bytes) from the unified code pool; load the code segment into the execution buffer (a pre-allocated dynamic execution buffer located in RAM); set the program counter to the starting address of the execution buffer and execute the code of S_A; During the execution of S_A, 48 bytes of data in the input message buffer are parsed to extract the instruction type = closing (0x01), target table number = 0x12345678, timestamp = 0x5A8B9C00, and authentication code = 16 bytes of data. After S_A is completed, the execution time is 3.2ms, which is less than the constraint of maxExecTime (5ms).

[0049] In another possible scenario, when resource contention exists, and there are currently 1024 bytes of available RAM, three function slices are requesting execution simultaneously: Functional slice A: Fundamental energy metering, resource tag {minRAM: 128 bytes, maxExecTime: 2ms, priority: 9} (legal metering function); Functional slice B: Event reporting, resource tag {minRAM: 256 bytes, maxExecTime: 10ms, priority: 6} (communication reporting function); Functional slice C: Load forecasting slice, resource tag {minRAM: 1024 bytes, maxExecTime: 50ms, priority: 2} (non-metering auxiliary function).

[0050] The resource scheduling unit sorts the above functional slices from highest to lowest priority value: Functional slice A (priority=9) > Functional slice B (priority=6) > Functional slice C (priority=2) The scheduling process is as follows: Functional slice A first obtains execution resources, allocates 128 bytes of RAM, executes the metering task, and the execution time is 2ms; after functional slice A completes execution, it releases 128 bytes of RAM, and the system's available RAM is restored to 1024 bytes. Functional slice B (p=6) acquires execution resources, allocates 256 bytes of RAM, and executes the event reporting task. During the execution of functional slice B (execution time is 10ms), the available RAM of the system decreases from 1024 bytes to 768 bytes. After functional slice B completes execution, it releases 256 bytes of RAM, and the available RAM of the system is restored to 1024 bytes. Functional slice C (p=2) acquires execution resources, requiring 1024 bytes of RAM, which is exactly met by the system's available RAM, and executes the load forecasting task. Assume that during the execution of slice C, a new high-priority metering task (functional slice D, priority=9) arrives, requiring 128 bytes of RAM. At this time, the available RAM is 0 (occupied by functional slice C), and the resource scheduling unit executes a priority preemption strategy, including the following process: The newly arrived functional slice D is detected to have a priority value of 9, which is higher than the priority value of 2 of the currently executing functional slice C. The resource scheduling unit immediately suspends the execution of functional slice C and saves the context of slice C (current execution state, intermediate calculation results, program counter, etc.) to the context storage area. 128 bytes are allocated from the 1024-byte execution buffer occupied by functional slice C to functional slice D, and functional slice D begins to execute the metering task. After functional slice D finishes execution, it releases the 128 bytes, the system restores the context of functional slice C, and continues to execute the remaining part of functional slice C.

[0051] During the scheduling process described above, the resource scheduling unit strictly allocates resources according to a single quantitative standard of priority values ​​from largest to smallest. Functional slices with a priority value of 9 have priority over functional slices with a priority value of less than 9 in obtaining execution resources. Functional slices with a priority value of less than 9 are sorted in descending order of priority value. Only when all functional slices with a priority value greater than the current slice have completed execution and released their execution buffers will the current slice obtain execution resources and resume execution.

[0052] In this embodiment, taking the completion of N6 (S_F, output relay signal) as an example: After N6 completes execution, it generates output data: relay control signal = closing (logic level "1"), and the output data volume is 1 byte; the scheduler immediately releases the execution buffer occupied by N6 (releases RAM resources), and uses the output result of N6 (relay closing signal) as input data, and simultaneously passes it to N7 (S_G, record fee control event) and N8 (S_H, generate response frame). After N7 and N8 obtain the input data, they load it into their respective execution buffers for execution; after the slice is completed, the scheduler releases all execution buffers, and the system resources are restored to the initial state.

[0053] In another possible scenario, when the available resources of the system are lower than the preset resource shortage threshold, the scheduler starts the degraded execution mode, setting the resource shortage threshold to be less than 20% of the total RAM (for example, if the total RAM is 2048 bytes, degrade will be triggered when the available RAM is less than 410 bytes).

[0054] Taking the degraded execution load prediction slice (S_Predict, priority=2) as an example, the comparison between this slice in normal mode and degraded execution mode is as follows: In normal execution mode, the load forecasting slice is executed every 15 minutes, with a sampling frequency of 64 points per second. It uses the precise ARIMA time series algorithm and requires 1024 bytes of RAM and 50ms execution time. When the available RAM in the system drops below 410 bytes, the scheduler detects that the priority value of the function slice S_Predict is 2 (lower than 5) and performs degraded execution on the slice: the sampling frequency is reduced to 16 points per second, the number of ARIMA algorithm iterations is reduced from 50 to 10, and a simplified exponential smoothing method is used to replace the full ARIMA algorithm; after degraded execution, the required RAM is reduced to 256 bytes, the execution time is shortened to 8ms, and the accuracy loss is controlled within 5%.

[0055] Degradation execution frees up 768 bytes of RAM for higher-priority metering functions, effectively ensuring the reliable operation of the core legal metering functions under resource constraints. Once system resources are restored, the scheduler automatically switches the function slice S_Predict from degraded execution mode back to normal execution mode, restoring the complete sampling frequency and algorithm accuracy.

[0056] Furthermore, the modular loading method for the business functions of a smart energy meter provided in this application embodiment also includes an online update step for function slices: For example, the function slice S_E (determining closing conditions) needs to be updated. The new judgment logic adds consideration of the tiered electricity price threshold. The server generates incremental patch data: compares the binary code of the new version (v2.1.4) of S_E with the old version (v2.1.3), generates a difference file, which is only 15% the size of the old version code.

[0057] The smart energy meter receives the incremental patch data through a remote communication channel. The format of the patch data packet is: {sliceId: "S_E", targetVersion: "v2.1.4", patchData: byte

[307] , patchType: "bsdiff", checksum: "MD5"}. SliceId is the unique identifier of the functional slice, targetVersion represents the new version number, and patchData represents the incremental patch data body, that is, the difference data between the functional slice code of the new and old versions. It is generated by the bsdiff binary difference algorithm and only contains the binary code of the changed part, rather than the complete functional module file. PatchType is the patch algorithm type identifier, and checksum is the checksum, which is the hash value generated by the MD5 message digest algorithm on patchData.

[0058] The slice version manager performs the following checks on the received incremental patch data: Integrity verification: Calculate the MD5 checksum of the patch data and compare it with the checksum field in the patch data packet. If they match, it indicates that the data has not been tampered with or lost during transmission. Security verification: Verify the source digital signature of the patch data package, use the preset master site public key to verify the signature, and confirm that the patch does indeed come from a legitimate server; Version compatibility check: Check if the target version number v2.1.4 is higher than the current version number v2.1.3 to avoid version rollback or duplicate updates.

[0059] After all verifications pass, the slice version manager requests storage space from the unified code pool management module. The unified code pool management module queries the free block list and finds a free block of 512 bytes (starting address 0x8000, ending address 0x81FF). The incremental patch is applied to the old version code (merging operation is performed in a temporary buffer), generating the complete new S_E version code (size 2048 bytes, occupying free block space 0x8000-0x87FF, using two adjacent free blocks).

[0060] The updated version of the function slice S_E is written to the free area of ​​the unified code pool (starting address 0x8000, size 2048 bytes). The original old version S_E remains unchanged at its original storage address (starting address 0x6000).

[0061] The slice version manager updates the S_E record in the version mapping table: The record before the update was {sliceId: "S_E", version: "v2.1.3", codeAddr: 0x6000, codeLen: 2048, status: valid}; the record after the update is {sliceId: "S_E", version: "v2.1.4", codeAddr: 0x8000, codeLen: 2048, status: valid}, where version represents the version number of the function slice S_E, codeAddr is the starting storage address of the execution logic code segment of the function slice in the unified code pool, codeLen is the length of the storage space occupied by the execution logic code segment of the function slice in bytes, and status is the current availability status of the function slice, used to indicate whether the slice can be matched and executed by the scheduler.

[0062] This pointer redirection operation is completed through an atomic memory write instruction, and the entire switching process takes no more than one CPU clock cycle, achieving instantaneous version switching. Simultaneously, the old version record is moved to the historical version list: {sliceId:"S_E", version: "v2.1.3", codeAddr: 0x6000, codeLen: 2048, status: obsolete, can be rolled back}.

[0063] Suppose that a logical defect is found in the new version of function slice S_E (v2.1.4) during runtime. Under specific boundary conditions (the third tier of the tiered electricity price, when the balance is exactly equal to the threshold), the judgment logic fails. If the execution result of node N5 (corresponding to function slice S_E) in the execution flow graph is abnormal (the output control signal does not match the expectation), the version rollback mechanism will be immediately triggered. The slice version manager queries the historical version list to obtain the old version record of the function slice S_E (v2.1.3, storage address 0x6000); it performs a pointer redirection operation, instantly switching the pointer of the function slice S_E from 0x8000 (new version) back to 0x6000 (old version); when the function slice S_E is called subsequently, the old version code is automatically executed, without affecting other running function slices.

[0064] During the update process of functional slice S_E, the system is executing remote cost control services. Functional slice S_E is running old version code (v2.1.3) in the execution buffer. At the same time, the update instruction arrives, and the slice version manager completes pointer redirection (switching to v2.1.4).

[0065] The N5 instance in execution continues to execute using the old version of the code (v2.1.3) that has been loaded into the execution buffer until execution is complete and the buffer is released. After the execution buffer is released, the scheduler reads the new version of the code (v2.1.4) from the unified code pool and loads it into the execution buffer the next time N5 is called. At the same time, there is no situation where the old and new versions of the code are mixed and executed in the system, and the execution context of each slice instance remains complete and consistent. This achieves slice-level canary updates where the business functions being executed are not affected by updates.

[0066] Example 2: The modular loading system for the business functions of a smart energy meter provided in this embodiment of the invention can execute the modular loading method for the business functions of a smart energy meter provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method, such as... Figure 3 As shown, it includes: Functional slice library construction unit: used to decompose all business functions of smart energy meters into multiple atomic-level functional slices. Each functional slice is the smallest executable unit of business functions, and each functional slice is stored in the unified code pool of smart energy meters. Functional requirement parsing unit: Used to receive business functional requirement descriptors, parse the requirement descriptors through the functional orchestration engine, and decompose them into several sub-tasks; Slice matching and execution flow orchestration unit: used to match the corresponding functional slice in the functional slice library according to each subtask, and the functional orchestration engine dynamically generates the execution flow graph according to the matching result; Dynamic scheduling execution unit: used to retrieve the corresponding function slices from the unified code pool as needed and execute them in the execution buffer according to the execution flow graph, and release the execution buffer after the slices are executed.

[0067] Although this application makes various references to certain modules in the system according to the embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the scope of protection of this invention.

[0068] Example 3: This application provides a modular loading device for the business functions of a smart meter. The modular loading device for the business functions of a smart meter includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the modular loading method for the business functions of a smart meter as described in Example 1 above.

[0069] Example 4: This application provides a computer program product including a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication system, or installed from a storage system. When the computer program is executed by a processing system, it performs the functions defined in the method of Example 1 of this application.

[0070] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application. In some cases, the actions or steps described in this application can be performed in a different order than that shown in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A method for modularly loading the business functions of a smart energy meter, characterized in that, The method includes: Step S10: Construct a functional slice library, decompose all business functions of the smart energy meter into multiple atomic-level functional slices, each functional slice is the smallest executable unit of the business function, and each functional slice is stored in the unified code pool of the smart energy meter. Step S20: Receive the business function requirement descriptor, parse the requirement descriptor through the function orchestration engine, and decompose it into several sub-tasks; Step S30: Match the corresponding function slice in the function slice library according to each subtask, and the function orchestration engine dynamically generates an execution flow graph based on the matching result; In step S40, the scheduler retrieves the corresponding function slices from the unified code pool as needed and executes them in the execution buffer according to the execution flow graph. After the slices are executed, the execution buffer is released.

2. The modular loading method for the business functions of a smart energy meter as described in claim 1, characterized in that, In step S10, the construction of the functional slice library includes the following detailed steps: Step S101: Perform functional semantic analysis on all business functions of the smart energy meter, identify the smallest indivisible business operation unit contained in each business function, and define each of the smallest business operation units as a functional slice. Step S102: Configure slice metadata for each functional slice. The slice metadata includes: slice identifier, execution logic code segment, input / output contract, dependency declaration, and resource tag. The resource tag indicates the minimum memory required for the functional slice to run, the minimum CPU time, and the priority value. The priority value is an integer between 0 and 9, with a higher value indicating a higher priority. Step S103: Store the execution logic code segments of all functional slices in the unified code pool in the form of source code level or intermediate code level, and store the slice metadata of each functional slice in the slice index table; the unified code pool does not pre-divide fixed storage subspaces, and each functional slice shares a unified storage space.

3. The modular loading method for the business functions of a smart energy meter as described in claim 1, characterized in that, Step S20 includes the following detailed steps: Step S201: Receive a structured business function requirement descriptor, wherein the requirement descriptor defines the input parameters, expected output, and constraints of the required business function; Step S202: The function orchestration engine performs lexical and syntactic analysis on the requirement descriptor and extracts the functional semantic elements therein. Step S203: The function orchestration engine decomposes the business function requirements into several sub-tasks with logical temporal relationships based on the function semantic elements, and records the dependencies between each sub-task.

4. The modular loading method for the business functions of a smart energy meter as described in claim 1, characterized in that, Step S30 includes the following detailed steps: Step S301: The slice matching engine queries the functional slice library for matching functional slices based on the functional semantics of each subtask. The matching criteria include the degree of matching between the functional semantics of the subtask and the input-output contract of the slice, as well as the compatibility between the dependency relationships between the subtasks and the dependency relationship declarations of the slice. Each subtask matches one or more candidate feature slices; Step S302: When a subtask matches multiple candidate functional slices, the slice matching engine performs a comprehensive evaluation based on the resource tags of each candidate functional slice and the current resource status of the system, and selects the functional slice with the best resource consumption as the matching result. Step S303: The execution flow orchestrator constructs a directed acyclic graph as the execution flow graph based on the matching results of all subtasks, with each functional slice as a node and the data dependencies between functional slices as edges. Step S304: The execution flow orchestrator performs dependency conflict detection and circular dependency detection on the directed acyclic graph to ensure that the execution flow graph is acyclic and can be executed in parallel.

5. The modular loading method for the business functions of a smart energy meter as described in claim 4, characterized in that, Step S40 includes the following detailed steps: Step S401: The scheduler determines the execution order of each functional slice according to the topological order of the execution flow graph; Step S402: Before executing the current functional slice, the scheduler queries the resource tag of the functional slice and obtains the current available resource status of the system from the resource monitor; Step S403: When the available resources of the system meet the resource tag requirements of the functional slice, the scheduler retrieves the execution logic code segment of the functional slice from the unified code pool to the execution buffer and executes the functional slice. Step S404: When the currently available resources of the system do not meet the resource tag requirements of the functional slice, the scheduler suspends the execution of the functional slice, adds the functional slice to the waiting queue, and resumes execution after the system resources are released. In step S405, after the function slice is executed, the scheduler immediately releases the execution buffer occupied by the function slice and passes the execution result as input to the function slice corresponding to the subsequent node of the function slice in the execution flow graph.

6. The modular loading method for the business functions of a smart energy meter as described in claim 5, characterized in that, In step S404, when multiple functional slices compete for limited execution resources, the scheduler allocates execution resources in descending order of priority value. Only when all functional slices with a priority value greater than the current functional slice have finished executing and released the execution buffer can the current functional slice obtain execution resources and resume execution. When the available resources of the system are lower than the preset resource shortage threshold, the scheduler performs degraded execution on function slices with priority values ​​lower than 5. The degraded execution means that the scheduler adopts a simplified execution mode for the function slices that are degraded. The simplified execution mode includes reducing the sampling frequency, reducing the number of iterations, or using an approximate algorithm instead of an exact algorithm.

7. The modular loading method for the business functions of a smart energy meter as described in claim 1, characterized in that, The method also includes an online update step for functional slices: The smart energy meter receives incremental patch data from the server. The incremental patch data only contains the changed parts of the functional slices that have been changed, rather than the complete functional module files. The slice version manager performs integrity and security checks on the incremental patch data; After verification, the slice version manager will directly write the updated feature slices into the free area of ​​the unified code pool, while the original old version feature slices remain unchanged. The slice version manager updates the version mapping table, redirecting the pointer to the feature slice from the old version to the new version; when the feature slice is called subsequently, the scheduler automatically executes the new version of the feature slice; if the new version of the feature slice runs abnormally, the slice version manager instantly switches back to the old version by pointer rollback.

8. A modular loading system for the business functions of a smart energy meter, characterized in that, The system is used to implement the modular loading method for the business functions of a smart energy meter according to any one of claims 1-7, the system comprising: Functional slice library construction unit: used to decompose all business functions of smart energy meters into multiple atomic-level functional slices. Each functional slice is the smallest executable unit of business functions, and each functional slice is stored in the unified code pool of smart energy meters. Functional requirement parsing unit: Used to receive business functional requirement descriptors, parse the requirement descriptors through the functional orchestration engine, and decompose them into several sub-tasks; Slice matching and execution flow orchestration unit: used to match the corresponding functional slice in the functional slice library according to each subtask, and the functional orchestration engine dynamically generates the execution flow graph according to the matching result; Dynamic scheduling execution unit: used to retrieve the corresponding function slices from the unified code pool as needed and execute them in the execution buffer according to the execution flow graph, and release the execution buffer after the slices are executed.

9. A modular loading device for the business functions of a smart energy meter, characterized in that, The modular loading device for the business functions of the smart energy meter includes: a memory, a processor, and a modular loading program for the business functions of the smart energy meter stored in the memory and executable on the processor. When the modular loading program for the business functions of the smart energy meter is executed by the processor, it implements a modular loading method for the business functions of a smart energy meter according to any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a modular loading program for the business functions of a smart meter. When the modular loading program for the business functions of a smart meter is executed by a processor, it implements a modular loading method for the business functions of a smart meter according to any one of claims 1 to 7.

Images