Train working diagram conversion system, method, device and medium for multi-network convergence

Abstract

The present application relates to a kind of train working diagram conversion system, method, equipment and medium for multi-network fusion, the conversion system includes the interface machine connected with CTC system and CBTC-based ATS system respectively, the interface machine is independent of CTC system and ATS system;After the interface machine receives the working diagram data issued under CTC system, according to the preset conversion rule, the structured conversion of CTC working diagram is carried out, and the converted working diagram is sent to the central server CATS in ATS system.Compared with prior art, the present application realizes the automatic, high-reliable conversion and synchronization between the two sets of heterogeneous working diagram systems of CTC and ATS, significantly reduces the complexity and error rate of manual conversion, improves the efficiency of dispatching coordination and the consistency of train data, and provides key technical support for track traffic multi-signal system integration, line upgrading and cross-line operation scheduling.

Description

Technical Field

[0001] This invention relates to rail transit signaling systems, and more particularly to a train timetable conversion system, method, device, and medium for multi-network convergence. Background Technology

[0002] With the development of metropolitan areas and urban clusters, the "multi-network integration" of rail transit has become an inevitable trend. A key aspect is achieving cross-line operation or coordinated scheduling between national railways (usually using the CTC system) and urban rail transit (usually using the CBTC system). Currently, the CTC and CBTC systems differ fundamentally in technical standards, control logic, and timetable formats. CTC timetables primarily include macro-level planning information such as train arrival and departure times at stations, track occupancy, and route sequences; ATS timetables, in addition to basic timetable information, must also include precise speed curves, operating levels, train operation modes, and protection points, among other micro-level control parameters, to adapt to the moving block logic of CBTC. The two systems are designed independently, with incompatible data interfaces, making it impossible to directly understand and use each other's operating plans.

[0003] In multi-network convergence scenarios, when a train needs to enter the urban rail network from the national railway network, or needs to operate on CBTC lines using a plan issued by the CTC (China Railway Control Center), there is a lack of effective technical means to automatically and accurately convert and reconstruct the macro-level operation plan issued by the CTC system into a detailed operation plan that the CBTC system can recognize and execute, conforming to the moving block control logic. Currently, this usually relies on manual translation and re-compilation based on experience, which is inefficient, error-prone, and cannot meet the high-density, high-real-time operational requirements, becoming a major challenge in multi-network convergence operations.

[0004] Meanwhile, in the existing rail transit dispatching system, the CTC system is typically used in traditional railways or some urban rail lines. Its timetable uses independent train numbers as the basic dispatching unit, and the train plan ends after completing a single journey from the originating station to the terminating station, lacking explicit support for train turnarounds and continuous cyclical operations. In contrast, the ATS timetable in the CBTC system is designed for high-density, public transport-like urban rail transit scenarios, supporting the same train to run cyclically within a fixed route, and using multi-layered identification and management through "service numbers" (identifying the train's full-journey service) and "single-journey numbers" (identifying the single trip after each turnaround). The two systems have fundamental differences in the data structure of the timetable, train identification logic, plan succession relationships, and control granularity. This makes it difficult to directly interact with the timetable and conduct unified dispatching in mixed-system lines, transitional phases between old and new systems, or cross-line dispatching scenarios. This not only increases the workload and error risk of manual conversion but also affects the efficiency and safety of train dispatching.

[0005] A search revealed that Chinese Patent Publication No. CN114872766A discloses a signal dispatching system for urban rail transit oriented towards multi-network integration. This system is a signal dispatching system for trunk railways, intercity railways, urban rail transit lines, and urban rail transit lines. It includes a two-layer architecture of center and stations, adopts a distributed architecture, integrates the hardware and software of CTC and ATS, and considers the standardization of external interfaces with other systems of existing national railway lines by setting up a separate interface server to achieve seamless access to national railway lines. This existing patent meets the two core operational requirements of urban rail transit: public transportation and networking, and has a high degree of flexible configuration. However, it does not have a clear method to solve the conversion between CTC operation diagrams and ATS operation diagrams. Therefore, in multi-network convergence scenarios, when a train needs to enter the urban rail network from the national railway network, or needs to use the plan issued by the CTC to run on the CBTC line, there is a lack of an effective technical means to automatically and accurately convert and reconstruct the macro-operation plan issued by the CTC system into a detailed operation plan that the CBTC system can recognize, execute, and conform to the moving block control logic. Summary of the Invention

[0006] The purpose of this invention is to overcome the defects of the prior art and provide a train timetable conversion system, method, device and medium for multi-network integration.

[0007] The objective of this invention can be achieved through the following technical solutions: According to a first aspect of the present invention, a train timetable conversion system for multi-network convergence is provided, the conversion system comprising an interface unit connected to a CTC system and a CBTC-based ATS system respectively, the interface unit being independent of the CTC system and the ATS system; After receiving the operation diagram data issued by the CTC system, the interface machine performs a structured transformation of the CTC operation diagram according to the preset transformation rules, and sends the transformed operation diagram to the central server CATS in the ATS system.

[0008] As a preferred technical solution, the interface unit monitors the connection status with CTC and CATS in real time; Once the interface device re-establishes a connection with the CTC system, it actively sends a reconnection notification message to the CTC system at a configurable period. The CTC system provides a clear prompt on the dispatcher interface and sends a confirmation response. After receiving the response, the interface device stops sending messages periodically. When the connection between the interface machine and CATS is restored, the same two-way handshake and status synchronization process is executed.

[0009] As a preferred technical solution, the structured transformation of the CTC operation diagram according to the preset transformation rules specifically involves: First, the linear operation diagram of the CTC system centered on train numbers is decomposed into basic train operation information, then reorganized into a structured data model that meets ATS requirements and supports train turnaround and route loops, and finally the mapping relationship between service number and one-way number is automatically generated.

[0010] As a preferred technical solution, when the CTC system sends information about each train to the interface machine, it includes the train number of the preceding train. The interface machine uses train information and the accompanying previous train number to construct a train sequence linked list locally, clarifying the train connection and turnaround logic at the station.

[0011] As a preferred technical solution, the interface machine loads the CBTC route configuration table during the startup phase and establishes a hash table cache; when it receives the CTC train route description, it quickly maps it to the corresponding CBTC route identifier through hash lookup.

[0012] As a preferred technical solution, the CBTC route configuration table includes route ID, station sequence, turnaround station, and running time.

[0013] As a preferred technical solution, the interface machine calculates the MD5 checksum of the received CTC operation graph data and compares it with the checksum attached to the data packet; If the verification fails, a receipt failure message is returned to the CTC system, requesting a retransmission; after the verification passes, the converted data is forwarded to CATS.

[0014] As a preferred technical solution, after receiving the complete operation diagram forwarded by the interface machine, the CATS performs MD5 verification again.

[0015] As a preferred technical solution, the process of performing the MD5 check again specifically involves: The ATS station server LATS periodically sends a plan data verification message to CATS, which carries the MD5 value of the local current plan data. CATS compares the received MD5 value with its own cached value. If they do not match, it will proactively resynchronize the daily plan with the corresponding LATS. When LATS starts up, restarts, or the host is upgraded, it immediately sends a full plan synchronization request to CATS. If CATS detects an MD5 inconsistency during synchronization, it will report a failure to sign off to the interface machine and notify the CTC system through the interface machine for appropriate processing.

[0016] According to a second aspect of the present invention, a method for using the aforementioned train timetable conversion system for multi-network convergence is provided, the method comprising the following steps: Step S1: The CTC system sends the operation diagram data to the interface machine; Step S2: The interface device verifies the received CTC operation diagram data. If the verification is successful, proceed to step S3; otherwise, proceed to step S6. Step S3: The interface machine performs a structured transformation on the CTC operation diagram according to the preset transformation rules. If the transformation is successful, the transformed data is sent to the central server CATS and step S4 is executed; otherwise, step S6 is executed. Step S4: The central server CATS creates the ATS daily driving plan. If the creation is successful, proceed to step S5; otherwise, proceed to step S6. Step S5: The central server CATS synchronizes with the ATS station server LATS. If the synchronization is successful, the CTC system is notified that the receipt is successful; otherwise, proceed to step S6. In step S6, the interface device notifies the CTC system that the receipt has failed.

[0017] According to a third aspect of the present invention, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method described thereon.

[0018] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method described thereon.

[0019] Compared with the prior art, the present invention has the following advantages: 1) This invention pioneered an automatic conversion rule for the operation diagram between CTC and CBTC systems: it proposed a complete conversion methodology from macroscopic fixed block plan to microscopic moving block plan, filling a technological gap in this field; 2) This invention is based on rule-based intelligent mapping of operating parameters: elements such as routes and tracks in CTC are automatically mapped to control parameters such as paths, operating levels, and mode conversions in CBTC through a rule base, thereby realizing the translation of control logic; 3) This invention provides a software solution for seamless integration of driving plans across multiple systems under multi-network convergence: through an independent conversion engine, the interoperability of driving plans is achieved without modifying the existing CTC and CBTC core systems, thereby reducing integration costs and risks. Attached Figure Description

[0020] Figure 1 This is an architecture diagram of the CTC-ATS operation diagram conversion system of the present invention; Figure 2 This is a flowchart illustrating the CTC-ATS runtime graph conversion method of the present invention. Figure 3This is a flowchart illustrating the specific process of CTC-ATS operation diagram conversion in this invention. Detailed Implementation

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

[0022] Example 1 This invention proposes an intelligent conversion engine deployed between CTC and CBTC-ATS systems. By constructing a bidirectional adaptive data model and communication protocol, it achieves automatic parsing, reconstruction, and synchronization between heterogeneous runtime graphs. This engine possesses independent data processing and caching mechanisms, enabling accurate conversion and reliable transmission of runtime graph information without interfering with the normal operation of existing systems.

[0023] like Figure 1 As shown, a train timetable conversion system for multi-network integration includes an interface machine that is connected to both the CTC system and the CBTC-based ATS system, and the interface machine is independent of the CTC system and the ATS system. After receiving the operation diagram data issued by the CTC system, the interface machine performs a structured transformation of the CTC operation diagram according to the preset transformation rules, and sends the transformed operation diagram to the central server CATS in the ATS system.

[0024] This invention establishes an independent ATS-CTC interface machine (hereinafter referred to as the "interface machine"), which is independent of the existing ATS central server (CATS) and CTC dispatch center in both physical topology and logical function. As a dedicated data conversion and communication hub, the interface machine embeds a runtime graph conversion module, a communication adaptation module, a data verification module, and a cache management module, which are respectively responsible for the local storage of static information such as runtime graph model mapping, protocol encapsulation and parsing, data integrity verification, and routing configuration.

[0025] This invention establishes a reconnection alarm mechanism. To ensure the reliability of the communication link, the interface device monitors the connection status with CTC and CATS in real time. When the interface device re-establishes a connection with the CTC system, it actively sends a reconnection notification message to the CTC at a configurable period. The CTC system provides a clear prompt on the dispatcher interface and sends a confirmation response. After receiving the response, the interface device stops sending messages periodically. Similarly, when the connection between the interface device and CATS is restored, a similar two-way handshake and status synchronization process is executed to ensure that both systems can sense the change in connection status and avoid incomplete transmission of planned data or loss of control commands due to communication interruption.

[0026] This invention features a plan reception and conversion process. To ensure the relative independence of the CTC system and the ATS system, the interface machine needs to adapt to the operation diagram interfaces of both systems. While the dispatcher completes the operation diagram editing at the CTC terminal and issues it to the station's automated control unit, the plan data is simultaneously sent to the interface machine. Upon receiving the data, the interface machine performs a structured conversion of the CTC operation diagram according to preset conversion rules and forwards it to the CATS. Specifically, this includes: 1) Decompose the CTC linear operation diagram centered on train number into basic train operation information (such as train number, arrival and departure time, and route nodes), and then reorganize it into a structured data model that meets the requirements of ATS and supports train turnaround and route loop, and automatically generate the mapping relationship between service number and one-way number. 2) When the CTC system sends information about each train to the interface machine, it includes the train number of the preceding train. The interface machine uses this information to build a train sequence list locally, clarifying the connection and turnaround logic of trains at stations, and providing a basis for train tracking and plan rolling in the ATS. 3) During the startup phase, the interface machine loads the CBTC system's route configuration table (including route ID, station sequence, turnaround station, running time, etc.) and establishes a hash table cache. When it receives a CTC train route description, it quickly maps it to the corresponding CBTC route identifier through hash lookup, ensuring the accuracy and efficiency of route information conversion; 4) The interface unit calculates the MD5 checksum of the received CTC plan data and compares it with the checksum attached to the data packet. If the verification fails, a receipt failure message is returned to the CTC, requesting a retransmission; only after the verification passes will the converted data be forwarded to CATS.

[0027] This invention features a plan synchronization and verification mechanism. After receiving the complete operation plan forwarded by the interface machine, the CATS performs an MD5 check again. If the verification fails, it reports a failure to receive the plan to all station servers to the interface machine, which then forwards the result to the CTC system. If the verification passes, it creates the daily plan within the ATS system and distributes it to all ATS station servers (LATS). To ensure the consistency of plan data between the center and the stations: 1) LATS periodically sends a plan data verification message to CATS, which carries the MD5 value of the current local plan data; 2) CATS compares the received MD5 value with its own cached value. If they are inconsistent, it will actively resynchronize the daily plan with the LATS. 3) When LATS starts up, restarts, or the host is upgraded, it immediately sends a complete plan synchronization request to CATS to ensure that the data on the end side is consistent with the data in the center. 4) If CATS detects an MD5 inconsistency during the synchronization process, it will report a failure to sign for the device, and the device will then notify the CTC system to handle the matter accordingly.

[0028] Through the above architecture design, this invention realizes automated and highly reliable conversion and synchronization between two heterogeneous operation diagram systems, CTC and CBTC-ATS, which significantly reduces the complexity and error rate of manual conversion, improves scheduling coordination efficiency and the consistency of train operation data, and provides key technical support for the integration of multiple signaling systems in rail transit, line upgrading and transformation and cross-line operation scheduling.

[0029] Example 2 like Figure 2 As shown, a method for a train timetable conversion system for multi-network convergence as described in Embodiment 1 is provided, the method comprising the following steps: Step S1: The CTC system sends the operation diagram data to the interface machine; Step S2: The interface device verifies the received CTC operation diagram data. If the verification is successful, proceed to step S3; otherwise, proceed to step S6. Step S3: The interface machine performs a structured transformation on the CTC operation diagram according to the preset transformation rules. If the transformation is successful, the transformed data is sent to the central server CATS and step S4 is executed; otherwise, step S6 is executed. Step S4: The central server CATS creates the ATS daily driving plan. If the creation is successful, proceed to step S5; otherwise, proceed to step S6. Step S5: The central server CATS synchronizes with the ATS station server LATS. If the synchronization is successful, the CTC system is notified that the receipt is successful; otherwise, proceed to step S6. In step S6, the interface device notifies the CTC system that the receipt has failed.

[0030] The following is a supplementary explanation of the conversion algorithm: 1) Planned data format conversion and global integration First, the system receives planning information from the CTC (Centralized Train Control System) and converts it into structured data conforming to the ATS (Automatic Train Monitoring System) rules. During the conversion process, according to the ATS planning rules, the data type of each planning node issued by the CTC is mapped and formatted to ensure semantic consistency and compliance with ATS processing specifications. After conversion, all train number information is integrated into a global key-value pair structure, AllTrainTrips, where the key is the train number identifier and the value is the complete set of planning attributes for the corresponding train number. This structure provides a complete train planning data source for subsequent processes.

[0031] 2) Identify the service origin and construct an initial set of train services. In the CTC plan, if a train's preceding train is empty, that train can be considered the starting point of a certain operating service. The algorithm iterates through AllTrainTrips, extracts all one-way plans with empty preceding trains, and organizes them into another key-value pair set, TrainFirstTrips, where the key is also the train number information. This set essentially represents the initial journeys of all independent services in the ATS, and is the foundation for subsequently constructing a complete service sequence.

[0032] 3) Construct a complete service chain based on prior associations Next, the system iterates through each initial train in TrainFirstTrips, using it as a starting point, and recursively searches for matching subsequent planned nodes in AllTrainTrips. Based on the sequential relationships between nodes, it assembles them into a complete operational service chain. This process ultimately generates a mapping structure ATSTrainInfo with the service number as the key. Each element corresponds to a complete operational service, containing information on all trains covered by that service, and integrating relevant attributes such as turnaround points, routes, and operating levels. Through this mechanism, the originally discrete CTC planned nodes are reconstructed into continuous service units that the ATS can identify and schedule.

[0033] int tripIndex = 0 for iterFirstTrip = TrainFirstTrips .begin #TrainFirstTrips do ATSTrainInfo[tripIndex++] = iterFirstTrip.Info int index = iterFirstTrip.index While (true) foundNext = false for iterAllTrip=AllTrainTrips.begin #AllTrainTrips do if iterAllTrip.preIndex == index then ATSTrainInfo[tripIndex++] = iterAllTrip.Info Index = iterAllTrip.index foundNext=true Break end end for if foundNext == false then break end end end for Through the above three-layer processing, the algorithm realizes the transformation from CTC discrete plan nodes to ATS coherent service plans, ensuring the connection and consistency of train operation information across different systems, and providing a reliable data foundation for automated train scheduling and monitoring. This design balances the accuracy of data transformation with the integrity of service organization, demonstrating the key role of modularity and structuring in operation planning.

[0034] Example 3 This invention also provides an electronic device including a central processing unit (CPU), which can perform various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) or loaded from a storage unit into a random access memory (RAM). The RAM may also store various programs and data required for device operation. The CPU, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0035] Multiple components in the device are connected to the I / O interface, including: input units such as keyboards and mice; output units such as various types of displays and speakers; storage units such as disks and optical discs; and communication units such as network interface cards (NICs), modems, and wireless transceivers. The communication unit allows the device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0036] The processing unit performs the various methods and processes described above, such as the methods of the present invention. For example, in some embodiments, the methods of the present invention may be implemented as computer software programs tangibly contained in a machine-readable medium, such as a storage unit. In some embodiments, part or all of the computer program may be loaded and / or installed on the device via ROM and / or a communication unit. When the computer program is loaded into RAM and executed by the CPU, one or more steps of the methods of the present invention described above may be performed. Alternatively, in other embodiments, the CPU may be configured to execute the methods of the present invention by any other suitable means (e.g., by means of firmware).

[0037] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0038] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0039] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0040] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A train timetable conversion system for multi-network integration, characterized in that, The conversion system includes an interface machine that connects to both the CTC system and the CBTC-based ATS system, and the interface machine is independent of the CTC system and the ATS system. After receiving the operation diagram data issued by the CTC system, the interface machine performs a structured transformation of the CTC operation diagram according to the preset transformation rules, and sends the transformed operation diagram to the central server CATS in the ATS system. The interface unit monitors the connection status with CTC and CATS in real time. Once the interface device re-establishes a connection with the CTC system, it actively sends a reconnection notification message to the CTC system at a configurable period. The CTC system provides a clear prompt on the dispatcher interface and sends a confirmation response. After receiving the response, the interface device stops sending messages periodically. When the connection between the interface machine and CATS is restored, the same two-way handshake and status synchronization process is performed. The specific steps of performing structured transformation of the CTC operation diagram according to preset transformation rules are as follows: First, the linear operation diagram of the CTC system centered on train number is decomposed into basic train operation information, then reorganized into a structured data model that meets ATS requirements and supports train turnaround and route loop, and finally the mapping relationship between service number and one-way number is automatically generated. When the CTC system sends information about each train to the interface machine, it includes the train number of the preceding train. The interface machine uses train information and the accompanying previous train number to build a train sequence linked list locally, clarifying the train connection and turnaround logic at the station; During the startup phase, the interface machine loads the CBTC route configuration table and establishes a hash table cache; when it receives the CTC train route description, it quickly maps it to the corresponding CBTC route identifier through hash lookup.

2. The train timetable conversion system for multi-network integration according to claim 1, characterized in that, The CBTC route configuration table includes route ID, station sequence, turnaround station, and running time.

3. The train timetable conversion system for multi-network integration according to claim 1, characterized in that, The interface device calculates the MD5 checksum of the received CTC operation diagram data and compares it with the checksum attached to the data packet. If the verification fails, a receipt failure message will be returned to the CTC system, requesting a resend; After the verification is successful, the converted data is forwarded to CATS.

4. The train timetable conversion system for multi-network integration according to claim 3, characterized in that, After receiving the complete runtime graph forwarded by the interface machine, CATS performs MD5 verification again.

5. The train timetable conversion system for multi-network integration according to claim 4, characterized in that, The process of performing the MD5 check again is as follows: The ATS station server LATS periodically sends a plan data verification message to CATS, which carries the MD5 value of the local current plan data. CATS compares the received MD5 value with its own cached value. If they do not match, it will proactively resynchronize the daily plan with the corresponding LATS. When LATS starts up, restarts, or the host is upgraded, it immediately sends a full plan synchronization request to CATS. If CATS detects an MD5 inconsistency during synchronization, it will report a failure to sign off to the interface machine and notify the CTC system through the interface machine for appropriate processing.

6. A method for using the train timetable conversion system for multi-network convergence as described in any one of claims 1-5, characterized in that, The method includes the following steps: Step S1: The CTC system sends the operation diagram data to the interface machine; Step S2: The interface device verifies the received CTC operation diagram data. If the verification is successful, proceed to step S3; otherwise, proceed to step S6. Step S3: The interface machine performs a structured transformation on the CTC operation diagram according to the preset transformation rules. If the transformation is successful, the transformed data is sent to the central server CATS and step S4 is executed; otherwise, step S6 is executed. Step S4: The central server CATS creates the ATS daily driving plan. If the creation is successful, proceed to step S5; otherwise, proceed to step S6. Step S5: The central server CATS synchronizes with the ATS station server LATS. If the synchronization is successful, the CTC system is notified that the receipt is successful; otherwise, proceed to step S6. In step S6, the interface device notifies the CTC system that the receipt has failed.

7. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the program, it implements the method as described in claim 6.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in claim 6.

Images