CN117055914A - Method for using equipment model and related equipment - Google Patents

Method for using equipment model and related equipment Download PDF

Info

Publication number
CN117055914A
CN117055914A CN202210482512.0A CN202210482512A CN117055914A CN 117055914 A CN117055914 A CN 117055914A CN 202210482512 A CN202210482512 A CN 202210482512A CN 117055914 A CN117055914 A CN 117055914A
Authority
CN
China
Prior art keywords
hardware
devices
network device
description information
hardware model
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210482512.0A
Other languages
Chinese (zh)
Inventor
盛凯
曾南志
陈进
葛宁
张莉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Beihang University
Original Assignee
Huawei Technologies Co Ltd
Beihang University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd, Beihang University filed Critical Huawei Technologies Co Ltd
Priority to CN202210482512.0A priority Critical patent/CN117055914A/en
Publication of CN117055914A publication Critical patent/CN117055914A/en
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates

Abstract

The embodiment of the application discloses a method for using an equipment model and related equipment, which are used for decoupling a software part and a hardware part of network equipment. Comprising the following steps: the network device executes a hardware model data file, the hardware model data file being determined based on hardware model description information describing a hardware system of the network device, the description information including basic attribute information of the devices, composition relationships of the devices, connection relationships of the devices, classification relationships of the devices, and processing logic of the devices. A hardware system in the network device responds to control messages by the service software to one or more devices.

Description

Method for using equipment model and related equipment
Technical Field
The present application relates to the field of communications, and in particular, to a method for using a device model and related devices.
Background
The network device is a whole composed of a software part and a hardware system, the hardware system comprises devices for realizing various functions, and the software part mainly comprises upper business software and device management software. The service software is mainly used for network equipment to realize service functions such as routing, switching and the like, and the equipment management software is mainly used for managing each device in the hardware system.
In the prior art, if a network device changes a device in a hardware system due to update, device management software also needs to be adaptively changed. Furthermore, with the replacement of device management software, business software may also need to be adaptively replaced.
Disclosure of Invention
The application provides a method for using an equipment model and related equipment, which are used for realizing decoupling of a software part and a hardware part of network equipment, reducing the workload of development and maintenance caused by the change of the software part of the network equipment due to the change of a hardware system, and improving the efficiency of the butt joint of the software and the hardware of the network equipment.
The first aspect of the present application provides a method of using a device model:
the network device executes a hardware model data file, the hardware model data file being determined based on hardware model description information, the hardware model description information being used to describe a hardware system of the network device, the hardware model description information including description information of one or more devices in the hardware system of the network device, the description information including basic attribute information of the devices, composition relationships of the devices, connection relationships of the devices, classification relationships of the devices, and processing logic of the devices. The hardware system in the network device then responds to the control messages of the service software for one or more devices.
In the application, because the hardware model data file comprises the description information of each device in the hardware system, when one device A of the network equipment needs to be replaced by the device B, the network equipment can ensure the normal operation of the network equipment only by loading the hardware model data file corresponding to the execution device B. Because the device B uses the format based on the hardware model description information same as the device A, the original device management software on the network device can identify the hardware model description information of the new device B, so that a manager does not need to replace the device management software on the network device, further does not need to replace service software, and further realizes the decoupling of a software part and a hardware system.
In a possible implementation manner, the basic attribute information of the device includes a device identifier, a device type identifier, and a hardware type identifier, where the device identifier is used to identify a device, the device type identifier is used to indicate a type of the device, and the hardware type identifier is used to indicate a hardware characteristic of the device.
In one possible implementation, the types of devices include one or more of the following: a frame, a plugboard, a plug-in card or an interface.
In one possible implementation, the hardware type identifier includes a hardware manufacturer identifier.
In one possible implementation, the devices indicated as being of the same class based on the categorization relation have the same processing logic and/or have the same basic attribute information.
In the application, devices with the same processing logic or the same basic attribute information can be classified into one type through the classification relation, so that the processing logic or the basic attribute information of each device is not required to be defined.
In one possible implementation, the connection relationship includes pin connection or bus connection.
In one possible implementation, the processing logic of the device directs the processing action of the device on one or more events.
In one possible implementation, the hardware model data file is compiled by a compiler from the hardware model description information.
A second aspect of the present application provides a network device comprising a plurality of functional modules, the plurality of functional modules interacting to implement the method of the first aspect. A plurality of functional modules may be implemented based on software, hardware, or a combination of software and hardware, and the plurality of functional modules may be arbitrarily combined or divided based on a specific implementation.
A third aspect of the application provides a network device comprising a processor and a memory, the processor being coupled to the memory, the memory being for storing instructions which, when executed by the memory, cause the network device to perform the method of the first aspect described above.
A fourth aspect of the application provides a computer readable storage medium having stored thereon computer instructions or a program, characterized in that the computer instructions or the program, when executed, cause a computer to perform the method as in the first aspect described above.
A fifth aspect of the application provides a computer program product comprising computer instructions or a program which, when executed, cause a computer to perform a method as in the first aspect described above.
Drawings
FIG. 1a is a schematic diagram of a network device replacement apparatus;
FIG. 1b is a schematic flow diagram of the encoding device management software;
FIG. 2 is a flow chart of the method for obtaining a hardware model data file according to the present application;
FIG. 3 is a schematic diagram of the categorization of devices according to the present application;
FIG. 4a is a flow chart of the present application using a hardware model data file;
FIG. 4b is a diagram illustrating the use of hardware model data files in the present application;
FIG. 5 is a schematic diagram of a MAC chip according to the present application;
FIG. 6 is a schematic diagram of another structure of a MAC chip according to the present application;
FIG. 7 is a schematic diagram of a network device according to the present application;
fig. 8 is a schematic diagram of another architecture of a network device according to the present application.
Detailed Description
Embodiments of the present application will now be described with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all embodiments of the present application. As one of ordinary skill in the art can know, with the development of technology and the appearance of new scenes, the technical scheme provided by the embodiment of the application is also applicable to similar technical problems.
The terms first, second and the like in the description and in the claims and in the above-described figures, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
For the purposes of promoting an understanding of the application, reference will now be made to the relevant concepts related to the application:
the network device in the present application may be, for example, a physical device such as a router, a switch, or a gateway, but may be other physical devices, and is not limited specifically.
Business software: the service software is mainly used for realizing various service capabilities of the network equipment, such as routing, forwarding, connection establishment, switching and the like.
Device management software: the device management software is mainly used for managing each device in the hardware system, and the device management software is used as an adaptation layer between the service software and the hardware system, so that control information of the service software can be accurately executed by each device in the hardware system. So business software may also need to be adaptively replaced when replacement of device management software occurs.
The application can be applied to the development process of the network equipment, referring to fig. 1a, along with the upgrading and updating of the network equipment by manufacturers, the devices inside the network equipment can be replaced. For example, the main control board (main processing unit, MPU) a is replaced with an MPU B, or the line processing unit (line processing unit, LPU) a is replaced with an LPU B. Referring to fig. 1b, in the prior art, the device management software of the network device is encoded based on the actual hardware system and the service requirements of the network device. Therefore, along with the upgrading and updating of the network equipment, manufacturers must rewrite equipment management software for new types of network equipment, and development efficiency is reduced.
The application provides a method and equipment for using an equipment model, which are used for decoupling a software part and a hardware part of network equipment.
Referring to fig. 2, the process of obtaining the hardware model data file in the present application is first described below:
201. acquiring description information of a hardware model;
firstly, aiming at a hardware system of network equipment, acquiring hardware model description information. It should be noted that, the hardware system is the most main physical component of the network device, and includes physical devices with various functions of calculation, control, storage, input, output, and the like. The hardware model description information includes description information of one or more devices in the hardware system. The description information specifically includes basic attribute information of the devices, composition relationships of the devices, connection relationships of the devices, classification relationships of the devices, and processing logic of the devices, and of course, the description information may also include other information, which is not exemplified here too much.
Description information is described below:
1. basic attribute information of the device;
the basic attribute information of the device is used to indicate basic attributes of the device, including, for example, a device identification, a device type identification, and a hardware type identification. The device identifier is used to identify a device, and the device type identifier is used to indicate a type of the device, where the type of the device includes, for example, a subrack, a board, a card, a network processor, an interface, a clock, a power supply, or a fan, but may also include other types, which are not limited herein. The hardware type identifier is used to indicate the hardware characteristics of the device. Illustratively, the basic attribute information of a MAC chip includes a device identifier "MAC a", a device type identifier "MAC", and a hardware type identifier "suppler a", where "suppler a" indicates that the manufacturer of the MAC chip is vendor a. The basic attribute information of another MAC chip includes a device identifier "MAC chip B", a device type identifier "MAC chip", and a hardware type identifier "supplier B". It should be noted that, in addition to indicating the manufacturer, the hardware type identifier may also indicate the production number of the device or other information related to the hardware characteristics. The basic attribute information of some devices may additionally include other content, for example, the basic attribute information of the POS interface further includes information related to link protocol configuration, and the basic attribute information of the ethernet interface further includes information related to MAC address configuration.
The description information of the device may be obtained by describing the device by a target syntax, and the target syntax may be, for example, a bachelor form. The following shows the way in which basic attribute information of a device is described by the bachelus-norm:
one of the MAC chips is:
in the above description, "component MAC {" is used to indicate that the MAC chip is described. "devname=" MAC a "" is used to indicate that the device is identified as "MAC a". "devtype=" MAC "" is used to indicate that the device type identifier is "MAC". "hardtype=" supplier a "is used to indicate that the hardware type identifier is" supplier a ".
The second MAC chip is as follows:
in the above description, "component MAC {" indicates that the MAC chip is described. "devname=" MAC B "indicates that the device is identified as" MAC B ". "devtype=" MAC "" indicates that the device type is identified as "MAC". "hardtype=" supplier B "indicates that the hardware type identifier is" supplier B ".
2. Composition relation and connection relation of devices;
some devices in the network apparatus are often constituted by a plurality of smaller devices, and therefore, for these devices, the composition relationship thereof is described in addition to the basic attribute information. For example, one LPU identified as "LPU X" is composed of a field programmable gate array (field programmable gate array, FPGA), a network processor (network processor, NP), an interface port, a power supply monitor, a clock, and a fan, and describing the composition of LPU X by the bachelson form may be:
component LPU X struct{
FPGA ctrl;
np np;
port frontPort;
vlt vltMonitor;
clk srcClk;
fan fan;
}
in the above description, "component LPU X struct" is used to indicate that the composition relationship of LPU X is described. "FPGA ctrl" is used to indicate that LPU X includes a device whose device type is identified as "FPGA" and whose device is identified as "ctrl". "np" is used to indicate that LPU X includes a device whose device type identification is "np" and whose device identification is "np". "port front port" is used to indicate that LPU X includes a device whose device type is identified as "port" and a device whose device is identified as "front port". "vlt monitor" is used to indicate that LPU X includes a device of device type identification "vlt" and device identification "vlt monitor". "clk srcClk" is used to indicate that LPU X includes a device of device type identification "clk" and a device of device identification "srcClk". "fan fan" is used to indicate that LPU X includes a device whose device type identification is "fan" and whose device identification is "fan".
It should be noted that, in the above example, the device type indicated by "FPGA" is FPAG, the device type indicated by "np" is a network processor, the device type indicated by "port" is an interface, the device type indicated by "vlt" is a power supply, the device type indicated by "clk" is a clock, and the device type indicated by "fan" is a fan. In addition, the connection relationship between devices needs to be described, for example, the connection relationship between pins between devices is described, and the following is an example:
link ctrlbus{
FPGA[0],port[0];
FPGA[1],port[1];
FPGA[2],port[2];
FPGA[3],port[3];
FPGA[4],port[4];
FPGA[5],port[5];
FPGA[6],port[6];
FPGA[7],port[7];
}
in the above description, "link ctrlbus" is used to indicate that the connection relationship is described. "FPGA [0], port [0]" is used to indicate that the No. 0 pin of FPGA is connected with the No. 0 pin of port. "FPGA [1], port [1]" is used to indicate that the FPGA pin 1 is connected with port pin 1. "FPGA [2], port [2]" is used to indicate that the No. 2 pin of FPGA is connected with the No. 2 pin of port. "FPGA [3], port [3]" is used to indicate that pin 3 of FPGA is connected with pin 3 of port. "FPGA [4], port [4]" is used to indicate that the No. 4 pin of FPGA is connected with the No. 4 pin of port. "FPGA [5], port [5]" is used to indicate that the No. 5 pin of FPGA is connected with the No. 5 pin of port. "FPGA [6], port [6]" is used to indicate that the No. 6 pin of FPGA is connected with the No. 6 pin of port. "FPGA [7], port [7]" is used to indicate that pin 7 of FPGA is connected with pin 7 of port.
Alternatively, the above connection relationship may be described in a more concise manner:
link ctrlbus{
FPGA[0:7],port[0:7];
}
in the above description, "link ctrlbus" is used to indicate that the connection relationship is described. "FPGA [0:7], port [0:7]" is used to indicate that pins 0 to 7 of the FPGA are connected with pins 0 to 7 of port in sequence.
The connection relationship of the devices may be connected via a bus, or may be other than the connection relationship of the pins, and is not particularly limited.
3. Processing logic of the device;
the processing logic of the device is embodied as processing actions of the device on one or more events, such as power up, reboot, etc., such as alarms, logging, etc. Illustratively, in one processing logic of a port, an alarm is required when the port is not in place. The manner in which the aforementioned processing logic for a port is described by the Backus-Van is shown below:
in the above description, "component port {" is used to indicate a description port, i.e., a description interface. "Not Available" IS used to indicate that an event that an interface needs to process includes that the interface IS out of place. "alarm=1" is used to indicate that an alarm is triggered when the interface is not in place.
4. Classification of devices.
Individual devices within a network device may be classified into different categories, i.e., each child device belongs to a parent device at a higher level. Referring to fig. 3, an exemplary network device serves as a parent device at the uppermost layer, and a child device at the next level of the network device includes a board. Of course, the sub-devices of the next level of the network device may also include other devices, which are only a simple example here, and thus are not supplementary examples. The LPU and the MPU are different kinds of boards, so that the boards are parent devices of the upper layer of the two sub-devices, i.e., the LPU and the MPU. Of course, the specific manner of dividing the different child devices and parent devices in the network device is not limited, for example, the LPU may also be used as the parent device, and the child devices of the next level include different types of LPUs. The MPU may also be a parent device, with the child devices of the next level including MPUs of different types. The child device may inherit the processing logic and basic attribute information of the parent device, for example, if the processing action of the single board on the reset command is described, and accordingly, the child device LPU and the child device MPU also have the same processing action on the reset command. It should be noted that the basic attribute information and the processing logic of the child device may be identical to those of the parent device, or may be only partially identical, which is not limited in particular.
By way of example, the following illustrates the manner in which the categorization of devices is described by the Backus-Van:
component board inherit device{
}
component LPU inherit board{
}
component MPU inherit board{
}
in the above description, "component board inherit device" is used to indicate that "board" is categorized in "device", i.e., a board is categorized in a network device. "component LPU inherit board" is used to indicate that the LPU is categorized as a single board. "component MPU inherit board" is used to indicate that the MPU is categorized as a single board.
202. Compiling the description information of the hardware model.
After the hardware model description information is obtained, compiling the hardware model description information through a compiler, so that a hardware model data file is obtained.
In the application, because the hardware model data file comprises the description information of each device in the hardware system, when the device of the network equipment needs to be replaced, the normal operation of the network equipment can be ensured only by replacing the corresponding hardware model data file and loading and executing. The equipment management software does not need to be replaced, so that the business software does not need to be replaced, and further decoupling of the software part and the hardware system is realized.
The process of obtaining the hardware model data file in the present application is described above, referring to fig. 4a, the process of using the hardware model data file by the network device in the present application is described below:
401. the network equipment executes the hardware model data file;
referring to fig. 4b, the device management software in the present application is obtained based on service requirement encoding without considering the actual hardware system of the network device. Describing the hardware system to obtain hardware model description information, compiling the hardware model description information to obtain a hardware model data file, and storing the hardware model data file into the network equipment. After the network device is powered on, the network device first needs to complete the initialization of the hardware system, and at this time, the network device loads and executes the hardware model data file and the device management software to initialize the hardware system. It should be noted that, for simplicity of description, the initialization process is described by taking only one device in the hardware system as an example. Illustratively, the network device includes an LPU identified as "LPU a" whose initialization process is described below.
The LPU A internally comprises a MAC chip and an FPGA. Referring to fig. 5, the manufacturer of the MAC chip is manufacturer a, and pin 11 of the MAC chip is connected with pin 0 of the FPGA, and pin 10 of the MAC chip is connected with pin 1 of the FPGA.
The following is basic attribute information about the MAC chip in the LPU a in the hardware model description information:
the information indicated in the above description refers to the related description in the foregoing embodiments, and is not repeated here.
The following is the content of the classification relation of the device in the hardware model description information:
component LPU inherit board{
}
the information indicated in the above description refers to the related description in the foregoing embodiments, and is not repeated here.
The following is the content of the hardware model description information about the composition relationship and connection relationship of the LPU a:
component LPU A struct{
FPGA ctrl;
MAC MAC A;
}
link ctrlbus{
MAC[11],FPGA[0];
MAC[10],FPGA[1];
}
the information indicated in the above description refers to the related description in the foregoing embodiments, and is not repeated here.
The following is the content of the hardware model description information regarding the processing logic of the device:
component board{
Reset(Soft_reset){
log(Soft_reset);
reset();
}
}
in the above description, "component board {" is used to indicate that a board is described. "Reset" is used to indicate that the events that the board needs to handle include a restart. "log (soft_reset)" and "reset ()" are used to indicate that the processing action of the board for restarting this event is logged first, followed by restarting.
It should be understood that the foregoing is only a part of the description information of the hardware model, and the present application is only for simplicity of description and not all shown, and the foregoing should not be construed as limiting the present application.
The process of initializing the LPU a includes steps a01 to a02:
a01, establishing a control channel;
it should be appreciated that the initialization process of the LPU a is implemented by executing device management software and hardware model data files. The network device first reads the description information about the LPU a in the hardware model data file. The description information of the LPU A comprises the composition relation of the LPU A, and the network equipment determines that the LPU A internally comprises a MAC chip and an FPGA based on the composition relation of the LPU A. And the network equipment determines the pin connection mode of the MAC chip and the FPGA based on the connection relation, and establishes a control channel of the FPGA to the MAC chip based on the pin connection mode of the MAC chip and the FPGA. Specifically, since the pin 11 of the MAC chip is connected with the pin 0 of the FPGA, the pin 10 of the MAC chip is connected with the pin 1 of the FPGA. Therefore, a control channel is established between the No. 0 pin of the FPGA and the No. 11 pin of the MAC chip, and a control channel is established between the No. 1 pin of the FPGA and the No. 10 pin of the MAC chip. Then, the network device establishes a control channel between the FPGA and other devices based on the connection relationship, which will not be described herein.
A02, loading a driver program to finish initialization.
The network equipment sequentially acquires basic attribute information of each device on the LPU A based on the composition relation of the LPU A. For example, basic attribute information of the MAC chip is acquired, where the basic attribute information of the MAC chip includes a hardware type identifier "supplier a". Based on the hardware type identifier, the network device loads the driving software corresponding to the manufacturer A, thereby completing initialization. It should be noted that, the manner of initializing other devices on the network device is similar to that of initializing the LPU a, and will not be repeated here.
The hardware system of the network device may respond to control messages of the service software to one or more devices after the initialization is completed. With continued reference to fig. 4a, the following description is provided.
402. A hardware system in the network device responds to control messages by the service software to one or more devices.
For example, after all the devices on the LPU a complete initialization, if the service software instructs the board to restart, the service software sends a control message for restarting the board to the hardware system of the network device, and the hardware system of the network device receives the control message, then the network device determines that the LPU a needs to restart based on the classification relationship of the devices. And determining, according to processing logic of the LPU a, that the LPU a needs to record a restart reason, and finally restarting the LPU a as a response to the control message. Of course, the above is only a simple example and should not be construed as a practical limitation. The manner of other devices in the hardware system responding to the control message of the service software is similar to the operation of the LPU a, and detailed description thereof is omitted.
The manner in which the hardware model data file is obtained and the network device operates based on the hardware model data file is described above. When the network device needs to be upgraded, i.e. the internal devices are replaced. Only the hardware model data file corresponding to the network equipment after upgrading and updating is acquired, and the hardware model data file is stored in the network equipment after upgrading and updating. The service software and the device management software of the original network device can be directly used in the network device after upgrading and updating, and the following detailed description is given:
the network device after upgrading and updating is different from the original network device only in that the LPU with the device identified as "LPU B" in the network device after upgrading and updating is replaced by the LPU with the device identified as "LPU a" in the original network device. Also, in the LPU B, a MAC chip and an FPGA are included, and referring to fig. 6, the manufacturer of the MAC chip is manufacturer B. And the No. 22 pin of the MAC chip is connected with the No. 3 pin of the FPGA, and the No. 23 pin of the MAC chip is connected with the No. 2 pin of the FPGA.
Correspondingly, the following is basic attribute information about the MAC chip in the LPU B in the hardware model description information:
the following is the content of the classification relation of the device in the hardware model description information:
component LPU inherit board{
}
the following is the content of the hardware model description information about the composition relationship and connection relationship of LPU B:
component LPU B struct{
FPGA ctrl;
MAC MAC B;
}
link ctrlbus{
MAC[23],FPGA[2];
MAC[22],FPGA[3];
}
the following is the content of the hardware model description information regarding the processing logic of the device:
component board{
Reset(Soft_reset){
log(Soft_reset);
reset();
}
}
it should be noted that, compared with the original network device, only the composition relationship, connection relationship and basic attribute information of the MAC chip related to the LPU B in the hardware description information of the network device after upgrading and upgrading need to be modified along with the change of the hardware, and other descriptions need not be modified. Therefore, after the original hardware description information is simply modified, the compiled hardware model data file can be adapted to the network equipment after upgrading and updating.
The following describes a procedure of using a hardware model data file by an updated network device:
b01, the network equipment executes the hardware model data file;
after the network device is powered on, the hardware model data file and the device management software are executed so as to initialize the hardware system. The initialization process will still be described taking LPU B in the network device as an example.
The network device first reads the description information about LPU B in the hardware model data file. The description information of the LPU B comprises the composition relation of the LPU B, and the network equipment determines that the LPU B internally comprises a MAC chip and an FPGA based on the composition relation of the LPU B. And the network equipment determines the pin connection mode of the MAC chip and the FPGA based on the connection relation, and establishes a control channel of the FPGA to the MAC chip based on the pin connection mode of the MAC chip and the FPGA. Specifically, since the pin 23 of the MAC chip is connected with the pin 2 of the FPGA, the pin 22 of the MAC chip is connected with the pin 3 of the FPGA. Therefore, a control channel is established between the No. 2 pin of the FPGA and the No. 23 pin of the MAC chip, and a control channel is established between the No. 3 pin of the FPGA and the No. 22 pin of the MAC chip. Then, the network device establishes a control channel between the FPGA and other devices based on the connection relationship, which will not be described herein.
The network equipment sequentially acquires basic attribute information of each device on the LPU B based on the composition relation of the LPU B. For example, basic attribute information of the MAC chip is acquired, where the basic attribute information of the MAC chip includes a hardware type identifier "supplier B". Based on the hardware type identifier, the network device loads the driving software corresponding to the manufacturer B, thereby completing initialization. It should be noted that, the manner of initializing other devices on the network device is similar to that of initializing the LPU B, and will not be repeated here.
B02, the hardware system of the network equipment responds to the control message of the service software to one or more devices.
For example, after all the devices on the LPU B are initialized, if the service software instructs the board to restart, the service software sends a control message for restarting the board to the hardware system of the network device, and the hardware system of the network device receives the control message, so that the network device determines that the LPU B needs to restart based on the classification relationship of the devices. And determining, according to processing logic of the LPU B, that the LPU B needs to record a restart reason, and finally restarting the LPU B as a response to the control message.
In the application, after the network equipment is updated, only the adaptive hardware model data file is needed to be replaced, and the equipment management software and the service software are not needed to be replaced. And because the workload of replacing the adaptive hardware model data file is not great, the development efficiency of the network equipment can be improved, and the marketing period can be shortened.
The method of using the device model in the embodiment of the present application is described above, and the device in the present application is described below:
referring to fig. 7, a network device 700 of the present application includes an execution unit 701 and a response unit 702. The network device 700 is used to implement the methods of the various embodiments described above.
An execution unit 701, configured to execute a hardware model data file, where the hardware model data file is determined based on hardware model description information, where the hardware model description information is used to describe a hardware system of the network device, and the hardware model description information includes description information of one or more devices in the hardware system of the network device, where the description information includes basic attribute information of the devices, a composition relationship of the devices, a connection relationship of the devices, a classification relationship of the devices, and processing logic of the devices.
A response unit 702, configured to respond to control messages of the service software to one or more devices.
In one possible implementation of the present application,
the basic attribute information of the device includes a device identifier for identifying a device, a device type identifier for indicating the kind of the device, and a hardware type identifier for indicating the hardware characteristics of the device.
In one possible implementation of the present application,
the types of devices include one or more of the following: a frame, a plugboard, a plug-in card or an interface.
In one possible implementation of the present application,
the hardware type identifier includes a hardware manufacturer identifier.
In one possible implementation of the present application,
the categorization relationship indicates that devices of the same class have the same processing logic and/or have the same basic attribute information.
In one possible implementation of the present application,
the connection relationship includes a pin connection manner or a bus connection.
In one possible implementation of the present application,
the processing logic of the device directs the processing action of the device on one or more events.
In one possible implementation of the present application,
the hardware model data file is compiled by a compiler from the hardware model description information.
Fig. 8 is a schematic structural diagram of a network device according to the present application, where the network device is configured to implement the method in the foregoing embodiments. The network device 800 may include one or more central processing units (central processing units, CPU) 801 and memory 805, where the memory 805 stores one or more application programs or data.
Wherein the memory 805 may be volatile storage or persistent storage. The program stored in the memory 805 may include one or more modules, each of which may include a series of instruction operations in a server. Still further, the central processor 801 may be arranged to communicate with the memory 805 to execute a series of instruction operations in the memory 805 on the network device 800.
It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.
In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in part or all of the technical solution or in part in the form of a software product stored in a storage medium, including instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (RAM, random access memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

Claims (19)

1. A method of using a device model, comprising:
executing a hardware model data file by the network equipment, wherein the hardware model data file is determined based on hardware model description information, the hardware model description information is used for describing a hardware system of the network equipment, the hardware model description information comprises description information of one or more devices in the hardware system of the network equipment, and the description information comprises basic attribute information of the devices, composition relations of the devices, connection relations of the devices, classification relations of the devices and processing logic of the devices;
the hardware system in the network device responds to control messages of the service software to the one or more devices.
2. The method of claim 1, wherein the basic attribute information of the device includes a device identifier for identifying one device, a device type identifier for indicating a kind of the device, and a hardware type identifier for indicating a hardware characteristic of the device.
3. The method of claim 2, wherein the class of devices comprises one or more of: a frame, a plugboard, a plug-in card or an interface.
4. A method according to claim 2 or 3, wherein the hardware type identification comprises a hardware manufacturer identification.
5. The method of claim 4, wherein devices indicated as being of a same class based on the categorization relation have the same processing logic and/or have the same basic attribute information.
6. The method of claim 5, wherein the connection relationship comprises a pin connection or a bus connection.
7. The method of claim 1 or 5, wherein the processing logic of the device directs the processing action of the device on one or more events.
8. The method according to any one of claims 1 to 7, wherein the hardware model data file is compiled by a compiler from the hardware model description information.
9. A network device, comprising:
an execution unit configured to execute a hardware model data file, where the hardware model data file is determined based on hardware model description information, where the hardware model description information is used to describe a hardware system of the network device, and the hardware model description information includes description information of one or more devices in the hardware system of the network device, where the description information includes basic attribute information of the devices, a composition relationship of the devices, a connection relationship of the devices, a classification relationship of the devices, and processing logic of the devices;
and the response unit is used for responding to the control message of the business software to the one or more devices.
10. The network device of claim 9, wherein the basic attribute information of the device includes a device identifier for identifying one device, a device type identifier for indicating a kind of the device, and a hardware type identifier for indicating a hardware characteristic of the device.
11. The network device of claim 10, wherein the class of devices includes one or more of: a frame, a plugboard, a plug-in card or an interface.
12. The network device of claim 10 or 11, wherein the hardware type identifier comprises a hardware manufacturer identifier.
13. The network device of claim 12, wherein devices indicated as being of a same class based on the categorization relation have the same processing logic and/or have the same basic attribute information.
14. The network device of claim 13, wherein the connection relationship comprises a pin connection or a bus connection.
15. The network device of claim 9 or 13, wherein the processing logic of the device directs the processing action of the device on one or more events.
16. The network device according to any one of claims 9 to 15, wherein the hardware model data file is compiled by a compiler from the hardware model description information.
17. A network device comprising a processor and a memory, the processor being coupled with the memory, the memory for storing instructions that, when executed by the memory, cause the network device to perform the method of any one of claims 1 to 8.
18. A computer readable storage medium having stored thereon computer instructions or programs, which when executed, cause a computer to perform the method of any of claims 1 to 8.
19. A computer program product comprising computer instructions or a program which, when executed, cause a computer to perform the method of any of claims 1 to 8.
CN202210482512.0A 2022-05-05 2022-05-05 Method for using equipment model and related equipment Pending CN117055914A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210482512.0A CN117055914A (en) 2022-05-05 2022-05-05 Method for using equipment model and related equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210482512.0A CN117055914A (en) 2022-05-05 2022-05-05 Method for using equipment model and related equipment

Publications (1)

Publication Number Publication Date
CN117055914A true CN117055914A (en) 2023-11-14

Family

ID=88661320

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210482512.0A Pending CN117055914A (en) 2022-05-05 2022-05-05 Method for using equipment model and related equipment

Country Status (1)

Country Link
CN (1) CN117055914A (en)

Similar Documents

Publication Publication Date Title
US10700932B2 (en) Automated standalone bootstrapping of hardware inventory
US11842052B2 (en) Method and apparatus for fine tuning and optimizing NVMe-oF SSDs
US10868862B2 (en) System and method for policy based fibre channel zoning based on storage ports and bus adaptors
US9137111B2 (en) Discovering, validating, and configuring hardware-inventory components
TWI240184B (en) System, method, computer readable storage medium and state engine to automate the management of computer services and programmable devices
US7787456B2 (en) Checking and repairing a network configuration
CN102541606B (en) Collocation method and the device of BIOS is remotely managed based on UEFI
US20100071066A1 (en) System, method and program product for dynamically performing an audit and security compliance validation in an operating environment
CA2504333A1 (en) Programming and development infrastructure for an autonomic element
US11005735B1 (en) Configuration system and method for an integrated computing system
CN106716926B (en) Automated stand-alone boot circuit for hardware inventory
US7401238B2 (en) System and method for causing an idle image to execute on an application node of a distributed computing system when instructed to power down
CN108737499A (en) server configuration method and device
US20180082066A1 (en) Secure data erasure in hyperscale computing systems
US20060114923A1 (en) Disaggregated star platform management bus architecture system
CN117055914A (en) Method for using equipment model and related equipment
CN113805950A (en) Method for managing server by cluster management system
US20050132039A1 (en) Data processing system with automatable administration and method for automated administration of a data processing system
JP2008287699A (en) Extensible system for network discovery
US20240134656A1 (en) Self-contained worker orchestrator in a distributed system
US20240111579A1 (en) Termination of sidecar containers
CN115878413A (en) Hardware monitoring method and device, electronic equipment and storage medium
White et al. Design of an Autonomic Element for Server Management
CN117834414A (en) Cloud resource nano tube assembly based on Sidecar mode
NL1030644C2 (en) Automated information component usage control method for information technology infrastructure, involves generating linkage data indicating link between logical and virtual information technology services based on technical service

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication