Fault diagnosis method and electronic device

Abstract

The application discloses a fault diagnosis method and electronic equipment, and relates to the technical field of equipment management. Through a component topology address mapping table, the multi-protocol communication address and component belonging relationship are uniformly regularized, automatic association of various heterogeneous protocol messages and corresponding hardware components is realized, automatic restoration of fault communication context is realized, the fault type and fault source are accurately located, manual operation is reduced, and thus the fault diagnosis efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of equipment management technology, and in particular to fault diagnosis methods and electronic equipment. Background Technology

[0002] During equipment operation, alarm information from various components is collected in real time for fault diagnosis. Currently, related technologies rely on manual comparison to identify faults corresponding to alarm information, which is inefficient. Summary of the Invention

[0003] This application provides a fault diagnosis method and electronic device to at least solve the problem of low fault diagnosis efficiency in related technologies.

[0004] This application provides a fault diagnosis method, comprising: responding to component fault alarm information, determining a fault period based on the alarm trigger time; determining all messages between the controller and each component, wherein the all messages are collected in real time; determining at least one target message corresponding to the faulty component from the all messages according to the fault period and a component topology address mapping table, wherein the component topology address mapping table represents the address information of each component under each communication protocol; and analyzing the at least one target message to obtain fault diagnosis information corresponding to the faulty component.

[0005] This application also provides a fault diagnosis device, comprising: a time module, used to determine the fault period based on the alarm trigger time in response to component fault alarm information; an acquisition module, used to determine the full amount of messages between the controller and each component, wherein the full amount of messages is acquired in real time; a filtering module, used to determine at least one target message corresponding to the faulty component from the full amount of messages according to the fault period and a component topology address mapping table, wherein the component topology address mapping table represents the address information of each component under each communication protocol; and an analysis module, used to analyze the at least one target message to obtain fault diagnosis information corresponding to the faulty component.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described fault diagnosis methods.

[0007] This application also provides a non-volatile computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described fault diagnosis methods.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described fault diagnosis methods.

[0009] By using a component topology address mapping table, the multi-protocol communication addresses and component affiliation relationships are uniformly organized, enabling automatic association of various heterogeneous protocol messages with corresponding hardware components, automatic restoration of fault communication context, accurate location of fault type and fault source, reduction of manual operation, and thus improvement of fault diagnosis efficiency. Attached Figure Description

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

[0011] Figure 1 This is a schematic diagram illustrating an application scenario of a fault diagnosis method provided in an embodiment of this application;

[0012] Figure 2 A flowchart illustrating a fault diagnosis method provided in an embodiment of this application;

[0013] Figure 3 A flowchart illustrating another fault diagnosis method provided in an embodiment of this application;

[0014] Figure 4 A schematic diagram of a message snapshot provided for an embodiment of this application;

[0015] Figure 5 A schematic diagram illustrating the circular storage of messages provided in an embodiment of this application;

[0016] Figure 6 This is a schematic diagram of the structure of a fault diagnosis device provided in an embodiment of this application;

[0017] Figure 7 This is a schematic diagram of another fault diagnosis device provided in an embodiment of this application;

[0018] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application 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. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0020] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0021] In devices such as servers, the controller plays a crucial role in monitoring and managing the status of the server's internal components. These components include, but are not limited to, the central processing unit (CPU), graphics processing unit (GPU), network interface card (NIC), power supply, and fans.

[0022] The server communicates with components in real time, collects key indicators such as temperature, voltage, power consumption, and link status, and records system event logs to assist in fault diagnosis.

[0023] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0024] The specific application environment architecture upon which the fault diagnosis method depends is described here. (References) Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario for a fault diagnosis method. The controller connects to multiple components and collects information from them. When the controller receives a component fault alarm, it performs fault diagnosis to determine the fault type.

[0025] In practical applications, the controller connects to multiple components through various communication protocols, and the controller and these components transmit messages through these protocols. Examples include Inter-Integrated Circuit (I2C), Improved Inter-Integrated Circuit (I3C), Power Management Bus (PMBus), and Management Component Transport Protocol (MCTP).

[0026] The controller monitors the health status of each component in real time, and triggers fault diagnosis when it detects fault alarm information such as excessive temperature, abnormal voltage, or communication interruption.

[0027] In related technologies, fault diagnosis is performed by manually comparing data from multiple protocols. However, cross-protocol communication messages cannot be uniformly captured and associated with specific components, resulting in a lack of complete communication context during fault analysis and inefficiency in manual diagnosis.

[0028] In particular, for complex component connections, such as graphics processors and smart network cards, the interaction between them and the controller may involve multiple communication protocols. The data fragmentation problem of related technologies makes it impossible to quickly obtain the complete communication context before and after the fault. Fault diagnosis relies heavily on human experience, resulting in low fault diagnosis efficiency.

[0029] Figure 2 This is a flowchart illustrating the fault diagnosis method provided in the embodiments of this application, as shown below. Figure 2 As shown, embodiments of this application provide a fault diagnosis method, which is described in detail below:

[0030] S201. In response to component fault alarm information, determine the fault period based on the alarm trigger time.

[0031] Specifically, when any component monitoring service module (such as the temperature monitoring module) inside the controller detects a component failure, it will generate a component failure alarm message.

[0032] Optionally, the component fault alarm information includes the faulty component identifier, fault type (such as overheating, link disconnection), and alarm trigger time.

[0033] This step uses the alarm trigger time as a reference point and determines a continuous time range for analyzing the fault context, i.e., the fault period, through preset rules. For example, this fault period could be 30 seconds before and 10 seconds after the alarm trigger time.

[0034] Optionally, the controller can be a Baseboard Management Controller (BMC).

[0035] S202. Determine the full amount of messages between the controller and each component. The full amount of messages are collected in real time.

[0036] The controller's internal message capture service continuously and in real-time captures all raw communication data packets exchanged between the controller and all monitored components via various protocols, and processes them to form a full message. The full message is a cross-protocol collection of information containing rich metadata, rather than a single sensor value or a packet capture file of a specific bus.

[0037] S203. Based on the fault period and the component topology address mapping table, determine at least one target message corresponding to the faulty component from the full number of messages. The component topology address mapping table represents the address information of each component under each communication protocol.

[0038] Upon receiving an alarm, a pre-generated component topology address mapping table is used. This table records the addresses of each component under different communication protocols.

[0039] By combining the fault period and component topology address mapping table, all messages related to the faulty component can be quickly and accurately filtered from a massive amount of full messages to form the target message, thereby improving fault diagnosis efficiency.

[0040] S204. Analyze at least one target message to obtain fault diagnosis information corresponding to the faulty component.

[0041] The selected target messages are subjected to in-depth analysis, including timing arrangement and content parsing. The analysis process can compare the issued commands and returned responses, check the timing intervals of messages, and identify abnormal error codes, thereby obtaining logically clear and evidence-based fault diagnosis information, such as "component firmware is unresponsive" or "communication link jitter".

[0042] The fault diagnosis method provided in this application responds to component fault alarm information and determines the fault period based on the alarm trigger time; it determines all messages between the controller and each component, which are collected in real time; based on the fault period and the component topology address mapping table, it determines at least one target message corresponding to the faulty component from the all messages, where the component topology address mapping table represents the address information of each component under each communication protocol; it analyzes the at least one target message to obtain the fault diagnosis information corresponding to the faulty component. By establishing a cross-protocol component topology address mapping table and accurately extracting target messages from continuously captured all messages based on the fault period and the mapping table, it achieves automatic capture and association of the complete communication context before and after the fault. This application uses the component topology address mapping table to uniformly organize multi-protocol communication addresses and component affiliation relationships, realizes automatic association of various heterogeneous protocol messages with corresponding hardware components, automatically restores the fault communication context, accurately locates the fault type and fault source, reduces manual operation, and thus improves fault diagnosis efficiency.

[0043] Based on any of the above embodiments, the following, in conjunction with Figure 3 The detailed process of fault diagnosis is explained.

[0044] Figure 3 This is a flowchart illustrating another fault diagnosis method provided in an embodiment of this application. Figure 3 As shown, the method includes:

[0045] S301. In response to component fault alarm information, determine the fault period based on the alarm trigger time.

[0046] For example, when any monitoring service of the controller (such as temperature, voltage, or watchdog timer) detects an abnormal component status and generates an alarm, such as when a sensor reading exceeds a threshold, an alarm message is issued. The system program immediately parses this message to obtain the alarm trigger time.

[0047] Subsequently, based on the alarm trigger time, the fault period is determined according to preset or configurable parameters. The fault period is used to define the time range of data that needs to be analyzed.

[0048] One feasible implementation method is to determine the fault period by: determining the preset pre-time window and post-time window corresponding to the faulty component; taking the alarm trigger time as the center, tracing back the pre-time window and extending the post-time window backward to obtain a continuous fault period.

[0049] For example, the fault period defines an asymmetric time window centered on alarms.

[0050] For example, a common configuration for memory failures might be a 5-second pre-processing time followed by a 3-second post-processing time; while for complex graphics processor failures, a 30-second pre-processing time followed by a 10-second post-processing time might be required.

[0051] With the help of scenario examples, it is shown that determining the fault period through time windows can not only capture the triggers that cause the fault (pre-fault period), but also observe the system behavior and chain reactions after the fault occurs (post-fault period).

[0052] Optionally, the lengths of the pre-time window and the post-time window can be preset for different component types or fault types, or they can be dynamically configured by the user through the interface.

[0053] To illustrate with a scenario example, if a network card driver reports a link disconnection and an alarm is triggered, the system automatically backtracks 5 minutes and extends forward 1 minute, thereby capturing the complete message sequence before and after the link jitter disappears and the disconnection.

[0054] In this feasible implementation, by setting before and after time windows, the captured data can cover the causal stage before the fault occurs and the impact stage after the fault occurs, ensuring the integrity of the fault context data, providing sufficient information for fault diagnosis, and thus improving the efficiency of fault diagnosis.

[0055] S302. Determine the full amount of messages between the controller and each component. The full amount of messages are collected in real time.

[0056] For example, in the controller, a multi-protocol packet capture and processing service runs continuously. This service does not passively wait, but actively collects packets in real time according to configured rules. Full packets refer to all raw communication data captured and processed by the packet processing service according to preset rules. This data is organized and stored in chronological order and serves as the basis for fault diagnosis.

[0057] One feasible implementation method is to collect all messages in real time by: determining message capture rules, which include at least one of the following: message storage duration, monitoring component range, communication protocol type, and fault time window parameters; collecting raw messages between the controller and each component in real time across multiple protocols according to the capture rules and component topology address mapping table; and generating full messages based on the raw messages.

[0058] For example, system administrators configure the message processing service and determine message capture rules through a web interface or the Redfish API, a representational state transition application programming interface.

[0059] Packet capture rules can be flexibly defined: for example, the storage duration can be set to 24 hours, the monitoring scope can be the graphics processor and onboard network card in slot C, and the communication protocol type can be I2C and PCIeVDM. Based on these rules, the packet processing service can quickly locate the specific address of the target component under each protocol using the component topology address mapping table.

[0060] When the component monitoring service interacts with these components, the message processing service captures the raw messages of these underlying interactions in real time.

[0061] Optionally, the source of the original message can be initiated by the controller or an asynchronous event that the controller listens to and that is actively reported by the component.

[0062] Optionally, the message processing service formats these massive amounts of raw messages, generates standardized full messages, and stores them in a circular buffer.

[0063] In this feasible implementation, through flexible and configurable capture rules and a cross-protocol capture mechanism based on a topology address mapping table, only key messages related to the target component can be collected, avoiding interference from irrelevant data and waste of storage resources. At the same time, it ensures the comprehensiveness of data sources, solves the problem of multi-protocol data fragmentation in related technologies, and thus improves the efficiency of fault diagnosis.

[0064] One feasible implementation method involves the following steps during the generation of the full message from the original messages: determining the metadata of each original message, including at least one of the following: timestamp, protocol type, and component identifier metadata; determining the protocol type of each original message and, based on the protocol type, determining the parsing and encapsulation type of each original message; processing each original message according to its parsing and encapsulation type to obtain a processed message; and adding the metadata of each original message to the processed message to obtain the full message.

[0065] For example, when the message processing service receives a raw message, it first adds a high-precision timestamp at the microsecond level to the message and identifies its source bus to determine its protocol type.

[0066] Next, the service program will call the corresponding parsing and encapsulation modules to process the data according to the protocol type. For example, for a piece of raw binary data from the I2C bus, it needs to be parsed into readable fields such as "read / write direction", "slave device address", "command code", and "data payload", and then encapsulated into a unified internal data structure, i.e., a processing message.

[0067] At the same time, extract the metadata of the message, such as the timestamp, protocol type, and component identifier determined by table lookup.

[0068] Ultimately, this metadata is appended as a separate field or header to the processed message data to form a complete full message.

[0069] Optionally, the metadata may also include a hash of the original data payload, which the controller uses to verify data integrity.

[0070] In this feasible implementation, protocol identification, adaptive parsing, and unified encapsulation transform formats from different buses into a unified format, with metadata appended. This solves the problem of inconsistent and difficult-to-correlate cross-protocol message formats, thereby improving the efficiency of fault diagnosis.

[0071] One feasible implementation is to add metadata of each original message to the processed message to obtain the full message. This can be optimized by introducing a high-performance in-memory database, including: using the hash structure of a key-value database to encapsulate the metadata in a structured way to obtain message attribute fields; and adding message attribute fields to the processed message to obtain the full message.

[0072] For example, to achieve efficient querying of massive amounts of messages, a key-value database can be introduced to store and manage the message metadata.

[0073] Specifically, each full message is assigned a globally unique message identifier. The metadata of the full messages, such as timestamps, component identifiers, protocol types, and digest information, is stored in a structured manner using a hash structure in a key-value database.

[0074] For example, the metadata of a message can be encapsulated as a HashKey of msg:{message ID}, which contains fields such as timestamp:1723704024123, component:GPU0, and protocol:I2C. This encapsulated data is the message attribute field.

[0075] When generating the full message, the message identifier and corresponding message attribute fields are appended to the processed message. In this way, the full message contains structured attribute fields that are easy to index quickly and a complete message payload that is easy for humans to read.

[0076] As an example, the query process based on a key-value database is as follows:

[0077] 1. Data model design:

[0078] Full-text storage of raw messages: The complete raw message (including timestamp and raw data payload) is stored in the circular buffer (flash or RAM file system) of the BMC and organized by time.

[0079] Message metadata storage: For each captured message, key metadata is extracted, including: message ID (unique identifier), timestamp, component identifier (e.g., GPU0), protocol type (I2C / PCIeVDM / MCTP, etc.), bus address, command type, key status codes, etc. This metadata is stored in a key-value database structure.

[0080] Storage architecture design:

[0081] The complete metadata of each message is stored using a hash structure of a key-value database, with the key being msg:{message ID}.

[0082] The index is built using an ordered set of key-value databases, with the key being idx:time:{component identifier}, the score being the timestamp, and the member being the message ID. It supports fast retrieval by time range.

[0083] A protocol type index is created using a key-value database collection. The key is idx:proto:{protocol type}, and the member is the message ID. Filtering by protocol type is supported.

[0084] Use a key-value database list structure (List) or data stream structure (Stream) to maintain a list of recent message IDs by component for quick retrieval of the latest messages.

[0085] 2. Data writing process:

[0086] When the message capture module generates a new message, it also executes the following:

[0087] Write the entire original message to the circular buffer (flash / file system).

[0088] Generate a unique message ID (e.g., based on timestamp + sequence number).

[0089] Write message metadata to the hash structure of the key-value database: HSETmsg:{Message ID}timestamp“2026-03-1314:23:40.123”component“GPU0”protocol“I2C”addr“0x50”summary“ReadTempCommand”.

[0090] Add the message ID to the time index: ZADDidx:time:GPU0{timestamp}{message ID}.

[0091] Add the message ID to the protocol index: SADDidx:proto:I2C{Message ID}.

[0092] Push the message ID into the latest message list of the component: LPUSHlatest:GPU0{Message ID}, and periodically trim the list length (e.g., keep only the most recent 1000 messages).

[0093] 3. Data expiration and eviction policy:

[0094] Set the TTL (Time to Live) for the metadata in the key-value database to be consistent with the storage duration of the full text message (e.g., 24 hours), and automatically delete it after it expires.

[0095] By combining the LRU eviction mechanism of the key-value database, when memory space is insufficient, the oldest packets are evicted first.

[0096] 4. Optimization of fault snapshot generation:

[0097] When a component fails, the snapshot generation module no longer performs a full scan of the full-text cache, but instead:

[0098] The snapshot generation module executes according to the selected snapshot generation strategy:

[0099] Delay generation strategy: At time T+10, the alarm service sends a query request to the message processing service. The message processing service queries the key-value database for a list of message IDs with timestamps in the range [T-30, T+10]: ZRANGEBYSCOREidx:time:GPU0{T-30}{T+10}WITHSCORES.

[0100] Dynamic appending strategy: At time T, the alarm service sends a query request to the message processing service to first query the range [T-30, T]; then the alarm service starts a timer, and after the timer period, such as 10 seconds, it obtains the newly added message IDs in the range (T, T+10] and merges them into the snapshot.

[0101] Based on the returned list of message IDs, retrieve metadata in batches: HMGETmsg:{Message ID}...

[0102] The original message data is read from the full-text cache based on the message ID (it can be located directly through the file system).

[0103] This approach optimizes O(N) traversal queries into O(logN) index queries, significantly improving snapshot generation speed.

[0104] 5. Advanced query function:

[0105] Users can perform multi-dimensional combined queries through the web interface, for example:

[0106] "Query all I2C protocol write commands for GPU0 in the past hour".

[0107] "Query the PCIeVDM messages of network card NIC1 within 5 minutes before and after the time of the failure".

[0108] "Query all messages that have timed out".

[0109] The multiprotocol packet capture and processing service converts conditions into key-value database command combinations:

[0110] First, obtain the message ID within the time range using ZRANGEBYSCOREidx:time:GPU0{start}{end}.

[0111] Then filter the protocol type using SINTER or SISMEMBER.

[0112] Finally, the metadata is retrieved in batches and returned to the front end.

[0113] 6. Durability guarantee:

[0114] Configure RDB snapshots and AOF logs for the key-value database, and periodically persist metadata in memory to BMC flash memory to prevent metadata loss due to BMC restarts.

[0115] Metadata is linked to the original full-text message via message ID, and the index can be rebuilt after a restart.

[0116] In this feasible implementation, the high-performance hash structure of the key-value database is used to manage metadata, reducing query complexity and thus improving fault diagnosis efficiency.

[0117] One feasible implementation method relies on a dynamically updated address mapping relationship for the collection of all packets. The component topology address mapping table can be constructed by the following method: establishing an initial address mapping table based on the bus address and address identifier of the communication protocol corresponding to each component; periodically reading the topology service and asset configuration information of the controller, where the topology service is used to represent the online status of each component, the bus topology connection relationship, and the dynamically changing communication address, and the asset configuration information is used to represent the device identifier of each component and its hierarchical relationship with the controller; and updating the initial address mapping table based on the topology service and asset configuration information to obtain the component topology address mapping table.

[0118] For example, the controller establishes an initial address mapping table upon startup based on preset hardware configuration information (such as device tree and configuration files). For instance, the power module is known to be mounted on the PMBus bus at address 0x58.

[0119] However, the server's hardware topology may change dynamically (e.g., after hot-swapping and topology readjustment). This is addressed by periodically (e.g., every 30 seconds) calling the controller's internal topology and asset configuration services. The topology service reports the current object paths, online status, and bus connections for each component. The asset configuration service contains the unique identifiers for each component.

[0120] By combining connectivity relationships and unique identifiers, the latest address of a component can be automatically discovered and updated in the mapping table. In this way, the component topology address mapping table always reflects the current actual physical connections and address relationships.

[0121] In this feasible implementation, by introducing a dynamic update mechanism, the problem that traditional static configuration cannot adapt to dynamic changes in hardware topology (such as device hot-plugging and firmware updates leading to address reallocation) is solved, thereby improving the accuracy of fault diagnosis.

[0122] S303. Based on the fault period and component topology address mapping table, determine at least one target message corresponding to the faulty component from the full message list.

[0123] For example, when an alarm occurs, the controller receives a query request. The request includes the faulty component identifier and the fault period. Based on the component topology address mapping table, the controller quickly obtains the addresses of the faulty component under all protocols. Combining this with the fault period range, at least one target message is obtained by filtering from the stored full set of messages.

[0124] One feasible implementation method is to determine the target message by: determining the target address information corresponding to the faulty component from the component topology address mapping table; querying at least one initial message corresponding to the faulty component from the full message list based on the faulty time period and the target address information; and binding at least one initial message with the component identifier of the faulty component to obtain at least one target message.

[0125] For example, based on the faulty component identifier, its target address information is retrieved from the component topology address mapping table. In the full message cache, for each address information, a query is performed within the fault period to obtain at least one initial message, such as a temperature read message from the I2C bus and a link status event message from the PCIeVDM. These scattered initial messages are then uniformly labeled with the faulty component's identifier and packaged into a target message logically belonging to the faulty component. The target message contains all communication records between the controller and the faulty component before and after the fault.

[0126] In this feasible implementation, by using multi-address lookup of the mapping table and component identifier binding, messages scattered across different protocols and buses that are related to the same faulty component are successfully aggregated into a logical whole, realizing transparent integration of cross-protocol data and laying the foundation for subsequent one-stop fault analysis.

[0127] One feasible implementation further includes, after generating at least one target message, determining a snapshot generation strategy; and generating a message snapshot corresponding to at least one target message according to the snapshot generation strategy, wherein the message snapshot is used to solidify at least one target message.

[0128] For example, in order to prevent target messages from being overwritten by subsequent messages in the circular buffer, and to facilitate permanent association with specific alarm events, these messages can be persisted to form an independent, immutable message snapshot.

[0129] For example, snapshot generation is not instantaneous because the packets within the subsequent time window of the failure period have not yet been fully generated at the time of the failure. A snapshot generation strategy records the complete packets.

[0130] Below, in conjunction with Figure 4 Explanation of message snapshots.

[0131] Figure 4This is a schematic diagram of a message snapshot provided in an embodiment of this application. Figure 4 As shown, the alarm list includes fields such as alarm identifier, time of occurrence, fault severity level, hardware component involved in the fault, fault description, and operation buttons, displaying all current abnormal alarm entries for the server, such as different levels of faults like excessive graphics processor temperature, network card link jitter, and abnormal power supply fan speed. Each alarm has a "View Related Messages" button on the right, used to retrieve the communication interaction data corresponding to the time period of the fault.

[0132] When maintenance personnel click the view button for any alarm, a message snapshot window will pop up below. The window displays all bus interaction records of the faulty component during the abnormal period in a table format. The table fields include message generation timestamp, communication protocol type, bus identifier and device address, message transmission / reception direction, message summary, and raw hexadecimal message data. The table fully records the bidirectional transmission between the BMC and the graphics processor, as well as the vendor-defined message messages of the high-speed serial computer expansion bus, completely reconstructing the entire hardware communication process before and after the fault.

[0133] The message snapshot window has two function buttons at the bottom: "Close" and "Export Snapshot". The "Close" button collapses the pop-up window and returns to the alarm list, while the "Export Snapshot" button saves all message data associated with the current fault, facilitating offline review and fault location analysis. The overall interface links alarms with underlying communication messages, allowing maintenance personnel to quickly retrieve the original interaction messages for the corresponding time period based on alarms. By analyzing message sequence and transmitted / received data, the root cause of the fault can be located, improving fault diagnosis efficiency.

[0134] In this feasible implementation, by generating message snapshots, dynamic and volatile circular cache data is transformed into static and persistent diagnostic evidence, thereby reducing the search time for fragmented data and improving fault diagnosis efficiency.

[0135] One feasible implementation method is that the snapshot generation strategy can be, but is not limited to, the following two: the snapshot generation strategy is a delayed generation strategy or a dynamic appending strategy; the delayed generation strategy is to extract at least one target packet and generate a packet snapshot after the alarm trigger time and the subsequent time window has ended; the dynamic appending strategy is to extract the target packets from the preceding time window to the alarm time, generate an initial packet snapshot, listen for and append new packets from the alarm time to the subsequent time window, dynamically complete the initial packet snapshot, and obtain the packet snapshot.

[0136] For example, the delay generation strategy involves starting a timer at the alarm trigger time, with the timer duration covering the subsequent time window. After the timer expires, the target packets for the entire fault period are queried and extracted all at once, generating a complete snapshot, thereby improving the integrity of the snapshot.

[0137] For example, the dynamic appending strategy involves immediately extracting packets within the specified time period and generating a preliminary snapshot associated with the alarm upon alarm triggering. Simultaneously, a listener is started to monitor newly generated packets within the time period in real time. Once a packet belonging to the faulty component is detected, it is immediately appended to the preliminary packet snapshot. After a set time window, the listener stops, resulting in a complete packet snapshot. The dynamic appending strategy allows for immediate access to partial data after an alarm occurs, prioritizing response speed.

[0138] In this feasible implementation, an appropriate snapshot generation strategy is selected for different needs, thereby improving the reliability of fault diagnosis.

[0139] S304. Analyze at least one target message to obtain fault diagnosis information corresponding to the faulty component.

[0140] For example, after obtaining a snapshot of the target message, the core of the diagnostic analysis lies in how to extract valuable information from this raw communication data. The analysis process aims to identify abnormal patterns that match fault characteristics from complex message sequences.

[0141] One feasible implementation method involves the following steps: arranging at least one target message in chronological order based on its timestamp to obtain a message sequence; parsing the message sequence to obtain multiple parsed contents, each including at least one of the following: issued instruction content, component response return status, message timing interval, and error reporting field; and analyzing the multiple parsed contents to obtain fault diagnosis information.

[0142] For example, each target message is strictly sorted according to its microsecond-level timestamp to form a precise time-series chain that reconstructs the communication process before and after the failure. Each message in the time-series chain is then subjected to in-depth analysis.

[0143] Optionally, the parsed content may include: what instructions the controller issued (e.g., "read temperature register"); what status the component returned (e.g., "normal temperature value of 25 degrees"); whether the time interval between two consecutive instructions is normal (i.e., whether a timeout occurred); and whether the message payload contains specific abnormal error fields. A diagnostic conclusion is drawn by comprehensively analyzing this parsed content.

[0144] To illustrate with a scenario example, if the controller continuously issues temperature reading commands, but the response time interval for the last few commands is much longer than normal, and the component eventually returns an error code, the fault diagnosis information might be "component communication timeout, protocol interaction abnormality".

[0145] In this feasible implementation, by transforming disordered messages into ordered time-series chains and extracting core key features, the underlying binary data is transformed into high-level semantic information with fault diagnosis significance, thereby improving the efficiency of fault diagnosis.

[0146] One feasible implementation involves analyzing multiple parsed contents to obtain fault diagnosis information. This information can be intelligently classified according to different fault modes, including: if a component continuously returns a fixed fault code, there is no link packet loss or timing disorder, then the fault diagnosis information is determined to be a component body fault; if the command is issued normally, but the component does not respond or the message transmission is lost or the timing is interrupted, then the fault diagnosis information is determined to be a communication link fault; if the command is issued abnormally, is issued repeatedly, or the command format is incorrect, then the fault diagnosis information is determined to be a controller command interaction abnormality.

[0147] For example, the process of analyzing multiple parsed contents is a rule-based intelligent decision-making process, which automatically provides diagnostic conclusions by recognizing patterns in the parsed contents.

[0148] As an example, when analysis reveals that the configuration commands (such as setting power limits) sent by the controller to the graphics processor are all acknowledged and the timing is neat, but every response returned by the graphics processor contains the same, clear exception status code (such as "command not supported"), it can be determined that there is a problem with the GPU's internal firmware or logic, and the diagnosis is "component failure".

[0149] As another example, if the analysis reveals that the controller's command format appears to be correct, but the graphics processor does not respond at all, or the controller only receives partial messages (timing interruption), and there are a large number of retransmissions at the data link layer, this indicates a fault at the physical layer or the data link layer, and is diagnosed as a "communication link failure".

[0150] As another example, the analysis revealed that the controller sent multiple contradictory instructions to the power module (such as requesting both an increase and a decrease in voltage), or the instruction format did not conform to the protocol specification. This usually indicates a fault in the controller's internal software logic, and is diagnosed as "abnormal controller instruction interaction".

[0151] In this feasible implementation, by using preset fault modes, complex message interaction phenomena can be automatically and quickly categorized into a limited number of fault types, thereby improving the efficiency of fault diagnosis.

[0152] One feasible implementation involves analyzing multiple faulty components when a component fault alarm indicates multiple faulty components. This analysis yields fault diagnosis information, including: grouping the multiple parsed contents according to their respective corresponding faulty components to obtain multiple sets of parsed contents; performing cross-comparison analysis on the multiple sets of parsed contents to obtain the common anomaly source and fault propagation path of the multiple faulty components; and determining hierarchical fault diagnosis information based on the common anomaly source and fault propagation path. The hierarchical fault diagnosis information includes root faults, secondary faults, and fault propagation links.

[0153] To illustrate with a scenario example, when multiple component alarms occur simultaneously, such as simultaneous alarms for CPU overheating, power module unresponsiveness, and GPU communication failure, manual troubleshooting becomes inefficient due to the complexity of the fault.

[0154] For example, the target messages of multiple alarms are parsed into three sets of parsed content. Then, cross-comparison is performed to obtain the earliest and most original common triggering fault point where all faulty components successively experience communication anomalies, message errors, and response anomalies, i.e., the common anomaly source. The anomaly propagation timing and topology link of the initial anomaly generated from the common anomaly source are also obtained, showing how the anomaly propagates and spreads to downstream components level by level according to communication timing, bus topology, and message interaction process, i.e., the fault propagation path.

[0155] Based on the scenario examples, by comparing the timelines, we can observe the following: Cross-analysis of the timelines of fault messages from multiple components reveals the complete fault evolution process: Before the fault alarm is triggered, the power supply component reports its interaction messages normally, and the message data shows that its output power parameters are within the normal operating range, providing stable power to the entire hardware. After this point in time, the power supply component no longer generates valid response messages, resulting in a communication non-response anomaly. The graphics processor's inter-integrated circuit bus messages continuously experience interaction timeouts, while the central processing unit's temperature sensor data shows an abnormal spike, triggering fault alarms from multiple components simultaneously.

[0156] For the aforementioned multi-component synchronization anomaly scenarios, two types of fault causal logic and tracing results can be identified by analyzing message characteristics and timing relationships. The first type is a hardware-based chain fault: As the core power supply component of the entire machine, its own malfunction or interruption will directly lead to abnormal power supply and communication failure of the downstream graphics processor. At the same time, it causes unstable power supply and a sharp increase in operating temperature of the central processing unit. The corresponding fault propagation path is: power supply component failure, graphics processor communication failure, and central processing unit overheating.

[0157] The second category is controller interaction-induced faults: If the timing message data shows that the preliminary cause of power component malfunction and communication failure is the controller sending interaction messages with abnormal format and incorrect instructions, then it can be determined that the initial source of the fault is not the component itself, but the abnormal interaction of controller instructions.

[0158] In this feasible implementation, the parsed content corresponding to multiple faulty components is grouped and cross-compared for analysis. In scenarios where multiple components generate fault alarms simultaneously, the initial location of the fault and the subsequent spread of its impact can be identified based on the temporal characteristics, communication correlation, and anomaly sequence of each faulty component's message. This accurately distinguishes between the initial fault and the associated faults, effectively avoiding the blindness and repetitive operations of traditional manual troubleshooting, and significantly improving the diagnostic efficiency of multi-component faults.

[0159] S305. Group all messages to obtain multiple message lists, each message list corresponding to a component.

[0160] For example, during the continuous reception of all messages, based on the component identifier in the message metadata, all messages belonging to the same component are grouped into the same logical container, forming an independent message list. For instance, a first-in, first-out queue is created specifically to store messages from components with a unified identifier. Each message list is allocated an independent storage area in memory, ensuring they do not interfere with each other.

[0161] Optionally, this grouping operation can be implemented using a hash table, with the component identifier as the key and a linked list or circular buffer as the value. When a new message arrives, its component identifier is parsed to quickly locate the corresponding message list, and the message is appended to the end of the list.

[0162] Based on the above implementation method, by grouping messages by component, isolated storage of data streams from different components is achieved, thereby enabling quick querying of multiple data from the same component and improving fault diagnosis efficiency.

[0163] S306. For each message list, push new messages in real time and calculate the cached data capacity.

[0164] For example, whenever a new full message is parsed, the message is immediately pushed to the end of the message list of the corresponding component to ensure the real-time nature of the data.

[0165] On the other hand, a counter (or calculated using the length of a linked list) is maintained for each message list to record the number of memory bytes currently occupied by the list. This statistic is updated at a microsecond frequency and can be queried by the memory management module at any time.

[0166] For example, suppose the capacity limit for the graphics processor is set to 10MB. During continuous operation, new messages are constantly added to the list of GPU0, and its capacity gradually increases from 0. When it reaches 9.8MB, the capacity monitoring module can accurately detect that the threshold is about to be reached, providing a basis for subsequent adjustment decisions.

[0167] As illustrated by the scenario example, when a controller manages multiple components simultaneously, the communication frequencies of these components vary significantly. For instance, fan speed monitoring might only update once per second, while graphics processor temperature queries might occur every 10 milliseconds. By independently tracking these parameters, the resource consumption of each component can be accurately determined, preventing resource allocation imbalances caused by estimation errors.

[0168] S307. When the cached data capacity of any message list is greater than or equal to the capacity threshold, adjust the messages in the message list until the cached data capacity of the message list is less than the capacity threshold.

[0169] For example, the goal of the adjustment is to remove some packets from the list so that the capacity of the remaining packets is once again below the capacity threshold, thereby making room for subsequent new packets.

[0170] Below, in conjunction with Figure 5 Explanation of circular storage messages.

[0171] Figure 5 This is a schematic diagram illustrating the circular storage of messages provided in an embodiment of this application. For example... Figure 5 As shown, the BMC runs continuously in the background. Operations and maintenance personnel can pre-configure message storage policies. The BMC first determines whether message capture is enabled. If not, it returns to the main system workflow. If capture is enabled, three parallel processing operations are executed simultaneously: continuously monitoring multiple hardware buses to capture raw interaction messages, parsing the internal address of the message and querying the address mapping table to bind the corresponding hardware component identifier, and attaching metadata such as timestamp, protocol type, and component identifier to the message. After processing, the message carrying complete metadata is written to a first-in-first-out circular buffer. The BMC monitors the buffer occupancy status in real time. If the buffer space is full, it performs an overwrite operation to release storage space, then returns to the message writing stage to store the current new message. If the buffer has not reached its capacity limit, it enters a continuous running state, jumping back to the multi-protocol monitoring stage to continuously collect new bus messages. The accompanying address mapping table records the correspondence between each hardware component and its corresponding bus address and protocol endpoint identifier, providing a basis for component attribution matching in the address resolution stage.

[0172] One feasible implementation involves adjusting the message list by: determining messages to be removed from the message list, wherein the duration of the messages to be removed is greater than a duration threshold, and / or the usage frequency is less than a frequency threshold; removing the messages to be removed from the message list; and storing the messages to be removed on disk.

[0173] For example, all messages are logically grouped by component identifier, and an independent first-in-first-out (FIFO) circular message list is maintained for each active component. When a new full message arrives, it is pushed to the end of the corresponding component's list in real time.

[0174] Optionally, continuously monitor the cached data capacity of each list. Assume one component list has a set capacity threshold of 10MB. When the list's data capacity reaches 9.9MB, approaching the threshold, begin preparations for adjustment.

[0175] For example, scanning the header of the list, messages with a duration greater than the duration threshold are those that have existed for a long time (e.g., more than 5 minutes), which may have lower value; messages with a usage frequency less than the frequency threshold are those that have not been accessed by any query requests in the recent past. The system will prioritize removing historical messages that meet both of these conditions.

[0176] Optionally, the message to be removed is removed from the cache in memory, but it is not discarded directly. Instead, its complete message content, along with its metadata, is serialized and stored on the controller's onboard disk, and its new location is recorded.

[0177] With the example scenario, removing packets from the packet list alleviates memory pressure without data loss.

[0178] In this feasible implementation, messages to be removed are filtered based on both message duration and access frequency. Low-value messages that have been stored for too long and rarely participate in fault retrieval and analysis are prioritized for removal, while recently accessed, frequently retrieved, and highly relevant messages are retained in the memory cache. The messages retained in memory are all easily searchable and highly valuable data during fault diagnosis, reducing the time spent reading and matching target messages during fault diagnosis, thereby improving fault diagnosis efficiency.

[0179] As an example, the fault diagnosis steps include:

[0180] Step A: Loop capture and storage of multi-protocol packets based on component topology addresses.

[0181] Configuration phase: Administrators configure multi-protocol packet capture and processing service parameters through a web management interface or a standardized hardware remote management interface.

[0182] Control switch: Turn on or off.

[0183] Storage duration: for example, 24 hours, 1 hour, 30 minutes, 5 minutes, etc.

[0184] Capture Scope: You can specify the components or interfaces to be monitored. The system automatically obtains various communication addresses of these components: such as the GPU's PCIe BDF (e.g., 03:00.0), the corresponding I2C bus number and slave address (e.g., I2C-2, 0x50), MCTPEID (e.g., 8), etc.

[0185] Capture protocols: Optional I2C, I3C, PMBus, PCIeVDM, MCTP, etc.

[0186] Component information: Some component information is fixed, and the association information between components and communication parameters can be configured in advance, such as PSU1-i2c10-addr0x58.

[0187] Operation phase:

[0188] After the multi-protocol packet capture and processing service in BMC runs, it reads information from the topology service, asset information service, and user configuration files to generate a component address mapping table. The mapping table is updated periodically. During packet capture, the table is looked up in real time to convert the original address into a component identifier. During fault snapshot extraction, the table is looked up in reverse through the component identifier to obtain all relevant addresses, thereby comprehensively filtering packets.

[0189] The component address mapping table records the name, type, and address of each component under each protocol.

[0190] Example mapping table is as follows:

[0191] Component name / Slot information, component type, PCIeBDF, bus / address, MCTPEID, and other protocol addresses.

[0192] GPU0, Graphics Processing Unit, 03:00.0, I2C-2:0x50, 8.

[0193] NIC1, Smart NIC, 04:00.0I2C-3:0x3010.

[0194] PSU0 power module, PMBus-10:0x58.

[0195] CPU0 Central Processing Unit, Peci: 0x48.

[0196] The multiprotocol packet capture and processing service reads the user configuration and publishes the capture rules set by the user to the desktop bus.

[0197] After the monitoring module service starts running, it reads the capture rules from the multi-protocol message capture and processing service. Whenever the monitoring module sends or receives a message, according to the obtained capture rules, if it is within the capture range, it sends the detailed address and message content to the message capture and processing service through the message receiving method provided by the multi-protocol message capture and processing service. The message capture and processing service parses out the corresponding component identifier according to its source / destination (by looking up a table to map the bus / address, BDF, EID, etc. to the specific component name).

[0198] Add a microsecond-level timestamp to the message and attach metadata such as component identifier, protocol type, and bus information.

[0199] The raw message with metadata is stored in a circular buffer. The buffer is organized by time, and the storage duration is configurable.

[0200] The multiprotocol message capture and processing service continuously stores and processes messages.

[0201] Step B: Generation of association between fault alarms and cross-protocol context snapshots.

[0202] Fault Trigger: Suppose the monitoring module detects that the GPU (part name: GPU0) temperature is too high and triggers an overheat alarm, or the network card (NIC1) link is disconnected and triggers an alarm.

[0203] Snapshot generation:

[0204] Record the exact time T when the fault occurred, and determine the preset time window (e.g., 30 seconds before the fault to 10 seconds after the fault).

[0205] Snapshot generation timing: Since packets generated 10 seconds after a failure do not exist at the time the failure was triggered, the system employs one of the following two strategies to ensure the integrity of the snapshot:

[0206] Strategy 1 (Delayed Generation): When a fault is triggered, the system starts a timer and waits for 10 seconds (i.e., at time T+10). Then, it extracts all packets with timestamps in the range of [T-30, T+10] from the multi-protocol packet capture and processing service to ensure that packets within 10 seconds after the fault have been written to the cache and appended to the alarm.

[0207] Strategy 2 (Dynamic Appendage): When a fault is triggered, the system immediately extracts packets with timestamps in the range of [T-30, T] from the multi-protocol packet capture and processing service to form a preliminary snapshot and associate it with an alarm; at the same time, it continuously monitors in the background, and after the time arrives, it queries again to dynamically append packets with timestamps in the range of (T, T+10] that are related to the faulty component to the snapshot.

[0208] Upon receiving a request, the multi-protocol packet capture and processing service filters out all packets related to the faulty component from the cached packets based on the identifier of the faulty component (I2C address, BDF, EID corresponding to GPU0), regardless of whether these packets originate from I2C, PCIe VDM, or MCTP. For example, it may extract packets from the BMC reading GPU temperature via I2C before the fault, PCIe link error events at the time of the fault, and error states actively reported by the GPU via MCTP after the fault.

[0209] Step C: Quickly associate presentation and positioning.

[0210] When users view alarms, they can bring up the associated message snapshots with one click.

[0211] The interface can be filtered by protocol, time, etc., and key commands related to the fault are highlighted (such as the response timeout of the last temperature reading request).

[0212] By analyzing snapshots, the complete interaction process between the BMC and the component before the failure can be reconstructed. For example, it can be found that the BMC continuously requests temperature data from the GPU via I2C, but the GPU returned invalid data in the last few attempts, which then triggered an overheating alarm. This can help pinpoint that the problem may be a sensor failure inside the GPU, rather than a heat dissipation issue.

[0213] In some examples, after obtaining target message snapshots and preliminary diagnostic information for each faulty component, further comprehensive analysis can be performed. For instance, by analyzing the timestamps of multiple alarms and the parent-child, power supply, and connection relationships of related components in the topology mapping table, it can determine whether there is a causal relationship between alarms. If a root cause fault (such as power module failure) is found to have caused multiple secondary faults (such as SSD or hard drive power failure), it can automatically converge multiple seemingly independent alarms to a single root cause alarm, providing fault propagation chain and hierarchical diagnostic information. This avoids aimless troubleshooting among massive alarms and allows direct location of the most fundamental fault point.

[0214] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0215] Figure 6 This is a schematic diagram of the fault diagnosis device provided in an embodiment of this application. Figure 6 As shown, embodiments of this application also provide a fault diagnosis device 60, which may include: a time module 61, an acquisition module 62, a filtering module 63, and an analysis module 64.

[0216] The time module 61 is used to respond to component fault alarm information and determine the fault period based on the alarm trigger time.

[0217] The acquisition module 62 is used to determine the full amount of messages between the controller and each component. The full amount of messages are collected in real time.

[0218] The filtering module 63 is used to determine at least one target message corresponding to the faulty component from the full number of messages based on the fault period and the component topology address mapping table. The component topology address mapping table represents the address information of each component under each communication protocol.

[0219] Analysis module 64 is used to analyze at least one target message to obtain fault diagnosis information corresponding to the faulty component.

[0220] Optionally, time module 61 can be executed. Figure 2 S201 in the embodiment.

[0221] Optionally, module 62 can be executed. Figure 2 S202 in the embodiment.

[0222] Optionally, the filtering module 63 can perform... Figure 2 S203 in the embodiment.

[0223] Optionally, analysis module 64 can execute... Figure 2 S204 in the embodiment.

[0224] It should be noted that the fault diagnosis device shown in the embodiments of this application can execute the technical solution shown in the above method embodiments, and its implementation principle and beneficial effects are similar, so they will not be described again here.

[0225] In one possible implementation, the time module 61 is specifically used for:

[0226] Determine the preset pre-time window and post-time window corresponding to the faulty component.

[0227] Centered on the alarm trigger time, the preceding time window is traced back and the following time window is extended forward to obtain a continuous fault period.

[0228] In one possible implementation, the filtering module 63 is specifically used for:

[0229] Determine the target address information corresponding to the faulty component from the component topology address mapping table.

[0230] Based on the fault period and target address information, at least one corresponding initial message is retrieved from the full message list.

[0231] Bind at least one initial message to the component identifier of the faulty component to obtain at least one target message.

[0232] In one possible implementation, the analysis module 64 is specifically used for:

[0233] Based on the timestamp of at least one target message, arrange at least one target message in chronological order to obtain a message sequence.

[0234] The message sequence is parsed to obtain multiple parsed contents, which include at least one of the following: the content of the issued instruction, the component response return status, the message timing interval, and the error reporting field.

[0235] By analyzing multiple parsed contents, fault diagnosis information is obtained.

[0236] In one possible implementation, the analysis module 64 is specifically used for:

[0237] If a component continuously returns a fixed fault code, and there is no packet loss or timing disorder, then the fault diagnosis information is determined to be a component failure.

[0238] If the command is issued normally, but the component does not respond, or the message transmission is lost or the timing is interrupted, then the fault diagnosis information is determined to be a communication link failure.

[0239] If the command is issued abnormally, is issued repeatedly, or has an incorrect format, the fault diagnosis information is determined to be an abnormal controller command interaction.

[0240] In one possible implementation, the analysis module 64 is specifically used for:

[0241] Based on the faulty components corresponding to the multiple analytical contents, the multiple analytical contents are grouped to obtain multiple groups of analytical contents.

[0242] By cross-comparing and analyzing multiple sets of analytical data, the common abnormal source and fault propagation path of multiple faulty components were obtained.

[0243] Based on the common anomaly source and fault propagation path, hierarchical fault diagnosis information is determined, which includes root faults, secondary faults, and fault propagation links.

[0244] Figure 7 This is a schematic diagram of another fault diagnosis device provided in an embodiment of this application. Figure 6 Based on the illustrated embodiments, as Figure 7 As shown, the fault diagnosis device 60 also includes: a data acquisition module 65, a data construction module 66, a data generation module 67, and a data management module 68.

[0245] Acquisition module 65 is used for:

[0246] Determine the message capture rules, which include at least one of the following: message storage duration, monitoring component range, communication protocol type, and fault time window parameters.

[0247] Based on the capture rules and component topology address mapping table, the raw messages of interaction between the controller and each component are collected in real time across multiple protocols.

[0248] Generate the full message based on the original message.

[0249] In one possible implementation, the acquisition module 65 is specifically used for:

[0250] Determine the metadata of each original message. The metadata includes at least one of the following: timestamp, protocol type, and component identifier metadata.

[0251] Determine the protocol type of each raw message, and based on the protocol type, determine the parsing and encapsulation type of each raw message.

[0252] Based on the parsing and encapsulation types of each original message, the original messages are processed to obtain processed messages.

[0253] Metadata from each original message is added to the processed message to obtain the full message.

[0254] In one possible implementation, the acquisition module 65 is specifically used for:

[0255] By using the hash structure of the key-value database, the metadata is structurally encapsulated to obtain message attribute fields.

[0256] Add message attribute fields to the processed message to obtain the full message.

[0257] Module 66 is used for:

[0258] An initial address mapping table is established based on the bus address and address identifier of the communication protocol corresponding to each component.

[0259] The topology service and asset configuration information of the controller are read periodically. The topology service is used to represent the online status of each component, the bus topology connection relationship, and the dynamically changing communication address. The asset configuration information is used to represent the device identifier of each component and its hierarchical relationship with the controller.

[0260] Based on the topology service and asset configuration information, update the initial address mapping table to obtain the component topology address mapping table.

[0261] Module 67 is generated for:

[0262] Determine the snapshot generation strategy.

[0263] According to the snapshot generation strategy, at least one target message snapshot is generated, and the message snapshot is used to solidify at least one target message.

[0264] Data management module 68 is used for:

[0265] All messages are grouped to obtain multiple message lists, and each message list corresponds to a component.

[0266] For each message list, new messages are pushed in real time and the cached data capacity is calculated.

[0267] If the cached data capacity of any message list is greater than or equal to the capacity threshold, adjust the messages in the message list until the cached data capacity of the message list is less than the capacity threshold.

[0268] In one possible implementation, the data management module 68 is specifically used for:

[0269] The message to be removed is determined from the message list. The duration of the message to be removed is greater than the duration threshold, and / or the frequency of use is less than the frequency threshold.

[0270] Remove the message to be removed from the message list.

[0271] Store the messages to be removed on the disk.

[0272] For a description of the features in the embodiment corresponding to the fault diagnosis device, please refer to the relevant description of the embodiment corresponding to the fault diagnosis method, which will not be repeated here.

[0273] Figure 8 A schematic diagram of the structure of the electronic device provided in this application. Figure 8 As shown, the electronic device 80 provided in this embodiment includes at least one processor 801 and a memory 802. Optionally, the electronic device 80 further includes a communication component 803. The processor 801, memory 802, and communication component 803 are connected via a bus.

[0274] In a specific implementation, at least one processor 801 executes computer execution instructions stored in memory 802, causing at least one processor 801 to execute the above-described fault diagnosis method embodiment.

[0275] The specific implementation process of processor 801 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0276] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0277] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0278] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0279] Embodiments of this application also provide a non-volatile computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described fault diagnosis method embodiments when it is run.

[0280] In one exemplary embodiment, the aforementioned non-volatile computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0281] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described fault diagnosis method embodiments.

[0282] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described fault diagnosis method embodiments.

[0283] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be performed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0284] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0285] The foregoing has provided a detailed description of a fault diagnosis method and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A fault diagnosis method, characterized in that, include: In response to component fault alarm information, the fault period is determined based on the alarm trigger time. Based on the message capture rules and component topology mapping table, the original messages between the controller and each component are collected, the original messages are processed and metadata of each original message is added to obtain the full message. The metadata includes: timestamp, protocol type and component identifier. Based on the fault period and the component topology address mapping table, at least one target message corresponding to the faulty component is determined from the full message list. The component topology address mapping table represents the address information of each component under each communication protocol. The process of determining at least one target message corresponding to a faulty component includes: determining the target address information corresponding to the faulty component from the component topology address mapping table; querying at least one initial message corresponding to the faulty component from the full message list based on the faulty time period and the target address information; and binding the at least one initial message to the component identifier of the faulty component to obtain the at least one target message. The at least one target message is analyzed to obtain the fault diagnosis information corresponding to the faulty component.

2. The fault diagnosis method according to claim 1, characterized in that, The raw messages between the acquisition controller and each component include: The message capture rules are determined, and the message capture rules include at least one of the following: message storage duration, monitoring component range, communication protocol type, and fault time window parameters; Based on the capture rules and the component topology address mapping table, the original messages exchanged between the controller and each component are collected in real time across multiple protocols.

3. The fault diagnosis method according to claim 2, characterized in that, The original messages are processed and metadata of each original message is added to obtain the full message, including: Determine the protocol type of each original message, and based on the protocol type, determine the parsing and encapsulation type of each original message; Based on the parsing and encapsulation types of each original message, the original messages are processed to obtain processed messages; The metadata of each original message is added to the processed message to obtain the full message.

4. The fault diagnosis method according to claim 3, characterized in that, Adding metadata from each original message to the processed message yields the full message, including: The metadata is structured and encapsulated using the hash structure of the key-value database to obtain message attribute fields; The message attribute field is added to the processed message to obtain the full message.

5. The fault diagnosis method according to claim 1, characterized in that, The process of constructing the component topology address mapping table includes: An initial address mapping table is established based on the bus address and address identifier of the communication protocol corresponding to each component; The topology service and asset configuration information of the controller are read periodically. The topology service is used to represent the online status of each component, the bus topology connection relationship, and the dynamically changing communication address. The asset configuration information is used to represent the device identifier of each component and its hierarchical relationship with the controller. Based on the topology service and the asset configuration information, the initial address mapping table is updated to obtain the component topology address mapping table.

6. The fault diagnosis method according to claim 1, characterized in that, The fault period is determined based on the alarm trigger time, including: Determine the preset pre-time window and post-time window corresponding to the faulty component; Centered on the alarm trigger time, the preceding time window is traced back and the following time window is extended forward to obtain the continuous fault period.

7. The fault diagnosis method according to claim 1, characterized in that, After generating the at least one target message, the method further includes: Determine the snapshot generation strategy; According to the snapshot generation strategy, a snapshot of the at least one target message is generated, and the snapshot is used to preserve the at least one target message.

8. The fault diagnosis method according to claim 7, characterized in that, The snapshot generation strategy is either a delayed generation strategy or a dynamic appending strategy; The delay generation strategy is to extract the at least one target message and generate the message snapshot after the alarm is triggered and after the post-time window has ended. The dynamic appending strategy involves extracting target packets from the preceding time window to the alarm time, generating an initial packet snapshot, monitoring and appending new packets from the alarm time to the following time window, dynamically completing the initial packet snapshot, and obtaining the packet snapshot.

9. The fault diagnosis method according to claim 1, characterized in that, Analyzing the at least one target message to obtain fault diagnosis information corresponding to the faulty component includes: Based on the timestamp of the at least one target message, the at least one target message is arranged in chronological order to obtain a message sequence; The message sequence is parsed to obtain multiple parsed contents, which include at least one of the following: the content of the issued instruction, the component response return status, the message timing interval, and the error reporting field; The fault diagnosis information is obtained by analyzing the multiple parsed contents.

10. The fault diagnosis method according to claim 9, characterized in that, Based on the analysis of the multiple parsed contents, the fault diagnosis information is obtained, including: If the component continuously returns a fixed fault code, and there is no link packet loss or timing disorder, then the fault diagnosis information is determined to be a component body fault. If the instruction is issued normally, but the component does not respond, or the message transmission is lost or the timing is interrupted, then the fault diagnosis information is determined to be a communication link fault. If the command is issued abnormally, is issued repeatedly, or has an incorrect format, the fault diagnosis information is determined to be a controller command interaction abnormality.

11. The fault diagnosis method according to claim 9, characterized in that, The component fault alarm information indicates multiple faulty components; based on the analysis of the multiple parsed contents, the fault diagnosis information is obtained, including: Based on the faulty components corresponding to the multiple parsed contents, the multiple parsed contents are grouped to obtain multiple groups of parsed contents; By cross-comparing and analyzing the multiple sets of parsed content, the common abnormal source and fault propagation path of the multiple faulty components are obtained; Based on the common anomaly source and the fault propagation path, hierarchical fault diagnosis information is determined, which includes root faults, secondary faults, and fault propagation links.

12. The fault diagnosis method according to any one of claims 1-11, characterized in that, The method further includes: The full message is grouped to obtain multiple message lists, and each message list corresponds to a component; For each message list, new messages are pushed in real time and the cached data capacity is calculated. When the cached data capacity of any message list is greater than or equal to the capacity threshold, adjust the messages in the message list until the cached data capacity of the message list is less than the capacity threshold.

13. The fault diagnosis method according to claim 12, characterized in that, Messages that adjust the message list include: The message to be removed is determined from the message list, wherein the duration of the message to be removed is greater than the duration threshold and / or the frequency of use is less than the frequency threshold. Remove the message to be removed from the message list; The message to be removed is stored on the disk.

14. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the fault diagnosis method as described in any one of claims 1 to 13 when executing the computer program.

Images