Automatic collection and cloud upload of firmware logs triggered by production testing failures: methods, systems, devices, and storage media.

Abstract

This invention relates to the field of production line testing technology, and more particularly to a method, system, device, and storage medium for automatic collection and cloud upload of firmware logs triggered by production test failures. The method includes: registering a failure event listening mechanism in the production test tool to capture failure events and generate a log collection task identifier; automatically starting firmware-side log collection to obtain a firmware log set; extracting factory test log fragments and production test environment metadata corresponding to the current test process of the device under test; associating and archiving the firmware logs, factory test logs, and metadata to generate a dual-channel joint log package; asynchronously uploading the dual-channel joint log package to the cloud in a background thread and establishing an association between the log identifier and the failure record; and performing local cache cleanup or retention and retransmission based on the upload result. This invention, through a failure event-driven dual-channel log joint collection and asynchronous upload mechanism, achieves real-time preservation and centralized traceability of test failure scenarios, improving root cause localization efficiency without affecting production line cycle time.

Description

Technical Field

[0001] This invention relates to the field of production line testing technology, and in particular to a method, system, device, and storage medium for automatically collecting and uploading firmware logs to the cloud when production testing fails. Background Technology

[0002] With the continuous improvement of automation in intelligent audio equipment production lines, production line testing systems are showing a significant trend towards higher efficiency and reliability. Against this backdrop, to improve the diagnostic efficiency of production testing failures, traditional techniques typically employ manual post-event reproduction or manual log capture solutions, mainly encompassing manual experiment reproduction, operator manual command capture, and distributed storage of local logs.

[0003] During manual reproduction experiments, engineers can only make speculative reproductions based on the failure names and judgments recorded by the production testing tools. When a test fails, the internal operating status information of the device firmware at the moment of failure is completely missing, forcing engineers to conduct a large number of repetitive reproduction experiments, often taking several hours or even days to locate the root cause. This severely limits the rapid response and closed-loop efficiency of production line failures. Manual command capture by operators relies on engineers manually executing ADB or serial port commands to collect firmware logs after a test failure. However, due to the delay of several minutes or even tens of minutes caused by manual intervention, the device under test has often cleared the critical logs due to automatic restart or entering protection mode. It is impossible to truly restore the firmware operating situation at the moment of failure, affecting the accuracy and timeliness of fault location. Although the local log distributed storage solution retains some log data to a certain extent, the log files are scattered across various production line workstations, lacking unified storage specifications, naming standards, and a centralized management platform. As the scale of the production line and the number of test workstations increase, the data silo problem becomes more and more serious, making it difficult to support systematic failure mode analysis and continuous process improvement based on a large amount of historical data. Furthermore, the aforementioned traditional solutions all rely on manual logging. When equipment failure modes exceed the engineers' experience or involve intermittent firmware anomalies, even if the failure occurs repeatedly, the lack of a complete snapshot of the moment of failure will cause the entire diagnostic process to fall into a state of repeated trial and error, making it difficult to ensure the rapid convergence and continuous optimization of production line process problems.

[0004] In real-world production line applications, the diagnostic information requirements after different test items fail vary significantly. When core functional test items (such as audio distortion, network connectivity, and power output) fail, there is an urgent need for in-depth diagnostic information such as firmware kernel logs, driver errors, and audio link status. However, the completeness requirements for on-site information are relatively lower when most minor test items fail. However, traditional production test failure handling solutions, once the process is established, are difficult to dynamically adjust, and all failure cases rely on a uniform manual post-failure processing procedure. This forces production lines to allocate engineer resources based on the highest diagnostic requirements for core faults. When a large number of minor failure cases occur frequently, the engineering team is forced into highly repetitive, low-value manual reproduction work, leading to excessive consumption of diagnostic resources and significant deficiencies in terms of manpower costs and response time. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by providing a method for automatically collecting and uploading firmware logs to the cloud when production testing fails, comprising the following steps: Register a failure event listening mechanism in the test engine of the production testing tool to listen for failure events of the device under test (DUT) during the testing process, and generate a log collection task identifier corresponding to the current device DUT when a failure event that meets the triggering conditions is detected. Based on the log collection task identifier, firmware-side log collection is automatically started within the start delay that meets the timeliness constraint, so as to obtain a set of firmware logs that characterize the device firmware running status when the failure occurs. Extract the factory test log fragments corresponding to the current test process of the current device DUT from the memory log cache maintained in real time by the production test tool, according to the timestamp range, and obtain the production test environment metadata related to the device DUT; The firmware log set, the factory test log fragment, and the production test environment metadata are associated, archived, and packaged to generate a dual-path joint log package that simultaneously contains firmware-side logs and factory test-side logs. In a background thread or independent task queue that does not block the main production test process, the dual-path joint log package is asynchronously uploaded to the cloud, and after successful upload, the permanent log identifier returned by the cloud is associated with the failed test record of the current DUT. Based on the uploaded results, local cache management is performed. After confirming that the cloud has completed receiving and storage, the corresponding local cache is deleted; if the upload fails, the local cache is retained for subsequent re-upload.

[0006] Preferably, the failure event listening mechanism includes: When the production testing tool starts, the failure event listener is registered to the test engine's event bus or result distribution module, and the failure event listener subscribes to at least one failure event type, such as single test item failure events or overall system failure events. The failure event listener receives events asynchronously in an independent thread pool in the form of a callback function, without occupying the main test engine's execution thread. After the test engine outputs the test results, it sends an event payload containing the test item name, measurement value, judgment result, judgment timestamp, DUT sequence number and test process identifier to the failure event listener. The failure event listener determines whether to trigger the log collection process according to a preset triggering strategy. The triggering strategy includes at least one of the following: any failure triggers the mode, a specified test item failure triggers the mode, and a comprehensive machine failure triggers the mode. When the triggering conditions are met, a log collection task identifier corresponding to the current failure event is generated and submitted to the background processing thread to decouple the log collection action from the foreground test execution thread.

[0007] Preferably, it also includes debouncing and deduplication processing for multiple failure events of the same DUT in the same test process: Use the combination of the DUT serial number and the unique identifier of the test process as the deduplication key; When the first failure event corresponding to the same deduplication key meets the triggering condition, a log collection task is created and the triggered status of the deduplication key is recorded. When a failure event corresponding to the same deduplication key is received again, the creation of new log collection tasks will be stopped. The newly added failure test item information will be appended to the factory test log fragment or failure summary information corresponding to the device DUT. Multiple failed test items occurring on the same device DUT in the same test process are merged into a single dual-path combined log package to reduce resource consumption caused by repeated collection and uploading.

[0008] Preferably, automatically initiating firmware-side log collection includes detecting the connection status of the current device under test (DUT) based on a preset communication channel priority and selecting a collection channel, including: Check if the current device DUT has a USB debugging connection and if the ADB service is in a communicable state. If so, select the ADB channel as the first acquisition channel. If the ADB channel is unavailable, check if the debug serial port corresponding to the current device DUT is accessible. If it is accessible, send a preset log export command through the serial port and use the serial port as the second acquisition channel. If both the ADB channel and the serial port channel are unavailable, determine whether the current device DUT is connected to the local area network and supports remote login service. If so, execute the log export command through the SSH channel and use SSH as the third acquisition channel. The final selected acquisition channel will be written into the metadata of this joint log package to trace the source and availability of the acquisition channel.

[0009] Preferably, firmware log collection is performed in layers according to timeliness constraints and log priority, including: Within a preset startup delay threshold after a failure event is triggered, the first-level log collection is initiated first. The first-level log includes at least the kernel ring buffer log, audio link status log, and application layer log within a predetermined time window before the failure. The preset startup delay threshold does not exceed 2 seconds to ensure that critical logs are captured before the device may automatically restart or enter protection mode. After completing the first level of log collection, if the current total collection time does not exceed the preset total duration threshold, the second level of log collection will continue. The second level of log includes at least one of the following: complete application layer log, network interface status, memory status, and bus error count. If there is still remaining collection time and the current product model supports extended logs, continue collecting third-level logs, which include at least one of the following: player private logs, wireless communication protocol stack logs, or product-specific debugging logs. Set a command-level timeout for each data collection command. When any command times out or fails to execute, skip the command and record a failure flag, without terminating the collection of other log entries. This ensures that the most diagnostically valuable failure logs are preserved before the device may restart or enter protection mode.

[0010] Preferably, the memory log cache is implemented using a circular buffer, extracting plant test log fragments from the production test tool, including: During the operation of the production testing tool, the test logs output by the test engine are continuously written to the local rolling log file, and a circular buffer is maintained in memory to store the most recent log records. After a failure event is triggered, the log records belonging to the current test process of the device DUT are filtered and extracted from the circular buffer, starting from the timestamp of the start of the current test process and ending from the timestamp of the failure event. When the log records in the circular buffer are insufficient to cover the entire time range of this test process, the corresponding logs are read from the local rolling log file according to the timestamp range to fill in the missing parts, thereby obtaining a complete factory test log segment. The extracted plant test log fragments are serialized and stored in a structured format, so that each log record contains at least a timestamp, test item identifier, execution stage, measurement value, threshold, and result field.

[0011] Preferably, it also includes building production testing environment metadata: Read the production testing tool version number, workstation number, operator employee number or automatic operation identifier, test fixture number, product model and DUT serial number; Summarize the list of failed test items in the current DUT testing process, and record the corresponding measurement value, judgment threshold, result type and trigger time for each failed test item; The trigger strategy mode, the actual firmware log collection channel used, the log collection start time, the collection completion time, and the collection exception information are added as additional context fields to the metadata; The metadata is written to the total metadata file and the factory test environment metadata file in the dual-path joint log package, respectively, to support multi-dimensional retrieval and analysis of failure cases in the cloud by model, workstation, test item, time period and collection method.

[0012] Preferably, the archiving and packaging includes archiving according to a preset directory structure, and the generation of the dual-path combined log package includes: Create a root directory named after the DUT serial number, failure timestamp, and product model; A firmware log directory and a factory test log directory are created in the root directory. The firmware log directory is used to store firmware log files from different sources and at different levels. The factory test log directory is used to store factory test log fragments and production test environment metadata files. Generate a total metadata file in the root directory. The total metadata file shall include at least the DUT serial number, product model, failure time, trigger mode, acquisition channel, summary of failed test items, and log file list. Firmware-side logs and factory test-side logs are written to their respective directories according to preset file naming rules, thereby forming a dual-channel joint log directory tree that can jointly reconstruct the test failure scenario.

[0013] Preferably, the archive packaging also includes performing compression and integrity verification on the archived union log directory tree: The federated log directory tree is compressed to generate a single compressed log package, and the hash check value of the compressed log package is calculated and written to the total metadata file. Perform a format integrity check on the generated compressed log package, and check whether the total metadata file exists in the compressed log package and whether the preset required fields are complete; If the integrity check passes, the compressed log package will be used as the object to be uploaded. If the integrity check fails, the corrupted compressed log package is discarded, and the uncompressed union log directory tree is retained as the alternative upload object. At the same time, the reason for the compression failure and the local resource status information are recorded.

[0014] Preferably, asynchronously uploading the dual-path combined log packet to the cloud includes performing cloud pre-registration and persistent uploading tasks: Before the formal upload, a pre-registration request is sent to the cloud service. The pre-registration request carries the DUT serial number, product model, failure time, workstation number, summary of failed test items, and size information of the object to be uploaded. Receive the upload task identifier, upload address, fragmentation parameters, and validity period information returned by the cloud; The upload task identifier, upload address, fragmentation parameters, local file path, task status, and completed fragmentation information are written into a local database or persistent task queue to construct a recoverable upload task record. The background upload thread polls the local database or persistent task queue and performs subsequent upload processing on tasks with a pending upload status, thus enabling the upload process to run independently outside of the main production testing process.

[0015] Preferably, asynchronous upload also includes chunked upload and breakpoint resume mechanisms: When the size of the object to be uploaded exceeds the preset fragmentation threshold, it is divided into multiple upload fragments, and an upload request is initiated for each fragment separately; when the size of the object to be uploaded does not exceed the fragmentation threshold, it is uploaded as a whole package. During the upload process, the upload results of each segment, the set of completed segment numbers, the reasons for failure and the number of retries are recorded in real time, and the task status in the local database is updated synchronously. When any fragment upload fails, a retry is performed according to the exponential backoff strategy. Before the retry, the set of successfully received fragments is queried from the cloud, and only the missing fragments are re-uploaded. If the number of retries reaches the preset limit and the task still fails, the task status will be updated to "failed and awaiting recovery," and local files and fragment completion records will be retained so that the task can be reactivated by a background scheduled task to continue uploading once the network is restored.

[0016] Preferably, the upload confirmation, record association, and local cleanup include: After all segments or the entire package has been uploaded, a merge confirmation or receipt confirmation request is sent to the cloud, and the cloud is polled to check whether the file storage has been completed. When the file size, file identifier, or verification result returned by the cloud matches the information of the object to be uploaded locally, the upload is considered successful, and the permanent log identifier and access address returned by the cloud are received. The permanent log identifier is written back to the local task record, and the permanent log identifier is automatically associated with the failure test record or MES record corresponding to the current device DUT, so that the user can directly access the dual-path joint log packet on the failure record page; Only after the permanent log identifier is successfully written and the cloud confirms the storage completion will the corresponding local compressed log package or the original federated log directory tree be deleted. If the task is in a failed and pending recovery state, the local cache will continue to be retained for a preset retention period, and the cleanup will be performed after the retention period expires.

[0017] Based on the same concept, the present invention also provides an automatic firmware log collection and cloud upload system triggered by production test failure, including a failure monitoring module, a firmware collection module, a factory test extraction module, a joint packaging module, an asynchronous upload module, and a cache management module. The failure monitoring module is used to register a failure event monitoring mechanism in the test engine of the production testing tool, to monitor failure events of the device under test (DUT) during the testing process, and to generate a log collection task identifier corresponding to the current device DUT when a failure event that meets the triggering conditions is detected. The firmware acquisition module is used to automatically start firmware-side log acquisition within a startup delay that meets the timeliness constraints according to the log acquisition task identifier, so as to obtain a set of firmware logs that characterize the device firmware running status when the failure occurs. The factory test extraction module is used to extract the factory test log fragments corresponding to the current test process of the current device DUT from the memory log cache maintained in real time by the production test tool, according to the timestamp range, and obtain the production test environment metadata related to the device DUT. The joint packaging module is used to associate, archive, and package the firmware log set, the factory test log fragment, and the production test environment metadata to generate a dual-path joint log package that simultaneously contains firmware-side logs and factory test-side logs. The asynchronous upload module is used to asynchronously upload the dual-path joint log package to the cloud in a background thread or independent task queue without blocking the main production test process, and to associate the permanent log identifier returned by the cloud with the failed test record of the current DUT after successful upload. The cache management module is used to perform local cache management based on the upload results. After confirming that the cloud has completed receiving and storing the data, the corresponding local cache is deleted; if the upload fails, the local cache is retained for subsequent re-upload.

[0018] Based on the same concept, the present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of the method for automatically collecting and uploading firmware logs to the cloud as described in the embodiment when the production test fails.

[0019] Based on the same concept, the present invention also provides a computer-readable storage medium, wherein when the computer-readable instructions are executed by one or more processors, the one or more processors perform the steps of the firmware log automatic collection and cloud upload method triggered by production test failure as described in any one of the embodiments.

[0020] Compared with the prior art, the beneficial effects of the present invention are: (1) This invention uses a built-in failure event listener in the production testing tool to automatically trigger test failure events, transforming the collection of firmware-side logs and factory test-side logs from passive manual drive to active automatic drive. This achieves a dual-channel log joint collection architecture driven by failure events. The failure event automatically triggers the real-time collection of high-value firmware kernel logs, driver errors, audio link status and other in-depth diagnostic information, while low-value routine test records are naturally covered by the factory test-side logs, thereby ensuring a significant improvement in root cause localization efficiency and reasonable allocation of production line diagnostic resources.

[0021] (2) This invention archives and packages the firmware-side log collection, factory test log fragments and production test environment metadata according to a preset standardized directory structure to generate a dual-channel joint log package containing firmware-side logs and factory test logs. After the dual-channel joint log package is asynchronously uploaded to the cloud, it is associated with the failure test records of the current DUT, realizing the structured fusion storage of the firmware-side running site and the factory test execution context. The cloud platform provides multi-dimensional retrieval capabilities by model, workstation, test item, time period and collection method, enabling engineers to obtain a complete failure site snapshot with one click on the failure record page.

[0022] (3) This invention achieves zero impact on the production line cycle time by performing cloud pre-registration, fragmented upload, breakpoint resume and upload status management in a background thread or task queue independent of the main production test process. When a network interruption occurs during the upload process, the locally persistent upload task identifier and completed fragmented record support the breakpoint resume after network recovery. When the retry reaches the limit and still fails, the task is marked as failed and awaits recovery and the local cache is retained. The background timed task is reactivated to continue the upload, thereby ensuring that the log package is not lost due to network fluctuations and achieving highly reliable data preservation. When the upload is successful and the cloud storage is confirmed to be completed, the local cache is automatically cleared to release the workstation disk space. It has significant advantages of high reliability, low operation and maintenance cost and no impact on the production line. Attached Figure Description

[0023] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention.

[0024] Figure 1 This is a flowchart of a method for automatically collecting and uploading firmware logs to the cloud when a production test fails, according to the present invention. Figure 2 This is a flowchart illustrating the timeliness constraints of firmware log layered collection in this invention. Figure 3 This is a schematic diagram of an automatic firmware log collection and cloud upload system triggered by a production test failure according to the present invention; Figure 4 This is a schematic diagram of one embodiment of the computer device of the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. Obviously, the described embodiments are only some, not all, of the embodiments described in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without creative effort are within the scope of protection of this application.

[0026] Those skilled in the art will understand that, unless otherwise stated, the singular forms “a” and “an” used herein, and “the”, may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0027] It is understood that the executing entity of this invention can be an IoT terminal, an embedded communication device, a smart gateway, an edge computing node, a server, or other electronic devices with network address management capabilities, and no specific limitation is made here. The following embodiments use IoT devices as the executing entity for description, but the invention is not limited thereto.

[0028] First Embodiment Please see Figure 1As shown, this embodiment provides a method for automatically collecting and uploading firmware logs to the cloud when production testing fails. By constructing an automatic collection closed-loop mechanism in the production testing tool with failure events as the sole driving source, it automatically and synchronously collects the deep operational logs from the device firmware side and the test execution logs from the production testing tool side at the moment of test failure. These logs are then structured and packaged into a dual-path joint log package. Cloud pre-registration, fragmented upload, breakpoint resumption, and upload confirmation are completed in a background thread independent of the main production testing process. This achieves adaptive adaptation to complex production line network environments, communication differences between multiple device models, and local resource constraints at workstations, significantly improving the efficiency of root cause localization of production line test failures, the ability to accumulate failure data assets, and the level of zero-impact operation on production line cycle time. The method includes the following steps: S101: Register a failure event listening mechanism in the test engine of the production testing tool to listen for failure events of the device under test (DUT) during the testing process, and generate a log collection task identifier corresponding to the current device DUT when a failure event that meets the trigger conditions is detected.

[0029] Preferably, the failure event listening mechanism includes: When the production testing tool starts, the failure event listener is registered to the test engine's event bus or result distribution module, and the failure event listener subscribes to at least one failure event type, either a single test item failure event or a system-wide comprehensive failure event. The failure event listener receives events asynchronously in an independent thread pool in the form of a callback function, without occupying the main test engine's execution thread. This ensures that any operation of the listener does not block the continued progress of the testing process.

[0030] Furthermore, the core thread count of the independent thread pool can be dynamically configured based on the number of concurrent DUTs at each workstation, preferably as follows: ,in, This indicates the core thread count of the listening and task submission thread pool. This indicates the number of DUTs that can be processed concurrently at the current workstation. By implementing these constraints, we can avoid wasting thread resources while ensuring real-time response during peak failure periods.

[0031] After the test engine outputs the test results, it sends an event payload containing the test item name, measurement value, judgment result, judgment timestamp, DUT sequence number and test process identifier to the failure event listener.

[0032] The failure event listener determines whether to trigger the log collection process based on a preset triggering strategy. The triggering strategy includes at least one of the following: trigger mode for any failure, trigger mode for failure of a specified test item, and trigger mode for overall machine failure.

[0033] In one optional implementation, the trigger strategy configuration can be defined in JSON format through the production testing tool's configuration file, and each workstation can configure it independently. In the specified test item failure trigger mode, log collection is triggered only when high-value test items listed in the configuration file (such as core functional tests like audio distortion, network connectivity, and power output) fail, filtering out occasional failures of secondary test items. In the overall system failure trigger mode, it is triggered only once when all test items on the entire DUT have been executed and the overall result is determined to be a failure, reducing the overhead of repeated data collection for a single DUT due to multiple test item failures.

[0034] Furthermore, the failure trigger determination function can be expressed as: ,in, Indicates the current failure event payload. This represents the set of triggering strategies configured for the current workstation. Indicates the current DUT testing status; when A log collection task is generated on time; otherwise, the failure event is ignored.

[0035] In one specific implementation, taking the A-type intelligent audio amplifier as an example, the production testing tool sequentially executes 47 test items in the testing process, including network testing, audio output testing, AUX input testing, LED testing, touchscreen testing, and power output testing. After the listener is registered, when the 12th test item, "Audio Output Test - Left Channel THD+N," is determined to be FAIL, the main testing engine publishes a failure event to the event bus. The event payload includes information such as the test item name AUD_L_THDN, the measured value of 3.82%, the pass / fail limit of 1.00%, the judgment timestamp, and the DUT serial number. The failure event listener callback function is immediately triggered, carrying the complete event payload into the subsequent process.

[0036] When the triggering conditions are met, a log collection task identifier corresponding to the current failure event is generated and submitted to the background processing thread to decouple the log collection action from the foreground test execution thread.

[0037] Preferably, it also includes debouncing and deduplication processing for multiple failure events of the same DUT in the same test process: Use the combination of the DUT serial number and the unique identifier of the test process as the deduplication key; When the first failure event corresponding to the same deduplication key meets the triggering condition, a log collection task is created and the triggered status of the deduplication key is recorded. When a failure event corresponding to the same deduplication key is received again, the creation of new log collection tasks will be stopped. The newly added failure test item information will be appended to the factory test log fragment or failure summary information corresponding to the device DUT. Multiple failed test items occurring on the same device DUT in the same test process are merged into a single dual-path combined log package to reduce resource consumption caused by repeated collection and uploading.

[0038] Furthermore, the deduplication key can be defined as: ,in, Indicates the DUT serial number. This indicates a unique identifier for the testing process. This indicates a concatenation or combination operation. This deduplication key ensures that only one joint log task is created for the same device and the same test round.

[0039] S102: Based on the log collection task identifier, automatically start firmware-side log collection within the start delay that meets the timeliness constraint, so as to obtain a set of firmware logs that characterize the device firmware running status when the failure occurs.

[0040] Preferably, automatically initiating firmware-side log collection includes detecting the connection status of the current device under test (DUT) based on a preset communication channel priority and selecting a collection channel, including: Check if the current device DUT has a USB debugging connection and if the ADB service is in a communicable state. If so, select the ADB channel as the first acquisition channel.

[0041] If the ADB channel is unavailable, check if the debug serial port corresponding to the current device DUT is accessible. If it is accessible, send a preset log export command through the serial port and use the serial port as the second acquisition channel. If both the ADB channel and the serial port channel are unavailable, determine whether the current device DUT is connected to the local area network and supports remote login service. If so, execute the log export command through the SSH channel and use SSH as the third acquisition channel.

[0042] The final selected acquisition channel will be written into the metadata of this joint log package to trace the source and availability of the acquisition channel.

[0043] Furthermore, channel selection can be performed according to the following priority function: ,in, This indicates the priority value of the communication channel, which is preferably set to [value]. , , When a higher-priority channel becomes unavailable, the system automatically falls back to the next higher-priority channel.

[0044] Please see Figure 2 As shown, firmware log collection is performed in layers according to timeliness constraints and log priority, including: Within a preset startup delay threshold after a failure event is triggered, the first-level log collection is initiated first. The first-level logs include at least the kernel ring buffer log, audio link status log, and application layer logs within a predetermined time window prior to the failure. The preset startup delay threshold does not exceed 2 seconds to ensure that critical logs are captured before the device may automatically restart or enter protection mode. This embodiment introduces a log collection priority hierarchical mechanism, dividing firmware log collection content into three levels (P1, P2, and P3) based on diagnostic value from high to low, and within a preset total duration threshold. Data collection is performed according to hierarchical priority.

[0045] After completing the first-level log collection, if the current total collection time does not exceed a preset total duration threshold, the second-level log collection continues. The second-level log includes at least one of the following: complete application layer log, network interface status, memory status, and bus error count. Specifically, in this embodiment, the P1 level is a mandatory collection level, which is initiated preferentially within a preset startup delay threshold T_trigger_delay after a failure event is triggered. T_trigger_delay is preferably 2 seconds. The P1 level log includes at least the kernel ring buffer log, audio link status log, and application layer log within a predetermined time window before the failure, and is completed within 5 seconds. The P2 level is a conditional collection level. After completing the P1 level log collection, if the current total collection time does not exceed a preset total duration threshold... .

[0046] While there is still remaining data collection time and the current product model supports extended logs, the collection of third-level logs continues. These third-level logs include at least one of the following: player-specific logs, wireless communication protocol stack logs, or product-specific debugging logs. Specifically, in this embodiment... The preferred time is 30 seconds. Level P3 is an optional sampling level; if there is still remaining sampling time and the current product model supports extended logs, continue sampling the third level of logs.

[0047] Set a command-level timeout for each data collection command. The preferred interval is 10 seconds. When any command times out or fails to execute, the command is skipped and a failure flag is recorded, without terminating the collection of other log entries. This ensures that the most diagnostically valuable failure logs are preserved before the device may restart or enter protection mode.

[0048] Furthermore, the total data collection time should meet the following requirements: And the execution time of a single command meets the following requirements: ,in, This indicates the total duration of firmware log collection. , , These represent the time consumed for data collection at levels P1, P2, and P3, respectively. Time budget constraints ensure that the log collection process will not be blocked globally due to delays in a single command.

[0049] In actual execution, if the previous level experiences slower response due to device malfunction or command timeout, resulting in a longer actual time consumption than expected, the total time limit alone cannot guide the time allocation for the remaining levels. Therefore, this embodiment introduces an adaptive allocation algorithm for the remaining time of layered firmware log collection. Before the k-th level starts, this algorithm dynamically calculates the available time budget for the current level and subsequent levels based on the consumed time and the diagnostic value weights of the remaining levels. This maximizes the root cause localization value of the collected information while strictly adhering to the total time limit.

[0050] The adaptive allocation algorithm for remaining time in firmware log tiered collection is shown in the following formula: ,in, For the first The dynamic allocation of time budget (in seconds) at each level is calculated in real time by the algorithm. This is the maximum total duration for firmware log collection, i.e. 30 seconds is preferred. This represents the actual data collection time (in seconds) for the i-th level, and only has values ​​for completed levels. This is the sum of the actual time spent on each completed level (i=1 to k-1) before the start of level k, i.e., the total time consumed. The diagnostic value weight for the k-th level reflects the importance of the logs at that level for root cause localization. This is the sum of weights from level k to the last level K, used for normalization to ensure the remaining time is allocated proportionally. K is the total number of data collection levels. =3, corresponding to the three levels P1, P2, and P3. Recommended weight values: , , This reflects the prior judgment that P1-level kernel logs have the highest diagnostic value and P3-level private logs have the lowest value. Weights can be configured independently for each product model in the production testing tool's configuration file.

[0051] The following uses a smart audio amplifier (Type A) as an example to illustrate three typical scenarios of this algorithm, setting... Three-level weighting , , .

[0052] Scenario 1: P1 data collection is normal (actual time taken: 4 seconds). Before P2 begins, 4 seconds have been consumed, leaving 30 - 4 = 26 seconds. The sum of the weights of P2 and P3 is 0.3 + 0.1 = 0.4. The algorithm calculates separately... and : P2 was allocated a budget of 19.5 seconds, and P3 was allocated a budget of 6.5 seconds, both having ample time to complete the data acquisition. This scenario represents a normal data acquisition path, and the algorithm results are not significantly different from the fixed-slice strategy, validating the algorithm's baseline behavior under normal conditions.

[0053] Scenario 2: P1 timed out due to suspension caused by the ALSA driver (actual time elapsed: 12 seconds). The P1 timeout resulted in 12 seconds of elapsed time, leaving only 30-12=18 seconds remaining. The algorithm dynamically reallocated the remaining time. and : Compared to the fixed-slice strategy (P2 fixed at 10 seconds, P3 fixed at 5 seconds), the adaptive algorithm extends the P2 time to 13.5 seconds, making it more likely that the complete application layer logs will be collected completely; the cost of P1 timeout is borne by P3, which has the lowest diagnostic value (compressed to 4.5 seconds), which is in line with the design goal of maximizing the amount of root cause localization information.

[0054] Scenario 3: Both P1 and P2 time out (total time 27 seconds). With only 3 seconds remaining, the algorithm allocates all remaining time to P3. Even in extreme timeout scenarios, the algorithm can automatically allocate all remaining time to P3 and attempt to collect private player logs within 3 seconds. This is superior to the fixed strategy of directly skipping P3 and fully utilizes the last collection window.

[0055] By introducing the aforementioned adaptive allocation algorithm for the remaining time of firmware log hierarchical collection, this embodiment has at least the following beneficial technical effects: Effect 1: Maximizing the amount of root cause information in a single data collection. The fixed-time slicing strategy allocates a fixed amount of time to P2 as originally planned when P1 times out, resulting in a situation where high-value levels time out while low-value levels have ample time. The adaptive allocation algorithm redistributes the remaining time according to the diagnostic value weight, ensuring that the time budget for each level is commensurate with its diagnostic value in any timeout scenario, thus maximizing the root cause localization value of the collected information overall.

[0056] Effect 2: The upper bound of the total data acquisition time is determined, and the impact on production line cycle time is controllable. Regardless of how the actual data acquisition time at each level fluctuates, the algorithm strictly guarantees that the total data acquisition time does not exceed [a certain limit]. Its upper bound determinism is completely consistent with the fixed slicing strategy, without introducing additional time uncertainty, and meets the core design requirement of zero impact on production line cycle time.

[0057] Effect 3: Weights can be configured differently according to product models, with one algorithm adaptable to all product lines. The core fault modes of the Type B intelligent audio player (without amplifier) ​​and the Type A intelligent audio amplifier (with amplifier) ​​are different; for the former, the audio ALSA log (P1) is the most critical, while for the latter, the power drive bus error log (P2) is equally important. By adjusting... , , The value of allows the same algorithm framework to be adapted to the diagnostic priority strategies of different products, eliminating the need to implement separate data acquisition and scheduling logic for each product model, thus reducing system maintenance costs.

[0058] In one specific implementation, taking the A-type intelligent audio amplifier as an example, the production testing tool completes channel selection and begins executing the P1-level acquisition command sequence within 1.1 seconds after a failure event is triggered: using ADB to execute `adb shell dmesg` to obtain the kernel ring buffer log, `adb shell logcat -d` to obtain the user space application log, `adb shell cat / proc / asound / cards` to obtain the ALSA sound card registration status, and `adb shell cat / proc / net / dev` to obtain network interface packet transmission and reception statistics. P1-level acquisition is completed within 4.2 seconds; P2-level acquisition is completed within an additional 8.6 seconds; and P3-level acquisition is completed within an additional 3.1 seconds. The total acquisition time is 15.9 seconds, which is less than [the required time]. The upper limit is that all three levels of logs are fully collected.

[0059] For example, a certain smart audio player (model B) failed a test after a fatal error occurred in its audio ALSA driver, and the firmware was about to automatically restart within 2 seconds. This method completes channel selection and starts executing the dmesg acquisition command within 1.1 seconds after the failure event is triggered, successfully capturing the ALSA driver error message "snd_soc_component_open: failed -EIO" in the kernel log before the device restarts. This error message is cleared by dmesg after the device restarts. If the acquisition delay exceeds 2 seconds, it cannot be acquired, and the root cause of the failure will be impossible to trace.

[0060] S103: Extract the factory test log fragments corresponding to the current test process of the current device DUT from the memory log cache maintained in real time by the production test tool, according to the timestamp range, and obtain the production test environment metadata related to the device DUT.

[0061] Preferably, the memory log cache is implemented using a circular buffer, extracting factory test log fragments from the production test tools, including: During the operation of the production testing tool, test logs output by the test engine are continuously written to a local rolling log file, and a circular buffer is maintained in memory to store the most recent log records. The capacity of the circular buffer is... Ideally, there should be 500 log entries, which roughly covers the complete test process log of a single DUT. This is used to quickly extract the test context log of the current DUT without having to read the entire disk log file.

[0062] After a failure event is triggered, the log records belonging to the current test process of the device DUT are filtered and extracted from the circular buffer, starting from the timestamp of the start of the current test process and ending from the timestamp of the failure event.

[0063] When the log records in the circular buffer are insufficient to cover the entire time range of this test process, the corresponding logs are read from the local rolling log file according to the timestamp range to fill in the missing parts, thereby obtaining a complete factory test log segment. The preferred rolling strategy for the local rolling log file is a maximum of 64MB per file. After exceeding the limit, a new file is automatically created and the 5 most recent historical files are retained.

[0064] The extracted plant test log fragments are serialized and stored in a structured format, so that each log record contains at least a timestamp, test item identifier, execution stage, measurement value, threshold, and result field.

[0065] Furthermore, the capacity of the ring buffer can be estimated using the following formula: ,in, This indicates the number of test items per DUT. This represents the average number of log entries for a single test item. This represents the redundancy factor, preferably between 1.5 and 3. This method allows for adaptive setting of the cache capacity based on the testing complexity of different products.

[0066] Preferably, it also includes building production testing environment metadata: Read the production testing tool version number, workstation number, operator employee number or automatic operation identifier, test fixture number, product model and DUT serial number; Summarize the list of failed test items in the current DUT testing process, and record the corresponding measurement value, judgment threshold, result type and trigger time for each failed test item; The trigger strategy mode, the actual firmware log collection channel used, the log collection start time, the collection completion time, and the collection exception information are added as additional context fields to the metadata; Metadata is written to the total metadata file and the factory test environment metadata file in the dual-path joint log package, respectively, to support multi-dimensional retrieval and analysis of failure cases in the cloud by model, workstation, test item, time period and collection method.

[0067] In one specific implementation, taking the intelligent audio amplifier type A as an example, a complete test process generates 47 log entries for each test item, each approximately 200 bytes, totaling about 9KB. The test start timestamp is 2025-01-08 10:32:00.000, and the failure trigger timestamp is 2025-01-08 10:32:17.483, with a time span of 17.483 seconds. 47 log entries are extracted from the memory circular buffer according to the timestamp range. An example of the content of the 12th log entry is as follows: {"ts":"2025-01-08 10:32:17.483","item":"AUD_L_THDN","stage":"result","value":3.82,"limit":1.00,"unit":"percent","result":"FAIL","message":"Left channel THD+N exceeds the standard, measured value 3.82%, upper limit of 1.00%"}.

[0068] S104: Associate and archive the firmware log set, factory test log fragments, and production test environment metadata to generate a dual-path joint log package that includes both firmware-side logs and factory test-side logs.

[0069] Preferably, the archiving and packaging includes archiving according to a preset directory structure, and the generation of the dual-path combined log package includes: Create a root directory named after the DUT serial number, failure timestamp, and product model; Create a firmware log directory and a factory test log directory in the root directory. The firmware log directory is used to store firmware log files from different sources and at different levels, while the factory test log directory is used to store factory test log fragments and production test environment metadata files. Generate a master metadata file in the root directory. The master metadata file should include at least the DUT serial number, product model, failure time, trigger mode, acquisition channel, summary of failed test items, and log file list. Firmware-side logs and factory test-side logs are written to their respective directories according to preset file naming rules, thereby forming a dual-channel joint log directory tree that can jointly reconstruct the test failure scenario.

[0070] In a preferred implementation, the root directory naming convention is: FailLog_{DUT serial number}{failure trigger timestamp}{product model}. The subdirectory structure includes: meta.json, the package metadata file containing all environment metadata fields; firmware_log / directory storing firmware-side log files such as dmesg.txt, logcat_recent.txt, alsa_status.txt, logcat_full.txt, net_dev.txt, and player.log; and factory_log / directory storing test_slice.json (factory test log fragment) and env_meta.json (factory test environment metadata file).

[0071] Furthermore, to avoid conflicts between files with the same name from different workstations or batches, the root directory naming rules can also include the workstation number and task sequence number, resulting in the following naming format: Wherein, SN represents the DUT serial number, TS represents the failure trigger timestamp, MODEL represents the product model, STATION represents the workstation number, and SEQ represents the task serial number.

[0072] Preferably, the archive packaging also includes performing compression and integrity verification on the archived union log directory tree: The federated log directory tree is compressed to generate a single compressed log package, and the hash checksum of the compressed log package is calculated and written to the total metadata file. Perform a format integrity check on the generated compressed log package. Use gzip compression level 6 to generate a single compressed log package with a compression ratio typically between 70% and 85%. Also check if the total metadata file exists in the compressed log package and if the preset required fields are complete. If the integrity check passes, the compressed log package will be used as the object to be uploaded. If the integrity check fails, the corrupted compressed log package is discarded, and the uncompressed union log directory tree is retained as the alternative upload object. At the same time, the reason for the compression failure and the local resource status information are recorded.

[0073] Furthermore, the compressed yield can be expressed as: ,in, Indicates the size of the directory tree before compression. Indicates the size of the compressed file. When... If the data is below the preset threshold, the original directory tree can be uploaded directly to reduce additional compression time overhead.

[0074] In one alternative implementation, the integrity check includes not only hash ratio verification but also file list consistency verification, i.e., verifying the number of files registered in the metadata file. Compared with the actual number of archived files Does it meet the following requirements: If the conditions are not met, the dual-path combined log packet is determined to be incomplete.

[0075] In one specific implementation, the original directory size of the Type A log package of the smart audio amplifier is approximately 258KB. After gzip compression (level 6), the resulting compressed file size is 41KB, with a compression ratio of approximately 84%, and the compression time is approximately 0.3 seconds. After the MD5 hash calculation of the compressed file is completed, it is written to meta.json. After the meta.json is updated, it is archived along with the compressed file.

[0076] For example, a production PC at a certain workstation had only 150MB of remaining disk space. During a compression process, the process was interrupted due to the disk running out of space, resulting in an incomplete .tar.gz file. The integrity verification step detected the truncation error using gzip -t, discarded the corrupted compressed file, and uploaded the original directory tree instead. Simultaneously, a disk space alert was triggered, prompting the operator to clean up the file promptly.

[0077] S105: In a background thread or independent task queue that does not block the main production test process, asynchronously upload the dual-path combined log packet to the cloud, and after successful upload, associate the permanent log identifier returned by the cloud with the failed test record of the current DUT.

[0078] Preferably, asynchronously uploading the dual-path combined log packet to the cloud includes performing cloud pre-registration and persistent uploading tasks: Before the formal upload, send a pre-registration request to the cloud service. The pre-registration request carries the DUT serial number, product model, failure time, workstation number, summary of failed test items, and size information of the object to be uploaded. Receive the upload task identifier, upload address, fragmentation parameters, and validity period information returned by the cloud; Write the upload task identifier, upload address, fragmentation parameters, local file path, task status, and completed fragmentation information to a local database or persistent task queue to build a recoverable upload task record. The background upload thread polls the local database or persistent task queue, and performs subsequent upload processing on tasks with a pending upload status, thus enabling the upload process to run independently outside of the main production test process.

[0079] Preferably, asynchronous upload also includes chunked upload and breakpoint resume mechanisms: When the size of the object to be uploaded exceeds the preset fragmentation threshold, it is divided into multiple upload fragments, and an upload request is initiated for each fragment separately; when the size of the object to be uploaded does not exceed the fragmentation threshold, it is uploaded as a whole packet. The preferred fragmentation threshold is 5MB.

[0080] During the upload process, the upload results of each segment, the set of completed segment numbers, the reasons for failure and the number of retries are recorded in real time, and the task status in the local database is updated synchronously.

[0081] When any fragment upload fails, a retry is performed according to the exponential backoff strategy. The specific backoff strategy is as follows: wait 5 seconds for the first retry, 15 seconds for the second, 45 seconds for the third, and so on, up to a maximum of 5 retries. Before retrying, query the cloud for the set of fragments that have been successfully received, and only re-upload the missing fragments, skipping the successfully received fragments.

[0082] If the number of retries reaches the preset limit and the task still fails, the task status will be updated to "failed and awaiting recovery," and local files and fragment completion records will be retained so that the task can be reactivated by a background scheduled task to continue uploading once the network is restored.

[0083] In one specific implementation, the compressed file size of the Type A log packet from the smart audio amplifier is 41KB, far smaller than the 5MB fragment size. Uploading it as a single fragment requires only one PUT request. However, during a large-scale firmware crash investigation of a Type C smart soundbar player, the collected firmware log packet, even after compression, still contained 23MB. It was split into five 5MB fragments and uploaded independently. The third fragment failed initially due to network jitter; only the third 5MB fragment was retransmitted instead of the entire 23MB, significantly saving retransmission bandwidth.

[0084] For example, a workstation experienced a network outage of approximately 40 minutes due to a switch failure. During this time, 23 upload tasks were in a pending state, and 2 tasks that were in progress failed due to the network interruption. The breakpoint resume mechanism recorded the completed segment numbers of these two tasks. After the network was restored, the upload automatically resumed from the breakpoint without having to start uploading from the beginning. Approximately 3 minutes after the upload resumed, both tasks were completed, and then the 23 pending tasks in the queue began uploading sequentially.

[0085] S106: Perform local cache management based on the upload result. After confirming that the cloud has completed receiving and storing the data, delete the corresponding local cache. If the upload fails, retain the local cache for subsequent re-upload.

[0086] Preferably, the upload confirmation, record association, and local cleanup include: After all parts of the file have been uploaded or the entire package has been uploaded, a merge confirmation or receipt confirmation request is sent to the cloud, and the cloud is polled to check whether file storage has been completed. The preferred polling interval is 10 seconds, with a maximum of 30 polls, or 5 minutes.

[0087] When the file size, file identifier, or verification result returned by the cloud matches the information of the object to be uploaded locally, the upload is considered successful, and the permanent log identifier and access address returned by the cloud are received.

[0088] Write the permanent log identifier back to the local task record and automatically associate the permanent log identifier with the failure test record or MES record corresponding to the current device DUT. For example, call the notification interface of the cloud MES platform to trigger the backend to associate the log identifier with the failure test record of the corresponding DUT, so that users can directly access the dual-path joint log package through a one-click link on the failure record page. Only after the permanent log identifier is successfully written and the cloud confirms the storage completion, the corresponding local compressed log package or the original federated log directory tree is deleted to free up workstation disk space; if the task is in a failed and pending recovery state, the local cache will continue to be retained for a preset retention period, and the cleanup will be performed after the retention period expires. The preferred retention period is 7 days.

[0089] In one specific implementation, after the intelligent audio amplifier's Type A log package is uploaded, the cloud merges it and returns a Log ID of FLOG-20250108-LINE2-SN0047. The MES platform's failure case details page automatically adds a log download link. When engineers search for failure records with this serial number on the MES platform, they directly click the link to download the log package. After decompression and viewing dmesg.txt, they discover that the audio driver reports an I2S clock configuration error during loading. The root cause is identified as a mismatch between the DAC chip model and the firmware driver due to a change in the production BOM. The root cause was located in approximately 20 minutes.

[0090] Analysis of the overall timing of the method and its impact on production line cycle time Taking the failure of a Type A intelligent audio amplifier test as an example, the estimated timing of each step is as follows: Step S1 event capture is less than 50ms; Step S2 firmware log collection at P1 level takes about 5 seconds, and continues in the background at P2 / P3 level for about 16 seconds; Step S3 factory test log extraction takes less than 0.5 seconds; Step S4 packaging and compression takes about 0.3 seconds, and integrity verification takes about 1 second; Step S5 cloud pre-registration takes about 1 second, and uploading takes about 1 minute (asynchronous background); Step S6 confirmation and cleanup takes about 10 seconds (asynchronous background). The actual impact on production line cycle time: The total foreground processing time for steps S1 to S4 is about 7 seconds, while production testing tools typically wait for operator confirmation or for the DUT to be removed after failure determination (about 10 to 30 seconds of manual operation time). The 7 seconds of foreground processing in this method is completely covered by the manual operation time. Steps S5 and S6 are executed asynchronously in the background, achieving zero additional impact on production line cycle time.

[0091] Second Embodiment Please see Figure 3 As shown, based on the same concept, the present invention also provides an automatic firmware log collection and cloud upload system triggered by production test failure, including a failure monitoring module 201, a firmware collection module 202, a factory test extraction module 203, a joint packaging module 204, an asynchronous upload module 205, and a cache management module 206. The failure monitoring module 201 is used to register a failure event monitoring mechanism in the test engine of the production testing tool, monitor failure events of the device under test (DUT) during the testing process, and generate a log collection task identifier corresponding to the current device DUT when a failure event that meets the triggering conditions is detected. Firmware acquisition module 202 is used to automatically start firmware-side log acquisition within a startup delay that meets timeliness constraints according to the log acquisition task identifier, so as to obtain a set of firmware logs that characterize the device firmware running status when the failure occurs. The factory test extraction module 203 is used to extract the factory test log fragments corresponding to the current test process of the current device DUT from the memory log cache maintained in real time by the production test tool according to the timestamp range, and obtain the production test environment metadata related to the device DUT. The joint packaging module 204 is used to associate and archive the firmware log set, factory test log fragments and production test environment metadata to generate a dual-path joint log package that contains both firmware-side logs and factory test-side logs. The asynchronous upload module 205 is used to asynchronously upload dual-path combined log packets to the cloud in a background thread or independent task queue without blocking the main production test process, and to associate the permanent log identifier returned by the cloud with the failed test record of the current DUT after successful upload. The cache management module 206 is used to perform local cache management based on the upload results. After confirming that the cloud has completed receiving and storing the data, it deletes the corresponding local cache. If the upload fails, it retains the local cache for subsequent re-upload.

[0092] Third Embodiment In this embodiment, a computer device is provided, including a memory and one or more processors. The memory stores computer code. When the computer code is executed by one or more processors, the one or more processors cause the one or more processors to perform the steps of the firmware log automatic collection and cloud upload method triggered by the production test failure in the first embodiment.

[0093] In some embodiments of this application, a computer-readable storage medium is also provided, wherein when the computer-readable instructions are executed by one or more processors, the one or more processors perform the steps of a firmware log automatic collection and cloud upload method triggered by a production test failure as described in any one of the first embodiments.

[0094] The computer device in this embodiment will be described in detail below from the perspective of hardware processing.

[0095] Please see Figure 4 As shown, the computer device includes a processor 300 and a memory 301. The memory 301 stores machine-executable instructions that can be executed by the processor 300. The processor 300 executes the machine-executable instructions to implement the above-described method for synchronizing state parameters across terminal devices.

[0096] further, Figure 4 The computer device shown also includes a bus 302 and a communication interface 303, with the processor 200, communication interface 303 and memory 301 connected via the bus 302.

[0097] The memory 301 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 303 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 302 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0098] The processor 300 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 300 or by instructions in software form. The processor 300 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 301. The processor 300 reads the information in memory 301 and, in conjunction with its hardware, completes the method steps of the aforementioned embodiments.

[0099] It is understandable that, regarding the aforementioned method for automatically collecting and uploading firmware logs to the cloud when a production test fails, if all of these are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer server or a network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this invention. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0100] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0101] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for automatically collecting and uploading firmware logs to the cloud when production testing fails, characterized in that, Includes the following steps: Register a failure event listening mechanism in the test engine of the production testing tool to listen for failure events of the device under test (DUT) during the testing process, and generate a log collection task identifier corresponding to the current device DUT when a failure event that meets the triggering conditions is detected. Based on the log collection task identifier, firmware-side log collection is automatically started within the start delay that meets the timeliness constraint, so as to obtain a set of firmware logs that characterize the device firmware running status when the failure occurs. Extract the factory test log fragments corresponding to the current test process of the current device DUT from the memory log cache maintained in real time by the production test tool, according to the timestamp range, and obtain the production test environment metadata related to the device DUT; The firmware log set, the factory test log fragment, and the production test environment metadata are associated, archived, and packaged to generate a dual-path joint log package that simultaneously contains firmware-side logs and factory test-side logs. In a background thread or independent task queue that does not block the main production test process, the dual-path joint log package is asynchronously uploaded to the cloud, and after successful upload, the permanent log identifier returned by the cloud is associated with the failed test record of the current DUT. Perform local cache management based on the uploaded results, and delete the corresponding local cache after confirming that the cloud has completed receiving and storage; If the upload fails, the local cache will be retained for subsequent re-upload.

2. The method for automatic collection and cloud upload of firmware logs triggered by production testing failure as described in claim 1, characterized in that, Failure event listening mechanism, including: When the production testing tool starts, the failure event listener is registered to the event bus or result distribution module of the test engine, and the failure event listener subscribes to at least one failure event type among single test item failure events and overall machine failure events; the failure event listener receives events asynchronously in an independent thread pool in the form of a callback function, without occupying the execution thread of the main test engine; After the test engine outputs the test results, it sends an event payload containing the test item name, measurement value, judgment result, judgment timestamp, DUT sequence number and test process identifier to the failure event listener. The failure event listener determines whether to trigger the log collection process according to a preset triggering strategy. The triggering strategy includes at least one of the following: any failure triggers the mode, a specified test item failure triggers the mode, and a comprehensive machine failure triggers the mode. When the triggering conditions are met, a log collection task identifier corresponding to the current failure event is generated and submitted to the background processing thread to decouple the log collection action from the foreground test execution thread.

3. The method for automatic collection and cloud upload of firmware logs triggered by production testing failure as described in claim 1, characterized in that, This also includes debouncing and deduplication for multiple failure events of the same DUT in the same test process: Use the combination of the DUT serial number and the unique identifier of the test process as the deduplication key; When the first failure event corresponding to the same deduplication key meets the triggering condition, a log collection task is created and the triggered status of the deduplication key is recorded. When a failure event corresponding to the same deduplication key is received again, the creation of new log collection tasks will be stopped. The newly added failure test item information will be appended to the factory test log fragment or failure summary information corresponding to the device DUT. Multiple failed test items occurring on the same device DUT in the same test process are merged into a single dual-path combined log package to reduce resource consumption caused by repeated collection and uploading.

4. The method for automatic collection and cloud upload of firmware logs triggered by production testing failure according to claim 1, characterized in that, Automatic firmware-side log collection includes detecting the connection status of the current device under test (DUT) based on preset communication channel priorities and selecting the collection channel, including: Check if the current device DUT has a USB debugging connection and if the ADB service is in a communicable state. If so, select the ADB channel as the first acquisition channel. If the ADB channel is unavailable, check if the debug serial port corresponding to the current device DUT is accessible. If it is accessible, send a preset log export command through the serial port and use the serial port as the second acquisition channel. If both the ADB channel and the serial port channel are unavailable, determine whether the current device DUT is connected to the local area network and supports remote login service. If so, execute the log export command through the SSH channel and use SSH as the third acquisition channel. The final selected acquisition channel will be written into the metadata of this joint log package to trace the source and availability of the acquisition channel.

5. The method for automatic collection and cloud upload of firmware logs triggered by production testing failure according to claim 4, characterized in that, Firmware log collection is performed in layers based on timeliness constraints and log priority, including: Within a preset startup delay threshold after a failure event is triggered, the first-level log collection is initiated first. The first-level log includes at least the kernel ring buffer log, the audio link status log, and the application layer log within a predetermined time window before the failure. The preset startup delay threshold does not exceed 2 seconds to ensure that the capture of critical logs is completed before the device may automatically restart or enter protection mode. After completing the first level of log collection, if the current total collection time does not exceed the preset total duration threshold, the second level of log collection will continue. The second level of log includes at least one of the following: complete application layer log, network interface status, memory status, and bus error count. If there is still remaining collection time and the current product model supports extended logs, continue collecting third-level logs, which include at least one of the following: player private logs, wireless communication protocol stack logs, or product-specific debugging logs. Set a command-level timeout for each data collection command. When any command times out or fails to execute, skip the command and record a failure flag, without terminating the collection of other log entries. This ensures that the most diagnostically valuable failure logs are preserved before the device may restart or enter protection mode.

6. The method for automatic collection and cloud upload of firmware logs triggered by production testing failure according to claim 1, characterized in that, The memory log cache is implemented using a circular buffer, extracting factory test log fragments from production testing tools, including: During the operation of the production testing tool, the test logs output by the test engine are continuously written to the local rolling log file, and a circular buffer is maintained in memory to store the most recent log records. After a failure event is triggered, the log records belonging to the current test process of the device DUT are filtered and extracted from the circular buffer, starting from the timestamp of the start of the current test process and ending from the timestamp of the failure event. When the log records in the circular buffer are insufficient to cover the entire time range of this test process, the corresponding logs are read from the local rolling log file according to the timestamp range to fill in the missing parts, thereby obtaining a complete factory test log segment. The extracted plant test log fragments are serialized and stored in a structured format, so that each log record contains at least a timestamp, test item identifier, execution stage, measurement value, threshold, and result field.

7. The method for automatic collection and cloud upload of firmware logs triggered by production testing failure as described in claim 6, characterized in that, This also includes building metadata for the production testing environment: Read the production testing tool version number, workstation number, operator employee number or automatic operation identifier, test fixture number, product model, and DUT serial number; Summarize the list of failed test items in the current DUT testing process, and record the corresponding measurement value, judgment threshold, result type and trigger time for each failed test item; The trigger strategy mode, the actual firmware log collection channel used, the log collection start time, the collection completion time, and the collection exception information are added as additional context fields to the metadata; The metadata is written to the total metadata file and the factory test environment metadata file in the dual-path joint log package, respectively, to support multi-dimensional retrieval and analysis of failure cases in the cloud by model, workstation, test item, time period and collection method.

8. The method for automatic collection and cloud upload of firmware logs triggered by production testing failure according to claim 1, characterized in that, Archive packaging includes archiving according to a preset directory structure. The generation of dual-path combined log packages includes: Create a root directory named after the DUT serial number, failure timestamp, and product model; A firmware log directory and a factory test log directory are created in the root directory. The firmware log directory is used to store firmware log files from different sources and at different levels. The factory test log directory is used to store factory test log fragments and production test environment metadata files. Generate a total metadata file in the root directory. The total metadata file shall include at least the DUT serial number, product model, failure time, trigger mode, acquisition channel, summary of failed test items, and log file list. Firmware-side logs and factory test-side logs are written to their respective directories according to preset file naming rules, thereby forming a dual-channel joint log directory tree that can jointly reconstruct the test failure scenario.

9. The method for automatic collection and cloud upload of firmware logs triggered by production testing failure according to claim 8, characterized in that, The archive packaging also includes performing compression and integrity checks on the archived union log directory tree: The federated log directory tree is compressed to generate a single compressed log package, and the hash check value of the compressed log package is calculated and written to the total metadata file. Perform a format integrity check on the generated compressed log package, and check whether the total metadata file exists in the compressed log package and whether the preset required fields are complete; If the integrity check passes, the compressed log package will be used as the object to be uploaded. If the integrity check fails, the corrupted compressed log package is discarded, and the uncompressed union log directory tree is retained as the alternative upload object. At the same time, the reason for the compression failure and the local resource status information are recorded.

10. The method for automatic collection and cloud upload of firmware logs triggered by production testing failure according to claim 1, characterized in that, Asynchronously uploading the dual-path combined log package to the cloud includes performing cloud pre-registration and persistent uploading tasks: Before the formal upload, a pre-registration request is sent to the cloud service. The pre-registration request carries the DUT serial number, product model, failure time, workstation number, summary of failed test items, and size information of the object to be uploaded. Receive the upload task identifier, upload address, fragmentation parameters, and validity period information returned by the cloud; The upload task identifier, upload address, fragmentation parameters, local file path, task status, and completed fragmentation information are written into a local database or persistent task queue to construct a recoverable upload task record. The background upload thread polls the local database or persistent task queue and performs subsequent upload processing on tasks with a pending upload status, thus enabling the upload process to run independently outside of the main production testing process.

11. The method for automatic collection and cloud upload of firmware logs triggered by production testing failure according to claim 10, characterized in that, Asynchronous upload also includes chunked upload and breakpoint resume mechanisms: When the size of the object to be uploaded exceeds the preset fragmentation threshold, it is divided into multiple upload fragments, and an upload request is sent to each fragment separately. When the number of objects to be uploaded does not exceed the fragmentation threshold, they are uploaded as a whole package. During the upload process, the upload results of each segment, the set of completed segment numbers, the reasons for failure and the number of retries are recorded in real time, and the task status in the local database is updated synchronously. When any fragment upload fails, a retry is performed according to the exponential backoff strategy. Before the retry, the set of successfully received fragments is queried from the cloud, and only the missing fragments are re-uploaded. If the number of retries reaches the preset limit and the task still fails, the task status will be updated to "failed and awaiting recovery," and local files and fragment completion records will be retained so that the task can be reactivated by a background scheduled task to continue uploading once the network is restored.

12. The method for automatic collection and cloud upload of firmware logs triggered by production testing failure according to claim 1, characterized in that, Upload confirmation, record association, and local cleanup include: After all segments or the entire package has been uploaded, a merge confirmation or receipt confirmation request is sent to the cloud, and the cloud is polled to check whether the file storage has been completed. When the file size, file identifier, or verification result returned by the cloud matches the information of the object to be uploaded locally, the upload is considered successful, and the permanent log identifier and access address returned by the cloud are received. The permanent log identifier is written back to the local task record, and the permanent log identifier is automatically associated with the failure test record or MES record corresponding to the current device DUT, so that the user can directly access the dual-path joint log packet on the failure record page; Only after the permanent log identifier is successfully written and the cloud confirms the storage completion will the corresponding local compressed log package or the original federated log directory tree be deleted. If the task is in a failed and pending recovery state, the local cache will continue to be retained for a preset retention period, and the cleanup will be performed after the retention period expires.

13. A system for automatically collecting and uploading firmware logs to the cloud when production testing fails, characterized in that, It includes a failure monitoring module, a firmware acquisition module, a factory test extraction module, a combined packaging module, an asynchronous upload module, and a cache management module; The failure monitoring module is used to register a failure event monitoring mechanism in the test engine of the production testing tool, to monitor failure events of the device under test (DUT) during the testing process, and to generate a log collection task identifier corresponding to the current device DUT when a failure event that meets the triggering conditions is detected. The firmware acquisition module is used to automatically start firmware-side log acquisition within a startup delay that meets the timeliness constraints according to the log acquisition task identifier, so as to obtain a set of firmware logs that characterize the device firmware running status when the failure occurs. The factory test extraction module is used to extract the factory test log fragments corresponding to the current test process of the current device DUT from the memory log cache maintained in real time by the production test tool, according to the timestamp range, and obtain the production test environment metadata related to the device DUT. The joint packaging module is used to associate, archive, and package the firmware log set, the factory test log fragment, and the production test environment metadata to generate a dual-path joint log package that simultaneously contains firmware-side logs and factory test-side logs. The asynchronous upload module is used to asynchronously upload the dual-path joint log package to the cloud in a background thread or independent task queue without blocking the main production test process, and to associate the permanent log identifier returned by the cloud with the failed test record of the current DUT after successful upload. The cache management module is used to perform local cache management based on the uploaded results, and delete the corresponding local cache after confirming that the cloud has completed receiving and storage; If the upload fails, the local cache will be retained for subsequent re-upload.

14. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for automatically collecting and uploading firmware logs to the cloud as described in any one of claims 1-12 when production testing fails.

15. A computer-readable storage medium, characterized in that, When the computer-readable instructions are executed by one or more processors, the one or more processors perform the steps of the firmware log automatic collection and cloud upload method triggered by production test failure as described in any one of claims 1 to 12.

Images