A remote automated testing method for a rail transit safety platform

Abstract

The application discloses a kind of remote automation test methods for rail transit safety platform, comprising: step S1, pre-deploy test support base;Step S2, the collaborative communication link of test end and measured end is established;Step S3, the automatic cycle verification of single test case is executed;Step S4, the automatic iteration execution of full amount test case.The application can more efficiently and more accurately test and verify rail transit platform, improve the availability and reliability of rail transit embedded platform.

Description

Technical Field

[0001] This invention belongs to the field of urban rail transit signal control technology, specifically a remote automated testing method for rail transit safety platforms. Background Technology

[0002] The middleware of the rail transit safety platform is the core hub connecting various subsystems of rail transit (such as the computer interlocking subsystem, the automatic train protection subsystem, the automatic train driving subsystem, the mobile authorization subsystem, etc.) with upper-level applications. It undertakes common tasks such as data interaction, interface adaptation, security protection, and resource scheduling. Its operational stability, interface compatibility, and security reliability directly determine the overall operational efficiency of the rail transit safety platform and even affect the operational safety of rail transit. Therefore, extremely high requirements are placed on the testing and verification of the middleware, which must meet the relevant requirements of the Safety Integrity Level (SIL) specifications.

[0003] Currently, the testing of rail transit safety platform middleware mainly adopts localized manual testing or semi-automated testing modes, which have the following core defects: 1. Strong limitations of testing scenarios: Some traditional testing methods take business scenarios as the starting point, which have complex deployment environments, complex interactions between different subsystem nodes, extremely low testing efficiency, and difficulty in covering all actual operating scenarios. The testing cost is extremely high, and it is difficult to accurately target the test points of the security platform.

[0004] 2. The testing process is cumbersome and error-prone: The existing testing model requires manual configuration of the test environment, writing test cases, executing test steps, and recording test results. The testing process is highly repetitive. Furthermore, the rail transit safety middleware involves multiple types of interfaces (such as API interfaces and underlying driver interfaces) and multi-format data interaction. Manual operation is prone to configuration errors and data omissions, affecting the accuracy of the tests. 3. Poor compatibility and scalability: Middleware for different rail transit safety platforms may be developed based on different operating systems (such as embedded systems and general operating systems) and need to be adapted to the interface specifications of different subsystems. Existing test frameworks are mostly customized and cannot flexibly adapt to different types of middleware. They are also difficult to extend to new test scenarios (such as fault injection testing and high concurrency testing) and cannot meet the test requirements after the middleware is iterated and upgraded.

[0005] 4. Test data is difficult to trace and analyze: In manual testing mode, test cases, test logs, and test results are stored in a scattered manner, making it impossible to achieve unified management of data throughout the entire testing process. In subsequent troubleshooting, test optimization, and compliance auditing, it is difficult to quickly trace the testing process and cannot provide complete data support for the security and reliability verification of middleware.

[0006] 5. Extremely long testing cycle: For rail transit operations, stable operation is required for extended periods, potentially months or even years, necessitating extremely high stability requirements. Therefore, stability verification of the safety platform involves numerous and time-consuming scenarios. Existing testing methods are time-consuming and labor-intensive, making it difficult to fully verify the system within a rapid iteration cycle.

[0007] While existing technologies include general software automation testing frameworks and middleware testing technologies—such as some patents disclosing middleware systems applied to rail transit signal safety systems or general automation testing frameworks—none of them have designed dedicated testing frameworks for the specific characteristics of rail transit safety platform middleware (high security, high reliability, multi-scenario adaptation, and remote deployment). These frameworks fail to address the problems of low efficiency, poor accuracy, weak compatibility, high security risks, and lack of data traceability that exist in the testing process of rail transit safety platform middleware. Therefore, there is an urgent need for a remote automated testing method for rail transit safety platform middleware that can achieve remote control, automated execution, multi-scenario adaptation, security controllability, and data traceability, filling the gap in existing technologies. Summary of the Invention

[0008] To address the aforementioned problems in existing technologies, this invention provides a remote automated testing method for rail transit safety platforms, which can replace the current traditional inefficient integration testing. This method can test and verify rail transit platforms more efficiently and accurately, thereby improving the availability and reliability of embedded rail transit platforms.

[0009] The technical solution to achieve the above objectives is: A remote automated testing method for rail transit safety platforms includes: Step S1, Pre-deploy test support infrastructure: Register operation and query API interfaces that can be remotely called by the host computer in the underlying operating system of the rail transit safety platform under test, configure the test case function thread group under the multi-core redundant architecture of the under-test terminal, and complete the initialization of hardware link and software environment; Step S2: Establish a collaborative communication link between the test end and the test end: Start the rail transit safety platform under test and load the test case program. The host computer test end establishes a bidirectional communication connection with the platform under test through Ethernet and serial port to complete the communication status verification and operation synchronization. Step S3: Perform automated cycle verification of a single test case: The host computer sends test data to the platform under test according to a preset cycle. The platform under test completes data flow, redundancy voting and result feedback through the test case function thread group. The host computer verifies the feedback results in real time and continues to run until all verification cycles of the current test case are completed. Step S4, Automatic Iterative Execution of All Test Cases: The host computer collects the running status and test data status of the platform under test in real time through the multi-threaded monitoring module. When the current test case is completed or an abnormal interruption occurs, it automatically calls the underlying API to complete the reset of the platform under test, update the test configuration, and switch to the next test case for execution until all test cases are verified.

[0010] Preferably, step S1 specifically includes: Step S11: In the operating system of the board of the rail transit safety platform under test, pre-implement command functions for platform restart, configuration modification, status query and log export, register all API interfaces to the platform software Shell, and set call permission verification rules; Step S12: For the multi-core redundant architecture of the security platform under test, the functional thread group of each test case is set into three categories: forwarder thread, producer thread, and consumer thread. Among them, the forwarder thread is used to receive test data from the host computer and pass it into the middleware message queue, the producer thread is used to receive message queue data and generate a safe output message to be voted, and the consumer thread is used to receive the output message after redundant voting and send it back to the host computer.

[0011] Preferably, in step S1, the hardware link initialization specifically includes: The tested end is a rail transit safety platform subframe system equipped with multiple embedded redundant boards, and the test end is a host computer device. The two establish a bidirectional network connection through an Ethernet switch, and the host computer accesses each redundant board unit through a serial port channel.

[0012] Preferably, step S2 specifically includes: Step S21: Turn on the power of the embedded board of the security platform under test, execute the platform startup command, load the security platform middleware software, and after completing the system self-test, read the test case application and enter the periodic running state. In step S22, the host computer test terminal initiates a communication handshake request and performs message interaction verification with the platform under test through the network channel and serial port channel respectively. After confirming that the communication link is connected, both parties synchronize the test cycle benchmark, and the platform under test enters the test state.

[0013] Preferably, step S3 specifically includes: Step S31: The host computer sends test application data to the forwarder thread of the security platform under test according to the synchronized test cycle. Step S32: The platform under test processes data according to the periodic scheduling logic. In the nth cycle, the forwarder thread receives the test data and passes it into the middleware distribution message queue. In the (n+1)th cycle, the producer thread of each redundant unit receives the message and generates a security output message to be voted and passes it into the voting message queue. After the middleware completes the voting of the multi-redundant unit messages, in the (n+2)th cycle, the consumer thread receives the voted security output message and sends it back to the host computer. Step S33: After receiving the returned data, the host computer performs a consistency check with the expected result. After the check passes, it enters the next test cycle loop and continues to execute the test for the current test case for hundreds of thousands to millions of cycle verifications to achieve the dynamic balance test requirements.

[0014] Preferably, in step S4, the multi-threaded monitoring module of the host computer includes a serial port monitoring thread, a network monitoring thread, a data monitoring thread, and a liveness status monitoring thread, which respectively collect the serial port communication status, network connectivity status, test data verification results, and operating system running status of the platform under test in real time.

[0015] Preferably, step S4 specifically includes: Step S41: When the multi-threaded monitoring module detects that the current test case has completed all verification cycles, the host computer remotely calls the API interface to restart the board under test, update the test configuration file and test case application, and automatically start the verification process of the next test case. Step S42: When the multi-threaded monitoring module detects that the platform under test is running abnormally or the test data verification fails, it immediately stops the current test, retains the on-site operation log and error data, records the cause of the failure, remotely calls the API interface to reset the platform under test, and automatically switches to the next test case for execution. Step S43: Repeat the above steps until all preset test cases have been verified. The host computer will automatically generate a full-process traceable test report containing test case execution results, exception records, and data statistics.

[0016] Compared with the prior art, the beneficial effects of the present invention are: This invention employs remote control technology, which shortens the testing cycle by more than 70%, significantly reduces manual workload, lowers labor costs, and improves testing accuracy. This invention adopts a modular and configurable design, supports different hardware architectures and operating systems, and can quickly adjust test parameters, making it far more versatile than existing technologies. This invention integrates modules such as boundary testing and anomaly injection to simulate various complex operating scenarios, achieving a test coverage of over 95%, accurately locating potential hazards, and reducing the actual failure rate. This invention collects and analyzes test data in real time, generates traceable reports, and automatically optimizes test cases through machine learning, realizing a closed loop of "test-analysis-optimization" to adapt to platform iteration requirements; This invention achieves a high degree of synchronization between the host computer and the target computer, controls the test command response time to the millisecond level, supports real-time monitoring of test anomalies and interruptions, and provides more realistic and effective test results, meeting the platform's high real-time requirements. Attached Figure Description

[0017] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of a remote automated testing method for a rail transit safety platform according to the present invention; Figure 2 This is a flowchart of step S1 in this invention; Figure 3 This is a flowchart of step S2 in this invention; Figure 4 This is a flowchart of step S3 in this invention; Figure 5 This is a flowchart of step S4 in this invention; Figure 6 This is a hardware structure diagram of the automated testing system for rail transit platforms in this invention; Figure 7 This is the message flow diagram of a single test case in step S12 of the present invention; Figure 8 This is a timing diagram of a message stream in step S32 of the present invention; Figure 9 This is a flowchart of the automation logic for step S4 of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some 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 are within the scope of protection of the present invention.

[0019] like Figure 1 As shown, a remote automated testing method for a rail transit safety platform includes: Step S1, Pre-deployment of test support infrastructure: Register operation and query API interfaces that can be remotely called by the host computer in the underlying operating system of the rail transit safety platform under test, configure the test case function thread group under the multi-core redundant architecture of the under-test terminal, and complete the initialization of hardware link and software environment.

[0020] In this embodiment, the hardware link initialization specifically involves: The tested end is a rail transit safety platform subframe system equipped with multiple embedded redundant boards, and the testing end is a host computer device. The two are connected bidirectionally via an Ethernet switch. The host computer accesses each redundant board unit through a serial port channel, such as... Figure 6 As shown.

[0021] like Figure 2 As shown, step S1 specifically includes: Step S11: In the operating system of the board of the rail transit safety platform under test, pre-implement command functions for platform restart, configuration modification, status query and log export, register all API interfaces to the platform software Shell, and set call permission verification rules; Step S12: For the multi-core redundant architecture of the security platform under test, the functional thread group of each test case is set into three categories: forwarder thread, producer thread, and consumer thread. The forwarder thread receives test data from the host computer and passes it to the middleware message queue; the producer thread receives data from the message queue and generates a safe output message to be voted on; and the consumer thread receives the output message after redundant voting and sends it back to the host computer. Figure 7 As shown, specifically, the forwarder, a forwarder thread of a certain redundant unit receives application data from the host computer, processes it, and then passes it to the message queue of the distribution function. The middleware software distributes it to multiple redundant units, and each redundant unit performs logical processing. The producer, a producer thread of each redundant unit receives application messages from the message queue of the distribution function, produces safe output messages that require voting based on the received messages, and then passes them to the voting message queue. The middleware software votes on the messages from multiple redundant units and then outputs them uniformly. The consumer, a consumer thread of each redundant unit receives safe output messages from the voting message queue, processes the messages, and then sends them back to the host computer for verification.

[0022] Step S2: Establish a collaborative communication link between the test end and the test end: Start the rail transit safety platform under test and load the test case program. The host computer test end establishes a bidirectional communication connection with the platform under test through Ethernet and serial port to complete the communication status verification and operation synchronization.

[0023] like Figure 3 As shown, step S2 specifically includes: Step S21: Turn on the power of the embedded board of the security platform under test, execute the platform startup command, load the security platform middleware software, and after completing the system self-test, read the test case application and enter the periodic running state. In step S22, the host computer test terminal initiates a communication handshake request and performs message interaction verification with the platform under test through the network channel and serial port channel respectively. After confirming that the communication link is connected, both parties synchronize the test cycle benchmark, and the platform under test enters the test-ready state. The precision of the synchronized test cycle benchmark is controlled at the millisecond level to ensure that the periodic scheduling logic of the platform under test is consistent with the timing of the host computer test command sending logic.

[0024] Step S3: Perform automated cycle verification for a single test case: The host computer sends test data to the platform under test according to a preset cycle. The platform under test completes data flow, redundant voting, and result feedback through the test case function thread group. The host computer verifies the feedback results in real time and continues to run until all verification cycles of the current test case are completed.

[0025] like Figure 4 As shown, step S3 specifically includes: Step S31: The host computer sends test application data to the forwarder thread of the security platform under test according to the synchronized test cycle. Step S32: The platform under test processes data according to the periodic scheduling logic. like Figure 8 As shown, in the nth cycle: the forwarder thread receives test data and passes it to the middleware distribution message queue; In the (n+1)th cycle: the producer thread of each redundant unit receives the message and generates a safe output message to be voted and puts it into the voting message queue. The middleware completes the voting of messages from multiple redundant units. In the (n+2)th cycle: the consumer thread receives the safe output message after voting and sends it back to the host computer; Step S33: After receiving the returned data, the host computer performs a consistency check with the expected result. After the check passes, it enters the next test cycle loop and continues to execute the test for the current test case for hundreds of thousands to millions of cycle verifications to achieve the dynamic balance test requirements.

[0026] Step S4, Automatic Iterative Execution of All Test Cases: The host computer collects the running status and test data status of the platform under test in real time through the multi-threaded monitoring module. When the current test case is completed or an abnormal interruption occurs, it automatically calls the underlying API to complete the reset of the platform under test, update the test configuration, and switch to the next test case for execution until all test cases are verified.

[0027] In this embodiment, the multi-threaded monitoring module of the host computer includes a serial port monitoring thread, a network monitoring thread, a data monitoring thread, and a liveness status monitoring thread, which respectively collect the serial port communication status, network connectivity status, test data verification results, and operating system running status of the platform under test in real time.

[0028] like Figure 5 ,9 As shown, step S4 specifically includes: Step S41: When the multi-threaded monitoring module detects that the current test case has completed all verification cycles, the host computer remotely calls the API interface to restart the board under test, update the test configuration file and test case application, and automatically start the verification process of the next test case. Step S42: When the multi-threaded monitoring module detects that the platform under test is running abnormally or the test data verification fails, it immediately stops the current test, retains the on-site operation log and error data, records the cause of the failure, remotely calls the API interface to reset the platform under test, and automatically switches to the next test case for execution. Step S43: Repeat the above steps until all preset test cases have been verified. The host computer will automatically generate a full-process traceable test report containing test case execution results, exception records, and data statistics.

[0029] This invention achieves automation and intelligence in the testing of rail transit safety platforms through remote automated testing methods, improving testing efficiency and accuracy, and ensuring the reliability and safety of rail transit safety platforms.

[0030] Finally, it should be noted that the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A remote automated testing method for rail transit safety platforms, characterized in that, include: Step S1, Pre-deploy test support infrastructure: Register operation and query API interfaces that can be remotely called by the host computer in the underlying operating system of the rail transit safety platform under test, configure the test case function thread group under the multi-core redundant architecture of the under-test terminal, and complete the initialization of hardware link and software environment; Step S2: Establish a collaborative communication link between the test end and the test end: Start the rail transit safety platform under test and load the test case program. The host computer test end establishes a bidirectional communication connection with the platform under test through Ethernet and serial port to complete the communication status verification and operation synchronization. Step S3: Perform automated cycle verification of a single test case: The host computer sends test data to the platform under test according to a preset cycle. The platform under test completes data flow, redundancy voting and result feedback through the test case function thread group. The host computer verifies the feedback results in real time and continues to run until all verification cycles of the current test case are completed. Step S4, Automatic Iterative Execution of All Test Cases: The host computer collects the running status and test data status of the platform under test in real time through the multi-threaded monitoring module. When the current test case is completed or an abnormal interruption occurs, it automatically calls the underlying API to complete the reset of the platform under test, update the test configuration, and switch to the next test case for execution until all test cases are verified.

2. The remote automated testing method for a rail transit safety platform according to claim 1, characterized in that, Step S1 specifically includes: Step S11: In the operating system of the board of the rail transit safety platform under test, pre-implement command functions for platform restart, configuration modification, status query and log export, register all API interfaces to the platform software Shell, and set call permission verification rules; Step S12: For the multi-core redundant architecture of the security platform under test, the functional thread group of each test case is set into three categories: forwarder thread, producer thread, and consumer thread. Among them, the forwarder thread is used to receive test data from the host computer and pass it into the middleware message queue, the producer thread is used to receive message queue data and generate a safe output message to be voted, and the consumer thread is used to receive the output message after redundant voting and send it back to the host computer.

3. The remote automated testing method for a rail transit safety platform according to claim 1, characterized in that, In step S1, the hardware link initialization specifically involves: The tested end is a rail transit safety platform subframe system equipped with multiple embedded redundant boards, and the test end is a host computer device. The two establish a bidirectional network connection through an Ethernet switch, and the host computer accesses each redundant board unit through a serial port channel.

4. The remote automated testing method for a rail transit safety platform according to claim 1, characterized in that, Step S2 specifically includes: Step S21: Turn on the power of the embedded board of the security platform under test, execute the platform startup command, load the security platform middleware software, and after completing the system self-test, read the test case application and enter the periodic running state. In step S22, the host computer test terminal initiates a communication handshake request and performs message interaction verification with the platform under test through the network channel and serial port channel respectively. After confirming that the communication link is connected, both parties synchronize the test cycle benchmark, and the platform under test enters the test state.

5. The remote automated testing method for a rail transit safety platform according to claim 1, characterized in that, Step S3 specifically includes: Step S31: The host computer sends test application data to the forwarder thread of the security platform under test according to the synchronized test cycle. Step S32: The platform under test processes data according to the periodic scheduling logic. In the nth cycle, the forwarder thread receives the test data and passes it into the middleware distribution message queue. In the (n+1)th cycle, the producer thread of each redundant unit receives the message and generates a security output message to be voted and passes it into the voting message queue. After the middleware completes the voting of the multi-redundant unit messages, in the (n+2)th cycle, the consumer thread receives the voted security output message and sends it back to the host computer. Step S33: After receiving the returned data, the host computer performs a consistency check with the expected result. After the check passes, it enters the next test cycle loop and continues to execute the test for the current test case for hundreds of thousands to millions of cycle verifications to achieve the dynamic balance test requirements.

6. The remote automated testing method for a rail transit safety platform according to claim 1, characterized in that, In step S4, the multi-threaded monitoring module of the host computer includes a serial port monitoring thread, a network monitoring thread, a data monitoring thread, and a survival status monitoring thread, which respectively collect the serial port communication status, network connectivity status, test data verification results, and operating system running status of the platform under test in real time.

7. A remote automated testing method for a rail transit safety platform according to claim 6, characterized in that, Step S4 specifically includes: Step S41: When the multi-threaded monitoring module detects that the current test case has completed all verification cycles, the host computer remotely calls the API interface to restart the board under test, update the test configuration file and test case application, and automatically start the verification process of the next test case. Step S42: When the multi-threaded monitoring module detects that the platform under test is running abnormally or the test data verification fails, it immediately stops the current test, retains the on-site operation log and error data, records the cause of the failure, remotely calls the API interface to reset the platform under test, and automatically switches to the next test case for execution. Step S43: Repeat the above steps until all preset test cases have been verified. The host computer will automatically generate a full-process traceable test report containing test case execution results, exception records, and data statistics.

Images