An asset information acquisition method, device, medium and product

Abstract

The present application relates to the technical field of server management, and particularly relates to an asset information acquisition method, device, medium and product, the method comprising: scanning downstream equipment of a high-speed serial computer expansion bus standard switch, acquiring basic information of the downstream equipment, the basic information at least comprising equipment identification and equipment type; constructing an equipment registration frame and sending the equipment registration frame to a baseboard management controller through a secure communication channel, so that the baseboard management controller updates an equipment list locally according to the equipment registration frame; the high-speed serial computer expansion bus standard switch is connected with the baseboard management controller through the secure communication channel, and information transmitted through the secure communication channel is encrypted based on a session key; detecting whether insertion or removal of the downstream equipment occurs, and when insertion or removal occurs, sending plugging event reporting information to the baseboard management controller through the secure communication channel, so that the efficiency and security of asset information acquisition can be improved.

Description

Technical Field

[0001] This invention relates to the field of server management technology, and in particular to a method, device, medium and product for acquiring asset information. Background Technology

[0002] As data centers continue to expand and the number of servers grows exponentially, hardware asset management has become a core component of the operations and maintenance system. Servers extensively utilize PCIe (Peripheral Component Interconnect Express) devices, such as NVMe solid-state drives, GPU accelerator cards, and high-speed network cards. Accurately obtaining asset information for these devices (including manufacturer name, product model, serial number, firmware version, and PCIe link capabilities) is fundamental for asset management, fault diagnosis, lifecycle management, and capacity planning.

[0003] The Baseboard Management Controller (BMC) is an independent embedded management unit on the server motherboard that does not rely on the main CPU and operating system to run. It is responsible for monitoring hardware status (temperature, voltage, fan speed), providing remote management interfaces (IPMI, Redfish), and recording system event logs.

[0004] In related technologies, a dedicated side link (such as SMBus, I2C, LPC) is established between the BMC and the PCIe switch that supports the Management Endpoint function. A lightweight proxy service module is embedded in the switch firmware. After the BMC issues a command, the proxy service module directly accesses the configuration space of the downstream PCIe device to obtain asset information and then returns it to the BMC. However, the asset information acquisition efficiency is low and the security is poor.

[0005] It is evident that improving the efficiency and security of asset information acquisition is a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0006] The purpose of this invention is to provide a method, device, medium, and product for acquiring asset information, which can improve the efficiency and security of asset information acquisition.

[0007] Firstly, an asset information acquisition method is provided, applicable to high-speed serial computer expansion bus standard switches, including: Scan the downstream devices of the high-speed serial computer extended bus standard switch to obtain basic information of the downstream devices, including at least device identifier and device type; A device registration frame is constructed and sent to the baseboard management controller via a secure communication channel, so that the baseboard management controller updates its local device list based on the device registration frame; wherein, the device registration frame includes basic information of the downstream device; the high-speed serial computer extended bus standard switch is connected to the baseboard management controller through a secure communication channel, and the information transmitted through the secure communication channel is encrypted based on a session key; The system detects whether the downstream device has been inserted or removed. When insertion or removal occurs, the system sends insertion / removal event reporting information to the baseboard management controller via the secure communication channel, so that the baseboard management controller updates the device list based on the insertion / removal event reporting information.

[0008] In a preferred embodiment, the present invention may further be configured to include: Receive the read command sent by the baseboard management controller via the secure communication channel; In response to the read command, the configuration space of the corresponding downstream device is accessed to read the original asset information; the original asset information is then encapsulated into response information. The response information is sent to the baseboard management controller via the secure communication channel.

[0009] In a preferred embodiment, the present invention may be further configured to: before accessing the configuration space corresponding to the downstream device and reading the original asset information in response to the read command, further include: When the corresponding and non-expired original asset information exists in the local cache, the original asset information in the local cache is encapsulated and the encapsulated response information is sent to the baseboard management controller through the secure communication channel. When the corresponding original asset information does not exist in the local cache or when there is expired original asset information, the step of accessing the configuration space of the corresponding downstream device and reading the original asset information is executed.

[0010] In a preferred embodiment, the present invention may further be configured to include: Record the access history of the baseboard management controller to the asset information of each of the downstream devices; Based on the access history, predict the downstream devices that will be frequently accessed in the future; The predicted asset information of the downstream devices is pre-read and stored in the local cache.

[0011] In a preferred embodiment, the present invention can be further configured to: receive a read command sent by the baseboard management controller via the secure communication channel, including: The system receives a TLV format command frame sent by the baseboard management controller via the secure communication channel. The command frame includes a frame header, session identifier, sequence number, TLV block sequence, and message authentication code. The TLV block sequence consists of at least one TLV block, and each TLV block includes a type field, a length field, and a value field. The type field is used to define the command type. Parse the command frame to obtain the read command corresponding to the command type.

[0012] In a preferred embodiment, the present invention can be further configured such that: the command type includes a batch read command, the batch read command being used to instruct the reading of asset information of multiple downstream devices at once; In response to the read command, the configuration space of the corresponding downstream device is accessed to read the original asset information; the original asset information is encapsulated into response information, including: The configuration space of each downstream device indicated by the batch read command is accessed sequentially to read the original asset information of each device; The original asset information of each downstream device read is encapsulated in the same response information and returned to the baseboard management controller via the secure communication channel.

[0013] In a preferred embodiment, the invention may further be configured to include, prior to scanning downstream devices of the high-speed serial computer extended bus standard switch: Receive the first handshake message sent by the baseboard management controller, which carries the digital certificate of the baseboard management controller; Verify the validity of the digital certificate of the baseboard management controller for the first handshake message; After successful verification, a second handshake message carrying the digital certificate of the switch is sent to the baseboard management controller, so that the baseboard management controller can verify the legality of the digital certificate of the switch in the second handshake message, and generate a session key after successful verification; the session key is used to encrypt information transmitted through the secure communication channel. The session key is used to interact with the baseboard management controller to confirm the message, thereby establishing a secure communication channel with the baseboard management controller.

[0014] In a preferred embodiment, the present invention can be further configured to: verify the legitimacy of the digital certificate of the baseboard management controller for the first handshake message, including: Verify the digital signature, validity period, and certificate chain of the digital certificate of the baseboard management controller for the first handshake message.

[0015] In a preferred embodiment, the present invention may further be configured to include: Health parameters of each downstream device are actively collected according to a preset cycle. The health parameters include temperature, link error count, power consumption, and bandwidth utilization. The collected health parameters are actively reported to the baseboard management controller via the secure communication channel.

[0016] In a preferred embodiment, the present invention may further be configured to include: The system receives a firmware upgrade command sent by the baseboard management controller via the secure communication channel. The firmware upgrade command includes firmware version, fragment number, fragment data, and verification information. The data of each segment is stored. When the transmission of a segment fails, the baseboard management controller is requested to resume transmission from the breakpoint of that segment. After all the fragmented data has been received, the firmware image is verified for integrity. If the verification is successful, it is written to the backup firmware partition so that the firmware can be automatically started from the backup partition on the next reboot.

[0017] Secondly, an asset information acquisition method is provided, applied to a baseboard management controller, including: The device registration frame sent by the high-speed serial computer extended bus standard switch is received via a secure communication channel. The device registration frame includes basic information of the downstream devices of the high-speed serial computer extended bus standard switch. The basic information includes at least the device identifier and the device type. The device list on the baseboard management controller is updated based on the device registration frame. The system receives insertion / removal event reporting information from the high-speed serial computer extended bus standard switch via the secure communication channel. The insertion / removal event reporting information is used to indicate that the downstream device has been inserted or removed. The device list is updated based on the reported plug-in / plug-out events.

[0018] In a preferred embodiment, the present invention may further be configured to include: Construct a command frame in TLV format, the command frame including a frame header, session identifier, sequence number, TLV block sequence and message authentication code; wherein, the TLV block sequence consists of at least one TLV block, each TLV block including a type field, a length field and a value field, the type field being used to define the command type; The command frame is sent to the high-speed serial computer extended bus standard switch via the secure communication channel. The command frame is used to instruct the high-speed serial computer extended bus standard switch to read the asset information of the downstream device.

[0019] A third aspect provides an electronic device, including a memory for storing a computer program; and a processor for executing the computer program to implement the method as described in any of the first aspects, or the method as described in any of the second aspects.

[0020] Fourthly, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the method described in any of the first aspects or the method described in any of the second aspects.

[0021] Fifthly, a computer program product is provided, comprising a computer program or instructions that, when executed by a processor, implement the method described in any of the first aspects or the method described in any of the second aspects.

[0022] In summary, the method provided by this invention has the following beneficial technical effects: The PCIe switch first scans its downstream devices to obtain basic information, including at least the device identifier and device type. This allows the switch to proactively discover all its connected PCIe devices without relying on external configuration or manual input. The switch constructs a device registration frame carrying this basic information and sends it to the BMC via a secure communication channel. Because this secure communication channel encrypts the transmitted information using a session key, the confidentiality and integrity of the device registration frame during transmission are guaranteed, preventing malicious devices from forging registration information or attackers from eavesdropping and causing information leakage. Upon receiving the registration frame, the BMC updates its local device list accordingly, enabling the BMC to accurately and in real-time grasp the topology information of the downstream devices. Furthermore, the switch continuously monitors the insertion and removal status of downstream devices. When an insertion or removal event occurs, it reports the event information to the BMC via the secure communication channel, and the BMC dynamically updates its device list accordingly. The device list on the BMC side can automatically and synchronously update with the actual physical changes of the downstream devices of the PCIe switch, always reflecting the true online status of the devices, thus enabling real-time and reliable monitoring of device information.

[0023] In addition, the present invention also provides an apparatus, a medium, and a product, all of which have the aforementioned beneficial technical effects. Attached Figure Description

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

[0025] Figure 1 This is a schematic diagram illustrating an application scenario of an asset information acquisition system provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of an asset information acquisition method provided in an embodiment of the present invention; Figure 3 This is a flowchart of the dynamic device discovery and registration process in an embodiment of the present invention; Figure 4 This is a flowchart illustrating the establishment of a secure communication channel according to an embodiment of the present invention; Figure 5 This is a schematic diagram of a TLV command frame provided in an embodiment of the present invention; Figure 6 This is a flowchart of the proxy service firmware remote upgrade process provided in an embodiment of the present invention; Figure 7 This is a specific asset information acquisition process provided by an embodiment of the present invention; Figure 8 A schematic diagram illustrating another method for obtaining asset information provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0027] It should be noted that, in the optional embodiments of the present invention, the data related to object information, etc., requires the permission or consent of the object when the embodiments of the present invention are applied to specific products or technologies. Furthermore, the collection, use, and processing of the relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. In other words, if the embodiments of the present invention involve data related to an object, it must be obtained with the permission and consent of the object, the permission and consent of relevant departments, and in accordance with the relevant laws, regulations, and standards of the country and region. If the embodiments involve personal information, the acquisition of all personal information requires the consent of the individual. If sensitive information is involved, the separate consent of the information subject is required. The embodiments also need to be implemented with the permission and consent of the object.

[0028] The terms "comprising" and "having," and any variations thereof, in the specification and accompanying drawings of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may include steps or units not listed.

[0029] There are two traditional methods for the BMC to obtain PCIe device asset information: 1. BIOS Push Method: During startup, the Basic Input / Output System (BIOS) enumerates and initializes PCIe devices. After completing the configuration space scan, it pushes asset information to the BMC through a pre-defined interface (such as IPMI commands). This method has significant drawbacks: the BMC is tightly coupled with the BIOS. If the BIOS fails to boot, has a configuration error, or enters hibernation (the BIOS typically no longer actively interacts with the BMC after the operating system starts), the BMC cannot obtain or update asset information. Furthermore, this method cannot detect hot-plugging events; when an NVMe hard drive or GPU is removed or inserted during operation, the BMC is completely unaware. 2. Production Burning Method: During server production and assembly, pre-collected PCIe device asset information is written to non-volatile memory (such as EEPROM or SPI Flash) on the motherboard using a burning tool. The BMC reads the asset information from this memory after startup. The disadvantages of this method are: increased production processes and time costs; once written, the information is static and cannot reflect subsequent changes such as device replacement or upgrades; human error during the input process (such as serial number misalignment) can lead to long-term management chaos.

[0030] To address the aforementioned issues, related technologies propose establishing a dedicated side link (such as SMBus, I2C, or LPC) between the BMC and a PCIe switch supporting Management Endpoint functionality. A lightweight proxy service module is then embedded in the switch firmware. This proxy service module directly accesses the configuration space of downstream PCIe devices to obtain asset information and then returns it to the BMC. This solution initially enables the BMC to obtain asset information independently of the BIOS and provides hot-swap awareness. However, this technology lacks effective security protection during communication, and device discovery relies on the BMC's proactive polling, resulting in low efficiency.

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

[0032] To facilitate understanding, we will first provide a unified explanation of the key terms that appear repeatedly in this article. When they appear in subsequent articles, we will continue to use this definition and will not repeat the explanation.

[0033] Among them, the high-speed serial computer expansion bus standard switch, also known as a PCIe switch, refers to a PCIe switching device that supports management endpoint functionality. It is used to expand PCIe device connections and allows external managers to access the management information of downstream devices through a dedicated interface.

[0034] The proxy service module is a lightweight software module embedded in the PCIe switch firmware, which is responsible for communicating with the BMC and accessing the configuration space of downstream PCIe devices.

[0035] A side link refers to a dedicated physical connection between the BMC and the PCIe switch, such as a Serial Management Bus (SMBus), an Inter-Integrated Circuit (I2C) bus, or a Low Pin Count (LPC) bus.

[0036] A secure communication channel refers to a logically encrypted link established between the BMC and the PCIe switch through two-way authentication and negotiation of session keys. Both the command frames and response frames transmitted are encrypted with the session key and an additional message authentication code is attached.

[0037] The device list refers to a database or configuration file that BMC maintains locally and persistently, recording the asset information and status of each downstream PCIe device.

[0038] A session key is a symmetric key derived by the two communicating parties through a key negotiation algorithm, used to encrypt and decrypt data during the current session.

[0039] A Message Authentication Code (MAC) is a cryptographic label used to verify the integrity and authenticity of a message.

[0040] Hot-swapping allows for the insertion or removal of devices while the system is running, and the system can automatically recognize and adjust accordingly.

[0041] The cache stores recently read device asset information in the agent service module to improve response speed.

[0042] Firmware upgrade refers to updating the firmware in a hardware device via software.

[0043] In one embodiment, please refer to Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario of an asset information acquisition system provided by an embodiment of the present invention. The system includes a Base Management Controller (BMC), a PCIe switch supporting management endpoint functions, and several downstream PCIe devices (e.g., NVMe solid-state drives, GPU accelerator cards, high-speed network cards). The BMC and the PCIe switch are connected via a sidelink, and the PCIe switch connects to each downstream device via a PCIe bus. A proxy service module runs in the PCIe switch firmware, used to proactively register devices with the BMC on a secure communication channel, report plug-in / plug-out and health events, and respond to the BMC's asset read commands. The following embodiments are all based on the above scenario.

[0044] Specifically, this invention provides an asset information acquisition method applied to a high-speed serial computer expansion bus standard switch, such as... Figure 2 As shown, the method includes the following steps.

[0045] S110. Scan downstream devices of the high-speed serial computer expansion bus standard switch to obtain basic information of the downstream devices, including at least device identifier and device type.

[0046] Downstream devices refer to terminal devices connected to the high-speed serial computer expansion bus standard switch port via the PCIe bus, such as Non-Volatile Memory Express (NVMe) solid-state drives, Graphics Processing Unit (GPU) accelerator cards, and high-speed network interface cards. Device identifier is an address or number used to uniquely locate a downstream device in the PCIe topology. Device type refers to an attribute characterizing the functional category of the downstream device, such as a storage device, network device, or computing acceleration device (GPU). Basic information includes at least device identifier and device type, and may also include manufacturer name, product model, etc.

[0047] In this embodiment of the invention, the proxy service module in the switch firmware automatically runs when the switch powers on to implement the asset information acquisition method. Specifically, when the switch powers on, the proxy service module performs a scan of the PCIe bus, traverses all downstream devices, and reads basic information from the configuration space of each device, including device identifiers such as BDF address, vendor ID (VID), device ID (DID), and device type (such as storage device, network device, GPU, etc.).

[0048] S120: Construct a device registration frame and send it to the baseboard management controller via a secure communication channel, so that the baseboard management controller updates its local device list based on the device registration frame. The device registration frame includes basic information about the downstream device; the high-speed serial computer extended bus standard switch is connected to the baseboard management controller through a secure communication channel, and the information transmitted through the secure communication channel is encrypted based on the session key.

[0049] In this step, a device registration frame is constructed and actively sent to the BMC through the established secure communication channel. The registration frame contains basic attributes. After receiving the registration frame, the BMC updates its local device list and completes the device registration.

[0050] See Figure 3 , Figure 3This is a flowchart of the dynamic device discovery and registration process in an embodiment of the present invention, including: When the agent service timer is triggered, the device health parameters are read, a reporting frame is constructed, and sent to the BMC. The BMC analyzes whether the data exceeds the threshold. If so, an early warning event is generated; otherwise, it waits for the next reporting.

[0051] Understandably, the device list is not empty upon each power-on. In this embodiment of the invention, a differentiated update is performed. In standard BMC firmware design, the device list is typically persisted using non-volatile storage (such as a database or configuration file in flash memory). Therefore, the BMC's local device list is not empty upon each power-on; it retains all device information recorded before power-off. The basic attributes of the scanned current physical topology devices are incrementally compared and merged with the locally stored historical device list. Upon each power-on, the BMC reads the device list stored in the persistent medium as a baseline, then compares it with the latest scan results reported by the agent service module, and performs a differentiated update operation.

[0052] Specifically, if the scan result shows the first PCIe device, but the device does not exist in the local device list, the update action is to add a new record, achieving the goal of adding the newly connected PCIe device to the asset list. If the scan result shows the first PCIe device, and the device exists in the local device list but its information has changed, such as a change in firmware version, the update action is to update the corresponding fields, ensuring that the device itself remains unchanged in the device list, only its key attributes have been updated. If the scan result shows the first PCIe device, and the device exists in the local device list but its information has not changed, no action is taken. If the scan result shows the first PCIe device not detected, but the device exists in the local device list, the update operation is to mark it as removed or offline, indicating that the device has been physically disconnected or a link failure has occurred. Direct deletion is avoided to preserve historical asset audit records and fault analysis data.

[0053] If a system misses a device during a scan due to PCIe link instability, a full update would delete the device's information, making its history unavailable during subsequent troubleshooting. Incremental updates, however, retain the removed marker and timestamp, allowing administrators to determine whether the issue is a device malfunction or a temporary outage. Data center operations typically require auditing device service history, including insertion / removal records and maintenance logs; directly deleting these records would result in data loss. Furthermore, if the device list is large (e.g., hundreds of NVMe drives), differential updates only need to handle the changed portions, avoiding the need to rewrite all data.

[0054] In this embodiment of the invention, if managing a large-scale device list and supporting structured queries and transactions, the BMC can use a dedicated database to store the device list. This dedicated database can be a lightweight embedded database (such as SQLite). If the number of devices is small and query performance requirements are not high, the BMC can store the device list in a configuration file, storing the device list in a structured configuration file within the file system, such as in JSON / XML format. Regardless of the storage method used, this embodiment of the invention replaces the traditional passive query method of the BMC with the proactive registration and reporting mechanism of the agent service module, making device list updates more timely and efficient.

[0055] The device registration frame is a message frame constructed by the agent service module according to a predetermined protocol format, used to declare to the BMC which downstream devices the switch currently manages. Its payload includes basic information such as the device identifier and device type of each downstream device. The secure communication channel is an encrypted link established by the BMC and the PCIe switch through a handshake negotiation; all information transmitted through this channel is encrypted using a session key. The device list is a persistent database of device assets and status maintained by the BMC, which updates it based on the registration frame.

[0056] The purpose of this step is to proactively register the downstream device topology known to the switch with the BMC, ensuring that the BMC's local device list remains consistent with the physical topology. By adopting the above technical solution, the BMC can obtain complete and up-to-date asset information without relying on the BIOS or proactive polling, thereby improving the efficiency and independence of asset discovery.

[0057] S130. Detect whether a downstream device is inserted or removed. When insertion or removal occurs, send insertion / removal event reporting information to the board management controller via a secure communication channel, so that the board management controller updates the device list based on the insertion / removal event reporting information.

[0058] When the PCIe switch hardware detects a device insertion or removal interruption, the agent service module immediately constructs an event reporting frame, containing the BDF and basic information of the newly added device, or the identifier of the device to be removed as reporting information, and actively sends it to the BMC through a secure channel. The BMC then dynamically updates the device list accordingly.

[0059] In this embodiment of the invention, the switch's hardware hot-plug detection mechanism generates an interrupt signal when a device is detected being inserted or removed, notifying the agent service module. The agent service module reads the basic information of the newly inserted device, including at least BDF, VID, DID, or information confirming the removal of the device, immediately constructs an event reporting frame, and sends it to the BMC through a secure channel. Upon receiving the frame, the BMC updates its local device list in real time and may trigger subsequent asset information refresh operations, such as automatically sending batch read commands to obtain detailed asset information of the new devices.

[0060] The purpose of this step is to synchronize equipment insertion and removal changes during operation to the BMC in real time, ensuring that the equipment list always matches the actual state. By adopting the above technical solution, this embodiment of the invention can replace passive polling, actively and with low latency report hot-plug events, thereby ensuring that asset information is consistent with the actual physical state and supporting asset tracking of equipment changes during operation.

[0061] As can be seen, in this embodiment of the invention, the PCIe switch first scans its downstream devices to obtain basic information, including at least device identifiers and device types. This allows the switch to proactively discover all its connected PCIe devices without relying on external configuration or manual input. The switch constructs a device registration frame carrying the aforementioned basic information and sends it to the BMC via a secure communication channel. Because this secure communication channel encrypts the transmitted information based on a session key, the confidentiality and integrity of the device registration frame during transmission are guaranteed, preventing malicious devices from forging registration information or attackers from eavesdropping and causing information leakage. After receiving the registration frame, the BMC updates its local device list accordingly, enabling the BMC to accurately and in real-time grasp the topology information of the downstream devices. Furthermore, the switch continuously monitors the insertion and removal status of downstream devices. When an insertion or removal event occurs, it also reports the insertion or removal event information to the BMC via the secure communication channel, and the BMC dynamically updates the device list accordingly. The device list on the BMC side can be automatically and synchronously updated with the actual physical changes of the downstream devices of the PCIe switch, always reflecting the true online status of the devices, thereby enabling real-time and reliable monitoring of device information.

[0062] In one possible implementation of this application embodiment, to improve communication security, in this embodiment of the invention, before scanning downstream devices of a high-speed serial computer extended bus standard switch, the method further includes a process of establishing a secure communication channel, see [link to relevant documentation]. Figure 4 , Figure 4 This is a flowchart of a secure communication channel establishment provided by an embodiment of the present invention, including: S201, receiving a first handshake message carrying the digital certificate of the baseboard management controller sent by the baseboard management controller.

[0063] In this embodiment of the invention, the BMC and the PCIe switch that supports management endpoint functions establish a secure communication channel by handshaking through a side link, such as SMBus, I2C or LPC.

[0064] The BMC sends a first handshake message, such as a Hello message, to the switch. This message carries the BMC's own digital certificate, issued by a trusted certificate authority. The digital certificate is an electronic credential that binds the BMC device identifier, public key, validity period information, and digital signature, used to prove its identity to the other end.

[0065] This step is performed after the PCIe switch is powered on, the proxy service module starts and establishes a physical link with the BMC, and before scanning downstream devices. Specifically, the proxy service module listens for Hello messages from the BMC, extracts the attached BMC digital certificate, which contains the BMC device identifier, public key, validity period, and CA digital signature, and stores it temporarily for later verification.

[0066] S202. Verify the validity of the digital certificate of the baseboard management controller for the first handshake message.

[0067] Specifically, the digital signature, validity period, and certificate chain of the digital certificate of the baseboard management controller that verifies the first handshake message.

[0068] In this context, a digital signature refers to a hash value generated by a Certificate Authority (CA) using its private key to encrypt the certificate content. This hash proves that the certificate has not been tampered with and was indeed issued by the CA. The validity period refers to the two time boundaries in the certificate: no earlier than (not Before) and no later than (not After), and the current time must fall within these boundaries. The certificate chain refers to the path tracing back from the device certificate to the local root CA, typically consisting of three layers: the root CA, intermediate CAs, and the device certificate. After successful verification, the switch replies with a second handshake message, such as a Hello message, carrying its own digital certificate.

[0069] Specifically, the switch extracts all the original data (i.e., TBSCertificate, the content of the certificate to be signed) from the digital certificate, excluding the digital signature field. Using the hash algorithm specified in the certificate (such as SHA-256), a fixed-length hash value (Hash_1) is calculated on the original data. The digital signature field attached to the certificate is decrypted using the public key of the CA that issued the certificate. Since the signature was generated by the CA using its private key, the decrypted result yields the hash value (Hash_2) initially calculated by the CA. If Hash_1 equals Hash_2, the integrity check passes, the certificate content has not been tampered with during transmission, and the certificate was indeed issued by the authority holding the CA's private key. The switch also verifies whether the current date is within the validity period and verifies the certificate chain.

[0070] Understandably, in large enterprise or data center environments, the top-level root CA is typically not used directly to issue BMC certificates for every server, as the risk of its private key being leaked is extremely high. An intermediate CA is introduced instead. A certificate chain is a path tracing back from the device certificate to the trusted root certificate, typically containing the following hierarchical structure: Level 1 (Root CA): Signed by itself, extremely secure, usually stored offline, and pre-installed in the device's trust store. Level 2 (Intermediate CA): Signed by the root CA, used for routine device certificate issuance. Level 3 (End-entity Certificate): Signed by the intermediate CA, i.e., the certificate actually held by the BMC or switch. Example of a certificate chain path: Root CA certificate, issuance, intermediate CA certificate, issuance, BMC device certificate.

[0071] Verifying the certificate chain ensures that the certificate can be traced back to an absolutely trusted source (i.e., a trust anchor). The specific verification steps are as follows: Obtaining and arranging the certificate sequence: When the switch receives the BMC certificate, it usually also includes a sequence containing intermediate CA certificates. The switch needs to arrange these certificates in the following order: [BMC certificate], [Intermediate CA certificate], [Root CA certificate]. Step 1 Verification: Using the intermediate CA's public key, verify the digital signature on the BMC certificate. Successful verification indicates that the BMC certificate was indeed issued by the intermediate CA and has not been tampered with. Using the root CA's public key, verify the digital signature on the intermediate CA certificate. Successful verification indicates that the intermediate CA was indeed issued by the root CA and has not been tampered with. Check the local Trust Store to confirm that the root CA certificate exists in the store and is marked as trusted. Furthermore, you can check whether the certificate has been revoked (if this security level is enabled) via OCSP (Online Certificate Status Protocol) or CRL (Certificate Revocation List).

[0072] S203. After successful verification, a second handshake message carrying the digital certificate of the switch is sent to the baseboard management controller so that the baseboard management controller can verify the legality of the digital certificate of the switch in the second handshake message and generate a session key after successful verification; the session key is used to encrypt information transmitted through the secure communication channel.

[0073] BMC verifies the switch's certificate. Then, once both parties have successfully verified the certificate, they negotiate and generate a session key using the Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm. The session key is a symmetric key derived from the ECDH shared secret via KDF, used for AES-GCM encryption and MAC integrity protection.

[0074] By adopting the above technical solution, the two communicating parties establish a session key that is held only by each other on the insecure side link, laying the foundation for subsequent encrypted transmission.

[0075] S204. Use the session key to interact with the baseboard management controller to confirm the message, thereby establishing a secure communication channel with the baseboard management controller.

[0076] Both parties send an acknowledgment message, such as a Finished message, which is encrypted using the session key to confirm the establishment of a secure channel. Thereafter, all command and response frames are encrypted using the same session key with AES-GCM and appended with a Message Authentication Code (MAC) to ensure the confidentiality, integrity, and authenticity of the data.

[0077] As can be seen, in this embodiment of the invention, after both the switch and the BMC pass bidirectional authentication, a session key is generated. This session key is specifically used for the encryption protection of information transmitted on the subsequent secure communication channel. Finally, both parties use this session key to exchange confirmation messages, confirming successful key negotiation and establishing a secure communication channel. This constructs a trusted secure communication environment at the out-of-band management link level, effectively ensuring the security of the entire asset information management process.

[0078] In one possible implementation of this application embodiment, the method further includes: S301, Receive the read command sent by the board management controller through the secure communication channel.

[0079] Among them, the read command refers to the instruction issued by BMC through a secure communication channel to obtain detailed asset information of a certain downstream device or devices. Its typical form is a TLV format command frame, and the command type is used to indicate whether this read is a batch read, a cache read, or a health query, etc.

[0080] This step is executed when the BMC needs to query detailed asset information for a downstream device. Specifically, the proxy service module listens for encrypted frames from the BMC via a sidelink, decrypts them using the session key, verifies the MAC address, extracts the read command and its target device identifier and command type, and then passes the command to the subsequent processing flow. If decryption or MAC verification fails, the frame is discarded and a security event is recorded.

[0081] S302. In response to the read command, access the configuration space of the corresponding downstream device and read the original asset information; encapsulate the original asset information into response information; and send the response information to the baseboard management controller via the secure communication channel.

[0082] The agent service module executes the read command to obtain the raw asset information, including but not limited to asset information or health data, and encapsulates it into a response frame according to the TLV format. This frame is then encrypted using the session key and accompanied by a MAC address, and returned to the BMC via a secure channel. The BMC parses the response frame, extracts the asset information, and stores it in its local database or reports it to the upper-level management platform.

[0083] In one possible implementation of this invention, to address the problem of high response latency and bus resource consumption caused by repeated access to the configuration space, this embodiment adds a smart cache prefetch strategy. Before accessing the configuration space of the corresponding downstream device and reading the original asset information in response to a read command, the following steps are also included: When the corresponding and non-expired original asset information exists in the local cache, the original asset information in the local cache is encapsulated and the encapsulated response information is sent to the baseboard management controller through the secure communication channel. When the corresponding original asset information does not exist in the local cache or the original asset information has expired, the step of accessing the configuration space of the corresponding downstream device and reading the original asset information is executed.

[0084] The local cache refers to the storage area in the proxy service module's memory used to temporarily store recently read results. It adopts the Least Recently Used (LRU) eviction policy and adaptive Time To Live (TTL) management. Not expired means that the time since the cache entry was written is less than its TTL (for example, the TTL of high-frequency static data can be up to 1 hour, while the TTL of dynamic data such as temperature is only 10 seconds).

[0085] Furthermore, the cache employs an adaptive TTL (Time To Live) mechanism: a shorter TTL (e.g., 10 seconds) is set for frequently changing data (such as temperature and link error counts), while a longer TTL (e.g., 1 hour) is set for static data (such as vendor IDs and serial numbers). This strategy further improves the cache hit rate, reduces the number of actual configuration space accesses, and lowers response latency.

[0086] Specifically, the proxy service module retrieves the local cache using the target device's BDF and the set of fields as keys. If a match is found and the current time has not exceeded its TTL, the original asset information in the cache is directly retrieved, encapsulated into a response message in TLV format, encrypted, and sent, without touching the PCIe configuration space. If a match is missed, or if a match is found but the current time has exceeded its TTL, the module accesses the configuration space of the corresponding downstream device to read the original asset information.

[0087] As can be seen, in this embodiment of the invention, after receiving the read command from the BMC, the PCIe switch does not directly access the configuration space of the downstream device every time. Instead, it first checks whether the original asset information of the corresponding device exists in the local cache and whether the information has expired. This avoids the bus transaction overhead caused by repeatedly accessing the PCIe device configuration space and also reduces the response latency of interaction with the downstream device, enabling the BMC to obtain asset information more quickly.

[0088] In one possible implementation of this application embodiment, the method further includes: recording the access history of the baseboard management controller to the asset information of each downstream device; predicting downstream devices that may be frequently accessed in the future based on the access history; pre-reading the asset information of the predicted downstream devices and storing it in a local cache.

[0089] Access history refers to the time-series statistics recorded by the agent service module for each BMC asset query request, categorized by device. The future time period refers to the immediately following short time window, which can be customized, such as the next 10 to 30 minutes. Frequently accessed downstream devices refer to the set of devices predicted to be most likely to initiate queries by BMC based on historical patterns and recent trends.

[0090] Asset information refers to the configuration space data that BMC most frequently retrieves and that is most valuable for asset management when querying PCIe devices. This data is typically stored in the PCIe device's configuration space.

[0091] In PCIe specifications and server management, this type of information is specifically shown in Table 1, which is an example of asset information. Table 1. Example of Asset Information

[0092] The agent service module records the BMC's access history to the asset information of each device, forming time-series data.

[0093] In one feasible approach, lightweight time series prediction algorithms (such as Prophet or a simple LSTM network) can be used to predict future access patterns and identify devices that are likely to be frequently queried in the coming period.

[0094] In another feasible approach, due to the computational and storage limitations of the switch firmware environment, this implementation can also employ deterministic periodic decomposition and weighted scoring models to achieve prediction performance equivalent to Prophet or LSTM, without introducing a large deep learning or statistical inference library. The entire prediction module can be completed in a C language environment, with low memory usage (e.g., controlled within 16KB) and short execution time for a single prediction (e.g., within 30ms).

[0095] The following are the specific implementation steps of this process: Phase 1: Data Acquisition and Preprocessing (Constructing Time Series). The proxy service module maintains a ring buffer to store access events, but does not store the raw time points (to save memory); instead, it stores time bucket statistics.

[0096] First, divide the time into buckets. For example, divide a day (24 hours) into 144 buckets (each bucket is 10 minutes). At the same time, retain data from the past 7 days and the current period.

[0097] Secondly, data structures.

[0098] / / Device access statistics table (one copy for each device)

[0099] struct DeviceStats {

[0100] uint16_t dev_id; / / Device BDF address

[0101] uint8_t day_buckets[7]

[144] ; / / The number of queries per bucket in the past 7 days (uint8_t is sufficient for single-bucket counting)

[0102] uint8_t current_day_buckets

[144] ; / / Cumulative query count for each bucket so far today

[0103] uint16_t last_24h_total; / / Total number of queries in the last 24 hours (used for recent trends)

[0104] };

[0105] Then, after the proxy service processes a BMC asset query request, it obtains the current system time T and calculates the corresponding bucket index (idx=(hour)). (60+minute) / 10) increments the counter for the corresponding bucket in device_stats by 1. Simultaneously, last_24h_total is updated (using a sliding window update).

[0106] Phase Two: Lightweight Periodic Factor Extraction. The system triggers a prediction calculation every 30 minutes. Three independent periodic factors are calculated for each device: ① Daily periodic factor (P_day), reflecting query patterns during specific time periods each day. Calculation method: Take the number of queries for the same bucket index (e.g., 14:50-15:00 each day) over the past 7 days and calculate a weighted average. For the past day d, a weight of (d+1) / 28 is assigned (the more recent the day, the higher the weight). P_day = Σ(weight_d × bucket_count[d][idx]) / Σ(weight_d). If the device has never appeared, this value is 0. Where bucket_count[d][idx] represents the number of queries for index idx on day d. ② Weekly periodic factor (P_week), reflecting query patterns for specific days each week. Calculation method: For example, take the number of queries for the same day of the week and the same time period over the past 4 weeks and calculate a weighted moving average (weight biased towards the most recent week). P_week = 0.6 × value of the same day and time last week + 0.3 × value of the same day and time two weeks ago + 0.1 × value of the same day and time three weeks ago. The above weighting coefficients are examples and can be dynamically adjusted based on the actual hit rate. ③ Recent trend factor (P_recent), reflecting recent sudden changes. Calculation method: Take the cumulative number of queries in the most recent hour (6 buckets), divide it by the expected number of queries for the same period in history (daily cycle prediction value), and obtain the sudden factor. P_recent = (actual access count in the most recent hour) / (P_day (corresponding time period) + 1), where 1 is added to the denominator to prevent division by zero errors. If this value > 1.2, it indicates that the recent access activity is significantly higher than historical patterns.

[0107] Phase 3: Comprehensive Scoring and Top-K Ranking. Scoring Formula: Score = w1 × Normalized(P_day) + w2 × Normalized(P_week) + w3 × Normalized(P_recent). Normalization is a cross-device normalization (Min-Max scaling): the maximum value of this factor across all devices is used as the denominator, for example, P_day_norm = P_day / P_day_max (to avoid bias from individual high-frequency devices, a logarithmic normalization variant is used: log(1+P_day) / log(1+P_day_max)). Weighting: w1 = 0.3, w2 = 0.2, w3 = 0.5 (recent trend has the highest weight, emphasizing real-time performance).

[0108] Sort the output. Sort all devices in descending order of Score, and take the top-K (the value of K can be dynamically adjusted according to the cache capacity, and the typical value is max(5, total number of devices × 10%)) as the prefetch target list.

[0109] Phase 4: Idle Detection and Prefetching Execution. 1. Idle Detection: Monitor the bus status of the side link (e.g., SMBus). If there are no commands sent or received for 200ms consecutively, it is considered an idle window. Simultaneously check the CPU load of the proxy service module (if the current utilization is >50%, prefetching is temporarily suspended to avoid interfering with normal service). 2. Prefetching Strategy: Sequentially access the configuration space of the Top-K devices in the prediction list, reading key asset information such as VPD, temperature, and link status. Use non-blocking PCIe reading (to avoid prolonged bus occupation). If the read times out (>5ms), skip the device. 3. Cache Writing: If the read is successful, store the data in the cache and set different TTLs (TimeToLive) according to the data type: Static data (serial number, vendor ID): TTL=3600 seconds (1 hour); Semi-dynamic data (firmware version): TTL=600 seconds (10 minutes); Dynamic data (temperature, link count): TTL=10 seconds.

[0110] Phase 5: Adaptive Feedback and Optimization. To ensure continuous online prediction accuracy, a lightweight hit rate monitoring system is introduced: Definition of a hit: When the BMC actually queries a device, if the device's data exists in the cache and has not expired, it is counted as a hit. Statistics Window: Overall hit rate is calculated every 24 hours.

[0111] Parameter adjustment rules: If the hit rate is ≥60%, maintain the current parameters. If the hit rate is <40%, trigger parameter adjustment: increase w3 (recent trend weight) by 5 percentage points, and decrease w1 (daily cycle weight) to make the model more sensitive and capture changes in access patterns faster. If all Top-5 predictions in a single period fail, a breadth-first prefetch will be forced in the next period (scanning the basic BDF list of all devices, but not reading detailed VPDs, only supplementing the device list cache).

[0112] In this embodiment of the invention, during system idle periods (e.g., when there is no command transmission or reception on the side link and the CPU load is low), the agent service module actively pre-reads key asset information from the configuration space of the prediction device and stores it in the cache.

[0113] For example, suppose that maintenance personnel regularly inspect all NVMe drives at 10:00 AM every day. After several days of learning, the algorithm will mark these NVMe drives as predicted devices around 9:50 AM each day. In the prefetching strategy, the proxy service module will prioritize reading static information (because the cache time is long, TTL can reach 1 hour), while also taking into account dynamic information (such as temperature, but this type of data has a very short TTL of only 10 seconds and needs to be refreshed frequently).

[0114] In this embodiment of the invention, prefetching is used for caching, which reduces response time. Furthermore, the sidelink (SMBus / I2C) bandwidth between the BMC and the switch is extremely low (typically only 100kHz~1MHz). If the BMC performs real-time reading for every query, it will severely consume this low-speed bus. Prefetching shifts the data preparation process to idle periods (when there are no command transmissions or receptions on the sidelink and the CPU load is low), effectively switching high-load PCIe read operations to off-peak periods, thus smoothing out peaks and valleys and preventing sidelink congestion during sudden, intensive BMC queries. Moreover, directly accessing the PCIe configuration space involves hardware register operations, which consume CPU resources. Prefetching during system idle periods converts data into memory data, so subsequent BMC queries only require simple memory copying, reducing the pressure on real-time interrupt handling and improving the overall stability of the embedded system.

[0115] In one possible implementation of this application embodiment, in order to solve the problems of fixed command frame format, poor scalability, and lack of secure parsing, this embodiment of the invention receives a read command sent by the baseboard management controller via a secure communication channel, including: receiving a TLV format command frame sent by the baseboard management controller via a secure communication channel, wherein the command frame includes a frame header, session identifier, sequence number, TLV block sequence, and message authentication code; wherein the TLV block sequence consists of at least one TLV block, and each TLV block includes a type field, a length field, and a value field, the type field being used to define the command type; parsing the command frame to obtain the read command corresponding to the command type.

[0116] In this embodiment of the invention, the BMC constructs a command frame in TLV (Type-Length-Value) format based on management needs (e.g., the need to read complete asset information of a device) and sends it to the agent service module through a secure channel. Figure 5 As shown, the command frame structure includes: Frame header (4 bytes): A fixed synchronization word used to identify the start of the frame, unencrypted. Session ID (2 bytes): Identifies the current secure session, used to distinguish frames from different sessions. Sequence number (2 bytes): Used for pairing requests and responses, and for detecting retransmissions or loss. TLV block sequence: Consists of one or more TLV blocks. The encrypted content includes: Session ID, Sequence number, and TLV block sequence.

[0117] Each TLV block contains: Type (1 byte): Defines the command type, for example, 0x01 represents a batch read command, 0x02 represents a cache read command, 0x03 represents a health status query command, and 0x04 represents a firmware upgrade command. Length (2 bytes): Indicates the length (number of bytes) of the value field. Value (variable length): The specific command parameters, such as the device identifier list, configuration space offset, and read data length. Message Authentication Code (4 bytes): A MAC value calculated for the entire frame (including the frame header, session ID, sequence number, and all TLV blocks), used for integrity verification.

[0118] Command types include: Batch Read Command: Instructs the agent service module to read asset information for multiple specified devices at once, reducing the number of command interactions. Cache Read Command: Instructs the agent service module to return the latest asset information stored in the local cache (if the cache has not expired), avoiding repeated access to the PCIe device configuration space. Health Status Query Command: Queries real-time health parameters of the device, such as temperature, link error count, power consumption, and bandwidth utilization. Firmware Upgrade Command: Carries firmware version information and fragmented upgrade data.

[0119] Furthermore, upon receiving a command frame, the following steps are executed sequentially: Verify the MAC address and discard incomplete or tampered frames. AES-GCM provides both encryption and authentication functions. The MAC verification and decryption process for the receiver (proxy service module) is as follows: Step 1: Separate the frame parts. Upon receiving the complete frame, extract the frame header (plaintext), extract the encrypted parts (session ID, sequence number, ciphertext of TLV block sequence), and extract the additional MAC tag.

[0120] Step 2: Calculate and compare the MAC. The proxy service module uses the session key negotiated with the BMC, and the nonce (obtainable from the frame header or session context, or transmitted by the BMC during transmission) to recalculate the MAC on the received ciphertext and additional authentication data (AAD, typically containing unencrypted fields such as the frame header that require integrity protection). The calculation process is a mathematical function that outputs a fixed-length authentication tag: Calculate MAC = AES - GCM_Authentication(Session Key, Nonce, Ciphertext, AAD). The calculated MAC value is then compared byte-by-byte with the MAC appended to the end of the frame.

[0121] Step 3: If the comparison fails, it indicates that the data integrity has been compromised or the key is incorrect. In this case, the entire frame is immediately discarded, and no decryption operation is performed (to prevent system anomalies or denial-of-service attacks caused by decryption failure). A security event log can be logged if desired. If the comparison succeeds, it indicates that the data has not been tampered with and its source is trustworthy, and the decryption process can proceed.

[0122] Step 4: Decrypt the payload data.

[0123] Using the same session key and nonce, AES-GCM decryption is performed on the ciphertext portion to obtain the original plaintext fields: session ID, sequence number, and TLV block sequence. Only after successful decryption does the subsequent TLV parsing process begin.

[0124] Since AES-GCM is an Authenticated Encryption Algorithm (AEAD), it generates an Authentication Tag (MAC) during encryption. In its implementation, the plaintext input to the encryption operation is the session ID, sequence number, and TLV block sequence, and the output is the corresponding ciphertext and MAC tag. The MAC calculation covers both the ciphertext portion and additional supplementary data such as the frame header (if additional Authentication Data (AAD) is specified in the implementation).

[0125] In one possible implementation of this application embodiment, in order to solve the problem of high interaction frequency and low efficiency in reading asset information of multiple devices one by one, the command type in this embodiment includes a batch read command, which is used to instruct the reading of asset information of multiple downstream devices at one time; in response to the read command, the configuration space of the corresponding downstream device is accessed to read the original asset information; the original asset information is encapsulated into response information, including: sequentially accessing the configuration space of each downstream device indicated by the batch read command to read the original asset information of each device; encapsulating the original asset information of each downstream device read in the same response information and returning it to the baseboard management controller through a secure communication channel.

[0126] The batch read command refers to a command whose type field can be 0x01, and whose value field carries a list of identifiers for multiple target devices, instructing the agent service module to read the asset information of multiple devices at once. Each downstream device refers to the device corresponding to each BDF listed in the command. Specifically, the agent service module retrieves the target device BDF list from the command value field and initiates configuration space access for each device in sequence: reading the original asset information of each device sequentially; temporarily storing the original asset information of each device after reading it; if any device fails to read (returns all 1s) during the process, it is treated as a device access exception (see fault detection embodiment), without affecting the other devices. The original asset information of each downstream device read is encapsulated in the same response information and returned to the baseboard management controller via a secure communication channel.

[0127] Furthermore, it can check if the requested device's asset information already exists in the local cache and has not expired. If a match is found and the information is not expired, a response frame is constructed and the cached data is returned directly; otherwise, the configuration space of the corresponding PCIe device is accessed sequentially, the original data is read, the cache is updated, and then the data is returned.

[0128] In one possible implementation of this invention, if the command type includes a cache read command, then in response to the read command, the configuration space of the corresponding downstream device is accessed to read the original asset information; the original asset information is encapsulated into response information, including: reading the original asset information of each downstream device corresponding to the cache read command from the cache; encapsulating the original asset information of each downstream device read into the same response information, and returning it to the baseboard management controller via a secure communication channel.

[0129] In one possible implementation of this invention, receiving a read command sent by the substrate management controller via a secure communication channel includes: receiving a command sent by the substrate management controller via a secure communication channel; determining whether the command is a read command; if the command is a read command, then executing a response to the read command, accessing the configuration space of the corresponding downstream device, and reading the original asset information; encapsulating the original asset information into response information; and sending the response information to the substrate management controller via the secure communication channel. If the command is a firmware upgrade command, the data of each segment is stored. If the transmission of a segment fails, the baseboard management controller is requested to resume the transmission from the breakpoint of that segment. After all segment data is received, the integrity of the firmware image is verified. If the verification passes, it is written to the backup firmware partition. If the firmware upgrade is abnormal, the previous version of the firmware is retained and the system is restarted from the previous version of the firmware.

[0130] Understandably, when it's necessary to upgrade the functionality of the proxy service module or fix security vulnerabilities, BMC sends a firmware upgrade command through a secure channel. The TLV value field of this command contains: firmware version number, firmware image fragment number, fragment data, and total checksum. These four fields—firmware version number, firmware image fragment number, fragment data, and total checksum—are subfields stored sequentially according to a predetermined format within the Value field of the TLV block Type=0x04 (firmware upgrade command).

[0131] If the command is a health status query command, then collect device health parameters (temperature, link error count, power consumption, bandwidth utilization) and construct a response frame to return.

[0132] In one possible implementation of this invention, in order to solve the problems of only supporting on-demand reading, being unable to actively monitor the operating status of devices, and being difficult to predictive maintain, this invention further includes: actively collecting health parameters of each downstream device according to a preset cycle, the health parameters including temperature, link error count, power consumption, and bandwidth utilization; and actively reporting the collected health parameters to the baseboard management controller via a secure communication channel.

[0133] The proxy service module operates independently of the BMC's queries, proactively collecting health parameters (temperature, link error count, power consumption, bandwidth utilization) of all downstream PCIe devices at preset intervals (e.g., every minute). The collected data is encapsulated into proactive reporting frames and sent to the BMC via a secure channel. Upon receiving the data, the BMC compares it with preset thresholds and incorporates trend analysis algorithms (e.g., determining if three consecutive temperature increases exceed a warning threshold). If a fault risk is identified, a warning event and maintenance recommendations (e.g., suggesting cleaning device dust or checking PCIe link connections) are generated, and the system administrator is notified. The preset thresholds can be customized by the user; this embodiment of the invention does not limit their specific settings.

[0134] Specifically, the collected data can also be preprocessed.

[0135] Sensor data (especially temperature) is susceptible to transient noise (such as airflow fluctuations), and directly using instantaneous values ​​can lead to false alarms. Therefore, the algorithm first preprocesses the raw data: it takes the arithmetic mean of the raw temperature values ​​from the most recent 3 to 5 sampling periods to obtain a smoothing value T_smooth, eliminating high-frequency spike interference. If the change in the current sampled value relative to the previous sampled value exceeds the physical limit (e.g., a change of more than 5°C per second), it is determined to be an abnormal sensor pulse, and the predicted value is used instead (estimated by the previous value and the historical average rate of change).

[0136] In one possible implementation of the present invention, the BMC can also use continuous counting with threshold combined with slope double verification to avoid misjudgment due to small fluctuations. Taking temperature as an example, see Table 2. Taking the idle state as an example, if the current temperature is ≤ the warning lower limit (e.g., 70℃), the idle state is maintained and the up counter up_count=0 is reset.

[0137] Table 2. State, Condition, and Action Mapping Table

[0138] It is understandable that the parameters reported for health status are not limited to temperature. Therefore, the early warning logic requires the fusion of multi-dimensional features, as detailed in Table 3.

[0139] Table 3. Example of mapping health parameters, early warning conditions, and maintenance recommendations.

[0140] Then, when the BMC receives the proactively reported health data, it executes a three-level judgment logic, as shown in Table 4.

[0141] Table 4 Mapping Table of Levels, Conditions, and Actions

[0142] Furthermore, maintenance suggestions can be generated.

[0143] Generated dynamically through a rules engine: IF (Temperature_Slope>0.5℃ / min AND Fan Speed==100% AND Ambient Temperature<30℃)THEN; Recommendation: If the fan performance is degraded or the airflow is blocked, it is recommended to check the fan and heatsink for dust. ELSEIF(Link Error Count - Rate of Change > 5 times / minute) THEN; Recommendation: The PCIe link is unstable. We suggest checking the connector or replacing the cable. ELSEIF(Power consumption change rate > 20% AND CPU / GPU utilization change rate < 5%) THEN; Recommendation: There is abnormal power consumption leakage; it is recommended to check the power supply module immediately. ELSEIF(Temperature_Number of consecutive increases == 3 AND Current temperature < Danger threshold) THEN; Recommendation: If the equipment temperature continues to rise, it is recommended to schedule an inspection of the cooling system in advance. ELSE; Recommendation: The device has potential risks; it is recommended to review the detailed logs. Finally, alerts and suggestions can be sent via email / SMS / SNMPTrap / Redfish events.

[0144] In one possible implementation of this invention, the proxy service module continuously monitors the communication status of the sidelink: for each sent command, a timeout timer is started. If no response is received within the timeout period, a retry is performed (up to 3 retries). If the retry still fails, an attempt is made to re-establish the secure channel. If the secure channel is successfully re-established, subsequent commands are processed; if multiple reconnection attempts fail, a fault log is recorded, and a permanent sidelink communication fault is reported to the BMC via out-of-band (e.g., System Event Log SEL) for administrator troubleshooting. For PCIe device access errors, such as a configuration space read returning all 1s indicating that the device does not exist or has been removed, the proxy service module also performs a retry, up to 3 times. If it still fails, a device access anomaly is reported to the BMC, which can then mark the device as offline.

[0145] In one possible implementation of this invention, the method further includes: receiving a firmware upgrade command sent by a baseboard management controller via a secure communication channel, wherein the firmware upgrade command includes firmware version, fragment number, fragment data, and verification information; The data of each segment is stored. When the transmission of a segment fails, the system requests the baseboard management controller to resume transmission from the breakpoint of that segment. After all fragmented data is received, the firmware image is verified for integrity. If the verification passes, it is written to the backup firmware partition so that the firmware can be automatically booted from the backup partition on the next reboot.

[0146] See Figure 6 , Figure 6 This is a flowchart of the remote firmware upgrade process provided by the proxy service embodiment of the present invention. The proxy service module receives each fragment, stores it temporarily, and replies with confirmation. Firmware images are typically large, ranging from several MB to tens of MB, while the single-frame data carrying capacity of the side link between the BMC and the switch (such as I2C / SMBus) is extremely limited, usually with an effective payload of only 32-64 bytes. Therefore, fragmentation is performed. If a fragment transmission fails, the BMC can resume transmission from that fragment. After all fragments are received, the proxy service module performs an integrity check on the entire firmware image. If the check passes, it writes the image to the switch's backup firmware partition. After writing, the proxy service module sends an upgrade success confirmation. The switch automatically boots the new firmware from the backup partition upon the next reboot. During the upgrade process, the proxy service module still responds to basic query commands, such as health status queries, ensuring uninterrupted management services. If an anomaly is detected after the upgrade, the BMC can send a rollback command, and the switch boots from the retained previous firmware version.

[0147] In one possible implementation of this invention, scanning downstream devices of a high-speed serial computer extended bus standard switch to obtain basic information about the downstream devices includes: before scanning, obtaining the current bus topology of the high-speed serial computer extended bus standard switch, which may be the structure detected last time; identifying the link level and port bandwidth of each downstream device based on the bus topology; configuring different scan timeout times and retry counts for different device types based on the device type of the downstream devices, with the configuration rules set according to the importance of the downstream devices; then, for downstream devices whose link level is deeper than a preset level threshold or whose port bandwidth is lower than a preset bandwidth threshold, adopting a scanning strategy of extending the scan timeout time and increasing the number of retry counts; after scanning is completed, using the device identifier and device type in the scan results as basic information.

[0148] In one possible implementation of this invention, the method further includes: recording the actual hit rate of each pre-read operation, wherein the actual hit rate is the ratio of the number of times the pre-read asset information cached locally is actually read by the baseboard management controller to the total number of pre-read operations; if the actual hit rate is lower than a preset hit rate threshold for N consecutive times, adjusting the prediction window length or prediction weight parameter in the prediction algorithm for predicting downstream devices that will be frequently accessed in the future based on access history; applying the adjusted prediction algorithm to subsequent pre-read operations, and continuing to monitor the adjusted actual hit rate until the hit rate recovers to above the preset hit rate threshold; wherein N is a preset positive integer.

[0149] Based on any of the above embodiments, see Figure 7 , Figure 7 This is a specific asset information acquisition process provided by an embodiment of the present invention, including: Establish secure communication channels; dynamically discover and register devices; send TLV command frames from the BMC; perform access / caching through the agent service; return responses and have the BMC parse them; periodically report and warn about health status; proactively report hot-plug events; detect and automatically recover from faults; and remotely upgrade firmware.

[0150] Based on any of the above embodiments, the solution of this invention includes bidirectional authentication between the BMC and the switch via sidelink digital certificate exchange, negotiation of session keys based on ECDH, and subsequent encryption of all command and response frames using AES-GCM with an attached MAC address. The proxy service module actively scans and reports all downstream devices upon startup; it also actively reports events in real time during hot-plugging, replacing passive polling. It adopts a type-length-value format, supporting flexible expansion of command types without modifying the frame structure; the frame header contains a session ID and sequence number, supporting request-response matching and retransmission detection. The proxy service module supports reading asset information from multiple devices with a single command; it maintains a local cache (LRU, adaptive TTL) to reduce repeated access to PCIe configuration space. The proxy service module periodically collects health parameters such as device temperature, link error count, and power consumption, and actively reports them to the BMC. The BMC combines threshold and trend analysis for fault warnings. Mechanisms such as command timeout retries, automatic sidelink reconnection, and PCIe device access retries are included to improve system robustness. It supports fragmented transmission, breakpoint resumption, integrity verification, backup partition writing, and version rollback, ensuring uninterrupted service during upgrades. It achieves the following: dynamic device discovery and batch reading significantly reduce communication overhead and improve asset information acquisition speed; two-way authentication, session keys, and message authentication codes ensure secure communication links, preventing data leakage and tampering; proactive reporting of hot-plug events and periodic collection of health status enable real-time synchronization of asset information and fault early warning; TLV format command frames support future additions of command types without modifying the frame structure; fault detection and automatic recovery mechanisms enhance system robustness and reduce manual intervention; and the proxy service firmware remote upgrade function facilitates feature iteration and vulnerability patching.

[0151] In one possible implementation of this application embodiment, the present invention also provides an asset information acquisition method applied to a baseboard management controller, see [link to relevant documentation]. Figure 8 ,include: S401: Receives device registration frames sent by a high-speed serial computer extended bus standard switch via a secure communication channel.

[0152] The device registration frame includes basic information about the downstream devices of the high-speed serial computer extended bus standard switch; the basic information includes at least the device identifier and device type.

[0153] S402. Update the local device list of the baseboard management controller based on the device registration frame.

[0154] S403: Receive insertion / removal event reporting information from a high-speed serial computer extended bus standard switch via a secure communication channel. The insertion / removal event reporting information is used to indicate that a downstream device has been inserted or removed.

[0155] S404. Update the device list based on the plug-in / plug-out event reporting information.

[0156] In one possible implementation of this application embodiment, it further includes: Construct a command frame in TLV format. The command frame includes a frame header, session identifier, sequence number, TLV block sequence, and message authentication code. The TLV block sequence consists of at least one TLV block. Each TLV block includes a type field, a length field, and a value field. The type field is used to define the command type. Command frames are sent to the high-speed serial computer extended bus standard switch via a secure communication channel. The command frames are used to instruct the high-speed serial computer extended bus standard switch to read the asset information of downstream devices.

[0157] It is understood that the asset information acquisition method applied to the baseboard management controller in this embodiment of the invention can be referred to in conjunction with the asset information acquisition method described above, and will not be elaborated further in this embodiment of the invention.

[0158] Furthermore, the solutions of this invention embodiment—dynamic service discovery, enhanced secure communication, TLV extended protocol, proactive health monitoring, and remote firmware upgrade—are not only applicable to BMC obtaining downstream device asset information through PCIe switches, but can also be extended to the following areas: Hard drive management in storage networks: A similar proxy service module is embedded in SAS / SATA expanders or NVMe switches, communicating with the storage controller (e.g., RAID card, HBA card) via a side link. The proxy service module proactively discovers connected hard drives, reports their asset information (model, serial number, capacity), and periodically collects SMART health data (temperature, relocation sector count, power-on time). The storage controller can then use this data to predict hard drive failures and proactively replace them.

[0159] Network device asset management: Secure channels are established between network devices such as Ethernet switches, routers, and firewalls and the management system via console ports, USB ports, or out-of-band management ports. The agent service in the device firmware proactively discovers replaceable units (power modules, fan modules, line cards), reports serial numbers and firmware versions, and monitors their health status (temperature, voltage, fan speed). The management system enables automatic discovery and lifecycle management of all hardware assets across the network.

[0160] Figure 9 A structural diagram of an electronic device provided in an embodiment of the present invention, such as... Figure 9 As shown, the electronic device includes: a memory 60 for storing a computer program; and a processor 61 for executing the computer program to implement the steps of the method as described in the above embodiments.

[0161] Electronic devices can be devices with BMC or switches.

[0162] The processor 61 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 61 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 61 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 61 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0163] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 60 is used to store at least the following computer program 601, which, after being loaded and executed by the processor 61, is capable of implementing the relevant steps of the method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, etc., and the storage method may be temporary storage or permanent storage. The operating system 602 may include Windows, Unix, Linux, etc.

[0164] In some embodiments, the electronic device may further include a display screen 62, an input / output interface 63, a communication interface 64, a power supply 65, and a communication bus 66.

[0165] Those skilled in the art will understand that Figure 9 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0166] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, magnetic disks, or optical disks, and other media capable of storing program code.

[0167] Based on this, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method described above.

[0168] Based on this, embodiments of the present invention also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the above-described method.

[0169] The foregoing has provided a detailed description of an asset information acquisition method, apparatus, medium, and product provided by embodiments of the present invention. The various embodiments are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0170] 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 implementations should not be considered beyond the scope of this invention.

[0171] The foregoing has provided a detailed description of the asset information acquisition method, device, medium, and product provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this invention. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of this invention.

Claims

1. A method for obtaining asset information, characterized in that, Applications include standard switches for high-speed serial computer expansion buses, including: Scan the downstream devices of the high-speed serial computer extended bus standard switch to obtain basic information of the downstream devices, including at least device identifier and device type; A device registration frame is constructed and sent to the baseboard management controller via a secure communication channel, so that the baseboard management controller updates its local device list based on the device registration frame; wherein, the device registration frame includes basic information of the downstream device; the high-speed serial computer extended bus standard switch is connected to the baseboard management controller through a secure communication channel, and the information transmitted through the secure communication channel is encrypted based on a session key; The system detects whether the downstream device has been inserted or removed. When insertion or removal occurs, the system sends insertion / removal event reporting information to the baseboard management controller via the secure communication channel, so that the baseboard management controller updates the device list based on the insertion / removal event reporting information.

2. The asset information acquisition method according to claim 1, characterized in that, Also includes: Receive the read command sent by the baseboard management controller via the secure communication channel; In response to the read command, the configuration space of the corresponding downstream device is accessed to read the original asset information; the original asset information is then encapsulated into response information. The response information is sent to the baseboard management controller via the secure communication channel.

3. The asset information acquisition method according to claim 2, characterized in that, In response to the read command, before accessing the configuration space of the corresponding downstream device and reading the original asset information, the process further includes: When the corresponding and non-expired original asset information exists in the local cache, the original asset information in the local cache is encapsulated and the encapsulated response information is sent to the baseboard management controller through the secure communication channel. When the corresponding original asset information does not exist in the local cache or when there is expired original asset information, the step of accessing the configuration space of the corresponding downstream device and reading the original asset information is executed.

4. The asset information acquisition method according to claim 3, characterized in that, Also includes: Record the access history of the baseboard management controller to the asset information of each of the downstream devices; Based on the access history, predict the downstream devices that will be frequently accessed in the future; The predicted asset information of the downstream devices is pre-read and stored in the local cache.

5. The asset information acquisition method according to claim 2, characterized in that, Receiving a read command sent by the baseboard management controller via the secure communication channel includes: The system receives a TLV format command frame sent by the baseboard management controller via the secure communication channel. The command frame includes a frame header, session identifier, sequence number, TLV block sequence, and message authentication code. The TLV block sequence consists of at least one TLV block, and each TLV block includes a type field, a length field, and a value field. The type field is used to define the command type. Parse the command frame to obtain the read command corresponding to the command type.

6. The asset information acquisition method according to claim 5, characterized in that, The command type includes a batch read command, which is used to instruct the reading of asset information of multiple downstream devices at one time; In response to the read command, access the configuration space of the corresponding downstream device and read the original asset information; The original asset information is encapsulated into response information, including: The configuration space of each downstream device indicated by the batch read command is accessed sequentially to read the original asset information of each device; The original asset information of each downstream device read is encapsulated in the same response information and returned to the baseboard management controller via the secure communication channel.

7. The asset information acquisition method according to claim 1, characterized in that, Before scanning the downstream devices of the high-speed serial computer expansion bus standard switch, the method further includes: Receive the first handshake message sent by the baseboard management controller, which carries the digital certificate of the baseboard management controller; Verify the validity of the digital certificate of the baseboard management controller for the first handshake message; After successful verification, a second handshake message carrying the digital certificate of the switch is sent to the baseboard management controller, so that the baseboard management controller can verify the legality of the digital certificate of the switch in the second handshake message, and generate a session key after successful verification; the session key is used to encrypt information transmitted through the secure communication channel. The session key is used to interact with the baseboard management controller to confirm the message, thereby establishing a secure communication channel with the baseboard management controller.

8. The asset information acquisition method according to claim 7, characterized in that, Verifying the validity of the digital certificate of the baseboard management controller for the first handshake message includes: Verify the digital signature, validity period, and certificate chain of the digital certificate of the baseboard management controller for the first handshake message.

9. The asset information acquisition method according to claim 1, characterized in that, Also includes: Health parameters of each downstream device are actively collected according to a preset cycle. The health parameters include temperature, link error count, power consumption, and bandwidth utilization. The collected health parameters are actively reported to the baseboard management controller via the secure communication channel.

10. The asset information acquisition method according to claim 5, characterized in that, Also includes: The system receives a firmware upgrade command sent by the baseboard management controller via the secure communication channel. The firmware upgrade command includes firmware version, fragment number, fragment data, and verification information. The data of each segment is stored. When the transmission of a segment fails, the baseboard management controller is requested to resume transmission from the breakpoint of that segment. After all the fragmented data has been received, the firmware image is verified for integrity. If the verification is successful, it is written to the backup firmware partition so that the firmware can be automatically started from the backup partition on the next reboot.

11. A method for obtaining asset information, characterized in that, Applications to baseboard management controllers include: The device registration frame sent by the high-speed serial computer extended bus standard switch is received via a secure communication channel. The device registration frame includes basic information of the downstream devices of the high-speed serial computer extended bus standard switch. The basic information includes at least the device identifier and the device type. The device list on the baseboard management controller is updated based on the device registration frame. The system receives insertion / removal event reporting information from the high-speed serial computer extended bus standard switch via the secure communication channel. The insertion / removal event reporting information is used to indicate that the downstream device has been inserted or removed. The device list is updated based on the reported plug-in / plug-out events.

12. The asset information acquisition method according to claim 11, characterized in that, Also includes: Construct a command frame in TLV format, the command frame including a frame header, session identifier, sequence number, TLV block sequence and message authentication code; wherein, the TLV block sequence consists of at least one TLV block, each TLV block including a type field, a length field and a value field, the type field being used to define the command type; The command frame is sent to the high-speed serial computer extended bus standard switch via the secure communication channel. The command frame is used to instruct the high-speed serial computer extended bus standard switch to read the asset information of the downstream device.

13. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the asset information acquisition method as described in any one of claims 1 to 12 when running the computer program.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one piece of program code, which is loaded and executed by a processor to implement the asset information acquisition method as described in any one of claims 1 to 12.

15. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the asset information acquisition method as described in any one of claims 1 to 12.

Images