An operation ticket step checking method based on secondary equipment account, an operation ticket checking terminal and a computer program product

Abstract

The application discloses a kind of based on secondary equipment account operation ticket step checking method, operation ticket checking terminal and computer program product, wherein, the method is extracted by constructing double index structure including strict account and low confidence account, site identification, screen cabinet context and element number key from operation ticket, and positioning matching is carried out gradually according to the order of site level, screen cabinet level, element number level. For the case that subitem omits screen cabinet information, screen cabinet context is determined by context inheritance relationship from main item to subitem;For the scene that soft pressboard has no entity screen cabinet name, candidate matching is carried out based on context feature and screen cabinet alias similarity. At the same time, hierarchical prompt and similar merging strategy are used to converge redundant alarm, and review prompt is generated for low confidence account hit. The application effectively avoids misjudgment caused by mis-matching of same station across screen cabinet and account defect, and significantly improves the accuracy of operation ticket checking and the on-site availability of results.

Description

Technical Field

[0001] This invention relates to the field of intelligent verification technology for power system operation tickets, specifically to a method for verifying operation ticket steps based on secondary equipment ledgers, an operation ticket verification terminal, and a computer program product. Background Technology

[0002] During substation operation and maintenance, operation tickets are crucial for ensuring the correct operation of secondary equipment. These tickets frequently involve the activation and deactivation of components such as protection switches (hard switches), soft switches, and secondary air circuit breakers. To reduce the risk of human error, it is typically necessary to automatically verify the operation ticket steps based on standardized equipment ledgers to identify the operated objects and verify their existence and consistency of status.

[0003] However, existing verification schemes face multiple difficulties in practical applications. First, within the same substation, hard switchboards or air circuit breakers with the same number may be configured repeatedly in different cabinets. If matching is based solely on the substation and component number, it is easy to incorrectly associate components with the same number in other cabinets with the current operating procedure, leading to mismatches.

[0004] Secondly, the text of on-site operation tickets generally uses a hierarchical abbreviation method for the steps. For example, the main step specifies the name of the cabinet, while multiple sub-steps only list the pressure plate or air switch number without repeating the information of the cabinet to which they belong. In addition, the logical affiliation of soft pressure plate operations involved in the background monitoring system, monitoring backend, or protection sub-diagrams often does not correspond one-to-one with the physical cabinet, making it difficult to extract the clear cabinet name. If only the text of the current operation line is matched in isolation, the lack of contextual information will result in missed identification or incorrect prompts.

[0005] Furthermore, the standard pressure plate ledger itself, which serves as the basis for verification, often suffers from incomplete data, including missing site information, missing cabinet information, low record confidence, and aliasing differences in cabinet names. If the missing ledger information is directly converted into error reports for each step, it will generate a large number of repetitive and inefficient alarm prompts, seriously affecting the on-site user experience and the reliability of the verification results. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide a method for verifying operation ticket steps based on secondary equipment ledgers, an operation ticket verification terminal and a computer program product, so as to improve the accuracy and usability of operation ticket verification while ensuring security.

[0007] To solve the above technical problems, the present invention provides a method for verifying operation ticket steps based on secondary equipment ledgers, comprising the following steps: Obtain the operation ticket to be verified and the pre-established standard ledger of secondary equipment, and build a ledger index based on the standard ledger of secondary equipment; each record in the standard ledger of secondary equipment is associated with at least a site identifier, a cabinet identifier and a component number; The station identifier is extracted from the ticket information of the operation ticket, and the station identifier is standardized to obtain the station key; For the operation steps in the operation ticket, establish the context inheritance relationship between the main item and the sub-item, and determine the screen cabinet context of the current step based on at least one of the context inheritance relationship and the text content of the current step. Extract the secondary device number from the text content of the current step, and standardize the secondary device number to obtain the component number key; Using the site key, the cabinet context, and the component number key as search criteria, the system performs location matching in the ledger index level by level, according to the order of site level, cabinet level, and component number level, to obtain the matching results for each level. The verification result of the operation ticket is generated based on the matching results of each level.

[0008] Preferably, the normalization process for the site identifier includes at least one of the following processes: Extract the station name from the location name on the ticket; Remove the substation suffix and unify the suffixes; Normalize whitespace characters; Remove punctuation marks.

[0009] Preferably, determining the context of the current step based on at least one of the context inheritance relationship and the text content of the current step includes: When a brief description of the display cabinet is identified in the text content of the current step, the context of the display cabinet is determined based on the brief description of the display cabinet. When the description of the cabinet is not recognized in the text content of the current step, the cabinet context that belongs to the same main item as the current step is inherited as the cabinet context.

[0010] Preferably, the step of locating and matching in the ledger index level by level according to the order of site level, cabinet level, and component number level includes: At the site level, the site key is used to search the ledger index to determine whether a site ledger corresponding to the site key exists. At the cabinet level, within the scope of the hit sites, a search is performed using the cabinet context to determine whether a corresponding cabinet account exists. At the component number level, within the range of matched sites and cabinets, the component number key is used to search and determine whether the number exists within the cabinet.

[0011] Preferably, generating the verification result of the operation ticket based on the matching results of each level includes: When the matching result of any of the site level, the cabinet level, or the component number level is unsuccessful, the matching of the lower levels is terminated at the unsuccessful level, and a verification result corresponding to the unsuccessful level is generated.

[0012] Preferably, the verification result includes hierarchical verification prompts, and generating hierarchical verification prompts includes at least one of the following processes: When the matching result at the site level is unsuccessful, a verification prompt indicating that the site lacks an account will be output at the ticket level or the first related step. When a site involves multiple cabinets and the matching results of all the cabinets are unsuccessful, the missing cases of the multiple cabinets are merged into a single verification prompt output. The single verification prompt includes the number of cabinets involved and a cabinet example. When the matching result of a single cabinet is unsuccessful, a verification prompt for the missing ledger of the corresponding cabinet will be output at the cabinet level; When the matching result at the component number level is unsuccessful, a verification prompt indicating that the corresponding number is missing is output at the component number level.

[0013] Preferably, the method further includes: When the current step is in the background machine, monitoring background, protection sub-map, interval sub-map or soft pressure plate status context, a soft pressure plate context feature is constructed based on the operation task, the text before the colon of the step and the display name of the screen cabinet, and the similarity between the soft pressure plate context feature and the screen cabinet alias of the soft pressure plate record in the ledger index is calculated, and the matching result of the component number level is determined based on the similarity.

[0014] Preferably, the ledger index includes a strict ledger record index and a low-confidence ledger record index; When the component number level does not match the strict ledger record index, query the low confidence ledger record index; If the low-confidence ledger record index is hit, a verification prompt is generated to check the ledger identification results.

[0015] The present invention also provides an operation ticket verification terminal, comprising: One or more processors; Memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, and the one or more applications are configured to perform the operation ticket step verification method based on the secondary equipment ledger.

[0016] The present invention also provides a computer program product, including computer instructions, which instruct a computer device to perform the operation corresponding to the operation ticket step verification method based on the secondary equipment ledger.

[0017] The beneficial effects of this invention are as follows: By constructing a three-level hierarchical positioning and matching mechanism for site, cabinet, and component numbers, it effectively avoids mismatches of secondary devices with the same number under different cabinets at the same site. By combining the contextual inheritance relationship from main item to sub-item to determine the cabinet context, it solves the problem of missing ledger location caused by omitting cabinet information in operation ticket sub-items. For ledger missing cases, a layered prompting and similar output merging strategy is adopted to converge redundant alarms to the corresponding level, significantly improving the readability of the verification results. For low-confidence ledger records, by separating the index and generating review prompts instead of directly judging errors, the risk of misjudgment caused by ledger data quality defects is reduced. Furthermore, for soft pressure plate contexts such as back-end machines and protection sub-maps, candidate matching is performed based on contextual features and cabinet alias similarity, reducing false alarms in scenarios without physical cabinet names. Overall, this invention effectively suppresses noise prompts while ensuring verification accuracy, enhancing the robustness and on-site usability of the audit results. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a method for verifying operation tickets based on a secondary equipment ledger, according to an embodiment of the present invention.

[0020] Figure 2 This is an overall architecture diagram of the operation ticket ledger constraint audit provided in an embodiment of the present invention.

[0021] Figure 3 This is a flowchart illustrating the three-level location process for station cabinet numbers in an embodiment of the present invention.

[0022] Figure 4 This is the output diagram of layered noise reduction for missing ledgers in an embodiment of the present invention.

[0023] Figure 5This is the candidate matching diagram of the background soft pressure plate context in the embodiment of the present invention.

[0024] Figure 6 This is a closed-loop diagram for low-confidence ledger verification in an embodiment of the present invention. Detailed Implementation

[0025] The following description of the embodiments is taken with reference to the accompanying drawings, which illustrate specific embodiments in which the invention can be implemented.

[0026] Please refer to Figure 1 As shown, Embodiment 1 of the present invention provides a method for verifying operation ticket steps based on secondary equipment ledgers, including the following steps: Obtain the operation ticket to be verified and the pre-established standard ledger of secondary equipment, and build a ledger index based on the standard ledger of secondary equipment; each record in the standard ledger of secondary equipment is associated with at least a site identifier, a cabinet identifier and a component number; The station identifier is extracted from the ticket information of the operation ticket, and the station identifier is standardized to obtain the station key; For the operation steps in the operation ticket, establish the context inheritance relationship between the main item and the sub-item, and determine the screen cabinet context of the current step based on at least one of the context inheritance relationship and the text content of the current step. Extract the secondary device number from the text content of the current step, and standardize the secondary device number to obtain the component number key; Using the site key, the cabinet context, and the component number key as search criteria, the system performs location matching in the ledger index level by level, according to the order of site level, cabinet level, and component number level, to obtain the matching results for each level. The verification result of the operation ticket is generated based on the matching results of each level.

[0027] It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of this invention can be combined with each other. The execution order of the method steps of this invention can be adjusted, executed in parallel, or merged according to actual needs, unless there is a logical dependency (e.g., site keys must be obtained before site hierarchy matching can be performed). This does not affect the implementation of the technical solution of this invention. The ordinal numbers such as "first" and "second" appearing in this invention are only used to distinguish different objects or steps and do not indicate any limitation on order, quantity, or importance.

[0028] To facilitate a unified understanding, the following definitions are provided for some of the terms involved in this invention: "Secondary equipment" refers to auxiliary equipment used for monitoring, controlling, regulating, and protecting primary equipment. In this invention, it exemplarily includes pressure plates, flexible pressure plates, and air switches. A "pressure plate" (also known as a connecting piece) is a physical enabling / disabling element installed on a protection cabinet or control cabinet; a "flexible pressure plate" is a logical enabling / disabling element present in a protection device, back-end unit, monitoring back-end, or protection sub-diagram, and its operation item may not correspond to the name of a physical cabinet in the operation ticket; an "air switch" is a switching element in a secondary circuit.

[0029] The "Standard Ledger for Secondary Equipment" (hereinafter referred to as the Standard Ledger or Ledger) is a pre-established data set used to record the configuration information of secondary equipment. Each ledger record is associated with at least three fields: site identifier, cabinet identifier, and component number, and can be further associated with fields such as confidence level and cabinet alias.

[0030] "Site Identifier" represents the name or code of the substation or plant; "Site Key" is a standardized site identifier obtained after normalizing the location name on the ticket, used for ledger retrieval. "Cabinet Identifier" represents the name or code of the cabinet; "Cabinet Context" is the cabinet attribution information used when matching ledgers for a specific operation step; "Cabinet Description" is the text segment directly appearing in the step text that refers to the cabinet. "Component Number" is the number of the pressure plate, soft pressure plate, or air switch; "Component Number Key" is a standardized number obtained after normalizing the component number.

[0031] "Strict ledger records" refer to ledger records with a confidence level reaching a preset threshold and all three fields—site identifier, cabinet identifier, and component number—are complete and valid. "Low-confidence ledger records" refer to ledger records with a confidence level below the preset threshold, or missing fields, or cabinet names with alias differences, and therefore not yet confirmed as strict records. The "ledger index" (or ledger snapshot) is a data structure pre-built based on standard ledgers to accelerate retrieval. "Main items" and "sub-items" represent the hierarchical structure of operation ticket steps. Main items typically record more complete information about the operation object (such as cabinet name), while sub-items typically record more concise operation content (such as only the component number).

[0032] The technical solution of the present invention will now be described in detail with reference to the accompanying drawings.

[0033] In one embodiment, the operation ticket step verification method provided by this invention can be executed by an operation ticket verification terminal. The terminal is exemplarily a server, workstation, or embedded computing device deployed locally at a substation, a centralized control station, or a dispatch master station. The terminal includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the following steps.

[0034] Furthermore, the data source relied upon by the terminal when executing the method may include one or more combinations of the following: locally stored structured tables, the text of the operation ticket, the standard ledger, a pre-built rule base, and a historical ticket set. The rule base provides rules for site name normalization, cabinet alias mapping, component number identification, and contextual identification, etc.; the historical ticket set can be used to assist in contextual identification or alias mining. The specific form of the data source does not constitute a limitation of the present invention.

[0035] like Figure 2 As shown, the terminal uses the operation ticket and standard ledger as two input sources. The overall processing flow includes: operation ticket input, standard ledger snapshot construction, ticket site identification, step component extraction, cabinet context inheritance, three-level location matching, soft pressure plate context matching, and hierarchical review output. The construction of the standard ledger snapshot and the parsing of the operation ticket can be performed in parallel or sequentially. Step component extraction, cabinet context inheritance, three-level location matching, and soft pressure plate context matching are executed cyclically for each relevant step in the operation ticket, ultimately summarizing to form the hierarchical review output. The following sections further elaborate on each step according to the logical order of data preparation, information extraction, location matching, and result generation.

[0036] The terminal receives the operation ticket to be verified and a pre-established standard ledger of secondary equipment, and constructs a ledger index based on the standard ledger. In one embodiment, when constructing the ledger index, the records in the standard ledger are divided into two categories according to confidence level and field completeness: strict ledger records and low-confidence ledger records, and strict ledger record indexes and low-confidence ledger record indexes are constructed accordingly. Specifically, records with a confidence level reaching a preset threshold and complete in all three fields (site identifier, cabinet identifier, and component number) are included in the strict ledger record index; records with a confidence level below the preset threshold, or missing in any of the three fields, or with alias differences in cabinet naming are included in the low-confidence ledger record index. The preset threshold can be pre-set by those skilled in the art based on the quality of the ledger data, for example, exemplarily set to 0.8, 0.9, etc., and this invention does not limit this. Through the separate construction of the above dual indexes, subsequent matching can prioritize judgment based on strict records, and only query low-confidence records when strict records are not matched, thereby avoiding the direct conversion of the uncertainty of the ledger itself into incorrect judgment of the operation ticket.

[0037] Furthermore, the ledger index exemplarily employs a multi-level index structure with site identifier as the first level, cabinet identifier as the second level, and component number as the third level. This can be implemented using a multi-level hash table, inverted index, or tree index, to facilitate rapid hierarchical retrieval during three-level location matching. Optionally, the ledger index also includes a cabinet alias index, used to record the correspondence between different names (aliases) of the same cabinet, to support cabinet alias similarity matching as described later. The specific data structure of the index is merely an example; those skilled in the art can implement it using other equivalent data organization methods.

[0038] The terminal extracts the station identifier from the ticket information (such as the location name on the ticket) and performs normalization processing on the station identifier to obtain the station key.

[0039] In one implementation, the normalization process includes at least one of the following processes, and these processes can be combined: extracting the station name from the ticket location name to remove redundant descriptive text from the location description; removing and standardizing substation suffixes, for example, unifying different suffixes such as "substation," "transformer station," "station," and "transformer" into the same standard form or removing them; standardizing whitespace characters, for example, unifying full-width spaces, half-width spaces, tabs, and consecutive whitespace; and removing punctuation marks, for example, removing Chinese and English parentheses, commas, periods, etc. For example, the terminal can use preset regular expressions, suffix lists, or alias mapping tables to complete the above normalization. After normalization, ticket location names with different writing styles but pointing to the same station (e.g., "XX substation," "XX station," "XX transformer") will be mapped to the same station key, thereby reducing station level matching failures caused by writing differences.

[0040] For the operation steps in the operation ticket, the terminal establishes a context inheritance relationship between the main item and the sub-item, and determines the screen cabinet context of the current step based on at least one of the context inheritance relationship and the text content of the current step.

[0041] In one implementation, the terminal first constructs the hierarchical relationship between main items and sub-items based on the hierarchical structure of the operation ticket, for example, using a tree structure or a "main item-sub-item" linked list, and maintains a pointer or stack structure pointing to the current main item's cabinet context. Based on this, for the current step, the terminal prioritizes identifying a cabinet summary in the text content of that step itself; when a cabinet summary is identified, it determines the cabinet context of the current step. When a cabinet summary is not identified in the text content of the current step (this is common in sub-items that only record component numbers), the terminal inherits the cabinet context belonging to the same main item as the current step, as the cabinet context of the current step. Through the above "line-first, missing inheritance" mechanism, the writing characteristics of operation tickets where the main item specifies the cabinet name and the sub-items omit the cabinet name can be correctly handled, avoiding the omission of cabinet information due to isolated matching of single-line text.

[0042] It should be understood that for soft pressure plate operation items originating from the back-end machine, monitoring back-end, or protection sub-map, their text may not contain a brief description of the physical cabinet corresponding to the physical cabinet name, nor can there be any inherited physical cabinet context. In this case, the cabinet context may be empty or a logical context, and the terminal will process it in conjunction with the soft pressure plate context matching described in Part VII below.

[0043] The terminal extracts the secondary equipment number from the text content of the current step and performs normalization processing on the secondary equipment number to obtain a component number key. In one embodiment, the terminal identifies the pressure plate number, soft pressure plate number, or air switch number from the step text according to preset component number recognition rules (e.g., number format rules, keyword rules, or patterns in a rule base), and adds a component type mark to the extracted number to distinguish between pressure plates, soft pressure plates, and air switches. Subsequently, the terminal performs normalization processing on the secondary equipment number, which includes at least one of the following: removing blank characters and punctuation marks from the number; unifying the case and full-width / half-width characters of the number; and removing the cabinet prefix or status description text (e.g., action or status words such as "input," "output," "trip," etc.) attached to the number. The normalized component number key is used for comparison with the ledger at the component number level.

[0044] The terminal uses the site key, the cabinet context, and the component number key as search conditions, and performs location matching in the ledger index level by level in the order of site level, cabinet level, and component number level to obtain the matching results of each level, and generates the verification result of the operation ticket based on the matching results of each level.

[0045] like Figure 3As shown, the three-level positioning and matching process includes: determining the site key, determining whether the site ledger exists, determining the screen cabinet context, determining whether the screen cabinet ledger exists, extracting the component number, determining whether the number within the screen exists, performing low-confidence record judgment, and outputting the corresponding result accordingly.

[0046] Specifically, at the site level, the terminal searches the ledger index using the site key to determine if a site ledger corresponding to that site key exists. At the cabinet level, the terminal searches within the matched site range using the cabinet context to determine if a corresponding cabinet ledger exists. At the component number level, the terminal searches within the matched site and cabinet range using the component number key to determine if the number exists within the cabinet. These three levels constitute a sequential positioning structure, with the search results of the upper level constraining the search range of the lower level. This limits secondary devices with the same number but belonging to different cabinets to comparison within the correct cabinet range, helping to avoid misjudging components with the same number in other cabinets as matching objects due to searching only by site and number.

[0047] Furthermore, in one embodiment, when the matching result of any of the site level, the cabinet level, or the component number level is unsuccessful, the terminal terminates the matching of lower levels at the unsuccessful level and generates a verification result corresponding to the unsuccessful level. In other words, the terminal does not continue to enumerate downwards across unsuccessful levels, thereby avoiding meaningless line-by-line comparisons of the numbers within the screen and generating misleading matching or prompts when the site or cabinet cannot yet be determined.

[0048] In response to missing records during the matching process, the terminal generates hierarchical verification prompts according to the level at which the missing records are located. Furthermore, when there are multiple similar missing records at the same level, the terminal merges these multiple similar missing records into a single verification prompt, which includes the number of cabinets involved and an example of the cabinet.

[0049] like Figure 4 As shown, the generation of the hierarchical verification prompts follows the principle of "aggregating by level and merging similar items," and includes the following examples: When the station to which the operation ticket belongs does not match the standard ledger, and the operation ticket contains a pressure plate or air switch operation item, the terminal only outputs a verification prompt that the station lacks a ledger at the ticket level or the first relevant step, instead of outputting the missing result for each component under the station one by one, thereby converging the station-level ledger missing into a single prompt.

[0050] When an operation ticket involves multiple cabinets at the same site, and none of the multiple cabinets can be matched with a corresponding cabinet account, the terminal will output the missing cases of the multiple cabinets in a combined manner. The combined output includes the number of cabinets involved and cabinet examples (e.g., listing some cabinet names as examples), instead of enumerating each pressure plate or air switch number in each cabinet one by one.

[0051] When only a single cabinet is missing an entry, the terminal outputs a corresponding prompt at the cabinet level, without expanding downwards to each number within the cabinet.

[0052] When both the site and the cabinet exist, but the component number does not match the strict ledger record, the terminal outputs a corresponding prompt at the component number level and triggers the low confidence record judgment described in Part 9 below.

[0053] Through the aforementioned layering and merging mechanism, the terminal can control the prompts caused by the missing information in the ledger itself to a granularity corresponding to the level of the missing information. This helps reduce repetitive and redundant prompts and improves the readability and on-site usability of the verification results. It should be understood that the above-mentioned "merging into a single verification prompt output" is exemplarily manifested in the following way: the terminal aggregates the same level and type of missing information to generate a single aggregated prompt record containing a count and an example field, rather than generating an independent record for each component number.

[0054] When the current step is in the background machine, monitoring background, protection sub-map, interval sub-map or soft pressure plate status context, the terminal constructs soft pressure plate context features based on the operation task, the text before the colon of the step and the display name of the screen cabinet, and calculates the similarity between the soft pressure plate context features and the screen cabinet alias of the soft pressure plate record in the ledger index, and determines the matching result of the component number level based on the similarity.

[0055] like Figure 5 As shown, the soft pressure plate context matching includes: background / sub-image context recognition, extraction of text before the colon of task and step, extraction of soft pressure plate number, retrieval of soft pressure plate index on the same site, calculation of screen cabinet alias similarity, candidate score sorting, high confidence missing number prompt, and automatic noise reduction for unclear position.

[0056] Specifically, the terminal first determines whether the current step belongs to a context such as a backend machine, monitoring backend, protection sub-map, interval sub-map, or soft pressure plate status, based on context recognition rules. If it does, since soft pressure plate operation items in such contexts often do not correspond to physical cabinet names, the terminal switches to a context feature matching method. The terminal constructs soft pressure plate context features based on the operation task text, the text before the colon in the step, and the cabinet display name, and retrieves candidate cabinet aliases from the same-site soft pressure plate records in the ledger index. Subsequently, the terminal calculates the similarity between the soft pressure plate context features and each candidate cabinet alias, and sorts the candidate results by score based on the similarity. The similarity calculation method can use conventional string or semantic similarity algorithms in the field, such as edit distance, Jaccard similarity coefficient, cosine similarity based on word vectors, or similarity of multiple weighted combinations of features; this invention does not limit this.

[0057] In one implementation, when the highest similarity after sorting reaches a preset confidence threshold, the terminal determines the cabinet to which the soft pressure plate belongs and continues to determine whether a corresponding soft pressure plate number exists under that cabinet; if not, it outputs a high-confidence missing number prompt. When the similarity does not reach the confidence threshold, i.e., the location of the soft pressure plate is unclear, the terminal automatically performs noise reduction processing, such as not outputting a missing number prompt or only outputting a low-priority "to be verified" prompt, to avoid false prompts when the contextual information is insufficient to locate the cabinet.

[0058] In one implementation, the ledger index includes a strict ledger record index and a low-confidence ledger record index. When the component number level does not match the strict ledger record index, the terminal queries the low-confidence ledger record index; if it matches, a verification prompt is generated to check the ledger identification result, instead of directly determining that the operation ticket is incorrect.

[0059] like Figure 6As shown, the terminal categorizes ledger records into strict records and low-confidence records based on their confidence levels and indexes them separately. When an operation ticket hits a low-confidence record, the terminal outputs a prompt to review the ledger, instructing on-site or maintenance personnel to review the identification result of the corresponding ledger record. Optionally, after manual correction and confirmation, the ledger is updated back to the standard ledger, and the updated ledger record is reused in subsequent operation ticket reviews, thus forming a closed loop of "hitting low-confidence records—outputting a review prompt—correcting the ledger—subsequent reuse." It should be understood that the above-mentioned manual correction step is a human-computer interaction process. The actions performed by the terminal in this step are limited to outputting a review prompt and receiving and storing the corrected ledger. The core verification logic of the method is still completed unilaterally by the terminal. Through this closed loop, the terminal adopts a conservative strategy when there is uncertainty in the quality of the ledger data, presenting the uncertainty in the form of a review prompt rather than making a direct erroneous judgment, which helps to improve the robustness of the verification conclusion.

[0060] The terminal outputs a verification result containing the step sequence, problem type, review level, and ledger location information. The step sequence identifies the order of the corresponding operation steps in the operation ticket; the problem type indicates the category to which the problem belongs, such as missing ledger for the site, missing ledger for the display cabinet, missing internal number, low-confidence hit, unidentified display cabinet, or unclear location of the soft pressure plate; the review level indicates the urgency or confidence level of the recommended review for the problem; and the ledger location information provides the location of the site, display cabinet, and number corresponding to the problem in the ledger index, enabling on-site personnel to quickly locate and review it.

[0061] Furthermore, in one embodiment, when outputting the verification result, the terminal may simultaneously record one or more of the following information: the hit step, the hit ticket, the comparison ticket, the rule label, and the review level. The hit step and the hit ticket are used to trace back the specific steps and tickets that triggered the result; the comparison ticket is used to provide a reference when needed; and the rule label is used to identify the verification rule on which the result is based. This additional information helps on-site personnel to locate, trace, and review the output verification result.

[0062] Corresponding to the method for verifying operation ticket steps based on secondary equipment ledger in Embodiment 1 of the present invention, Embodiment 2 of the present invention also provides an operation ticket step verification terminal, including: One or more processors; Memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, and the one or more applications are configured to perform the operation ticket step verification method based on the secondary equipment ledger.

[0063] Corresponding to the method for verifying operation tickets based on secondary equipment ledgers in Embodiment 1 of the present invention, Embodiment 3 of the present invention also provides a computer program product, including computer instructions, which instruct computer equipment to perform the operation corresponding to the method for verifying operation tickets based on secondary equipment ledgers.

[0064] Preferably, the processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor, or the processor can be any conventional processor. The processor is the control center of the device, connecting various parts of the device through various interfaces and lines.

[0065] The memory mainly includes a program storage area and a data storage area. The program storage area can store the operating system, applications required for at least one function, etc., while the data storage area can store related data, etc. Furthermore, the memory can be a high-speed random access memory, or a non-volatile memory, such as a plug-in hard drive, a SmartMedia Card (SMC), a Secure Digital (SD) card, and a Flash Card, or other volatile solid-state storage devices.

[0066] It should be noted that the above-mentioned devices may include, but are not limited to, processors and memory, as will be understood by those skilled in the art.

[0067] For the working principle and process of the above embodiments, please refer to the description of Embodiment 1 of the present invention, which will not be repeated here.

[0068] Compared with existing technologies, this invention has the following significant advantages: By constructing a three-level hierarchical positioning and matching mechanism for site, cabinet, and component numbers, this invention effectively avoids mismatches of secondary devices with the same number under different cabinets at the same site. By combining the contextual inheritance relationship from main item to sub-item to determine the cabinet context, it solves the problem of missing ledger location caused by omitting cabinet information in operation ticket sub-items. For ledger missing cases, a layered prompting and similar output merging strategy is adopted to converge redundant alarms to the corresponding level, significantly improving the readability of the verification results. For low-confidence ledger records, by separating the index and generating review prompts instead of directly judging errors, the risk of misjudgment caused by ledger data quality defects is reduced. Furthermore, for soft pressure plate contexts such as back-end machines and protection sub-maps, candidate matching is performed based on contextual features and cabinet alias similarity, reducing false alarms in scenarios without physical cabinet names. Overall, this invention effectively suppresses noise prompts while ensuring verification accuracy, enhancing the robustness and on-site usability of the audit results.

[0069] The above description is merely a preferred embodiment of the present invention and should not be construed as limiting the scope of the invention. Therefore, any equivalent variations made in accordance with the claims of the present invention are still within the scope of the present invention.

Claims

1. A method for verifying operation ticket steps based on secondary equipment ledgers, characterized in that, Includes the following steps: Obtain the operation ticket to be verified and the pre-established standard ledger of secondary equipment, and build a ledger index based on the standard ledger of secondary equipment; each record in the standard ledger of secondary equipment is associated with at least a site identifier, a cabinet identifier and a component number; The station identifier is extracted from the ticket information of the operation ticket, and the station identifier is standardized to obtain the station key; For the operation steps in the operation ticket, establish the context inheritance relationship between the main item and the sub-item, and determine the screen cabinet context of the current step based on at least one of the context inheritance relationship and the text content of the current step. Extract the secondary device number from the text content of the current step, and standardize the secondary device number to obtain the component number key; Using the site key, the cabinet context, and the component number key as search criteria, the system performs location matching in the ledger index level by level, according to the order of site level, cabinet level, and component number level, to obtain the matching results for each level. The verification result of the operation ticket is generated based on the matching results of each level.

2. The method according to claim 1, characterized in that, The standardization process for the site identifier includes at least one of the following processes: Extract the station name from the location name on the ticket; Remove the substation suffix and unify the suffixes; Normalize whitespace characters; Remove punctuation marks.

3. The method according to claim 1, characterized in that, Determining the cabinet context of the current step based on at least one of the context inheritance relationship and the text content of the current step includes: When a brief description of the display cabinet is identified in the text content of the current step, the context of the display cabinet is determined based on the brief description of the display cabinet. When the description of the cabinet is not recognized in the text content of the current step, the cabinet context that belongs to the same main item as the current step is inherited as the cabinet context.

4. The method according to claim 1, characterized in that, The step of locating and matching in the ledger index in the order of site level, cabinet level, and component number level includes: At the site level, the site key is used to search the ledger index to determine whether a site ledger corresponding to the site key exists. At the cabinet level, within the scope of the hit sites, a search is performed using the cabinet context to determine whether a corresponding cabinet account exists. At the component number level, within the range of matched sites and cabinets, the component number key is used to search and determine whether the number exists within the cabinet.

5. The method according to claim 4, characterized in that, The step of generating the verification result of the operation ticket based on the matching results of each level includes: When the matching result of any of the site level, the cabinet level, or the component number level is unsuccessful, the matching of the lower levels is terminated at the unsuccessful level, and a verification result corresponding to the unsuccessful level is generated.

6. The method according to claim 5, characterized in that, The verification result includes hierarchical verification prompts, and the generation of hierarchical verification prompts includes at least one of the following processes: When the matching result at the site level is unsuccessful, a verification prompt indicating that the site lacks an account will be output at the ticket level or the first related step. When a site involves multiple cabinets and the matching results of all the cabinets are unsuccessful, the missing cases of the multiple cabinets are merged into a single verification prompt output. The single verification prompt includes the number of cabinets involved and a cabinet example. When the matching result of a single cabinet is unsuccessful, a verification prompt for the missing ledger of the corresponding cabinet will be output at the cabinet level; When the matching result at the component number level is unsuccessful, a verification prompt indicating that the corresponding number is missing is output at the component number level.

7. The method according to claim 1, characterized in that, The method further includes: When the current step is in the background machine, monitoring background, protection sub-map, interval sub-map or soft pressure plate status context, a soft pressure plate context feature is constructed based on the operation task, the text before the colon of the step and the display name of the screen cabinet, and the similarity between the soft pressure plate context feature and the screen cabinet alias of the soft pressure plate record in the ledger index is calculated, and the matching result of the component number level is determined based on the similarity.

8. The method according to claim 1, characterized in that, The ledger index includes a strict ledger record index and a low-confidence ledger record index; When the component number level does not match the strict ledger record index, query the low confidence ledger record index; If the low-confidence ledger record index is hit, a verification prompt is generated to check the ledger identification results.

9. A ticket verification terminal, characterized in that, include: One or more processors; Memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications being configured to perform the operation ticket step verification method based on the secondary equipment ledger as described in any one of claims 1 to 8.

10. A computer program product, characterized in that, The method includes computer instructions that instruct a computer device to perform the operation corresponding to the operation ticket step verification method based on the secondary equipment ledger as described in any one of claims 1 to 8.

Images