An automated test system for TACS system

By designing an automated test system for TACS system and writing automated test scripts using TestStand, the problem of lack of an automated test platform in the existing technology is solved, and efficient and safe testing and verification of TACS system is achieved.

CN114706747BActive Publication Date: 2025-03-25CASCO SIGNAL LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202210183818.6
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-02-28
Publication Date
2025-03-25
Estimated Expiration
2042-02-28

AI Technical Summary

Technical Problem

The existing technology lacks an automated test platform in the testing and verification of TACS systems, resulting in cumbersome testing process, high safety risks, and a reliable integrated verification environment.

Method used

An automated test system for TACS system was designed, and automated test scripts were written using NI's TestStand test management software, and a target test environment or host test environment was built in combination with real devices or simulated subsystems.

Benefits of technology

It realizes automated testing of the TACS system, improves testing efficiency and accuracy, reduces manpower and material investment and safety risks, and provides flexible testing environment selection.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114706747B_ABST
    Figure CN114706747B_ABST
Patent Text Reader

Abstract

The present invention relates to an automated test system for a TACS system, comprising a tested signal system and a test platform connected to each other, wherein the software part of the test platform uses NI's TestStand test management software to write automated test scripts, and the hardware part of the test platform is connected to the tested signal system to form an automated test environment, which can use all real devices to build a set of real target test environments, or use a simulation subsystem to build a set of virtual host test environments. Compared with the prior art, the present invention has the advantages of strong flexibility, automated testing, strong versatility, etc.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The invention relates to a rail transit signal system, and in particular to an automatic testing system for a TACS system. Background Art

[0002] With the vigorous development of my country's urban rail transit industry, the CBTC signal system has matured in China and has been put into practical use in many cities. The CBTC signal system is a communication-based train control system. Its signal system's trackside resource management and train interval protection are centered on ground equipment. The ground equipment interacts with the on-board equipment through vehicle-to-ground communication to ensure the safe operation of the train.

[0003] In recent years, the train control system TACS based on vehicle-to-vehicle communication has become the development direction of the next generation of train control signal systems. The full name of TACS is Train Autonomous Circumambulate System. It takes on-board control as the core. The on-board equipment communicates directly with adjacent trains, obtains the location information of adjacent trains and performs mobile authorization calculations to control the safe and efficient operation of trains. In order to ensure the smooth opening and safe and stable operation of the TACS system, it is necessary to build an integrated test environment indoors to fully test and verify the TACS signal system. At present, the domestic vehicle-to-vehicle communication signal system is still in its infancy, and there is no relatively mature integrated test environment. There is also relatively little research on the automated test platform of the TACS signal system.

[0004] At present, the test and verification of the domestic TACS signal system is mainly carried out in the following ways:

[0005] 1) On-site debugging: This type of on-site debugging will waste a lot of manpower and material resources, and there are great safety hazards. The purpose of the signal system laboratory verification is to reduce the construction pressure on site and eliminate the safety hazards of on-site construction. If there is no reliable integrated verification environment indoors, all tests will be carried out on site. On the one hand, it will delay the progress of on-site construction, and on the other hand, it will also have great safety hazards. Generally, only a few scenarios that do not have the testing conditions in the laboratory will be put on site for verification. Putting all on-site verification will have great disadvantages.

[0006] 2) Indoor integrated test environment, but without automated testing function. Due to the increasing number of use cases and the tight opening time, the current subway signal system testing usually requires several rounds of regression testing indoors before opening. Automated testing can greatly facilitate the execution of regression testing and reduce the probability of errors. Therefore, automated testing of subway signal systems is also the main research direction of many manufacturers. Summary of the invention

[0007] The purpose of the present invention is to provide an automated testing system for a TACS system in order to overcome the defects of the prior art.

[0008] The purpose of the present invention can be achieved by the following technical solutions:

[0009] According to one aspect of the present invention, there is provided an automated testing system for a TACS system, comprising a tested signal system and a testing platform that are interconnected. The software portion of the testing platform uses NI's TestStand test management software to write automated testing scripts. The hardware portion of the testing platform is connected to the tested signal system to form an automated testing environment. The automated testing environment can use all real devices to build a real target testing environment, or use a simulation subsystem to build a virtual host testing environment.

[0010] As a preferred technical solution, if a target test environment is adopted, the signal system under test includes an on-board controller CC, an automatic train monitoring system ATS, a trackside resource manager WRC, a trackside vehicle manager WTC and an interlocking target controller OC; the test platform includes a programmable power supply, an IO module, a speed sensor and beacon simulation module, a PXI controller and a switch, wherein the switch includes a three-layer switch and a two-layer switch.

[0011] As a preferred technical solution, the on-board controller CC serves as the signal subsystem under test and is connected to the remaining signal subsystems through a three-layer switch at the signal layer; at the test platform layer, the on-board controller CC is connected to the programmable power supply, IO module, speed transmission and beacon simulation module through hard wires, and the PXI controller is connected to the on-board controller CC through the omap network to obtain the omap information of the on-board subsystem. The PXI controller is connected to the on-board controller CC through the TCMS network to interact with the on-board subsystem for TCMS information.

[0012] As a preferred technical solution, the automatic train monitoring system ATS is the signal subsystem under test, responsible for supervising and controlling the operation of the train, and has the functions of train tracking operation, alarm, operation adjustment, and operation control; during the actual operation, ATS sends the train operation plan, manual adjustment information, etc. to the on-board controller CC.

[0013] As a preferred technical solution, the trackside resource manager WRC, as the signal subsystem under test, is responsible for the allocation and recovery of trackside resources, train sequence management, operation adjustment and operation control functions; at the same time, the trackside resource manager WRC also sends driving commands of trackside equipment to the target controller OC, and collects the status of trackside equipment sent by the target controller OC.

[0014] As a preferred technical solution, the trackside vehicle manager WTC is used as a signal subsystem under test. On the one hand, it is used by the running car in the train backup mode, and on the other hand, it handles the temporary speed limit function of the train.

[0015] As a preferred technical solution, the interlocking target controller OC serves as the signal subsystem under test and is responsible for the driving and status acquisition functions of the trackside equipment. The interlocking target controller OC receives control commands from the trackside resource manager WRC to drive the trackside resources and sends the status of these trackside resources to the WRC.

[0016] As a preferred technical solution, the three-layer switch is used to replace the DCS module in the actual signal system. A mirror port needs to be configured on the three-layer switch, and all other ports are mirrored to the port, and the information interaction between all the measured signal subsystems is obtained through the mirror port;

[0017] The mirror port is connected to the PXI controller via a network, and an automated test script is written on the PXI controller to obtain messages between various signal subsystems, thereby achieving the purpose of automated testing.

[0018] As a preferred technical solution, the input of the programmable power supply is AC power, and the output is a multi-channel 110V DC power supply. Its function is to provide power for the vehicle controller CC. It is connected to the PXI controller through a network cable through a two-layer switch. An automated script is written on the PXI controller to control the power on and off of the vehicle controller CC, thereby achieving the purpose of automated testing.

[0019] As a preferred technical solution, the IO module is used to simulate the input and output code bits between the vehicle and the on-board controller. It is connected to the on-board controller CC and the PXI controller respectively through hard wires. A digital IO board is installed on the PXI controller. By writing an automated test script on the PXI controller, the output code bits of the on-board controller CC are collected and the input code bits of the on-board controller CC are controlled, thereby achieving the purpose of automated testing.

[0020] As a preferred technical solution, the speed sensor and beacon simulation module is used to simulate the signals of the speed sensor and beacon, and is connected to the on-board controller CC and the PXI controller respectively through hard wires. An automated test script is written on the PXI controller to simulate the operation of the train. The script sends the train control command to the speed sensor and beacon simulation module through the network. The speed sensor and beacon simulation module is used to simulate the speed sensor and beacon waveforms during the operation of the train and send them to the on-board controller, thereby achieving the purpose of automated testing.

[0021] As a preferred technical solution, the two-layer switch is used to connect the programmable power supply, speed sensor and beacon simulation module to the PXI controller through a test network, and the programmable power supply module, speed sensor and beacon simulation module are controlled by writing an automated script on the PXI controller.

[0022] As a preferred technical solution, the PXI controller is installed with NI's TestStand test management software, and APIs are written in various programming languages ​​to control the programmable power supply, IO modules, speed transmission and beacon simulation modules, interact with TCMS, interact with Omap, and interact with wireshark, and these APIs are called through TestStand to create test sequences, thereby achieving the purpose of automated testing.

[0023] As an optimal technical solution, if a host test environment is adopted, the signal system under test includes the on-board controller CC Sim, the automatic train monitoring system ATS Sim, the trackside resource manager WRC Sim, the trackside vehicle manager WTC Sim and the interlocking target controller OC Sim; the test platform includes a PC or a server, and a three-layer switch.

[0024] As a preferred technical solution, the on-board controller CC Sim, automatic train monitoring system ATS Sim, trackside resource manager WRC Sim, trackside vehicle manager WTC Sim and interlocking target controller OC Sim are all simulators running on a PC, and their functions are the same as those of real devices.

[0025] Compared with the prior art, the present invention has the following advantages:

[0026] 1. High flexibility. The test system of the present invention can use all real equipment to build the Target test environment according to different test requirements, or it can use all simulated systems to build the host test environment. The Target environment requires relatively more hardware equipment and has a relatively high cost, but it is more consistent with the on-site environment and is mainly used for tests related to function confirmation. The Host test environment only requires a few PCs and switches to complete the construction of the entire test environment, which takes a short time and has low cost. However, since the signal systems are all simulated, it is suitable for interface integration testing between subsystems.

[0027] 2. Automated testing. The test system of the present invention uses NI's TestStand as automated test management software. The biggest advantage of TestStand is that it can call APIs developed in different mainstream programming languages ​​to form automated test scripts, and its steps are divided into many types. Some steps only perform a certain action, and some steps can set expected values ​​or upper and lower limits, and compare the actual test value with the set value to judge the test result. Different developers can use their familiar programming languages ​​to develop different functional module APIs, and finally call these APIs through TestStand to form automated test scripts. And using this system, test cases and test scripts can be matched, each case corresponds to an automated script, and the steps in the script and the case steps can also be matched one by one, which greatly facilitates the maintenance of test cases and test scripts. At the same time, TestStand can automatically generate test reports in different formats, and the test report will record in detail the tester, test time, and detailed execution of each step.

[0028] 3. Strong versatility. The present invention provides a universal automated testing system for TACS systems. Different signal system manufacturers may have different vehicle-to-vehicle communication solutions, but the test platform architecture in the present invention is universal. Any signal system will have information interactions between different subsystems. The use of a three-layer switch mirror port can capture information between all these subsystems. The on-board controller of any signal system will also have a data recording software similar to omap, and the information of the on-board controller can be captured by interacting with omap. At the same time, different signal system manufacturers can use their own programming languages ​​to develop universal APIs, and then generate their own automated test scripts through TestStand calls. Compared with other methods, the present invention has the advantages of greater scalability and versatility. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 It is a schematic diagram of the structure of the Target automated testing environment of the present invention;

[0030] Figure 2 It is a schematic diagram of the structure of the Host automated testing environment of the present invention;

[0031] Figure 3 The figure is a flow chart of the automated test script of the present invention. DETAILED DESCRIPTION

[0032] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0033] The present invention proposes an automated test system for a TACS system, which is mainly divided into two parts: a signal system to be tested and a test platform. The signal system to be tested mainly includes several parts such as a vehicle controller CC, an automatic train monitoring system ATS, a trackside resource manager WRC, a trackside vehicle manager WTC and an interlocking target controller OC; the test platform hardware mainly includes a programmable power supply, an IO module, a speed sensor and a beacon simulation module, a high-performance PXI controller, a switch, etc.; the test platform software mainly uses NI's TestStand test management software to write automated test scripts. This test system can use all real equipment to build a real target test environment, and can also use a simulation subsystem to build a virtual host test environment.

[0034] as follows Figure 1 The figure shows a real target test environment. The present invention can be implemented by the following technical solutions:

[0035] 1) An automated test method and test system for a TACS system, mainly divided into two parts: a signal system under test and a test platform. The signal system under test mainly includes a vehicle controller CC, an automatic train monitoring system ATS, a trackside resource manager WRC, a trackside vehicle manager WTC, and an interlocking target controller OC; the test platform hardware mainly includes a programmable power supply, an IO module, a speed sensor and a beacon simulation module, a high-performance PXI controller, a switch, etc.; the test platform software mainly uses NI's TestStand test management software to write automated test scripts.

[0036] 2) The onboard controller CC is the signal subsystem under test. It mainly performs path planning based on the operation tasks sent by ATS, and applies for the required trackside resources from the trackside resource managers WRC and WTC. When the onboard subsystem obtains the allocated trackside resources, it autonomously controls the train operation. When the train no longer needs these resources, it actively initiates an application to release the resources. Each onboard controller will communicate with the adjacent onboard controller to obtain the location and operation range information of the adjacent train, and actively calculate the mobile authorization required for operation. The onboard controller is connected to the other signal subsystems through a three-layer switch at the signal layer. At the test platform layer, the onboard controller is connected to the programmable power supply, IO module, speed transmission and beacon simulation module through hard wires. The PXI controller is connected to the onboard controller through the omap network to obtain the omap information of the onboard subsystem. The PXI controller is connected to the onboard controller through the TCMS network to interact with the onboard subsystem for TCMS information.

[0037] 3) The automatic train monitoring system ATS is the signal subsystem under test. The ATS subsystem is mainly responsible for supervising and controlling the operation of the train, and has functions such as train tracking operation, alarm, operation adjustment, and operation control. During the actual operation process, ATS will send the train operation plan, manual adjustment information, etc. to the on-board controller CC.

[0038] 4) Trackside Resource Manager WRC is the signal subsystem under test. Trackside Resource Manager is mainly responsible for the allocation and recovery of trackside resources, train sequence management, operation adjustment, operation control and other functions. At the same time, it also sends the driving command of the trackside equipment to the target controller OC and collects the status of the trackside equipment sent by the target controller OC.

[0039] 5) Trackside Vehicle Manager WTC is the signal subsystem under test. On the one hand, the trackside vehicle manager is used for running cars in the train backup mode, and on the other hand, it handles functions such as temporary speed limit of the train.

[0040] 6) The interlocking target controller OC is the signal subsystem under test. The interlocking target controller is responsible for the driving and status acquisition functions of trackside equipment such as turnouts and signals. It receives control commands from the trackside resource manager WRC to drive trackside resources such as turnouts and signals, and sends the status of these trackside resources to the WRC.

[0041] 7) The three-layer switch is a component of the signal system. It is used to replace the DCS module in the actual signal system. The signal subsystems under test communicate with each other through the three-layer switch. A mirror port needs to be configured on the three-layer switch to mirror all other ports to this port, so that the information interaction between all the signal subsystems under test can be obtained through the mirror port. The mirror port is connected to the PXI controller through the network, so that the automated test script can be written on the PXI controller to obtain the messages between the signal subsystems, thereby achieving the purpose of automated testing.

[0042] 8) The programmable power supply is a hardware component of the test platform. Its input is AC power and its output is multiple 110V DC power supplies. Its main function is to provide power for the on-board controller CC. It is connected to the PXI controller through a network cable through a two-layer switch. In this way, an automated script can be written on the PXI controller to control the power on and off of the CC, thereby achieving the purpose of automated testing.

[0043] 9) The IO module is a hardware component of the test platform. It is mainly used to simulate the input and output code bits between the vehicle and the on-board controller. It is directly connected to the on-board controller CC through hard lines, and is also connected to the high-performance PXI controller through hard lines. A digital IO card will be installed on the PXI controller. By writing an automated test script on the PXI controller, the output code bits of the CC are collected and the input code bits of the CC are controlled, thereby achieving the purpose of automated testing.

[0044] 10) The speed sensor and beacon simulation module is a hardware component of the test platform. It is mainly used to simulate the speed sensor and beacon signals. It is directly connected to the on-board controller CC through a hard line and connected to the high-performance PXI controller through a test network. An automated test script is written on the PXI controller to simulate the operation of the train. The script sends the train control command to the speed sensor and beacon simulation module through the network. The module simulates the speed sensor and beacon waveforms during the train operation and sends them to the on-board controller, thereby achieving the purpose of automated testing.

[0045] 11) The two-layer switch is the hardware component of the test platform. It is mainly used to connect the programmable power supply, speed sensor and beacon simulation module to the high-performance PXI controller through the test network. In this way, the programmable power supply module and the speed sensor and beacon simulation module can be controlled by writing automated scripts on the PXI controller.

[0046] 12) The high-performance PXI controller is an important part of the test platform, on which NI's TestStand test management software is installed. TestStand is a software platform developed by National Instruments. It is an immediately executable test management software that can help users develop automatic test and verification systems faster. Its biggest advantage is that it can support test programs written in multiple programming languages, such as LabVIEW, C++, DLL, .NET, Python, etc., and then use TestStand to call these code modules to quickly create test sequences. In other words, APIs are written in various programming languages ​​to control automatic power modules, IO modules, speed transmission and beacon simulation modules, interact with TCMS, interact with Omap, and interact with wireshark. Then these APIs are called through TestStand to create test sequences, thereby achieving the purpose of automated testing.

[0047] In this solution, if you want to test the interfaces between various signal subsystems, you can also build a host simulation environment for each subsystem to create a purely virtual host test environment. Figure 2 As shown, the present invention can be implemented through the following technical solutions.

[0048] 1) An automated test method and test system for a TACS system, mainly divided into two parts: a signal system under test and a test platform. The signal system under test mainly includes several parts, such as a vehicle controller CC Sim, an automatic train monitoring system ATS Sim, a trackside resource manager WRC Sim, a trackside vehicle manager WTC Sim, and an interlocking target controller OC Sim. The test platform hardware mainly includes a high-performance PC or server, a three-layer switch, and the test platform software mainly uses NI's TestStand test management software to write automated test scripts.

[0049] 2) The functions of the tested signal systems ATS Sim, CC Sim, WRC Sim, WTC Sim, ATS Sim and OC Sim are the same as those described in the target environment. The main difference is that in the target environment, these tested signal systems are built with the same hardware devices as on-site, but in the host environment, these tested signal systems are software running on an ordinary PC, but they have the same functions as real devices.

[0050] 3) The hardware part of the test platform uses a high-performance PC or server. The difference between it and the target environment is that since the on-board controller uses simulated software and is separated from the hardware carrier, the test platform part no longer needs to use programmable power modules, IO modules, fast transmission and beacon simulation modules, etc.

[0051] 4) The test platform software also uses NI's Teststand to call APIs written in various programming languages ​​to achieve the purpose of automated testing.

[0052] 5) The three-layer switch of the test platform is used to replace the DCS module in the actual signal system and connect various signal subsystems. A mirror port also needs to be configured on the three-layer switch to mirror all other ports to this port, so that the information interaction between all the tested signal subsystems can be obtained through the mirror port. The mirror port is connected to the PXI controller through the network, so that the automated test script can be written on the PXI controller to obtain the messages between the signal subsystems, thereby achieving the purpose of automated testing.

[0053] 6) Compared with the Target test environment, the Host test environment can be built using only a few PCs and a three-layer switch. The hardware resources required are relatively small, and the construction is simple and fast. Its accuracy depends on the accuracy of the simulation software of each signal subsystem. The more realistic the simulation signal subsystem is, the more accurate the test environment is. However, the Host test environment can only be used for interface integration testing between various signal subsystems, and cannot be used for system-level function confirmation testing.

[0054] Figure 3 This is a typical implementation flow chart of an automated test system for a TACS system of the present invention. In the actual test process, the classic scenario is to control a sports car, view various CC information through omap, and view the information interaction between various signal subsystems through wireshark. The following takes this classic scenario as an example to illustrate the workflow of the automated test script of the present invention.

[0055] 1) Preparation: Before running the automated test script, you need to manually start and prepare all the WRC, WTC, OC, ATS, switches and other equipment. Power on the program-controlled power supply and switch to automatic mode, and power on the speed transmission and beacon simulation modules and enter the initialization state. During the test, if there are no abnormalities in these systems, they do not need to be restarted every time.

[0056] 2) Start the test platform: The test platform is started and variables are initialized. During the initialization process, the variables are mainly initialized. All programs that need to be started in advance can be called and started through this step, and all devices that need to be initialized can be initialized through this step.

[0057] 3) Start the speed transmission and beacon simulation module: The speed transmission and beacon simulation module is a state machine, which is controlled by the script to enter the running state. In the actual system, even if the vehicle is stationary, the on-board controller will collect the vehicle's stationary signal from the speed sensor and beacon, and the on-board controller CC will check these signals during the power-on process. If it is detected that the speed sensor or beacon module does not exist, or the stationary signal is incorrect, the on-board controller cannot be started correctly, so this module should be started before the on-board controller CC.

[0058] 4) CC power-on: The programmable power supply is connected to the PXI controller through the test network. The input of the programmable power supply is 220V AC power and the output is multiple 110V DC power supplies. The 110V voltage output of the programmable power supply is controlled by writing an API to power on the CC.

[0059] 5) Set the initial code position information (RM) of the train: There are safety code position and non-safety code position information between the vehicle and CC. By setting the input of the relevant code position of CC, CC enters the initial RM restriction mode. Write a test script to send the code position information to be set to the IO module. The IO module inputs the relevant code position information to the on-board controller CC module through hard wire, so that CC enters the RM restriction mode.

[0060] 6) Set the initial motion information of the train and run the train: Write a test script to set the initial position, acceleration, deceleration, maximum speed, end position, up and down movement information of the train. The test script will plan a speed curve for running the train according to this setting. At the same time, during the running process, the test script will interact with the speed transmission and beacon simulation module in real time. The speed transmission and beacon simulation module converts the received motion information into the real waveform signal of the speed sensor and beacon, and connects to the on-board controller CC through hard wires.

[0061] 7) Check CC information through omap: Write a test script to interact with CC's omap to get CC related information. For example, check whether CC is located and other information, and compare it with the expected value to determine whether the step passes the test. TestStand steps can be divided into several types. For example, some steps only perform a certain action. After the step is completed, Done will be displayed in the result column; some steps require judgment, such as comparison with the expected value, or determining whether it is within the set upper and lower limits. After the step is completed, Pass or Fail will be displayed in the result column. This method of checking CC information through omap can set an expected value and make a comparison.

[0062] 8) Set the code position information (FAM) of CC: This step is consistent with setting the initial code position information (RM) of CC. The difference is that the code position required to set CC to RM mode and FAM mode is different. This is generally defined in the interface document between the vehicle and the signal.

[0063] 9) FAM running: Note that before the script FAM running, you need to manually send a task to CC on ATS, such as running from point A to point B, etc. CC will automatically run the FAM running car only after receiving a valid task. Also note that during the FAM running car process, the test platform needs to communicate with the TCMS simulation part in real time to obtain the traction braking level issued by CC. And during the FAM running car process, the test script also needs to continuously send motion information to the speed sensor and beacon simulation module.

[0064] 10) Check the information between each signal subsystem through real-time interaction with Wireshark. During the test process, it is often necessary to capture packets through Wireshark to check certain information fields between each signal subsystem. Since the PXI controller has been connected to the mirror port of the three-layer switch through the Wireshark network, the information fields between each signal subsystem can be obtained by writing a test script and compared with the expected value.

[0065] 11) CC power off: This step is the opposite process of CC power on. It is also necessary to write test steps to interact with the programmable power supply to control the power off of CC.

[0066] 12) Stop the test platform: This step is the opposite of starting the test platform. Stop the test platform, reset the CC input code position, and close the program started during the initialization process.

[0067] 13) Generate test reports: TestStand can automatically generate reports in XML, HTML and other formats, and can customize the report format according to customer needs. The test report will show in detail the tester, test time, test script name, detailed test values ​​and test results of each step, test results of the entire script, etc.

[0068] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. An automated test system for a TACS system, characterized in that: It includes a signal system under test and a test platform that are interconnected. The software part of the test platform uses NI's TestStand test management software to write automated test scripts. The hardware part of the test platform is connected to the signal system under test to form an automated test environment. The automated test environment uses all real devices to build a real target test environment, or uses a simulation subsystem to build a virtual host test environment. If the target test environment is adopted, the signal system under test includes the on-board controller CC, the automatic train monitoring system ATS, the trackside resource manager WRC, the trackside vehicle manager WTC and the interlocking target controller OC; the test platform includes a programmable power supply, an IO module, a speed sensor and beacon simulation module, a PXI controller and a switch, wherein the switch includes a three-layer switch and a two-layer switch; The vehicle controller CC is used as the signal subsystem under test, and is connected to the other signal subsystems through a three-layer switch at the signal layer; at the test platform layer, the vehicle controller CC is connected to the programmable power supply, IO module, speed transmission and beacon simulation module through hard wires, the PXI controller is connected to the vehicle controller CC through the omap network to obtain the omap information of the vehicle subsystem, and the PXI controller is connected to the vehicle controller CC through the TCMS network to interact with the vehicle subsystem for TCMS information; The automatic train monitoring system ATS, as the signal subsystem under test, is responsible for supervising and controlling the operation of the train and has the functions of train tracking, alarm, operation adjustment and operation control; During actual operation, ATS sends the train operation plan and manual adjustment information to the onboard controller CC; The trackside resource manager WRC, as the signal subsystem under test, is responsible for the allocation and recovery of trackside resources, train sequence management, operation adjustment and operation control functions; at the same time, the trackside resource manager WRC also sends the driving command of the trackside equipment to the target controller OC, and collects the trackside equipment status sent by the target controller OC; The trackside vehicle manager WTC is used as the signal subsystem under test, on the one hand, for running cars in the train backup mode, and on the other hand, it handles the temporary speed limit function of the train; The interlocking target controller OC, as the signal subsystem under test, is responsible for the driving and status acquisition functions of the trackside equipment. The interlocking target controller OC receives control commands from the trackside resource manager WRC to drive the trackside resources and sends the status of these trackside resources to the WRC.

2. An automated test system for a TACS system according to claim 1, characterized in that: The three-layer switch is used to replace the DCS module in the actual signal system. A mirror port needs to be configured on the three-layer switch to mirror all other ports to the port, and obtain the information interaction between all the signal subsystems under test through the mirror port; The mirror port is connected to the PXI controller via a network, and an automated test script is written on the PXI controller to obtain messages between various signal subsystems, thereby achieving the purpose of automated testing.

3. An automated test system for a TACS system according to claim 1, characterized in that: The input of the programmable power supply is AC power, and the output is a multi-channel 110V DC power supply. Its function is to provide power for the vehicle controller CC. It is connected to the PXI controller through a network cable through a two-layer switch. An automated script is written on the PXI controller to control the power on and off of the vehicle controller CC, thereby achieving the purpose of automated testing.

4. The automated test system for a TACS system according to claim 1, characterized in that: The IO module is used to simulate the input and output code bits between the vehicle and the on-board controller. It is connected to the on-board controller CC and the PXI controller respectively through hard lines. The PXI controller is installed with a digital IO board. By writing an automated test script on the PXI controller, the output code bits of the on-board controller CC are collected and the input code bits of the on-board controller CC are controlled, thereby achieving the purpose of automated testing.

5. The automated test system for a TACS system according to claim 1, characterized in that: The speed sensor and beacon simulation module is used to simulate the signals of the speed sensor and beacon. It is connected to the on-board controller CC and the PXI controller respectively through hard lines. An automated test script is written on the PXI controller to simulate the operation of the train. The script sends the train control command to the speed sensor and beacon simulation module through the network. The speed sensor and beacon simulation module is used to simulate the speed sensor and beacon waveforms during the operation of the train and send them to the on-board controller, thereby achieving the purpose of automated testing.

6. The automated test system for a TACS system according to claim 1, characterized in that: The two-layer switch is used to connect the program-controlled power supply, speed sensor and beacon simulation module to the PXI controller through a test network, and the program-controlled power supply module and the speed sensor and beacon simulation module are controlled by writing an automated script on the PXI controller.

7. An automated test system for a TACS system according to claim 1, characterized in that: The PXI controller is installed with NI's TestStand test management software, and APIs are written in various programming languages ​​to control the programmable power supply, IO modules, speed transmission and beacon simulation modules, interact with TCMS, interact with Omap, and interact with wireshark, and these APIs are called through TestStand to create test sequences, thereby achieving the purpose of automated testing.

8. An automated test system for a TACS system according to claim 1, characterized in that: If the host test environment is adopted, the signal system under test includes the on-board controller CC Sim, the automatic train monitoring system ATS Sim, the trackside resource manager WRC Sim, the trackside vehicle manager WTC Sim and the interlocking target controller OC Sim; the test platform includes a PC or a server, and a three-layer switch.

9. An automated test system for a TACS system according to claim 8, characterized in that: The on-board controller CC Sim, automatic train monitoring system ATS Sim, trackside resource manager WRC Sim, trackside vehicle manager WTCSim and interlocking target controller OC Sim are all simulators running on a PC, and their functions are the same as those of real devices.

Citation Information

Patent Citations

  • Track signal system software testing method and device and storage medium

    CN112131094A

  • Simulation verification method and device for TACS system

    CN113219855A