Automatic test and integrated management method for fixed-period control of road traffic signal machines

Abstract

The application discloses a method for automatic testing and integrated management of road traffic signal machine fixed period control, which configures a test scheme to a target signal machine by using an automatic testing framework; during the testing process of the target signal machine, output information corresponding to the test scheme is collected; wherein, if the test scheme is a timing scheme, voltage values of a phase board of the target signal machine are collected to determine light color information, and output information corresponding to the timing scheme is determined according to the light color information; if the test scheme is a countdown scheme or a bar screen scheme, a communication link is established with the target signal machine, and output information corresponding to the countdown scheme or the bar screen scheme is collected through the communication link; the output information corresponding to the test scheme is compared with the test scheme, and an automatic testing result of fixed period control of the target signal machine is determined. The method realizes a breakthrough of automatic testing of road traffic signal machine fixed period control from scratch, saves testing manpower and time, and improves testing efficiency and accuracy.

Description

Technical Field

[0001] This application relates to the field of software automated testing technology, and in particular to automated testing and integrated management methods for periodic control of road traffic signal controllers. Background Technology

[0002] Currently, road traffic signal controller software testing is still mainly performed manually. The testing process mainly involves manually configuring the signal controller's software and hardware environment, manually configuring the signal controller timing scheme, manually issuing the timing scheme, manually switching the time period scheme, manually checking the signal controller's output results, and manually filling out the test report, etc., with a very low degree of automation.

[0003] Furthermore, the following pain points exist during the testing process: (1) The execution of signal machine test cases is time-consuming and places high demands on the time of testers. The duration of a single signal machine operation cycle varies from 1 to 10 minutes, depending on the timing scheme. Testers need to check the output results of each signal cycle and need to observe multiple signal cycles continuously. The execution of a single test case takes at least 10 minutes if the personnel observe it properly and there are no errors, which is quite time-consuming. For regression testing that needs to be executed repeatedly, hundreds or thousands of test cases are executed in each round of testing, which places very high demands on manpower and time.

[0004] (2) Signal controllers simultaneously output multiple information channels, requiring testers to switch between different equipment terminals to observe multiple outputs simultaneously, which can easily lead to overlooking problems. Signal controllers simultaneously output information such as signal light colors, countdowns, and bar charts. Testers need to constantly switch between different test terminals during the result observation process, inevitably missing some short-term defects. At the same time, observing the output results is a process check, requiring as much as possible to check every second, which also places relatively high demands on the personnel's concentration.

[0005] (3) For maintenance version testing with a high annual release frequency, repeatedly performing the same work can easily lead to testers becoming passive and lazy; and different testers may have different understandings and execution of test cases, making it difficult to guarantee test quality.

[0006] (4) Serious problems such as release conflicts are extremely difficult to discover by relying solely on testers, and there is a risk of missing detection. Summary of the Invention

[0007] This application provides a method, apparatus, electronic device, and storage medium to achieve a breakthrough in the automated testing of periodic control of road traffic signal controllers, saving manpower and time compared with manual testing, and improving testing efficiency and accuracy.

[0008] In a first aspect, this application provides an automated testing method for the periodic control of road traffic signal controllers, the method comprising: An automated testing framework is used to configure a test plan onto the target signal controller; wherein the test plan includes at least one of a timing scheme, a countdown scheme, and a bar screen scheme; During the testing of the target signal, the output information corresponding to the test scheme is collected; wherein, if the test scheme is the timing scheme, the light color information is determined by collecting the voltage value of the phase plate of the target signal, and the output information corresponding to the timing scheme is determined based on the light color information; if the test scheme is the countdown scheme or the bar screen scheme, a communication link is established with the target signal, and the output information corresponding to the countdown scheme or the bar screen scheme is collected through the communication link; The output information corresponding to the test scheme is compared with the test scheme to determine the automated test result of the fixed-period control of the target signal machine.

[0009] The above technical solution has the following advantages or beneficial effects: In related technologies, the periodic control of traffic signals is typically tested manually. This presents several challenges: the execution of test cases is time-consuming, placing high demands on the testers' time management; the simultaneous output of multiple signals requires testers to switch between different devices to observe all outputs, increasing the risk of omissions; and different testers may have differing understandings and executions of test cases, making it difficult to guarantee test quality. Serious issues such as release conflicts are extremely difficult to detect relying solely on testers, posing a risk of missed detections. The technical challenges of transitioning from manual control to automated testing in periodic traffic signal control schemes lie in the difficulties of hardware interaction control and the challenges of achieving full-process closed-loop automation. In manual testing, the hardware configuration of the traffic signal (such as phase boards and communication modules) relies on manual operation, while automation requires precise hardware control through programming. Achieving automated configuration and accurate data acquisition is the core challenge of hardware interaction control. The challenge of achieving full-process closed-loop automation lies in the transition from "manually driven single-point operation" to "system-driven global collaboration," a transition requiring breakthroughs in multiple technical bottlenecks across hardware, software, and scenarios.

[0010] This application addresses the aforementioned problems associated with manual testing in related technologies and proposes an automated testing method for periodic control of road traffic signal controllers. Specifically, firstly, an automated testing framework is used to configure the test scheme onto the target signal controller. After configuration, during the testing process, the output information corresponding to the test scheme is collected. Specifically, if the test scheme is a timing scheme, the output information corresponding to the timing scheme is determined based on the collected light color information; if the test scheme is a countdown scheme or a bar screen scheme, a communication link is established with the target signal controller to collect the output information corresponding to the countdown scheme or bar screen scheme. Finally, the output information corresponding to the test scheme is compared with the test scheme itself to obtain the final test result. In the technical solution provided by this application, personnel only need to write test cases; all subsequent testing work is automated, achieving a breakthrough in automated testing of periodic control of road traffic signal controllers. Compared with manual testing, it saves testing manpower and time, and improves testing efficiency and accuracy. Furthermore, it solves the aforementioned problems associated with manual testing in related technologies. Specifically, this application solves the problems of manual hardware operation and poor compatibility in manual testing by using an automated testing framework and hardware data acquisition technology. The automated framework automatically distributes test plans to the target signal controllers, replacing manual configuration. It determines light color information by collecting phase board voltage values ​​and collects output information corresponding to countdown or bar screen schemes via communication links, replacing manual visual observation. It achieves automated interaction between various hardware components in the testing system, overcoming the difficulties in hardware interaction control. From test plan configuration, signal controller control, data acquisition to result comparison, the entire process is automatically executed by the framework without human intervention. This replaces manual operations, improves testing efficiency, and provides a feasible path for the industry to transform from "manual-driven" to "data-driven" approaches. It overcomes the difficulty of achieving full-process closed-loop automation.

[0011] Secondly, this application provides an automated test integration management method based on the automated test method of fixed-cycle control of road traffic signal controllers, the method comprising: By using the Jenkins integration management tool and SVN version control tool, a Jenkins server and an SVN server are set up, and the environment and tasks of the Jenkins server and SVN server are configured to realize the functions of integrated management of test nodes, automatic deployment of test environment, cyclic execution of test tasks, and notification of test results.

[0012] Thirdly, this application provides an automated testing device for the periodic control of road traffic signal controllers, the device comprising: The scheme configuration module is used to configure the test scheme to the target signal machine using an automated testing framework; wherein, the test scheme includes at least one of the following: timing scheme, countdown scheme, and bar screen scheme; The data acquisition module is used to acquire output information corresponding to the test scheme during the testing process of the target signal machine; wherein, if the test scheme is the timing scheme, the module determines the light color information by acquiring the voltage value of the phase plate of the target signal machine, and determines the output information corresponding to the timing scheme based on the light color information; if the test scheme is the countdown scheme or the bar screen scheme, the module establishes a communication link with the target signal machine, and acquires the output information corresponding to the countdown scheme or the bar screen scheme through the communication link; The scheme comparison module is used to compare the output information corresponding to the test scheme with the test scheme to determine the automated test result of the fixed-period control of the target signal machine.

[0013] Fourthly, this application provides an automated testing integration management device based on a road traffic signal controller with periodic control, the device comprising: The integration management module is used to set up Jenkins and SVN servers by using the Jenkins integration management tool and SVN version control tool, configure the environment and tasks of the Jenkins and SVN servers, and realize the functions of integrated management of test nodes, automatic deployment of test environment, cyclic execution of test tasks, and notification of test results.

[0014] Fifthly, this application provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, used to execute a program stored in memory, implements the method described.

[0015] In a sixth aspect, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described herein.

[0016] In a seventh aspect, this application provides a computer program product comprising an executable program that is executed by a processor to implement the method described. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0018] Figure 1 A schematic diagram of the automated testing process for the periodic control of road traffic signal controllers provided in this application; Figure 2 Flowchart for the automatic distribution of signal timing schemes provided in this application; Figure 3 A schematic diagram of the time period scheme for automatic signal switching provided in this application; Figure 4 This is a schematic diagram of the scheme for collecting the light colors of the signal device provided in this application; Figure 5 Example diagrams illustrating the start and end of a signal period provided in this application; Figure 6 The signal periodic data acquisition flowchart provided for this application; Figure 7 The flowchart for processing traffic light color data provided in this application; Figure 8 A schematic diagram illustrating the execution results of the keyword test cases for determining channel light color provided in this application; Figure 9 A schematic diagram of the physical link setup provided for this application; Figure 10 A schematic diagram illustrating the format of the countdown data collected in this application; Figure 11 A schematic diagram illustrating the storage of countdown data in the form of a linked list, as provided in this application; Figure 12 A schematic diagram illustrating the comparison results of the countdown data provided in this application; Figure 13 A schematic diagram of the data processing results for the bar screen provided in this application; Figure 14 A schematic diagram illustrating the data comparison results of the bar screen provided in this application; Figure 15 This is a schematic diagram of the test cases provided in this application; Figure 16 A schematic diagram of the test report provided in this application; Figure 17 The architecture diagram of the automated test integration management system provided in this application; Figure 18 This is a schematic diagram of the underlying execution system scheme for automated testing of signal controllers provided in this application; Figure 19 A schematic diagram of the structure of the automated testing device for the periodic control of road traffic signal controllers provided in this application; Figure 20 A schematic diagram of the electronic device structure provided in this application. Detailed Implementation

[0019] To make the objectives and implementation methods of this application clearer, the exemplary implementation methods of this application will be clearly and completely described below with reference to the accompanying drawings of the exemplary embodiments of this application. Obviously, the exemplary embodiments described are only some embodiments of this application, and not all embodiments.

[0020] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0021] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0022] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0023] The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0024] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0025] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the described embodiments and various different variations of embodiments suitable for specific use considerations.

[0026] Figure 1 A schematic diagram of the automated testing process for the periodic control of a road traffic signal controller provided in this application, the process including the following steps: S101: Configure the test plan to the target signal controller using an automated test framework; wherein the test plan includes at least one of the following: timing plan, countdown plan, and bar screen plan; S102: During the testing of the target signal, the output information corresponding to the test scheme is collected; wherein, if the test scheme is the timing scheme, the light color information is determined by collecting the voltage value of the phase plate of the target signal, and the output information corresponding to the timing scheme is determined based on the light color information; if the test scheme is the countdown scheme or the bar screen scheme, a communication link is established with the target signal, and the output information corresponding to the countdown scheme or the bar screen scheme is collected through the communication link; S103: Compare the output information corresponding to the test scheme with the test scheme to determine the automated test result of the fixed-period control of the target signal machine.

[0027] The automated testing method for the periodic control of road traffic signal controllers provided in this application is applied to electronic devices, such as host computers, servers, etc.

[0028] Electronic devices utilize an automated testing framework to configure test plans onto the target signal controller. This automated testing framework can be a Robot Framework. The test plan must include at least one of the following: timing plan, countdown plan, or bar screen plan.

[0029] If the test scheme is the timing scheme, configuring the test scheme to the target signal machine using the automated test framework includes: using the Python program in the automated test framework to read the timing scheme data to be configured under a specified path in the scheme library, reassembling the timing scheme data according to the data format supported by the target signal machine, encapsulating the reassembled timing scheme data into a request data packet, and sending the request data packet to the target signal machine.

[0030] Traffic signal test cases are written based on timing schemes, and different test cases will be paired with different timing schemes. Therefore, to achieve automated testing of traffic signals, the first problem to solve is the automatic distribution of timing schemes. This application uses Python to write the underlying modules of the timing scheme distribution process. After layers of encapsulation, each underlying module forms a keyword for automatic timing scheme distribution. This keyword is called when the traffic signal test environment is initialized to realize the automatic distribution of the scheme.

[0031] Figure 2The flowchart for the automatic distribution of signal timing schemes provided in this application includes the following steps: reading signal scheme data from a specified path using Python; repackaging and reassembling the scheme data according to the scheme distribution rules defined between the signal center platform service and the signal; encapsulating HTTP request data (including scheme data) according to the HTTP protocol; sending the HTTP request to the signal center platform service; the signal center platform service distributing the scheme to the target signal; and the signal center platform service returning the scheme distribution result.

[0032] Step 1: Read the timing scheme data from the specified path (the storage path of the scheme data specified by the personnel in the scheme library). The scheme library covers all intersection scenarios, including multiple intersections, multiple policies, and multiple time periods. The scheme data in the CMTS format timing scheme is mainly stored in JSON data format and is generated after zip compression and base64 encoding encryption. The file data is read by Python, and the scheme data is parsed through base64 decoding, zip decompression, and other processes.

[0033] Step 2: According to the pre-set scheme distribution rules between the signal center platform service and the signal controller, the parsed scheme data is reassembled and packaged to generate a scheme data format that meets the requirements.

[0034] Step 3: Encapsulate the HTTP request data packet according to the HTTP protocol, and send the standard format scheme data to the signal center platform service in the form of an HTTP request.

[0035] Step 4: The signal center platform service automatically sends the received scheme data to the target signal and returns the scheme sending result, thereby realizing the automatic sending of signal timing schemes.

[0036] If the test plan is the countdown plan or the bar screen plan, configuring the test plan to the target signal machine using the automated test framework includes: encapsulating the communication interface using the Python program in the automated test framework, defining the configuration rules of the countdown plan or the bar screen plan, and obtaining the corresponding MIB node of the target signal machine; and sending the configuration rules of the countdown plan or the bar screen plan to the corresponding MIB node of the target signal machine through the communication interface.

[0037] The countdown scheme includes countdown types, such as full-time countdown or half-time countdown. The bar screen scheme includes a bar screen protocol. The bar screen protocol includes dedicated control logic and a general transmission standard. The dedicated control logic is used to solve problems related to text encoding, animation effects, and device control, while the general transmission standard is used to solve problems related to signal interference resistance, bandwidth matching, and hardware compatibility.

[0038] In addition to issuing the timing scheme, the signal controller test environment configuration also requires modifying the signal controller test configuration items according to test requirements, such as countdown type configuration, bar screen protocol configuration, start phase takeover, and start countdown. These configurations are currently configured manually using a dedicated configuration tool. This application, based on the SNMP communication protocol between the dedicated configuration tool and the signal controller, preset MIB node addresses, data types, and data values, uses Python to encapsulate the SNMP communication interface between the host computer and the signal controller. This encapsulates the configuration items into a compliant data format and sends it to the target signal controller through the encapsulated SNMP communication interface, thereby automatically modifying the target signal controller's test configuration items.

[0039] SNMP stands for Simple Network Management Protocol, a communication language between signal controllers and host computers. A MIB node is like an "address book" for device parameters; each configuration item (such as countdown type) corresponds to a unique MIB node address, which the host computer uses to locate the corresponding parameter. Taking countdown type configuration as an example, to change the signal controller's countdown display type from "static fixed duration" to "dynamic following timing scheme," a Python program pre-packages the SNMP communication interface; simply running the script completes the configuration. Define the configuration rules: For example, the MIB node address for the countdown type is 1.3.6.1.4.1.12345.1.2.3.4. Static countdown corresponds to a data value of 0, and dynamic countdown corresponds to a data value of 1. Run the script: The program automatically sends the "dynamic countdown" command (data value 1) to the corresponding MIB node of the target signal controller via the SNMP interface, without manual operation.

[0040] In addition, the system can automatically configure and switch signal operation time periods. A multi-time period fixed-cycle signal scheme divides the 0-24 hour period into different time periods, configuring different signal cycle lengths and green light ratios for each period. The signal controller operates according to the time period configuration. When testing different schemes, testers typically use specialized tools to modify the signal controller's current system time, enabling the signal controller to quickly transition to the specified test scheme. Modifying the signal controller's system time is similar to modifying the signal controller's test configuration; the host computer sends the set signal controller system time to the target signal controller via an SNMP communication interface, automatically modifying the signal controller's system time and achieving automatic switching of time period schemes.

[0041] Figure 3 This is a schematic diagram of the automatic signal switching time period scheme provided in this application, as shown below. Figure 3As shown, the 0-24 hour period is divided into four time periods. During time period 1, Plan 1 is implemented from 0:00 to 04:56; during time period 2, Plan 2 is implemented from 04:56 to 09:54; during time period 3, Plan 3 is implemented from 09:54 to 15:54; and during time period 4, Plan 4 is implemented from 15:54 to 24:54.

[0042] After the test plan is configured on the target signal machine using an automated test framework, the electronic equipment needs to go through the process of acquiring, analyzing and comparing the signal machine output data with the expected results.

[0043] After configuring the signal controller test environment, formal testing begins. Fixed-cycle control of the signal controller refers to its operation according to the configured cycle length and green light ratio of the timing scheme. No other external control inputs are received during this process; therefore, testers only need to check the correctness of the signal controller's output information. The signal controller's output information includes signal light colors, countdown timers, and bar display information. The acquisition of signal controller output data uses an independent process, employing asynchronous I / O technology to achieve synchronous acquisition of multiple data streams. The acquired data is stored in cycle units, processed to form comparable structured data, and compared with the expected results, thus completing the automatic acquisition, analysis, and result comparison of the signal controller's output data.

[0044] Fixed-cycle control refers to the signal controller operating strictly according to the timing scheme (e.g., "cycle 120 seconds, green light ratio 3:2"), without external intervention (e.g., manual control, sensor triggering). Asynchronous I / O technology refers to simultaneously monitoring multiple data streams (e.g., multiple traffic light groups, countdown timers, bar screens), without waiting for one stream to complete before processing the next, resulting in higher efficiency.

[0045] Assuming the test scenario is "the green light duration at an intersection is 30 seconds for east-west traffic and 25 seconds for north-south traffic, with a cycle of 120 seconds," the test procedure is as follows: During the data acquisition phase, the data collected includes traffic light colors (red / yellow / green), countdown displays (remaining seconds), and bar chart information (e.g., "green flashing for 3 seconds"). The acquisition method involves starting an independent process (e.g., Python's asyncio asynchronous framework) while simultaneously monitoring multiple outputs. Traffic light colors are read in real-time via GPIO interface or network protocols (e.g., UDP). Countdown data is acquired via serial port or SNMP protocol. Data is stored in 120-second cycles, recording the output status at each time point within each cycle (e.g., "10th second: East-West green light, countdown 20 seconds").

[0046] During the data processing phase, the collected raw data (such as "green light on" or "countdown 20") is converted into structured data (such as JSON format), for example: { "Period Number": 1, "Time point": "00:00:10", Traffic light status: {"East": "Green", "West": "Green", "South": "Red", "North": "Red"}, "Countdown": {"East": 20, "West": 20, "South": 55, "North": 55}, "Bar Screen": "Green flash for 3 seconds" } Clean the data (e.g., filter outliers) and align it (match by timestamp) to ensure it matches the expected format.

[0047] During the result comparison phase, the expected result is based on the preset timing scheme (e.g., "East and West green lights at the 10th second, countdown 20 seconds"). The automatic comparison process is as follows: if the actual data matches the expected result (e.g., "East green light is on, countdown 20 seconds"), it is marked as "passed". If it does not match (e.g., "East green light is on, but the countdown shows 19 seconds"), it is marked as "abnormal", and the difference is recorded (e.g., "countdown 1 second less").

[0048] In this application, determining the light color information by collecting the voltage value of the phase plate of the target signal receiver includes: The communication command information of the main control board of the target signal and the voltage value of the phase board are collected respectively; wherein, the communication command information is used to represent the intention information of light color control, and the voltage value of the phase board is used to represent the execution result of the phase board in response to the communication command information; if the intention information of light color control represented by the communication command information is consistent with the execution result of the phase board in response to the communication command information, then the light color information is determined according to the voltage value of the phase board of the target signal.

[0049] Figure 4 The diagram below illustrates the signal light color acquisition scheme provided in this application. The signal controller's main control board sends light color data to the phase board via a CANBUS bus. The phase board then controls the on / off switching of the intersection signal lights via 220V power. Considering the reliability and accuracy of the data source, we choose to directly acquire the 220V power data output from the signal controller's phase board as the data source for signal light color determination. The 220V light color data is acquired using a signal acquisition and conversion device. This device performs an AD conversion calculation every 0.1ms and converts the acquired data into Ethernet data, which is then transmitted to the host computer via Ethernet port using UDP.

[0050] The essence of traffic signal light color acquisition is "end-to-end data verification from command to execution." The main control board sends light color control commands (such as "green light on") to the phase board via CANBUS. The phase board outputs 220V high voltage according to the command, directly controlling the on / off state of the traffic signal light. Module 1 (CAN acquisition) and Module 2 (220V high voltage acquisition) respectively acquire the "command signal" and "execution result," providing dual verification to ensure data reliability.

[0051] Figure 4 Module 1 is the CANBUS data acquisition module, which acquires CAN communication commands between the main control board and the phase board, recording the "original intent of light color control". The main control board sends light color control frames (such as "Eastbound green light on" and "Southbound yellow light flashing") to the phase board via the CANBUS bus. The CAN transceiver receives the CAN bus signals and converts them into digital signals. The CAN frame ID and data segment are parsed to extract the light color control command (such as "0x01" corresponding to the green light). The data is verified (such as CRC check) to ensure that the command has not been tampered with. The parsed command (such as "Eastbound green light") is encapsulated into a UDP data packet and sent to the host computer. Module 1 is used to record whether the command was correctly issued, serving as evidence of the intent of light color control. If subsequent light color anomalies occur, the CAN data can be used to trace whether the main control board command was incorrect.

[0052] Figure 4 Module 2 is a 220V high-voltage power acquisition module, which directly acquires the 220V high-voltage signal output from the phase board and records the "actual result of the light color execution". The phase board outputs 220V AC power to the traffic lights (voltage exists when the light is on and disappears when the light is off). A voltage transformer is used to convert the 220V high-voltage power into a low-voltage signal (e.g., 0-5V) to ensure the safety of the acquisition equipment. An AD converter is used to perform analog-to-digital conversion (AD conversion) on the low-voltage signal every 0.1ms, converting the analog voltage into a digital quantity (e.g., "220V corresponds to the digital quantity 1023, 0V corresponds to 0"). The AD conversion result is filtered (e.g., to remove spike interference) to ensure data stability. The light color status is determined based on the voltage threshold (e.g., "digital quantity > 800" indicates the light is on, corresponding to green / red / yellow light). The light color status (e.g., "east-facing green light on") is encapsulated into a UDP data packet and sent to the host computer. Module 2 records "whether the light color was actually executed", serving as the final basis for the light color status. If the CAN command displays a "green light" but there is no output of 220V high voltage, it can be determined that the phase board is faulty.

[0053] The main control board sends an "Eastbound Green Light" command via CANBUS, which is collected and parsed into a "Green Light Command" by module 1. The phase board outputs 220V high voltage, and module 2 determines whether the "Eastbound Green Light" is on through a voltage transformer and AD conversion. Both modules encapsulate the data into UDP packets (including timestamps and light status) and send them to the host computer. The host computer compares the data from module 1 and module 2 (e.g., whether the "Command Green Light" matches the "Executed Green Light") and generates a test report. The combination of modules 1 and 2 achieves closed-loop verification between command intent and actual execution. Module 1 ensures that the "command is correctly issued," and module 2 ensures that the "light color is actually effective." This dual-module collaboration not only improves data reliability but also enables rapid fault location (e.g., command errors, execution failures, communication anomalies), providing a precise data source for signal controller testing.

[0054] Module 2 distinguishes light colors by mapping multiple independent acquisition channels to physical circuits. The hardware circuit of Module 2 includes multiple independent acquisition channels (e.g., three channels corresponding to red, yellow, and green), each channel connected to the corresponding light color output terminal of the phase board via a dedicated physical circuit. For example: Channel 1 corresponds to the red light output line of the phase board; Channel 2 corresponds to the yellow light output line; and Channel 3 corresponds to the green light output line. Each channel contains an independent voltage transformer, AD converter, and signal processing unit, ensuring that the 220V signals of different light colors are acquired separately and without interference. Module 2 pre-defines the mapping relationship between channel numbers and light colors. For example, when Channel 1 detects 220V, it determines that the red light is on; when Channel 2 detects 220V, it determines that the yellow light is on; and when Channel 3 detects 220V, it determines that the green light is on. The mapping relationship is fixed in the configuration file before the signal controller leaves the factory, and the host computer also synchronizes this mapping table to ensure that the data can be directly matched to the light color during parsing. Each LED has an independent 220V line, and the acquisition channels of Module 2 are physically isolated to avoid signal crosstalk. Each channel has a unique identifier (e.g., Channel 1, Channel 2), and the firmware directly maps the LED color using the ID, without additional judgment. Module 2 achieves accurate identification of different LED colors from both hardware and software levels through the design of multiple independent channels combined with the channel-to-LED color mapping relationship. Each channel corresponds to a physical line for one LED color, and combined with the preset mapping relationship, the host computer can ultimately directly parse the color of the currently lit LED.

[0055] Table 1 is an example table showing how two modules solve the reliability problem of a single data source through dual verification of "instruction-execution".

[0056] Table 1

[0057] In this application, determining the output information corresponding to the timing scheme based on the light color information includes: Based on the light color information and the determined cycle data, the output information corresponding to the timing scheme is determined; wherein, the cycle data is determined based on the first frame type of the pre-set cycle start frame data and the second frame type of the cycle end frame data.

[0058] Figure 5 The example diagram provided in this application illustrates the determination of the start and end of a signal cycle. The signal controller's periodic light color acquisition and judgment are performed on a cycle-by-cycle basis, thus requiring the acquisition of cycle data and comparison. To accurately capture the start and end times of the signal cycle for controlling light color data acquisition, this application utilizes the signal controller's existing phase takeover function. This function, based on the light color data sent from the main control board to the phase board, sends cycle start frame data (e.g., frame type 04 01) at the start of the signal cycle and cycle end frame data (e.g., frame type 0402) at the end of the cycle. All data in between is the light color data for that cycle. Therefore, this application can use these two signals to determine the start and end of the signal cycle to control the acquisition of cycle light color data.

[0059] The method further includes: If a coordinated transition is triggered, the key parameters are captured by combining the printed information output from the debugging serial port of the target signal machine with regular expressions, and the variable period length data is determined based on the key parameters; the determined period data is adjusted based on the variable period length data; wherein, the key parameters include the number of periods, the period length, and the green ratio.

[0060] When a traffic signal operates under fixed-cycle control, it generally runs according to the cycle length and green ratio configured in the timing scheme. However, if events such as signal synchronization, scheme switching, or manual control occur, the signal will perform a coordinated transition. The number of transition cycles and the green ratio allocation for each cycle are uncertain and are calculated in real time according to coordination rules. The transition cycle information (number of cycles, cycle length, etc.) is output in the serial port output of the traffic signal debugging system. This transition cycle information is output before the start of the transition cycle. In order to collect complete transition cycle data, this application uses the printed information output by the debugging serial port to capture the transition cycle information through regular expressions, configures the acquisition task, and realizes the acquisition of transition cycle data.

[0061] The core challenge of variable-cycle data acquisition lies in the dynamic nature of the transition cycle (the number of cycles, cycle length, and green light ratio are all calculated in real time). The solution is to use the printed information output from the signal controller's serial port, combined with regular expressions to capture key parameters, dynamically configure the acquisition task, and ensure data integrity. When the signal controller is running at a fixed cycle (e.g., a cycle of 120 seconds, green light ratio of 3:2), the following events will trigger a coordinated transition: 1. Time synchronization event: The signal controller synchronizes with an external clock (e.g., GPS time synchronization), requiring adjustment of the cycle start point. 2. Scheme switching: Switching from "peak hour scheme" to "off-peak scheme," the cycle length changes from 120 seconds to 90 seconds. 3. Manual intervention: Maintenance personnel manually adjust the light color (e.g., forced green light), causing cycle interruption. The cycle length and green light ratio during the transition phase are calculated in real time (e.g., transition cycle 1: 100 seconds, transition cycle 2: 90 seconds), and cannot be preset. If only the original cycle is collected, it will lead to data loss or misalignment (e.g., a light color with a "cycle of 120 seconds" is collected, but the actual cycle has changed to 100 seconds).

[0062] The signal controller's debugging serial port (such as RS232 / RS485) outputs key information about the transition cycle (number of cycles, cycle length, green ratio, etc.), and this information is output before the start of the transition cycle (e.g., "Transition cycles: 3, cycle lengths are 100 seconds, 90 seconds, and 110 seconds respectively"). Data acquisition is achieved through the following steps: Connect the signal controller's debugging serial port to the acquisition device using a USB-to-serial cable, and use a serial port monitoring tool (such as Python's pyserial library) to read the serial port output in real time to achieve serial port data monitoring. Capture transition parameters using regular expressions. Extract the number of cycles and the length of each cycle from the serial port output using regular expressions. For example: Serial port output example: [2026-03-14 10:00:00] Transition cycles: 3, cycle length: 100s, 90s, 110s. Regular expression: Transition cycles: (\d+) cycles, cycle length: ([\d,]+)s. Capture result: 3 (number of cycles), 100, 90, 110 (list of cycle lengths).

[0063] Based on the captured parameters, the period length and duration of the data acquisition task are automatically adjusted. If there are three transition periods with lengths of 100 seconds, 90 seconds, and 110 seconds respectively, the data acquisition task must: start acquisition at the beginning of the first transition period (100 seconds) and continue for 100 seconds; start acquisition at the beginning of the second transition period (90 seconds) and continue for 90 seconds; and start acquisition at the beginning of the third transition period (110 seconds) and continue for 110 seconds.

[0064] In this application, transition cycle parameters are obtained in advance via serial port information, ensuring that data for each transition cycle is collected and avoiding missed data due to cycle changes. No manual intervention is required; the acquisition task automatically adjusts based on the serial port output to adapt to the real-time operating status of the signal. Data for each transition cycle is labeled with the cycle type (e.g., "scheme switching transition" or "time synchronization transition"), facilitating subsequent analysis of the event's impact on signal operation. The core of variable-cycle data acquisition is serial port information-guided acquisition. By monitoring and debugging the transition cycle parameters output by the serial port, key information is extracted using regular expressions, and the acquisition task is dynamically configured to ensure the completeness and accuracy of data during the transition phase. This solves the problem of acquiring data when the cycle changes dynamically during signal operation, providing reliable data support for signal debugging and optimization.

[0065] The signal controller output data acquisition scheme employs an independent process, utilizing asynchronous I / O technology to synchronously acquire multiple data streams (signal light colors, countdown timers, and bar screens). Interaction with the test case process occurs via a TCP server / client architecture, following a custom message format. The client sends acquisition messages, the server verifies these messages, creates acquisition tasks according to acquisition rules, and after acquisition, the data undergoes compression, deserialization, and other processes before being transmitted back to the client for comparison.

[0066] Figure 6 The flowchart for signal periodic data acquisition provided in this application is shown. Figure 6 As shown, a data acquisition task is created. It checks if the acquisition type is a transition period. If so, it debugs serial port data listening and checks if transition period information is captured. If not, it continues debugging serial port data listening. If captured, it updates the acquisition period count and proceeds with the frame data acquisition step. If the acquisition type is not a transition period, the frame data acquisition step is still performed. Frame data is acquired, and it checks if it is the start frame of the period. If so, it checks if periodic data acquisition is enabled. If so, a data acquisition exception is thrown. If periodic data acquisition is not enabled, it starts periodic data acquisition and continues acquiring frame data. Frame data is acquired. If it is not the start frame of the period, it checks if it is the end frame of the period. If so, it checks if periodic data acquisition is enabled. If so, it updates the number of completed periods and checks if all acquisition periods are completed. If so, it saves the result and ends the acquisition task, updating the status (finished). If not all acquisition periods are completed, it continues acquiring frame data. If periodic data acquisition is not enabled, the frame data acquisition step is still performed. If the frame data is not determined to be the end of the cycle, check if the cycle data acquisition has been started. If so, save the frame data and continue to acquire frame data. If not, also perform the frame data acquisition step.

[0067] After collecting the output information corresponding to the test plan, and before comparing the output information corresponding to the test plan with the test plan, the method further includes: If the test scheme is the timing scheme, the output information is subjected to frame data verification, wherein the frame data verification includes integrity verification, correctness verification and timing verification; if the verification result of the frame data verification is that the data is normal, the light color data in the output information is processed in a structured manner through the light color recombination algorithm to obtain the output information to be compared corresponding to the test scheme.

[0068] Traffic light color data processing. Basic frame data verification is performed on the raw signal cycle data transmitted back from the acquisition service, and the data is reconstructed and structured according to the color reconstruction algorithm to form comparable structured data.

[0069] This application transforms the collected raw UDP data packets (e.g., one packet every 0.1ms, containing timestamps, light color status, etc.) into structured data (e.g., grouped by signal period, containing light color change sequences) for subsequent comparison with timing schemes, fault diagnosis, or performance analysis. This application ensures the reliability of the raw data through frame data verification. When raw data is transmitted from the acquisition device to the host computer, errors or missing data may occur due to network packet loss, electromagnetic interference, etc. Frame data verification is the first step in data processing, filtering out invalid data by verifying the integrity, correctness, and timing of the data.

[0070] Integrity checks include verifying that UDP packets contain all required fields (such as timestamp, channel number, and voltage value); missing fields are marked as invalid. Correctness checks include voltage range verification: the AD conversion value corresponding to 220V high voltage should be within a reasonable range (e.g., 0~1023, corresponding to 0~220V); values ​​outside this range are considered abnormal. Channel number validity checks: channel numbers should correspond to red, yellow, and green (e.g., 1=red, 2=yellow, 3=green); invalid channel numbers (e.g., 0 or 4) are discarded. Timing checks include checking if timestamps are continuous (e.g., the time difference between adjacent data should be ≤0.1ms); if a timestamp jumps (e.g., from 10:00:00.000 to 10:00:00.002), missing data is added or the packet is marked as abnormal.

[0071] A light color reorganization algorithm is used to transform "discrete data" into "structured periodic data." The original data is discrete (e.g., one record every 0.1ms), which cannot directly reflect the color change patterns within a signal cycle. The light color reorganization algorithm groups the data according to the signal cycle to form a structured record through the following steps: Optionally, based on the signal cycle length (e.g., 120 seconds), the continuous original data is divided into multiple cycles by timestamps (e.g., 10:00:00~10:02:00 is cycle 1, 10:02:00~10:04:00 is cycle 2). For the original data within each cycle, the light color status is extracted in chronological order (e.g., "green light on," "yellow light on"). The duration of each light color within the cycle is calculated (e.g., green light lasts 40 seconds, yellow light lasts 3 seconds).

[0072] Reorganized structured data, for example: { "Period ID": 1, "Start Time": "10:00:00", End Time: 10:02:00 "Light color sequence": [ {"Light color": "Green light", "Start time": "10:00:00", "End time": "10:00:40", "Duration": 40}, {"Light color": "Yellow light", "Start time": "10:00:40", "End time": "10:00:43", "Duration": 3}, {"Light Color": "Red Light", "Start Time": "10:00:43", "End Time": "10:02:00", "Duration": 77} ] } The processed structured data can be directly used for timing scheme comparison. The actual light color sequence can be compared with the preset timing scheme (e.g., 40 seconds green, 3 seconds yellow, 77 seconds red) to verify consistency. Fault diagnosis: If the green light duration is abnormal within a certain cycle (e.g., only 30 seconds), the cause can be traced by combining the original data (e.g., phase board failure). Performance analysis: The duration of light colors across multiple cycles is statistically analyzed to assess the stability of the traffic signal operation. The core of light color data processing is transforming disorder into order. Frame verification ensures data reliability, and a reorganization algorithm converts discrete data into structured records organized by cycle, providing a clear and usable data source for subsequent analysis.

[0073] Figure 7The flowchart for processing traffic light color data provided in this application includes frame data verification; determining whether the verification passes; if not, throwing an exception; if yes, unpacking and reassembling the frame data; reassembling the color status; and generating metrics.

[0074] This application compares the collected actual signal cycle light color data with the expected results. The above steps have processed the actual operating cycle light color data of the signal into a comparable structured matrix metrics format. The expected results are given by the testers when writing test cases, specifying information such as the light channel number, light duration, and light position index. Using corresponding color judgment keywords, the results for green, flashing green, yellow, and red lights are judged respectively. This application compares the actually collected light color data (structured matrix metrics) with the expected results defined in the test cases point by point to verify whether the signal operation conforms to the preset logic (such as timing scheme and phase sequence). The consistency of light color status, duration, and time points is compared.

[0075] Structured matrix metrics refer to the actual data processed in the above steps, including the light color status (on / off) and duration of each channel (red / yellow / green) recorded on the time axis. Expected results refer to the predefined "ideal light color sequence" in the test cases, including constraints such as channel number, light color type, start time, and duration. Color judgment keywords refer to labels used to identify the light color status (such as "green light on", "green flashing", "yellow light on", "red light on"), corresponding to the voltage change patterns in the actual data.

[0076] The process of comparing the above results will be explained below with an example.

[0077] For example, the structured matrix metrics are: { "Period ID": 1, "Timeline": ["10:00:00.000", "10:00:00.100", ..., "10:02:00.000"], / / One time point every 0.1ms "Channel 1 (Red Light)": ["Off", "Off", ..., "On", ..., "Off"], / / Red light state sequence "Channel 2 (Yellow Light)": ["Off", "Off", ..., "On", ..., "Off"], / / Yellow Light State Sequence "Channel 3 (Green Light)": ["On", "On", ..., "Off", ..., "Off"] / / Green light state sequence } The expected result is: { "Test Case ID": "TC001", "Period length": 120, / / Expected period: 120 seconds "Lighting color rules": [ {"Channel": 3, "Light Color": "Green Light On", "Start Time": "10:00:00", "Duration": 40}, / / Green light for 40 seconds {"Channel": 2, "Light Color": "Yellow Light On", "Start Time": "10:00:40", "Duration": 3}, / / Yellow light for 3 seconds {"Channel": 1, "Light Color": "Red Light On", "Start Time": "10:00:43", "Duration": 77} / / Red light for 77 seconds ] } First, align the timeline of the actual data with the time range of the expected result (e.g., if the expected period starts from 10:00:00, the actual data needs to be extracted from the corresponding time period).

[0078] Verify the light status of each channel point by point in time. Check whether the light color at a certain point in the actual data matches the expectation (e.g., if the expectation is that channel 3 will be "green light on" at 10:00:00, is channel 3 actually "on" at that point in the actual data?). Calculate the duration of a certain light color in the actual data and compare it with the expected duration (e.g., if the expectation is that the green light will last for 40 seconds, and the actual green light lasts for 39.9 seconds from 10:00:00 to 10:00:39.900, with an error of 0.1 seconds, is this within the allowable range?).

[0079] If the actual light color does not match the expectation (e.g., the expected green light is on, but the actual red light is on), then the status is incorrect; if the actual duration exceeds the allowable error range (e.g., the expected duration is 40 seconds, but the actual duration is 35 seconds, with an error of 5 seconds, exceeding the tolerance of ±1 second), then the duration deviation is too large; if the light color switching sequence does not match the expectation (e.g., the expected green light → yellow light → red light, but the actual duration is green light → red light → yellow light), then the timing is incorrect.

[0080] Color-coding keywords (such as "green light on" and "green flashing") serve as a bridge connecting actual voltage data with the semantic meaning of the light color. "Green light on" corresponds to a 220V high-voltage output from the phase board, with an AD conversion value greater than or equal to the set threshold. "Green flashing" corresponds to rapid voltage alternation (e.g., 220V→0V→220V, frequency 5Hz), with the AD conversion value rapidly switching between the set threshold and 0. Similarly, "yellow light on" and "red light on" correspond to different channel voltage thresholds. Through these keywords, test cases can clearly define the desired light color state, while the actual data is compared semantically by matching the AD conversion value with the keywords. Figure 8 A schematic diagram illustrating the execution results of the keyword test case for determining the channel light color provided in this application.

[0081] In this application, during countdown data acquisition, the signal gantry and the countdown display communicate via a 485 serial port. The signal gantry sends the displayed content to the countdown display through the 485 interface, and the countdown display sends a heartbeat response to the signal gantry through the 485 interface. The physical communication between the signal gantry and the countdown display is simulated using a USB-232 serial cable and a 232-485 converter. The USB end is connected to the host computer's USB interface, and the 485 end is connected to the signal gantry's 485 interface, thus completing the physical link setup. Figure 9 This is a schematic diagram of the physical link setup provided in this application. The host computer encapsulates the serial port protocol and establishes serial communication with the signal controller. The countdown data acquisition is also performed periodically, starting and ending synchronously with the periodic light color data acquisition. Figure 10 This is a schematic diagram illustrating the format of the countdown data collected in this application.

[0082] By simulating a 485 serial communication link between the traffic signal and the countdown display, the countdown display commands sent by the traffic signal (such as "40 seconds remaining on the green light") are acquired and synchronized with the light color data to achieve joint verification of "light color status + countdown value" (e.g., the countdown decreases from 40 seconds to 0 when the green light is on, and from 3 seconds to 0 when the yellow light is on). Hardware conversion enables 485 communication between the host computer and the traffic signal. The host computer configures the serial port parameters, parses the 485 protocol frames of the traffic signal, and encapsulates the communication protocol. The timing starts and ends at the same time as the light color data acquisition to ensure timeline consistency. The native communication between the traffic signal and the countdown display is via a 485 serial port, but the host computer typically only has a USB interface; therefore, a USB-to-232 serial cable and a 232-to-485 converter are required for hardware adaptation.

[0083] The hardware connection is as follows: Insert the USB end of the USB-232 serial cable into the host computer's USB port, and connect the other end (232 interface) to the 232 port of the 232-485 converter. Connect the 485 port (A / B line) of the 232-485 converter to the 485 interface of the signal device. Power the 232-485 converter.

[0084] Link verification is as follows: The host computer installs the serial port driver and identifies the virtual serial port. A serial port debugging tool is opened, and a test command is sent. If the signal device responds with the corresponding command, the link is normal. Communication between the signal device and the countdown screen follows a custom serial port protocol; the host computer needs to encapsulate the protocol to parse the data.

[0085] The countdown data collection period and time range are completely synchronized with the light color data (e.g., if the light color collection period is 120 seconds, the countdown collection also starts and ends at the same time).

[0086] Assuming the light color acquisition period is 10:00:00 ~ 10:02:00 (120 seconds), the countdown acquisition is executed synchronously: Data acquisition begins: 10:00:00, the host computer starts serial port monitoring and simultaneously starts acquiring light color data.

[0087] Real-time reception: The traffic signal sends a countdown command every second (e.g., "green light for 40 seconds" at 10:00:00, "green light for 39 seconds" at 10:00:01, ... "yellow light for 3 seconds" at 10:00:40).

[0088] Data collection ended at 10:02:00. The host computer stopped listening, and the light color data collection also ended.

[0089] The collected countdown data is perfectly aligned with the light color data timeline, allowing for verification of the match between the light colors and the countdown, as well as the accuracy of the countdown. The core of the countdown data acquisition is the simulated RS-485 communication link, synchronously acquiring the countdown commands from the traffic signal. Through hardware adaptation, protocol parsing, and synchronization mechanisms, joint verification with the light color data is achieved. This method directly acquires data from the "command source" of the traffic signal, ensuring the reliability of the countdown information and its consistency with the light colors.

[0090] After collecting the output information corresponding to the test plan, and before comparing the output information corresponding to the test plan with the test plan, the method further includes: If the test scheme is the countdown scheme, the countdown data in the output information is parsed frame by frame according to the countdown protocol to obtain structured countdown data, which is then stored in the form of a data linked list.

[0091] Figure 11 This diagram illustrates the use of a linked list to store countdown data, as provided in this application. The original UDP-transmitted countdown data frames are parsed into structured information (such as timestamps and countdown values) according to protocol rules, and efficiently stored and dynamically managed using a linked list, providing a foundation for subsequent "light color-countdown joint verification." The countdown data is transmitted in UDP packets and needs to be parsed frame by frame according to a custom serial port protocol. Frame-by-frame parsing includes frame integrity verification, extraction of core fields, and checksum verification. Frame integrity verification includes checking the presence of the start and end bits of the frame. Extracting core fields includes extracting the address code, command code, and data segment.

[0092] The countdown data is characterized by strong temporal sequence and high real-time performance. It is stored using a singly linked list, requiring no pre-allocation of memory and automatically growing with the number of data frames. Linked list nodes are inserted in timestamp order, naturally supporting time-dimension traversal. New data frames are directly appended to the end of the linked list, with a time complexity of O(1). Through "protocol parsing + linked list storage," the following goals are achieved: Data reliability: Invalid data is filtered through CRC checksum and frame integrity verification. Temporal consistency: The linked list is sorted by timestamp, ensuring alignment with the timeline of the light color data (e.g., the countdown decreases from 40 seconds when the green light is on). Efficient analysis: Supports querying by time range, quickly locating anomalies (e.g., countdown jumps, mismatch between light color and countdown).

[0093] Testers provide the expected countdown result in the test cases and compare it with the actual countdown data collected to achieve a comparison of the countdown data results. Optionally, verify whether the error between the actual countdown value and the expected countdown value is within the allowable range. Compare the actual countdown value with the expected countdown value frame by frame in timestamp order (e.g., in the test case, the countdown to the green light at 10:00:00 should be 40 seconds, is the actual collected value 40 ± 1 seconds?). If the error exceeds the threshold (e.g., if the actual countdown is 38 seconds, the error is -2 seconds), mark it as an incorrect countdown value. If the countdown value is incorrect, check whether there are logical errors in the countdown algorithm of the traffic signal controller. Optionally, verify whether the decreasing pattern of the countdown value conforms to the design logic (e.g., the green light countdown should continuously decrease from 40 seconds to 0 without abrupt changes). Check whether the countdown value of adjacent frames decreases continuously (e.g., if 10:00:00 is 40 seconds, 10:00:01 should be 39 seconds). If a jump (e.g., from 40 seconds to 38 seconds) or an increase (e.g., from 39 seconds to 40 seconds) occurs, it is marked as an abnormal trend. If an abnormal trend is found, check whether the countdown update mechanism of the signal machine is abnormal, or whether there is data disorder in the linked list storage of the host computer. Figure 12 A schematic diagram illustrating the comparison results of the countdown data provided in this application.

[0094] During bar screen data acquisition, the output of the signal bar screen and the countdown data use the same RS-485 interface. The acquisition principle is similar to that of countdown data acquisition, the difference being the data protocol format; data is acquired according to the bar screen protocol. After receiving the data, the host computer parses the data frames according to the bar screen's specific protocol, extracting structured information such as display content and status codes. The process of bar screen data acquisition is the same as the countdown data acquisition process described above, and will not be repeated here.

[0095] After collecting the output information corresponding to the test plan, and before comparing the output information corresponding to the test plan with the test plan, the method further includes: If the test scheme is the bar screen scheme, the bar screen data in the output information is parsed frame by frame according to the bar screen protocol to obtain structured bar screen data.

[0096] Figure 13 This diagram illustrates the data processing results of the bar screen provided in this application. After the periodic data collection of the bar screen is completed, the bar screen data is parsed frame by frame according to the bar screen protocol to form comparable structured data. The collected raw bar screen data frames are parsed according to a dedicated protocol to extract key information and convert it into structured data (such as JSON, tables, etc.), providing standardized input for subsequent status monitoring, anomaly analysis, and data comparison.

[0097] Data processing for bar screens consists of three steps: data reception, protocol parsing, and structure conversion.

[0098] Data Reception: The host computer receives Ethernet data packets sent by the signal acquisition and conversion device via the UDP protocol. It performs integrity checks on the data packets, filtering out lost or corrupted data. Valid data is sorted by timestamp to ensure the data order matches the acquisition order.

[0099] Protocol parsing: Each frame of data is parsed according to the bar screen's specific protocol, extracting key fields (such as address code, command code, display content, status code, etc.). The start bit, end bit, and check bit of the data frame are verified to ensure data validity.

[0100] Structured data conversion: The parsed fields are mapped to a structured data format (such as JSON), including fields such as timestamp, device address, displayed content, and status. The structured data is then output to a database or host computer system for subsequent analysis.

[0101] Bar screen data processing combines protocol parsing with structured conversion. By parsing the raw data frames field by field, meaningful information is extracted and converted into a standardized format, providing reliable data support for traffic signal system monitoring and fault diagnosis. Its collaborative analysis with light color data further enhances the system's reliability and traceability.

[0102] Testers specify the expected bar display results in the test cases and compare them with the actual collected bar display data to achieve data comparison. If the actual displayed content is inconsistent with the expectation (e.g., the expected green light is 40 seconds, but the actual red light is 20 seconds), the protocol parsing logic or signal controller configuration needs to be checked. Figure 14 This is a schematic diagram of the data comparison results of the bar screen provided in this application.

[0103] After developing the underlying key technologies for the periodic control of the signal controller, the next step is to write and execute test cases. This application's automated testing method is based on the Robot Framework automated testing framework, and test case writing and execution are completed through the Robot Framework RIDE graphical management interface. Robot Framework is an open-source, Python-based, highly extensible, keyword-driven general-purpose automated testing framework with rich built-in and extended libraries. Users can also develop their own test libraries based on their needs and import them. This application uses Python to develop a dedicated test library for signal controllers based on Robot Framework. By importing the test library into Robot Framework, test cases can be written and executed using the test case keywords within the library. When writing test cases, users can search for available test case keywords in the test library and use them directly, or they can encapsulate test case keywords into higher-level user keywords to write test cases. Test cases can also be tagged, and during execution, the system will select test cases based on the tags to perform corresponding acceptance tests, regression tests, full-function tests, etc. After testing, Robot Framework automatically generates an HTML test report.

[0104] By using RobotFramework and a dedicated signal controller test library, automated testing of the signal controller's periodic control function is achieved, covering acceptance testing, regression testing, and other scenarios, improving testing efficiency and accuracy. RobotFramework is a keyword-driven general-purpose automated testing framework with strong extensibility, supporting the development of custom test libraries in Python and adapting to the signal controller's proprietary protocols and hardware interfaces. It supports visual management, allowing users to write and execute test cases through the RIDE (Robot Framework IDE) graphical interface, lowering the technical barrier. To adapt to the signal controller's hardware interfaces and protocols, a custom test library needs to be developed based on Python. Its core functions include hardware communication encapsulation, implementing communication interfaces (such as CANBUS and UDP) with the signal controller's main control board and phase board, supporting the sending of control commands (such as phase switching and light color settings); data acquisition and verification, encapsulating functions such as light color data acquisition (220V high-voltage data from module 2) and bar screen data parsing to verify whether the actual output meets expectations; and exception handling and logging, capturing exceptions such as communication timeouts and data parsing errors, generating detailed logs for easy problem localization.

[0105] The test cases employ a keyword-driven approach, combining built-in and custom keywords to implement complex logic. Basic keywords directly call functions in the test library, while user keywords combine multiple basic keywords into more advanced logic. Upon execution, RobotFramework automatically generates an HTML report, including: test case execution results (pass / fail / skipped); detailed logs of failed test cases (e.g., communication timeout, data mismatch); and statistical information (pass rate, execution time, tag distribution).

[0106] By using RobotFramework and a dedicated test library for signal controllers, the entire process from hardware control to data acquisition to result verification is fully automated. The keyword-driven test case model and tagging mechanism significantly improve testing efficiency and flexibility, providing a reliable guarantee for the stability of the signal controller's periodic control function.

[0107] Figure 15 This is a schematic diagram of the test cases provided in this application. Figure 16 This is a schematic diagram of the test report provided in this application.

[0108] This application provides an automated test integration management method based on the automated test method of fixed-cycle control of road traffic signal controllers, the method comprising: By using the Jenkins integration management tool and SVN version control tool, a Jenkins server and an SVN server are set up, and the environment and tasks of the Jenkins server and SVN server are configured to realize the functions of integrated management of test nodes, automatic deployment of test environment, cyclic execution of test tasks, and notification of test results.

[0109] Once the underlying execution system for automated signal testing is designed, an integrated management system for automated testing is needed to facilitate centralized management of multiple test devices and to implement other auxiliary functions of the automated testing system. This application utilizes the Jenkins integration management tool and the SVN version control tool. By setting up Jenkins and SVN servers, configuring the server environment and tasks, it achieves integrated management of test nodes, automatic deployment of test environments, cyclical execution of test tasks, and email notification of test results. By building an integrated management system using Jenkins (a continuous integration tool) and SVN (a version control tool), it achieves centralized management of multiple test devices, automated deployment of test environments, cyclical execution of test tasks, and automatic notification of results, improving the efficiency and traceability of the testing process. Jenkins acts as the "scheduling center" of the automated testing process, responsible for triggering test tasks, managing test nodes, monitoring execution status, and generating reports. SVN manages test cases, configuration files, test library code, etc.

[0110] Figure 17 This is an architecture diagram of the automated test integration management system provided in this application. It includes integrated management of test nodes, automatic deployment of test environments, cyclical execution of test tasks, and email notification of test results.

[0111] The integration and management instructions for test nodes are as follows: The Jenkins server acts as the master node, managing the various host machine slave nodes through a JNLP agent. Testers access the Jenkins management platform via a browser to centrally manage all slave nodes. Test slave nodes can be expanded on the Jenkins management platform as needed. Testers can configure test task pools on the Jenkins management platform, and these test tasks can be deployed and executed across different test nodes.

[0112] The Jenkins master node centrally manages multiple host machine slave nodes through a JNLP (Java Network Launch Protocol) agent. Test tasks can be dynamically allocated to idle nodes for execution, improving resource utilization and testing efficiency. This Jenkins master node (JNLP agent) + slave node architecture achieves centralized management, elastic scaling, and distributed task execution for test nodes. The master node is responsible for scheduling and monitoring, while the slave nodes are responsible for completing specific test tasks. Their collaboration ensures an efficient and stable testing process.

[0113] The automatic deployment instructions for the test environment are as follows: Automated testing requires deploying code, test cases, timing schemes, etc., on each host computer slave node, and this content is constantly updated to achieve automatic deployment of the host computer slave node test environment. SVN is used to store code, test cases, and timing schemes; the Jenkins SVN plugin is used to automatically download and deploy these resources; and SVN hooks are used to automatically trigger Jenkins' automatic download and deployment tasks when the SVN repository content is updated, thus achieving automatic deployment of the host computer node test environment. Furthermore, the configuration files for different test nodes may differ slightly, and scripts are used to automatically update these configuration files, enabling automatic deployment of the test node environment without human intervention.

[0114] By leveraging the collaboration of SVN (resource storage), Jenkins (deployment execution), SVN hooks (triggering mechanism), and configuration scripts (differentiated processing), fully automated, unattended deployment of the host computer's slave node test environment is achieved, ensuring the consistency and real-time updates of test resources (code, test cases, timing schemes). All resources deployed on all nodes originate from the SVN repository, ensuring version uniformity. Deployment is triggered immediately after an SVN update, ensuring the test environment is synchronized with the latest resources. The entire process from resource updates to environment deployment is automated, reducing manual operations and errors.

[0115] The test task is executed cyclically as follows: By configuring Jenkins build task triggers, test tasks can be executed continuously in a loop. Loop types include timed loops and chained loops between tasks. Jenkins build trigger configuration enables continuous cyclical execution of test tasks, supporting two typical loop modes: timed loops (repeated execution according to a time period) and chained loops between tasks (automatically triggering the next task after one task is completed, forming a chained loop). Jenkins' timed triggers and inter-task triggering mechanisms allow for flexible implementation of cyclical execution of test tasks: timed loops are suitable for periodic, independent test tasks; chained loops are suitable for multi-task chained execution with dependencies. Combined with Jenkins' node management functionality, cyclical tasks can be distributed to different host machine slave nodes, further improving execution efficiency.

[0116] The test results email notification is explained as follows: When an external network access environment is available, the test result email notification function can be directly implemented using the Jenkins email notification plugin; when an external network access environment is not available, a message middleware is used to realize message transmission in both local area network and external network environments, sending the results to designated persons so that they can know the test results in a timely manner.

[0117] Depending on the network environment, two notification strategies are adopted: For environments with external network access, test results are sent directly via the Jenkins email plugin. For environments without external network access, a message middleware (such as RabbitMQ) is used to transmit messages between the local area network and the external network to achieve test result notification. The notification method is selected based on the network environment: the plugin is used directly for external networks, while a middleware acts as a "bridge" for environments without external network access, ultimately ensuring timely delivery of test results.

[0118] Figure 18 This diagram illustrates the underlying execution system scheme for automated testing of signal controllers provided in this application. The solid arrows represent the original manual execution process, while the dashed arrows represent the automated testing execution scheme of this application.

[0119] Considering that current software testing of road traffic signal controllers relies on manual processes, resulting in low automation and a high risk of missed tests, this application focuses on the periodic control of traffic signal controllers. Based on the Robot Framework, it utilizes Python to develop a dedicated automated testing system and device for embedded software testing of traffic signal controllers. This system achieves a complete closed loop for periodic control testing, from scheme issuance to data acquisition and result comparison. Management tools such as Jenkins are used for centralized management of test nodes and cyclical execution of test tasks. This proposal represents a breakthrough in automated testing of periodic control for road traffic signal controllers, saving manpower and time compared to manual testing, and improving testing efficiency and accuracy.

[0120] This application primarily aims to implement an automated testing system and device for the periodic control of road traffic signal controllers. Based on the Robot Framework automated testing framework, this application uses Python to build a signal controller protocol driver test library and leverages hardware simulation fixtures to achieve a complete closed loop for periodic control of the signal controller, from scheme issuance to data acquisition and result comparison. Furthermore, it utilizes the Jenkins integration management tool to achieve centralized management of test nodes and continuous cyclic execution of test tasks.

[0121] This automated testing system comprises two main parts: the signal controller automated testing underlying execution system and the signal controller automated testing integrated management system. The hardware environment of the signal controller automated testing underlying execution system mainly includes a host computer, the signal controller under test, and some hardware simulation fixtures. The host computer software environment is based on the Robot Framework automated testing framework and uses a signal controller protocol driver test library built with Python. By writing and executing test cases, it achieves a complete closed loop for the periodic control of the signal controller, from automatic scheme distribution to automatic output signal acquisition and automatic result judgment.

[0122] The underlying execution system for automated signal controller testing needs to achieve the following functions: 1. Automatic configuration of signal controller testing environment, including scheme creation library, scheme distribution, countdown type configuration, bar screen protocol configuration, time period switching scheme, etc.; 2. Automatic acquisition, analysis, and comparison with expected results of signal controller output data. This includes data from signal light colors, countdown times, and bar screens; 3. Test case writing, execution, and test report generation.

[0123] This application marks the first time that the entire process of periodic control testing for road traffic signal controllers has been automated, resolving the long-standing pain points of low efficiency, frequent missed detections, and excessive time consumption caused by reliance on manual testing in this field. Its highlights include: constructing a complete automated testing closed loop; developing a dedicated testing library based on a mature framework; innovatively solving the problems of simultaneous acquisition and period definition of multi-source data; achieving structured data processing and automatic comparison; and establishing an efficient integrated management system. This system, developed from scratch, is groundbreaking and can significantly improve testing efficiency and quality while reducing risks.

[0124] Figure 19 The schematic diagram of the automated testing device for the periodic control of road traffic signal controllers provided in this application includes: The scheme configuration module 11 is used to configure the test scheme to the target signal machine using an automated test framework; wherein, the test scheme includes at least one of the following: timing scheme, countdown scheme, and bar screen scheme; The data acquisition module 12 is used to acquire the output information corresponding to the test scheme during the testing process of the target signal machine; wherein, if the test scheme is the timing scheme, the light color information is determined by acquiring the voltage value of the phase plate of the target signal machine, and the output information corresponding to the timing scheme is determined based on the light color information; if the test scheme is the countdown scheme or the bar screen scheme, a communication link is established with the target signal machine, and the output information corresponding to the countdown scheme or the bar screen scheme is acquired through the communication link; The scheme comparison module 13 is used to compare the output information corresponding to the test scheme with the test scheme to determine the automated test result of the fixed period control of the target signal machine.

[0125] The scheme configuration module 11 is specifically used to read the timing scheme data to be configured under the specified path in the scheme library using the Python program in the automated testing framework if the test scheme is the timing scheme, reassemble the timing scheme data according to the data format supported by the target signal machine, encapsulate the reassembled timing scheme data into a request data packet, and send the request data packet to the target signal machine.

[0126] The scheme configuration module 11 is specifically used to, if the test scheme is the countdown scheme or the bar screen scheme, use the Python program in the automated test framework to encapsulate the communication interface, define the configuration rules of the countdown scheme or the bar screen scheme, obtain the corresponding MIB node of the target signal machine, and send the configuration rules of the countdown scheme or the bar screen scheme to the corresponding MIB node of the target signal machine through the communication interface.

[0127] The data acquisition module 12 is specifically used to acquire the communication command information of the main control board of the target signal and the voltage value of the phase board respectively; wherein, the communication command information is used to represent the intention information of light color control, and the voltage value of the phase board is used to represent the execution result of the phase board in response to the communication command information; if the intention information of light color control represented by the communication command information is consistent with the execution result of the phase board in response to the communication command information, then the light color information is determined according to the voltage value of the phase board of the target signal.

[0128] The data acquisition module 12 is specifically used to determine the output information corresponding to the timing scheme based on the light color information and the determined period data; wherein, the period data is determined based on the first frame type of the pre-set period start frame data and the second frame type of the period end frame data.

[0129] The data acquisition module 12 is also used to capture key parameters by combining the printed information output by the debugging serial port of the target signal machine with regular expressions if a coordinated transition is triggered, and to determine variable period length data based on the key parameters; and to adjust the determined period data based on the variable period length data; wherein the key parameters include the number of periods, period length and green ratio.

[0130] The data acquisition module 12 is further configured to perform frame data verification on the output information if the test scheme is the timing scheme, wherein the frame data verification includes integrity verification, correctness verification and timing verification; if the verification result of the frame data verification is that the data is normal, the light color data in the output information is structured through the light color recombination algorithm to obtain the output information to be compared corresponding to the test scheme.

[0131] The data acquisition module 12 is further configured to, if the test scheme is the countdown scheme, parse the countdown data in the output information frame by frame according to the countdown protocol to obtain structured countdown data and store it in the form of a data linked list; if the test scheme is the bar screen scheme, parse the bar screen data in the output information frame by frame according to the bar screen protocol to obtain structured bar screen data.

[0132] This application also provides an electronic device, such as Figure 20 As shown, it includes: processor 21, communication interface 22, memory 23 and communication bus 24, wherein processor 21, communication interface 22 and memory 23 communicate with each other through communication bus 24; The memory 23 stores a computer program, which, when executed by the processor 21, causes the processor 21 to perform any of the above method steps.

[0133] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0134] Communication interface 22 is used for communication between the above-mentioned electronic device and other devices.

[0135] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0136] The processors mentioned above can be general-purpose processors, including central processing units, network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits, field-programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0137] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform any of the above method steps.

[0138] This application provides a computer program product, which includes an executable program that, when executed by a processor, implements the method described herein.

[0139] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0140] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. An automated testing method for the periodic control of road traffic signal controllers, characterized in that, The method includes: An automated testing framework is used to configure a test plan onto the target signal controller; wherein the test plan includes at least one of a timing scheme, a countdown scheme, and a bar screen scheme; During the testing of the target signal, the output information corresponding to the test scheme is collected; wherein, if the test scheme is the timing scheme, the light color information is determined by collecting the voltage value of the phase plate of the target signal, and the output information corresponding to the timing scheme is determined based on the light color information; if the test scheme is the countdown scheme or the bar screen scheme, a communication link is established with the target signal, and the output information corresponding to the countdown scheme or the bar screen scheme is collected through the communication link; The output information corresponding to the test scheme is compared with the test scheme to determine the automated test result of the fixed-period control of the target signal machine.

2. The method as described in claim 1, characterized in that, The step of configuring the test plan onto the target signal machine using an automated testing framework includes: If the test plan is the timing plan, the Python program in the automated test framework reads the timing plan data to be configured from the specified path in the plan library, reassembles the timing plan data according to the data format supported by the target signal, encapsulates the reassembled timing plan data into a request data packet, and sends the request data packet to the target signal.

3. The method as described in claim 1, characterized in that, The step of configuring the test plan onto the target signal machine using an automated testing framework includes: If the test plan is the countdown plan or the bar screen plan, the communication interface is encapsulated using the Python program in the automated test framework, the configuration rules of the countdown plan or the bar screen plan are defined, and the corresponding MIB node of the target signal machine is obtained; the configuration rules of the countdown plan or the bar screen plan are sent to the corresponding MIB node of the target signal machine through the communication interface.

4. The method as described in claim 1, characterized in that, By collecting the voltage value of the phase plate of the target signal receiver, the light color information is determined, including: The communication command information of the main control board of the target signal and the voltage value of the phase board are collected respectively; wherein, the communication command information is used to represent the intention information of light color control, and the voltage value of the phase board is used to represent the execution result of the phase board in response to the communication command information; if the intention information of light color control represented by the communication command information is consistent with the execution result of the phase board in response to the communication command information, then the light color information is determined according to the voltage value of the phase board of the target signal.

5. The method as described in claim 1, characterized in that, The output information corresponding to the timing scheme determined based on the light color information includes: Based on the light color information and the determined cycle data, the output information corresponding to the timing scheme is determined; wherein, the cycle data is determined based on the first frame type of the pre-set cycle start frame data and the second frame type of the cycle end frame data.

6. The method as described in claim 5, characterized in that, The method further includes: If a coordinated transition is triggered, the key parameters are captured by combining the printed information output from the debugging serial port of the target signal machine with regular expressions, and the variable period length data is determined based on the key parameters; the determined period data is adjusted based on the variable period length data; wherein, the key parameters include the number of periods, the period length, and the green ratio.

7. The method as described in claim 1, characterized in that, After collecting the output information corresponding to the test plan, and before comparing the output information corresponding to the test plan with the test plan, the method further includes: If the test scheme is the timing scheme, the output information is subjected to frame data verification, wherein the frame data verification includes integrity verification, correctness verification and timing verification; if the verification result of the frame data verification is that the data is normal, the light color data in the output information is processed in a structured manner through the light color recombination algorithm to obtain the output information to be compared corresponding to the test scheme.

8. The method as described in claim 1, characterized in that, After collecting the output information corresponding to the test plan, and before comparing the output information corresponding to the test plan with the test plan, the method further includes: If the test scheme is the countdown scheme, the countdown data in the output information is parsed frame by frame according to the countdown protocol to obtain structured countdown data, which is then stored in the form of a data linked list; If the test scheme is the bar screen scheme, the bar screen data in the output information is parsed frame by frame according to the bar screen protocol to obtain structured bar screen data.

9. An automated test integration management method based on the automated test method for the periodic control of road traffic signal controllers according to any one of claims 1 to 8, characterized in that, The method includes: By using the Jenkins integration management tool and SVN version control tool, a Jenkins server and an SVN server are set up, and the environment and tasks of the Jenkins server and SVN server are configured to realize the functions of integrated management of test nodes, automatic deployment of test environment, cyclic execution of test tasks, and notification of test results.

10. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-9.

Images