Automatic PCBA comprehensive test method and system

Abstract

The invention belongs to the field of embedded system test technology and industrial automation, and discloses an automatic PCBA comprehensive test method and system, and the method comprises the steps: carrying out the power-on processing of a to-be-tested PCBA board card; detecting a PCBA board card to be tested which runs a board card program under the same local area network, establishing connection, detecting peripheral information to be tested, and reporting a detection result to the upper computer; generating a board card serial number by using an SM3 Hash algorithm and combining with a stream encryption algorithm; the PCBA board card to be tested is tested, and the test process and the test result are visually displayed through the upper computer; and binding a test result with a fault code and a board card serial number generated in the test process, and storing the test result as a test log. According to the invention, the problems of high specificity and low reuse rate of traditional test equipment can be solved, rapid adaptation of PCBA of multiple models is realized, and the problem of repeated development of multi-peripheral test is eliminated.

Description

Technical Field

[0001] The present invention relates to the field of embedded system testing technology and industrial automation, and particularly to an automated PCBA comprehensive testing method and system. Background Art

[0002] In modern electronic manufacturing, the PCBA board is the core component responsible for implementing the main functions of electronic devices. With the rapid development of technology, electronic products are becoming increasingly complex and high-performance, which places higher requirements on the quality of PCBA boards. Efficient and accurate testing of PCBA boards not only affects the quality of the final product but also relates to production costs and efficiency. In this context, the development and application of more advanced PCBA testing technologies become particularly important.

[0003] Currently, the traditional PCBA testing methods have the following problems:

[0004] Poor software compatibility: Separate test programs need to be developed for different peripherals, resulting in a long development cycle.

[0005] Low automation level: The testing process relies on manual operations, with a high rate of human misjudgment, especially difficult to accurately detect tiny signals.

[0006] Complex operation: Testers need to manually switch test items and configure parameters, and the full-function testing of a single board takes a long time.

[0007] Poor system compatibility: Traditional testing solutions have a single function and lack scalability, making it difficult to adapt to new interfaces.

[0008] Lack of standardized management: It is impossible to automatically associate test data with the board card serial number, making traceability difficult.

[0009] Therefore, how to provide an automated PCBA comprehensive testing method and system is an urgent problem to be solved currently. Summary of the Invention

[0010] Embodiments of the present invention provide an automated PCBA comprehensive testing method and system to solve the problems in the prior art.

[0011] To provide a basic understanding of some aspects of the disclosed embodiments, a simple summary is given below. This summary part is not a general review, nor is it intended to identify key / important constituent elements or delineate the protection scope of these embodiments. Its sole purpose is to present some concepts in a simple form as a prelude to the detailed description that follows.

[0012] According to the first aspect of the embodiments of the present invention, an automated PCBA comprehensive testing method is provided.

[0013] In one embodiment, an automated PCBA comprehensive testing method includes:

[0014] Place the PCBA board to be tested on a pre-configured fixture, and power on the PCBA board to be tested to start the board program of the PCBA board to be tested;

[0015] Use the host computer to automatically detect the PCBA board to be tested that has run the board program under the same local area network, establish a connection, detect the peripheral information to be tested based on the board program, and report the detection result to the host computer;

[0016] Based on the detection result, the host computer uses the SM3 hashing algorithm and combines it with a stream encryption algorithm to generate a board serial number;

[0017] List the test items of the PCBA board to be tested through the host computer, test the PCBA board to be tested, and visually display the test process and test results through the host computer;

[0018] Bind the test result with the fault code and board serial number generated during the test process, and store it as a test log.

[0019] In one embodiment, the host computer uses the SM3 hashing algorithm and combines it with a stream encryption algorithm to generate a board serial number based on the detection result, including:

[0020] Use a pre-configured hardware RNG module to generate a random salt value;

[0021] Obtain the MAC address and timestamp of the PCBA board to be tested, and perform data splicing on the random salt value, MAC address, and timestamp to obtain spliced data;

[0022] Perform data expansion on the spliced data, and use the SM3 hashing algorithm to hash the expanded data to obtain hashed data;

[0023] Use the stream encryption algorithm to encrypt the hashed data, and perform final calculation using the SHA-256 algorithm to obtain the board serial number.

[0024] In one embodiment, using the stream encryption algorithm to encrypt the hashed data and performing final calculation using the SHA-256 algorithm to obtain the board serial number includes:

[0025] Derive the hashed data as a key, and generate a Nonce value through a pre-configured hardware RNG module;

[0026] Use the stream encryption algorithm to generate a key stream, perform an exclusive OR operation on the hashed data as the plaintext and the key stream to generate mixed encrypted data;

[0027] Calculate the SHA-256 of the mixed encrypted data, and obtain the board serial number by selecting a preset byte digest.

[0028] In one embodiment, the testing of the PCBA board to be tested includes: function testing, performance testing, and driver initialization;

[0029] The function testing includes:

[0030] Obtain the function test instruction sent by the host computer, and perform initialization processing on the function test items;

[0031] After the initialization of the function test items is completed, perform function testing on the PCBA board to be tested, and after the testing is completed, release the peripheral resources to restore the PCBA board to be tested to the initial state;

[0032] Determine whether the test item requires restarting the device to verify the test result. If so, wait for all test items to be executed, report the test status to the host computer, and restart the device. After the device restarts, the host computer sends a restart verification result instruction and verifies the test result to obtain the verification result; otherwise, the test ends;

[0033] The performance testing includes:

[0034] Obtain the performance test instruction sent by the host computer, and perform initialization processing on the performance test items;

[0035] After the initialization of the performance test items is completed, perform performance testing on the PCBA board to be tested;

[0036] During the performance testing process, determine whether it is necessary to terminate the test. If so, release the peripheral resources to restore the PCBA board to be tested to the initial state to obtain the test result. Otherwise, continue to perform performance testing on the PCBA board to be tested;

[0037] The driver initialization includes:

[0038] Based on the pre-defined variable size of the data type, allocate private data space for the driver, and after the allocation is completed, store the private data;

[0039] Use the configuration parsing function to parse the private attribute parameters of the PCBA board to be tested to obtain the private attributes;

[0040] Based on the obtained private attributes, use the driver detection function to initialize the driver.

[0041] In one embodiment, the device auto-discovery protocol includes:

[0042] When the host computer starts, it sends a broadcast packet with the destination address being the limited broadcast address;

[0043] The device - end response contains JSON data with a device - name flag bit.

[0044] According to the second aspect of the embodiments of the present invention, an automated PCBA comprehensive test system is provided.

[0045] In one embodiment, the automated PCBA comprehensive test system includes:

[0046] A hardware IO unit for providing a physical interface for the device under test;

[0047] A bottom - layer unit for implementing the operation of peripheral devices;

[0048] A core - layer unit for providing a unified peripheral - operation interface;

[0049] A test - item unit for providing the peripheral - device items to be tested on the target board;

[0050] A main - framework unit for carrying the main framework of the program.

[0051] In one embodiment, the hardware IO unit includes:

[0052] A communication - interface module for implementing multi - protocol physical - signal conversion;

[0053] A register - mapping module for providing a hardware - register access interface.

[0054] In one embodiment, the bottom - layer unit includes:

[0055] A physical - driver module for connecting and operating hardware devices;

[0056] A virtual - driver module for providing an analog communication interface;

[0057] A dynamic - binding module for selecting a driver mode according to the configuration;

[0058] In one embodiment, the core - layer unit includes:

[0059] An event - scheduling engine module for managing an event queue, for application - layer modules to call, and dynamically configuring test logic based on priority tags and dependency relationships;

[0060] A protocol - abstraction interface module for unifying the peripheral - operation methods and communication protocols of different drivers;

[0061] Among them, the dynamically configuring test logic based on priority tags and dependency relationships includes:

[0062] Updating the ready queue using atomic instructions;

[0063] I / O intensive task automatic priority boost flag bit;

[0064] Use initialization test items, basic function test items, and final inspection test items to divide the test phase, configure dependencies, and control the test order of each part;

[0065] Hardware IO reads use memory barriers.

[0066] In one embodiment, the test item unit includes:

[0067] An application layer module for performing related operations depending on the core layer unit to implement test logic;

[0068] A device test logic module for the specific test logic of the peripheral device;

[0069] A fault diagnosis module for performing fault diagnosis using standard Linux fault codes;

[0070] In one embodiment, the main framework unit includes:

[0071] An upper computer communication module for communicating with the upper computer;

[0072] A configuration test item module for dynamically loading the test items to be tested through a json file to activate the corresponding test modules;

[0073] A test information summary module for uniformly summarizing the test results, logs and other information to the upper computer.

[0074] According to the third aspect of the embodiments of the present invention, a computer device is provided.

[0075] In some embodiments, the computer device includes a memory and a processor, the memory stores a computer program, and when the processor executes the computer program, the steps of the above method are implemented.

[0076] According to the fourth aspect of the embodiments of the present invention, a computer-readable storage medium is provided.

[0077] In one embodiment, a computer program is stored on the computer-readable storage medium, and when the computer program is executed by the processor, the steps of the above method are implemented.

[0078] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects:

[0079] The present invention can solve the problems of strong specificity and low reuse rate of traditional test equipment, achieve rapid adaptation of multiple models of PCBA, eliminate the repetitive development problems of multi-peripheral testing, realize the testing ability of "one deployment, full peripheral coverage", reduce manual operation links, eliminate the inefficiency and misjudgment risks caused by manual operation, construct a fully automated testing process, and greatly shorten the testing time; break through the single function limit, provide the comprehensive testing ability of different test schemes for different peripherals; realize the automatic binding of test data and board card identity information, and improve the quality management efficiency.

[0080] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0081] The drawings herein are incorporated into the specification and form a part of the specification, showing embodiments consistent with the present invention, and are used together with the specification to explain the principles of the present invention.

[0082] Figure 1 is a flowchart of an automated PCBA comprehensive testing method shown according to an exemplary embodiment;

[0083] Figure 2 is a schematic block diagram of an automated PCBA comprehensive testing system shown according to an exemplary embodiment;

[0084] Figure 3 is a schematic structural diagram of a computer device shown according to an exemplary embodiment;

[0085] Figure 4 is a decomposition diagram of an automated PCBA comprehensive testing system shown according to an exemplary embodiment;

[0086] Figure 5 is a display diagram of the LAN device discovery protocol in an automated PCBA comprehensive testing method shown according to an exemplary embodiment;

[0087] Figure 6 is an overall testing flowchart in an automated PCBA comprehensive testing method shown according to an exemplary embodiment;

[0088] Figure 7 is a functional testing flowchart in an automated PCBA comprehensive testing method shown according to an exemplary embodiment;

[0089] Figure 8 is a performance testing flowchart in an automated PCBA comprehensive testing method shown according to an exemplary embodiment;

[0090] Figure 9It is a flowchart for driving initialization in an automated PCBA comprehensive test method shown according to an exemplary embodiment. Detailed implementation manners

[0091] The following description and the accompanying drawings fully disclose the specific implementation manners herein, enabling those skilled in the art to practice them. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. The scope of the embodiments herein includes the entire scope of the claims and all available equivalents of the claims. Herein, the terms "first", "second", etc. are only used to distinguish one element from another, without requiring or implying any actual relationship or order between these elements. In fact, the first element can also be called the second element, and vice versa. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a structure, device or equipment including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such structure, device or equipment. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of another identical element in the structure, device or equipment including the said element. The embodiments herein are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts among the embodiments can be referred to each other.

[0092] The terms "longitudinal", "transverse", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc. herein indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings. They are only for the convenience of describing the present text and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus cannot be construed as a limitation to the present invention. In the description herein, unless otherwise specified and limited, the terms "mounted", "connected" and "coupled" shall be understood in a broad sense. For example, it can be a mechanical connection or an electrical connection, or can also be the internal communication of two elements. It can be directly connected or indirectly connected through an intermediate medium. For those of ordinary skill in the art, the specific meanings of the above terms can be understood according to specific circumstances.

[0093] Herein, unless otherwise stated, the term "plurality" means two or more.

[0094] Herein, the character " / " indicates that the objects before and after are in an "or" relationship. For example, A / B means: A or B.

[0095] In this text, the term "and / or" describes the relationship between objects and indicates that three relationships can exist. For example, A and / or B means: A or B, or, the three relationships of A and B.

[0096] It should be understood that although the steps in the flowchart are sequentially displayed according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise clearly stated in this text, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, at least a part of the steps in the figure may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed alternately or in turn with at least a part of other steps or sub-steps or stages of other steps.

[0097] Each module in the device or system of this application can be implemented in whole or in part by software, hardware, and their combination. The above-mentioned modules can be embedded in the processor in the computer device in hardware form or be independent of it, or can be stored in the memory in the computer device in software form, so that the processor can call and execute the operations corresponding to each of the above modules.

[0098] Without conflict, the embodiments in the present invention and the features in the embodiments can be combined with each other.

[0099] Figure 1 An embodiment of the automated PCBA comprehensive test method of the present invention is shown.

[0100] In this alternative embodiment, the automated PCBA comprehensive test method includes:

[0101] Step S101, place the PCBA board to be tested on a pre-configured fixed fixture, and perform power-on processing on the PCBA board to be tested to start the board program of the PCBA board to be tested;

[0102] It should be noted that the fixed fixture has a board positioning slot and an elastic conductive contact array, and the contact array matches the test point positions of the PCBA board to be tested;

[0103] Step S102, use the host computer to automatically detect the PCBA board to be tested that has run the board program under the same local area network, establish a connection, detect the information of the peripherals to be tested based on the board program, and report the detection result to the host computer;

[0104] Step S103, the host computer generates a board serial number according to the detection result, using the SM3 hashing algorithm and combining with the stream encryption algorithm;

[0105] Step S104: List the test items of the PCBA board to be tested through the host computer, test the PCBA board to be tested, and visually display the test process and test results through the host computer;

[0106] Step S105: Bind the test results with the fault codes and board serial numbers generated during the test process, and store them as test logs.

[0107] In this alternative embodiment, the host computer generates the board serial number according to the detection result, using the SM3 hashing algorithm and combining with the stream encryption algorithm, including:

[0108] Generate a random salt value using a pre-configured hardware RNG module;

[0109] Obtain the MAC address and timestamp of the PCBA board to be tested, and perform data splicing on the random salt value, MAC address and timestamp to obtain spliced data;

[0110] Perform data expansion on the spliced data, and perform hashing on the expanded data using the SM3 hashing algorithm to obtain hashed data;

[0111] Encrypt the hashed data using the stream encryption algorithm, and perform final calculation using the SHA-256 algorithm to obtain the board serial number.

[0112] In this alternative embodiment, the encrypting the hashed data using the stream encryption algorithm and performing final calculation using the SHA-256 algorithm to obtain the board serial number includes:

[0113] Derive the hashed data as the key, and generate a Nonce value (in cryptography, Nonce is an arbitrary or non-repeating random value used only once) through a pre-configured hardware RNG module;

[0114] Generate a key stream using the stream encryption algorithm, perform exclusive OR operation on the hashed data as the plaintext and the key stream to generate mixed encrypted data;

[0115] Calculate SHA-256 for the mixed encrypted data, and obtain the board serial number by selecting a preset byte digest.

[0116] In this alternative embodiment, the testing of the PCBA board to be tested includes: function testing, performance testing and driver initialization;

[0117] The function test includes: obtaining the function test instruction sent by the host computer and performing initialization processing on the function test items; after the initialization of the function test items is completed, performing a function test on the PCBA board to be tested, and after the test is completed, releasing the peripheral resources to restore the PCBA board to be tested to its initial state; determining whether the test item requires restarting the device to verify the test result. If so, after all test items are executed, reporting the test status to the host computer and restarting the device. After the device restarts, the host computer sends a restart verification result instruction and verifies the test result to obtain the verification result; otherwise, the test ends.

[0118] Specifically, after the main framework receives the function test instruction sent by the host computer, it initializes the test items by calling the init function pointer in the AppLevelOpsObj structure in the driver. The init function pointer is defined by the driver itself, and the function pointer definition is as follows: int(*init)(DeviceHandle hDevice);

[0119] After the initialization of the test items is completed, the main framework executes the test by calling the task function pointer in the AppLevelOpsObj structure in the driver. The task function pointer is defined by the driver itself. The task function pointer definition is as follows: int(*task)(DeviceHandle hDevice);

[0120] After the test is completed, the main framework releases the peripheral resources by calling the exit function pointer in the AppLevelOpsObj structure in the driver and restores the PCBA board to be tested to its initial state. The exit function pointer is defined by the driver itself. The exit function pointer definition is as follows: void(*exit)(DeviceHandle hDevice);

[0121] The main framework determines whether the test item requires restarting the device to verify the test result. If not, the test ends. If so, the FTS (main framework) waits for all test items to be executed, reports the test status to the host computer, and restarts the device. After the device restarts, the host computer sends a restart verification result instruction. After receiving the instruction, the main framework verifies the test result by calling the rebootConfirm function pointer in the AppLevelOpsObj structure in the driver. The rebootConfirm function pointer is defined by the driver itself, and the rebootConfirm function pointer definition is as follows: int(*rebootConfirm)(DeviceHandle hDevice);

[0122] The performance test includes: obtaining a performance test instruction issued by the host computer and performing initialization processing on performance test items; after the initialization of performance test items is completed, performing a performance test on the PCBA board under test; during the performance test, determining whether it is necessary to terminate the test. If so, by releasing peripheral resources, restoring the PCBA board under test to its initial state to obtain the test result. Otherwise, continue to perform the performance test on the PCBA board under test;

[0123] Specifically, the test items are initialized by calling the init function pointer in the AppLevelOpsObj structure in the driver. The init function pointer is defined by the driver itself, and the definition of the init function pointer is as follows: int(*init)(DeviceHandle hDevice);

[0124] After the initialization of the test items is completed, the main framework will execute the test by calling the task function pointer in the AppLevelOpsObj structure in the driver. The task function pointer is defined by the driver itself. The definition of the task function pointer is as follows: int(*task)(DeviceHandle hDevice);

[0125] Determine whether to terminate the test. If not, continue to execute the test. Otherwise, the test is completed. After the test is completed, the main framework releases the peripheral resources by calling the exit function pointer in the AppLevelOpsObj structure in the driver and restores the PCBA board under test to its initial state. The exit function pointer is defined by the driver itself. The definition of the exit function pointer is as follows: void(*exit)(DeviceHandle hDevice);

[0126] The driver initialization includes: allocating private data space for the driver based on the variable size of a predefined data type, and after the allocation is completed, storing the private data; using a configuration parsing function to configure and parse the private attribute parameters of the PCBA board under test to obtain the private attributes; based on the obtained private attributes, using a driver detection function to initialize the driver.

[0127] Specifically, the main framework allocates private data space for the driver according to the variable size of privSize (the private data size defined in the DriverObj structure) defined in the driver in the DriverObj structure. After the allocation is completed, the private data pointer will be stored in privData of the DriverObj structure, and other functions in the driver can obtain this private data through privData (the private data pointer defined in the DriverObj structure);

[0128] The private attribute parameters of the device are defined in the configuration file BoardCfg.json. The main framework is responsible for parsing the entire configuration file and completing the private configuration parsing of each driver through the configuration parsing function pointer of the driver. The driver developer needs to implement the configuration parsing function according to the API functions of various types of variables provided by the main framework for the main framework to call. The configuration parsing function pointer is defined as follows:

[0129] int(*cfgParse)(ParamRootHandle hParamRoot,PrivDataHandle hPrivData);

[0130] The driver probe function pointer is only called once during the driver initialization phase. Developers can implement some operations that do not need to be executed repeatedly in this function. The specific implementation can be defined according to the actual situation. This function is optional and depends on whether it is needed. The function pointer is defined as follows: int(*probe)(DeviceHandle hDevice).

[0131] In addition, the underlying driver development includes:

[0132] It is necessary to implement the probe / remov (driver detection / uninstallation) function to complete the device life cycle management;

[0133] Use cfgParse (parameter parsing function pointer) to parse the device private parameters;

[0134] Expose the standard operation function set through hOps (driver private operation function);

[0135] In this alternative embodiment, the device auto-discovery protocol includes:

[0136] When the host computer starts, it sends a broadcast packet with the destination address being the limited broadcast address;

[0137] The device side responds with JSON data containing the device name flag bit.

[0138] Figure 2 An embodiment of the automated PCBA comprehensive test system of the present invention is shown.

[0139] In this alternative embodiment, an automated PCBA comprehensive test system includes:

[0140] The hardware IO unit 100 is used to provide the physical interface of the device under test;

[0141] The underlying unit 200 is used to implement the operation of the peripherals, implement the hardware driver and the specific test operation;

[0142] The core layer unit 300 is used to provide a unified operation interface for external peripherals (PCBA boards to be tested), and provide a protocol abstraction interface and an event scheduling engine;

[0143] The test item unit 400 is used to provide the external peripheral items to be tested on the target board;

[0144] The main framework unit 500 is used to carry the main framework of the program.

[0145] In this alternative embodiment, the hardware IO unit 100 includes:

[0146] The communication interface module 101 is used to implement multi-protocol physical signal conversion;

[0147] The register mapping module 102 is used to provide a hardware register access interface.

[0148] In this alternative embodiment, the underlying unit 200 includes:

[0149] The physical drive module 201 is used to connect and operate hardware devices;

[0150] The virtual drive module 202 is used to provide an analog communication interface;

[0151] The dynamic binding module 203 is used to select a drive mode according to the configuration;

[0152] In this alternative embodiment, the core layer unit 300 includes:

[0153] The event scheduling engine module 301 is used to manage the event queue, for the application layer module 401 to call, and dynamically configure the test logic based on the priority tag and the dependency relationship;

[0154] The protocol abstraction interface module 302 is used to unify the operation methods and communication protocols of external peripherals with different drivers;

[0155] Among them, the dynamic configuration of the test logic based on the priority tag and the dependency relationship includes: using atomic instructions to update the ready queue; automatically raising the priority tag bit for I / O intensive tasks; using initialization test items, basic function test items, and final inspection test items to divide the test stages, configure the dependency relationship, and control the test order of each part; using memory barriers for hardware IO reads.

[0156] Specifically, use the __sync_fetch_and_or() atomic instruction to update the ready queue;

[0157] Automatically raise the priority tag bit (0x80) for I / O intensive tasks;

[0158] Use initIterm (initialize test items), baseIterm (basic function test items), and finalIterm (final test items) to divide the test phases, configure the dependency relationships, precisely control the test order of each part, and prevent compatibility failures;

[0159] For hardware IO reading, use memory barriers: mb() / rmb() (a way to implement memory barriers).

[0160] In this alternative embodiment, the test item unit 400 includes:

[0161] The application layer module 401 is used to execute related operations depending on the core layer unit 300 to implement the test logic;

[0162] The device test logic module 402 is used for the specific test logic of the peripherals;

[0163] The fault diagnosis module 403 is used to perform fault diagnosis using standard Linux fault codes;

[0164] In this alternative embodiment, the main framework unit 500 includes:

[0165] The host computer communication module 501 is responsible for communicating with the host computer;

[0166] The configuration test item module 502 is used to dynamically load the test items to be tested through a json file to activate the corresponding test modules;

[0167] The test information summary module 503 is used to uniformly summarize the test results, logs and other information to the host computer.

[0168] Generally speaking, the present invention adopts the collaborative design of a modular and reconfigurable hardware platform + intelligent test management software to achieve fast hardware adaptation and software algorithm decoupling. The overall technical architecture is divided into:

[0169] Hardware platform: test tooling platform (supporting the connection of all peripherals of the board);

[0170] Embedded software layer: embedded test engine (supporting dynamic loading of peripherals);

[0171] Host computer application layer: visual test management platform (multi-device collaborative control);

[0172] The present invention can also achieve:

[0173] (1) Fast adaptation solution for multiple models of boards;

[0174] Technical means: standardized interface board, supporting fast switching.

[0175] Function: Achieve rapid adaptation of multiple models of PCBA boards.

[0176] Inventive point: Adopt a spring + contact matrix, cooperate with a quick-release interface board, shorten the replacement time, and improve the adaptability and switching efficiency.

[0177] Workflow: Replace the model of the board under test → Replace the interface board (operation time ≤ 30 seconds) → The system automatically loads the preset parameters → The probe self-calibrates.

[0178] (2) Peripheral full-coverage test solution;

[0179] Technical means: Design of dynamic test module loading, automatically detect the test items according to the PCBA board;

[0180] Technical function: Eliminate duplicate development in the peripheral test part;

[0181] Inventive point:

[0182] a) Adopt a four-layer architecture model (as Figure 4 shown), the driver model design of the Linux-like device tree, realize the separation of devices and drivers, support dynamic loading (through configurable module attributes), and provide a unified operation interface set;

[0183] b) Application layer 401: Implement test logic (such as RS485 loopback test), call peripheral operations through the core layer interface, and prohibit direct hardware operation;

[0184] c) Core layer 300: Abstract a unified peripheral interface, solve the operation differences of different drivers, provide device management APIs, and support reuse;

[0185] d) Bottom layer 200: Implement specific hardware drivers, and realize "plug and play" development through the DriverObj (driver object) structure;

[0186] e) Hardware IO 100: Support standard hardware specifications, and can be flexibly adapted to non-standard interfaces based on the first three layers;

[0187] f) Multilevel linked list management system, dynamically manage resources such as test items, devices, tasks, etc., support fast traversal and addition / removal operations, and improve the program operation efficiency;

[0188] g) Three-level test system: Support test stage division, configurable dependency relationships, accurately control the test order of each part, and prevent compatibility failures;

[0189] h) The embedded program uses bit fields to achieve precise register-level control, greatly optimize memory usage, and enable support for more PCBA boards with weak hardware performance;

[0190] i) Use the json library to communicate with the host computer, tooling, and programs, support dynamic library loading, actively detect the peripherals to be tested, and automatically configure the test plan.

[0191] In addition, the above architecture has the following advantages:

[0192] a) Scalability: For newly added devices, only the standard driver interface needs to be implemented. When special peripheral development is required, the development cycle can be shortened from 2 weeks to 2 days.

[0193] b) Maintainability: The layered design isolates hardware differences, the modular architecture reduces coupling, and the unified error handling mechanism reduces the difficulty of maintenance, making it suitable for long-term development.

[0194] c) This architecture is particularly suitable for industrial automation test scenarios that require high reliability and multi-device management. Its modular design enables the system to maintain the stability of the core framework while quickly adapting to different hardware platforms and test requirements.

[0195] The specific workflow is as follows: The program detects the type of peripherals on the board to be tested → Dynamically load the corresponding test module → Concurrently execute function verification.

[0196] (3) Automated test process;

[0197] Technical means: Test tooling + Embedded software + Windows host computer control;

[0198] Technical effect: Reduce manual operation links and reduce test errors caused by manual operation;

[0199] Inventive point: The program runs automatically, judges the test items by itself, conducts multi-protocol concurrent testing of different modules, and supports simultaneous testing of 10+ peripherals;

[0200] Workflow: Load the board → Scan the code to bind the SN number → Press the probe → Automatically archive the test results.

[0201] (4) Automated binding of test data;

[0202] Technical means: SN automated binding system;

[0203] Technical effect: Realize the association between test data and the board. Each PCBA board to be tested has a unique serial number, enabling accurate traceability and error location;

[0204] Inventive point: Generate a unique serial number based on the MAC address and timestamp. The host computer automatically binds it to the PCBA board and generates a test record;

[0205] Workflow: Input the SN with a barcode scanner → Store the test data in real time → Automatically generate a test log.

[0206] To facilitate the understanding of the above technical solution of the present invention, the RS485 serial port module test is taken as an example for further illustration, as follows:

[0207] Example 1: Device Automatic Discovery and Test Process (as Figures 5-6 shown):

[0208] Hardware connection: Fix the PCBA device to be tested on the test platform fixture, making its back contacts fit with the fixture contact probes (in the case of not using the fixture, the hardware to be tested can also be connected by itself).

[0209] Use a USB to serial port module to connect the PC and the fixture (directly connect the PCBA device when not using the fixture)

[0210] Turn on the power of the PCBA device to be tested, and the board program will run automatically.

[0211] Software configuration: When the host computer starts, it sends a broadcast packet (function code 0x8, protocol header 0xAA55), and the destination address is the limited broadcast address 255.255.255.255:8887;

[0212] The FTS device responds with JSON data containing device information (function code 0x1), example:

[0213] {

[0214] "devName":"HZ-PCBA-2024",

[0215] "itermLen":5,

[0216] "itermVal":

[0217] {"code":0,"name":"RS485_1","reboot":false,"isManual":false},

[0218] {"code":1,"name":"LED_TEST","reboot":true,"isManual":true}

[0220] }

[0221] Among them, the host computer dynamically updates the device list and test items through the "devName" and "itermVal" fields (device name flag bits) in the device response.

[0222] Test execution:

[0223] The barcode scanner inputs the SN number of the PCBA board (or a unique SN is automatically generated, and the SN is the board serial number);​

[0224] Check the test items (such as RS485_1, LED_TEST), select the test mode (such as functional test, performance test), and start the concurrent test;

[0225] The core layer unit 300 sends test instructions through hOps->send(), and the underlying unit 200 operates the hardware register module 102;

[0226] The test results are displayed in real time, and the logs are automatically associated with the SN number and stored in the database.

[0227] Note: Functional test: Only execute once, used to verify the feasibility of the module function (as Figure 7 shown);

[0228] Performance test: Execute infinitely, used to verify the stability of the module function (as Figure 8 shown);

[0229] Embodiment 2: Driver development and parameter parsing;

[0230] 1. Device tree configuration;

[0231] Define the device tree in the json configuration file, example:

[0232] "RS485_1":{ / / Test item name

[0233] "appLevel":{ / / Parameter set of the application layer module (401)

[0234] "compatible":"multiSerial", / / Used to match the device types supported by the application layer driver

[0235] "baudRate":[9600,38400,115200] / / Serial port baud rate array, which is a private attribute of the serial port device

[0236] },

[0237] "coreLevel":{ / / Parameter set of the core layer unit (300), which can include multiple peripheral core layer devices

[0238] "serialCore":[ / / Serial port core layer name, used for binding the core layer device and the driver

[0239] {

[0240] "name":"serial-0", / / When using this serial port in the application, the device descriptor of this serial port can be obtained by name

[0241] "compatible": "genericSerial", / / Used to match the device types supported by the underlying driver

[0242] "device": " / dev / ttyS3" / / Serial port device node, which is a private attribute of the serial port device

[0243] },

[0245] }

[0246] }

[0247] Driver loading process (as Figure 9 shown);

[0248] probe() function: Parse the private parameters of the device. Example:

[0249] int serial_probe(DeviceHandle hDev) {

[0250] / / 1. Call cfgParse to parse the private parameters of the device such as baud rate

[0251] GetObjectIntArrayMember(hParam, "baudRate", 0, &baud);

[0252] / / 2. Initialize the UART controller (register mapping to 0xFE000000)

[0253] writel(baud, UART_BASE + UART_BAUD_REG);

[0254] / / 3. Register the device to the core layer linked list

[0255] core_layer_add_device(hDev);

[0256] }

[0257] remove() function: Release the memory and unregister the device (device lifecycle management)

[0258] hOps pointer: Expose the set of private driver operation functions

[0259] struct SerialOps {

[0260] / / Serial port initialization operation

[0261] int(*init)(DeviceHandle hDev);

[0262] ​ / / Serial port data sending operation

[0263] int(*send)(DeviceHandle hDev,uint8_t*data,size_t len);

[0264] / / Serial port data receiving operation

[0265] int(*recv)(DeviceHandle hDev,uint8_t*buf,size_t timeout);

[0266] };

[0267] Note: The device private parameter types include: device node, baud rate array, and other hardware IO related configurations.

[0268] Example 3: SN generation algorithm implementation process;

[0269] 1. SM3 hash calculation;

[0270] 1) Acquisition of original data:

[0271] After the board is powered on, the hardware RNG module (hardware random number generator, such as STM32 TRNG) generates a random salt value (8 bytes);

[0272] Read the board MAC address (6 bytes) and Unix timestamp (8 bytes);

[0273] 2) The MAC address + Unix timestamp + salt value constitute 22 bytes (176 bits) of original data.

[0274] 3) Data expansion: Append the 0x80 flag bit, pad with 0x00 to 448 bits, and append a 64-bit original data length field (a total of 512 bits);

[0275] 4) SM3 hash processing, example:

[0276] mbedtls_sm3(input_data,24,hash1); / / Output 32 bytes (256 bits) of hash1

[0277] 2. ChaCha20 encryption processing:

[0278] 1) Use the hash1 value (256 bits) for key derivation;

[0279] 2) Generate a 12-byte (96-bit) Nonce through the hardware RNG, example:

[0280] trng_read(nonce,12); / / Generate a unique Nonce each time

[0281] 3) Use ChaCha20 to generate the key stream. Example:

[0282] chacha20_generate_keystream(hash1, nonce, keystream); / / Outputs a 64-byte (512-bit) key stream

[0283] 4) Use hash1 as the plaintext and XOR it with the first 32 bytes (256 bits) of the key stream (chacha_key) to generate 32 bytes of mixed encrypted data;

[0284] for(int i = 0; i < 32; i++){

[0285] mixed_data[i] = keystream[i] ^ hash1[i];

[0286] }

[0287] 3. Final processing with SHA-256:

[0288] Calculate SHA-256 for the mixed data, take the entire 32-byte digest, encode it in ASCII, and use it as the SN number. Example:

[0289] sha256(mixed_data, 32, final_hash);

[0290] hex_to_ascii(final_hash, 32, sn); / / Outputs 64-character ASCII

[0291] Note: SM3 algorithm: National Cryptographic Hash Algorithm Standard (GB / T 32905-2016) issued by the State Cryptography Administration;

[0292] ChaCha20: A stream cipher algorithm standardized by IETF RFC 8439;

[0293] SHA-256: A cryptographic hash function defined in NIST FIPS 180-4, which outputs a 32-byte digest.

[0294] In summary, the present invention has the following technical effects:

[0295] Decoupling of hardware and software: There are general software and general hardware test platforms for different peripherals, eliminating the need to develop special software modules for the peripherals to be tested and hardware tooling adapted to the software. The development cost is reduced by 70%, and the development cycle is shortened by 80%.

[0296] Quality Precision Breakthrough: Automated operation reduces errors caused by manual operation while improving efficiency. Especially in tests of projects with 10 or more items, automated operation reduces the misjudgment rate to 1.0%.

[0297] Intelligent Upgrade of Operations: Automatically detect items to be tested, automatically bind serial numbers, automatically summarize data, and self-locate faults.

[0298] Direct Cost Savings: The equipment reuse rate is increased by 3 times, and there is no need to purchase / develop new machines to adapt to different models; the development cost is reduced by 70%, and there is no need for special development; the maintenance cost is saved by 50%, and only the damaged part needs to be replaced when the test hardware is damaged; software operation does not require proprietary hardware.

[0299] Production Efficiency Improvement: Support parallel testing of multiple machines, and the station utilization rate is increased from 65% to 95%; the manpower requirement is reduced by 80%, and a single-line operator can perform batch testing simultaneously.

[0300] Industry Promotion: Achieve industrial intelligent testing; improve the intelligent level of domestic PCBA board testing equipment and enhance domestic competitiveness.

[0301] Environmental Contribution: Reduce the amount of fixture waste and improve the service life and utilization rate of a single piece of hardware.

[0302] Technology Radiation: The accumulated test database and the test modules jointly maintained by industry insiders can reversely optimize the production manufacturing process.

[0303] In one embodiment, a computer device is provided. The computer device can be a server, and its internal structure diagram can be as Figure 3 shown. The computer device includes a processor, a memory, and a network interface connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store static information and dynamic information data. The network interface of the computer device is used to communicate with external terminals through a network connection. When the computer program is executed by the processor, it realizes the steps in the above method embodiment.

[0304] Those skilled in the art can understand that Figure 3 the structure shown in

[0305] In addition, the present invention also provides a computer device, including a memory and a processor. A computer program is stored in the memory, and when the processor executes the computer program, the steps in the above method embodiments are implemented.

[0306] In addition, the present invention also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0307] Those of ordinary skill in the art can understand that all or part of the processes in the above method embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the above method embodiments. Among them, any reference to a memory, storage, database, or other medium used in the various embodiments provided by the present invention can include at least one of non-volatile and volatile memories. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical memory, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0308] The present invention is not limited to the structures that have been described above and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the present invention is only limited by the appended claims.

Claims

1. An automated PCBA comprehensive testing method, characterized in that, Including: Place the PCBA board to be tested on a pre-configured fixture, and power on the PCBA board to be tested to start the board program of the PCBA board to be tested; The host computer uses the device auto-discovery protocol to automatically detect the PCBA board to be tested that has run the board program under the same local area network, establish a connection, detect the peripheral information to be tested based on the board program, and report the detection result to the host computer; Based on the detection result, the host computer uses the SM3 hashing algorithm and combines it with the stream encryption algorithm to generate a board serial number; The host computer lists the test items of the PCBA board to be tested, conducts tests on the PCBA board to be tested, and visually displays the test process and test results through the host computer; Bind the test result with the fault code and board serial number generated during the test process, and store it as a test log.

2. The automated PCBA comprehensive test method according to claim 1, wherein The host computer uses the SM3 hashing algorithm and combines it with the stream encryption algorithm to generate a board serial number based on the detection result, including: Generate a random salt value using a pre-configured hardware RNG module; Obtain the MAC address and timestamp of the PCBA board to be tested, and perform data splicing on the random salt value, MAC address, and timestamp to obtain spliced data; Perform data expansion on the spliced data, and perform hashing on the expanded data using the SM3 hashing algorithm to obtain hashed data; Encrypt the hashed data using the stream encryption algorithm, and perform final calculation using the SHA-256 algorithm to obtain the board serial number.

3. The automated PCBA comprehensive test method according to claim 2, characterized in that, The encrypting the hashed data using the stream encryption algorithm and performing final calculation using the SHA-256 algorithm to obtain the board serial number includes: Derive the hashed data as a key, and generate a Nonce value through a pre-configured hardware RNG module; Generate a key stream using the stream encryption algorithm, perform an exclusive OR operation on the hashed data as the plaintext and the key stream to generate mixed encrypted data; Calculate SHA-256 on the mixed encrypted data, and obtain the board serial number by selecting a preset byte digest.

4. The automated PCBA comprehensive test method according to claim 1, wherein The testing the PCBA board to be tested includes: function testing, performance testing, and driver initialization; The function testing includes: Obtain the function test instruction sent by the host computer, and perform function test item initialization processing; After the function test item initialization is completed, perform function testing on the PCBA board to be tested, and after the test is completed, release the peripheral resources to restore the PCBA board to be tested to its initial state; Determine whether the test item requires restarting the device to verify the test result. If so, wait for all test items to be executed, report the test status to the host computer, and restart the device. After the device restarts, the host computer sends a restart verification result instruction and verifies the test result to obtain the verification result; otherwise, the test ends; The performance testing includes: Obtain the performance test instruction sent by the host computer, and perform performance test item initialization processing; After the performance test item initialization is completed, perform performance testing on the PCBA board to be tested; During the performance test, it is determined whether the test needs to be terminated. If so, the peripheral resources are released, and the PCBA board under test is restored to its initial state to obtain the test results. Otherwise, the performance test of the PCBA board under test continues; The driver initialization includes: Based on the predefined data type variable size, allocate private data space for the driver, and after the allocation is completed, store the private data; Use the configuration parsing function to configure and parse the private attribute parameters of the PCBA board under test to obtain the private attributes; Based on the obtained private attributes, use the driver probing function to initialize the driver.

5. The automated PCBA comprehensive testing method according to claim 1, wherein The device automatic discovery protocol includes: When the host computer starts, it sends a broadcast packet with the destination address being the limited broadcast address; The device side responds with JSON data containing the device name flag bit.

6. An automated PCBA comprehensive testing system, characterized in that, Includes: The hardware IO unit is used to provide the physical interface of the device under test; The bottom layer unit is used to implement the operation of the peripheral device; The core layer unit is used to provide a unified peripheral operation interface; The test item unit is used to provide the peripheral items to be tested on the target board; The main framework unit is used to carry the main framework of the program; Among them, the hardware IO unit includes: The communication interface module is used to implement multi-protocol physical signal conversion; The register mapping module is used to provide a hardware register access interface.

7. The automated PCBA comprehensive test system according to claim 5, wherein The bottom layer unit includes: The physical driver module is used to connect and operate the hardware device; The virtual driver module is used to provide an analog communication interface; The dynamic binding module is used to select the driver mode according to the configuration.

8. The automated PCBA comprehensive test system according to claim 5, characterized in that, The core layer unit includes: The event scheduling engine module is used to manage the event queue for the application layer module to call, and dynamically configure the test logic based on the priority mark and dependency relationship; The protocol abstraction interface module is used to unify the peripheral operation methods and communication protocols of different drivers; Among them, the dynamically configuring the test logic based on the priority mark and dependency relationship includes: Use atomic instructions to update the ready queue; Automatically increase the priority mark bit for I / O intensive tasks; Use the initialization test items, basic function test items, and final inspection test items to divide the test stages, configure the dependency relationship, and control the test order of each part; Use memory barriers for hardware IO reading.

9. The automated PCBA comprehensive test system according to claim 5, characterized in that, The test item unit includes: The application layer module is used to execute related operations depending on the core layer unit to implement the test logic; The device test logic module is used for the specific test logic of the peripheral device; The fault diagnosis module is used to perform fault diagnosis using standard Linux fault codes.

10. The automated PCBA comprehensive test system according to claim 5, characterized in that, The main framework unit includes: The host computer communication module is used to be responsible for communicating with the host computer; The configuration test item module is used to dynamically load the test items to be tested through a json file to activate the corresponding test module; The test information summary module is used to uniformly summarize the test results, logs and other information to the host computer.

Images