Operation order verification system

Abstract

The invention discloses an operation order verification system. The method relates to the field of substation control, and solves the problem of misoperation caused by errors easily caused by manual operation ticket compiling and auditing. Standard basis information stored in the knowledge base module comprises substation rule information and equipment related information, and covers two types of core basis required by verification; an operation task is converted into a clear analysis result through the semantic analysis module, the verification and error correction module is guided to directionally call standard bases, accurate matching is achieved, and the tedious process of manually screening the standard bases one by one is avoided; the verification and error correction module performs automatic comparison based on a standard basis, replaces a core link of manual auditing, and avoids misrecognition omission caused by human negligence from the technical level; on the basis of verification and error correction, a secondary confirmation module is additionally arranged to perform secondary verification on error correction information, so that the probability of error correction or error correction omission is further reduced; the output module outputs error correction information, an operator can directly modify according to a prompt, and the operation order modification efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of substation control, and in particular to an operation ticket verification system. Background Technology

[0002] During the critical phase of the power industry's transformation towards a new power system, substations, as core hubs of the power grid, directly determine power supply reliability, energy utilization efficiency, and the public's electricity experience through their operation and maintenance quality. Switching operations, as a fundamental task in the power system characterized by high importance, advanced technology, and inherent risks, directly impact the safe and stable operation of personnel, equipment, and the power grid. Furthermore, the operation ticket, as the written basis for switching operations in the power system, directly determines the success or failure of the operation based on its accuracy.

[0003] Currently, operation tickets are primarily prepared and reviewed manually based on the operational tasks. If operators and reviewers are unfamiliar with the substation equipment, or if errors occur due to insufficient load capacity, poor mental state, or lack of personal ability, it can lead to serious production accidents such as equipment tripping, and in severe cases, even endanger personnel lives. Furthermore, as substation equipment is continuously upgraded, operating regulations are also constantly updated. If the preparers fail to learn the new regulations in a timely manner, they may apply old regulations to new equipment, ultimately causing accidents. Although operation tickets undergo a second review after preparation, it cannot be guaranteed to be error-free, and production accidents caused by errors in operation ticket preparation still occur frequently.

[0004] Therefore, how to solve the problem of errors that easily occur when manually writing and reviewing operation tickets, leading to operational mistakes, is a technical problem that urgently needs to be solved by people in this field. Summary of the Invention

[0005] The purpose of this application is to provide an operation ticket verification system to solve the problem of errors that easily occur when manually writing and reviewing operation tickets, leading to operational mistakes.

[0006] To address the aforementioned technical problems, this application provides an operation ticket verification system, comprising:

[0007] The knowledge base module is used to store the standard basis information required for operation ticket verification. The standard basis information includes at least substation rule information and equipment-related information.

[0008] The semantic analysis module is used to receive operation tasks, perform semantic parsing on the operation tasks, and output task analysis results corresponding to the operation tasks.

[0009] The verification and error correction module is connected to the knowledge base module and the semantic analysis module respectively. It is used to obtain manually written operation tickets to be verified, call the corresponding standard basis information from the knowledge base module based on the task analysis results, compare the operation tickets to be verified with the standard basis information, identify errors in the operation tickets to be verified, and generate error correction information.

[0010] The secondary confirmation module is connected to the knowledge base module and the verification and error correction module respectively. It is used to obtain the error correction information, perform secondary comparison and verification of the error correction information with the standard basis information in the knowledge base module, and output the error correction information that has passed the verification.

[0011] The output module, connected to the secondary confirmation module, is used to output the verified error correction information in a preset format.

[0012] As an optional solution, in the above-mentioned operation ticket verification system, the knowledge base module is constructed using a relational database; the knowledge base module also includes an automatic synchronization interface.

[0013] The knowledge base module connects with the substation SCADA system and equipment operation and maintenance management platform through an automatic synchronization interface to receive updated standard basis information.

[0014] The substation rule-based information includes at least one of the following: on-site operation procedures, typical operation tickets, protection procedures, equipment operation and maintenance regulations, equipment ledgers, and equipment manuals; the equipment-related information includes at least one of the following: equipment attribute information, equipment real-time status information, and equipment association information.

[0015] As an optional solution, in the above-mentioned operation ticket verification system, the semantic analysis module is implemented based on a preset semantic model; the preset semantic model is a model trained by power scenario semantic knowledge, which includes at least one of: typical operation tickets, dispatch management procedures, and historical operation tickets;

[0016] When the preset semantic model performs semantic parsing on the operation task, if the task ambiguity exceeds a preset threshold, a candidate task list is generated, and the operator receives a selection instruction based on the candidate task list to determine the final task analysis result.

[0017] As an optional solution, in the above-mentioned operation ticket verification system, the semantic analysis module performs semantic parsing of the operation task, including:

[0018] Identify the task type, core objective, and associated equipment of the operation task, and output basic analysis results including task type identifier, core objective description, and associated equipment list;

[0019] If the operation task contains multiple sub-tasks, the operation task is split into sub-tasks, and the task type, core target and associated device of each sub-task are identified respectively;

[0020] Output a combined task analysis result that includes the independent analysis results of each subtask.

[0021] As an optional solution, in the above-mentioned operation ticket verification system, the verification and error correction module has an error correlation analysis function. When an error is detected in a certain step of the operation ticket to be verified, it automatically traces the impact of the error on subsequent related operation steps and outputs all chain errors, error root causes and corresponding error correction suggestions at once.

[0022] As an optional solution, in the above-mentioned operation ticket verification system, the verification and error correction module compares the operation ticket to be verified with the standard basis information, including: comparing the operation ticket to be verified with the standard basis information item by item according to at least one of the following dimensions: operation steps, operation object, operation logic, and operation conditions; the errors in the operation ticket to be verified include at least one of the following: missing operation steps, incorrect operation order, misselected operation object, omission of operation conditions, and logical conflict.

[0023] As an optional solution, in the above-mentioned operation ticket verification system, the secondary confirmation module is used to determine whether the source of the standard basis corresponding to the error correction information is unique and whether the error correction suggestion is consistent with the standard basis information based on the standard basis information in the knowledge base module; if both are satisfied, the verification is deemed successful and the error correction information is output; if there is a conflict in the source of the standard basis or the error correction suggestion is inconsistent with the standard basis information, the error correction information is returned to the verification and error correction module for reprocessing.

[0024] As an optional solution, in the above-mentioned operation ticket verification system, the secondary confirmation module further includes: a rule conflict processing unit, which is used to output a list of conflicting rules and the corresponding rule sources when a conflict is detected in the standard basis source corresponding to the error correction information, and after receiving the confirmation instruction, update the corresponding rules in the knowledge base module and complete the secondary verification.

[0025] The secondary confirmation module includes a manual intervention interface for receiving rejection or modification control instructions for the error correction information.

[0026] As an optional solution, in the above-mentioned operation ticket verification system, the operation ticket to be verified is in document format, and the format of the verification-passed error correction information output by the output module is consistent with the format of the operation ticket to be verified.

[0027] As an optional solution, in the above-mentioned operation ticket verification system, the knowledge base module further includes: an update triggering unit, used to set an expiration date for the stored standard basis information, mark the standard basis information that has exceeded the expiration date as pending review and issue a reminder message.

[0028] The operation ticket verification system provided in this application stores standard reference information in its knowledge base module, including substation rule information and equipment-related information, covering the two core types of references required for verification. The semantic analysis module transforms operation tasks into clear analysis results, guiding the verification and correction module to call upon standard references in a targeted manner, achieving accurate matching and avoiding the tedious process of manually screening standard references one by one. The verification and correction module automatically compares against standard references, replacing the core step of manual review and technically avoiding errors caused by human negligence. A secondary confirmation module is added to the verification and correction system to perform secondary verification of the correction information, further reducing the probability of incorrect or missed corrections, ensuring the correctness of the operation ticket, and reducing the occurrence of switching operation accidents from the source. The output module outputs correction information in a preset format, allowing operators to directly modify it according to the prompts without needing to re-examine the correction logic, improving the efficiency of operation ticket modification and effectively alleviating the problem of insufficient manual workload. Attached Figure Description

[0029] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 This application provides a schematic diagram of an operation ticket verification system.

[0031] Figure label:

[0032] 11-Knowledge base module; 12-Semantic analysis module; 13-Verification and error correction module; 14-Secondary confirmation module; 15-Output module. Detailed Implementation

[0033] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0034] The core of this application is to provide an operation ticket verification system.

[0035] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0036] This application provides an operation ticket verification system, such as... Figure 1 As shown, it includes:

[0037] Knowledge base module 11 is used to store the standard basis information required for operation ticket verification. The standard basis information includes at least substation rule information and equipment-related information.

[0038] The semantic analysis module 12 is used to receive operation tasks, perform semantic parsing on the operation tasks, and output the task analysis results corresponding to the operation tasks.

[0039] The verification and error correction module 13 is connected to the knowledge base module 11 and the semantic analysis module 12 respectively. It is used to obtain the manually written operation ticket to be verified, call the corresponding standard basis information from the knowledge base module 11 based on the task analysis results, compare the operation ticket to be verified with the standard basis information, identify the errors in the operation ticket to be verified and generate error correction information.

[0040] The secondary confirmation module 14 is connected to the knowledge base module 11 and the verification and correction module 13 respectively. It is used to obtain correction information, compare and verify the correction information with the standard basis information in the knowledge base module 11, and output the correction information that has passed the verification.

[0041] The output module 15 is connected to the secondary confirmation module 14 and is used to output the verified error correction information in a preset format.

[0042] An operation ticket is a written document that provides the basis for switching operations in a power system. It contains key information such as the operation task, operation steps, operation object, and operation conditions. It is a core document that ensures the implementation of switching operation specifications.

[0043] First, the knowledge base module 11 is used to store the standard basis information required for operation ticket verification, and to systematically store substation rule information and equipment-related information to form structured data that can be called.

[0044] The system stores substation rule-related information to ensure that the verification basis complies with industry standards and on-site operation and maintenance requirements, avoiding inaccurate verification due to missing or incorrect rules. It also stores equipment-related information to ensure that the verification process is combined with the actual status and attributes of the equipment, avoiding issues of discussing operating procedures without considering the actual equipment. Substation rule-related information generally includes static rules such as on-site operating procedures, typical operation tickets, protection procedures, and equipment operation and maintenance regulations. Equipment-related information includes dynamic data such as equipment attributes (e.g., model, serial number), real-time equipment status (e.g., operating / out of service), and equipment relationships (e.g., upper and lower level linked equipment).

[0045] It should also be noted that this does not mean that the knowledge base module 11 can only store the above two types of information. In fact, it can also expand to store other verification-related information according to actual needs, but it must at least include these two core types of content, which is the basis for ensuring the validity of verification.

[0046] The semantic analysis module 12 can be broken down into two steps: the first step is to receive the operation task input by the operator, and the second step is to perform semantic parsing on the operation task, ultimately outputting the corresponding task analysis results. Since the description of the operation task may be ambiguous (such as handling a line problem), this does not mean that the semantic analysis module 12 can only passively parse it. Its core function is to transform the ambiguous operation task into a clear verification direction: by parsing the task type, core objective, and associated devices, it provides precise navigation for the subsequent verification and error correction module 13, avoiding problems such as errors in standards or objects during the verification process.

[0047] Therefore, the parsing process of the semantic analysis module 12 needs to be based on the professional logic of the power scenario, rather than ordinary text parsing. That is, it is necessary to accurately identify the operation terms and task logic unique to the power industry to ensure that the analysis results meet the actual needs of switching operations.

[0048] The task analysis result is the information output by the semantic analysis module 12 after parsing the operation task. It usually includes the task type (such as power outage operation, power restoration operation), core objective (such as disconnecting the power supply of a certain line), and a list of associated equipment, which is used to clarify the direction of verification.

[0049] Based on the above principles, the working steps of the verification and error correction module 13 can be divided into three steps: First, obtain the manually written operation ticket to be verified; second, based on the task analysis results output by the semantic analysis module 12, call the corresponding standard basis information from the knowledge base module 11; finally, compare the operation ticket to be verified with the called standard basis information, identify errors and generate error correction information.

[0050] It should be noted that, as the verification and error correction module 13 is the core execution unit of the system, its purpose is to replace the core step of manual review. Through automated comparison, it accurately identifies errors in the operation ticket (such as missing operation steps, incorrect operation sequence, misselection of operation objects, etc.) and provides clear error correction suggestions. Compared with manual review, this automated comparison not only avoids errors caused by human negligence but also significantly improves verification efficiency and alleviates the problem of insufficient human workload.

[0051] It should also be noted that the comparison process is not limited to a single method. In fact, the comparison can be carried out from multiple dimensions such as operation steps, operation objects, operation logic, and operation conditions. This embodiment does not impose strict limitations, but the core is to call standard references based on the task analysis results to ensure the relevance and accuracy of the comparison.

[0052] Error correction information is the correction content generated by the error correction module 13 after it identifies an error in the operation ticket. It generally includes the error location, error type, and correct operation suggestions.

[0053] The working steps of the secondary verification module 14 are as follows: First, it obtains error correction information from the verification and correction module 13; second, it performs a secondary comparison and verification between the error correction information and the standard basis information in the knowledge base module 11; finally, it outputs the error correction information that has passed the verification. It should be noted that... Figure 1 The judgment process actually occurs in the secondary confirmation module 14.

[0054] It should be noted that since the verification and correction module 13 may make misjudgments (such as inaccurate correction suggestions due to data deviation), the core function of the secondary confirmation module 14 is to provide double protection. By comparing it again with the standard, it eliminates the possibility of erroneous or missed corrections, ensuring the accuracy of the output correction information. In addition, if the secondary comparison finds that the correction information is inconsistent with the standard, it needs to be returned to the verification and correction module 13 for reprocessing, forming a closed-loop verification mechanism.

[0055] On the other hand, the verification logic of the secondary confirmation module 14 is consistent with that of the verification and error correction module 13. Both are based on the standard in the knowledge base module 11, which is to ensure the consistency and rigor of the entire verification process and avoid result conflicts caused by different verification standards of different modules.

[0056] The output module 15 receives the verification pass error correction information output by the secondary confirmation module 14 and outputs it in a preset format. The preset format does not represent a fixed single format, but refers to a format that is compatible with the format of the operation ticket to be verified and is easy for operators to view and modify (such as .doc format). This embodiment does not impose strict limitations.

[0057] The operation ticket verification system provided in this application firstly constructs a unified verification standard benchmark through the knowledge base module 11; secondly, the semantic analysis module 12 parses the operation task and clarifies the verification direction; thirdly, the verification and error correction module 13 conducts automated comparison based on the standard and task direction to identify errors; then, the secondary confirmation module 14 verifies the accuracy of the error correction information and eliminates misjudgments; finally, the output module 15 delivers the results in a practical format to support the modification of the operation ticket. The knowledge base module 11 stores standard reference information including substation rule information and equipment-related information, covering the two core references required for verification. The semantic analysis module 12 transforms the operation tasks into clear analysis results, guiding the verification and correction module 13 to call up standard references in a targeted manner, achieving accurate matching and avoiding the tedious process of manually screening standard references one by one. The verification and correction module 13 automatically compares the standard references, replacing the core link of manual review, and avoiding errors caused by human negligence from a technical perspective. On the basis of verification and correction, a secondary confirmation module 14 is added to perform secondary verification of the correction information, further reducing the probability of incorrect or missed corrections, ensuring the correctness of the operation ticket, and reducing the occurrence of switching operation accidents from the source. The output module 15 outputs the correction information in a preset format, and operators can directly modify it according to the prompts without having to re-examine the correction logic, improving the efficiency of operation ticket modification and effectively alleviating the problem of insufficient manual workload.

[0058] According to the above embodiments, in a specific implementation of the operation ticket verification system of this application, the knowledge base module 11 is constructed through a relational database; the knowledge base module 11 also includes an automatic synchronization interface.

[0059] The knowledge base module 11 connects with the substation data acquisition and monitoring control (SCADA) system and equipment operation and maintenance management platform through the automatic synchronization interface to receive updated standard basis information;

[0060] Substation rule-related information includes at least one of the following: on-site operation procedures, typical operation tickets, protection procedures, equipment operation and maintenance regulations, equipment ledgers, and equipment manuals; equipment-related information includes at least one of the following: equipment attribute information, equipment real-time status information, and equipment association information.

[0061] First, this solution uses a relational database to construct the knowledge base module 11. The relational database is constructed using a database that supports structured data storage and multi-table join queries (such as MySQL, a relational database management system). Because standard reference information has the characteristics of strong structure and frequent join queries, the relational database's support for multi-table join queries ensures that the verification and error correction module 13 can quickly obtain the relevant data when calling the information, thus improving verification efficiency. On the other hand, the format of standard reference information is relatively fixed (such as procedure clauses, equipment parameters, etc.), and structured storage can ensure the standardization of the data and avoid verification errors caused by chaotic data formats.

[0062] In real-world scenarios, the real-time status of equipment changes dynamically with operational conditions (e.g., from operation to shutdown), and substation rules are adjusted due to industry standard updates or equipment upgrades. Manually entering data for updates is not only inefficient but also prone to omissions or delays, leading to outdated verification criteria. Knowledge Base Module 11 adds an automatic synchronization interface and connects to external systems. This interface is a dedicated data transmission channel between Knowledge Base Module 11 and external systems, its core function being automatic data updates. The automatic synchronization interface is compatible with commonly used standard protocols in the power industry; this solution does not impose strict limitations. Furthermore, automatic synchronization does not mean data is unaudited. In fact, after receiving data, the interface can be configured with an automatic verification process to ensure the accuracy of the updated data before synchronizing it to the knowledge base.

[0063] The external interface system specifically refers to the substation SCADA system (data acquisition and monitoring system) and the equipment operation and maintenance management platform. The SCADA system mainly provides real-time equipment status data, while the equipment operation and maintenance management platform mainly provides information such as rule updates and equipment ledger changes.

[0064] This plan clarifies the specific composition of the standard information. Substation rule-based information covers six categories, including on-site operating procedures and typical operation tickets. The verification of operation tickets must not only comply with general procedures but also refer to specific requirements such as typical operation cases and equipment manuals to ensure the comprehensiveness of the verification. For example, when verifying the operation steps of a certain device, it is necessary to comply with the general requirements of the on-site operating procedures and also follow the specific provisions of the equipment manual. The equipment-related information clearly includes three types of data: attributes, real-time status, and correlation relationships. This ensures that the verification is consistent with the actual equipment. For example, when judging whether an operation step is correct, it is necessary to make a comprehensive judgment based on the equipment attributes (such as rated voltage), real-time status (such as whether it is in operation), and the situation of related equipment (such as whether it affects the operation of other equipment) to avoid one-sided verification that is detached from the actual equipment.

[0065] It should also be noted that the descriptions included in the plan do not represent a limitation on the scope of information. In fact, other relevant information (such as regional operation and maintenance specifications) can be added according to the differentiated needs of different substations. This plan does not impose strict restrictions.

[0066] According to the above embodiments, in a specific implementation of the operation ticket verification system of this application, the semantic analysis module 12 is implemented based on a preset semantic model; the preset semantic model is a model trained by power scenario semantic knowledge, which includes at least one of typical operation tickets, dispatch management procedures and historical operation tickets.

[0067] When the preset semantic model performs semantic parsing on the operation task, if the ambiguity of the task exceeds a preset threshold, a candidate task list is generated, and the operator's selection instruction based on the candidate task list is received to determine the final task analysis result.

[0068] First, the semantic analysis module 12 is based on a pre-defined semantic model. This model is trained using semantic knowledge from the power industry. Because power industry operations involve numerous technical terms and specific operational logics, general semantic models struggle to accurately understand this specialized content, leading to parsing biases. However, training the model with power industry-specific data such as typical operation tickets and dispatch management procedures allows the model to learn the professional expression habits and task logic of power operations, ensuring that the parsing results meet actual operation and maintenance needs. Furthermore, the model can be iteratively optimized by continuously importing new power industry semantic knowledge, allowing its parsing capabilities to continuously improve with the development of the power system.

[0069] The preset semantic model performs a process of ambiguity judgment, candidate list generation, and manual confirmation during parsing. The core purpose is to solve the problem of inaccurate parsing caused by ambiguous descriptions of operation tasks. In actual operation and maintenance scenarios, operators may not be clear about the operation tasks they input due to busy work or their expression habits. If the model forcibly outputs a single parsing result, it is very easy to have an incorrect verification direction, which will lead to the subsequent verification and error correction module 13 calling the wrong standard basis and causing verification failure.

[0070] It should be noted that the fuzzy quantification mentioned in this embodiment can be judged separately by the weights of different elements, based on the power semantic knowledge base, such as whether the task elements are complete, whether the expression is ambiguous, and whether it conforms to logic, and comprehensively judge the fuzziness of the operation task.

[0071] Therefore, when the model detects that the ambiguity of a task exceeds a preset threshold, a list of candidate tasks is generated for the operator to select. The accuracy of the final task analysis results is ensured through manual confirmation, realizing the synergistic advantages of efficient machine analysis and precise human control, and further improving the reliability of the system.

[0072] It should also be noted that the specific format of the task analysis results is not strictly limited in the solution, as long as the core elements required for verification are clearly presented, such as including task type identifier, core objective description, and a list of associated equipment.

[0073] The semantic knowledge of the power scenario includes at least three categories: typical operation tickets, dispatch management procedures, and historical operation tickets. These data are all directly derived from actual power operation and maintenance scenarios, which can ensure that the model learns parsing capabilities that fit actual needs. However, this does not mean that it is limited to these three types of data. Other semantic-related data in the power industry (such as operation and maintenance manuals) can also be extended. This solution does not impose strict limitations.

[0074] According to the above embodiments, in a specific implementation scheme, the process of semantic analysis module 12 performing semantic parsing on the operation task includes:

[0075] Identify the task type, core objectives, and associated equipment of the operation task, and output basic analysis results including task type identifier, core objective description, and associated equipment list;

[0076] If an operation task contains multiple subtasks, the operation task is split into subtasks, and the task type, core objective and associated device of each subtask are identified.

[0077] Output a combined task analysis result that includes the independent analysis results of each subtask.

[0078] For a single subtask operation task, the output includes structured information such as task type identifier, core objective description, and associated device list. Its purpose is to provide clear verification guidance for simple operation tasks.

[0079] When an operation task contains multiple interrelated but independently executable operational objectives, it is broken down into multiple independent sub-tasks. The decomposition logic is based on the professionalism and independence of power switching operations, ensuring that the analysis of each sub-task accurately corresponds to its exclusive verification standard. The unified output is formed by integrating the independent analysis results of each sub-task after decomposition, which not only retains the core analysis information of each sub-task, but also clarifies the relationship between the sub-tasks.

[0080] According to the above embodiments, in a specific implementation scheme, the verification and error correction module 13 has an error correlation analysis function. When an error is detected in a certain step of the operation ticket to be verified, it automatically traces the impact of the error on subsequent related operation steps and outputs all chain errors, error root causes and corresponding error correction suggestions at once.

[0081] First, the basic step of the verification and error correction module 13 is to call the standard reference information based on the task analysis results, compare the operation ticket to be verified with the standard reference, and identify the initial error in a certain step. Since the steps of power switching operation have a very strong logical sequence and conditional dependencies, the initial error often leads to subsequent steps going wrong from the source. Therefore, accurately identifying the initial error is the foundation for ensuring the effectiveness of correlation analysis.

[0082] After identifying the initial error, the module automatically traces its impact on subsequent related operation steps. The core purpose of this step is to address the pain point of isolated error correction in traditional verification. In real-world scenarios, manual review or simple automated verification often only identifies a single error. After the operator makes corrections, derivative errors may still exist, leading to repeated verification and low efficiency. The module will check each subsequent step for failure or error due to the initial error based on the logical relationships between operation steps (such as sequential relationships and conditional relationships) and device association relationships.

[0083] Based on the above principles, the module ultimately outputs the root cause of the error, all cascading errors, and corresponding error correction suggestions in one go, which greatly reduces the number of times operation tickets need to be modified and the verification process, alleviates the workload of operators, and improves operation and maintenance efficiency.

[0084] According to the above embodiments, in a specific implementation scheme, the verification and error correction module 13 compares the operation ticket to be verified with the standard basis information, including: comparing the operation ticket to be verified with the standard basis information item by item according to at least one dimension of operation steps, operation object, operation logic, and operation conditions; the errors in the operation ticket to be verified include at least one of the following: missing operation steps, incorrect operation order, misselected operation object, omission of operation conditions, and logical conflict.

[0085] The verification and error correction module 13 selects appropriate comparison dimensions based on the task analysis results output by the semantic analysis module 12. Since different operational tasks have different verification priorities, it is unnecessary to enable all dimensions every time. Instead, at least one dimension is selected for comparison to ensure verification accuracy while avoiding redundant comparisons that reduce efficiency. "At least one dimension" does not mean that only a single dimension can be used; rather, it can be flexibly adapted according to task characteristics. All four dimensions can also be enabled to ensure no verification blind spots.

[0086] The item-by-item comparison breaks down each step of the operation ticket into four parts: operation steps, operation objects, operation logic, and operation conditions, and matches them with the corresponding content in the standard reference information. Item-by-item comparison is not a mechanical comparison of text, but rather a comparison based on the logical diagram mentioned earlier. As long as the core elements are consistent (such as the same operation object number or the same action), even if the descriptions are different, it is judged as correct, avoiding misjudgment.

[0087] Preferably, error types are classified, with different error types corresponding to different risk levels and modification logic (e.g., incorrect operation sequence is a fatal error and needs to be modified first; missing operation conditions is an important error and needs to be supplemented and improved). Classification can help operators handle errors according to priority.

[0088] According to the above embodiments, in a specific implementation scheme, the secondary confirmation module 14 is used to determine whether the source of the standard basis corresponding to the error correction information is unique and whether the error correction suggestion is consistent with the standard basis information based on the standard basis information in the knowledge base module 11. If both are satisfied, the verification is deemed successful and the error correction information is output. If there is a conflict in the source of the standard basis or the error correction suggestion is inconsistent with the standard basis information, the error correction information is returned to the verification and error correction module 13 for reprocessing.

[0089] First, the secondary confirmation module 14 retrieves the standard basis information corresponding to the error correction information from the knowledge base module 11 to determine whether the source of the standard basis corresponding to the error correction information is unique and whether the error correction suggestion is consistent with the standard basis information. Since the error correction result of the operation ticket directly guides the switching operation, if the standard referenced by the error correction information is conflicting, or if the suggestion itself deviates from the standard, it may cause the operator to modify according to the incorrect suggestion, resulting in a more serious safety accident.

[0090] For example, after the error correction module 13 makes an error correction suggestion, the secondary confirmation module 14 will first check whether there are other contradictory versions of the standard basis cited by the suggestion in the knowledge base (such as no other procedures have different requirements for the same operation sequence) to ensure that the source is unique; then it will check whether the error correction suggestion is completely consistent with the clause of the procedure to ensure the consistency of the suggestion.

[0091] When both verification dimensions are satisfied, it indicates that the error correction information has no standard conflict and meets compliance requirements. It is judged as verified and output, ensuring that subsequent operation ticket modifications have a reliable basis. If there is a conflict in the source of the standard basis (such as multiple conflicting instructions for a certain operation in the knowledge base), or the error correction suggestion is inconsistent with the standard basis (such as the standard requires grounding before maintenance, while the suggestion is maintenance before grounding), it is judged as verified as not passing. The error correction information is returned to the verification and error correction module 13 with the reason for the return (such as a conflict in the source of the standard basis: the requirements of procedure A and procedure B are contradictory, or the error correction suggestion is inconsistent with standard X), so that the verification and error correction module 13 can make targeted corrections.

[0092] According to the above embodiments, in a specific implementation scheme, the secondary confirmation module 14 further includes: a rule conflict processing unit, which is used to output a list of conflicting rules and the corresponding rule sources when a conflict is detected in the standard basis source corresponding to the error correction information, and after receiving the confirmation instruction, update the corresponding rules in the knowledge base module 11 and complete the secondary verification.

[0093] The secondary confirmation module 14 includes a manual intervention interface for receiving rejection or modification control instructions for error correction information.

[0094] First, the workflow of the rule conflict handling unit can be broken down into conflict detection, information output, instruction reception, rule update, and secondary verification. Since substation rule information may come from different sources (such as national industry standards, local operation and maintenance specifications, and equipment manufacturer requirements), and rules may be updated asynchronously at different times, it is very easy for standard basis conflicts to occur. Simply returning the error correction information to the verification and error correction module 13 cannot fundamentally solve the problem. It is necessary to unify the rules before completing the verification.

[0095] For example, ① the conflict is detected; ② a list of conflict rules is output (clearly specifying the complete content of the two conflicting rules) and the source of the rules (labeling the procedure name, version, and clause number); ③ confirmation instructions are received from the administrator (e.g., confirming that standard A is the currently applicable standard); ④ the standard basis corresponding to this operation in the knowledge base is updated to the confirmed optimal rule, overriding the original conflicting rule; ⑤ based on the updated unified standard, the error correction information is re-verified, and if the error correction suggestion is consistent with the optimal rule, the verification is deemed successful.

[0096] In real-world scenarios, there may be special cases that automated verification cannot cover. For example, the standard cited in the error correction information may be correct, but the error correction suggestions need to be adjusted based on temporary on-site conditions; or the automated verification may misjudge the error correction information as inconsistent with the standard. In these cases, manual intervention is required to ensure the reasonableness of the verification results. If the secondary confirmation module 14 misjudges the error correction suggestions as inconsistent with the standard, the administrator can send a rejection instruction through this interface, specifying the reason for rejection, and trigger the secondary confirmation module 14 to re-verify. The manual intervention interface can be triggered at any stage of the secondary verification (such as before verification passes or after verification fails), but it must be executed based on reasonable reasons to avoid arbitrary intervention in the automated process and ensure the standardization of system operation.

[0097] Preferably, any manual intervention instructions (rejection / modification) will be recorded synchronously in the system log.

[0098] This collaborative design retains the efficiency of the original automated verification while covering special scenarios through specialized functions and manual interfaces, making the secondary confirmation module 14 more comprehensive and better suited to actual operation and maintenance needs.

[0099] According to the above embodiments, in a specific implementation scheme, the format of the operation ticket to be verified is a document format, and the format of the verification-passed error correction information output by the output module 15 is consistent with the format of the operation ticket to be verified.

[0100] The document format of the operation ticket to be verified refers to the standardized document format commonly used in the power industry. The error correction information output by the output module 15 after verification is consistent with the operation ticket to be verified in terms of document type, layout structure, step numbering rules, and content presentation method, ensuring that operators can directly compare and modify it without additional format adjustments.

[0101] According to the above embodiments, in a specific implementation scheme, the knowledge base module 11 further includes: an update triggering unit, used to set an expiration date for the stored standard basis information, mark the standard basis information that has exceeded the expiration date as pending review and issue a reminder message.

[0102] The update trigger unit sets an expiration period for each piece of standard information stored in the knowledge base. The expiration period is not a fixed, uniform duration, but is set differently based on the type of information.

[0103] When standard information exceeds its set validity period, the update triggering unit will automatically mark it as pending review. In actual operation and maintenance scenarios, if there are expired and unupdated standards in the knowledge base, the verification and correction module 13 may call invalid standards, generate incorrect correction suggestions, and thus cause operational accidents. Specifically, information marked as pending review will be automatically hidden or marked with a warning by the system.

[0104] For example, when the verification and error correction module 13 calls the standard basis, it will prioritize filtering information with valid status. If an operation can only match information with the pending review status, it will add a prompt when calling: "This basis has expired and its validity needs to be verified" to avoid blind citation. At the same time, the knowledge base backend will classify the "pending review status" information separately to facilitate centralized processing by administrators.

[0105] The update trigger unit will send targeted reminders while marking expired information, helping managers quickly locate target information and reduce processing time.

[0106] The operation ticket verification system provided in this application has been described in detail above. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

[0107] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A ticket verification system, characterized in that, include: The knowledge base module is used to store the standard basis information required for operation ticket verification. The standard basis information includes at least substation rule information and equipment-related information. The semantic analysis module is used to receive operation tasks, perform semantic parsing on the operation tasks, and output task analysis results corresponding to the operation tasks. The verification and error correction module is connected to the knowledge base module and the semantic analysis module respectively. It is used to obtain manually written operation tickets to be verified, call the corresponding standard basis information from the knowledge base module based on the task analysis results, compare the operation tickets to be verified with the standard basis information, identify errors in the operation tickets to be verified, and generate error correction information. The secondary confirmation module is connected to the knowledge base module and the verification and error correction module respectively. It is used to obtain the error correction information, perform secondary comparison and verification of the error correction information with the standard basis information in the knowledge base module, and output the error correction information that has passed the verification. The output module, connected to the secondary confirmation module, is used to output the verified error correction information in a preset format.

2. The operation ticket verification system according to claim 1, characterized in that, The knowledge base module is built using a relational database; the knowledge base module also includes an automatic synchronization interface; The knowledge base module connects with the substation SCADA system and equipment operation and maintenance management platform through an automatic synchronization interface to receive updated standard basis information. The substation rule-based information includes at least one of the following: on-site operation procedures, typical operation tickets, protection procedures, equipment operation and maintenance regulations, equipment ledgers, and equipment manuals; the equipment-related information includes at least one of the following: equipment attribute information, equipment real-time status information, and equipment association information.

3. The operation ticket verification system according to claim 1, characterized in that, The semantic analysis module is implemented based on a preset semantic model; the preset semantic model is a model trained by power scenario semantic knowledge, which includes at least one of: typical operation tickets, dispatch management procedures and historical operation tickets. When the preset semantic model performs semantic parsing on the operation task, if the task ambiguity exceeds a preset threshold, a candidate task list is generated, and the operator receives a selection instruction based on the candidate task list to determine the final task analysis result.

4. The operation ticket verification system according to claim 3, characterized in that, The semantic analysis module performs semantic parsing on the operation task, including: Identify the task type, core objective, and associated equipment of the operation task, and output basic analysis results including task type identifier, core objective description, and associated equipment list; If the operation task contains multiple sub-tasks, the operation task is split into sub-tasks, and the task type, core target and associated device of each sub-task are identified respectively; Output a combined task analysis result that includes the independent analysis results of each subtask.

5. The operation ticket verification system according to claim 1, characterized in that, The verification and error correction module has an error correlation analysis function. When an error is detected in a certain step of the operation ticket to be verified, it automatically traces the impact of the error on subsequent related operation steps and outputs all chain errors, error root causes and corresponding error correction suggestions at once.

6. The operation ticket verification system according to claim 5, characterized in that, The verification and error correction module compares the operation ticket to be verified with the standard basis information, including: comparing the operation ticket to be verified with the standard basis information item by item according to at least one of the following dimensions: operation steps, operation object, operation logic, and operation conditions; the errors in the operation ticket to be verified include at least one of the following: missing operation steps, incorrect operation order, misselected operation object, omission of operation conditions, and logical conflict.

7. The operation ticket verification system according to claim 1, characterized in that, The secondary confirmation module is used to determine whether the source of the standard basis corresponding to the error correction information is unique and whether the error correction suggestion is consistent with the standard basis information based on the standard basis information in the knowledge base module. If both are satisfied, the verification is deemed successful and the error correction information is output. If there is a conflict in the source of the standard basis or the error correction suggestion is inconsistent with the standard basis information, the error correction information is returned to the verification and error correction module for reprocessing.

8. The operation ticket verification system according to claim 7, characterized in that, The secondary confirmation module further includes: a rule conflict processing unit, which is used to output a list of conflicting rules and the corresponding rule sources when a conflict is detected in the standard basis source corresponding to the error correction information, and after receiving the confirmation instruction, update the corresponding rules in the knowledge base module and complete the secondary verification. The secondary confirmation module includes a manual intervention interface for receiving rejection or modification control instructions for the error correction information.

9. The operation ticket verification system according to claim 1, characterized in that, The operation ticket to be verified is in document format, and the error correction information output by the output module after successful verification is in the same format as the operation ticket to be verified.

10. The operation ticket verification system according to claim 2, characterized in that, The knowledge base module also includes an update triggering unit, which is used to set an expiration date for the stored standard reference information, mark the standard reference information that has expired as pending review and issue a reminder message.

Images