Rail transit ATS human-computer interface system based on dynamic modular architecture and method thereof

Abstract

The invention discloses a rail transit ATS human-computer interface system and method based on a dynamic modular architecture, and the system comprises a background service module which is used for processing the core business logic of a rail transit ATS system; the interface display service module is used for constructing and rendering a human-computer interaction interface; the communication middleware is connected with the background service module and the interface display service module to realize cross-process communication; wherein the background service module comprises a message processing module, and the message processing module processes different types of messages by adopting fixed compilation codes, dynamic libraries or scripts according to a predefined message processing strategy. Compared with the prior art, the method has the advantages that through a dynamic modular architecture and a configurable message processing division mechanism, the core stability of the rail transit ATS system is guaranteed, and meanwhile, the protocol change and interface customization are flexibly and efficiently adapted.

Description

Technical Field

[0001] This invention relates to the field of rail transit signal control technology, and in particular to a rail transit ATS human-machine interface system and method based on a dynamic modular architecture. Background Technology

[0002] In existing Automatic Train Control (ATS) systems for rail transit, the Station Map Human-Machine Interface (GPC) is a key subsystem for dispatchers to perform signal equipment control, train control, and track management. However, current technology has significant drawbacks: First, there is a prominent issue of architectural coupling, with the interface display logic tightly bound to the core business logic, making independent system upgrades and maintenance impossible. Second, protocol adaptability is poor, as message processing logic is hard-coded and fixed, making it difficult to flexibly adapt to protocol version changes in different urban rail transit projects. Third, customization flexibility is insufficient, as interface customization requirements must be implemented by modifying the core code, significantly reducing development efficiency. Fourth, cross-platform compatibility is lacking, as the traditional fixed architecture cannot meet the deployment requirements of different operating system platforms. From the perspective of current technology, current rail ATS systems generally adopt a fixed architecture design, with all message processing logic relying on hard-coding and lacking a dynamic expansion mechanism.

[0003] A search revealed Chinese Patent Publication No. CN104484735A, which discloses a comprehensive maintenance management information publishing system for rail transit. This system comprises a backend service module, a message broker server, and a frontend page display module. The backend service module integrates maintenance data from various subsystems and publishes it to the message broker server, which then pushes it in real-time to subscribed client browsers, thus achieving centralized management and real-time publishing of maintenance information. However, this system aims to address the real-time nature of maintenance information delivery and server load issues. Its backend service module focuses on data reception, storage, and forwarding, without addressing the differentiated and configurable processing mechanisms for core business messages of the rail transit ATS system.

[0004] Therefore, how to flexibly and efficiently adapt to diverse protocol changes and interface customization needs while ensuring the stability of the core functions of the rail transit ATS human-machine interface system is a technical problem that needs to be solved. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of the existing technology and provide a rail transit ATS human-machine interface system and method based on a dynamic modular architecture.

[0006] The objective of this invention can be achieved through the following technical solutions: According to a first aspect of the present invention, a human-machine interface system for rail transit ATS based on a dynamic modular architecture is provided, comprising: The back-end service module is used to handle the core business logic of the rail transit ATS system. The interface display service module is used to build and render human-computer interaction interfaces; A communication middleware connects the background service module and the interface display service module to enable cross-process communication; The background service module includes a message processing module, which processes different types of messages using fixed compiled code, dynamic libraries, or scripts according to a predefined message processing strategy.

[0007] As a preferred technical solution, the message processing module includes a configuration unit and a processor; The configuration unit is used to query configuration information based on the message identifier in order to determine the processor type corresponding to the message identifier; The processor types include fixed-code processors, dynamic library processors, and script processors; The message processing module calls the processor corresponding to the processor type to parse or assemble the message.

[0008] As a preferred technical solution, the system further includes: The data management module is used to receive and store the data parsed by the message processing module; The command management module is used to receive interface operation commands and convert the interface operation commands into a format that the data management module can recognize to obtain or operate data.

[0009] As a preferred technical solution, the system further includes an interface data converter; The interface data converter performs bidirectional data format conversion between the command management module and the interface display service.

[0010] As a preferred technical solution, the data management module includes a typed data warehouse; The typed data warehouse stores and retrieves equipment status, train position, and signal status data of the rail transit ATS system in a structured manner based on the combination of data type values ​​and parameters.

[0011] As a preferred technical solution, the background service module and the interface display service module are physically separate independent processes, and the communication middleware is a cross-platform lightweight remote procedure call middleware.

[0012] As a preferred technical solution, the background service module and the interface display service module communicate using an event-driven mechanism; After the data is updated, the background service module actively pushes an update notification corresponding to the event type to the interface display service module through the communication middleware.

[0013] As a preferred technical solution, the dynamic library and the script follow a unified interface standard; The system also includes a module loader, which is used to dynamically load specified dynamic libraries or scripts according to the configuration file when the system starts or runs.

[0014] As a preferred technical solution, the interface display service module includes: The interface builder selects whether to use direct rendering from dynamic libraries or script interpretation to construct interface elements based on the interface type. The event handler receives and responds to update events from the background service module to refresh the interface display.

[0015] As a preferred technical solution, the interface builder uses a dynamic library written in a compiled language to render performance-sensitive interface elements; and uses scripts to build interface elements that require flexible customization.

[0016] According to a second aspect of the present invention, a method for implementing a human-machine interface for rail transit ATS based on the said system is provided, characterized in that the method includes: Receive messages from the rail transit ATS system; Based on the predefined message processing strategy, determine the processing method for the current message: fixed compiled code, dynamic library, or script. The processor corresponding to the determined processing method is invoked to process the message.

[0017] As a preferred technical solution, the processing method specifically includes: Parse the message to obtain the message identifier; The corresponding processor type identifier is obtained by querying the preset mapping relationship based on the message identifier.

[0018] As a preferred technical solution, after invoking the processor to process the message, the method further includes: The processed data is stored in a typed data warehouse; Based on data changes, an interface update event is generated and proactively pushed to the interface display service.

[0019] As a preferred technical solution, the method further includes: Receive operation commands from the interface; Convert the interface data related to the operation commands into a common data format for the background service; Querying or manipulating the typed data warehouse based on the transformed data.

[0020] Compared with the prior art, the present invention has the following advantages: 1. This invention adopts a dynamic modular architecture consisting of a backend service module, an interface display service module, and a communication middleware. The backend service module is equipped with a message processing module with a dynamic division of labor mechanism. The stable and unchanging protocol logic is fixed in the code to ensure performance and reliability, while the changeable protocol logic is handled by dynamically replaceable libraries or scripts. Thus, it can flexibly adapt to different projects or different versions of communication protocols without reconstructing the core system.

[0021] 2. This invention introduces a decoupled typed data structure and an interface data converter to separate the core business data from the interface display data and perform bidirectional conversion. This decouples the interface logic from the business logic, allowing customized interface development to proceed without touching the backend core code. It enables rapid response to diverse interface customization needs, improving development efficiency and system maintainability.

[0022] 3. This invention adopts a physically separated process architecture and an event-driven proactive push communication mechanism, deploying the background service and the interface display service as independent processes and communicating through lightweight middleware. This enhances the modularity of the system and its cross-platform deployment capability. Furthermore, the proactive push updates from the background ensure the real-time response of the interface, while also facilitating independent optimization, upgrades, and fault isolation of each process.

[0023] 4. This invention adopts a multi-mode interface construction strategy. For performance-sensitive elements such as site maps, compiled dynamic libraries are used for direct rendering to ensure user experience. For elements such as dialog boxes that require rapid iteration, scripts are used for construction to support flexible customization. This differentiated implementation method ensures the performance of key interfaces while improving the development and iteration efficiency of interface modules. Attached Figure Description

[0024] Figure 1 This is a system architecture diagram of the present invention; Figure 2 This is a structural diagram of the backend service module of the present invention; Figure 3 This is a structural diagram of the interface display service module of the present invention; Detailed Implementation

[0025] 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.

[0026] Example 1: like Figure 1 As shown, the present invention provides a human-machine interface system for rail transit ATS based on a dynamic modular architecture. The system adopts a process-level architecture with front-end and back-end separation, including a background service process and an interface display service process. The two exchange data and notify events through a lightweight communication middleware.

[0027] Backend service module: The background service process is the core business logic executor of the system, responsible for protocol parsing, data management, command processing, and event generation. Its structure is as follows: Figure 2 As shown, it mainly includes the following modules: Network module: Responsible for communicating with the central server or other subsystems of the rail transit ATS system, receiving real-time messages from the ATS system, such as equipment status, train position, signal commands, etc., and sending the processed control commands back to the ATS system. This module supports standard rail transit communication protocols and has network anomaly detection and reconnection mechanisms.

[0028] Message processing module: This module is used to implement a dynamic division of labor mechanism for message processing. It contains a configuration unit and three types of processors. The configuration unit maintains a mapping table of message ID and processor type. This mapping table can be defined through an external configuration file and supports hot updates. The configuration unit loads this mapping table when the system starts. Fixed code processors are used to process core ATS messages with fixed protocol versions, stable structures, and extremely high processing performance requirements. These processing logics are directly integrated into the system in the form of compiled native code, resulting in high execution efficiency. The dynamic library processor is used to handle messages whose protocol versions may change and which have high performance requirements. The processing logic is compiled into an independent dynamic link library, and the system dynamically loads the corresponding library files according to the configuration. Script processor: Used to handle messages with frequent protocol version changes or complex business logic but low real-time requirements. The processing logic is written in script form, and the system has an embedded script engine that dynamically loads, interprets and executes the scripts. When the network module receives a message, the message processing module first parses out the message identifier; then, the configuration unit queries the mapping table based on the msgId to obtain the corresponding processor type (fixed, dynamic library, or script); finally, it calls the corresponding type of processor instance to complete the message unpacking (when receiving) or repacking (when sending).

[0029] Data Management Module: The data management module is responsible for the typed storage and management of the parsed ATS data, and it includes a typed data warehouse; Typed data warehouses are not simply key-value pair stores, but are designed according to the data characteristics of the rail transit ATS field. Each piece of data consists of a unique type identifier and a set of structured parameters. For example, a signal object has a type identifier of SIGNAL and parameters may include id, name, state (open or closed), associatedTrack, etc. This design supports efficient conditional retrieval and batch operations through the combination of (type identifier, parameter key), improves data access performance, and meets the data needs of various scenarios such as station map updating and route search. After receiving the data parsed by the message processing module, the data management module stores it in the typed data warehouse and then triggers an internal data update event.

[0030] Command Management Module: Responsible for processing user operation commands from the interface display service, such as clicking buttons, setting routes, and operating switches; The command management module integrates an interface data converter. When an interface command is received, the converter first converts it into the CData format commonly used within the backend service based on the command ID. Then, based on the converted data, the business logic is completed by querying or manipulating the data management module. Finally, the processing result is converted back into the CUIData format required by the interface layer and returned to the interface. This process achieves complete decoupling between interface logic and core business data.

[0031] Event Management Module: Used to monitor internal data update events of the Data Management Module. When data changes, such as when a train moves or a signal changes, this module creates a corresponding ATS system-specific event. Subsequently, it actively pushes the event and its related data to the interface display service process via a lightweight communication middleware through an event-driven cross-module communication mechanism, driving the real-time refresh of the interface. Interface display service module: The interface display service process focuses on the presentation and response of human-computer interaction, and its structure is as follows: Figure 3 As shown, it mainly includes the following modules: Communication Proxy Module: This module acts as the client of the background service process communication middleware. It is responsible for receiving update events pushed by the background and sending user operation commands to the background.

[0032] Interface Builder: Employing different building techniques based on varying interface types and performance requirements to achieve a balance between flexibility and performance, including: The dynamic library rendering mode is used for core interfaces that are extremely sensitive to performance and require fast refresh, such as site maps. It uses a high-performance dynamic library written in C++ for direct rendering. This method avoids the overhead of script interpretation and ensures that the scaling, dragging and element state updates of graphics remain smooth even in huge and complex site map scenarios. The script-based build mode is suitable for interfaces that require frequent customization and rapid iteration, such as various configuration dialogs, menus, and forms. By using scripts for building, developers do not need to recompile the main program; they only need to modify the script files to adjust the interface layout, controls, and behaviors, which greatly improves development efficiency.

[0033] Event handler: Receives background update events from the communication proxy module. Similar to background message processing, the event handling of the interface also follows a dynamic division of labor mechanism. It determines whether to use a fixed C++ event handling function, a handling function in a dynamic library, or call a Lua script to update the interface based on the event type. This ensures that the logic of the interface response can be flexibly configured and extended.

[0034] User interaction module: This module captures user actions on the interface, converts them into command requests with commandId and CUIData, and sends them to the command management module of the background service process through the communication proxy module.

[0035] Communication middleware and cross-platform design: This system uses a specially optimized lightweight Remote Procedure Call (RPC) communication middleware to connect the background service process and the interface display service process. This middleware has the following characteristics: Cross-platform: Based on standard Socket or higher-level abstraction implementation, it ensures that the backend service can be deployed on a Linux server, while the interface display service can be deployed on a Windows or Linux workstation; High efficiency: The serialization and deserialization of high-frequency, small-sized state update events in the ATS system have been optimized to reduce communication latency.

[0036] Reliable: Provides mechanisms such as heartbeat detection, reconnection after disconnection, and message confirmation to ensure the reliability of communication.

[0037] This process separation architecture allows the front-end and back-end to be developed, tested, deployed, and upgraded independently, improving the maintainability and scalability of the system.

[0038] The system of this invention separates the background service from the interface display service and adopts a configuration-driven dynamic division of labor mechanism, enabling the system to flexibly select fixed code, dynamic libraries or scripts to process various messages and commands. This decouples the core business from the interface display, and improves the system's maintainability, protocol adaptability and cross-platform deployment capabilities.

[0039] Example 2: This invention provides a method for implementing a human-machine interface for rail transit ATS based on a dynamic modular architecture, applied to the system described in Example 1. The method includes: Step S2: System Initialization Flow When the system starts, the background service process and the interface display service process each read their respective configuration files, which include: Mapping relationship between message ID and processor type; Path to dynamic library file; path to script file; Network connection parameters, communication middleware address, etc.; Based on the configuration, the system dynamically loads the specified dynamic link libraries (.dll / .so) and script files (.lua) into memory and completes the initialization; The background service process starts the network module to connect to the ATS central system, and at the same time establishes an RPC connection with the interface display service process through the communication middleware; Step S2: Message Reception and Processing The network module receives a raw network message from the ATS system; Perform basic legality checks on the message; Parse the message header to obtain the msgId, which uniquely identifies the message type; Query the configuration mapping table and determine the processor type to be used based on msgId; Call the processor to unpack: If it is a fixed type, call the built-in fixed unpacking function; If it is a dynamic library type, call the unpacking function in the corresponding loaded dynamic library; If it is a script type, the script engine is invoked to execute the corresponding unpacking script; Structured storage: The structured data (including type identifiers and parameters) obtained after unpacking is stored in a typed data warehouse; When data is updated, an internal event is triggered. The event management module creates a corresponding UI update event, encapsulating the event type and the latest data.

[0040] Step S3: Interface Update The background event management module actively pushes UI update events to the UI display service process through the communication middleware; The interface displays the events received by the service process's event handler; Depending on the type of event, decide whether to use a fixed C++ function, a dynamic library function, or a Lua script to handle it; Perform UI update: Invoke the selected processing logic and obtain the updated UI data; The interface builder refreshes the corresponding interface elements based on the updated data (such as changing the color of the signal in the station map, moving the position of the train icon, and updating the text in the dialog box). Step S4: User Interaction and Command Processing Users perform operations on the interface, such as clicking the "Create Route" button; The user interaction module generates a command request with commandId and interface data, and sends the command request to the command management module of the background service process through the communication middleware. The UI data converter in the command management module calls the convertFromUIData function based on the commandId to convert CUIData into the internally common CData format; Based on the converted CData, the data management module or other business modules are called to complete the actual ATS control logic; Obtain the execution result of the business logic and convert it back to CUIData format using the convertToUIData function; The results are returned to the interface, which then refreshes and displays or prompts the operation results based on the returned data.

[0041] Step S5: Protocol Adaptation When adapting to a new urban rail transit project or a new ATS protocol version, developers do not need to modify the core system code; they only need to: Analyze the new protocol: Determine which messages in the new protocol are fixed and which are new or changed; Write the processing module: For messages that are changing and have high performance requirements, write new dynamic link libraries; For messages that are changing or have complex logic, write new Lua scripts; Update the configuration file: In the configuration file, map the ID of the new message to the newly written dynamic library or script processor; Deployment: Deploy the new dynamic library or script file and configuration file to the system, then restart the service to load the new configuration.

[0042] The method of this invention dynamically selects the processing mode to parse and respond to ATS messages or user commands through a predefined configuration strategy, and actively pushes data updates to the interface using an event-driven mechanism. While ensuring processing performance, it supports rapid customization of interface elements and flexible adaptation of business logic.

[0043] 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 human-machine interface system for rail transit ATS based on a dynamic modular architecture, characterized in that, include: The back-end service module is used to handle the core business logic of the rail transit ATS system. The interface display service module is used to build and render human-computer interaction interfaces; A communication middleware connects the background service module and the interface display service module to enable cross-process communication; The background service module includes a message processing module, which processes different types of messages using fixed compiled code, dynamic libraries, or scripts according to a predefined message processing strategy.

2. The rail transit ATS human-machine interface system based on a dynamic modular architecture according to claim 1, characterized in that, The message processing module includes a configuration unit and a processor; The configuration unit is used to query configuration information based on the message identifier in order to determine the processor type corresponding to the message identifier; The processor types include fixed-code processors, dynamic library processors, and script processors; The message processing module calls the processor corresponding to the processor type to parse or assemble the message.

3. The rail transit ATS human-machine interface system based on a dynamic modular architecture according to claim 2, characterized in that, The system also includes: The data management module is used to receive and store the data parsed by the message processing module; The command management module is used to receive interface operation commands and convert the interface operation commands into a format that the data management module can recognize to obtain or operate data.

4. A human-machine interface system for rail transit ATS based on a dynamic modular architecture according to claim 3, characterized in that, The system also includes an interface data converter; The interface data converter performs bidirectional data format conversion between the command management module and the interface display service.

5. A human-machine interface system for rail transit ATS based on a dynamic modular architecture according to claim 3, characterized in that, The data management module includes a typed data warehouse; The typed data warehouse stores and retrieves equipment status, train position, and signal status data of the rail transit ATS system in a structured manner based on the combination of data type values ​​and parameters.

6. A human-machine interface system for rail transit ATS based on a dynamic modular architecture according to claim 1, characterized in that, The background service module and the interface display service module are physically separate independent processes, and the communication middleware is a cross-platform lightweight remote procedure call middleware.

7. A human-machine interface system for rail transit ATS based on a dynamic modular architecture according to claim 6, characterized in that, The background service module and the interface display service module communicate using an event-driven mechanism. After the data is updated, the background service module actively pushes an update notification corresponding to the event type to the interface display service module through the communication middleware.

8. A human-machine interface system for rail transit ATS based on a dynamic modular architecture according to claim 1, characterized in that, The dynamic library and the script follow a unified interface standard; The system also includes a module loader, which is used to dynamically load specified dynamic libraries or scripts according to the configuration file when the system starts or runs.

9. A human-machine interface system for rail transit ATS based on a dynamic modular architecture according to claim 1, characterized in that, The interface display service module includes: The interface builder selects whether to use direct rendering from dynamic libraries or script interpretation to construct interface elements based on the interface type. The event handler receives and responds to update events from the background service module to refresh the interface display.

10. A human-machine interface system for rail transit ATS based on a dynamic modular architecture according to claim 9, characterized in that, The interface builder uses dynamic libraries written in compiled languages ​​to render performance-sensitive interface elements; for interface elements that require flexible customization, it uses scripts for construction.

11. A method for implementing a human-machine interface for rail transit ATS based on any one of the systems described in claims 1-10, characterized in that, The method includes: Receive messages from the rail transit ATS system; Based on the predefined message processing strategy, determine the processing method for the current message: fixed compiled code, dynamic library, or script. The processor corresponding to the determined processing method is invoked to process the message.

12. The method for implementing a human-machine interface for rail transit ATS according to claim 11, characterized in that, Determining the processing method specifically includes: Parse the message to obtain the message identifier; The corresponding processor type identifier is obtained by querying the preset mapping relationship based on the message identifier.

13. The method for implementing a human-machine interface for rail transit ATS according to claim 11, characterized in that, After invoking the processor to process the message, the method further includes: The processed data is stored in a typed data warehouse; Based on data changes, an interface update event is generated and proactively pushed to the interface display service.

14. The method for implementing a human-machine interface for rail transit ATS according to claim 11, characterized in that, The method further includes: Receive operation commands from the interface; Convert the interface data related to the operation commands into a common data format for the background service; Querying or manipulating the typed data warehouse based on the transformed data.

Images