A railway dispatching instruction life cycle management method, system, device and medium

Abstract

This disclosure relates to the field of rail transit technology, and in particular to a method, system, equipment, and medium for managing the lifecycle of railway dispatching instructions. It constructs a railway dispatching business consortium blockchain network including a dispatching center, stations, professional departments, and regulatory nodes; deploys smart contracts pre-installed with state machine models; a business system access adaptation module monitors key operations of the existing dispatching system, extracts operational data, and generates transactions to be uploaded to the blockchain; the smart contract verifies the legality and permissions of the transactions, and upon successful verification, records the operational events in the blockchain ledger and updates the instruction status. This disclosure utilizes the immutability and traceability of blockchain, combined with the strict constraints of smart contracts on state transitions, to achieve trusted evidence storage and multi-party consensus throughout the entire process of dispatching instructions, from drafting, approval, issuance, execution to cancellation. This solves the problems of easily tampered data, difficulty in cross-entity collaboration, and unclear responsibility definition in centralized management schemes, significantly improving the security and audit traceability efficiency of railway dispatching operations.

Description

Technical Field

[0001] This disclosure relates to the field of rail transit technology, and in particular to a method, system, equipment and medium for managing the life cycle of railway dispatching instructions. Background Technology

[0002] Railway dispatching instructions are core operational instructions in train operation organization and safety control, used to issue orders for train operation adjustments, line closures / openings, slow-moving traffic, equipment maintenance, temporary construction, and other related matters. Their typical operational characteristics include: Strong timeliness: Instructions must be issued, confirmed, and executed within a specified time limit, with strict requirements on timing; Strong safety and seriousness: If the instructions are wrong or not executed properly, it may directly affect driving safety; Multiple entities involved: including the central dispatching center, section dispatching centers, station duty officers, locomotive crew, track maintenance, signaling, power supply, and other entities; Full lifecycle management requirements: from drafting, approval, reading aloud, repeating, execution to cancellation, traceable records must be created.

[0003] As the level of railway informatization improves, the generation, transmission, and recording of dispatching instructions are gradually shifting from paper to electronic, but many management processes still follow traditional concepts.

[0004] Although the generation, transmission, execution, and archiving of railway dispatching instructions have generally been digitized, they still mainly rely on centralized databases, paper records, and multi-system log splicing for management, resulting in the following prominent problems: (1) Instruction records are easily tampered with and difficult to detect: Existing systems typically use a single database or application system log to record scheduling instructions and their operation processes. Once the database administrator or system maintenance personnel maliciously tamper with or misoperate the records, it is difficult to find and restore the original records afterward, and the non-repudiation and integrity of the records cannot be guaranteed technically.

[0005] (2) Data fragmentation across multiple systems and stages makes it difficult to form a unified full lifecycle chain: From generation to execution, dispatch instructions often go through multiple business systems such as dispatch system, vehicle terminal system, maintenance system, and driving record system. Each system only saves data for its own stage, lacking a unified data model and a unified timeline. This results in the need for manual retrieval and comparison in multiple systems when reviewing accidents or determining responsibility, which is inefficient and prone to omissions.

[0006] (3) Lack of an authoritative and credible timestamp and accountability mechanism: While existing solutions record operation time and operator account, the time source is usually local time of each system or database time, lacking a unified and reliable timestamp service; at the same time, account permission management is decentralized, making it difficult to achieve strong binding and non-repudiable technical proof of "who performed which operation on which instruction at what time".

[0007] (4) Lack of a unified, trusted, and shared ledger for cross-departmental and cross-regional collaboration: Railway dispatching involves multiple departments, including railway bureaus, dispatching centers, stations, engineering, signaling, power supply, and even third-party regulatory units. The existing sharing method based on centralized databases and point-to-point interfaces lacks a unified and reliable "Single Source of Truth," which easily leads to inconsistencies in information between different systems.

[0008] (5) Low efficiency and high cost in auditing and incident tracing: When abnormal driving, equipment failure or safety accident occurs, it is necessary to trace and audit the relevant dispatch instructions. The existing methods often require calling up a large amount of historical logs, paper dispatch command registers and other materials, manually screening, comparing and reviewing them, which is time-consuming, labor-intensive and easy to miss key links.

[0009] In summary, there is an urgent need to address the problems in existing railway dispatch instruction management, such as data susceptibility to tampering, difficulties in cross-entity collaboration, and the inability to form a reliable closed loop for the entire lifecycle of records, caused by centralized storage. Summary of the Invention To address the aforementioned issues, this disclosure provides a method, system, equipment, and medium for managing the lifecycle of railway dispatching instructions.

[0010] Firstly, a method for managing the lifecycle of railway dispatching instructions includes: Construct a railway dispatching business alliance chain network, which includes dispatch center nodes deployed in dispatch centers, station nodes deployed in stations, professional department nodes deployed in equipment maintenance units, and regulatory nodes deployed in regulatory agencies; Deploy a smart contract for the full lifecycle management of scheduling instructions on a consortium blockchain network. The smart contract has a pre-built state machine model of the scheduling instructions. The state machine model sets up several states of the instructions and the transition paths between the states. The system monitors the business operations of the scheduling system. When a scheduling instruction operation that meets the preset conditions is detected, the system extracts the scheduling instruction operation data to generate a transaction to be uploaded to the blockchain. The transaction to be uploaded to the blockchain is verified through a smart contract. Once the verification is successful, the operation event record corresponding to the scheduling instruction is written into the blockchain ledger, and the current state of the scheduling instruction is updated according to the state machine model. The scheduling instruction operation includes instruction drafting, approval, issuance, receipt, repetition, execution, cancellation, and invalidation. The operation event record includes at least the instruction identifier, operation type, digital signature of the operation subject, operation timestamp, and instruction content summary.

[0011] Furthermore, the scheduling instruction operation data is extracted to generate transactions to be uploaded to the blockchain, including: Obtain the business data for scheduling instructions and perform structured processing on the business data; The hash value of the business data is calculated using a preset hash algorithm, and the hash value is used as a digest of the instruction content. The instruction content summary, instruction identifier, and operator identity information are encapsulated, and the operator's private key is used to digitally sign the transaction to be uploaded to the blockchain. The full text of business data is stored in an off-chain database or file storage system, while the instruction summary is stored in the blockchain ledger to verify the integrity of the business data.

[0012] Furthermore, smart contracts are used to verify transactions to be uploaded to the blockchain, including: Verify the legitimacy of the operator's identity; Verify the validity of the digital signature of the entity performing the operation; Verify whether the user has the necessary permissions to perform the current operation; Verify for duplicate instruction numbers or conflicting instructions; Verify whether the current instruction state allows a transition to the target state. Verify the transaction format and field integrity; If all verifications pass, the smart contract is invoked to perform state updates and ledger write operations; otherwise, execution is refused and the exception information is recorded to the blockchain or log system.

[0013] Furthermore, the transition paths between states include at least: The process transitions from the draft stage to the approval stage; The process transitions from the approval status to the issuance status; The process transitions from the issuing state to the receiving state; The process transitions from the receiving state to the repeating state. The process transitions from the repetition state to the execution state. The process transitions from the execution state to the completion state. The process transitions from the completed state to the cancelled state. And under the corresponding conditions, it can transition from any intermediate state to the invalid state.

[0014] Furthermore, the operation timestamp is generated by the consortium blockchain node based on a unified trusted time source when packaging the transaction into a block, or it is issued by the time center when the business system generates the transaction.

[0015] Furthermore, it also includes audit tracing steps: Receive query requests sent by the audit terminal. The query requests carry instruction identifiers, time ranges, or information about the responsible party. Based on the query request, traverse the blockchain ledger to obtain all historical operation event records of the target scheduling instruction; Reassemble historical operation event records according to timestamp order to generate a full lifecycle sequence diagram of the instruction; Calculate the current hash value of the instruction business data stored off-chain and compare it with the instruction content digest stored on-chain. If they match, verify the data integrity; if they do not match, issue a data tampering warning.

[0016] Furthermore, the consortium blockchain network adopts a Byzantine fault-tolerant consensus mechanism or a practical Byzantine fault-tolerant consensus mechanism to ensure the consistency and immutability of data among nodes.

[0017] Secondly, a railway dispatching instruction lifecycle management system includes: The consortium blockchain network consists of scheduling center nodes, station nodes, professional department nodes, and regulatory nodes, and is used to provide distributed ledger storage and consensus services. The smart contract module, deployed on the consortium blockchain network, is used to set and execute the state machine logic and permission verification logic of scheduling instructions; The business access adaptation module is configured on the existing scheduling system side to monitor business operations and convert them into transaction requests that conform to the blockchain protocol. The identity authentication and access control module is used to issue digital certificates to dispatchers, station duty officers and operators, and to sign and verify on-chain transactions. The auditing and visualization module is used to read blockchain ledger data, visualize the instruction flow process, and verify the integrity of instruction data.

[0018] Thirdly, an electronic device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, which stores computer programs; When a processor executes a computer program stored in memory, it implements the aforementioned method for managing the lifecycle of railway dispatching instructions.

[0019] Fourthly, a computer-readable storage medium stores a computer program that, when executed by a processor, implements the aforementioned railway dispatch instruction lifecycle management method.

[0020] This disclosure includes at least the following beneficial effects: This disclosure establishes a railway dispatching business alliance chain, which solidifies the key operations of the entire process of dispatching instructions—from generation, approval, issuance, confirmation, execution, feedback to archiving—into a blockchain ledger using a unified data structure and state machine approach. This achieves tamper-proof and verifiable authenticity of dispatching instruction records, a unified timeline and chain of responsible parties throughout the entire lifecycle, multi-party joint maintenance and witnessing across systems and departments, and supports rapid and reliable auditing and traceability based on multiple dimensions such as instruction, time, and responsible person.

[0021] This disclosure eliminates the risk of tampering from single-point databases from a technical architecture perspective, achieving immutable evidence storage throughout the entire lifecycle of dispatch instructions; automatically constructs the "time sequence chain" and "responsibility chain" of dispatch instructions, providing strong evidentiary support for driving safety analysis and accident investigation; improves the efficiency of cross-system and cross-departmental collaboration in dispatch operations, reducing reliance on manual record-keeping and reconciliation; reduces auditing and traceability costs, and enables "one-click review" of all operational steps of a dispatch instruction throughout its lifecycle.

[0022] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objects and other advantages of this disclosure may be realized and obtained by means of the structures pointed out in the description and the accompanying drawings. Attached Figure Description

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

[0024] Figure 1 This is a schematic diagram of the management method flow according to an embodiment of the present disclosure; Figure 2 This is a schematic diagram illustrating the principle of trusted traceability of the entire lifecycle of railway dispatching instructions in an embodiment of this disclosure. Figure 1 ; Figure 3 This is a schematic diagram illustrating the principle of trusted traceability of the entire lifecycle of railway dispatching instructions in an embodiment of this disclosure. Figure 2 ; Figure 4 This is a schematic diagram of the scheduling instruction generation and on-chain process in an embodiment of this disclosure. Figure 1 ; Figure 5 This is a schematic diagram of the scheduling instruction generation and on-chain process in an embodiment of this disclosure. Figure 2 ; Figure 6This is a schematic diagram of the on-chain recording process from the issuance of a scheduling instruction to the completion of its execution, as shown in an embodiment of this disclosure. Figure 7 This is a schematic diagram of the anomaly handling and audit tracing process in an embodiment of this disclosure; Figure 8 This is a schematic diagram of the electronic device architecture according to an embodiment of this disclosure. Detailed Implementation

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

[0026] like Figure 1 As shown, a method for managing the lifecycle of railway dispatching instructions includes: Construct a railway dispatching business alliance chain network, which includes dispatch center nodes deployed in dispatch centers, station nodes deployed in stations, professional department nodes deployed in equipment maintenance units, and regulatory nodes deployed in regulatory agencies; Deploy a smart contract for the full lifecycle management of scheduling instructions on a consortium blockchain network. The smart contract has a pre-built state machine model of the scheduling instructions. The state machine model sets up several states of the instructions and the transition paths between the states. The system monitors the business operations of the scheduling system. When a scheduling instruction operation that meets the preset conditions is detected, the system extracts the scheduling instruction operation data to generate a transaction to be uploaded to the blockchain. The transaction to be uploaded to the blockchain is verified through a smart contract. Once the verification is successful, the operation event record corresponding to the scheduling instruction is written into the blockchain ledger, and the current state of the scheduling instruction is updated according to the state machine model. The scheduling instruction operation includes instruction drafting, approval, issuance, receipt, repetition, execution, cancellation, and invalidation. The operation event record includes at least the instruction identifier, operation type, digital signature of the operation subject, operation timestamp, and instruction content summary.

[0027] In practice: A reliable traceability method for the entire lifecycle of railway dispatching instructions based on blockchain technology mainly includes system architecture design, data model design, full lifecycle process design, and audit traceability mechanism.

[0028] Consortium blockchain node types: Dispatch center node: Deployed in railway bureaus or dispatching offices, used to record operations such as dispatchers generating, modifying, and canceling dispatch instructions; Station nodes: Deployed in the train operation control room of each station, used to record operations such as receiving, repeating, executing, and deleting instructions; Specialized department nodes: such as maintenance units like engineering, electrical, and power supply departments, used to record work plans and work confirmations related to dispatch instructions; Regulatory / Audit Node: Deployed at a higher-level regulatory agency or security supervision department, with only read access, for auditing and querying purposes; Backup / Evidence Storage Nodes: Deployed in a dedicated data center for long-term evidence storage and emergency recovery.

[0029] The scheduling instruction is identified on the chain. Each scheduling instruction is assigned a globally unique on-chain identifier ID when it is generated. For example, it adopts the encoding rule of "circuit / line / date / serial number + random number" and exists as the primary key on the chain.

[0030] The scheduling instruction state machine can abstract the instruction state into one of the following states: Created: The instruction has been prepared; Approved: The instruction has been approved according to the prescribed procedures (if applicable); Issued: The directive has been officially issued; Acknowledged: The station or relevant personnel have confirmed this. Executing: The command is being executed; Completed: Execution complete, proceeding to the pre-closing check stage; Closed: The cancellation and filing are complete; Cancelled: The instruction has been invalidated or revoked.

[0031] The transitions between states are controlled by predefined smart contracts to prevent illegal state transitions.

[0032] Each critical operation related to a scheduling instruction is recorded as an "event" on a chain. The event structure can include: Instruction chain identifier; Current operation type (generate, approve, issue, receive, repeat, execute, complete, cancel, void, modify, etc.); Before and after the operation; The identity of the operation initiator (dispatcher, station duty officer, track maintenance duty officer, etc.) and its digital certificate identifier; Operation time (obtained using a unified trusted time source); Key field summaries (such as instruction content summary, affected sections, affected trains, operation time windows, etc. hash values); Related information to records in the business system (such as the business system serial number); Related electronic signatures and signature verification results.

[0033] To save on-chain storage space, the full text of scheduling instructions can be stored in an off-chain database or file storage system, with only its hash digest written to the blockchain for integrity verification.

[0034] like Figure 2 and Figure 3 As shown, Figure 2 Follow-up Figure 3 This disclosure presents the overall process of a trusted traceability method for the entire lifecycle of railway dispatching instructions based on blockchain technology, comprising the following steps S101 to S108: S101: Construct a railway dispatching business alliance chain and deploy smart contracts; Configure the consortium blockchain nodes of each participating unit, establish a consensus mechanism, and deploy smart contracts for managing the lifecycle of scheduling instructions and access control contracts.

[0035] S102: Business System Access and Event Rule Configuration; Deploy access adaptation modules in existing key systems such as dispatching systems and vehicle terminal systems, and configure which business events need to trigger on-chain records, such as "new dispatching instruction", "station confirmation", "construction completion confirmation", etc.

[0036] S103: The scheduling instruction generation event is uploaded to the blockchain; When a dispatcher generates a new dispatch instruction in the dispatch system, the access module automatically extracts the core fields of the instruction according to the configuration, calculates the digest hash, and initiates a "new instruction" transaction to the consortium blockchain. The smart contract verifies the initiator's identity, permissions, and field integrity. After successful verification, the instruction is written to the blockchain, and its status is set to Created.

[0037] S104: Multi-level approval and instruction issuance processes are recorded on the blockchain; If the instruction requires multi-level approval or review, the approval result is confirmed by the approvers at each level on their terminals. The adaptation module will upload the approval operation to the blockchain, and the status will change from Created to Approved. When an instruction is issued, the smart contract updates its state from Approved to Issued and records the list of recipients.

[0038] S105: Station receives, repeats, and executes events on the blockchain; The station duty officer receives the instruction on the train operation terminal and repeats it for confirmation as required. The access module uploads the receiving and confirmation operations to the blockchain, changing the status to Acknowledged and Executing in sequence.

[0039] S106: The execution completion and cancellation process is recorded on the blockchain; Once the task is completed, the relevant personnel will confirm its completion in the system, and the status will change from Executing to Completed. After verifying the situation on-site, the dispatcher or station duty officer performs a write-off operation, changing the status from Completed to Closed. All related operations are then written to the blockchain.

[0040] S107: Abnormal events and modification / cancellation processing are uploaded to the blockchain; For errors or changes in conditions discovered during execution, they can be handled through modification or invalidation. The corresponding on-chain events will record the complete reasons for the changes and the responsible parties, and ensure that the historical records cannot be deleted.

[0041] S108: Audit and source tracing; During audits, accident investigations, or routine inspections, the audit and visualization module can be used to query the complete on-chain records of one or more scheduling instructions by instruction ID, time interval, or responsible person, enabling fast and reliable full lifecycle traceability.

[0042] like Figure 4 and Figure 5 As shown, Figure 4 Follow-up Figure 5 The scheduling instruction generation and on-chain process can be further refined into the following steps S201~S210: S201: Dispatcher logs in and authenticates; The dispatcher logs into the dispatch system using a digital certificate or a dedicated token. After identity authentication and permission verification are passed, the system writes a summary of the login event onto the blockchain (optional).

[0043] S202: Formulate scheduling instructions; The dispatcher fills in the instruction content in the dispatching system, including instruction type, applicable section, affected trains, start and end time of operation, precautions, etc.

[0044] S203: Local structuring and field validation; The scheduling system converts the input content into an internal structured data model and performs field integrity and compliance checks, such as checking for time window conflicts and segment conflicts.

[0045] S204: Calculate the instruction digest hash; The full text of the instruction or key fields are normalized in a pre-defined order, and a hash value (such as SHA-256) is calculated as a digest of the on-chain data.

[0046] S205: Generate an on-chain transaction request for a "new instruction"; The access adaptation module constructs a transaction request containing information such as the instruction chain identifier, digest hash, initiator identity, and creation time based on a predefined data structure, and signs the transaction using the scheduler's digital certificate.

[0047] S206: Smart contracts verify the legality of transactions; After receiving a transaction request, the smart contract automatically performs the following verifications: Verify whether the dispatcher's identity is legitimate and whether they have the appropriate permissions; Verify signature validity; Check for duplicate instruction numbers or conflicting instructions; Check the transaction format and field integrity.

[0048] S207: Consensus and Ledger Records; Once a transaction passes contract verification, the multiple nodes participating in the consensus process sort the transactions according to a consensus algorithm (such as PBFT, Raft, or one of the other implementations) and package them into blocks, then write them into the distributed ledger.

[0049] S208: Return the result of the previous chain; Once consensus is reached, information such as block height and transaction hash recorded on the chain is returned to the business system through an interface. The business system can then associate and store this identification information with local data.

[0050] S209: Set the initial state of the instruction to Created; The smart contract creates a lifecycle record for the instruction in the ledger, sets the state to Created, and records the time the state was generated.

[0051] S210: Notification of approval or issuance of procedures; If approval is required, the system will trigger the approval process based on the configuration; if no approval is required, the system can directly proceed to the issuance process.

[0052] Through the above process, the scheduling instruction is stored on the blockchain with multi-party witnessing at the time of generation, and any subsequent step can be traced back to this initial record.

[0053] like Figure 6 As shown, the on-chain recording process from the issuance of a scheduling instruction to the completion of execution includes steps S301 to S309: S301: Instruction issued and uploaded to the chain; After the dispatcher confirms the instructions are correct, they execute the "issue" operation in the scheduling system. The access module generates an on-chain transaction of type "issue," containing a list of recipients. After smart contract verification, the status is updated from Created / Approved to Issued.

[0054] S302: Station receives instructions; The station duty officer receives the instruction on the train operation terminal. The system sends the "receive time" and "recipient" information to the chain and records it as a new event. The status can remain as Issued or be converted to an intermediate state (such as "delivered but not confirmed", depending on the specific design).

[0055] S303: Repetition and verification; The duty officer repeats and verifies the instructions with the dispatcher according to the business procedures. After the repeating and confirmation is completed, the vehicle terminal triggers a "repeated confirmation" event on the blockchain, the contract updates the instruction status to Acknowledged, and records the identities of both parties repeating the instructions.

[0056] S304: Pre-execution condition check; Before execution, the station or relevant personnel shall conduct on-site condition checks (such as turnout position, signal status, etc.). The check results can be entered into the front-end terminal and uploaded to the blockchain to form proof of the conditions before execution.

[0057] S305: Entering execution state; Once the conditions are met, the duty officer or relevant personnel will perform the "Start Execution" operation in the system, triggering an on-chain event and changing the status to Executing.

[0058] S306: Important node records during execution (optional); For instructions involving long durations or high risks, such as construction or slow-moving operations, key checkpoints (such as phased completion confirmation or temporary pauses) can be set. Each key node operation triggers on-chain records, forming a more granular execution process trajectory.

[0059] S307: Confirmation of completion of execution; Once the task is completed, the person in charge of the task performs a "completion confirmation" operation on the terminal. The on-chain event record shows the completion time, a description of the completion status, and the identity of the person in charge. The status is updated from Executing to Completed.

[0060] S308: Cancellation and Archiving; The dispatcher or station duty officer performs a cancellation operation based on the on-site situation and work completion information. The system writes the "cancellation event" onto the chain and updates the status from Completed to Closed. At this point, the instruction's lifecycle is closed on the state machine.

[0061] S309: Off-chain full-text archiving and on-chain digest verification; When the full text of the instruction and its supplementary materials (such as construction plans, photos, etc.) are archived off-chain, the system can recalculate the digest hash and compare it with the digest stored on-chain to ensure that the archived content has not been tampered with.

[0062] like Figure 7 As shown, this disclosure also defines anomaly handling and audit tracing procedures, including steps S401 to S409: S401: An abnormal event has been triggered; When a driving anomaly, equipment failure, or safety incident occurs, relevant personnel enter the abnormal event information into the accident analysis system or dispatch system.

[0063] S402: Determine the relevant time range and segment; Based on information such as the time and location of the anomaly, auditors or analysts can initially determine the time range and line segment of the dispatch instructions that may be involved.

[0064] S403: Initiate instruction retrieval in the audit module; The auditing and visualization module retrieves a list of all potentially relevant scheduling instructions from the blockchain ledger using criteria such as "time range + segment + instruction type".

[0065] S404: Select target scheduling instruction; Select one or more target instructions from the search results, and the system will automatically summarize all event records of them on the chain and display them in chronological order.

[0066] S405: Construct the instruction lifecycle timing diagram; The system sorts the events on the chain by their occurrence time and generates a lifecycle sequence diagram of the instruction, including information such as the time of each state transition, the operator, and the operating terminal.

[0067] S406: Integrity and Consistency Verification; The audit module automatically verifies: Check if there are any missing states or illegal jumps in the on-chain records; Are the time and operator information consistent between the off-chain system logs and the on-chain records? Does the hash of the full instruction text match the on-chain evidence?

[0068] S407: Automatic Chain of Responsibility Analysis; By analyzing the operation records of the instruction at each node, a chain of responsible parties is automatically generated (e.g., "drafter - approver - issuer - recipient - execution confirmer - cancellation person"), and displayed intuitively on the interface.

[0069] S408: Generate an audit report; The system can automatically generate audit reports as needed. The key data cited in the reports include on-chain block heights and transaction hashes, which can serve as technical evidence.

[0070] S409: Abnormal Handling and Experience Feedback; Audit results can be fed back to the safety management and business process optimization stages, providing quantitative basis for improving scheduling regulations.

[0071] This disclosure abstracts scheduling instructions into an on-chain state machine, with smart contracts strictly constraining state transition paths to prevent business processes from being bypassed. It employs a unified data model and event structure to uniformly map operations from different business systems and stages to on-chain events. Utilizing consortium blockchain consensus mechanisms and encryption algorithms, it achieves multi-party joint maintenance and tamper-proofing of instruction records. Through a unified trusted time source (such as GPS time synchronization, PTP time synchronization, etc., combined with on-chain timestamps), it ensures the comparability and reliability of event times throughout the lifecycle. Through auditing and visualization modules, it supports multi-dimensional and multi-granular queries and analyses, improving auditing and traceability efficiency.

[0072] A railway dispatching instruction lifecycle management system, comprising: The consortium blockchain network consists of scheduling center nodes, station nodes, professional department nodes, and regulatory nodes, and is used to provide distributed ledger storage and consensus services. The smart contract module, deployed on the consortium blockchain network, is used to set and execute the state machine logic and permission verification logic of scheduling instructions; The business access adaptation module is configured on the existing scheduling system side to monitor business operations and convert them into transaction requests that conform to the blockchain protocol. The identity authentication and access control module is used to issue digital certificates to dispatchers, station duty officers and operators, and to sign and verify on-chain transactions. The auditing and visualization module is used to read blockchain ledger data, visualize the instruction flow process, and verify the integrity of instruction data.

[0073] In practice: The blockchain infrastructure platform implements consensus mechanisms, ledger storage, smart contract execution, and encryption algorithms; the scheduling instruction lifecycle management implements scheduling instruction state machine management, event-driven processing, and lifecycle control.

[0074] The consortium blockchain network consists of scheduling center nodes, station nodes, professional department nodes, and regulatory nodes, and is used to provide distributed ledger storage and consensus services. The smart contract module, deployed on the consortium blockchain network, is used to set and execute the state machine logic and permission verification logic of scheduling instructions; The business system access and adaptation module interfaces with existing dispatch systems, vehicle terminal systems, etc., to achieve business event capture and data conversion. The identity authentication and access control module, based on digital certificates and role-based access control models, performs identity authentication and access control for on-chain operations. The auditing and visualization module provides multi-dimensional query and visualization capabilities by instruction, time, personnel, and device.

[0075] By constructing a consortium blockchain network encompassing dispatch centers, stations, specialized departments, and regulatory agencies, traditional centralized data storage is transformed into a distributed ledger jointly maintained by multiple parties. Leveraging the immutability and cryptographic algorithms of blockchain, it ensures that dispatch instructions, once uploaded to the chain, cannot be unilaterally modified or deleted. This effectively eliminates the single point of failure risk and internal tampering vulnerabilities inherent in centralized databases, providing a solid foundation of data trust for cross-departmental business collaboration.

[0076] The business logic of scheduling instructions is abstracted into an on-chain state machine, and strict flow rules are pre-defined through smart contracts (such as no instructions can be issued without approval, and no instructions can be executed without repetition). This technically enforced control mechanism effectively prevents people from skipping key steps, violating regulations, or modifying processes, ensuring that the generation and execution of scheduling instructions strictly comply with railway traffic safety regulations.

[0077] This disclosure enables the on-chain recording of key events throughout the entire process of an instruction, from drafting, approval, issuance, repetition, execution to cancellation. Combined with a unified and trusted time source, a complete and irreversible time-series evidence chain is formed. In the event of an incident or during an audit, the complete lifecycle of the instruction can be quickly traced back, data integrity can be automatically verified, and the responsible party can be accurately identified, greatly shortening incident analysis time and reducing the cost of liability determination.

[0078] By using a unified data model and event logging structure, data from different geographical locations and different business systems (dispatch systems, train operation terminals, etc.) are mapped to the same on-chain ledger. This solves the problem of data consistency difficulties caused by the reliance on system interface interfaces for cross-bureau and cross-section instructions in the traditional model, and enables real-time synchronization and sharing of data from multiple parties, thereby improving the overall collaborative operation efficiency of railway dispatching.

[0079] like Figure 8 As shown, this disclosure provides an electronic device, including a processor 801, a communication interface 802, a memory 803, and a communication bus 804, wherein the processor 801, the communication interface 802, and the memory 803 communicate with each other through the communication bus 804; Memory 803 stores computer programs; The processor 801 implements the above method when executing a computer program stored in the memory 803.

[0080] This disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0081] The computer-readable storage medium may be included in the device / apparatus described in the above embodiments; or it may exist independently and not assembled into the device / apparatus. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0082] According to embodiments of this disclosure, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0083] To enable those skilled in the art to better understand this disclosure, the principles of this disclosure are explained below in conjunction with the accompanying drawings: like Figure 1 As shown, this disclosure constructs a railway dispatching business consortium blockchain network including a dispatching center, stations, professional departments, and regulatory nodes; deploys smart contracts with pre-built state machine models; a business system access adaptation module monitors key operations of the existing dispatching system, extracts operation data to generate transactions to be uploaded to the blockchain; the smart contract verifies the legality and permissions of the transactions, and upon successful verification, records the operation events in the blockchain ledger and updates the instruction status. This disclosure utilizes the immutability and traceability of blockchain, combined with the strict constraints of smart contracts on state transitions, to achieve trusted evidence storage and multi-party consensus throughout the entire process of dispatching instructions from drafting, approval, issuance, execution to cancellation. This solves the problems of easily tampered data, difficulty in cross-entity collaboration, and unclear responsibility definition in existing centralized management schemes, significantly improving the security and audit traceability efficiency of railway dispatching operations.

[0084] In existing technologies, most solutions focus on centralized storage and analysis of event logs or data sharing in the broader transportation sector. There is a lack of complete blockchain solutions that deeply integrate with industry regulations and business processes for the specific scenario of the "full lifecycle of railway dispatching instructions." This disclosure proposes a systematic approach for this specific scenario.

[0085] The most typical electronic scheduling instruction management methods currently used in the industry are as follows: (1) Centralized dispatching instruction management system: The dispatching instruction management system is deployed in the dispatching office. The dispatcher enters the dispatching instruction content through the system. The instruction is sent to the relevant stations and posts through a dedicated communication network. The station duty officer receives and confirms the instruction on the train operation terminal. The system records the basic information such as the generation time, the target of the instruction, and the confirmation time in the central database. Key instructions still require the printing of paper dispatching orders, which are registered by the station in the paper dispatching order register.

[0086] The problem is that all electronic records are concentrated in the dispatch center or a central computer room database, which poses a single point of failure and the risk of tampering. The execution, repetition, and cancellation processes at the station are still mainly recorded by paper records or independent systems, making it difficult to form a complete chain with the central database. For instructions that are coordinated across bureaus and regions, they often rely on the interface between the two systems, making it difficult to guarantee data consistency in real time.

[0087] (2) Enhanced solutions based on electronic signatures and log auditing: Some systems have introduced digital certificates, electronic signatures and operation log auditing mechanisms. The main practices include: dispatchers and station personnel use USB keys or soft certificates when logging into the system; electronically signing the content of dispatch instructions when generating or confirming them; and saving operation logs, including login logs and instruction operation logs.

[0088] The problem is that, although electronic signatures and log auditing have been introduced, the solution is still based on a centralized system: logs and signature information are still stored in the center or on a few servers; the auditing process relies on operations and maintenance personnel to export logs, which is opaque; there is a lack of a mutually trusted "common ledger" among the parties, and additional proof is still required when it comes to defining cross-unit responsibilities.

[0089] This disclosure introduces blockchain technology, abstracting the lifecycle of scheduling instructions into an on-chain state machine, and solidifying key events on the consortium blockchain to achieve a higher level of trusted traceability. For example... Figure 1 As shown, this disclosure adopts on-chain state machine modeling for the entire lifecycle of scheduling instructions, abstracting the scheduling instructions from "drafting, approval, issuance, receipt, repetition, execution, completion, cancellation, and invalidation" into a state machine; and constrains state transitions through smart contracts to prohibit illegal state jumps.

[0090] This disclosure adopts a scheduling instruction ledger structure based on a consortium blockchain, which is jointly maintained by multiple parties. The consortium blockchain consists of a scheduling center, stations, professional departments, regulatory agencies, etc., and uses a consensus algorithm to jointly maintain the scheduling instruction ledger. Key operations of each party are recorded as immutable on-chain events.

[0091] This disclosure adopts an event-driven access mechanism between the scheduling business system and the blockchain. Through the access adaptation module, key business events are captured from the existing scheduling system, vehicle terminal, etc., and converted into on-chain transaction requests in a unified format, so as to achieve a minimally invasive transformation of the original system.

[0092] This disclosure employs a combination of on-chain evidence storage and off-chain full-text storage for instruction data integrity protection. The full text of the instruction and its attachments are stored off-chain, while only the digest hash, key fields, and status information are written to the blockchain. The integrity verification of the full text of the instruction is achieved through hash comparison, balancing performance and security.

[0093] This public unified and trusted time source and responsibility entity binding mechanism ensures the uniformity of event time across the entire network through a unified time synchronization system and on-chain timestamps; and utilizes digital certificates and role-based access control system to strongly bind operator identities on the chain, enabling traceability of responsible entities.

[0094] This disclosure adopts a multi-dimensional instruction tracing approach for auditing and incident investigation. It automatically retrieves relevant on-chain records based on multiple conditions such as instruction ID, time interval, line segment, instruction type, and responsible person. It automatically generates instruction lifecycle sequence diagrams and responsibility chains, and supports one-click export of audit reports.

[0095] This disclosure adopts an indelible chain-based evidence storage mechanism for exception handling and change records, which records operations such as instruction modification, revocation, and exception handling separately, rather than overwriting the original records; ensuring that any change has a complete on-chain history that can be traced.

[0096] An optional fine-grained on-chain recording mechanism for execution processes allows for the configuration of key execution nodes to be recorded on the chain for high-risk, long-cycle scheduling instructions, forming a more granular execution trajectory.

[0097] This disclosure upgrades from a centralized "record" to a consortium blockchain "consensus ledger." In existing solutions, scheduling instruction records are mainly maintained by a central database, and their credibility depends on a single institution and operation and maintenance management. This disclosure adopts a consortium blockchain, in which multiple nodes participate in consensus and ledger recording. Any single party tampering with the record will be detected by other nodes, thus improving the credibility of the record from an architectural perspective.

[0098] This disclosure upgrades from "partial stage logs" to "full lifecycle chain tracing." Existing solutions often only record a few stages such as generation, issuance, and confirmation, and different systems record them separately. This disclosure maps all key stages of the scheduling instruction lifecycle into on-chain events, forming a complete chain record from Created to Closed, truly achieving reliable traceability throughout the entire lifecycle.

[0099] This disclosure offers stronger time consistency and traceability of responsible parties. In existing solutions, the time sources of different systems are not uniform and the log formats are inconsistent, requiring manual comparison during auditing. This disclosure adopts a unified and reliable time source and a unified data structure, automatically recording the time of each operation and the identity of the responsible party. The chain of responsibility is automatically generated technically, reducing human judgment bias.

[0100] This disclosure reduces auditing and incident investigation costs and improves efficiency. Traditionally, auditing and incident investigations require significant manual effort to export and compare logs from multiple systems; this disclosure, through its auditing and visualization modules, allows for a single query to obtain the complete on-chain trace of a specific instruction, and enables cross-instruction correlation analysis, greatly shortening auditing time.

[0101] This disclosure has minimal invasiveness to existing systems and is easy to integrate with existing architectures. This disclosure uses an access adaptation module to access in an event-driven manner, without requiring the replacement of the existing scheduling system. Only event capture and on-chain logic needs to be added at key interfaces. This facilitates smooth evolution on the basis of existing systems and reduces the risks and costs of transformation.

[0102] This disclosure supports expansion to a wider range of traffic safety scenarios. While maintaining the core architecture, the methods disclosed herein can be extended to other traffic safety-related command scenarios such as train timetable adjustment orders and construction plan approvals, demonstrating good scalability and versatility.

[0103] Optionally, the underlying platform of the consortium blockchain can adopt different implementation frameworks, such as Hyperledger Fabric, FISCO BCOS, or modified enterprise-grade blockchain platforms; the consensus algorithm can be PBFT, improved BFT, Raft, PoA (based on authorization proof), etc., as long as it can meet the consistency and performance requirements of railway scheduling scenarios.

[0104] Optionally, in certain scenarios, station nodes and professional department nodes can be merged into a "field integrated node," which can act as an agent to record the operations of multiple positions. For stations with relatively weak technical conditions, "proxy nodes" can be set up, with neighboring centers or regional nodes participating in consensus on their behalf, while the station itself only acts as a light node or client.

[0105] Optionally, for scenarios with high storage and performance requirements, only key fields (such as instruction number, instruction type, segment, time window, etc.) and summary hash can be put on the chain, while detailed text, attachments, etc. are stored off-chain; for instruction types with higher regulatory requirements or smaller data volume, the full text of the instruction can be encrypted before being put on the chain, and only nodes with corresponding permissions can decrypt and view it.

[0106] Optionally, the specific state machine definition and state transition rules can be adjusted according to the scheduling regulations of each railway bureau or line, such as adding intermediate states such as "pending review" and "pending cancellation confirmation"; different contract templates and state machines can be used for different types of scheduling instructions (such as blockade orders, slow-moving orders, construction orders, etc.) to more precisely match business differences.

[0107] Optionally, the time source can be implemented using different methods such as GPS time synchronization, PTP precision time protocol, or railway-specific time synchronization system, as long as it can meet the unified time requirements; the on-chain timestamp can be implemented using mechanisms such as "local time + consensus verification" or "introducing independent timestamp service nodes".

[0108] Optionally, the lifecycle of instructions can be displayed in different interface formats such as lists, timelines, flowcharts, and topology diagrams, depending on user habits; it can also support aggregated analysis and display by different dimensions such as by route, by train number, and by equipment.

[0109] Optionally, different encryption strategies and access control models can be adopted under different regulatory requirements, such as attribute-based access control (ABAC) and role-based access control (RBAC). Through technologies such as multi-party secure computation and zero-knowledge proof, it is possible to verify whether certain instructions meet the corresponding conditions without disclosing sensitive details.

[0110] Although the present disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure.

Claims

1. A method for railway dispatching instruction lifecycle management, characterized in that, include: Construct a railway dispatching business alliance chain network, which includes dispatch center nodes deployed in dispatch centers, station nodes deployed in stations, professional department nodes deployed in equipment maintenance units, and regulatory nodes deployed in regulatory agencies; Deploy a smart contract for the full lifecycle management of scheduling instructions on a consortium blockchain network. The smart contract has a pre-built state machine model of the scheduling instructions. The state machine model sets up several states of the instructions and the transition paths between the states. The system monitors the business operations of the scheduling system. When a scheduling instruction operation that meets the preset conditions is detected, the system extracts the scheduling instruction operation data to generate a transaction to be uploaded to the blockchain. The transaction to be uploaded to the blockchain is verified through a smart contract. Once the verification is successful, the operation event record corresponding to the scheduling instruction is written into the blockchain ledger, and the current state of the scheduling instruction is updated according to the state machine model. The scheduling instruction operation includes instruction drafting, approval, issuance, receipt, repetition, execution, cancellation, and invalidation. The operation event record includes at least the instruction identifier, operation type, digital signature of the operation subject, operation timestamp, and instruction content summary.

2. The railway dispatching instruction lifecycle management method according to claim 1, characterized in that, Extract scheduling instruction operation data to generate transactions to be uploaded to the blockchain, including: Obtain the business data for scheduling instructions and perform structured processing on the business data; The hash value of the business data is calculated using a preset hash algorithm, and the hash value is used as a digest of the instruction content. The instruction content summary, instruction identifier, and operator identity information are encapsulated, and the operator's private key is used to digitally sign the transaction to be uploaded to the blockchain. The full text of business data is stored in an off-chain database or file storage system, while the instruction summary is stored in the blockchain ledger to verify the integrity of the business data.

3. The railway dispatching instruction lifecycle management method according to claim 1, characterized in that, Verification of transactions to be uploaded to the blockchain via smart contracts includes: Verify the legitimacy of the operator's identity; Verify the validity of the digital signature of the entity performing the operation; Verify whether the user has the necessary permissions to perform the current operation; Verify for duplicate instruction numbers or conflicting instructions; Verify whether the current instruction state allows a transition to the target state. Verify the transaction format and field integrity; If all verifications pass, the smart contract is invoked to perform state updates and ledger write operations; otherwise, execution is refused and the exception information is recorded to the blockchain or log system.

4. The railway dispatching instruction lifecycle management method according to claim 1, characterized in that, The transition path between states must include at least: The process transitions from the draft stage to the approval stage; The process transitions from the approval status to the issuance status; The process transitions from the issuing state to the receiving state; The process transitions from the receiving state to the repeating state. The process transitions from the repetition state to the execution state. The process transitions from the execution state to the completion state. The process transitions from the completed state to the cancelled state. And under the corresponding conditions, it can transition from any intermediate state to the invalid state.

5. The railway dispatching instruction lifecycle management method according to claim 1, characterized in that, Operation timestamps are generated by consortium blockchain nodes based on a unified trusted time source when packaging transactions into blocks, or by business systems applying to the time center for issuance when generating transactions.

6. The railway dispatching instruction lifecycle management method according to claim 1, characterized in that, It also includes audit tracing steps: Receive query requests sent by the audit terminal. The query requests carry instruction identifiers, time ranges, or information about the responsible party. Based on the query request, traverse the blockchain ledger to obtain all historical operation event records of the target scheduling instruction; Reassemble historical operation event records according to timestamp order to generate a full lifecycle sequence diagram of the instruction; Calculate the current hash value of the instruction business data stored off-chain and compare it with the instruction content digest stored on-chain. If they match, verify the data integrity; if they do not match, issue a data tampering warning.

7. The railway dispatching instruction lifecycle management method according to claim 1, characterized in that, Consortium blockchain networks employ Byzantine fault-tolerant consensus mechanisms or practical Byzantine fault-tolerant consensus mechanisms to ensure the consistency and immutability of data among nodes. 8.A blockchain-based railway dispatching instruction full-life-cycle trusted traceability system, characterized in that, include: The consortium blockchain network consists of scheduling center nodes, station nodes, professional department nodes, and regulatory nodes, and is used to provide distributed ledger storage and consensus services. The smart contract module, deployed on the consortium blockchain network, is used to set and execute the state machine logic and permission verification logic of scheduling instructions; The business access adaptation module is configured on the existing scheduling system side to monitor business operations and convert them into transaction requests that conform to the blockchain protocol. The identity authentication and access control module is used to issue digital certificates to dispatchers, station duty officers and operators, and to sign and verify on-chain transactions. The auditing and visualization module is used to read blockchain ledger data, visualize the instruction flow process, and verify the integrity of instruction data.

9. An electronic device, comprising: It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, which stores computer programs; A processor, when executing a computer program stored in memory, implements a railway dispatching instruction lifecycle management method according to any one of claims 1-7.

10. A computer readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements a railway dispatching instruction lifecycle management method according to any one of claims 1-7.

Images