A multi-signal mode fusion DMI display method and system

Abstract

The present application relates to a kind of DMI display method and system of multi-signal system fusion, DMI device is connected with the vehicle host computer of multiple signal systems respectively, it is installed with the DMI software and middleware software corresponding to signal system on it.First, middleware software is started to listen to connection request;In turn, DMI software is started, after DMI software is started, it is actively connected middleware software, sends hardware control request to middleware software and sets up peripheral initial state;DMI software is periodically obtained from the vehicle host computer of corresponding signal system vehicle system control right state, if it has control right, it sends control right request to middleware software;Middleware software is based on control right request and judges control right attribution, when control right changes, it executes display switching operation.Compared with prior art, the present application realizes that multiple signal systems share DMI hardware, and multiple DMI software works independently, both ensure the flexibility of engineering application, and avoid the influence between cross system.

Description

Technical Field

[0001] This invention relates to the field of rail transit signaling system fusion technology, and in particular to a DMI display method and system for multi-signal system fusion. Background Technology

[0002] Under the development trend of the integration of the four rail transit networks, trunk railway networks, intercity railway networks, suburban railway networks, and urban rail transit networks need to achieve integrated development to build a multi-level, integrated rail transit system. However, the CTCS2+ATO system and CBTC system currently mainly used by suburban railways are two independent signaling systems.

[0003] The CTCS2+ATO system's onboard human-machine interface (DMI) unit is redundantly configured, with one onboard system equipped with two DMIs, one primary and one backup. It interacts with the Automatic Train Control (ATC) host via a programmable bus network (Profibus), multi-function vehicle bus (MVB), or industrial Ethernet. The DMI is equipped with buttons for user input.

[0004] One end of the CBTC system is equipped with a DMI (Distributed Management Interface), which interacts with the vehicle controller (CC) via Ethernet. The DMI features a touchscreen for user input. The two systems differ significantly in their DMI displays, communication messages, and hardware.

[0005] If the four-network integration is achieved in a completely independent manner, three signal system DMI devices need to be installed at one end of the train. However, the installation space for the human-machine interface on the driver's cab is limited, and generally only a maximum of five display devices can be configured. In addition to the signal equipment, two redundant vehicle displays and communication professional displays must also be placed, leaving only space for two signal system DMI devices.

[0006] Current technology uses a mechanical switch to switch the control signals of two on-board units, enabling the sharing of DMI equipment. This means that the DMI software needs to be redeveloped to support display interfaces and control signals of two different signal formats, and the DMI hardware needs to ensure rapid communication with the switch to restore the connection during switching. This significantly increases the complexity of the DMI's hardware and software system, resulting in high initial R&D costs. Furthermore, the switch requires driver operation, and improper operation may lead to discrepancies between the DMI display and the actual vehicle control system information. This places higher demands on drivers, requiring more training time and resources. Summary of the Invention

[0007] The purpose of this invention is to overcome the problems of high complexity of software and hardware systems in current multi-signal system fusion display technology solutions, and to provide a DMI display method and system for multi-signal system fusion.

[0008] The objective of this invention can be achieved through the following technical solutions:

[0009] As a first aspect of the present invention, a DMI display method for multi-signal system fusion is provided, wherein a DMI device is installed on the driver's cab at each end of the train, the DMI device is connected to the ATC host of different signal systems respectively, and each DMI device is equipped with DMI software and middleware software for different signal systems. The DMI display steps include:

[0010] When the DMI device is powered on, the middleware software is started first. After the middleware software starts, it first completes the initialization of the middleware software itself and the hardware peripherals. After the middleware software is ready, it starts listening for connection requests and starts the DMI software in sequence according to the configured startup order.

[0011] After the DMI software starts up and completes its own initialization, it actively connects to the middleware software through a socket. Once the connection is successful, the DMI software immediately sends a hardware control request to the middleware software to set the initial state of the peripherals.

[0012] During the operation of the DMI software, the control status of the vehicle system is periodically obtained from the vehicle host of the corresponding signal system. If the vehicle host has control, the DMI software sends a control request to the middleware software.

[0013] The middleware software determines the ownership of control based on the control request of the connected DMI software. When the ownership of control changes, the middleware software performs a display switching operation and then notifies the switched DMI software of the switch request.

[0014] As a preferred technical solution, the hardware control request is a request initiated by the DMI software to the middleware software to set the state of the hardware peripherals; when the middleware software executes the hardware control request, it updates the setting value of the hardware peripheral state to the program context.

[0015] The control request is a request initiated by the DMI software to the middleware software, and the content of the control request is either requesting control or relinquishing control.

[0016] The notification request is initiated by the middleware software to the DMI software, and the notification request content is to switch to the foreground display state or switch to the background hidden state.

[0017] As a preferred technical solution, the startup process of the DMI device is as follows:

[0018] After the DMI device's operating system has started, the middleware software is started first to complete the initialization of peripherals. Once the middleware software is ready and begins listening for connections, the DMI software is started in sequence.

[0019] The DMI software that starts first will be responsible for displaying the startup loading animation and will have initial control. After the DMI software starts, it will attempt to communicate with the corresponding vehicle host. If the corresponding vehicle signal system has control over the vehicle, it will request control from the middleware software.

[0020] As a preferred technical solution, the middleware software should receive and respond to the hardware control remote request from the DMI software. Regardless of whether the DMI software has control, the settings will be updated in the program context. Each DMI software connected to the middleware software has its own dedicated program context, which is used to store the hardware peripheral states expected by the DMI software.

[0021] The corresponding program context is set to the device context only when the DMI software has control. The device context is a structure that records the current state of the hardware peripheral.

[0022] When the device context changes, the middleware software sets the state of the hardware peripherals.

[0023] As a preferred technical solution, the mechanism by which the middleware software determines the ownership of control is as follows:

[0024] The first DMI software to connect has initial control, while other DMI software have no control.

[0025] Only one DMI software can hold control at any given time;

[0026] When a background DMI software requests control, a switchover occurs if no other software requests control.

[0027] When a foreground DMI software relinquishes control, a switchover occurs if other software requests control.

[0028] When the middleware software determines that the connection with the DMI software is interrupted through the socket, it is considered that the DMI software has relinquished control.

[0029] As a preferred technical solution, when a change of control occurs in the DMI software, the middleware software hides the window of the DMI software that has lost control, then reads the program context of the DMI software that has gained control, updates it to the device context, completes the setting of peripheral status through the device adaptation module, and finally displays the window of the DMI software that has gained control.

[0030] As a preferred technical solution, the application layer protocol between the DMI software and the middleware software adopts an improved XMLRPC remote procedure call protocol. The improved XMLRPC protocol does not distinguish between the server and the client. Both parties can initiate requests, and the other party responds to the requests. Each request message carries a unique identifier Request Id, and the response message contains the unique identifier RequestId corresponding to the request.

[0031] As a second aspect of the present invention, a multi-signal system fusion DMI display system is provided, characterized in that the system executes the multi-signal system fusion DMI display method as described above, the DMI display system comprising: DMI software and middleware software for multiple different vehicle signal systems installed on a DMI device; the middleware software is responsible for window management and hardware peripheral management functions; the DMI software is used to provide an interface display for the corresponding vehicle signal system; and the DMI software and the middleware software communicate across processes using an improved XMLRPC protocol.

[0032] As a preferred technical solution, two DMI devices are installed on the driver's cab at each end of the train. Each DMI device establishes a dual-channel redundant wired connection with the host of a different onboard signaling system. The communication methods include MVB, Profibus, and Ethernet.

[0033] As a preferred technical solution, the DMI software and middleware software adopt a cross-platform design, which can run on Windows or Unix operating system environments and in test simulations; the connection between the DMI software and middleware software adopts different transport layer protocols under different platforms, using named pipes under Windows operating system, Unix domain sockets under Unix operating system, and TCP sockets under the transport layer in the test simulation environment.

[0034] As a preferred technical solution, the middleware program includes:

[0035] Local server module: The middleware software establishes inter-process communication with the DMI program through the local server module based on the improved XMLRPC protocol;

[0036] Window management module: Controls the display and hiding of DMI program windows based on the corresponding operating system;

[0037] Device adaptation module: Abstracts hardware peripherals from different manufacturers into a unified interface for management.

[0038] As a preferred technical solution, the window management module controls the display and hiding of the DMI program window by sending display client messages to Unix operating systems; and controls the display and hiding of the DMI program window by calling the operating system API to Windows operating systems.

[0039] Compared with the prior art, the present invention has the following beneficial effects:

[0040] 1) The multi-signal system fusion DMI display method proposed in this invention uses a request-response model to update the control rights and desired hardware peripheral states of the vehicle signaling system between the DMI software and the middleware DMW software. Based on control ownership, the middleware DMW displays the corresponding DMI software window on the DMI device and sets the hardware peripheral states. This enables multiple signaling systems to share the DMI hardware device for displaying the vehicle signaling system interface and configuring the hardware peripheral states. It avoids the need for the DMI software to handle interface switching and hardware peripheral control. The DMI software of the fused signaling system itself only requires minor modifications for adaptation, with minimal changes to the engineering configuration. This ensures flexibility in engineering applications while reducing development costs and engineering complexity.

[0041] 2) In this invention, the middleware DMW software and the DMI software application layer adopt an improved XMLRPC protocol. This protocol ensures a one-to-one correspondence between responses and requests based on RequestId, allowing for timely retransmission of important requests if no response is received, and providing high security during concurrency. The protocol transmits human-readable text, is decoupled from the hardware platform, and is easy to debug, test, and migrate.

[0042] 3) This invention isolates the communication links between the C2 and CBTC signaling systems, allowing the DMI software for multiple signaling systems to operate independently. This increases the redundancy of the DMI hardware and software, avoids cross-system interference, and improves the overall availability of the fusion system. Attached Figure Description

[0043] Figure 1 This is a flowchart of a DMI display method for multi-signal system fusion according to the present invention.

[0044] Figure 2 This is a schematic diagram of the CTCS2+ATO and CBTC integrated vehicle architecture.

[0045] Figure 3 This is a schematic diagram of the DMI system architecture.

[0046] Figure 6 This is a schematic diagram of a typical startup process of a CTCS2+ATO and CBTC fused DMI system in an embodiment of the present invention.

[0047] Figure 4This is a schematic diagram of the processing logic for DMW hardware control requests.

[0048] Figure 5 This is a schematic diagram of the DMW display switching operation processing logic. Detailed Implementation

[0049] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0050] Example 1

[0051] This invention proposes a multi-signal standard fusion DMI display method to enable the sharing of DMI devices among different signal systems, such as... Figure 1 As shown, the method includes the following steps:

[0052] S1. Two DMI hardware devices are installed on the driver's cab at each end of the train (i.e., four per train), which are connected to the CTCS2+ATO system ATC host and the CBTC system CC host respectively.

[0053] S2. Install CTCS2+ATO DMI software, CBTC DMI software, and DMI middleware software (DMW) on each DMI device. The software is configured with the startup order at boot time through the startup script, and the DMW software starts first.

[0054] After the S3 and DMW software starts, it first completes the initialization of the software itself and hardware peripherals, and then begins to listen for connection requests.

[0055] After the S4 and DMI software start up and complete their own initialization, they actively connect to the DMW software via a socket. Once the connection is successful, they immediately send a hardware control request to the DMW software to set the initial state of the peripherals.

[0056] During the operation of S5 and DMI software, the control status of the vehicle system is periodically obtained from the corresponding vehicle host. If the vehicle host has control, DMI sends a control request to DMW. All peripheral control of DMI software is completed by sending requests to DMW.

[0057] S6. The DMW software determines the ownership of control based on the control request of the connected DMI software. When the ownership of control changes, the DMW software performs a display switching operation. After the switch, the DMW notifies the switched DMI software through a request.

[0058] In this embodiment, the DMI hardware device adopts a unified core board design, and can be optionally equipped with communication facilities adapted to various vehicle signaling systems while adhering to the system's hardware specifications. The vehicle signaling system supports communication methods including MVB, Profibus, and Ethernet, which can be flexibly selected according to specific engineering projects. Common DMI hardware configurations are 2x Profibus + 2x Ethernet, 2x MVB + 2x Ethernet, or 4x Ethernet.

[0059] The CTCS2+ATO DMI software, CBTC DMI software, and DMW software are designed to be cross-platform and can run on Windows or Unix operating systems (including Linux, QNX, etc.) for testing and simulation.

[0060] The connection between DMI and DMW software uses different transport layer protocols on different platforms, but all are full-duplex, connection-oriented, and streaming. For example, named pipes are used on Windows, Unix domain sockets (AF_UNIX or AF_LOCAL) are used on Unix operating systems, and TCP sockets are used in the transport layer in the test simulation environment.

[0061] The application layer protocol used between the DMI and DMW software is an improved XML Remote Procedure Call (XMLRPC) protocol. This protocol follows a request-response model, where the client actively initiates the connection, and the server passively listens for connections. However, unlike traditional XMLRPC, once a connection is established between the client and server, both parties can initiate requests, and the other end responds to those requests. Each request message carries a unique identifier (Request Id), and the response message must also contain the unique Request Id corresponding to the request.

[0062] Hardware control requests are a type of request initiated by the DMI software to the DMW. These include setting the volume, setting the display brightness, enabling or disabling the display's automatic brightness mode, setting the button backlight status, setting indicator light status, and reading temperature sensor values. When the DMW executes such requests, it updates the settings in the program context.

[0063] A control request is a request initiated by the DMI software to the DMW, in which the request content is either to request control or to relinquish control.

[0064] The control ownership mechanism is as follows: the first DMI software to connect has initial control, and other DMI software have no control. Only one DMI software can hold control at a time. When a background DMI software requests control, a switchover occurs if no other software requests control. When a foreground DMI software relinquishes control, a switchover occurs if other software requests control. When the middleware determines that the connection with a DMI software is interrupted through sockets, it is considered that the DMI software has relinquished control.

[0065] The display switching operation refers to the DMW software setting the window of the DMI software that has gained control to be displayed in the foreground and setting the corresponding program context of the DMI software to the actual DMI hardware device, while setting all windows of the DMI software that has lost control to be hidden in the background.

[0066] A notification request is a request initiated by the DMW software to the DMI software, requesting to switch to foreground display mode or background hidden mode.

[0067] Example 2

[0068] As another aspect of the present invention, this embodiment provides a DMI display system that implements the display method described in the above embodiment and fuses multiple signal formats.

[0069] like Figure 2 As shown, two DMI hardware devices are installed on the driver's cab at each end of the train. Each DMI establishes a dual-channel redundant wired communication connection with the ATC host of the CTCS2+ATO system and the CC host of the CBTC system. MVB, Profibus, and Ethernet can be used, and the appropriate method can be flexibly selected according to the specific project requirements.

[0070] like Figure 3 As shown, a typical DMI system includes three application programs: the DMI software for the CTCS2+ATO system, the DMI software for the CBTC system, and the DMW software. These applications communicate across processes (IPC) using a modified XMLRPC protocol, allowing them to send request and response messages to each other. The CTCS2+ATO DMI software provides the interface display for the CTCS2+ATO vehicle signaling system. The CBTC DMI software provides the interface display for the CBTC vehicle signaling system. The DMW software handles window management and hardware peripheral management functions. The DMW software contains three functional modules:

[0071] Local Server module: The Local Server module DMW can establish inter-process communication with the DMI program through the communication protocol, which is an improved XMLRPC.

[0072] Window Manager module: Controls the display and hiding of DMI program windows by sending display client messages (Unix operating system) or calling operating system APIs (Windows operating system).

[0073] Device Adapter module: Abstracts hardware peripherals from different manufacturers into a unified interface for management.

[0074] like Figure 4 As shown, this is a typical startup process for a CTCS2+ATO and CBTC integrated DMI system. After the operating system starts, the DMW software is started first to initialize the peripherals. Once the DMW is ready and begins listening for connections, the DMI software is started sequentially. The first DMI software to start will be responsible for displaying the startup loading animation and will have initial control. After the DMI software starts, it will attempt to communicate with the corresponding vehicle host. If the corresponding vehicle signal system has vehicle control rights, it will request control from the DMW.

[0075] like Figure 5 As shown, the DMW software will receive and respond to remote hardware control requests from the DMI software. Regardless of whether the DMI software has control, the settings will be updated in the application context. The application context is unique to each DMI software connected to the DMW and stores the hardware peripheral states desired by the DMI software. However, this application context is only set in the device context when the DMI software has control. The device context is a structure that records the current hardware peripheral state. When the device context changes, the DMW will set the hardware peripheral state through the Device Adapter module.

[0076] like Figure 6 As shown, when a change of control occurs in the DMI software, the DMW first hides the window of the DMI software that has lost control through the Window Manager module, then reads the context of the DMI software that has gained control, updates it in the device context, completes the setting of peripheral status through the Device Adapter module, and finally displays the window of the DMI software that has gained control.

[0077] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0078] The preferred embodiments of the present invention have been described in detail above. It should be understood that those skilled in the art can make numerous modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of existing technology should be within the scope of protection defined by the claims.

Claims

1. A DMI display method that integrates multiple signal formats, characterized in that, A DMI device is installed on the driver's cab at each end of the train. Each DMI device is connected to the onboard host of various different signaling systems. Each DMI device contains the corresponding DMI software and middleware software for each signaling system. The DMI display steps include: When the DMI device is powered on, the middleware software is started first. After the middleware software starts, it completes the initialization of itself and the hardware peripherals. Once the middleware software is ready, it starts listening for connection requests and starts the DMI software in sequence according to the configured startup order. After the DMI software starts up and completes its own initialization, it actively connects to the middleware software. Once the connection is successful, the DMI software sends a hardware control request to the middleware software to set the initial state of the peripherals. During operation, the DMI software periodically obtains the control status of the vehicle system from the vehicle host of the corresponding signal system. If the vehicle host has control, the DMI software sends a control request to the middleware software. The middleware software will receive and respond to remote hardware control requests from the DMI software. Regardless of whether the DMI software has control, the settings will be updated in the program context. Each DMI software connected to the middleware software has its own dedicated program context, which is used to store the hardware peripheral states expected by the DMI software. The corresponding program context will only be set in the device context when the DMI software has control. The device context is a structure for recording the current hardware peripheral states. When the device context changes, the middleware software will set the hardware peripheral states. The middleware software determines control ownership based on the control request from the connected DMI software. When the DMI software with control ownership changes, the middleware software performs a display switching operation. After the switch, the middleware software notifies the switched DMI software via a request. The mechanism by which the middleware software determines control ownership is as follows: The first DMI software to connect has initial control, while other DMI software have no control. Only one DMI software can hold control at any given time; When a background DMI software requests control, a switchover occurs if no other software requests control. When a foreground DMI software relinquishes control, a switchover occurs if other software requests control. When the middleware software determines that the connection with the DMI software is interrupted through the socket, it is considered that the DMI software has relinquished control.

2. The DMI display method for multi-signal system fusion according to claim 1, characterized in that, The hardware control request is a request initiated by the DMI software to the middleware software to set the state of the hardware peripherals; when the middleware software executes the hardware control request, it updates the set values ​​of the hardware peripheral states to the program context. The control request is a request initiated by the DMI software to the middleware software, and the content of the control request is either requesting control or relinquishing control. The notification request is initiated by the middleware software to the DMI software. The notification request content is to switch to the foreground display state or switch to the background hidden state.

3. The DMI display method for multi-signal system fusion according to claim 1, characterized in that, The startup process for the DMI device is as follows: After the DMI device's operating system has started, the middleware software is started first to complete the initialization of peripherals. Once the middleware software is ready and begins listening for connections, the DMI software is started in sequence. The DMI software that starts first will be responsible for displaying the startup loading animation and will have initial control. After the DMI software starts, it will attempt to communicate with the corresponding vehicle host. If the corresponding vehicle signal system has control over the vehicle, it will request control from the middleware software.

4. The DMI display method for multi-signal system fusion according to claim 1, characterized in that, When a change of control occurs in the DMI software, the middleware software hides the window of the DMI software that has lost control, then reads the program context of the DMI software that has gained control, updates it in the device context, completes the setting of peripheral status through the device adaptation module, and finally displays the window of the DMI software that has gained control.

5. The DMI display method for multi-signal system fusion according to claim 1, characterized in that, The application layer protocol between the DMI software and the middleware software adopts an improved XMLRPC remote procedure call protocol. The improved XMLRPC protocol is initiated by the client and passively listens for connections by the server. Once a connection is established between the client and the server, both parties can initiate requests, and the other party can respond to the requests. Each request message carries a unique identifier, Request Id, and the response message contains the unique identifier Request Id corresponding to the request.

6. A DMI display system that integrates multiple signal formats, characterized in that, The system executes the DMI display method for multi-signal system fusion as described in any one of claims 1-5. The DMI display system includes: DMI software and middleware software for various different vehicle signal systems installed on the DMI device; the middleware software is responsible for window management and hardware peripheral management functions; the DMI software is used to provide the interface display for the corresponding vehicle signal system; and the DMI software and the middleware software communicate across processes using an improved XMLRPC protocol.

7. A DMI display system with multi-signal fusion according to claim 6, characterized in that, Two DMI devices are installed on the driver's cab at each end of the train. Each DMI device establishes a dual-channel redundant wired connection with the host of a different onboard signaling system. The communication methods include MVB, Profibus and Ethernet.

8. A DMI display system with multi-signal fusion according to claim 6, characterized in that, The DMI software and middleware software are designed to be cross-platform, capable of running on Windows or Unix operating systems and in test and simulation environments. The connection between the DMI software and middleware software uses different transport layer protocols on different platforms: named pipes are used on Windows, Unix domain sockets are used on Unix, and TCP sockets are used in the transport layer in the test and simulation environment.

9. A DMI display system with multi-signal fusion according to claim 6, characterized in that, The middleware software includes: Local server module: The middleware software establishes inter-process communication with the DMI program through the local server module based on the improved XMLRPC protocol; Window management module: Controls the display and hiding of DMI program windows based on the corresponding operating system; Device adaptation module: Abstracts hardware peripherals from different manufacturers into a unified interface for management.

10. A DMI display system with multi-signal fusion according to claim 9, characterized in that, The window management module controls the display and hiding of DMI program windows for Unix operating systems by sending display client messages; for Windows operating systems, it controls the display and hiding of DMI program windows by calling operating system APIs.

Images