Method and controller for acquiring hardware asset information

Abstract

The application discloses a method and a controller for obtaining hardware asset information, and relates to the technical field of hardware management, and comprises the following steps: after a target device is powered on, position information of a target board card is acquired first, then target coding address information corresponding to the target board card is determined in total address configuration information according to the position information of the target board card. Further, coding information is read from a target component of the target board card according to the target coding address information, the target component being a component selected from native components of the target board card according to a board card type of the target board card. Finally, target hardware asset information of the target board card is downloaded from a target storage location outside the target device according to the coding information. The target hardware asset information is stored in a manager of the target device. In this way, the coding information can be stored in the target component of the target device, without the need of setting a special memory on the board card to store the coding information, so that the hardware cost is greatly reduced.

Description

Technical Field

[0001] This application relates to the field of hardware management technology, and in particular to methods and controllers for acquiring hardware asset information. Background Technology

[0002] In the field of hardware management technology, hardware asset information is the core foundational data for hardware operation and maintenance, asset control, fault location, and equipment traceability. Current common technical solutions require each board in the device to be independently configured with dedicated memory to store hardware asset information. However, this approach results in high hardware costs. Summary of the Invention

[0003] This application provides methods, apparatus, controllers, storage media, and program products for acquiring hardware asset information, in order to address the problem of high hardware costs in related technologies.

[0004] This application provides a method for obtaining hardware asset information, including: After the target device is powered on, the location information of the target board is obtained. The target board is any one of the multiple boards included in the target device, excluding the motherboard. Based on the location information of the target board, determine the target encoding address information corresponding to the target board from the pre-configured total address configuration information; Based on the target encoding address information, the encoding information is read from the target component of the target board, where the target component is the component selected from the native components of the target board according to the board type of the target board; Based on the encoding information, download the target hardware asset information of the target board from the target storage location outside the target device; The target hardware asset information is stored in the target device's manager, which allows the manager to manage the target board based on the target hardware asset information.

[0005] This application also provides an apparatus for acquiring hardware asset information, including: The acquisition module is used to acquire the location information of the target board after the target device is powered on. The target board is any board other than the motherboard among the multiple boards included in the target device. The determination module is used to determine the target encoding address information corresponding to the target board from the pre-configured total address configuration information based on the location information of the target board. The reading module is used to read encoding information from the target component of the target board according to the target encoding address information, wherein the target component is the component selected from the native components of the target board according to the board type of the target board; The download module is used to download the target hardware asset information of the target board from the target storage location outside the target device, based on the encoding information. The storage module is used to store the target hardware asset information in the target device's manager, so that the manager can manage the target board based on the target hardware asset information.

[0006] This application also provides a controller, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described methods for acquiring hardware asset information.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described methods for obtaining hardware asset information.

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

[0009] This application allows for the following mechanism: After the target device is powered on, the location information of the target board can be obtained first. Then, based on the location information, the target encoding address information corresponding to the target board can be determined from the pre-configured total address configuration information. Furthermore, encoding information can be read from the target component of the target board based on the target encoding address information. The target component is selected from the native components of the target board according to its type. Finally, the target hardware asset information of the target board can be downloaded from a target storage location outside the target device based on the encoding information. This target hardware asset information is stored in the target device's manager, allowing the manager to manage the target board based on this information. In this way, encoding information can be stored in the target component of the target device, and different boards use target components corresponding to their types to store encoding information, eliminating the need for dedicated memory on the board to store encoding information and significantly reducing hardware costs. Attached Figure Description

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

[0011] Figure 1 This application provides a schematic diagram of the architecture of a target device. Figure 2 A flowchart illustrating a method for obtaining hardware asset information provided in an embodiment of this application; Figure 3This is a schematic diagram of the architecture of another target device provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating another process for obtaining hardware asset information provided in an embodiment of this application; Figure 5 A schematic diagram of the structure of a device for acquiring hardware asset information provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a controller provided in an embodiment of this application. Detailed Implementation

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

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

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

[0015] The method for obtaining hardware asset information provided in this application can be applied to a target device, which may be a server or other device with installed boards. For example... Figure 1 As shown, the target device may include at least one board. For example, at least one board may include one or more of a motherboard, hard drive backplane, power supply backplane, fan board, adapter card (e.g., RISE card), and other simple boards that implement different functions.

[0016] In the field of hardware management technology, hardware asset information is the core foundational data for hardware operation and maintenance, asset control, fault location, and equipment traceability. Hardware asset information is generally referred to as Field Replaceable Unit (FRU) information. In current common technical solutions, each board in the equipment needs to be independently configured with dedicated memory to store hardware asset information. However, this approach has the following problems: First, hardware costs increase and material redundancy is high. A server consists of a large number of boards, with a typical rack server having several to a dozen boards, while high-end, high-density servers and blade servers can have dozens or more. If each board is soldered with a separate electrically erasable programmable read-only memory (E2PROM) to store FRU information, along with corresponding peripheral circuits, soldering processes, and material warehousing management, the overall hardware material cost and manufacturing cost of the server increase.

[0017] Secondly, E2PROM is only used to store fixed FRU information, has a single function, and occupies board space. Currently, server boards are becoming smaller and have more and more layers. Adding E2PROM to store FRU information occupies the limited printed circuit board (PCB) area, reducing the PCB area used by other components, which indirectly increases the design difficulty of the board and increases the cost.

[0018] Third, the production process is cumbersome and inefficient. In the traditional solution, each board needs to complete the FRU information burning, verification and filing process separately during the production stage. The FRU information needs to be burned at least twice: once offline before power-on, burning a part of the information, and then the production line burns another part of the information.

[0019] To address the aforementioned technical problems, embodiments of this application provide a method for acquiring hardware asset information, which can be executed by a manager. The manager can be a Baseboard Management Controller (BMC), located in the aforementioned motherboard, such as... Figure 2 As shown, the specific processing steps for obtaining hardware asset information may include: Step S201: After the target device is powered on, obtain the location information of the target board.

[0020] The target board can be any board other than the motherboard among the multiple boards included in the target device.

[0021] Specifically, after each power-on, the manager can scan each board in the target device. For each board scanned, it can obtain the board's location information and the location information of its components. The board's location information can be its slot within the target device, and the component's location information can be its bus address, a factory-fixed address such as a Serial Peripheral Interface (SPI) address or an I2C address. The target board is any board scanned during each scan.

[0022] For the motherboard in the target device, the manager can directly obtain the coded address information of the target component of the motherboard without needing to obtain the location information of the target board. Based on the coded address information, the hardware asset information of the motherboard can be read from the target component.

[0023] In some alternative implementations, the target board can also be a new board or a replacement board. Accordingly, after the manager detects that the status of the target slot's presence signal changes from absent to present, it determines the location information of the target slot as the location information of the target board.

[0024] The target slot can be any one of the at least one slots included in the target device, and the target board is the board inserted into the target slot.

[0025] Specifically, during the operation of the target device, new or replaced boards may be added or replaced. No processing is needed after removing boards, but after adding or replacing boards, hardware asset information can be updated in real time to ensure timely availability to other devices. Since the presence signal status of the corresponding slot changes from absent to present after a board is added or replaced, the manager can update hardware asset information by monitoring the presence status of each slot. Taking the target slot as an example, after detecting that the presence signal status of the target slot changes from absent to present, the target board inserted into the target slot is considered a new or replaced board. At this point, the location information of the target slot can be directly determined as the location information of the target board.

[0026] Similarly, the target device can scan the target board to obtain the identification information and location information of each component included in the target board.

[0027] In this way, by monitoring the status changes of the presence signal, the manager can immediately trigger the subsequent encoding information reading and hardware asset information download process after the board is inserted, without waiting for the next full scan or manual triggering, and can obtain the latest hardware asset information in a timely manner.

[0028] Step S202: Based on the location information of the target board, determine the target encoding address information corresponding to the target board in the pre-configured total address configuration information.

[0029] Specifically, for each slot, the encoding address information of the target component where the board code resides can be pre-specified. This encoding address information can include the bus address of the target component, the offset address of the board code in the target component's memory, data length, and other information. For example, for slot A, multiple types of boards can be inserted. Different types of boards target different components, but the encoding address information of the target components in different types of boards can be specified to be the same, that is, the bus address, offset address, data length, etc., are all the same. The manager can pre-store the overall address configuration information, which can store the encoding address information corresponding to each slot. Accordingly, after obtaining the location information of the target board, the corresponding target encoding address information can be determined from the overall address configuration information based on the location information of the target board. In this way, by pre-specifying the encoding address information of the target component, the address of the target component only needs to be fixed when designing the board, which is relatively simple.

[0030] In some alternative implementations, step S202 may also take the following specific steps: Step 1: Obtain the board type of the target board.

[0031] Step 2: Based on the target board's board type and location information, determine the target encoding address information corresponding to the target board in the total address configuration information.

[0032] Specifically, hardware asset information is typically obtained through serial peripheral interface buses or I2C buses. For some boards that support Peripheral Component Interconnect Express (PCIe), the type of components on the board can be identified through the PCIe link. Furthermore, the corresponding board type can be determined based on the component type. For example, if the component type is a hard drive, the board type can be considered a hard drive board.

[0033] For any given slot, different types of boards may be connected, and the encoding address information of different types of boards may be different. Therefore, for the target board, the manager can jointly determine the target encoding address information of the target board based on the board type and location information of the target board.

[0034] In this way, since there are general slots in actual servers (for example, PCIe x16 slots can accommodate accelerator cards such as graphical processors, network cards, and Redundant Array of Independent Disks (RAID), this solution introduces the card type dimension, eliminating the need to bind a specific type of card to each slot, thus providing greater flexibility. Furthermore, through dual indexing, the accuracy of the encoded address information can be ensured.

[0035] In some alternative implementations, step two above may include: Step 1: Based on the location information of the target board, determine the target address configuration information corresponding to the target board in the total address configuration information.

[0036] The target address configuration information includes coded address information corresponding to at least one type of board.

[0037] Step 2: Based on the target board type, determine the target encoding address information corresponding to the target board type in the target address configuration information.

[0038] Specifically, for each slot, the manager is configured with the coded address information corresponding to at least one type of board that can be connected to that slot. The manager can determine the target address configuration information of the target board from the overall address configuration information based on the location information of the target board, and then determine the target coded address information corresponding to the board type of the target board from the target address configuration information based on the board type of the target board.

[0039] Step S203: Read the encoding information from the target component of the target board according to the target encoding address information.

[0040] The target component is selected from the native components of the target board based on its board type. For example, the board type can be any of type 1, type 2, type 3, etc. Type 1 can indicate that the board does not include native components with unique hardware identification information, but includes native components with programming capabilities. Type 2 can indicate that the board includes native components with unique hardware identification information. Type 3 can indicate that the board does not include native components with unique hardware identification information, and does not include native components with programming capabilities. Having programming capabilities means that the component's memory supports programming data other than its own business functions.

[0041] When the board type is Type 1, the encoding information is the board code pre-programmed into the target component. The target component is any native component in the target board that has programming capabilities. When the native component of the target board includes a logic controller, the logic controller is the target component, and the target storage area of ​​the logic controller's memory has the board code pre-programmed.

[0042] When the board type is Type 2, the encoded information is the unique hardware identifier information of the target component. The target component is any native component in the target board that has unique hardware identifier information.

[0043] When the board type is type 3, the target component is an additional encrypted component added to the target board, and the encoded information is a unique hardware identifier within the encrypted component. Alternatively, regardless of the board type, an encrypted component can be added to the board.

[0044] Specifically, for the first type, since the components of the board itself do not have unique hardware identification information, the board code can be pre-programmed using the existing memory of its components. The board code data is small, requiring only minimal storage space. For example, most logic controllers allow flexible programming; therefore, a designated storage location in the logic controller's memory can be pre-programmed with the board code. This eliminates the need for additional memory in such boards to store FRU information, saving hardware costs, reducing the size of the target device, and simplifying the programming process for the logic controller. This storage location can employ a read / write permission locking mechanism, prohibiting data writing after the initial board code is written, allowing only read operations. For example, motherboards, adapter cards, and power supply backplanes commonly incorporate Complex Programmable Logic Devices (CPLDs). CPLDs do not have a factory-defined unique code, but they support firmware programming and partitioned storage.

[0045] For the second type, since the components of the board itself have unique hardware identification information, possessing inherent uniqueness, immutability, and lifelong immutability, the coding of these components can be reused to obtain hardware asset information. This eliminates the need for additional storage resources, secondary processing and programming during production, resulting in extremely high adaptability and zero cost. Examples include hard drive backplanes, microcontroller units (MCUs) mounted on fan boards, and temperature sensors.

[0046] For the third type, some boards do not include native components that can be programmed with board code, nor do they include native components with unique hardware identification information. Therefore, components with unique hardware identification information can be added to them, for example, encrypted components can be used.

[0047] Because the encryption component comes with a unique identifier (UID) at the factory, it can serve as a unique identification code for the board, enabling board identification. On the other hand, the encryption component can achieve hardware encryption, overall anti-tampering, and anti-replacement functions, combining the dual functions of identification and hardware security protection. Compared to traditional E2PROMs that only have storage functions, it offers richer functionality and higher cost-effectiveness. Furthermore, the encryption chip is compact, adaptable to compact board layouts, addressing the industry shortcoming of small boards being unable to deploy E2PROMs, and achieving full board type coverage.

[0048] Based on the pre-set encoding information, the manager can read the encoding information from the target component of the target board according to the target encoding address information. For example, the target component can be identified on the target board based on the bus address of the target component in the target encoding address information, and data of the same length as the target component can be read from the memory of the target component as encoding information based on the offset address and data length.

[0049] During the process of reading the encoded information, for the first type, the pre-programmed board code can be read from the CPLD via the SPI bus, and for the second type, its unique hardware identification information can be read from the temperature sensor of the board via the I2C bus.

[0050] Step S204: Download the target hardware asset information of the target board from the target storage location outside the target device according to the encoding information.

[0051] The encoding information can be used to indicate the unique identifier of the target board. The encoding information can be the board code or unique hardware identification information mentioned above. Alternatively, the encoding information can include an initial code and a first checksum, where the initial code can be the board code or unique hardware identification information mentioned above.

[0052] The target storage location can be any of the following: a cloud platform, a mobile storage device, etc. For example, a cloud platform can store a database containing multiple data entries. Each data entry uses a unique board code as its primary key, linking complete hardware asset information. This hardware asset information can include a full range of hardware information such as manufacturer information, board model, hardware version number, production serial number, production date, compatible server model, hardware parameters, power consumption parameters, quality inspection number, warranty period, replacement and compatibility models, and even more flexible associated information, such as sales region.

[0053] Specifically, taking a cloud platform as an example, the manager can directly identify the read encoding information as the target board's board code. Then, the manager can generate a query command based on the target board's board code and send it to the cloud platform. The cloud platform, based on the target board's board code in the query command, finds the target hardware asset information corresponding to the target board's board code in its database and sends it to the manager. In this way, the manager can download the target hardware asset information from the cloud platform.

[0054] Alternatively, after obtaining the encoding information corresponding to all boards in the target device as described above, the manager can generate a query command based on the encoding information of each board and send it to the cloud platform. The cloud platform, based on the encoding information of each board in the query command, retrieves the hardware asset information of each board from the database and sends it to the manager. In this way, the manager can download the hardware asset information of all boards from the cloud platform.

[0055] In some optional implementations, to ensure the accuracy of the board encoding, the accuracy of the encoding information can be verified first after obtaining it, for example, by using Cyclic Redundancy Check (CRC) for verification, and then the hardware asset information can be obtained. Accordingly, step S204 may include: Step 1: Extract the initial code from the first position of the encoded information, and extract the first check code from the second position of the encoded information.

[0056] Step two: Verify the encoded information to obtain the second verification code.

[0057] Step 3: If the first and second verification codes are consistent, download the target hardware asset information from the target storage location according to the initial encoding.

[0058] Specifically, the manager can first extract the initial code from the first position, extract the first check code from the second position, and then perform a check operation on the initial code to obtain the second check code.

[0059] If the first and second check codes match, a query command can be generated based on the initial code and sent to the cloud platform. The cloud platform then uses the initial code in the query command to find the target hardware asset information corresponding to the initial code of the target board in the database and sends it to the manager.

[0060] If the first check code and the second check code do not match, an error message can be generated based on the location information of the target board where the target component is located, so as to prompt the technicians to check.

[0061] Thus, encoded information may be corrupted during storage or transmission. Through a verification mechanism, the manager can detect data anomalies before using the encoded information, avoiding the retrieval of incorrect hardware asset information based on erroneous encoding. Additionally, board encoding may be written incorrectly during factory programming due to manufacturing processes; the verification mechanism can detect such problems during the first read, allowing for timely correction.

[0062] Step S205: Store the target hardware asset information in the target device's manager.

[0063] Specifically, the manager can store the target hardware asset information in its own memory, which facilitates subsequent management operations on the target board based on the target hardware asset information, such as providing it to other devices.

[0064] In some alternative implementations, the manager may cache the encoding information and target hardware asset information in the manager itself, and / or persist the encoding information and target hardware asset information in the manager's local database.

[0065] Specifically, when the encoding information is a board code or unique hardware identifier, the encoding information and target hardware asset information can be directly cached in the manager. Alternatively, the encoding information and target hardware asset information can be permanently stored in the manager's local database.

[0066] When the encoding information includes the initial encoding and the first verification code, the encoding information and the target hardware asset information can be directly cached in the manager. Alternatively, the encoding information and the target hardware asset information can be permanently stored in the manager's local database.

[0067] Alternatively, the initial encoding and target hardware asset information can be cached in the manager. And / or, the initial encoding and target hardware asset information can be persisted in the manager's local database.

[0068] The method for obtaining hardware asset information in embodiments of this application involves first obtaining the location information of the target board after the target device is powered on, and then determining the target encoding address information corresponding to the target board from the pre-configured total address configuration information based on the target board's location information. Furthermore, encoding information can be read from a target component of the target board based on the target encoding address information, wherein the target component is a native component selected from the target board according to the board type. Finally, the target hardware asset information of the target board can be downloaded from a target storage location outside the target device based on the encoding information. The target hardware asset information is stored in the target device's manager, allowing the manager to perform management operations on the target board based on the target hardware asset information.

[0069] This eliminates the need for dedicated memory and peripheral circuitry on all boards used to store hardware asset information. A single device can reduce the material and soldering costs of dozens of integrated circuits, resulting in significant cost reductions during mass production. It also completely eliminates potential failure points caused by massive memory usage, such as poor soldering, damage, and read / write anomalies. Furthermore, the reduced component count and board area lowers design complexity, allowing for the addition of other useful functions to the saved board space. Moreover, the production phase eliminates the need to burn large amounts of hardware asset information onto each board; only certain components require coded information, shortening production processes and improving mass production efficiency. Adding and removing FRU information is quick and easy, and updates can be performed at any time, requiring only network synchronization, resulting in extremely low product iteration costs.

[0070] In some alternative implementations, the pre-programmed board code can be determined in the following manner: Obtain the production batch, production line number, and production timestamp of the board. Determine the board code based on the production batch, production line number, and production timestamp.

[0071] Specifically, after obtaining the production batch, production line number, and production timestamp of the board, these pieces of information can be directly combined into a board code. Alternatively, a random algorithm can be used to process the production batch, production line number, and production timestamp to obtain a globally unique code of a specified length, such as a 64-bit globally unique code.

[0072] In this way, when a batch of circuit boards fails, the production batch and production line number in the circuit board code can be used to quickly identify the problematic batch and production line, enabling accurate recall.

[0073] In some alternative implementations, when the target device is powered on for the first time, step S205 above may include: The encoding information and target hardware asset information are cached in the manager.

[0074] Additionally, the encoding information and target hardware asset information are stored in the manager's local database.

[0075] Specifically, during the initial power-on process of the target device, after obtaining the encoding information and target hardware asset information, the encoding information and target hardware asset information can be cached in the manager so that when the manager receives an instruction to query hardware asset information, it can immediately retrieve the hardware asset information from the cache and provide feedback.

[0076] In addition, to avoid repeating the download process after each power-on, the encoding information and target hardware asset information can be stored in the manager's local database. This allows the target hardware asset information to be read directly from the local database based on the encoding information after subsequent power-ons, which is more efficient and saves communication resources.

[0077] Accordingly, if the target device is not being powered on for the first time, after step S203, the manager may also perform the following operations: Step 1: Based on the encoding information, determine whether the target hardware asset information exists in the local database.

[0078] Step two: If the target hardware asset information exists in the local database, the target hardware asset information is read directly from the local database according to the encoding information and stored in the manager's cache.

[0079] Furthermore, in step three, if it is determined that the target hardware asset information does not exist in the local database, the target hardware asset information is downloaded from the target storage location based on the encoding information. The encoding information and the target hardware asset information are cached in the manager. Additionally, the encoding information and the target hardware asset information are permanently stored in the manager's local database.

[0080] Specifically, after the target device has been powered on multiple times, the currently scanned boards may differ from those scanned previously, for example, boards may have been added or replaced. Since the hardware asset information for some boards may already exist after the first or last power-on, there is no need to repeat the download operation. Therefore, the corresponding target hardware asset information can be determined first based on the encoding information to determine whether it exists in the local database.

[0081] If the target hardware asset information does not exist, it can be downloaded from the cloud platform in a manner similar to step S204 described above. Additionally, to facilitate timely feedback of the target hardware asset information, the encoding information and the target hardware asset information can be cached in the manager. Furthermore, to ensure that the target hardware asset information can still be obtained promptly during subsequent scans, the encoding information and the target hardware asset information can be stored in the manager's local database.

[0082] If it exists, the target hardware asset information can be read directly from the local database based on the encoding information and stored in the manager's cache.

[0083] In this way, when the local database is matched, hardware asset information can be obtained promptly without network communication; only newly added or replaced boards require downloading over the network. Furthermore, hardware asset information can still be queried even when the network is disconnected, without affecting basic management functions.

[0084] In some optional implementations, steps S201 to S204 described above may be scanning operations automatically executed by the manager after detecting that the target device is powered on, for example, executed once after power-on, or executed periodically after power-on. Alternatively, they may be executed by the manager after receiving a scanning command. Accordingly, the manager may also perform the following operations: Step 1: Based on the encoding information, determine whether the target hardware asset information exists in the manager's cache.

[0085] Step two: If the target hardware asset information is not found in the manager's cache, determine whether the target hardware asset information exists in the local database based on the encoding information.

[0086] Step 3: If the target hardware asset information exists in the local database, read the target hardware asset information directly from the local database and store it in the manager's cache.

[0087] Step four: If the target hardware asset information does not exist in the local database, download the target hardware asset information from the target storage location based on the encoding information.

[0088] Step 5: Cache the encoding information and target hardware asset information in the manager, and also persist the encoding information and target hardware asset information in the manager's local database.

[0089] Specifically, since new or replaced boards may be added during the operation of the target device, the manager can periodically perform the aforementioned steps S201 to S203, or, after a board changes, for example, when the presence signal of the corresponding slot is detected to change from absent to present, the aforementioned steps S201 to S203 are executed.

[0090] Furthermore, after obtaining the encoding information, the system can first determine whether the target hardware asset information corresponding to the encoding information exists in the manager's cache. If it does not exist in the cache, it can then determine whether the target hardware asset information exists in the local database. If it exists in the local database, the target hardware asset information can be directly read from the local database and stored in the manager's cache. If it does not exist in the local database, the target hardware asset information can be downloaded from the cloud platform in a manner similar to step S204 described above. Additionally, to facilitate timely feedback of the target hardware asset information, the encoding information and the target hardware asset information can be cached in the manager. Furthermore, to ensure that the target hardware asset information can still be obtained promptly during the next scan, the encoding information and the target hardware asset information can be permanently stored in the manager's local database.

[0091] In some optional implementations, for scenarios involving classified data centers or offline servers without external network access, the cloud platform can be accessed in advance via a network-connected device. Based on the target device's board code list (including the board codes for each board, which can be affixed to board labels for easy retrieval), hardware asset information can be downloaded in batches to obtain total hardware asset information. This information is then encrypted and stored on a dedicated mobile storage device (e.g., a USB flash drive). The mobile storage device can then be connected to the target device. Upon the target device's first power-on, the manager can perform the following operations: Step 1: Read the total hardware asset information of the target device directly from the mobile storage device.

[0092] The total hardware asset information may include the identification information and hardware asset information of multiple boards in the target device.

[0093] Step 2: Save the total hardware asset information to the manager's local database.

[0094] Specifically, the manager can directly download total hardware asset information from the removable storage device, store it in its own cache, and persist it to a local database. This total hardware asset information can be stored on the target device in the form of encrypted data packets. After downloading the encrypted data packets, the manager can first verify that the source of the encrypted data packets is a specified source, for example, by using key verification, to prevent the import of dangerous data and ensure hardware information security. If it is, then the manager downloads and verifies the integrity of the data (e.g., the aforementioned CRC check) to prevent data tampering.

[0095] In this way, the device's compatibility covers all categories of server products, including regular networked systems, classified offline systems, systems without network access, small circuit boards, and high-end high-density servers.

[0096] Furthermore, to determine whether the total hardware asset information read is complete and correct, after traversing all the boards in the target device and obtaining the identification information corresponding to each of the multiple boards included in the target device, the following operations can be performed: Step 3: Determine the verification result based on the total hardware asset information and the identification information corresponding to the multiple boards included in the target device.

[0097] Step 4: If the verification results indicate that the total hardware asset information is correct, save the total hardware asset information to the manager's local database.

[0098] Specifically, it can be determined whether the total hardware asset information includes the identification information of each board of the target device. If so, the total hardware asset information can be confirmed to be correct. If the total hardware asset information is missing the identification information of a certain board of the target device, or if the identification information of the scanned board is missing compared to the total hardware asset information, an error can be reported and further confirmed by technical personnel.

[0099] If the verification results confirm that the total hardware asset information is correct, the total hardware asset information can be stored in the manager's local database. Similarly, the total hardware asset information can be stored in the manager's cache for timely feedback of hardware asset information.

[0100] In some optional implementations, after adding or replacing a board, the corresponding hardware asset information can be downloaded from the cloud platform to the mobile storage device based on the coding information of the added or replaced board. Then, the manager can download the hardware asset information of the added or replaced board from the mobile storage device.

[0101] In some alternative implementations, to conserve the manager's storage resources, different storage strategies can be used to store hardware asset information for different board types. Accordingly, the manager can perform the following operations: Step 1: Based on the target board type, obtain the storage strategy corresponding to the board type.

[0102] Step two: Use a storage strategy to store the target hardware asset information in the target device's manager.

[0103] Specifically, since the usage frequency of hardware asset information varies across different board types, to conserve the manager's storage resources, only the full hardware asset information for a subset of boards can be archived. The manager can store storage policies corresponding to various board types. First, based on the target board's board type, a storage policy corresponding to that type can be determined. This policy specifies the fields to be archived, the fields to be cached, and temporary fields (i.e., downloaded from the cloud database only when a request for that field is received). The manager can then select the fields from the target hardware asset information that need to be archived, archive them to the local database, and cache them. For fields requiring caching, caching is performed; for temporary fields, no download is required.

[0104] This avoids the storage waste caused by full data freezing and maximizes storage resource utilization. Furthermore, the storage strategy can be dynamically adjusted to flexibly adapt to changes in business needs, saving storage space without affecting query efficiency.

[0105] The following is a detailed explanation of the execution process of the above method for obtaining hardware asset information using a specific example.

[0106] like Figure 3 As shown, the baseboard management controller includes an encoding information reading unit, a local database, and an automatic update management unit. The encoding information reading unit can be used to read the encoding information of the corresponding board from the complex programmable logic controller (CPL) of the motherboard, the CPL of the adapter card, the microcontroller of the hard drive backplane, the microcontroller of the fan board, the encryption circuit of the simple board, etc.

[0107] like Figure 4 As shown, after the server powers on and the BMC starts, the I2C bus is initialized first. Then, the various boards in the server are traversed to obtain their encoding information. Based on this encoding information, it is determined whether the local database can find the corresponding hardware asset information. If so, the hardware asset information can be read for use by other systems. If not, the hardware asset information in the local database can be updated via the automatic update management unit.

[0108] The baseboard management controller can first determine whether the network is normal. If it is, it can download hardware asset information from the cloud database. If not, it can import hardware asset information from a USB flash drive and write the acquired hardware asset information into the local database.

[0109] This solution offers multiple update modes, including online automatic update, offline USB flash drive import update, and local firmware reuse. In online automatic update mode, maintenance logs are automatically generated without manual intervention, resulting in high efficiency. Offline USB flash drive import update mode ensures hardware security. In local firmware reuse mode, BMC can directly reuse locally stored hardware asset information without network queries or external imports, offering fast read / write speeds, stable operation, and no network dependency, ensuring continuous and stable operation of the server hardware monitoring system.

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

[0111] Embodiments of this application also provide an apparatus for acquiring hardware asset information, such as... Figure 5 As shown, it includes: The acquisition module 510 is used to acquire the location information of the target board after the target device is powered on, wherein the target board is any board other than the motherboard among the multiple boards included in the target device.

[0112] The determination module 520 is used to determine the target encoding address information corresponding to the target board from the pre-configured total address configuration information based on the location information of the target board.

[0113] The reading module 530 is used to read encoding information from the target component of the target board according to the target encoding address information, wherein the target component is a component selected from the native components of the target board according to the board type of the target board.

[0114] Download module 540 is used to download target hardware asset information of target board from target storage location outside the target device based on encoding information.

[0115] Storage module 550 is used to store target hardware asset information in the target device manager, so that the manager can perform management operations on the target board based on the target hardware asset information.

[0116] In some alternative implementations, the determining module 520 is further configured to: Obtain the board type of the target board.

[0117] Based on the target board's board type and location information, determine the target encoding address information corresponding to the target board in the general address configuration information.

[0118] In some alternative implementations, the determining module 520 is specifically used for: Based on the location information of the target board, the target address configuration information corresponding to the target board is determined in the total address configuration information. The target address configuration information includes coded address information corresponding to at least one type of board. Based on the target board type, determine the target encoding address information corresponding to the target board type in the target address configuration information.

[0119] In some alternative implementations, the download module 540 is specifically used for: Extract the initial code from the first position of the encoded information, and extract the first check code from the second position of the encoded information.

[0120] The initial code is verified to obtain the second verification code.

[0121] If the first and second check codes are found to be consistent, the target hardware asset information is downloaded from the target storage location according to the initial encoding.

[0122] In some optional implementations, the acquisition module 510 is specifically used for: After the state of the target slot's presence signal changes from absent to present, the position information of the target slot is determined as the position information of the target board. The target slot is any one of the at least one slots included in the target device, and the target board is the board inserted into the target slot.

[0123] In some optional implementations, when the board type is the first type, the encoding information is the board code pre-programmed into the target component. The first type is used to indicate that the board does not include native components with unique hardware identification information, but includes native components with programming function. The target component is any native component with programming function in the target board.

[0124] In some alternative implementations, when the native components of the target board include a logic controller, the logic controller is the target component, and the target storage area of ​​the logic controller's memory is pre-programmed with the board code.

[0125] In some optional implementations, when the board type is the second type, the encoding information is the unique hardware identification information of the target component, wherein the second type is used to indicate that the board includes native components with unique hardware identification information, and the target component is any native component with unique hardware identification information in the target board.

[0126] In some alternative implementations, the target component is an additional encryption component added to the target board, and the encoded information is the unique hardware identification information in the encryption component.

[0127] In some alternative implementations, upon the initial power-on of the target device, the storage module 550 is specifically used for: The encoding information and target hardware asset information are cached in the manager.

[0128] Additionally, the encoding information and target hardware asset information are stored in the manager's local database.

[0129] In some alternative implementations, when the target device is not powered on for the first time, the storage module 550 is further configured to: Before downloading the target hardware asset information of the target board from the target storage location outside the target device based on the encoding information, it is determined whether the target hardware asset information exists in the local database based on the encoding information.

[0130] If the target hardware asset information is confirmed to exist in the local database, the target hardware asset information is read directly from the local database based on the encoding information and stored in the manager's cache.

[0131] In some alternative implementations, the storage module 550 is further configured to: If the target hardware asset information does not exist in the local database, the target hardware asset information is downloaded from the target storage location based on the encoding information.

[0132] The encoding information and target hardware asset information are cached in the manager.

[0133] Additionally, the encoding information and target hardware asset information are stored in the manager's local database.

[0134] In some alternative implementations, the storage module 550 is further configured to: After the target device is powered on for the first time, the total hardware asset information of the target device is read directly from the mobile storage device. The total hardware asset information includes the coding information and hardware asset information of multiple boards in the target device.

[0135] The total hardware asset information is stored in the manager's local database.

[0136] In some alternative implementations, the storage module 550 is further configured to: After obtaining the coding information corresponding to the multiple boards included in the target device, the verification result is determined based on the total hardware asset information and the coding information corresponding to the multiple boards included in the target device.

[0137] If the verification results indicate that the total hardware asset information is correct, the total hardware asset information will be stored in the local database.

[0138] For a description of the features in the embodiment corresponding to the device for obtaining hardware asset information, please refer to the relevant description in the embodiment corresponding to the method for obtaining hardware asset information, which will not be repeated here.

[0139] Embodiments of this application also provide a controller, such as Figure 6 As shown, it includes a memory 10 and a processor 20. The memory 10 stores a computer program, and the processor 20 is configured to run the computer program to perform the steps in any of the above-described embodiments of the method for obtaining hardware asset information.

[0140] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the method for obtaining hardware asset information when it is run.

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

[0142] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described methods for obtaining hardware asset information.

[0143] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described methods for obtaining hardware asset information.

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

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

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

Claims

1. A method for acquiring hardware asset information, characterized in that, include: After the target device is powered on, the location information of the target board is obtained, wherein the target board is any one of the multiple boards included in the target device, excluding the motherboard; Based on the location information of the target board, the target encoding address information corresponding to the target board is determined from the pre-configured total address configuration information; Based on the target encoding address information, encoding information is read from the target component of the target board, wherein the target component is a component selected from the native components of the target board according to the board type of the target board; Based on the encoded information, download the target hardware asset information of the target board from a target storage location outside the target device; The target hardware asset information is stored in the manager of the target device, so that the manager can perform management operations on the target board based on the target hardware asset information.

2. The method for obtaining hardware asset information according to claim 1, characterized in that, The method further includes: Obtain the board type of the target board; Based on the board type and location information of the target board, the target encoding address information corresponding to the target board is determined in the total address configuration information.

3. The method for obtaining hardware asset information according to claim 2, characterized in that, The step of determining the coded address information corresponding to the target board in the total address configuration information based on the board type and location information of the target board includes: Based on the location information of the target board, target address configuration information corresponding to the target board is determined in the total address configuration information, wherein the target address configuration information includes coded address information corresponding to at least one type of board; Based on the board type of the target board, the target encoding address information corresponding to the board type of the target board is determined in the target address configuration information.

4. The method for obtaining hardware asset information according to any one of claims 1 to 3, characterized in that, The step of downloading the target hardware asset information of the target board from a target storage location outside the target device according to the encoded information includes: Extract the initial code from the first position of the encoded information, and extract the first check code from the second position of the encoded information; The initial code is verified to obtain a second verification code; If the first verification code and the second verification code are found to be consistent, the target hardware asset information is downloaded from the target storage location according to the initial encoding.

5. The method for obtaining hardware asset information according to any one of claims 1 to 3, characterized in that, The acquisition of the target board's location information includes: After the state of the detected presence signal of the target slot changes from absent to present, the position information of the target slot is determined as the position information of the target board. The target slot is any one of the at least one slots included in the target device, and the target board is the board inserted into the target slot.

6. The method for obtaining hardware asset information according to any one of claims 1 to 3, characterized in that, When the board type is the first type, the encoding information is the board code pre-programmed into the target component. The first type is used to indicate that the board does not include native components with unique hardware identification information, but includes native components with programming function. The target component is any native component with programming function in the target board.

7. The method for obtaining hardware asset information according to claim 6, characterized in that, When the native components of the target board include a logic controller, the logic controller is the target component, and the target storage area of ​​the logic controller's memory is pre-programmed with the board's code.

8. The method for obtaining hardware asset information according to any one of claims 1 to 3, characterized in that, When the board type is the second type, the encoding information is the unique hardware identification information of the target component. The second type is used to indicate that the board includes native components with unique hardware identification information, and the target component is any native component with unique hardware identification information in the target board.

9. The method for obtaining hardware asset information according to any one of claims 1 to 3, characterized in that, The target component is an additional encryption component added to the target board, and the encoded information is a unique hardware identifier in the encryption component.

10. The method for acquiring hardware asset information according to any one of claims 1 to 3, characterized in that, When the target device is powered on for the first time, storing the target hardware asset information in the target device's manager includes: The encoded information and the target hardware asset information are cached in the manager; In addition, the encoded information and the target hardware asset information are stored in the manager's local database.

11. The method for acquiring hardware asset information according to claim 10, characterized in that, When the target device is not powered on for the first time, after reading the encoding information from the target component of the target board according to the target encoding address information, the method further includes: Based on the encoding information, determine whether the target hardware asset information exists in the local database; If the target hardware asset information is found in the local database, the target hardware asset information is read directly from the local database according to the encoding information and stored in the cache of the manager.

12. The method for acquiring hardware asset information according to claim 11, characterized in that, The method further includes: If it is determined that the target hardware asset information does not exist in the local database, the target hardware asset information is downloaded from the target storage location according to the encoding information; The encoded information and the target hardware asset information are cached in the manager; In addition, the encoded information and the target hardware asset information are stored in the manager's local database.

13. The method for acquiring hardware asset information according to any one of claims 1 to 3, characterized in that, The method further includes: After the target device is powered on for the first time, the total hardware asset information of the target device is directly read from the mobile storage device. The total hardware asset information includes the coding information and hardware asset information of multiple boards in the target device. The total hardware asset information is stored in the manager's local database.

14. The method for acquiring hardware asset information according to claim 13, characterized in that, After directly reading the total hardware asset information of the target device from the mobile storage device, the method further includes: After obtaining the coding information corresponding to the multiple boards included in the target device, the verification result is determined based on the total hardware asset information and the coding information corresponding to the multiple boards included in the target device. If the verification result indicates that the total hardware asset information is correct, the total hardware asset information is saved to the local database.

15. A manager, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the method for acquiring hardware asset information as described in any one of claims 1 to 14 when executing the computer program.

Images