A human-machine interface system for rail transit drivers and its configuration method
By introducing a data receiving module, a context fusion engine, and a configurable configuration storage module into the rail transit driver human-machine interface system, multi-source information fusion and dynamic adaptive switching of the interface are achieved, solving the problems of information overload and hardware-software coupling in the existing system, and improving the system's safety and flexibility.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING MASS TRANSIT RAILWAY OPERATION CORPORATION LIMITED
- Filing Date
- 2026-03-30
- Publication Date
- 2026-06-02
AI Technical Summary
Existing human-machine interface systems for rail transit drivers struggle to achieve multi-source information fusion and dynamic adaptive switching under various operating conditions. Furthermore, the tight coupling between hardware and software results in high system maintenance costs and poor scalability, failing to meet the high safety and rapid iteration requirements under the context of four-network convergence.
The system uses a data receiving module to access multiple signal subsystems, parses and classifies data through a context fusion engine to generate the current running scene identifier, and combines a standardized configuration file of a configurable configuration storage module to achieve dynamic rendering of the interface engine. It also decouples from the underlying hardware through a hardware abstraction layer, supporting hot reload and fault degradation mechanisms.
It achieves intelligent fusion of multi-source information and dynamic adaptive switching of the interface, improving driver operation accuracy and driving safety, reducing development and maintenance costs, and meeting the high safety requirements of the rail transit field.
Smart Images
Figure CN122126326A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of rail transit train control technology, and in particular to a human-machine interface system for rail transit drivers and its configuration method. Background Technology
[0002] With the rapid development of rail transit systems towards intelligence, networking, and high reliability, "four-network integration" (i.e., the integration and interconnection of trunk railways, intercity railways, suburban railways, and urban rail transit) has become an important strategic direction for the construction of the national comprehensive three-dimensional transportation network. Against this backdrop, the train operation control system (ATC) and its human-machine interface (HMI) are facing unprecedented technical challenges and architectural bottlenecks.
[0003] First, the heterogeneity of signaling systems and the complexity of scenarios are increasing exponentially. Different lines, and even different sections of the same line (such as the junction of intercity and urban sections), may use completely heterogeneous signaling systems (such as CBTC, CTCS-2 / 3, point-to-point backup, vehicle-to-vehicle communication V2V, etc.), and the operating scenarios cover fully automated operation (GoA4), manned automated operation (GoA2), and even traditional manual driving mode (GoA0). Drivers need to operate in high-frequency switching contexts such as depot shunting, high-speed operation on the main line, turnaround station operations, temporary speed-limited sections, and system switching sections. The traditional customized development model of "one vehicle, one interface; one system, one HMI" leads to deep hard coupling between the interface logic and the underlying signaling system, forming a serious "siloed" architecture.
[0004] Secondly, existing HMI architectures lack the ability to fuse multi-source information and dynamically reconstruct data. Traditional HMIs can only passively display the raw messages from a single signal subsystem and cannot perform semantic-level fusion of heterogeneous data from multiple sources, including ATP (Train Protection), ATS (Train Monitoring System), TCMS (Train Control System), and electronic maps of the line. For example, in signal degradation or fault scenarios, the system cannot intelligently filter redundant information and highlight key alarms based on train location and fault level, leading to a dilemma for drivers facing information overload or missing key information, increasing the risk of misjudgment.
[0005] Furthermore, the tight coupling between hardware and software leads to high system maintenance costs and poor scalability. Existing HMI software often relies on specific hardware platforms (such as specific touchscreen models, GPUs, or operating systems), and the interface logic (View) and business data (Model) are not completely decoupled. When adapting to new vehicle models or upgrading hardware, it is often necessary to rewrite a large amount of low-level code, which not only results in long development cycles but also easily introduces unexpected compatibility bugs. In addition, the fragmentation of HMI versions across different networks is severe, lacking a unified full lifecycle configuration management and version verification mechanism, making it difficult to ensure absolute consistency between the design and vehicle-side behavior, and posing significant security risks.
[0006] In particular, there is an inherent contradiction between flexibility and safety in the field of functional safety. The rail transit industry has extremely high requirements for functional safety. Under the traditional development model, any minor change must undergo a rigorous testing process, resulting in system rigidity and an inability to quickly adjust display strategies or perform remote maintenance according to the needs of operators. Existing configuration attempts mostly remain at the static layout configuration level, lacking runtime context awareness and hot reload mechanisms, and have not established integrity verification (such as digital signatures) and fault degradation and fault tolerance mechanisms for configuration files, thus failing to meet the dual requirements of high security and rapid iteration in the context of four-network convergence.
[0007] A search revealed Chinese Patent Publication No. CN106681710A, which discloses an interface display method for the rail transit field. This method divides the interface into different control areas, generates an XML configuration file based on the interface control description, and the display software parses network data packets in real time and refreshes the display memory according to the configuration file, thereby achieving the integrated display of multi-interface data and interface configurability. However, this method only distributes and displays data based on interface type and preset logical conditions. When multiple data sources indicate different operating scenarios, it is difficult to adaptively adjust the interface display strategy. Under conditions of heterogeneous signal systems and complex and ever-changing operating scenarios, there is still a risk of information overload or loss of key information. At the same time, the configuration file of this method is bound to the data structure of a specific interface. When the hardware platform changes or needs to be adapted to different input devices, the underlying program still needs to be modified, making it difficult to achieve cross-platform reuse of interface logic.
[0008] Therefore, how to enable the driver's human-machine interface to achieve multi-source information fusion, dynamic adaptive switching according to the scenario, and decoupling from the underlying hardware under the multi-scenario operation conditions of rail transit is a technical problem that needs to be solved. Summary of the Invention
[0009] The purpose of this invention is to overcome the defects of the prior art and provide a human-machine interface system for rail transit drivers and its configuration method.
[0010] 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 drivers is provided, comprising: The data receiving module connects to multiple signal subsystems through a standardized communication protocol to receive heterogeneous data from multiple sources. A context fusion engine, connected to the data receiving module, is used to parse and classify the multi-source heterogeneous data, and generate a current operating scenario identifier based on the priority and confidence of each signal subsystem. A configuration storage module is used to store configuration configuration files. The configuration configuration files describe the interface layout, data mapping relationships and interaction logic in a standardized format, and include display and switching logic rules for different operating scenarios. The interface engine is connected to the context fusion engine and the configuration storage module, respectively. It is used to obtain the current running scene identifier, load the configuration file from the configuration storage module according to the current running scene identifier, parse and apply the part of the display and switching logic rules corresponding to the current running scene identifier, and render and generate the driver human-machine interface.
[0011] As a preferred technical solution, the step of generating the current operating scenario identifier based on the priority and confidence level of each signal subsystem specifically includes: When data from different signal subsystems indicate different operating scenarios, the context fusion engine selects the scenario indicated by the signal subsystem with the highest priority as the current operating scenario identifier. When priorities are the same, the scenario indicated by the signal subsystem with the highest confidence level is selected as the current running scenario identifier.
[0012] As a preferred technical solution, the confidence level is determined in real time by the signal subsystem based on its own data quality, communication status and fault status, and is transmitted to the data receiving module along with the original data sent by the signal subsystem.
[0013] As a preferred technical solution, the way the interface layout and data mapping relationship are described in the configuration configuration file is as follows: the interface elements are abstracted into component units, and the component units are bound to one or more data source fields as needed. The data source fields have unique identifiers and correspond to parameter items in the signal subsystem data packets.
[0014] As a preferred technical solution, the component unit includes at least one of a speedometer component, a warning icon component, a text information component, an operation button component, a target distance component, and a parking position component, and each component unit has configurable style attributes and behavior attributes.
[0015] As a preferred technical solution, the configuration file includes display and switching logic rules for different operating scenarios, specifically including: A set of rules described using a scripting language, where each rule contains a conditional expression and an action to be performed; The conditional expression is used to determine whether the current running scenario identifier matches a preset value; The actions performed include switching the interface layout, modifying the visibility of controls, changing the color scheme, and adjusting the alarm level.
[0016] As a preferred technical solution, the configuration file is generated by a visual configuration design tool. The visual configuration design tool supports generating the configuration file by dragging and dropping interface components, setting attributes, binding data sources, and writing the script language, and converts the script language into a subset of the WebAssembly instruction set.
[0017] As a preferred technical solution, the interface engine supports a hot reload mechanism, specifically including: When the current running scenario identifier changes, the interface engine reloads the configuration configuration file while keeping the process running. During the reloading process, the interface engine continuously displays core security information.
[0018] As a preferred technical solution, the interface engine verifies the digital signature of the configuration configuration file before reloading it, and performs loading after the verification is successful.
[0019] As a preferred technical solution, the system further includes: The hardware abstraction layer interacts with the interface engine through the XML-RPC protocol carried by streaming inter-process communication, shielding hardware device differences; The interface engine accesses hardware resources through the hardware abstraction layer, thus decoupling from the underlying hardware platform.
[0020] As a preferred technical solution, the system further includes an interaction mapping layer for mapping the operations of different physical input devices into standard events that the interface engine can recognize; the different physical input devices include touch screens, physical buttons, and knobs.
[0021] As a preferred technical solution, the system further includes: The fault degradation module is used to control the interface engine to automatically switch to a restricted state interface display when the signal system partially fails. The restricted state interface only retains core safety information. The remote update module receives update data packets through a network port or maintenance interface and updates the software of the driver human-machine interface system. The software includes a configuration file and an executable program. The log diagnostic module is used to record interface switching events triggered by the interface engine, data anomaly events detected by the data receiving module or the context fusion engine, and user operation information, and store them in a hierarchical manner according to their levels.
[0022] According to a second aspect of the present invention, a configuration method based on the rail transit driver human-machine interface system is provided, comprising: It can access multiple signal subsystems through standardized communication protocols and receive heterogeneous data from multiple sources. The multi-source heterogeneous data is parsed and classified, and a current operating scenario identifier is generated based on the priority and confidence of each signal subsystem. Based on the generated current running scenario identifier, a configuration file is loaded. The configuration file uses a standardized format to describe the interface layout, data mapping relationship and interaction logic, and includes display and switching logic rules for different running scenarios. The configuration file is parsed, and the part of the display and switching logic rules corresponding to the current running scene identifier is applied to render and generate the driver human-machine interface.
[0023] Compared with the prior art, the present invention has the following advantages: 1. This invention uses a context fusion engine to parse and classify data from various signal subsystems. Through a fusion mechanism of priority and confidence, the system can identify reliable information from multi-source heterogeneous data as a basis for scene judgment. On this basis, the interface engine loads the corresponding configuration file from the configurable configuration storage module according to the generated scene identifier, so that the interface display matches the current running scene. This achieves multi-source information fusion and dynamic adaptive switching of the interface, improving the driver's operational accuracy and driving safety in complex operating scenarios.
[0024] 2. This invention uses a configurable configuration storage module to store standardized configuration files, separating the interface layout, data mapping relationships, and interaction logic from the program code. This decouples the interface from the business logic, eliminating the need for developers to write a large amount of customized code for different scenarios, thus shortening the development cycle and reducing development costs.
[0025] 3. This invention achieves hardware and software decoupling through a hardware abstraction layer and an interaction mapping layer. When adapting to new car models or upgrading hardware, only the hardware interface layer needs to be adjusted, without rewriting the business logic code. It supports deployment on multiple platforms such as embedded Linux, QNX, and Windows, improving the system's maintainability and cross-platform adaptability.
[0026] 4. This invention performs structural verification on the original configuration file using XSD Schema to ensure that the configuration format is correct and the content is complete. After the verification is passed, a visual configuration design tool generates a configurable configuration file containing an SHA256 digital signature. When deploying the vehicle-mounted equipment, the integrity and source of the configurable configuration file are ensured through signature verification, thus guaranteeing the security and reliability of the configuration data.
[0027] 5. This invention supports dual-machine hot standby and fault degradation strategies. When a part of the signal system fails, it automatically switches to the restricted state interface, retaining only core safety information such as current speed, target distance, and emergency braking status. This effectively improves the system's fault tolerance and operational safety, meeting the high safety requirements of the rail transit field. Attached Figure Description
[0028] Figure 1 This is a schematic diagram of the system structure of the present invention; Figure 2 This is a schematic diagram of a vehicle architecture for signal system fusion in an embodiment of the present invention; Figure 3 This is a schematic diagram of the configurable speedometer component of the system of the present invention, wherein, Figure 3 (a) is the visual interface for the speedometer component. Figure 3 (b) is a schematic diagram illustrating the binding of the speedometer component interface fields to the data source. Figure 3 (c) is a schematic diagram of the message parameter definition for the signal subsystem; Figure 4 This is a flowchart of the method of the present invention; Figure 5 The flowchart for generating configuration files for the method of this invention is provided. Detailed Implementation
[0029] 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.
[0030] Example 1: This invention provides a human-machine interface system for rail transit drivers, such as... Figure 1 As shown, the system includes: 1. Data receiving module: The data receiving module connects to multiple signaling subsystems via standardized communication protocols, receiving heterogeneous data from multiple sources. Specifically, each signaling subsystem (including the Train Protection Subsystem (ATP), Train Monitoring Subsystem (ATS), and Vehicle Control Subsystem (TCMS)) establishes a connection with the driver's human-machine interface system via industrial Ethernet using TRDP or RMS / GAPP protocols. The data receiving module continuously monitors the data transmission channels of each signaling subsystem. When data is received, it parses and classifies the data, extracting information relevant to the current train operation, including: Train Control Level (GoA), signaling system activation status (CBTC / TBTC for urban rail transit, CTCS-2 / 3 railway, V2V vehicle-to-vehicle communication, etc.), electronic map sections of the line (such as high-speed operating sections on the main line, turnaround station operation sections, depot shunting sections, etc.), and fault status. This information is stored in the system's internal data buffer for use by subsequent modules.
[0031] 2. Context fusion engine: The context fusion engine connects to the data receiving module to parse and classify multi-source heterogeneous data, and generates a current operating scenario identifier based on the priority and confidence level of each signal subsystem. Specifically, the priority of each signal subsystem is pre-configured in the HMI configuration file, with the priority order of each subsystem predefined according to different operating scenarios. For example, the CBTC system has the highest priority in urban rail sections, while the CTCS-2 system has the highest priority in national railway sections. This priority configuration is loaded along with the configuration file and remains unchanged during system operation. The confidence level is determined in real time by the signal subsystem based on its own data quality, communication status, and fault status, and is transmitted to the data receiving module along with its data packets. For example, when the communication quality between a signal subsystem and the train network deteriorates or the data packet loss rate increases, the subsystem automatically lowers its confidence level; when the subsystem detects a fault in its own sensors, the confidence level drops to the lowest level.
[0032] The context fusion engine generates the current running scene identifier according to the following rules: When data from different signal subsystems indicate different operating scenarios, the scenario indicated by the signal subsystem with the highest priority is selected as the current operating scenario identifier; When priorities are the same, the scenario indicated by the signal subsystem with the highest confidence level is selected as the current running scenario identifier.
[0033] 3. Configurable configuration storage module: The configuration storage module is configured to store configuration configuration files. These files are compressed and digitally signed binary configuration packages used to load and run on in-vehicle devices. They use a standardized format to describe the interface layout, data mapping relationships, and interaction logic, and contain display and switching logic rules for different operating scenarios.
[0034] The generation process of the configuration configuration file is as follows: First, a raw configuration file is generated using a visual configuration design tool. This file is in XML format and serves as an intermediate product during the design process. The raw configuration file must undergo XSD Schema validation to ensure it conforms to predefined structure and format requirements. After successful validation, the raw configuration file is compressed and packaged, with a version number management mechanism included. A digital signature is then generated using the SHA256 algorithm to ensure consistency and security from design to deployment.
[0035] In the configuration file, interface elements are abstracted as component units, including but not limited to common interface elements such as speedometers, alarm icons, text information, operation buttons, target distance components, and parking location components. Each component unit is bound to one or more data source fields as needed. These data source fields have unique identifiers and correspond to parameter items in the signal subsystem data packets. Static component units, such as static text components, do not need to be bound to a data source and exist only as interface layout elements. Figure 3 (a) Taking the speedometer component shown as an example, this component will refer to interface fields such as color, display mode, maximum speed, and current speed, and bind them to parameter items such as CC_POINTER_DISPLAY (CC008), CC_DIAL_DISPLAY (CC006), CC_MAX_DISPLAY (CC007), and CC_TRAIN_SPEED (CC009) in the signal subsystem message, respectively. Figure 3 (b). Further, the data source field corresponds to the parameter items in the signal subsystem data message, and the specific attributes of each parameter item (such as data range, scaling factor) are preset by the signal subsystem, such as... Figure 3 As shown in (c), each interface field is bound to its corresponding data source field via a unique identifier. When the value of the CC009 field changes, the current speed display of the speedometer component is automatically updated; when the value of the CC008 field changes, the pointer color changes accordingly.
[0036] The configuration file contains display and switching logic rules for different operating scenarios. Specifically, a set of rules is described using a Basic-like scripting language. Each rule includes a conditional expression and an execution action. The conditional expression determines whether the current operating scenario identifier matches a preset value, and the execution action includes at least one of the following: switching the interface layout, modifying control visibility, changing the color scheme, and adjusting the alarm level. Component-level logic rules can be embedded in component configurations to implement data transformation and conditional display. Figure 3 Taking the speedometer component shown in (a) as an example, the conditional assignment transformation rule is configured for the current speed field: when the original data x = -1, output y = -1 to indicate that the data is invalid; when x∈[0, 65535], the original data is mapped to a display value that can be rendered by the interface through y = 0.01x + 0.5.
[0037] The aforementioned configuration file was generated using a visual configuration design tool. This tool provides a low-code visual interface, allowing users to generate configuration files by dragging and dropping interface components, setting properties, binding data sources, and writing the scripting language. The design tool converts the user-written Basic-like scripting language into a subset of the WebAssembly instruction set to improve execution efficiency and cross-platform compatibility.
[0038] 4. Interface Engine: The interface engine is connected to the context fusion engine and the configuration storage module respectively. It is used to obtain the current running scene identifier, load the corresponding configuration configuration file from the configuration storage module based on the identifier, parse and apply the part of the display and switching logic rules that corresponds to the current running scene identifier, and render and generate the driver human-machine interface.
[0039] The UI engine supports a hot reload mechanism. When the current running scenario identifier generated by the context fusion engine changes (e.g., a train enters the CTCS-2 section from the CBTC section), the UI engine reloads the configuration file while keeping the process running. During the reload process, the UI engine maintains uninterrupted display of core safety information, such as the speedometer and braking status, which are continuously updated. Before reloading, the UI engine verifies the digital signature of the configuration file; loading only proceeds after successful verification, preventing the loading of tampered configuration files.
[0040] Through a hot reload mechanism, the UI engine can achieve real-time switching of UI layout, control visibility, color scheme, and alarm levels. For example, Figure 2 The typical signaling system fusion onboard architecture shown depicts a train equipped with two independent onboard signaling systems: CTCS-2 and CBTC. The onboard host establishes a connection with the HMI. When the train is within the urban rail signaling system control area, HMI A is displayed as inactive, while HMI B displays the CBTC driving interface. When the train is within the C2 system control area, HMI A displays the C2 driving interface, and HMI B is displayed as inactive. When the train is within a shared signaling system section, HMIs A and B display the fusion driving interface.
[0041] 5. Hardware Abstraction Layer: This system also includes a Hardware Abstraction Layer (HAL), which interacts with the UI engine via the XML-RPC protocol carried by streaming inter-process communication, shielding the differences between hardware devices. The UI engine accesses hardware resources (such as displays, touchscreens, buttons, indicator lights, etc.) through the HAL, achieving decoupling from the underlying hardware platform. Specifically, the HAL runs as a daemon process, providing a unified XML-RPC interface. The UI engine communicates with the HAL via Unix Sockets or PIPE, sending XML-RPC requests. When the hardware is changed (e.g., from model A touchscreen to model B touchscreen), only the underlying driver of the HAL needs to be modified; the UI engine requires no modification.
[0042] 6. Interaction Mapping Layer: The interaction mapping layer is responsible for mapping user input commands to standard events, thus standardizing the internal event handling process of the system. User input commands include touchscreen clicks, physical button presses, and knob rotations. Different hardware platforms have different user input methods; for example, HMI devices with touchscreens use touchscreen clicks for input, while HMI devices with physical buttons use button presses. The interaction mapping layer unifies the user input methods of different hardware platforms into standard events, including "confirmation events," "cancel events," "page up events," "page down events," "value increment events," and "value decrement events." For example, soft keyboard clicks on a touchscreen HMI device and numeric keypad presses on a physical button HMI device are both mapped to the same "value input event," achieving consistent interaction between the user and the HMI across different devices. The interaction mapping layer is also responsible for dynamically adjusting the control display size, automatically scaling the control size according to the display area to ensure the interface displays correctly on screens of different sizes.
[0043] 7. Fault Degradation Module: When a portion of the signal system fails, the fault degradation module automatically switches the control interface engine to a restricted state display. The restricted state interface retains only core safety information, including current speed, target distance, and emergency braking status. For example, when communication between the ATC subsystem and the HMI is interrupted, the fault degradation module triggers the interface engine to load a degradation configuration package. The interface then displays only the speedometer, emergency braking indicator, and "communication interruption" alarm, hiding non-safety-critical controls.
[0044] 8. Remote update module: The remote update module receives update data packets via a network port or maintenance interface and updates the configuration file. The update data packet contains the new program and interface configuration, and is verified using a file checksum to prevent unauthorized tampering.
[0045] 9. Log Diagnostic Module: The log diagnostic module is used to record various types of information during system operation and to perform differentiated processing and storage according to type.
[0046] Periodic logs contain routine status information during normal system operation, including continuously updated interface status from the interface engine and periodically reported data quality information from the data receiving module, which are continuously sent to the vehicle log recording unit for storage.
[0047] Event logs are records of abnormal or critical events triggered during system operation, including child process crashes, communication interruptions, and hardware failures. They are stored on the local storage card when an event is triggered. If the device's network communication is normal, these event logs are forwarded to the vehicle's logging unit in real time to facilitate problem analysis and function optimization.
[0048] This system adopts a platform abstraction design, supporting deployment in multiple operating environments: Real-world environment: Embedded platform: Embedded Linux + Qt or QNX + Photon, meeting real-time and functional safety requirements; Simulation / Debugging / Training Environment: WebUI or Windows + Qt desktop platform, used for non-safety-critical scenarios such as development debugging, driver training, and system demonstration.
[0049] All platforms share the same configuration and core business logic. Automated HIL testing ensures behavioral consistency, and conditional compilation and runtime adaptation layers shield platform differences.
[0050] To achieve hardware and software decoupling while meeting the functional safety requirements of rail transit, this system adopts a universal core board conforming to EN50128 SIL2 functional safety design requirements as its computing core. This core board is uniformly applied to devices with different mechanical sizes and external interfaces, standardizing the core computing platform and avoiding redundant development of core hardware for each vehicle model or interface requirement. Peripheral expansion interfaces (such as I / O boards) are designed as safety-independent components (QSLs) and are electrically isolated from the core board via optocouplers. Optocoupler isolation ensures that electrical faults in non-safety peripherals (such as short circuits and overvoltages) will not be conducted to the safety core, thus guaranteeing the stable operation of the core board under harsh conditions. Through this design, devices of different models or mechanical sizes only require replacement of the peripheral I / O boards, while the core board can be reused, reducing customized development costs and hardware maintenance costs, while simultaneously meeting the functional safety requirements of EN50128.
[0051] The system of this invention receives heterogeneous data from multiple signal subsystems through a data receiving module. It generates a current operating scenario identifier based on the priority and confidence of each signal subsystem through a context fusion engine. It stores configuration files describing the interface layout, data mapping relationships, and interaction logic through a configurable configuration storage module. Finally, it loads the corresponding configuration file based on the scenario identifier and renders the driver's human-machine interface through an interface engine. This system achieves dynamic reconstruction of the interface that is adaptive to multiple scenarios, intelligent fusion of multi-source information, and decoupling of software and hardware, thereby improving the safety and flexibility of human-machine interaction.
[0052] Example 2: This invention provides a configuration method based on the driver human-machine interface system, such as... Figure 4 As shown, the method includes: Step S1: Receive heterogeneous data from multiple sources.
[0053] The system connects to multiple signal subsystems via standardized communication protocols, receiving heterogeneous data from multiple sources. Specifically, the driver's human-machine interface (HMI) system establishes connections with signal subsystems such as ATP, ATS, and TCMS via industrial Ethernet using TRDP or RMS / GAPP protocols. These signal subsystems include, but are not limited to, the Train Protection Subsystem (ATP), the Train Monitoring Subsystem (ATS), the Vehicle Control Subsystem (TCMS), and the track electronic map system. The HMI system continuously monitors the data transmission channels of each subsystem, receiving real-time data packets. Upon receiving a data packet, the data receiving module first performs protocol parsing and data verification, filtering out abnormal or incorrectly formatted data packets. Valid data is then categorized and processed to extract key information relevant to the current train operation, including: Train Control Level (GoA); signal system activation status (e.g., CBTC, CTCS-2 / 3, V2V vehicle-to-vehicle communication); track electronic map sections (e.g., high-speed mainline sections, turnaround station operation sections, depot shunting sections); and fault status (e.g., subsystem communication interruption, sensor failure, data anomalies). This information is stored in the system's internal data buffer, along with a timestamp and source identifier, for use by subsequent modules.
[0054] Step S2: Generate the current running scenario identifier.
[0055] The received multi-source heterogeneous data is parsed and classified, and a current operating scenario identifier is generated based on the priority and confidence level of each signal subsystem. Each signal subsystem carries priority and confidence level information when sending data. The confidence level is determined in real time by the signal subsystem based on its own data quality, communication status, and fault status. The confidence level is transmitted as metadata to the data receiving module along with the data packet. For example, when the communication quality between a signal subsystem and the train network deteriorates or the data packet loss rate exceeds a threshold, the subsystem automatically lowers its confidence level; when the subsystem detects a fault in its own sensors, the confidence level drops to the lowest value. The current operating scenario identifier is generated according to the following rules: when data from different signal subsystems indicates different operating scenarios, the scenario indicated by the signal subsystem with the highest priority is selected as the current operating scenario identifier; when priorities are the same, the scenario indicated by the signal subsystem with the highest confidence level is selected as the current operating scenario identifier.
[0056] Step S3: Load the configuration configuration file.
[0057] Based on the generated current running scenario identifier, a configuration file is loaded from the storage unit. This configuration file uses a standardized format to describe the interface layout, data mapping relationships, and interaction logic, and includes display and switching logic rules for different running scenarios.
[0058] The configuration file generation process is as follows: Figure 5 As shown: Choose a product configuration template that best matches your project as a base. Product configuration templates are predefined interface configuration files containing common interface layouts, elements, and data binding relationships, such as the "CBTC Driving Interface Template" and the "CTCS-2 Driving Interface Template." The configuration tool provides a template library management function, allowing users to select the template that best meets their project needs as the starting point. After selecting a template, the tool automatically loads the template configuration file, displaying the interface elements, data binding relationships, and logical rules from the template in the tool's editing interface. Users can modify and customize based on the template, avoiding starting from scratch and improving configuration efficiency.
[0059] The interface can be customized to meet the specific display requirements of the project. The configuration tool provides a visual interface editing function, allowing users to drag and drop interface components from the component library into the interface editing area to adjust their position and size, and set their properties and styles. The interface component library includes various types of components such as speedometers, alarm icons, text information boxes, operation buttons, progress bars, and charts. Each component has different configurable properties. For example, the speedometer component can be configured with properties such as dial units, scale range, and pointer color, while the text information box component can be configured with properties such as font size, font color, and text alignment. When a user selects a component, the configuration tool displays all the component's configurable properties in the property editing panel. Users can set property values through interactive methods such as drop-down menus, text input boxes, and color pickers. Modifications to property values are reflected in the interface editing area in real time, allowing users to intuitively see the interface adjustment effects.
[0060] Configure display and switching logic rules to determine the content and style displayed under different conditions. Logic rules define the dynamic display behavior of interface elements, such as showing or hiding an element or changing its color when the value of a data item meets a specific condition. The configuration tool provides a data relationship editing module, allowing users to graphically establish binding relationships between interface elements and data sources, select data source fields, and set data mapping rules. Data mapping rules support multiple methods, including direct mapping, proportional scaling mapping, and conditional mapping. Direct mapping means the displayed value of an interface element is directly equal to the value of the data source field; proportional scaling mapping means the displayed value of an interface element is equal to the value of the data source field multiplied by a scaling factor plus an intercept; and conditional mapping selects different display values or styles based on the range of values in the data source field. Logic rules are written in a Basic-like scripting language that supports basic syntax structures such as variable definition, conditional judgment, loop control, arithmetic operations, and logical operations. The configuration tool provides a script editor with features such as syntax highlighting, auto-completion, and syntax error prompts to help users quickly write correct logic rules. User-written logic rules are automatically converted into a subset of the WebAssembly instruction set by the configuration tool. The converted WebAssembly instructions are embedded in the configuration file and executed by the WebAssembly virtual machine when the HMI system is running.
[0061] Perform simulation debugging to check if the configuration achieves the expected results. The configuration tool has a built-in simulation debugging function, allowing users to simulate the HMI system's operating environment, input simulated data, observe the display behavior of interface elements, and verify the correctness of logical rules. The simulation debugging function supports debugging methods such as single-step execution, breakpoint debugging, and variable monitoring. Users can step-by-step trace the execution process of logical rules, view the variable values and interface states at each step, and quickly locate logical errors. Simulation debugging also supports scene playback functionality. Users can record a sequence of simulated data, save it as a scene file, and repeatedly play the scene in subsequent debugging to verify the interface's performance under specific scenarios, ensuring smooth interface transitions and accurate data display.
[0062] If the desired result is not achieved, return to the interface customization steps to modify the logic rules and perform iterative optimization. The configuration tool supports version management during the configuration process, automatically saving historical versions of the configuration file after each modification, allowing users to revert to previous versions at any time. The generated configuration file itself includes a version number for runtime compatibility checks.
[0063] After the simulation and debugging meet the expectations, the configuration file is checked using XSD Schema to ensure that it meets the predetermined structure and format requirements.
[0064] After verification, the final configuration package is generated using a configuration tool and digitally signed (using the SHA256 algorithm) to ensure its integrity and trustworthy origin.
[0065] Step S4: Render and generate the driver's human-machine interface.
[0066] The configuration configuration file is parsed, and the portion of the display and switching logic rules corresponding to the current operating scenario identifier is applied to render and generate the driver's human-machine interface. The interface engine first loads the configuration configuration file obtained in step S3 and parses the XML format configuration file. During parsing, the interface engine instantiates various component units according to the interface layout described in the configuration file; establishes bindings between components and data source fields according to data mapping relationships; and constructs a rule execution engine according to the display and switching logic rules. When the current operating scenario identifier changes (e.g., the train enters the CTCS-2 section from the CBTC section), the interface engine triggers a configuration hot reload mechanism: the interface engine reloads the configuration configuration file while maintaining process execution; during reloading, the interface engine maintains uninterrupted display of core safety information (e.g., speedometer, braking status, and other critical information are continuously updated without black screens or flickering); before reloading, the interface engine verifies the digital signature of the configuration file, and only executes loading after successful verification to prevent loading of tampered configuration files. Through the hot reload mechanism, the interface engine can achieve real-time switching of interface layout, control visibility, color scheme, and alarm levels.
[0067] The method of this invention adopts a scenario-driven configuration loading mechanism, supports hot reload and uninterrupted switching of core information, and achieves decoupling between the interface and the underlying system. Under the premise of meeting the functional safety requirements of rail transit, the system can flexibly adapt to different signal systems and operating scenarios, effectively reduce the cost of customized development, and improve the maintainability and scenario adaptability of the system.
[0068] 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 drivers, characterized in that, include: The data receiving module connects to multiple signal subsystems through a standardized communication protocol to receive heterogeneous data from multiple sources. A context fusion engine, connected to the data receiving module, is used to parse and classify the multi-source heterogeneous data, and generate a current operating scenario identifier based on the priority and confidence of each signal subsystem. A configuration storage module is used to store configuration configuration files. The configuration configuration files describe the interface layout, data mapping relationships and interaction logic in a standardized format, and include display and switching logic rules for different operating scenarios. The interface engine is connected to the context fusion engine and the configuration storage module, respectively. It is used to obtain the current running scene identifier, load the configuration file from the configuration storage module according to the current running scene identifier, parse and apply the part of the display and switching logic rules corresponding to the current running scene identifier, and render and generate the driver human-machine interface.
2. The human-machine interface system for rail transit drivers according to claim 1, characterized in that, The process of generating the current operating scenario identifier based on the priority and confidence level of each signal subsystem specifically includes: When data from different signal subsystems indicate different operating scenarios, the context fusion engine selects the scenario indicated by the signal subsystem with the highest priority as the current operating scenario identifier. When priorities are the same, the scenario indicated by the signal subsystem with the highest confidence level is selected as the current running scenario identifier.
3. The human-machine interface system for rail transit drivers according to claim 2, characterized in that, The confidence level is determined in real time by the signal subsystem based on its own data quality, communication status, and fault status, and is transmitted to the data receiving module along with the original data sent by the signal subsystem.
4. The human-machine interface system for rail transit drivers according to claim 1, characterized in that, The configuration file describes the interface layout and data mapping relationship in the following way: the interface elements are abstracted into component units, and the component units are bound to one or more data source fields as needed. The data source fields have unique identifiers and correspond to parameter items in the signal subsystem data packets.
5. A human-machine interface system for rail transit drivers according to claim 4, characterized in that, The component unit includes at least one of the following: speedometer component, warning icon component, text information component, operation button component, target distance component, and parking location component. Each component unit has configurable style attributes and behavior attributes.
6. A human-machine interface system for rail transit drivers according to claim 1, characterized in that, The configuration file contains display and switching logic rules for different operating scenarios, specifically including: A set of rules described using a scripting language, where each rule contains a conditional expression and an action to be performed; The conditional expression is used to determine whether the current running scenario identifier matches a preset value; The actions performed include switching the interface layout, modifying the visibility of controls, changing the color scheme, and adjusting the alarm level.
7. A human-machine interface system for rail transit drivers according to claim 6, characterized in that, The configuration file is generated by a visual configuration design tool. The visual configuration design tool supports generating the configuration file by dragging and dropping interface components, setting properties, binding data sources, and writing the script language, and converts the script language into a subset of the WebAssembly instruction set.
8. A human-machine interface system for rail transit drivers according to claim 1, characterized in that, The interface engine supports a hot reload mechanism, specifically including: When the current running scenario identifier changes, the interface engine reloads the configuration configuration file while keeping the process running. During the reloading process, the interface engine continuously displays core security information.
9. A human-machine interface system for rail transit drivers according to claim 8, characterized in that, Before reloading the configuration configuration file, the interface engine verifies the digital signature of the configuration configuration file. Once the verification is successful, the loading is executed.
10. A human-machine interface system for rail transit drivers according to claim 1, characterized in that, The system also includes: The hardware abstraction layer interacts with the interface engine through the XML-RPC protocol carried by streaming inter-process communication, shielding hardware device differences; The interface engine accesses hardware resources through the hardware abstraction layer, thus decoupling from the underlying hardware platform.
11. A human-machine interface system for rail transit drivers according to claim 1, characterized in that, The system also includes an interaction mapping layer for mapping the operations of different physical input devices into standard events that the interface engine can recognize; the different physical input devices include touch screens, physical buttons, and knobs.
12. A human-machine interface system for rail transit drivers according to claim 1, characterized in that, The system also includes: The fault degradation module is used to control the interface engine to automatically switch to a restricted state interface display when the signal system partially fails. The restricted state interface only retains core safety information. The remote update module receives update data packets through a network port or maintenance interface and updates the software of the driver human-machine interface system. The software includes a configuration file and an executable program. The log diagnostic module is used to record interface switching events triggered by the interface engine, data anomaly events detected by the data receiving module or the context fusion engine, and user operation information, and store them in a hierarchical manner according to their levels.
13. A configuration method for a rail transit driver human-machine interface system based on any one of claims 1-12, characterized in that, include: It can access multiple signal subsystems through standardized communication protocols and receive heterogeneous data from multiple sources. The multi-source heterogeneous data is parsed and classified, and a current operating scenario identifier is generated based on the priority and confidence of each signal subsystem. Based on the generated current running scenario identifier, a configuration file is loaded. The configuration file uses a standardized format to describe the interface layout, data mapping relationship and interaction logic, and includes display and switching logic rules for different running scenarios. The configuration file is parsed, and the part of the display and switching logic rules corresponding to the current running scene identifier is applied to render and generate the driver human-machine interface.