A heavy haul railway dispatching instruction post-event checking method

Abstract

This application relates to a post-event inspection method for heavy-haul railway dispatching instructions, belonging to the field of track control technology, which can improve the business processing efficiency of heavy-haul railway dispatching instruction inspection. The method includes: associating dispatching instruction data with preset business data to generate a standardized instruction object carrying business characteristics to be inspected; determining and sending the standardized instruction object to the target inspection terminal corresponding to the standardized instruction object based on a preset allocation strategy; receiving error inspection data returned by the target inspection terminal, matching the error inspection data with a preset error dictionary to determine an error type marker; obtaining the state transition path corresponding to the error type marker, and driving the standardized instruction object to flow and update its state among multiple business processing nodes included in the state transition path until the flow state of the standardized instruction object is updated to a business closed-loop state.

Description

Technical Field

[0001] This application relates to the field of track control technology, and in particular to a method, apparatus, computer equipment, computer-readable storage medium, and computer program product for post-event inspection of dispatching instructions for heavy-haul railways. Background Technology

[0002] Dispatch instructions for heavy-haul railways are the legal basis for guiding train operations and equipment maintenance, and the accuracy of their contents is directly related to the safety and efficiency of railway transportation.

[0003] Currently, post-dispatch inspections of dispatch instructions mainly rely on manual, random offline checks. This is not only labor-intensive but also highly susceptible to missed inspections due to staff fatigue or differences in experience. Furthermore, the lack of standardized metrics leads to subjective differences in how inspectors characterize instruction anomalies, resulting in ambiguous error classifications, a lack of targeted rectification, and an inability to effectively relay high-frequency issues to the pre-processing stage. Given the objective context of heavy-haul railways—characterized by the wide impact of instructions and high error correction costs—the existing inefficient inspection methods are no longer sufficient to meet the high-safety operational requirements of railway network integration. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer equipment, computer-readable storage medium, and computer program product for post-event inspection of heavy-haul railway dispatching instructions to address the aforementioned technical problems.

[0005] Firstly, this application provides a method for post-event inspection of heavy-haul railway dispatching instructions, including:

[0006] Acquire the scheduling instruction data to be processed, associate the scheduling instruction data with preset business data, and generate a standardized instruction object to be inspected carrying business characteristics;

[0007] Based on a preset allocation strategy, the target inspection terminal corresponding to the standardized instruction object is determined, and the standardized instruction object is sent to the target inspection terminal.

[0008] Receive error checking data for the standardized instruction object returned by the target inspection terminal, match the error checking data with a preset error dictionary, and determine the error type label of the standardized instruction object;

[0009] Obtain the state transition path corresponding to the error type marker, and drive the standardized instruction object to flow and update its state among multiple business processing nodes included in the state transition path until the flow state of the standardized instruction object is updated to the business closed loop state.

[0010] In one embodiment, the step of associating the scheduling instruction data with preset service data to generate a standardized instruction object to be inspected carrying service characteristics includes:

[0011] The scheduling instruction data is subjected to structured feature extraction to obtain a set of instruction elements containing spatiotemporal feature attributes;

[0012] From the business data, obtain the associated business data that matches the spatiotemporal feature attributes;

[0013] The set of instruction elements and the associated business data are combined using a data structure to obtain the standardized instruction object to be inspected.

[0014] In one embodiment, determining the target inspection terminal corresponding to the standardized instruction object based on a preset allocation strategy includes:

[0015] Obtain the original issuer identifier corresponding to the standardized instruction object;

[0016] The terminal corresponding to the original publisher's identifier is removed from the preset first set of inspection terminals to obtain the second set of inspection terminals;

[0017] Obtain the current task queue load data of each terminal in the second inspection terminal set, and select the terminal with the smallest load from the second inspection terminal set as the target inspection terminal based on the load data.

[0018] In one embodiment, the error dictionary includes multiple error types and corresponding element verification rules for each error type;

[0019] The step of matching the error checking data with a preset error dictionary to determine the error type label of the standardized instruction object includes:

[0020] Extract the error classification field from the error check data;

[0021] The error classification field is matched with multiple error types in the error dictionary to determine the target error type of the error inspection data, and the target element verification rule bound to the target error type is obtained.

[0022] The business features in the standardized instruction object are validated based on the target element validation rules. If the validation result is unsuccessful, the error classification field is determined as the error type marker of the standardized instruction object.

[0023] In one embodiment, after determining the error type flag of the standardized instruction object, the method further includes:

[0024] Obtain the level feature field associated with the error classification field from the error checking data, and determine it as the error level label of the standardized instruction object;

[0025] Determine whether the error level flag matches a preset emergency error level;

[0026] If the emergency error level is matched, an audible and visual alarm message is generated, and a front-end rendering instruction is sent to update the display background color of the standardized instruction object to a preset warning color.

[0027] The audible and visual alarm information and the front-end rendering command are sent to the target inspection terminal.

[0028] In one embodiment, after the flow status of the standardized instruction object is updated to the business closed-loop status, the method further includes:

[0029] Based on the error type label, determine the error root cause report corresponding to the error inspection data, and based on the error root cause report, update the element verification rules in the error dictionary;

[0030] The updated element verification rules, as well as the scheduling instruction data, error type flags, and error level flags corresponding to the standardized instruction objects, are encrypted using a preset encryption algorithm and then saved to the business database.

[0031] In one embodiment, the business processing node includes a node to be rectified and a rectification review node, wherein the node to be rectified corresponds to a flow status of a pending rectification status, and the rectification review node corresponds to a flow status of a rectification review status.

[0032] The process of driving the standardized instruction object to flow and update its state among multiple business processing nodes included in the state transition path includes:

[0033] When the standardized instruction object is in a pending rectification stage, the circulation status of the standardized instruction object is updated to a pending rectification stage, and the standardized instruction object is sent to the corresponding scheduling initiation terminal.

[0034] The rectification review node receives the modification record returned by the standardized instruction object of the rectification status from the scheduling initiating terminal, and saves the modification record to the business database;

[0035] Based on the modification record, the circulation status is updated to the rectification and review status, and the rectification instruction data is sent to the corresponding target inspection terminal for comparison and verification.

[0036] If a verification pass instruction is received from the target inspection terminal, the flow status is updated to the business closed-loop status.

[0037] In one embodiment, after sending the standardized instruction object to the corresponding scheduling initiation terminal, the method further includes:

[0038] If an objection instruction for the error type flag is received from the scheduling initiating terminal, the flow status of the standardized instruction object is updated to the objection lock status;

[0039] The standardized instruction object that is in the objection lock state is sent to the preset arbitration terminal;

[0040] Obtain the arbitration result data returned by the arbitration terminal:

[0041] If the ruling result data is an objection rejection instruction, then the circulation status of the standardized instruction object is updated to the mandatory rectification status and sent to the scheduling initiation terminal;

[0042] If the ruling result data is an objection consent instruction, then an objection withdrawal log corresponding to the error type marker is generated.

[0043] Secondly, this application also provides a device for post-event inspection of heavy-haul railway dispatching instructions, comprising:

[0044] The instruction standardization module is used to acquire scheduling instruction data to be processed, associate the scheduling instruction data with preset business data, and generate a standardized instruction object to be inspected carrying business characteristics.

[0045] The task distribution module is used to determine the target inspection terminal corresponding to the standardized instruction object based on a preset allocation strategy, and send the standardized instruction object to the target inspection terminal.

[0046] An anomaly analysis module is used to receive error checking data for the standardized instruction object returned by the target inspection terminal, match the error checking data with a preset error dictionary, and determine the error type label of the standardized instruction object.

[0047] The process closed-loop module is used to obtain the state transition path corresponding to the error type mark, and drive the standardized instruction object to flow and update its state among multiple business processing nodes included in the state transition path until the flow state of the standardized instruction object is updated to the business closed-loop state.

[0048] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0049] Acquire the scheduling instruction data to be processed, associate the scheduling instruction data with preset business data, and generate a standardized instruction object to be inspected carrying business characteristics;

[0050] Based on a preset allocation strategy, the target inspection terminal corresponding to the standardized instruction object is determined, and the standardized instruction object is sent to the target inspection terminal.

[0051] Receive error checking data for the standardized instruction object returned by the target inspection terminal, match the error checking data with a preset error dictionary, and determine the error type label of the standardized instruction object;

[0052] Obtain the state transition path corresponding to the error type marker, and drive the standardized instruction object to flow and update its state among multiple business processing nodes included in the state transition path until the flow state of the standardized instruction object is updated to the business closed loop state.

[0053] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0054] Acquire the scheduling instruction data to be processed, associate the scheduling instruction data with preset business data, and generate a standardized instruction object to be inspected carrying business characteristics;

[0055] Based on a preset allocation strategy, the target inspection terminal corresponding to the standardized instruction object is determined, and the standardized instruction object is sent to the target inspection terminal.

[0056] Receive error checking data for the standardized instruction object returned by the target inspection terminal, match the error checking data with a preset error dictionary, and determine the error type label of the standardized instruction object;

[0057] Obtain the state transition path corresponding to the error type marker, and drive the standardized instruction object to flow and update its state among multiple business processing nodes included in the state transition path until the flow state of the standardized instruction object is updated to the business closed loop state.

[0058] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0059] Acquire the scheduling instruction data to be processed, associate the scheduling instruction data with preset business data, and generate a standardized instruction object to be inspected carrying business characteristics;

[0060] Based on a preset allocation strategy, the target inspection terminal corresponding to the standardized instruction object is determined, and the standardized instruction object is sent to the target inspection terminal.

[0061] Receive error checking data for the standardized instruction object returned by the target inspection terminal, match the error checking data with a preset error dictionary, and determine the error type label of the standardized instruction object;

[0062] Obtain the state transition path corresponding to the error type marker, and drive the standardized instruction object to flow and update its state among multiple business processing nodes included in the state transition path until the flow state of the standardized instruction object is updated to the business closed loop state.

[0063] The aforementioned method, apparatus, computer equipment, computer-readable storage medium, and computer program product for post-inspection of heavy-haul railway dispatching instructions acquire dispatching instruction data to be processed, associate the dispatching instruction data with preset business data, and generate standardized instruction objects carrying business characteristics to be inspected; based on a preset allocation strategy, determine the target inspection terminal corresponding to the standardized instruction object, and send the standardized instruction object to the target inspection terminal; receive error inspection data for the standardized instruction object returned by the target inspection terminal, match the error inspection data with a preset error dictionary, and determine the error type label of the standardized instruction object; acquire the state transition path corresponding to the error type label, and drive the standardized instruction object to flow and update its state among multiple business processing nodes included in the state transition path until the flow state of the standardized instruction object is updated to a business closed-loop state. In this embodiment, standardized instruction objects are generated by associating original scheduling instructions with business data. These objects are then automatically identified and targeted for inspection using a preset allocation strategy, reducing the arbitrariness and delays inherent in traditional manual task assignment. During the inspection and judgment phase, a preset error dictionary is used to perform structured matching with the inspection data returned by the terminal to output error type markers. This effectively reduces subjective qualitative differences caused by over-reliance on human experience. Furthermore, based on these error type markers, the corresponding state transition path is automatically matched, driving the instruction objects to update their state across nodes until a closed loop is achieved. This realizes end-to-end state tracking from error marking and verification to rectification, significantly improving the business processing efficiency of heavy-haul railway scheduling instruction investigation. Attached Figure Description

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

[0065] Figure 1 This is a diagram illustrating the application environment of a post-event inspection method for heavy-haul railway dispatching instructions in one embodiment.

[0066] Figure 2 This is a flowchart illustrating a method for post-event inspection of heavy-haul railway dispatching instructions in one embodiment;

[0067] Figure 3 This is a schematic diagram of the inspection task management process for a post-inspection method of heavy-haul railway dispatching instructions in one embodiment;

[0068] Figure 4 This is a schematic diagram of the error management process of a post-event inspection method for heavy-haul railway dispatching instructions in one embodiment.

[0069] Figure 5 This is a schematic diagram of the interactive inspection process of a post-event inspection method for heavy-haul railway dispatching instructions in one embodiment;

[0070] Figure 6 This is a schematic diagram of the review and objection handling process for a post-event inspection method for heavy-haul railway dispatching instructions in one embodiment;

[0071] Figure 7 This is a schematic diagram of the result analysis and feedback process of a post-event inspection method for heavy-haul railway dispatching instructions in one embodiment.

[0072] Figure 8 This is a schematic diagram of the full archiving process of a post-event inspection method for heavy-haul railway dispatching instructions in one embodiment;

[0073] Figure 9 This is a flowchart illustrating a method for post-event inspection of heavy-haul railway dispatching instructions in another embodiment;

[0074] Figure 10 This is a structural block diagram of a post-dispatch inspection device for heavy-haul railway dispatching instructions in one embodiment.

[0075] Figure 11 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0076] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0077] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various objects, but these objects are not limited by these terms. These terms are only used to distinguish the first object from the second object. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0078] The post-event inspection method for heavy-haul railway dispatching instructions provided in this application embodiment can be applied to, for example... Figure 1 The application environment is illustrated. The terminal communicates with the server via a network. The data storage system stores the data the server needs to process. The data storage system can be integrated onto the server or located on the cloud or other network servers. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted displays, etc. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0079] In one exemplary embodiment, such as Figure 2 As shown, a method for post-event inspection of heavy-haul railway dispatching instructions is provided, which can be applied to... Figure 1 Taking the server-side as an example, the explanation includes the following steps S201 to S204. Wherein:

[0080] Step S201: Obtain the scheduling instruction data to be processed, associate the scheduling instruction data with the preset business data, and generate a standardized instruction object to be inspected carrying business characteristics.

[0081] Among them, the dispatch instruction data can be the original control information text used to guide train operation or on-site equipment operation in the heavy-haul railway operation control scenario.

[0082] The preset business data can be basic background reference information related to the actual operating environment of the train, such as train timetable planning data or the current operating status of the underlying equipment (such as the red light status of the signal), which is used to provide multi-dimensional objective factual basis for subsequent reasonableness comparison.

[0083] Standardized instruction objects can be structured data packets generated after low-level parsing and multi-source information fusion. These objects carry extracted spatiotemporal elements and auxiliary decision features.

[0084] Specifically, the server can collect raw dispatch instruction text from the business environment through a pre-defined application programming interface (API), and perform natural language parsing on the text content to extract key information such as train number identifiers, spatial departure intervals, and time-limited blocking ranges. Next, based on the extracted key information, the server retrieves and matches corresponding train timetable plans and field equipment status information from local or external business databases. Finally, the server merges and encapsulates the extracted instruction elements with these matched auxiliary business data to generate a uniformly formatted structured instruction package.

[0085] Step S202: Based on the preset allocation strategy, determine the target inspection terminal corresponding to the standardized instruction object, and send the standardized instruction object to the target inspection terminal.

[0086] The preset allocation strategy can be a logical rule configured inside the server to regulate the data distribution flow, such as a filtering rule based on the mutual exclusion principle between publishers and inspectors, and a scheduling rule based on the queuing status of terminal tasks, etc., which is used to ensure the rationality of instruction flow and the balance of node load in multi-node scenarios.

[0087] The target inspection terminal can be a computing device or terminal node in the network topology that is responsible for receiving and presenting the instruction data to be processed.

[0088] Specifically, after obtaining the standardized instruction object, the server can read the basic attribute information carried by the object (such as the business level or processing requirements of the instruction). Then, the server calls the internally configured allocation strategy to comprehensively evaluate and match the above attribute information with the processing qualifications or current working status of each available terminal node. Subsequently, based on the matching evaluation results, the server selects a suitable terminal node from the available nodes to receive the instruction object and uses it as the target inspection terminal. Finally, the server routes and sends the standardized instruction object to the target inspection terminal through the communication network.

[0089] Step S203: Receive error check data for the standardized instruction object returned by the target inspection terminal, match the error check data with a preset error dictionary, and determine the error type label of the standardized instruction object.

[0090] Error checking data can be interactive information returned by the target checking terminal after verifying the instruction content, including but not limited to descriptive content about instruction differences or abnormal situations, used to reflect the potential risks of the standardized instruction object.

[0091] The preset error dictionary can be a pre-configured standardized classification mapping library that covers reference entries for various error types and different anomaly dimensions. It is used to provide a comparison benchmark for unstructured feedback information and can serve as a rule reference for machine-executed automated classification.

[0092] Error type markers can be standardized feature identifiers generated after dictionary comparison, indicating the specific error attributes of standardized instruction objects.

[0093] Specifically, after the target inspection terminal completes the corresponding verification operation, the server receives the error inspection data fed back by it through the network communication interface; then, the server parses the error inspection data and extracts the abnormal feedback content; subsequently, the server calls the system's internal preset error dictionary and performs information association and mapping evaluation between the extracted abnormal feedback content and the standardized reference entries in the error dictionary; finally, based on the mapping evaluation results, the server determines a corresponding standardized error category for the standardized instruction object and generates a corresponding error type label.

[0094] Step S204: Obtain the state transition path corresponding to the error type marker, and drive the standardized instruction object to flow and update its state among multiple business processing nodes included in the state transition path until the flow state of the standardized instruction object is updated to the business closed loop state.

[0095] Among them, the status transition path can be a predefined data flow logic chain within the server, used to regulate the order and flow of instruction objects in different verification or approval stages, and can serve as a track reference for the full lifecycle management of instruction data.

[0096] Business processing nodes can be logical processing units that undertake specific approval, verification, or rectification feedback tasks, and are used to perform corresponding business response operations on the data objects that are transferred to them.

[0097] The business closed-loop status can be a final state attribute identifier that indicates that the instruction data has completed all the predetermined processes. It is used to confirm that the process associated with the instruction data has been properly completed and can be used as a termination condition for this automated workflow task.

[0098] Specifically, after determining the error type flag of the standardized instruction object, the server can retrieve a matching state transition path from the system's underlying layer based on the anomaly reflected by the flag (e.g., a complex path involving multi-level business processing or a simple path requiring only single-step confirmation). Then, the server pushes the standardized instruction object sequentially to each business processing node included in the path according to the topological order of the state transition path. After the target business processing node completes the corresponding processing or feedback action, the server receives the feedback data and synchronously updates the flow status tag of the standardized instruction object at the system's underlying layer. The above-mentioned mechanism for driving flow and state updates continues until the server detects that the standardized instruction object has completed all node interactions specified by the path, and then updates its flow status to a business closed-loop state, thereby ending the flow lifecycle of the object.

[0099] In this embodiment, standardized instruction objects are generated by associating original scheduling instructions with business data. These objects are then automatically identified and targeted for inspection using a preset allocation strategy, reducing the arbitrariness and delays inherent in traditional manual task assignment. During the inspection and judgment phase, a preset error dictionary is used to perform structured matching with the inspection data returned by the terminal to output error type markers. This effectively reduces subjective qualitative differences caused by over-reliance on human experience. Furthermore, based on these error type markers, the corresponding state transition path is automatically matched, driving the instruction objects to update their state across nodes until a closed loop is achieved. This realizes end-to-end state tracking from error marking and verification to rectification, significantly improving the business processing efficiency of heavy-haul railway scheduling instruction investigation.

[0100] In one embodiment, the scheduling instruction data is associated with preset service data to generate a standardized instruction object to be inspected, carrying service characteristics, including:

[0101] Structured feature extraction is performed on the scheduling instruction data to obtain a set of instruction elements containing spatiotemporal feature attributes; related business data matching the spatiotemporal feature attributes are obtained from the business data; the set of instruction elements and the related business data are concatenated using a data structure to obtain the standardized instruction object to be inspected.

[0102] Among them, spatiotemporal characteristic attributes can be key parameters characterizing the execution time and physical spatial range of scheduling instructions, such as specific train number identifiers, train operating sections, and time blockade ranges. The instruction element set can be a structured data group formed after parsing and processing, which carries the various core elements extracted above and can serve as a concise expression carrier of the original long text instructions.

[0103] Related business data can be auxiliary reference information that matches spatiotemporal characteristics, such as specific train operation data or on-site equipment status information, to provide objective background verification material for the instruction content.

[0104] Specifically, after obtaining the original scheduling instruction data (i.e., long text commands), the server performs in-depth parsing of the command content, automatically extracting key elements (such as extracting specific information like "train 80001", "section between XX station and YY station", and "10:00-12:00 closure"), thus obtaining a set of instruction elements containing the aforementioned spatiotemporal feature attributes. Next, using the extracted spatiotemporal feature attributes as the retrieval basis, the server retrieves and matches the train timetable data and current equipment status information (such as switch positions and section occupancy) corresponding to the train number, section, or time period from the underlying business database, and uses them as associated business data. Finally, the server performs field-level mapping and data structure concatenation between the extracted instruction element set and the obtained associated business data, thereby generating a standardized instruction object that simultaneously contains spatiotemporal features and auxiliary verification basis for subsequent circulation and inspection processes.

[0105] Furthermore, after generating the standardized instruction object, the server can extract the command type (e.g., train operation command, shunting command, or construction command) and priority characteristics (e.g., first-level, second-level, or third-level priority, where first-level can correspond to the core commands of heavy-haul trains). Based on the extracted command type and priority, the server generates a unique index number for the standardized instruction object and persists it to the business database according to the logic of classified storage to support subsequent multi-dimensional retrieval and retrieval.

[0106] In this embodiment, by extracting structured features from scheduling instruction data, obtaining matching related business data, and splicing data structures, the originally unstructured command text containing only a single dimension can be refined into structured elements with clear spatiotemporal boundaries. Relevant underlying business background information is automatically added, making the final standardized instruction object have extremely high data self-interpretability, which is conducive to effectively improving the data acquisition continuity and comprehensive comparison accuracy in the post-inspection stage.

[0107] In one embodiment, the target inspection terminal corresponding to the standardized instruction object is determined based on a preset allocation strategy, including:

[0108] Obtain the original issuer identifier corresponding to the standardized instruction object; remove the terminal corresponding to the original issuer identifier from the preset first inspection terminal set to obtain the second inspection terminal set; obtain the current pending task queue load data of each terminal in the second inspection terminal set, and select the terminal with the smallest load from the second inspection terminal set as the target inspection terminal based on the load data.

[0109] Among them, the original issuer identifier can be a unique identity code of the source of the initial generation and issuance of the scheduling instruction, used to trace the operating subject of the instruction, and can be used as the basic comparison parameter for subsequent identity mutual exclusion verification.

[0110] The first set of check terminals can be a pre-set group of all candidate nodes that are qualified to check instructions, while the second set of check terminals is the group of available nodes that remain after being filtered by specific mutual exclusion rules. They are used to define the dynamic range of optional tasks and can serve as a node resource pool for different screening stages.

[0111] The pending task queue load data can be a system status parameter that reflects the number of backlogged tasks or the queuing status of each terminal, and is used to quantitatively assess the real-time workload of the underlying nodes.

[0112] Specifically, after a standardized instruction object is generated, the server can read the original publisher identifier carried in the object's data packet. Subsequently, to implement the "publisher-inspector crossover principle" and avoid blind spots in self-inspection, the server retrieves a first set of inspection terminals consisting of all available nodes and compares the original publisher identifier with the login identity information of each terminal in this set one by one, directly eliminating terminal nodes with overlapping identities, thus forming a second set of inspection terminals with the remaining available terminals. Next, the server obtains the current pending task queue load data of each terminal in the second set of inspection terminals in real time through the status monitoring interface (e.g., the number of instructions waiting to be inspected). Finally, the server compares these load data values ​​and selects the terminal with the least backlog of tasks, i.e., the least load, and establishes it as the target inspection terminal to receive the instruction object, thereby executing the subsequent data distribution operation.

[0113] In an optional embodiment, such as Figure 3As shown, before executing the assigned tasks, the server can automatically trigger the next day's post-inspection tasks at a fixed time each day (e.g., 22:00) through a built-in task triggering mechanism, or receive temporary inspection instructions manually sent by the administrator (e.g., inspection tasks initiated after the completion of major tasks). When standardized instruction objects enter the allocation stage, the server will intelligently schedule them according to preset allocation rules: for high-priority level 1 commands, the server can directly assign them to the inspection terminals corresponding to senior schedulers (e.g., those with 5 or more years of work experience) or security inspectors; for level 2 or 3 commands, identity is eliminated and the terminal with the least load is selected as the target inspection terminal. In addition, the server can also enable a task bidding mode, allowing each inspection terminal to actively send a claim request to obtain high-priority inspection tasks; after the target inspection terminal is determined and data is distributed, the server can send a new task reminder to the target inspection terminal by pushing a desktop pop-up or sending an SMS notification; at the same time, the server will control the task list on the target inspection terminal to be sorted according to the rule of "priority combined with timeliness", for example, generating red-highlighted instructions for tasks that need to be completed within 24 hours to achieve visually prominent prompts.

[0114] In this embodiment, the server extracts the original publisher's identifier for identity mutual exclusion and performs minimum load filtering by combining the real-time queue load data of each terminal. This transforms the original simple random or manual assignment into an intelligent routing mechanism based on identity isolation and dynamic load, effectively avoiding the resource imbalance phenomenon of some inspection terminals being severely congested while other terminals are idle in multi-concurrency scenarios. This is conducive to maximizing the concurrent response speed and processing throughput of the entire inspection network.

[0115] In one embodiment, the error dictionary includes multiple error types and corresponding element verification rules for each error type;

[0116] The error checking data is matched against a pre-defined error dictionary to determine the error type flags for standardized instruction objects, including:

[0117] Extract the error classification field from the error checking data; match the error classification field with multiple error types in the error dictionary to determine the target error type of the error checking data, and obtain the target element verification rule bound to the target error type; verify the business features in the standardized instruction object based on the target element verification rule, and if the verification result is unsuccessful, determine the error classification field as the error type marker of the standardized instruction object.

[0118] Among them, there are multiple error types, which can be classification data that covers various abnormal dimensions of the command and is pre-defined through the configuration file. For example, there are multiple preset error categories (such as command application format error, command location error, etc.) and corresponding error-free statuses.

[0119] Element verification rules can be data verification logic bound to specific error categories, such as conditional statements that verify whether an instruction contains specific basic elements, used to assist in verifying the completeness or compliance of the instruction content.

[0120] The error classification field can be the identifier information representing the anomaly category carried in the error checking data, which serves as the input parameter to trigger the system to call the corresponding verification logic.

[0121] Specifically, such as Figure 4 As shown, after receiving error check data from the terminal (this data may include the error type initially selected by the terminal, the specific description of the error, and the supporting materials uploaded), the server extracts the core error classification field. Next, the server compares this classification field with the error dictionary configured at the system's underlying level to match the corresponding target error type and simultaneously retrieves the target element verification rules bound to that target error type. For example, when the matched target error type is "command application format error," the server automatically retrieves the preset automatic judgment rule for "verifying whether the instruction contains a command number and release time." Subsequently, the server runs this judgment rule to perform machine verification on the structured business features carried in the standardized instruction object. If the server finds that the original instruction does indeed have the above-mentioned missing elements (i.e., the verification result is failed), the server finally formally establishes the error classification field as the error type marker for that standardized instruction object. Furthermore, the server allows administrators to add, modify, and maintain the error types in the error dictionary.

[0122] In this embodiment, the server automatically verifies the data by introducing element verification rules bound to the error type. This integrates preliminary anomaly feedback with objective data verification, effectively filtering out invalid check feedback caused by misoperation, and improving the accuracy of error marking and the standardization of data processing.

[0123] In one embodiment, after determining the error type flag of the standardized instruction object, the method further includes:

[0124] The error level feature field associated with the error classification field is obtained from the error inspection data, and the error level mark of the standardized instruction object is determined. It is then determined whether the error level mark matches the preset emergency error level. If it matches the emergency error level, an audible and visual alarm message is generated, as well as a front-end rendering instruction to update the display background color of the standardized instruction object to the preset warning color. The audible and visual alarm message and the front-end rendering instruction are then sent to the target inspection terminal.

[0125] Among them, the level feature field can be a parameter identifier carried in the error check data that represents the depth of the impact of the abnormality, such as a status value such as general, severe or urgent, which is used to quantify the potential harm of the instruction error.

[0126] Error severity rating can be a standardized rating attribute established based on the extracted severity parameters, used to solidify the severity of the error at the system level.

[0127] The emergency error level can be a pre-set highest risk judgment threshold, such as a serious abnormal state that may lead to driving conflict. It is used to intercept high-risk command flow and can be used as an activation condition to trigger an immediate alarm.

[0128] Front-end rendering instructions can be data control messages sent from the server to the terminal to change the visual presentation of the interface, thereby achieving intuitive visual feedback and serving as a dynamic update driver for the human-computer interaction interface.

[0129] Specifically, after determining the error type, the server continues to parse the error inspection data reported by the terminal, extracting the level feature field (e.g., general, severe, or urgent) selected by the inspector based on the degree of impact, and establishing it as the error level label for the instruction object. Next, the server compares the error level label with the underlying emergency error level to assess whether it belongs to a high-risk situation that may lead to driving conflicts. If the assessment result matches the emergency error level, the server will generate an audible and visual alarm in the background in real time, and simultaneously generate a front-end rendering instruction to update the background color of the command list to a preset warning color (e.g., red). Subsequently, the server sends the above alarm information and rendering instruction to the target inspection terminal. In addition, after receiving a request from the terminal to confirm that the label has taken effect (e.g., clicking to save the error), the server will control the terminal interface to prominently display the error type and level in the form of a merged label, and automatically generate and save relevant operation logs in the background for subsequent traceability.

[0130] In a specific embodiment, such as Figure 5As shown, during the front-end loading and interaction phase, the target inspection terminal will display the original command text, structured elements, and related data such as the train schedule for the corresponding time period in the operation diagram to the inspectors. If the command is correct, the server can automatically mark "pass" based on the confirmation operation or timeout mechanism, turn the background of the list green, and record the error-free judgment basis such as "complies with Article X of the XX Dispatch Rules". In scenarios where errors exist, after determining the error type marker, the server continues to parse the error inspection data returned by the terminal (this data may include specific descriptions filled in by the front end, such as "the departure time of train 80001 at station A conflicts with the schedule," and supporting materials such as uploaded screenshots of the schedule). From this data, the server extracts the general, severe, or urgent level characteristic fields associated with the error classification and determines them as the error level marker for the instruction object. Next, the server determines whether the marker matches the preset urgent error level (e.g., whether it belongs to a potential hazard that may cause a driving conflict). If it matches, the server generates audible and visual alarm information and updates the background color of the command list display to a preset warning color (e.g., red) in the front end rendering instruction. Subsequently, the server sends the alarm information and rendering instruction to the target inspection terminal, controls the terminal interface to trigger the alarm, and displays the error type and level in the form of a label (e.g., "Severe - Content Conflict"), while automatically recording the operation log.

[0131] In this embodiment, the server introduces error level matching and generates sound and light alarms and front-end rendering instructions in conjunction with the alarm level. This enables the underlying abnormal data to be transformed into intuitive multi-dimensional sensory warnings. This mechanism effectively improves the sensitivity of the processing node to high-risk instructions and ensures that potential hazards in emergency driving can be intercepted in a timely manner.

[0132] In one embodiment, the business processing node includes a node to be rectified and a rectification review node. The node to be rectified corresponds to a flow status of "to be rectified" and the rectification review node corresponds to a flow status of "rectification review".

[0133] The standardized instruction object is driven to flow and update its state among multiple business processing nodes included in the state transition path, including:

[0134] When the standardized instruction object is in the pending rectification stage, its circulation status is updated to pending rectification, and the standardized instruction object is sent to the corresponding scheduling initiation terminal. The rectification review node receives the modification record returned by the scheduling initiation terminal for the standardized instruction object in the pending rectification stage and saves the modification record to the business database. Based on the modification record, the circulation status is updated to the rectification review status, and the rectified instruction data is sent to the corresponding target inspection terminal for comparison and verification. If the target inspection terminal returns a verification pass instruction, the circulation status is updated to the business closed-loop status.

[0135] Among them, the nodes to be rectified and the rectification review nodes can be logical units in the network architecture that respectively undertake error correction and post-correction verification operations. They are used to connect the processing flow after error discovery and can serve as a hub for instruction data repair and secondary verification.

[0136] The "Pending Rectification" and "Rectification Review" statuses can be attribute tags assigned to standardized instruction objects at different repair stages, used to identify the current processing stage of the instruction.

[0137] The scheduling initiating terminal can be the business device that initially generates and issues the instruction, used to receive returned abnormal instructions and provide an entry point for modification operations.

[0138] Specifically, when the server detects that the instruction object is in a pending rectification node, it updates the circulation status of the standardized instruction object to the pending rectification status and directly returns the standardized instruction object containing error details to the corresponding scheduling initiating terminal (e.g., back to the dispatcher's terminal that originally issued the command). Then, the server, as a rectification review node, receives the modification record returned by the scheduling initiating terminal (e.g., the revision record generated by the dispatcher re-modifying and issuing the command in the system). At the same time, the server saves the original erroneous version and the above modification record to the business database for traceability. Subsequently, the server updates the circulation status of the instruction object to the rectification review status based on the modification record and resends the generated rectified instruction data to the corresponding target inspection terminal (e.g., re-pushing to the terminal of the original inspector who initially discovered the error) for secondary comparison and verification. If the server receives a verification pass instruction returned by the target inspection terminal after review, the server finally updates the circulation status of the standardized instruction object to the business closed-loop status, ending the entire error correction process.

[0139] In this embodiment, by driving instructions to flow between the nodes to be rectified and those to be reviewed, the error-checking action is transformed into a closed-loop error correction mechanism. This method achieves low-level traceability of modification records and mandatory secondary verification, avoiding incomplete rectification and effectively improving the reliability of instruction repair and the efficiency of system closed-loop management.

[0140] In one embodiment, after sending the standardized instruction object to the corresponding scheduling initiating terminal, the method further includes:

[0141] If an objection instruction for an error type label is received from the scheduling initiating terminal, the circulation status of the standardized instruction object is updated to the objection locked status; the standardized instruction object in the objection locked status is sent to the preset arbitration terminal; the arbitration terminal returns the arbitration result data: if the arbitration result data is an objection rejection instruction, the circulation status of the standardized instruction object is updated to the mandatory rectification status and sent to the scheduling initiating terminal; if the arbitration result data is an objection agreement instruction, an objection withdrawal log corresponding to the error type label is generated.

[0142] Among them, the objection instruction can be a business request message from the scheduling initiating terminal that holds a different opinion on the current error classification. It is used to trigger the exception review process and can serve as a trigger signal to interrupt the regular rectification path.

[0143] The objection lock status can be a static attribute tag assigned to an instruction object that is in the process of arbitration, which is used to freeze the object's modification and transfer permissions between ordinary nodes.

[0144] Arbitration terminals can be computing nodes with high-level privileges, used to receive dispute data and provide an interactive entry point for final rulings.

[0145] The arbitration result data can be feedback data generated by the arbitration terminal that includes the judgment conclusion. It is used to determine the sole subsequent destination of the disputed instructions and can serve as a decisive basis for driving the flow of branches.

[0146] Specifically, after the server sends the standardized instruction object to the corresponding scheduling initiating terminal, if the server receives an objection instruction from the scheduling initiating terminal regarding the error type marking (e.g., an appeal request initiated by the original issuing scheduler who disagrees with the erroneous conclusion reached during the inspection), the server will update the flow status of the standardized instruction object to the objection-locked state to suspend its normal data flow. Next, the server sends the standardized instruction object in the objection-locked state to a preset arbitration terminal (e.g., a high-privilege node corresponding to the dispatch center's security monitoring room or the duty officer) for comprehensive evaluation. Subsequently, the server obtains the arbitration result data returned by the arbitration terminal after evaluation. At this point, the server executes differentiated underlying routing branches based on the arbitration result data: if the server parses the arbitration result data as an objection rejection instruction (i.e., the arbitration node maintains the original error judgment), the server updates the flow status of the standardized instruction object to the mandatory rectification state and resends it to the scheduling initiating terminal to push it to continue executing the relevant correction operations; if the server parses the arbitration result data as an objection agreement instruction (i.e., the arbitration node acknowledges the initiating terminal's appeal), the server will generate an objection withdrawal log corresponding to the error type marking in the background, thereby canceling the original error record and ending this exception handling process.

[0147] In a specific embodiment, such asFigure 6 As shown, after the server sends the standardized instruction object to the corresponding scheduling initiating terminal (i.e., the node where the original issuer is located) for first-level review, if the server receives a confirmation error request from the terminal, it directly drives the standardized instruction object into the rectification process. If the scheduling initiating terminal does not confirm the error, and the server receives an objection instruction containing specific appeal reasons, it updates the flow status of the standardized instruction object to the objection locked state. Next, the server sends the standardized instruction object in the objection locked state, along with the retrieved original command text, inspection records, and related data, to the preset arbitration terminal for comprehensive evaluation. In actual flow, the server can first send it to the terminal corresponding to the administrator for second-level review. If a further appeal request for the second-level review result is received, it will be further sent to the terminal corresponding to the scheduling director or security chief for third-level final review if necessary. Subsequently, the server obtains the arbitration result data based on the review, which includes the conclusion of maintaining the error judgment or revoking the error mark and the basis for filling in the data. If the ruling result is an objection rejection instruction (i.e., maintaining the error judgment), the server updates the workflow status to a mandatory rectification status and resends it to the scheduling initiating terminal. Simultaneously, the server generates a rectification order, specifying the responsible party (e.g., the issuer), the rectification deadline (e.g., 24 hours), and the verification method for reissuing the correction order. If the ruling result is an objection approval instruction (i.e., revoking the error mark), the server generates an objection revocation log corresponding to the error type mark. Furthermore, after the rectification process is completed, the server receives the verification pass request returned by the original inspector's terminal and updates the system mark to "rectified" to achieve a closed-loop rectification process. Simultaneously, for tasks not rectified on time, the server automatically triggers an escalation reminder operation, such as pushing a notification to the department head node.

[0148] In this embodiment, the server effectively breaks the deadlock in the flow of anomaly judgment by introducing a multi-level review and arbitration mechanism and an objection lock state, ensuring the isolation and control of disputed instructions and the authority of the final determination, and improving the execution efficiency of closed-loop management.

[0149] In one embodiment, after the flow status of the standardized instruction object is updated to the business closed-loop status, the method further includes:

[0150] Based on the error type label, the error root cause report corresponding to the error check data is determined, and based on the error root cause report, the element verification rules in the error dictionary are updated; the updated element verification rules, as well as the scheduling instruction data, error type label and error level label corresponding to the standardized instruction object, are encrypted using a preset encryption algorithm and then saved to the business database.

[0151] Among them, the root cause report can be a statistical analysis result generated by the server after in-depth mining of historical abnormal data.

[0152] The preset encryption algorithm can be a cryptographic model configured by the system to ensure data integrity and security, such as blockchain encryption technology or asymmetric encryption algorithm, to prevent sensitive archived data from being illegally tampered with, and can serve as a security protection measure for data traceability throughout the entire lifecycle.

[0153] Specifically, after the instruction completes its closed-loop flow, the server can periodically (e.g., monthly) extract accumulated error type tags and other data, use underlying correlation analysis algorithms to uncover the root causes of errors (e.g., analyze the correlation characteristics of frequently occurring train errors during equipment failures), and generate an error root cause report containing high-frequency types and guidance suggestions. Then, based on the analysis conclusions of this root cause report, the server automatically or manually updates the corresponding element verification rules in the error dictionary to achieve rule feedback. Subsequently, the server packages the updated element verification rules, along with the original scheduling instruction data, error type tags, error level tags, and various operation process records associated with the standardized instruction object throughout its lifecycle, into a full data package. Finally, the server uses preset blockchain technology or asymmetric encryption algorithms to generate a digital digest of the data packet and performs underlying encryption, persistently saving it to the business database, thereby generating an electronic archive that supports multi-dimensional, penetrating queries.

[0154] In a specific embodiment, such as Figure 7 As shown, the server can automatically calculate the overall pass rate (overall pass rate = number of passed commands / total number of checked commands), error type distribution (such as the proportion of format errors and content conflicts), and high-frequency error command types on a daily, weekly, or monthly basis. Next, the server mines high-frequency errors (such as non-standard route descriptions) and generates an error root cause report that distinguishes between human factors (such as dispatchers' unfamiliarity with new regulations) and system factors (such as outdated command templates). Subsequently, the server performs cross-process feedback based on this report, such as pushing individual error lists and training suggestions to dispatchers, and pushing template optimization requirements such as adding automatic route verification to the development team. Simultaneously, the server updates the element verification rules in the error dictionary based on the analysis results (e.g., adding a check item requiring heavy-load train formation commands to include axle load information).

[0155] In another specific embodiment, such as Figure 8As shown, the server packages the updated element verification rules, along with the corresponding scheduling instruction data (including original text and structured data), inspection records, error type markers, review processes, error level markers, and rectification verification results, into a single package. This package is then encrypted using a pre-defined encryption algorithm (such as blockchain technology) and stored in the business database to generate an electronic archive. Furthermore, the server can support multi-scenario traceability applications based on this business database. Examples include tracing safety incidents by associating incident time with concurrent commands, extracting inspection results for monthly performance evaluations, and providing complete documentation to prove the effectiveness of control measures during compliance audits.

[0156] In this embodiment, cross-process feedback and rule feedback are achieved by generating error root cause reports, and full archiving is carried out in conjunction with encryption algorithms, realizing a self-evolving closed-loop defense capability, while ensuring the immutability of historical archives and secure and reliable traceability in multiple scenarios.

[0157] To enable those skilled in the art to better understand the above steps, the following example illustrates the embodiments of this application, but it should be understood that the embodiments of this application are not limited thereto.

[0158] In a specific interactive inspection and error marking implementation scenario, combined with, for example Figure 9 The flow control logic shown involves the server first responding to the login and retrieval requests from the target inspection terminal, sending it a list of tasks to be inspected. When the server receives a selection trigger command from the target inspection terminal for any task, it drives the front-end interface of the target inspection terminal to display the original command text carried by the standardized command object, the structured extracted set of command elements, and the matching related business data (such as the train timetable plan for the corresponding period), providing comprehensive data support for subsequent verification operations.

[0159] Subsequently, the server monitors the interactive feedback status of the target inspection terminal in real time and executes the corresponding branch routing logic at the underlying level. If the server receives a confirmation instruction without errors from the target inspection terminal (e.g., the front-end clicks "Confirm Pass"), or if no operation is detected within a preset waiting time (e.g., configurable 5 to 10 seconds) thus triggering the system's automatic confirmation mechanism, the server determines that the instruction has been verified correctly. At this time, the server automatically marks the standardized instruction object as "Pass" in the background, generates a front-end rendering instruction to update the background color of its list display to a preset safety color (e.g., green) and issues it, while automatically recording the inspector, inspection time, and specific error-free determination criteria (e.g., compliance with specific clauses of the "Railway Dispatch Rules") in the underlying database.

[0160] Conversely, if the front-end detects an anomaly and triggers an error marking request, the server controls the target inspection terminal to display an option panel based on a preset error dictionary. Subsequently, the server receives detailed error inspection data submitted by the target inspection terminal. This data includes the error type initially selected by the front-end, the specific error description entered in the details box (e.g., a text description of a conflict between departure time and the timetable), and uploaded supporting materials (e.g., screenshots of the timetable). Next, the server extracts the core error classification field from this error inspection data, matches it against the underlying error dictionary to determine the target error type, and after completing the underlying validation of the element rules, formally establishes this field as the error type marker for the standardized instruction object.

[0161] While establishing the error type, the server further parses the error check data to obtain the level characteristic fields (general, severe, or urgent) selected by the front end based on the impact, and establishes them as the error level marker for the standardized instruction object. Next, the server triggers the underlying risk assessment logic to determine whether the error level marker matches the preset urgent error level (i.e., assessing whether the anomaly belongs to a high-risk situation that may lead to traffic conflicts). If the determination result is a match for the urgent error level, the server immediately generates an audible and visual alarm in the background and simultaneously generates a front-end rendering instruction to update the background color of the standardized instruction object in the list to a preset warning color (e.g., red).

[0162] Finally, upon receiving a confirmation instruction from the target inspection terminal confirming the flag's effectiveness (e.g., clicking "Save Error"), the server sends the generated audio-visual alarm information and front-end rendering instructions to the target inspection terminal. The server controls the target inspection terminal to execute immediate physical alarms and renders the error type and error level flags in a combined label format (e.g., prominently displayed as "Severe - Content Conflict") on the front-end interface. Simultaneously, the server automatically records a complete operation log in the background, containing all the above-mentioned flow and judgment details, thereby rigorously completing interactive error checking and multi-dimensional risk assessment for a single instruction.

[0163] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0164] Based on the same inventive concept, this application also provides a device for post-event inspection of heavy-haul railway dispatching instructions to implement the aforementioned method for post-event inspection of heavy-haul railway dispatching instructions. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations of one or more embodiments of the device for post-event inspection of heavy-haul railway dispatching instructions provided below can be found in the limitations of the method for post-event inspection of heavy-haul railway dispatching instructions described above, and will not be repeated here.

[0165] In one exemplary embodiment, such as Figure 10 As shown, a post-event inspection device for heavy-haul railway dispatching instructions is provided, comprising: an instruction standardization module 1010, a task distribution module 1020, an anomaly analysis module 1030, and a process closed-loop module 1040, wherein:

[0166] The instruction standardization module 1010 is used to acquire the scheduling instruction data to be processed, associate the scheduling instruction data with preset business data, and generate a standardized instruction object to be inspected carrying business characteristics.

[0167] The task distribution module 1020 is used to determine the target inspection terminal corresponding to the standardized instruction object based on a preset allocation strategy, and send the standardized instruction object to the target inspection terminal.

[0168] The anomaly analysis module 1030 is used to receive error checking data for the standardized instruction object returned by the target inspection terminal, match the error checking data with a preset error dictionary, and determine the error type label of the standardized instruction object;

[0169] The process closed-loop module 1040 is used to obtain the state transition path corresponding to the error type mark, and drive the standardized instruction object to flow and update its state among multiple business processing nodes included in the state transition path until the flow state of the standardized instruction object is updated to the business closed-loop state.

[0170] In one embodiment, the instruction standardization module 1010 is further configured to:

[0171] The scheduling instruction data is subjected to structured feature extraction to obtain a set of instruction elements containing spatiotemporal feature attributes;

[0172] From the business data, obtain the associated business data that matches the spatiotemporal feature attributes;

[0173] The set of instruction elements and the associated business data are combined using a data structure to obtain the standardized instruction object to be inspected.

[0174] In one embodiment, the task distribution module 1020 is further configured to:

[0175] Obtain the original issuer identifier corresponding to the standardized instruction object;

[0176] The terminal corresponding to the original publisher's identifier is removed from the preset first set of inspection terminals to obtain the second set of inspection terminals;

[0177] Obtain the current task queue load data of each terminal in the second inspection terminal set, and select the terminal with the smallest load from the second inspection terminal set as the target inspection terminal based on the load data.

[0178] In one embodiment, the error dictionary includes multiple error types and corresponding element verification rules for each error type. The anomaly analysis module 1030 is further configured to:

[0179] Extract the error classification field from the error check data;

[0180] The error classification field is matched with multiple error types in the error dictionary to determine the target error type of the error inspection data, and the target element verification rule bound to the target error type is obtained.

[0181] The business features in the standardized instruction object are validated based on the target element validation rules. If the validation result is unsuccessful, the error classification field is determined as the error type marker of the standardized instruction object.

[0182] In one embodiment, the anomaly analysis module 1030 is further configured to:

[0183] Obtain the level feature field associated with the error classification field from the error checking data, and determine it as the error level label of the standardized instruction object;

[0184] Determine whether the error level flag matches a preset emergency error level;

[0185] If the emergency error level is matched, an audible and visual alarm message is generated, and a front-end rendering instruction is sent to update the display background color of the standardized instruction object to a preset warning color.

[0186] The audible and visual alarm information and the front-end rendering command are sent to the target inspection terminal.

[0187] In one embodiment, the process closed-loop module 1040 is further configured to:

[0188] Based on the error type label, determine the error root cause report corresponding to the error inspection data, and based on the error root cause report, update the element verification rules in the error dictionary;

[0189] The updated element verification rules, as well as the scheduling instruction data, error type flags, and error level flags corresponding to the standardized instruction objects, are encrypted using a preset encryption algorithm and then saved to the business database.

[0190] In one embodiment, the business processing node includes a node to be rectified and a rectification review node, wherein the node to be rectified corresponds to a pending rectification state in the workflow, and the rectification review node corresponds to a rectification review state in the workflow; the process closed-loop module 1040 is further used for:

[0191] When the standardized instruction object is in a pending rectification stage, the circulation status of the standardized instruction object is updated to a pending rectification stage, and the standardized instruction object is sent to the corresponding scheduling initiation terminal.

[0192] The rectification review node receives the modification record returned by the standardized instruction object of the rectification status from the scheduling initiating terminal, and saves the modification record to the business database;

[0193] Based on the modification record, the circulation status is updated to the rectification and review status, and the rectification instruction data is sent to the corresponding target inspection terminal for comparison and verification.

[0194] If a verification pass instruction is received from the target inspection terminal, the flow status is updated to the business closed-loop status.

[0195] In one embodiment, the process closed-loop module 1040 is further configured to:

[0196] If an objection instruction for the error type flag is received from the scheduling initiating terminal, the flow status of the standardized instruction object is updated to the objection lock status;

[0197] The standardized instruction object that is in the objection lock state is sent to the preset arbitration terminal;

[0198] Obtain the arbitration result data returned by the arbitration terminal:

[0199] If the ruling result data is an objection rejection instruction, then the circulation status of the standardized instruction object is updated to the mandatory rectification status and sent to the scheduling initiation terminal;

[0200] If the ruling result data is an objection consent instruction, then an objection withdrawal log corresponding to the error type marker is generated.

[0201] The modules in the aforementioned post-dispatch inspection device for heavy-haul railway dispatch instructions can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0202] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 1 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores business data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When executed by the processor, the computer program implements a method for post-event inspection of heavy-haul railway dispatching instructions.

[0203] Those skilled in the art will understand that Figure 11The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0204] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0205] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0206] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0207] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0208] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0209] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0210] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for post-event inspection of heavy-haul railway dispatching instructions, characterized in that, The method includes: Acquire the scheduling instruction data to be processed, associate the scheduling instruction data with preset business data, and generate a standardized instruction object to be inspected carrying business characteristics; Based on a preset allocation strategy, the target inspection terminal corresponding to the standardized instruction object is determined, and the standardized instruction object is sent to the target inspection terminal. Receive error checking data for the standardized instruction object returned by the target inspection terminal, match the error checking data with a preset error dictionary, and determine the error type label of the standardized instruction object; Obtain the state transition path corresponding to the error type marker, and drive the standardized instruction object to flow and update its state among multiple business processing nodes included in the state transition path until the flow state of the standardized instruction object is updated to the business closed loop state.

2. The method according to claim 1, characterized in that, The step of associating the scheduling instruction data with preset service data to generate a standardized instruction object to be inspected, carrying service characteristics, includes: The scheduling instruction data is subjected to structured feature extraction to obtain a set of instruction elements containing spatiotemporal feature attributes; From the business data, obtain the associated business data that matches the spatiotemporal feature attributes; The set of instruction elements and the associated business data are combined using a data structure to obtain the standardized instruction object to be inspected.

3. The method according to claim 1, characterized in that, The process of determining the target inspection terminal corresponding to the standardized instruction object based on a preset allocation strategy includes: Obtain the original issuer identifier corresponding to the standardized instruction object; The terminal corresponding to the original publisher's identifier is removed from the preset first set of inspection terminals to obtain the second set of inspection terminals; Obtain the current task queue load data of each terminal in the second inspection terminal set, and select the terminal with the smallest load from the second inspection terminal set as the target inspection terminal based on the load data.

4. The method according to claim 1, characterized in that, The error dictionary includes various error types and corresponding element verification rules for each error type; The step of matching the error checking data with a preset error dictionary to determine the error type label of the standardized instruction object includes: Extract the error classification field from the error check data; The error classification field is matched with multiple error types in the error dictionary to determine the target error type of the error inspection data, and the target element verification rule bound to the target error type is obtained. The business features in the standardized instruction object are validated based on the target element validation rules. If the validation result is unsuccessful, the error classification field is determined as the error type marker of the standardized instruction object.

5. The method according to claim 4, characterized in that, After determining the error type flag of the standardized instruction object, the method further includes: Obtain the level feature field associated with the error classification field from the error checking data, and determine it as the error level label of the standardized instruction object; Determine whether the error level flag matches a preset emergency error level; If the emergency error level is matched, an audible and visual alarm message is generated, and a front-end rendering instruction is sent to update the display background color of the standardized instruction object to a preset warning color. The audible and visual alarm information and the front-end rendering command are sent to the target inspection terminal.

6. The method according to claim 4, characterized in that, After the standardized instruction object's flow status is updated to the business closed-loop status, the following is also included: Based on the error type label, determine the error root cause report corresponding to the error inspection data, and based on the error root cause report, update the element verification rules in the error dictionary; The updated element verification rules, as well as the scheduling instruction data, error type flags, and error level flags corresponding to the standardized instruction objects, are encrypted using a preset encryption algorithm and then saved to the business database.

7. The method according to claim 1, characterized in that, The business processing node includes a node to be rectified and a rectification review node. The node to be rectified corresponds to a processing status of "to be rectified" and the rectification review node corresponds to a processing status of "rectification review". The process of driving the standardized instruction object to flow and update its state among multiple business processing nodes included in the state transition path includes: When the standardized instruction object is in a pending rectification stage, the circulation status of the standardized instruction object is updated to a pending rectification stage, and the standardized instruction object is sent to the corresponding scheduling initiation terminal. The rectification review node receives the modification record returned by the standardized instruction object of the rectification status from the scheduling initiating terminal, and saves the modification record to the business database; Based on the modification record, the circulation status is updated to the rectification and review status, and the rectification instruction data is sent to the corresponding target inspection terminal for comparison and verification. If a verification pass instruction is received from the target inspection terminal, the flow status is updated to the business closed-loop status.

8. The method according to claim 7, characterized in that, After sending the standardized instruction object to the corresponding scheduling initiation terminal, the process further includes: If an objection instruction for the error type flag is received from the scheduling initiating terminal, the flow status of the standardized instruction object is updated to the objection lock status; The standardized instruction object that is in the objection lock state is sent to the preset arbitration terminal; Obtain the arbitration result data returned by the arbitration terminal: If the ruling result data is an objection rejection instruction, then the circulation status of the standardized instruction object is updated to the mandatory rectification status and sent to the scheduling initiation terminal; If the ruling result data is an objection consent instruction, then an objection withdrawal log corresponding to the error type marker is generated.

9. A device for post-event inspection of dispatching instructions for heavy-haul railways, characterized in that, The device includes: The instruction standardization module is used to acquire scheduling instruction data to be processed, associate the scheduling instruction data with preset business data, and generate a standardized instruction object to be inspected carrying business characteristics. The task distribution module is used to determine the target inspection terminal corresponding to the standardized instruction object based on a preset allocation strategy, and send the standardized instruction object to the target inspection terminal. An anomaly analysis module is used to receive error checking data for the standardized instruction object returned by the target inspection terminal, match the error checking data with a preset error dictionary, and determine the error type label of the standardized instruction object; The process closed-loop module is used to obtain the state transition path corresponding to the error type mark, and drive the standardized instruction object to flow and update its state among multiple business processing nodes included in the state transition path until the flow state of the standardized instruction object is updated to the business closed-loop state.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

Images