Tbm-free train brake test control method and device

Abstract

The application discloses a train brake test control method without a TBM. The method comprises the following steps: a CCU sends a query instruction of a brake test permission condition to each BCU to obtain brake test permission conditions and train brake state data fed back by each BCU; the CCU determines whether a corresponding carriage of each BCU meets a test starting requirement based on the feedback data; if the requirement is met, the CCU sends a test execution instruction to each BCU to instruct the BCU to execute a brake test and feed back test process data and an execution result in real time; finally, the CCU controls a test process according to the fed back process data and determines a train brake function according to the execution result. The method does not need to depend on a TBM device, realizes full-process control of the brake test through bidirectional communication between the CCU and each BCU, gets rid of the dependence on a special test device, and simplifies a deployment process of the brake test.

Description

Technical Field

[0001] This application relates to the field of train braking test technology, and in particular to a train braking test control method and equipment without a TBM. Background Technology

[0002] As the core guarantee for safe train operation, the reliability and availability of the braking system directly affect the safety of train operation and the lives and property of passengers. Braking tests are a key part of the train's factory inspection, daily maintenance, and periodic overhaul. By simulating braking operations under different working conditions, the core functions of the braking system, such as direct braking, emergency braking, anti-skid, and magnetic track braking, as well as auxiliary performance such as air compressor air output capacity and main air duct sealing, are verified. Potential faults are identified in a timely manner, ensuring that the braking system is always in an effective working state. Therefore, it holds an irreplaceable and important position in the rail transit field.

[0003] Currently, the braking test control of rail transit vehicles such as high-speed trains mostly relies on the Trailer Brake Control Module (TBM), which is usually handled by the Brake Control Unit (BCU) activated in the driver's cab, with other BCUs serving as slave control units.

[0004] However, the existing TBM-based control architecture has significant shortcomings. First, the TBM setup increases the overall vehicle procurement and integration costs. Second, the communication link is redundant, data transmission is subject to latency risks, and troubleshooting is difficult, which is not conducive to the CCU's direct control of the braking system. Third, the determination of test start conditions and the selection of projects lack flexibility and adaptability, making it difficult to dynamically adjust according to the actual braking state of the train, affecting the convenience of test operation, and limiting the integrated optimization of the overall vehicle control architecture. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a train braking test control method and equipment without a TBM.

[0006] The embodiments of this application disclose the following technical solutions: In a first aspect, embodiments of this application provide a train braking test control method without a TBM, the method comprising: The central control unit (CCU) issues a query command to each train braking control unit (BCU) regarding the permissible conditions for braking tests; wherein, the query command is used to instruct each BCU to provide feedback to the CCU on the permissible conditions for braking tests and train braking status data; The CCU determines whether the carriage corresponding to each BCU meets the test start requirements based on the braking test allowable conditions fed back by each BCU and the train braking status data; and if the test start requirements are met, it issues a test execution command to each BCU; wherein, the test execution command is used to instruct the BCU to perform the braking test operation and to provide real-time feedback on the test process data and execution results; The CCU controls the test process based on the process data and determines the braking function based on the execution results.

[0007] In one possible implementation, the CCU determines whether the carriage corresponding to each BCU meets the test start requirements based on the braking test allowable conditions fed back by each BCU and the train braking status data, including: The CCU summarizes the braking test allowable conditions fed back by each BCU, and determines whether the carriage corresponding to each BCU meets the test start requirements based on the braking test allowable conditions, combined with the preset pre-test basic conditions and various braking test prompt conditions. Among them, the pre-test basic conditions include normal train power supply status and brake line pressure meeting the standard, and the braking test prompt conditions are used to describe the pre-operation requirements and restrictions required for the braking test.

[0008] In one possible implementation, before issuing test execution instructions to each of the BCUs, the method further includes: After the test start requirements are met, the CCU determines the number of parking brakes and holding brakes to be applied based on the train braking status data; The CCU selects the feasible braking test items based on the number of parking brakes and holding brakes applied; When the number of parking brake applications meets the brake test item screening rules, the test execution command is used to instruct the BCU to execute all test items; the all test items include automatic braking test, emergency braking test, anti-skid system test, magnetic track braking test and main air duct leakage test; When the number of parking brake applications does not meet the selection rules for the braking test items but the number of brake applications still meets the selection rules for the braking test items, the test execution instruction is used to instruct the BCU to perform the anti-skid system test, the magnetic track brake test, and the main duct leakage test.

[0009] In one possible implementation, before the CCU issues the test execution instruction to each of the BCUs, the method further includes: The CCU sends a release holding brake command to each of the BCUs and waits for each of the BCUs to send back a confirmation signal that the holding brake has been released; If no confirmation signal indicating that the braking has been released is received from each of the BCUs within the time limit, the CCU determines that the test preparation has failed, stops issuing the test execution command, and displays an abnormal message through the HMI.

[0010] In one possible implementation, when the test execution command is used to instruct the performance of a test item, the CCU locks other braking test items besides the braking test indicated by the test execution command; and resets the historical results of the test item before each test item is started. When the braking test indicated by the test execution command ends or is interrupted, the other braking test items are unlocked and a new test item is selected.

[0011] In one possible implementation, the process data includes the test execution duration; the CCU manages the test process based on the process data and determines the braking function based on the execution result, specifically including: The CCU monitors the execution time of the experiment in real time. If the timeout threshold is exceeded, the experiment corresponding to the process data is directly determined to have failed. The CCU determines whether the test item corresponding to the execution result is successful or unsuccessful based on the preset braking test judgment criteria and the execution results fed back by each BCU.

[0012] In one possible implementation, the method further includes: The CCU sets the display status of the execution result according to a preset priority. If the execution result does not change, the original display status is maintained. The CCU displays the braking function determination result in real time through the HMI prompt window and stores it in the system database, supporting querying on the execution result interface.

[0013] In one possible implementation, the test train includes multiple carriage groups, each carriage group includes multiple carriages, one CCU is configured in one-to-one correspondence with each carriage group, one carriage is configured in one-to-one correspondence with at least one BCU, one CCU is configured in one-to-one correspondence with the BCUs corresponding to each carriage in the corresponding carriage group, and the multiple CCUs are connected to each other via a twisted-wire train bus WTB gateway.

[0014] Secondly, embodiments of this application disclose a train braking test control device without a TBM, the device comprising: The sending module is used to send a query command for the allowable conditions of braking test to each train braking control unit (BCU) corresponding to the CCU; wherein, the query command is used to instruct each BCU to feed back the allowable conditions of braking test and train braking status data to the CCU; The startup module is used to determine whether the carriage corresponding to each BCU meets the test startup requirements based on the braking test allowable conditions fed back by each BCU and the train braking status data; and if the test startup requirements are met, to issue a test execution command to each BCU; wherein, the test execution command is used to instruct the BCU to perform the braking test operation and to provide real-time feedback of the test process data and execution results; The determination module is used to control the test process based on the process data and to determine the braking function based on the execution result.

[0015] In one possible implementation, the startup module is specifically used to summarize the braking test allowable conditions fed back by each BCU, and determine whether the carriage corresponding to each BCU meets the test startup requirements based on the braking test allowable conditions, combined with the preset pre-test basic conditions and various braking test prompt conditions; wherein, the pre-test basic conditions include normal train power supply status and brake line pressure meeting the standard, and the braking test prompt conditions are used to describe the pre-operation requirements and restrictions required for the braking test.

[0016] In one possible implementation, the starting module is further configured to determine the number of parking brakes and holding brakes applied based on the train braking status data after the test start requirements are met; Select feasible braking test items based on the number of parking brakes and holding brakes applied; When the number of parking brake applications meets the brake test item screening rules, the test execution command is used to instruct the BCU to execute all test items; the all test items include automatic braking test, emergency braking test, anti-skid system test, magnetic track braking test and main air duct leakage test; When the number of parking brake applications does not meet the selection rules for the braking test items but the number of brake applications still meets the selection rules for the braking test items, the test execution instruction is used to instruct the BCU to perform the anti-skid system test, the magnetic track brake test, and the main duct leakage test.

[0017] In one possible implementation, the startup module is further configured to send a release holding brake command to each of the BCUs and wait for each of the BCUs to send back a confirmation signal that the holding brake has been released; If no confirmation signal indicating that the braking has been released is received from each of the BCUs within the time limit, the test preparation is deemed to have failed, the test execution command is stopped, and an abnormal message is displayed via HMI.

[0018] In one possible implementation, when the test execution command is used to instruct the execution of a test item, the startup module is used to lock other braking test items besides the braking test indicated by the test execution command; and reset the historical results of the test item before each start of a test item; and when the braking test indicated by the test execution command ends or is interrupted, unlock the other braking test items and reselect the test item.

[0019] In one possible implementation, the process data includes the test execution time; the judgment module is specifically used to monitor the execution time of the test in real time, and if it exceeds a preset timeout threshold, it directly determines that the test item corresponding to the process data has failed; based on the preset braking test judgment criteria, combined with the execution results fed back by each BCU, it determines whether the test item corresponding to the execution result is successful or failed.

[0020] In one possible implementation, the device further includes a display module, which is used to set the display state of the execution result according to a preset priority, and to maintain the original display state if the execution result does not change; the braking function judgment result is displayed in real time through the HMI prompt window and stored in the system database, supporting querying on the execution result interface.

[0021] Thirdly, embodiments of this application disclose a control device, including a processor and a memory, wherein the memory is used to store programs, instructions or code, and the processor is used to execute the programs, instructions or code in the memory to complete the train braking test control method without TBM as described in any of the first aspects.

[0022] Fourthly, embodiments of this application disclose a computer-readable storage medium, characterized in that it stores a computer program, which is loaded by a processor to execute the train braking test control method without TBM as described in any of the first aspects.

[0023] This application provides a train braking test control method without a TBM. The method involves the Control Unit (CCU) sending a query command to each Train Control Unit (BCU) regarding the permitted braking test conditions to obtain feedback from each BCU on the permitted braking test conditions and train braking status data. Based on this feedback data, the CCU determines whether the carriage corresponding to each BCU meets the test initiation requirements. If the requirements are met, the CCU issues a test execution command to each BCU, instructing the BCU to perform the braking test and providing real-time feedback on the test process data and execution results. Finally, the CCU manages the test process based on the feedback process data and determines the train braking function based on the execution results. This method does not rely on TBM equipment. It achieves full-process control of the braking test through bidirectional communication between the CCU and each BCU, eliminating reliance on dedicated testing equipment and simplifying the deployment process of the braking test. The CCU first verifies the test initiation conditions through the query command, avoiding initiation of the braking test when the test requirements are not met, thus ensuring the safety of the test process. Simultaneously, the CCU manages the test process through real-time acquired test process data and combines the execution results to determine the braking function, ensuring the controllability of the braking test process and the accuracy of the test results. This effectively achieves standardized and efficient execution of train braking tests without dedicated equipment. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application 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 only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A schematic diagram of the architecture of a TBM-free TCMS system provided for an embodiment of this application; Figure 2 A schematic flowchart illustrating a train braking test control method without a TBM provided in this application embodiment; Figure 3 A schematic diagram of the architecture of another TBM-free TCMS system provided for an embodiment of this application; Figure 4 This is a schematic diagram of a train braking test control device without a TBM, provided as an embodiment of this application. Detailed Implementation

[0026] To facilitate understanding of the TBM-free train braking test control method and equipment provided in the embodiments of this application, before delving into the details, the definitions of key terms are clarified (in conjunction with the disclosure document and industry standards) to ensure unambiguous understanding in the future: "TBM-free" means eliminating the TBM in the traditional braking test control architecture. Instead of setting up a separate braking master control module for summarizing braking status data and transferring control commands, the core control functions of the braking test are directly undertaken by the central control unit of the Train Control and Management System (TCMS).

[0027] The Central Control Unit (CCU) is the core processing unit of the TCMS system. As the control subject of the braking test in this embodiment, it is responsible for issuing query commands and test execution commands, receiving and summarizing feedback data from each BCU, determining test conditions, controlling the test process, and processing execution results.

[0028] The Braking Control Unit (BCU) is the local control unit for the braking system of each carriage of the train. It is used to respond to the instructions of the Control Unit (CCU), execute specific braking test operations, and collect and feedback the allowable conditions for braking tests, train braking status data, test process data, and execution results in real time.

[0029] The Wired Train Bus (WTB) gateway is an interface conversion and data forwarding device adapted to the WTB communication protocol. It is used to realize the communication connection between CCUs of different train formations, support cross-formation data interaction in the train coupling scenario, ensure that the test-related data of each formation's BCU can be effectively summarized by the main control CCU in the coupling state, and ensure the coordinated execution of braking tests.

[0030] As described earlier, most high-speed trains and other rail transit vehicles currently employ multi-car formations. Traditional 8-car trains often use a "four-motor, four-trailer" configuration, alternating between trailer and motor cars. Their overall vehicle network communication operates on a four-car communication unit, with multiple units exchanging data via WTB. In the corresponding braking system control architecture, each communication unit has a braking master control unit (TBM). The braking master control unit (TBM) is typically activated by the driver's cab's BCU, while the BCUs of other units within the train act as slave control units. During braking tests, the TBM is responsible for summarizing the braking status data of the entire train. This braking status data is directly sent by the train's corresponding BCU, and core information, including braking test data, is transmitted via the WTB bus to the TCMS system's CCU. The CCU then coordinates the issuance of test-related commands and status feedback.

[0031] However, existing TBM-based braking test control architectures have significant technical limitations. On one hand, the TBM, as an independent braking control unit, incurs high procurement and integration costs, increasing overall vehicle manufacturing costs. On the other hand, braking test data must be aggregated by the TBM before being transmitted to the CCU, resulting in redundant communication links. This not only may lead to data transmission delays but also increases the complexity of fault diagnosis, hindering the TCMS system's direct control and in-depth diagnostics of the braking system. Furthermore, the existing architecture lacks flexible adaptive logic for determining braking test initiation conditions and selecting test items, making it difficult to dynamically adjust executable test content based on the actual braking state of the train, thus reducing the operational convenience and adaptability of braking tests. In addition, the presence of the TBM limits the degree of collaborative control between the braking system and the TCMS system, hindering the integrated design and optimization of the overall vehicle control architecture.

[0032] To address this technical problem, this application provides a train braking test control method without a TBM (Train Braking Management Unit), applied to a TCMS (Train Control System) including a CCU (Train Control Unit) and multiple BCUs (Train Braking Units), where the multiple BCUs include at least a first BCU and a second BCU. The CCU establishes connections with the first BCU of the first carriage and the second BCU of the second carriage, respectively. The method involves the CCU issuing query commands for braking test permit conditions to each BCU, receiving feedback from each BCU on the braking test permit conditions and train braking status data, determining whether the test initiation requirements are met based on the feedback data, and issuing test execution commands to each BCU when the requirements are met. The BCUs respond to the commands, execute the braking test operations, and provide real-time feedback on the test process data and execution results. Finally, the CCU manages the test process based on the feedback test process data and completes the braking function determination based on the execution results.

[0033] This embodiment eliminates the TBM (Train Bus Module) in the traditional braking test control architecture. Instead, the CCU (Control Unit) directly communicates with the BCU (Body Control Unit) of each train and undertakes the core control functions. This eliminates the procurement and integration costs associated with the TBM, reducing overall vehicle manufacturing costs. Furthermore, it simplifies the communication link, avoiding the redundant steps of data aggregation and transfer via the TBM in the traditional architecture, reducing data transmission latency, and improving the real-time performance of test control. Simultaneously, the CCU directly receives raw data from the BCU and performs test condition and function determinations, enhancing direct control over the braking test, ensuring the accuracy of execution results, and adapting to multi-train connection scenarios, thus improving the flexibility and applicability of braking test control.

[0034] The method provided in this application is applicable to train control and management systems including CCU, WTB gateway, and multiple BCUs. It is primarily adapted to rail transit scenarios involving single or multiple trains in coupling, and is particularly suitable for high-speed trains, heavy-haul locomotives, and other vehicles with high requirements for braking safety and testing efficiency. In scenarios such as train factory testing, routine maintenance, and periodic inspections, operators can trigger braking tests through a human-machine interface. The CCU directly establishes communication with the BCUs of each carriage, completing the braking system function verification without relying on traditional TBM modules. In scenarios involving two or more trains in coupling, the CCU of the main control train can achieve cross-train communication with the CCUs of other trains through the WTB gateway, comprehensively receiving braking status data and execution results from all coupled train BCUs. This ensures the coordination and accuracy of braking tests under coupling conditions, meeting the braking system testing needs of complex operating conditions such as heavy-haul transportation and long-formation operations.

[0035] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0036] See Figure 1 and Figure 2 , Figure 1 This is a schematic diagram of the architecture of a TBM-free TCMS system provided in an embodiment of this application. Figure 2 This is a flowchart illustrating a train braking test control method without a TBM, as provided in an embodiment of this application.

[0037] like Figure 1 As shown, the train control and management system includes a central control unit (CCU) and multiple train braking control units (BCUs); the CCU is connected to each BCU.

[0038] The following section uses multiple BCUs, including a first BCU and a second BCU, as an example to introduce this control method in conjunction with the interaction process between the CCU and the BCU. This method includes: S201: The CCU issues a query command to each BCU regarding the permissible conditions for braking tests.

[0039] The query command for brake test permit conditions is a standardized control command generated and issued by the CCU. It is used to inquire with each BCU whether the braking system within its jurisdiction meets the basic conditions for conducting brake tests. The command includes key information such as test type identifier and data feedback format requirements.

[0040] In this embodiment, the train control and management system has been initialized. The CCU establishes stable connections with the first BCU of the first carriage and the second BCU of the second carriage through preset communication links, ensuring the real-time performance and reliability of command transmission. When the operator triggers a braking test start request through the Human-Machine Interface (HMI), or when the system meets the preset automatic test trigger conditions, the CCU, as the control core, first generates a query command for the braking test allowable conditions in a unified format. This command clearly includes the time window for data feedback and the category of allowable conditions to be queried (such as brake line pressure, actuator status, etc.), ensuring that each BCU understands the query requirements consistently.

[0041] Subsequently, the CCU synchronously sends the query command to the first BCU and the second BCU via point-to-point communication to avoid command transmission conflicts. During the command sending process, the CCU monitors the command transmission status in real time. If a command transmission failure is detected, the command is immediately resent and retried no more than a preset number of times. If the command still fails after the preset number of retries, the CCU notifies the operator of a communication error through the HMI to ensure the effectiveness of the command sending.

[0042] This application embodiment replaces the traditional TBM summary query mode by having the CCU actively initiate query commands, directly realizing communication interaction between the CCU and each train's BCU, simplifying the command transmission link, reducing delays caused by intermediate transfer links, and improving the efficiency of the test preparation stage.

[0043] S202: Each BCU responds to the query command and sends back the braking test permitting conditions and train braking status data to the CCU.

[0044] The conditions for brake testing are state parameters collected locally by the BCU that characterize the braking system under its jurisdiction as having a basis for testing, including but not limited to whether the brake line pressure meets the standard, whether the brake actuator has no fault alarms, whether the brake power supply is normal, and whether the brake loop is in a continuous state.

[0045] Train braking status data is used to reflect the real-time data of the overall operating status of the train's current braking system, including key information such as the number of parking brakes applied, the status of maintaining brake application, brake cylinder pressure values, or the activation status of the anti-skid system.

[0046] Upon receiving the query command from the CCU, the first and second BCUs immediately initiate their local data acquisition programs. Through their connected sensors and actuator feedback interfaces, they synchronously collect data on the permissible conditions for braking tests and the train's braking status. For example, the first BCU collects data such as the brake line pressure of the first car, brake actuator fault codes, and the number of cars with applied braking at rest. Simultaneously, the second BCU collects the corresponding data from the second car, ensuring the comprehensiveness and real-time nature of the data acquisition.

[0047] After data collection, the first and second BCUs organize and package the data according to the data format specified in the query command, removing invalid and abnormal data to ensure the accuracy of the feedback data. Subsequently, within the time window specified in the command, the two BCUs, through the communication link established with the CCU, send the organized data packets back to the CCU point-to-point. During the feedback process, the BCU monitors the data transmission status in real time. If a transmission interruption is detected, it will automatically resend the data packet until successful transmission or the maximum number of retries is reached. If a retry fails, a transmission anomaly is marked in the feedback data.

[0048] The first and second BCUs accurately collect and feedback the required data based on query commands, ensuring the relevance and comprehensiveness of the information acquired by the CCU. This provides complete and reliable data support for determining subsequent test initiation requirements. The point-to-point feedback method between the BCU and CCU, along with the transmission retry mechanism, guarantees the reliability of data transmission and reduces data loss due to communication failures. The mode of BCU directly feeding data back to the CCU eliminates the TBM relay link in the traditional architecture, further shortening the data transmission cycle and improving the overall efficiency of the test process.

[0049] S203: The CCU determines whether the carriage corresponding to each BCU meets the test start requirements based on the braking test allowable conditions and train braking status data fed back by each BCU; and if the test start requirements are met, it issues a test execution command to each BCU.

[0050] The test start requirements are the core conditions preset by the TCMS system to ensure the safe and effective conduct of the braking test. These include conditions such as all allowable conditions fed back by each BCU meeting the standards or the overall braking status of the train meeting the basic requirements of the test.

[0051] The test execution command is a standardized control command generated by the CCU after determining that the test start requirements are met. It includes key information such as test item identification, execution parameters (such as braking pressure threshold, test duration threshold, etc.) or data feedback frequency requirements. The test execution command is used to instruct each BCU to perform specific braking test operations.

[0052] After receiving the complete data packets from the first and second Bus Control Units (BCUs), the Control Center (CCU) first parses and verifies the data, discarding data marked as abnormal or formatted incorrectly. If a BCU's feedback data is missing key parameters, the data from that BCU is deemed invalid. Subsequently, the CCU comprehensively evaluates the valid data according to the preset test initiation requirement judgment logic. The CCU checks the braking test allowable conditions fed back by the first and second BCUs one by one (while also considering the overall braking status data of the train) to determine whether the basic conditions for test initiation are met.

[0053] If the determination result indicates that the test start requirements are met, the CCU generates a corresponding test execution instruction based on the test items selected by the operator. The instruction specifies the braking test items, execution duration, key parameter thresholds, and data feedback intervals. Subsequently, the CCU synchronously sends the test execution instruction to the first BCU and the second BCU via a stable communication link to ensure that the braking tests of the two trains start synchronously. If the determination result indicates that the test start requirements are not met, the CCU will notify the operator of the specific conditions that are not met through the HMI and terminate the test start process.

[0054] In this embodiment, the CCU makes a decision directly based on the raw data fed back by each BCU, replacing the TBM relay decision mode in the traditional architecture, reducing the decision delay in the intermediate links and improving the response speed of the test start.

[0055] In step S203, the process of the CCU determining the test start requirements based on feedback data from each BCU can be implemented through a more refined multi-condition comprehensive judgment logic to further improve the accuracy and adaptability of the judgment. In this embodiment, the judgment process specifically combines the preset pre-test basic conditions and braking test prompt conditions with the braking test allowable conditions fed back by each BCU to form a complete judgment basis. The following provides a detailed description of this specific implementation method.

[0056] In one possible implementation, step S203 includes: The CCU summarizes the braking test allowable conditions reported by each BCU. Based on the braking test allowable conditions, combined with the preset pre-test basic conditions and various braking test prompt conditions, it determines whether the carriage corresponding to each BCU meets the test start requirements. Among them, the pre-test basic conditions include normal train power supply status and brake line pressure meeting the standard. The braking test prompt conditions are used to describe the pre-operational requirements and limitations required for the braking test.

[0057] The basic conditions before the test are the core prerequisites that the TCMS system pre-configures to ensure the effectiveness of the overall environment for the braking test. The basic conditions before the test include normal train power supply status (such as stable power supply to the traction system and dedicated power supply to the braking system) and qualified brake pipeline pressure (the pressure of the entire train's brake pipeline is within the preset safety threshold range).

[0058] Braking test prompts are standardized information that clarifies the prerequisites for braking tests and the current limitations to be avoided. For example, it may require confirmation that the train is stationary, prohibit starting the test under train traction conditions, or require the application of parking brakes.

[0059] After the CCU completes the parsing and verification of the feedback data from the first and second BCUs, it first extracts and summarizes the allowable braking test conditions fed back by the first and second BCUs to form the basic state dataset of the entire train's braking system. The allowable braking test conditions specifically include information such as the absence of faults in the braking actuators of the first and second cars, normal power supply to the braking system, and the readiness of the anti-skid system, ensuring coverage of the key state dimensions of the entire train's braking system.

[0060] Subsequently, the CCU invoked the pre-set test basic condition startup module of the TCMS system to check the overall power supply status of the train and the pressure of the entire train's brake lines. On one hand, the CCU interacted with the train power supply management module to confirm that there were no abnormal fluctuations in the traction power supply and the dedicated power supply for the braking system, meeting the stable power supply requirements for the test. On the other hand, the CCU summarized the brake line pressure data fed back by the first and second BCUs to determine whether the pressure of the entire train's main lines had reached the preset threshold, avoiding the impact of insufficient local line pressure on the test's effectiveness.

[0061] Simultaneously, the CCU retrieves preset braking test prompt conditions and verifies the pre-operation requirements and constraints of the current test scenario. For example, it determines whether the operator has completed pre-operation steps such as locking the train to a stationary position or issuing no traction command, and confirms that there are no constraints such as unsynchronized multiple-unit formations or unresolved braking system faults in the current operating condition. If any prompt conditions are not met, the CCU displays the specific requirements to the operator via the HMI to assist in completing the preparation work; if all prompt conditions are met, the final judgment is made based on the verification results of the BCU braking test allowable conditions and pre-test basic conditions summarized above.

[0062] The CCU will only determine that the test start requirements are met if the brake test allowable conditions, pre-test basic conditions, and brake test prompt conditions reported by each BCU are all met. Subsequently, the test execution command will be generated and issued according to the conventional process described above. If any one of the conditions is not met, it will be determined that the test start requirements are not met, the test start process will be terminated, and the specific non-compliance item will be prompted through the HMI.

[0063] In step S203, after the CCU determines that the test start requirements are met, it does not directly issue a test execution command. Instead, it can add an adaptive screening step for test items to ensure that the test items are accurately matched with the current braking state of the train. In this embodiment, the screening step is based on the number of applications of parking brake and holding brake, and formulates differentiated test item execution strategies. The following is a detailed description of this specific implementation method.

[0064] In one possible implementation, the method further includes, before issuing test execution instructions to each BCU: After the test start requirements are met, the CCU determines the number of parking brakes and holding brakes to be applied based on the train braking status data; The CCU selects the feasible braking tests based on the number of parking brakes and holding brakes applied. When the number of parking brake applications meets the brake test item screening rules, the test execution command is used to instruct the BCU to execute all test items; all test items include automatic braking test, emergency braking test, anti-skid system test, magnetic track braking test and main air duct leakage test; When the number of parking brake applications does not meet the brake test item screening rules but the number of brake applications still meets the brake test item screening rules, the test execution command is used to instruct the BCU to perform the anti-skid system test, magnetic track brake test and main air duct leakage test.

[0065] In this embodiment, the braking test item selection rule is a standardized judgment criterion based on the actual application states of the entire train's parking brake and holding brake to determine the scope of executable braking test items. The core logic of this rule is hierarchical matching, that is, the parking brake application state is given priority as the basis for the execution of all test items. When the parking brake does not meet the requirements, the holding brake application state is used as the basis for the execution of some test items. If neither is met, the test is prohibited from starting, thereby ensuring the safety of the test and the validity of the data.

[0066] The number of cars with parking brakes applied refers to the number of cars in the entire train formation that have completed the parking brake operation, or the proportion of cars with parking brakes applied to the total number of cars in the train. Parking brakes are a type of mechanical braking used to fix vehicles when the train is stationary. The number of cars with parking brakes applied directly determines whether the train has a stable test base condition and is a core indicator for determining whether automatic braking, emergency braking, and other tests with high requirements for vehicle fixation can be performed.

[0067] The number of cars with applied holding brakes refers to the number of cars in the entire train formation that have completed the holding brake operation, or the proportion of cars with applied holding brakes to the total number of cars in the train. Holding brakes are an auxiliary braking method that can temporarily stabilize the vehicle when the parking brake is not fully applied. The number of cars with applied holding brakes is a substitute indicator for determining whether to perform tests with lower requirements for vehicle fixation, such as the anti-skid system test, magnetic track brake test, and main air duct leakage test.

[0068] First, after confirming that the test start requirements are met, the CCU immediately extracts information related to the number of cars with applied parking brakes and the number of cars with applied holding brakes from the feedback data received from the first and second BCUs, forming a statistical result of the braking application status of the entire train. For example, it counts the number of cars with applied parking brakes and the number of cars with applied holding brakes, and then summarizes them to obtain the application ratio of the entire train.

[0069] Subsequently, the CCU invokes the preset braking test item screening rules to match and determine the braking application status of the entire train. If the statistical results show that the number of braking applications for the entire train meets the screening rules, it is determined that the current status can support the effective execution of all test items. At this time, the test execution instruction generated by the CCU clearly includes the execution parameters of five types of test items: automatic braking test, emergency braking test, anti-skid system test, magnetic track braking test, and main air duct leakage test, instructing the first BCU and the second BCU to execute all test items simultaneously.

[0070] If the statistical results show that the number of parking brake applications does not meet the screening rules, but the number of holding brake applications does, then it is determined that the current state can only support the execution of test items with lower requirements for vehicle fixation. In this case, the test execution instructions generated by the CCU only include the execution parameters for three types of test items: anti-skid system test, magnetic track brake test, and main air duct leakage test. The first BCU and the second BCU are instructed to execute only these test items. If the number of parking brake and holding brake applications does not meet the screening rules, the CCU will notify the operator via HMI that the brake application status is insufficient and the test cannot be started, terminating the subsequent instruction issuance process.

[0071] In this embodiment, adaptive filtering based on the number of brake applications achieves precise matching between test items and the actual train condition, avoiding the forced execution of demanding test items when the braking force is insufficient. This ensures the accuracy of the execution results and reduces the risk of equipment damage. Furthermore, the differentiated test item execution strategy improves the adaptability of the solution to different operating conditions. Even in scenarios where the braking is not fully applied but remains effective, the verification of key core test items can still be completed, ensuring the continuity of braking system testing and improving maintenance efficiency.

[0072] In step S203, after the CCU completes the screening of test items and determines the test items to be executed, a pre-verification step of releasing the holding brake can be added to avoid interference with the accuracy of the test data caused by the continuous application of the holding brake. In this embodiment, this step ensures that the holding brake is completely released before the test through the interaction logic of the CCU issuing a release command and the BCU feeding back a confirmation signal. The following is a detailed description of this specific implementation method.

[0073] In one possible implementation, before the CCU issues test execution instructions to each BCU, the method further includes: The CCU sends a release holding brake command to each BCU and waits for confirmation signals from each BCU that the holding brake has been released. If no confirmation signal is received from each BCU after a timeout, the CCU determines that the test preparation has failed, stops issuing test execution commands, and displays an error message through the HMI.

[0074] First, after the CCU completes the test item screening based on the number of parking brake and holding brake applications, it does not directly issue test execution commands. Instead, it first generates a holding brake release command for the holding brake state. This command explicitly requires the first BCU and the second BCU to complete the holding brake release operation within a preset time limit and simultaneously send back a confirmation signal. Subsequently, the CCU, through a stable communication link established with the BCU, synchronously sends the release command to the first and second BCUs, and simultaneously starts the local timing module to monitor the feedback time limit.

[0075] Upon receiving the command to release the holding brake, the first and second BCUs immediately initiate the local holding brake release procedure. They control the corresponding brake actuator to release the holding brake, and simultaneously detect the braking status via sensors. Once the holding brake is fully released, a confirmation signal indicating release is generated and fed back to the CCU in the format required by the command. If a release operation failure is detected, an exception signal indicating release failure is generated and fed back.

[0076] The CCU receives feedback signals in real time within a preset waiting time limit. If the first and second BCUs receive confirmation signals that the holding brake has been released on time, the pre-release stage is considered complete, and subsequent test execution instructions are generated and issued normally. If all confirmation signals are not received after the preset time limit, the test preparation is directly judged as a failure, the subsequent test execution instruction issuance process is immediately stopped, and the operator is accurately prompted with abnormal information through the HMI, such as the second carriage BCU not reporting confirmation of holding brake release or the first carriage's holding brake release failure, so that the operator can troubleshoot the fault in a timely manner.

[0077] When the test execution command targets a single braking test (such as performing an emergency braking test or an anti-skid system test alone), to avoid signal interference or data conflicts caused by the parallel execution of multiple test items, the CCU can add a test item locking and historical result reset mechanism. In the embodiments of this application, this mechanism runs through the entire process before, during, and after the start or interruption of a single test, ensuring the independence of the single test and the accuracy of the results. The following provides a detailed description of this specific implementation method.

[0078] In one possible implementation, when a test execution command is used to instruct the execution of a test item, the CCU locks other braking test items besides the braking test indicated by the test execution command; and resets the historical results of the test item before each test item is started; and when the braking test indicated by the test execution command ends or is interrupted, the other braking test items are unlocked and a new test item is selected.

[0079] First, after the CCU completes the pre-test verification for brake release and hold, it initiates the test item locking logic while generating the execution command for the individual braking test. Through the system's internal test item management module, it identifies the identifier of the currently pending individual test (such as the emergency braking test identifier) ​​and locks all other braking test items (such as automatic braking test, anti-skid system test, etc.). Once locked, operators cannot trigger the start command for other test items, and the system will not automatically schedule other test items, retaining only the execution permission for the currently pending individual test.

[0080] Subsequently, before formally issuing the test execution command, the CCU calls the execution result storage module to locate the historical result data of the current single test item to be executed (including the judgment results of the previous or multiple tests, status parameters during the process, and fault alarm records, etc.), and performs a reset operation. The historical result data is marked as invalid and the cache is cleared. Simultaneously, the real-time recording module for this test item is initialized to ensure that all data for this test is newly acquired and recorded, unaffected by historical results. After completing the locking and reset, the CCU then issues the single braking test execution command to the first BCU and the second BCU to start the test operation.

[0081] During the execution of a single braking test, the CCU continuously maintains the locked status of other test items and monitors the test execution status in real time. If the test ends normally, the CCU, after receiving and processing the final execution result fed back by the BCU, releases the lock on other test items, allowing the operator to reselect other test items for testing. If the test is interrupted due to fault, human operation, or other reasons, the CCU immediately triggers the lock release logic, records the reason for the interruption, and prompts it through the HMI. After the operator has investigated the problem, they can reselect the test item.

[0082] S204: The BCU responds to the test execution command and performs the braking test operation, and provides real-time feedback on the test process data and execution results.

[0083] In this embodiment, after receiving the test execution instruction from the CCU, the first BCU and the second BCU first parse the instruction, extracting the test item identifier, execution parameters, and data feedback requirements to ensure the understanding of the instruction and the control intent of the CCU. Figure 1 The command is then executed. Both BCUs simultaneously initiate braking test operations. If the command is to execute all test items, the corresponding braking actuators are driven sequentially according to the preset test order, such as automatic braking test first, then emergency braking test, and finally anti-skid system test. If the command is to execute a single test item, the operation is directly focused on the actuator corresponding to that item.

[0084] During the test operation, the first and second BCUs collect test data in real time through connected pressure sensors, displacement sensors, status sensors, and other devices. For example, during an emergency braking test, they collect data such as the time it takes for the brake cylinder pressure to rise from its initial value to its maximum value, the magnitude of the main duct pressure drop, and the number of times the anti-slip valve actuates; during a main duct leakage test, they collect data such as the leakage amount within a preset time period. Simultaneously, the BCUs package the real-time collected process data according to the required feedback frequency and transmit it point-to-point to the CCU via a communication link, ensuring that the CCU can monitor the test progress in real time.

[0085] Once a test item is completed, the BCU stops process data acquisition and generates an execution result based on preset local judgment criteria (such as whether the pressure reaches the threshold, whether the action is completed within the specified time, and whether there is a fault alarm). If it is an execution command for all test items, the execution results of each item are summarized after all items are completed to form the overall execution result of the entire train braking test. If it is a single test command, the execution result of that item is generated directly. Finally, the BCU feeds back the final execution result (including test completion status, fault codes, etc.) to the CCU, completing the response process for this test operation.

[0086] S205: The CCU controls the test process based on the feedback test process data and determines the braking function based on the execution results.

[0087] In this embodiment, after receiving the test process data from the first and second BCUs, the CCU immediately initiates the test process control procedure. On one hand, it uses a built-in timing module to monitor the execution time of the current test in real time, comparing the actual time with a preset timeout threshold. If the actual time exceeds the threshold, the test item is determined to have timed out, and a test interruption timeout control command is immediately generated. On the other hand, it continuously maintains a locked state on other test items until the current test is completed or interrupted, avoiding interference from parallel tests on the process data.

[0088] While controlling the test process, the CCU integrates and analyzes the execution results and overall process data fed back by the BCU. First, it extracts the core status information from the execution results and associates it with the corresponding process data. Then, it calls the system's preset global judgment criteria to verify the integrated data. For example, to determine whether an automatic braking test is qualified, three conditions must be met simultaneously: the brake cylinder pressure reaches a preset threshold, the pressure rise time does not exceed the upper limit, and there are no fault alarms. To determine whether a main duct leakage test is qualified, the pipeline pressure leakage must be lower than the standard value within a preset time.

[0089] If the data verification meets the global judgment criteria, the CCU determines that the corresponding braking function is valid. If the data verification does not meet the criteria, or if timeouts or fault alarms occur during the test, the corresponding braking function is determined to be invalid, and the specific reasons for the abnormality are recorded, such as the brake cylinder pressure not meeting the standard or the test execution timeout. For the execution scenarios of all test items, the CCU also needs to summarize the judgment results of each individual function to form an overall functional evaluation conclusion of the entire train braking system.

[0090] In step S205, the CCU's control over the test process and determination of braking functions can be achieved through multi-dimensional refined logic, covering the entire process of test duration monitoring, project lock maintenance, result determination, display priority control, and result storage feedback, further improving the comprehensiveness of test control and the standardization of result processing. The following is a detailed explanation of this specific implementation method.

[0091] In one possible implementation, the process data includes the test execution duration. The CCU manages the test process based on the process data and determines the braking function based on the execution results, specifically including: The CCU monitors the execution time of the test in real time. If the preset timeout threshold is exceeded, the test item corresponding to the process data is directly judged as a failure. Based on the preset braking test judgment criteria and the execution results fed back by each BCU, the CCU determines whether the test item corresponding to the execution result is successful or unsuccessful.

[0092] First, after receiving the test process data from the first and second BCUs, the CCU initiates real-time monitoring of the test execution time. A preset timeout threshold is matched to the currently executing test item, and the timing module continuously tracks the test execution time. If the actual duration exceeds the corresponding threshold, the test item is directly determined to have failed without waiting for the BCU to provide the execution result, and the reason for the timeout is recorded.

[0093] Meanwhile, if a single braking test is currently being performed, the CCU will maintain a locked state on other test items, prohibiting operators from triggering or the system from automatically scheduling other test items; only when the BCU receives a test end signal, or determines that the test has timed out or been interrupted, will the lock on other test items be released and the test item selection permission be restored.

[0094] After completing the test process control, the CCU initiates the braking function judgment process. The CCU retrieves the preset braking test judgment criteria and compares and verifies the test execution results fed back by each BCU with the data of the entire process one by one. For example, when verifying the emergency braking test, the following conditions must be met simultaneously: brake cylinder pressure ≥800kPa, pressure rise time ≤2s, and no abnormal alarm from the anti-skid system. If any condition is not met, the test is judged as a failure; if all conditions are met, the test is judged as a success.

[0095] In one possible implementation, the method further includes: The CCU sets the display status of the execution results according to the preset priority. If the execution results do not change, the original display status is maintained. The CCU displays the braking function determination results in real time through the HMI prompt window and stores them in the system database, supporting querying on the execution results interface.

[0096] After the determination is completed, the CCU sets the execution result display status according to the preset priority of Unknown > Success > Failure > In Trial. If the current determination result is consistent with the previous status, such as two consecutive determinations of success, the original display status is maintained; if the result changes, such as changing from In Trial to Failure, the display status is updated. Subsequently, the CCU displays the final determination result in real time through the HMI prompt window, and simultaneously writes the result to the system database, noting information such as the test time, test item, and involved BCU number to ensure data traceability. Operators can query historical test records through filtering conditions on the execution result interface.

[0097] This application further provides a system architecture for scenarios involving multiple train carriages coupled together, such as... Figure 3As shown, specifically, the TCMS system includes a CCU, a WTB gateway, and multiple BCUs. The test train includes multiple carriage groups, and each carriage group includes multiple carriages. The CCU corresponds one-to-one with the carriage group, and the BCU corresponds one-to-one with each carriage. Each CCU corresponds one-to-one with each BCU and carriage in its corresponding carriage group. The multiple CCUs are connected to each other via a twisted-wire train bus WTB gateway.

[0098] As the core interface for cross-train communication, the WTB gateway supports the CCU of this train group to establish a stable bus communication connection with the CCUs of other train groups through the WTB gateway. This enables the transmission of braking test-related commands, the exchange of status data, and the collaborative management and control of the test process among multiple train groups, adapting to the braking test requirements of double or multiple trains operating in parallel. Specifically, the CCU within a single train group establishes a direct communication connection with all BCUs in that train group, responsible for issuing local commands, collecting data, and providing status feedback for the braking test of that train group. The WTB gateway, corresponding one-to-one with each CCU, serves as a dedicated cross-train communication interface for that train group, building a communication bridge between the CCUs of this train group and the CCUs of other train groups. This allows the CCUs of each train group to achieve bidirectional data exchange and command transmission through their own WTB gateways, thereby constructing a collaborative control network in multi-train parallel operation scenarios and meeting the unified management and control requirements for braking tests of the entire train under parallel operation conditions.

[0099] In one possible implementation, each train group can also be configured with two CCUs (CCU1.1 and CCU1.2) and two WTB gateways (WTB gateway1.1 and WTB gateway1.2), forming a redundant combination of dual CCUs and dual WTB gateways. At the same time, the CCUs of each train group communicate directly with multiple BCUs of the same train group.

[0100] During coupling, the two train sets establish a communication connection through their respective WTB gateways. If a CCU or WTB gateway fails, another set of redundant equipment in that group can immediately take over the function, ensuring that the braking test control within a single train set is not interrupted, while also ensuring the stability of cross-group communication, thus improving the reliability and fault tolerance of the braking test system in multi-train coupling scenarios.

[0101] After multiple train sets complete mechanical coupling, the CCUs of each carriage set initiate communication connection requests through the onboard WTB gateway to complete network matching and communication link verification, establishing a master-slave communication architecture. The CCU of the activated carriage set acts as the master control CCU, and the CCUs of the remaining carriage sets act as slave control CCUs. After the communication link is established, each slave control CCU reports the number, distribution location, and initial status of its carriage set's BCUs to the master control CCU through the WTB gateway. The master control CCU then summarizes these reports to form the braking system topology information of the coupled carriage sets.

[0102] The master control CCU generates a unified format for querying braking test permitting conditions. On one hand, it directly issues the command to each BCU in the same car group. On the other hand, it forwards the command to all slave control CCUs through the WTB gateway. After receiving the command, each slave control CCU synchronously issues the query command to the BCU under its jurisdiction, realizing the unified scheduling of query commands for the coupled car group.

[0103] Each carriage group's BCU responds to the query command, collects and feeds back the braking test allowable conditions and train braking status data to the local CCU; each slave control CCU summarizes the feedback data from its own carriage group's BCU and then packages and transmits the data to the master control CCU through the WTB gateway; finally, the master control CCU integrates the feedback data from its own managed BCUs with the reported data from all slave control CCUs to form a complete status dataset for the coupled carriage group.

[0104] Based on the aggregated data of the entire train, the master control CCU combines the preset pre-test conditions and braking test prompts to determine the test start requirements. Then, it extracts the number of parking brakes and holding brakes applied to the coupled carriages, selects the executable test items according to the unified screening rules, determines the range of test items to be performed on the entire train, and synchronizes the judgment results and the project screening scheme to all slave control CCUs through the WTB gateway.

[0105] The master control CCU generates test execution instructions and sends them to each slave control CCU through the WTB gateway, instructing all carriage group BCUs to synchronously execute braking test operations. During the test, each carriage group's BCU collects test process data in real time and feeds it back to its local CCU. After the local CCU completes preliminary data processing, it uploads the data to the master control CCU through the WTB gateway. The master control CCU uniformly monitors the test execution time of the entire train and instructs each slave control CCU to maintain the locked state of non-current test items within its jurisdiction to avoid cross-train test conflicts.

[0106] After the test is completed, the BCU of each carriage group feeds back the test results to the local CCU. Each slave CCU summarizes the results of its carriage group and reports them to the master CCU through the WTB gateway. The master CCU integrates the test process data and execution results of the entire train and makes a unified judgment on the braking function of the coupled carriage groups according to the preset judgment criteria. The judgment results are synchronized to all slave CCUs through the WTB gateway, and the HMI of each carriage group displays the test details of its carriage group and the overall conclusion of the entire train. At the same time, the test data of the entire train is stored in the system database of the master CCU, supporting subsequent query and traceability.

[0107] Based on the above embodiments, this application also provides a train braking test control device without a TBM. The device is applied to a train control and management system, which includes a central control unit (CCU) and multiple train braking control units (BCUs). The multiple BCUs include at least a first BCU and a second BCU. The CCU is connected to the first BCU of a first car and the second BCU of a second car, respectively. Figure 4 As shown, the device includes: The sending module 401 is used to send a query instruction for the allowable conditions of braking test to each train braking control unit (BCU) corresponding to the CCU; wherein, the query instruction is used to instruct each BCU to feed back the allowable conditions of braking test and train braking status data to the CCU; The startup module 402 is used to determine whether the carriage corresponding to each BCU meets the test startup requirements based on the braking test allowable conditions fed back by each BCU and the train braking status data; and if the test startup requirements are met, to issue a test execution command to each BCU; wherein, the test execution command is used to instruct the BCU to perform the braking test operation and to provide real-time feedback of the test process data and execution results; The determination module 403 is used to control the process of the test based on the process data and to determine the braking function based on the execution result.

[0108] In one possible implementation, the startup module 402 is specifically used to summarize the braking test allowable conditions fed back by each BCU, and determine whether the carriage corresponding to each BCU meets the test startup requirements based on the braking test allowable conditions, combined with the preset pre-test basic conditions and various braking test prompt conditions; wherein, the pre-test basic conditions include normal train power supply status and brake pipeline pressure meeting the standard, and the braking test prompt conditions are used to describe the pre-operation requirements and restrictions required for the braking test.

[0109] In one possible implementation, the starting module 402 is further configured to determine the number of parking brakes and holding brakes applied based on the train braking status data after the test start requirements are met; Select feasible braking test items based on the number of parking brakes and holding brakes applied; When the number of parking brake applications meets the brake test item screening rules, the test execution command is used to instruct the BCU to execute all test items; the all test items include automatic braking test, emergency braking test, anti-skid system test, magnetic track braking test and main air duct leakage test; When the number of parking brake applications does not meet the selection rules for the braking test items but the number of brake applications still meets the selection rules for the braking test items, the test execution instruction is used to instruct the BCU to perform the anti-skid system test, the magnetic track brake test, and the main duct leakage test.

[0110] In one possible implementation, the start module 402 is further configured to send a release holding brake command to each of the BCUs and wait for each of the BCUs to send a confirmation signal that the holding brake has been released; If no confirmation signal indicating that the braking has been released is received from each of the BCUs within the time limit, the test preparation is deemed to have failed, the test execution command is stopped, and an abnormal message is displayed via HMI.

[0111] In one possible implementation, when the test execution command is used to instruct the performance of a test item, the startup module 402 is used to lock other braking test items besides the braking test indicated by the test execution command; and reset the historical results of the test item before each start of a test item; and when the braking test indicated by the test execution command ends or is interrupted, unlock the other braking test items and reselect the test item.

[0112] In one possible implementation, the process data includes the test execution time; the determination module 403 is specifically used to monitor the execution time of the test in real time, and if the timeout threshold is exceeded, the test item corresponding to the process data is directly determined to have failed; based on the preset braking test determination criteria and combined with the execution results fed back by each BCU, the test item corresponding to the execution result is determined to have succeeded or failed.

[0113] In one possible implementation, the device further includes a display module, which is used to set the display state of the execution result according to a preset priority, and to maintain the original display state if the execution result does not change; the braking function judgment result is displayed in real time through the HMI prompt window and stored in the system database, supporting querying on the execution result interface.

[0114] This application also provides a control device. The control device may include a memory and a processor. The processor is used to execute the train braking test control method without TBM described in any of the above embodiments. The memory may be random access memory (RAM), flash memory, read-only memory (ROM), non-volatile read-only memory (EPROM), registers, hard disk, removable disk, etc.

[0115] The memory can store computer instructions. When these instructions are executed by the processor, the processor can use them to implement control methods for train braking tests without a TBM. The memory can also store data.

[0116] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape) or a semiconductor medium (e.g., solid-state disk (SSD)).

[0117] This application also provides a readable storage medium for storing the methods provided in the above embodiments. For example, RAM, flash memory, ROM, EPROM, registers, hard disk, removable disk, or any other form of storage medium in the art.

[0118] In the embodiments of this application, the terms "first" and "second" (if they exist) are used only as name identifiers and do not represent the order of first and second.

[0119] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. Regarding the methods disclosed in the embodiments, since they correspond to the product embodiments disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the description of the product embodiments.

[0120] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A train braking test control method without TBM, characterized in that, The method includes: The central control unit (CCU) sends a query command to each train braking control unit (BCU) corresponding to the CCU regarding the permitted conditions for braking tests; wherein, the query command is used to instruct each BCU to provide feedback to the CCU on the permitted conditions for braking tests and train braking status data; The CCU determines whether the carriage corresponding to each BCU meets the test start requirements based on the braking test allowable conditions fed back by each BCU and the train braking status data; and if the test start requirements are met, it issues a test execution command to each BCU; wherein, the test execution command is used to instruct the BCU to perform the braking test operation and to provide real-time feedback on the test process data and execution results; The CCU controls the test process based on the process data and determines the braking function based on the execution results.

2. The method according to claim 1, characterized in that, The CCU determines whether the carriage corresponding to each BCU meets the test start requirements based on the braking test allowable conditions fed back by each BCU and the train braking status data, including: The CCU summarizes the braking test allowable conditions fed back by each BCU, and determines whether the carriage corresponding to each BCU meets the test start requirements based on the braking test allowable conditions, combined with the preset pre-test basic conditions and various braking test prompt conditions. Among them, the pre-test basic conditions include normal train power supply status and brake line pressure meeting the standard, and the braking test prompt conditions are used to describe the pre-operation requirements and restrictions required for the braking test.

3. The method according to claim 1, characterized in that, Before issuing test execution instructions to each of the BCUs, the method further includes: After the test start requirements are met, the CCU determines the number of parking brakes and holding brakes to be applied based on the train braking status data; The CCU selects the feasible braking test items based on the number of parking brakes and holding brakes applied; When the number of parking brake applications meets the brake test item screening rules, the test execution command is used to instruct the BCU to execute all test items; the all test items include automatic braking test, emergency braking test, anti-skid system test, magnetic track braking test and main air duct leakage test; When the number of parking brake applications does not meet the selection rules for the braking test items but the number of brake applications still meets the selection rules for the braking test items, the test execution instruction is used to instruct the BCU to perform the anti-skid system test, the magnetic track brake test, and the main duct leakage test.

4. The method according to claim 1, characterized in that, Before the CCU issues the test execution command to each of the BCUs, the method further includes: The CCU sends a release holding brake command to each of the BCUs and waits for each of the BCUs to send back a confirmation signal that the holding brake has been released; If no confirmation signal indicating that the braking has been released is received from each of the BCUs within the time limit, the CCU determines that the test preparation has failed, stops issuing the test execution command, and displays an abnormal message through the HMI.

5. The method according to claim 1, characterized in that, When the test execution command is used to instruct the performance of a test item, the CCU locks other braking test items besides the braking test indicated by the test execution command; and resets the historical results of the test item before each test item is started. When the braking test indicated by the test execution command ends or is interrupted, the other braking test items are unlocked and a new test item is selected.

6. The method according to claim 1, characterized in that, The process data includes the test execution duration; the CCU manages the test process based on the process data and determines the braking function based on the execution results, specifically including: The CCU monitors the execution time of the experiment in real time. If the timeout threshold is exceeded, the experiment corresponding to the process data is directly determined to have failed. The CCU determines whether the test item corresponding to the execution result is successful or unsuccessful based on the preset braking test judgment criteria and the execution results fed back by each BCU.

7. The method according to claim 1, characterized in that, The method further includes: The CCU sets the display status of the execution result according to a preset priority. If the execution result does not change, the original display status is maintained. The CCU displays the braking function determination result in real time through the HMI prompt window and stores it in the system database, supporting querying on the execution result interface.

8. The method according to claim 1, characterized in that, The test train includes multiple carriage groups, each carriage group includes multiple carriages, one CCU is set up in one-to-one correspondence with the carriage group, one carriage is set up in one-to-one correspondence with at least one BCU, one CCU is set up in one-to-one correspondence with the BCUs of each carriage in the corresponding carriage group, and the multiple CCUs are connected to each other through a twisted-wire train bus WTB gateway.

9. A train braking test control device without a TBM, characterized in that, The device includes: The sending module is used to send a query command for the allowable conditions of braking test to each train braking control unit (BCU) corresponding to the CCU; wherein, the query command is used to instruct each BCU to feed back the allowable conditions of braking test and train braking status data to the CCU; The startup module is used to determine whether the carriage corresponding to each BCU meets the test startup requirements based on the braking test allowable conditions fed back by each BCU and the train braking status data; and if the test startup requirements are met, to issue a test execution command to each BCU; wherein, the test execution command is used to instruct the BCU to perform the braking test operation and to provide real-time feedback of the test process data and execution results; The determination module is used to control the test process based on the process data and to determine the braking function based on the execution result.

10. A control device, characterized in that, It includes a processor and a memory, the memory being used to store programs, instructions, or code, and the processor being used to execute the programs, instructions, or code in the memory to complete the train braking test control method without TBM as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The system contains a computer program that is loaded by a processor to execute the train braking test control method without a TBM as described in any one of claims 1-8.

Images