A broadcast multi-board parallel test method, system, medium and product

Abstract

The application provides a broadcast multi-board parallel test method, system, medium and product, relates to the electronic manufacturing board test technical field, and the method comprises the following steps: a broadcast test instruction makes a plurality of to-be-tested boards start executing target test items at the same time. An initial token frame address list to be collected establishes an ordered mechanism for board access, and a first data segment provides a unified data collection space. In a token frame transmission operation, the first to-be-tested board executes differentiated token frame processing operations according to its own test state: in an unfinished state, the token frame is directly forwarded; in a completed state, test completion result data is written into the first data segment and the address list to be collected is updated. This makes the boards that have completed the test automatically exit the loop, and the boards that have not completed the test continue to participate in token transmission until the address list to be collected is empty, and the test results of all the boards are collected into the first token frame. In this way, the technical problem of low time utilization efficiency in the multi-board parallel test process in the prior art is solved.

Description

Technical Field

[0001] This application relates to the field of electronic manufacturing board testing technology, and in particular to a broadcast-type multi-board parallel testing method, system, medium and product. Background Technology

[0002] In the field of electronic product manufacturing, functional testing and performance verification are required for mass-produced circuit boards. Traditional board testing methods employ a serial testing mode, where a host computer sequentially tests each board via a bus. Only after each board completes all test items is the next board tested. This serial testing method results in a linear increase in total testing time as the number of boards increases. When testing large batches of boards, the excessively long testing cycle severely impacts production efficiency, increases production costs, and fails to meet the testing requirements of modern large-scale production.

[0003] In related technologies, to address the aforementioned technical problems, a parallel test control method based on broadcast commands has been proposed. This method involves a host computer broadcasting test commands to all boards on the bus, enabling all boards to simultaneously execute the same test items. Specifically, after the host computer sends the broadcast command to start parallel testing on all boards, it waits for a preset test completion time and then polls each board sequentially to obtain the test results. This reduces the total test time from single-board test time × number of boards to single-board test time + polling time, thereby improving the testing efficiency of batch boards to a certain extent.

[0004] However, the parallel test control method described above relies solely on a preset fixed waiting time to determine the test completion status of all boards. It cannot dynamically adjust the timing of result collection based on the actual test progress of each board. Therefore, even if most boards have completed the test ahead of schedule, the system still needs to wait for the preset time before it can start polling, resulting in unnecessary time waste. Furthermore, when the test time of individual boards exceeds the preset value, it will lead to incomplete data acquisition, which in turn results in low time utilization efficiency in the parallel testing process of multiple boards in related technologies. Summary of the Invention

[0005] This application provides a broadcast-style multi-board parallel testing method, system, medium, and product to improve the time utilization efficiency of the multi-board parallel testing process.

[0006] Firstly, this application provides a broadcast-style multi-board parallel testing method, applied to the aforementioned broadcast-style multi-board parallel testing system. The method includes: sending a broadcast test command to multiple boards under test connected on a bus, so that the multiple boards under test simultaneously begin executing a target test item, each board under test having a unique address number; after sending the broadcast test command, generating an initial token frame, the initial token frame including a list of addresses to be collected and a first data segment, the list of addresses to be collected including address numbers of all boards under test sorted; using the initial token frame as a loop variable, performing the following token frame passing operation until the address to be collected in the initial token frame is reached. If the list is empty, the first token frame is obtained: The initial token frame is sent to the first test board corresponding to the first address number in the address numbering order, to trigger the first test board to perform token frame processing operation on the initial token frame according to its own test status. Specifically: if the first test board determines that its test status is incomplete, it sends the initial token frame to the next test board corresponding to the next address number; if the first test board determines that its test status is complete, it writes the test completion result data into the first data segment, removes the first address number from the list of addresses to be collected, and updates the next address number with the first address number.

[0007] By adopting the above technical solution, broadcast test commands enable multiple boards under test to simultaneously execute target test items, achieving parallelization of test startup and eliminating the time overhead of serial startup. The initial token frame includes a list of addresses to be collected, establishing an ordered mechanism for board access, and the first data segment provides a unified data collection space. In the token frame transmission operation, the first board under test performs differentiated token frame processing operations based on its own test status: in the incomplete state, the token frame is forwarded directly to avoid blocking and waiting; in the completed state, the test completion result data is written to the first data segment and the list of addresses to be collected is updated, realizing the dynamic integration of data collection and token transmission. This allows boards that have completed the test to automatically exit the loop, while boards that have not completed the test continue to participate in token transmission until the list of addresses to be collected is empty, and the test results of all boards are collected in the first token frame, achieving efficient parallel processing of test execution and data collection. This solves the technical problem of low time utilization efficiency in the multi-board parallel testing process in related technologies, achieving the technical effect of improving the time utilization efficiency of the multi-board parallel testing process.

[0008] Optionally, after sending the initial token frame to the first test board corresponding to the first address number in the address numbering sequence, the method further includes: starting a token monitoring timer to monitor the execution process of the token frame transmission operation for a preset duration; determining that the token frame processing operation has malfunctioned if the first token frame is not received when the token monitoring timer reaches the preset duration; sending a token status query command to each test board to identify the faulty front-end board holding the current token frame; identifying the test board corresponding to the next address number adjacent to the address number of the faulty front-end board in the current collection address list of the current token frame as the faulty test board; deleting the address number of the faulty test board from the current collection address list of the current token frame to obtain a current recovery token frame including the current recovery address list; and sending a token recovery command to the faulty front-end board to control the faulty front-end board to send the current recovery token frame to the test board corresponding to the next address number adjacent to the address number of the faulty test board in the current recovery address list.

[0009] By adopting the above technical solution, the token monitoring timer monitors the execution process of the token frame transmission operation in real time, and the preset duration provides a time benchmark for anomaly detection. When the timer reaches the preset duration and the first token frame has not been received, the anomaly handling mechanism is triggered. The token status query command is broadcast to all boards under test to quickly locate the faulty front-end board holding the current token frame. Based on the address number of the faulty front-end board, adjacent faulty boards under test are accurately identified in the current list of addresses to be collected. By deleting the address number of the faulty board under test from the current list of addresses to be collected, a current recovery token frame is generated, and the token transmission link is reconstructed. The token recovery command controls the faulty front-end board to send the current recovery token frame to the next board under test after the faulty board under test, bypassing the faulty node to recover token transmission. This proactive fault detection and recovery mechanism avoids the entire testing process from being interrupted by a single point of failure, ensuring the robustness of multi-board parallel testing.

[0010] Optionally, a token status query command is sent to each board under test to determine the faulty front-end board holding the current token frame. Specifically, this includes: sending a token status query command including a token identifier to each board under test, where the token identifier is the unique identifier of the initial token frame; receiving token status response information returned by each board under test, where each token status response information includes the address number and token processing status of the corresponding board under test; and determining the faulty front-end board based on the token status response information.

[0011] By adopting the above technical solution, the token identifier serves as the unique identifier of the initial token frame, ensuring the accuracy of token status queries and avoiding confusion in multi-token environments. A token status query command, including the token identifier, is sent to each board under test (DUT), enabling parallel collection of status information. The token status response information returned by each DUT includes two key elements: an address number and a token processing status. The address number identifies the responding board, and the token processing status reflects the interaction status between the board and the token frame. By aggregating all token status response information, a global token flow view is established. Based on this global view, the current location and transmission path of the token frame can be accurately analyzed, thereby precisely identifying the upstream board of the fault. This query mechanism based on a unique identifier and the response structure including dual information provide efficient and reliable fault location capabilities, providing an accurate foundation for subsequent fault recovery.

[0012] Optionally, when the token processing status is in the holding status, the token status response information includes the token reception timestamp; determining the fault-preceding board based on the token status response information specifically includes: filtering out the first response information where the token processing status is in the holding status from all token status response information; when there is one first response information, determining the board under test corresponding to the address number in the first response information as the fault-preceding board; when there are multiple first response information, sorting the multiple first response information according to the token reception timestamp, and determining the board under test corresponding to the address number in the last first response information after sorting as the fault-preceding board.

[0013] By employing the above technical solution, the token reception timestamp records the precise moment each board receives the token, providing a timing basis for determining multiple holding state conflicts. The first response information of the holding state is filtered from all token state response information, focusing on the set of boards that actually hold the token. When only one first response information exists, the corresponding board is directly identified as the faulty preceding board, achieving rapid location. When multiple first response information exists, it indicates a token duplication or state synchronization anomaly. In this case, the token reception timestamp plays a crucial role: by sorting the timestamps chronologically, the true path of token transmission is determined, and the board corresponding to the last timestamp is the last board to receive the token, i.e., the true faulty preceding board. This timestamp-based conflict resolution mechanism effectively handles the problem of multiple holding states caused by network latency or asynchronous state updates, ensuring the accuracy and uniqueness of fault location.

[0014] Optionally, when the token processing status is forwarded, the token status response information includes the token forwarding target address; determining the faulty front-end board based on the token status response information specifically includes: when none of the token status responses are in the holding state, filtering out the second response information with the token processing status being forwarded from all the token status response information; determining the token delivery path based on the address number and token forwarding target address in each second response information; in the token delivery path, searching for the token delivery endpoint that meets at least one of the following conditions: the board under test corresponding to the token forwarding target address does not return the second response information; the token processing status in the second response information returned by the board under test corresponding to the token forwarding target address is not forwarded; and identifying the board under test with the token forwarding target address as the token delivery endpoint as the faulty front-end board.

[0015] By adopting the above technical solution, the token forwarding target address records the token transmission destination of each board, forming a complete transmission link information. When there is no holding state, the token transmission path is reconstructed from the second response information of the forwarded state. The address number of each second response information and the token forwarding target address constitute a directed edge, and multiple edges are connected to form a token transmission path graph. The token transmission endpoint is found in this path, and two judgment conditions cover different fault scenarios: no second response information is returned, indicating that the board has completely failed; the returned token processing status is not the forwarded state, indicating that the board's processing after receiving the token is abnormal. The node before the token transmission endpoint is the faulty board, realizing accurate location based on path analysis. This path tracing mechanism makes full use of distributed state information, and even if the token is lost, the fault location can be recovered through historical paths, improving the completeness of fault diagnosis.

[0016] Optionally, after obtaining the first token frame, the method further includes: performing data extraction processing on the first token frame to extract the test completion result data of all boards under test from the first data segment to obtain a test completion result dataset; performing pass / fail judgment processing on the test completion result dataset according to the preset test item standard requirements to generate a test pass report, the test pass report including the mapping relationship between address number and pass / fail judgment result; adding the address number corresponding to the board under test with a pass / fail judgment result of unqualified to the retest address list to generate a retest token frame, the retest token frame including the retest address list and the second data segment; using the retest token frame as a loop variable to perform the retest token frame passing operation until the retest address list in the retest token frame is empty, to obtain the second token frame.

[0017] By adopting the above technical solution, the data extraction and processing can batch extract the test completion results data of all boards under test from the first data segment, forming a centralized test completion result dataset, which enables unified management of distributed data. Preset test item standards provide an objective benchmark for pass / fail judgment. The generated test pass report establishes a board-level quality archive through the mapping relationship between address numbers and pass / fail judgment results. The address numbers of unqualified boards are added to the retest address list, achieving precise screening of faulty boards. The retest token frame includes a retest address list and a second data segment, inheriting the structural advantages of the initial token frame, and only performing the retest token frame transmission operation for unqualified boards. This selective retest mechanism avoids repeated testing of all boards. The second data segment independently collects retest data, forming a basis for comparative analysis with the first data segment, improving testing efficiency and the targeted nature of fault diagnosis.

[0018] Optionally, before using the retest token frame as a loop variable to perform the retest token frame transmission operation, the method further includes: performing fault type analysis on each board under test in the retest address list using the test completion result dataset to determine the fault type of each board under test in the retest address list; generating corresponding retest parameter configurations for each board under test in the retest address list according to the fault type, the retest parameter configurations including the number of retests, test depth level, and diagnostic mode flag; and sending a retest configuration command to each board under test in the retest address list so that each board under test in the retest address list re-executes the retest according to the retest parameter configuration in the received retest configuration command. The target test items are executed as follows: each board under test in the retest address list executes the target test item a corresponding number of times based on the number of retests; the test coverage of each board under test in the retest address list is adjusted according to the test depth level; each board under test in the retest address list determines the data recording level according to the diagnostic mode flag, where: when the diagnostic mode flag is basic mode, the test pass result data or test failure result data of the target test item is recorded; when the diagnostic mode flag is diagnostic mode, the test process data of the target test item is recorded, and the test process data includes the test step execution sequence, intermediate test parameters, fault triggering conditions, and abnormal status information.

[0019] By adopting the above technical solution, fault type analysis utilizes the test completion result dataset to deeply mine the failure modes of each board under test, providing a basis for differentiated retesting decisions. Three dimensions of retest parameter configuration enable precise test customization: the number of retests is dynamically adjusted based on the sporadic nature of the fault type, avoiding one-size-fits-all repetitive testing; the test depth level expands or contracts the test coverage, achieving a balance between test completeness and efficiency; and the diagnostic mode flag controls the granularity of data recording. The basic mode only records result data to reduce storage overhead, while the diagnostic mode records detailed data such as the test step execution sequence, intermediate test parameters, fault triggering conditions, and abnormal state information, providing complete process information for in-depth fault analysis. This intelligent configuration mechanism based on fault type enables each board to obtain the most suitable retesting strategy for its fault characteristics, improving the accuracy of fault location and retesting efficiency.

[0020] Secondly, embodiments of this application provide a broadcast multi-board parallel testing system, which includes: one or more processors and a memory; the memory is coupled to one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the broadcast multi-board parallel testing system to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer program product including instructions that, when the computer program product is run on a broadcast multi-board parallel test system, cause the broadcast multi-board parallel test system to execute the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a broadcast multi-board parallel test system, cause the broadcast multi-board parallel test system to perform the method described in the first aspect and any possible implementation thereof. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating a method for suppressing broadcast-style multi-board parallel testing in an embodiment of this application. Figure 2 This is a block diagram of a broadcast-type multi-board parallel testing system in an embodiment of this application; Figure 3 This is a schematic diagram of the physical device structure of a broadcast-type multi-board parallel testing system in the embodiments of this application. Detailed Implementation

[0024] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0025] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0026] This application provides a broadcast-based parallel testing method for multiple boards, see reference. Figure 1 , Figure 1 This is a flowchart illustrating a broadcast-style multi-board parallel testing method in an embodiment of this application, including the following steps: Step S101: Send a broadcast test command to multiple boards under test connected on the bus so that multiple boards under test can start executing the target test item at the same time. Each board under test has a unique address number. Step S102: After sending the broadcast test command, an initial token frame is generated. The initial token frame includes a list of addresses to be collected and a first data segment. The list of addresses to be collected includes the address numbers of all the boards under test in sorted order. Step S103: Using the initial token frame as a loop variable, perform the following token frame passing operation until the list of addresses to be collected in the initial token frame is empty, thus obtaining the first token frame: Send the initial token frame to the first test board corresponding to the first address number in the address numbering order, to trigger the first test board to perform token frame processing operation on the initial token frame according to its own test status, wherein: if the first test board determines that its own test status is incomplete, it sends the initial token frame to the next test board corresponding to the next address number; if the first test board determines that its own test status is complete, it writes the test completion result data into the first data segment, deletes the first address number from the list of addresses to be collected, and updates the next address number to the first address number.

[0027] In the above embodiment, taking a production test line of a communication equipment manufacturing company as an example, this production test line needs to perform functional tests on mass-produced network interface boards. The parallel test system includes a test host and eight network interface boards under test connected via a CAN bus. Each board has a unique address number (0x01 to 0x08). The target test item is the data transmission and reception function test of the board, including three sub-items: transmission rate test, reception sensitivity test, and bit error rate test. The specific implementation process is as follows: the test host sends a broadcast test command to the eight boards under test via the CAN bus. The broadcast test command uses the CAN bus broadcast address 0xFF, and the command content includes the test item code (0x1001) and test parameters (transmission power 10dBm, test data packet length 1024 bytes, test duration 60 seconds). After receiving the broadcast test command, the eight boards under test simultaneously start their respective test programs and begin to execute the data transmission and reception function test. The test host generates an initial token frame 100 milliseconds after sending the broadcast test command. The data structure of the initial token frame includes: a frame header: including a token identifier (0xABCD), a frame type identifier (0x01 indicates a test token), and a creation timestamp; a list of addresses to be collected: including 8 address numbers sorted from smallest to largest (0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08), with a list length field value of 8; and a first data segment: reserving 2048 bytes of storage space, initially filled with 0x00, used to store the test result data of each board.

[0028] In the above embodiment, the token frame cyclic transmission process is as follows: In the first cycle (T=0 seconds), the test host sends the initial token frame to the board with address number 0x01. After receiving the token frame, the board checks its own test status. At this time, the test has just started for 10 seconds and has not yet been completed, so it directly forwards the token frame to the board with address number 0x02. This continues, with the token frame being rapidly transmitted among the 8 boards. The processing time for each board is approximately 5 milliseconds. After completing one cycle, the token frame returns to the test host, with a total time of approximately 40 milliseconds. In the second to tenth cycles (T=0.04 seconds to T=0.4 seconds), the token frame continues to cyclically transmit among the boards. The test status of all boards is incomplete, and the content of the token frame remains unchanged. In the eleventh cycle (T=45 seconds), the board with address number 0x03 completes the test first. When the token frame is delivered to the board, the board performs the following operations: writes the test result data (including average transmission rate of 985Mbps, receiver sensitivity of -85dBm, bit error rate of 0.0001%, totaling 128 bytes) to offset address 256 of the first data segment (a reserved position for the third board); deletes 0x03 from the list of addresses to be collected, updates the list to [0x01, 0x02, 0x04, 0x05, 0x06, 0x07, 0x08], and updates the length to 7; and sends the modified token frame to the board with address number 0x04.

[0029] In the above embodiment, during the twelfth to fifteenth rounds (T=45.04 seconds to T=58 seconds), boards with address numbers 0x05, 0x01, and 0x07 successively complete the test and update their token frames according to the same processing logic. The list of addresses to be collected is gradually shortened to [0x02, 0x04, 0x06, 0x08]. During the sixteenth to twentieth rounds (T=58.04 seconds to T=65 seconds), the remaining four boards successively complete the test and update their token frames. When board with address number 0x08 completes data writing and deletes its own address, the list of addresses to be collected becomes empty, and the token frame is converted to the first token frame. The test host receives the first token frame with an empty list of addresses to be collected, confirming that all boards have completed the test. At this time, the first data segment includes the complete test result data of the eight boards. The data of each board is stored according to a predetermined offset address, which facilitates subsequent data parsing and analysis.

[0030] Through the above steps, the broadcast test command enables multiple boards under test to simultaneously execute the target test items, achieving parallelization of test startup and eliminating the time overhead of serial startup. The initial token frame includes a list of addresses to be collected, establishing an ordered mechanism for board access, and the first data segment provides a unified data collection space. In the token frame transmission operation, the first board under test performs differentiated token frame processing operations based on its own test status: in the incomplete state, the token frame is forwarded directly to avoid blocking and waiting; in the completed state, the test completion result data is written to the first data segment and the list of addresses to be collected is updated, realizing the dynamic integration of data collection and token transmission. This allows boards that have completed the test to automatically exit the loop, while boards that have not completed the test continue to participate in token transmission until the list of addresses to be collected is empty, and the test results of all boards are collected in the first token frame, achieving efficient parallel processing of test execution and data collection. This solves the technical problem of low time utilization efficiency in the multi-board parallel testing process in related technologies, achieving the technical effect of improving the time utilization efficiency of the multi-board parallel testing process.

[0031] The entity executing the above steps can be a system, such as a broadcast multi-board parallel test system, or a test device, or a controller or processor in the device or system, or a standalone controller or processor, or other processing devices or processing units with similar processing functions, but is not limited to these.

[0032] In an optional embodiment, after sending the initial token frame to the first test board corresponding to the first address number in the address numbering sequence, the method further includes: starting a token monitoring timer to monitor the execution process of the token frame transmission operation for a preset duration; determining that the token frame processing operation has malfunctioned if the first token frame is not received when the token monitoring timer reaches the preset duration; sending a token status query command to each test board to identify the faulty front-end board holding the current token frame; identifying the test board corresponding to the next address number adjacent to the address number of the faulty front-end board in the current collection address list of the current token frame as the faulty test board; deleting the address number of the faulty test board from the current collection address list of the current token frame to obtain a current recovery token frame including the current recovery address list; and sending a token recovery command to the faulty front-end board to control the faulty front-end board to send the current recovery token frame to the test board corresponding to the next address number adjacent to the address number of the faulty test board in the current recovery address list.

[0033] In the above embodiment, based on the production test line scenario of the aforementioned communication equipment manufacturer, a token monitoring and fault recovery mechanism was added during the parallel testing of eight network interface boards. The test system configuration remained unchanged; the eight boards were numbered 0x01 to 0x08 and connected via a CAN bus. After sending the initial token frame to the first board under test (address 0x01), the test host immediately started a token monitoring timer. The preset duration of this timer was set to 5 seconds. This duration was determined based on the following considerations: under normal circumstances, it takes approximately 40-50 milliseconds for a token frame to complete one round of transmission among the eight boards. A 5-second monitoring cycle can cover approximately 100 rounds of normal transmission, ensuring timely detection of anomalies without accidental triggering due to normal processing delays. The token monitoring timer was implemented using an independent hardware timer module, running in parallel with the main test process without affecting the normal transmission of token frames. After the timer started, the test host continued to listen to the bus, waiting for the token frame to return. At the 32-second mark of the test, it was assumed that the board at address 0x05 failed to forward the received token frame normally due to an internal processing anomaly. At this point, the token frame transmission path is: 0x01→0x02→0x03→0x04→0x05 (stalled). The token monitoring timer reaches its preset duration 5 seconds after startup. The test host detects that no returned token frame (whether the initial token frame or the updated token frame) has been received, immediately determining that the token frame processing operation has malfunctioned and triggering the fault diagnosis process.

[0034] In the above embodiment, the test host sends a token status query command to eight boards on the bus. This command is broadcast and includes the identifier 0xABCD of the current token. After receiving the query command, each board returns token status response information within 10 milliseconds: Board 0x01 returns: Address number 0x01, token processing status "forwarded", forwarding target address 0x02; Board 0x02 returns: Address number 0x02, token processing status "forwarded", forwarding target address 0x03; Board 0x03 returns: Address number 0x03, token processing status "forwarded", forwarding target address 0x04; Board 0x04 returns: Address number 0x04, token processing status "forwarded", forwarding target address 0x05; Board 0x05 returns: Address number 0x05, token processing status "held"; Boards 0x06 to 0x08 return: their respective address numbers, token processing status "not received". Based on the response information, the test host identifies the board with address 0x05 as the faulty preceding board because it currently holds a token frame but fails to forward it correctly. The test host accesses the current list of addresses to be collected for the current token frame. Assuming that board 0x03 has already completed testing and been removed from the list, the current list of addresses to be collected is [0x01, 0x02, 0x04, 0x05, 0x06, 0x07, 0x08]. In this list, the next address after the faulty preceding board 0x05 is 0x06, therefore, the board with address 0x06 is identified as the faulty board under test. This judgment is based on the following logic: the inability of board 0x05 to forward the token frame to 0x06 indicates a problem with the transmission path from 0x05 to 0x06, which may be due to a malfunction in the receiving function of board 0x06 or a communication link failure.

[0035] In the above embodiment, the test host performs the following recovery operations: 1) Generate a current recovery token frame: Delete the address number of the faulty test board 0x06 from the current list of addresses to be collected [0x01, 0x02, 0x04, 0x05, 0x06, 0x07, 0x08] to obtain the current recovery address list [0x01, 0x02, 0x04, 0x05, 0x07, 0x08]. The current recovery token frame retains the original first data segment content (including the result data of the tested board 0x03), and only updates the list of addresses to be collected. 2) Send a token recovery command: The test host sends a token recovery command to the faulty front-end board 0x05. This command includes three key pieces of information: token identifier 0xABCD, indicating the token to be recovered; recovery action identifier 0x02, instructing the board to perform a token forwarding operation; and target address 0x07, which is the next address after the faulty test board 0x06 in the current recovery address list. 3) Token Passing Recovery: After receiving the token recovery command, board 0x05 directly sends its token frame (updated to the current recovery token frame) to board 0x07, bypassing the faulty board 0x06. Upon receiving the token frame, board 0x07 continues the normal token passing process, passing the token frame to 0x08 and finally returning it to the test host. After token passing recovery, the test process continues. The faulty board 0x06 is excluded from the token loop and no longer participates in subsequent test data collection. The test host records the fault status of this board and marks it as "communication failure, test incomplete" in the final test report. The remaining 7 boards continue to execute the test until all boards complete the test or the test timeout period is reached. The final first token frame includes the test result data of the 7 normal boards, achieving test process continuity even under single-point failure conditions.

[0036] In an optional embodiment, a token status query command is sent to each board under test to determine the faulty front-end board holding the current token frame. Specifically, this includes: sending a token status query command including a token identifier to each board under test, where the token identifier is a unique identifier of the initial token frame; receiving token status response information returned by each board under test, where each token status response information includes the address number and token processing status of the corresponding board under test; and determining the faulty front-end board based on the token status response information.

[0037] In the above embodiment, taking the parallel testing scenario of testing six data acquisition boards on a production line of an electronic device as an example, the board address numbers are 0x11, 0x12, 0x13, 0x14, 0x15, and 0x16, respectively, and they are connected to the test host via an RS485 bus. The specific implementation process of token status query is as follows: when generating the initial token frame, the test host assigns a unique identifier to the token frame. In this embodiment, the token identifier uses a 32-bit value, consisting of the following parts: high 16 bits: test batch number, which is 0x2024 in this case; low 16 bits: serial number, which is 0x0856 in this case; complete token identifier: 0x20240856. This token identifier is written into the frame header of the initial token frame and remains unchanged throughout the test. Each board under test extracts and temporarily stores the token identifier when it receives the initial token frame. Assume that at the 18th second of the test process, the token monitoring timer detects an abnormality in the token frame transmission. The test host immediately constructs a token status query command. The data structure of this command includes: a command type field (0xCC) indicating a token status query; a broadcast address field (0xFF) indicating that it will be sent to all boards; a token identifier field (0x20240856) used by the board to identify the query target; a query timestamp recording the system time of sending the query; and a checksum field calculated using a CRC16 checksum. The complete query command is 12 bytes long and is broadcast to all boards under test via the RS485 bus.

[0038] In the above embodiments, after each board under test receives the token status query command, it performs the following processing: Board 0x11's response process: Extracts the token identifier 0x20240856 from the query command; checks its own token processing record, finding that the token was received and forwarded at 17.2 seconds; constructs response information: address number 0x11 + token processing status "forwarded" (encoded as 0x01) + forwarding timestamp 17.2 seconds + forwarding target address 0x12. Board 0x12's response process: Performs the same identifier matching; the query record shows that the token was received and forwarded at 17.3 seconds; constructs response information: address number 0x12 + token processing status "forwarded" (0x01) + forwarding timestamp 17.3 seconds + forwarding target address 0x13. Response process of board 0x13: Identifier match successful; record shows that the token was received at 17.4 seconds and is currently still held; construct response information: address number 0x13 + token processing status "held" (encoded as 0x02) + reception timestamp 17.4 seconds + expected forwarding address 0x14. Response process of boards 0x14, 0x15, and 0x16: After identifier matching, no processing record for the token was found; construct response information for each: their respective address number + token processing status "not received" (encoded as 0x00) + empty timestamp + empty address field.

[0039] In the above embodiment, to avoid bus conflicts caused by multiple cards responding simultaneously, a time-division response mechanism based on address numbers is adopted: each card calculates its response delay time = (last digit of the address number) × 20 milliseconds; card 0x11 sends its response after a 20-millisecond delay; card 0x12 sends its response after a 40-millisecond delay; card 0x13 sends its response after a 60-millisecond delay; and so on, with card 0x16 sending its response after a 120-millisecond delay. This staggered response sequence ensures the orderliness of bus communication. Within 200 milliseconds after sending the query command, the test host successively receives token status response information from 6 cards. The test host analyzes the received response information: 1) Summary of response information: Card 0x11: Forwarded, forwarded to 0x12; Card 0x12: Forwarded, forwarded to 0x13; Card 0x13: Holding; Card 0x14: Not received; Card 0x15: Not received; Card 0x16: Not received. The test host determines the status based on the logical relationship of the token processing status: "Forwarded" indicates that the board successfully received and forwarded the token; "Holding" indicates that the board received the token but failed to forward it successfully; "Not Received" indicates that the board has not yet received the token. Analysis determined that board 0x13 was the preceding board due to the following reasons: this board currently holds a token frame (status: "Holding"); subsequent boards 0x14, 0x15, and 0x16 did not receive the token; indicating that token transmission was interrupted at board 0x13. To further verify the diagnostic results, the test host performed a supplementary query: sending a detailed status query command to board 0x13; board 0x13 returned detailed information: token reception was normal, but no acknowledgment response was received when attempting to forward it to 0x14, and it failed after 3 retries, therefore maintaining the holding state. This supplementary information confirmed that board 0x13 was indeed the preceding board, and the problem occurred in the transmission link from 0x13 to 0x14.

[0040] In an optional embodiment, when the token processing status is in the holding status, the token status response information includes a token reception timestamp; determining the fault pre-fault board based on the token status response information specifically includes: filtering out the first response information where the token processing status is in the holding status from all token status response information; when there is one first response information, determining the board under test corresponding to the address number in the first response information as the fault pre-fault board; when there are multiple first response information, sorting the multiple first response information according to the token reception timestamp, and determining the board under test corresponding to the address number in the last first response information after sorting as the fault pre-fault board.

[0041] In the above embodiment, a parallel testing scenario is described using 10 control boards from an industrial control system production line. The 10 boards are numbered 0x21 to 0x2A and interconnected via a CAN bus. During testing, due to communication interference or board processing abnormalities, multiple boards may simultaneously hold tokens, requiring accurate identification of the true faulty board. Each board under test has a built-in hardware real-time clock module that synchronizes with the test host upon system startup. When a board receives a token frame, it immediately reads the current clock value as the token reception timestamp. The timestamp uses a 32-bit millisecond counter format, counting from the start of the test. For example, if board 0x24 receives a token frame at 45678 milliseconds after the test starts, the token reception timestamp is recorded as 45678. This timestamp, along with the token identifier, is stored in the board's token status register.

[0042] In the above embodiments, the fault location of a single holding state is implemented as follows: for a normal single point of failure, when the test is in progress for a certain time, the token monitoring timer triggers anomaly detection. After the test host sends a token status query command (including token identifier 0x33445566), it receives response information from 10 boards: Board 0x21 responds: Address number 0x21, token processing status is "forwarded" (encoding 0x01); Board 0x22 responds: Address number 0x22, token processing status is "forwarded" (encoding 0x01); Board 0x23 responds: Address number 0x23, token processing status is "forwarded" (encoding 0x01); Board 0x24 responds: Address number 0x24, token processing status is "forwarded" (encoding 0x01); Board 0x25 responds: Address number 0x25, token processing status is "held" (encoding 0x02), token reception timestamp is 87234; Boards 0x26 to 0x2A respond: their respective address numbers, token processing status is "not received" (encoding 0x00). The process for identifying the faulty pre-fault board is as follows: 1) The test host filters all response messages for the first response message with a token processing status of "held"; 2) Only the response message from board 0x25 meets the criteria; 3) Since there is only one first response message, the board under test corresponding to address 0x25 is directly identified as the faulty pre-fault board. This situation indicates that the token frame is stuck at board 0x25, and the board failed to forward the token to the next board after receiving it.

[0043] In the above embodiments, the fault location of multiple holding states is implemented as follows: In complex multiple holding situations, under certain special circumstances, such as electromagnetic interference to bus communication or data distortion of token frames during transmission, multiple boards may think that they hold the token. After the test host sends a token status query command, it receives the following response information: Board 0x21 response: Address number 0x21, token processing status is "Forwarded"; Board 0x22 response: Address number 0x22, token processing status is "Forwarded"; Board 0x23 response: Address number 0x23, token processing status is "Holding", token reception timestamp is 65432; Board 0x24 response: Address number 0x24, token processing status is "Not Received"; Board 0x25 response: Address number 0x25, token processing status is "Holding", token reception timestamp is 65890; Board 0x26 response: Address number 0x26, token processing status is "Not Received"; Board 0x27 response: Address number 0x27, token processing status is "Holding", token reception timestamp is 66125; Boards 0x28 to 0x2A responses: token processing status is "Not Received". Analysis and processing of multiple holding states: 1) The test host filters out the first response information of three tokens with the "holding state": the response information of board 0x23, timestamp 65432; the response information of board 0x25, timestamp 65890; and the response information of board 0x27, timestamp 66125. 2) Sort the tokens in ascending order according to the token reception timestamp: First: board 0x23, timestamp 65432 (earliest); Second: board 0x25, timestamp 65890 (middle); Third: board 0x27, timestamp 66125 (latest). 3) Select the first response information at the end of the sorted list, that is, the board under test corresponding to board 0x27 (timestamp 66125), and determine it as the fault precursor board.

[0044] In the above embodiments, the causes of multiple token holding are analyzed as follows: This multiple token holding situation may be caused by the following reasons: When board 0x22 forwards the token to 0x23, the token frame is copied or retransmitted due to bus interference; board 0x23 receives the token but fails to process it properly, causing abnormal propagation of the token frame; distorted token frames are incorrectly identified as valid tokens by boards 0x25 and 0x27. The logic for selecting the board with the latest timestamp as the fault-preceding board is that the board that last received the token is most likely the actual end point of the token transmission chain, and its inability to continue forwarding the token leads to the interruption of the entire transmission process. Handling timestamp anomalies: If multiple boards receive tokens with identical timestamps (possibly due to clock precision limitations or simultaneous reception of distorted broadcast tokens), the test host employs a supplementary judgment rule: Assuming both boards 0x24 and 0x26 report a holding status with timestamps of 78900: First, sort by timestamp, with both tied at the bottom; second, sort by address number, with 0x26 being greater than 0x24; finally, board 0x26 is determined to be the preceding fault board. This supplementary rule ensures that the preceding fault board can be uniquely identified under any circumstances.

[0045] In an optional embodiment, when the token processing status is forwarded, the token status response information includes the token forwarding target address; determining the faulty front-end board based on the token status response information specifically includes: when none of the token status responses are in the holding state, filtering out second response information with the token processing status being forwarded from all token status response information; determining the token delivery path based on the address number and token forwarding target address in each second response information; in the token delivery path, searching for a token delivery endpoint that satisfies at least one of the following conditions: the board under test corresponding to the token forwarding target address does not return second response information; the token processing status in the second response information returned by the board under test corresponding to the token forwarding target address is not forwarded; and determining the board under test with the token forwarding target address as the token delivery endpoint as the faulty front-end board.

[0046] In the above embodiment, taking the test scenario of 8 data processing boards on a communication equipment production line as an example, the board address numbers are 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, and 0x38, respectively, and they are connected via Ethernet in a ring topology. In this scenario, all boards have forwarded the token, but the token transmission chain is interrupted at some point, requiring analysis of the forwarding path to locate the faulty upstream board. Each board under test records the following information when performing a token forwarding operation: Token identifier: used to identify a specific token frame; Self address number: identifies the forwarding source; Token forwarding target address: records the target board address to which the token was sent; Forwarding status flag: confirms that the forwarding operation has been executed. For example, after receiving the token, board 0x33 determines the next target as board 0x34 according to the preset forwarding rules, performs the forwarding operation, and records: Token identifier 0xAABBCCDD, Self address 0x33, Forwarding target address 0x34, and Forwarding status "Forwarded". During the test, the token monitoring timer detects an anomaly. After the test host sends a query command including the token identifier 0xAABBCCDD, it receives response information from 8 boards: Board 0x31 response: Address number 0x31, token processing status "forwarded" (encoding 0x01), token forwarding destination address 0x32; Board 0x32 response: Address number 0x32, token processing status "forwarded" (encoding 0x01), token forwarding destination address 0x33; Board 0x33 response: Address number 0x33, token processing status "forwarded" (encoding 0x01), token forwarding destination address 0x34; Board 0x34 response: Address number 0x34, token processing... Status "Forwarded" (code 0x01), token forwarding target address 0x35; Board 0x35 response: Address number 0x35, token processing status "Forwarded" (code 0x01), token forwarding target address 0x36; Board 0x36 response: Address number 0x36, token processing status "Not Received" (code 0x00), no forwarding target address; Board 0x37 response: Address number 0x37, token processing status "Not Received" (code 0x00), no forwarding target address; Board 0x38 response: Address number 0x38, token processing status "Not Received" (code 0x00), no forwarding target address.

[0047] In the above embodiment, the process for determining the faulty front-end board is as follows: Step 1, the test host first checks all response information and confirms that no board reports a "held state," indicating that the token may have been lost during forwarding. Step 2, from all response information, the second response information with the token processing status of "forwarded" is filtered out, resulting in 5 second response information: response information of board 0x31; response information of board 0x32; response information of board 0x33; response information of board 0x34; and response information of board 0x35. Based on the address number and token forwarding target address in each second response information, the token transmission path is constructed: Transmission path: 0x31→0x32→0x33→0x34→0x35→0x36. Path construction method: Starting from board 0x31, its forwarding target is 0x32; look for the response from board 0x32, its forwarding target is 0x33; and so on, until board 0x35, whose forwarding target is 0x36; board 0x36 does not report a forwarded status, the path is interrupted here. Analyze the token passing path and find the position that meets the termination condition: For the forwarding target address 0x36 of board 0x35: Check condition one: Does board 0x36 return a second response message? Result: Board 0x36 returned a response message, but it was not the second response message (status is "not received"). Check condition two: Is the token processing status of board 0x36 a forwarded status? Result: The status of board 0x36 is "not received", not a forwarded status. Board 0x36 meets condition two, therefore 0x36 is determined to be the token passing endpoint.

[0048] In the above embodiment, the board under test whose token forwarding destination address is the token passing endpoint (0x36) is identified as the fault-preceding board, i.e., board 0x35 is the fault-preceding board. This indicates that although board 0x35 reports that it has forwarded the token to 0x36, 0x36 has not actually received the token, and the problem lies in the transmission link from 0x35 to 0x36. In some test configurations, token passing may adopt a branching structure. Assume the following response information is received: Board 0x31: Forwarded, destination address 0x32; Board 0x32: Forwarded, destination addresses 0x33 and 0x34 (bidirectional forwarding); Board 0x33: Forwarded, destination address 0x35; Board 0x34: Forwarded, destination address 0x36; Board 0x35: Not received; Board 0x36: Forwarded, destination address 0x37; Board 0x37: Forwarded, destination address 0x38; Board 0x38: Not received. Token passing path construction: Main path: 0x31→0x32→0x33→0x35 (interrupted); Branch path: 0x32→0x34→0x36→0x37→0x38 (interrupted). In the main path, 0x35 is the passing endpoint (satisfying condition one: no second response information returned); in the branch path, 0x38 is the passing endpoint (satisfying condition one: no second response information returned). The fault preceding board in the main path is board 0x33 (its forwarding target 0x35 failed to receive); the fault preceding board in the branch path is board 0x37 (its forwarding target 0x38 failed to receive). The test host can choose to prioritize handling the main path fault or report both fault points simultaneously, based on actual needs. If a board fails to respond, and if a board completely ignores the query command (e.g., due to board failure or communication interruption), proper handling is still required. Assume board 0x35 is completely unresponsive, and other boards respond as follows: Board 0x34: Forwarded, destination address 0x35; Board 0x36: Not received. Processing: Board 0x34's forwarding destination 0x35 did not return any response information; condition one is met: the board under test corresponding to the token forwarding destination address did not return a second response information; board 0x34 is determined to be the faulty preceding board.

[0049] In an optional embodiment, after obtaining the first token frame, the method further includes: performing data extraction processing on the first token frame to extract test completion result data of all boards under test from the first data segment to obtain a test completion result dataset; performing pass / fail judgment processing on the test completion result dataset according to preset test item standard requirements to generate a test pass report, the test pass report including the mapping relationship between address number and pass / fail judgment result; adding the address number corresponding to the board under test with a pass / fail judgment result of unqualified to the retest address list to generate a retest token frame, the retest token frame including a retest address list and a second data segment; using the retest token frame as a loop variable to perform a retest token frame passing operation until the retest address list in the retest token frame is empty, to obtain a second token frame.

[0050] In the above embodiment, a batch testing scenario of an automotive electronic control unit production line is taken as an example. The parallel testing system needs to perform functional tests on 12 engine control boards, with address numbers from 0x41 to 0x4C. Each board needs to complete three tests: voltage test, communication rate test, and temperature sensor calibration. After the initial test, the parallel testing system automatically identifies unqualified boards and performs targeted retests until all boards meet the qualification standards or are identified as faulty boards. After the first token frame passes through all 12 boards, its first data segment includes the test results of all boards. The data segment is organized in a fixed format, with each board occupying 16 bytes of data space: Bytes 0-1: Board address number; Bytes 2-5: Voltage test results (including input voltage value and output voltage value); Bytes 6-9: Communication rate test results (including measured baud rate and bit error rate); Bytes 10-13: Temperature sensor calibration results (including zero-point deviation and linearity); Bytes 14-15: Test status flag and check code. After receiving the first token frame, the test host parses it according to a predefined data format: First, it locates the start of the first data segment. Based on the token frame format, it skips the frame header, token identifier, and other control information to find the starting address of the data segment. Then, it extracts data from each board sequentially in 16-byte units. For example, from the first 16-byte block, it extracts: address number 0x41; voltage test: input voltage 11.8V, output voltage 4.95V; communication test: baud rate 499.5kbps, bit error rate 0.0002; temperature calibration: zero-point deviation +0.3℃, linearity 0.98. This process continues, extracting test data from all 12 boards to form the test completion result dataset. Each element in the dataset includes the board address and three corresponding test results.

[0051] In the above embodiments, the preset test item standards require that the passing standards for each test item are pre-configured: Voltage test: input voltage range is 11.5V - 12.5V, output voltage range is 4.9V - 5.1V; Communication rate test: baud rate range is 495kbps - 505kbps, bit error rate is less than 0.001; Temperature sensor calibration: zero-point deviation is within ±0.5°C, linearity is greater than 0.95. Determine each board data in the test result dataset: Take board 0x41 as an example. Voltage test determination: input 11.8V is within the standard range, output 4.95V is within the standard range, determined as qualified; Communication test determination: baud rate 499.5kbps is within the standard range, bit error rate 0.0002 is less than 0.001, determined as qualified; Temperature calibration determination: zero-point deviation +0.3°C is within ±0.5°C, linearity 0.98 is greater than 0.95, determined as qualified. Comprehensive determination: All three tests are qualified, and board 0x41 is determined as qualified. Determination of board 0x43: Voltage test: input 11.7V is qualified, output 5.15V exceeds the upper limit, determined as unqualified; Communication test: baud rate 502kbps is qualified, bit error rate 0.0008 is qualified; Temperature calibration: zero-point deviation -0.2°C is qualified, linearity 0.96 is qualified. Comprehensive determination: There are unqualified items, and board 0x43 is determined as unqualified. After determining all boards, generate a test passing report. The report content includes: 0x41: qualified; 0x42: qualified; 0x43: unqualified (voltage output exceeds the limit); 0x44: qualified; 0x45: unqualified (communication bit error rate exceeds the standard); 0x46 to 0x4B: qualified; 0x4C: unqualified (temperature linearity is insufficient). The report clearly records the mapping relationship between each address number and the passing determination result, and the specific reasons for the unqualified items are also noted.

[0052] In the above embodiment, based on the test pass report, the address numbers of the unqualified boards are extracted: board 0x43 (voltage output exceeds limit); board 0x45 (communication bit error rate exceeds standard); board 0x4C (temperature linearity is insufficient). These three address numbers are added to the retest address list, forming the list [0x43, 0x45, 0x4C]. The retest token frame includes the following main parts: frame header: identifies this as a retest token frame; token identifier: uses a new identifier 0xDDEEFF00 to distinguish it from the initial test; retest address list: includes the three addresses 0x43, 0x45, and 0x4C; second data segment: reserves 192 bytes of space (3 boards × 16 bytes / board × 4 times redundancy); frame tail: includes verification information. First round of retest execution: the retest token frame is sent to the test bus, and only boards with addresses in the retest address list respond. After receiving the retest token frame, board 0x43: identifies its own address in the retest list; re-executes the voltage test, adjusting the output voltage to 5.02V; writes the new test result to the second data segment; removes its own address 0x43 from the retest address list; and forwards the modified token frame. After receiving the token frame, board 0x45: performs a communication test, optimizing the bit error rate to 0.0006; updates the test result to the second data segment; removes address 0x45 from the list; and continues forwarding. After receiving the token frame, board 0x4C: recalibrates the temperature sensor, improving linearity to 0.94; finds it still doesn't meet the standard, retains the address in the retest list; updates the test result and forwards it. Second round of retest execution: After the first round of retests, the test host checks the returned token frame: the retest address list still contains [0x4C]; the list is not empty, so retesting needs to continue. A new retest token frame is generated, containing only board 0x4C: board 0x4C is recalibrated, achieving a linearity of 0.96; the test passes, and 0x4C is removed from the list; the retest address list becomes empty. Retest termination condition: After the second round of retesting is completed, the test host receives the second token frame, checks that the retest address list is empty, and the retesting process ends. At this point, all boards have either met the pass criteria or been marked as faulty boards requiring repair.

[0053] In the above embodiments, for persistently unqualified boards, if a board still fails after a preset maximum number of retests (e.g., 3 times), the parallel testing system takes the following action: If board 0x47 consistently fails to meet temperature calibration standards in three rounds of retesting: Round 1: Linearity 0.92; Round 2: Linearity 0.93; Round 3: Linearity 0.94, the system determines that the board has a hardware defect, marks it as "requires repair" in the final test report, and permanently removes it from the subsequent retest list to avoid infinite loops. Through an automated retesting mechanism, targeted retesting of unqualified boards is achieved. Dynamic management of the retest address list ensures that only boards requiring retesting participate in subsequent tests, improving testing efficiency. The strategy of cyclical retesting until the list is empty ensures that all recoverable boards can reach the pass standard through adjustments, while the maximum number of retests limits prevents invalid repeated testing of faulty boards.

[0054] In an optional embodiment, before using the retest token frame as a loop variable to perform the retest token frame transmission operation, the method further includes: performing fault type analysis on each board under test in the retest address list using the test completion result dataset to determine the fault type of each board under test in the retest address list; generating corresponding retest parameter configurations for each board under test in the retest address list according to the fault type, the retest parameter configurations including the number of retests, test depth level, and diagnostic mode flag; and sending a retest configuration instruction to each board under test in the retest address list, so that each board under test in the retest address list is configured according to the retest parameters in the received retest configuration instruction. The target test item is re-executed, wherein: each board under test in the retest address list executes the target test item a corresponding number of times according to the number of retests; the test coverage of each board under test in the retest address list is adjusted according to the test depth level; each board under test in the retest address list determines the data recording level according to the diagnostic mode flag, wherein: when the diagnostic mode flag is basic mode, the test pass result data or test failure result data of the target test item is recorded; when the diagnostic mode flag is diagnostic mode, the test process data of the target test item is recorded, and the test process data includes the test step execution sequence, intermediate test parameters, fault triggering conditions, and abnormal status information.

[0055] In the above embodiment, a batch testing scenario of flight control boards from an avionics equipment manufacturer is used as an example. The parallel testing system needs to comprehensively test eight flight control boards, numbered 0x51 to 0x58. These boards are responsible for key functions such as flight attitude control, navigation data processing, and sensor information fusion, and have extremely high reliability requirements. Initial testing revealed that some boards had different types of faults, requiring targeted retesting and configuration based on the fault characteristics. In-depth analysis of the test data of the three boards (0x52, 0x55, and 0x57) that failed the initial test was conducted. The test data of board 0x52 showed: Analog signal acquisition test: The acquisition accuracy deviation of 3 out of 12 channels exceeded the threshold; Deviation characteristics: All were adjacent channels, and the deviation values ​​showed a regular increasing trend; Other test items: The digital interface was normal, and the processor operation was normal; Analysis conclusion: Board 0x52 has a systematic offset in the analog front-end circuit, which may be due to reference voltage drift or abnormal amplifier gain, belonging to the "analog circuit fault" type. Test data from board 0x55 shows: High-speed data transmission test: Intermittent packet loss occurred after 15 seconds of continuous transmission; Fault characteristics: The temperature sensor showed a local temperature reaching 85℃; After restarting, the test returned to normal for a short time; Analysis conclusion: Board 0x55 has a thermal stability issue, with insufficient heat dissipation under high load leading to performance degradation, belonging to the "thermal sensitive fault" type. Test data from board 0x57 shows: Memory test: Read / write verification failed in a specific address range 0x2000-0x2FFF; Fault characteristics: This address range is completely inaccessible, returning a fixed value of 0xFF; Other address ranges function normally; Analysis conclusion: Board 0x57 has local memory damage, belonging to the "memory fault" type.

[0056] In the above embodiments, the fault type classification system is as follows: The test system maintains a fault type knowledge base, including the following main categories: Analog circuit faults: require recalibration and compensation; Thermally sensitive faults: require extended test intervals and reduced test intensity; Memory faults: require locating bad blocks and trying alternative solutions; Timing faults: require adjusting clock parameters and synchronization mechanisms; Communication faults: require optimizing protocol parameters and retransmission strategies. Configuration generation for board 0x52 (analog circuit fault): Retest parameter configuration includes three core elements: The number of retests is set to 3. The first retest executes the automatic calibration procedure, the second uses the calibrated parameters for verification testing, and the third confirms stability. This multi-test strategy ensures the reliability of the calibration effect. The test depth level is set to "Depth Level 2". This level requires: Expanded test points: increasing from the standard 5 test points to 20 test points; Full range coverage: expanding the test range from 80% to 110% of the normal operating range; Increased boundary testing: paying special attention to accuracy near the range boundaries and zero point. The diagnostic mode flag is set to "Diagnostic Mode". The board will record detailed calibration process data, including the original sampled values ​​for each channel, the calibration coefficient calculation process, and comparison data before and after compensation. For configuration generation for board 0x55 (thermal sensitive fault): the number of retests is set to 5. A progressive testing strategy is adopted: First test: low load test to establish baseline performance; Second test: medium load to monitor the temperature rise curve; Third test: high load short-time test to determine the temperature threshold; Fourth test: intermittent load test to verify heat dissipation recovery capability; Fifth test: verification of the optimized operating mode. The test depth level is set to "Depth Level 1". Key adjustments are made to the test rhythm: cooling intervals are inserted between each test item; the continuous test time is shortened from 30 seconds to 10 seconds; temperature monitoring points are added to track the temperature of key components in real time. The diagnostic mode flag is also set to "Diagnostic Mode". Key temperature-related data is recorded: temperature change curves at each test stage; the correlation between performance indicators and temperature; heat dissipation time constant and thermal equilibrium point. For configuration generation for board 0x57 (memory fault): the number of retests is set to 2. The first attempt is to test the memory repair algorithm; the second attempt verifies the repair effectiveness or enables a backup storage area. The test depth level is set to "Depth Level 3". Perform the most comprehensive memory diagnostics: scan byte-by-byte to locate all faulty cells; test different access modes and timings; assess the risk of fault propagation. The diagnostic mode flag is set to "Diagnostic Mode". Detailed records are kept of the memory fault distribution map, fault address mapping table, and feasibility assessment of backup solutions.

[0057] In the above embodiments, each retest configuration instruction is encapsulated in a structured format, including the following fields: Target Address: specifies the receiving board; Instruction Type: identifies as a retest configuration instruction; Fault Type Code: identifies the identified fault type; Number of Retests: 1-255 times; Test Depth Level: 1-3 levels; Diagnostic Mode Flag: 0 for basic mode, 1 for diagnostic mode; Additional Parameters: configuration parameters specific to the fault type. The test host sends configuration instructions to each board through a dedicated configuration channel: To board 0x52, a configuration instruction is sent: An instruction frame is constructed: Address 0x52, Fault Type 01 (Analog Circuit), 3 Retests, Depth Level 2, Diagnostic Mode 1; Additional Parameters: Calibration Algorithm Selection, Initial Compensation Coefficient; The instruction is sent and a confirmation response is awaited. Board 0x52 processes the received configuration: Parses the configuration parameters, updates the internal test control register; loads the analog circuit calibration program; prepares the data acquisition buffer for the extended test points; and returns configuration confirmation information. Similarly, configuration instructions are sent to boards 0x55 and 0x57, and each board adjusts its test strategy according to the received configuration. Board 0x52 performs simulated channel calibration tests (corresponding to the target test items mentioned above). The first retest involves: initiating the automatic calibration program to calibrate each of the 12 simulated channels; collecting raw data at 20 test points; calculating and storing calibration coefficients; and recording the convergence curve of the calibration process. The second retest involves: applying the calibration coefficients and retesting all channels; verifying whether the accuracy meets the requirements; and recording the performance indicators after calibration. The third retest involves: conducting long-term stability tests; monitoring the drift of calibration parameters; and generating the final test report. Board 0x55 performs thermal management optimization tests: The board executes the following steps according to the configured 5-retest plan: establishing thermal characteristic models under different loads; determining the safe operating temperature boundaries; optimizing task scheduling strategies to control heat generation; and verifying the optimization effect. Throughout the process, the correspondence between temperature and performance is recorded in detail, forming a complete thermal characteristic analysis report.

[0058] In the above embodiments, the data recording level is differentiated as follows: Basic mode data recording, assuming board 0x53 is configured in basic mode during retesting: only the final test result is recorded: pass or fail; the data volume is small, including only necessary judgment information; suitable for situations where the fault cause is clear and the repair plan is standardized. Detailed recording of the diagnostic mode (board 0x52): Test step execution sequence recording: Step 1: Channel 1 zero-point calibration, time 120ms; Step 2: Channel 1 gain calibration, time 150ms; Step 3: Channel 1 linearity verification, time 200ms; the execution order and time of all steps are recorded sequentially. Intermediate test parameter recording: Channel 1 original zero-point offset: +23mV; calculated compensation value: -23mV; compensated zero-point offset: +0.2mV; comparison of the original and corrected values ​​for each test point. Fault trigger condition recording: accuracy decreases when the input signal amplitude exceeds 4.5V; zero-point drift intensifies when the ambient temperature exceeds 50℃; crosstalk exists when adjacent channels operate simultaneously. Abnormal status information logging includes: abnormal patterns detected during calibration; unexpected parameter mutations; and potential fault indications. Intelligent retesting strategies are implemented through fault type analysis and differentiated retesting parameter configuration. Different types of faults employ targeted testing schemes, avoiding resource waste caused by indiscriminate retesting. Detailed data logging in diagnostic mode provides data support for subsequent fault analysis and product improvement. The entire retesting process adaptively adjusts based on fault characteristics, improving the success rate and efficiency of retesting.

[0059] It should also be noted that the examples of actual values ​​for the above-mentioned parameters are merely exemplary embodiments, and the examples of actual values ​​for the above-mentioned parameters are not limited to the examples mentioned above.

[0060] Through the embodiments of this application, the orderly transmission of token frames among the boards under test enables each board to autonomously execute tests and summarize the results into a token data segment, avoiding the communication bottleneck of traditional centralized testing. When token transmission is abnormal, by analyzing the token processing status and forwarding path of the boards, the faulty upstream boards can be accurately located, improving fault diagnosis efficiency. After the test is completed, the test results are automatically extracted and qualified. For unqualified boards, retest token frames are generated for targeted retesting until all boards meet the standards or the fault is confirmed. In particular, differentiated retest parameters, including the number of retests, test depth, and diagnostic mode, are configured for different boards through fault type analysis, realizing an adaptive retest strategy. The entire testing process requires no manual intervention, thereby improving the testing efficiency and automation level of batch boards. At the same time, the detailed data records in the diagnostic mode provide data support for product quality improvement.

[0061] It should be noted that the embodiments described above are only some embodiments of this application, and not all embodiments. The present application will be described in detail below with reference to specific embodiments.

[0062] This application provides a broadcast-type multi-board parallel testing system, see below. Figure 2 , Figure 2 This is a block diagram of a broadcast-type multi-board parallel testing system in an embodiment of this application. The system includes: a host computer, a control box, and an interface box, wherein: The host computer communicates with multiple control boards inside the control box via CAN communication lines. Figure 2 (Taking control boards 1 to 10 as examples) establishes a communication connection to broadcast unified test commands to all control boards and receive test result data returned by each control board.

[0063] The control box contains multiple control boards, each of which is connected to the host computer via a CAN communication line to receive broadcast commands from the host computer.

[0064] The interface box contains multiple test boards. Figure 2 (Taking test board 1 to test board 10 as examples).

[0065] Specifically, each control board establishes a one-to-one connection with a corresponding board under test via inter-board connection line 1 (for example, control board 1 connects to board under test 1, control board 2 connects to board under test 2, and so on). After receiving the broadcast command from the host computer, each control board independently performs the corresponding test operation on the board under test it is connected to, collects test data, and feeds the data back to the host computer via the CAN communication line, thereby realizing parallel testing of multiple boards.

[0066] It should also be noted that parallel testing systems can employ a more flexible one-to-many control architecture to adapt to scenarios with varying test densities and cost requirements. Under this architecture, one control board can connect to and control multiple boards under test. The specific implementation is as follows: A control board (e.g., control board 1) within the control box establishes a physical connection with multiple boards under test (e.g., board under test 1, board under test 2, and board under test 3) within the interface box via one or more inter-board connection cables in a bus, daisy-chain, or star topology, forming an independent test subsystem. Under this configuration, the test procedure is adjusted accordingly: 1) Addressing and Gating: The control board (control board 1) selects and communicates with the target board under test (such as board under test 2) by sending instructions carrying specific address information on its connected inter-board connection lines. Each board under test is assigned a unique local address within this test subsystem and only responds to instructions that match its address.

[0067] 2) Time-sharing parallel testing: The host computer still broadcasts a unified test task to all control boards via the CAN communication line. When control board 1 receives the task, it executes test operations on the connected test boards 1, 2, and 3 sequentially or in a time-sharing manner according to the preset test sequence. Simultaneously, other control boards in the parallel testing system (such as control board 2) independently perform time-sharing tests on their respective groups of test boards. This method achieves time-sharing within a group and parallel testing between groups.

[0068] 3) Results Summary and Reporting: Control board 1 is responsible for managing the test progress of all boards under its control, collecting and caching the test results of each board. After a test cycle is completed, control board 1 will compile the summarized test result data packet (including the results of boards 1, 2, and 3 under test) and report it to the host computer via the CAN communication line.

[0069] With this one-to-many implementation, the parallel testing system can manage a large number of boards under test with only a few control boards, effectively reducing hardware costs and system complexity. At the same time, it maintains high overall testing efficiency through inter-group parallelism.

[0070] The following describes the broadcast-type multi-board parallel testing system in the embodiments of this invention from the perspective of hardware processing. (See attached document.) Figure 3 , Figure 3 This is a schematic diagram of the physical device structure of a broadcast-type multi-board parallel testing system in the embodiments of this application.

[0071] It should be noted that, Figure 3 The structure of the broadcast multi-board parallel test system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0072] like Figure 3 As shown, the broadcast-type multi-board parallel test system includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes according to a program stored in Read-Only Memory (ROM) 302 or a program loaded from storage section 308 into Random Access Memory (RAM) 303, such as performing the methods described in the above embodiments. The RAM 303 also stores... It contains various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via bus 304. The input / output (I / O) interface 305 is also connected to bus 304.

[0073] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0074] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0075] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0076] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0077] Specifically, the broadcast-type multi-board parallel testing system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the broadcast-type multi-board parallel testing method provided in the above embodiment.

[0078] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the broadcast multi-board parallel testing system described in the above embodiments; or it may exist independently and not assembled into the broadcast multi-board parallel testing system. The storage medium carries one or more computer programs, which, when executed by a processor of the broadcast multi-board parallel testing system, cause the broadcast multi-board parallel testing system to implement the broadcast multi-board parallel testing method provided in the above embodiments.

[0079] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. 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 of the technical features. 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.

[0080] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A broadcast-style multi-board parallel testing method, characterized in that, include: A broadcast test command is sent to multiple boards under test connected on the bus so that the multiple boards under test can start executing the target test item simultaneously. Each board under test has a unique address number. After sending the broadcast test command, an initial token frame is generated. The initial token frame includes a list of addresses to be collected and a first data segment. The list of addresses to be collected includes all the address numbers of the boards under test in sorted order. Using the initial token frame as a loop variable, perform the following token frame passing operation until the list of addresses to be collected in the initial token frame is empty, thus obtaining the first token frame: The initial token frame is sent to the first test board corresponding to the first address number in the address numbering sequence, to trigger the first test board to perform token frame processing operation on the initial token frame according to its own test status, wherein: When the first test board determines that its test status is incomplete, it sends the initial token frame to the next test board corresponding to the next address number. When the first board under test determines that its test status is complete, it writes the test completion result data into the first data segment, deletes the first address number from the list of addresses to be collected, and updates the next address number to the first address number. After sending the initial token frame to the first test board corresponding to the first address number in the address numbering sequence, the method further includes: Start the token monitoring timer so that the token monitoring timer monitors the execution process of the token frame transmission operation for a preset duration; If the first token frame is not received when the token monitoring timer reaches the preset duration, it is determined that the token frame processing operation has malfunctioned. Sending a token status query command to each of the boards under test to determine the faulty front-end board holding the current token frame specifically includes: sending the token status query command including a token identifier to each of the boards under test, wherein the token identifier is a unique identifier of the initial token frame; Receive token status response information returned by each of the boards under test, wherein each token status response information includes the address number and token processing status of the corresponding board under test; The faulty front-end board is determined based on the token status response information; The board to be tested corresponding to the next address number adjacent to the address number of the faulty front board in the current address list of the current token frame is identified as the faulty board to be tested. Remove the address number of the faulty board under test from the current collection address list of the current token frame to obtain the current recovery token frame including the current recovery address list; Send a token recovery command to the faulty front-end board to control the faulty front-end board to send the current recovery token frame to the test board corresponding to the next address number adjacent to the address number of the faulty test board in the current recovery address list.

2. The method according to claim 1, characterized in that, When the token processing status is in the holding status, the token status response information includes the token reception timestamp; The step of determining the faulty front-end board based on the token status response information specifically includes: Filter out the first response information from all the token status response information, where the token processing status is the holding status; When a first response message exists, the board under test corresponding to the address number in the first response message is identified as the fault pre-fault board. When there are multiple first response messages, the multiple first response messages are sorted by time according to the token receiving timestamp, and the test board corresponding to the address number in the last first response message after sorting is determined as the fault pre-processing board.

3. The method according to claim 1, characterized in that, When the token processing status is forwarded, the token status response information includes the token forwarding target address; The step of determining the faulty front-end board based on the token status response information specifically includes: When none of the token status response messages are in the holding state, a second response message in which the token status is in the forwarded state is selected from all the token status response messages; The token delivery path is determined based on the address number and token forwarding target address in each of the second response messages; In the token passing path, find a token passing endpoint that satisfies at least one of the following conditions: The test board corresponding to the token forwarding target address did not return the second response information; The token processing status in the second response information returned by the test board corresponding to the token forwarding target address is not the forwarded status; The test board whose token forwarding target address is the token transmission endpoint is identified as the fault pre-processing board.

4. The method according to claim 1, characterized in that, After obtaining the first token frame, the method further includes: The first token frame is processed for data extraction to extract the test completion result data of all the boards under test from the first data segment, so as to obtain the test completion result dataset. The test completion result dataset is processed for pass / fail determination according to the preset test item standard requirements, and a test pass report is generated. The test pass report includes the mapping relationship between address number and pass determination result. The address number corresponding to the test board whose pass / fail judgment result is unqualified is added to the retest address list to generate a retest token frame, the retest token frame including the retest address list and a second data segment. The retest token frame is used as a loop variable to perform the retest token frame passing operation until the retest address list in the retest token frame is empty, thus obtaining the second token frame.

5. The method according to claim 4, characterized in that, Before using the retest token frame as a loop variable to perform the retest token frame passing operation, the method further includes: The test completion result dataset is used to perform fault type analysis on each board under test in the retest address list to determine the fault type of each board under test in the retest address list; Based on the fault type, generate a corresponding retest parameter configuration for each board under test in the retest address list. The retest parameter configuration includes the number of retests, test depth level, and diagnostic mode flag. A retest configuration command is sent to each board under test in the retest address list, so that each board under test in the retest address list is configured to re-execute the target test item according to the retest parameters in the received retest configuration command, wherein: Each board under test in the retest address list executes the target test item a corresponding number of times according to the number of retests; The test coverage of each board under test in the retest address list is adjusted according to the test depth level; Each board under test in the retest address list determines its data recording level according to the diagnostic mode flag, wherein: When the diagnostic mode is marked as basic mode, record the test pass result data or test failure result data of the target test item; When the diagnostic mode is set to diagnostic mode, the test process data of the target test item is recorded. The test process data includes the test step execution sequence, intermediate test parameters, fault triggering conditions, and abnormal state information.

6. A broadcast-type multi-board parallel testing system, characterized in that, The broadcast-type multi-board parallel testing system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the broadcast-type multi-board parallel testing system to perform the method as described in any one of claims 1-5.

7. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on a broadcast multi-board parallel test system, the broadcast multi-board parallel test system performs the method as described in any one of claims 1-5.

8. A computer program product, characterized in that, When the computer program product is run on a broadcast multi-board parallel test system, the broadcast multi-board parallel test system performs the method as described in any one of claims 1-5.

Images