WO2023185266A1

WO2023185266A1 - Automatic detection method, single board, electronic device and storage medium

Info

Publication number: WO2023185266A1
Application number: PCT/CN2023/075287
Authority: WO
Inventors: 张二芬
Original assignee: 中兴通讯股份有限公司
Priority date: 2022-03-30
Filing date: 2023-02-09
Publication date: 2023-10-05
Also published as: CN116938779A

Abstract

Disclosed in the present application are an automatic detection method, a single board, an electronic device and a storage medium. The method comprises: receiving a hardware self-checking instruction issued by a master single board; loading a pre-cached tool self-checking patch package according to the hardware automatic detection instruction, the tool self-checking patch package comprising a pre-packaged hardware self-checking script; restarting to enter a tool self-checking mode according to a preset program, carrying out hardware self-checking according to the hardware self-checking script, and feeding back a self-checking result to the master single board.

Description

Automated detection methods, single boards, electronic equipment and storage media

Related applications

This application claims priority to the Chinese patent application with application number 202210356511.1 filed on March 30, 2022, the entire content of which is incorporated into this application by reference.

Technical field

The implementation of this application relates to the field of communication technology, and in particular to an automated detection method, single board, electronic equipment and storage medium.

Background technique

As router equipment is highly modernized, the requirements for hardware self-test of the equipment are getting higher and higher. During the implementation process of router equipment from production to delivery, it is necessary to intercept various short circuits, open circuits, device leaks, etc. that occur during the welding process. Welding faults need to be eliminated, and bumps during board transportation need to be eliminated. A comprehensive self-check of the equipment hardware system is required to ensure that the equipment is in normal condition before business operation, to prevent business failures from being triggered and to prevent subsequent risks.

When performing hardware self-test on equipment during the implementation of field projects, the following scenarios need to be considered: Scenario 1: Adding new equipment: After adding new equipment, it is required to perform self-test on the entire hardware system, including main control/line card/switching/interface sub-card / Backplane, covering control plane channels and forwarding plane channels; Scenario 2: Single board expansion of existing network equipment: Perform hardware self-test of new expansion single boards on existing network equipment, including line cards/interface cards, and hardware self-test of expansion single boards. During the inspection, it needs to be isolated from the single board that carries the service on the existing network, and it cannot have an excessive impact on the existing network business; Scenario 3: A suspected hardware failure occurs on the existing network equipment single board: Without any physical operation on the on-site environment, Perform hardware self-check on the faulty board.

In order to solve the hardware self-test problem in the above scenario, a commonly used method is to use an independent version to perform self-test. After the user issues a self-test command, all the tested boards will perform self-test together. However, after the test starts, newly inserted The single board can only wait for the current round of self-test to be completed, and then perform self-test together with each tested single board. In the case of single board expansion of the existing network equipment or the need for faulty single board self-test, the self-test can be performed on-site unconditionally. Independent version self-test requires sending the board out and back, which is time-consuming and labor-intensive. Another way is to run the commercial version of the control self-test script on the main control board, run the self-test version of the training tool on the self-test board, and let the main control board control one or several devices on the existing network. The self-test of the single board is used to implement the hardware self-test of the single board. However, the self-test mode in this method is fixed and has poor pertinence. Moreover, due to the long release cycle of commercial versions and strict release processes, etc., therefore, when the single board occurs In the case of capacity expansion, it is difficult to be compatible with the hardware self-test of the expansion board, and its practicality is poor.

Contents of the invention

The purpose of the embodiments of the present application is to solve the above problems and provide an automated detection method, a single board, an electronic device and a storage medium, by encapsulating the self-test script in a tooling self-test patch package that is pre-stored locally on the single board to make the self-test script independent Release and maintenance to realize the decoupling of the self-test version and the commercial version of the main control board, thereby achieving single-board granular hardware self-test simply and efficiently.

In order to achieve the above purpose, embodiments of the present application provide an automated detection method, which includes: receiving a hardware self-test instruction issued by a main control board; loading a pre-cached tooling self-test patch package according to the hardware self-test instruction; Wherein, the tooling self-test patch package includes a pre-packaged hardware self-test script; restart the tooling self-test mode according to the preset program, perform hardware self-test according to the hardware self-test script, and report to the main control unit The board feeds back the self-test results.

In order to achieve the above purpose, an embodiment of the present application also provides a single board, including: an acquisition module for receiving the main control unit Hardware self-test instructions issued by the board;

A loading module, configured to load a pre-cached tooling self-checking patch package according to the hardware self-checking instructions; wherein the tooling self-checking patch package includes a prepackaged hardware self-checking script;

The self-test module is used to reboot into the tooling self-test mode according to the preset program, perform hardware self-test according to the hardware self-test script, and feed back the self-test results to the main control board.

To achieve the above object, embodiments of the present application further provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor. , the instructions are executed by at least one processor, so that at least one processor can execute the automated detection method as described above.

In order to achieve the above object, embodiments of the present application also provide a computer-readable storage medium that stores a computer program. When the computer program is executed by a processor, the automated detection method as described above is implemented.

In the automated detection method provided by the embodiment of this application, after receiving the hardware self-test instruction from the main control board, the single board loads the pre-cached local tooling self-test patch package according to the hardware self-test instruction. The tooling self-test patch package Contains prepackaged hardware self-test scripts. Then enter the tooling self-test mode by restarting, perform hardware self-test according to the hardware self-test script in the tooling self-test patch package, and feed back the self-test results to the main control board. By pre-stored on the board in the form of a patch package, the tooling self-test mode version file containing the packaged hardware self-test script enables the tooling self-test mode version file to be independently released and maintained, realizing self-test version and Decoupling of the commercial version of the main control single board; and after receiving the hardware self-test command of the main control single board, the single board completes the switch from the live network mode to the hardware self-test mode according to the tooling self-test patch package, and according to the hardware The self-test script automatically completes the hardware self-test and reports the self-test results. It can implement board-granular hardware self-test simply and efficiently without the need for the main control board to perform self-test control.

Description of drawings

One or more embodiments are exemplified by the pictures in the corresponding drawings. These illustrative illustrations do not constitute limitations to the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements. Unless otherwise stated, the figures in the drawings are not intended to be limited to scale.

Figure 1 is a flow chart of the automated detection method in the embodiment of the present application;

Figure 2 is a schematic diagram of hardware self-test interaction in an embodiment of the present application;

Figure 3 is a schematic structural diagram of a single board in another embodiment of the present application;

Figure 4 is a schematic structural diagram of an electronic device in another embodiment of the present application.

Detailed ways

It can be seen from the background technology that among the currently more commonly used automated detection methods, using an independent version for hardware self-test cannot achieve single-board granular hardware self-test and targeted hardware self-test for faulty boards. Using the main control unit The board control hardware self-test that implements single board granular self-test has poor pertinence and cannot be adapted to new types of boards in a timely manner, resulting in poor feasibility. Therefore, how to complete single-board granular hardware self-test simply and efficiently to improve the efficiency and effectiveness of hardware self-test and fault analysis is an urgent problem that needs to be solved.

In order to solve the above problems, embodiments of the present application provide an automated detection method, which includes: receiving a hardware self-test instruction issued by a main control board; loading a pre-cached tooling self-test patch package according to the hardware self-test instruction; wherein , the tooling self-test patch package includes a pre-packaged hardware self-test script; restart according to the preset program to enter the tooling self-test mode, perform hardware self-test according to the hardware self-test script, and feed back the self-test results to the main control board.

In the automated detection method provided by the embodiment of this application, after receiving the hardware self-test instruction from the main control board, the single board loads the pre-cached local tooling self-test patch package according to the hardware self-test instruction. The tooling self-test patch package Contains prepackaged hardware self-test scripts. Then enter the tooling self-test mode by restarting, perform hardware self-test according to the hardware self-test script in the tooling self-test patch package, and feed back the self-test results to the main control board. By pre-stored on the board in the form of a patch package, the tooling self-checking mode version file containing the packaged hardware self-checking script enables the tooling self-checking mode version file to be independently released and maintained, realizing the integration of the self-checking version with the main The commercial version of the control single board is decoupled; and after receiving the hardware self-test command of the main control single board, the single board completes the switch from the live network mode to the hardware self-test mode according to the tooling self-test patch package, and performs the hardware self-test according to the hardware self-test. The inspection script automatically completes the hardware self-inspection and reports the self-inspection results. Without the need for the main control board to perform self-inspection control, it is simple and efficient to implement board-granular hardware self-inspection.

In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, each embodiment of the present application will be described in detail below with reference to the accompanying drawings. However, those of ordinary skill in the art can understand that in each embodiment of the present application, many technical details are provided to enable readers to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical solution claimed in this application can also be implemented. The division of the following embodiments is for the convenience of description and should not constitute any limitation on the specific implementation of the present application. The various embodiments can be combined with each other and referenced with each other on the premise that there is no contradiction.

The implementation details of the automated detection method recorded in this application will be described in detail below with reference to specific embodiments. The following content is only implementation details provided for ease of understanding and is not necessary for implementation of this solution.

The first aspect of the embodiments of the present application provides an automated detection method. For the flow of the automated detection method, refer to Figure 1. In some embodiments, the automated detection method includes the following steps:

Step 101: Receive the hardware self-test command issued by the main control board.

When a new board is added to the existing network equipment, the capacity of the existing network equipment board is expanded, or a suspected hardware failure occurs on the existing network equipment board, the operation and maintenance personnel will use the user terminal or the background control terminal to report to the main controller of the existing network equipment. The board sends specific board operation instructions to instruct the existing network equipment to perform board hardware self-test. After receiving the board operation instructions, the main control board will issue hardware self-test instructions to the boards that need to perform hardware self-test according to the board operation instructions. The single board receives the instructions from the main control board and obtains the main control board. The hardware self-test command issued by the control board.

Step 102: Load the pre-cached tooling self-test patch package according to the hardware self-test instruction.

After receiving the hardware self-test command from the main control board, the single board reads and detects the tooling self-test patch package in the local storage space, and then uses the files in the tooling self-test patch package as the preset program. Installation files are loaded, in which the tooling self-test patch package includes pre-packaged hardware self-test scripts. By locally pre-saving the tooling self-checking patch package containing the hardware self-checking script, the board can complete the file loading in time and improve the efficiency of board mode change; the hardware self-checking script is stored in the tooling self-checking patch package in the form of a patch package. In this way, the hardware self-test script of the single board can be independently generated and maintained, and the self-test version on the single board is decoupled from the commercial version on the main control board, so that the subsequent hardware self-test process does not require the control of the main control board. Simplify the self-test process.

The tooling self-test patch package not only contains the hardware self-test scripts pre-generated based on the board information, but also includes Field Programmable Gate Array (FPGA) files used by the tooling process and library files of related modules, such as , library files of self-test modules, extensible markup language (XML) files, etc. The encapsulation method of the tooling self-test patch package can directly use the existing patch package production method to package each included file to generate the tooling self-test patch package. This embodiment does not place any restrictions on the specific files included in the tooling self-test patch package and the packaging method of the files.

In one example, loading a pre-cached tooling self-test patch package according to the hardware self-test instructions includes: according to the hardware The self-test command changes the file calling path of the board from the installation file storage path of the currently running live network mode to the installation file storage path of the tooling self-test mode.

In the process of reading and loading the pre-cached tooling self-test patch package according to the hardware self-test instruction of the main control single board, the single board will determine the software version of the single board according to the version switching instruction in the main control single board hardware self-test instruction. The management module modifies the file calling path of the single board, and changes the installation file calling path of the single board from the installation file storage path of the currently running live network mode to the installation file storage path of the tooling self-test mode, that is, the single board installation file The calling path is adjusted to the tooling self-test patch package in local memory. By modifying the board installation file calling path, the board can accurately load the required installation files, and then accurately enter the tooling self-test mode after restarting, and complete the self-test according to the self-test script.

In another example, the hardware self-test script can be generated in the following manner: obtain the board type of the board; determine the standard test items of the board based on the correspondence between the board type and the test items; Test items and generate hardware self-test scripts.

In the process of generating the hardware self-test script of a single board, first classify the type of the single board according to the classification standard of the single board or the hardware information of the single board. For example, according to the number of specified hardware contained in the single board, the hardware information of the single board. The working parameters and other information are used to classify the type of the board. After obtaining the board type of the board based on the hardware information of the current board, determine all the standard test items corresponding to the current board based on the pre-set correspondence between the board type and the test items. For example, pre-set the Type A unit The board corresponds to 200 test items, and the B-type single board corresponds to 150 test items. According to the classification standard, it is determined that the current single board is a type A single board, and the 200 test items corresponding to the type A single board in the preset relationship are As a standard test item for the current single board. Among them, the items to be tested during the single board hardware detection process may be set according to the specific functions of the single board or the standard working parameters of the hardware in the single board. Then, based on all standard test items corresponding to the current board, the hardware self-test script that needs to be used in the hardware self-test process is generated for the board. By setting corresponding test items for different types of boards in advance, the standard test items based on the board type are determined when generating the hardware self-test script, and the hardware self-test script is generated to ensure that the generated hardware self-test script is correct for the board. It has good pertinence and ensures the effect of hardware detection.

In addition, when the board for which a hardware self-test script needs to be generated does not belong to any existing board type, the board type can also be expanded based on the hardware data of the board, and then based on the correspondence between the hardware and the hardware test items, Combined with several pieces of hardware included in the single board, obtain the hardware test items corresponding to each hardware one by one, deduplicate the obtained set of hardware test items, and use the deduplicated set of hardware test items as the standard set of test items for the single board, and then Design hardware self-test scripts for new types of boards based on a set of standard test items.

Further, a hardware self-test script is generated based on the standard test items of the single board, including: obtaining the current hardware potential fault to be detected; obtaining the target test items related to the hardware potential fault according to the hardware potential fault; item to generate a hardware self-test script.

In the process of designing and generating a hardware self-test script for a single board, all possible hardware faults of the single board can be directly detected. At this time, the hardware self-test script needs to be able to test all standard test items of the single board. to avoid missed detection of hardware faults. In addition, when there is a clear target for hardware fault detection, in order to improve the efficiency of self-test, the hardware fault that needs to be detected can be regarded as a potential hardware fault in advance, and then there is a correlation with the potential hardware fault, which can reflect the potential hardware fault of the single board. The faulty standard test item is used as the target test item, and a hardware self-test script that can test all target test items is generated for the board to use during the hardware self-test process. By selecting some or all standard test items as target test items according to the potential faults that currently need to be detected, a hardware self-test script is generated, so that the detection range of the hardware self-test script loaded on the board can be flexibly adjusted, and the hardware can be tested through customized scripts. Self-test enables operation and maintenance personnel to quickly analyze specific faults and fault causes based on test results, improving fault detection and analysis efficiency.

For example, the current board is a type A board. Type A board has 200 standard test items. The current hardware fault to be detected is a hardware latent fault T. There are 20 standard test items related to the hardware latent fault T. , then, in the process of generating the hardware self-test script, the test items included in the hardware self-test script are set to 20 standard test items related to the hardware potential fault T, and the generation of the hardware self-test script is completed. In a specific application, there can be one or more potential hardware faults in a single hardware self-test. The designed hardware self-test script can test all standard test items related to potential hardware faults. This implementation The example does not impose any restrictions on the specific generation of hardware self-test scripts.

In addition, in order to avoid missed detection of hardware faults, you can also generate a hardware self-test script based on all standard test items of the board and publish it to the board for storage and use. When a secondary detection of a specific hardware fault is required, According to the specific hardware fault to be detected, select some target test items from all standard test items, then generate a new hardware self-test script, and package the new hardware self-test script into the tool self-test through patching In the patch package, the single board is used to detect specific hardware faults based on the new hardware self-test script. By patching the tooling self-test patch package, the hardware test scope in the single-board hardware self-test process can be realized simply and efficiently. Adjustment.

Further, generate a hardware self-test script based on the standard test items of the single board, including: obtaining the preset test duration of the single board; determining the hardware self-test based on the preset test duration and the total number of test items included in the hardware self-test script The number of test items that the script detects in a single time; set the test parallelism of the hardware self-test script based on the number of test items that are detected in a single time.

In order to ensure the efficiency of hardware self-test, during the process of generating the hardware self-test script, it is also necessary to set the test parallelism of the hardware self-test script. After obtaining the preset test duration set for the single board, obtain the hardware self-test script. The total number of test items covered by the test script, combined with the time required for each test item, the total number of test items and the preset test time expected to complete the hardware self-test, determine the parallelism of each round of testing in the hardware self-test script. The number of tested items to be detected, and based on the determined number of tested items to be detected in parallel, set the test parallelism in the hardware self-test script. For example, if the hardware self-test script covers 100 test items, the average test time of each test item is 6S, and the preset test time is 5 minutes, then two or more test items can be tested at the same time each time to be able to test within 5 seconds. The test is completed within minutes, so set the test parallelism of the hardware self-test script to an integer greater than or equal to 2. By accurately setting the test parallelism for the hardware self-test script, the hardware self-test time can be compressed, ensuring the accuracy of the hardware self-test while improving the efficiency of the hardware self-test.

In addition, when the expected completion time of the hardware self-test changes, the test parallelism of the hardware self-test script can be re-determined based on the changed expected completion time, and a new hardware self-test script can be generated. Then, the new hardware self-test script is packaged into the tooling self-test patch package through patching, so that the single board can perform parallel detection of the items to be tested with the new test parallelism based on the new hardware self-test script. The patching method of the self-test patch package simply and efficiently implements the change of test parallelism during the single-board hardware self-test, making the hardware self-test more flexible.

In addition, the hardware self-test script in the tooling self-test patch package can also be updated through patching, so that the test items in the hardware self-test script can complete the arrangement of group tests, further improving the personalization of hardware self-test.

Step 103: Restart according to the preset program to enter the tooling self-test mode, perform hardware self-test according to the hardware self-test script, and feed back the self-test results to the main control board.

After the board completes loading of the pre-cached tooling self-test patch package, it restarts according to the preset mode switching procedure and uses the files in the tooling self-test patch package as installation files, and switches the current live network mode to tooling self-test. mode, and then the board uses the hardware self-test script to perform hardware self-test based on its own hardware data, and feeds back the self-test results to the main control board.

In one example, hardware self-test is performed according to the hardware self-test script, and the self-test results are fed back to the main control board, including: obtaining the current test status and/or self-test results of the single board, and based on the current test status and/or self-test results. Or the self-test results generate a test result file; the test result file is fed back to the main control board for the main control board to parse the test result file and echo the test results.

When the board uses the hardware self-test script to perform hardware self-test, it obtains the hardware data that needs to be used in the test process according to the detection sequence of the items to be tested in the hardware script, tests each item to be tested, and records the completed results. The demerits of the items to be tested are marked as success, failure, timeout, etc., and the test duration, test rounds and other information of the completed items to be tested are counted. Then, based on the test results of the completed items to be tested, the current hardware self-test results of the single board are generated, and the current hardware self-test results of the single board are generated based on the completed items to be tested, unfinished items to be tested, and ongoing items to be tested. Check test status. Then the test status and/or hardware self-test results are arranged and packaged, the current test result file of the board is generated, and the test result file is fed back to the main control board for the main control board to parse the test result file and analyze the test results. The echo is used to facilitate operation and maintenance personnel to accurately obtain the hardware self-test results of the board. By generating test result files based on the current test status and/or hardware self-test results, the main control board can accurately echo the results of the single-board hardware self-test, which facilitates operation and maintenance personnel to accurately monitor the hardware self-test. and analysis of test results.

The test status can include: board status, that is, the running status of the single board, which can be used to distinguish whether the single board is currently in idle mode or test mode; task status, that is, the execution status of the test items of the single board that performs hardware self-test, and has been tested and untested items; test results: that is, the execution results of the test items of the single board undergoing hardware self-test, test pass and failed items, etc.

Further, feeding back the test result file to the main control board includes: feeding back the test result file to the main control board according to the query instruction of the main control board, or periodically generating and feeding back the test result file to the main control board according to a preset program. document.

During the process of the board performing hardware self-test according to the hardware self-test script, the main control board can issue a query command to the board. After receiving the query command, the board will perform the hardware self-check according to the current test status of the board and the hardware self-check results. Generate a test result file and feed the test result file back to the main control board. In order to ensure the timeliness and stability of the test result feedback, a preset test result feedback program can also be packaged in the tooling self-test patch package. The board will feedback the test result according to the program at a certain time interval, for example, 10S, 20S or 30S, etc., periodically update the generated test result file, and feed the updated test result file back to the main control board. Improve the timeliness of test result feedback by providing test result file feedback based on query instructions or preset cycles.

The main control board can also issue test commands such as pause self-test instructions, resume self-test instructions, start self-test instructions, and terminate self-test instructions to the single board according to the received instructions, to interfere with the hardware self-test process of the single board. , to further improve the flexibility of single-board hardware self-test.

To sum up, during the process of the board performing hardware self-test according to the hardware self-test script, the interaction process between the board and the main control board can be referred to Figure 2:

The Product Management Configuration (PMCFG) module of the main control board sends hardware self-test instructions to the device through the Product Communication Process (PTCP). The board switches the mode from live network mode to Work equipment self-test mode. After the tooling version is run, the board will shake hands with the PTCP process of the main control board to establish a link. The board and the main control board will synchronize board information, time information, and request File Transfer Protocol. FTP) server user name and password information. At the same time, the board directly conducts keep-alive communication with the main control board once every 10 seconds through the agreed message number. In this embodiment, the communication between the main control single board and one single board is used as an example. In practical applications, one main control single board can communicate with multiple single boards. In this embodiment, the main control single board communicates with the main control single board. There is no limit on the number of boards.

During the hardware self-test of the board, the PTCP process issues corresponding hardware instructions to the board according to the received instructions, and feeds back the information fed back by the board to the PMCFG module. Among them, if the command received by the PTCP process is a query command, it will immediately reply the test result data uploaded by the single board to the PMCFG module; if the command received is a test command (including start self-test command, pause self-test command, resume self-test command Inspection instructions, etc.), which are parsed by PTCP and sent to the self-inspection line of the board. process processing.

When the PTCP process issues a test command to the board, after receiving the test command, the board will detect whether it is currently in the hardware self-check state. If it is currently in the hardware self-check state, it will directly perform the test according to the currently recorded test state. And/or the test result file generated by the hardware test result is fed back to the PTCP process, so that PMCFG can update the current test status of the board based on the test result file fed back by the PTCP process. At this time, the user can stop the test through the main control board. command, the self-test module in the board will terminate the test suite after processing the issued test items, and update the database. PMCFG will refresh the test status and display it back to the user.

When the board detects that it has not processed the hardware self-check status, it starts the tooling version of the self-check module. The self-check module parses and delivers the hardware self-check script to the board. For example, the hardware self-check script is set In group mode, the items to be tested are executed according to the group. If the script sets the serial mode, the items to be tested are executed according to the serial rules. During the period, the self-test module executes the delivery and operation of the test items according to the rules set by the hardware self-test script. Maintenance The test sequence is scheduled and the test result file feedback is performed according to the received instructions or the preset time interval until the single board completes the hardware self-test.

During the process of uploading the test result file, since the board has requested the user name and password information of the FTP server from the main control, the tooling process can use FTP transmission technology to transfer the processed test result file and other logs used for fault location. It is sent to the main control board regularly. The self-test log is stored according to the address of the board and is used for research and development to locate faults. When receiving the query command, the main control directly parses the test result file and echoes the test results.

After performing hardware self-test according to the hardware self-test script, it also includes: receiving the live network mode switching command of the main control board; restarting according to the live network mode switching command, and restoring to the live network mode before entering the tooling self-checking mode.

After the main control board detects that the board has completed the hardware self-test, it will find the network mode switching command to the board according to the received instructions or preset program, so that the board will switch its own mode and perform the hardware self-check. live network mode. After receiving the live network mode switching command from the main control board, the single board deactivates the loading and activation of the tooling self-test patch package, changes the calling path of the installation file to the file storage address of the live network mode, and then loads and activates the live network mode by restarting. Install the installation file corresponding to the network mode, switch back to the live network mode before the hardware self-test, and resume the original business operation. By promptly switching back to the live network mode before the hardware self-test after the hardware self-test is completed, and restoring the original business operation, the hardware self-test can be avoided from having an excessive impact on the services running on the single board.

In addition, the steps of the various methods above are divided just for the purpose of clear description. During implementation, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all protected by this patent. Within the scope; adding insignificant modifications or introducing insignificant designs to the algorithm or process, but not changing the core design of the algorithm and process are within the scope of protection of this patent.

Another aspect of the embodiment of the present application relates to a single board. Referring to Figure 3, it includes:

The acquisition module 301 is used to receive hardware self-test instructions issued by the main control board.

The loading module 302 is configured to load a pre-cached tooling self-checking patch package according to the hardware self-checking instructions; wherein the tooling self-checking patch package includes a prepackaged hardware self-checking script.

The self-test module 303 is used to reboot into the tooling self-test mode according to the preset program, perform hardware self-test according to the hardware self-test script, and feed back the self-test results to the main control board.

This embodiment is a device embodiment corresponding to the method embodiment, and this embodiment can be implemented in cooperation with the method embodiment. The relevant technical details mentioned in the method embodiment are still valid in this embodiment. In order to reduce duplication, they will not be described again here. Correspondingly, the relevant technical details mentioned in this embodiment can also be applied to the method embodiment.

Each module involved in this embodiment is a logic module. In practical applications, a logic unit can be a A physical unit can also be a part of a physical unit, or can be implemented as a combination of multiple physical units. In addition, in order to highlight the innovative part of this application, units that are not closely related to solving the technical problems raised in this application are not introduced in this embodiment, but this does not mean that other units do not exist in this embodiment.

Another aspect of the embodiment of the present application also provides an electronic device. Referring to Figure 4, it includes: at least one processor 401; and a memory 402 communicatively connected to the at least one processor 401; wherein the memory 402 stores data that can be Instructions executed by at least one processor 401, the instructions are executed by at least one processor 401, so that at least one processor 401 can execute the automated detection method described in any of the above method embodiments.

The memory 402 and the processor 401 are connected using a bus. The bus may include any number of interconnected buses and bridges. The bus connects various circuits of one or more processors 401 and the memory 402 together. The bus may also connect various other circuits together such as peripherals, voltage regulators, and power management circuits, which are all well known in the art and therefore will not be described further herein. The bus interface provides the interface between the bus and the transceiver. A transceiver may be one element or may be multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. The data processed by the processor 401 is transmitted on the wireless medium through the antenna. Furthermore, the antenna also receives the data and transmits the data to the processor 401.

Processor 401 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. The memory 402 may be used to store data used by the processor 401 when performing operations.

Another aspect of the embodiments of the present application also provides a computer-readable storage medium storing a computer program. The above method embodiments are implemented when the computer program is executed by the processor.

That is, those skilled in the art can understand that all or part of the steps in the methods of the above embodiments can be completed by instructing relevant hardware through a program. The program is stored in a storage medium and includes several instructions to cause a device ( It may be a microcontroller, a chip, etc.) or a processor (processor) that executes all or part of the steps of the methods described in various embodiments of this application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disk and other media that can store program code. .

Those of ordinary skill in the art can understand that the above-mentioned embodiments are specific embodiments for implementing the present application, and in actual applications, various changes can be made in form and details without departing from the scope of the present application.

Claims

An automated detection method including:

Receive hardware self-test instructions issued by the main control board;

Load a pre-cached tooling self-checking patch package according to the hardware self-checking instructions; wherein the tooling self-checking patch package includes a prepackaged hardware self-checking script;

Restart according to the preset program to enter the tooling self-test mode, perform hardware self-test according to the hardware self-test script, and feed back the self-test results to the main control board.
The automated detection method according to claim 1, wherein the hardware self-test script can be generated in the following manner:

Get the board type of the board;

Determine the standard test items of the single board according to the corresponding relationship between the single board type and the test items;

The hardware self-test script is generated according to the standard test items of the single board.
The automated detection method according to claim 2, wherein generating the hardware self-test script according to the standard test items of the single board includes:

Obtain the potential hardware fault currently to be detected;

According to the potential hardware failure, obtain target test items related to the potential hardware failure;

The hardware self-test script is generated according to the target item to be tested.
The automated detection method according to claim 2, wherein generating the hardware self-test script according to the standard test items of the single board includes:

Obtain the preset test duration of the single board;

According to the preset test duration and the total number of items to be tested included in the hardware self-test script, determine the number of items to be tested in a single test by the hardware self-test script;

According to the number of items to be tested in a single detection, test parallelism is set for the hardware self-test script.
The automated detection method according to claim 1, wherein said loading a pre-cached tooling self-test patch package according to the hardware self-test instruction includes:

According to the hardware self-test instruction, the file calling path of the single board is modified from the installation file storage path of the currently running live network mode to the installation file storage path of the tooling self-test mode.
The automated detection method according to claim 1, wherein the step of performing hardware self-test according to the hardware self-test script and feeding back the self-test results to the main control board includes:

Obtain the current test status and/or self-test results of the single board, and generate a test result file based on the current test status and/or self-test results;

The test result file is fed back to the main control board, so that the main control board can parse the test result file and echo the test results.
The automated detection method according to claim 6, wherein the feedback of the test result file to the main control board includes:

The test result file is fed back to the main control board according to the query instruction of the main control board, or the test result file is periodically generated and fed back to the main control board according to a preset program.
The automated detection method according to any one of claims 1 to 7, wherein after the hardware self-test is performed according to the hardware self-test script, it further includes:

Receive the live network mode switching instruction of the main control board;

Restart according to the current network mode switching instruction and restore to the current network mode before entering the tooling self-test mode.
A single board, including:

The acquisition module is set to receive the hardware self-test instructions issued by the main control board;

A loading module configured to load a pre-cached tooling self-checking patch package according to the hardware self-checking instructions; wherein the tooling self-checking patch package includes a prepackaged hardware self-checking script;

The self-test module is configured to reboot into the tooling self-test mode according to a preset program, perform hardware self-test according to the hardware self-test script, and feed back the self-test results to the main control board.
An electronic device including:

at least one processor; and,

a memory communicatively connected to the at least one processor; wherein,

The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor, so that the at least one processor can perform as claimed in any one of claims 1 to 8 The automated detection method described above.
A computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the automated detection method according to any one of claims 1 to 8 is implemented.