Integrated test system for city-region braking software of bullet train

Abstract

The application provides a motor train city area braking software integrated test system, and relates to the motor train city area braking software test technical field.The system comprises: a plurality of electronic brake control unit cabinets to be tested, a plurality of sub-simulation nodes, a main simulation node and a test service node; the sub-simulation nodes are electrically connected with the corresponding electronic brake control unit cabinets respectively, are used for simulating the external input signals of the electronic brake control unit cabinets and collecting the output signals of the electronic brake control unit cabinets; the main simulation node is used for controlling the signal interaction between the sub-simulation nodes and the electronic brake control unit cabinets by managing the train communication network and simulating the train bus control instructions; the test service node is used for uniformly configuring, parameter issuing and scheduling controlling the main simulation node and the sub-simulation nodes, and analyzing the output signals to generate a test report.The application realizes software configuration instead of physical replacement, significantly shortens the test preparation time, improves the test stability and prolongs the hardware life.

Description

Technical Field

[0001] This application relates to the field of testing technology for urban braking software for high-speed trains, and in particular to an integrated testing system for urban braking software for high-speed trains. Background Technology

[0002] Currently, the high-speed train software integration test platform is widely used for simulation and verification in the software testing of braking systems for both high-speed trains and urban rail trains. This test platform is mainly used for testing the braking system software of high-speed trains and urban rail trains, and is an important tool for train software integration and functional verification.

[0003] Under current technological conditions, when conducting software testing for different vehicle models or projects, due to the differences in the required testing environment, the type and quantity of the Electronic Brake Control Unit (EBCU) board under test, and the differences in the number of boards, testers need to manually replace the EBCU board under test and reconfigure the connection between the test fixture cables and the simulation load board before testing.

[0004] This traditional method of hardware replacement and cable reconfiguration has the following main problems: 1. Low efficiency in replacing circuit boards: Frequent switching between test environments across different projects necessitates unplugging and replugging the EBCU board under test and reconfiguring the cables each time. Each replacement takes approximately 30 to 60 minutes, severely impacting test progress and continuity.

[0005] 2. Increased hardware wear and tear: Frequent physical plugging and unplugging operations can easily lead to problems such as oxidation of the board's gold fingers and deformation of the slot pins, which significantly increases the hardware failure rate and also increases maintenance and replacement costs.

[0006] 3. Significant operational risks: During manual insertion and removal, random failures can easily occur due to electrostatic discharge, misaligned pins, poor contact, and other reasons. According to recent test statistics, approximately one-third of test interruptions are caused by contact or operational problems during hardware replacement.

[0007] The aforementioned problems not only lead to low testing efficiency, cumbersome manual operations, and decreased equipment reliability, but also adversely affect the stability and accuracy of test data. Frequent replacement of circuit boards and tooling cables also increases the difficulty of long-term maintenance of the simulation platform, and in severe cases, may require recalibration and rewiring of the entire testing system, further extending the debugging cycle.

[0008] Therefore, there is an urgent need for a new integrated testing solution that can avoid frequent physical replacement of boards, improve test switching efficiency, and reduce hardware wear and tear.

[0009] This section is intended to provide background or context for the embodiments of the invention set forth in the claims. The description herein is not an admission that it is prior art simply because it is included in this section. Summary of the Invention

[0010] To address the problems in the prior art, this application provides a high-speed train urban braking software integration testing system that can solve the problems of low efficiency, high hardware wear and tear, and high operational risks caused by frequent physical replacement of circuit boards during high-speed train / urban EBCU testing.

[0011] One aspect of the present invention provides a mobile train urban braking software integration test system, comprising: multiple electronic braking control unit chassis to be tested, multiple sub-simulation nodes, a main simulation node, and a test service node; The sub-simulation nodes are electrically connected to the corresponding electronic brake control unit chassis, and are used to simulate the external input signals of the electronic brake control unit chassis and acquire the output signals of the electronic brake control unit chassis. The main simulation node connects the multiple electronic brake control unit chassis and the multiple sub-simulation nodes, and is used to control the signal interaction between the sub-simulation nodes and the electronic brake control unit chassis by managing the train communication network and the simulated train bus control commands; The test service node connects the multiple sub-simulation nodes and the main simulation node, and is used to uniformly configure, distribute parameters and schedule the main simulation node and the sub-simulation nodes, analyze the output signals and generate test reports.

[0012] Furthermore, the electronic brake control unit chassis is provided with multiple board mounting slots, and each slot is used to install multiple electronic brake control unit boards and power management boards under test. The power management board is connected to the multiple electronic braking control unit boards and is used to independently control the power supply status of each electronic braking control unit board according to the power supply signal of the sub-simulation node.

[0013] Furthermore, the sub-simulation node includes multiple simulation load boards and power management simulation load boards; The simulation load board is electrically connected to the corresponding electronic brake control unit board via tooling cables, and is used to simulate the external input signals of the electronic brake control unit board and acquire the output signals of the electronic brake control unit board. The power management simulation load board is electrically connected to the power management board via a tooling cable, and is used to control the power management board to output power supply signals according to the configuration instructions issued by the test service node.

[0014] Furthermore, the external input signals include pressure sensor signals, speed sensor signals, train loop status signals, and isolation gate signals.

[0015] Furthermore, the sub-simulation node carries a load model, which is built by the Simulink platform and compiled into a dynamic link library file. The dynamic link library file performs input / output port identification and data routing binding in the Hilab platform to realize the hardware input / output binding between the load model and the simulation load board.

[0016] Furthermore, after the routing binding relationship is established, the configuration table can be directly modified within the sub-simulation node to realize the power supply control of each slot board in the electronic brake control unit chassis without physical plugging and unplugging operations, thus completing the online management of the electronic brake control unit board.

[0017] Furthermore, the main simulation node has TCN network management functions, CAN network management functions, and ECN network management functions.

[0018] Furthermore, the main simulation node includes a TCN & ECN gateway, an Ethernet router, and an Ethernet switch, used to perform data transmission and bus control of the train communication network.

[0019] Furthermore, the test service node consists of an industrial control computer and is equipped with the Hilab platform.

[0020] Furthermore, the test service node is also used to simulate the functions of a train driver's cab, including the operation of the occupancy, driver's controller, parking brake button, and emergency brake button.

[0021] The beneficial effects of this invention are as follows: This invention achieves a "no physical replacement" switching method for test items by pre-integrating all EBCU boards under test within the same chassis and using a power management board to independently control the power supply to each slot. When performing different tests, there is no need for manual board insertion / removal or reconfiguration of tooling cables; switching can be completed simply by modifying the software configuration on the Hilab platform. This significantly reduces project preparation and switching time, resulting in a substantial improvement in overall efficiency. Comparative tests show that single-item test preparation time can be reduced by approximately 90%, effectively improving test continuity and overall production efficiency.

[0022] Traditional testing methods often involve frequent physical plugging and unplugging, which can easily cause oxidation of the board's gold fingers and deformation of the slot pins, significantly shortening the lifespan of the boards and connecting cables. This invention uses a power management board to control power supply on / off, enabling switching of test objects at the logic level. This avoids repeated plugging and unplugging operations, fundamentally reducing physical wear and tear, effectively extending the lifespan of the EBCU board under test and the simulated load board, and lowering system maintenance and replacement costs.

[0023] This invention utilizes a software-linked control mechanism to send commands from the simulated load board to the power management board. The Hilab platform then uniformly configures and manages the test scenarios, avoiding random failures caused by improper operation during manual replacement, such as loose wiring, misaligned pins, or electrostatic discharge. This approach ensures consistent configuration and signal integrity across all test environments, significantly improving the reliability of the testing process and the accuracy of the results, effectively reducing the interference of human factors on the test data.

[0024] The system architecture of this invention adopts a modular design. When a new project or a new EBCU board is added to the testing system, it only needs to be connected to an empty slot in the chassis and configured through software to be included in unified management, without requiring any changes to the existing hardware structure. This design gives the testing system good scalability and compatibility, and can flexibly adapt to the rapid iteration needs of different vehicle models and projects.

[0025] This invention is the first to combine hardware pre-configuration with software logic control, transforming the traditional manual "physical replacement" mode into a visualized and automated logic switching process, achieving a qualitative improvement in testing efficiency, system stability, and reliability. This solution fundamentally solves the bottleneck problems existing in the traditional EMU software integration testing mode, providing a highly efficient, stable, and scalable new solution for EMU and urban train braking system software testing, with significant engineering application value and promising prospects for widespread adoption. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 This is a structural block diagram of the integrated testing system for urban braking software of electric vehicles according to an embodiment of the present invention; Figure 2 This is a structural block diagram of the electronic brake control unit chassis according to an embodiment of the present invention; Figure 3This is a structural block diagram showing the connection relationship between the sub-simulation node, the electronic braking control unit chassis, and the main simulation node in an embodiment of the present invention. Figure 4 This is a schematic diagram of the configuration interface of a sub-simulation node provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of a route binding interface provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the default input value interface of the model provided in an embodiment of the present invention. Detailed Implementation

[0027] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. 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.

[0028] It should be noted that the terms "comprising" and "having" and any variations thereof in the specification, claims and accompanying drawings of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such processes, methods, products or devices.

[0029] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0030] The integrated testing system for urban braking software of high-speed trains provided by this invention is mainly used for the integrated testing of electronic brake control unit (EBCU) software of high-speed trains and urban trains. It can realize the unified configuration and rapid switching of multi-item test environments, thereby improving test efficiency, reducing hardware wear and tear and improving test reliability.

[0031] Through software control and hardware collaboration, automated scheduling and data exchange of test tasks across different EBCU chassis are achieved. The various units of the system form a complete testing framework via communication networks, power control signals, and tooling cables, enabling fully automated management of the entire process from signal input and data acquisition to result analysis.

[0032] Figure 1 This is a structural block diagram of the integrated testing system for urban braking software of electric vehicles according to an embodiment of the present invention, as shown below. Figure 1As shown, in one embodiment of the present invention, the electric vehicle urban braking software integration test system of the present invention includes: multiple electronic brake control unit (EBCU) chassis to be tested, multiple sub-simulation nodes, a main simulation node and a test service node; The sub-simulation nodes are electrically connected to the corresponding electronic brake control unit chassis, and are used to simulate the external input signals of the electronic brake control unit chassis and acquire the output signals of the electronic brake control unit chassis. The main simulation node connects the multiple electronic brake control unit chassis and the multiple sub-simulation nodes, and is used to control the signal interaction between the sub-simulation nodes and the electronic brake control unit chassis by managing the train communication network and the simulated train bus control commands; The test service node connects the multiple sub-simulation nodes and the main simulation node, and is used to uniformly configure, distribute parameters and schedule the main simulation node and the sub-simulation nodes, analyze the output signals and generate test reports.

[0033] Specifically, each electronic brake control unit (EBCU) chassis serves as the test object, containing several EBCU boards and power management boards. Each chassis is electrically connected to its corresponding sub-simulation node, forming a one-to-one test channel for receiving simulation input signals and output response signals.

[0034] The sub-simulation node is the unit for generating and acquiring test signals. It contains a simulation load board and corresponding interface modules to simulate external input signals of the EBCU (such as pressure sensors, speed sensors, train loop status signals, isolation gate signals, etc.) and acquire feedback signals output by the EBCU. The sub-simulation node is connected to the corresponding electronic brake control unit chassis via tooling cables to form a high-precision signal loop, achieving real-time mapping of input and output.

[0035] The master simulation node, serving as the system's communication control and data coordination center, is responsible for managing the train-level communication network. Internally, it includes various network management modules such as TCN, CAN, and ECN, and can simultaneously simulate train bus control commands, coordinating signal interactions between sub-simulation nodes and the EBCU chassis. The master simulation node can not only execute bus protocol control within the virtual vehicle model but also achieve unified timing and data synchronization across multiple nodes based on the scheduling instructions of the test service node.

[0036] The test service node, consisting of an industrial control computer or a host computer, is the core of the system's software control and is used to run the test management platform (such as the Hilab platform). This node connects to the main simulation node and each sub-simulation node via a network, enabling centralized control and task scheduling of the system.

[0037] During the testing process, the test service node is responsible for: uniformly configuring and distributing parameters to the main simulation node and sub-simulation nodes; setting test items, communication rules, and execution order; collecting test data and EBCU output signals and performing real-time analysis; and automatically generating test reports to record the execution results of each item.

[0038] During the test preparation phase, the test service node selects the test configuration file according to the vehicle model or project under test, and sends parameters and task instructions to the main simulation node and each sub-simulation node through the Ethernet communication network.

[0039] After receiving the command, the main simulation node initializes and configures the train communication network, simulating the operating environment of TCN, CAN, and ECN bus protocols to form a virtual train communication topology. Upon receiving the command, each sub-simulation node generates corresponding input signals based on the set test conditions and inputs them to the corresponding EBCU chassis via tooling cables.

[0040] The board under test (DUT) inside the EBCU chassis responds to and processes the input signals. Its output signals are collected by the corresponding sub-simulation nodes and returned to the test service node. The master simulation node is responsible for synchronizing data and timing at the network layer, ensuring the integrity and consistency of signal transmission between nodes. Finally, the test service node analyzes and compares all collected data, automatically generating a test report to evaluate the correctness and stability of the software functionality.

[0041] Through the above workflow, this invention achieves comprehensive management and automated execution of the hardware testing process at the software level, thereby eliminating inefficient operations such as frequent plugging and unplugging of boards and manual wiring in traditional testing.

[0042] In one embodiment, the sub-simulation node chassis is composed of an NI-PXI chassis, and the node is controlled by the test service node configuration control, with customized simulation load cards inserted into the NI-PXI chassis.

[0043] In this application, multiple electronic brake control unit (EBCU) boards within multiple EBCU chassis can simultaneously be in a test-ready state. Test service nodes can quickly switch between different projects via software configuration, avoiding traditional manual board replacement operations. The communication management and bus simulation functions of the main simulation node ensure the consistency and accuracy of signal interaction, reducing random errors caused by human error or poor physical contact. Through a hierarchical structure of "test service node—main simulation node—sub-simulation node—EBCU chassis," closed-loop control of command and signal flows is achieved, resulting in a clear system operating logic and strong scalability. Each node is uniformly managed through standardized interfaces and a software platform, facilitating subsequent expansion to different vehicle models or test projects within the same system framework and reducing redundant construction.

[0044] Figure 2This is a structural block diagram of the electronic brake control unit chassis according to an embodiment of the present invention, as shown below. Figure 2 As shown, in one embodiment of the present invention, the electronic brake control unit chassis is provided with multiple board mounting slots, and each slot is respectively used to install multiple electronic brake control unit boards and power management boards under test. The power management board is connected to the multiple electronic braking control unit boards and is used to independently control the power supply status of each electronic braking control unit board according to the power supply signal of the sub-simulation node.

[0045] Specifically, to meet the flexible switching requirements of multi-project testing scenarios, this invention designs a modular multi-slot structure inside the electronic brake control unit chassis, and configures a power management board for independent control of the power supply status of each slot. In the chassis backplane bus, such as... Figure 2 As shown, the power supply lines for each slot are connected in series to the AC power control board slot, enabling the AC power control board to control the power supply of each board.

[0046] The electronic brake control unit (EBCU) chassis serves as the carrier of the test system's device under test (DUT). Internally, it features several board mounting slots for inserting and securing multiple DUT boards and a power management board. Each slot has a pre-set standardized backplane interface and power path, enabling both signal transmission and power distribution. The chassis employs a modular design, allowing for the simultaneous accommodation of EBCU boards of different models or for different projects, achieving a "multi-board co-mounted" DUT configuration.

[0047] Each EBCU board is connected to the power management board and external signal interfaces via the chassis backplane bus, and is a software or hardware control module that needs to be verified during the test. Each board corresponds to a specific vehicle control function, such as braking control, pressure regulation, or status detection. During the test, these boards receive input signals from the sub-simulation nodes and output response signals back to the test system.

[0048] The power management board is installed in a dedicated slot in the chassis and is electrically connected to each EBCU board via the chassis backplane circuitry. It is the core module for power control within the chassis. The power management board receives power control signals from the sub-simulation nodes and regulates the power supply to each EBCU board according to the control commands, thereby achieving independent power supply management across multiple slots.

[0049] In traditional EMU software testing platforms, whenever a test item is switched, operators need to manually unplug and plug in the EBCU board under test and rewire it, which is a complicated process and can easily damage the hardware.

[0050] This invention introduces a power management board inside the chassis, transforming the original manual "physical replacement" into a "software-controlled" logical switching process. When a test service node issues a test task, the corresponding sub-simulation node generates a power control signal and transmits it to the power management board. Based on the received control commands, the power management board selectively switches power on or off across multiple slots, thereby activating the target EBCU board while simultaneously shutting down the power supply to other non-target boards. This independently controllable power scheduling mechanism allows multiple EBCU boards in the same chassis to be activated separately for different test items without the need for physical plugging and unplugging. Throughout the testing process, the power management board continuously monitors the power supply status of each slot and can quickly switch power outputs when needed, achieving fast, stable, and safe test environment management.

[0051] In this application, the power supply channel of the board under test can be switched via software commands, eliminating the need for manual plugging and unplugging. This reduces test preparation time by approximately 90%, significantly improving test progress and continuity. The board and slot maintain a stable connection over a long period, avoiding problems such as gold finger oxidation, slot pin deformation, and poor contact caused by frequent plugging and unplugging, thus extending the lifespan of both the board under test and the chassis. Independent control of the power management board avoids the risks of electrostatic discharge and incorrect connections during manual operation, ensuring the stability and consistency of the power switching process, thereby improving the reliability of the overall test results. The modular multi-slot chassis design is compatible with different types of EBCU boards. In the future, if new vehicle models or projects are added, new boards can simply be pre-installed in the available slots to integrate them into the testing system.

[0052] Figure 3 This is a structural block diagram illustrating the connection relationship between the sub-simulation node, the electronic braking control unit chassis, and the main simulation node in an embodiment of the present invention, as shown below. Figure 3 As shown, in one embodiment of the present invention, the sub-simulation node includes multiple simulation load boards and a power management simulation load board. The simulation load board is electrically connected to the corresponding electronic brake control unit board via tooling cables, and is used to simulate the external input signals of the electronic brake control unit board and acquire the output signals of the electronic brake control unit board. The power management simulation load board is electrically connected to the power management board via a tooling cable, and is used to control the power management board to output power supply signals according to the configuration instructions issued by the test service node.

[0053] Specifically, to achieve more efficient hardware control and precise signal transmission, the sub-simulation node is equipped with multiple simulation load boards and power management simulation load boards. The simulation load boards are used to construct the input / output signal paths for the EBCU board, while the power management simulation load boards are used to control the power supply output of the power management board within the chassis, enabling independent power supply control for the board under test. This structural design allows the test system to quickly switch between test items via software commands without replacing the physical hardware.

[0054] The simulation load board, installed within the sub-simulation node chassis, is a crucial component for simulating external train signals. Each simulation load board is electrically connected to the corresponding EBCU chassis's board under test via tooling cables. Its main functions include: generating and outputting external input signals required by the EBCU, such as pressure sensor signals, speed sensor signals, train loop status signals, and isolation gate signals; acquiring feedback signals output by the EBCU board, such as braking commands, voltage signals, or status signals; and uploading the acquired output signals to the main simulation node or test service node via a data channel for real-time analysis.

[0055] The power management simulation load board is electrically connected to the power management board via a tooling cable, establishing a power control link between the simulation system and the EBCU chassis under test. This board receives configuration commands from the test service node and sends corresponding control signals to the power management board to control its output power signals for each slot. In this way, the sub-simulation node can dynamically control the power supply status of each board under test in the EBCU chassis at the software level, achieving automated switching between multiple test items. When a test scenario needs to be changed, the system only needs to modify the configuration file of the power management simulation load board to quickly complete the switch, without manual hardware plugging and unplugging. The AC power management board is controlled by the TAC power management simulation load board, which can be uniformly configured by the Hilab platform, thus achieving software control of hardware—one hardware platform for multiple test scenarios.

[0056] During system operation, the test service node sends configuration commands to each sub-simulation node via the network according to the selected test task. The simulation load board of the sub-simulation node generates specific types of external input signals according to the task requirements and transmits them to the board under test in the corresponding EBCU chassis via tooling cables. At the same time, the output signal of the EBCU board is returned to the simulation load board for acquisition via tooling cables.

[0057] After receiving control commands from the test service node, the power management simulation load board sends the corresponding power control signals to the power management board inside the EBCU chassis. The power management board then adjusts the power supply to each slot to activate the target board under test. This allows for seamless switching between test items without the need to unplug or replug any hardware; power-on and power-off operations for different EBCU boards can be completed solely through software configuration, significantly improving testing efficiency.

[0058] Throughout the signal transmission and power control process, the simulation load board and the power management simulation load board work together: the former is responsible for signal simulation and acquisition, while the latter is responsible for power supply logic control, forming a closed-loop hardware collaboration system.

[0059] In one embodiment, the configuration interface of the sub-simulation node is as follows: Figure 4 As shown, the interface is displayed in a tree structure. Users can select the Electronic Brake Control Unit (EBCU) to be simulated and enter the corresponding EBCU simulation environment parameter configuration interface. This interface is used to configure the PXI model task and related hardware parameters of the EBCU under test, including IP address settings, SLB simulation load board configuration, and loading of Models load model files.

[0060] As shown in Table 1, the Configuration page of the simulation load board configuration table lists the specific slot distribution of each simulation load board in the NI-PXI chassis. Among them, the power management simulation load board (TAC board) can be installed in slot 6.

[0061] Table 1

[0062] As shown in Table 2, the TEX01_AC page in the simulation load board configuration table lists the function definitions and default parameter values ​​of each pin of the TAC simulation load board in detail, providing a configuration basis for the system's signal wiring and parameter verification.

[0063] Table 2

[0064] In one embodiment, each simulation load board has multiple input / output interfaces, enabling simultaneous simulation of multiple signal channels. The tooling cables employ a shielded multi-core structure to ensure interference resistance and high precision during signal transmission, guaranteeing consistency between simulated signals and real train signals in timing and amplitude.

[0065] In one embodiment of the present invention, the external input signals include pressure sensor signals, speed sensor signals, train loop status signals, and isolation gate signals.

[0066] Specifically, external input signals include various types such as pressure sensor signals, speed sensor signals, train loop status signals, and isolation gate signals. These external input signals are the main signal sources that the Electronic Brake Control Unit (EBCU) needs to sense and respond to during vehicle operation. During testing, the system generates corresponding simulation signals through the simulation load boards of sub-simulation nodes to replace the physical signal inputs in the real train environment, thereby verifying the functionality and performance of the EBCU under laboratory conditions.

[0067] The pressure sensor signal is used to simulate changes in air pressure in the braking system. During the test, the simulation load board generates continuously variable pressure and voltage signals according to the model settings, enabling the EBCU to detect the simulated air pressure value and respond logically to braking commands.

[0068] Speed ​​sensor signals are used to simulate train speed. The simulation system can output speed signals according to different test conditions to verify the braking response characteristics and anti-skid control algorithm of the EBCU in different speed ranges.

[0069] Train loop status signals are used to simulate the occupancy and interlocking states in the vehicle control loop. The simulation node simulation load board can output different signals according to the model logic to simulate the activation and deactivation of the train control loop, so as to test the logical judgment capability of the EBCU in train running and stopping scenarios.

[0070] The isolation valve signal is used to simulate the isolation status of the brake line or air line. Changes in this signal can guide the EBCU to identify and respond to abnormal situations such as air source interruption or line leakage.

[0071] Through comprehensive simulation of the above-mentioned multiple input signals, the system can realize the real-time response and functional verification of EBCU under different operating conditions without relying on actual train equipment, thereby significantly improving the reliability and safety of software testing.

[0072] In one embodiment of the present invention, the sub-simulation node carries a load model, which is constructed by the Simulink platform and compiled into a dynamic link library file; the dynamic link library file performs input / output port identification and data routing binding in the Hilab platform to realize the hardware input / output binding between the load model and the simulation load board.

[0073] Specifically, each sub-simulation node carries a load model, which is built using the Simulink platform and compiled into a dynamic link library (DLL) file. In the test system, the logical relationships between different signals (e.g., a change in one sensor signal causing a response in another) are defined and calculated by the load model. Within the sub-simulation node, by configuring "signal routing relationships" (i.e., defining where signals output from and input in the Hilab platform), the calculation results output by the model are passed to the specific simulation load board channels. In this way, a change in one signal automatically drives changes in other related signals, forming a logical "signal linkage."

[0074] The load model, built on the Simulink platform, describes the external environment, signal logic relationships, and dynamic response characteristics of the vehicle braking system. The model defines multiple input / output ports, corresponding to the input signals (sensor quantities) and output signals (control commands or status feedback) of the EBCU. After modeling, the model is compiled into a dynamic link library (DLL), which can be directly loaded and executed by external software platforms, ensuring real-time communication between the model calculations and the hardware interface.

[0075] The compiled DLL file is imported into the Hilab test platform. The Hilab platform automatically identifies the input / output ports (IO ports) defined in the model and generates a port mapping list in the interface. Through port identification, the system establishes a one-to-one correspondence between virtual model signals and physical channels, laying the foundation for subsequent data binding. The Hilab platform provides data routing functionality to establish binding relationships between model signals and the physical input / output ports of the simulation load board. Through routing configuration, a specific input signal in the model can correspond to a specific input channel of the simulation load board; similarly, model output signals can be mapped to specific output pins. Through Hilab's data routing function, hardware IO binding between the model and the simulation load board is achieved, thereby enabling data transmission between the model and the EBCU under test via physical hardware ports.

[0076] Once the test task is initiated, the Hilab platform loads the DLL model file and runs it in real time. The model calculates simulation results based on the input signals, and the output port data is transmitted to the EBCU under test via the physical board. Simultaneously, the EBCU feedback signal is acquired by the simulation load board and then transmitted back to the model input, achieving closed-loop interaction. The entire process is updated cyclically within millisecond intervals, ensuring controllable signal delay and reliable test results.

[0077] In one embodiment, the route binding interface is as follows: Figure 5 As shown.

[0078] In one embodiment, after the routing binding relationship is established, the system can directly modify the configuration table within a single sub-simulation node to achieve power supply control of each slot board in the EBCU chassis, without the need for physical plugging and unplugging operations, thus completing the online management of the EBCU boards.

[0079] like Figure 6 As shown, when users modify the model's default values ​​in the Hilab platform, they can set the default value of parameter TA1 to "1". According to the model logic, this operation is equivalent to setting the model output signal to "1". This signal is bound to the TAC A1_ON channel of the simulation load board via the Hilab platform's data routing function, thereby causing this channel to output a power supply signal and control the corresponding A1 board to power on and operate. The power supply control method for other slot boards follows the same principle.

[0080] In this application, by combining real-time computation of the Simulink model with the I / O binding of the Hilab platform, a tight closed loop is formed between the virtual simulation model and the actual hardware, realistically reflecting the dynamic response of the EBCU during vehicle operation. The model is loaded as a DLL, allowing for quick replacement or modification of model parameters for different projects without altering the hardware connection structure. Data routing and binding mechanisms ensure a clear and fixed correspondence between model ports and hardware ports, avoiding manual wiring errors and guaranteeing the accuracy of signal transmission. Different simulation models can correspond to different test conditions (such as normal braking, emergency braking, and anti-skid control), and quick switching can be achieved through configuration files on the Hilab platform, greatly improving testing efficiency.

[0081] In one embodiment of the present invention, the master simulation node has TCN network management function, CAN network management function and ECN network management function.

[0082] Specifically, the main simulation node is the core of the system's communication management and coordination, responsible for managing data interaction, timing control, and signal synchronization throughout the test network.

[0083] The main simulation node possesses TCN, CAN, and ECN network management functions, enabling the construction of a complete train communication architecture. During actual testing, the main simulation node operates as a virtual train, interacting with multiple sub-simulation nodes and the electronic brake control unit chassis through different communication networks, ensuring that communication between nodes conforms to the logic and timing requirements of a real train.

[0084] The TCN (Train Communication Network) network management function is used to realize integrated communication management between multiple devices at the train level. The main simulation node sends and receives train control commands through the TCN gateway to realize the simulation and scheduling of train-level bus control logic.

[0085] The CAN (Controller Area Network) network management function is used for data communication between controllers at the subsystem level. The main simulation node communicates and controls with subsystems inside or outside the EBCU chassis via the CAN interface, verifying the stability and response performance of the CAN bus under different communication loads.

[0086] The ECN (Ethernet Communication Network) network management function is used to transmit test data and real-time control signals in a high-bandwidth environment. The main simulation node uses the ECN network to establish a high-speed communication link to realize the parallel transmission and processing of large-scale simulation data.

[0087] By managing the three communication networks mentioned above simultaneously, the main simulation node can construct a multi-level train communication simulation structure, realizing signal coordination and scheduling at the train level, subsystem level, and equipment level, providing a stable and reliable communication foundation for the entire test system.

[0088] In one embodiment of the present invention, the main simulation node includes a TCN & ECN gateway, an Ethernet router, and an Ethernet switch, used to perform data transmission and bus control of the train communication network.

[0089] Specifically, the main simulation node includes hardware modules such as TCN & ECN gateways, Ethernet routers, Ethernet switches, and train real-time data protocol boards (TRDP boards).

[0090] Among them, the TCN & ECN gateway is the core of data conversion and management between different communication networks. It is used to realize protocol bridging and data exchange between the TCN bus and ECN Ethernet, ensuring accurate data flow between different communication layers.

[0091] Ethernet routers and switches are used to construct the system's communication topology. Ethernet routers are responsible for data forwarding and addressing control between different subnetworks, while Ethernet switches are used to manage high-speed interconnection between various communication devices within the main simulation node, ensuring bandwidth allocation and real-time communication performance under multi-task testing.

[0092] The Train Real-time Data Protocol (TRDP) board is a real-time communication protocol used in train systems. The TRDP board in the main simulation node simulates the real-time data transmission process inside the train, enabling real-time information exchange and control command synchronization between the main simulation node and the EBCU chassis. Through this board, the system can completely reproduce the real-time communication mechanism of a train in a simulation test environment, ensuring that the update cycle of the test data is consistent with that of real train communication.

[0093] The aforementioned devices on the main simulation node work together to perform data transmission and bus control of the train communication network, that is, to realize data interaction, signal forwarding and control command scheduling between multiple network protocols, thereby building a stable train-level communication simulation environment.

[0094] In one embodiment of the present invention, the test service node is composed of an industrial control computer and is equipped with the Hilab platform.

[0095] Specifically, the test service node is the core of the management and scheduling of the entire test system, responsible for centralized control, configuration and task scheduling of the main simulation node and multiple sub-simulation nodes.

[0096] The test service node consists of an industrial control computer (ICC), equipped with high-performance computing capabilities and multiple network communication interfaces to meet the complex needs of multi-channel signal processing and test management. The ICC runs the Hilab platform software, which serves as the system's software control and data management center, enabling visualized configuration, operational control, and result analysis throughout the entire testing process. The Hilab platform centrally manages multiple distributed NI-PXI systems, configuring the main simulation node and all sub-simulation nodes through the test service node, and uniformly monitoring all node signals during test execution.

[0097] The Hilab platform provides a unified graphical configuration interface that manages the hardware resources of the main simulation node and all sub-simulation nodes. Users can load test projects, define signal channels, set communication protocols and routing relationships within the platform, and distribute configuration parameters via the network to achieve automated initialization of the entire system.

[0098] During the test run phase, the Hilab platform sends control commands and test tasks to each simulation node through the test service node. The main simulation node organizes the operation logic of the train communication network according to the scheduling commands, while the sub-simulation nodes perform low-level operations such as signal simulation and data acquisition. The test service node can monitor the operating status of each node in real time and dynamically adjust the task priority and execution order, thereby ensuring the orderly and efficient testing process.

[0099] The test service node continuously receives test data and EBCU output signals uploaded from the main simulation node and sub-simulation nodes. The Hilab platform's built-in data analysis module processes and visualizes this data in real time. The system can automatically determine whether the signal response meets the set conditions based on the test cases and generate a test report containing curves, timing data, and anomaly analysis results. In this way, testers can complete the entire process of configuration, execution, monitoring, and evaluation on a single platform, significantly improving the level of test automation.

[0100] In one embodiment, the test service node is a Hilab client, and the main simulation node and sub-simulation node are Hilab servers.

[0101] In one embodiment, the test service node possesses functions such as system configuration and parameter reading / writing, data monitoring, model parameter modification, fault injection, simulated driver's console, manual testing, and automatic testing. Through system configuration and reading / writing, unified initialization and parameter distribution can be completed for each simulation node and EBCU chassis; the data monitoring function is used to collect and display test signals in real time, ensuring visualization and safety during the testing process; the model parameter modification function supports online adjustment of simulation model parameters to adapt to different operating conditions; the fault injection function can simulate abnormal states such as short circuits and open circuits to verify the fault tolerance and safety logic of the EBCU; the simulated driver's console function reproduces driver operation behavior and supports virtual operations such as the driver's controller, brake buttons, and sand spray switches; manual testing is used for single-step verification or debugging of specific signals, while automatic testing can execute the complete test process according to a preset script and generate a report. Through these functions, the test service node achieves centralized control, automated operation, and result analysis of the system, providing an efficient and stable management platform for EBCU software testing of EMUs and urban rail trains.

[0102] Through the above functions, the test service node realizes closed-loop control of the entire process from "test plan management - task issuance - result analysis", and is the core software support platform for this system to realize multi-node collaborative simulation.

[0103] In one embodiment of the present invention, the test service node is also used to simulate the functions of a train driver's cab, including the operation of the occupancy, driver's controller, parking brake button and emergency brake button.

[0104] Specifically, the test service node is also used to simulate the functions of a train driver's cab. This functional module also relies on the Hilab platform, and realizes the simulation input of train driving-related operations through a virtualized operating interface or external human-computer interaction devices, thereby reproducing the real driver's operating scenario during the test.

[0105] The Hilab platform includes a built-in driver's cab interface with virtual controls corresponding to those on a real train driving control console. These controls include occupancy, driver control, parking brake button, emergency brake button, sand spray switch, and other operation items. The platform manages and configures the entire system, stores data, generates test reports, and injects faults. It also provides an overview of all information. Users can perform corresponding operations using the mouse, and the Hilab system converts these signals into corresponding control commands and sends them to the main simulation node and sub-simulation nodes.

[0106] When the tester performs operations in the driver's cab interface, such as pulling the driver's control lever or triggering the emergency brake button, the Hilab platform generates corresponding virtual command signals. After receiving these signals, the main simulation node sends commands to the EBCU chassis via the train communication network to simulate and control the braking system's response. Simultaneously, the sub-simulation nodes generate matching external signal inputs, such as simulating dynamic feedback like changes in train acceleration and braking pressure, thus creating a closed-loop simulation process of operation-response-feedback for the entire system.

[0107] With the driver's cab simulation function, testers can perform complete testing of the EBCU's software logic without the need for a real vehicle. The system can verify the timing correctness of braking command execution, the stability of signal response, and the coordination of various control functions, thereby simulating the actual control logic of train operation under laboratory conditions.

[0108] In one embodiment, the Hilab platform supports automated scripting, enabling the automatic repetition of specific operating conditions for large-scale automated testing and performance verification. This module supports custom signal configurations and parameter adjustments, allowing modification of the sequence script logic according to different vehicle models, thus possessing high versatility and scalability.

[0109] In this application, after integrating the Hilab platform into the test service node, unified configuration, task allocation, and data acquisition of the main simulation node and sub-simulation nodes can be completed on the same workstation, significantly improving system coordination efficiency. The Hilab platform provides a graphical configuration and real-time monitoring interface, enabling testers to intuitively grasp signal status and node operation; it also supports automated execution of test tasks, reducing manual intervention. The driver's cab functional module can simulate train driving operations and braking control logic, allowing the EBCU control software to be verified under real operating logic, greatly improving the realism and safety of the test. Through the data archiving and recording functions of the Hilab platform, all signal trajectories, configuration parameters, and operation records of the test process can be saved, providing a basis for subsequent analysis and problem localization.

[0110] This application provides a system for integrated testing of urban braking software for high-speed trains. The system includes: multiple electronic brake control unit (EBD) chassis to be tested, multiple sub-simulation nodes, a main simulation node, and a test service node. Each sub-simulation node is electrically connected to its corresponding EBD chassis and is used to simulate external input signals and acquire output signals from the EBD chassis. The main simulation node connects the multiple EBD chassis and the multiple sub-simulation nodes and controls the signal interaction between the sub-simulation nodes and the EBD chassis by managing the train communication network and simulating train bus control commands. The test service node connects the multiple sub-simulation nodes and the main simulation node and performs unified configuration, parameter distribution, and scheduling control of the main simulation node and sub-simulation nodes, analyzes the output signals, and generates a test report. This system for integrated testing of urban braking software for high-speed trains achieves software configuration instead of physical replacement, significantly shortening test preparation time, improving test stability, and extending hardware lifespan.

[0111] In the description of this specification, it should be understood that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on this application. Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0112] The terms "an embodiment," "a specific embodiment," "some embodiments," "for example," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. The order of steps involved in the various embodiments is used to illustrate the implementation of this application, and the order of steps is not limited and may be adjusted appropriately as needed.

[0113] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art will understand the specific meaning of the above terms in this application based on the specific circumstances.

[0114] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A software integration testing system for urban braking of high-speed trains, characterized in that, include: The test consists of multiple electronic brake control unit chassis, multiple sub-simulation nodes, a main simulation node, and test service nodes. The sub-simulation nodes are electrically connected to the corresponding electronic brake control unit chassis, and are used to simulate the external input signals of the electronic brake control unit chassis and acquire the output signals of the electronic brake control unit chassis. The main simulation node connects the multiple electronic brake control unit chassis and the multiple sub-simulation nodes, and is used to control the signal interaction between the sub-simulation nodes and the electronic brake control unit chassis by managing the train communication network and the simulated train bus control commands; The test service node connects the multiple sub-simulation nodes and the main simulation node, and is used to uniformly configure, distribute parameters and schedule the main simulation node and the sub-simulation nodes, analyze the output signals and generate test reports.

2. The integrated testing system for urban braking software of high-speed trains according to claim 1, characterized in that, The electronic brake control unit chassis is provided with multiple board mounting slots, and each slot is used to install multiple electronic brake control unit boards and power management boards under test. The power management board is connected to the multiple electronic braking control unit boards and is used to independently control the power supply status of each electronic braking control unit board according to the power supply signal of the sub-simulation node.

3. The integrated testing system for urban braking software of high-speed trains according to claim 2, characterized in that, The sub-simulation node includes multiple simulation load boards and power management simulation load boards; The simulation load board is electrically connected to the corresponding electronic brake control unit board via tooling cables, and is used to simulate the external input signals of the electronic brake control unit board and acquire the output signals of the electronic brake control unit board. The power management simulation load board is electrically connected to the power management board via a tooling cable, and is used to control the power management board to output power supply signals according to the configuration instructions issued by the test service node.

4. The integrated testing system for urban braking software of high-speed trains according to claim 1, characterized in that, The external input signals include pressure sensor signals, speed sensor signals, train loop status signals, and isolation gate signals.

5. The integrated testing system for urban braking software of high-speed trains according to claim 1, characterized in that, The sub-simulation node carries a load model, which is built by the Simulink platform and compiled into a dynamic link library file. The dynamic link library file performs input / output port identification and data routing binding in the Hilab platform to realize the hardware input / output binding between the load model and the simulation load board.

6. The integrated testing system for urban braking software of high-speed trains according to claim 5, characterized in that, After the routing binding relationship is established, the configuration table can be directly modified in the sub-simulation node to realize the power supply control of each slot board in the electronic brake control unit chassis without physical plugging and unplugging operations, thus completing the online management of the electronic brake control unit board.

7. The integrated testing system for urban braking software of high-speed trains according to claim 1, characterized in that, The main simulation node has TCN network management functions, CAN network management functions, and ECN network management functions.

8. The integrated testing system for urban braking software of high-speed trains according to claim 7, characterized in that, The main simulation node includes a TCN & ECN gateway, an Ethernet router, and an Ethernet switch, which are used to perform data transmission and bus control of the train communication network.

9. The integrated testing system for urban braking software of high-speed trains according to claim 1, characterized in that, The test service node consists of an industrial control computer and is equipped with the Hilab platform.

10. The integrated testing system for urban braking software of high-speed trains according to claim 1, characterized in that, The test service node is also used to simulate the functions of a train driver's cab, including the operation of the driver's cab, the driver's controller, the parking brake button, and the emergency brake button.

Images