Methods, systems, media, and products for testing and monitoring motherboards based on ARM devices.

Abstract

A motherboard testing and monitoring method, system, medium, and product based on ARM devices are disclosed, relating to the testing field of structural components or devices not included in other categories. The method includes: responding to a test start command by closing the power-on pin of the device under test (DUT) to trigger its power-on; acquiring voltage data from the power indicator pin of the DUT to determine its power-on startup state; capturing real-time frame images of the display screen after the DUT enters and maintains the preset power-on startup state for a preset duration; performing feature matching calculations on the real-time frame images to determine the display content on the screen and generating a system fault record; generating a normal power-on record and triggering the DUT to power off when the operating system loading characteristics are met; and generating a single test completion record and triggering the next round of testing after the voltage data drops to the shutdown state. Implementing this application can improve the accuracy of fault type attribution for the entire power-on / off process of a computer motherboard.

Description

Technical Field

[0001] This application relates to the field of testing structural components or equipment not included in other categories, and in particular to a motherboard testing and monitoring method, system, medium and product based on ARM devices. Background Technology

[0002] During the research and development and production phases, computer motherboards must undergo rigorous power-on and power-off aging tests to verify the timing stability of their power management circuits, the reliability of components under frequent thermal shocks, and the boot robustness of the BIOS / operating system. This process requires the testing system to simulate real user key presses and accurately capture the changes in the motherboard's electrical characteristics and system loading status during the boot process, thereby eliminating defective products with potential problems such as power-on failures, system freezes, or difficulty in powering on before mass production.

[0003] In related technologies, motherboard power-on / off testing primarily employs WOL (Wake-on-LAN) in conjunction with scripts, or uses a programmable power strip in conjunction with the motherboard's power-on auto-boot function. Specifically, the test machine sends a magic packet over the network to trigger the motherboard under test to power on. After entering the operating system, the motherboard runs a preset script to record the boot time and executes a shutdown command. Alternatively, the programmable power strip is used to periodically cut off and restore AC power input, utilizing the AC Power Loss setting in the motherboard BIOS to achieve repeated restarts, and the success of the boot is confirmed by a simple Ping command or system log.

[0004] However, when the motherboard experiences a false freeze (i.e., the power indicator light stays on but the screen is frozen at the BIOS self-test or logo screen), the operating system has not been fully loaded, and the network scripts have not run or provided feedback. In related technologies, the test system may misjudge this as a shutdown or an infinite wait, making it difficult to accurately attribute the fault type. Summary of the Invention

[0005] This application provides a motherboard testing and monitoring method, system, medium, and product based on ARM devices, which can improve the accuracy of fault type attribution for the entire power-on and power-off process of a computer motherboard.

[0006] In a first aspect, this application provides a motherboard testing and monitoring method based on an ARM device, applied to an ARM device in an intelligent monitoring system. The intelligent monitoring system further includes a relay control module, a voltage acquisition module, and an image acquisition module. The relay control module is electrically connected to the power-on pin of the device under test (DUT). The voltage acquisition module is electrically connected to the power indicator pin of the DUT. The image acquisition module is used to acquire images from the display screen of the DUT. The method includes: responding to a test start command, closing the power-on pin of the DUT based on the relay control module to trigger the DUT to power on; acquiring voltage data from the power indicator pin of the DUT based on the voltage acquisition module, and then... The voltage change characteristics of the voltage data determine the power-on startup state of the device under test (DUT). After the DUT enters the preset power-on startup state and maintains it for a preset duration, the image acquisition module captures real-time frame images of the DUT's display screen. Feature matching calculations are performed on the real-time frame images to determine the display content of the display screen. When the display content matches the preset fault characteristics, a system fault record is generated. When the display content matches the operating system loading completion characteristics, a normal power-on record is generated, and a power-off command is sent to the DUT via the communication interface to trigger the DUT to power off. After the voltage data of the power indicator pin drops to the power-off state, a single test completion record is generated and the next round of testing is triggered.

[0007] In the above embodiments, the intelligent monitoring system simulates physical button operation through relays to trigger the device under test to power on, and monitors the level change of the power indicator pin through the voltage acquisition module to determine whether the device has been successfully powered on, and directly analyzes the output image content of the display screen; whether it is the BIOS self-test interface, the operating system loading logo, or fault screens such as blue screens and freezes, all can be captured and identified, solving the problem that the existing technology is difficult to effectively identify the false death fault before the operating system loads, and improving the accuracy of identification and attribution of various fault states in the entire power-on and power-off process.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the intelligent monitoring system further includes an audio acquisition module; after the step of closing the power-on pin of the device under test based on the relay control module in response to the test start command to trigger the power-on of the device under test, the method further includes: capturing the sound data stream of the device under test based on the audio acquisition module, and performing spectrum analysis on the sound data stream to extract fan sound data and buzzer sound data; determining fan speed change data based on the fan sound data to obtain the fan operating status; determining the motherboard self-test time point and motherboard self-test result based on the buzzer sound data; and generating a power-on judgment auxiliary result based on the fan operating status, the motherboard self-test time point, and the motherboard self-test result.

[0009] In the above embodiments, the changing trend of the fan sound can reflect the changes in motherboard load and the working status of the heat dissipation system, while the beeping mode of the buzzer is a direct encoding of the motherboard self-test results. The intelligent monitoring system combines these audio features with voltage and image information to construct a multimodal monitoring system. Even in extreme fault conditions where there is no video signal output (such as complete damage to the graphics card), it can still preliminarily determine that the fault occurred in the hardware self-test stage based on the buzzer alarm sound and the fan operation status, thus enhancing the robustness of fault location.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, after generating the power-on judgment auxiliary result based on the fan operating status, the motherboard self-test time point, and the motherboard self-test result, the method further includes: determining the motherboard operating status by combining the motherboard self-test time point, the motherboard self-test result, and the display content of the real-time frame image; matching the motherboard operating status with a preset fault knowledge base to determine the specific fault type and root cause of the fault of the device under test, in order to replace the system fault record.

[0011] In the above embodiments, after the intelligent monitoring system determines the motherboard's operating status based on the system's comprehensive buzzer self-test results, fan status, and screen image content, it can transform scattered and superficial monitoring data into in-depth fault diagnosis conclusions, thereby improving the diagnostic efficiency of the test.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, the intelligent monitoring system further includes a load acquisition module; after the step of closing the power-on pin of the device under test based on the relay control module to trigger the power-on of the device under test in response to the test start command, the method further includes: acquiring the operating power data of the device under test based on the load acquisition module; extracting the peak points, valley points, and slope change points from the operating power data as power features; determining the current self-test stage of the device under test based on the power features, the current time node, and a preset self-test stage timing table; and determining the sampling time node of the image acquisition module according to the current self-test stage.

[0013] In the above embodiments, the intelligent monitoring system analyzes the operating power data stream, extracts key feature points such as peak values, valley values, and slope changes, and compares them with a preset self-test phase timing table of a standard motherboard. This allows the system to infer in real time which specific self-test phase the device under test is currently in (e.g., memory self-test phase, PCIe device enumeration phase). For example, by increasing the sampling frequency at key time points when the BIOS logo or operating system loading screen is expected to appear, and decreasing the frequency during waiting periods when power consumption is stable, the system can optimize the configuration of image acquisition resources and improve the capture efficiency of key frames.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, the step of determining the current self-test stage of the device under test based on power characteristics, current time, and a preset self-test stage timing table specifically includes: acquiring voltage data of the power indicator pin, comparing the voltage data with a preset voltage threshold to obtain a voltage comparison result; calculating the power similarity between the current power curve and a preset standard power curve based on the waveform change trend of the power characteristics; determining the current self-test stage of the device under test based on the voltage comparison result and the power similarity, combined with the standard duration of each stage recorded in the self-test stage timing table; and recording the current time and corresponding power characteristics when the power similarity is lower than a preset similarity threshold to generate self-test fault information.

[0015] In the above embodiments, the intelligent monitoring system can assess the degree of matching between the current power consumption mode and the standard mode by calculating the tolerance for small timing differences between different devices. It can more accurately determine the current stage and record self-test fault information in advance, thus realizing early warning of potential hardware functional abnormalities or timing problems.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, before the step of controlling the closure of a relay connected to the power-on pin of the device under test (DUT) in response to a test start command to trigger the DUT to power on, the method further includes: determining the operating system type of the DUT; determining a corresponding system loading feature template based on the operating system type; determining display matching parameters and power-on / off timing based on the system loading feature template; detecting the interface type of the display output of the DUT; and adjusting the acquisition parameters of the image acquisition module based on the display matching parameters, power-on / off timing, and interface type.

[0017] In the above embodiments, the intelligent monitoring system can identify the type of operating system installed on the device under test and detect the display interface (such as HDMI, DisplayPort) used by the device under test. Based on the interface type, the display characteristics and timing of the target operating system, the system can adaptively adjust parameters such as resolution, frame rate and color space of the image acquisition module, ensuring the high accuracy and reliability of the testing method under different platforms and configurations.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, after determining the operating system type of the device under test and determining the corresponding system loading feature template based on the operating system type, the method further includes: reading the standard boot sequence corresponding to the operating system type from a preset operating system parameter library; when the data deviation between the actual boot sequence of the device under test and the standard boot sequence exceeds a preset deviation range, generating a timing anomaly alarm, and recording the actual boot sequence and data deviation as a timing anomaly event.

[0019] In the above embodiments, after determining the operating system type, the intelligent monitoring system loads a standard boot timing baseline. If the time deviation is found to exceed the preset tolerance range (for example, the boot time is extended by more than 20%), a timing anomaly alarm will be generated, providing important quantitative data support for evaluating the system compatibility and long-term operational stability of the motherboard.

[0020] In a second aspect, embodiments of this application provide an intelligent monitoring system, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, which includes computer instructions, and the one or more processors call the computer instructions to cause the intelligent monitoring system to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an intelligent monitoring system, cause the intelligent monitoring system to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on an intelligent monitoring system, cause the intelligent monitoring system to perform the method described in the first aspect and any possible implementation thereof.

[0023] Understandably, the intelligent monitoring system provided in the second aspect, the computer storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0025] 1. This method employs a technical solution that uses a relay control module to close the power-on pin of the device under test (DUT) to simulate physical power-on, a voltage acquisition module to monitor the power indicator pin to confirm power-on status, and an image acquisition module to capture real-time screen frame images for feature matching to determine the system loading status. Therefore, this method can directly observe the entire physical behavior of the motherboard from power-on to system loading, without relying on the network function of the DUT or the execution of internal operating system scripts. This method effectively solves the problem in existing technologies that use methods such as Wake-on-LAN or Ping commands, which make it difficult to accurately identify faults such as apparent freezes (e.g., stuck in the BIOS interface) or no display output that occur before the operating system is fully loaded. This enables accurate identification and attribution of various fault types throughout the entire power-on / off process of the computer motherboard, improving the reliability and fault coverage of aging tests.

[0026] 2. By employing a technical solution that adds an audio acquisition module to capture sound data streams and separates and extracts fan and buzzer sound data through spectrum analysis, this method can introduce an auditory information dimension for cross-validation and auxiliary diagnosis, in addition to visual information (screen display). Fan sound reflects hardware load and heat dissipation, while buzzer sound is a direct encoding of the motherboard's hardware self-test (POST) results. This method effectively solves the problem of lacking effective fault diagnosis methods in the early startup phase when there is no video output or abnormal video output. For example, when a graphics card failure causes a black screen, the system can still locate the fault source by decoding the buzzer alarm tone (such as one long and two short beeps), thereby realizing multimodal and deeper fault diagnosis capabilities, especially enhancing the early detection and location accuracy of purely hardware-level faults.

[0027] 3. Because this method employs a technique that determines the operating system type of the device under test before testing begins, and loads the corresponding system loading feature template from a preset template library to determine display matching parameters and power-on / off timing, and adjusts the image acquisition module parameters based on the detected display output interface type, its monitoring strategy is highly adaptive. Different operating systems (such as Windows and Linux) have vastly different boot screens and timings, and different display interfaces (such as HDMI and DP) may require different acquisition settings. This method effectively solves the problems of low image recognition rate and timing errors caused by parameter mismatch in traditional fixed-parameter testing schemes when facing diverse test objects. It thus achieves compatibility and universality with motherboards of different hardware and software configurations, ensuring the accuracy of image analysis and status judgment in complex testing environments. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating a motherboard testing and monitoring method based on an ARM device in an embodiment of this application.

[0029] Figure 2 This is another flowchart illustrating the motherboard testing and monitoring method based on ARM devices in this application embodiment;

[0030] Figure 3 This is a schematic diagram of the physical device structure of an intelligent monitoring system in the embodiments of this application. Detailed Implementation

[0031] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions a, an, the above, the, and this are intended to also include the plural expressions unless the context clearly indicates otherwise. It should also be understood that the terms used in this application refer to any or all possible combinations that include one or more of the listed items.

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

[0033] In the specific implementation scenarios of this application, the technical terms involved have specific meanings. Among them, "ARM device" refers to an embedded computing device equipped with an ARM architecture processor, serving as the monitoring entity. Its characteristics include low power consumption and high integration, making it suitable as an independent and reliable test controller. The relay control module is an electrically controlled switch that controls the relay coil's on / off state via low-voltage signals output from the GPIO (General Purpose Input / Output) pins of the ARM device, thereby closing or opening its mechanical contacts to simulate a human hand pressing a power switch on the motherboard. The voltage acquisition module is typically a circuit containing an ADC (Analog-to-Digital Converter) used to accurately measure and quantify the analog voltage value on the motherboard's power indicator LED pin, thereby determining whether it is lit (high level) or off (low level). The image acquisition module is a device capable of capturing video signals, such as an HDMI capture card, which converts the display output of the motherboard under test into a digital image data stream. Feature matching computation is an image processing algorithm that extracts key features of real-time frame images (such as color histograms, SIFT feature points, and template contours) and compares them with pre-stored preset fault features (such as image templates of blue screen error codes) or operating system loading completion features (such as image templates of desktops or login interfaces) to calculate similarity in order to identify the current screen content.

[0034] The following describes the process of the method provided in this implementation. Please refer to [link / reference]. Figure 1This is a flowchart illustrating a motherboard testing and monitoring method based on an ARM device in an embodiment of this application.

[0035] S101. In response to the test start command, the power-on pin of the device under test is closed based on the relay control module to trigger the device under test to power on.

[0036] Among them, the test start command refers to the signal issued by the host computer or the preset test scheduling program to start a round of power-on and power-off tests; the relay control module refers to the device that controls the mechanical switch to turn on and off through electrical signals; the power-on pin refers to the two pins on the motherboard used to connect to the power button of the chassis. Shorting these two pins can trigger the power-on sequence of the ATX power supply.

[0037] Specifically, when the intelligent monitoring system receives the test start command, its internal ARM processor outputs a high-level or low-level signal to the relay control module through a GPIO pin. This signal drives the relay coil, causing its contacts to close. This contact is connected to the power-on pin of the motherboard under test (usually marked as POWER SW or PWR_BTN) via a wire. The closing of the contact simulates the action of a user pressing a power button. After a preset short duration (e.g., 500 milliseconds), the GPIO signal recovers, the relay contacts open, and a single press-to-power-on trigger is completed.

[0038] In some embodiments, this step can be triggered and controlled in several ways: Optionally, the intelligent monitoring system can receive remote instructions from the central test management server via a network interface. These instructions contain the identifier of the device under test (DUT) and a power-on operation code. After system parsing, the relay is closed. Optionally, the intelligent monitoring system can have a built-in timed task scheduler that generates a test start instruction based on a preset aging test strategy (e.g., powering on and off every 10 minutes) and drives the relay module. It is understood that other methods can also be used to implement this step, such as manual triggering via a physical button connected to the ARM device; this is not limited here.

[0039] In some embodiments, the device under test (DUT) may be frozen or not fully powered off due to a previous test anomaly. To address this, the intelligent monitoring system will perform a forced shutdown operation before executing the power-on command. Specifically, this operation involves controlling a relay to close the power-on pin and holding it for a relatively long preset duration (e.g., 5-10 seconds), simulating a long press of the power button to forcibly cut off the power, ensuring the DUT is completely powered off and providing a definite initial condition for the next round of testing.

[0040] S102. The voltage data of the power indicator pin of the device under test is collected based on the voltage acquisition module, and the power-on start-up status of the device under test is determined based on the voltage change characteristics of the voltage data.

[0041] Among them, the power indicator pin refers to the pin on the motherboard used to connect to the power LED of the chassis. When the motherboard is powered on, this pin will output a stable voltage (e.g., 3.3V or 5V); voltage data refers to the sequence of voltage values ​​continuously sampled by the voltage acquisition module; power-on startup status refers to the state in which the device is powered on and running, as determined by the voltage data.

[0042] Specifically, the probe of the voltage acquisition module of the intelligent monitoring system is connected to the positive terminal of the power indicator pin on the motherboard under test. After power-on is triggered, the module continuously acquires the voltage value of this pin at a certain frequency (e.g., 10Hz). The intelligent monitoring system analyzes the acquired voltage data stream. When the voltage value jumps from a low level close to 0V to a stable high level higher than a preset voltage threshold (e.g., 2.5V), the system determines that the device under test has successfully responded to the power-on command and entered the power-on startup state.

[0043] In some embodiments, the state determination of this step can be implemented in several ways: Optionally, the system can use a simple threshold comparison method, that is, if the voltage value is continuously higher than the threshold for more than a short debouncing time (e.g., 100 milliseconds), it is confirmed that the power is on; Optionally, the system can analyze the rising edge slope of the voltage waveform, as a steep rising edge is more likely to confirm a valid transition of the digital signal rather than noise interference. It is understood that other methods can also be used to implement this step, such as monitoring the pulse voltage changes in the standby state (breathing light mode) to more finely determine the power supply state, which is not limited here.

[0044] S103. After the device under test enters the preset power-on startup state and maintains it for a preset time, the real-time frame image of the display screen of the device under test is captured based on the image acquisition module.

[0045] The preset power-on startup state is the state determined in step S102; the preset duration is an empirical value used to wait for the motherboard to complete the initial initialization and start outputting video signals; the image acquisition module refers to the video acquisition card connected to the display output interface (such as HDMI) of the device under test.

[0046] Specifically, after confirming the device is powered on in step S102, the intelligent monitoring system starts a timer. The duration of this timer is set to a reasonable estimated value, such as 3 seconds, which is usually sufficient for the motherboard to complete the basic power-on self-test and light up the screen. After the timer expires, the intelligent monitoring system activates the image acquisition module and begins to continuously capture frame after frame of digital image data from the display output port of the device under test at a set frame rate (e.g., 5fps), and stores these real-time frame images in a memory buffer for subsequent analysis.

[0047] In some embodiments, image capture in this step can be implemented in several ways: Optionally, the image acquisition module can be configured in continuous capture mode, whereby the system begins reading frame data from the data stream after a preset duration; alternatively, the system can employ triggered capture, sending one or more capture commands to the image acquisition module only after the preset duration has elapsed, in order to obtain a snapshot at a specific point in time. It is understood that this step can also be implemented in other ways, such as dynamically adjusting the capture timing based on power changes, which is not limited here.

[0048] S104. Perform feature matching calculations on the real-time frame image to determine the content to be displayed on the screen.

[0049] Among them, real-time frame image refers to the image data captured in step S103; feature matching calculation is an image recognition technology used to compare the similarity of two images; display content refers to the semantic description of the screen after matching calculation, such as BIOS setup interface, Windows logo, blue screen error.

[0050] Specifically, the intelligent monitoring system retrieves a real-time image frame from the memory buffer and then loads features from a pre-stored feature template library of standard images. These templates include various BIOS interfaces, operating system loading logos, login screens, and known fault screens (such as BSOD and kernel panic). The system uses algorithms such as template matching, SIFT feature point comparison, or deep learning-based image classification models to calculate the similarity score between the real-time frame image and each template. If the template with the highest score exceeds a preset matching threshold, the display content represented by that template is determined as the current screen display content.

[0051] In some embodiments, feature matching in this step can be implemented in several ways: Optionally, for interfaces with fixed content (such as the BIOS logo), a template matching algorithm based on pixel grayscale values ​​can be used, which is computationally fast; alternatively, for interfaces with variable content (such as a blue screen containing error codes), OCR (Optical Character Recognition) technology can be used to extract text, or local feature descriptors such as SIFT / ORB can be used for matching to enhance robustness to changes in position and size. It is understood that other methods can also be used to implement this step, such as training a CNN classification network to directly perform end-to-end classification of frame images; this is not limited here.

[0052] S105. When the displayed content matches the preset fault characteristics, generate a system fault record.

[0053] Among them, preset fault characteristics refer to predefined screen display templates that represent device malfunctions, such as blue screen images containing specific error codes or command-line prompts indicating GRUB boot failure. The system fault log is a structured log entry containing information such as fault time and fault type.

[0054] Specifically, when the feature matching calculation result in step S104 shows that the content displayed on the current screen highly matches a template in the preset fault feature library (e.g., Windows Blue Screen 0x0000007B), the intelligent monitoring system determines that the device under test has experienced a fault during startup. The system then generates a system fault record, which details the timestamp of the fault occurrence, the specific fault type identified (based on the matched template name), and the test number of the current round, and stores the record in the test log database.

[0055] In some embodiments, fault recording in this step can be implemented in several ways: optionally, the system only records the fault type code and time; optionally, in addition to recording the fault type, the system also saves the fault image frame that led to the judgment as direct evidence of the fault, facilitating subsequent manual analysis. It is understood that other methods can also be used to implement this step, such as reporting the fault information to the central monitoring platform in real time via the network and triggering an alarm; this is not limited here.

[0056] In some embodiments, the screen may freeze on an atypical fault scene that is not included in the preset fault feature library. To address this, the intelligent monitoring system introduces a still screen detection mechanism. The system compares multiple consecutive frames (e.g., 5 frames spaced 1 second apart). If the content of these images is highly consistent (e.g., the inter-frame difference is below a threshold), and the scene neither meets the characteristics of successful loading nor is it in the known fault library, the system determines it as an unknown interface freeze, generates a corresponding fault record, and saves the image sample of this unknown scene for subsequent analysis and expansion of the fault library.

[0057] S106. When the displayed content matches the characteristics of the operating system loading completion, a normal boot record is generated, and a shutdown command is sent to the device under test through the communication interface to trigger the shutdown of the device under test.

[0058] Among them, the operating system loading completion characteristic refers to the screen display content that indicates the system is ready and can accept user interaction, such as the Windows desktop, Linux login interface, etc.; the communication interface can be USB, serial port or network interface; the shutdown command is a command that the operating system of the device under test can recognize and execute.

[0059] Specifically, when the feature matching calculation result in step S104 shows a high degree of match between the current screen display content and the operating system's loaded feature template (such as the Windows desktop background and taskbar), the intelligent monitoring system determines that the boot was successful. The system generates a normal boot record, including information such as boot time. Subsequently, the system sends a shutdown command to the device under test through a preset communication interface. For example, if connected via USB, it can simulate USB keyboard input by pressing Win+X and then UU to shut down; if connected via network, it can send a remote command such as shutdown -s -t 0.

[0060] In some embodiments, the shutdown trigger for this step can be implemented in several ways: Optionally, a lightweight agent program can be pre-installed on the device under test, and the intelligent monitoring system can send a custom shutdown API call to the agent over the network; alternatively, if the device under test supports IPMI (Intelligent Platform Management Interface), a standard IPMI shutdown command can be sent over the network. It is understood that other methods can also be used to implement this step, such as triggering a restart by shorting the reset pin on the motherboard using a relay module; this is not limited here.

[0061] S107. After the voltage data on the power indicator pin drops to the power-off state, generate a single test completion record and trigger the next round of testing.

[0062] Among them, the power off state refers to the voltage of the power indicator pin dropping from a high level to a low level close to 0V, indicating that the motherboard has been powered off; the single test completion record is a summary of the entire power-on and power-off cycle; triggering the next round of testing means that the system returns to the execution step S101 after a short interval.

[0063] Specifically, after sending the shutdown command, the intelligent monitoring system continuously monitors the voltage of the power indicator pin through the voltage acquisition module. When the voltage value drops from a stable high level and falls below the preset shutdown voltage threshold (e.g., 0.5V), the system determines that the device under test has been completely shut down. At this point, the system generates a record of a single test completion and summarizes the results of this round of testing (normal startup / fault type). After waiting for a preset heat dissipation interval (e.g., 30 seconds), the system loops and executes the next round of the test process.

[0064] In some embodiments, the cyclical triggering of this step can be implemented in several ways: Optionally, the system executes the test in a main loop, and immediately proceeds to the next iteration upon completion; alternatively, the system treats a single test as a function call, and an external test scheduler decides whether to initiate the next call based on the total number of tests or the total test duration requirements. It is understood that other methods can also be used to implement this step, such as synchronizing the test plan with a central server before each loop, which is not limited here.

[0065] In some embodiments, after sending a shutdown command, the device under test may not respond, and the power indicator voltage may not drop. In response, the intelligent monitoring system will start a shutdown timeout timer. If the voltage does not drop within a preset timeout period (e.g., 2 minutes), the system will determine that the shutdown has failed or the system is frozen, and generate a corresponding fault record. Subsequently, the system will execute the forced shutdown operation described in step S101 to ensure that the device is powered off, thereby allowing the next round of testing to continue and preventing the testing process from being blocked.

[0066] To address early hardware failures or performance anomalies that are difficult to diagnose using only voltage and image information, the following embodiments introduce the collection and analysis of multi-dimensional information such as audio and power, constructing a more comprehensive and in-depth monitoring system aimed at improving the accuracy of fault location and early warning capabilities.

[0067] The following provides a more detailed description of the process of the method provided in this implementation. Please refer to [link / reference]. Figure 2 This is another flowchart illustrating the motherboard testing and monitoring method based on ARM devices in this application embodiment.

[0068] S201. In response to the test start command, the power-on pin of the device under test is closed based on the relay control module to trigger the device under test to power on.

[0069] Refer to step S101, which will not be repeated here.

[0070] In some embodiments, the intelligent monitoring system incorporates power consumption analysis. Specifically, the intelligent monitoring system acquires the operating power data of the device under test based on the load acquisition module; extracts the peak points, valley points, and slope change points from the operating power data as power characteristics; determines the current self-test stage of the device under test based on the power characteristics, the current time node, and a preset self-test stage timing table; and determines the sampling time node of the image acquisition module according to the current self-test stage.

[0071] Among them, the load acquisition module refers to a smart socket or dedicated power meter that can measure AC or DC power consumption; the operating power data is a real-time power consumption value sequence of the device under test throughout the entire power-on process; the self-test phase timing table is a preset reference data that describes the typical start and end times and power consumption range of each hardware initialization phase (such as CPU initialization, memory initialization, and hard disk initialization) of a standard device during power-on.

[0072] Specifically, the intelligent monitoring system records the instantaneous power of the device under test at a high frequency (e.g., 100Hz) through a load acquisition module. The system smooths the acquired power data and applies algorithms to detect key feature points, such as sudden power spikes (peak points, possibly corresponding to the CPU starting full-speed operation), brief drops (valley points, possibly corresponding to a device completing initialization and entering standby), and inflection points in the rate of change (slope change points). The system compares the timestamps of these power feature points with a preset self-test phase timing table to infer which self-test phase the motherboard is most likely in. For example, a significant power spike occurring 2 seconds after power-on may correspond to the start of the memory self-test phase. Based on this judgment, the system can intelligently decide when to initiate high-frequency image acquisition; for example, when it infers that the display controller initialization phase is about to begin, it increases the image acquisition frame rate to ensure that the first valid frame is captured.

[0073] To further refine the power consumption-based stage determination, in some embodiments, the stage determination can be implemented in several ways: Optionally, a Dynamic Time Warping (DTW) algorithm can be used to calculate the distance between the real-time power curve and the standard power curve segments of each stage in the standard time series table; the stage with the smallest distance is the current stage. Optionally, a Hidden Markov Model (HMM) can be trained, where the hidden states correspond to each self-check stage, the observations are power features, and the most likely self-check stage sequence can be decoded using the Viterbi algorithm. It is understood that other methods can also be used to implement this step, such as fusing power data with audio data for analysis to improve the accuracy of stage division; this is not limited here.

[0074] In some embodiments, there may be significant differences in power consumption curves between different motherboard models. To address this, the intelligent monitoring system supports a baseline learning mode. Before formally testing a new motherboard model, a normal power-on / off process can be run several times. The system records its power consumption curve, the time taken for each stage, and other information, generating a dedicated self-test timing table and standard power consumption curve for that model. In subsequent batch tests, the system uses this dedicated baseline for comparison, thereby eliminating judgment errors caused by hardware differences.

[0075] In some embodiments, the intelligent monitoring system performs more refined power analysis. Specifically, the system acquires voltage data from the power indicator pin, compares the voltage data with a preset voltage threshold to obtain a voltage comparison result, calculates the power similarity between the current power curve and a preset standard power curve based on the waveform change trend of the power characteristics, determines the current self-test stage of the device under test based on the voltage comparison result and power similarity, combined with the standard duration of each stage recorded in the self-test stage timing table, and records the current time and corresponding power characteristics when the power similarity is lower than the preset similarity threshold to generate self-test fault information.

[0076] Among them, power similarity is an indicator that quantifies the degree of shape similarity between the current real-time power curve and the standard template curve; self-check fault information is an early warning signal generated based on power anomalies.

[0077] Specifically, this step deepens the aforementioned power analysis. First, the voltage comparison results confirm that the device is indeed powered on, which is a prerequisite for effective power analysis. Then, the system not only searches for isolated feature points but also treats the power curve over a period of time as a whole, calculating its similarity to a standard power curve template (e.g., by calculating the cross-correlation coefficient or DTW distance between the two normalized curves). The system integrates the voltage comparison results (confirming online status), power similarity (waveform matching), and time constraints in the self-test timing table to make a more robust judgment on the current self-test stage. Crucially, if the power similarity calculated by the system at any stage falls below a set threshold (e.g., 0.8), it immediately generates a self-test fault message, recording the current time, the abnormal power value, and the deviation from the standard curve, even if the screen and buzzer have not yet shown any abnormalities.

[0078] To quantitatively evaluate the motherboard's boot performance, in some embodiments, the similarity calculation for this step can be implemented in several ways: Optionally, the two power curves can be resampled to make their lengths consistent, and then their Pearson correlation coefficient can be calculated; alternatively, the DTW algorithm can be used, which can find the optimal nonlinear alignment path between two curves of unequal length, and its path cost can be used as a measure of dissimilarity, exhibiting good robustness to scaling on the time axis. It is understood that other methods can also be used to implement this step, such as extracting the Fourier descriptors or wavelet transform coefficients of the curves for comparison, which is not limited here.

[0079] In some embodiments, fluctuations in the power adapter or power supply environment may cause the overall power consumption baseline to drift. To address this, the intelligent monitoring system preprocesses the power data before calculating similarity. Preprocessing includes subtracting a moving average to eliminate low-frequency drift, or normalizing the power values ​​(e.g., scaling them to the [0, 1] range), making the comparison focus on the shape of power changes rather than absolute values, thereby reducing interference from the external power supply environment in fault diagnosis.

[0080] S202. The audio data stream of the device under test is captured by the audio acquisition module, and the spectrum analysis of the audio data stream is performed to extract the fan sound data and the buzzer sound data.

[0081] The audio acquisition module refers to the microphone and its associated audio codec circuit; the audio data stream refers to the original audio signal captured and digitized by the microphone; and spectrum analysis is a signal processing technique, such as the Fast Fourier Transform (FFT), used to convert time-domain signals to the frequency domain and analyze their frequency components.

[0082] Specifically, upon powering on, the intelligent monitoring system activates the audio acquisition module, placing it near the device under test to continuously record ambient sounds. The system processes the acquired audio data stream in frames and applies an FFT algorithm to each frame to obtain its spectrogram. Since fan noise is typically concentrated in the low-frequency broadband noise band, while the motherboard buzzer sound is a single tone or combination of tones at specific frequencies (such as 2kHz-4kHz), the system can effectively separate these two sound signals by setting different frequency band filters on the spectrogram, extracting the energy distribution of the fan sound and the fundamental frequency and harmonics of the buzzer sound respectively.

[0083] In some embodiments, environmental noise interference may lead to inaccurate sound extraction. To address this, the intelligent monitoring system performs an environmental noise learning phase before testing begins. The system first collects background noise data from the device under test (DUT) when it is powered off, and establishes a noise spectrum model. In subsequent tests, the system subtracts this background noise model from the collected real-time spectrum, thereby highlighting the fan and buzzer sounds generated by the DUT, improving the signal-to-noise ratio and extraction accuracy.

[0084] S203. Determine the fan speed change data based on the fan sound data to obtain the fan operating status.

[0085] Among them, fan sound data refers to the spectrum information related to the fan extracted in step S202; fan speed change data refers to the relative change trend of fan speed estimated by analyzing sound characteristics; fan operating status is a qualitative description of the fan's working condition, such as not rotating, low speed, high speed, or abnormal speed.

[0086] Specifically, the intelligent monitoring system analyzes and extracts changes in the energy (power spectral density) of the fan sound data. Generally, the higher the fan speed, the greater the noise energy produced, and the dominant frequency shifts towards higher frequencies. By tracking changes in sound energy within a specific frequency band, the system can indirectly deduce the relative trend of fan speed changes. For example, a sudden surge in energy at startup indicates fan activation, while subsequent stable or periodic fluctuations in energy correspond to speed adjustments under the BIOS temperature control strategy. Based on these patterns of change, the system determines the fan's operating status.

[0087] In some embodiments, the state determination in this step can be achieved in several ways: Optionally, a mapping table between sound energy and actual rotational speed (obtained through pre-calibration) can be established for quantitative estimation; alternatively, a machine learning method can be used to train a classifier, taking the Mel-frequency cepstral coefficient (MFCC) features of the fan sound as input, and directly outputting state classifications such as normal, stopped, and abnormal noise. It is understood that other methods can also be used to achieve this step, such as analyzing the beat characteristics of the sound to detect mechanical faults such as bearing damage, which is not limited here.

[0088] In some embodiments, the device under test may employ a fanless passive cooling design. In response, when analyzing fan noise data, if the intelligent monitoring system does not detect any signals matching fan noise characteristics throughout the entire power-on process, it will not misjudge it as a fan malfunction. Instead, it will combine the hardware configuration information of the device under test (which can be pre-inputted) to mark it as a fanless device and skip this check.

[0089] S204. Determine the motherboard self-test timing and results based on the buzzer sound data.

[0090] Among them, the buzzer sound data refers to the buzzer signal extracted in step S202; the motherboard self-test time point refers to the start time of detecting the buzzer sound; the motherboard self-test result is the POST error code obtained by decoding the combination of the length and number of buzzer sounds.

[0091] Specifically, the intelligent monitoring system performs time-domain analysis on the extracted buzzer sound data to detect the presence of pulses with energy higher than the background noise. The system records the start time, duration, and interval of each pulse. Based on the pulse duration, it categorizes them as long or short beeps. Then, the system matches consecutive long and short beep sequences (e.g., one long beep followed by two short beeps) against a preset BIOS / UEFI buzzer code standard library (such as the encoding rules of AMI, Award, and Phoenix BIOS). Once a match is successful, the system determines the motherboard's self-test result (e.g., a graphics card error) and records the time of the first beep as the self-test time point.

[0092] In some embodiments, this decoding step can be implemented in several ways: optionally, a simple state machine can be used to parse the long and short beep sequences; alternatively, the sound pulse sequence can be converted into a string (e.g., LSS represents one long and two short beeps) and then looked up in a buzzer code dictionary. It is understood that other methods can also be used to implement this step; for example, for diagnostic cards that do not emit sound, the POST code can be read through other interfaces, which is not limited here.

[0093] In some embodiments, different motherboard manufacturers may use non-standard buzzer codes. To address this, the intelligent monitoring system supports user-defined buzzer code libraries. Testers can add or modify unique buzzer codes and their corresponding fault meanings for specific motherboard models or BIOS versions, based on the motherboard's technical manual. During testing, the system prioritizes loading the custom library that matches the device under test model, improving diagnostic accuracy and flexibility.

[0094] S205. Generate power-on judgment auxiliary results based on fan operation status, motherboard self-test timing, and motherboard self-test results.

[0095] Among them, the power-on judgment auxiliary result is an intermediate report that integrates audio analysis information, used to supplement and verify the judgments of other monitoring dimensions.

[0096] Specifically, the intelligent monitoring system integrates the results obtained in steps S203 and S204. For example, the system might generate the following auxiliary result: T+1.5s: Fan starts, speed is normal. T+3.2s: One long and three short beep codes are detected, matching result is memory error. This auxiliary result provides crucial diagnostic information before the video signal appears or in the case of missing video signal. It can independently point out hardware-level problems or provide corroborating evidence of whether the motherboard is actually powered on and working (for example, the presence of fan noise but no voltage or video may mean that some circuitry on the motherboard is working, but the core power supply or display is abnormal).

[0097] In some embodiments, the results of this step can be generated in several ways: optionally, a structured JSON or XML object containing timestamps and content of each audio analysis result can be generated; alternatively, a text log describing the results in natural language can be generated for easy human reading and understanding. It is understood that other methods can also be used to implement this step, such as presenting the results graphically on a monitoring interface, like event markers on a timeline; this is not limited here.

[0098] To further improve the accuracy of fault diagnosis, in some embodiments, the intelligent monitoring system performs more in-depth fault analysis. That is, the intelligent monitoring system combines the motherboard self-test time point, the motherboard self-test result and the display content of real-time frame images to determine the motherboard operating status; and matches the motherboard operating status with a preset fault knowledge base to determine the specific fault type and root cause of the device under test, in order to replace the system fault record.

[0099] Among them, the motherboard operating status is a composite status description that integrates multi-source information (audio, video); the preset fault knowledge base is a database that stores the phenomenon-cause mapping relationship, which associates the monitored data patterns with specific hardware or software problems.

[0100] Specifically, the intelligent monitoring system no longer views each fault phenomenon in isolation. For example, when step S204 determines that the motherboard self-test result is a graphics card error (via the beep code), and step S211 determines that the display content is no signal, the system integrates these two pieces of information into a composite motherboard operating state: hardware self-test failed - graphics card error, no video output. Then, the system uses this composite state as an index to search in a preset fault knowledge base. The knowledge base may contain a rule: IF (beep code == graphics card error AND video state == no signal) THEN root cause of the fault = physical damage or poor contact of the graphics card OR PCIe slot failure. Based on this, the system generates a more specific and instructive fault diagnosis report, rather than simply recording the system fault.

[0101] In some embodiments, the root cause inference step can be implemented in several ways: optionally, a rule-based expert system can be used, in which experienced engineers pre-write a large number of IF-THEN rules; optionally, case-based reasoning can be used, where the system searches for historical failure cases in a knowledge base that are most similar to the current failure phenomenon, and uses the recorded root causes as a reference for this diagnosis. It is understood that other methods can also be used to implement this step, such as using Bayesian network probabilistic graphical models to infer the most likely cause of the failure, which is not limited here.

[0102] In some embodiments, there may be a situation where a combination of fault phenomena has no corresponding entry in the knowledge base. In this case, the intelligent monitoring system will record this new, unknown combination of phenomena and mark it as a new fault mode to be analyzed. Simultaneously, the system will save all related raw monitoring data (video clips, audio clips, power curves, etc.). This data can be used by test engineers for offline analysis. Once the root cause is determined, it can be added to the knowledge base as new knowledge, enabling the system to continuously learn and evolve.

[0103] S206. Determine the operating system type of the device under test, and determine the corresponding system loading feature template based on the operating system type.

[0104] Among them, the operating system type refers to the specific operating system and its version installed on the device under test, such as Windows 11, Ubuntu 22.04 or the domestic operating system UOS; the system loading feature template is a pre-configured data structure that encapsulates a series of key features of a specific operating system during startup and operation. The template may include image samples of the startup logo, image features of the desktop or login interface, timestamps of each stage of the standard startup process, and parameters for image matching, etc.

[0105] Specifically, before officially starting the cyclic testing, the intelligent monitoring system needs to perform this pre-configuration step to clarify the monitoring target. The system first needs to determine the type of operating system running on the motherboard under test. This information can be obtained in several ways, such as by the tester manually specifying it through the configuration interface before the test begins, or by the system automatically identifying it through a preliminary probing boot. After determining the operating system type, the intelligent monitoring system retrieves and loads a system loading feature template that perfectly matches the operating system version from its internal template library. This template provides a benchmark and basis for subsequent image recognition, timing analysis, and status judgment.

[0106] In some embodiments, template determination for this step can be achieved in several ways: Optionally, a manual configuration method can be used, whereby the tester selects the operating system type of the device under test from a preset list of operating systems through a graphical user interface when starting the test task, and the system directly loads the corresponding feature template file based on this selection; alternatively, an automatic identification method can be used, whereby the system captures keyframe images of the device under test during its startup process when it starts up for the first time, and identifies the GRUB menu, Windows logo, or login screen text appearing on the screen through an image classification model or optical character recognition (OCR) technology, thereby inferring the operating system type and automatically loading the corresponding template. It is understood that other methods can also be used to achieve this step, such as querying system information through some out-of-band management channel established with the device under test; this is not limited here.

[0107] In some embodiments, the device under test may have a customized or non-mainstream operating system installed, resulting in a lack of corresponding templates in the template library. To address this, the intelligent monitoring system provides a template learning or template creation mode. In this mode, the system guides the tester through a complete manual boot process. During this process, the tester can manually trigger snapshots at key points (e.g., when the BIOS logo appears, the operating system logo appears, or the desktop is reached). The system saves these snapshot images and their corresponding timestamps, allowing the tester to name these states, thereby dynamically generating a new system loading feature template and storing it in the template library for later use.

[0108] S207. Determine the display matching parameters and power-on / off sequence based on the system loading feature template.

[0109] Among them, the system loading feature template is the data structure determined in step S206; the display matching parameters refer to the specific configuration values ​​used for subsequent image feature matching calculations, such as the similarity threshold required for template matching, the image region of interest (ROI) used for feature extraction, etc.; the power-on / off sequence is a set of predefined reference data describing the expected occurrence time of each key event in the standard power-on / off process, such as the expected time from power-on to the appearance of the BIOS screen, and the standard time from operating system loading to entering the desktop.

[0110] Specifically, after loading the correct feature template in step S206, the intelligent monitoring system parses the template file and extracts the parameters used to configure its internal algorithm modules. For example, the matching parameters defined for the Windows 11 desktop in the template might include: a low global similarity threshold to accommodate different wallpapers, but a high similarity threshold for the taskbar area; the power-on / off timing defined in the template might include: T_PowerOn_to_BIOS for 3 seconds and T_OSLoad_to_Desktop for 25 seconds. The system sets these parameters into the corresponding image processing and timing monitoring modules, giving subsequent monitoring actions clear judgment criteria specific to the current operating system.

[0111] In some embodiments, parameter determination in this step can be achieved in several ways: Optionally, a static loading method can be used, where the system loads a JSON or XML template file containing fixed key-value pairs, directly reads the values ​​of fields such as match_threshold and timing_sequence, and applies them; alternatively, a dynamic generation method can be used, where the template stores parameter generation rules rather than fixed values. For example, the rule can define a similarity threshold that is inversely proportional to the screen resolution of the device under test, and the system dynamically calculates the final matching parameters based on the detected actual resolution. It is understood that other methods can also be used to implement this step, such as adaptively fine-tuning the template parameters based on historical test data; this is not limited here.

[0112] In some embodiments, operating system updates (such as UI redesigns) may cause image features in the original template to become invalid. To address this, the intelligent monitoring system employs a multi-feature redundancy judgment mechanism. The feature template not only includes a single, complete screenshot but also multiple key, independent local features, such as multiple historical versions of the Start menu icon, common structural features of the taskbar, and the shape of the mouse pointer. During matching, the system comprehensively evaluates the matching results of multiple local features. As long as a sufficient number of key features match successfully, the desired state is determined, enhancing robustness to minor UI changes.

[0113] S208. Detect the interface type of the display output of the device under test, and adjust the acquisition parameters of the image acquisition module according to the display matching parameters, power-on / off sequence and interface type.

[0114] Among them, the display output interface type refers to the type of video interface for the physical connection between the motherboard under test and the image acquisition module, such as HDMI, DisplayPort (DP) or VGA; the display matching parameters and power-on / off sequence are the configurations determined in step S207; the acquisition parameters of the image acquisition module refer to the specific settings that control the operation of the image acquisition hardware, mainly including resolution, refresh rate, color space (such as RGB, YUV) and pixel format.

[0115] Specifically, this step is the final hardware configuration step before the test begins. After the intelligent monitoring system establishes a connection with the device under test (DUT) through its image acquisition module (e.g., a capture card), it attempts to detect the physical interface type and read the video signal information output by the DUT. The system matches and negotiates the acquired actual signal parameters (e.g., 1920x1080@60Hz) with the expected display parameters obtained from the template in step S207, ultimately setting an optimal set of acquisition parameters for the image acquisition module. For example, if an HDMI interface is detected and the template expects 1080p, the capture card is set to 1920x1080 resolution, 60Hz refresh rate, and RGB color space to ensure that the captured image data is consistent with the input requirements of the subsequent matching algorithm.

[0116] In some embodiments, parameter adjustment for this step can be implemented in several ways: Optionally, configuration can be based on EDID (Extended Display Identifier Data), whereby the image acquisition module reads the EDID information sent by the device under test through the display interface. This information details all supported display modes, and the system selects the mode that best matches the template expectation to configure the acquisition parameters. Optionally, probing configuration can be used, whereby when EDID information is unavailable, the system sequentially tries different acquisition parameters according to a preset list (e.g., 1080p, 720p, 480p) until a stable video signal is successfully locked, and then uses these parameters for testing. It is understood that other methods can also be used to implement this step, such as allowing users to forcibly specify acquisition parameters in the configuration interface; this is not limited here.

[0117] In some embodiments, the device under test (DUT) may dynamically change its resolution during startup (e.g., switching from a low resolution in the BIOS to a high resolution in the operating system). To address this, the intelligent monitoring system enables dynamic mode switching. The image acquisition module continuously monitors the synchronization status of the video signal. Upon detecting signal loss or a mode change, the system pauses image analysis and re-triggers an interface detection and parameter negotiation process (as described in S208) to reconfigure the acquisition module with the new resolution and refresh rate. After configuration, the system resumes image analysis, ensuring correct capture and processing of video frames throughout the startup process.

[0118] S209-S214: The voltage data of the power indicator pin of the device under test (DUT) is collected by the voltage acquisition module, and the power-on state of the DUT is determined based on the voltage change characteristics of the voltage data. After the DUT enters the preset power-on state and maintains it for a preset time, the real-time frame image of the display screen of the DUT is captured by the image acquisition module. Feature matching calculation is performed on the real-time frame image to determine the display content of the display screen. When the display content meets the preset fault characteristics, a system fault record is generated. When the display content meets the operating system loading completion characteristics, a normal power-on record is generated, and a power-off command is sent to the DUT through the communication interface to trigger the DUT to power off. After the voltage data of the power indicator pin drops to the power-off state, a single test completion record is generated and the next round of testing is triggered.

[0119] Refer to steps S102-S107, which will not be repeated here.

[0120] In some embodiments, the intelligent monitoring system performs quantitative analysis of timing performance. Specifically, the intelligent monitoring system reads the standard boot sequence corresponding to the operating system type from a preset operating system parameter library. When the data deviation between the actual boot sequence and the standard boot sequence of the device under test exceeds a preset deviation range, a timing anomaly alarm is generated, and the actual boot sequence and data deviation are recorded as timing anomaly events.

[0121] The standard boot sequence is a detailed timeline that records the standard time points of various milestone events from booting to entering the desktop (such as the appearance of the BIOS logo, the start of OS loading, and the appearance of the login screen); the timing abnormal events are log entries that record boot performance failures.

[0122] Specifically, during the testing process, the intelligent monitoring system uses image recognition and power analysis to accurately record the actual timestamps of each startup milestone reached by the device under test. After a successful boot, the system compares this actual boot sequence with the standard boot sequence corresponding to the current operating system, read from the parameter library. For example, the standard sequence specifies that the time from OS loading to the appearance of the login screen should be 15 seconds ± 2 seconds, while the actual measurement is 25 seconds. Since the deviation (10 seconds) exceeds the preset deviation range, the system generates a timing anomaly alarm and records the login screen delay event along with the specific delay time.

[0123] In some embodiments, the time-series comparison step can be implemented in several ways: optionally, independent difference comparison and threshold judgment are performed for the time points of each milestone event; optionally, the entire time-series sequence is treated as a time vector, and the Euclidean distance or Mahalanobis distance between the actual time-series vector and the standard time-series vector is calculated. If the distance exceeds the threshold, it is determined that the overall time-series is abnormal. It is understood that other methods can also be used to implement this step, such as statistically analyzing the mean and variance of the time series in multiple tests to discover performance jitter and instability, which is not limited here.

[0124] In some embodiments, the boot time may increase upon first power-on or after a system update, leading to false alarms about timing anomalies. To address this, the intelligent monitoring system can be configured with a learning / adaptation cycle. In the first few tests (e.g., the first 5), the system only records timing data without issuing alarms, instead calculating an average actual boot time and using it as a personalized baseline for that specific device under test. From the 6th test onwards, the system compares subsequent actual timings with this personalized baseline, thus avoiding false alarms caused by normal one-time time-consuming operations such as initial setup or updates.

[0125] In this embodiment, an independent monitoring system based on ARM devices is employed, integrating relay control, multimodal sensing (voltage, image, audio, power), and intelligent analysis technologies. Therefore, this solution constructs a closed-loop test and monitoring system that combines the physical and application layers, independent of the operating system and network functions of the device under test. This system effectively solves the problems of existing technologies that rely solely on networks or scripts, making it difficult to cover hardware self-test faults before operating system loading and to identify screen freezes and other apparent dead states. Furthermore, it enables refined, multi-dimensional, and highly robust fault diagnosis of the entire power-on / off process of a computer motherboard, from power-on, hardware self-test, system boot to desktop access, thereby improving the accuracy and efficiency of fault attribution in aging tests.

[0126] The intelligent monitoring system in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference]. Figure 3This is a schematic diagram of the physical device structure of an intelligent monitoring system in an embodiment of this application.

[0127] It should be noted that, Figure 3 The structure of the intelligent monitoring system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0128] like Figure 3 As shown, the intelligent monitoring system includes a CPU 301, which can perform various appropriate actions and processes according to a program stored in ROM 302 or a program loaded from storage section 308 into RAM 303, such as executing the methods described in the above embodiments. RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via bus 304. I / O interface 305 is also connected to bus 304.

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

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

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

[0132] Specifically, the intelligent monitoring system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the motherboard testing and monitoring method based on ARM devices provided in the above embodiment.

[0133] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the intelligent monitoring system described in the above embodiments; or it may exist independently and not assembled into the intelligent monitoring system. The storage medium carries one or more computer programs, which, when executed by a processor of the intelligent monitoring system, enable the intelligent monitoring system to implement the motherboard testing and monitoring method based on an ARM device provided in the above embodiments.

[0134] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0135] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning if... or after... or in response to determining... or in response to detecting... Similarly, depending on the context, the phrase "when determining... or if (the stated condition or event) is interpreted as meaning if determining... or in response to determining... or in response to detecting (the stated condition or event)" or in response to detecting (the stated condition or event).

Claims

1. A motherboard testing and monitoring method based on ARM devices, characterized in that, An ARM device is used in an intelligent monitoring system, which further includes a relay control module, a voltage acquisition module, and an image acquisition module; the relay control module is electrically connected to the power-on pin of the device under test; the voltage acquisition module is electrically connected to the power indicator pin of the device under test. The image acquisition module is used to acquire images of the display screen of the device under test; the method includes: In response to the test start command, the relay control module closes the power-on pin of the device under test to trigger the device under test to power on. The voltage acquisition module acquires voltage data from the power indicator pin of the device under test, and determines the power-on state of the device under test based on the voltage change characteristics of the voltage data. After the device under test enters a preset power-on startup state and maintains it for a preset duration, the image acquisition module captures real-time frame images of the display screen of the device under test. Feature matching calculations are performed on the real-time frame images to determine the display content of the display screen; When the displayed content matches the preset fault characteristics, a system fault record is generated; When the displayed content matches the characteristics of the operating system loading completion, a normal boot record is generated, and a shutdown command is sent to the device under test through the communication interface to trigger the device under test to shut down. After the voltage data on the power indicator pin drops to the power-off state, a single test completion record is generated and the next round of testing is triggered.

2. The method according to claim 1, characterized in that, The intelligent monitoring system further includes an audio acquisition module; after the step of closing the power-on pin of the device under test based on the relay control module in response to the test start command to trigger the device under test to power on, the method further includes: The audio acquisition module captures the sound data stream of the device under test and performs spectrum analysis on the sound data stream to extract fan sound data and buzzer sound data. Based on the fan sound data, the fan speed change data is determined to obtain the fan operating status; Based on the buzzer sound data, determine the motherboard self-test timing and the motherboard self-test result; Based on the fan operating status, the motherboard self-test time point, and the motherboard self-test result, a power-on judgment auxiliary result is generated.

3. The method according to claim 2, characterized in that, After the step of generating a power-on judgment auxiliary result based on the fan operating status, the motherboard self-test time point, and the motherboard self-test result, the method further includes: By combining the motherboard self-test time points, the motherboard self-test results, and the displayed content of the real-time frame images, the motherboard operating status is determined; The motherboard's operating status is matched with a preset fault knowledge base to determine the specific fault type and root cause of the device under test, thereby replacing the system fault record.

4. The method according to claim 1, characterized in that, The intelligent monitoring system further includes a load acquisition module; after the step of closing the power-on pin of the device under test based on the relay control module in response to the test start command to trigger the device under test to power on, the method further includes: The load acquisition module acquires the operating power data of the device under test. Extract the peak points, valley points, and slope change points from the operating power data as power features; Based on the power characteristics, the current time node, and the preset self-test phase timing table, the current self-test phase of the device under test is determined; The sampling time node of the image acquisition module is determined based on the current self-test phase.

5. The method according to claim 4, characterized in that, The step of determining the current self-test stage of the device under test based on the power characteristics, the current time, and a preset self-test stage timing table specifically includes: Obtain the voltage data of the power indicator pin, compare the voltage data with a preset voltage threshold, and obtain the voltage comparison result; Based on the waveform change trend of the power characteristics, calculate the power similarity between the current power curve and the preset standard power curve; Based on the voltage comparison results and the power similarity, and combined with the standard duration of each stage recorded in the self-test stage timing table, the current self-test stage of the device under test is determined. When the power similarity is lower than a preset similarity threshold, the current time and the corresponding power characteristics are recorded to generate self-test fault information.

6. The method according to claim 1, characterized in that, Prior to the step of closing a relay connected to the power-on pin of the device under test in response to a test start command to trigger power-on of the device under test, the method further includes: Determine the operating system type of the device under test, and determine the corresponding system loading feature template based on the operating system type; Based on the system loading feature template, the display matching parameters and power-on / off timing are determined; The interface type of the display output of the device under test is detected, and the acquisition parameters of the image acquisition module are adjusted according to the display matching parameters, the power-on / off sequence, and the interface type.

7. The method according to claim 6, characterized in that, After determining the operating system type of the device under test and determining the corresponding system loading feature template based on the operating system type, the method further includes: Read the standard boot sequence corresponding to the operating system type from the preset operating system parameter library; When the actual power-on timing of the device under test is detected to deviate from the standard power-on timing by more than a preset deviation range, a timing anomaly alarm is generated, and the actual power-on timing and the data deviation are recorded as a timing anomaly event.

8. An intelligent monitoring system, characterized in that, The intelligent monitoring system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the intelligent monitoring system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on the intelligent monitoring system, the intelligent monitoring system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the intelligent monitoring system, the intelligent monitoring system performs the method as described in any one of claims 1-7.

Images