A fault diagnosis and intelligent display method and system applied to a docking station

Abstract

The application discloses a fault diagnosis and intelligent display method and system applied to a docking station, and relates to the field of docking stations. In the method, a communication negotiation process between the docking station and a host device is monitored; a first state transition event of the docking station and a second state transition event of the host device in the communication negotiation process are acquired; a composite event corresponding to the communication negotiation process is generated based on the first state transition event and the second state transition event; if it is determined that a target state transition event is interrupted or failed, the target state transition event is stored into a fault event queue arranged in time sequence, and the fault event queue is processed to determine a main fault event; according to the main fault event, a search is performed in a preset fault knowledge base to generate a structured display scheme; a user interface is displayed on a display screen integrated in the docking station, and the main fault event is displayed on the user interface according to the structured display scheme. The technical scheme provided by the application improves user experience.

Description

Technical Field

[0001] This application relates to the field of docking stations, specifically to a fault diagnosis and intelligent display method and system for docking stations. Background Technology

[0002] With the widespread adoption of portable electronic devices, especially laptops, their designs increasingly prioritize thinness and integration, leading to a sharp decrease in the number of ports they carry. To meet users' multiple needs, such as simultaneously connecting monitors, keyboards, mice, and charging, docking stations have emerged as a crucial peripheral. Connecting to the host device via a single cable, such as USB-C or Thunderbolt, they can expand to include various functional interfaces, greatly improving user efficiency and convenience. However, because docking stations integrate multiple complex control chips and circuit units for video conversion, network communication, and other functions, their frequent protocol interactions result in a relatively high probability of malfunction, with diverse symptoms. When problems occur, ordinary users often struggle to quickly and accurately determine whether the fault originates from the host device, the connecting cable, the docking station itself, or the external device. They are often forced to repeatedly plug and unplug cables, a cumbersome and inefficient process that severely impacts the user experience.

[0003] To address the aforementioned difficulties in fault localization, existing technologies have proposed a diagnostic scheme based on host device software. This scheme typically requires users to install specific drivers or accompanying diagnostic applications on the host device, such as a laptop. Once the docking station is connected, this application can communicate with the docking station's internal firmware to read its operating status, port connection information, and some preset error codes. By running this software, users can obtain a basic diagnostic report.

[0004] However, the aforementioned existing technologies still suffer from a critical technical flaw, especially in current mainstream single-cable full-featured docking stations, such as those connected via USB-C or Thunderbolt interfaces. This flaw lies in the fact that the effectiveness of diagnostic methods based on the host device's software depends entirely on a stable and effective data communication link being established between the host device and the docking station. In many failure scenarios, such as when the USB-C power delivery protocol handshake between the docking station and the host device fails, or when the display port alternation mode negotiation is interrupted, the entire data channel itself cannot be established properly. In such cases, the diagnostic software installed on the host device cannot initiate the diagnostic process because it cannot communicate with the docking station, or it can only return useless information that no device was detected, resulting in a poor user experience. Summary of the Invention

[0005] This application provides a fault diagnosis and intelligent display method and system for docking stations, which improves the user experience.

[0006] A first aspect of this application provides a fault diagnosis and intelligent display method for a docking station. The method includes: monitoring a communication negotiation process between the docking station and a host device; acquiring a first state transition event of the docking station and a second state transition event of the host device during the communication negotiation process; generating a composite event corresponding to the communication negotiation process based on the first and second state transition events, the composite event including multiple state transition events; if a target state transition event is determined to have been interrupted or failed, storing the target state transition event in a fault event queue arranged in chronological order, processing the fault event queue to determine a primary fault event, the target state transition event being any one of the multiple state transition events; retrieving information from a preset fault knowledge base based on the primary fault event to generate a structured display scheme; displaying a user interface on a display screen integrated in the docking station, and displaying the primary fault event on the user interface according to the structured display scheme.

[0007] By adopting the above technical solution, the communication negotiation process between the docking station and the main device is monitored, and state transition events of the docking station and the main device during the communication negotiation process are obtained. Based on these state transition events, composite events are generated, which can comprehensively capture and represent key events and the relationships between events during the communication negotiation process, providing a complete event information foundation for subsequent fault diagnosis. When a target state transition event is determined to be interrupted or failed, the target state transition event is stored in a fault event queue arranged in chronological order. By processing the fault event queue, the main fault event can be accurately located from numerous fault events, avoiding redundancy and interference of event information, and improving the efficiency and accuracy of fault location. Based on the identified main fault event, a search is performed in a preset fault knowledge base to generate a structured display scheme. By displaying the user interface on the screen integrated in the docking station and presenting the main fault event according to the structured display scheme, fault information can be clearly and intuitively presented to the user, improving the readability and understandability of the fault diagnosis results, facilitating users to quickly understand the fault situation and take corresponding measures, and enhancing the user experience. This method eliminates the dependence on the main device communication link, achieving independent, efficient, and accurate fault diagnosis and indication, significantly improving the user experience and fault handling efficiency.

[0008] Optionally, generating a composite event corresponding to the communication negotiation process based on the first state transition event and the second state transition event specifically includes: determining the sequential relationship between the first state transition event and the second state transition event in the communication negotiation process according to a preset state machine model, wherein the state machine model defines each state of the docking station and the master device in the communication negotiation process and the transition conditions between each state; identifying the triggering relationship between the first state transition event and the second state transition event, and determining whether the first state transition event and the second state transition event satisfy a preset triggering rule; if the first state transition event and the second state transition event satisfy the preset triggering rule, then combining the first state transition event and the second state transition event into the composite event according to the sequential relationship, and generating a corresponding event identifier for the composite event.

[0009] By adopting the above technical solution, in the process of generating composite events, the introduction of a preset state machine model can accurately determine the sequential relationship between the first and second state transition events during the communication negotiation process, ensuring the rationality and correctness of the event order in the composite event. Simultaneously, by identifying the triggering relationship between the first and second state transition events and determining whether they satisfy preset triggering rules, the causal logic between events can be accurately reflected, avoiding unreasonable event combinations. When the first and second state transition events satisfy the preset triggering rules, they are combined into a composite event according to their sequential relationship, and an event identifier is generated, forming a structured event combination unit. This retains the temporal characteristics of atomic events while revealing the triggering mechanism between events, making the representation of composite events more complete, standardized, and easy to understand, providing high-quality event data support for subsequent fault analysis and localization.

[0010] Optionally, processing the fault event queue to determine the primary fault event specifically includes: analyzing the contextual relationships of each fault event in the fault event queue and identifying the causal relationships between each fault event; constructing a causal relationship graph of the fault events based on the causal relationships, wherein the causal relationship graph includes multiple nodes and directed edges connecting the nodes, wherein the nodes represent fault events and the direction of the directed edges represents the causal relationship of the fault events; counting the in-degree of each node in the causal relationship graph, and determining the fault event corresponding to the node with the largest in-degree as the primary fault event, wherein the in-degree represents the number of directed edges with the node as the arc head.

[0011] By employing the aforementioned technical solution, in the process of processing the fault event queue to determine the primary fault event, the contextual relationships of each fault event in the queue are analyzed to identify the causal relationships between them. This reveals the occurrence and evolution patterns of faults, providing clues for fault tracing. Based on the identified causal relationships, a causal relationship graph of fault events is constructed, visually presenting the complex chain of fault events in a graphical form, facilitating the understanding and analysis of fault propagation paths. In the causal relationship graph, nodes represent fault events, and directed edges between nodes represent causal relationships. By statistically analyzing the in-degree of each node, the importance and influence of each fault event in the entire fault chain can be objectively measured. Identifying the fault event corresponding to the node with the highest in-degree as the primary fault event allows for rapid focus on the key aspects of the fault, identifying the main causes, avoiding the inefficiency of blindly searching among numerous fault events, and greatly improving the targeting and accuracy of fault localization.

[0012] Optionally, the step of retrieving data from a preset fault knowledge base based on the main fault event to generate a structured display scheme specifically includes: taking the node corresponding to the main fault event as the endpoint node, performing a reverse traversal in the causal relationship graph, searching for all directed edges pointing to the endpoint node, and tracing back along the directed edges to the starting node until all root cause nodes with an in-degree of zero are traversed, thus obtaining a complete fault propagation path from the root cause node to the endpoint node; matching preset graphic elements and connection styles for each node and directed edge in the complete fault propagation path; configuring the fault event corresponding to the root cause node to be highlighted in the complete fault propagation path, configuring the main fault event to be displayed in an alert mode, and constructing the transmission process from the root cause node to the endpoint node through the graphic elements and connection styles to obtain the structured display scheme.

[0013] By adopting the above technical solution, in the process of generating a structured display scheme based on the main fault event, the node corresponding to the main fault event is used as the endpoint node. A reverse traversal is performed in the causal relationship graph, tracing back along directed edges to all root cause nodes with an in-degree of zero. This yields the complete fault propagation path from the root cause node to the endpoint node, comprehensively demonstrating how the fault evolves and spreads step by step, revealing the complete picture of the fault. By matching preset graphical elements and connection styles to each node and directed edge in the complete fault propagation path, and highlighting the fault events corresponding to the root cause nodes while presenting the main fault event as an alert, the key event points on the fault path are intuitively and vividly depicted, highlighting the initial and final causes of the fault, making the fault propagation process clear at a glance. The propagation process from the root cause node to the endpoint node thus constructed forms a structured and visualized fault analysis report. This report not only preserves the integrity of the fault logic chain but also enhances readability and expressiveness through graphical representation, facilitating users to quickly and accurately understand and grasp the overall picture of the fault and take timely and effective countermeasures.

[0014] Optionally, after generating the composite event corresponding to the communication negotiation process based on the first state transition event and the second state transition event, the method further includes: monitoring the state changes of the docking station and the master device during the communication negotiation process; if a new state transition event is detected, determining whether the new state transition event can be combined with an existing composite event; if the new state transition event can be combined with the existing composite event, adding the new state transition event to the corresponding existing composite event and updating the order relationship and event identifier of the existing composite event; if the new state transition event cannot be combined with the existing composite event, treating the new state transition event as a new composite event and generating a corresponding event identifier.

[0015] By adopting the above technical solution, continuous monitoring of the status changes of the docking station and the main device during communication negotiation allows for the real-time acquisition of newly occurring state transition events, ensuring the integrity and timeliness of event information. Upon detecting a new state transition event, it is promptly determined whether the new event can be combined with existing composite events. This allows for dynamic adjustment of the structure and content of composite events to adapt to actual changes in the communication process. If the new state transition event can be combined with an existing composite event, the new event is added to the corresponding composite event, and the sequence relationship and event identifier of the composite events are updated, achieving dynamic incremental updates of composite events and avoiding omissions and failures in event data. If the new state transition event cannot be combined with an existing composite event, the new event is treated as a new composite event, and a corresponding identifier is generated, ensuring that newly emerging independent events can also be properly handled and represented. Through this dynamic adaptation, event information can be continuously tracked and recorded during communication negotiation, ensuring that event data is synchronized with the communication process in real time, providing a complete, accurate, and real-time data foundation for fault diagnosis.

[0016] Optionally, determining whether the new state transition event can be combined with an existing composite event specifically includes: constructing an event feature vector based on the attribute information of the new state transition event, wherein the attribute information includes the fault type, fault occurrence time, and fault functional location of the new state transition event; extracting common event features within each of the existing composite events; calculating the similarity between the event feature vector and the common event features; if the similarity is determined to be greater than a preset similarity threshold, then the new state transition event is determined to be able to be combined with the existing composite event; if the similarity is determined to be less than or equal to the preset similarity threshold, then the new state transition event is determined to be unable to be combined with the existing composite event.

[0017] By adopting the above technical solution, an event feature vector is constructed based on the attribute information of the new state transition event. This comprehensively considers multiple attribute dimensions such as the fault type, occurrence time, and functional location of the event, thus fully characterizing its features. Then, common features within each existing composite event are extracted, revealing the common characteristics and patterns of events within the composite event. By calculating the similarity between the feature vector of the new event and the common features of the existing composite events, the correlation and matching degree between the new event and the existing composite events can be quantitatively measured. When the similarity is greater than a preset threshold, it indicates that the new event and the existing composite event are highly consistent in features, and it can be determined that the new event can be combined with the composite event; when the similarity is less than or equal to the threshold, it indicates that the new event and the existing composite event differ significantly in features and are not suitable for combination. This quantitative judgment method based on event feature similarity overcomes the subjectivity and uncertainty of manual judgment, providing an objective, accurate, and automated event combination discrimination mechanism. This improves discrimination efficiency and ensures the reliability and consistency of the discrimination results.

[0018] Optionally, after monitoring the state changes of the docking station and the main device, the method further includes: performing time series alignment on historical first state transition events and historical second state transition events to form a state transition event sequence; segmenting and pattern mining the state transition event sequence to identify multiple state transition event sub-sequences and the occurrence frequency corresponding to each state transition event sub-sequence; determining a target state transition event sub-sequence with an occurrence frequency greater than a preset frequency, and using the target state transition event sub-sequence as a preset communication negotiation process mode; during the communication negotiation process, matching the preset communication negotiation process mode in real time, and if any first state transition event or any second state transition event is detected to deviate from the preset communication negotiation process mode, then predicting that a communication anomaly has occurred.

[0019] By adopting the above technical solution, after monitoring the status changes of the docking station and the main equipment, the historical first and second state transition events are aligned in time series to form a state transition event sequence. This allows discrete state transition events to be arranged into a continuous event stream in chronological order, facilitating overall analysis and mining of the event sequence. Through segmentation and pattern mining of the state transition event sequence, frequently occurring event sub-sequence patterns are identified, revealing typical patterns and regularities of equipment state transitions. These mined high-frequency event sub-sequences are used as preset communication negotiation process patterns, forming a set of standard event templates based on a large amount of historical data, reflecting the normal flow and general rules of the communication negotiation process. In actual communication negotiation, by matching the preset communication negotiation process pattern in real time, if a deviating state transition event is detected, a possible communication anomaly can be predicted in a timely manner, providing a basis for fault warning and timely handling. This method of summarizing standard communication negotiation patterns based on historical event data mining and using them to guide real-time communication monitoring and anomaly warning can fully utilize the experience and knowledge gained from historical data, making anomaly judgment more intelligent and accurate, and improving the efficiency and reliability of fault warning.

[0020] Secondly, embodiments of this application provide a fault diagnosis and intelligent display system for a docking station, the system comprising: one or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors calling the computer instructions to cause the system to perform the method described in the first aspect and any possible implementation thereof.

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

[0022] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a fault diagnosis and intelligent display system applied to a docking station, causes the fault diagnosis and intelligent display system applied to the docking station to perform the method described in the first aspect and any possible implementation thereof.

[0023] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages:

[0024] By monitoring the communication negotiation process between the docking station and the main device, multiple state transition events are captured and correlated to generate composite events. When a target state transition event is interrupted or fails, it is stored in a fault event queue, and the primary fault event is determined through priority adjudication. A structured display scheme is generated based on a fault knowledge base, and fault information and solution suggestions are presented intuitively on the docking station's built-in display screen. This method eliminates the dependence on the main device's communication link, achieving independent, efficient, and accurate fault diagnosis and indication, significantly improving user experience and fault handling efficiency. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating a fault diagnosis and intelligent display method for a docking station disclosed in an embodiment of this application;

[0026] Figure 2 This is another schematic flowchart of a fault diagnosis and intelligent display method for a docking station disclosed in an embodiment of this application;

[0027] Figure 3 This is a schematic diagram of the structure of a system provided in an embodiment of this application.

[0028] Explanation of reference numerals in the attached drawings: 301, Central Processing Unit; 302, Read-Only Memory; 303, Random Access Memory; 304, Bus; 305, Input / Output Interface; 306, Input Section; 307, Output Section; 308, Storage Section; 309, Communication Section; 310, Driver; 311, Removable Media. Detailed Implementation

[0029] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0030] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0031] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0032] This application provides a fault diagnosis and intelligent display method for docking stations, referring to... Figure 1 , Figure 1 This is a flowchart illustrating a fault diagnosis and intelligent display method for a docking station provided in an embodiment of this application. The method is applied to a system, which refers to a controller inside a docking station designed with fault diagnosis and intelligent display functions. The system can be used to execute fault diagnosis and intelligent display programs. The method includes steps S101 to S106, as follows:

[0033] Step S101: Monitor the communication negotiation process between the docking station and the main device.

[0034] In step S101, the docking station refers to an external hardware device used to expand the functional interfaces of the host device, such as providing additional USB ports, video output ports, network interfaces, etc. The host device refers to the core computing device connected to the docking station, such as a laptop, tablet, or smartphone, which provides data and power to the docking station. The communication negotiation process refers to a series of information exchanges and parameter configuration interactions between the docking station and the host device during their initial connection or when a function request is made, following a specific communication protocol, in order to establish a stable and efficient data transmission and power supply connection.

[0035] Specifically, after the system starts up, its built-in monitoring module continuously and in real-time monitors the physical communication channel between the docking station and the host device. For example, for a USB-C docking station, the system will focus on monitoring the data flow on its CC (Configuration Channel) pin. This monitoring module can capture every data packet exchanged between the two parties and decode these raw low-level communication signals into recognizable protocol messages. This monitoring process is 24 / 7 and non-intrusive; it does not interfere with normal communication but rather records the entire interaction history from connection establishment to stable operation or connection termination, providing the most original and complete data foundation for subsequent status analysis and fault diagnosis.

[0036] Step S102: Obtain the first state transition event of the docking station and the second state transition event of the master device during the communication negotiation process.

[0037] In step S102, the first state transition event refers to an event generated by a change in the docking station's own state during the communication negotiation process. It reflects the docking station's actions or responses in protocol interaction. For example, the docking station transitions from the "waiting for connection" state to the "capability list sent" state. The second state transition event refers to an event generated by a change in the master device's state. It is usually a response to a request or information issued by the docking station. For example, the master device transitions from the "waiting for power supply scheme" state to the "accepted 20V power supply scheme" state. These two events together constitute one interaction round in the communication negotiation process.

[0038] Specifically, after acquiring the raw protocol messages monitored in step S101, the system parses these messages according to a predefined state machine model. This state machine model precisely defines every possible state of the docking station and the master device under various communication protocols, as well as the conditions that must be met to transition from one state to another, i.e., the specific message received. When the system parses a message that satisfies the conditions for a certain state transition, the system generates a structured state transition event record. This record includes the timestamp of the event, the event source (docking station or master device), the initial state before the event, the target state after the event, and the specific message content that triggered the transition. In this way, the system transforms the continuous communication data stream into a series of discrete state transition event sequences with clear business meanings.

[0039] Step S103: Based on the first state transition event and the second state transition event, generate a composite event corresponding to the communication negotiation process. The composite event includes multiple state transition events.

[0040] In step S103, a composite event refers to a higher-level event set that better represents a complete business function, combining multiple independent atomic-level state transition events with inherent logical connections according to chronological order and causal relationships. For example, a composite event of "successfully establishing video output" may include multiple atomic events such as "dock requests to enter DP mode," "master device agrees to enter DP mode," and "HPD signal pulls high." Here, "state transition event" broadly refers to the aforementioned first and second state transition events.

[0041] Specifically, after receiving a series of discrete state transition events, the system activates an event composition engine. This engine has a built-in set of preset event composition rules. These rules define which sequences of state transition events can constitute a meaningful composite event. The system analyzes each newly generated state transition event and attempts to match it with previously occurring events. For example, a rule might define that when the system observes a "dock requests power scheme" event, followed by a "master device accepts power scheme" event within a specified time, and then a "power switch successful" event, these three events satisfy the conditions for constituting a "power negotiation successful" composite event. Once a match is found, the system packages these three events, assigns them a unique composite event identifier, and records the start and end times of the composite event. This process allows the system to understand the progress of communication negotiation from a macroscopic perspective, rather than focusing on scattered event points.

[0042] In one possible implementation, a composite event corresponding to the communication negotiation process is generated based on the first state transition event and the second state transition event, specifically including steps S1031-S103, as follows:

[0043] Step S1031: Based on the preset state machine model, determine the order of the first state transition event and the second state transition event in the communication negotiation process. The state machine model defines the various states of the docking station and the master device in the communication negotiation process, as well as the transition conditions between the various states.

[0044] In step S1031, the preset state machine model refers to a formalized mathematical model built into the system that precisely describes the complete logic of the communication protocol. This model contains a finite series of states, such as "waiting for connection," "sending capability list," and "waiting for request," which represent specific stages in the interaction process. The model also defines the transition conditions between states, that is, the inputs or events that must be satisfied to jump from one state to another, such as receiving a specific data packet. The sequence relation is used to represent the natural order in which different state transition events occur on the timeline, determined by comparing the timestamps of each event.

[0045] Specifically, upon receiving the first and second state transition events generated in step S102, the system does not simply treat them as independent event points. Instead, it invokes an internal preset state machine model, which acts as a "standard map" for protocol interaction. The system sorts each captured state transition event according to its timestamp. Then, starting from the first event, the system verifies, chronologically, whether the event sequence conforms to the valid path defined by the state machine model. For example, the state machine model stipulates that the master device can only enter the "Sent Power Request" state after the docking station enters the "Sent Capability List" state. By verifying the timestamps and event types, the system confirms that the docking station's event indeed occurred before the master device's event, thus verifying and determining the logical and temporal sequence of these two events. This process ensures that the subsequent event sequence analysis conforms to the protocol specifications, eliminating meaningless event sequencing caused by chance or erroneous signals.

[0046] Step S1032: Identify the triggering relationship between the first state transition event and the second state transition event, and determine whether the first state transition event and the second state transition event meet the preset triggering rules.

[0047] In step S1032, a triggering relationship refers to a direct, request-response connection between two or more state transition events. It reflects the causal relationship between events, meaning that the occurrence of one event is the direct cause of the occurrence of another event. Preset triggering rules refer to a series of logical judgment conditions stored internally by the system, which explicitly define the conditions that must be met to constitute a valid triggering relationship. For example, a rule might be defined as "After event A occurs, event B of type Y must occur within 100 milliseconds to satisfy the triggering relationship."

[0048] Specifically, after determining the chronological order of events, the system further analyzes their logical relationships. The system extracts adjacent or potentially related event pairs from the event sequence, such as an event from the docking station and a subsequent event from the master device. Then, the system loads a pre-defined trigger rule base and uses these rules to verify the event pair. For example, one rule states that "when the docking station triggers a 'Send Power Capability' event, the master device should trigger a 'Request Power Contract' event within a specified timeout period." The system checks if the currently analyzed event pair matches this rule, verifying the event type, the event source (docking station or master device), and the time interval between the two events. If all conditions are met, the system determines that a valid trigger relationship exists between the two events. The purpose of this step is to filter out event combinations that truly constitute a "dialogue" or "interaction" from a series of time-ordered events, laying the foundation for generating subsequent composite events.

[0049] Step S1033: If the first state transition event and the second state transition event satisfy the preset triggering rules, then the first state transition event and the second state transition event are combined into a composite event according to their sequential relationship, and a corresponding event identifier is generated for the composite event.

[0050] In step S1033, a composite event refers to a higher-level event unit that represents a complete business process, formed by bundling together multiple atomic state transition events that have been verified through triggering relationships, according to their original chronological order. An event identifier is a unique name or code assigned to a newly generated composite event, used for convenient referencing, recording, and querying of this composite event within the system. For example, an identifier could be "CE," where CE represents a composite event.

[0051] Specifically, when the system confirms in step S1032 that a set of state transition events meets the preset triggering rules, it means that these events have collectively completed a meaningful protocol interaction segment. At this point, the system performs a combination operation. It creates a new data structure, namely a composite event, and then places all the verified, causally related state transition events into this new data structure according to their original chronological order. In this way, the originally scattered events are organized into an organic whole. After the combination is completed, the system calls the identifier generation module to generate a semantically clear and globally unique event identifier for this newly created composite event based on the content of these events and their respective business domains, such as power supply negotiation or video mode negotiation. This identifier is stored together with the composite event, enabling the system to quickly and accurately locate this set of events representing a specific negotiation process in the subsequent fault diagnosis and information display stages.

[0052] Step S104: If it is determined that the target state transition event has been interrupted or failed, the target state transition event is stored in the fault event queue arranged in chronological order, and the fault event queue is processed to determine the main fault event. The target state transition event is any one of the multiple state transition events.

[0053] In step S104, the target state transition event refers to any state transition event that is expected to occur or is occurring during the communication negotiation process. An interruption or failure refers to a state transition failing to complete within the expected time, or failing to achieve the expected result after completion, such as timeout, receiving a rejection response, or entering an error state. The fault event queue is a temporary, chronologically ordered storage structure specifically used to record all state transition events determined to be failed or interrupted. The primary fault event refers to the fault event identified as the root cause or the one with the most significant impact in a series of cascading or concurrent fault events.

[0054] Specifically, the system performs a health check on each state transition event it monitors. For example, when the docking station sends a request, the system starts a timer. If the expected response from the master device is not received within the preset timeout period, the system determines that the "request" event has failed. This failed event, along with its timestamp, failure reason, and other information, is encapsulated into a fault event object and pushed to the end of the fault event queue. When an anomaly occurs during the communication negotiation process, multiple fault events may accumulate in this queue. Subsequently, the fault handling module analyzes all events in the queue. It constructs a temporary causal relationship graph. If fault A occurs earlier than fault B, and according to protocol logic, the failure of A may lead to the failure of B, an edge from A to B is drawn in the graph. After the analysis, the system calculates the in-degree of each node in the graph, that is, the number of edges pointing to that node. The fault event corresponding to the node with the highest in-degree is considered the core of the problem because it is caused by the most other faults or causes the most subsequent faults, and is therefore identified as the "primary fault event."

[0055] In one possible implementation, the fault event queue is processed to determine the main fault event, specifically including steps S1041-S1043, as follows:

[0056] Step S1041: Analyze the contextual relationships of each fault event in the fault event queue and identify the causal relationships between each fault event.

[0057] In step S1041, the fault event queue refers to a list that records all occurring faults or abnormal events, arranged chronologically or by other priorities. Contextual relationships are used to represent the environmental information surrounding a fault event, such as the time of the event, the operating status of the main device and the docking station at that time, and other events that occurred immediately before and after it. Causal relationships refer to the cause-and-effect relationship between fault events, that is, the occurrence of one fault event is a direct or indirect cause of another fault event.

[0058] Specifically, the system first acquires a queue of fault events containing multiple fault events. Instead of treating each fault independently, the system performs a correlation analysis on the events in the queue. The system iterates through the queue, examining the context of each fault event, particularly its temporal proximity to other fault events and its logical correlation with the protocol. Internally, the system has a pre-built causal relationship rule base, constructed based on communication protocol specifications and extensive expert experience. For example, a rule might be defined as "If a 'power negotiation timeout' event occurs, it is very likely to subsequently trigger a 'failure to enter DP alternation mode' event." The system matches the events in the queue against these rules. If the occurrence time and type of event A meet the conditions for a cause in the rule, and the occurrence time and type of event B meet the conditions for a result in the rule, the system establishes a temporary causal link between them, marking event A as causing event B. Through this process, the system can organize a series of seemingly isolated fault points into one or more logically related causal chains.

[0059] Step S1042: Based on causal relationships, construct a causal relationship graph of the fault events. The causal relationship graph includes multiple nodes and directed edges connecting the nodes. Nodes represent fault events, and the direction of the directed edges represents the causal relationship of the fault events.

[0060] In step S1042, the causal relationship graph is a graphical data structure that can intuitively display the mutual influence between fault events. Nodes are the basic elements of the graph, and each node uniquely corresponds to a fault event analyzed in step S1041. Directed edges are line segments with arrows connecting two nodes, and the direction of the arrows clearly indicates the causal relationship, pointing from the fault event node that is the cause to the fault event node that is the result.

[0061] Specifically, after the system identifies the causal relationships between various failure events, it begins to construct a data structure to store these relationships; this data structure is the causal relationship graph. First, the system iterates through all failure events in the failure event queue, creating an independent node for each unique failure event. Next, the system reviews all causal relationship pairs identified in step S1041, such as "event A causes event B". For each such pair, the system finds the node representing event A and the node representing event B in the graph, and then draws a directed edge from node A to node B. This process continues until all identified causal relationships have been transformed into directed edges in the graph. Finally, the system generates a complete causal relationship graph, which may contain one or more connected parts, clearly depicting how a failure propagates step by step from its initial root cause, triggering a series of other cascading failures.

[0062] Step S1043: Calculate the in-degree of each node in the causal relationship graph, and determine the fault event corresponding to the node with the largest in-degree as the main fault event. The in-degree represents the number of directed edges with the node as the arc head.

[0063] In step S1043, in-degree is a concept in graph theory. For a node in a causal graph, its in-degree is the total number of directed edges pointing to that node. Here, a high in-degree of a node means that the failure event is caused by multiple different upstream failure events. The main failure event refers to the most critical and core failure event determined by the system in a complex failure scenario. It is often the focal point of multiple problems or a key bottleneck in the failure propagation path.

[0064] Specifically, after constructing the causal relationship graph, the system initiates an analysis program to calculate the in-degree of each node in the graph. The system traverses all nodes in the graph, and for each node, it checks how many directed edges point to it, recording this number as the node's in-degree value. For example, if node C is pointed to by directed edges from both node A and node B, then node C's in-degree is 2. After calculating the in-degree of all nodes, the system compares these in-degree values ​​and finds the node with the highest in-degree value. The fault event corresponding to this node with the highest in-degree value is identified by the system as the "primary fault event" for this fault analysis. The logic behind selecting the event with the highest in-degree as the primary fault event is that this event is the convergence point of most other fault phenomena; solving it, or understanding why it occurred, often allows us to grasp the core of the entire fault problem. If multiple nodes have the same maximum in-degree, the system can ultimately determine a unique primary fault event based on preset secondary rules, such as selecting the one with the earliest timestamp or the one with the highest fault severity level.

[0065] For example, suppose a user connects their laptop (the main device) to a complex docking station, but finds that the external monitor is not working and the laptop cannot be charged. The system's background fault event queue records the following fault events: Event A is "Docking station VBUS bus voltage unstable"; Event B is "CRC check error in CC communication channel"; Event C is "Power negotiation failed"; Event D is "Laptop stops charging"; Event E is "DP alternation mode entry failed".

[0066] The system first executes step S1041 to analyze the context and causal relationships of these events. Based on the built-in protocol rules, the system identifies that "VBUS bus voltage instability" may prevent the communicating parties from establishing stable power negotiation; therefore, event A is a cause of event C. Simultaneously, "CC channel verification error" will inevitably lead to the upper-layer power negotiation failing to complete normally; therefore, event B is also a cause of event C. "Power negotiation failure" will directly cause the device to be unable to obtain the required power, thus triggering "laptop stopping charging," so event C is a cause of event D. Similarly, entering the higher-power DP video mode also depends on successful power negotiation; therefore, event C is also a cause of event E.

[0067] Next, in step S1042, the system begins to construct a causal relationship graph based on these identified causal relationships. It creates five nodes, representing events A, B, C, D, and E respectively. Then, it adds directed edges according to the causal relationships: one from A to C, one from B to C, one from C to D, and one from C to E.

[0068] Finally, the system executes step S1043 to calculate the in-degree of each node in the graph. Nodes A and B have no edges pointing to them, so their in-degree is 0. Nodes D and E each have only one edge from node C pointing to them, so their in-degree is 1. Node C, however, has two edges pointing to it, one from A and one from B, so its in-degree is 2. By comparison, the system finds that node C has the highest in-degree. Therefore, the system identifies the fault event "power negotiation failure" corresponding to node C as the primary fault event for this fault and presents it to the user or uses it in subsequent diagnostic processes as the most critical information.

[0069] Step S105: Based on the main fault event, search the preset fault knowledge base to generate a structured display scheme.

[0070] In step S105, the preset fault knowledge base is a pre-established database or knowledge graph that stores the mapping relationship between various known major fault events and user-friendly solutions. Each record in the database describes in detail the technical identifier of a fault, possible user-level causes, suggested troubleshooting steps, and relevant graphical elements for display. The structured display scheme refers to a data structure, which is not the final display interface itself, but rather a detailed set of instructions for generating the interface. It specifies what text should be displayed, what icons should be used, how the charts should be laid out, which parts need to be highlighted, etc., thereby transforming technical fault information into an intuitive and easy-to-understand visual presentation blueprint.

[0071] Specifically, the system uses the unique identifier of the main fault event determined in step S104 as the search keyword to query the preset fault knowledge base. The knowledge base will return entries matching the main fault event. For example, if the main fault event is "PD_CONTRACT_REJECTED", the knowledge base may return a record containing the following information: the title text is "Charging protocol negotiation failed", the detailed description is "Your main device rejected the charging solution provided by the docking station", the suggested action is "Please check if your main device supports the current power, or try replacing the charging cable", and it is associated with an icon ID representing "Power Warning". The system integrates and packages this information to form a structured display scheme object, which fully defines all the content and style to be displayed on the screen next, waiting for the display module to call it.

[0072] In one possible implementation, a structured display scheme is generated by searching a preset fault knowledge base based on the main fault event, specifically including steps S1051-S1053, as follows:

[0073] Step S1051: Using the node corresponding to the main fault event as the endpoint node, perform a reverse traversal in the causal relationship graph, find all directed edges pointing to the endpoint node, and trace back to the starting node along the directed edges until all root cause nodes with an in-degree of zero are traversed, thus obtaining the complete fault propagation path from the root cause node to the endpoint node.

[0074] In step S1051, the endpoint node refers to the node that serves as the target in this tracing analysis; it is the node corresponding to the main failure event identified in the previous steps. Reverse traversal is a graph traversal algorithm that does not follow the direction of the directed edges from cause to effect, but rather reverses the direction of the directed edges, starting from the result node and tracing back step by step to the cause node that led to it. Root cause nodes are nodes with an in-degree of zero in the causal relationship graph. These nodes represent the original starting point of the failure chain; they are causes, but not the result of any other event. A complete failure propagation path represents one or more complete causal chains that start from the root cause node, pass through a series of intermediate failure events, and finally converge to the main failure event. It may be a simple path or a tree structure formed by the convergence of multiple paths.

[0075] Specifically, the system first marks the node corresponding to the main fault event identified in the previous stage as the endpoint node for this analysis. Then, the system executes a reverse traversal algorithm starting from this endpoint node. The system checks all directed edges pointing to this endpoint node and identifies the starting nodes of these edges; these starting nodes are the direct causes of the main fault event. The system records these direct cause nodes and the directed edges connecting them. Next, for each newly discovered direct cause node, the system repeats the above process, continuing to search for directed edges pointing to them, thereby finding the cause at a higher level. This tracing process goes deeper and deeper, like peeling an onion, continuously backtracking in the reverse direction of the directed edges until the traced node no longer has any directed edges pointing to it, that is, the in-degree of the node is zero. These nodes with zero in-degree are the root cause nodes, representing the initial source of the fault. The system combines all the nodes and directed edges traversed throughout the entire backtracking process to form a complete topology from all relevant root cause nodes to the endpoint node; this structure is the final complete fault propagation path.

[0076] Step S1052: For each node and directed edge in the complete fault propagation path, match the preset graphical elements and connection styles.

[0077] In step S1052, the preset graphic elements refer to a set of predefined graphic symbols in the fault knowledge base used to visualize different fault events. For example, circles, squares, triangles, or specific icons are used to represent different categories or severity levels of faults. The connection style refers to the visual style of the directed edges that are also predefined to represent the causal relationship between fault events. For example, solid lines, dashed lines, and arrows of different thicknesses or colors can be used to distinguish different types of causal relationships, such as "strong association" or "weak association".

[0078] Specifically, after obtaining the complete fault propagation path, the system prepares to generate a structured visualization scheme. The system accesses an internal, pre-defined fault knowledge base, which stores the graphical element definitions corresponding to each known fault event type. The system traverses each node in the complete fault propagation path, searching and matching the corresponding pre-defined graphical element in the knowledge base based on the type of fault event represented by that node. For example, a "power negotiation failure" event might be matched with a square icon, while a "communication error" event might be matched with a circle icon. Similarly, the system matches connection styles for each directed edge in the path. This matching process can be simple, where all directed edges use the same standard arrow style; or it can be complex, matching different connection styles for causal relationships with different confidence levels according to the rules defined in the fault knowledge base, such as using thick solid arrows to represent deterministic direct causal relationships and dashed arrows to represent more probable inference relationships. After this step, each component in the fault propagation path is assigned specific visual attributes.

[0079] Step S1053: Configure the fault events corresponding to the root cause node to be highlighted in the complete fault propagation path, configure the main fault events to be displayed in the warning mode, and construct the transmission process from the root cause node to the end node through graphic elements and connection styles to obtain a structured display scheme.

[0080] In step S1053, the highlighting method is a special visual emphasis effect used to highlight graphic elements, making them particularly eye-catching in the entire view, with the aim of guiding the user's attention to the source of the fault. The warning method is another visual emphasis effect, usually carrying a warning or danger connotation, used to identify the most critical or serious fault event. The transmission process refers to the logical flow of the causal chain from the root cause of the fault to the main fault, clearly presented through graphical layout and connections. The structured display scheme refers to the final generated complete set of display instructions or data structures containing all graphic elements, connection styles, layout information, and special visual effects, which can be directly used to draw fault transmission diagrams on the user interface.

[0081] Specifically, the system configures the final visual effects based on the complete fault propagation path with pre-matched graphical elements and connection styles. First, the system identifies all root cause nodes in the path—those with an in-degree of zero. It then applies preset highlighting methods to the graphical elements corresponding to these nodes, such as adding a bright, continuously glowing border or enlarging their size. Next, the system finds the endpoint node in the path, the primary fault event node, and applies preset warning methods to its graphical elements, such as changing its color to a striking red and making it flash, or overlaying a warning symbol next to it. Finally, the system uses a suitable layout algorithm to organize all nodes and directed edges into a clear and legible graph. This layout explicitly shows the propagation process, typically placing root cause nodes on one side of the graph (e.g., top or left) and primary fault event nodes on the other side (e.g., bottom or right), connected by directed edges, visually illustrating how the fault propagates step-by-step from one or more root cause nodes and ultimately converges into the primary fault event. All this information, including the position, shape, color, and special effects of each node, as well as the style and path of each edge, together constitute the final structured display scheme.

[0082] For example, the system has already determined in the preceding steps that "power negotiation failure" (event C) is the primary fault event. Now, the system begins a reverse traversal of the causal graph, using the node representing event C as the endpoint node. The system finds two directed edges pointing to node C, originating from node A ("Instantaneous VBUS bus voltage at the docking station") and node B ("CRC checksum error in the CC communication channel"), respectively. The system continues tracing nodes A and B, finding that neither has directed edges pointing to itself, and both have an in-degree of zero; therefore, they are the root cause nodes. At this point, the system obtains the complete fault propagation path, which contains two branches: from root cause node A to endpoint node C, and from root cause node B to endpoint node C.

[0083] Next, the system matches visual elements to each part of this path. In the preset fault knowledge base, the system finds that the preset graphic element corresponding to the "voltage instability" event is a circle with a lightning bolt symbol, "communication error" corresponds to a circle with a corrupted data packet symbol, and "power negotiation failure" corresponds to a square with a prohibition symbol. All causal relationships are connected using standard solid black arrows.

[0084] Finally, the system began constructing a structured display scheme. It identified two root cause nodes, A and B, and configured them with a highlighting method, adding a bright green halo to their circular icons. Then, it located the primary fault event node C and configured it with an alert method, displaying its square icon as a flashing red. The system placed these two green-glowing root cause nodes side-by-side at the top of the display area, and the flashing red primary fault event node at the bottom. Then, two solid black arrows were drawn from the two upper nodes, converging on the lower node, clearly constructing a visual representation of the fault propagation process. This final graphical scheme intuitively tells the user that "voltage instability" and "communication errors" are the two root causes that together led to the core problem of "power negotiation failure."

[0085] Step S106: Display the user interface on the display screen integrated in the docking station, and display the main fault event on the user interface according to the structured display scheme.

[0086] In step S106, the integrated display screen of the docking station refers to a small display, such as an OLED or LCD screen, physically embedded in the docking station's casing, capable of dynamically displaying information. The user interface refers to the graphical or text-based interface presented to the user on the display screen, which carries the results of fault diagnosis and guidance information.

[0087] Specifically, the system's display driver receives the structured display scheme generated in step S105. It first initializes a basic user interface layout on the display screen, which may include a title area, a details area, and a suggestion area. Then, the driver parses the instructions in the structured display scheme, rendering the specified title text "Charging protocol negotiation failed" into the title area, and filling the corresponding areas with detailed descriptions and suggested operations. Simultaneously, it loads the corresponding "Power Warning" icon from the internal resource library based on the icon ID provided in the scheme and displays it in a prominent position on the interface. This entire process materializes the abstract fault codes and data display scheme into clear and concise fault descriptions and operation instructions that are visible to the user, thus achieving intelligent fault display.

[0088] Please refer to Figure 2 In one possible implementation, after generating the composite event corresponding to the communication negotiation process based on the first state transition event and the second state transition event, the method further includes steps S201-S208, as follows:

[0089] Step S201: During the communication negotiation process, monitor the status changes of the docking station and the main device.

[0090] In step S201, the communication negotiation process refers to a series of interactions between the docking station and the host device to establish a normal working relationship, such as power role negotiation and data role negotiation in the USB Power Delivery protocol. State changes refer to events in which a device transitions from one operating state to another, especially abnormal state transitions that deviate from the normal negotiation process; these are often early signs of failure.

[0091] Specifically, the system plays a continuous monitoring role in this step. It uses built-in sensors, log analysis modules, or bus analyzers to continuously monitor the communication bus connecting the docking station and the host device in real time, such as the USB-C CC pin or the VBUS power line. The system focuses on key physical parameters such as voltage and current, as well as protocol-level data packets and state machine transitions. Once the system detects any changes outside the predefined range, or a state transition that does not conform to the protocol specifications, it records this change as a newly discovered state change event requiring further analysis.

[0092] Step S202: If a new state transition event is detected, an event feature vector is constructed based on the attribute information of the new state transition event. The attribute information includes the fault type, fault occurrence time, and fault functional part of the new state transition event.

[0093] In step S202, the new state transition event refers to the most recently detected state change in step S201. Attribute information is a set of data used to describe the essential characteristics of the event, containing at least three dimensions: fault type to indicate the nature of the event, such as a voltage anomaly or a communication error; fault occurrence time to indicate the precise location of the event on the timeline, typically a timestamp; and fault functional location to indicate the physical or logical location of the event, such as a VBUS power line or a CC communication channel. The event feature vector refers to converting this multi-dimensional, potentially non-numerical attribute information into a standardized numerical array or vector that can be used for mathematical calculations.

[0094] Specifically, when the system detects a new state transition event, it immediately provides a structured description of the event. The system first parses the raw data of the event, categorizing it into a predefined fault type directory; for example, "VBUS voltage below 4.75V" is categorized as "voltage dip". Simultaneously, the system records the precise timestamp of the event. Furthermore, the system determines the specific functional area affected by the fault, such as the "VBUS pin". Subsequently, the system vectorizes this structured attribute information. This process typically involves converting category information, such as fault type and functional area, into numerical values ​​using an encoding scheme, such as one-hot encoding or tag encoding. For example, "voltage dip" might be encoded as the number 1, and "CC communication channel" might be encoded as the number 5. Finally, the system combines these numerical values, along with the numerical timestamp, into an ordered array, namely the event feature vector, such as a vector of the form [fault type code, fault functional area code, timestamp].

[0095] Step S203: Extract the common features of events within each existing composite event.

[0096] In step S203, an existing composite event refers to one or more event sets that have been formed before the current analysis time, each set containing a series of state transition events considered to be interrelated. Common event characteristics refer to representative features that can represent the core characteristics of an existing composite event; they are extracted from the characteristics of all member events within the composite event and reflect the common attributes of this event cluster.

[0097] Specifically, before classifying new events, the system needs to generate a "portrait" or "signature" for each existing composite event; this portrait represents the common features of the events. The system iterates through all existing composite events in memory. For each composite event, the system examines the feature vectors of all events it contains. There are several methods for extracting common features. One simple and effective way is to calculate the centroid of the feature vectors of all events within the composite event, i.e., to take the average value for each dimension of the vector. Another method is to use the most frequently occurring feature value as the common feature for categorical features. For example, if a composite event contains three events, all of which have the fault type "voltage drop," then the common feature of this composite event in the "fault type" dimension is determined to be "voltage drop."

[0098] Step S204: Calculate the similarity between the event feature vector and the common features of the event.

[0099] In step S204, the event feature vector is the numerical vector constructed for the new state transition event in step S202. The common event features are the representative feature vectors extracted for each existing composite event in step S203. Similarity is a quantitative measure used to evaluate the degree of association between a new event and an existing event cluster. Its value is usually within a fixed range, such as between 0 and 1, with a larger value indicating a stronger association.

[0100] Specifically, the system performs a matching process. It extracts the feature vector of the new state transition event and then compares it one by one with the common features of each existing composite event. Several mathematical methods can be used to calculate similarity. One method is to calculate the cosine similarity between two vectors, which focuses on the consistency of vector directions and is suitable for measuring the similarity of feature patterns. Another method is to calculate the reciprocal of the Euclidean distance; the closer the distance, the higher the similarity. During the calculation, the system can also assign different weights to features of different dimensions; for example, the matching degree of fault type and functional part may be more important than the proximity of timestamps. The system calculates a specific similarity score for each new event and each existing composite event.

[0101] Step S205: If the similarity is determined to be greater than the preset similarity threshold, then it is determined that the new state transition event can be combined with the existing composite event.

[0102] In step S205, the preset similarity threshold is a critical value pre-set by a domain expert or learned from historical data. It serves as a standard for determining whether a new event should be attributed to an existing composite event. For example, the threshold can be set to 0.8.

[0103] Specifically, after obtaining a list of similarity scores between the new event and all existing composite events, the system checks these scores one by one. The system takes a score and compares it to a preset similarity threshold. If the score is greater than the threshold, the system makes a positive judgment: this new state transition event and the currently compared existing composite event are strongly correlated in their root cause or influence chain, therefore they should be combined. If the similarity between the new event and multiple existing composite events exceeds the threshold, the system usually selects the one with the highest similarity for combination.

[0104] Step S206: If the similarity is determined to be less than or equal to the preset similarity threshold, then it is determined that the new state transition event cannot be combined with the existing composite event.

[0105] In step S206, the judgment logic is the opposite of that in step S205.

[0106] Specifically, when comparing the similarity score with a preset similarity threshold, the system makes a negative judgment if the score is less than or equal to the threshold. This means that although the new event may have some accidental similarities with the existing composite event, their correlation is insufficient to be considered as belonging to the same failure scenario. If the similarity score calculated between the new event and all existing composite events does not exceed the threshold, then the system ultimately determines that the new event is an independent event with no strong correlation to any known event cluster.

[0107] Step S207: If the new state transition event can be combined with an existing composite event, then add the new state transition event to the corresponding existing composite event and update the order of the existing composite events and the event identifier.

[0108] In step S207, the chronological order refers to the ordering of all member events within a composite event according to their natural chronological sequence of occurrence. The event identifier is a unique name or number assigned to each composite event for tracking and management.

[0109] Specifically, after the system determines in step S205 that a new event can be combined with an existing composite event, the system performs a merging operation. First, the system adds this new state transition event, along with its complete attribute information and feature vector, as a new member to the selected set of existing composite events. Next, the system reads the timestamps of all member events within the composite event and reorders them to ensure that the entire event sequence strictly follows chronological order. Finally, the system may update the metadata of the composite event to reflect its changes. For example, it may update its event identifier, perhaps by appending a version number to the original identifier, or by updating a content-related hash value to indicate that the content of the composite event has evolved.

[0110] Step S208: If the new state transition event cannot be combined with an existing composite event, then the new state transition event is treated as a new composite event, and a corresponding event identifier is generated.

[0111] In step S208, the new composite event is a completely new set of events, whose initial members only include the current "new state transition event" that cannot be classified.

[0112] Specifically, when the system determines, according to step S206, that a new event cannot be combined with any existing composite event, the system considers it to be the beginning of a completely new fault scenario. Therefore, the system creates a new, empty composite event structure. Then, this new state transition event is placed as the first member of this new structure. Simultaneously, the system invokes an identifier generation mechanism, such as an incrementing counter or a universally unique identifier generator, to assign a completely new, system-unique event identifier to this new composite event. At this point, this new event becomes a new starting point for fault analysis, awaiting subsequent related events.

[0113] For example, suppose that during USB Power Delivery negotiation between the host device and the docking station, the system has identified and created an existing composite event with the event identifier "CE_001". This composite event contains an event: E1, whose attribute information is {Fault Type: VBUS Voltage Drop, Functional Location: VBUS Power Line, Occurrence Time: 10:00:01.100}. The common characteristics of the events extracted by the system are consistent with the characteristics of E1.

[0114] The system continuously monitors state changes. At 10:00:01:350, a new state transition event E2 is detected, with attributes of {Fault Type: CC Communication Timeout, Functional Location: CC Communication Channel, Occurrence Time: 10:00:01:350}. The system constructs an event feature vector for it. Subsequently, the system calculates the similarity between the feature vector of E2 and the common features of “CE_001”. Since the fault type (voltage comparison communication) and functional location (power line comparison communication channel) are completely different, the calculated similarity is only 0.2. Assuming the preset similarity threshold is 0.7, the system determines that 0.2 is less than 0.7, therefore E2 cannot be combined with “CE_001”. Therefore, the system executes step S208, treating E2 as a new composite event and generating a new event identifier “CE_002” for it.

[0115] Several hundred milliseconds later, at 10:00:01.800, the system detected a new event E3 with the attributes {Fault Type: VBUS voltage drop, Functional Location: VBUS power line, Occurrence Time: 10:00:01.800}. After constructing a feature vector for it, the system calculated the similarity of its common features with "CE_001" and "CE_002". Compared with "CE_001", E3's fault type and functional location are completely identical, and the time is also close, with a similarity of 0.95. Compared with "CE_002", it is almost dissimilar, with a similarity of 0.15. The system determined that 0.95 is greater than 0.7, therefore E3 can be combined with "CE_001". The system then executes step S207, adding E3 to "CE_001" and updating its internal order based on the timestamp, with E1 preceding E3. Simultaneously, the system may update the identifier of "CE_001" or its metadata to reflect changes in its member count and time span. This process continues, with similar events being aggregated to form a dynamic classification of different fault scenarios.

[0116] Please refer to Figure 2 In one possible implementation, after monitoring the status changes of the docking station and the main device during the communication negotiation process, the method further includes steps S209-S213, as follows:

[0117] Step S209: Align the historical first state transition event and the historical second state transition event in time series to form a state transition event sequence.

[0118] In step S209, the first historical state transition event and the second historical state transition event refer to the set of all state transition events recorded and stored by the system during a large number of past communication and negotiation processes. Time series alignment represents a data preprocessing procedure, the core of which is to uniformly sort all individual events from different time points and different sessions strictly according to their respective timestamps from first to last. The state transition event sequence refers to a single, chronologically ordered long stream of events containing all historical events, formed after time series alignment.

[0119] Specifically, the system first accesses its historical database, which stores tens of thousands of successful or failed communication records between the master device and the docking station. From these records, the system extracts all state transition events, each with a timestamp accurate to milliseconds or microseconds. Then, the system performs an alignment operation, essentially a global sorting process. It aggregates all these events, ignoring their original communication sessions, and sorts them in ascending order based solely on their timestamps. After this process, the system obtains a very long, linear sequence of events that faithfully records the chronological order of state transition events across all historical observations, providing standardized input data for subsequent pattern mining.

[0120] Step S210: Segment and pattern mining are performed on the state transition event sequence to identify multiple state transition event subsequences and the occurrence frequency of each state transition event subsequence.

[0121] In step S210, segmentation and pattern mining refer to data analysis techniques used to discover recurring, meaningful local patterns from the long sequence generated in step S209. Segmentation is typically achieved using methods such as sliding windows, while pattern mining uses specific algorithms to find frequent items. A state transition event subsequence represents a short sequence of two or more consecutive events discovered through mining; for example, "event A immediately following event B" is a subsequence of length 2. The frequency of occurrence refers to the total number of times a specific state transition event subsequence repeats throughout the entire historical event stream.

[0122] Specifically, the system employs sequential pattern mining algorithms, such as the GSP algorithm or the PrefixSpan algorithm, to process the state transition event sequence formed in step S209. An intuitive implementation involves setting a window length, for example, 3. This window then slides backward from the beginning of the long sequence. Each slide defines a subsequence containing three consecutive events. The system records this subsequence, then moves the window one position forward to define a new subsequence. This process continues until the window reaches the end of the long sequence. After sliding, the system has a list of all occurrences of subsequences of length 3. Finally, the system statistically analyzes this list to calculate the total number of occurrences of each unique subsequence; this number is its frequency.

[0123] Step S211: Determine the target state transition event subsequence with an occurrence frequency greater than the preset frequency, and use the target state transition event subsequence as the preset communication negotiation process mode.

[0124] In step S211, the preset frequency is a threshold value set by technicians based on experience or derived through statistical analysis. It is used to filter out frequently occurring event patterns that are generally representative. The target state transition event subsequence refers to those subsequences whose frequency of occurrence successfully exceeds this preset frequency; these are considered "normal" or "typical" communication behavior segments. The preset communication negotiation process pattern represents a set or knowledge base that stores all event subsequences identified as targets that represent normal communication flows.

[0125] Specifically, the system iterates through the list generated in step S210, which contains all subsequences and their frequencies. For each subsequence in the list, the system compares its frequency with a preset frequency threshold. For example, if the preset frequency is 1000 times, any subsequence that appears more than 1000 times will be marked as a "target state transition event subsequence." Subsequences with infrequent occurrences are ignored and discarded because they may represent rare anomalies or noise. Finally, the system collects all subsequences marked as targets and stores them in a dedicated pattern library. This pattern library constitutes the final preset communication negotiation process pattern, which is equivalent to a rulebook recording all "standard operating procedures."

[0126] Step S212: During the communication negotiation process, the preset communication negotiation process mode is matched in real time. If any first state transition event or any second state transition event is detected to deviate from the preset communication negotiation process mode, a communication abnormality is predicted to occur.

[0127] In step S212, real-time matching refers to the system dynamically comparing the currently observed event sequence with the pattern library established in step S211 during a new ongoing communication negotiation process. A deviation from the preset communication negotiation process pattern indicates that the currently occurring event subsequence cannot find any "standard pattern" in the pattern library that perfectly matches it. Predicting a communication anomaly means that the system issues an early warning signal based on this deviation, indicating that the current communication process has deviated from its known normal trajectory and is likely heading towards failure or malfunction.

[0128] Specifically, this step is the application phase of the aforementioned training phase. When a new communication negotiation process begins, the system enters real-time monitoring mode. The system maintains a real-time event buffer with the same window length as that used during pattern mining. Whenever a new state transition event occurs, it is pushed into this buffer. For example, if all patterns in the pattern library have a length of 3, then when the buffer collects 3 of the latest consecutive events, it forms a real-time state transition event subsequence. The system immediately takes this real-time subsequence and queries the preset communication negotiation process pattern library established in step S211. If a completely identical pattern is found in the library, it indicates that the current communication process is normal. Conversely, if the system queries the entire pattern library and fails to find any match for this real-time subsequence, the system determines that a deviation has occurred. At this time, the system immediately triggers an anomaly warning mechanism, such as recording a high-level log or notifying the upper-level management system, thereby achieving early prediction and judgment of communication anomalies.

[0129] The following describes a fault diagnosis and intelligent display system applied to a docking station from the perspective of hardware processing. Please refer to [link to relevant documentation]. Figure 3 This is a schematic diagram of a fault diagnosis and intelligent display system applied to a docking station in an embodiment of this application.

[0130] It should be noted that, Figure 3 The structure of a fault diagnosis and intelligent display system for a docking station shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0131] like Figure 3 As shown, a fault diagnosis and intelligent display system applied to a docking station includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes according to a program stored in a Read-Only Memory (ROM) 302 or a program loaded from a storage section 308 into a Random Access Memory (RAM) 303, such as executing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

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

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

[0134] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

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

[0136] Specifically, a fault diagnosis and intelligent display system for a docking station according to this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the fault diagnosis and intelligent display method for a docking station provided in the above embodiment.

[0137] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the fault diagnosis and intelligent display system for a docking station described in the above embodiments; or it may exist independently and not assembled into the fault diagnosis and intelligent display system for a docking station. The storage medium carries one or more computer programs, which, when executed by a processor of the fault diagnosis and intelligent display system for a docking station, cause the system to implement the fault diagnosis and intelligent display method for a docking station based on encrypted data transmission via the Internet of Things provided in the above embodiments.

Claims

1. A fault diagnosis and intelligent display method applied to a docking station, characterized in that, The method includes: Monitor the communication negotiation process between the expansion dock and the main device; Acquire the first state transition event of the docking station and the second state transition event of the master device during the communication negotiation process; Based on the first state transition event and the second state transition event, a composite event corresponding to the communication negotiation process is generated, and the composite event includes multiple state transition events; If it is determined that the target state transition event has been interrupted or failed, the target state transition event is stored in a fault event queue arranged in chronological order, and the fault event queue is processed to determine the main fault event. The target state transition event is any one of the multiple state transition events. Based on the main fault event, a search is performed in the preset fault knowledge base to generate a structured display scheme; The user interface is displayed on the screen integrated in the docking station, and the main fault event is displayed on the user interface according to the structured display scheme; The generation of the composite event corresponding to the communication negotiation process based on the first state transition event and the second state transition event specifically includes: Based on a preset state machine model, the sequential relationship between the first state transition event and the second state transition event in the communication negotiation process is determined. The state machine model defines the various states of the docking station and the main device in the communication negotiation process, as well as the transition conditions between the various states. Identify the triggering relationship between the first state transition event and the second state transition event, and determine whether the first state transition event and the second state transition event meet the preset triggering rules; If the first state transition event and the second state transition event satisfy the preset triggering rule, then the first state transition event and the second state transition event are combined into the composite event according to the order relationship, and a corresponding event identifier is generated for the composite event.

2. The method according to claim 1, characterized in that, The process of processing the fault event queue to determine the primary fault event specifically includes: Analyze the contextual relationships of each fault event in the fault event queue to identify the causal relationships between each fault event; Based on the causal relationship, a causal relationship graph of the fault events is constructed. The causal relationship graph includes multiple nodes and directed edges connecting the nodes. The nodes represent fault events, and the direction of the directed edges represents the causal relationship of the fault events. The in-degree of each node in the causal relationship graph is counted, and the fault event corresponding to the node with the largest in-degree is determined as the main fault event. The in-degree represents the number of directed edges with the node as the arc head.

3. The method according to claim 2, characterized in that, The step of retrieving data from a preset fault knowledge base based on the main fault event and generating a structured display scheme specifically includes: Using the node corresponding to the main fault event as the endpoint node, perform a reverse traversal in the causal relationship graph to find all directed edges pointing to the endpoint node, and trace back to the starting node along the directed edges until all root cause nodes with an in-degree of zero are traversed, thus obtaining the complete fault propagation path from the root cause node to the endpoint node. For each node and directed edge in the complete fault propagation path, match preset graphical elements and connection styles; In the complete fault propagation path, the fault events corresponding to the root cause node are highlighted, the main fault events are displayed as warnings, and the transmission process from the root cause node to the endpoint node is constructed through the graphic elements and connection styles to obtain the structured display scheme.

4. The method according to claim 1, characterized in that, After generating the composite event corresponding to the communication negotiation process based on the first state transition event and the second state transition event, the method further includes: During the communication negotiation process, the status changes of the docking station and the main device are monitored; If a new state transition event is detected, it is determined whether the new state transition event can be combined with an existing composite event; If the new state transition event can be combined with the existing composite event, then the new state transition event is added to the corresponding existing composite event, and the order of the existing composite events and the event identifier are updated. If the new state transition event cannot be combined with the existing composite event, then the new state transition event is treated as a new composite event, and a corresponding event identifier is generated.

5. The method according to claim 4, characterized in that, The determination of whether the new state transition event can be combined with an existing composite event specifically includes: An event feature vector is constructed based on the attribute information of the new state transition event. The attribute information includes the fault type, fault occurrence time, and fault functional part of the new state transition event. Extract the common features of each of the existing composite events; Calculate the similarity between the event feature vector and the common features of the event; If the similarity is determined to be greater than a preset similarity threshold, then the new state transition event is determined to be able to be combined with the existing composite event; If the similarity is determined to be less than or equal to the preset similarity threshold, then the new state transition event cannot be combined with the existing composite event.

6. The method according to claim 4, characterized in that, After monitoring the status changes of the docking station and the host device during the communication negotiation process, the method further includes: The first and second historical state transition events are time-series aligned to form a state transition event sequence. The state transition event sequence is segmented and pattern mining is performed to identify multiple state transition event subsequences and the occurrence frequency of each state transition event subsequence. Determine a target state transition event subsequence that occurs at a frequency greater than a preset frequency, and use the target state transition event subsequence as a preset communication negotiation process mode; During the communication negotiation process, the preset communication negotiation process mode is matched in real time. If any first state transition event or any second state transition event is detected to deviate from the preset communication negotiation process mode, a communication anomaly is predicted to occur.

7. A fault diagnosis and intelligent display system for a docking station, characterized in that, The system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the system to perform the method as described in any one of claims 1-6.

8. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the fault diagnosis and intelligent display system applied to the docking station, the fault diagnosis and intelligent display system applied to the docking station performs the method as described in any one of claims 1-6.

9. A computer program product, comprising instructions, characterized in that, When the instructions are executed on the fault diagnosis and intelligent display system applied to the docking station, the fault diagnosis and intelligent display system applied to the docking station performs the method as described in any one of claims 1-6.

Images