Rail transit cross-line operation dispatching communication system and method

Abstract

This invention provides a communication system and method for cross-line operation scheduling in rail transit, relating to the field of rail transit communication technology. It includes multiple scheduling servers, each associated with a corresponding line, and communication connections are established between the scheduling servers associated with the cross-line lines. Each scheduling server includes: a storage module for storing a train attribution table, which stores the mapping relationship between each train and its corresponding scheduling server; and a message scheduling module, used to, upon receiving a business message from a train currently operating on the associated line, designate the train's corresponding scheduling server as the target scheduling server according to the train attribution table, forward the business message to the target scheduling server, and receive the business processing result from the target scheduling server and forward it to the corresponding train. The beneficial effects include ensuring the business continuity of cross-line operations and significantly improving the compatibility and interconnection efficiency of scheduling systems from different manufacturers and lines.

Description

Technical Field

[0001] This invention relates to the field of rail transit communication technology, and in particular to a rail transit cross-line operation scheduling communication system and method. Background Technology

[0002] With the acceleration of urbanization and the dense development of rail transit networks, the interconnection of rail transit lines such as subways and intercity railways has become a key trend in meeting passenger travel needs and improving transportation efficiency. The scenario of trains operating across lines (i.e., trains traveling from one line to another related line) is becoming increasingly frequent. This requires that the dispatching systems of different lines achieve efficient and stable communication interconnection to ensure the continuous operation of core services such as cross-line train dispatching, emergency intercom, and manual announcements.

[0003] In existing rail transit networks, different lines are typically managed by independent dispatch servers, each provided by different vendors and employing its own independent management architecture. There is a lack of standardized real-time interconnection mechanisms between these servers. During cross-line operations, when a train enters a line outside its designated area, it becomes difficult to establish an effective communication link between the original dispatch server and the target line's dispatch server. This results in the inability to perform core services such as dispatch requests and emergency intercoms, leading to frequent cross-line communication interruptions. Furthermore, because each line's dispatch system independently maintains its own business data, there is a lack of a unified train attribution association mechanism. When a train crosses lines, the dispatch server of the currently operating line cannot quickly identify the train's original line and corresponding dispatch server. This results in a lack of clear targets for forwarding business messages. Either manual intervention is required to specify the forwarding path, which is inefficient and prone to errors; or messages are lost due to the inability to locate the target dispatch server, severely impacting the normal operation of cross-line services.

[0004] Therefore, there is an urgent need for a communication technology solution for cross-line operation scheduling in rail transit that can solve the above-mentioned defects in order to meet actual operational needs. Summary of the Invention

[0005] To address the problems existing in the prior art, this invention provides a rail transit cross-line operation scheduling and communication system, including multiple scheduling servers, each of which is associated with a corresponding line, and communication connections are established between the scheduling servers associated with the cross-line lines. Each scheduling server includes: a storage module for storing a train attribution table, which stores the mapping relationship between each train and its corresponding scheduling server; and a message scheduling module connected to the storage module, used for, upon receiving a service message sent by a train currently running on the associated line, recording the scheduling server to which the train belongs as the target scheduling server according to the train attribution table, forwarding the service message to the target scheduling server, and receiving the service processing result fed back by the target scheduling server and forwarding it to the corresponding train.

[0006] Preferably, the scheduling servers interact with each other via a lightweight communication protocol based on UDP+JSON, the communication protocol including a unified message header and an extensible message structure.

[0007] Preferably, the unified message header includes a message sequence number field, a message name field, and a message encoding method field, and the extensible message structure includes a business content field, wherein the business content field encapsulates custom business content in JSON format.

[0008] Preferably, the storage module further stores a global line topology table, where each node in the global line topology table corresponds to a respective scheduling server, and each node is associated with the online status of the corresponding scheduling server. Each scheduling server also includes an initialization module, used to send heartbeat messages to all scheduling servers that need to communicate when it starts up, and update the global line topology table based on the heartbeat feedback results. Before forwarding the service message, the message scheduling module first confirms that the target scheduling server is online through the global line topology table.

[0009] Preferably, it also includes a dispatch console, which establishes a wireless communication connection with each of the dispatch servers. Each train sends the service message to the dispatch server associated with the current operating line through its own onboard radio, and then forwards it to the dispatch console through the target dispatch server for service processing to obtain the service processing result.

[0010] Preferably, each of the aforementioned business messages contains a unique message ID that is sequentially incremented.

[0011] Preferably, each scheduling server further includes a message delivery confirmation module, comprising: a message receipt unit, used to provide a message receipt when successfully receiving the business message when acting as the receiver of the business message; and a message retransmission unit, used to automatically trigger retransmission of the business message and count the number of retransmissions when acting as the sender of the business message and if the message receipt is not received within a preset timeout period when acting as the sender of the business message, and stop retransmission and record an error log when the number of retransmissions exceeds a threshold.

[0012] Preferably, the message delivery confirmation module further includes a status tracking unit, which, when acting as the sender of the business message, marks the message status as sent after sending the business message, marks the message status as confirmed when receiving the message receipt, marks the message status as retransmission in progress when a retransmission is triggered, and marks the message status as sending failed when the number of retransmissions exceeds a threshold.

[0013] This invention also provides a communication method for cross-line operation scheduling in rail transit, applied to the aforementioned rail transit cross-line operation scheduling communication system. The method includes: step S1, whereby a train sends a service message to the scheduling server associated with the currently operating line; step S2, whereby, upon receiving the service message, the scheduling server of the currently operating line records the scheduling server to which the train belongs as the target scheduling server according to its stored train affiliation table containing the mapping relationship between each train and its affiliated scheduling server; and step S3, whereby the scheduling server of the currently operating line forwards the service message to the target scheduling server, and receives the service processing result fed back by the target scheduling server and forwards it to the corresponding train.

[0014] Preferably, the scheduling servers interact with each other via a lightweight communication protocol based on UDP+JSON, the communication protocol including a unified message header and an extensible message structure.

[0015] The above technical solution has the following advantages or beneficial effects: 1) By establishing communication connections between dispatch servers associated with cross-line lines, a standardized cross-line communication link is constructed, replacing the independent closed-loop architecture in the existing technology that lacks a real-time interconnection mechanism. When a train is running across lines, the current line dispatch server can accurately locate the target dispatch server through the train affiliation table, realize the targeted forwarding of business messages, and ensure that core business messages such as requesting dispatch, emergency intercom, and manual broadcast can be smoothly transmitted from the cross-line train to the dispatch system of its own line. At the same time, the business processing results are reliably fed back to the train, completely solving the problem of cross-line communication interruption and ensuring the business continuity of cross-line operation. 2) This invention avoids the interoperability problems caused by differences in manufacturers and protocols in the prior art by using a unified message forwarding logic and train affiliation table mapping mechanism. Regardless of the interface protocol or encoding format used by each line dispatching server, as long as they are interconnected through the communication connection of this system, the cross-line transmission of business messages can be completed with the help of the message dispatching module. There is no need to modify the core architecture of the original dispatching system, which significantly improves the compatibility and interconnection efficiency of dispatching systems from different manufacturers and on different lines. 3) A unified train ownership mapping relationship is established through the train ownership table in the storage module, providing a clear and fixed basis for message forwarding. Compared with the existing technology that relies on manual intervention to specify the forwarding path or static IP mapping, the message scheduling module of this invention can automatically complete the train ownership identification and target scheduling server location without manual intervention. This not only greatly improves the message forwarding efficiency, but also avoids forwarding errors caused by manual operation or static configuration. At the same time, each scheduling server does not need to independently maintain complete cross-line communication logic, but only needs to execute the standardized process of receiving, querying, and forwarding, reducing the resource waste caused by repetitive business logic and simplifying the system architecture. 4) The architecture of this invention has good scalability. When a new line is added to the rail transit network or the cross-line relationship is adjusted, it is only necessary to connect the dispatch server of the new line to the existing communication connection and update the mapping relationship in the train affiliation table at the same time. This can quickly realize the cross-line communication adaptation between the new line and the original line. Unlike the existing technology, there is no need to modify the core business logic or reconfigure a large number of parameters. This reduces the engineering implementation complexity caused by line expansion, greatly reduces the adaptation time and cost, and can flexibly respond to the dynamic expansion needs of the rail transit network. 5) This invention requires no modification or upgrade to the train-mounted radios involved in cross-line operations. The deployment of the cross-line communication system can be completed simply by establishing a communication connection between the dispatching servers and configuring the train affiliation table. Compared with the cumbersome operation of upgrading hundreds of train-mounted radios one by one when connecting across manufacturers in the prior art, this invention greatly reduces the workload and difficulty of engineering implementation and reduces the system stability risks that may be caused by equipment upgrades. At the same time, the standardized message forwarding logic and clear affiliation mapping relationship also simplify the troubleshooting and system optimization in the later maintenance, further reducing the maintenance cost throughout the entire life cycle. 6) A complete message transmission closed loop is constructed through the message scheduling module. Business messages are initiated from the train, forwarded to the target scheduling server for processing, and then fed back to the train through the original path. This ensures the integrity and traceability of message transmission, solves the problems of lost business messages and obstructed feedback of processing results in the existing technology, and improves the reliability and controllability of cross-line communication. Attached Figure Description

[0016] Figure 1A schematic diagram of the structure of a rail transit cross-line operation scheduling and communication system is shown in a preferred embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of the scheduling server in a preferred embodiment of the present invention; Figure 3 A flowchart illustrating a cross-line operation scheduling communication method for rail transit is provided in a preferred embodiment of the present invention. Figure 4 In a preferred embodiment of the present invention, a cross-line communication flowchart for the passenger emergency intercom service is provided. Detailed Implementation

[0017] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. The present invention is not limited to this embodiment; other embodiments that conform to the spirit of the present invention may also fall within the scope of the present invention.

[0018] In a preferred embodiment of the present invention, based on the above-mentioned problems existing in the prior art, a rail transit cross-line operation scheduling communication system is provided, such as... Figure 1 and Figure 2 As shown, the system includes multiple dispatch servers 1, each associated with a corresponding line, and communication connections are established between dispatch servers 1 associated across lines. Each dispatch server 1 includes: a storage module 11 for storing a train attribution table, which stores the mapping relationship between each train and its assigned dispatch server; and a message dispatch module 12 connected to the storage module 11, which, upon receiving a service message from a train currently running on the associated line, records the dispatch server to which the train belongs as the target dispatch server according to the train attribution table, forwards the service message to the target dispatch server, and receives the service processing result from the target dispatch server and forwards it to the corresponding train.

[0019] Specifically, the rail transit cross-line operation dispatching and communication system of the present invention includes a dispatching console 2, at least two dispatching servers 1, and cross-line trains. Each train communicates with the dispatching server 1 through its own onboard radio 3. The dispatching console 2 is a dispatching terminal located in the control center, where dispatchers can process various business messages sent by the dispatching server 1.

[0020] The scheduling server 1 is the data processing center of this invention, used to forward and process cross-line service messages. Only one main scheduling server is configured for each line to participate in cross-line communication, and a single cross-line service can be completed through only two corresponding scheduling servers 1.

[0021] More specifically, when a train is crossing lines, the current line's dispatch server 1 identifies its original line through the train affiliation table and automatically forwards the service message to the target dispatch server on the original line. The target dispatch server then connects to dispatch console 2. This entire process requires no re-registration with the LTE core network, achieving seamless communication. Furthermore, each dispatch server 1 only handles train services for its own line, avoiding conflicts and data leaks, and achieving service isolation.

[0022] In a preferred embodiment of the present invention, each scheduling server 1 interacts with each other through a lightweight communication protocol based on UDP+JSON. The communication protocol includes a unified message header and an extensible message structure.

[0023] Specifically, in this embodiment, UDP, as a transport layer protocol, can achieve millisecond-level command transmission latency, meeting the low-latency requirements of subway and intercity train dispatching, emergency calls, broadcast control, and other services. JSON format is used to encapsulate upper-layer business data, facilitating rapid parsing and adaptation by systems from different manufacturers and dispatch servers on different lines. By adopting a lightweight communication protocol based on UDP + JSON, both real-time performance and scalability can be balanced.

[0024] Furthermore, the protocol design fully considers the safety and compatibility of the railway industry, defining a unified message header (including fields such as message sequence number, message type, and message encoding) to achieve a unified communication format across systems and lines. Specifically, the unified message header includes a message sequence number field, a message name field, and a message encoding method field. The extensible message structure includes a business content field, which encapsulates custom business content in JSON format. The specific structure is shown in the table below:

[0025] In the table above, MsgSeqID is the message sequence number field, used for unique message identification and sequential tracking. It is preferably assigned in an ascending order to ensure message orderliness. MsgName is the message name, used to distinguish service types (such as CallRequest, Broadcast, Ack, etc.) to facilitate quick identification and processing by the receiving end. MsgEncoding is the message encoding method field (optional, defaults to UTF-8, used for compatibility with special character sets or compressed formats). MsgInfo is the service content field, whose format and content can be customized according to business needs. It supports nested structures and dynamic expansion, and fields can be customized according to different business needs to achieve the goal of adding new services without modifying the core protocol structure.

[0026] The system's design, featuring a unified message header and an extensible message structure, ensures excellent scalability and backward compatibility. Compared to binary proprietary protocols, JSON, being a plain text format, is easy to parse and debug, reducing the cost of interfacing with multiple vendor systems. Specifically, configuring a unified message header ensures that different business messages (such as emergency intercoms and dispatch instructions) have a consistent identification dimension, allowing the receiving end to quickly determine message type and track message order. The extensible message structure, nested within a JSON-formatted message body, leverages JSON's flexibility to enable custom extensions (e.g., the MsgInfo field for emergency intercom messages includes train ID and location, while the MsgInfo field for dispatch instructions includes instruction content and issuance time). This does not alter the UDP transmission method or the fixed rules of the unified message header; it only extends business content within the JSON format. Therefore, for new services, only the corresponding fields need to be defined in MsgInfo, without modifying the core protocol structure. It supports on-demand extension between different lines and vendor systems, achieving flexible adaptation of a "unified protocol framework + customized business" approach.

[0027] In a preferred embodiment of the present invention, the storage module 11 further stores a global line topology table, in which each node corresponds to a scheduling server 1, and each node is associated with the online status of the corresponding scheduling server 1; each scheduling server 1 further includes an initialization module 13, which is used to send a heartbeat message to all scheduling servers 1 that need to communicate when it starts up, and update the global line topology table according to the heartbeat feedback result; before forwarding the service message, the message scheduling module 12 first confirms that the target scheduling server is online through the global line topology table.

[0028] Specifically, in this embodiment, after each scheduling server 1 is launched, the initialization module 13 automatically sends heartbeat messages periodically to all peer scheduling servers that need to communicate. After receiving the messages, the peer servers return message receipts. If a peer server does not receive a receipt multiple times in a row, it is determined that the server is offline, and the global line topology table is updated to ensure that message forwarding only points to online servers, thereby improving system reliability.

[0029] Preferably, when a train needs to operate across three or more lines, this system expands in the following way: First, after the dispatch server for the newly added line comes online, it automatically sends a heartbeat message to all existing dispatch servers. The existing servers then update their line topology tables and establish interconnections. Then, when a train crosses multiple lines, the current line dispatch server identifies the original line through the train's affiliation table and directly forwards the message to the target server, without needing to go through intermediate line servers, ensuring transmission efficiency. Even more preferably, if the target server is offline, the system can select an alternative forwarding path (such as forwarding through an adjacent line server) through the global line topology table, improving system fault tolerance.

[0030] Understandably, when the scheduling server goes offline due to a fault, the global line topology table is updated to offline via heartbeat timeout, temporarily disconnecting its interconnection links. If the scheduling server comes back online after the fault is recovered, the heartbeat receipt will trigger the global line topology table to be updated to online, automatically restoring the interconnection relationship and realizing a self-recoverable interconnection topology. The update process does not require manual intervention, reducing manual maintenance costs.

[0031] Based on this, before sending cross-line messages, the scheduling server can quickly query the online status of the target scheduling server through the global line topology table, and only forward messages to online servers to avoid message loss and service timeouts caused by sending to offline nodes, thus reducing the waste of system resources. When a scheduling server temporarily goes offline and then recovers, the global line topology table can quickly update its status and restore interconnection. Cross-line services can be re-established without manual restart, ensuring that core services such as call scheduling and emergency intercom are not interrupted. Even if some line servers temporarily fail, the global line topology table can mark the status in a timely manner, and other scheduling servers can adjust their communication strategies accordingly (such as temporarily not forwarding to the failed node) to prevent the failure from spreading and ensure the stable operation of the overall cross-line communication network.

[0032] Preferably, the global line topology table also includes key information such as the IP address and communication port of each dispatching server. When a train initiates a service request across lines, the current line server can first confirm the target line through the train affiliation table, and then query the IP address, communication port, and other key information of the dispatching server corresponding to the target line through the global line topology table. This allows the system to automatically complete message routing based on the address information in the topology table without the need for manual configuration of forwarding paths, achieving automatic identification and accurate forwarding, and avoiding the cumbersome and erroneous nature of traditional static configuration.

[0033] More preferably, the global line topology table also records link quality (such as heartbeat response latency and packet loss rate). This allows the system to select an alternative forwarding path (such as relaying through an adjacent line server) based on the link information in the global line topology table if the link quality of a target scheduling server is poor (e.g., frequent packet loss). If the target scheduling server is offline, the system can quickly identify it through the global line topology table and trigger error log recording or backup plans (such as notifying the dispatcher for manual intervention), avoiding long-term service interruptions and ensuring the reliability and fault tolerance of communication links. Furthermore, maintenance personnel can also intuitively view the connection status and communication link conditions of all line scheduling servers through the global line topology table, quickly locating offline nodes and faulty links; eliminating the need to log in to each individual server for troubleshooting, reducing maintenance complexity and improving fault response speed.

[0034] In a preferred embodiment of the present invention, a dispatch console 2 is also included, which establishes a wireless communication connection with each dispatch server 1. Each train sends a service message to the dispatch server associated with the current operating line through its own onboard radio 3, and then forwards it to the dispatch console through the target dispatch server for service processing to obtain the service processing result.

[0035] In a preferred embodiment of the present invention, each service message contains a unique message ID that is sequentially incremented.

[0036] In a preferred embodiment of the present invention, each scheduling server 1 further includes a message delivery confirmation module 14, comprising: a message receipt unit 141, used to provide a message receipt when successfully receiving a business message when acting as a receiver of a business message; and a message retransmission unit 142, used to automatically trigger retransmission of the business message and count the number of retransmissions when acting as a sender of a business message and if no message receipt is received within a preset timeout period when acting as a sender of a business message, and to stop retransmission and record an error log when the number of retransmissions exceeds a threshold.

[0037] Specifically, in this embodiment, when the sending end's scheduling server sends a service message, it assigns a unique MsgSeqID to each service message. After the receiving end's scheduling server successfully receives and processes the service message, it returns an acknowledgment message (Ack) containing the corresponding MsgSeqID. The sending end's scheduling server has a preset timeout period. If no acknowledgment message is received within this preset timeout period, a retransmission is automatically triggered. After the cumulative number of retransmissions reaches a threshold, retransmission stops and an error log is recorded for maintenance personnel to review and handle, effectively ensuring the reliable transmission of service messages.

[0038] The preset timeout time and number of times thresholds can be set in batches or individually to reduce communication load and optimize bandwidth usage.

[0039] In a preferred embodiment of the present invention, the message delivery confirmation module 14 further includes a status tracking unit 143, which is used to mark the message status as sent after sending the service message when it is acting as the sender of the service message, mark the message status as confirmed when a message receipt is received, mark the message status as retransmission in progress when a retransmission is triggered, and mark the message status as sending failure when the number of retransmissions exceeds the number threshold.

[0040] This invention also provides a communication method for cross-line operation scheduling of rail transit, applied to the aforementioned cross-line operation scheduling communication system for rail transit, such as... Figure 3 As shown, the method includes: Step S1, the train sends a service message to the dispatch server associated with the current operating line; Step S2, when the dispatch server of the current operating line receives the service message, it records the dispatch server to which the train belongs as the target dispatch server according to its own stored train affiliation table containing the mapping relationship between each train and its affiliated dispatch server; Step S3, the dispatch server of the current operating line forwards the service message to the target dispatch server, and receives the service processing result fed back by the target dispatch server and forwards it to the corresponding train.

[0041] In a preferred embodiment of the present invention, the scheduling servers interact with each other through a lightweight communication protocol based on UDP+JSON. The communication protocol includes a unified message header and an extensible message structure.

[0042] like Figure 4 As shown, taking the passenger emergency intercom service as an example, the specific process of cross-line communication of the present invention is explained in detail: 1) The onboard unit of the cross-line train sends a message to the dispatch server of the current line ( Figure 3 The system sends an emergency intercom request to passengers via DIS1, encapsulating the request message according to the UDP+JSON protocol. Specifically, it is preferable to first construct a unified message header, where the MsgName field can be set to EmergencyTalkRequest, and then construct an extensible message structure, such as configuring the MsgInfo field to include information such as train identification and intercom initiation location. Subsequently, the unified message header and extensible message structure are integrated into a JSON string, converting the business rules into a general format, and then the JSON string is sent as the data payload via the UDP protocol to the dispatch server of the current line (DIS1). Figure 3 DIS1 in the middle.

[0043] 2) The dispatch server of the current line ( Figure 3 After receiving an emergency intercom request from a passenger, the DIS1 (in the system) queries the train affiliation table and identifies the dispatch server of the original line based on the train's identifier. Figure 3 DIS2 in the middle.

[0044] 3) The dispatch server of the current line ( Figure 3 DIS1 in the middle queries the global line topology table through the heartbeat detection module. After confirming that the target server is online, it forwards the emergency intercom request message to the target server. Figure 3 (DIS2 in the middle) retains complete information of the unified message header and MsgInfo field during forwarding.

[0045] 4) Target server ( Figure 3 After receiving an emergency intercom request message, DIS2 in the current line sends a message to the dispatch server (DIS2 in the current line). Figure 3 The DIS1 in the message returns a passenger emergency intercom reception confirmation message (MsgName is set to "Ack", and MsgInfo contains the corresponding MsgSeqID); if the dispatch server of the current line ( Figure 3 If DIS1 in the current line does not receive an acknowledgment message within the timeout period, a retransmission process will be executed; the scheduling server of the current line ( Figure 3 The DIS1 (optional) system will also send a confirmation message from the passenger emergency intercom to the train.

[0046] 5) Target server ( Figure 3 The DIS2 in the system forwards the emergency intercom request message to the dispatch console in the control center. Figure 3 In the DC), after the dispatcher responds to the request, it passes through the target server ( Figure 3 DIS2 in the middle sends a message to the scheduling server of the current line ( Figure 3 The DIS1 in the system sends a passenger emergency intercom start command, which is then sent by the dispatch server of the current line (DIS1). Figure 3 The DIS1 in the middle is forwarded to the train's onboard radio to establish a communication link.

[0047] 6) During the intercom, voice packets are transmitted in real time through the same forwarding path; after the intercom ends, the dispatch console sends a request to the passenger to end the intercom, which is then transmitted to the target server ( Figure 3 DIS2 in the current line, and the scheduling server of the current line. Figure 3 The DIS1 in the process is forwarded to the train's onboard unit. After confirmation, the train's onboard unit sends out a termination command, thus completing the entire business process.

[0048] As can be seen, the entire process does not require re-registration or control switching at the LTE core network layer. Seamless communication can be achieved through message encapsulation and forwarding, which greatly reduces the complexity of cross-line communication and the cost of subsequent operation and maintenance.

[0049] In summary, the present invention has the following technical advantages: 1. By using a unified scheduling interface and dynamic message forwarding mechanism, the problem of configuring a communication channel for each line separately in traditional systems is avoided, realizing automated, scalable and low-maintenance cross-line communication, making cross-line communication more efficient and easier to maintain; 2. The protocol adopts a standardized JSON format and a unified message header design, which can interoperate with systems from different manufacturers and with different protocol stacks, significantly improving system compatibility and openness. It is compatible with multiple manufacturers' systems and is easy to integrate. 3. Through message confirmation and retransmission mechanisms, the reliable delivery of critical scheduling services (such as call requests, passenger intercoms, and broadcasts) in cross-line scenarios is achieved. Even if the communication link is momentarily interrupted, it can be automatically retried and restored, effectively improving system reliability. 4. The custom mechanism for message fields provides a flexible and extensible architecture, allowing the system to extend new business types without modifying the underlying structure, which facilitates subsequent function upgrades or the introduction of new interfaces. 5. Adopting a "logically interconnected but business-independent" design, the dispatch server of each line only handles the train business of its own line, avoiding business conflicts and data leakage, and ensuring system isolation; 6. No need to re-register or switch control domains at the LTE core network layer (requiring interconnection between core networks of different lines). Cross-line communication can be completed simply through message encapsulation and forwarding, greatly reducing deployment and maintenance costs.

[0050] The above description is merely a preferred embodiment of the present invention and does not limit the implementation and protection scope of the present invention. Those skilled in the art should realize that any equivalent substitutions and obvious changes made using the content of this specification and illustrations should be included within the protection scope of the present invention.

Claims

1. A communication system for cross-line operation scheduling in rail transit, characterized in that, The system includes multiple dispatch servers, each associated with a corresponding line, and communication connections are established between dispatch servers associated across different lines. Each dispatch server includes: a storage module for storing a train attribution table, which stores the mapping relationship between each train and its associated dispatch server; and a message dispatch module connected to the storage module, used for, upon receiving a service message sent by a train currently running on the associated line, to designate the dispatch server to which the train belongs as the target dispatch server according to the train attribution table, and forward the service message to the target dispatch server, as well as to receive the service processing result fed back by the target dispatch server and forward it to the corresponding train.

2. The rail transit cross-line operation dispatching communication system according to claim 1, characterized in that, The scheduling servers interact with each other via a lightweight communication protocol based on UDP+JSON, which includes a unified message header and an extensible message structure.

3. The rail transit cross-line operation dispatching communication system according to claim 2, characterized in that, The unified message header includes a message sequence number field, a message name field, and a message encoding method field. The extensible message structure includes a business content field, which encapsulates custom business content in JSON format.

4. The rail transit cross-line operation dispatching communication system according to claim 1, characterized in that, The storage module also stores a global line topology table, where each node in the global line topology table corresponds to a specific scheduling server, and each node is associated with the online status of the corresponding scheduling server. Each scheduling server also includes an initialization module, which, upon startup, sends a heartbeat message to all scheduling servers that need to communicate, and updates the global line topology table based on the heartbeat feedback results. Before forwarding the service message, the message scheduling module first confirms that the target scheduling server is online through the global line topology table.

5. The rail transit cross-line operation dispatching communication system according to claim 1, characterized in that, It also includes a dispatch console, which establishes a wireless communication connection with each of the dispatch servers. Each train sends the service message to the dispatch server associated with the current operating line through its own onboard radio, and then forwards it to the dispatch console through the target dispatch server for service processing to obtain the service processing result.

6. The rail transit cross-line operation dispatching communication system according to claim 1, characterized in that, Each of the aforementioned business messages contains a unique message ID that is sequentially incremented.

7. The rail transit cross-line operation dispatching communication system according to claim 1, characterized in that, Each of the scheduling servers further includes a message delivery confirmation module, comprising: a message receipt unit, used to provide a message receipt when successfully receiving the business message when acting as the receiver of the business message; and a message retransmission unit, used to automatically trigger retransmission of the business message and count the number of retransmissions when acting as the sender of the business message and if the message receipt is not received within a preset timeout period when acting as the sender of the business message, and stop retransmission and record an error log when the number of retransmissions exceeds a threshold.

8. The rail transit cross-line operation dispatching communication system according to claim 7, characterized in that, The message delivery confirmation module also includes a status tracking unit, which, when acting as the sender of the business message, marks the message status as sent after sending the business message, marks the message status as confirmed when receiving the message receipt, marks the message status as retransmission in progress when a retransmission is triggered, and marks the message status as sending failed when the number of retransmissions exceeds a threshold.

9. A communication method for cross-line operation scheduling in rail transit, characterized in that, The method, applied to the rail transit cross-line operation dispatching communication system as described in any one of claims 1-8, comprises: step S1, a train sending a service message to the dispatching server associated with the currently operating line; step S2, when the dispatching server of the currently operating line receives the service message, it records the dispatching server to which the train belongs as the target dispatching server according to its stored train affiliation table containing the mapping relationship between each train and its affiliated dispatching server; step S3, the dispatching server of the currently operating line forwarding the service message to the target dispatching server, and receiving the service processing result fed back by the target dispatching server and forwarding it to the corresponding train.

10. The communication method for cross-line operation scheduling of rail transit according to claim 9, characterized in that, The scheduling servers interact with each other via a lightweight communication protocol based on UDP+JSON, which includes a unified message header and an extensible message structure.

Images