A FRU device management method based on soft bus soft and hard decoupling

Abstract

The application relates to a FRU equipment management method based on soft bus soft and hard decoupling. On one hand, a distributed soft bus is arranged in a transmission layer, then the distributed soft bus is taken as a center, access of at least one FRU equipment node and a management equipment node into a physical layer to a network layer of an OSI seven-layer architecture is realized, and discovery, connection, networking and establishment of a transmission channel between the management equipment node and the at least one FRU equipment node are realized, so that the equipment with the bus interface can be easily accessed, the access efficiency is greatly improved, and the self-discovery function of the distributed soft bus can also improve the flexibility and expansibility of the management equipment interconnection. On the other hand, an RPC framework is arranged in a session layer, a hardware isolated development platform is provided for application from the session layer to an application layer through RPC technology, the soft and hard isolation development can reduce the complexity of development and design, reduce the design difficulty, and improve the implementation efficiency and stability of application management.

Description

Technical Field

[0001] This application relates to the field of FRU device management technology, and in particular to an FRU device management method based on software-hardware decoupling of a soft bus. Background Technology

[0002] The OSI (Open System Interconnect) reference model defines a seven-layer framework for network interconnection. Each layer of this layered framework is relatively independent and communicates through clear interfaces, making network design, implementation, and maintenance more flexible and simple.

[0003] In highly complex and continuously operating data center and unmanned system network environments, the stability and reliability of information system equipment are of paramount importance. Field Replaceable Units (FRUs) enable maintenance personnel to quickly replace faulty components without interrupting the overall system operation, thereby significantly reducing downtime and improving system availability and stability.

[0004] Existing FRU device management methods are mostly based on tightly coupled architectures, resulting in complex inter-device interconnections, poor scalability, and difficulty in adapting to rapidly changing application requirements. Especially in distributed device management scenarios, traditional management methods struggle to effectively achieve unified management and efficient interconnection of devices. For example:

[0005] The Intelligent Platform Management Interface (IPMI) protocol supports multiple physical layer and data link layer protocols such as I2C / SMBus, KCS, and BT. However, its focus is on providing design guidance for the network layer and the interface between the data representation part and the application layer. There are no standardized specifications for the design of the transport layer and session layer, requiring each vendor to design and implement them on their own at the application layer, resulting in poor compatibility.

[0006] The Management Component Transport Protocol (MCTP) / Platform Level Data Model (PLDM) protocol suite evolved from IPMI. MCTP extended support for the data link layer to include PCIe, SMBus / I2C, UART, Host Interface, USB, etc., and designed a centralized hybrid network layer protocol, providing transport layer protocol support. PLDM standardized the presentation layer of FRU device management information, but still used serialized service commands based on the MCTP protocol as the basis for data interaction. It lacked explicit session layer constraints, resulting in strong inter-protocol dependencies and an inability to achieve hardware and software decoupling of communication transmission and service protocols, making it difficult to flexibly adapt to different devices and application scenarios.

[0007] Furthermore, tightly coupled designs often lead to higher development and maintenance costs in actual deployments, limiting the system's portability and scalability. Summary of the Invention

[0008] The main objective of this disclosure is to propose an FRU device management method based on software-hardware decoupling of a soft bus, which can achieve design isolation for hardware device access and multi-terminal management application software development.

[0009] The first aspect of this application proposes a FRU device management method based on software-hardware decoupling of a soft bus, applied to an application development system; the application development system includes:

[0010] OSI seven-layer architecture;

[0011] The physical layer in the OSI seven-layer architecture includes: a management device node and at least one FRU device node, both of which have a bus interface; the management device node is used to manage the at least one FRU device node.

[0012] The transport layer in the OSI seven-layer architecture is equipped with a distributed soft bus.

[0013] The session layer in the OSI seven-layer architecture is equipped with an RPC framework.

[0014] The application layer in the OSI seven-layer architecture includes: a first management terminal corresponding to the at least one FRU device node, and a second management terminal corresponding to the management device node;

[0015] The FRU device management method based on soft bus hardware-software decoupling includes:

[0016] The communication protocols corresponding to the data link layer to the network layer in the OSI seven-layer architecture, as well as the bus interfaces of the management device node and the at least one FRU device node, are connected to the distributed soft bus to realize the discovery, connection, networking and establishment of transmission channels between the management device node and the at least one FRU device node based on the distributed soft bus;

[0017] In the first management terminal, at least one FRU device management data model corresponding to the at least one FRU device node in the presentation layer is set, and an RPC management service model in the session layer is set based on the RPC framework. The at least one FRU device management data model and the RPC management service model are associated and integrated into the corresponding at least one FRU device node, so as to realize the management of the at least one FRU device node based on the RPC management service model; the FRU device management data model is used as the data representation in the data communication transmission of the FRU device node.

[0018] The FRU device management method based on software-hardware decoupling of the soft bus provided in this embodiment has at least the following advantages:

[0019] This method employs two main approaches. First, it establishes a distributed soft bus at the transport layer. This soft bus serves as the central hub, enabling access for at least one FRU device node and a management device node across the OSI seven-layer architecture, from the physical layer to the network layer. By abstracting and adapting the underlying OSI communication protocols, it achieves compatibility with multiple buses, facilitating discovery, connection, networking, and the establishment of transmission channels between the management device node and at least one FRU device node. This allows various hardware devices with the bus interface to easily connect, significantly improving access efficiency. Furthermore, the self-discovery function of the distributed soft bus enhances the flexibility and scalability of management device interconnection. Second, it incorporates an RPC framework at the session layer. Through RPC technology, it provides a hardware-isolated development platform for applications across the OSI seven-layer architecture, from the session layer to the application layer. This hardware-software isolation reduces development complexity and design difficulty, while improving the efficiency and stability of application management.

[0020] In some embodiments of this application, the step of connecting the communication protocols corresponding to the data link layer to the network layer in the OSI seven-layer architecture, as well as the bus interfaces of the management device node and the at least one FRU device node, to the distributed soft bus to realize the discovery, connection, networking, and establishment of transmission channels between the management device node and the at least one FRU device node based on the distributed soft bus includes:

[0021] Configure the controller driver package;

[0022] The bus interface is driven according to the controller driver package to enable data transmission and reception between the management device node and the at least one FRU device node at the data link layer based on the communication protocol corresponding to the data link layer.

[0023] Configure the network protocol package corresponding to the controller driver package; the network protocol package includes the communication protocol corresponding to the network layer.

[0024] In the distributed soft bus, at least one distributed soft bus FRU device node corresponding to the at least one FRU device node and a distributed soft bus management device node corresponding to the management device node are configured, and the network protocol packet matching is adapted to realize the discovery, connection, networking and establishment of transmission channels between the management device node and the at least one FRU device node.

[0025] In some embodiments of this application, the method further includes:

[0026] Configure the first management function of the at least one FRU device node in the first management terminal located in the application layer.

[0027] In some embodiments of this application, the first management function includes at least information collection, status control, and autonomous management.

[0028] In some embodiments of this application, before setting the FRU device management data model corresponding to the at least one FRU device node located in the presentation layer, the method further includes:

[0029] In the first management terminal, the at least one distributed soft bus FRU device node is associated based on the openHarmony virtual tool;

[0030] After integrating the FRU device management data model and the RPC management service model to the corresponding at least one FRU device node, the method further includes:

[0031] The first management terminal manages the at least one FRU device node based on the at least one associated distributed soft bus FRU device node according to the first management function.

[0032] In some embodiments of this application, the method further includes:

[0033] In the second management terminal, at least one virtual FRU device node corresponding to the at least one FRU device node is configured;

[0034] Configure the second management function corresponding to the at least one virtual FRU device node in the second management terminal;

[0035] In the second management terminal, based on the RPC management service model and the second management function, the management data model of the at least one FRU device is invoked to realize the management of the at least one FRU device node.

[0036] In some embodiments of this application, the FRU device management data model is a PLDM-based management data model.

[0037] In some embodiments of this application, the data types included in the FRU device management data model include at least: static readable and writable data, dynamic readable data, control readable and writable data, and event reporting data.

[0038] In some embodiments of this application, the method further includes:

[0039] The first management terminal registers general read data functions and write data functions with the RPC management service model;

[0040] The first management terminal obtains a general event data reporting function from the RPC management service model to actively report data to the second management terminal when an event occurs in at least one FRU device; the general event data reporting function is registered by the second management terminal.

[0041] In some embodiments of this application, the method further includes:

[0042] The second management terminal registers a general event data reporting function with the RPC management service model;

[0043] The second management terminal obtains the general read data function and write data function from the RPC management service model.

[0044] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

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

[0046] Figure 1 This is an architecture diagram of an embodiment of an application development system provided in this application;

[0047] Figure 2This is an architectural diagram of at least one embodiment of the FRU device and management device provided in this application;

[0048] Figure 3 This is a flowchart of an embodiment of FRU device access provided in this application;

[0049] Figure 4 This is a flowchart of an application software development embodiment provided in this application. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] In the description of this application, the use of terms such as "first," "second," etc., is for the purpose of distinguishing technical features only and should not be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated or the order of the technical features indicated.

[0052] In the description of this application, it should be understood that the orientation descriptions, such as up, down, etc., are based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed or function in a specific orientation, and therefore should not be construed as a limitation of this application.

[0053] like Figure 1 As shown, this application provides an embodiment, which includes a FRU device management method based on software-hardware decoupling of a soft bus, applied to an application development system; the application development system includes:

[0054] OSI seven-layer architecture;

[0055] The physical layer in the OSI seven-layer architecture includes: a management device node and at least one FRU device node, both of which have a bus interface; the management device node is used to manage at least one FRU device node.

[0056] The transport layer in the OSI seven-layer architecture is equipped with a distributed soft bus.

[0057] The session layer in the OSI seven-layer architecture has an RPC framework.

[0058] The application layer in the OSI seven-layer architecture includes: a first management terminal corresponding to at least one FRU device node, and a second management terminal corresponding to a management device node;

[0059] The method includes the following steps S110 to S120:

[0060] Step S110: Connect the communication protocols corresponding to the data link layer to the network layer in the OSI seven-layer architecture, as well as the bus interfaces of the management device node and at least one FRU device node, to the distributed soft bus to realize the discovery, connection, networking and establishment of transmission channels between the management device node and at least one FRU device node based on the distributed soft bus.

[0061] Step S120: In the first management terminal, at least one FRU device management data model corresponding to at least one FRU device node in the presentation layer is set, and an RPC management service model in the session layer is set based on the RPC framework. The at least one FRU device management data model and the RPC management service model are associated and integrated into the corresponding at least one FRU device node, so as to realize the management of at least one FRU device node based on the RPC management service model. The FRU device management data model is used as the data representation in the data communication transmission of the FRU device node.

[0062] Firstly, in this embodiment, the application development system can be applied to software system development.

[0063] like Figure 1 and Figure 2 The OSI seven-layer architecture, from lowest to highest, includes: Physical Layer, Data Link Layer, Network Layer, Transport Layer, Session Layer, Presentation Layer, and Application Layer. It should be noted that the specific functions of each layer are not detailed here.

[0064] The physical layer includes at least one FRU device node and a management device node, each of which has a corresponding bus interface.

[0065] like Figure 2 An FRU device includes at least: a management controller (MC), a load (managed object entity), and a bus interface. A management device includes at least: a management controller (MC) and a bus interface.

[0066] like Figure 1 In this embodiment, the data link layer includes wired management bus interfaces such as CAN, SMBus / I2C, UART, and bus-type Ethernet. The network layer includes network protocols such as MCTP, IP, and CANopen.

[0067] The transport layer features a distributed soft bus, which, through software definition, constructs a unified, cross-device communication platform, integrating dispersed hardware resources into a logical whole. Specifically, it comprises four modules: discovery module, connection module, networking module, and transmission module.

[0068] The session layer is equipped with an RPC framework. RPC technology is a multi-terminal management application development framework that provides remote procedure calls.

[0069] The application layer includes a first management port and a second management port. These ports are used for developing software functions, as detailed in subsequent embodiments.

[0070] In step S110 of this embodiment, the communication protocol corresponding to the data link layer to the network layer and the bus interface of each device node can be determined first, abstracted, and adapted with the distributed soft bus, so as to realize the discovery, connection, networking and transmission channel establishment between the management device node and at least one FRU device node by the discovery module, connection module, networking module and transmission module based on the distributed soft bus.

[0071] The following describes a distributed soft bus implementation of the process for discovering, connecting, networking, and establishing transmission channels between management device nodes and at least one FRU device node:

[0072] First, FRU devices and management devices are interconnected via bus interfaces such as CAN, SMBus / I2C, UART, and bus-type Ethernet. For example, the interface controllers and software drivers corresponding to the FRU and management devices perform the conversion between raw data (such as analog signals) and digital signals to send raw data to other devices and receive data from other devices. It is important to note that each device node has a unique identifier, and network communication messages must also specify the source and destination device node identifiers. Each device node in the distributed network is responsible for maintaining the network's node address book to ensure orderly communication with other device nodes in the network.

[0073] Different bus interfaces typically have different industry standards for their network message protocols. This embodiment supports multiple bus-type network message protocols to adapt to different bus interface hardware. For example, the MCTP protocol has communication message standards such as SMBus, I2C, and UART. IP is suitable for bus-type Ethernet connections, and CANopen specifies a communication protocol based on the CAN interface.

[0074] This embodiment primarily utilizes the communication message formats of these protocols to reduce unnecessary development and debugging work, thereby improving stability and maturity. These protocols are designed with methods for identifying device nodes in the network, and include command messages for network broadcasting and heartbeat commands for detecting active status. Here, they are integrated into the discovery module of the distributed soft bus to achieve accurate device node discovery.

[0075] Custom generic data transmission commands are implemented through licensed extension commands, isolating network information from upper-layer data. Device node connections, device networking, and data transmission in the distributed soft bus are all based on generic data transmission commands.

[0076] Through the above processing, multiple bus interfaces are connected to the distributed soft bus for unified management. FRU devices and management devices can discover each other and transmit common data through the distributed soft bus function interface.

[0077] Right now:

[0078] (1) The discovery module automatically discovers and identifies device nodes in the network;

[0079] (2) The connection module realizes the functions of device node information identification and authentication;

[0080] (3) The networking module provides network establishment and maintenance for multiple buses, and provides heterogeneous transmission functions between different bus networks;

[0081] (4) The transmission module mainly realizes the transmission session, provides a simple and secure one-to-one data interaction interface, and automatically selects a more efficient hardware transmission channel.

[0082] With this configuration, in this embodiment, in an OSI seven-layer architecture with at least one FRU device node at the physical layer, a distributed soft bus is set up at the transport layer. Then, based on the distributed soft bus as the center, at least one FRU device node and a management device node are connected to the physical layer and network layer of the OSI seven-layer architecture. That is, by abstracting and adapting the underlying communication protocols of OSI, it is compatible with multiple buses and realizes the discovery, connection, networking and establishment of transmission channels between the management device node and at least one FRU device node. This allows various hardware devices with this bus interface to be easily connected, greatly improving the access efficiency. Moreover, the self-discovery function of the distributed soft bus can also improve the flexibility and scalability of the interconnection of management devices.

[0083] After implementing the automatic networking of the distributed soft bus as described above, the following describes the process of achieving software-hardware decoupling based on RPC technology:

[0084] This embodiment sets up an RPC framework at the session layer, which can register FRU device nodes and manage device nodes, allowing them to discover each other's device node types and function interfaces through the RPC framework.

[0085] In step S120, this embodiment uses a unified management data model as the data representation for communication transmission between the FRU device and the management device, such as a PLDM data model or an OEM model. In the first management terminal, at least one FRU device management data model is set corresponding to at least one FRU device node located in the presentation layer.

[0086] In step S120, an RPC management service model located at the session layer is set up based on the RPC framework. The RPC management service model is developed based on the RPC framework, and the logic developed therein belongs to the supporting technologies of the RPC framework, which will not be described in detail here. In step S120, at least one FRU device management data model and the RPC management service model are associated and integrated into at least one corresponding FRU device node, enabling the first management terminal to manage at least one FRU device node based on the RPC management service model.

[0087] With the above settings, an RPC framework is set up at the session layer. Through RPC technology, a hardware and software isolated development platform is provided for various applications at the higher layers of the OSI seven-layer architecture (such as the session layer, presentation layer, and application layer). Hardware and software isolation development can effectively reduce the complexity of development and design, reduce the difficulty of system design, and effectively improve the efficiency and stability of management.

[0088] The beneficial effects of the FRU device management method based on software-hardware decoupling of a soft bus provided in this embodiment include:

[0089] The method provided in this embodiment, in the device access scenario at the bottom layer of the OSI architecture, has universal compatibility with bus interfaces. Only the distributed soft bus capability adaptation needs to be completed to allow various hardware devices with the bus interface to easily connect to the system, greatly improving the access efficiency of hardware devices. Simultaneously, the self-discovery feature enhances the flexibility and scalability of managing device interconnection. In the device management scenario at the higher layer of the OSI architecture, combined with RPC technology, it provides a hardware-isolated development platform for management applications, eliminating the need to focus on specific communication transmission methods, effectively reducing development complexity and lowering the design difficulty of application development systems.

[0090] In some embodiments of this application, step S110, which involves connecting the communication protocols corresponding to the data link layer to the network layer in the OSI seven-layer architecture, as well as the bus interfaces of the management device node and at least one FRU device node, to the distributed soft bus to realize the discovery, connection, networking, and establishment of transmission channels between the management device node and at least one FRU device node based on the distributed soft bus, includes:

[0091] Step S1110: Configure the controller driver package;

[0092] Step S1120: Drive the bus interface according to the controller driver package to realize data transmission and reception at the data link layer between the management device node and at least one FRU device node based on the communication protocol corresponding to the data link layer.

[0093] Step S1130: Set the network protocol package corresponding to the controller driver package; the network protocol package includes the communication protocol corresponding to the network layer.

[0094] Step S1140: In the distributed soft bus, set at least one distributed soft bus FRU device node corresponding to at least one FRU device node and a distributed soft bus management device node corresponding to the management device node, and adapt network protocol packet matching to realize the discovery, connection, networking and establishment of transmission channels between the management device node and at least one FRU device node.

[0095] In this embodiment, a general controller driver package is first set up to drive the controller corresponding to the bus interface of each device node (such as CAN, SMBus / I2C, UART, bus-type Ethernet) to realize data transmission and reception at the data link layer.

[0096] Secondly, by configuring a compatible controller driver package (or the controller corresponding to the bus interface) to correspond to a common network protocol package (such as CANopen, MCTP, or IP), it is possible to encapsulate and decapsulate raw data at the data link layer, as well as identify and process network information. For example, based on common network protocol packages and interfaces, device discovery identification, heartbeat communication, and data packet transmission can be implemented between at least one FRU device node.

[0097] Then, based on the support of network protocol packets, a soft bus device node (here named Distributed Soft Bus FRU Device Node) is established to match at least one FRU device management corresponding to the device node, and a soft bus device node (here named Distributed Soft Bus Management Device Node) is established to manage the device node corresponding to the device node, thereby realizing functions such as device node self-discovery, authentication connection, channel heterogeneous networking using all bus interfaces, and session transmission.

[0098] In some embodiments of this application, the FRU device management method based on soft-bus hardware-software decoupling further includes:

[0099] Step S130: Configure at least one FRU device node's first management function in the first management terminal located at the application layer.

[0100] In one embodiment, the first management function includes at least information collection, status control, and autonomous management.

[0101] After completing the distributed soft bus adaptation to the data link layer, network layer, and transport layer, the primary management function of at least one FRU device node is determined. This function mainly includes three parts: information acquisition, status control, and autonomous management. For example:

[0102] Information collection from at least one FRU device is a general basic core function. It usually needs to be developed specifically according to the specific information collection method. The specific implementation in this embodiment is the application layer content. No specific implementation constraints are imposed. It is only used to represent the process steps. The application layer debugs and verifies the implementation of the information collection function and performs reliability testing. FRU device status control and autonomous management (including event reporting) are both application layer content. They are only used to represent the process steps. Preparations should be made for integration with the FRU device management data model corresponding to the subsequent FRU device nodes.

[0103] In some embodiments of this application, before setting the FRU device management data model corresponding to at least one FRU device node located in the presentation layer, the FRU device management method based on soft-bus hardware-software decoupling further includes:

[0104] Step S140: In the first management terminal, associate at least one distributed soft bus FRU device node based on the openHarmony virtual tool;

[0105] After integrating the FRU device management data model and RPC management service model to at least one corresponding FRU device node, the method further includes:

[0106] In step S150, the first management terminal manages at least one FRU device node based on the first management function and the associated at least one distributed soft bus FRU device node.

[0107] In the first management terminal, virtual distributed soft bus device nodes (here named distributed soft bus FRU device nodes) can be added using the virtual tools provided by openHarmony, based on the type, quantity, and data requirements of the FRU device nodes to be managed. Then, the first management terminal manages at least one FRU device node according to the first management function pre-set in step S130 above.

[0108] In some embodiments of this application, the FRU device management method based on soft-bus hardware-software decoupling further includes:

[0109] Step S1610: Configure at least one virtual FRU device node corresponding to at least one FRU device node in the second management terminal;

[0110] Step S1620: Configure at least one second management function corresponding to a virtual FRU device node in the second management terminal;

[0111] In step S1630, the second management terminal calls at least one FRU device management data model based on the RPC management service model and the second management function to realize the management of at least one FRU device node.

[0112] Steps S130-S150 in the above embodiment describe the development of the first management terminal; here, we are developing an application for the second management terminal. The application development of the second management terminal mainly includes obtaining the FRU device management data model corresponding to the FRU device node, and providing an interactive management interface for direct or indirect interaction with the user, typically a web interface.

[0113] In some embodiments of this application, the FRU device management data model is a PLDM-based management data model. The data types included in the FRU device management data model include at least: statically readable and writable data, dynamically readable data, control-readable and writable data, and event reporting data.

[0114] FRU device management methods based on software-hardware decoupling of the soft bus also include:

[0115] Step S1710: The first management terminal registers general read data functions and write data functions with the RPC management service model;

[0116] In step S1720, the first management terminal obtains a general event data reporting function from the RPC management service model to actively report data to the second management terminal when an event occurs in at least one FRU device; the general event data reporting function is registered by the second management terminal.

[0117] FRU device management methods based on software-hardware decoupling of the soft bus also include:

[0118] Step S1810: The second management terminal registers a general event data reporting function with the RPC management service model;

[0119] In step S1820, the second management terminal obtains general read data functions and write data functions from the RPC management service model.

[0120] In the application layer, in this embodiment, the first management terminal registers three general data read functions (static data, dynamic data, and control data) and two general data write functions (static data and control data) with the RPC management service model; it obtains a general event data reporting function registered by the second management terminal from the RPC management service model, which is used to enable the FRU device node to actively report data to the first management terminal when an event occurs; the second management terminal registers a general event data reporting function with the RPC management service model, which is used to receive event information actively reported by the first management terminal; the first management terminal obtains three general data read functions and two general data write functions from the RPC management service model, which are used to realize information acquisition and status control.

[0121] For ease of understanding, please refer to Figures 1 to 4One embodiment of this application provides an application development system and a method for managing FRU devices based on software-hardware decoupling of a soft bus.

[0122] This application development system consists of a management device node and N FRU device nodes, which are connected via one or more bus interfaces. The MC (Management Controller) runs the management software. The other components of the FRU device nodes besides the MC are called loads, and loads are the managed object entities.

[0123] The implementation process of developing a system architecture using this application can be independently divided into the hardware access process for FRU device nodes facing the distributed soft bus and the software development process for the management end.

[0124] like Figure 3 The first process (hardware access process for FRU device nodes in a distributed soft bus):

[0125] This process primarily employs a layered design approach to develop and implement communication protocols for FRU device node management, including the physical layer, data link layer, network layer, and transport layer, enabling it to communicate with other devices. Simultaneously, it implements custom application layer management functions for FRU device nodes.

[0126] Step S810: Determine the management functions of the FRU device node and the bus interface of the FRU device node according to actual needs;

[0127] Step S820, the steps for the layered protocol adaptation of the bus interface are as follows:

[0128] Step S8210: The software adapts or adds the adapted controller driver package, which drives the controller corresponding to the bus interface (such as CAN, SMBus / I2C, UART, bus-type Ethernet) to realize data transmission and reception at the data link layer.

[0129] Step S8220: Set up the test environment and debug and test whether the standard driver data transmission and reception method can be used to realize the data link layer data transmission and reception between N FRU device nodes; at the same time, write or use a general reliability test method to test the communication reliability of the bus interface to ensure the stability and reliability of subsequent upper layer communication.

[0130] Step S8230: The software adapts or adds the network protocol packets (such as CANopen, MCTP, IP) corresponding to the controller with the adapted bus interface to realize the encapsulation and decapsulation of data at the data link layer, as well as network information identification and processing.

[0131] Step S8240: Set up the test environment described in the above steps, and debug and test whether device discovery identification, heartbeat communication and data packet transmission between N FRU device nodes can be achieved through a common network protocol packet; at the same time, write or use a common network reliability test method to test the reliability of bus interface communication to ensure that subsequent upper-layer communication is stable and reliable.

[0132] Step S8250: Adapt or enable support for the corresponding network protocol packets, establish a distributed soft bus FRU device node that matches the management type of the FRU device node, and realize functions such as self-discovery, authentication connection, heterogeneous networking using all hardware bus channels, and session transmission between device nodes.

[0133] Step S8260: Build a simulated or real-world environment, debug and test whether N FRU device nodes can be obtained through the distributed soft bus method, establish a heterogeneous network of all bus interface channels through authentication, and establish a session between N FRU devices and perform data transmission.

[0134] Step S8270: After passing the distributed soft bus verification and lower-layer protocol reliability test, write or use a general distributed soft bus reliability test method to test the reliability of the distributed soft bus network of FRU device nodes to ensure stable and reliable transmission.

[0135] Step S830: The management function of the FRU device node includes three parts: information collection, status control, and autonomous management. The development steps are as follows:

[0136] Step S8310: Information collection of FRU device nodes is a general basic core function. It usually needs to be developed specifically according to their respective information collection methods. The specific implementation in this embodiment belongs to the application layer and is not subject to specific implementation constraints. It is only used as a process step to illustrate the classification.

[0137] Step S8320: The application layer independently debugs and verifies the implementation of the information collection function and performs reliability testing;

[0138] Step S8330, the status control and autonomous management of FRU device nodes are the same as step S8310, both belonging to the application layer content, and are only used as process steps to reflect the classification, to prepare for the integration with the FRU device management data model corresponding to the FRU device nodes;

[0139] In step S840, after completing the adaptation of the data link layer, network layer, and transport layer, as well as the implementation of specific management functions at the application layer, the FRU device node has completed the reliable hardware access steps.

[0140] like Figure 4The second process (software development process for the management side) requires managing N FRU devices based on specific management needs, while providing a unique user interface for users (such as administrators). This includes the following:

[0141] Step S910: Clarify the types, quantities, and data requirements of the FRU device nodes that need to be managed, and outline the management function requirements;

[0142] The FRU device management data model corresponding to the concrete FRU device node is used as the integration interface between the software and the FRU device node. Therefore, this embodiment includes the development of two parts of software: the first management terminal and the second management terminal.

[0143] Step S920, the specific steps for developing the first management terminal application are as follows:

[0144] Step S9210: Using the virtual tools provided by openHarmony, add virtual distributed soft bus network device nodes, modify device types, establish the data structure of the management data model, and populate test data.

[0145] Step S9220: Develop the FRU device management data model corresponding to the FRU device node: Develop a new or add a general presentation layer FRU device management data model to realize management functions and interfaces such as adding, deleting, querying and modifying the data structure of the FRU device management data model;

[0146] Step S9230, Add RPC management service interface: Adapt or add a general session layer RPC management service model to realize the mutual conversion of data operation interface and various general data operation function RPC calls such as static data read and write, dynamic data read and event data push for the FRU device management data model; used for integration verification of the second management end based on the RPC management service model;

[0147] Step S9240: Add the FRU device management data model of the presentation layer and the RPC management service model of the session layer to the actual FRU device node, and fill the FRU device node with the management functions of the application layer such as information collection, status control and autonomous management, and wait for remote calls.

[0148] Step S9250: Build a simulated or real-world scenario environment and debug and verify the FRU device management data model call based on the actual bus interface;

[0149] Step S930, the development of the second management terminal mainly includes acquiring and managing the FRU device management data model, as well as the interactive management interface for direct or indirect interaction with users. Its implementation steps are as follows:

[0150] Step S9310, Build a virtual development environment: Based on the type, quantity and data requirements of the FRU device nodes to be managed, directly establish a virtual FRU device management data model, which can be directly called to obtain simulated data;

[0151] Step S9320: Based on the virtual development environment, develop application layer software such as management functions and interaction interfaces for the virtual FRU device management data model. After the design is completed, debug and verify the management functions and interfaces based on the virtual environment.

[0152] Step S9330: Integrate the application of the first management terminal based on the virtual development environment, obtain the FRU device management data model by calling the interface of the RPC management service model of the first management terminal, and complete the integration verification of the application.

[0153] Step S9340: Based on the simulated or actual scenario environment, apply RPC calls to obtain data from the actual FRU device nodes, and complete the software and hardware integration of the entire information system management.

[0154] This embodiment has at least the following beneficial effects:

[0155] In the field of FRU device management, a distributed soft bus is introduced to provide an independent and general implementation solution for basic management needs such as device discovery / identification and online / offline detection. The hardware is adapted to the distributed soft bus and no application layer is required to participate in debugging.

[0156] Introducing RPC technology into the FRU management field separates communication transmission processing from the application layer and makes it independent of the session layer. This allows application layer development to be based on the soft bus and oriented towards the management data model, without having to worry about hardware communication debugging.

Claims

1. A method for managing FRU devices based on software-hardware decoupling of a soft bus, characterized in that, It operates within application development systems; The application development system includes: OSI seven-layer architecture; The physical layer in the OSI seven-layer architecture includes: a management device node and at least one FRU device node, both of which have a bus interface; the management device node is used to manage the at least one FRU device node. The transport layer in the OSI seven-layer architecture is equipped with a distributed soft bus. The session layer in the OSI seven-layer architecture is equipped with an RPC framework. The application layer in the OSI seven-layer architecture includes: a first management terminal corresponding to the at least one FRU device node, and a second management terminal corresponding to the management device node; The FRU device management method based on soft bus hardware-software decoupling includes: The communication protocols corresponding to the data link layer to the network layer in the OSI seven-layer architecture, as well as the bus interfaces of the management device node and the at least one FRU device node, are connected to the distributed soft bus to realize the discovery, connection, networking and establishment of transmission channels between the management device node and the at least one FRU device node based on the distributed soft bus; In the first management terminal, at least one FRU device management data model corresponding to the at least one FRU device node in the presentation layer is set, and an RPC management service model in the session layer is set based on the RPC framework. The at least one FRU device management data model and the RPC management service model are associated and integrated into the corresponding at least one FRU device node, so as to realize the management of the at least one FRU device node based on the RPC management service model; the FRU device management data model is used as the data representation in the data communication transmission of the FRU device node.

2. The FRU device management method based on software-hardware decoupling of a soft bus according to claim 1, characterized in that, The step of connecting the communication protocols corresponding to the data link layer to the network layer in the OSI seven-layer architecture, as well as the bus interfaces of the management device node and the at least one FRU device node, to the distributed soft bus to realize the discovery, connection, networking, and establishment of transmission channels between the management device node and the at least one FRU device node based on the distributed soft bus includes: Configure the controller driver package; The bus interface is driven according to the controller driver package to enable data transmission and reception between the management device node and the at least one FRU device node at the data link layer based on the communication protocol corresponding to the data link layer. Configure the network protocol package corresponding to the controller driver package; the network protocol package includes at least the communication protocol corresponding to the network layer; In the distributed soft bus, at least one distributed soft bus FRU device node corresponding to the at least one FRU device node and a distributed soft bus management device node corresponding to the management device node are configured, and the network protocol packet matching is adapted to realize the discovery, connection, networking and establishment of transmission channels between the management device node and the at least one FRU device node.

3. The FRU device management method based on software-hardware decoupling of a soft bus according to claim 2, characterized in that, The method further includes: Configure the first management function of the at least one FRU device node in the first management terminal located in the application layer.

4. The FRU device management method based on software-hardware decoupling of a soft bus according to claim 3, characterized in that, The first management function includes at least information collection, status control, and autonomous management.

5. The FRU device management method based on software-hardware decoupling of a soft bus according to claim 3, characterized in that, Before setting the FRU device management data model corresponding to the at least one FRU device node located in the presentation layer, the method further includes: In the first management terminal, the at least one distributed soft bus FRU device node is associated based on the openHarmony virtual tool; After associating and integrating the at least one FRU device management data model and the RPC management service model to the corresponding at least one FRU device node, the method further includes: The first management terminal manages the at least one FRU device node based on the at least one associated distributed soft bus FRU device node according to the first management function.

6. The FRU device management method based on software-hardware decoupling of a soft bus according to claim 5, characterized in that, The method further includes: In the second management terminal, at least one virtual FRU device node corresponding to the at least one FRU device node is configured; Configure the second management function corresponding to the at least one virtual FRU device node in the second management terminal; In the second management terminal, based on the RPC management service model and the second management function, the management data model of the at least one FRU device is invoked to realize the management of the at least one FRU device node.

7. The FRU device management method based on software-hardware decoupling of a soft bus according to claim 1, characterized in that, The FRU device management data model is a PLDM-based management data model.

8. The FRU device management method based on software-hardware decoupling of a soft bus according to claim 7, characterized in that, The data types included in the FRU device management data model include at least: static readable and writable data, dynamic readable data, control readable and writable data, and event reporting data.

9. The FRU device management method based on software-hardware decoupling of a soft bus according to claim 1, characterized in that, The method further includes: The first management terminal registers general read data functions and write data functions with the RPC management service model; The first management terminal obtains a general event data reporting function from the RPC management service model to actively report data to the second management terminal when an event occurs in at least one FRU device; the general event data reporting function is registered by the second management terminal.

10. The FRU device management method based on software-hardware decoupling of a soft bus according to claim 9, characterized in that, The method further includes: The second management terminal registers a general event data reporting function with the RPC management service model; The second management terminal obtains the general read data function and write data function from the RPC management service model.

Images