Intelligent ticketing system based on programmable component-based rule engine

Abstract

This invention discloses an intelligent ticketing system based on a programmable component-based rule engine, relating to the field of data processing technology, to address the problems of insufficient flexibility and weak scalability in current ticketing systems. The system includes: a ticketing rule orchestration module for converting power grid operation data and knowledge into rule nodes; a ticketing task input module for parsing the content of maintenance orders into JSON format messages as input parameters; a ticketing dataset loading module for calling the power grid model topology service, finding the main power grid equipment model to be operated based on the plant ID and equipment ID in the dataset, dynamically loading and displaying the relevant power grid equipment models and topology connection relationships; and a ticketing rule engine module for decomposing the ticketing logic into multiple atomic rule nodes, controlling the execution order through a logic orchestration file, and generating JSON format operation ticket data. This invention has the advantages of low learning cost, high flexibility, and scalability.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to an intelligent ticketing system based on a programmable component-based rule engine. Background Technology

[0002] In power system dispatching and operation, operation tickets are core technical documents that ensure the safety of power grid equipment switching operations and standardize work procedures. Their accuracy and efficiency directly affect the safety of power grid operation and maintenance and the response speed of dispatching services. With the continuous expansion of the power grid, the number of substations, equipment types, and wiring methods are becoming increasingly complex. At the same time, dispatching services need to frequently deal with scenarios such as equipment maintenance and load adjustments, which places higher demands on the timeliness and rule adaptability of operation ticket generation.

[0003] Currently, the power industry's operation ticket generation technology has mainly gone through three stages: manual ticketing, semi-automated ticketing, and intelligent ticketing. The manual ticketing stage relied on dispatchers manually writing tickets based on equipment status and operating procedures, resulting in low efficiency and a high risk of errors. The semi-automated ticketing stage used preset fixed templates that could only match simple scenarios, lacking template versatility and unable to adapt to complex wiring methods and multi-device linkage scenarios. The intelligent ticketing stage introduced rule engine technology, using code encoding to solidify the ticketing logic, becoming the current mainstream technical solution.

[0004] From the perspective of the current state of industry technology, intelligent ticketing systems have covered provincial and municipal power grid dispatch centers. However, existing intelligent ticketing systems generally adopt a "hard-coded rule engine + static rule library" architecture. Although this has significantly improved efficiency compared to the previous two stages, it faces common problems such as insufficient flexibility due to the rigid rule engine, weak system scalability, and heavy reliance on the coding capabilities of R&D personnel. It is difficult to adapt to the core requirements of power grid dispatching business of "high-frequency adjustment and multi-scenario adaptation", and the need for technology upgrade is urgent. Summary of the Invention

[0005] The purpose of this invention is to provide an intelligent ticketing system based on a programmable component-based rule engine, which transforms knowledge and experience of power grid operation into reusable, programmable, and easily maintainable rule nodes. The rule engine drives the execution of these nodes, simulates the expert reasoning process, and ultimately generates operation tickets that comply with safety regulations.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] An intelligent ticketing system based on a programmable component-based rule engine includes:

[0008] The invoice arrangement module is used to transform data and knowledge of power grid operations into rule nodes;

[0009] The order processing task input module is used to read the maintenance order and parse the content of the maintenance order into a JSON format message as input parameters; the input parameters include JSON format data of the maintenance order and equipment information.

[0010] The invoice dataset loading module is used to call the power grid model topology service, find the main power grid equipment model to be operated based on the plant ID and equipment ID in the dataset, and dynamically load and display the relevant power grid equipment model and topology connection relationship;

[0011] The ticketing rules engine module is used to decompose the ticketing logic into multiple atomic rule nodes, and control the execution order through a logic orchestration file to generate operation ticket data in JSON format;

[0012] The operation ticket output module is used to load and display operation tickets on the front-end page.

[0013] More specifically, the ticketing rule arrangement module includes a database and a basic component library;

[0014] The database is divided into a device set and an attribute set, which are used to store device names and the device ownership and status information corresponding to the device names;

[0015] The basic component library is divided into two categories: process control components and instruction output components. Flow control components and instruction output components are used to drag and drop flow control components and instruction output components to complete the configuration.

[0016] More specifically, the process control element includes a sub-process element, an iterator element, a selection element, and a condition element;

[0017] The sub-process element is used to encapsulate and reuse process segments;

[0018] The iterator element is used to process collection data or loop body data in batches to realize loop execution logic;

[0019] The selection element generates multiple dictionary value branches by defining switch variables and configuring dictionary values. The dictionary value branches are used to match sub-processes or operation instructions. After obtaining the parsed configuration value through the dataset, the element enters the dictionary value branch where the configuration value is equal to the dictionary value.

[0020] The conditional element is used to define the value of the if variable and assign it an equal value, generating two branches: equal and not equal. The branches are used to match operation instructions, parse the if variable value through the dataset, and enter the branch that is equal to or not equal to the variable value.

[0021] More specifically, the instruction output element includes an operation command element, a reporting command element, and a custom element;

[0022] The operation command element includes a status command and a component command, which are used to generate specific operation instructions;

[0023] The reporting command element is used to configure the receiving unit and customize the reporting command content;

[0024] The custom element is applicable to instructions without a device set.

[0025] More specifically, the ticketing rule engine module includes a context acquisition unit and a rule execution unit;

[0026] The context acquisition unit is used to encapsulate the device association data, maintenance order information and process ID to be used, which are queried through the scheduling model topology service, into a context object;

[0027] The rule execution unit takes the context object as input data and converts rule nodes into specific instructions according to the rule chain of "general process - main process - sub-process", finally generating the ticket result. The general process, as the top-level entry point, reads the "main equipment.equipment type" parameter (e.g., main transformer, line) through the selection element and distributes it to the main process corresponding to the equipment type. The main process parses the "main equipment.wiring method" parameter (e.g., bridge wiring, double bus wiring) based on the selection element and distributes it to the sub-processes adapted to the wiring method. The sub-processes integrate elements such as operation orders and reporting orders to complete the generation of specific instructions. The triggering conditions and parameter sources of each level of the process are clear and can directly guide system configuration.

[0028] Compared with existing technologies, the intelligent ticketing system based on a programmable component-based rule engine provided by this invention has the following advantages:

[0029] Adopting the LiteFlow visual orchestration concept, the complex ticket generation process is broken down into countless fine-grained, single-function atomic components. Business logic is no longer written in code, but rather these components are connected as needed, like building blocks, through an external XML / JSON file (rule chain). They can reuse most of the same atomic components, greatly enhancing the adaptability of the solution. Business experts can quickly respond to new business requirements by modifying the rule chain configuration file, without requiring development intervention or only requiring the development of new atomic components, thus decoupling business logic from technical implementation. This significantly reduces the development, testing, and deployment workload caused by requirement changes, lowering the overall lifecycle maintenance cost; rule changes do not require compiling or deploying the application, only updating the configuration file, resulting in low learning costs and allowing business personnel to participate.

[0030] LiteFlow employs a mandatory component-based design. Its execution unit is naturally a component (Node). Each operation step (such as topology analysis, status checks, and operation item generation) is abstracted into an independent, reusable Java component. Whether it's a planned power outage, a fault power outage, or any other scenario requiring a switch to be disconnected, the rule chain doesn't need to reimplement the disconnection logic; it only needs to introduce this generic component during orchestration. In the future, if the preconditions for disconnecting the switch need to be modified (e.g., adding a "zero load" check), only the SwitchOperationComponent needs to be modified, and all business scenarios calling it will automatically take effect, truly achieving "one change, everywhere."

[0031] Complex power grid operation rules are broken down into indivisible, semantically clear business atomic components. For example, "equipment status judgment" and "generation of completion report content" are each independent components. The system provides a graphical drag-and-drop interface, allowing business personnel to construct complete operation ticket generation rules by connecting these pre-defined business components, much like building blocks. The system manages all business components and orchestrated rule templates uniformly, forming a reusable dataset and basic component library. This reduces the development cycle for adjusting business rules from weekly / monthly to online configuration in minutes / hours. The system's agility is significantly improved, enabling rapid response to business needs such as changes in power grid structure and the release of new regulations. Attached Figure Description

[0032] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0033] Figure 1 This is a system block diagram in an embodiment of the present invention;

[0034] Figure 2 This is the operation display interface of the sub-process elements in the ticket formation rule arrangement module of this invention embodiment;

[0035] Figure 3 This is the operation display interface for the overall process in the ticketing rules engine module of this embodiment of the invention;

[0036] Figure 4 This is the operation display interface of the main process in the ticketing rule engine module of this invention embodiment;

[0037] Figure 5 This is the operation display interface of a sub-process in the ticketing rule engine module of this embodiment of the invention;

[0038] Figure 6This is the output display interface for the operation ticket in an embodiment of the present invention. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0040] It should be noted that in this invention, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0041] This invention provides an intelligent ticketing system based on a programmable component-based rule engine. Please refer to [link / reference]. Figure 1 The system includes: a ticket formation rule arrangement module, a ticket formation task input module, a ticket formation dataset loading module, a ticket formation rule engine module, and an operation ticket output module.

[0042] The ticketing rule orchestration module is used to transform power grid operation data and knowledge into reusable, orchestratable, and easily maintainable atomic rule nodes. Each rule node corresponds to the functional encapsulation of a type of component in the basic component library (such as the operation command component corresponding to the rule node for 'generating equipment state transition instructions', and the condition component corresponding to the rule node for 'branch judgment'). The orderly arrangement of rule nodes forms a structured ticketing rule process, ultimately realizing process-oriented ticketing rule configuration management.

[0043] Specifically, the ticketing rule orchestration module includes a database and a basic component library. The dataset is the foundation for configuring the ticketing rule process and is divided into two categories: device set and attribute set. It is used to store device names and the device ownership and status information corresponding to the device names, and supports personalized variable expansion.

[0044] The equipment set is categorized by type, including main transformer-related equipment, line-related equipment, and busbar-related equipment. The relevant content from the maintenance order parsing serves as the data source input for generating maintenance orders. The equipment set is organized using a tree structure. Attribute sets are used to define the equipment's operating parameters and status information.

[0045] The basic component library is the "building blocks" for configuring ticketing rules and processes. It is divided into two categories: process control components and instruction output components. These components are used to drag and drop process control components and instruction output components in the visual interface to complete the configuration.

[0046] The process control elements include sub-process elements, iterator elements, selection elements, and condition elements.

[0047] Sub-process elements are used to encapsulate and reuse two types of ticketing rule process segments: First, there are standardized ticketing rule process segments that can be repeatedly invoked, such as standardized instruction generation rule processes commonly used in the start and completion stages of maintenance orders, which can be reused in ticketing scenarios for multiple types of equipment; second, there are ticketing rule process segments with independent business logic or clearly defined functional boundaries, such as the power outage instruction generation rule process for main transformers with internal bridge wiring, which can be reused in power outage ticketing scenarios for both line and busbar equipment. Sub-process elements support a hierarchical structure of overall process → main process → sub-process. In the overall process, different main processes are distributed according to equipment type (e.g., main transformer power outage / restoration main process). In the main process, different sub-processes are distributed according to different ticketing characteristics (e.g., main transformer wiring method), such as... Figure 2 As shown.

[0048] Iterator elements are used to process collection data or loop body data in batches to implement loop execution logic.

[0049] The selection element uses equipment attribute variables as the core configuration object and configures the dictionary values ​​corresponding to the equipment attributes to generate multiple sets of dictionary value branches (such as main transformer, line, bus, etc.). The dictionary value branches can be matched with sub-processes (such as main transformer shutdown and power-on processes, line shutdown and power-on processes) or operation instructions (such as equipment status transition instructions, reporting instructions). During system operation, the switch selection element will parse the actual value of the preset equipment attribute variable from the dataset (such as the actual value of "main equipment.equipment type" being "main transformer type") and match the actual value with the pre-configured dictionary value branches one by one. When the actual value is completely consistent with a certain dictionary value branch, the system will automatically enter that branch and execute the sub-process or operation instruction associated with the branch to ensure that the ticketing logic is accurately distributed according to the equipment attribute.

[0050] The IF condition element is used to define specific IF judgment statements in the ticketing rule configuration (e.g., "if main transformer.voltage level == '110'"). After the statement is configured, the system automatically generates two mutually exclusive logical branches: true (condition met) and false (condition not met). The branches are used to match the corresponding operation instructions (e.g., matching 110kV equipment operation instructions when the condition is met, and matching non-110kV equipment operation instructions when the condition is not met). During the execution of the ticketing engine, the IF condition element extracts and parses the parameters required for the judgment statement from the dataset to determine the truth value of the IF judgment statement. Subsequently, the system will automatically enter the true or false branch that matches its result (i.e., if the judgment result is "true", enter the "true" branch; if it is "false", enter the "false" branch), and execute the operation instructions associated with the branch to ensure that the ticketing logic proceeds in an orderly manner according to the condition judgment result.

[0051] The instruction output element is used to generate the specific instruction content in the operation ticket, including operation order element, reporting order element and custom element.

[0052] Operation command elements are used to generate specific operation instructions, including two modes: status commands and element commands. They support custom command content and parameter association. The system reserves pre-processing interfaces for specific operation instructions (such as determining whether the instruction needs to be output) and post-processing interfaces (such as rewriting specified content of the instruction).

[0053] The operation command defaults to a status command, which requires configuration of the operating device, initial status, and target status information. Status commands are generated based on device status transitions, such as switching the 220kV A-line 201 switch from operation to cold standby. The operation command can be switched to a component command, which requires configuration of the operating device and operation type (close / open). Component commands are used to generate operation commands for switching devices, disconnectors, grounding switches, etc. Component commands default to generating operation commands for the operating device. If the device is a switch, it is also possible to generate operation commands for the disconnectors or grounding switches on both sides of the switch. It supports selecting whether to perform step-by-step operation. If non-step-by-step operation is selected, only one command needs to be generated; if step-by-step operation is selected, the corresponding number of commands are generated based on the number of devices.

[0054] Example of the interaction process of the operation command element: Drag and drop the operation command element into the process canvas. It supports selecting the device and the initial target state of the device. Multiple devices can be selected (e.g., "Device 1 and Device 2 switch from running to cold standby"). It also supports adding multiple groups of different state transitions of devices, separated by commas (e.g., "Device 1 switch from running to cold standby, Device 2 switch from hot standby to cold standby"). After selecting the device state, the corresponding instruction preview effect is generated according to the terminology template. The instruction output effect can be modified through the custom button.

[0055] The reporting command element is used to configure the receiving unit and customize the reporting command content; the reporting command element is generally used to generate work communication content such as scheduling permission and reporting.

[0056] Custom components are suitable for generating instructions without a primary device set. For example, for operation instructions of secondary devices, a custom Java classpath "com.power.operation.SecondaryDeviceCmd" is configured. The backend parsing process is as follows: 1. Read the "generateCmd" method in this class; 2. Obtain parameters such as "primary device" and "operation type" from the dataset and pass them to the method; 3. The method generates instructions according to preset logic (such as "primary device + secondary device + operation type"); 4. Return the instructions to the frontend. The instruction format can be adjusted by modifying the "cmdFormat" variable in the class without modifying other modules.

[0057] The order processing task input module is used to read the maintenance order and parse the contents of the maintenance order into a JSON format message as input parameters. The input parameters include JSON format data of task information and equipment information on the maintenance order.

[0058] The data set loading module is used to call the power grid model topology service. Based on the plant ID and equipment ID in the dataset, it finds the main power grid equipment model to be operated, dynamically loads and displays the relevant power grid equipment models and topology connection relationships. The main power grid equipment model includes attributes such as the high-voltage side (110kV), medium-voltage side (35kV, if applicable), low-voltage side (10kV), and neutral point of the main transformer. The associated power grid equipment includes the high-voltage side switch, high-voltage side grounding switch, high-voltage side neutral point grounding switch, the high-voltage busbar connected to the 110kV side of the main transformer, the high-voltage line connected to the 110kV side of the main transformer, and the disconnect switch between the main transformer and the high-voltage side busbar, the low-voltage side switch, low-voltage side grounding switch, the low-voltage busbar connected to the 10kV side of the main transformer, and the 10kV bus branch switch on the 10kV side of the main transformer.

[0059] The ticket generation rule engine module decomposes the ticket generation logic into multiple atomic rule nodes. Each atomic rule node corresponds to a functional encapsulation of a type of component in the basic component library (e.g., the operation command component corresponds to the rule node for "generating device state transition instructions," and the condition component corresponds to the rule node for "branch judgment"). The ticket generation rule engine module controls the execution order of the rule nodes through a logic orchestration file, generating operation ticket data in JSON format.

[0060] The core of the ticket-generating rules engine module is to decompose the ticket-generating logic into multiple atomic rule nodes and control the execution order through a logic orchestration file (rule chain). The ticket-generating rules engine module includes a context acquisition unit and a rule execution unit.

[0061] The context acquisition unit is responsible for integrating external data (including relevant power grid equipment models, topology connection relationships, maintenance order information, and process IDs that need to be used), encapsulating the data into a context object, which will be used in the subsequent rule execution unit.

[0062] The rule execution unit specifically includes a general process, a main process, and sub-processes. The rule execution unit takes the context object as input data and executes according to the rule chain of "general process - main process - sub-process". The general process is responsible for the execution of global rules; the main process is responsible for the execution of rules for a specific type of device; the sub-processes are responsible for the execution of rules for a specific wiring method of a specific type of device, converting rule nodes into specific instructions such as operation commands and reporting commands, completing logical judgments, sequential execution, branch jumps, and instruction output, and finally generating a ticket result in JSON format.

[0063] like Figure 3 As shown, the ticketing rule execution unit first executes the overall process, determining the subsequent process direction based on the condition judgment value in the selection element. In this link, if the switch selection element is used when judging the condition, the configuration variable is "main device.device type", and its configured dictionary items include types such as main transformer, bus, line, switch, and secondary equipment, the system will obtain the corresponding value from the dataset based on the configuration variable "main device.device type", and then enter the main process of the specific device type.

[0064] like Figure 4 As shown, in the main process, the rule engine distributes the execution to specific sub-processes based on the wiring method of the equipment. This process utilizes selection elements, with configured dictionary entries including bridge wiring, line transformer group wiring, single busbar wiring, double busbar wiring, and 3 / 2 wiring. Based on the configured variable "main transformer.wiring method," the value of "main transformer.wiring method" is retrieved from the dataset, and the process proceeds to the specific wiring method's billing sub-process.

[0065] like Figure 5 As shown, in the sub-process, the rule engine processes the request data by selecting elements and condition elements, and executes the operation orders, reporting orders and custom order elements on the rule chain step by step. At the same time, the terms configured in these components are converted by the background program to generate the final operation instructions.

[0066] The following example, using the process of generating an operation ticket for the No. 2 main transformer at Xinminbian, illustrates the execution steps of the ticket generation rule execution unit:

[0067] 1. Execute the custom component to generate a reporting risk control instruction. The custom component is configured with a JavaBean path. The backend finds the processing operation JavaBean, dynamically generates risk control, and dynamically generates the operation instruction "Report: Risk control measures for the single main transformer power supply of Xinmin Substation at Level 6 have been implemented" based on the risk level of the substation.

[0068] 2. Execute the reporting command element to generate a reporting command for transformer low-voltage power transfer. The output command content configured in the reporting command element is "Report: [Main Transformer.Substation] [Transformer Low-Voltage Power Transfer Switch] is connected, [Main Transformer.Equipment Number] main transformer can be stopped, the load of [Main Transformer.Substation] [Transformer Low-Voltage Power Transfer Main Transformer] has been controlled to not exceed XXMW". Dynamically replace the corresponding equipment attribute values ​​in the dataset to generate the operation command "Report: Xinmin Substation 10kV #2 bus branch switch and 10kV #1 bus branch switch are connected, No. 2 main transformer can be stopped, the load of Xinmin Substation #1 main transformer has been controlled to not exceed XXMW".

[0069] 3. Execute the operation command element to generate the main transformer low-voltage switch to cold standby command. The output command content configured in the operation command element is "[Main Transformer.Equipment Number] Main Transformer No. 1 [Low Voltage Switch.Voltage Level] kV side changed from operation to cold standby", which dynamically replaces the corresponding equipment attribute in the data set to generate the operation command "Main Transformer No. 2 10kV side changed from operation to cold standby".

[0070] 4. Execute the operation command element to generate the high-voltage line to hot standby instruction. The output instruction content configured in the operation command element is "[High-voltage line] changed from operation to hot standby ([Main transformer.Voltage level] kV automatic transfer switch changed from trip to signal)", which dynamically replaces the corresponding equipment attributes in the data set to generate the operation instruction "Chaomin 1214 line changed from operation to hot standby (110kV automatic transfer switch changed from trip to signal)".

[0071] 5. Execute the operation command element to generate the main transformer high-voltage to cold standby command. The output command content configured in the operation command element is "[Main Transformer.Equipment Number] Main Transformer No. [Main Transformer.Voltage Level] kV side changed from operation to cold standby", which dynamically replaces the corresponding equipment attribute in the data set to generate the operation command "Main Transformer No. 2 110kV side changed from operation to cold standby".

[0072] 6. Execute the operation command element to generate the high-voltage line switching operation command. The output command content configured in the operation command element is "[High-voltage line] Change from hot standby to operation (110kV automatic transfer switch from signal to trip)", which dynamically replaces the corresponding equipment attributes in the data set to generate the operation command "Chaomin 1214 line change from hot standby to operation (110kV automatic transfer switch from signal to trip)".

[0073] 7. Execute the operation command element to generate a main transformer maintenance instruction. The output instruction content configured in the operation command element is: [Main Transformer.Equipment Number] Main transformer No. 2 is changed from cold standby to maintenance of both main transformers. The corresponding equipment attributes in the data set are dynamically replaced to generate the operation instruction "Main transformer No. 2 changed from cold standby to maintenance of both main transformers".

[0074] 8. Execute the reporting order element to generate the authorized work content instruction. The output instruction content configured in the reporting order element is "Permission: [Maintenance Order Work Content] Work Start [Maintenance Order Approval Work Start Time]", which dynamically replaces the corresponding equipment attributes in the dataset to generate the operation instruction "Permission: 1) Replacement of 110kV bushings and 110kV neutral point bushings of #2 main transformer; 2) Inspection and rectification of defects, hidden dangers, countermeasures, lean rectification, and one-station-one-warehouse problem of out-of-service equipment in the #2 main transformer bay, and comprehensive maintenance of primary equipment; Work Start 2025-10-13 06:30:00".

[0075] 9. Execute the reporting command element to generate a reporting work content instruction. The output instruction content configured in the reporting command element reports "[Maintenance Order Work Content] Work completed, equipment ready for commissioning [Maintenance Order Approved Work Completion Time]", dynamically replacing the corresponding equipment attributes in the data center to generate the operation instruction "Report: 1) Replacement of 110kV bushings and 110kV neutral point bushings of #2 main transformer; 2) Inspection and rectification of defects, hidden dangers, countermeasures, lean rectification, and one-station-one-warehouse problem inspection and rectification of out-of-service equipment in the #2 main transformer bay, and comprehensive maintenance of primary equipment; Work completed, equipment ready for commissioning 2025-10-14 23:00:00".

[0076] 10. Execute the operation command element to generate the main transformer to cold standby instruction. The output instruction content configured in the operation command element is "[Main Transformer.Equipment Number] Main transformer No. 1 is changed from both main transformers to cold standby", which dynamically replaces the corresponding equipment attribute in the data set to generate the operation instruction "Main transformer No. 2 is changed from both main transformers to cold standby".

[0077] 11. Execute the operation command element to generate the main transformer high-voltage line hot standby instruction. The output instruction content configured in the operation command element is "[High-voltage line] changed from operation to hot standby (110kV automatic transfer switch changed from trip to signal)", which dynamically replaces the corresponding equipment attributes in the data set to generate the operation instruction "Chaomin 1214 line changed from operation to hot standby (110kV automatic transfer switch changed from trip to signal)".

[0078] 12: Execute the operation command element to generate the main transformer high-speed operation command. The output command content configured in the operation command element is "[Main Transformer.Equipment Number] Main Transformer No. [Main Transformer.Voltage Level] kV side changed from cold standby to operation", which dynamically replaces the corresponding equipment attribute in the data set to generate the operation command "Main Transformer No. 2 110kV side changed from cold standby to operation".

[0079] 13. Execute the operation command element to generate the main transformer high-voltage line switching operation command. The output command content configured by the operation command element is "[High-voltage line] Change from hot standby to operation (110kV automatic transfer switch from signal to trip)", which dynamically replaces the corresponding equipment attributes in the data set to generate the operation command "Chaomin 1214 line change from hot standby to operation (110kV automatic transfer switch from signal to trip)".

[0080] 14. Execute the operation command element to generate the main transformer low-voltage switch to operation command. The output command content configured in the operation command element is "[Main Transformer.Equipment Number] Main Transformer No. 2 [Low Voltage Switch.Voltage Level] kV side changed from cold standby to operation", which dynamically replaces the corresponding equipment attribute in the data set to generate the operation command "Main Transformer No. 2 10kV side changed from cold standby to operation".

[0081] 15. Execute the reporting command element to generate a risk cancellation instruction. The output instruction content configured in the reporting command element is "Notify it: The operation of the [main transformer.affiliated substation] [main transformer.equipment number] main transformer [low voltage switch.voltage level] kV side has been changed, and the load control of the [low voltage transfer main transformer.equipment number] main transformer has been cancelled". Dynamically replace the corresponding equipment attributes in the data center to generate the operation instruction "Notify it: The operation of the 10kV side of the No. 2 main transformer of Xinmin Substation has been changed, the load control of the No. 1 main transformer has been cancelled, and the risk of single-line power supply of Xinmin Substation has been cancelled".

[0082] The operation ticket output module is used to load and display operation tickets on the front-end page, such as... Figure 6 As shown.

[0083] In the embodiments provided in this application, the division of modules, elements, or units is merely a logical functional division. In actual implementation, there may be other division methods; for example, multiple units or components may be combined or integrated into another system. Furthermore, the functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

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

[0085] Although the present invention has been described above in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made therein without departing from the spirit and scope of the invention. Accordingly, this specification and drawings are merely exemplary descriptions of the invention as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of the invention. Clearly, those skilled in the art can make various alterations and modifications to the invention without departing from its spirit and scope. Thus, if these modifications and modifications of the invention fall within the scope of the claims and their equivalents, the invention is also intended to include these modifications and modifications.

Claims

1. An intelligent ticketing system based on an orchestratable component-based rules engine, characterized in that, include: The invoice arrangement module is used to transform data and knowledge of power grid operations into rule nodes; The order processing task input module is used to read the maintenance order and parse the content of the maintenance order into a JSON format message as input parameters; the input parameters include JSON format data of the maintenance order and equipment information. The invoice dataset loading module is used to call the power grid model topology service, find the main power grid equipment model to be operated based on the plant ID and equipment ID in the dataset, and dynamically load and display the relevant power grid equipment model and topology connection relationship; The ticketing rules engine module is used to decompose the actual ticketing logic into a specific rule node execution path based on the input parameters, and to control the execution order through a logic orchestration file to generate operation ticket data in JSON format. The operation ticket output module is used to load and display operation tickets on the front-end page.

2. The intelligent ticketing system based on a programmable component-based rule engine according to claim 1, characterized in that, The ticketing rules arrangement module includes a database and a basic component library; The database is divided into a device set and an attribute set, which are used to store device names and the device ownership and status information corresponding to the device names; The basic component library is divided into two categories: process control components and instruction output components. Flow control components and instruction output components are used to drag and drop flow control components and instruction output components to complete the configuration.

3. The intelligent ticketing system based on the programmable component rule engine according to claim 2, wherein, The process control elements include sub-process elements, iterator elements, selection elements, and condition elements; The sub-process element is used to encapsulate and reuse process segments; The iterator element is used to process collection data or loop body data in batches to realize loop execution logic; The selection element generates multiple dictionary value branches by defining switch variables and configuring dictionary values. The dictionary value branches are used to match sub-processes or operation instructions. After obtaining the parsed configuration value through the dataset, the element enters the dictionary value branch where the configuration value is equal to the dictionary value. The conditional element is used to define the value of the if variable and assign it an equal value, generating two branches: equal and not equal. The branches are used to match operation instructions, parse the if variable value through the dataset, and enter the branch that is equal to or not equal to the variable value.

4. The intelligent ticketing system based on the programmable component rule engine according to claim 2, wherein, The instruction output element includes an operation command element, a reporting command element, and a user-defined element; The operation command element includes a status command and a component command, which are used to generate specific operation instructions; The reporting command element is used to configure the receiving unit and customize the reporting command content; The custom element is applicable to instructions without a device set.

5. The intelligent ticketing system based on the programmable component rule engine according to claim 1, wherein, The ticketing rule engine module includes a context acquisition unit and a rule execution unit; The context acquisition unit is used to encapsulate the device association data, maintenance order information and process ID to be used, which are queried through the scheduling model topology service, into a context object; The rule execution unit is used to take the context object as input data, convert the rule nodes into specific instructions according to the rule chain of "general process - main process - sub-process", and finally generate the ticket result.

Images