Electronic device combination environmental stress screening test method and storage device

Abstract

The present disclosure relates to an electronic device combination environment stress screening test method and a storage device, and belongs to the technical field of electronic device reliability testing. The present disclosure is aimed at the defects of the existing method, such as complicated process, untimely data observation, hardware-limited test time, and inconvenient data processing and analysis. The method realizes efficient testing of the communication state and performance parameters of each subsystem of the electronic device combination through the integrated design of screening test tool software, host computer screening test software, and test report template. Through innovative optimization design, the present disclosure greatly simplifies the test process, can intuitively obtain real-time data information, can set the test duration as needed, realizes the classification saving of test data and the automatic generation of test report, and the realization of related functions greatly reduces the workload of data acquisition, data arrangement, and result analysis process.

Description

Technical Field

[0001] This disclosure relates to the field of electronic equipment reliability testing technology, and in particular to an environmental stress screening test method for electronic equipment combinations and a storage device. Background Technology

[0002] Environmental stress screening tests are a key quality control method for stimulating and eliminating potential and process defects during product development and production, and are an indispensable part of the electronic equipment product development process. Integrated electronic equipment assemblies, as the core of the electronic information system of a product model, integrate various components and subsystems. The information exchange between systems and subsystems is complex, and the amount of data transmitted is large, placing high demands on the efficiency and accuracy of screening tests.

[0003] Existing environmental stress screening tests for electronic equipment system-level products employ a step-by-step testing approach: First, the product enters system operation mode, where it communicates with various subsystems and collects data via its system software, storing the communication data in frame format on a data logger. Then, the product enters measurement and control mode, downloading data from the data logger through a test interface, parsing it, and conducting further analysis. Screening tests typically include two types: temperature cycling and random vibration tests. The total number of tests throughout the cycle is high, and in practical applications, multiple products are often tested in parallel.

[0004] As the requirements for screening tests become increasingly stringent, existing technical solutions exhibit significant drawbacks: First, each test necessitates data downloading and recorder erasure, a cumbersome and time-consuming process that prevents real-time data observation. Second, test time is limited by the data logger's hardware storage space; for example, in some projects, the recorder can be fully written in just 80 seconds, causing some performance indicators to fail to meet technical document requirements. Third, the data processing and analysis after each product's screening test is extremely inconvenient, making it difficult to meet the testing needs of large-scale products. Therefore, an optimized screening test method is urgently needed to address the problems of cumbersome processes, testing limitations, and inconvenient data processing in existing technologies, thereby improving testing efficiency. Summary of the Invention

[0005] To address the aforementioned technical issues, this disclosure provides an environmental stress screening test method and storage device for electronic device assemblies. Through the integrated design of screening test fixture software, host computer screening test software, and test report templates, efficient testing of the communication status and performance parameters of each subsystem of the electronic device assembly is achieved.

[0006] In a first aspect, embodiments of this disclosure provide a method for environmental stress screening testing of electronic device assemblies, the method comprising:

[0007] The screening test tooling software is deployed inside the product processor to replace the original system working software of the product. It establishes interaction with each subsystem through the adapted communication configuration, completes the instruction issuance and feedback data reception, realizes data transmission optimization, communication status characterization and effective data screening, and transmits various interactive information back to the host computer in real time after standardized frame processing.

[0008] The screening test software in the host computer receives standardized framed data uploaded from the screening test fixture software deployed inside the product processor. It first verifies the data validity, then determines the communication status of relevant subsystems, and parses and extracts the communication status information and core performance parameters of each subsystem. The software interface displays the data in a modular fashion, automatically generates a save directory according to the test type, and stores the data files in categories, achieving data visualization and standardized storage. The software generates test reports and sends control commands to adjust the test-related parameters of the screening test fixture software, guiding its subsequent interaction and data processing operations.

[0009] In some embodiments of this disclosure, the adapted communication configuration includes: runtime environment and implementation language adaptation, communication interface type and quantity configuration, communication cycle unification configuration, and baud rate configuration.

[0010] In some embodiments of this disclosure, establishing interaction with each subsystem includes: designing differentiated processing logic for different communication needs of the subsystems to ensure that the interaction tasks of all subsystems are completed within the communication cycle.

[0011] In some embodiments of this disclosure, various types of interactive information are standardized and framed before being transmitted back to the host computer in real time, specifically including:

[0012] The data source integration and screening test tooling software first summarizes and sorts out the effective information after communication processing of each subsystem, clarifies the basic composition of the returned data, and ensures that no key information is omitted.

[0013] Standardized frame format framing: The integrated data source is standardized and framed according to a preset frame protocol.

[0014] Real-time data feedback configuration and execution: After the frame is assembled, the screening test tooling software transmits the complete data frame back to the host computer in real time through a dedicated communication channel.

[0015] The validity of the returned data is verified in conjunction with the framing and transmission quality of the screening test tooling software, and is also linked to the communication status determination of the subsystem.

[0016] In some embodiments of this disclosure, the workflow for screening test fixture software includes:

[0017] After the process is started, the basic environment configuration for software operation is completed, and the communication port is initialized to establish the basic conditions for subsequent communication and interaction.

[0018] Receive debugging-related instructions and verify their validity. Once the instructions meet the requirements, trigger the interrupt response function.

[0019] The system receives the trigger action of the interrupt response function, issues debugging instructions to the specified subsystem, and completes the first interaction with the subsystem within the interrupt cycle.

[0020] The interrupt cycle-based instruction issuance action first completes cycle initialization and initial interaction with the specified subsystem, and then processes the data verification, communication status configuration, and instruction retransmission data fed back by the specific subsystem, so as to realize bidirectional interaction and status recording with these subsystems.

[0021] Based on the interaction and processing status of the previous subsystems, the corresponding instructions are issued to the designated subsystems, and the feedback data of the designated subsystems and additional subsystems that synchronously process feedback data are processed, thus completing the interaction and information recording with these subsystems.

[0022] Receive the interaction results from each subsystem, organize and frame the relevant data, complete the data verification process, and upload all data within the period to the host computer.

[0023] End the subsystem interaction and data processing tasks.

[0024] In some embodiments of this disclosure, debugging-related instructions are received and their validity is verified. An interrupt response function is triggered after ensuring the instructions meet the requirements. Specifically, this includes:

[0025] Entering a continuous waiting state, the system receives byte handshake commands from the debug port. Upon receiving the handshake command, it immediately performs an accumulation and verification operation. If the verification result is incorrect, it returns to the initial state of waiting to receive byte handshake commands and resumes waiting. If the verification result is correct, it switches to the next waiting state to receive debug commands from the debug port. After successfully receiving the debug command, it performs the accumulation and verification again. If the verification result is incorrect, it returns to the state of waiting to receive debug commands and resumes waiting. If the verification result is correct, it triggers the interrupt response function, completing the validity verification of the debug command and the interrupt triggering connection.

[0026] In some embodiments of this disclosure, processing data verification, communication status configuration, and instruction retransmission data feedback from specific subsystems specifically includes:

[0027] When processing feedback data from a specific subsystem, first determine whether the length of the received feedback data from the specific subsystem meets the preset requirements. If the length does not meet the requirements, skip the subsequent processing flow of the specific subsystem and proceed to the processing stage of another specific subsystem. If the length meets the requirements, find the data frame header and calculate the cumulative sum check. Configure the communication status bit of the specific subsystem according to the check result. After completing the status configuration, immediately send the debugging command to the specific subsystem again within the current cycle.

[0028] In some embodiments of this disclosure, the workflow of the host computer screening test software includes:

[0029] Perform window initialization and security box definition, create path files, data storage files and report files based on initialization information, and call test functions to create threads according to different test types to build a basic environment for subsequent communication and data interaction;

[0030] Wait for the handshake instruction returned by the product, and send a debugging instruction to the product according to the handshake instruction. After completing the communication handshake, start the test data receiving process.

[0031] The test data reception and preliminary verification process involves a dual validity check of the received test data's frame header format and verification information. If the frame header or verification information does not meet the preset protocol requirements, the current erroneous data is saved to an error file, and the process returns to continue receiving new test data. If both the frame header and verification information meet the preset protocol requirements, the preliminary verification of the data is complete.

[0032] Subsystem data processing and hierarchical storage: Parse the raw data of the subsystem; first, store the raw data before parsing into an empty second data file, then accumulate the received frame count and time according to the rules; display the parameter data after parsing of the subsystem on the test interface, and store this parsed data into the second data file to realize hierarchical processing and classified storage of data;

[0033] Test duration determination and performance index analysis: Determine whether the current test duration is equal to the set duration. If not, return to the data processing stage to continue the loop. If equal, calculate the subsystem's performance index, display the test results on the test interface, and save the single test result to the specified cell area of ​​the report file.

[0034] The entire test project is verified and the process loop is repeated. After a single test is completed, it is determined whether all test projects of the same type have been completed. If not, it returns to the data receiving and processing stage to continue executing the remaining projects. If it has been completed, it enters the stage of summarizing test data from multiple rounds.

[0035] In some embodiments of this disclosure, the workflow of the host computer screening test software further includes: summarizing multiple rounds of test data and generating a final report; reading multiple test data stored in the report file; determining whether there are empty type numbers in the data; if so, performing quality inspection on the test items, supplementing the corresponding test content, and then reading the report file again; if there are no empty type numbers, generating the final test report.

[0036] Secondly, embodiments of this disclosure also provide a storage device, including: a memory and a processor, the processor including a plurality of cores, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the method described above.

[0037] This disclosure provides a method for environmental stress screening testing of electronic device combinations and a storage device. The technical solutions provided by the embodiments of this disclosure bring at least the following beneficial effects:

[0038] (1) Simplify the testing process, select test tooling software to replace the product system working software, realize real-time data acquisition and transmission, eliminate the data recorder storage, download and erase process, and greatly shorten the testing cycle;

[0039] (2) Supports real-time observation. The host computer software analyzes and displays the returned data in real time and in a modular manner, which can intuitively obtain the communication status and performance parameters of each subsystem and solve the problem of untimely data observation.

[0040] (3) Overcoming hardware limitations, by selectively extracting data, designing misaligned frames, and optimizing interrupt scheduling, the test time is not limited by the storage space of the data logger. The test duration can be set as needed to meet the assessment requirements of different indicators.

[0041] (4) The data processing is efficient. The host computer software realizes the classification and storage of test data, and the report template supports one-click interpretation of multiple test data and automatic report generation, reducing the workload of data sorting and analysis.

[0042] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 A flowchart illustrating the experimental method provided in this embodiment of the disclosure;

[0045] Figure 2 A flowchart illustrating the workflow for selecting experimental tooling software;

[0046] Figure 3 This is a flowchart illustrating the workflow of the host computer screening test software.

[0047] Figure 4 This is a schematic diagram of the interface of the host computer screening test software;

[0048] Figure 5 This is a schematic diagram of a report from a temperature cycling screening test. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this disclosure.

[0050] Before describing the technical solution in this disclosure in detail, the technical background and technical terms involved in the technical solution shall be explained first:

[0051] Stress screening test: a reliability assurance and quality control technology for products (especially electronic equipment, mechatronics products, etc.). The core of the test is to apply controllable, non-destructive stress to the product to actively stimulate and expose potential defects introduced during the research and development and production process (such as design omissions, process defects, hidden component failures, etc.), thereby eliminating these early failure sources before the product is delivered or put into actual use, and ultimately improving the batch production consistency and reliability of the product.

[0052] Figure 1 This is a flowchart illustrating the experimental method provided in this embodiment. The method includes three aspects: First, by developing software for screening test fixtures using electronic equipment, data originally stored in the recorder by the product system software is selectively extracted according to test requirements (reducing the amount of data transmitted), and packaged for real-time transmission via a test interface; second, the data results are modularly displayed in the host computer screening test software interface, and data files can be automatically categorized and stored according to test type by generating a save directory folder; third, by combining report template file design, multiple test data for the same product can be interpreted with a single click based on the qualification criteria. Specifically, the method includes the following steps:

[0053] Step S101: Deploy the screening test fixture software inside the product processor to replace the original system working software of the product. Through the adapted communication configuration, establish interaction with each subsystem, complete the instruction issuance and feedback data reception, realize data transmission optimization, communication status characterization and effective data screening, and transmit the various interactive information back to the host computer in real time after standardized frame processing.

[0054] Step S102: The screening test software in the host computer receives standardized framed data uploaded from the screening test fixture software deployed inside the product processor. It first verifies the validity of the data, then determines the communication status of the relevant subsystems, and parses and extracts the communication status information and core performance parameters of each subsystem. The software interface displays the data in a modular manner, automatically generates a save directory according to the test type, and stores the data files in categories to achieve data visualization and standardized storage. The software generates test reports, sends control commands to adjust the test-related parameters of the fixture software, and guides its subsequent interaction and data processing operations.

[0055] In step S101 above, configuring the communication parameters of the screening test fixture software is fundamental to ensuring stable and efficient data interaction with each subsystem and the host computer. All configurations are designed to meet the parallel communication needs of multiple subsystems, avoid transmission timeouts, and ensure data real-time performance. The adapted communication configuration specifically includes:

[0056] Operating environment and implementation language compatibility: The tooling software is implemented using C language programming, which is specifically adapted to the hardware architecture of DSP processors. After being burned into the processor's internal flash, it runs independently, replacing the original system software of the product to undertake communication and data processing tasks, ensuring the lightweight operation and real-time responsiveness of the software, and fitting the embedded application scenarios of electronic device combinations.

[0057] Communication Interface Type and Quantity Configuration: An industrial-grade RS-422 serial communication interface is adopted. This interface features strong anti-interference capabilities, moderate transmission distance, and support for multi-point communication, adapting to the environment requirements of multiple subsystems working collaboratively in combination with electronic equipment. Specifically, the interface allocation is as follows: 4 RS-422 external interfaces serve as subsystem communication channels, establishing one-to-one communication links with subsystems A, B, C, and D respectively, responsible for command issuance and feedback data reception; 1 RS-422 external interface serves as a data return channel, specifically used to frame the integrated subsystem data and upload it to the host computer screening and testing software, achieving separation and specialization of communication links and avoiding data transmission conflicts.

[0058] Standardized Communication Cycle Configuration: The communication cycle of all RS-422 interfaces is strictly set to the same value to ensure the timing synchronization of communication and data return among various subsystems. This cycle parameter has been precisely calculated to suit the command response and data processing time of the subsystems (such as the long data transmission and processing requirements of subsystems A and B), and also to provide basic timing support for subsequent frame error design and interrupt scheduling optimization, avoiding transmission timeout problems caused by the superposition of tasks within a single cycle.

[0059] Baud rate optimization configuration: The baud rate of all communication interfaces is uniformly configured to 921600bps. This baud rate achieves a balance between transmission rate and stability, which can meet the timeliness requirements of large data volume transmission such as subsystem A (143 bytes of data readback) and subsystem B (38 bytes of data readback), ensuring that data transmission and reception are completed within the set communication cycle, while reducing the transmission error rate at high baud rates, ensuring the accuracy of data transmission, and adapting to the real-time data acquisition and transmission needs in the environmental stress screening test of electronic equipment combination.

[0060] The above parameter configuration forms a standardized and collaborative communication foundation, providing stable and reliable underlying support for subsequent functions such as subsystem data interaction, misalignment design and implementation, and data frame return, ensuring that the tooling software can efficiently connect multiple subsystems and the host computer to achieve accurate acquisition and real-time transmission of test data.

[0061] In the above steps, the subsystem communication processing of the selected test tooling software aims for timing optimization, data simplification, and efficient adaptation. Differentiated processing logic is designed for the different communication needs (data volume, interaction type, and status determination requirements) of subsystems A, B, C, D, and E. This ensures that all subsystem interaction tasks are completed within a 2.5ms communication cycle, avoiding transmission timeouts, while guaranteeing data validity and transmission efficiency. Examples from different application scenarios are provided below:

[0062] 1. Communication processing between subsystems A and B (large data volume interaction scenario)

[0063] Subsystems A and B are the two subsystems with the largest data transmission volume. Subsystem A needs to receive 143 bytes of feedback data, and subsystem B needs to receive 38 bytes of feedback data. In addition, the subsystems need extra time to respond to commands and process data. Therefore, a staggered frame design is adopted to realize asynchronous interaction. The specific process is as follows:

[0064] The first communication cycle: only the instruction issuance operation is performed, sending a 6-byte test instruction to subsystem A and a 34-byte test instruction to subsystem B, without waiting for feedback data, so as to reserve sufficient response and data processing time for the subsystems;

[0065] The second communication cycle: First, receive 143 bytes of data from subsystem A and 38 bytes of data from subsystem B, and complete data parsing and caching; Second, immediately send the next frame of test instructions to subsystems A and B to ensure the continuity of data interaction in subsequent cycles; Third, switch to processing the communication tasks of subsystems C, D, and E to avoid conflicts with the large data volume processing of A and B.

[0066] Communication cycles 3 to N: The process of communication cycle 2 is fully reused, which ensures the integrity of large data transmission between subsystems A and B, without occupying the communication resources of other subsystems, and achieves the timing balance of multi-channel parallel interaction.

[0067] 2. Communication status representation of subsystems C, A, B, and E (for scenarios requiring only status determination)

[0068] For subsystems C, A, B, and E, the test only needs to assess whether the communication link is normal; it does not require obtaining complete raw data. To simplify data transmission and improve communication efficiency, the specific processing methods include:

[0069] Data verification logic: The screening test tooling software performs cumulative and verification calculations on the received subsystem communication data (or interaction frames), and determines whether there are problems such as data loss or bit errors in the communication link based on the verification results;

[0070] Status coding rule: The communication status is clearly represented by a 1-byte binary code. When the code is 0x01, it means that the summation and check are correct and the communication link is normal; when the code is 0x00, it means that the summation and check are incorrect and the communication link is abnormal.

[0071] Data transmission optimization: Only single-byte status codes are included in subsequent frame-based data transmission, replacing the complete original data transmission, significantly reducing the amount of invalid data and ensuring that the status acquisition of all subsystems is completed within a limited communication cycle. Furthermore, the communication status determination of subsystem C is linked to the data transmission results: when the host computer software determines that the frame data transmitted back by the tooling software is generally correct, it can directly confirm that the communication status of subsystem C is normal, further simplifying the interaction logic.

[0072] 3. Communication processing of subsystem D (raw data return scenario)

[0073] The testing requirement for subsystem D is to obtain complete performance parameters and communication status. Its feedback data already contains communication status words, eliminating the need for additional status encoding conversion. The specific processing flow is as follows:

[0074] Command issuance: The tooling software sends a 13-byte timed test command to subsystem D. The command content is preset according to the test requirements to ensure that subsystem D triggers the corresponding performance test and data feedback.

[0075] Data reception: Receive 26 bytes of feedback data returned by subsystem D. This data contains complete information such as communication status words and performance parameters, without the need for additional parsing or processing.

[0076] Direct framing: The received 26-byte raw data is directly included in the framing queue. After adding frame headers and checksums according to the unified frame protocol, it is sent back to the host computer, where the host computer software performs further data analysis. This ensures data integrity and simplifies the processing load on the tooling software.

[0077] 4. Communication processing of subsystem E (special transmission cycle scenario)

[0078] The core characteristics of subsystem E are its short transmission cycle of 1.25ms, requiring only one frame of valid data, and the tooling software only receiving data without sending commands. If conventional timing acquisition is used, it is easy to cause data disorder or excessive consumption of communication resources. Therefore, a special processing logic is designed:

[0079] Data acquisition timing optimization: The data acquisition stage of subsystem E is scheduled at the last stage of the interrupt execution cycle. Data reception of E is started only after the tooling software completes serial communication with subsystems A, B, C, and D, so as to avoid communication conflicts with other subsystems.

[0080] Valid data screening: Since the transmission cycle of subsystem E is 1.25ms (half of the communication cycle of the tooling software), it can receive 2 frames of data in a single cycle. In order to ensure the order of data, 2 complete frames of data are collected first, and then 1 frame is screened as valid data according to the preset rules to avoid affecting the test results due to frame order disorder.

[0081] Timeout control: By combining delayed acquisition and multi-frame filtering, the integrity of valid data is ensured without occupying the communication time of other subsystems, ensuring that the overall communication process is completed within a 2.5ms cycle without timeout risk.

[0082] The aforementioned subsystem communication processing, through differentiated scenario adaptation and timing optimization design, has formulated exclusive interaction logic for the experimental needs of different subsystems. This not only solves problems such as timeouts in large-volume data transmission and redundant invalid data, but also ensures the accurate collection of communication status and valid data, providing high-quality data source support for subsequent data frame back transmission and host computer parsing.

[0083] In the above steps, the standardized framing of various interactive information and its real-time transmission back to the host computer are crucial steps in connecting the screening test software with the communication processing of various subsystems and the data parsing of the host computer. The goal is to standardize and integrate the scattered subsystem interactive information (communication status, effective performance parameters) into a unified frame format, and reliably transmit it back to the host computer screening test software in real time through a designated communication interface, while ensuring the integrity and verifiability of data transmission. Implementation details are as follows:

[0084] 1. Backhaul data source integration

[0085] The screening test tooling software first summarizes and organizes the effective information after communication processing by each subsystem, clarifies the basic composition of the returned data, and ensures that no key information is omitted. The data sources include:

[0086] Communication status data: Communication status identifiers for subsystems A, B, and E obtained through cumulative sum checksum and single-byte encoding (0x01 for normal, 0x00 for abnormal); Communication status associated identifier for subsystem C (to be confirmed by the host computer through frame integrity check).

[0087] Performance parameter data: 26 bytes of raw feedback data directly transmitted back by subsystem D (including communication status words and performance parameters); 1 frame of valid performance data obtained by subsystem E through multi-frame acquisition and ordered filtering;

[0088] Auxiliary identification data: Auxiliary information (frame header, accumulation and checksum) to ensure that the frame structure is identifiable and verifiable.

[0089] All data sources undergo validity verification during the initial subsystem communication process (such as data length verification, frame header matching, and cumulative verification) to ensure the quality of returned data from the source and prevent invalid or erroneous data from being included in the framing process.

[0090] 2. Standardized frame format framing

[0091] To ensure that the host computer screening test software can quickly parse and accurately identify the data, the tooling software standardizes and frames the integrated data source according to a preset frame protocol. The frame structure takes into account readability, verifiability, and data density. The specific framing rules are as follows:

[0092] Frame header addition: A fixed-format frame header identifier is added at the beginning of the framed data. The frame header uses a unique byte sequence to help the host computer screen the test software to quickly identify valid data frames, distinguish noise or invalid transmission signals, and improve data parsing efficiency.

[0093] Data field arrangement: Core data fields are arranged in the order of communication status data and performance parameter data. The field positions and lengths are predefined and agreed upon with the host computer screening and testing software.

[0094] Communication status field: Fill in the single-byte status codes of subsystems A, B, and E in sequence. The field length is fixed at 1 Byte / field to ensure that the host computer can quickly extract the data at a fixed offset.

[0095] Performance Parameter Field: Enter 26 bytes of raw data from subsystem D and valid performance data from subsystem E consecutively. The field length should be set according to the actual valid data length to maintain data integrity.

[0096] Accumulation and checksum calculation and addition: The byte data of the frame header and all data fields are accumulated and calculated to obtain the checksum (1 Byte), and then added to the end of the frame data to form a complete frame structure of "frame header + data fields + checksum".

[0097] Frame length control: The total length of each frame is strictly controlled to 65 bytes. This length design has been precisely calculated to fully accommodate all core data sources and adapt to the transmission capability of the RS-422 interface within a 2.5ms communication cycle, avoiding transmission timeouts due to excessively long frames or data redundancy due to excessively short frames.

[0098] During the framing process, the tooling software ensures the uniformity of the data format for each frame by using fixed field offsets, length definitions, and verification rules, providing a standardized basis for the real-time analysis of the host computer's screening test software.

[0099] 3. Real-time data feedback configuration and execution

[0100] After framing is completed, the tooling software transmits the complete data frame back to the host computer in real time through a dedicated communication channel. The parameter configuration during the transmission process remains consistent with the previous communication parameters to ensure transmission stability and real-time performance. The specific implementation is as follows:

[0101] Communication channel selection: A dedicated RS-422 external interface is used as the data backhaul channel, which is separate from the subsystem communication channel to avoid data transmission conflicts and ensure the specialization and stability of the backhaul link.

[0102] Transmission parameter adaptation: The communication cycle of the backhaul channel is consistent with the communication cycle of the subsystem (2.5ms), and the baud rate is 921600bps. This parameter combination can ensure that the complete frame data of 65 bytes is transmitted in a single communication cycle, meeting the experimental requirements of real-time backhaul, while reducing the risk of bit error at high baud rates.

[0103] Backhaul timing synchronization: Data framing is strictly synchronized with the communication cycle. After each communication cycle is completed, the backhaul operation is immediately started to ensure that the host computer screening test software can continuously receive data according to the cycle, so as to realize the real-time observation and recording of test data.

[0104] 4. Linked verification of returned data validity

[0105] The effectiveness of data return depends not only on the framing and transmission quality of the tooling software, but also on the communication status determination of subsystem C, as specifically implemented as follows:

[0106] The tooling software is only responsible for framing and sending data according to the protocol, and does not additionally determine the communication status of subsystem C;

[0107] After receiving the data frame, the host computer screening test software first verifies the uniqueness and integrity of the frame header, and then verifies the entire frame data by using the accumulated sum and check code at the end of the frame (recalculating the accumulated sum and comparing it with the check code).

[0108] If the host computer determines that the data frame format is correct and the summation and verification are consistent, it confirms that the entire frame data transmission is valid, and then determines that the communication status of subsystem C is normal; if the verification fails, the data frame is determined to be invalid, and the communication status of subsystem C is marked as abnormal.

[0109] This linkage design simplifies the processing logic of the tooling software and indirectly verifies the communication link quality of subsystem C through the validity check of whole frame data, ensuring the comprehensiveness and accuracy of communication status determination.

[0110] The aforementioned data frame return processing and operations enable efficient and reliable return of interactive information between various subsystems, ensuring data integrity and real-time performance, while also providing a standardized and high-quality data source for the host computer's screening test software to analyze, display, and generate reports.

[0111] Figure 2 This is a flowchart illustrating the workflow of the screening test fixture software. Deployed within the product's DSP processor, the software replaces the product's system software. It establishes stable communication with each subsystem by configuring preset communication parameters. Employing a staggered framing design, it handles the instruction issuance and feedback data processing for subsystems with high data transmission volumes. It uses a simple summation and checksum method to characterize the communication status of relevant subsystems. It filters valid data from another subsystem according to specific rules, directly frames and transmits the original feedback data from the specified subsystem, and simultaneously performs frame protocol framing on all interactive data (including adding frame headers and calculating checksums) before transmitting it back to the host computer in real time via a dedicated interface. This provides accurate and real-time data source support for the host computer software's data parsing, status determination, and report generation, ensuring efficient acquisition and reliable transmission of communication status and performance parameters of each subsystem throughout the environmental stress screening test. The workflow of the screening test fixture software includes the following steps:

[0112] Step S201: After starting the process, complete the basic environment configuration for software operation, and initialize the communication port to establish the basic conditions for subsequent communication interaction. This follows the initial actions of the process startup and provides support for subsequent command interaction.

[0113] like Figure 2As shown, after the process starts from the "Start" node, it first completes the initialization of the basic software operating environment, and specifically configures the interrupt function to ensure the normal triggering and execution of subsequent interrupt cycle processes. Then, it performs targeted processing on the RS-422 communication port, clears the port buffer to avoid interference from residual data, and uniformly configures the port receiving parameters to a baud rate of 921600bps, building a stable and standardized underlying communication condition, providing reliable basic support for subsequent handshake and debugging command reception, subsystem communication interaction and other links.

[0114] Step S202: Receive debugging-related instructions and verify their validity. After ensuring that the instructions meet the requirements, trigger the interrupt response function.

[0115] The above steps not only complete the verification of the debugging instructions but also prepare for the subsequent entry into the interrupt cycle. For example... Figure 2 As shown, in this step, the process enters the handshake and debug command interaction phase. First, it enters a continuous waiting state to receive a 51-byte handshake command from the debug port. Upon receiving this handshake command, it immediately performs an accumulation and verification operation. If the verification result is incorrect, it returns to the initial state of waiting to receive the 51-byte handshake command again. If the verification result is correct, it switches to the next waiting state to receive a 6-byte debug command from the debug port. After successfully receiving the 6-byte debug command, it performs the accumulation and verification again. If the verification result is incorrect this time, it returns to the state of waiting to receive the 6-byte debug command again. If the verification result is correct, it triggers the interrupt response function, completing the validity verification of the debug command and the interrupt triggering connection, preparing for the subsequent entry into the first interrupt cycle process.

[0116] Step S203: Receive the trigger action of the interrupt response function, issue a debugging command to the specified subsystem, and complete the first interaction with the subsystem within the interrupt cycle.

[0117] The above steps constitute the first interrupt cycle process and lay the groundwork for subsystem interaction tasks in subsequent interrupt cycles. For example... Figure 2 As shown, in this step, following a single execution logic, no data reception or other subsystem interaction operations are performed during this cycle. The focus is solely on executing the instruction issuance task, sending corresponding debugging instructions to subsystems A and B respectively. This allows sufficient response and processing time to receive feedback data from the two subsystems in the subsequent second interrupt cycle. After completing the single operation of this cycle, the process naturally connects to the second to n (n≥2) interrupt cycles.

[0118] Step S204: The instruction issuance action based on the interrupt cycle first completes the cycle initialization and the initial interaction with the specified subsystem, and then processes the data verification, communication status configuration and instruction retransmission data fed back by the specific subsystem, so as to realize bidirectional interaction and status recording with these subsystems.

[0119] like Figure 2 As shown, upon receiving the debugging instructions for subsystems A and B during the first interrupt cycle, the process proceeds to the second through n (n≥2) interrupt cycles. This step follows the logic of initialization, subsystem interaction, branch processing, and subsequent execution, as detailed below:

[0120] Perform the initialization preparation operation for this cycle, send 5 bytes of data to the host computer, and synchronously receive feedback data from subsystem E;

[0121] When processing feedback data from subsystem A, first determine whether the length of the received feedback data from subsystem A meets the preset requirements. If the length does not meet the requirements, skip the subsequent processing flow of subsystem A and proceed to the processing stage of subsystem B. If the length meets the requirements, search the data frame header and calculate the cumulative checksum. Configure the communication status bit of subsystem A according to the checksum result (set to a code indicating normal when the checksum is correct, and set to a code indicating abnormal when the checksum is incorrect). After completing the status configuration, immediately send the debugging command to subsystem A again within the current cycle.

[0122] Upon entering the feedback data processing of subsystem B, the system first receives the feedback data from subsystem B, then determines whether its length meets the preset requirements. If the length does not meet the requirements, the system skips the subsequent processing of subsystem B. If the length meets the requirements, the system searches the frame header and calculates the cumulative checksum. Based on the checksum result, the system configures the communication status bit of subsystem B (set to a normal code when the checksum is correct, and set to an abnormal code when the checksum is incorrect). After completing the status configuration, the system immediately sends the debugging command to subsystem B again within the current cycle.

[0123] After completing the above steps, the process connects to the instruction sending and data processing stage of the subsequent subsystem D.

[0124] Step S205: Based on the interaction processing status of the previous subsystems, issue corresponding instructions to the designated subsystems, and simultaneously process the feedback data of the designated subsystems and additional subsystems that synchronously process feedback data, thereby completing the interaction and information recording with these subsystems.

[0125] like Figure 2 As shown, this step follows the feedback data processing and instruction retransmission actions of subsystems A and B in the 2nd to nth (n≥2) interrupt cycles of the previous stage, and the process enters the instruction sending and data processing stage of subsystem D. The specific process is as follows:

[0126] A 13-byte test command is sent to subsystem D based on the interrupt count n. Different interrupt count ranges correspond to different deflection commands, specifically:

[0127] Send a 0.25-degree deflection command when n < 400;

[0128] Send a 0-degree deflection command when 400≤n<800;

[0129] When 800 ≤ n < 1200, send a 0.25-degree deflection command;

[0130] Send a 0-degree deflection command when 1200≤n<1600;

[0131] Send a -0.25 degree deflection command when 1600≤n<2000;

[0132] Send a 0-degree deflection command when 2000≤n<2400;

[0133] When 2400≤n<2800, send a -0.25 degree deflection command;

[0134] Send a 0-degree deflection command when 2800≤n<3200;

[0135] When 3200≤n, send a 0.25-degree deflection command.

[0136] After sending the instruction, the system receives feedback data from subsystem D and then determines whether the length of the feedback data is 26 bytes. If the length does not match, the subsequent processing of subsystem D is skipped. If the length matches, the 26-byte feedback data is assigned to the array SendData.D0[19~31] to be sent to the host computer.

[0137] After completing the data processing of subsystem D, continue to receive the feedback data of subsystem E and search the frame header. Then, determine whether the length of the feedback data of subsystem E is 62 bytes. If the length does not match, skip the status bit configuration of subsystem E. If the length matches, configure the communication status bit of subsystem E based on the cumulative check result. Specifically, when the check is correct, set SendData.D0

[32] to 0x01, and when the check is incorrect, set SendData.D0

[32] to 0x00.

[0138] After the above steps are completed, the process will connect to the subsequent data framing and host computer uploading stage.

[0139] Step S206: Receive the interaction results from each subsystem, organize and frame the relevant data, complete the data verification process, and upload all data within the period to the host computer.

[0140] like Figure 2As shown, this step receives data processing and status configuration actions from subsystems D and E, and then enters the data framing and host computer upload stage. The specific process is as follows:

[0141] The effective data after the interaction and processing of each subsystem in the early stage are integrated, and the mechanical deflection command parameter group in the feedback data is sorted out first and included in the frame group as core data.

[0142] Accumulation and verification calculations are carried out. The specific calculation object is the byte data in the range SendData.D0[0]~SendData.D0[3]. After the calculation is completed, the obtained verification bit result is assigned to SendData.D0[6] to complete the verification preparation before framing.

[0143] The full data is framed according to the preset frame protocol. The framed data includes the communication status bit of subsystem A (SendData.D0[4], 0x01 is normal and 0x00 is abnormal), the communication status bit of subsystem B (SendData.D0[5], 0x01 is normal and 0x00 is abnormal), the 26-byte original feedback data of subsystem D (SendData.D0[19~31]), the communication status bit of subsystem E (SendData.D0

[32] , 0x01 is normal and 0x00 is abnormal) and the above-calculated sum check bit (SendData.D0[6]), ensuring that all key data are not omitted.

[0144] After framing is completed, the complete framing data for this cycle is sent to the host computer in real time through a dedicated test interface (RS-422 communication interface). The transmission parameters use the previously configured baud rate of 921600bps to ensure the stability and real-time performance of data transmission.

[0145] The framed data transmitted in the above steps will directly provide accurate data source support for the host computer software's data parsing, subsystem communication status determination, and test report generation.

[0146] Step S207: End the subsystem interaction and data processing task.

[0147] like Figure 2As shown, when the screening test fixture software successfully uploads the framed data containing complete parameters (including the communication status bit SendData.D0[4] of subsystem A, the communication status bit SendData.D0[5] of subsystem B, the cumulative and check bits SendData.D0[6], the 26 bytes of original data SendData.D0[19~31] of subsystem D, and the communication status bit SendData.D0

[32] of subsystem E) to the host computer through the RS-422 communication interface (baud rate 921600bps), the entire process of interactive tasks in this cycle is officially completed. If it is a multi-cycle test scenario, the software will repeat the loop of steps S204 to S206 according to the preset logic until all preset test cycle tasks are completed. Finally, after all the framed data of all cycles are successfully uploaded and there are no transmission abnormalities, the entire execution process of the screening test fixture software is completely finished, marking the completion of all subsystem communication and data acquisition tasks in this environmental stress screening test.

[0148] After introducing the screening test tooling software, we will now introduce the host computer screening test software.

[0149] The screening test software in the host computer receives standardized framed data uploaded by the screening test tooling software deployed inside the product processor. First, it performs frame header matching and cumulative verification on the whole frame data containing the communication status bits of subsystems A, B, and E (SendData.D0[4], D0[5], D0

[32] ), the original feedback data of subsystem D26 bytes (SendData.D0[19~31]), the cumulative check bit (SendData.D0[6]), and the mechanical deflection command parameter group. After verifying the validity of data transmission, it determines the communication status of subsystem C in conjunction with the data transmission. The system analyzes and extracts the communication status information of each subsystem (based on 0x01 / 0x00 encoding to determine normal / abnormal) and the performance parameters of subsystem D. It then performs real-time visualization and full-cycle recording and storage of the analyzed data, generating reports that meet experimental requirements. Simultaneously, it can send control commands downwards according to experimental needs, adjusting parameters such as the test cycle and interruption count threshold of the tooling software. This guides the tooling software in subsequent subsystem command issuance and data processing operations, enabling bidirectional data interaction with the tooling software. This allows for full-process control of the environmental stress screening test, ensuring accurate analysis of test data and the orderly progress of the test process.

[0150] Figure 3 This is a flowchart illustrating the workflow of the host computer-based screening test software. It specifically includes the following steps:

[0151] Step S301: Initialize the window and define the security box. Create path files, data storage files and report files based on the initialization information. Create threads by calling test functions according to different test types to build a basic environment for subsequent communication and data interaction.

[0152] like Figure 3 As shown, this step starts the process from the "Start" node. First, it performs window initialization, simultaneously defining the security frame. Next, it adds preset optional items to the window initialization information bar and enters the product number to complete the configuration of basic interface information. Then, it selects the test type and specific test items, and automatically creates three types of files based on the configured initialization information: path file, data save file, and report file. After the files are created, it opens the serial port and calls the corresponding test function to create threads according to the selected test type, setting up the test process's runtime environment. Finally, it sends a 5-byte handshake command to the product through the opened serial port to prepare for the subsequent communication handshake. This completes all the operations for process startup and initial configuration.

[0153] Step S302: Wait for the handshake instruction returned by the product, and send a debugging instruction to the product according to the handshake instruction. After completing the communication handshake, start the test data receiving process.

[0154] like Figure 3 As shown, this step enters the communication handshake and data reception preparation stage. First, a 5-byte handshake command is sent to the product through the opened serial port, and a judgment is made on "whether the handshake command returned by the product has been received". If the judgment result is "N (not received)", the current state is maintained and the process continues to wait until the handshake command returned by the product is received. If the judgment result is "Y (received)", a 6-byte debugging command is immediately sent to the product through the serial port to complete the communication handshake process with the product. Then, the "start receiving test data" operation is triggered, and the test data interaction stage is officially entered.

[0155] Step S303: Test data reception and preliminary verification. The received test data is subjected to a dual validity determination of the frame header format and verification information. If the determination result is that the frame header or verification information does not meet the preset protocol requirements, the current erroneous data is saved to the error file, and then the process returns to continue receiving new test data. If the determination result is that both the frame header and verification information meet the preset protocol requirements, the preliminary verification of this data is completed.

[0156] like Figure 3As shown, this step enters the test data reception and preliminary verification stage. First, test data from the product is continuously received, and the validity of the currently received test data is simultaneously determined by "judging the frame header and verifying its correctness" (the judgment content is whether the data frame header format and verification information meet the preset test data protocol requirements). If the judgment result is "N (frame header or verification is incorrect)," the currently received erroneous test data is saved to an error file, and then the process returns to the "receiving test data" step to continue the data reception and judgment operation. If the judgment result is "Y (frame header and verification are both correct)," the preliminary validity verification of this test data is completed, and the process smoothly connects to the subsequent subsystem data processing stage. The entire process covers all process details of data reception, validity judgment, and error data storage without any omissions.

[0157] Step S304: Subsystem data processing and hierarchical storage. Parse the raw data of the subsystem; first, store the raw data before parsing into an empty second data file, then accumulate the received frame count and time according to the rules; display the parameter data after subsystem parsing on the test interface, and store this parsed data into the second data file to realize hierarchical processing and classified storage of data.

[0158] like Figure 3 As shown, this step involves subsystem data processing and hierarchical storage. First, based on the preset communication protocol, the preliminarily verified test data is parsed to extract the communication status information of subsystems A to E (the result is judged as "normal" or "abnormal"), and displayed in real time in the corresponding module area of ​​the test interface. Simultaneously, the raw data of subsystems D and E is analyzed in detail. The raw data of subsystems D and E before parsing is completely stored in a preset empty-second data file, completing the first level of raw data storage. Then, the received frame count is accumulated and statistically analyzed, and timing is performed according to the preset rule of "every 400 frames received," forming a time dimension marker for data reception. Next, the parsed parameter data of subsystems D and E (such as deflection parameters, performance feedback parameters, etc.) is displayed again in the parameter display area of ​​the test interface, ensuring full coverage of data visualization. Finally, these parsed valid parameter data are stored in the data file, completing the second level of data storage and realizing hierarchical classification management of "raw data - parsed data." The entire process covers the status processing of subsystems A to E, the dual data storage of subsystems D and E, and the "400 frames / time" timing rule.

[0159] Step S305: Test duration determination and performance index analysis. Determine whether the current test duration is equal to the set duration. If not, return to the data processing stage to continue the loop execution. If equal, calculate the performance index of the subsystem, display the test results on the test interface, and save the single test result to the specified cell area of ​​the report file.

[0160] like Figure 3 As shown, this step enters the test duration determination and performance index analysis stage, performing the core determination of "whether the current test duration is equal to the set duration". The "current test duration" is the actual test time accumulated in the previous stage according to "time for every 400 frames received", and the "set duration" is the total test duration preset before the test. If the determination result is "N (not equal)", it directly returns to the "subsystem data processing and hierarchical storage" stage to continue the cyclic operation of data reception, processing and storage. If the determination result is "Y (equal)", it focuses on subsystems D and E to carry out performance index analysis, specifically calculating the core performance parameters of the two in the whole test duration (such as deflection accuracy stability, data response timeliness, etc.). Then, the calculated performance index results are displayed in real time in the performance analysis module of the test interface, and the complete results of this single round of test (including the communication status summary of subsystems A to E, and the performance index of subsystems D / E) are saved to the designated cell area of ​​the report file, completing the targeted archiving of the single round of test results.

[0161] Step S306: Full test item verification and process loop. After completing a single test, determine whether all test items of the same type of test have been completed. If not, return to the data receiving and processing stage to continue executing the remaining items. If completed, proceed to the multi-round test data aggregation stage.

[0162] like Figure 3 As shown, this step enters the full test item verification and process loop stage, performing the core judgment of "whether all test items of the same type have been completed". Here, "same type of test" refers to the test type selected in the previous process (such as subsystem test under a certain type of environmental stress), and "all test items" refers to the list of all preset sub-items under this type (the specific number and content of the items are fixed parameters configured before the test). If the judgment result is "N (not completed)", it will directly return to the "test data reception and preliminary verification" stage and continue to perform the full process operation of "data reception-processing-analysis-archiving" for the remaining test items to ensure that all preset sub-items under the same type can be fully covered. If the judgment result is "Y (completed)", the loop process of the current type of test ends and smoothly connects to the subsequent stage, preparing to carry out the integration and processing of multiple rounds of test data.

[0163] Step S307: Summarize multiple rounds of test data and generate the final report. Read the multiple test data stored in the report file, determine whether there are empty data types in the data. If there are, perform quality inspection on the test items, supplement the corresponding test content, and then read the report file again. If there are no empty data types, generate the final test report.

[0164] like Figure 3As shown, this step involves summarizing multiple rounds of test data and generating the final report. It locates the report file containing the previously stored test data and precisely reads the complete test data from multiple rounds stored in sheet2 of that file. The reading scope covers the communication status data of subsystems A through E, the performance index data of subsystems D / E, and the archived information of each round of tests. Subsequently, it performs a null type check on the read multi-round data to determine if there are any unfilled null data cells in sheet2. If the result is "yes (null type exists)," the test quality inspection process is initiated. Corresponding test content is supplemented for the test items corresponding to the null data. After completing the supplementary tests and obtaining valid data, the process returns to "reading the report file sheet." Following the "2 Data" step, data reading and null type number verification are performed again to ensure data integrity. If the judgment result is "No (no null type number)," the final test report is generated based on the complete multi-round test data in Sheet2 according to the preset report format. The final report is stored in Sheet1 of the report file. The report content covers core information such as the summary of multi-round test data, the comprehensive analysis results of subsystem performance, and the test qualification judgment conclusion. After the final report is generated, the entire workflow of the host computer screening test software is officially completed. The entire process covers all details such as the data reading range, null type number verification rules, supplementary test connection, and final report storage location, ensuring the integrity of multi-round test data and the validity of the final report.

[0165] Figure 4 This is a schematic diagram of the interface of the host computer screening test software. The software test interface adopts a split layout, which is divided into an operation configuration area on the left, a data display area in the middle, and a results display area on the right. The functional modules of each area are clearly defined.

[0166] The left-hand operation configuration and status area contains multiple functional modules: from top to bottom, they are "Input Test Product Information Area" (used to enter relevant information about the product under test), "Initialize Serial Port Configuration Area" (used to configure serial communication parameters), "Test Type and Project Selection Area" (used to select the type and specific project for this test), "Test Time Selection Area" (used to set the test duration parameters), and "Communication Status Judgment Result Display Area" (used to display the communication status judgment results of each subsystem). It is the core operation area for pre-test configuration and in-test status viewing.

[0167] The intermediate parsing data display area is divided into product dimensions to display the parsed test data: it includes "Display Parsed Product 1 Test Data Area 1" and "Display Parsed Product 1 Test Data Area 2" (corresponding to the two types of parsed data for Product 1), as well as "Display Parsed Product 2 Test Data Area 1" and "Display Parsed Product 2 Test Data Area 2" (corresponding to the two types of parsed data for Product 2), which are used to intuitively present the details of the parsed test data for different products.

[0168] The test results display area on the right corresponds to the products in the middle data area, and is divided into "Product 1 Test Results Display Area" and "Product 2 Test Results Display Area". These areas are used to display the final results of Product 1 and Product 2 after the tests are completed, respectively, so as to achieve a corresponding presentation of test data and results.

[0169] The interface modules are clearly divided, covering information input and parameter configuration before testing, data display and status viewing during testing, and result presentation after testing. It also supports simultaneous processing of test tasks for Product 1 and Product 2, facilitating parallel testing and data differentiation.

[0170] The following specific example, a temperature cycling screening test, will be used to provide a comprehensive explanation of the above scheme. Figure 5 This is a schematic diagram of a report from a temperature cycling screening test.

[0171] Deployment of screening test fixture software: The screening test fixture software written in C language is burned into the internal flash of the DSP processor of the electronic equipment product. Four RS-422 communication interfaces are configured to connect to subsystems A, B, C, and D, and one RS-422 interface is connected to the host computer. The communication cycle is 2.5ms and the baud rate is 921600bps.

[0172] Host computer software initialization: Start the C# host computer software compiled based on Visual Studio 2019, enter the product number (e.g., "PD20250825001"), select the test type as "temperature cycle", select the test item (e.g., "communication status + performance parameter test"), set the test duration to 30 minutes, and the software will automatically create a storage path "PD20250825001 / temperature cycle / communication status + performance parameter test / millisecond data / PD20250825001_communication status + performance parameter test.csv";

[0173] Tooling software data acquisition and feedback: The tooling software communicates with subsystems A and B according to the staggered frame design. In the first cycle, it sends test instructions. In the second cycle, it receives feedback data, processes it, and sends the next frame instruction. At the same time, it obtains the communication status of subsystems A, B, C, and E through accumulation and verification (all display 0x01, communication is normal). It receives 26 bytes of feedback data from subsystem D and directly frames it. In the final stage of the interrupt, it obtains 2 frames of data from subsystem E and selects odd-numbered frames as valid data. After all data is framed (65 bytes / frame), it is fed back to the host computer.

[0174] Host computer data processing: The host computer software parses the transmitted data in real time, and displays that subsystems A to E are all normal in the communication status display area. Test data area one displays the second data of subsystem D (e.g., "parameter 1: XX.XX, parameter 2: XX.XX"), and test data area two displays the second data of subsystem E (e.g., "parameter 1: XX.XX, parameter 2: XX.XX"). The data is synchronously stored in a .csv file.

[0175] Report generation: After the 30-minute test is completed, the software calculates the single test results and writes them into the report template sheet2; after completing 10 temperature cycle tests, click "Generate Test Report". The software calls the data in sheet2 to automatically calculate the minimum and maximum values ​​of each parameter, determines that all indicators meet the "normal" requirements, and generates the final temperature cycle screening test report in sheet1.

[0176] According to embodiments of this disclosure, a storage device is also provided. The storage device may include a processor and a memory, wherein the memory stores a computer program. When the computer program is executed by the processor, it can implement the methods provided in any of the above embodiments, and its execution method and beneficial effects are similar, and will not be repeated here. In addition, depending on the specific application, the storage device may also include any other suitable components.

[0177] It should be understood that although the steps in the flowcharts in the accompanying drawings are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts in the accompanying drawings may include multiple steps or stages, which are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0178] It is understood that the same / similar parts between the various embodiments of the methods described above in this specification can be referred to each other. Each embodiment focuses on the differences from other embodiments, and relevant parts can be referred to the description of other method embodiments.

[0179] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0180] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for environmental stress screening of electronic equipment assemblies, characterized in that, The method includes: The screening test tooling software is deployed inside the product processor to replace the original system working software of the product. It establishes interaction with each subsystem through the adapted communication configuration, completes the instruction issuance and feedback data reception, realizes data transmission optimization, communication status characterization and effective data screening, and transmits various interactive information back to the host computer in real time after standardized frame processing. The screening test software in the host computer receives standardized framed data uploaded from the screening test fixture software deployed inside the product processor. It first verifies the validity of the data, then determines the communication status of the relevant subsystems, and parses and extracts the communication status information and core performance parameters of each subsystem. The software interface displays the data in a modular fashion, automatically generates a save directory according to the test type, and stores the data files in categories, realizing data visualization and standardized storage. The software generates test reports and sends control commands to adjust the test-related parameters of the screening test fixture software, guiding its subsequent interaction and data processing operations. After standardizing and framing various interactive information, it is transmitted back to the host computer in real time, including: The data source integration and screening test tooling software first summarizes and sorts out the effective information after communication processing of each subsystem, clarifies the basic composition of the returned data, and ensures that no key information is omitted. Standardized frame format framing: The integrated data source is standardized and framed according to a preset frame protocol. Real-time data feedback configuration and execution: After the frame is assembled, the screening test tooling software transmits the complete data frame back to the host computer in real time through a dedicated communication channel. The validity of the returned data is verified in conjunction with the framing and transmission quality of the screening test tooling software, and is also linked with the communication status determination of the subsystem. The workflow for screening experimental tooling software includes: After the process is started, the basic environment configuration for software operation is completed, and the communication port is initialized to establish the basic conditions for subsequent communication and interaction. Receive debugging-related instructions and verify their validity. Once the instructions meet the requirements, trigger the interrupt response function. The system receives the trigger action of the interrupt response function, issues debugging instructions to the specified subsystem, and completes the first interaction with the subsystem within the interrupt cycle. The interrupt cycle-based instruction issuance action first completes cycle initialization and initial interaction with the specified subsystem, and then processes the data verification, communication status configuration, and instruction retransmission data fed back by the specific subsystem, so as to realize bidirectional interaction and status recording with these subsystems. Based on the interaction and processing status of the previous subsystems, the corresponding instructions are issued to the designated subsystems, and the feedback data of the designated subsystems and additional subsystems that synchronously process feedback data are processed, thus completing the interaction and information recording with these subsystems. Receive the interaction results from each subsystem, organize and frame the relevant data, complete the data verification process, and upload all data within the period to the host computer. End subsystem interaction and data processing tasks; Receive debugging-related commands and perform validity checks. Once the commands meet the requirements, trigger an interrupt response function, including: Entering a continuous waiting state, the system receives byte handshake commands from the debug port. Upon receiving the handshake command, it immediately performs an accumulation and verification operation. If the verification result is incorrect, it returns to the initial state of waiting to receive byte handshake commands and resumes waiting. If the verification result is correct, it switches to the next waiting state to receive debug commands from the debug port. After successfully receiving the debug command, it performs the accumulation and verification again. If the verification result is incorrect, it returns to the state of waiting to receive debug commands and resumes waiting. If the verification result is correct, it triggers the interrupt response function, completing the validity verification of the debug command and the interrupt triggering connection.

2. The method according to claim 1, characterized in that, The adapted communication configuration includes: runtime environment and implementation language adaptation, communication interface type and quantity configuration, communication cycle unification configuration, and baud rate configuration.

3. The method according to claim 1, characterized in that, Establish interaction with each subsystem, including: designing differentiated processing logic for the different communication needs of the subsystems to ensure that the interaction tasks of all subsystems are completed within the communication cycle.

4. The method according to claim 1, characterized in that, Handling data verification, communication status configuration, and command retransmission data from specific subsystems, specifically including: When processing feedback data from a specific subsystem, first determine whether the length of the received feedback data from the specific subsystem meets the preset requirements. If the length does not meet the requirements, skip the subsequent processing flow of the specific subsystem and proceed to the processing stage of another specific subsystem. If the length meets the requirements, find the data frame header and calculate the cumulative sum check. Configure the communication status bit of the specific subsystem according to the check result. After completing the status configuration, immediately send the debugging command to the specific subsystem again within the current cycle.

5. The method according to claim 1, characterized in that, The workflow of the host computer screening test software includes: Perform window initialization and security box definition, create path files, data storage files and report files based on initialization information, and call test functions to create threads according to different test types to build a basic environment for subsequent communication and data interaction; Wait for the handshake instruction returned by the product, and send a debugging instruction to the product according to the handshake instruction. After completing the communication handshake, start the test data receiving process. The test data reception and preliminary verification process involves a dual validity check of the received test data's frame header format and verification information. If the frame header or verification information does not meet the preset protocol requirements, the current erroneous data is saved to an error file, and the process returns to continue receiving new test data. If both the frame header and verification information meet the preset protocol requirements, the preliminary verification of the data is complete. Subsystem data processing and hierarchical storage: Parse the raw data of the subsystem; first, store the raw data before parsing into an empty second data file, then accumulate the received frame count and time according to the rules; display the parameter data after parsing of the subsystem on the test interface, and store this parsed data into the second data file to realize hierarchical processing and classified storage of data; Test duration determination and performance index analysis: Determine whether the current test duration is equal to the set duration. If not, return to the data processing stage to continue the loop. If equal, calculate the subsystem's performance index, display the test results on the test interface, and save the single test result to the specified cell area of ​​the report file. The entire test project is verified and the process loop is repeated. After a single test is completed, it is determined whether all test projects of the same type have been completed. If not, it returns to the data receiving and processing stage to continue executing the remaining projects. If it has been completed, it enters the stage of summarizing test data from multiple rounds.

6. The method according to claim 5, characterized in that, The workflow of the host computer screening test software also includes: summarizing multiple rounds of test data and generating the final report; reading multiple test data stored in the report file; determining whether there are empty data types in the data; if so, performing quality inspection on the test items, supplementing the corresponding test content, and then reading the report file again; if there are no empty data types, generating the final test report.

7. A storage device, characterized in that, include: A memory and a processor, the processor including multiple cores, wherein the memory stores a computer program that, when executed by the processor, implements the method as described in any one of claims 1 to 6.

Images