Server fault diagnosis system

Abstract

The utility model discloses a server fault diagnosis system, which relates to the field of server operation and maintenance and comprises a fault monitoring device, a communication device, a remote diagnosis device and a local diagnosis device. The fault monitoring equipment is provided with a monitoring server interface and a first communication equipment interface, the communication equipment is provided with a monitoring equipment interface, a remote diagnosis equipment interface and a local diagnosis equipment interface, the remote diagnosis equipment is provided with a second communication equipment interface, and the local diagnosis equipment is provided with a third communication equipment interface; the first communication equipment interface is connected with the monitoring equipment interface, the remote diagnosis equipment interface is connected with the second communication equipment interface, and the local diagnosis equipment interface is connected with the third communication equipment interface, so that the problems of low communication reliability between diagnosis equipment and fault monitoring equipment and the like are solved; the technical effect of improving the communication reliability between the diagnosis equipment and the fault monitoring equipment is achieved.

Description

Technical Field

[0001] This utility model relates to the field of server operation and maintenance, and more specifically, to a server fault diagnosis system. Background Technology

[0002] In related technologies, server fault diagnosis systems collect internal server status data through fault monitoring equipment to diagnose server hardware faults. When external diagnostic equipment acquires this status data, it needs to send a request to the server controller via the management network. Upon receiving the request, the server controller communicates with the fault monitoring equipment via its internal bus, relaying the status data to the diagnostic equipment. However, this data interaction scheme relies entirely on the server controller as a relay node. If the server controller or its management network malfunctions, the external diagnostic equipment will be unable to acquire any monitoring data, causing the diagnostic function to fail.

[0003] There is still no effective solution to the problem of low communication reliability between diagnostic equipment and fault monitoring equipment in related technologies. Utility Model Content

[0004] This invention provides a server fault diagnosis system to solve the problem of low communication reliability between diagnostic equipment and fault monitoring equipment in related technologies.

[0005] According to one embodiment of the present invention, a server fault diagnosis system is provided, comprising:

[0006] Fault monitoring equipment, communication equipment, remote diagnostic equipment, and local diagnostic equipment;

[0007] The fault monitoring equipment is equipped with a monitoring server interface and a first communication device interface. The communication device is equipped with a monitoring device interface, a remote diagnostic device interface, and a local diagnostic device interface. The remote diagnostic device is equipped with a second communication device interface, and the local diagnostic device is equipped with a third communication device interface.

[0008] The first communication device interface is connected to the monitoring device interface, the remote diagnostic device interface is connected to the second communication device interface, and the local diagnostic device interface is connected to the third communication device interface.

[0009] This invention enables a fault monitoring device to collect data through a monitoring server interface and transmit the data to the monitoring device interface of a communication device via a first communication device interface. Upon receiving the data, the communication device provides two independent communication paths: on one hand, it connects to the second communication device interface of a remote diagnostic device via the remote diagnostic device interface to establish a remote data channel; on the other hand, it connects to the third communication device interface of a local diagnostic device via the local diagnostic device interface to establish a local data channel.

[0010] The aforementioned server fault diagnosis system, by adding communication equipment, constructs dual communication links directly to both remote and local diagnostic devices. These two links operate independently of the server controller, thereby avoiding the single point of failure caused by the reliance on a single server controller for relay in related technologies. This ensures that the diagnostic devices can still stably acquire monitoring data even when the server controller or management network is abnormal. It solves the problem of low communication reliability between diagnostic devices and fault monitoring devices in related technologies, and achieves the technical effect of improving the communication reliability between diagnostic devices and fault monitoring devices. Attached Figure Description

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

[0012] Figure 1 This is a schematic diagram of the structure of a server fault diagnosis system according to an embodiment of the present utility model. Figure 1 ;

[0013] Figure 2 This is a schematic diagram of the structure of a communication device according to an embodiment of the present utility model. Figure 1 ;

[0014] Figure 3 This is a schematic diagram of the structure of a communication device according to an embodiment of the present utility model. Figure 2 ;

[0015] Figure 4 This is a schematic diagram of the structure of a remote communication device according to an embodiment of the present utility model;

[0016] Figure 5 This is a schematic diagram of a communication process supporting a target protocol according to an embodiment of the present utility model;

[0017] Figure 6 This is a schematic diagram of the structure of a server fault diagnosis system according to an embodiment of the present utility model. Figure 2 ;

[0018] Figure 7 This is a schematic diagram of the structure of a server fault diagnosis system according to an embodiment of the present utility model. Figure 3 ;

[0019] Figure 8 This is a schematic diagram of the structure of a monitoring server interface according to an embodiment of the present utility model. Figure 1 ;

[0020] Figure 9 This is a schematic diagram of the structure of a monitoring server interface according to an embodiment of the present utility model. Figure 2 ;

[0021] Figure 10 This is a schematic diagram of the internal structure of the server fault diagnosis system according to an embodiment of the present invention during operation. Detailed Implementation

[0022] The technical solutions of the present utility model will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present utility model, and not all embodiments. Based on the embodiments of the present utility model, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the present utility model.

[0023] It should be noted that in the description of this utility model, 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., are used to distinguish similar objects and are not used to describe a specific order or sequence. The terms "upper," "lower," "left," "right," "inner," "outer," "remote," "local," etc., indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. The terms "connected," "linked," and "set" should be interpreted broadly; for example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection, an electrical connection, or a communication connection; they can refer to a direct connection or an indirect connection through an intermediate medium, and they can also refer to the internal communication or interaction between two elements. Those skilled in the art can understand the specific meaning of the above terms in this utility model according to the specific circumstances.

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

[0025] According to one aspect of an embodiment of this application, a server fault diagnosis system is provided. This server fault diagnosis system can be applied in the field of server operation and maintenance, specifically in scenarios involving fault diagnosis of servers.

[0026] In related technologies, when external diagnostic equipment acquires internal server status data collected by fault monitoring equipment, it needs to send a request to the server controller via the management network. Upon receiving the request, the server controller then communicates with the fault monitoring equipment via its internal bus to relay the status data to the diagnostic equipment. However, if the server controller or its management network malfunctions, the external diagnostic equipment will be unable to acquire any monitoring data, let alone perform fault diagnosis. Therefore, related technologies suffer from low communication reliability between the diagnostic equipment and the fault monitoring equipment.

[0027] To address the aforementioned problems, embodiments of this utility model provide a server fault diagnosis system. Figure 1 This is a schematic diagram of the structure of a server fault diagnosis system according to an embodiment of the present utility model. Figure 1 ,like Figure 1 As shown, the server fault diagnosis system includes: a fault monitoring device 100, a communication device 200, a remote diagnosis device 300, and a local diagnosis device 400; the fault monitoring device 100 is equipped with a monitoring server interface 102 and a first communication device interface 104; the communication device 200 is equipped with a monitoring device interface 202, a remote diagnosis device interface 204, and a local diagnosis device interface 206; the remote diagnosis device 300 is equipped with a second communication device interface 302; and the local diagnosis device 400 is equipped with a third communication device interface 402; the first communication device interface 104 is connected to the monitoring device interface 202, the remote diagnosis device interface 204 is connected to the second communication device interface 302, and the local diagnosis device interface 206 is connected to the third communication device interface 402.

[0028] Optionally, in this embodiment, the fault monitoring device 100 may be, but is not limited to, a hardware module with server status data acquisition and preliminary storage functions, capable of acquiring data such as server internal voltage, timing signals, and component operation logs in real time. Examples include an embedded diagnostic daughter card integrating an i.MX 8M Mini (embedded processor model), a sensor acquisition module with SPI (Serial Peripheral Interface) / I2C (Inter-Integrated Circuit) interface, and a monitoring board supporting UART (Universal Asynchronous Receiver / Transmitter) log reception.

[0029] Optionally, in this embodiment, the monitoring server interface 102 may be, but is not limited to, a hardware interface that physically connects the fault monitoring device 100 to the internal components of the server, used to collect server status data. For example, a monitoring server interface 102 with an SPI interface can be connected to a server CPLD (Complex Programmable Logic Device) to acquire timing signals; a monitoring server interface 102 with an I2C interface can be connected to a server ADC (Analog-to-Digital Converter) to acquire voltage data; and a monitoring server interface 102 with a UART interface can be connected to a BMC (Baseboard Management Controller) to acquire serial port logs, etc. The first communication device interface 104 may be, but is not limited to, the interface for physical connection between the fault monitoring device 100 and the communication device 200, used to transmit collected data, such as a USB 2.0 (Universal Serial Bus 2.0) interface, an Ethernet RJ45 (Registered Jack 45) interface, an RS485 (Recommended Standard 485) bus interface, etc.

[0030] Optionally, in this embodiment, the communication device 200 may be, but is not limited to, a hardware unit that provides an independent communication path for the fault monitoring device 100, such as an industrial communication gateway with a USB HUB (Universal Serial Bus Hub) module, an interface adapter board integrating a 5G (5th Generation Mobile Communication Technology) or WiFi (Wireless Fidelity) module, or a communication controller that supports multiple bus protocols.

[0031] Optionally, in this embodiment, the monitoring device interface 202 may be, but is not limited to, a hardware interface on the communication device 200 that matches the first communication device interface 104, used to receive data transmitted by the fault monitoring device 100, such as a USB 2.0 female connector, an Ethernet adapter interface, an RS485 adapter interface, etc., corresponding to the first communication device interface. The remote diagnostic device interface 204 may be, but is not limited to, a hardware interface on the communication device 200 that connects to the remote diagnostic device 300, used for remote data transmission, such as a 5G module interface, a WiFi antenna interface, an optical fiber interface, etc. The local diagnostic device interface 206 may be, but is not limited to, a hardware interface on the communication device 200 that connects to the local diagnostic device 400, used for on-site data interaction, such as a USB Type-A female connector, an Ethernet RJ45 interface, etc.

[0032] Optionally, in this embodiment, the remote diagnostic device 300 may be, but is not limited to, a hardware device with remote data reception and display functions, used to obtain server fault data remotely, such as a cloud-based maintenance terminal with a 5G module, a device supporting Ethernet remote access, or a diagnostic server with an integrated wireless receiving module. The second communication device interface 302 may be, but is not limited to, a hardware interface on the remote diagnostic device 300 that matches the remote diagnostic device interface 204, used to receive remote data, such as a 5G SIM (Subscriber Identity Module) card interface, a WiFi receiving module interface, or a fiber optic Ethernet adapter interface.

[0033] Optionally, in this embodiment, the local diagnostic device 400 may be, but is not limited to, a device for on-site data reading, capable of real-time viewing of fault data, such as a portable maintenance laptop with a USB Type-A interface, a locally deployed touch-screen diagnostic terminal, or a handheld monitoring device supporting near-field communication. The third communication device interface 402 may be, but is not limited to, a hardware interface on the local diagnostic device 400 that matches the local diagnostic device interface 206, used to receive local data, such as a USB Type-A male connector, an Ethernet RJ45 interface, etc.

[0034] Optionally, in this embodiment, the fault monitoring device 100 and the communication device 200 can be physically connected via a wired cable. For example, if the first communication device interface 104 is a USB 2.0 male connector and the monitoring device interface 202 is a USB 2.0 female connector, a standard USB A-to-B (USB Type-A to Type-B Cable) cable can be used, with one end inserted into the first communication device interface 104 and the other end inserted into the monitoring device interface 202, establishing a data transmission path through the cable. Alternatively, the fault monitoring device 100 and the communication device 200 can be physically integrated onto a single PCB (Printed Circuit Board) to form a fault diagnosis module. The fault diagnosis module can be installed on the motherboard of the monitored server using M.2 (Generation 2) connectors. In this case, the first communication device interface 104 and the monitoring device interface 202 are electrically connected through internal bus traces on the PCB.

[0035] Optionally, in this embodiment, the communication device 200 and the remote diagnostic device 300 can be wirelessly connected via a mobile network. For example, if the remote diagnostic device interface 204 is a 5G module interface (with a built-in SIM card), and the second communication device interface 302 is the 5G receiving interface of the remote diagnostic device 300, the two can automatically pair through the operator's 5G network to establish a remote data transmission link. The communication device 200 and the remote diagnostic device 300 can also be wired connected via a local area network. For example, if the remote diagnostic device interface 204 is an Ethernet RJ45 female connector, and the second communication device interface 302 is the Ethernet RJ45 male connector of the remote diagnostic device 300, they can be connected to the same local area network router using a network cable, configured with the same network segment IP (Internet Protocol) address, to achieve data interaction.

[0036] Optionally, in this embodiment, the connection between the communication device 200 and the local diagnostic device 400 can be a wired connection. For example, if the local diagnostic device interface 206 is a USB Type-A female connector and the third communication device interface 402 is a USB Type-A male connector of the local diagnostic device 400, directly inserting the USB male connector of the local diagnostic device 400 into the local diagnostic device interface 206 will automatically identify the device and establish a data connection without additional configuration. The connection between the communication device 200 and the local diagnostic device 400 can also be a near-field wireless connection. For example, if the local diagnostic device interface 206 is an NFC (Near Field Communication) sensing module and the third communication device interface 402 is the NFC sensing area of ​​the local diagnostic device 400, bringing the two close together (distance ≤ 10cm) will trigger automatic NFC pairing, establishing a near-field data link within seconds.

[0037] This invention enables a fault monitoring device to collect data via a monitoring server interface and transmit the data to the monitoring device interface of a communication device via a first communication device interface. Upon receiving the data, the communication device provides two independent communication paths: firstly, it connects to the second communication device interface of a remote diagnostic device via the remote diagnostic device interface, establishing a remote data channel; secondly, it connects to the third communication device interface of a local diagnostic device via the local diagnostic device interface, establishing a local data channel. In other words, the aforementioned server fault diagnosis system, by adding a communication device, constructs dual communication links directly to both the remote and local diagnostic devices. These two links operate independently of the server controller, thus avoiding the single point of failure caused by reliance on a single server controller in related technologies. This ensures that even when the server controller or management network malfunctions, the diagnostic device can still stably acquire monitoring data, solving the problem of low communication reliability between the diagnostic device and the fault monitoring device in related technologies, and achieving the technical effect of improving the communication reliability between the diagnostic device and the fault monitoring device.

[0038] In one exemplary embodiment, Figure 2 This is a schematic diagram of the structure of a communication device according to an embodiment of the present utility model. Figure 1 ,like Figure 2 As shown, the communication device 200 includes: an interface expansion device 210 and a remote communication device 220; the interface expansion device 210 is provided with a monitoring device interface 202 and a first expansion interface 212, and the remote communication device 220 is provided with a remote access interface 222 and a remote diagnostic device interface 204; the first expansion interface 212 is connected to the remote access interface 222.

[0039] Optionally, in this embodiment, the interface expansion device 210 may be, but is not limited to, a hardware integrated circuit for expanding a single upstream communication port into multiple downstream communication ports to realize data bus distribution, such as a USB HUB device, a PCIe (Peripheral Component Interconnect Express) switching device, an Ethernet switching integrated circuit, etc. The first expansion interface 212 may be, but is not limited to, a downstream port on the interface expansion device 210, such as a standard physical slot for connecting pluggable modules, such as an M.2 Key-B (M.2 interface with B-type key) slot, a Mini-PCIe (Mini Peripheral Component Interconnect Express) slot, etc.

[0040] Optionally, in this embodiment, the remote communication device 220 may be, but is not limited to, a hardware module for realizing wireless remote communication, capable of encapsulating data and transmitting it to a remote network, such as an IoT (Internet of Things) module, a 5G communication module, an NB-IoT (Narrowband Internet of Things) module, or a Long Range (LoRa) module. The remote access interface 222 may be, but is not limited to, a physical interface on the remote communication device 220 that matches the first expansion interface 212, such as the gold finger edge connector of an M.2 module or the gold finger of a Mini-PCIe interface.

[0041] Optionally, in this embodiment, the connection between the first expansion interface 212 and the remote access interface 222 can be a pluggable physical connection. For example, if the first expansion interface 212 is an M.2 Key-B slot and the remote access interface 222 is an M.2 gold finger, the gold finger of the remote communication device 220 is inserted into the M.2 Key-B slot, and an electrical connection is established by the spring contacts in the M.2 Key-B slot contacting the conductive pads on the gold finger. The connection between the first expansion interface 212 and the remote access interface 222 can also be achieved by soldering to achieve a board-to-board connection. For example, if the first expansion interface 212 is a set of pads on the main PCB, and the remote access interface 222 is a BGA (Ball Grid Array) or LGA (Land Grid Array) pad corresponding to the bottom of the remote communication device 220, the two can be permanently fixed and electrically connected by a reflow soldering process.

[0042] In this embodiment, the functions of the communication device 200 are decoupled into an interface expansion device 210 and a remote communication device 220, which are connected through a standardized first expansion interface 212 and a remote access interface 222. This allows the remote communication device 220 to be flexibly replaced as needed (e.g., upgraded from NB-IoT to a 5G module) without changing the main design of the interface expansion device 210 or the fault monitoring device 100, thus improving the maintainability and scalability of the system.

[0043] In one exemplary embodiment, Figure 3 This is a schematic diagram of the structure of a communication device according to an embodiment of the present utility model. Figure 2 ,like Figure 3 As shown, the communication device 200 also includes: a local communication device 230; the interface expansion device 210 is further provided with a second expansion interface 214, and the local communication device 230 is provided with a local access interface 232 and a local diagnostic device interface 206; the second expansion interface 214 is connected to the local access interface 232.

[0044] Optionally, in this embodiment, the local communication device 230 may be, but is not limited to, a physical interface for implementing wired local communication, capable of providing high-speed and stable data connection for field devices, such as a USB Type-A female connector, a USB Type-C interface, an RJ45 Ethernet interface, etc.

[0045] Optionally, in this embodiment, the second expansion interface 214 may be, but is not limited to, another downstream port on the interface expansion device 210, corresponding to the first expansion interface 212, such as the second downstream port of a USB HUB device, the second downstream channel of a PCIe switching device, etc. The local access interface 232 may be, but is not limited to, an electrical pin on the local communication device 230, used to connect to traces on the circuit board, such as the PCB soldering pins of a USB Type-A connector, the signal pins of an RJ45 connector, etc.

[0046] Optionally, in this embodiment, the connection between the second expansion interface 214 and the local access interface 232 can be achieved through internal traces on the PCB. For example, if the interface expansion device 210 and the local communication device 230 are both soldered on the same PCB, the second expansion interface 214 is electrically connected to the local access interface 232 through differential traces on the PCB.

[0047] This embodiment adds a local communication device to a communication device that includes a remote communication device and an interface expansion device, enabling the device to simultaneously possess both remote and local communication capabilities. When the remote network signal is poor or high-speed data export is required on-site, a connection can be established through the local diagnostic device interface, achieving multi-mode communication and further improving the reliability and convenience of communication.

[0048] In one exemplary embodiment, Figure 4 This is a schematic diagram of the structure of a remote communication device according to an embodiment of the present utility model, as shown below. Figure 4 As shown, the remote communication device 220 includes: an Internet of Things (IoT) module 224 and a trusted platform module 226; the IoT module 224 is provided with a remote access interface 222, a remote diagnostic device interface 204 and a first encryption interface 227, and the trusted platform module 226 is provided with a second encryption interface 228; the first encryption interface 227 is connected to the second encryption interface 228.

[0049] Optionally, in this embodiment, the IoT module 224 may be, but is not limited to, the main communication unit on the remote communication device 220, responsible for handling wireless communication protocols (such as 5G, NB-IoT) and data transmission, such as a 5G baseband processing unit, NB-IoT SoC (System on Chip), WiFi module, etc.

[0050] Optionally, in this embodiment, the trusted platform module 226 may be, but is not limited to, a hardware security integrated circuit conforming to the TCG (Trusted Computing Group) specification, used to provide security functions such as encryption, key storage, and authentication.

[0051] Optionally, in this embodiment, the first encryption interface 227 and the second encryption interface 228 may be, but are not limited to, internal bus interfaces used for secure communication between the two modules, such as I2C master / slave controller interface, SPI master / slave bus interface, LPC (Low Pin Count) bus interface, etc.

[0052] Optionally, in this embodiment, the connection between the first encryption interface 227 and the second encryption interface 228 can be achieved through a dedicated bus on the internal PCB of the remote communication device 220. For example, the I2C master control pin on the IoT module 224 (serving as the first encryption interface 227) is connected to the I2C slave device pin (serving as the second encryption interface 228) of the trusted platform module 226 via a trace on the inner layer of the PCB. The connection between the first encryption interface 227 and the second encryption interface 228 can also be achieved through an SPI bus. For example, the SPI master control pin (serving as the first encryption interface 227) on the IoT module 224 is connected to the SPI slave device pin (serving as the second encryption interface 228) of the trusted platform module 226 to achieve higher-speed secure data interaction.

[0053] In this embodiment, a trusted platform module 226 is integrated into the remote communication device 220 as a hardware security core. This allows the storage and encryption of sensitive data (such as device keys and certificates) to be performed in the tamper-proof hardware of the trusted platform module 226, rather than in the general processing unit of the Internet of Things module 224 in a software manner. This enhances the security of data transmission and the credibility of device identity, preventing data in the remote communication link from being eavesdropped on, tampered with, or the device from being impersonated.

[0054] In one exemplary embodiment, Figure 5 This is a schematic diagram of a communication process supporting a target protocol according to an embodiment of the present utility model, as shown below. Figure 5 As shown, the first extended interface 212 is an interface that supports target protocols, including: message queue telemetry transmission protocol, restricted application protocol, narrowband Internet of Things protocol, fifth generation mobile communication technology protocol, hypertext transfer protocol, secure hypertext transfer protocol and long distance protocol.

[0055] Optionally, in this embodiment, the target protocol may be, but is not limited to, a network layer, transport layer, or application layer communication protocol that runs on top of physical and electrical connections, such as MQTT (Message Queuing Telemetry Transport), CoAP (Constrained Application Protocol), NB-IoT, 5G, HTTP (Hypertext Transfer Protocol), HTTPS (Hypertext Transfer Protocol Secure), and LoRa.

[0056] Optionally, in this embodiment, the support for the target protocol by the first expansion interface can be implemented through the firmware of the pluggable module. For example, the first expansion interface 212 itself (such as an M.2 slot) only defines physical and electrical standards (such as USB). The target protocol (such as MQTT) is implemented by the firmware of the remote communication device 220 inserted into the interface. For example, if an NB-IoT module is inserted, the system supports the NB-IoT and MQTT protocols; if the NB-IoT module is removed and a 5G module is inserted, the system switches to supporting the 5G and HTTPS protocols.

[0057] In this embodiment, a standardized first extension interface 212 is used to carry communication modules that support different target protocols, providing extremely high communication flexibility and scalability. Depending on the network coverage of the deployment environment (such as 5G, NB-IoT or LoRa), the corresponding remote communication device 220 can be freely selected and replaced without redesigning the entire diagnostic system, thus reducing the cost of adapting to different network environments.

[0058] In one exemplary embodiment, Figure 6 This is a schematic diagram of the structure of a server fault diagnosis system according to an embodiment of the present utility model. Figure 2 ,like Figure 6 As shown, the server fault diagnosis system also includes: storage device 500; the fault monitoring device 100 is also provided with storage device interface 106, and storage device 500 is provided with data interaction interface 502; storage device interface 106 is connected to data interaction interface 502.

[0059] Optionally, in this embodiment, the storage device 500 may be, but is not limited to, a non-volatile storage device used to store logs and data collected by the fault monitoring device 100, such as eMMC (embedded Multi Media Card) storage chips, UFS (Universal Flash Storage) chips, NAND Flash storage chips, etc.

[0060] Optionally, in this embodiment, the storage device interface 106 may be, but is not limited to, a dedicated controller pin on the fault monitoring device 100 for connecting to an external memory, such as a pin of an eMMC controller, a pin of an SDIO (Secure Digital Input Output) controller, a pin of an SPI controller, etc.

[0061] Optionally, in this embodiment, the data interaction interface 502 may be, but is not limited to, a pin on the storage device 500 used to receive data and instructions, such as the BGA solder ball of the eMMC storage chip, the TSOP (Thin Small Outline Package) pad of the NAND Flash device, etc.

[0062] Optionally, in this embodiment, the connection between the storage device interface 106 and the data interaction interface 502 can be achieved by soldering them onto the same PCB board. For example, the fault monitoring device 100 and the storage device 500 are soldered onto the same PCB, and the electrical connection is achieved through high-speed parallel bus traces on the inner layer of the PCB.

[0063] In this embodiment, the fault monitoring device 100 stores the collected server status data and log data into the storage device 500 via the storage device interface 106, preventing data loss during power outages or restarts. Preferably, eMMC storage chips are used as the storage device 500, and a wear leveling algorithm is enabled. Compared to related technologies that rely solely on TF (TransFlash) cards, this provides a higher performance, higher reliability, and longer write / erase life storage solution, resolving the risk of data loss due to TF card damage in fault monitoring devices of related technologies.

[0064] In one exemplary embodiment, the data interaction interface 502 of the storage device 500 is soldered to the storage device interface 106 of the fault monitoring device 100.

[0065] Optionally, in this embodiment, the data interaction interface 502 may be a BGA or LGA pad / solder ball on the bottom of the storage device 500.

[0066] Optionally, in this embodiment, the storage device interface 106 may be a copper foil pad coated with solder paste on the PCB board of the fault monitoring device 100, corresponding to the storage particle pads.

[0067] Optionally, in this embodiment, the data interaction interface 502 can be soldered to the storage device interface 106 of the fault monitoring device 100 via a reflow soldering process. For example, the storage device 500 (BGA package) is mounted onto the storage device interface 106 (pad) on the PCB board, and then the entire PCB is sent into a reflow oven where the solder melts and then cools to form a permanent electrical and mechanical connection.

[0068] This embodiment clarifies that the connection between the storage device 500 and the fault monitoring device 100 is achieved through soldering. Compared to the TF card slots used in related technologies, this metallurgical connection is structurally more robust, possessing extremely high vibration and shock resistance. It avoids poor contact caused by connector vibration, oxidation, or loosening in the server operating environment, greatly improving data storage reliability. Furthermore, the soldered storage is smaller, optimizing the PCB layout of the fault monitoring device 100 and eliminating the need for USB signals on the motherboard, thus also optimizing the motherboard design.

[0069] When the server fault diagnosis system in this embodiment of the invention is working, the internal status data and logs of the server under monitoring (including server controller 600, server component 700, and server expansion component 800) are collected through the monitoring server interface 102 (including component monitoring interface 103, controller monitoring interface 105, and expansion monitoring interface 107) on the fault monitoring device 100. The data is then processed and timestamped by the fault monitoring device 100 and subsequently stored in the storage device 500. When diagnostic data is needed, the data is sent from the fault monitoring device 100 to the monitoring device interface 202 of the communication device 200 through the first communication device interface 104, and then enters the interface expansion device 210 (e.g., a USB hub device). The interface expansion device 210 copies and distributes the data signal to two independent communication links:

[0070] Link 1 (Remote): Data enters the remote communication device 220 (e.g., IoT module) through the first extended interface 212 and the remote access interface 222, and is then sent to the remote diagnostic device 300 by the remote diagnostic device interface 204.

[0071] Link 2 (Local): Data enters the local communication device 230 (e.g., USB Type-A interface) through the second expansion interface 214 and the local access interface 232, and is then sent to the local diagnostic device 400 through the local diagnostic device interface 206 (USB port).

[0072] The establishment and data transmission processes of the two links mentioned above operate independently of the server controller 600 of the monitored server. Even if the server controller 600 or its management network malfunctions, the remote diagnostic device 300 or the local diagnostic device 400 can still obtain data from the fault monitoring device 100 through this independent link, thus solving the problem of single point of failure and low reliability in the communication path.

[0073] In one exemplary embodiment, Figure 7 This is a schematic diagram of the structure of a server fault diagnosis system according to an embodiment of the present utility model. Figure 3 ,like Figure 7 As shown, the fault monitoring device 100 is also provided with a first integrated circuit bus interface 108, and the local diagnostic device 400 is also provided with a first network interface 404; the first integrated circuit bus interface 108 is connected to the second integrated circuit bus interface 602 of the server controller 600 of the monitored server; the first network interface 404 is connected to the second network interface 604 of the server controller 600.

[0074] Optionally, in this embodiment, the first integrated circuit bus interface 108 may be, but is not limited to, a pin on the fault monitoring device 100 used for I2C communication, such as the I2C_SDA pin and I2C_SCL pin, or the SPI bus interface pin, on the M.2 gold finger of the fault monitoring device. The second integrated circuit bus interface 602 may be, but is not limited to, a pin on the server controller 600 used for connecting I2C slave devices, such as the I2C bus interface 9, or the SPI controller pin, on the BMC (or DC-SCM (Datacenter-ready Secure Control Module)).

[0075] Optionally, in this embodiment, the first network interface 404 may be, but is not limited to, an Ethernet interface on the local diagnostic device 400 used for network connection, such as an RJ45 interface. The second network interface 604 may be, but is not limited to, a dedicated out-of-band management network interface of the server controller 600, such as an RJ45 interface, NC-SI (Network Controller Sideband Interface), etc.

[0076] Optionally, in this embodiment, the connection between the first integrated circuit bus interface 108 and the second integrated circuit bus interface 602 can be achieved through PCB traces on the server motherboard. For example, the I2C pins on the gold fingers of the fault monitoring device 100 (serving as the first integrated circuit bus interface 108) are inserted into the M.2 slot, and the slot pins are connected to the I2C pins of the server controller 600 (serving as the second integrated circuit bus interface 602) through PCB traces on the motherboard.

[0077] Optionally, in this embodiment, the connection between the first network interface 404 and the second network interface 604 can be achieved through a local area network (LAN). For example, the RJ45 port of the local diagnostic device 400 (as the first network interface 404) and the management port of the server controller 600 (as the second network interface 604) are both connected to the same network switch, achieving the connection through an IP network. Alternatively, they can be directly connected using a crossover cable. For example, the RJ45 port of the local diagnostic device 400 can be directly connected to the management port of the server controller 600 using a crossover cable.

[0078] In this embodiment, in addition to the independent communication link, a traditional communication link relayed through the server controller 600 is also retained. The server fault diagnosis system with both the independent and traditional communication links is a dual-path redundancy system: when the server controller 600 is normal, the traditional communication link can be used; when the server controller 600 is abnormal, the independent communication link can be used, thereby maximizing the communication reliability of the entire diagnosis system.

[0079] In one exemplary embodiment, Figure 8 This is a schematic diagram of the structure of a monitoring server interface according to an embodiment of the present utility model. Figure 1 ,like Figure 8 As shown, the monitoring server interface 102 includes: at least one component monitoring interface 103 and a controller monitoring interface 105; the component monitoring interface 103 is connected to the server component 700 of the monitored server; the controller monitoring interface 105 is connected to the controller log interface 606 of the server controller 600 of the monitored server.

[0080] Optionally, in this embodiment, the server component may be, but is not limited to, key components such as CPLD and ADC microcontroller.

[0081] Optionally, in this embodiment, the component monitoring interface 103 may be, but is not limited to, an interface for connecting key components (non-server controller) on the server motherboard, such as an SPI bus interface, GPIO (General Purpose Input Output) pins, INT (Interrupt) pins, etc.

[0082] Optionally, in this embodiment, the controller monitoring interface 105 may be, but is not limited to, an interface used for collecting logs from the server controller 600, such as the RXD (Receive Data) pin of a UART. The controller log interface 606 may be, but is not limited to, the TXD (Transmit Data) pin of a serial port on the server controller 600 used for outputting debug logs.

[0083] Optionally, in this embodiment, the connection between the component monitoring interface 103 and the server component can be achieved through PCB traces on the server motherboard. For example, the SPI pin on the gold finger of the fault monitoring device 100 (as the component monitoring interface 103) is inserted into the M.2 slot, and the slot pin is connected to the SPI pin of the server component (such as a CPLD) through motherboard traces.

[0084] Optionally, in this embodiment, the connection between the controller monitoring interface 105 and the controller log interface 606 can be achieved through PCB traces on the server motherboard. For example, the UART RXD pin on the gold fingers of the fault monitoring device 100 (serving as the controller monitoring interface 105) is inserted into an M.2 slot, and the slot pin is connected to the UART TXD pin of the server controller 600 (serving as the controller log interface 606) through motherboard traces. Alternatively, a jumper cap can also be used for connection. For example, a set of pins is provided on the motherboard, and both the RXD pin of the fault monitoring device 100 and the TXD pin of the server controller 600 are connected to this set of pins, and the connection is achieved by inserting a jumper cap.

[0085] This embodiment enables the fault monitoring device 100 to monitor the server's health status from multiple dimensions. The component monitoring interface 103 can acquire the lowest-level hardware signals (such as timing, voltage, and alarms); the controller monitoring interface 105 can acquire the server controller's software logs. Combining this multi-dimensional data allows for more accurate fault location and improves diagnostic accuracy.

[0086] In one exemplary embodiment, Figure 9 This is a schematic diagram of the structure of a monitoring server interface according to an embodiment of the present utility model. Figure 2 ,like Figure 9 As shown, the monitoring server interface 102 also includes at least one extended monitoring interface 107; the extended monitoring interface 107 is connected to the server expansion component 800 of the monitored server.

[0087] Optionally, in this embodiment, the extended monitoring interface 107 may be, but is not limited to, an additional monitoring channel on the monitoring server interface 102 in addition to the component monitoring interface 103 and the controller monitoring interface 105, such as one or more additional UART RXD pins, additional I2C bus interfaces, etc.

[0088] Optionally, in this embodiment, the server expansion component 800 of the monitored server may be, but is not limited to, other key integrated circuits or plug-in cards on the server motherboard of the monitored server that can provide logging, in addition to CPLD, ADC, and server controller, such as SAS Expander (Serial Attached Small Computer System Interface Expander), PCIe Switch, SmartNIC (Network Interface Card), Raid Card, etc.

[0089] Optionally, in this embodiment, the connection between the extended monitoring interface 107 and the server expansion component 800 can be achieved through PCB traces on the server motherboard. For example, the UART3 RXD pin on the gold finger of the fault monitoring device 100 (as the extended monitoring interface 107) is inserted into the M.2 slot, and the slot pin is connected to the UART TXD debug pin of the SAS Expander through motherboard traces.

[0090] In this embodiment, the fault monitoring device 100, in addition to monitoring the motherboard core components and BMC, can also delve into the server's data path and I / O (Input / Output) subsystem through the extended monitoring interface 107. This enables the provision of more comprehensive and richer on-site data when facing complex cross-component faults (such as PCIe link problems or SAS storage problems), helping to quickly locate the root cause of the problem.

[0091] Optionally, in this embodiment, in order to better understand the above-mentioned server fault diagnosis system, the workflow of the above-mentioned server fault diagnosis system will be described below in conjunction with optional embodiments, but this is not intended to limit the present invention.

[0092] This utility model provides a server fault diagnosis system. Figure 10 This is a schematic diagram of the internal structure of the server fault diagnosis system according to an embodiment of the present invention during operation, as shown below. Figure 10 As shown, the server fault diagnosis system takes the fault diagnosis module (i.e., fault monitoring device 100) as its core. It integrates a main control unit (such as i.MX 8MMini, which supports eMMC 5.1 and USB2.0 OTG, has built-in high-speed interfaces such as PCIe, and can be expanded with IoT communication modules) and a real-time clock (RTC), forming a core unit that integrates data acquisition, processing, storage and communication functions.

[0093] From the data acquisition perspective, the fault diagnosis module connects to various components of the monitored server (i.e., server component 700 and server expansion component 800) through GPIO, SPI, INT and multiple sets of UART pins (i.e., monitoring server interface 102), constructing a multi-dimensional signal acquisition network: it connects to the motherboard CPLD through GPIO, SPI and INT pins to acquire alarm signals and timing signals in real time; it connects to the motherboard MCU (Microcontroller Unit) ADC through SPI to accurately acquire voltage signals (for example, when a voltage abnormality is detected, it will automatically record the voltage waveform 5 seconds before and after the abnormality and store the voltage waveform log to the storage device); it connects to the UART pin (606) of the BMC (i.e., server controller 600) through a set of UART pins to collect BMC serial port logs; and it connects to server expansion components such as SAS Expander, PCIeSwitch, Smart NIC and Raid Card through multiple sets of UART pins to comprehensively acquire the operation logs of these I / O components.

[0094] In terms of data storage, the fault diagnosis module connects to the eMMC (i.e., storage device 500) via the eMMC bus (i.e., storage device interface 106) to perform local persistent storage of the various types of data collected above, ensuring that the data is not lost when the device is powered off or restarted.

[0095] In terms of communication architecture, the independent communication path starts from the USB bus of the main control unit MCU (i.e., the first communication device interface 104), connects to the USB HUB (i.e., the interface expansion device 210), and then branches into two links: one is connected to the IoT module (i.e., the remote communication device 220) through a 1xUSB 2.0 bus (i.e., the connection between the first expansion interface 212 and the remote access interface 222), and then establishes remote communication with the host computer (i.e., the remote diagnostic device 300) through the antenna interface of the IoT module (i.e., the remote diagnostic device interface 204); the other is connected to the USB Type A interface (i.e., the local communication device 230) through another USB bus (i.e., the connection between the second expansion interface 214 and the local access interface 232), and then realizes on-site data interaction with the local PC (Personal Computer) (i.e., the local diagnostic device 400) through its USB-A port (i.e., the local diagnostic device interface 206). The redundant communication path is connected to the I2C9 pin (i.e., the second integrated circuit bus interface 602) of the server controller through the I2C bus of the fault diagnosis module (i.e., the first integrated circuit bus interface 108), as a supplement to the independent communication path, forming a redundant backup of the traditional communication link.

[0096] The above architecture design enables the fault diagnosis module to comprehensively collect and reliably store server hardware signals and software logs. It also relies on dual communication paths to ensure stable transmission of diagnostic data in both local and remote scenarios. Furthermore, the redundancy design further enhances the reliability of system communication.

[0097] The server fault diagnosis system provided by this utility model has been described in detail above. Specific examples have been used to illustrate the principle and implementation of this utility model. The descriptions of the above embodiments are only intended to help understand the method and core idea of ​​this utility model. It should be noted that those skilled in the art can make various improvements and modifications to this utility model without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this utility model.

Claims

1. A server fault diagnosis system, characterized in that, include: Fault monitoring equipment (100), communication equipment (200), remote diagnostic equipment (300) and local diagnostic equipment (400); The fault monitoring device (100) is provided with a monitoring server interface (102) and a first communication device interface (104). The communication device (200) is provided with a monitoring device interface (202), a remote diagnostic device interface (204) and a local diagnostic device interface (206). The remote diagnostic device (300) is provided with a second communication device interface (302). The local diagnostic device (400) is provided with a third communication device interface (402). The first communication device interface (104) is connected to the monitoring device interface (202), the remote diagnostic device interface (204) is connected to the second communication device interface (302), and the local diagnostic device interface (206) is connected to the third communication device interface (402).

2. The server fault diagnosis system according to claim 1, characterized in that, The communication device (200) includes: an interface expansion device (210) and a remote communication device (220). The interface expansion device (210) is provided with the monitoring device interface (202) and the first expansion interface (212), and the remote communication device (220) is provided with the remote access interface (222) and the remote diagnostic device interface (204). The first expansion interface (212) is connected to the remote access interface (222).

3. The server fault diagnosis system according to claim 2, characterized in that, The communication device (200) further includes: a local communication device (230); The interface expansion device (210) is also provided with a second expansion interface (214), and the local communication device (230) is provided with a local access interface (232) and a local diagnostic device interface (206). The second expansion interface (214) is connected to the local access interface (232).

4. The server fault diagnosis system according to claim 2, characterized in that, The remote communication device (220) includes: Internet of Things module (224) and Trusted Platform module (226); The Internet of Things module (224) is provided with the remote access interface (222), the remote diagnostic device interface (204) and the first encryption interface (227), and the trusted platform module (226) is provided with the second encryption interface (228). The first encryption interface (227) is connected to the second encryption interface (228).

5. The server fault diagnosis system according to claim 2, characterized in that, The first extended interface (212) is an interface that supports target protocols, including: message queue telemetry transmission protocol, restricted application protocol, narrowband Internet of Things protocol, fifth generation mobile communication technology protocol, hypertext transfer protocol, secure hypertext transfer protocol and long distance protocol.

6. The server fault diagnosis system according to claim 1, characterized in that, The server fault diagnosis system also includes: a storage device (500). The fault monitoring device (100) is also provided with a storage device interface (106), and the storage device (500) is provided with a data interaction interface (502). The storage device interface (106) is connected to the data interaction interface (502).

7. The server fault diagnosis system according to claim 6, characterized in that, The data interaction interface (502) of the storage device (500) is soldered to the storage device interface (106).

8. The server fault diagnosis system according to claim 1, characterized in that, The fault monitoring device (100) is also provided with a first integrated circuit bus interface (108), and the local diagnostic device (400) is also provided with a first network interface (404). The first integrated circuit bus interface (108) is connected to the second integrated circuit bus interface (602) of the server controller (600) of the monitored server; The first network interface (404) is connected to the second network interface (604) of the server controller (600).

9. The server fault diagnosis system according to claim 1, characterized in that, The monitoring server interface (102) includes: At least one component monitoring interface (103) and controller monitoring interface (105); The component monitoring interface (103) is connected to the server component (700) of the monitored server; The controller monitoring interface (105) is connected to the controller log interface (606) of the server controller (600) of the monitored server.

10. The server fault diagnosis system according to claim 9, characterized in that, The monitoring server interface (102) further includes: at least one extended monitoring interface (107). The extended monitoring interface (107) is connected to the server extension component (800) of the monitored server.

Images