Electricity settlement rule automatic adjustment method and system for new market subject

Abstract

The application provides a power settlement rule automatic adjustment method and system for new market subjects, relates to the technical field of power market transactions, and aims at the problems that the existing technology has rule adjustment lag, difficulty in complex logic modeling, difficulty in balancing high real-time performance and high reliability, and absence of multi-source rule conflict detection and other problems. The method obtains multi-source data, performs flow processing, extracts business features, and generates rule execution context; a three-layer rule engine including a base, a scene and dynamics is constructed; a rule dependency graph is constructed, and a graph neural network is used for rule conflict detection to obtain conflict detection results; the three-layer rule engine is embedded in the multi-source data flow, the three-layer rule engine is called, and a decision result is generated; and a state synchronization mechanism is used to obtain the adjusted settlement rule through cooperative distributed calculation. The application solves the problems of the existing technology and meets the high-frequency, complex and real-time settlement requirements of the new power market.

Description

Technical Field

[0001] This invention belongs to the field of electricity market trading technology, and in particular relates to a method and system for automatically adjusting electricity settlement rules for new market participants. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] With the deepening of power market reform, the scale of new market players, represented by energy storage, virtual power plants, and load aggregators, participating in spot trading continues to expand. These players' trading models are characterized by multi-timescale coupling (day-ahead, intraday, real-time), diverse trading products (such as time-of-use pricing, ancillary services, etc.), and bidirectional power flow, resulting in complex settlement rules (such as multi-level offsetting, forward and reverse billing, etc.) and frequent rule iterations (such as monthly or even weekly updates).

[0004] However, traditional settlement systems, which use hard-coded rules embedded in monolithic applications, still have certain shortcomings in meeting the real-time settlement needs of complex scenarios in the electricity spot market: First, the rules lack flexibility; rule changes require manual code modification and system restarts, with response cycles lasting several days to weeks, which cannot match the high-frequency settlement needs of the spot market ("T+0 / T+1"). Second, complex rule modeling is difficult; modeling rules involving multi-level offsetting, nonlinear calculations, state machine judgments, and other complex nested logics is challenging, and traditional rule engines lack support for nested logic and dynamic dependencies. Third, there is a conflict between real-time performance and reliability; the spot market requires settlement of massive amounts of metering point data in minutes or even seconds. Fourth, settlement rules come from diverse sources, and rule conflict detection is lacking; multi-source rules (such as market agreements) may have logical contradictions, and manual verification is inefficient and prone to omissions, affecting the fairness of settlement. Summary of the Invention

[0005] To overcome the shortcomings of the existing technologies, this invention provides a method and system for automatically adjusting electricity settlement rules for new market participants. A novel method for automatically adjusting settlement rules for market participants, based on the collaboration of a hierarchical rule engine and stream computing, is designed to achieve real-time decision-making, intelligent conflict detection, and efficient parallel computing of settlement rules, meeting the needs of high-frequency rule iteration and complex settlement scenarios in the spot market.

[0006] To achieve the above objectives, one or more embodiments of the present invention provide the following technical solutions: The first aspect of this invention discloses a method for automatically adjusting electricity settlement rules for new market participants, comprising: Acquire multi-source data, which includes at least meteorological data, electricity market data, and equipment telemetry data; Perform stream processing on multi-source data, extract business features, and generate rule execution context; A three-layer rule engine, comprising basic, scenario-based, and dynamic elements, is constructed to obtain a structured rule data stream; Based on structured rule data flow, a rule dependency graph is constructed, and a graph neural network is used to detect rule conflicts to obtain conflict detection results; Based on the conflict detection results, a three-layer rule engine is embedded into the multi-source data stream, and the three-layer rule engine is called to generate decision results; By adopting a state synchronization mechanism and a collaborative distributed computing model, the adjusted settlement rules are obtained.

[0007] As a further technical solution, multi-source data is stream processed to extract business features and generate a rule execution context. The specific process is as follows: The multi-source data is cleaned and standardized to obtain standardized multi-source data. Feature extraction is performed on multi-source data to obtain business features; The standardized multi-source data and business characteristics constitute the rule execution context.

[0008] As a further technical solution, a three-layer rule engine comprising basic, scenario, and dynamic elements is constructed to obtain a structured rule data stream. The specific process is as follows: A basic rule layer is constructed, based on XSD, JAXB, and relational database triplet schema, to define, transform, and store static and atomic rules in a strongly typed manner; Construct a scenario rule layer, and based on the rule engine, perform condition-action modeling and execution order control on complex combined business logic; A dynamic rule layer is constructed, which generates environment-aware decision results based on the rule execution context and by utilizing a dynamic rule decision module that integrates dynamic rule flow, decision table and enhanced conditional expression.

[0009] As a further technical solution, a rule engine is used to perform condition-action modeling and execution order control on complex combined business logic. The specific process is as follows: The rule language of the rule engine defines the conditions for triggering rules, and supports nested attribute access, set operations, and logical operations; The action part after a rule is triggered can be defined using Java syntax or built-in functions of the rule engine, supporting fact updates and external system calls; The execution path of multiple sub-rules is defined by the rule flow, and the execution order of the rules is defined by the priority attribute.

[0010] As a further technical solution, based on the rule execution context, a dynamic rule decision module that integrates dynamic rule flow, decision table, and enhanced conditional expression is used to generate environment-aware decision results. The specific process is as follows: Define business states and execution paths through a graphical dynamic rule flow, supporting conditional branching, parallel execution, state backtracking, and context passing; Utilize decision tables to centrally manage threshold-action mapping rules with similar structures; The rules and conditions employ an enhanced expression language that supports arithmetic and logical operations, regular expression matching, and user-defined function calls.

[0011] As a further technical solution, a rule dependency graph is constructed based on structured rule data flow. The specific process is as follows: Each rule is broken down into condition nodes and action nodes, and multi-dimensional features, including type encoding, target object identifier, operator and parameter values, are extracted for each node. Based on the data dependency, temporal dependency, mutual exclusion and inclusion relationships between rules, directed edges are established between nodes, and the dynamic weights of the directed edges are calculated. In the rule dependency graph, identify multi-hop indirect dependency paths and calculate the weight decay of multi-hop indirect dependency paths based on the number of hops and a preset decay coefficient.

[0012] As a further technical solution, a graph neural network is used for rule conflict detection to obtain the conflict detection results. The specific process is as follows: A graph attention network is used to optimize the semantic embedding of nodes in the rule dependency graph, and neighbor node information is aggregated based on the attention mechanism. A hierarchical graph neural network is used to aggregate neighbor features with different hop counts at different layers to capture direct conflicts and multi-hop implicit conflicts between rules. The message passing mechanism is used to track the propagation path of conflicts in the rule dependency graph, and the conflict risk score is calculated based on the path weight.

[0013] As a further technical solution, a hierarchical graph neural network is adopted. This network aggregates neighbor features with different hop counts across different layers to capture direct and multi-hop implicit conflicts between rules. The graph neural network comprises three layers: a basic feature aggregation layer, a second-order dependency and relationship analysis layer, and a higher-order attention layer. The specific process is as follows: Explicit dependencies are identified by aggregating the direct neighbor features of nodes through the basic feature aggregation layer. By using a second-order dependency and relationship analysis layer, two-hop neighbor features are aggregated, and preliminary conflict detection is performed by combining the inclusion, intersection, and disjoint relationships between rules. By using a higher-order attention layer, we select and analyze the features of distant neighbors with three or more hops to identify indirect implicit conflicts in long-distance dependent paths.

[0014] As a further technical solution, the adjusted settlement rules are obtained through collaborative distributed computing. The specific process is as follows: Based on rule condition analysis, a rule dependency graph is constructed to identify groups of strongly dependent rules and map them to the same computing shard. At the same time, load-aware dynamic sharding adjustment and state affinity optimization are implemented. It employs a dual-mode approach, combining data-driven and rule-driven execution. Within each computing shard, the incoming data is matched and inferred according to the set of rules it is mapped to, and real-time decision-making is completed.

[0015] The second aspect of this invention discloses a method for automatically adjusting electricity settlement rules for new market participants, comprising: The data acquisition module is used to acquire multi-source data, which includes at least meteorological data, electricity market data, and equipment telemetry data. The data processing module is used to perform stream processing on multi-source data, extract business features, and generate rule execution contexts; The layered rule engine module is used to build a three-layer rule engine that includes basic, scenario, and dynamic rules to obtain a structured rule data stream. Based on the structured rule data stream, a rule dependency graph is constructed, and a graph neural network is used to detect rule conflicts to obtain conflict detection results. The rule-based collaborative computation module is used to embed the three-layer rule engine into a multi-source data stream based on the conflict detection results, call the three-layer rule engine, and generate decision results; it adopts a state synchronization mechanism and obtains the adjusted settlement rules through collaborative distributed computation.

[0016] The above one or more technical solutions have the following beneficial effects: In this embodiment, a three-layer rule engine architecture consisting of basic, scenario, and dynamic layers is constructed to achieve strong type management of static rules, efficient orchestration of complex business logic, and real-time decision-making driven by external data. By combining the collaborative mechanism of stream computing and the rule engine, it supports real-time settlement processing with high consistency or high throughput. Furthermore, intelligent conflict detection based on graph neural networks is introduced to accurately identify explicit and multi-hop implicit rule conflicts, significantly improving the accuracy, real-time performance, and reliability of complex settlement business.

[0017] In this embodiment, by constructing a three-layer decoupled rule engine architecture of foundation-scenario-dynamic and by using distributed state synchronization, the problem of rule update lag is solved, realizing dynamic hot update and agile response of rules. The response cycle for rule adjustment can be shortened from the traditional "several days to several weeks" to "minutes or even seconds", which perfectly matches the high-frequency settlement and rapid rule iteration requirements of the electricity spot market of "T+0 / T+1" and greatly improves the business flexibility of the system.

[0018] In this embodiment, by constructing a rule dependency graph and applying graph neural networks (GAT+GCN) for multi-hop neighbor analysis and conflict propagation path modeling, the system achieves automated and intelligent detection and impact analysis of multi-source rule conflicts. It can automatically and accurately identify direct conflicts such as overlapping time windows, contradictory actions, and condition dead zones. More importantly, it can discover implicit logical conflicts propagated by long path dependencies, enabling the system to not only locate conflict points but also trace the source of the conflict and analyze the scope of its impact.

[0019] In this embodiment, a topology of embedded decision points in the stream is adopted, the rule engine operator is deeply integrated into the stream processing framework such as Flink, and rule-driven dynamic data sharding and state affinity optimization are implemented. By leveraging the high throughput and low latency characteristics of stream computing and the parallel reasoning capability of the rule engine, millisecond-level real-time rule calculation is achieved for millions of metering point data streams. At the same time, through distributed state synchronization, the high availability of the system and the strong consistency of the calculation results are ensured in high-concurrency and uninterrupted operation scenarios, thus solving the traditional contradiction between real-time performance and reliability.

[0020] In this embodiment, the scenario rule layer uses the Drools rule engine to support complex conditional branching, set operations, and rule flow orchestration; the dynamic rule layer integrates dynamic rule flow, decision tables, and an enhanced expression language to achieve visualized and modular modeling of complex nonlinear, state machine-like business rules such as multi-level billing, bidirectional power flow billing, and virtual power plant aggregation compensation. Simultaneously, the technical implementation and business logic are completely decoupled, lowering the development and maintenance threshold and improving the expressibility, maintainability, and execution accuracy of complex rules.

[0021] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0022] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0023] Figure 1 This is a flowchart of the automatic adjustment method for electricity settlement rules for new market entities according to Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of directed edge modeling of dependency relationships in Embodiment 1 of the present invention. Detailed Implementation

[0024] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0025] It should be noted that the terminology used herein is for the purpose of describing particular implementations only and is not intended to limit the exemplary implementations of the present invention.

[0026] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0027] Example 1 This embodiment discloses a method for automatically adjusting electricity settlement rules for new market entities.

[0028] To more clearly illustrate this embodiment, the automatic adjustment process of electricity settlement rules for new market entities can be specifically described as follows: like Figure 1 As shown, this embodiment provides a method for automatically adjusting electricity settlement rules for new market entities, including: S1. Acquire multi-source data, which includes at least meteorological data, electricity market data, and equipment telemetry data; S2. Perform stream processing on multi-source data, extract business features, and generate rule execution context; S3. Construct a three-layer rule engine that includes basic, scenario, and dynamic rules to obtain a structured rule data stream; S4. Based on the structured rule data flow, construct a rule dependency graph and use a graph neural network to detect rule conflicts and obtain the conflict detection results; S5. Based on the conflict detection results, the three-layer rule engine is embedded into the multi-source data stream, and the three-layer rule engine is called to generate decision results; The adjusted settlement rules are obtained by adopting a state synchronization mechanism and through collaborative distributed computing.

[0029] like Figure 1 As shown, in step S1, multi-source data is acquired, which includes at least meteorological data, electricity market data, and equipment telemetry data.

[0030] By using stream processing frameworks such as Apache Flink or Kafka Streams, you can subscribe to multi-source external data streams in real time, that is, obtain multi-source data from transaction systems, risk control systems and CRM systems in real time through external system interfaces.

[0031] Multi-source data should include at least meteorological data, electricity market data, and equipment telemetry data. Meteorological data should include at least wind speed, temperature, and rainfall; electricity market data should include at least nodal tariffs and ancillary service prices; and equipment telemetry data should include at least wind power output, energy storage SOC, and inverter status.

[0032] like Figure 1 As shown, in step S2, multi-source data is stream processed to extract business features and generate a rule execution context.

[0033] (1) Clean and standardize the multi-source data to obtain standardized multi-source data.

[0034] After the data enters the system, it first undergoes real-time cleaning and standardization to remove outliers, fill in missing fields, and standardize timestamps and unit systems to ensure data quality.

[0035] (2) Extract features from multi-source data to obtain business features.

[0036] The original multi-source data is further processed into business feature vectors.

[0037] After real-time cleaning and standardization, the raw multi-source data enters the feature extraction and context construction stage. Targeted calculation methods transform the raw data into feature vectors directly related to business objectives. Specifically, for meteorological data, the system calculates the average wind speed based on a 10-minute sliding window, using it as a criterion for "strong wind events." For telemetry data, it combines the current state of charge (SOC) of the energy storage with a preset discharge curve to calculate the actual available regulating capacity of the energy storage. For electricity market signals, it integrates the day-ahead planned value with real-time operational deviations to generate a "frequency regulation demand urgency" index reflecting frequency regulation needs. These processed feature vectors, together with the raw data, constitute the context object for rule execution, providing crucial input for subsequent dynamic rule condition matching and decision-making, enabling rules to make accurate judgments based on real-time environmental conditions.

[0038] (3) The standardized multi-source data and business characteristics constitute the rule execution context.

[0039] Business features, together with the original data, form the context object for rule execution, which is then used for subsequent rule condition matching.

[0040] like Figure 1 As shown, in step S3, a three-layer rule engine including basic, scenario and dynamic elements is constructed to obtain a structured rule data stream.

[0041] A three-tiered rule system—foundational, scenario-based, and dynamic—is constructed for complex settlement business scenarios. The foundational layer uses XSD, JAXB, and a database to manage strongly typed static rules; the scenario layer uses Drools to support complex logic and execution order control; and the dynamic layer integrates stream processing and EL expressions to enable real-time decision-making driven by external data.

[0042] S301. Construct a basic rule layer, based on XSD, JAXB, and relational database triplet schema, to define, transform, and store static and atomic rules in a strongly typed manner.

[0043] To provide an immutable atomic data source, such as defining the current electricity price as 0.5 yuan per kilowatt-hour in any dimension, and to ensure the global consistency of such basic facts, a basic rule layer was designed.

[0044] The rule execution context is input to the basic rule layer. Various static rule files in XML format, such as electricity price standard files and equipment standard parameters, are processed by the basic rule layer to obtain at least structured database tables, strongly typed Java objects, and standardized JSON APIs, ensuring that the output items can be accurately stored in the corresponding database. In other words, the basic rule layer stores all immutable basic rules, such as electricity price time-of-use tables or equipment model parameters, providing a reliable and complete data foundation for subsequent scenario rule layers and dynamic rule layers. Specifically: When designing the basic rule layer, a strongly typed triplet pattern using XSD + JAXB + relational database is adopted to achieve consistent, traceable storage and management of static, atomic, and highly structured rules (such as electricity price standards, inherent equipment parameters, and basic geographic information). The specific process is as follows: 1) The data structure of each basic rule is defined as a three-level nested structure using XML schema.

[0045] Use XML Schema (XSD) to define the data structure for each type of basic rule, providing a framework for... <rule>(Rules subject) <condition>(Triggering conditions) <action>A three-level nested structure for (execution actions). For example, the XSD of electricity price standard rules will explicitly define elements such as time period division, price gradient, effective time, expiration time, applicable area, triggering conditions, and their data types, constraints, and levels.

[0046] 2) Based on a three-level nested structure, a standardized physical table structure is created in the relational database using SQL DDL.

[0047] Based on the aforementioned XSD definition, a standardized physical table structure is created in the relational database using SQL DDL. For example, when creating a price rule table, it includes XSD elements such as the corresponding start time period, end time period, price threshold, and region identifier ID, while simultaneously designing necessary indexes and foreign key constraints.

[0048] 3) Generate a bidirectional mapping library between XML and Java objects using JAXB.

[0049] Next, in order to facilitate lossless conversion between XML and Java objects, a Java class library with bidirectional mapping is generated through JAXB (Java Architecture for XML).

[0050] After the above steps, various static rule files in XML format are transformed into structured data records or standardized JSON API interfaces and stored in a relational database.

[0051] S302. Construct a scenario rule layer, and use the rule engine to perform condition-action modeling and execution order control on complex combined business logic.

[0052] The scenario rule layer is used to handle complex and combinatorial business logic, such as virtual power plant frequency regulation compensation strategies and demand response aggregation strategies. It decouples business logic from technical implementation through the rule engine (Drools), and completes the precise mapping of conditions and actions by encapsulating complex business logic, supporting efficient execution, dynamic adjustment and reuse of rules.

[0053] The rule execution context is input to the scenario rule layer. The input basic rule data, plus the corresponding business conditions, such as the current virtual power plant status or the current market signal, is processed by the scenario planning layer. Based on the basic rules and real-time conditions, the corresponding rule execution result is generated, such as initiating a status change command.

[0054] When designing the scenario rule layer, the following steps are key: first, the logical processing of complex conditional branches (such as compensation strategies for different frequency deviation ranges); second, precise control of the rule execution order (such as detecting the frequency first, then calculating compensation, and finally feeding back the result); and third, real-time updates of dynamic rules (such as adjusting the compensation coefficient according to market rules). The core mechanism of the Drools rule engine includes rule conditions, rule actions, rule flow, and priority. The specific construction process is as follows: S3021, Conditional-Action Modeling.

[0055] (1) The rule language of the rule engine is used to define the condition part of the rule trigger, and it supports nested attribute access, set operation and logical operation.

[0056] 1) Extract attributes from the corresponding fact object using pattern matching syntax.

[0057] Define the conditions for triggering rules, using the pattern matching syntax of Drools Rule Language (DRL), which supports nested attribute access, set operations, and logical operations (AND, OR, NOT).

[0058] For example, the condition of the "frequency deviation detection" sub-rule in the frequency modulation compensation rule can be defined as: This "frequency deviation detection" sub-rule is triggered when the real-time frequency deviation value of the virtual power plant object exceeds the preset frequency deviation threshold of the virtual power plant object.

[0059] 2) Perform a logical AND comparison operation on the extracted attribute values ​​to form the final trigger judgment condition.

[0060] This condition accesses and extracts the frequency deviation data of the virtual power plant through nested attributes, and uses logical operations (eval) to determine whether the rule is triggered.

[0061] (2) Use Java syntax or built-in functions of the rule engine to define the action part after the rule is triggered, and support fact updates and external system calls.

[0062] Based on the matching results, the pre-defined processing logic is executed. Specifically, a custom function is called to perform calculations, and the processing results are saved and fed back through fact updates or external calls.

[0063] S3022. Define the execution path of multiple sub-rules through rule flow, and define the execution order of rules through priority attributes.

[0064] (1) Perform branching processing on complex rule conditions.

[0065] The specific process is as follows: 1) Use nested logic to combine multiple atomic conditions and construct compound judgment logic through AND, OR, and NOT operators.

[0066] Taking the frequency modulation compensation rule in the scenario rule layer as an example, this business rule contains a large number of multi-condition branches, such as different compensation strategies corresponding to different frequency deviation ranges. Drools supports these logics through nested conditions and set operations: Nested conditions: Multiple conditions are combined using parentheses to achieve logical judgments such as "AND", "OR", and "NOT".

[0067] For example, the conditions "frequency deviation within ±0.2Hz" and "energy storage system has sufficient capacity" can be defined as: The virtual power plant object is considered to meet both conditions when its real-time frequency deviation is within the range of -0.2 Hz to +0.2 Hz (inclusive) and the available capacity of its energy storage system is greater than zero.

[0068] This condition combines the "frequency deviation range" and "energy storage capacity" conditions using a logical AND (&&) combination, ensuring that the rule is triggered only when both conditions are met.

[0069] 2) Aggregate the dataset using set functions to generate derived data indicators for conditional judgments.

[0070] Set operations: Process set data using the from keyword and set functions (such as collect, accumulate).

[0071] For example, the condition for "calculating the average output deviation of all distributed power sources" can be defined as: First, collect the output deviation values ​​of all distributed power sources in the virtual power plant object to form a list of deviation values; then, calculate the arithmetic mean of these deviation values ​​to obtain the average output deviation; finally, determine whether the average output deviation is greater than the threshold of 0.1 (i.e. 10%).

[0072] This condition uses the `collect` function to collect the output deviations of all distributed power sources and the `accumulate` function to calculate the average deviation, thus processing the aggregated data.

[0073] (2) Control the execution order of complex rules.

[0074] 1) Define the execution path of the rules through graphical or XML configuration, and organize multiple sub-rules into a rule flow.

[0075] Frequency modulation compensation services require a strict execution sequence, such as first detecting frequency deviation, then calculating the compensation coefficient, and finally feeding back the execution result. Drools achieves this requirement through rule flow and priority.

[0076] Rule flow: Define the execution path of rules through graphical or XML configuration, and organize multiple sub-rules (such as "frequency deviation detection", "compensation coefficient calculation" and "execution result feedback") into an orderly workflow.

[0077] For example, the regular flow of frequency modulation compensation can be defined as: Start -> Frequency Deviation Detection -> Compensation Coefficient Calculation -> Execution Result Feedback -> End.

[0078] 2) The execution order of the rule flow is controlled by nodes and transitions.

[0079] The rule flow controls the execution order through nodes (such as the "frequency deviation detection" node) and transitions (such as the transition from "detection passed" to the "compensation coefficient calculation" node), ensuring that the rules are executed sequentially according to the business logic.

[0080] 3) Set the rule execution priority based on the salience attribute to determine the final execution order of complex rules.

[0081] Each rule is assigned an integer priority value. The rule engine sorts all activated rules based on this value, with higher values ​​receiving higher execution priority. This ensures that critical or urgent business rules are executed first when rules are triggered concurrently.

[0082] Priority: The execution priority of the rule is defined by the salience attribute. The larger the value, the higher the priority.

[0083] For example, the priority of the "emergency frequency deviation handling" rule can be set to 1000 (higher than the 500 of ordinary rules) to ensure that this rule is executed first when the frequency deviation exceeds the emergency threshold. When the frequency deviation exceeds the emergency threshold, this rule will take precedence over other low-priority rules and immediately trigger the emergency compensation strategy.

[0084] S303. Construct a dynamic rule layer. Based on the rule execution context, use a dynamic rule decision module that integrates dynamic rule flow, decision table and enhanced condition expression to generate environmentally perceptive decision results.

[0085] The dynamic rule layer is mainly used to process rules that are highly real-time and rely on external dynamic data sources (such as second-level meteorological data, high-frequency market fluctuations, and real-time equipment status) (such as extreme weather emergency coefficient adjustment and real-time bidding strategy fine-tuning). It realizes dynamic parameter injection, real-time condition determination, and low-latency response of rules, enabling rules to have environmental awareness capabilities.

[0086] To achieve dynamic rule-based decision-making, the dynamic rule flow, decision table storage, and conditional expression capabilities are integrated to construct a dynamic rule-based decision-making module. The specific process is as follows: (1) Define business status and execution path through graphical dynamic rule flow, and support conditional branching, parallel execution, status backtracking and context passing.

[0087] Dynamic rule flow defines the execution path of rules in the form of a graphical state machine, supports conditional branching, parallel execution, state backtracking and context passing, and ensures the orderly execution of complex business logic.

[0088] For example: 1) The main process first enters the "Meteorological Event Detection" state; 2) If the wind speed exceeds the limit, the program will jump to the "Wind Power Compensation Coefficient Adjustment" branch; 3) The "Energy Storage Safety Verification" branch can be executed in parallel simultaneously; 4) Finally, summarize the results in the "Parameter Merge" state.

[0089] (2) Use decision tables to centrally manage threshold-action mapping rules with similar structures.

[0090] The decision table is used to manage a large number of rules with similar structures (such as different compensation coefficients corresponding to different wind speed ranges). Configuring thresholds and actions in tabular form facilitates maintenance by business personnel, avoids repeatedly writing rule scripts, and improves the maintainability and configuration efficiency of the rules.

[0091] (3) The rule conditions adopt an enhanced expression language to support arithmetic and logical operations, regular expression matching and custom function calls.

[0092] Conditional Expression: The "when" part in the rule uses Enhanced Expression Language (EL), which supports: arithmetic and logical operations, regular expression matching (for identifying device model or region code), and custom function calls (for example, encapsulating "SOC discharge efficiency correction" as an independent function, and the rule only needs to call this independent function to obtain the correction coefficient, realizing logic reuse and decoupling).

[0093] like Figure 1 As shown, in step S4, a rule dependency graph is constructed based on the structured rule data stream, and a graph neural network is used to detect rule conflicts to obtain the conflict detection results.

[0094] By constructing a multi-level rule dependency graph and combining dynamic weights and propagation decay mechanisms, the complex relationships between rules are described. A graph neural network (GAT + hierarchical GCN) is employed to automatically identify direct and multi-hop implicit conflicts. Through node semantic embedding optimization, multi-hop neighbor analysis, and conflict propagation path modeling, this method can not only detect typical conflicts such as time overlap, data competition, condition dead zones, and contradictory actions, but also trace the source and scope of conflict impact.

[0095] S401. Construct a rule dependency graph based on structured rule data flow.

[0096] Rule dependency graphs are the core foundation of conflict detection. Essentially, they transform discrete rules into a computable topological network. By visualizing the logical dependencies between rules, potential conflicts can be identified, such as when rule A modifies the electricity price, rule B is not updated synchronously.

[0097] The rule dependency graph is constructed in depth through three levels to ensure that it can accurately reflect the complex relationships between rules. The specific process is as follows: (1) Each rule is broken down into condition nodes and action nodes, and multi-dimensional features including type encoding, target object identifier, operator and parameter value are extracted for each node.

[0098] The first layer involves the abstraction of rule elements and the extraction of multi-dimensional features. Each business rule is broken down into atomic units, forming a machine-parseable structured description. The extraction of multi-dimensional features from condition nodes and action nodes is the first step in constructing the rule dependency graph. Specifically, this includes: 1) Decompose the condition nodes.

[0099] Condition nodes (circular identifiers) represent the prerequisites for triggering rules, such as time range (9:00-11:00), equipment status (SOC>80%), or market parameters (electricity price>0.8 yuan). The feature vector of a condition node consists of the following four parts: Type encoding: Maps condition types (time, state, parameters, etc.) to vectors of fixed dimensions; Target object hash value: The target object involved in the condition is hashed and encoded. Operator vectors: Convert operators (>, <, =, etc.) in a condition into vector representations; Threshold normalization value: Normalize the threshold value in the condition so that it is within the range of 0-1.

[0100] 2) Deconstruct the action nodes.

[0101] Action nodes (square identifiers) represent rule execution results, such as data modification (setting compensation rate = 0.85), state change (activating frequency modulation mode), or event triggering (sending alarm notifications). The feature vector of an action node consists of the following three parts: Operation type encoding: Mapping action types (data modification, state change, event triggering, etc.) to vectors; Impact object hash value: The object affected by the action is hashed; Parameter value vector: Converts the parameter values ​​in the action into a vector representation.

[0102] (2) Based on the data dependency, temporal dependency, mutual exclusion relationship and inclusion relationship between rules, a directed edge is established between nodes and the dynamic weight of the directed edge is calculated.

[0103] Dependency modeling is a crucial step in constructing a rule-based dependency graph. Four core relationships are established between nodes through directed edges: data dependency, temporal dependency, mutual exclusion, and inclusion. Unlike traditional methods, this approach introduces a dynamic weight calculation mechanism, enabling dependencies to adaptively adjust based on the actual business environment and rule execution. The specific process is as follows: 1) Based on the data dependency, temporal dependency, mutual exclusion relationship and inclusion relationship between rules, directed edges are established between nodes.

[0104] like Figure 2 As shown, dependencies are modeled, with different arrow shapes representing different dependencies, specifically including: Data dependency (solid arrow): The electricity price data output by rule A is read by rule B, indicating that rule B depends on the data output of rule A.

[0105] Temporal dependency (dashed arrow): Rule C must be executed after rule D is completed, indicating that rule C depends on rule D in time.

[0106] Mutual exclusion (wavy line): Two rules are prohibited from being activated at the same time (such as charging and discharging commands), indicating that there is a mutual exclusion constraint between the rules.

[0107] Inclusion relationship (double arrow): The promotional activity rules only take effect when the member's identity is verified, indicating that there is a conditional inclusion relationship between the rules.

[0108] 2) Calculate the dynamic weights of directed edges.

[0109] The formula for calculating the dynamic weight of a directed edge is: W(r_i) =α / C(r_i) + β·A(r_i) + γ·S(r_i); Where C(r_i) represents the execution time of rule r_i; A(r_i) represents the conflict frequency of rule r_i; S(r_i) represents the business priority of rule r_i; α, β, and γ are adjustable parameters representing the weights of the three factors.

[0110] (3) Identify multi-hop indirect dependency paths in the rule dependency graph, and calculate the weight decay of multi-hop indirect dependency paths based on the number of path hops and the preset decay coefficient.

[0111] The rule dependency graph also contains transitive dependencies, where rules A→B→C form indirect dependencies. A transitive dependency weight decay mechanism is introduced to ensure that the weight of distant dependencies decreases with distance, preventing excessively high weights for indirect dependencies. The weight decay formula is: W_{A→C}= W_{A→B}×W_{B→C}×δ^k; Where k represents the number of hops in the dependent path, such as A→B→C being 2 hops; δ is the weight decay coefficient.

[0112] S401. Use a graph neural network to perform rule conflict detection and obtain the conflict detection results.

[0113] Conflict detection based on rule dependency graphs is achieved through a three-layer analysis, utilizing neural network techniques, particularly Graph Attention Networks (GAT) and hierarchical GCN architectures, to realize multi-hop analysis of rule conflicts and identification of latent conflicts. The core significance of this technology module lies in automatically detecting direct and latent conflicts (such as conditional coverage of blank intervals) and predicting the scope of conflict impact. Inputs are the constructed rule dependency graph and historical conflict data, and outputs conflict type, propagation path, and risk score. The specific process is as follows: (1) A graph attention network is used to optimize the semantic embedding of nodes in the rule-dependent graph and to aggregate neighbor node information based on the attention mechanism.

[0114] Feature vector encoding is used to transform rule elements into digital vectors. Graph Attention Network (GAT) is then used to optimize node semantic embedding, enabling node representations to better reflect their importance and influence in the rule dependency graph. GAT allows each node to intelligently select from which neighbors to obtain information and how much information to obtain. Specifically: 1) Encode the explicit attributes and semantic information of the rules into multidimensional feature vectors.

[0115] Input node features, rule multi-dimensional feature vectors (including explicit attributes and semantic embeddings).

[0116] 2) The node features are linearly transformed to a new feature space through a fully connected layer.

[0117] Linear transformation projection projects node features into a new feature space through a fully connected layer.

[0118] 3) Calculate the attention score between a node and its neighbors using the linear rectification function and the normalization function.

[0119] The attention scores between a node and its neighbors are calculated using the LeakyReLU and softmax functions.

[0120] 4) Based on the attention score, the features of neighboring nodes are weighted and aggregated to generate an optimized node semantic embedding representation.

[0121] Neighbor information is aggregated based on attention weights to generate new node representations.

[0122] After the above steps, the system can automatically identify key dependencies between rules through GAT's attention mechanism, such as high-weight edges between mutually exclusive rules, or rule pairs with similar conditions but contradictory actions. At the same time, this optimized node semantic embedding provides a more accurate representation for subsequent conflict detection.

[0123] (2) A hierarchical graph neural network is used to aggregate neighbor features with different hop counts in different layers to capture direct conflicts and multi-hop implicit conflicts between rules.

[0124] Graph neural networks capture potential conflicts through message passing mechanisms. A hierarchical graph neural network (GNN architecture) was designed, consisting of three layers: a basic feature aggregation layer, a second-order dependency and relationship analysis layer, and a higher-order attention layer. By aggregating neighbor features with different hop counts at different layer levels, multi-hop analysis of rule conflicts is achieved. The specific process is as follows: 1) Identify explicit dependencies by aggregating the direct neighbor features of nodes in the basic feature aggregation layer.

[0125] Layer 1 (Basic Feature Aggregation Layer): Aggregates explicit attributes and semantic vectors of direct neighbors (1 hop).

[0126] 2) Through the second-order dependency and relationship analysis layer, the features of two-hop neighbors are aggregated, and the inclusion, intersection and separation relationships between rules are combined to perform preliminary conflict detection.

[0127] Layer 2 (Second-order Dependency and Relationship Analysis Layer): The second-order dependency and relationship analysis layer uses a graph convolutional network (GCN) to capture 2-hop dependencies and combines rules of inclusion / intersection / disjunction for conflict detection.

[0128] 3) By using a higher-order attention layer, select and analyze the features of distant neighbors with three or more hops to identify indirect latent conflicts in long-distance dependent paths.

[0129] Layer 3 (Higher-order attention layer): Introduces the attention mechanism of Graph Attention Network (GAT) to focus on long-distance dependencies with high conflict risk, such as 3-hop paths.

[0130] Through the above steps and a multi-layered GNN architecture, the system can capture both direct and indirect implicit conflicts between rules. For example, rule A modifies the electricity price → rule B reads the electricity price to calculate subsidies → rule C triggers activities based on subsidies. When A and C are not directly connected but there is a transmission contradiction, the system can identify this implicit conflict through multi-hop analysis.

[0131] (3) Based on the message passing mechanism, track the transmission path of the conflict in the rule dependency graph, that is, construct the conflict propagation path and calculate the conflict risk score of the conflict propagation path.

[0132] A conflict propagation path modeling technique is introduced, and the propagation process of conflict in the rule dependency graph is tracked by defining a path weight calculation method and a message passing mechanism.

[0133] Based on the message passing mechanism, the propagation path of conflicts in the rule dependency graph is traced, that is, the conflict propagation path is constructed. The specific process is as follows: 1) Based on the weights of the edges in the rule-dependent graph, the intensity quantization value of the conflict propagation along a specific multi-hop path is calculated by using a multiplication or attention weight aggregation method.

[0134] Path weight calculation quantifies the intensity of conflict propagation based on the product of edge weights or attention mechanisms.

[0135] 2) Utilize the message passing mechanism of graph neural networks to propagate along dependency edges and track conflict propagation paths.

[0136] The message passing mechanism utilizes the message passing mechanism of a graph neural network (GNN) (UPDATE and AGGREGATE functions) to track contradictory paths.

[0137] 3) Multiply or sum the weights of all nodes along the conflict propagation path to generate the final risk quantification score of the conflict propagation path.

[0138] The conflict scoring mechanism calculates the product or weighted sum of the rule weights on the path to quantify the conflict risk and obtain the final risk quantification score of the conflict propagation path, as shown in Table 1.

[0139] Table 1. Classification of common conflict types detected by graph neural network conflict detection. Conflict Types Feature description Detection Algorithm Time window overlap Rules for seizing the same time slot Interval tree cross scan Data competition Reverse operation on the same data source Read / write dependency path analysis conditional dead zone Conditional coverage has blank intervals Range continuity detection Contradictory Actions Triggering mutual exclusion actions under the same conditions Action result difference comparison The conflict detection results include conflict type, propagation path, and risk score.

[0140] After the above steps, by modeling the conflict propagation path, the system can identify the source and transmission path of the conflict. For example, the contradiction in the transmission of rule A→B→C can be identified by accumulating the attention weights on the path. It not only supports the detection of the existence of conflict, but also analyzes the propagation mechanism and scope of impact of conflict, providing an important basis for subsequent conflict resolution.

[0141] like Figure 1 As shown, in step S5, based on the conflict detection results, the three-layer rule engine is embedded into the multi-source data stream, the three-layer rule engine is called, and a decision result is generated; The adjusted settlement rules are obtained by adopting a state synchronization mechanism and through collaborative distributed computing.

[0142] The collaborative computing approach of stream computing and rule engine is the core technical architecture for realizing real-time data-driven intelligent decision-making. Through the deep coupling of the stream processing framework and the rule reasoning engine, dynamic decision-making capabilities are embedded in the data flow process.

[0143] S501. Based on the conflict detection results, the three-layer rule engine is embedded into the multi-source data stream, and the three-layer rule engine is called to generate decision results.

[0144] A bidirectional interactive topology architecture of data flow and rule engine is adopted, embedding decision points in the data flow process of various settlement entities. A three-layer rule engine is invoked to achieve real-time rule decision-making, further improving the handling of large-scale real-time rule processing problems. Multi-source data and the output of the three-layer rule engine are input to the flow-rule collaboration module to obtain decision events that trigger the rule engine, such as allow / intercept / correction instructions. The rule engine is embedded in the data flow to achieve atomic execution where the decision is made based on the data flow. The specific process is as follows: (1) Embed the three-layer rule engine into the multi-source data stream and construct the topology structure of embedded decision points in the stream.

[0145] A topology structure is constructed that includes a data stream input end, a rule engine operator, a state storage backend, and a data stream output end. The topology structure with decision points embedded in the stream adopts a closed-loop design of data stream → rule engine operator → state backend → data stream.

[0146] Among them, the data stream inlet, streaming data (such as real-time transactions, device status, and weather data) is accessed by Flink through message queues such as Kafka and RocketMQ.

[0147] The rule engine operator, Flink's custom RuleCheckFunction (UDF), serves as the rule execution node, responsible for converting streaming data into fact objects for the rule engine and calling the rule engine for matching.

[0148] The state backend of Flink (such as RocksDB) stores the state of rule matching (such as facts and rule trigger records in KieSession) and supports checkpoint fault tolerance. Data flow exits, and rule execution results (such as decision instructions and abnormal events) are fed back to downstream systems (such as trading systems and risk control systems) through message queues.

[0149] (2) The multi-source data stream is converted into rule fact objects through the rule engine operator, which drives the rule engine to complete matching and execution.

[0150] RuleCheckFunction is the core operator for embedding decision points in a stream. It is a Flink user-defined function used to encapsulate Drools rule service calls.

[0151] 1) Convert multi-source data into fact objects.

[0152] When streaming data passes through RuleCheckFunction, the data (such as transaction amount, device ID) is converted into Drools fact objects (such as TransactionFact, DeviceFact), which contain the attributes required by the rule (such as amount, deviceId, timestamp).

[0153] 2) Insert real-time objects into working memory.

[0154] The KieSession, the workbench of the rule execution engine of the open-source business rule management system (Drools) using fact objects, will be inserted into the working memory to trigger the matching process of the rule engine.

[0155] 3) The rule engine is driven to complete matching and execution.

[0156] Drools' Rete algorithm performs pattern matching on facts in its working memory and executes rules that meet certain conditions, such as triggering risk control if the transaction amount exceeds a threshold.

[0157] (3) Write the rule execution result back to the status backend and output it as a decision event stream to the downstream business system.

[0158] The results of rule execution (such as intercepted transactions) are written back to the Flink state backend via the KieSession insert method, supporting subsequent checkpoint fault tolerance and state recovery.

[0159] This involves inserting a fact into the working memory of the rule engine so that it can be matched and used later by rule conditions (LHS, i.e., the "when" part). Flink periodically takes snapshots of the global state of the entire stream processing job. Its main purpose is to automatically recover the job from the most recent successful checkpoint in the event of a failure (such as machine crash, network interruption, or program exception), thereby ensuring the consistency of the data processing state.

[0160] S502. A state synchronization mechanism is adopted, and the adjusted settlement rules are obtained through collaborative distributed computing.

[0161] S5021. Construct a three-level synchronization mechanism to obtain the consistency rule state and load balancing sharding strategy.

[0162] In a distributed stream computing environment, the state of the rule engine needs to remain consistent across multiple computing nodes. The system employs a three-level synchronization mechanism: "rule state broadcasting - local caching - version verification." When the rule management module detects a rule change, it distributes the rule update event to all computing nodes via Flink broadcast stream. Each node maintains a local copy of the rule state and verifies state consistency through a version vector mechanism. When a version conflict is detected, a conflict resolution protocol based on a logical clock is triggered to ensure that all nodes eventually converge to the same rule state. The system takes rule change events and distributed node states as inputs and outputs a consistent rule state and a load-balanced sharding strategy.

[0163] To address potential rule version inconsistencies in multi-node parallel processing, a three-level synchronization mechanism—rule state broadcasting, local caching, and version verification—was designed to ensure efficient and reliable state consistency across all computing nodes after rule changes. The specific process of distributed synchronization of the rule engine state is as follows: (1) When a rule update is detected, the event containing the complete rule content and metadata is distributed to all computing nodes in real time through the broadcast stream of the stream processing framework.

[0164] When the rule management module detects an update to a rule definition (such as adding, modifying, or disabling a frequency modulation compensation rule), the system generates a rule update event containing the complete new rule content and its metadata (such as rule ID, change type, and timestamp). This event is then distributed in real-time to all running compute task instances via Apache Flink's broadcast stream. The broadcast stream mechanism ensures that the update event is delivered to every parallel subtask without omission, preventing some nodes from missing change notifications due to partitioning strategies.

[0165] (2) Each node temporarily stores the received update events in its local cache and performs consistency verification.

[0166] Each compute node maintains a local cached copy of the rule state to support high-speed matching and inference by rule engines such as Drools. This cache not only improves rule query performance but also serves as a temporary state basis during fault recovery. When a node receives a broadcast update event, it does not immediately overwrite the current rule set but first stores it temporarily and initiates a consistency verification process.

[0167] (3) The version vector mechanism is used to compare the local and global rule versions and perform hot replacement on the lagging version; based on the logical clock protocol, the authoritative version is selected for the detected conflict and forced to synchronize, so as to achieve consistency of rule status across all nodes.

[0168] A version vector mechanism is introduced to track rule states in a fine-grained manner. Each rule is associated with a globally unique version identifier, and each node maintains a vector reflecting the versions of the rule set it currently holds. Before processing each business event, a node compares the time sequence of its local rule version with the latest broadcast version. If a local version lags behind, atomic rule hot replacement is triggered; if a version conflict is detected (e.g., different nodes receiving updates in different orders due to network partitioning), the system will initiate a conflict resolution protocol based on the Lamport logical clock: by comparing the timestamps and causal dependencies of events, the rule version with higher logical time or stronger business priority is automatically selected as the authoritative version, and the entire cluster is forced to synchronize, thereby ensuring eventual consistency.

[0169] Through the above three-level mechanism, while maintaining high throughput processing capabilities, strong consistency and rapid convergence of rule states in a distributed environment are achieved, effectively supporting the dual stringent requirements of rule accuracy and timeliness in the settlement scenarios of new market entities.

[0170] S5022. The adjusted settlement rules are obtained through collaborative distributed computing.

[0171] To efficiently support the real-time execution of differentiated settlement rules for multiple market participants in large-scale streaming scenarios, a distributed stream-rule collaborative computing model was constructed. This model is a fusion algorithm of distributed streams and collaborative computing, deeply integrating data sharding strategies with the execution model to achieve dynamic alignment of computing resources, rule logic, and data flow. The specific process is as follows: (1) Construct a rule-driven dynamic sharding mechanism.

[0172] A rule dependency graph is constructed based on rule condition analysis, strongly dependent rule groups are identified and mapped to the same computation shard, and load-aware dynamic sharding adjustment and state affinity optimization are implemented. The specific process is as follows: 1) Construct a dependency graph based on rule condition analysis, and map rule sets with strong data dependencies to the same computational partition.

[0173] A rule-driven dynamic data sharding mechanism. Unlike traditional static hash sharding based on fixed keys, this system first analyzes the data fields referenced in the rule antecedents (i.e., the "when" condition), such as user ID, region code, device type, and time window, to construct a directed graph of rule dependencies. This identifies sets of rules with strong data dependencies—that is, rule groups that need to access the same state context (such as a user's cumulative electricity consumption or a region's real-time electricity price). These rules are explicitly mapped to the same computation shard, ensuring that related rules can be matched locally, avoiding latency and consistency risks associated with cross-node communication.

[0174] 2) Monitor sharded load and trigger dynamic migration to achieve load balancing.

[0175] The system introduces load-aware dynamic adjustment capabilities, continuously monitoring the rule matching frequency, CPU usage, and processing latency of each shard. Once load imbalance is detected (such as a shard being overloaded due to a concentration of highly active users), a shard migration algorithm based on consistent hashing is triggered to rebalance the mapping relationship between rules and computing resources while minimizing the scope of data redistribution.

[0176] 3) Perform state affinity routing optimization on state-dense rules.

[0177] For rules involving historical state accumulation (such as tiered electricity consumption calculation under time-of-use pricing), the system implements state affinity optimization, intelligently routing associated data streams to computing nodes that already hold the corresponding states, avoiding the network overhead of remote state retrieval, and significantly improving the execution efficiency of state-intensive rules.

[0178] (2) Adopt a dual-mode collaborative execution of data-driven and rule-driven approaches.

[0179] A collaborative computing model that integrates data-driven and rule-driven modes is adopted.

[0180] 1) In the data-driven mode, micro-batch processing is used to convert streaming events into fact objects in batches and trigger rule matching.

[0181] In data-driven mode, when business events flow through stream processing operators, the system encapsulates them as fact objects and injects them into the working memory of the rule engine, triggering rule matching checkpoints. Considering the high computational overhead of rule inference, the system adopts a micro-batch processing strategy, aggregating multiple events within a short time window and submitting them to the rule engine in batches. This fully leverages the shared matching advantages of its internal RETE network, significantly improving throughput.

[0182] 2) In the rule-driven mode, based on the pre-built rule-data index, the data subset affected by rule changes is incrementally re-evaluated.

[0183] In rule-driven mode, when the rule management module changes, such as adding compensation rules or adjusting threshold parameters, the system no longer passively waits for new data to arrive, but actively triggers incremental reassessment. Through a pre-built rule-data index (which records which data streams have activated specific rules in history), the system accurately locates the affected data subset and notifies the relevant shards to re-execute rule matching, thereby achieving partial effectiveness of rule updates and avoiding costly full data backtracking and recalculation.

[0184] (3) Within each computing partition, the incoming data is matched and reasoned with the set of rules it maps to, and real-time decision-making is completed.

[0185] The two modes are coordinated through a unified event bus, which incorporates data stream events and rule change events into the same ordered event stream for processing. With the help of Flink's event time semantics and checkpoint mechanism, the causal order of rule update first and data processing second is strictly guaranteed.

[0186] Taking the scenario of aggregating distributed power sources, energy storage, and flexible load resources through a virtual power plant as an example, the electricity settlement rules are automatically adjusted according to steps S1 to S5.

[0187] (1) Layered construction of the rule engine.

[0188] 1) Construct a basic rules layer and establish a structured storage system that includes at least an electricity price rules table and an equipment parameter table.

[0189] Static rules such as electricity pricing time periods and energy storage SOC thresholds are defined using XML Schema Definition (XSD). Taking one electricity pricing time period rule as an example: The rules define the triggering conditions as the time period being between 9:00 AM and 12:00 PM and the applicable area being the Eastern Power Grid. The execution action is to set the electricity price to 0.65 yuan / kWh. After completing the XSD definition, JAXB technology is used to automatically generate corresponding Java classes from the XML rule files that conform to this structure, realizing bidirectional conversion between XML and Java objects. Finally, these Java objects are persistently stored in a MySQL relational database, thereby establishing structured data tables, such as electricity price rule tables and equipment parameter tables, providing a unified and reliable data source for upper-level rule applications.

[0190] 2) Constructing the scene rule layer Rule engine configuration: Configure the frequency modulation compensation strategy in Drools, for example: Conditional matching: Compensation is triggered when the virtual power plant frequency deviation is >0.2Hz and the energy storage SOC is >20%; Action execution: Calculate the compensation coefficient and update the virtual power plant control instructions; Rule-based flow design: Series frequency detection → Compensation calculation → Command issuance process, ensuring execution order.

[0191] 3) Construct a dynamic rule layer.

[0192] Streaming data access: Real-time streaming of meteorological data (wind speed, temperature), equipment telemetry (output, SOC), etc., is accessed via Flink; Feature engineering: Constructing indicators such as strong wind event index (10-minute moving average wind speed × turbine capacity) and frequency regulation urgency (frequency deviation × load demand); Dynamic decision-making: EL expressions are used to implement rule conditions, for example: The final value of the compensation coefficient is jointly determined by the base rate, the wind power factor, and the energy storage SOC penalty factor. The calculation formula is: "Compensation coefficient = Base rate × (1 + Wind power factor) × (1 - SOC penalty factor)". The wind power factor is obtained by querying a pre-configured decision table based on real-time wind speed data; while the SOC penalty factor is dynamically calculated based on the real-time state of charge of the energy storage system.

[0193] (2) Conflict detection based on rule dependency graph.

[0194] 1) Construction of rule dependency graph.

[0195] Node characteristics: Electricity price rule nodes include time period and price gradient attributes, while compensation rule nodes are associated with triggering conditions and action types; Dependencies: Establishing data dependencies on electricity prices → compensation coefficients, and time-series dependencies on compensation → energy storage control; Weighting calculation: High-priority rules (such as emergency frequency regulation) are weighted at 0.9, and low-priority rules (such as regular electricity price adjustments) are weighted at 0.5.

[0196] 2) Conflict detection.

[0197] Scenario: Wind power compensation and energy storage SOC protection rules are triggered simultaneously during a certain period; Testing process: Direct conflict identification: The GAT model discovered a contradiction between two rule actions (charging and discharging); Propagation path analysis: Tracing back to the "frequency deviation" nodes that are commonly relied upon to identify the source of the conflict; Priority arbitration: Select the energy storage protection strategy to be implemented based on the rule weight (energy storage protection 0.9 > wind power compensation 0.7); (3) Stream computing and rule engine work together.

[0198] 1) Decision point embedding architecture Data flow topology: After real-time processing by Flink, the data triggers decision nodes in the rule engine. For example: Meteorological data → Flink cleaning → Rule engine (compensation decision) → Results fed back to energy storage control system.

[0199] Synchronous dispatch: Emergency adjustments to electricity prices are submitted in two stages to ensure that compensation instructions are consistent with market clearing results; Asynchronous calls: Device status monitoring uses batch processing, decoupling high-throughput scenarios through Kafka.

[0200] 2) Fault tolerance and state synchronization Checkpoint mechanism: Saves the rule engine state (such as KieSession snapshot) every 5 minutes, and restores from the most recent checkpoint in case of failure; Distributed locks: Redis distributed locks are used for shared rules (such as network-wide frequency thresholds) to avoid concurrent conflicts among multiple nodes.

[0201] Example 2 This embodiment discloses an automatic adjustment system for electricity settlement rules for new market participants, including: The data acquisition module is used to acquire multi-source data, which includes at least meteorological data, electricity market data, and equipment telemetry data. The data processing module is used to perform stream processing on multi-source data, extract business features, and generate rule execution contexts; The layered rule engine module is used to build a three-layer rule engine that includes basic, scenario, and dynamic rules to obtain a structured rule data stream; Based on structured rule data flow, a rule dependency graph is constructed, and a graph neural network is used to detect rule conflicts to obtain conflict detection results; The rule-based collaborative computation module is used to embed the three-layer rule engine into a multi-source data stream based on conflict detection results, call the three-layer rule engine, and generate decision results. The adjusted settlement rules are obtained by adopting a state synchronization mechanism and through collaborative distributed computing.

[0202] The method steps in Example 1 are implemented by providing an automatic adjustment system for electricity settlement rules oriented towards new market entities.

[0203] Those skilled in the art will understand that the modules or steps of the present invention described above can be implemented using general-purpose computer devices. Optionally, they can be implemented using computer-executable program code, thereby allowing them to be stored in a storage device for execution by a computer device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. The present invention is not limited to any particular combination of hardware and software.

[0204] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.< / action> < / condition> < / rule>

Claims

1. A method for automatically adjusting electricity settlement rules for new market entities, characterized in that, include: Acquire multi-source data, which includes at least meteorological data, electricity market data, and equipment telemetry data; Perform stream processing on multi-source data, extract business features, and generate rule execution context; A three-layer rule engine, comprising basic, scenario-based, and dynamic elements, is constructed to obtain a structured rule data stream; Based on structured rule data flow, a rule dependency graph is constructed, and a graph neural network is used to detect rule conflicts to obtain conflict detection results; Based on the conflict detection results, a three-layer rule engine is embedded into the multi-source data stream, and the three-layer rule engine is called to generate decision results; The adjusted settlement rules are obtained by adopting a state synchronization mechanism and through collaborative distributed computing.

2. The method for automatically adjusting electricity settlement rules for new market entities as described in claim 1, characterized in that, The process involves stream processing of multi-source data to extract business features and generate rule execution contexts. The multi-source data is cleaned and standardized to obtain standardized multi-source data. Feature extraction is performed on multi-source data to obtain business features; The standardized multi-source data and business characteristics constitute the rule execution context.

3. The method for automatically adjusting electricity settlement rules for new market entities as described in claim 1, characterized in that, A three-layer rule engine, comprising basic, scenario-based, and dynamic elements, is constructed to obtain a structured rule data stream. The specific process is as follows: A basic rule layer is constructed, based on XSD, JAXB, and relational database triplet schema, to define, transform, and store static and atomic rules in a strongly typed manner; Construct a scenario rule layer, and based on the rule engine, perform condition-action modeling and execution order control on complex combined business logic; A dynamic rule layer is constructed, which generates environment-aware decision results based on the rule execution context and by utilizing a dynamic rule decision module that integrates dynamic rule flow, decision table and enhanced conditional expression.

4. The method for automatically adjusting electricity settlement rules for new market entities as described in claim 3, characterized in that, Based on a rule engine, condition-action modeling and execution sequence control are performed on complex combined business logic. The specific process is as follows: The rule language of the rule engine defines the conditions for triggering rules, and supports nested attribute access, set operations, and logical operations; The action part after a rule is triggered can be defined using Java syntax or built-in functions of the rule engine, supporting fact updates and external system calls; The execution path of multiple sub-rules is defined by the rule flow, and the execution order of the rules is defined by the priority attribute.

5. The method for automatically adjusting electricity settlement rules for new market entities as described in claim 3, characterized in that, Based on the rule execution context, a dynamic rule decision module that integrates dynamic rule flow, decision table, and enhanced conditional expression is used to generate environment-aware decision results. The specific process is as follows: Define business states and execution paths through a graphical dynamic rule flow, supporting conditional branching, parallel execution, state backtracking, and context passing; Utilize decision tables to centrally manage threshold-action mapping rules with similar structures; The rules and conditions employ an enhanced expression language that supports arithmetic and logical operations, regular expression matching, and user-defined function calls.

6. The method for automatically adjusting electricity settlement rules for new market entities as described in claim 1, characterized in that, Based on structured rule-based data flow, a rule dependency graph is constructed. The specific process is as follows: Each rule is broken down into condition nodes and action nodes, and multi-dimensional features, including type encoding, target object identifier, operator and parameter values, are extracted for each node. Based on the data dependency, temporal dependency, mutual exclusion and inclusion relationships between rules, directed edges are established between nodes, and the dynamic weights of the directed edges are calculated. In the rule dependency graph, identify multi-hop indirect dependency paths and calculate the weight decay of multi-hop indirect dependency paths based on the number of hops and a preset decay coefficient.

7. The method for automatically adjusting electricity settlement rules for new market entities as described in claim 1, characterized in that, The process of using a graph neural network to detect rule conflicts and obtain the conflict detection results is as follows: A graph attention network is used to optimize the semantic embedding of nodes in the rule dependency graph, and neighbor node information is aggregated based on the attention mechanism. A hierarchical graph neural network is used to aggregate neighbor features with different hop counts at different layers to capture direct conflicts and multi-hop implicit conflicts between rules. The message passing mechanism is used to track the propagation path of conflicts in the rule dependency graph, and the conflict risk score is calculated based on the path weight.

8. The method for automatically adjusting electricity settlement rules for new market entities as described in claim 7, characterized in that, A hierarchical graph neural network is employed, aggregating neighbor features with different hop counts across different layers to capture direct and multi-hop implicit conflicts between rules. The graph neural network comprises three layers: a basic feature aggregation layer, a second-order dependency and relationship analysis layer, and a higher-order attention layer. The specific process is as follows: Explicit dependencies are identified by aggregating the direct neighbor features of nodes through the basic feature aggregation layer. By using a second-order dependency and relationship analysis layer, two-hop neighbor features are aggregated, and preliminary conflict detection is performed by combining the inclusion, intersection, and disjoint relationships between rules. By using a higher-order attention layer, we select and analyze the features of distant neighbors with three or more hops to identify indirect implicit conflicts in long-distance dependent paths.

9. The method for automatically adjusting electricity settlement rules for new market entities as described in claim 1, characterized in that, The adjusted settlement rules are obtained through collaborative distributed computing. The specific process is as follows: Based on rule condition analysis, a rule dependency graph is constructed to identify groups of strongly dependent rules and map them to the same computing shard. At the same time, load-aware dynamic sharding adjustment and state affinity optimization are implemented. It employs a dual-mode approach, combining data-driven and rule-driven execution. Within each computing shard, the incoming data is matched and inferred according to the set of rules it is mapped to, and real-time decision-making is completed.

10. An automatic adjustment system for electricity settlement rules for new market entities, characterized in that: include: The data acquisition module is used to acquire multi-source data, which includes at least meteorological data, electricity market data, and equipment telemetry data. The data processing module is used to perform stream processing on multi-source data, extract business features, and generate rule execution contexts; The layered rule engine module is used to build a three-layer rule engine that includes basic, scenario, and dynamic rules to obtain a structured rule data stream. Based on the structured rule data stream, a rule dependency graph is constructed, and a graph neural network is used to detect rule conflicts to obtain conflict detection results. The rule-based collaborative computation module is used to embed the three-layer rule engine into a multi-source data stream based on the conflict detection results, call the three-layer rule engine, and generate decision results; it adopts a state synchronization mechanism and obtains the adjusted settlement rules through collaborative distributed computation.

Images