Terminal device and terminal device self-checking method based on cloud cooperation

Abstract

The application provides a terminal device and a terminal device self-checking method based on cloud cooperation, relates to the technical field of terminal devices, and can acquire a topology network after kernel startup is completed in response to a terminal device startup instruction, create a self-checking task for each function node according to the topology network, and calculate the priority of each self-checking task. According to the priority, the self-checking task is divided into a first-level self-checking task, a second-level self-checking task and a third-level self-checking task. The first-level self-checking task is synchronously executed in a key path before the startup of a system core service, and if the detection result is abnormal, the startup process is immediately interrupted; the second-level self-checking task is asynchronously executed after the startup of the system core service, and does not affect the startup process; and the third-level self-checking task is executed by a specific trigger condition after startup. The application uses a problem root cause analysis method to realize startup self-checking path optimization based on historical fault root cause knowledge, and improves startup self-checking accuracy and startup speed.

Description

Technical Field

[0001] This application relates to the field of terminal device technology, and in particular to a terminal device and a self-testing method for terminal devices based on cloud collaboration. Background Technology

[0002] Terminal devices refer to devices capable of performing specific functions, such as smart TVs, communication terminals, smart advertising screens, projectors, printers, scanners, etc. Taking smart TVs as an example, a smart TV is a television product based on Internet application technology, equipped with an open operating system and chip, possessing an open application platform, enabling two-way human-computer interaction, and integrating multiple functions such as audio-visual, entertainment, and data to meet diverse and personalized user needs.

[0003] To ensure stable operation of terminal devices, a Power-On Self-Test (POST) process is performed during startup to check the continuity of hardware modules such as the power supply, motherboard, display, and audio. However, this only detects hardware-level faults and can only identify existing faults, not pinpointing the root cause, resulting in low detection accuracy. Furthermore, the terminal device needs to perform a comprehensive check of all its test items, which slows down startup.

[0004] To improve boot speed, terminal devices may select important tests during the boot process, but this approach can easily lead to the omission of some tests. Furthermore, relying solely on experience to set mandatory boot tests may overlook the interrelationships between these tests, resulting in the neglect of critical ones and reduced accuracy. Summary of the Invention

[0005] This application provides a terminal device and a cloud-based collaborative self-testing method for terminal devices to solve the problems of low detection accuracy and slow boot speed in terminal device power-on self-tests.

[0006] In a first aspect, some embodiments of this application provide a terminal device, including:

[0007] The communication device is configured to establish a communication connection with a cloud server.

[0008] The memory is configured as a storage topology network; the topology network is pre-obtained from the cloud server via over-the-air download technology, the topology network includes functional nodes and edges, the functional nodes are used to characterize functional modules in the terminal device, the edges are used to characterize the dependencies between the functional nodes, the functional nodes are labeled with a first index and a second index, the first index is used to indicate the historical frequency of the functional node as a root cause of failure, and the second index is used to indicate the effectiveness score of the functional node as a self-test point.

[0009] The monitor is configured to display the user interface;

[0010] The controller is configured as follows:

[0011] In response to the power-on command of the terminal device, the kernel of the terminal device is started;

[0012] After the kernel boots up, the topology network is obtained;

[0013] Based on the topology network, create a self-test task for each of the functional nodes;

[0014] In the topology network, the first indicator and the second indicator corresponding to the functional node are parsed;

[0015] Calculate the priority of each self-test task based on the first indicator and the second indicator;

[0016] Based on the priority, the self-test tasks are divided into Level 1 self-test tasks, Level 2 self-test tasks, and Level 3 self-test tasks;

[0017] Perform the first-level self-test task;

[0018] If the detection result of the first-level self-test task indicates an abnormality, the power-on process of the terminal device shall be interrupted.

[0019] If the result of the first-level self-test task is normal, the power-on process of the terminal device continues to be executed, and in response to the broadcast that the core system services of the terminal device have been started and completed, the display is loaded and the user interface is controlled to be displayed. At the same time, the second-level self-test task is executed asynchronously through a background thread. If the result of the second-level self-test task is abnormal, the power-on process of the terminal device is not interrupted.

[0020] After the terminal device is powered on, it executes the three-level self-test task in response to preset trigger conditions.

[0021] The above technical solution has the following beneficial effects or advantages:

[0022] This application applies a topology network based on root cause analysis to the power-on self-test (POST) process. The functional modules of the terminal device are abstracted as nodes in the topology network, and the dependencies between functional modules are abstracted as edges. A POST task is created for each functional node based on the topology network, thereby refining the detection level to specific functional modules and improving detection accuracy. Furthermore, the priority sequence of POST tasks can be determined based on the first and second indicators in the topology network, prioritizing the detection of critical functional modules associated with high-frequency fault sources. Detection of functional modules that do not affect the power-on process can be performed after power-on, thus improving power-on speed.

[0023] In some embodiments of this application, the controller, based on the priority, divides the self-test task into a first-level self-test task, a second-level self-test task, and a third-level self-test task, and is configured as follows:

[0024] Based on the first indicator and the second indicator, a priority score is calculated for each self-test task; wherein, the priority score is used to characterize the priority of the self-test task, and the priority score is positively correlated with the first indicator and the second indicator; the first indicator is the sum of the products of the severity weight of the functional node as the root cause of the fault and the time decay factor in all historical self-test fault cases; the second indicator is the ratio of a second statistical value to a first statistical value, wherein the first statistical value is the number of times the functional node should be detected in historical self-test fault cases where the functional node is the root cause of the fault, and the second statistical value is the number of times the functional node is actually detected in historical self-test fault cases where the functional node is the root cause of the fault;

[0025] If the priority score is greater than or equal to the first threshold, the self-test task is determined to be the first-level self-test task;

[0026] If the priority score is less than the first threshold and greater than or equal to the second threshold, the self-test task is determined to be the second-level self-test task.

[0027] If the priority score is less than the second threshold, the self-test task is determined to be the level 3 self-test task;

[0028] Wherein, the first threshold is greater than the second threshold.

[0029] The above technical solution has the following beneficial effects or advantages:

[0030] Specific priority scores are calculated based on the first and second indicators, and a first threshold and a second threshold are introduced. By comparing the first threshold, the second threshold, and the priority scores, the self-inspection tasks are divided to improve the accuracy of task classification.

[0031] In some embodiments of this application, the controller calculates a priority score for each self-test task based on the first indicator and the second indicator, and is configured as follows:

[0032] Obtain a first weighting coefficient and a second weighting coefficient; wherein the sum of the first weighting coefficient and the second weighting coefficient is 1, and the first weighting coefficient is greater than the second weighting coefficient;

[0033] Calculate the product of the first weighting coefficient and the first index to obtain the first score;

[0034] Calculate the product of the second weighting coefficient and the second indicator to obtain the second score;

[0035] The priority score is obtained by summing the first score and the second score.

[0036] The above technical solution has the following beneficial effects or advantages:

[0037] By introducing configurable first and second weighting coefficients, the corresponding emphasis can be adjusted by changing the first and second weighting coefficients, thus improving flexibility.

[0038] In some embodiments of this application, the primary self-test task includes multiple tasks, and the controller executing the primary self-test task is further configured to:

[0039] Determine the priority score for each of the first-level self-inspection tasks;

[0040] The multiple Level 1 self-check tasks are sorted in descending order of priority scores to obtain a list of Level 1 self-check tasks.

[0041] According to the list of first-level self-check tasks, execute multiple first-level self-check tasks in sequence.

[0042] The above technical solution has the following beneficial effects or advantages:

[0043] By reordering the primary self-test tasks, it is ensured that the terminal device can prioritize high-priority self-test tasks during the boot process. This avoids damage to the terminal device due to the initialization of a module before the failure of the module is detected because high-frequency and high-risk modules are not detected first.

[0044] In some embodiments of this application, the memory is further configured to store a self-test strategy; the self-test strategy is obtained in advance from the cloud server via over-the-air download technology; after the controller acquires the topology network, it is further configured to:

[0045] The topology network is parsed to obtain the dependencies between the functional nodes and the list of self-check points corresponding to the functional nodes; wherein, the dependencies include power supply dependencies, data dependencies, and control dependencies, and the list of self-check points includes the self-check points corresponding to the functional nodes;

[0046] Obtain the self-test strategy corresponding to each self-test point; wherein, the self-test strategy includes self-test time point, self-test method, and self-test conditions;

[0047] Based on the self-check strategy and the dependency relationship, create a self-check task for each self-check point;

[0048] When performing the self-test task, the functional nodes are tested according to the self-test strategy to obtain the test results, and the test results are analyzed according to the dependency relationship.

[0049] If the detection result indicates that the input state of the functional node is normal but the output state is abnormal, the detection result is determined to be abnormal, and the functional node is determined to be the root cause of the fault.

[0050] The above technical solution has the following beneficial effects or advantages:

[0051] Based on the hardware architecture characteristics and usage scenarios of terminal devices, this application establishes a self-testing strategy with a multi-dimensional constraint-based information collection and feature extraction mechanism, which is maintained by a cloud server. The self-testing strategy includes self-testing time points, self-testing methods, and self-testing conditions. It can be used to instruct the terminal device to perform functional node testing at specific time points, in specific ways, and under specific conditions, capturing deep state characteristics highly correlated with specific fault modes, rather than relying solely on traditional basic electrical parameters or status flags, thereby improving detection accuracy.

[0052] In some embodiments of this application, the cloud server stores a global topology network generated based on historical self-test fault cases corresponding to multiple terminal device models;

[0053] The controller is also configured to:

[0054] After the terminal device is powered on, the device model of the terminal device is obtained;

[0055] Send a request carrying the device model to the cloud server. The request is used to request the topology network corresponding to the device model from the cloud server. The topology network includes a first functional node and a second functional node. The first functional node is the root cause of the fault in the historical self-test fault cases corresponding to the device model or has a self-test point in the terminal device corresponding to the device model. The second functional node is a functional node that has a dependency relationship with the first functional node.

[0056] The device receives the topology network fed back from the cloud server and updates the topology network stored in the memory according to the topology network; wherein the updated topology network is applied to the next boot process of the terminal device.

[0057] The above technical solution has the following beneficial effects or advantages:

[0058] The cloud server maintains the global topology network, and terminal devices can request the corresponding topology network from the cloud server based on their own device model. This method can save storage and computing costs on terminal devices, while also facilitating the optimization and updating of the global topology network.

[0059] In some embodiments of this application, the memory is configured to store a first version of the topology network and a second version of the topology network, wherein the first version is an earlier updated version of the second version; the controller is configured to:

[0060] Obtain the second version of the topology network;

[0061] Verify the topology network of the second version;

[0062] If the second version of the topology network verification passes, a self-test task is created for each of the functional nodes according to the second version of the topology network;

[0063] If the second version of the topology network fails the verification, obtain the first version of the topology network;

[0064] Verify the topology network of the first version;

[0065] If the first version of the topology network verification passes, a self-test task is created for each of the functional nodes based on the first version of the topology network.

[0066] If the topology network verification fails in the first version, a preset security self-check process is executed.

[0067] The above technical solution has the following beneficial effects or advantages:

[0068] The terminal device stores two versions of the topology network in its memory. This allows it to revert to the previous version of the topology network if the current version is faulty, thus avoiding a situation where there is no usable topology network during the boot process.

[0069] In some embodiments of this application, the controller is further configured to:

[0070] If the detection result of the first-level self-test task is abnormal, or if the detection result of the second-level self-test task is abnormal, or if the detection result of the third-level self-test task is abnormal, obtain the self-test task information.

[0071] Based on the self-test task information, generate self-test fault cases;

[0072] The self-test fault case is sent to the cloud server so that the cloud server updates the global topology network based on the self-test fault case.

[0073] The above technical solution has the following beneficial effects or advantages:

[0074] This application constructs a data feedback closed loop based on a cloud-based collaborative architecture to optimize the global topology network. Terminal devices generate and report self-test fault cases, and the cloud server updates the global topology network based on the reported self-test fault cases, so that the topology network and self-test strategy sent to the terminal devices can be continuously optimized.

[0075] In some embodiments of this application, the memory is further configured to store a self-healing operation library, the self-healing operation library including self-healing operations corresponding to each of the functional nodes; the controller is further configured to:

[0076] If the detection result of the first-level self-test task is abnormal, or if the detection result of the second-level self-test task is abnormal, or if the detection result of the third-level self-test task is abnormal, the target functional node as the root cause of the fault shall be identified.

[0077] Call the self-healing operation library;

[0078] In the self-healing operation library, query the self-healing operation corresponding to the target functional node;

[0079] The self-healing operation is performed on the target functional node.

[0080] The above technical solution has the following beneficial effects or advantages:

[0081] The terminal device provides a self-healing function. When the root cause of the fault is detected, it can automatically match and execute preset self-healing operations based on the self-healing operation library to ensure the safe operation of the device and improve the user experience.

[0082] Secondly, some embodiments of this application provide a terminal device self-testing method based on cloud collaboration, including:

[0083] In response to the power-on command of the terminal device, the kernel of the terminal device is started;

[0084] After the kernel boots up, a topology network is retrieved from memory. The topology network is obtained from a cloud server in advance via over-the-air download technology. The topology network includes functional nodes and edges. The functional nodes are used to represent functional modules in the terminal device, and the edges are used to represent the dependencies between the functional nodes. The functional nodes are labeled with a first indicator and a second indicator. The first indicator is used to indicate the historical frequency of the functional node as a root cause of a fault, and the second indicator is used to indicate the effectiveness score of the functional node as a self-check point.

[0085] Based on the topology network, create a self-test task for each of the functional nodes;

[0086] In the topology network, the first indicator and the second indicator corresponding to the functional node are parsed;

[0087] Calculate the priority of each self-test task based on the first indicator and the second indicator;

[0088] Based on the priority, the self-test tasks are divided into Level 1 self-test tasks, Level 2 self-test tasks, and Level 3 self-test tasks;

[0089] Perform the first-level self-test task;

[0090] If the detection result of the first-level self-test task indicates an abnormality, the power-on process of the terminal device shall be interrupted.

[0091] If the result of the first-level self-test task indicates that it is normal, the power-on process of the terminal device continues to be executed, and in response to the broadcast that the core system service of the terminal device has been started and completed, the display is loaded and the user interface is controlled to be displayed. At the same time, the second-level self-test task is executed asynchronously through a background thread. If the result of the second-level self-test task indicates that it is abnormal, the power-on process of the terminal device is not interrupted.

[0092] After the terminal device is powered on, it executes the three-level self-test task in response to preset trigger conditions.

[0093] The above technical solution has the following beneficial effects or advantages:

[0094] This application applies a topology network based on root cause analysis to the power-on self-test (POST) process. The functional modules of the terminal device are abstracted as nodes in the topology network, and the dependencies between functional modules are abstracted as edges. A POST task is created for each functional node based on the topology network, thereby refining the detection level to specific functional modules and improving detection accuracy. Furthermore, the priority sequence of POST tasks can be determined based on the first and second indicators in the topology network, prioritizing the detection of critical functional modules associated with high-frequency fault sources. Detection of functional modules that do not affect the power-on process can be performed after power-on, thus improving power-on speed. Attached Figure Description

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

[0096] Figure 1 This is a schematic diagram illustrating the operational scenarios between a terminal device and a control device provided in some embodiments of this application;

[0097] Figure 2 This is a schematic diagram of the hardware configuration of a terminal device provided in some embodiments of this application;

[0098] Figure 3 This is a schematic diagram of the software configuration of a terminal device provided in some embodiments of this application;

[0099] Figure 4 A flowchart illustrating a cloud-based collaborative terminal device self-testing method provided in some embodiments of this application;

[0100] Figure 5 This is a schematic diagram illustrating the interaction between a cloud server and a terminal device in some embodiments of this application, showing the network topology being distributed.

[0101] Figure 6 A flowchart illustrating the creation of a self-test task is provided for some embodiments of this application;

[0102] Figure 7 This is another flowchart illustrating the creation of a self-test task provided for some embodiments of this application;

[0103] Figure 8 A flowchart illustrating the division of self-test tasks provided for some embodiments of this application;

[0104] Figure 9 A flowchart illustrating the execution of a three-level self-test task provided in some embodiments of this application;

[0105] Figure 10 A flowchart illustrating the self-healing operation provided for some embodiments of this application;

[0106] Figure 11 This is an interactive diagram illustrating how a terminal device sends self-test fault cases to a cloud server, as provided in some embodiments of this application. Detailed Implementation

[0107] The embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described below do not represent all embodiments consistent with this application. They are merely examples of systems and methods consistent with some aspects of this application as detailed in the claims.

[0108] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0109] In this application embodiment, terminal device 200 generally refers to a device with data processing capabilities. Terminal device 200 includes, but is not limited to, smart TVs, mobile terminals, computers, monitors, advertising screens, wearable devices, virtual reality devices, augmented reality devices, etc.

[0110] Figure 1 This is a schematic diagram illustrating an operational scenario between a display device and a control device provided in some embodiments of this application. For example... Figure 1 As shown, a user can operate a terminal device 200 via touch operation, a mobile terminal 300, and a control device 100. The control device 100 receives user input commands and converts them into control commands that the terminal device 200 can recognize and respond to. For example, the control device 100 can be a remote control, a stylus, a gamepad, etc.

[0111] The mobile terminal 300 can function as a control device for human-computer interaction between the user and the terminal device 200. The mobile terminal 300 can also function as a communication device for establishing a communication connection with the terminal device 200 and exchanging data. In some embodiments, the mobile terminal 300 can install software applications with the terminal device 200 to establish a connection and communication via network communication protocols, achieving one-to-one control operations and data communication. It can also transmit audio and video content displayed on the mobile terminal 300 to the terminal device 200 for synchronized display.

[0112] In some embodiments, the mobile terminal 300 or other electronic devices may also simulate the functions of the control device 100 by running the application of the control terminal device 200.

[0113] like Figure 1 The document also shows that the terminal device 200 can communicate with the server 400 via various communication methods. The terminal device 200 can communicate via a local area network (LAN), a wireless local area network (WLAN), and other networks.

[0114] Terminal device 200 can provide broadcast television reception function, and can also be equipped with intelligent network television function with computer support, including but not limited to network television, smart television, Internet Protocol television (IPTV), etc.

[0115] Figure 2 Provided for some embodiments of this application Figure 1 Hardware configuration block diagram of terminal device 200.

[0116] In some embodiments, the terminal device 200 may include at least one of a tuner 210, a communication device 220, a detector 230, a device interface 240, a controller 250, a display 260, an audio output device 270, a memory, a power supply, and a user input interface 280.

[0117] In some embodiments, detector 230 is used to acquire signals from the external environment or to interact with the outside world. For example, detector 230 includes a light receiver, a sensor for acquiring ambient light intensity; or, detector 230 includes an image acquisition device, such as a camera, which can be used to acquire external environmental scenes, user attributes, or user interaction gestures; or, detector 230 includes a sound acquisition device, such as a microphone, for receiving external sounds.

[0118] In some embodiments, the display 260 includes display function components for presenting images and driving components for driving image display. The display 260 is used to receive and display image signals output from the controller 250. For example, the display 260 can be used to display video content, image content, menu control interface components, and user control UI interfaces, etc.

[0119] In some embodiments, the communication device 220 is a component used to communicate with external devices or the server 400 according to various communication protocol types. The terminal device 200 may have multiple communication devices 220 depending on the supported communication methods. For example, when the terminal device 200 supports wireless network communication, it may have a communication device 220 with WiFi functionality. When the terminal device 200 supports Bluetooth connection communication, it needs to have a communication device 220 with Bluetooth functionality.

[0120] The communication device 220 enables the terminal device 200 to communicate with external devices or the server 400 via wireless or wired connections. Wired connections utilize data cables, interfaces, or other components to connect the terminal device 200 to external devices. Wireless connections utilize wireless signals or wireless networks. The terminal device 200 can establish a direct connection with external devices or indirectly through gateways, routers, or other connection devices.

[0121] In some embodiments, the controller 250 may include at least one of a central processing unit, a video processor, an audio processor, a graphics processor, and a power processor, and a first to an nth interface for input / output. The controller 250 controls the operation of the display device and responds to user operations through various software control programs stored in memory. The controller 250 controls the overall operation of the terminal device 200.

[0122] In some embodiments, the controller 250 and the tuner 210 may be located in different separate devices, that is, the tuner 210 may also be located in an external device of the main device where the controller 250 is located, such as an external set-top box.

[0123] In some embodiments, a user can input user commands through a graphical user interface (GUI) displayed on a display 260, and the user input interface 280 receives the user input commands through the graphical user interface (GUI).

[0124] In some embodiments, the audio output device 270 can be the built-in speaker of the terminal device 200 or an external audio output device connected to the terminal device 200. For the external audio output device connected to the terminal device 200, the terminal device 200 may also be provided with an external audio output terminal, through which the audio output device can be connected to the terminal device 200 to output sound from the terminal device 200.

[0125] In some embodiments, the user input interface 280 can be used to receive instructions from user input.

[0126] To enable user interaction, in some embodiments, the terminal device 200 may run an operating system. The operating system is a computer program used to manage and control the hardware and software resources of the terminal device 200. The operating system can control a display device to provide a user interface; for example, the operating system can directly control the display device to provide a user interface, or it can provide a user interface by running applications. The operating system also allows users to interact with the terminal device 200.

[0127] It should be noted that the operating system can be a native operating system based on a specific operating platform, a third-party operating system that is deeply customized based on a specific operating platform, or an independent operating system specifically developed for display devices.

[0128] An operating system can be divided into different modules or levels based on the functions it implements, for example... Figure 3 As shown, in some embodiments, the system is divided into four layers, from top to bottom: the Applications layer (referred to as the "Application Layer"), the Application Framework layer (referred to as the "Framework Layer"), the System Runtime Library layer, and the Kernel Layer.

[0129] In some embodiments, the application layer provides services and interfaces for applications, enabling the terminal device 200 to run applications and interact with the user based on the applications. The application layer may contain at least one application, which may be a built-in Windows program, system settings program, or clock program of the operating system; or it may be an application developed by a third-party developer. In specific implementations, the application packages in the application layer are not limited to the examples above.

[0130] The framework layer provides application programming interfaces (APIs) and a programming framework for applications. The application framework layer includes predefined functions. It acts as a central processing unit, determining the actions taken by applications within the application layer. Through the API, applications can access system resources and obtain system services during execution.

[0131] like Figure 3As shown, the application framework layer in this embodiment includes a view system, managers, and content providers. The view system designs and implements the application's interface and interactions, and includes lists, grids, text boxes, and buttons. The managers include at least one of the following modules: an activity manager for interacting with all running activities in the system; a location manager for providing system services or applications with access to system location services; a package manager for retrieving various information related to application packages currently installed on the device; a notification manager for controlling the display and clearing of notification messages; and a window manager for managing icons, windows, toolbars, wallpapers, and desktop widgets on the user interface.

[0132] In some embodiments, the Activity Manager manages the lifecycle of individual applications and common navigation and back functions, such as controlling application exit, opening, and back actions. The Window Manager manages all window programs, such as obtaining the screen size, determining if a status bar is present, locking the screen, capturing the screen, and controlling changes to the display window, such as shrinking the display window, shaking the display, or distorting the display.

[0133] In some embodiments, the system runtime library layer can provide support for the framework layer. When the framework layer is used, the operating system runs the instruction library contained in the system runtime library layer, such as the C / C++ instruction library, to implement the functions to be performed by the framework layer.

[0134] In some embodiments, the kernel layer is a functional layer situated between the hardware and software of the terminal device 200. The kernel layer can implement functions such as hardware abstraction, multitasking, and memory management. For example, ... Figure 3 As shown, hardware drivers can be configured in the kernel layer. The kernel layer can contain at least one of the following drivers: audio driver, display driver, Bluetooth driver, camera driver, WIFI driver, USB driver, HDMI driver, sensor driver (such as fingerprint sensor, temperature sensor, pressure sensor, etc.), and power driver, etc.

[0135] It should be noted that the above examples are merely a simple division of operating system functions and do not limit the specific form of the operating system of the terminal device 200 in this application embodiment. Depending on factors such as the function of the display device and the type of the operating system, the number of levels and the specific level type of the operating system may be expressed in other forms.

[0136] To ensure the stable operation of terminal device 200, it performs a Power-On Self-Test (POST) process during startup. This process aims to detect the on / off status of hardware modules such as power supply, motherboard, display, and audio through preset thresholds. Therefore, terminal device 200 can only detect hardware-level faults; it can only detect existing hardware faults and cannot pinpoint the specific root cause, resulting in low detection accuracy.

[0137] For example, terminal device 200 can only determine whether the HDMI interface is abnormal by detecting whether the High Definition Multimedia Interface (HDMI) has a signal output, but cannot further determine whether the root cause of the fault is physical damage to the interface, failure to read Extended Display Identification Data (EDID), clock circuit lockout, abnormal power rails, etc.

[0138] Furthermore, during the power-on self-test process, the terminal device 200 needs to perform a comprehensive check of all its own test items. This full check method will lead to a decrease in power-on speed.

[0139] For example, non-core hardware modules that do not affect the critical path of system startup, such as certain expansion interfaces, auxiliary sensors, and Wi-Fi modules, still need to be tested during the critical power-on phase. These unnecessary testing processes will prolong the total boot time, resulting in a decrease in boot speed.

[0140] Furthermore, if high-frequency, high-risk modules (such as power chips) are not prioritized for detection, the terminal device 200 may be damaged due to initializing the module before the module's failure is detected, such as short circuits or current surges.

[0141] To improve boot speed, the terminal device 200 may select important detection items for testing during the boot process. However, this approach can easily lead to the omission of some detection items. Furthermore, relying solely on experience to set mandatory detection items during the boot process may overlook the correlation between detection items, resulting in the neglect of critical detection items and reduced detection accuracy.

[0142] To address the aforementioned issues, the terminal device 200 provided in this embodiment can execute a cloud-based collaborative self-test method. By utilizing the root cause analysis (Ka) method, it optimizes the power-on self-test path based on historical fault root cause knowledge, thereby improving the accuracy and speed of the power-on self-test.

[0143] It should be noted that the Ka method is the core logic and decision rules used to locate the root cause of a fault. The Ka method is built on a topology network. When a certain self-check point (point K) is abnormal, the method can trace back along the edges (dependencies) of the topology network and locate the upstream root cause of the fault (point a) through the preset decision rules.

[0144] In this embodiment, the Ka method is lightweighted and implemented on the terminal device 200, and a cloud-based collaborative architecture is constructed to optimize the power-on self-test path of the terminal device 200. Specifically, the internal hardware or subsystem functional modules of the terminal device 200 are abstracted as nodes in a topology network, and the dependencies between functional modules are abstracted as edges in the topology network. By refining the detection layer to specific functional modules, the detection accuracy is improved. During the power-on process of the terminal device 200, the terminal device 200 can dynamically generate a priority sequence of self-test tasks based on this topology network, prioritizing the detection of key functional modules associated with high-frequency fault sources. Detection of functional modules that do not affect the power-on process can be performed after power-on, thereby improving the power-on speed.

[0145] The terminal device 200, capable of applying the cloud-based collaborative terminal device 200 self-test method, includes: a communication device 220, a display 260, a memory, and a controller 250. The communication device 220 is configured to establish a communication connection with a cloud server 500, and the memory is configured to store a topology network, which is pre-obtained from the cloud server 500 via Over-the-Air (OTA) technology. The controller 250 is configured to execute the specific steps of the cloud-based collaborative terminal device 200 self-test method.

[0146] like Figure 4 The diagram shown is a flowchart illustrating the self-testing method for a cloud-based collaborative terminal device 200 provided in this application embodiment. Applied to the terminal device 200, it specifically includes the following steps:

[0147] S401, in response to the power-on command of terminal device 200, starts the kernel of terminal device 200.

[0148] The kernel is the core component of the terminal device 200 operating system. It is responsible for managing system hardware resources (such as CPU and memory) and providing a basic operating environment for upper-layer applications. All applications and system services in the terminal device 200 must go through the kernel to call hardware functions.

[0149] Regarding the boot process of terminal device 200, in response to the boot command, terminal device 200 can load and run the bootloader. The bootloader is used to initialize the hardware devices and load the kernel into memory, handing control over to the kernel. At this time, the kernel begins to run, performing self-initialization such as processor scheduling, memory management, and interrupt control, and initializing drivers for various hardware devices. After the kernel completes initialization, it establishes a user-space runtime environment and starts the init process. The init process is the first user-space process, which sequentially starts the core system processes, including the Zygote process (application incubator) and the System Server process (system service). The System Server process further loads and starts the core system services of the operating system framework layer, such as the activity manager, window manager, and package manager.

[0150] Once the core system services have started, the Activity Manager broadcasts that the core system services have finished starting (such as a BOOT_COMPLETED broadcast) and launches the desktop application. The desktop application loads and renders the user interface to the monitor 260. At this point, the terminal device 200 has completed the boot process and entered an operable working state.

[0151] In response, after completing the underlying hardware initialization and before entering the user's operating system, the terminal device 200 initiates an embedded self-test process, optimizing the power-on self-test path based on the topology network distributed by the cloud server 500.

[0152] S402 acquires the network topology after the kernel boot process is complete.

[0153] After the kernel boots up, the terminal device 200 can retrieve a pre-stored topology network from memory. This topology network includes multiple functional nodes and edges. Functional nodes represent functional modules within the terminal device 200, such as power management integrated circuits (PMICs), HDMI receivers, Wi-Fi modules, LCD panels, and main control chips, or other hardware modules or subsystems. Edges represent the dependencies between functional nodes, including but not limited to power supply dependencies, data dependencies, and control dependencies.

[0154] Each functional node is labeled with a first indicator and a second indicator. The first indicator indicates the historical frequency of the functional node as a root cause of failure (point a). The second indicator indicates the effectiveness score of the functional node as a self-test point (point K).

[0155] In some embodiments, the topology network can be represented in various forms, including but not limited to directed graphs, weighted directed graphs, hierarchical graphs, and hypergraphs. For example, the topology network can take the form of a directed graph, including multiple functional nodes and edges. Functional nodes are used to represent functional modules in the terminal device 200. The edges between nodes can be defined according to the hardware schematic of the terminal device 200 to define dependencies such as energy, signal, and data. Each node is labeled with its historical frequency as a fault root cause (point a) and its effectiveness score as a self-check point (point K), thereby forming a complete topology network.

[0156] In some embodiments, the cloud server 500 can store and maintain a global topology network generated based on historical self-test fault cases corresponding to multiple terminal device 200 models. The terminal device 200 can request the corresponding topology network from the cloud server 500 based on its own device model for use in the power-on self-test process.

[0157] The following describes the implementation method for creating and maintaining a global topology network using a cloud server 500.

[0158] The cloud server 500 can transform scattered historical self-test failure cases into a structured, computable global topology network, providing a knowledge base for the self-testing of terminal devices 200 of different device models.

[0159] Among them, historical fault self-test cases are a complete record of fault occurrence, detection, diagnosis, and repair. The cloud server 500 can collect historical self-test fault cases from multiple heterogeneous data sources, including but not limited to factory test databases, after-sales maintenance work order systems, and anonymous logs from user terminals uploaded with user authorization.

[0160] The factory test database includes test failure records of terminal device 200 during the final inspection before leaving the factory, including test item name, measured failure value, device under test (DUT) serial number, and firmware version information. The after-sales maintenance work order system includes maintenance reports analyzed and filled out by after-sales engineers, including a description of the fault phenomenon, the determined root cause of the fault (point a), the detected failure point (point K), the information of the actual replaced parts, and the maintenance timestamp. The anonymous user terminal log is a diagnostic snapshot automatically uploaded by terminal device 200 after user authorization, including device self-test results, error codes, and environmental context information (such as geographical location based on IP resolution, local climate data obtained through the weather application programming interface (API), etc.).

[0161] Because the aforementioned data sources differ in format, field definitions, and semantic expression, the cloud server 500 can perform structured normalization processing on the raw data collected from multiple different data sources to facilitate subsequent processing. This extracts key information related to the fault phenomenon, root cause module, failure detection stage, occurrence time, equipment model, and severity of the problem from each data source. Based on a preset standardized template, the extracted key information is mapped and integrated into a unified format of structured Ka analysis cases, i.e., historical self-test fault cases. Finally, these standardized historical self-test fault cases are stored in a knowledge base as the basic data unit for constructing the television fault propagation topology network.

[0162] In some embodiments, the cloud server 500 can predefine a list of functional nodes based on the hardware architecture of the terminal device 200 to ensure consistency between the labeling of the root cause of the fault (point a) and the self-test point (point K). Here, the functional nodes are not limited to physical chips, but are refined to the smallest functional unit that can fail independently.

[0163] For example, as shown in Table 1, here is an example of the list of functional nodes provided in the embodiments of this application:

[0164] Table 1

[0165]

[0166] It should be noted that node naming can adopt a hierarchical identification scheme (e.g., Audio Subsystem (AUDIO) Digital-to-Analog Converter (DAC)) to support clear classification of functional nodes and future system scalability.

[0167] After obtaining the list of functional nodes, the cloud server 500 can determine the dependencies between functional nodes based on the schematic diagram and signal flow of the terminal device 200, and construct directed edges based on the dependencies.

[0168] For example, for power supply dependencies, if module B is powered by module A, then add an edge A→B, such as PMIC→HDMI_RX (12V power supply); for data dependencies, if module B processes the output of module A, then add an edge A→B, such as HDMI_RX→SoC (video data input); for control dependencies, if module A configures module B, then add an edge A→B, such as SoC→LCD_PANEL (send timing control signals).

[0169] Meanwhile, the cloud server 500 can calculate a first metric and a second metric for each functional node. The first metric indicates the historical frequency of the functional node as a root cause of failure (point a). The second metric indicates the effectiveness score of the functional node as a self-check point (point K).

[0170] The first indicator can be calculated using a time-decay weighted model, and can be based on Formula 1, as shown below:

[0171] ;

[0172] in, Represents functional nodes The corresponding first indicator, This indicates that among the historical self-test fault cases collected by the cloud server 500, the functional nodes... This is a set of cases for the root cause of the fault (point a). Represents a set of cases Single case The severity weights can be obtained through normalization, i.e. =severity(c) / 5, where severity(c) represents the number of cases. The severity score can be an integer ranging from 1 to 5. Indicates the time decay factor. Example The number of days since the event occurred. This indicates a half-life of 180 days, meaning that cases from 6 months ago have their weight halved.

[0173] The second indicator measures the actual interception capability of this functional node as a detection defense line. The second indicator can be calculated based on Formula 2, which is shown below:

[0174] ;

[0175] in, Represents functional nodes The corresponding second metric measures the probability that a self-test point (K-point) is successfully detected when it is the root cause of the fault (a-point). The first statistical value indicates the value at the functional node. The number of times that should be detected in the historical self-test fault cases that serve as the root cause of the fault (point a). The second statistical value represents the value at the functional node. The number of times that the historical self-test fault cases that serve as the root cause of the fault (point a) are actually detected mainly depends on the reverse calculation and analysis of after-sales service work order data.

[0176] After cloud server 500 obtains the above data elements, it can construct a global topology network based on these elements, that is, construct a directed graph object G=(V, E, Attr), where V represents the set of functional nodes, E represents the set of edges, and Attr represents the node attribute mapping function, Attr:V→ For each functional node Associate a binary attribute vector ( , ).

[0177] The cloud server 500 can persistently store the global topology network in a graph database (such as Neo4j) or JSON-LD format, and build indexes based on multiple dimensions such as device model, time range, and functional modules to support fast query and backtracking analysis.

[0178] For example, the global topology network is stored in a structured data format, mainly containing two parts: node information and edge information. Node information includes a description of each functional node, the historical frequency of each functional node as a root cause of failure (point a), its effectiveness score as a self-checking point (point K), and a list of self-checking points (point K) supported by that functional node. Edge information includes functional nodes with dependencies and the corresponding specific dependencies.

[0179] For example, as shown in Table 2, here are some examples of node information provided in the embodiments of this application:

[0180] Table 2

[0181]

[0182] The node ID is used to uniquely identify the functional module within the topology graph structure. The module name is used to indicate a user-readable module name. (First indicator...) This is a quantitative indicator for the functional node as the root cause of the failure (point a), reflecting the likelihood that this functional node will cause a failure. The second indicator ( The K-point score represents the effectiveness of this functional node as a self-check point (K-point), with a value ranging from 0 to 1. It measures the actual contribution of this functional node in detecting and intercepting faults. The K-point list represents the list of specific self-check actions supported by this functional node, used to guide the generation of specific self-check tasks.

[0183] For example, as shown in Table 3, here are some examples of the content of the edge information provided in the embodiments of this application:

[0184] Table 3

[0185]

[0186] The starting node is the node ID of the upstream node in the dependency relationship, and the target node is the node ID of the downstream node in the dependency relationship. The dependency type represents the specific physical or logical connection relationship between functional nodes, including power supply, data flow, and control signals.

[0187] Based on the structured node and edge information, the cloud server 500 can dynamically generate a topology network for a specific device model and send it to the terminal device 200, so that the terminal device 200 can optimize the power-on self-test path according to the topology network, thereby improving detection accuracy and power-on speed.

[0188] In some embodiments, after completing the construction of the global topology network, the cloud server 500 may further perform model-oriented knowledge trimming and secure distribution to adapt to the resource-constrained terminal device 200, ensuring that the terminal device 200 only loads the topology network that is highly related to its own hardware configuration and historical issues.

[0189] The cloud server 500 can extract nodes and edges related only to the specific hardware configuration of the terminal device 200 from the global topology network based on the device model identifier of the terminal device 200, forming an initial topology network. Subsequently, this initial topology network can be refined using knowledge distillation techniques, including merging redundant nodes with highly similar functions and failure modes, and removing occasional low-frequency interference items unrelated to common faults. Then, the topology network can be serialized into a compressed and encrypted JSON format, ensuring its data size is less than a preset size (e.g., 200KB) to accommodate the storage and network transmission limitations of the terminal device 200.

[0190] The network topology is distributed to the corresponding terminal device 200 via a secure OTA channel, allowing the terminal device 200 to store it in a local encrypted cache for self-testing upon startup. Furthermore, the cloud server 500 supports incremental updates to the topology map (distributing only the changed portions) and version rollback capabilities (quickly restoring to the previous stable version when an anomaly is detected in the new version), thus ensuring reliable management of the topology map.

[0191] like Figure 5 The diagram illustrates the interaction between the cloud server 500 and the terminal device 200 in this embodiment of the application, specifically including the following steps:

[0192] S501, after the terminal device 200 is powered on, it obtains its own device model.

[0193] Among them, the terminal device 200 can obtain the device model through the model field in the device firmware.

[0194] S502, terminal device 200 sends a request to cloud server 500 to obtain the device model.

[0195] The request is used to request the topology network corresponding to the device model from the cloud server 500.

[0196] S503, in response to the retrieval request, cloud server 500 determines the device model and extracts the topology network corresponding to the device model from the stored global topology network.

[0197] In some embodiments, the cloud server 500 can filter out a first functional node, a second functional node, and the edges corresponding to the first functional node and the second functional node from the stored global topology network to form a topology network.

[0198] The first functional node is a functional node that serves as the root cause of a fault (point a) in historical self-test fault cases corresponding to the device model, or has a self-test point (point K) in the terminal device 200 corresponding to the device model, i.e., a functional node with self-test capabilities. The second functional node is a functional node that depends on the first functional node, and can be an upstream or downstream node of the first functional node to ensure the integrity of the fault propagation path.

[0199] In some embodiments, to improve terminal inference efficiency, the cloud server 500 can perform knowledge distillation on the extracted topology network. The cloud server 500 can group semantically similar failure descriptions from historical self-test failure cases within the topology network into unified labels. For example, descriptions such as "EDID parsing failure," "Invalid DTD (Detailed Timing Descriptor)," and "CEA (Consumer Electronics Association) extension block error" can be uniformly categorized into "EDID anomaly."

[0200] The cloud server 500 can also remove functional nodes and their associated edges in the topology network whose first index is less than a preset threshold (such as 0.5) based on the first index of the functional nodes, in order to avoid noise interference.

[0201] For cases where the same functional node corresponds to multiple self-check points (K points), the cloud server 500 can also sort them according to the second indicator of each check point (K point), retaining only the top N items with the highest scores (e.g., N=2) as the primary self-check points, and marking the rest as backup self-check points.

[0202] Based on the above data processing, the data volume of the topology network can be compressed to adapt to the storage and network transmission limitations of the terminal device 200.

[0203] S504, cloud server 500 sends the network topology to terminal device 200.

[0204] In some embodiments, the cloud server 500 may use a symmetric encryption algorithm (such as Advanced Encryption Standard-128, AES-128) to encrypt the transmission of the topology network. The encryption key is generated by a key derivation function from the unique identifier of the terminal device 200 (such as a serial number), ensuring that the topology network cannot be deciphered or tampered with.

[0205] In some embodiments, the cloud server 500 can attach a digital signature (such as a Hash-Based Message Authentication Code - Secure HashAlgorithm 256, HMAC-SHA256) to the topology network to ensure that the topology network is not damaged, replaced, or tampered with during transmission and storage. In response, after obtaining the topology network, the terminal device 200 can first verify the digital signature, and if the verification passes, store the topology network.

[0206] S505, the terminal device 200 receives the topology network sent by the cloud server 500, stores the topology network in the memory, or updates the topology network already stored in the memory according to the topology network.

[0207] The topology network stored in the memory is used for the next boot process.

[0208] In some embodiments, the global topology network maintained in the cloud server 500 is dynamically updated based on newly added self-check fault cases. To reduce the amount of transmitted data and traffic consumption, after extracting the topology network that needs to be sent to the terminal device 200 from the global topology network, the cloud server 500 can obtain the topology network sent last time, calculate the differences between the two versions, and send the differences to the terminal device 200. The terminal device 200 receives the differences and updates the topology network stored in its memory according to the differences to complete the topology network update.

[0209] In some embodiments, the terminal device 200 may store the received topology network to a secure storage area, such as a secure world memory area based on the Trust Zone architecture, or a replay protection memory block partition of eMMC (embedded Multi Media Card) flash memory, for use during the power-on self-test phase.

[0210] In some embodiments, the memory of the terminal device 200 may simultaneously store a first version of the topology network and a second version of the topology network, wherein the first version is an updated version preceding the second version.

[0211] During the power-on process, the terminal device 200 can first retrieve the second version of the topology network from the memory and verify it. If the verification of the second version of the topology network is successful, then proceed to the next step S403 or S404. If the verification of the second version of the topology network fails, then retrieve the first version of the topology network and verify it. If the verification of the first version of the topology network is successful, then proceed to the next step S403 or S404. If the verification of the first version of the topology network fails, then execute the preset security self-test process, performing a full-scale universality test on all functional modules.

[0212] The terminal device 200 stores two versions of the topology network in its memory. This allows it to revert to the previous version of the topology network if the current version is faulty, thus avoiding a situation where there is no usable topology network during the boot process.

[0213] In some embodiments, verifying the topology network means verifying the integrity of the topology network and determining whether it has been tampered with or damaged. If it has not been tampered with or damaged, the verification is successful, and the current version of the topology network is used. If it has been tampered with or damaged, the verification fails, and the network reverts to the previous version of the topology network.

[0214] It should be noted that the acquisition and verification of the topology network can be completed in the early stages of kernel startup and before user space service initialization. The processing time can be controlled within 50 milliseconds, and the impact on the overall boot time is negligible. Thus, while ensuring security and reliability, the requirements for fast boot are met.

[0215] S403 creates a self-test task for each functional node based on the network topology.

[0216] The self-test task is used to detect the status of functional nodes.

[0217] In some embodiments, such as Figure 6 The diagram shown is a flowchart illustrating the creation of a self-test task according to an embodiment of this application, specifically including the following steps:

[0218] S601, parse the topology network to obtain the dependencies between functional nodes and the list of self-check points corresponding to the functional nodes.

[0219] The self-test point list includes self-test points (K points) corresponding to each functional node, as shown in Table 2 above, such as "EDID read verification" and "12V power supply ripple detection". Each self-test point (K point) corresponds to a specific detection action preset in the system. The dependencies between functional nodes include power supply dependencies, data dependencies, and control dependencies, as shown in Table 3 above.

[0220] S602, based on dependencies, creates a self-check task for each self-check point (K point).

[0221] The terminal device 200 performs the self-test task, that is, it performs tests on the functional nodes according to the specific test actions corresponding to the self-test point (K point), obtains the test results, and analyzes the test results based on the dependency relationship.

[0222] In some embodiments, the self-test process focuses primarily on collecting basic physical layer parameters such as voltage, current, and connectivity. This shallow testing neglects deeper parameters such as protocol-level, configuration-level, and timing-level failure characteristics. For example, for an HDMI interface, the terminal device 200 only checks whether its power supply is normal, but cannot detect deeper issues such as communication protocol handshake failures, data verification errors, or clock timing lockouts. Consequently, many soft faults caused by software configuration, protocol mismatches, or timing drift cannot be effectively identified and intercepted during the boot-up phase, thus affecting subsequent system operation.

[0223] To ensure that the self-test results can truly and accurately reflect the hardware status of the terminal device 200 in a specific scenario, and to avoid misjudgment or omission due to factors such as improper information collection timing, single feature dimension, or environmental interference, this application sets up a self-test strategy with a multi-dimensional constraint information collection and feature extraction mechanism based on the hardware architecture characteristics and usage scenarios of the terminal device 200. The self-test strategy includes self-test time points, self-test methods, and self-test conditions, which are used to instruct the terminal device 200 to perform functional node testing at a specific time point, in a specific way, and under specific conditions, to capture deep state features that are highly correlated with specific fault modes, rather than relying solely on traditional basic electrical parameters or status flags, thereby improving the accuracy of detection.

[0224] The cloud server 500 can uniformly maintain the self-test policies corresponding to the self-test points (K points) of different terminal device models through a self-test policy library. The terminal device 200 can obtain the self-test policies from the cloud server 500 in advance via over-the-air download technology and store them in its memory for use during the power-on self-test phase.

[0225] In some embodiments, the terminal device 200 sends a request to the cloud server 500 to obtain the device model. In response to the request, the cloud server 500 determines the device model of the terminal device 200, and based on the device model, determines the self-test points (K points) that the terminal device 200 has, searches for the self-test policy corresponding to each self-test point (K point) in the maintained self-test policy library, and sends the self-test policy to the terminal device 200.

[0226] In some embodiments, when the cloud server 500 sends the topology network to the terminal device 200, it can simultaneously send the self-test strategy corresponding to each self-test point (K point) in the terminal device 200.

[0227] In some embodiments, such as Figure 7 The diagram shown illustrates another process for creating a self-test task according to an embodiment of this application, specifically including the following steps:

[0228] S701, parse the topology network to obtain the dependencies between functional nodes and the list of self-check points corresponding to the functional nodes.

[0229] The implementation details of step S701 can be found in step S601, and will not be repeated here.

[0230] S702, obtain the self-test strategy corresponding to each self-test point (K point).

[0231] The self-test strategy includes self-test time points, self-test methods, and self-test conditions. The self-test time point indicates the time at which node status information is collected when testing functional nodes. The self-test method indicates the specific method used to collect node status information when testing functional nodes. The self-test conditions indicate the conditions that the collected node status information must meet when testing functional nodes.

[0232] S703 creates a self-check task for each self-check point (K point) based on the self-check strategy and dependencies.

[0233] The terminal device 200 performs the self-test task, that is, it tests the functional nodes according to the self-test strategy, obtains the test results, and analyzes the test results based on the dependency relationship.

[0234] In some embodiments, when testing functional nodes, much critical information is only valid within a short window period following a specific hardware event. If this window is missed, the acquired data will be distorted or invalid. Therefore, the terminal device 200 can ensure that the information collection process is triggered within the critical window period based on the self-test time point.

[0235] For example, for the self-test of the HDMI interface, the hot plug detection (HPD) signal of the HDMI interface can be continuously monitored. Only when the HPD signal is detected to transition from low to high (indicating that the cable is plugged in or the device is powered on) will the corresponding self-test task for EDID reading and verification be initiated, and the I-test will be completed within 100 milliseconds after the transition. 2 The C bus actively reads the EDID data.

[0236] For example, the self-test process of the power management module can monitor the voltage value of the main power supply rail (such as 12V). Only when the voltage enters a stable state and remains stable for more than a preset time, that is, the voltage fluctuation amplitude is less than or equal to ±2% of the nominal value within 10 milliseconds, ripple sampling is initiated to avoid false alarms caused by power-on transient interference.

[0237] In some embodiments, the terminal device 200 can extract structured failure features by delving into the protocol layer according to a self-test method.

[0238] For example, when performing the self-test task corresponding to EDID read verification, it can be done through the internal integrated circuit (Inter-Integrated Circuit, I... 2 C) The bus actively accesses the EDID memory of the external device (usually located at address 0x50), reads the complete 128-byte EDID data block, and parses the key fields, including the pixel clock frequency, horizontal / vertical sync pulse width, list of color formats and resolutions supported by the interface, manufacturer identification and product code, etc. in the detailed timing descriptor (DTD).

[0239] Such protocol compliance features can accurately identify source device output exceeding limits or sink device compatibility issues, far superior to simply judging the presence or absence of a signal. Similarly, for Wi-Fi modules, in addition to reading RSSI, MAC (Media Access Control) layer indicators such as frame retransmission rate and channel interference index are also calculated to distinguish between weak network conditions and module failures.

[0240] In some embodiments, when detecting functional nodes, some faults are related to the external environment or user behavior. In response, the terminal device 200 can introduce a context-aware mechanism based on self-test conditions to dynamically adjust the detection strategy.

[0241] For example, it can be linked with meteorological conditions. When the terminal device 200 identifies itself as being in a high-incidence area of ​​thunderstorms through IP address location and the current time is thunderstorm season, it will automatically enable the enhanced power rail monitoring mode during the power-on self-test, increase the power rail ripple sampling rate to a preset threshold, and extend the sampling time, such as increasing the sampling rate from 1kHz to 10kHz and extending the sampling time to 500 milliseconds, in order to capture transient surges or voltage drops.

[0242] For example, user behavior pattern recognition can be added. If the detected historical data shows that the user frequently switches HDMI input sources, such as more than a preset threshold (e.g., 5 times per hour), it can be determined that the user may be using non-standard cables or inferior splitters. In this case, an HDMI CEC bus stress test will be forced to be performed during the next boot process to verify the robustness of the protocol handshake.

[0243] S404, in the topology network, the first and second indicators corresponding to the parsing function nodes.

[0244] The first indicator shows the historical frequency of a functional node as a root cause of failure (point a). The second indicator shows the effectiveness score of a functional node as a self-test point (point K).

[0245] S405, calculate the priority of each self-test task based on the first and second indicators.

[0246] Priority is used to indicate the execution order of self-test tasks.

[0247] In some embodiments, the terminal device 200 can calculate the priority score of each self-test task based on a first indicator and a second indicator to determine the priority of each self-test task. The priority score characterizes the priority of the self-test task and is positively correlated with the first and second indicators. The first indicator is the sum of the products of the severity weight of the functional node as the root cause (point a) in all historical self-test failure cases and the time decay factor, as described in Formula 1 above. The second indicator is the ratio of a second statistical value to a first statistical value. The first statistical value is the number of times a functional node should be detected in historical self-test failure cases where it is the root cause (point a), and the second statistical value is the number of times it is actually detected in historical self-test failure cases where it is the root cause (point a), as described in Formula 2 above.

[0248] In some embodiments, for calculating the priority score, the terminal device 200 can obtain a first weighting coefficient and a second weighting coefficient. The product of the first weighting coefficient and a first indicator is calculated to obtain a first score, and the product of the second weighting coefficient and a second indicator is calculated to obtain a second score. Finally, the sum of the first score and the second score is calculated to obtain the priority score.

[0249] The sum of the first weight coefficient and the second weight coefficient is 1, and the first weight coefficient is greater than the second weight coefficient.

[0250] For example, terminal device 200 can use a weighted linear combination model to calculate the priority score. The priority score can be calculated based on formula 3, which is shown below:

[0251] × + × ;

[0252] in, As the primary indicator, As the second indicator, As the first weighting coefficient, For the second weighting coefficients, α and It is a configurable item and satisfies In one embodiment, , This emphasizes the dominant role of historical fault exposure frequency in risk ranking while also considering the reliability of detection methods. In some embodiments, if a functional node's... If the value is 0 (the functional node has never caused a fault in the terminal device 200 of this device model), then the priority score of all its self-test points (K points) can be set to zero to skip the active detection of the functional node, thereby avoiding redundant operations on the stable module.

[0253] In some embodiments, the terminal device 200 may determine the priority score of each self-test task, sort the multiple self-test tasks in descending order of priority scores to obtain a self-test task list, and execute the multiple self-test tasks sequentially according to the self-test task list.

[0254] For example, the self-test task corresponding to "EDID Read Verification" of the HDMI receiver has a priority score of 19.3; the self-test task corresponding to "12V Ripple Detection" of the power management module has a priority score of 15.7; and the self-test task corresponding to "RSSI Threshold Monitoring" of the wireless communication module has a priority score of 4.2. These self-test tasks can be sorted from highest to lowest priority to form an ordered self-test task list. During the power-on self-test process, the corresponding self-test tasks are executed sequentially for the HDMI receiver, power management module, and wireless communication module according to this list.

[0255] In some embodiments, the self-test task list is not a static list and can be dynamically adjusted at runtime. That is, if the hardware resources depended by the currently executing self-test task are occupied by a higher-priority self-test task, the terminal device 200 can mark the self-test task as waiting and continue to execute the next self-test task with the highest priority score and available resources. When the occupied hardware resources are released, the self-test tasks that were in the waiting state can be executed retroactively.

[0256] In some embodiments, in resource-constrained embedded Linux or RTOS environments, a Ka lightweight inference engine can be deployed on the main control SOC in the terminal device 200. After the topology network is loaded, the Ka lightweight inference engine is activated. This engine adopts a rule-driven lightweight inference architecture, does not rely on neural networks or large models, and requires only a small amount of runtime memory. The Ka lightweight inference engine can parse the topology network, extract the first and second indicators corresponding to the functional nodes, and identify one or more self-check points (K-points) associated with each functional node, as well as the dependencies between functional nodes.

[0257] For each self-check point (K-point), the Ka lightweight inference engine calculates its priority based on the first and second metrics of its associated functional node. It then generates a K-point priority list, sorted from highest to lowest priority score. The Ka lightweight inference engine inputs this K-point priority list into the self-check scheduler to indicate which checks should be prioritized, which can be down-clocked, or omitted. The self-check scheduler receives the K-point priority list from the Ka lightweight inference engine and creates a corresponding self-check task for each self-check point (K-point). Each self-check task can contain the following information:

[0258] Related functional modules (e.g., "HDMI receiver");

[0259] Specific detection actions (such as "EDID read verification");

[0260] Priority score;

[0261] Related self-testing strategies (such as "execute only after HPD signal transition").

[0262] The self-test scheduler transforms the K-point priority list into an executable self-test task list and implements differentiated execution strategies based on task importance, thereby replacing the traditional fixed-sequence power-on self-test process and improving self-test efficiency and targeting.

[0263] S406, based on priority, divides self-test tasks into Level 1 self-test tasks, Level 2 self-test tasks, and Level 3 self-test tasks.

[0264] After determining the priority of each self-test task, the terminal device 200 can divide the self-test tasks according to the priority, dividing all self-test tasks into first-level self-test tasks, second-level self-test tasks, and third-level self-test tasks, so as to execute the self-test tasks in a hierarchical manner.

[0265] In some embodiments, such as Figure 8 The diagram shown is a flowchart illustrating the self-test task division provided in this embodiment of the application, which specifically includes the following steps:

[0266] S801, determine the first threshold and the second threshold.

[0267] The first threshold and the second threshold are preset, with the first threshold being greater than the second threshold. For example, the first threshold is 10 and the second threshold is 5.

[0268] S802 compares the first threshold and the second threshold with the priority score of the self-test task, respectively.

[0269] The priority score is calculated based on the first and second indicators, as shown in Formula 3 above.

[0270] S803: If the priority score is greater than or equal to the first threshold, the self-test task is determined to be a level 1 self-test task.

[0271] S804: If the priority score is less than the first threshold but greater than or equal to the second threshold, the self-test task is determined to be a level 2 self-test task.

[0272] S805: If the priority score is less than the second threshold, the self-test task is determined to be a level 3 self-test task.

[0273] In this embodiment, the terminal device 200 calculates a specific priority score based on the first indicator and the second indicator, and introduces a first threshold and a second threshold. By comparing the first threshold, the second threshold and the priority score, the self-inspection task is divided to improve the accuracy of task classification.

[0274] S407 performs a Level 1 self-test.

[0275] After determining the Level 1 self-test task, Level 2 self-test task, and Level 3 self-test task, the terminal device 200 can immediately execute the high-priority Level 1 self-test task during the power-on process.

[0276] In some embodiments, for multiple Level 1 self-test tasks, the terminal device 200 can determine the priority score of each Level 1 self-test task, sort the multiple Level 1 self-test tasks in descending order of priority scores to obtain a list of Level 1 self-test tasks, and execute the multiple Level 1 self-test tasks sequentially according to the list of Level 1 self-test tasks.

[0277] S408, if the detection result of the first-level self-test task indicates an abnormality, the power-on process of the terminal device 200 is interrupted.

[0278] S409, if the results of the Level 1 self-test indicate that everything is normal, continue the power-on process of the terminal device 200.

[0279] The Level 1 self-test task is typically associated with high-frequency fault modules (such as power supply and HDMI), and its test results directly affect whether the terminal device 200 can operate normally. Therefore, if the Level 1 self-test result indicates normal operation, the subsequent power-on process continues; if the Level 1 self-test result indicates abnormal operation, the power-off process is interrupted, and the fault handling stage is entered directly.

[0280] In some embodiments, for the boot process of terminal device 200, a first-level self-test task can be executed synchronously when the init process reaches the early-init stage.

[0281] S410, in response to the broadcast that the core system service of the terminal device 200 has been started and completed, loads and controls the display 260 to display the user interface, and at the same time performs the secondary self-test task asynchronously through a background thread.

[0282] The risk of failure for the secondary self-test tasks is low (such as Wi-Fi signal quality monitoring, sensor calibration, etc.), and their test results do not affect the startup and operation of the terminal device 200. Therefore, after the core system services have started, the secondary self-test tasks can be executed asynchronously through a background thread. The test results do not affect the normal startup process of the terminal device 200, that is, even if the test results of the secondary self-test task indicate abnormalities, the startup process of the terminal device 200 will not be interrupted.

[0283] In some embodiments, in order to improve the user experience, if the detection result of the secondary self-test task indicates an abnormality, the terminal device 200 may display an abnormality prompt message in the user interface after the control display 260 displays the user interface, so as to prompt the user that the functional node corresponding to the secondary self-test task is abnormal.

[0284] S411, after the terminal device 200 is powered on, executes a three-level self-test task in response to preset trigger conditions.

[0285] The results of the Level 3 self-test task do not affect the operation of the terminal device 200. During the power-on process, the Level 3 self-test task can be skipped and will only be executed based on preset trigger conditions after the terminal device 200 is powered on.

[0286] The triggering conditions include, but are not limited to, the start command of the functional module corresponding to the three-level self-test task, the command for a comprehensive diagnosis initiated manually by the user, the device entering maintenance mode, or the cloud management platform issuing a mandatory test command based on analysis strategies. This mechanism avoids redundant testing of long-term stable modules (such as audio decoding chips and low-speed peripheral interfaces) during the power-on phase, thereby minimizing power-on time while ensuring reliability.

[0287] In some embodiments, such as Figure 9 The diagram shown is a flowchart illustrating the execution of a three-level self-test task according to an embodiment of this application, specifically including the following steps:

[0288] S901, after the terminal device 200 is powered on, responds to the startup command of the functional node and checks whether there are any unexecuted level 3 self-test tasks on the functional node.

[0289] S902, if there are unexecuted level 3 self-check tasks on the functional node, execute the level 3 self-check task corresponding to the functional node.

[0290] S903, if the test results of the Level 3 self-test indicate that everything is normal, starts the functional node.

[0291] S904, if the test result of the Level 3 self-test task indicates an abnormality, the control display 260 will show an abnormality prompt message.

[0292] For example, terminal device 200 is equipped with a dedicated audio decoding chip. During the boot process, if the self-test task corresponding to the audio decoding chip is determined to be a level 3 self-test task based on the network topology, then the execution of the level 3 self-test task corresponding to the audio decoding chip is skipped during the boot process. After terminal device 200 boots up, when the user launches the music playback application installed on terminal device 200, the audio decoding chip needs to be called. If an unexecuted level 3 self-test task is detected, the level 3 self-test task corresponding to the audio decoding chip is triggered to ensure that the audio decoding chip meets the audio playback requirements of the music playback application. If the level 3 self-test task passes, the audio decoding chip is called, and the music playback application starts normally. If the level 3 self-test task fails, an error message is generated and the display 260 is controlled to display an error message to inform the user that the audio decoding chip is malfunctioning.

[0293] In some embodiments, in order to improve the user experience, if the detection result of the secondary self-test task indicates an abnormality, the terminal device 200 may display an abnormality prompt message in the user interface after the control display 260 displays the user interface, so as to prompt the user that the functional node corresponding to the secondary self-test task is abnormal.

[0294] In the above embodiments, the self-test task is divided into Level 1, Level 2, and Level 3 self-test tasks. This allows for differentiated management based on the severity of the fault, the urgency of the test, and resource utilization. Level 1 self-test tasks prioritize testing high-frequency, high-risk core functional modules (such as power supplies and main control chips) during the power-on phase, immediately halting the power-off process in case of anomalies to prevent fault propagation and ensure equipment safety. Level 2 self-test tasks asynchronously execute tests on non-core functional modules (such as Wi-Fi and common interfaces) in the background during the power-on phase, without blocking the power-on process, balancing power-on speed and comprehensive testing. Level 3 self-test tasks trigger corresponding functional module tests only under specific conditions, avoiding redundant testing during the power-on phase.

[0295] Compared with existing technologies, traditional self-testing either uses full-scale testing, resulting in long startup times, or relies solely on experience to select mandatory items, leading to omissions of critical items or inaccurate testing. This application maximizes and optimizes testing accuracy and startup speed while ensuring equipment safety and comprehensive testing by classifying self-testing tasks.

[0296] In some embodiments, for terminal devices 200 configured with Android or Linux systems, the self-test scheduler, as a core component of the init phase, is integrated into the underlying startup framework of the operating system. It is loaded during the early-init phase of system startup. The scheduler can load and parse the topology network to determine the first-level, second-level, and third-level self-test tasks, and then initiate the first-level self-test task. After the core system services have completed initialization and issued a BOOT_COMPLETED broadcast, the self-test scheduler can further respond to the broadcast and initiate the second-level self-test task in the background.

[0297] For all self-test tasks, the self-test scheduler can interact with the underlying driver by calling preset interfaces in the module health probe library. Furthermore, the self-test scheduler supports an interrupt response mechanism. When any self-test task detects a critical fault (such as a core power rail voltage collapse), the scheduler can immediately suspend subsequent self-test tasks and execute system-level protection procedures according to preset safety policies, thereby preventing fault propagation or secondary damage.

[0298] In some embodiments, when analyzing the detection results, the terminal device 200 may determine that the detection result indicates an abnormality and identify the functional node as the root cause of the fault (point a) if the input state of the detection result indicates that the input state of the functional node is normal but the output state is abnormal.

[0299] In some embodiments, the terminal device 200 determines whether a functional node is a fault root cause (point a) by using structured root cause determination rules. Not all abnormal self-test points (point K) are directly equivalent to their respective functional modules being fault root causes (point a). To avoid misjudgment, the terminal device 200 can perform input status detection and output status detection.

[0300] For input status detection, terminal device 200 checks whether the upstream input of the functional node is normal. For example, for an HDMI receiver, terminal device 200 needs to check whether its HPD signal status is valid, whether the source device is online, and whether the power supply voltage / clock signal meets the specifications. If all of the above conditions are passed, the input status of the functional node is determined to be normal.

[0301] For output status detection, the terminal device 200 checks whether the output of this functional node is normal. For example, whether EDID reading returns a null value, whether the TMDS clock is locked, and whether video stream parsing fails.

[0302] Based on the above checks, a functional module is determined to be the root cause of the fault (point a) only when the input state is normal but the output state is abnormal. This determination logic follows the definition of root cause nodes in the Ka analysis method and ensures the accuracy of root cause location through dual-state cross-validation.

[0303] In some embodiments, the terminal device 200 may store a self-healing operation library in a memory. The self-healing operation library is generated based on historical self-test failure cases and includes one or more self-healing operations corresponding to each functional node, which can be invoked when a functional node is detected as the root cause of a failure (point a).

[0304] like Figure 10 The diagram shown is a flowchart illustrating the self-healing operation performed according to an embodiment of this application, specifically including the following steps:

[0305] S1001, if the detection result of the Level 1 self-test task is abnormal, or if the detection result of the Level 2 self-test task is abnormal, or if the detection result of the Level 3 self-test task is abnormal, determine the target functional node as the root cause of the fault (point a).

[0306] When performing a level 1 self-test, level 2 self-test, or level 3 self-test, the terminal device 200 can identify the target functional node as the root cause of the fault (point a) and trigger the execution of the corresponding self-healing operation to restore the normal operation of the functional module.

[0307] S1002, call the self-healing operation library.

[0308] The self-healing operation library includes one or more self-healing operations corresponding to each functional node in the terminal device 200.

[0309] For example, as shown in Table 4, here is an example of the contents of the self-healing operation library provided in the embodiments of this application:

[0310] Table 4

[0311]

[0312] S1003, in the self-healing operation library, query the self-healing operation corresponding to the target function node.

[0313] After the terminal device 200 calls the self-healing operation library, it can query the corresponding self-healing operation in the self-healing operation library.

[0314] S1004, Perform self-healing operation on the target functional node.

[0315] After determining the self-healing operation corresponding to the target functional node, the terminal device 200 can execute the self-healing operation in sequence. If any self-healing operation successfully restores the function of the target functional node (such as HDMI re-outputting a valid video stream), the execution of subsequent self-healing operations will stop. If the function of the target functional node is not restored after all self-healing operations are completed, a security degradation mode will be entered (such as switching to composite video signal (AV) input, displaying a maintenance QR code), and high-risk operations (such as disabling video playback in 4K HDR mode) will be prohibited.

[0316] In some embodiments, the terminal device 200 can generate a self-test fault case based on the self-test task information of the self-test task and send it to the cloud server 500 so that the cloud server 500 can update the global topology network based on the self-test fault case.

[0317] like Figure 11 The diagram shown illustrates the interaction between the terminal device 200 and the cloud server 500 in an embodiment of this application, specifically including the following steps:

[0318] S1101, In the event of an abnormal result indication from a Level 1 self-test task, or in the event of an abnormal result indication from a Level 2 self-test task, or in the event of an abnormal result indication from a Level 3 self-test task, obtain self-test task information.

[0319] When performing a self-test task, the terminal device 200 can collect raw data generated during the task execution process, including the execution results of each test point, timing information, relevant hardware status register values, and environmental context parameters, to form structured self-test task information.

[0320] S1102, Generate self-test fault cases based on self-test task information.

[0321] After determining the self-test task information, the terminal device 200 can generate standardized self-test fault cases by combining its own device model, firmware version, and topology network version identifier.

[0322] Self-test failure cases include, but are not limited to, the following information:

[0323] Fault symptom coding;

[0324] The determination point 'a' and the trigger point 'K';

[0325] The self-healing actions performed and their results (success / failure);

[0326] Device model, firmware version, and environmental context (such as geographical location and weather).

[0327] In some embodiments, to improve boot speed, when the terminal device 200 performs a first-level self-test task, if the test result of the first-level self-test task indicates an abnormality, the self-test task information is first stored in a specific area of ​​the memory. After the terminal device 200 boots up, the self-test task information is retrieved from the memory, and a self-test fault case is generated based on the self-test task information.

[0328] S1103 sends a self-test fault case to cloud server 500.

[0329] Terminal device 200 can upload the generated self-test fault cases to cloud server 500 through OTA channel.

[0330] S1104, Cloud Server 500 updates the global topology network based on self-test fault cases.

[0331] After receiving the self-test fault cases sent by the terminal device 200, the cloud server 500 updates the global topology network through data analysis, including correcting the first and second indicators of the functional nodes of the corresponding device model, updating the structure of the topology network, etc., to form a new version of the global topology network.

[0332] In some embodiments, after receiving self-test fault cases sent by terminal device 200, cloud server 500 can optimize and update the corresponding self-test strategy based on the self-test fault cases.

[0333] Based on the aforementioned terminal device 200, this application embodiment also provides a terminal device self-testing method based on cloud collaboration, such as... Figure 4 As shown, the method may include the following steps:

[0334] S401, in response to the power-on command of the terminal device, starts the kernel of the terminal device.

[0335] S402 retrieves the topology network from memory after the kernel boot process is complete.

[0336] The topology network is obtained in advance from the cloud server 500 via over-the-air download technology. The topology network includes functional nodes and edges. Functional nodes are used to represent functional modules in terminal devices, and edges are used to represent the dependencies between functional nodes. Functional nodes are labeled with a first indicator and a second indicator. The first indicator is used to indicate the historical frequency of the functional node as a root cause of failure (point a), and the second indicator is used to indicate the effectiveness score of the functional node as a self-test point.

[0337] S403 creates a self-test task for each functional node based on the network topology.

[0338] S404, in the topology network, the first and second indicators corresponding to the parsing function nodes.

[0339] S405, calculate the priority of each self-test task based on the first and second indicators.

[0340] S406, based on priority, divides self-test tasks into Level 1 self-test tasks, Level 2 self-test tasks, and Level 3 self-test tasks.

[0341] S407 performs a Level 1 self-test.

[0342] S408: If the result of the Level 1 self-test indicates an abnormality, the power-on process of the terminal device will be interrupted.

[0343] S409: If the results of the Level 1 self-test indicate that everything is normal, continue the power-on process of the terminal device.

[0344] S410, in response to a broadcast indicating that the core system services of the terminal device have been started, loads and controls the display to show the user interface, while simultaneously executing a secondary self-test task asynchronously through a background thread.

[0345] In cases where the results of the Level 2 self-test indicate an abnormality, the power-on process of the terminal device will not be interrupted.

[0346] S411 performs a three-level self-test task in response to preset trigger conditions after the terminal device is powered on.

[0347] It is understood that the terminal device self-testing method based on cloud collaboration in this application embodiment can refer to the above-described terminal device 200 embodiment and can adopt the same principle, which will not be elaborated here.

[0348] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the described embodiments and various different variations of embodiments suitable for specific use considerations.

Claims

1. A terminal device, characterized by comprising: include: The communication device is configured to establish a communication connection with a cloud server. The memory is configured as a storage topology network; The topology network is obtained in advance from the cloud server via over-the-air download technology. The topology network includes functional nodes and edges. The functional nodes are used to characterize the functional modules in the terminal device, and the edges are used to characterize the dependencies between the functional nodes. The functional nodes are labeled with a first indicator and a second indicator. The first indicator is used to indicate the historical frequency of the functional node as a source of failure, and the second indicator is used to indicate the effectiveness score of the functional node as a self-test point. The monitor is configured to display the user interface; The controller is configured as follows: In response to the power-on command of the terminal device, the kernel of the terminal device is started; After the kernel boots up, the topology network is obtained; Based on the topology network, create a self-test task for each of the functional nodes; In the topology network, the first indicator and the second indicator corresponding to the functional node are parsed; Calculate the priority of each self-test task based on the first indicator and the second indicator; Based on the priority, the self-test tasks are divided into Level 1 self-test tasks, Level 2 self-test tasks, and Level 3 self-test tasks; Perform the first-level self-test task; If the detection result of the first-level self-test task indicates an abnormality, the power-on process of the terminal device shall be interrupted. If the result of the first-level self-test task is normal, the power-on process of the terminal device continues to be executed, and in response to the broadcast that the core system services of the terminal device have been started and completed, the display is loaded and the user interface is controlled to be displayed. At the same time, the second-level self-test task is executed asynchronously through a background thread. If the result of the second-level self-test task is abnormal, the power-on process of the terminal device is not interrupted. After the terminal device is powered on, it executes the three-level self-test task in response to preset trigger conditions.

2. The terminal device according to claim 1, characterized by The controller, based on the priority, divides the self-test task into level one, level two, and level three self-test tasks, and is configured as follows: Based on the first indicator and the second indicator, a priority score is calculated for each self-test task; wherein, the priority score is used to characterize the priority of the self-test task, and the priority score is positively correlated with the first indicator and the second indicator; the first indicator is the sum of the products of the severity weight of the functional node as the root cause of the fault and the time decay factor in all historical self-test fault cases; the second indicator is the ratio of a second statistical value to a first statistical value, wherein the first statistical value is the number of times the functional node should be detected in historical self-test fault cases where the functional node is the root cause of the fault, and the second statistical value is the number of times the functional node is actually detected in historical self-test fault cases where the functional node is the root cause of the fault; If the priority score is greater than or equal to the first threshold, the self-test task is determined to be the first-level self-test task; If the priority score is less than the first threshold and greater than or equal to the second threshold, the self-test task is determined to be the second-level self-test task. If the priority score is less than the second threshold, the self-test task is determined to be the level 3 self-test task; Wherein, the first threshold is greater than the second threshold.

3. The terminal device according to claim 2, characterized by The controller calculates a priority score for each self-test task based on the first and second indicators, and is configured as follows: Obtain a first weighting coefficient and a second weighting coefficient; wherein the sum of the first weighting coefficient and the second weighting coefficient is 1, and the first weighting coefficient is greater than the second weighting coefficient; Calculate the product of the first weighting coefficient and the first index to obtain the first score; Calculate the product of the second weighting coefficient and the second indicator to obtain the second score; The priority score is obtained by summing the first score and the second score.

4. The terminal device according to claim 2, characterized by The first-level self-test task includes multiple tasks, and the controller executes the first-level self-test task and is further configured to: Determine the priority score for each of the first-level self-inspection tasks; The multiple Level 1 self-check tasks are sorted in descending order of priority scores to obtain a list of Level 1 self-check tasks. According to the list of first-level self-check tasks, execute multiple first-level self-check tasks in sequence.

5. The terminal device according to claim 1, characterized by The memory is also configured to store a self-test strategy; the self-test strategy is pre-obtained from the cloud server via over-the-air download technology; after the controller acquires the topology network, it is further configured to: The topology network is parsed to obtain the dependencies between the functional nodes and the list of self-check points corresponding to the functional nodes; wherein, the dependencies include power supply dependencies, data dependencies, and control dependencies, and the list of self-check points includes the self-check points corresponding to the functional nodes; Obtain the self-test strategy corresponding to each self-test point; wherein, the self-test strategy includes self-test time point, self-test method, and self-test conditions; Based on the self-check strategy and the dependency relationship, create a self-check task for each self-check point; When performing the self-test task, the functional nodes are tested according to the self-test strategy to obtain the test results, and the test results are analyzed according to the dependency relationship. If the detection result indicates that the input state of the functional node is normal but the output state is abnormal, the detection result is determined to be abnormal, and the functional node is determined to be the root cause of the fault.

6. The terminal device of claim 1, wherein, The cloud server stores a global topology network generated based on historical self-test fault cases corresponding to multiple terminal device models. The controller is also configured to: After the terminal device is powered on, the device model of the terminal device is obtained; Send a request carrying the device model to the cloud server. The request is used to request the topology network corresponding to the device model from the cloud server. The topology network includes a first functional node and a second functional node. The first functional node is the root cause of the fault in the historical self-test fault cases corresponding to the device model or has a self-test point in the terminal device corresponding to the device model. The second functional node is a functional node that has a dependency relationship with the first functional node. The device receives the topology network fed back from the cloud server and updates the topology network stored in the memory according to the topology network; wherein the updated topology network is applied to the next boot process of the terminal device.

7. The terminal device according to claim 1, characterized in that, The memory is configured to store a first version of the topology network and a second version of the topology network, wherein the first version is an earlier update of the second version; the controller is configured after the kernel boots up to: Obtain the second version of the topology network; Verify the topology network of the second version; If the second version of the topology network verification passes, a self-test task is created for each of the functional nodes according to the second version of the topology network; If the second version of the topology network fails the verification, obtain the first version of the topology network; Verify the topology network of the first version; If the first version of the topology network verification passes, a self-test task is created for each of the functional nodes based on the first version of the topology network. If the topology network verification fails in the first version, a preset security self-check process is executed.

8. The terminal device according to claim 6, characterized by The controller is also configured to: If the detection result of the first-level self-test task is abnormal, or if the detection result of the second-level self-test task is abnormal, or if the detection result of the third-level self-test task is abnormal, obtain the self-test task information. Based on the self-test task information, generate self-test fault cases; The self-test fault case is sent to the cloud server so that the cloud server updates the global topology network based on the self-test fault case.

9. The terminal device according to claim 1, characterized by The memory is further configured to store a self-healing operation library, the self-healing operation library including self-healing operations corresponding to each of the functional nodes; the controller is further configured to: If the detection result of the first-level self-test task is abnormal, or if the detection result of the second-level self-test task is abnormal, or if the detection result of the third-level self-test task is abnormal, the target functional node as the root cause of the fault shall be identified. Call the self-healing operation library; In the self-healing operation library, query the self-healing operation corresponding to the target functional node; The self-healing operation is performed on the target functional node.

10. A terminal device self-checking method based on cloud collaboration, characterized in that, include: In response to the power-on command of the terminal device, the kernel of the terminal device is started; After the kernel boots up, a topology network is retrieved from memory. The topology network is obtained from a cloud server in advance via over-the-air download technology. The topology network includes functional nodes and edges. The functional nodes are used to represent functional modules in the terminal device, and the edges are used to represent the dependencies between the functional nodes. The functional nodes are labeled with a first indicator and a second indicator. The first indicator is used to indicate the historical frequency of the functional node as a root cause of a fault, and the second indicator is used to indicate the effectiveness score of the functional node as a self-check point. Based on the topology network, create a self-test task for each of the functional nodes; In the topology network, the first indicator and the second indicator corresponding to the functional node are parsed; Calculate the priority of each self-test task based on the first indicator and the second indicator; Based on the priority, the self-test tasks are divided into Level 1 self-test tasks, Level 2 self-test tasks, and Level 3 self-test tasks; Perform the first-level self-test task; If the detection result of the first-level self-test task indicates an abnormality, the power-on process of the terminal device shall be interrupted. If the result of the first-level self-test task indicates that it is normal, the power-on process of the terminal device continues to be executed, and in response to the broadcast that the core system service of the terminal device has been started and completed, the display is loaded and the user interface is controlled to be displayed. At the same time, the second-level self-test task is executed asynchronously through a background thread. If the result of the second-level self-test task indicates that it is abnormal, the power-on process of the terminal device is not interrupted. After the terminal device is powered on, it executes the three-level self-test task in response to preset trigger conditions.

Images