Terminal equipment and communication detection method for slave equipment mounted on bus

Abstract

Some embodiments of the present application show a terminal device and a communication detection method for a slave device mounted on a bus, the method comprising: in response to an instruction of slave device communication detection, if detecting that a master device is physically connected with the slave device, reading register data of the slave device once; if the single read register data is valid data, reading the register data of the slave device for multiple times; calculating a communication success rate, a response delay multiple and a jitter coefficient according to each time consumed for repeatedly reading the register data; and calculating the health level according to the communication success rate, the response delay multiple and the jitter coefficient. According to the embodiment of the invention, the multi-stage logic progressive model is constructed, whether the physical connection is performed or not is verified, whether the equipment can communicate or not is verified through a single reading result under the condition of the physical connection, and the communication stability is verified through the communication success rate, the response delay multiple and the jitter coefficient under the condition that the equipment can communicate, so that the fault level can be accurately positioned; and misjudgment and missing detection are avoided.

Description

A terminal device and a method for detecting communication between slave devices connected to a bus. Technical Field

[0001] This application relates to the field of slave device communication detection technology, and in particular to a terminal device and a slave device communication detection method mounted on a bus. Background Technology

[0002] With the rapid development of the Internet of Things (IoT), industrial automation, intelligent connected vehicles, and robotics, the reliability and maintainability of embedded systems in complex environments are increasingly becoming critical challenges. Modern embedded devices generally utilize internal integrated circuit buses (I-ICBs). 2 C) Low-speed serial buses such as Serial Peripheral Interface (SPI) and Universal Asynchronous Receiver / Transmitter (UART) connect various sensors, memories, display modules, and other peripheral chips, forming a multi-layered peripheral communication network. However, these buses typically operate in environments with high noise, wide temperature variations, and frequent vibrations, making them highly susceptible to communication abnormalities due to poor pin contact, power fluctuations, electromagnetic interference, or device aging.

[0003] Some solutions use tools like i2cdetect to detect whether a communication anomaly has occurred on the bus. However, i2cdetect only determines whether an I / O failure has occurred by sending the device address and checking whether the slave device returns an acknowledgment signal. 2 Checking whether a device at a given address exists on the C bus is essentially a presence detection mechanism. However, this mechanism cannot reflect the communication quality of the device during actual data transmission; it can only determine if the device has issues such as undetectable intermittent communication failures or increased latency. Summary of the Invention

[0004] Some embodiments of this application provide a communication detection method for a terminal device and a slave device mounted on a bus. A multi-level logical progressive model is constructed. First, the physical connection is verified. If the physical connection is established, the device can be verified to communicate by a single reading result. If the device can communicate, the communication stability is verified by the communication success rate, response latency multiple, and jitter coefficient. This method can accurately locate the fault level and avoid misjudgment and missed detection.

[0005] In a first aspect, some embodiments of this application provide a display device, including: a display; a controller, which is a master device mounted on a bus and configured to: in response to a slave device communication detection command, acquire a slave device mounted on the bus; if a physical connection between the master device and the slave device is detected, read the register data of the slave device once, wherein the physical connection is between the master device and the slave device via the bus; if the register data read once is valid data, read the register data of the slave device multiple times; calculate a communication success rate, a response latency multiple, and a jitter coefficient based on the time consumed for each of the multiple reads of register data, wherein the response latency multiple is a multiple of the average latency of register data reading and a preset baseline latency, and the response latency multiple is used to characterize the performance degradation degree of the slave device in response speed, and the jitter coefficient is the standard deviation of the register data reading latency, and the jitter coefficient is used to characterize the stability of the slave device in response time; and calculate the health level of the slave device based on the communication success rate, the response latency multiple, and the jitter coefficient, wherein the health level is used to characterize the communication stability of the slave device.

[0006] The above technical solution has the following advantages or beneficial effects: it constructs a multi-level logical progression model, first verifying whether there is a physical connection, then verifying whether the device can communicate by a single reading result if there is a physical connection, and verifying the communication stability by communication success rate, response latency multiple and jitter coefficient if the device can communicate. This can accurately locate the fault level and avoid misjudgment and missed detection.

[0007] In some embodiments, after calculating the health level of the slave device based on communication success rate, response latency multiple, and jitter coefficient, the controller is further configured to: if the health level is normal, read the target register data of the target register and obtain the corresponding value range of the target register from the device knowledge template library, wherein the target register is a register related to the function of the slave device, and the device knowledge template includes the correspondence between different types of registers and value ranges; if the target register data is within the value range, output a first detection result, which is used to characterize the normal function of the slave device; if the target register data is not within the value range, output a second detection result, which is used to characterize the abnormal function of the slave device.

[0008] The above technical solution has the following advantages or beneficial effects: by comparing the register data with its predefined normal value range in the device knowledge template library, it can automatically determine whether the functional status of the device is normal, which can avoid the limitations of relying solely on communication connectivity or simple response to judge the device status and significantly improve the accuracy of fault identification.

[0009] In some embodiments, the controller performs a health level calculation for the slave device based on communication success rate, response latency multiple, and jitter coefficient. This is further configured to: calculate a health score for the slave device based on communication success rate, response latency multiple, jitter coefficient, a preset communication success rate weight, a preset response latency multiple weight, and a preset jitter coefficient weight; if the health score is greater than or equal to a first threshold, the health level is determined to be normal; if the health score is greater than or equal to a second threshold and less than the first threshold, the health level is determined to be warning; if the health score is less than the second threshold, the health level is determined to be severely abnormal.

[0010] The above technical solution has the following advantages or beneficial effects: it transforms the originally subjective or vague judgment of communication quality into a quantifiable and comparable health score, enabling objective evaluation of the bus operating status and providing a reliable basis for subsequent decision-making. Communication success rate, response latency multiple, and jitter coefficient reflect bus performance from different perspectives, avoiding misjudgment by a single indicator. Through weighted fusion, it takes into account the importance of various indicators and more accurately reflects the actual communication quality.

[0011] In some embodiments, the controller performs a calculation of the slave device's health level based on communication success rate, response latency multiple, and jitter coefficient, further configured to: obtain a first level corresponding to communication success rate from a first grading table, a second level corresponding to response latency multiple from a second grading table, and a third level corresponding to jitter coefficient from a third grading table, wherein the first, second, and third levels respectively include one of normal, warning, and severe anomaly; if at least one of the first, second, and third levels is severe anomaly, the health level is determined to be severe anomaly; if at least two of the first, second, and third levels are warning, the health level is determined to be severe anomaly; if one of the first, second, and third levels is warning and two are normal, the health level is determined to be warning; if all three levels are normal, the health level is determined to be normal.

[0012] The above technical solution has the following advantages or beneficial effects: communication success rate, response latency multiple, and jitter coefficient are independently lookup-based and graded, avoiding interference caused by differences in units or numerical ranges between indicators. While preserving the semantic clarity of each indicator, it integrates them through logical rules to comprehensively reflect the overall health status, taking into account both comprehensiveness and interpretability.

[0013] In some embodiments, after responding to a slave device communication detection command, the controller is further configured to output a third detection result if it detects that the physical connection between the master device and the slave device is broken, the third detection result being used to characterize that a slave device cannot be found on the bus.

[0014] The above technical solution has the following advantages or beneficial effects: it prioritizes determining whether the controller is physically connected to the slave device, and directly outputs the result after detecting that the controller is physically disconnected from the slave device, without the need for subsequent testing, which helps to improve the efficiency of detection and maintenance.

[0015] In some embodiments, after a single read of register data from the slave device, the controller is further configured to output a fourth detection result if the single read register data is invalid, the fourth detection result being used to characterize that data from the slave device cannot be obtained via command.

[0016] The above technical solution has the following advantages or beneficial effects: If communication reachability is not confirmed first, directly analyzing the register logic or functional status will lead to invalid analysis. This application prioritizes determining whether the read register data is valid. Upon detecting that the read register is invalid, it directly outputs the result that the device is unreachable, eliminating the need for subsequent register function tests, thus improving detection and maintenance efficiency.

[0017] In some embodiments, after calculating the health level of the slave device based on the communication success rate, response latency multiple, and jitter coefficient, the controller is further configured to output a fifth detection result if the health level is a warning or a serious anomaly, the fifth detection result being used to characterize the unstable communication of the slave device.

[0018] The above technical solution has the following advantages or beneficial effects: After physical connectivity and device reachability testing, this application prioritizes calculating the health level based on communication success rate, response latency multiple, and jitter coefficient. Upon detecting a warning or severe anomaly in the health level, it directly outputs the result of unstable communication, eliminating the need for subsequent register function tests, thus improving testing and maintenance efficiency.

[0019] In some embodiments, the controller's action of reading the slave device's register data in a single instance if a physical connection between the master device and the slave device is detected is further configured to: obtain the slave device's device address; send response requests to the device address multiple times; calculate the slave device's response rate based on the multiple response results returned by the device address; and if the response rate is greater than a preset value, read the slave device's register data in a single instance.

[0020] The above technical solution has the following advantages or beneficial effects: by sending multiple requests and calculating the response rate instead of relying on the result of a single communication, it can effectively avoid accidental packet loss caused by instantaneous interference and significantly improve the reliability and anti-interference ability of physical connection judgment.

[0021] Secondly, some embodiments of this application provide a method for detecting communication between a slave device mounted on a bus, comprising: in response to a slave device communication detection command, acquiring a slave device mounted on the bus; if a physical connection between a master device and a slave device is detected, reading register data of the slave device in a single operation, wherein the physical connection is a connection between the master device and the slave device via the bus; if the register data read in the single operation is valid data, reading register data of the slave device multiple times; calculating a communication success rate, a response latency multiple, and a jitter coefficient based on the time consumed for each of the multiple reads of register data, wherein the response latency multiple is a multiple of the average latency of register data reading and a preset baseline latency, the response latency multiple being used to characterize the performance degradation degree of the slave device in response speed, and the jitter coefficient is the standard deviation of the register data reading latency, the jitter coefficient being used to characterize the stability of the slave device in response time; and calculating the health level of the slave device based on the communication success rate, the response latency multiple, and the jitter coefficient, wherein the health level is used to characterize the communication stability of the slave device.

[0022] The above technical solution has the following advantages or beneficial effects: it constructs a multi-level logical progression model, first verifying whether there is a physical connection, then verifying whether the device can communicate by a single reading result if there is a physical connection, and verifying the communication stability by communication success rate, response latency multiple and jitter coefficient if the device can communicate. This can accurately locate the fault level and avoid misjudgment and missed detection.

[0023] In some embodiments, after calculating the health level of the slave device based on the communication success rate, response latency multiple, and jitter coefficient, the method further includes: if the health level is normal, reading the target register data of the target register and obtaining the corresponding value range of the target register from the device knowledge template library, wherein the target register is a register related to the function of the slave device, and the device knowledge template includes the correspondence between different types of registers and value ranges; if the target register data is within the value range, outputting a first detection result, which is used to characterize the normal function of the slave device; if the target register data is not within the value range, outputting a second detection result, which is used to characterize the abnormal function of the slave device.

[0024] The above technical solution has the following advantages or beneficial effects: by comparing the register data with its predefined normal value range in the device knowledge template library, it can automatically determine whether the functional status of the device is normal, which can avoid the limitations of relying solely on communication connectivity or simple response to judge the device status and significantly improve the accuracy of fault identification.

[0025] In this embodiment, in response to a slave device communication detection command, the slave device mounted on the bus is acquired. If a physical connection between the master device and the slave device is detected, the slave device's register data is read once. If the register data read once is valid, the slave device's register data is read multiple times. Based on the time consumed for each of the multiple register data reads, the communication success rate, response latency multiple, and jitter coefficient are calculated. The response latency multiple is the multiple of the average latency of register data reading and the preset baseline latency, and is used to characterize the performance degradation degree of the slave device in response speed. The jitter coefficient is the standard deviation of the register data reading latency, and is used to characterize the stability of the slave device in response time. Based on the communication success rate, response latency multiple, and jitter coefficient, the health level of the slave device is calculated, and the health level is used to characterize the communication stability of the slave device. This embodiment constructs a multi-level logical progressive model. First, it verifies whether there is a physical connection. If there is a physical connection, it verifies whether the device can communicate using the result of a single read. If the device can communicate, it verifies the communication stability using the communication success rate, response latency multiple, and jitter coefficient. This can accurately locate the fault level and avoid misjudgment and missed detection. Attached Figure Description

[0026] Figure 1 is a schematic diagram of an operation scenario between a display device and a control device provided in some embodiments of this application; Figure 2 is a schematic diagram of the hardware configuration of a display device provided in some embodiments of this application; Figure 3 is a schematic diagram of the software configuration of a display device provided in some embodiments of this application; Figure 4 is a flowchart of a slave device communication detection method mounted on a bus provided in some embodiments of this application; Figure 5 is a flowchart of a physical connection judgment method provided in some embodiments of this application; Figure 6 is a flowchart of an I... 2 Figure 7 is a flowchart of a method for determining the validity of register data according to some embodiments of this application; Figure 8 is a flowchart of another method for detecting slave device communication on a bus according to some embodiments of this application; Figure 9 is a system structure block diagram according to some embodiments of this application; Figure 10 is a timing diagram of a method for detecting slave device communication on a bus according to some embodiments of this application. Detailed Implementation

[0027] 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.

[0028] 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.

[0029] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0030] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0031] The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0032] A terminal device refers to a physical device located at the network edge in a communication network or system, directly interacting with the user or performing specific sensing / control functions. Terminal devices can include embedded devices. Embedded devices are computer systems designed specifically for a particular function or task, typically integrated within hardware devices. Embedded devices can include display devices 200.

[0033] Display device 200 generally refers to a device with screen display and data processing capabilities. For example, display device 200 includes, but is not limited to, smart TVs, mobile terminals, computers, monitors, advertising screens, wearable devices, virtual reality devices, and augmented reality devices.

[0034] Figure 1 is a schematic diagram of an operation scenario between a display device and a control device provided in some embodiments of this application. As shown in Figure 1, a user can operate the display device 200 through touch operation, a mobile terminal 300, and a control device 100. The control device 100 is used to receive operation commands input by the user and convert these commands into control commands that the display device 200 can recognize and respond to. For example, the control device 100 can be a remote control, a stylus, a gamepad, etc.

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

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

[0037] As also shown in Figure 1, the display device 200 communicates with the server 400 via various communication methods. The display device 200 can communicate via a local area network (LAN), a wireless local area network (WLAN), and other networks.

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

[0039] Figure 2 is a hardware configuration block diagram of the display device 200 in Figure 1 provided in some embodiments of this application.

[0040] In some embodiments, the display 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.

[0041] 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.

[0042] 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.

[0043] 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 display device 200 may have multiple communication devices 220 depending on the supported communication methods. For example, when the display device 200 supports wireless network communication, it may have a communication device 220 with WiFi functionality. When the display device 200 supports Bluetooth connectivity, it needs to have a communication device 220 with Bluetooth functionality.

[0044] The communication device 220 enables the display 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 display device 200 to external devices. Wireless connections utilize wireless signals or wireless networks. The display device 200 can directly establish a connection with external devices or indirectly through gateways, routers, or other connection devices.

[0045] 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 display device 200.

[0046] 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.

[0047] 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).

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

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

[0050] In some embodiments, to enable user interaction, the display device 200 may run an operating system. An operating system is a computer program that manages and controls the hardware and software resources of the display device 200. The operating system can control the 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 display device 200.

[0051] 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.

[0052] Operating systems can be divided into different modules or layers based on the functions they implement. For example, as shown in Figure 3, 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 Library layer, and the Kernel layer.

[0053] In some embodiments, the application layer provides services and interfaces for applications, enabling the display 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.

[0054] In this embodiment, the application layer includes a bus detection application. The bus detection application includes a multi-level diagnostic executor and a quantitative decision engine (QDE). The multi-level diagnostic executor executes detection tasks in a predefined hierarchical order (physical connectivity → device reachability → communication stability → functional correctness), supporting a short-circuit exit mechanism. The quantitative decision engine receives test results from each level, calculates the success rate, response latency multiplier, jitter coefficient, and outputs the health level.

[0055] 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.

[0056] As shown in Figure 3, 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.

[0057] 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.

[0058] 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.

[0059] In this embodiment, the system runtime library layer may include a Device Knowledge Template Library (DKT-Lib) and a Bus Abstraction Layer (BAL). The Device Knowledge Template Library stores metadata such as register definitions, valid value ranges, and bit field semantics for various peripherals. The Bus Abstraction Layer encapsulates the open, read, write, and close operations of different buses such as I²C, SPI, and UART, providing a unified calling interface.

[0060] The bus abstraction layer defines a unified `bus_evaluator_ops` interface, encapsulating operations such as open, read, write, and close. It implements pluggable bus adapters: `i2c_evaluator.so`, `spi_evaluator.so`, and `uart_register_access_evaluator.so`, etc. Dynamic loading and expansion are supported, allowing future extension to other register-based buses such as CAN and MDIO. Through a reusable diagnostic middleware platform, it has the potential to become an industry infrastructure.

[0061] In some embodiments, the kernel layer is a functional layer between the hardware and software of the display device 200. The kernel layer can implement functions such as hardware abstraction, multitasking, and memory management. For example, as shown in Figure 3, the kernel layer can be configured with hardware drivers, which can be at least one of the following: 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.

[0062] 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 display device 200 in this application embodiment. Depending on the function of the display device, the type of operating system, and other factors, the number of levels and the specific level type of the operating system may be expressed in other forms.

[0063] With the rapid development of fields such as the Internet of Things, industrial automation, intelligent connected vehicles, and robotics, the reliability and maintainability of embedded systems in complex environments have become increasingly critical challenges. Modern embedded devices generally connect various sensors, memories, display modules, and other peripheral chips through low-speed serial buses such as internal integrated circuit buses, serial peripheral interfaces, and universal asynchronous transceivers, forming a multi-layered peripheral communication network. However, these buses typically operate in environments with high noise, wide temperature variations, and frequent vibrations, making them highly susceptible to communication anomalies due to poor pin contact, power fluctuations, electromagnetic interference, or device aging.

[0064] The industry is placing higher demands on the observability and self-diagnostic capabilities of embedded systems. Especially in unattended scenarios (such as remote base stations, autonomous driving controllers, and medical monitoring equipment), traditional methods relying on manual on-site troubleshooting are no longer sufficient to meet the needs of rapid fault location and recovery. Therefore, building an automated, intelligent, and non-intrusive bus health monitoring mechanism has become a core technological direction for improving product availability and operational efficiency. Linux, as a mainstream embedded operating system, provides user-space interfaces such as i2c-dev and spidev, allowing applications to access the hardware bus without kernel programming. This feature lays the foundation for lightweight diagnostic tools and drives the technological evolution from "driver-level monitoring" to "application-level autonomy."

[0065] In some embodiments, tools such as i2cdetect are used to detect whether a communication anomaly has occurred on the bus. However, i2cdetect only determines whether an I / O failure has occurred by sending the device address and detecting whether the slave device returns an acknowledgment signal. 2 Checking for the existence of a device at a given address on the C-bus is essentially a presence detection mechanism. However, this mechanism cannot reflect the communication quality of the device during actual data transmission. It can only determine if the device experiences intermittent communication failures or increased latency. The original design goal was solely to "discover devices," without considering the need for quantitative stability assessment, resulting in a coarse diagnostic granularity.

[0066] In some embodiments, different buses require different test programs, resulting in inconsistent operational logic and making integration into a unified operation and maintenance platform difficult. The fragmented development of each tool, lacking top-level design and standardized specifications, leads to functional isolation and a lack of a unified framework.

[0067] In some embodiments, fault localization relies on engineers using oscilloscopes and logic analyzers to perform physical layer testing, which is costly and slow. This approach depends on manual experience and judgment, and the software layer cannot obtain signal integrity information, leading to ambiguity in the hardware-software boundary.

[0068] In some embodiments, advanced diagnostics require loading kernel modules, enabling ftrace, or inserting debug hooks, which can impact system security and stability. While kernel-level monitoring is sophisticated, it violates the principle of least privilege, is unsuitable for firmware releases, and is highly intrusive, making it unsuitable for production environments.

[0069] In some embodiments, even if register data is read, it is impossible to automatically determine whether it meets the expected functional state (e.g., the temperature value is outside the reasonable range but success is still returned). Existing tools only focus on "whether communication is completed" rather than "whether the result is correct", ignoring device semantic information.

[0070] The root cause of the above problems lies in equating bus detection communication testing with health assessment, lacking a hierarchical diagnostic model and intelligent decision-making mechanism from a systems engineering perspective, which leads to a fragmented, subjective, and unsustainable diagnostic process.

[0071] To accurately pinpoint the fault level and avoid misjudgment and missed detection, this application provides a terminal device. The terminal device can be exemplified by a display device 200, which includes a controller 250, a master device mounted on a bus. As shown in Figure 4, the controller 250 is configured to perform the following steps: Step S401: In response to a slave device communication detection command, acquire the slave device mounted on the bus.

[0072] Step S402: Determine whether the master device and the slave device are physically connected. A physical connection means the master device and the slave device are connected via a bus.

[0073] In some embodiments, the device communication detection command can be entered by the user through a command-line interface (CLI) command. A CLI command refers to instructions entered by the user via text on a terminal device or command-line window, used for interacting with and controlling the operating system, applications, or devices.

[0074] In some embodiments, the device communication detection command may appear in the kernel log (syslog) as an I 2 C timeout (i2c timeout) error log input. 2 C timeout error logs typically indicate I 2 C-bus communication failed to complete within the specified time, meaning the master device attempted to communicate with I... 2 C. When communicating with the device, no response was received or data transmission was completed within the expected time.

[0075] In some embodiments, when a remote connection is established between the display device 200 and the server 400, the slave device communication detection command sent by the server 400 can be received via Message Queuing Telemetry Transport (MQTT). MQTT is a lightweight, publish / subscribe-based IoT communication protocol designed for low-bandwidth, high-latency, and unstable network environments, and is widely used in remote control. Command-line tools are not conducive to system integration; therefore, this embodiment provides a RESTful API server (lightweight HTTP Server) supporting D-Bus interface registration, allowing other processes to subscribe to diagnostic events. Prometheus-compatible metrics are output for easy visualization in Grafana.

[0076] It should be noted that users can configure the bus type, device address, and test parameters (such as the number of repetitions N). The bus abstraction layer can initialize the corresponding bus device node (such as / dev / i2c-1).

[0077] In some embodiments, as shown in FIG5, one implementation of determining whether the master device and the slave device are physically connected may include: step S501: obtaining the device address of the slave device.

[0078] Step S502: Send response requests to the device address multiple times.

[0079] Step S503: Calculate the response rate of the slave device based on the response results returned multiple times by the device address.

[0080] Step S504: Determine whether the response rate is greater than the preset value.

[0081] If the response rate is greater than the preset value, then proceed to step S505: determine the physical connection between the master device and the slave device.

[0082] If the response rate is less than or equal to the preset value, then proceed to step S506: determine that the physical connection between the master device and the slave device is disconnected.

[0083] One implementation of sending response requests to the device address multiple times may include: calling ioctl(fd, I 2 C_SLAVE, addr), the kernel will send an I_SLE containing only the start bit + address frame + direction = write. 2 C. Request. If the device returns ACK, the response is successful. If the device returns NACK or times out, the response fails. Response rate = number of successful responses / total number of attempts. The response rate confirms whether a response exists at the device address. This step does not involve actual data reading or writing; it only verifies the electrical connection.

[0084] For example, the preset value is 70%, and the total number of attempts is 5. If the number of successful responses is 4, the response rate is 80%, then the master device and the slave device are physically connected. If the number of successful responses is 3, the response rate is 60%, then the master device and the slave device are physically disconnected.

[0085] Compared to most advanced diagnostic solutions that require loading kernel modules, enabling ftrace, or modifying driver code, resulting in high deployment barriers and impacting system security, this application's embodiments represent an evolution from a kernel-dependent to a purely user-space, non-intrusive architecture. This application runs entirely in user space, completing all operations through standard device nodes (such as / dev / i2c-X) by calling ioctl() and read / write interfaces, without requiring privileged permissions or kernel modifications. It achieves compatibility with mainstream Linux distributions, can run long-term in production environments, and meets industrial-grade reliability requirements.

[0086] In some embodiments, one way to obtain the device address of a slave device may include obtaining the device address of a slave device mounted on the bus from a device knowledge template library.

[0087] Device knowledge templates can be stored in a non-markup language (YAML), JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), or SQLite database format. Device knowledge templates can include supported I... 2 C address list, register mapping table, legal value range, and bit field semantic parsing. 2 The C address list includes the device address of the slave device. There can be one register map, which includes the addresses and read / write attributes of registers corresponding to multiple slave devices. There can also be multiple register maps, each corresponding to a slave device, including the register address and read / write attributes of that slave device. The legal value range can refer to the legal value range of operating temperature and acceleration measurement range, etc. Taking operating temperature as an example, the legal value range of operating temperature is -40~125℃. Bit field semantic interpretation refers to the interpretation and explanation of the specific function, state, or configuration meaning represented by each bit or consecutive bit segments in a register. For example, a bit represents the shutdown mode. Template content can be derived from manual data entry in datasheets, automatically crawled authorized public specifications, and over-the-air (OTA) remote push updates.

[0088] In some embodiments, all device knowledge templates can be loaded in full, or the template for the current device under test can be loaded on demand, supporting hot-swappable updates. Template files can be named by manufacturer + model for easy retrieval via path index.

[0089] The slave devices on the bus are diverse, covering multiple categories such as sensors, memory, and controllers. These devices communicate via I / O. 2 The C-bus communicates with the master device. Sensors detect changes in the physical environment and convert this information into electrical signals, which are then transmitted via I-band. 2 The data is transmitted to the host device via the Type-C interface. Sensors can be temperature and humidity sensors, as well as accelerometers and gyroscopes, etc. 2 C can also be used to connect various types of memory chips for data read and write operations. The memory chip can be an electrically erasable programmable read-only memory (EEPROM).

[0090] In some embodiments, I 2 The C-bus communication system architecture is shown in Figure 6. The microcontroller unit (MCU) serves as the I / O interface. 2 The master device (C) is responsible for initiating communication, sending clock signals via the serial clock line (SCL) and data via the serial data line (SDA), and controlling the bus. The 24C02 is a 2Kbit EEPROM memory chip used for non-volatile data storage. 2 The C address is 0xA0. The MPU6050 is an inertial measurement unit (IMU) that integrates an accelerometer and a gyroscope. 2 The C address is 0xD0. Other: This indicates that it may be connected to the same I... 2 Other I on the C bus 2 For C-devices (such as sensors, OLED displays, etc.), the address needs to be determined based on the specific device. An MCU acts as the master controller, communicating via I / O. 2 The C-bus connects multiple slave devices (such as EEPROM, IMU, etc.), uses SDA / SCL for communication, and maintains signal integrity through pull-up resistors. Each device has an independent address, enabling efficient communication among multiple devices sharing the bus.

[0091] If the master device and the slave device are not physically connected, that is, the physical connection between the master device and the slave device is broken, execute step S403: output the third detection result, wherein the third detection result is used to indicate that the slave device on the bus cannot be found, that is, the physical connection between the master device and the slave device is broken.

[0092] In some embodiments, the third detection result may be a detection report in JSON format, which may include information about the inability to find a slave device on the bus, as well as solutions or suggestions corresponding to the inability to find a slave device on the bus.

[0093] If the master device and the slave device are physically connected, execute step S404: read the slave device's register data in a single operation.

[0094] If the master and slave devices are physically connected, a read request is sent to the slave device's registers via the bus abstraction layer. The registers can return register data based on the read request. Among the multiple registers on the slave device, a typical register, such as the Identifier (ID) register, can be selected as the read target. The value of the ID register is fixed and known, requiring no pre-configuration, and uniquely identifies the chip model. Avoid using variable registers (such as temperature or status registers) as verification criteria, as their values ​​may be valid but do not guarantee reliable communication. The bus abstraction layer includes various types of bus adapters, each supporting different types of bus switching and read / write operations.

[0095] with I 2 Compared to solutions where C, SPI, and UART each have independent test programs and inconsistent interfaces, making integration and management difficult, this application's embodiment extends from a single-bus dedicated tool to a unified cross-bus diagnostic platform. It designs an abstract bus interface layer (BusAbstraction Layer) that supports plug-in access to different bus types, forming a unified diagnostic framework. This achieves a single architecture covering multiple buses, reducing development and maintenance costs and possessing potential for ecosystem expansion.

[0096] In some embodiments, the i2c-dev interface is reused, and packet error checking (PEC) logic is added to verify the currently supported I2C interfaces. 2 C is extended to a System Management Bus (SMBus). Using the spidev interface and adjusting the transfer mode, the currently supported SPI can be expanded to Quad-SPI. Adding a CRC16 checksum and frame parsing module expands the currently supported UART to Modbus RTU. All new buses can be accessed by implementing a new BAL plugin without modifying the core logic.

[0097] Step S405: Determine whether the register data read in a single transaction is valid data.

[0098] In some embodiments, as shown in FIG7, one implementation of determining whether register data read in a single instance is valid data may include: step S701: obtaining the valid byte data corresponding to the register from the device knowledge template.

[0099] Step S702: Determine whether the register data read in a single operation is the same as the valid byte data.

[0100] If the register data read in a single operation is the same as the valid byte data, then proceed to step S703: determine that the register data read in a single operation is valid data.

[0101] If the register data read in a single operation is different from the valid byte data, then proceed to step S704: determine that the register data read in a single operation is invalid data.

[0102] For example, in the device knowledge template, the device model is BMP280, the ID register address is 0xD0, and the valid byte data is 0x58. Reading register 0xD0, if the returned register data is 0x58, then the register data is valid. If the returned register data is 0x00, then the register data is invalid.

[0103] If the register data read in a single operation is invalid, then step S406 is executed: output the fourth detection result. The fourth detection result is used to characterize that the data of the slave device cannot be obtained through the command, that is, the slave device is inaccessible and cannot be communicated with.

[0104] In some embodiments, the fourth detection result may be a detection report in JSON format. In addition to the detection results of the inability to obtain data from the slave device through commands, the detection report may also include physical connectivity detection results, as well as solutions or suggestions corresponding to the inability to obtain data from the slave device through commands.

[0105] If the register data read in a single reading is valid, then proceed to step S407: read the register data of the slave device multiple times.

[0106] In some embodiments, after sending a read request to the slave device's register, it can be determined whether register data returned by the slave device's register is received within a preset time. If no register data is received within the preset time, a fourth detection result can be output. If register data is received within the preset time, it can be determined whether the register data read in a single instance is valid data.

[0107] In this embodiment of the application, a read request is initiated to a typical register, and a complete read / write operation is determined based on whether the obtained register data is valid byte data, thereby verifying whether the device is reachable, that is, verifying whether data from the slave device can be obtained through a command.

[0108] Step S408: Calculate the communication success rate, response delay multiple, and jitter coefficient based on the time consumed for each of the multiple reads of register data.

[0109] Among them, the response latency multiple is the multiple of the average latency of register data reading to the preset baseline latency. The response latency multiple is used to characterize the degree of performance degradation of the slave device in response speed. The jitter coefficient is the standard deviation of the register data reading latency. The jitter coefficient is used to characterize the stability of the slave device in response time.

[0110] The slave device can correspond to multiple registers. Select any one of the registers and perform the same read operation N times consecutively (N≥10), and record the time taken to read the register data each time.

[0111] Then calculate the success rate P = number of successful transmissions / total number of attempts × 100%.

[0112] Average Response Time (ART): The average time taken to perform a complete read / write operation.

[0113] ; where t i This represents the time difference between sending a request and receiving a complete response in the i-th communication. Use a high-precision timer, such as clock_gettime(CLOCK_MONOTONIC).

[0114] In some embodiments, the baseline latency (BL) can be the minimum response time of the system under ideal conditions, used as a comparison reference (derived from historical best values ​​or specifications in the manual). However, traditional fixed baseline latency is susceptible to environmental changes. A better approach is to automatically collect 10 optimal latencies during the initial system run as the baseline latency, and then update it periodically thereafter. This solution can adapt to slowly changing factors such as aging and temperature drift, avoiding false alarms.

[0115] Latency Multiple (LM): The factor by which the current average latency is amplified relative to the baseline latency, reflecting the degree of performance degradation. LM = ART / BL.

[0116] Jitter Coefficient (JC): Reflects the instability of response time (i.e., "jitter"), and is particularly critical for real-time systems. The jitter coefficient can be calculated using the standard deviation normalization method.

[0117] .

[0118] Step S409: Calculate the health level of the slave device based on the communication success rate, response latency multiple, and jitter coefficient. The health level characterizes the communication stability of the slave device.

[0119] In some embodiments, one implementation of calculating the health level of a slave device based on communication success rate, response latency multiple, and jitter coefficient may include: calculating a health score for the slave device based on communication success rate, response latency multiple, jitter coefficient, preset communication success rate weight, preset response latency multiple weight, and preset jitter coefficient weight.

[0120] Where H is the health score, w1 is the preset communication success rate weight, P is the communication success rate (normalized to 0-1), w2 is the preset response latency multiplier weight, LM is the response latency multiplier, w3 is the preset jitter coefficient weight, and JC is the jitter coefficient. For example, w1=0.5, w2=0.3, w3=0.2. H ∈ (0, 1).

[0121] If the health score is greater than or equal to the first threshold, the health level is determined to be normal; if the health score is greater than or equal to the second threshold but less than the first threshold, the health level is determined to be warning; if the health score is less than the second threshold, the health level is determined to be severely abnormal. The first threshold is greater than the second threshold.

[0122] For example, the first threshold is 0.9 and the second threshold is 0.7. If H ≥ 0.9, the health level is normal (Success); if 0.7 ≤ H < 0.9, the health level is warning; if H < 0.7, the health level is critical.

[0123] The embodiments of this application can integrate communication success rate, response latency multiple and jitter coefficient into a health score. The health level can be determined based on the health score, which facilitates unified decision-making by the state machine.

[0124] In some embodiments, one implementation of calculating the health level of a slave device based on communication success rate, response latency multiple, and jitter coefficient may include: obtaining a first level corresponding to communication success rate from a first grading table, obtaining a second level corresponding to response latency multiple from a second grading table, and obtaining a third level corresponding to jitter coefficient from a third grading table, wherein the first level, the second level, and the third level respectively include one of normal, warning, and severe abnormality.

[0125] For example, the first level is shown in Table 1. If the communication success rate is 99%, the first level is normal; if the communication success rate is 95%, the first level is warning; if the communication success rate is 80%, the first level is serious anomaly.

[0126] Table 1

[0127] For example, the second grading table is shown in Table 2. If the response delay multiple is 1.2, the second grade is normal; if the response delay multiple is 2, the second grade is warning; if the response delay multiple is 3.5, the second grade is severe anomaly.

[0128] Table 2

[0129] For example, the third grading table is shown in Table 3. If the response delay multiple is 1.2, the second grade is normal; if the response delay multiple is 2, the second grade is warning; if the response delay multiple is 3.5, the second grade is severe anomaly.

[0130] Table 3

[0131] In some embodiments, Tables 1, 2, and 3 are integrated into one table to obtain a quantitative decision rule table. The quantitative decision rule table is shown in Table 4. From the quantitative decision rule table, the levels corresponding to communication success rate, response latency multiple, and jitter coefficient can be directly obtained.

[0132] Table 4

[0133] If at least one of the three levels (Level 1, Level 2, and Level 3) is severely abnormal, the health level is determined to be severely abnormal; if at least two of the three levels (Level 1, Level 2, and Level 3) are warnings, the health level is determined to be severely abnormal; if one of the three levels (Level 1, Level 2, and Level 3) is a warning and two are normal, the health level is determined to be a warning; if all three levels (Level 1, Level 2, and Level 3) are normal, the health level is determined to be normal.

[0134] For example, if the first level is severe abnormality and the second and third levels are normal, then the health level is severe abnormality. If the first level is normal and the second and third levels are warnings, then the health level is severe abnormality. If the first level is a warning and the second and third levels are normal, then the health level is a warning. If the first, second, and third levels are all normal, then the health level is normal.

[0135] Step S410: Determine whether the health level is normal.

[0136] If the health level is not normal, i.e., the health level is warning or serious abnormality, then execute step S411: output the fifth detection result, which is used to characterize the unstable communication between the slave device and the slave device.

[0137] In some embodiments, the fifth detection result may be a detection report in JSON format. In addition to the detection result of unstable communication with the slave device, the detection report may also include the detection results of physical connectivity and device reachability, as well as solutions or suggestions corresponding to the unstable communication with the slave device.

[0138] If the bus detection and diagnostic results are only "success / failure" boolean values, there is a lack of perception of performance degradation. However, the embodiments of this application transform the qualitative judgment into a vectorized decision-making mechanism. Three core quantitative indicators are introduced: communication success rate (P), relative response delay multiple (LM), and delay jitter coefficient (JC), combined with a preset threshold rule base for automatic scoring and alarm classification. This supports trend warning and stability assessment, and can identify potential risks such as intermittent faults and signal quality degradation.

[0139] If the health level is normal, then proceed to step S412: read the target register data from the target register and obtain the corresponding value range of the target register from the device knowledge template library.

[0140] The device knowledge template library includes a register mapping table. The register mapping table includes the function identifiers corresponding to the registers. If the function identifier corresponding to a register is a preset value (which can be 1), then the register can be identified as the target register. If the function identifier corresponding to a register is not a preset value (i.e., the function identifier is 0), then the register can be identified as not being the target register; that is, once the health level is normal, there is no need to read the register data of that register.

[0141] The target register is a register related to the function of the slave device. For example, if the slave device is a temperature sensor, the target register is a temperature register related to the function of the temperature sensor. If the slave device is a temperature and humidity sensor, the target register consists of both a temperature register and a humidity register related to the function of the temperature and humidity sensor.

[0142] The device knowledge template includes the correspondence between different registers and their numerical ranges. For example, the numerical range for a temperature sensor is -40 to 125°C. The device knowledge template also includes the correspondence between different registers and their bit fields. For example, a bit of 1 indicates the shutdown mode.

[0143] Step S413: Determine whether the data in the target register is within the numerical range.

[0144] If the target register data is within the numerical range, then execute step S414: output the first detection result, which is used to characterize the normal function of the slave device.

[0145] In some embodiments, the first detection result may be a detection report in JSON format. In addition to the detection result that the device is functioning normally, the detection report may also include detection results such as physical connectivity, device accessibility, and health level.

[0146] If the target register data is not within the numerical range, then step S415 is executed: output the second detection result, which is used to characterize the functional abnormality of the slave device.

[0147] In some embodiments, the fifth detection result may be a detection report in JSON format. In addition to the detection results of the device's functional abnormality, the detection report may also include detection results such as physical connectivity, device reachability and health level, as well as solutions or suggestions corresponding to the device's functional abnormality.

[0148] For example, the temperature register's value range is -40 to 125°C. If the temperature register reads 80°C, the slave device is functioning normally; if the temperature register reads 200°C, the slave device is malfunctioning.

[0149] In some embodiments, each bit in each status register represents a certain status meaning. When detecting and reading the slave device status register, it is also necessary to verify whether each bit conforms to the specification. Each bit / field in the register is parsed to check whether its logical state is consistent with the current device operating mode. For example, if the device is in normal operating mode but SHUTDOWN_BIT = 1, it can be determined that the bit field semantics are inconsistent, and a second detection result is output. If the device is in a power-off state and SHUTDOWN_BIT = 1, it can be determined that the bit field semantics are consistent, and a first detection result is output.

[0150] Compared to schemes where even if register data is read, its validity cannot be determined (e.g., a temperature reading of 200°C is still considered a successful communication), this application's embodiments upgrade from raw data access to device semantic-driven verification. A Device Knowledge Template (DKT) is introduced to describe the key registers, legal value ranges, and bit field meanings of each type of peripheral. During diagnosis, the actual values ​​are automatically compared with expected behavior, thereby achieving a leap from physical layer connectivity to functional-level trust, and identifying hidden faults such as false online status and genuine anomalies.

[0151] In some embodiments, slave devices on the bus are probed sequentially, i.e., serial testing.

[0152] In some embodiments, thread pools or asynchronous I / O (such as io_uring) are used to simultaneously probe multiple slave device addresses. This can significantly shorten the detection cycle when dozens of sensors are connected to the bus.

[0153] In some embodiments, if multiple slave devices connected to the bus malfunction, the bus function may be output as faulty.

[0154] Traditional tools (such as i2cdetect) perform only one address scan to determine device presence. This application, however, represents a leap from a single test to a multi-level progressive diagnostic architecture, upgrading connectivity checks to identifying specific problems and achieving structured separation of root causes. A four-level logical progressive model is constructed, verifying physical connection → device reachability → stable communication → correct functionality layer by layer, forming a causal chain reasoning mechanism to accurately locate the fault level and avoid misjudgments and missed detections. • A short-circuit judgment mechanism is used between each level: if the previous level fails, subsequent tests are terminated, improving efficiency.

[0155] Example 1: Vehicle-mounted camera I 2 C-link diagnosis.

[0156] Scenario: Frequent disconnections of the CMOS image sensor in an ADAS system. Configuration: Bus: I 2 C-2, address 0x3C; DKT: OV9650 camera chip template; Test parameters: N=20 cycles.

[0157] Results: L1 / L2 passed → physical connection is normal; L3 success rate P=0.75, R=2.3 → significant delay and packet loss; L4 read ID register as 0x96 → function is normal.

[0158] Judgment: Serious abnormality, prompting "unstable communication", it is recommended to check PCB solder joints or power supply filter capacitors.

[0159] Example 2: Concurrent detection of multiple SPI Flash in industrial PLC.

[0160] Scenario: Dual backup Flash chips require regular health checks.

[0161] Solution: Enable multi-threaded concurrent diagnostics, which will be executed every 5 minutes.

[0162] Output: Device: spi-flash@0, Health Level: Warning; Success Rate: 0.88, Response Latency Multiplier: 1.6, Recommendation: Replace the storage chip. Effect: Detected write timeout trends two weeks in advance, preventing sudden system crashes.

[0163] In some embodiments, the flowchart of the slave device communication detection method mounted on the bus can be shown in Figure 8. L1: First, scan the slave device's address (e.g., 5 times) and calculate the response rate based on the response results. If the response rate is less than or equal to 80%, the detection terminates, and a detection result indicating a physical connection failure is output. If the response rate is greater than 80%, execute L2: Read register data once to verify whether valid data has been obtained. If no valid data has been obtained, the detection terminates, and a detection result indicating the slave device cannot communicate is output. If valid data has been obtained, execute L3: Read register data N times in a loop, calculate the communication success rate, response latency multiple, and jitter coefficient, and determine the health level. If the health level is a warning or severe abnormality, the detection terminates, and a detection result indicating unstable slave device communication is output. If the health level is normal, execute L4: Load the device knowledge template library and determine whether the register data is valid. If the register data is invalid, the detection terminates, and a detection result indicating a slave device malfunction is output. If the register data is valid, the detection terminates, and a detection result indicating the slave device is functioning normally or healthily is output.

[0164] In some embodiments, the system architecture diagram can be as shown in Figure 9. The user interface can obtain configuration bus type, device address, test parameters, and slave device communication detection commands, and send these commands to the bus abstraction layer. The bus abstraction layer initializes the corresponding bus device nodes and completes read and write operations by calling ioctl() and read / write interfaces through user space device nodes. The multi-level diagnostic actuator can perform diagnostic operations for L1 physical connectivity, L2 device reachability, L3 communication stability, and L4 functional correctness. The quantization strategy engine can perform data calculations and output detection results based on the calculation results. Functional correctness diagnosis requires loading the device knowledge template library.

[0165] In some embodiments, the timing diagram of the slave device communication detection method mounted on the bus can be as shown in Figure 10. Upon receiving the slave device communication detection command, the device node of the bus is initialized, and an initialization success message is sent to the multi-level diagnostic actuator. The multi-level diagnostic actuator sets the slave address through the device node, calculates the response rate based on the slave device's response result, and sends the response rate to the quantization decision engine. When the response rate is less than or equal to a preset value, the quantization decision engine outputs that the physical connection is disconnected. When the response rate is greater than the preset value, a continue detection notification is sent to the multi-level diagnostic actuator. The multi-level diagnostic actuator reads the slave device's register data once through the device node and sends the register data to the quantization decision engine. When the register data read in a single read is invalid, the quantization decision engine outputs that the slave device cannot communicate. When the register data read in a single read is valid, a continue detection notification is sent to the multi-level diagnostic actuator. The multi-level diagnostic actuator reads the slave device's register data multiple times through the device node and sends the time taken for multiple register data reads to the quantization decision engine. The quantization decision engine calculates the communication success rate, response latency multiplier, and jitter coefficient based on the time taken to read register data multiple times, and then calculates the health level based on these metrics. When the health level is warning or severely abnormal, it outputs "communication unstable." When the health level is normal, it sends a "continue monitoring" notification to the multi-level diagnostic actuator. The multi-level diagnostic actuator reads the register value of the target register through the device node and sends the register value to the quantization decision engine. The quantization decision engine obtains the corresponding numerical range for the target register from the device knowledge template library. When the register value is outside the numerical range, it outputs "device malfunction." When the register value is within the numerical range, it outputs "device malfunction."

[0166] It should be noted that the multi-level diagnostic executor can also perform the following: whether the data is valid, the calculation of communication success rate, response latency multiple and jitter coefficient, the determination of health level, and the judgment of register value validity.

[0167] Traditional embedded devices often experience functional degradation or crashes during operation due to bus communication anomalies (such as sensor disconnection or data reading failure). However, existing diagnostic methods generally suffer from problems such as coarse diagnostic granularity, reliance on manual intervention, and the need for kernel privileges, making it difficult to meet the remote operation and maintenance and fault prediction needs of high-availability scenarios such as industrial control, automotive electronics, and robotics.

[0168] To address the aforementioned issues, this application proposes a user-space-based multi-level progressive bus health assessment architecture, aiming to solve the following core technical problems: how to achieve in-depth diagnosis of peripheral communication links without modifying the kernel or reloading the driver; how to upgrade from simple on / off judgment to quantitative health assessment including dimensions such as stability, latency, and trends; and how to combine device semantic information (such as register definitions and legal value ranges) to identify hidden faults that are physically connected but functionally abnormal.

[0169] This application constructs a three-in-one technical framework of multi-level progressive detection, quantitative decision engine, and device template-driven verification. Through a four-level hierarchical diagnostic mechanism (physical connectivity → device reachability → communication stability → functional correctness), the root cause of faults is located layer by layer. Quantifiable indicators such as communication success rate, response latency multiple, and jitter coefficient are introduced, and dynamic threshold rules are set to achieve objective evaluation. Based on predefined device knowledge templates, the actual values ​​of key registers are automatically compared with expected behaviors to complete semantic-level functional verification.

[0170] This application's embodiments run entirely in user space, requiring no privileged permissions or kernel modifications, exhibiting strong compatibility and deployable in various closed or hardened embedded environments; its diagnostic logic is structured and standardized, overcoming the fragmented limitations of traditional tools and forming a reusable, universal diagnostic paradigm; it supports cross-bus extensions (I... 2 (C / SPI / UART, etc.) with good platform adaptability and ecosystem expansion potential; intelligent and integrable output results, diagnostic reports support JSON format output, and can be connected to monitoring systems through D-Bus, REST API, etc., to help achieve predictive maintenance and remote operation and maintenance automation.

[0171] In summary, the embodiments of this application not only effectively improve the observability and self-diagnostic capabilities of embedded systems, but also provide fundamental technical support for building highly reliable and easy-to-maintain intelligent terminal devices, demonstrating significant technological advancements and broad application prospects.

[0172] Some embodiments of this application also provide a computer-readable storage medium that can store a program. When the computer storage medium is configured in a display device or server, the program, when executed, can include the program steps involved in the slave device communication detection method mounted on the bus in the above embodiments. The computer storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0173] This application provides an electronic device, which includes a processor and a memory for storing processor-executable instructions. The processor is used to read executable instructions from the memory and execute the instructions to implement the slave device communication detection method mounted on a bus as described in the above embodiments.

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

Claims

1. A terminal device, characterized in that, include: monitor; A controller, a master device mounted on a bus, is configured to: in response to a slave device communication detection command, acquire slave devices mounted on the bus; if a physical connection between the master device and the slave device is detected, read the register data of the slave device in a single operation, wherein the physical connection is the connection between the master device and the slave device via the bus; if the register data read in the single operation is valid, read the register data of the slave device multiple times; calculate a communication success rate, a response latency multiple, and a jitter coefficient based on the time consumed for each of the multiple reads of the register data, wherein the response latency multiple is the multiple of the average latency of register data reading to a preset baseline latency, and the response latency multiple is used to characterize the performance degradation degree of the slave device in response speed; the jitter coefficient is the standard deviation of the register data reading latency, and the jitter coefficient is used to characterize the stability of the slave device in response time; and calculate the health level of the slave device based on the communication success rate, the response latency multiple, and the jitter coefficient, wherein the health level is used to characterize the communication stability of the slave device.

2. The terminal device according to claim 1, characterized in that, After calculating the health level of the slave device based on the communication success rate, the response delay multiple, and the jitter coefficient, the controller is further configured to: if the health level is normal, read the target register data of the target register and obtain the corresponding value range of the target register from the device knowledge template library, wherein the target register is a register related to the function of the slave device, and the device knowledge template includes the correspondence between different types of registers and value ranges; If the target register data is within the specified value range, a first detection result is output, which is used to characterize that the slave device is functioning normally. If the target register data is not within the specified value range, a second detection result is output, which is used to characterize the functional abnormality of the slave device.

3. The terminal device according to claim 1, characterized in that, The controller calculates the health level of the slave device based on the communication success rate, the response latency multiple, and the jitter coefficient, and is further configured to calculate the health score of the slave device based on the communication success rate, the response latency multiple, the jitter coefficient, a preset communication success rate weight, a preset response latency multiple weight, and a preset jitter coefficient weight. If the health score is greater than or equal to the first threshold, the health level is determined to be normal. If the health score is greater than or equal to the second threshold and less than the first threshold, the health level is determined to be a warning. If the health score is less than the second threshold, the health level is determined to be severely abnormal.

4. The terminal device according to claim 1, characterized in that, The controller calculates the health level of the slave device based on the communication success rate, the response latency multiple, and the jitter coefficient, and is further configured to: obtain a first level corresponding to the communication success rate from a first grading table, a second level corresponding to the response latency multiple from a second grading table, and a third level corresponding to the jitter coefficient from a third grading table, wherein the first level, the second level, and the third level each include one of normal, warning, and severe anomaly; if at least one of the first level, the second level, and the third level is severe anomaly, then the health level is determined to be severe anomaly; if at least two of the first level, the second level, and the third level are warning, then the health level is determined to be severe anomaly; if one of the first level, the second level, and the third level is warning and two are normal, then the health level is determined to be warning; if all three levels are normal, then the health level is determined to be normal.

5. The terminal device according to claim 1, characterized in that, In response to a slave device communication detection command, the controller is further configured to output a third detection result if it detects that the master device and the slave device are physically disconnected, the third detection result being used to characterize that the slave device on the bus cannot be found.

6. The terminal device according to claim 1, characterized in that, After reading the register data of the slave device once, the controller is further configured to output a fourth detection result if the register data read once is invalid, the fourth detection result being used to indicate that the data of the slave device cannot be obtained by command.

7. The terminal device according to claim 1, characterized in that, After calculating the health level of the slave device based on the communication success rate, the response latency multiple, and the jitter coefficient, the controller is further configured to output a fifth detection result if the health level is a warning or a serious anomaly, the fifth detection result being used to characterize the communication instability of the slave device.

8. The terminal device according to claim 1, characterized in that, The controller's action of reading the slave device's register data in a single instance if it detects a physical connection between the master device and the slave device is further configured to: obtain the slave device's device address; send response requests to the device address multiple times; calculate the slave device's response rate based on the multiple response results returned by the device address; and if the response rate is greater than a preset value, read the slave device's register data in a single instance.

9. A method for detecting communication between slave devices mounted on a bus, applied to a master device mounted on a bus, characterized in that, include: In response to a slave device communication detection command, acquire the slave devices mounted on the bus; If a physical connection between the master device and the slave device is detected, the slave device's register data is read once. The physical connection is that the master device and the slave device are connected via the bus. If the register data read in the single reading is valid, the slave device's register data is read multiple times. Based on the time taken for each of the multiple reads of the register data, a communication success rate, a response latency multiple, and a jitter coefficient are calculated. The response latency multiple is the multiple of the average latency of register data reading to a preset baseline latency, and is used to characterize the degree of performance degradation of the slave device in response speed. The jitter coefficient is the standard deviation of the register data reading latency, and is used to characterize the stability of the slave device in response time. Based on the communication success rate, the response latency multiple, and the jitter coefficient, the health level of the slave device is calculated, and the health level is used to characterize the communication stability of the slave device.

10. The method according to claim 9, characterized in that, After calculating the health level of the slave device based on the communication success rate, the response latency multiple, and the jitter coefficient, the method further includes: if the health level is normal, reading the target register data of the target register and obtaining the corresponding value range of the target register from the device knowledge template library, wherein the target register is a register related to the function of the slave device, and the device knowledge template includes the correspondence between different types of registers and value ranges; if the target register data is within the value range, then outputting a first detection result, which is used to characterize the normal function of the slave device; if the target register data is not within the value range, then outputting a second detection result, which is used to characterize the abnormal function of the slave device.

Images