Power grid power failure fault real-time study and judgment analysis method based on business decoupling

Abstract

The invention discloses a power grid power failure fault real-time study and judgment analysis method based on service decoupling. According to the method, through an event-driven architecture and a signal state model, service logic and data processing are separated, modular extension is supported, and service decoupling and multiplexing are achieved. According to the method, multi-level signals are dynamically fitted, an event compensation mechanism is combined, the fault positioning speed and precision are improved, and real-time performance and accuracy are achieved. The method is based on distributed execution arrangement, concurrent access and real-time analysis of mass monitoring data are effectively processed, and high concurrency is supported. According to the method, the design of the multi-layer signal state model and the strategy expansion points flexibly adapts to the level change of the power grid equipment and the newly added monitoring requirements, and adapts to the complex topology. According to the method, through the rule engine and visual definition, the development difficulty is reduced, and research and transportation integration is achieved. According to the method, repeated research and judgment logic is eliminated, manual intervention is reduced, the automation level of power grid fault processing is improved, and the operation and maintenance cost is reduced.

Description

Technical Field

[0001] This invention belongs to the field of software engineering technology, and in particular relates to a real-time analysis and judgment method for power grid outage faults based on business decoupling. Background Technology

[0002] Since its inception, software development has undergone a series of methodological evolutions in software design and development, driven by advancements in computer hardware and software technology. For example... Figure 2 As shown, their evolution from low to high stages includes: process-oriented, object-oriented, service-oriented, domain-oriented, and artificial intelligence-oriented or natural language-oriented.

[0003] In practice, many "domain-oriented" development methodologies, which lie above services, have existed in various industries for a long time. These method employs a platform approach, defining a set of rules or providing a development model. Developers follow this theory or approach to develop information systems, and the platform translates the developed content according to the established rules to achieve system construction. A typical application of domain-oriented development methods is ERP systems (Enterprise Resource Planning).

[0004] In domain-oriented development methodologies, business processes largely employ model aggregation and business orchestration to abstract various activities and their relationships. Each activity node can run independently. Compared to artificial intelligence, this approach features coarse-grained models with explicitly defined parameters, guiding business operations. In contrast, artificial intelligence neural networks have fine-grained nodes with parameters generated through autonomous learning, lacking explicit business guidance. With the development of microservices and distributed architectures, design theories in this area have also evolved. For example, Alibaba's Domain-Driven Design (DDD) and Alistair Cockburn's Hexagonal Architecture are both built on a platform, using interface adaptation to achieve interaction and isolation between platform and non-platform business logic development.

[0005] Domain-oriented development methods are built on well-defined rules and a rule engine. Without a "platform" engine, it is as impossible as artificial intelligence having knowledge but no model or algorithm. Compared to the black box of computational behavior in the professional field of artificial intelligence, domain-oriented technology is more suitable for decoupling complex business scenarios. However, the decoupling unit granularity is coarse and observable, so the business can be decomposed and has a set of design methods.

[0006] Event-driven architecture is an effective way to solve domain-oriented development problems in large-scale distributed systems. Through event-driven message publishing and subscription patterns, the collaborative relationship between the application and the platform can be effectively decoupled. This decouples the relationships between the platform's interaction model and the collaborative relationships between the platform configuration and the business data processing message subscriber teams. In real-world information systems, whether operating systems, monolithic applications, or large-scale enterprise-level distributed applications, the use of asynchronous events is essential.

[0007] "Event streaming" technology is an application of event-driven technology architecture, such as... Figure 3 As shown, event flow essentially defines configurable activity nodes. Through message subscription and publishing, these nodes are connected, allowing enterprise events to propagate in a mesh structure. Information flow between nodes is routed according to predetermined rules (strategies), and the nodes themselves perform logical calculations. These nodes, the commands they can receive, the conditions for event publishing, and the strategies all require rule definition. Therefore, the core of "event flow" technology is model definition for business needs; it is also a business orchestration technology.

[0008] Furthermore, when applying "event stream" technology, firstly, the system should distinguish the types of activity nodes connected by events. One type of activity node can be defined and configured by the platform, while another type requires external developers to embed it, ultimately achieving serial and parallel connections through "event stream." Secondly, the system should differentiate between the types of activity node orchestration it targets, including business orchestration and execution orchestration. Business orchestration can solve the definition and reuse of business processes, while execution orchestration can ensure the execution order of distributed computing.

[0009] Currently, the design methods used in software information system development are relatively limited, with most employing intuitive design approaches such as prototyping and business process analysis. Other methods, such as ERP project implementation, may focus more on business modeling. However, there is still no clear design approach for applications involving massive data access and real-time analysis, such as power grid equipment outage fault diagnosis.

[0010] In power grid outage fault assessment, the topology scope extends from substation outgoing lines to low-voltage distribution area user meter boxes. This topology includes multiple physical and virtual devices such as outgoing switches, medium-voltage lines, cable sections, branch switches, distribution transformers, low-voltage lines, distribution areas, and meter boxes. Various measuring devices are connected to different devices to monitor the status of power grid equipment and switch opening / closing states. A schematic diagram of the entire power grid and terminal monitoring data can be found here. Figure 4 Based on the signal analysis of the main grid substation side (such as...) Figure 5 (as shown) and TTU assessment (as shown) Figure 6Taking the example shown, the monitoring results of different levels of equipment in the power grid are analyzed according to user needs. Due to the nonlinearity of the time series, the analysis process is inevitably very complex. If not handled properly, the analysis of line, transformer, and meter box faults will become chaotic. From the two original analysis diagrams ( Figure 5 and Figure 6 It can be found that there are a lot of repetitive judgment logic processes. If such independent judgment is used for the signals of all device terminal acquisition devices, it is obviously impossible to meet the fitting of signals and the status of the same type of devices at the same time, and performance and scalability cannot be guaranteed. Summary of the Invention

[0011] To address the problems existing in the prior art, this invention proposes a real-time analysis and judgment method for power grid outage faults based on business decoupling.

[0012] The technical solution of the present invention is as follows:

[0013] A real-time analysis method for power grid outage faults based on business decoupling includes the following steps:

[0014] Step 1) Based on the business models of equipment at each level from the outgoing line side to the user side in the power grid under analysis, fuse the monitoring signal data and generalize to extract multi-level signal state models; the attributes of the signal state model include at least the unique identifier of the equipment and each state attribute;

[0015] Step 2) Based on the attributes of the signal state model, extract the command model for each level as input to the signal state model;

[0016] Step 3) Based on the attributes of the signal state model, analyze the signal state change factor, define the conditions for the signal state model attribute changes to trigger the model to publish events, and extract the event model as the output of the signal state model.

[0017] Step 4) Associate the inputs and outputs of the upper and lower level signal state models to complete the mapping between the event model and the command model;

[0018] Step 5) Design the execution unit and subscribe to the signal state model published events, and schedule the execution unit to perform fault judgment logic processing.

[0019] Further, the monitoring signal data mentioned in step 1) includes monitoring signal data generated by all power grid monitoring devices in a one-time analysis, including status signal data of main grid event processing, bus grounding, feeder automation (FA), branch switches, user acquisition area smart terminal fusion equipment (TTU), user acquisition terminal, fusion terminal, secondary acquisition, and high-speed broadband carrier smart meter (hplc) household meter; the devices collected in a one-time analysis include: medium-voltage lines, distribution transformers, low-voltage lines, circuit breakers, and meter box de-energization equipment.

[0020] Furthermore, the signal state model described in step 1) includes at least a terminal measurement device layer, a power grid device layer, and a topology detail layer.

[0021] Furthermore, the event triggering conditions in step 3) include idempotent conditions for signal filtering and non-idempotent conditions for signal transmission.

[0022] Furthermore, in step 3), the inputs and outputs of the upper and lower level signal state models are associated by direct mapping or indirectly by strategy extension points. The strategy extension points are embedded by external programs to bridge the event model and the command model.

[0023] Furthermore, in step 4), the inputs and outputs of the upper and lower level signal state models are correlated, specifically including:

[0024] If the event model parameters output by the upper-level signal state model match the command model parameters input by the lower-level signal state model, then the event model parameters are directly mapped to command model parameters.

[0025] If the parameters do not match or need to be converted by business logic, external business logic is accessed through the strategy extension point to convert the event model parameters and map them to command model parameters.

[0026] Furthermore, when using the aforementioned strategy to extend the points for association, the system specifically analyzes the power grid topology to find the next-level devices that have a corresponding association with the previous-level devices, thereby enabling the transfer and conversion of signal state parameters between the upper and lower level signal state models.

[0027] Furthermore, the method also includes designing the orchestration process of the execution unit, controlling the fault judgment logic sequence of the execution unit through a judgment process from the bottom level to the top level, and realizing fault point location.

[0028] Furthermore, the orchestration process includes a start point, an end point, a compensation point, and semaphore control elements to support the timing management of distributed transactions.

[0029] Furthermore, the orchestration process also includes an event compensation mechanism, which triggers secondary analysis by setting a signal waiting threshold to ensure the accuracy of fault location.

[0030] Compared with the prior art, the present invention has the following beneficial effects:

[0031] The real-time analysis method for power grid outage faults based on business decoupling provided by this invention addresses complex business scenarios such as power grid outage fault analysis, which involve complex business logic, multiple routing branch judgments, large data concurrency, repetitive analysis of multiple signals, and poor scalability (e.g.) Figure 5and Figure 6 This can simplify and establish a standard definition for the derivation process. Figure 8 For key operating equipment such as medium and low voltage lines and transformers, a comprehensive analysis is conducted based on various signals to ultimately form a complete power grid topology outage fault analysis process. For detailed analysis examples, please refer to the implementation examples.

[0032] This invention relates to a domain-oriented business decoupling design approach. Through design, the results can be directly transformed into rule definitions and executed via an event flow rule engine, achieving integrated research and development. The design outcome using this invention decouples and associates various elements, thus allowing for online definition via visualization, enabling low-code backend services.

[0033] The method of this invention involves software technologies such as event-driven framework, event flow technology, and domain-driven design (DDD) to realize business analysis for power grid outage fault judgment. It has the characteristics of massive data access concurrency, decoupling of business logic, reusable components, and scalable business modules.

[0034] This invention's method separates business logic from data processing through an event-driven architecture and signal state model, supporting modular expansion and achieving business decoupling and reuse. By dynamically fitting multi-level signals and combining an event compensation mechanism, this method improves the speed and accuracy of fault location, exhibiting real-time performance and precision. Based on distributed execution orchestration, this method effectively handles concurrent access and real-time analysis of massive monitoring data, supporting high concurrency. The multi-level signal state model and strategy extension point design in this method flexibly adapt to changes in power grid equipment levels and new monitoring requirements, accommodating complex topologies. Through a rule engine and visual definition, this method reduces development difficulty and achieves integrated research and operation. This method eliminates repetitive judgment logic, reduces manual intervention, improves the automation level of power grid fault handling, and reduces operation and maintenance costs. Attached Figure Description

[0035] Figure 1 This is a flowchart illustrating a real-time analysis and judgment method for power grid outage faults based on business decoupling.

[0036] Figure 2 A schematic diagram illustrating the evolution of software development methodologies and the development methods used in this invention;

[0037] Figure 3 This is a schematic diagram of the event stream technology architecture;

[0038] Figure 4 A schematic diagram of the power grid equipment topology and data collection by monitoring devices;

[0039] Figure 5 Original logic diagram for signal analysis and judgment on the main grid substation side;

[0040] Figure 6 The original logic diagram for TTU signal analysis;

[0041] Figure 7 This is a diagram illustrating the orchestration process.

[0042] Figure 8 Design diagrams for signal state models and aggregation relationships;

[0043] Figure 9 This is a schematic diagram of a signal state model. Detailed Implementation

[0044] The present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. After reading this invention, any modifications of the invention in various equivalent forms by those skilled in the art will fall within the scope defined by the appended claims.

[0045] Example:

[0046] This embodiment provides a real-time analysis and judgment method for power grid outage faults based on business decoupling. It decomposes the complex power grid outage signal reception and processing business scenario, enabling business logic reuse and expansion, such as... Figure 1 As shown, it includes the following steps:

[0047] Step 1) Based on the business models of different levels of equipment in the power grid under analysis, from the outgoing line side (substation) to the user side (distribution area)... Figure 4 Medium equipment models: substations, poles, transformers, pole-mounted switches, meter boxes, line metadata) and monitoring signal data (i.e. Figure 4 The signal access point metadata is used to extract multi-level signal status models. The attributes of the signal status model include at least the unique identifier and status attributes of the device. In this example, the signal status model is extracted from the service model, that is, the attributes related to the signal status are retained from the attributes of the service model, and other attributes are removed. Taking the medium voltage line as an example, the line ID, the line power outage status, the power outage nature, and the signal attributes of various monitoring devices are retained.

[0048] Furthermore, for cases where the core content of the business model is accurately grasped and attributes can be aligned, the aforementioned signal state model can be created directly without relying on the business model.

[0049] Furthermore, the attributes in the signal state model include: unique identifier (required), state attribute (required), category attribute (not required), event attribute (not required), light summary value (not required), value object (not required, can be related business model), etc.

[0050] Step 2) Based on the attributes of the signal state model (unique identifier, state attributes, and attribute connection points), extract the command model at each level as input to the signal state model;

[0051] Furthermore, a command model is defined for the signal state model. The parameters of the command model must be derived from the attributes of the signal state model to which it belongs, including the unique identifier of the corresponding signal state model (e.g., transformer ID, medium voltage line ID). Other parameters are a subset of the attributes of the corresponding business model (only needing to include attributes related to device status and policy routing); generally, a specific value is set for a certain state attribute.

[0052] Step 3) Based on the attributes (unique identifier and state attribute) of the signal state model, analyze the signal state change factor, define the conditions for the signal state model attribute change to trigger the model to publish an event, and extract the event model as the output of the signal state model;

[0053] Furthermore, the conditions for triggering the above-mentioned events must be generated by changes in the state of one or more current signal state models.

[0054] Furthermore, the above analysis of signal state change factors and whether an event is triggered are based on the business rule definition (or event triggering rule).

[0055] Step 4) Fit the original signal state model to the signal state model of the target service, and associate the input and output of the upper and lower level signal state models. That is, use the output event parameters of the upper level model as the policy input and the input command parameters of the lower level model as the policy output, and complete the mapping between the event model and the command model.

[0056] Furthermore, the command model is used as the input to the signal state model, i.e., "action," and the events generated by changes in the internal attribute states of the signal state model are used as the model output, i.e., "behavior." A mapping relationship is established between which input command can produce which event.

[0057] Step 5) Design the execution unit (workunit) and subscribe to the signal state model published events, and schedule the execution unit to perform fault analysis logic processing;

[0058] Furthermore, the execution unit is a virtual task, whose implementation is carried out by external service logic. This mainly includes: data analysis and calculation for data entry, data storage, SMS notification dissemination, and calling other interfaces.

[0059] In one embodiment, the monitoring signal data mentioned in step 1) includes monitoring signal data generated by a one-time analysis of all power grid monitoring devices, including status signal data of main grid event processing, bus grounding, feeder automation (FA), branch switches, smart terminal fusion equipment (TTU) in the user acquisition area (TTU), user acquisition terminal, fusion terminal, secondary acquisition, and high-speed broadband carrier smart meter (hplc) (hereinafter referred to as hplc). (For the connection location and connection equipment of each monitoring device, please refer to...) Figure 4 ); One-time analysis of the collected equipment: medium-voltage lines, distribution transformers, low-voltage lines, circuit breakers, and meter box power outage equipment (see Figure 4 ).

[0060] In one embodiment, the signal state model described in step 1) includes at least a terminal measurement device layer, a power grid device layer, and a topology detail layer (sub-device layer).

[0061] Furthermore, the construction of this multi-level signal state model can be carried out using the following method:

[0062] First, establish a first-level signal state model. Then, using the power grid equipment to which the terminal measurement device belongs as a benchmark, establish a second-level signal state model through signal fitting. If the equipment topology is complex or there are other more detailed equipment fault assessment requirements, such as line segments under the line, then establish third to N-level signal state models.

[0063] In one embodiment, the event triggering conditions in step 3) include an idempotent condition for signal filtering and a non-idempotent condition for signal transmission.

[0064] Furthermore, an idempotent condition means that the event will only be triggered if the state attribute is updated from condition "A" to condition "B", while a non-idempotent condition means that the event will be triggered as long as the state update value satisfies condition "B".

[0065] In one embodiment, the inputs and outputs of the upper and lower level signal state models in step 3) are associated by direct mapping or indirectly by policy extension points, which are embedded by external programs to bridge the event model and the command model.

[0066] Furthermore, events (outputs) from the higher-level signal state model can be directly used as commands (inputs) for the lower-level signal state model. If parameters do not match or there is some kind of transformation logic in between, such as substituting a power outage event of a medium-voltage line into the lower-level connected transformer, it is necessary to call a service to query the list of subordinate transformers by line ID and distribute the signal to each corresponding transformer. This logic can be implemented by calling an external query service through an extension point access method, and then the transformation is performed by adding a business logic strategy. See also Figure 8In this context, the aggregated object is the parent, and the objects participating in the aggregation are the children.

[0067] Furthermore, in this example, the policy extension point (also called "SPI extension point") is not mandatory. If the relevant event of the defined upper-level signal state model corresponds exactly to the parameter of the lower-level command, it can be directly mapped and fitted. Otherwise, the SPI needs to be reserved for bridging by an external policy program.

[0068] In one embodiment, step 4) involves associating the inputs and outputs of the upper and lower level signal state models, specifically including:

[0069] If the event model parameters output by the upper-level signal state model match the command model parameters input by the lower-level signal state model, then the event model parameters are directly mapped to command model parameters.

[0070] If the parameters do not match or need to be converted by business logic, external business logic is accessed through the strategy extension point to convert the event model parameters and map them to command model parameters.

[0071] In one embodiment, when the strategy is extended to associate points, the power grid topology is analyzed to find the next-level devices that have a corresponding association with the previous-level devices, thereby realizing the transfer and conversion of signal state parameters between the upper and lower level signal state models.

[0072] In one embodiment, the method further includes designing the orchestration process of the execution unit, controlling the fault judgment logic sequence of the execution unit through a judgment process from the bottom level to the top level, and realizing fault point location (thereby realizing the execution sequence of each execution unit for the case of multiple business execution units without sequential signals).

[0073] Furthermore, the arrangement process can be presented in the form of diagrams, tables, etc.

[0074] In one embodiment, the orchestration process includes a start point, an end point, a compensation point, and a semaphore control element to support the timing management of distributed transactions.

[0075] Furthermore, not all execution units need to participate in execution orchestration. For example, execution orchestration flowcharts are only required when multiple execution units interact, such as in step-by-step data computation or long transaction processing.

[0076] The definition of execution orchestration mainly includes execution unit, start point, end point, compensation point, and semaphore element. Figure 7 An example of an execution orchestration flowchart is shown.

[0077] Execution Unit: Business logic executed by subscribed events, such as business database storage, data calculation, and mobile SMS delivery.

[0078] Starting point: Triggers the startup of a service orchestration process instance. There is no limit to one starting point; it can be triggered from multiple execution units.

[0079] End point: Ends a service orchestration process instance. There is no limit to one end point; it can end from multiple execution units.

[0080] Compensation point: If a timeout occurs due to the failure of a subsequent execution unit task, business exception handling (actually normal logic) is performed, such as business data rollback, secondary analysis, etc.

[0081] Semaphore: Semaphore P is located on the execution unit connection line. The default semaphore value is 1. If the number of parallel execution units is N (N>1), then semaphore P≤N.

[0082] In one embodiment, the orchestration process also includes an event compensation mechanism, which triggers secondary analysis by setting a signal waiting threshold to ensure the accuracy of fault location. By defining a signal arrival waiting time threshold, a compensation event is emitted when the signal times out, and the relevant execution unit performs secondary analysis to locate the equipment fault point.

[0083] Application Implementation Examples:

[0084] This application example provides a real-time analysis and judgment method for power grid outage faults based on business decoupling. Before applying the method, it is necessary to define the encoding of various elements under the current technical architecture so that each step of the implementation process can be clarified. At the same time, these metadata will use the encoding as a unique identifier to finally transform from the design state to the runtime state and be handed over to the system event flow.

[0085] The encoding method defined below is not fixed, as long as it can distinguish various types of elements and ensure that the encoding is unique.

[0086] Signal Status Model: [Model Encoding] _StatusModel, Example: (Line_StatusModel Medium Voltage Line Fault Judgment Status Model)

[0087] Command: C-[Service Code (Fault Analysis Service mentioned in this invention)]-[Three-digit Serial Number], Example: (C-AC001-001) Outgoing switch event message reception.

[0088] Event: E-[Service Code (Fault Analysis Service mentioned in this invention)]-[Three-digit Serial Number], Example: (E-AC001-001) Switch tripping event, Triggering condition: Outgoing switch status changes to "tripping", tripping time changes.

[0089] Strategy: STG-

Three-digit serial number

[0090] Execution unit: U-[Service code (fault analysis service mentioned in this invention)]-[three-digit serial number], example: (U-AC001-001) Line outgoing switch tripped.

[0091] Execution arrangement: G-

Service code (fault assessment service mentioned in this invention)

Three-digit serial number

[0092] The specific implementation method is as follows:

[0093] (1) Establish a signal status model of the equipment based on the monitored power grid equipment.

[0094] Taking medium-voltage lines as an example, the measurement signals related to medium-voltage line condition monitoring include outgoing switch signals and feeder automation (FA) signals. To fit the signal to the medium-voltage line fault state model, it is necessary to include the equipment's unique identifier, equipment information, and signal state attributes. The final medium-voltage line fault state model attributes should include: medium-voltage line ID (unique identifier), substation ID, outgoing switch ID, number of branch switches, feeder automation (FA) signals, event-based signals, event-based signal duration, and whether grounding is present. These attributes are provided to the equipment by the upstream measurement and acquisition device. Therefore, by aggregating the outgoing switch signal status and feeder automation (FA) signal status with the medium-voltage line fault judgment model, a comprehensive judgment model can be obtained. For the complete signal state model design, please refer to [link / reference needed]. Figure 9 In the actual platform, when events are processed, a grid topology query is performed through a strategy. The corresponding lower-level medium-voltage line ID is found from the upper-level outgoing switch ID, thus realizing the linkage of model instances.

[0095] (2) Analyze the equipment signal state model attributes and state change factors, and extract commands and events;

[0096] (2-1) Referring to step (1), design the command. The command comes from the command gateway and represents the input of the signal state model. At the same time, the command represents the activity of the signal state model and is thus associated with the signal state model. The model instance performs signal verification and filtering through the command input data. The following example illustrates this:

[0097] (2-2) Following step (1), we proceed with event design. Events are divided into two categories: one category represents the behavior of the signal state model, which is triggered by changes in the signal state model instance itself or its attribute state, thus associating it with the interaction model; the other category is compensation events caused by service orchestration instance transaction timeouts that require exception handling. Compensation events are not necessarily system exceptions. The compensation events in this fault assessment design are actually a branch processing of the normal business process. The following examples illustrate this:

[0098] (3) Filter out repeated signals from different devices in the same time series, and use a strategy to fit the signal and extract the extension points.

[0099] Referring to step (2), strategy design is carried out. In this invention, the strategy implementation is to provide an extension point, subscribe to the event of the previous stage, and execute the routing processing logic of calling the command of the next stage. For example, in the power outage fault assessment, the main body of the equipment instance of the upper-level signal needs to be fitted to the specific faulty power grid equipment entity that needs to be assessed: medium-voltage line, distribution transformer, meter box, line segment, and equipment topology query is required.

[0100]

[0101] (4) Subscribe to the signal state model to publish events, and the scheduling execution unit (WORKUNIT) performs specific fault judgment logic processing.

[0102] Referring to step (2), the execution units are designed. Most execution units perform data calculation and analysis and write the results into various physical data tables. A small number of execution units perform client message notification operations or call external interfaces. The execution units can flexibly subscribe to relevant events according to requirements, and the business can be expanded.

[0103]

[0104] (5) The execution order of the same power outage event is determined by the distributed transaction control of the execution scheduling, and the fault location is inferred by the event compensation mechanism.

[0105] Refer to step (4) to perform execution orchestration design. In the process of power outage fault assessment, the assessment of power outage faults of lower-level equipment generally relies first on the results of the assessment of the upper level, and then on the auxiliary assessment based on the signals of the current level or the lower level. Therefore, multiple signals are fitted, and when the upper-level event has not arrived, it is necessary to set the transaction time and wait for the upper-level signal to arrive before execution.

[0106] The execution process for medium-voltage line analysis is as follows: To perform line fault analysis, it is necessary to rule out the cause of line power outage due to power failure or fault of the upstream outgoing switch. The service orchestration instance is started by line ID, involving 5 execution units: line FA fault record storage (U-AC001-005), line outgoing switch tripping (U-AC001-001), line outgoing switch grounding fault (U-AC001-002), line outgoing switch reclosing fault (U-AC001-004), and line fault analysis (U-AC001-011). It includes 1 starting point, 3 ending points, and 1 compensation point. When a line FA power outage event is received, the line FA fault record is saved (U-AC001-005), the thread task is suspended, and U-AC001-001, U-AC001-002, and U-AC001-004 are executed within a similar time period. If the three execution units have not executed for more than 10 seconds, the service orchestration transaction times out. One possibility is that U-AC001-001, U-AC001-002, and U-AC001-004 have already completed their execution and have analysis results. Another possibility is that no power outage or fault information from the superior has been received, in which case the fault can be determined to be a line-based fault. For the first case, the analysis result table can be queried in the execution unit U-AC001-011 corresponding to the compensation event to see if there are any new superior analysis results. If so, it can be determined that the fault is not a line-based fault.

[0107] The above description is only an example of judging power outage faults on medium-voltage lines of the power grid, and should not be used to limit the scope of application of this invention. Therefore, equivalent changes made in accordance with the claims of this invention are still within the scope of this invention.

Claims

1. A real-time analysis and judgment method for power grid outage faults based on business decoupling, characterized in that, Includes the following steps: Step 1) Based on the business models of equipment at each level from the outgoing line side to the user side in the power grid under analysis, fuse the monitoring signal data and generalize to extract multi-level signal state models; the attributes of the signal state model include at least the unique identifier of the equipment and each state attribute; Step 2) Based on the attributes of the signal state model, extract the command model for each level as input to the signal state model; Step 3) Based on the attributes of the signal state model, analyze the signal state change factor, define the conditions for the signal state model attribute changes to trigger the model to publish events, and extract the event model as the output of the signal state model. Step 4) Associate the inputs and outputs of the upper and lower level signal state models to complete the mapping between the event model and the command model; Step 5) Design the execution unit and subscribe to the signal state model published events, and schedule the execution unit to perform fault judgment logic processing.

2. The real-time analysis and judgment method for power grid outage faults based on business decoupling according to claim 1, characterized in that, The monitoring signal data mentioned in step 1) includes monitoring signal data generated by all power grid monitoring devices in a one-time analysis, including main grid event data, bus grounding data, feeder automation (FA) data, branch switches, user acquisition area smart terminal fusion equipment (TTU), user acquisition terminal data, fusion terminal data, secondary acquisition data, and status signal data of high-speed broadband carrier smart meters (hplc) for households; the devices collected in the one-time analysis include: medium-voltage lines, distribution transformers, low-voltage lines, circuit breakers, and meter box de-energization equipment.

3. The real-time analysis and judgment method for power grid outage faults based on business decoupling according to claim 2, characterized in that, The signal state model described in step 1) includes at least the terminal measurement device layer, the power grid equipment layer, and the topology details layer.

4. The real-time analysis and judgment method for power grid outage faults based on business decoupling according to claim 1, characterized in that, The event triggering conditions in step 3) include idempotent conditions for signal filtering and non-idempotent conditions for signal transmission.

5. The real-time analysis and judgment method for power grid outage faults based on business decoupling according to claim 1, characterized in that, In step 3), the inputs and outputs of the upper and lower level signal state models are associated by direct mapping or indirectly by policy extension points. The policy extension points are embedded by external programs to bridge the event model and the command model.

6. The real-time analysis and judgment method for power grid outage faults based on business decoupling according to claim 5, characterized in that, In step 4), the inputs and outputs of the upper and lower level signal state models are correlated, specifically including: If the event model parameters output by the upper-level signal state model match the command model parameters input by the lower-level signal state model, then the event model parameters are directly mapped to command model parameters. If the parameters do not match or need to be converted by business logic, external business logic is accessed through the strategy extension point to convert the event model parameters and map them to command model parameters.

7. The real-time analysis and judgment method for power grid outage faults based on business decoupling according to claim 6, characterized in that, When the aforementioned strategy is used to extend the points for association, the power grid topology is analyzed to find the next-level devices that have a corresponding association with the previous-level devices, thereby realizing the transfer and conversion of signal state parameters between the upper and lower level signal state models.

8. The real-time analysis and judgment method for power grid outage faults based on business decoupling according to claim 1, characterized in that, The method also includes designing the orchestration process of the execution unit, controlling the fault judgment logic sequence of the execution unit through a judgment process from the bottom level to the top level, and realizing fault point location.

9. The real-time analysis and judgment method for power grid outage faults based on business decoupling according to claim 8, characterized in that, The orchestration process includes a start point, an end point, a compensation point, and semaphore control elements to support the timing management of distributed transactions.

10. The real-time analysis and judgment method for power grid outage faults based on business decoupling according to claim 8, characterized in that, The orchestration process also includes an event compensation mechanism, which triggers secondary analysis by setting a signal waiting threshold to ensure the accuracy of fault location.

Images