CN111414202B - Hardware operation management method, system, management subsystem, electronic device and storage medium - Google Patents
Hardware operation management method, system, management subsystem, electronic device and storage medium Download PDFInfo
- Publication number
- CN111414202B CN111414202B CN202010172580.8A CN202010172580A CN111414202B CN 111414202 B CN111414202 B CN 111414202B CN 202010172580 A CN202010172580 A CN 202010172580A CN 111414202 B CN111414202 B CN 111414202B
- Authority
- CN
- China
- Prior art keywords
- hardware
- driving
- module
- drive
- parameters
- 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1438—Restarting or rejuvenating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
- G06F9/4451—User profiles; Roaming
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
The invention relates to a hardware operation management method, which comprises the following steps: receiving hardware information of at least one hardware device; retrieving from a hardware drive adaptation queue according to the hardware information and judging whether a corresponding drive adaptation module exists; if the corresponding drive adaptation module does not exist, a new drive adaptation module is created according to the first mapping relation and is added into the hardware drive adaptation queue; and if the corresponding drive adaptation module exists, retrieving the required hardware drive parameter through a second mapping relation according to the hardware information by the drive adaptation module, and operating the hardware drive module according to the hardware drive parameter. The invention relates to a hardware operation management system, which comprises a hardware driving subsystem and a hardware management subsystem, wherein the hardware driving subsystem comprises a plurality of extensible hardware driving modules. The invention provides a hardware operation management method, a system, a management subsystem, electronic equipment and a storage medium aiming at the problems of the existing products, hardware parameters are simply and conveniently updated, hardware drive is conveniently operated, the hardware drive is efficiently managed, and meanwhile, the expansion support of new hardware equipment can be quickly adapted.
Description
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a hardware operation management method, a hardware operation management system, a hardware operation management subsystem, an electronic device, and a storage medium.
Background
In the field of robotics, various robots are often customized, and the customized robots require the configuration of various hardware peripherals.
As the variety of the peripheral hardware is increased, and the configuration environment and parameters of the hardware are also increased, the following problems are generally encountered when the hardware is driven:
1. the configuration is complicated. The following general method is to configure a hardware operating environment first, then configure hardware parameters, and configure the hardware parameters usually by the following two ways, one is to modify a configuration file directly, and the other is to modify configuration parameters solidified in advance in a program again, and then regenerate a new program; both of these methods require manual configuration of the dependent environment and then running of the hardware driver, which are complicated and cumbersome.
2. The operation is complicated. Running a hardware driver requires the following steps: the dependent environment is manually configured, then the hardware driver is operated, and if the hardware driver is abnormal or the configuration parameters are updated, the hardware driver needs to be manually started again, which is a tedious process.
3. The expansion support is poor, the expansion support of the hardware peripheral is quickly adapted, the drive of new hardware is usually developed firstly, then the hardware environment is configured manually, and then the hardware drive is started manually, so that the adaptation of the new hardware needs more work, general personnel are required to be familiar with the flow and the service, and the time of the expansion support is long;
in the prior art, the operation environment and parameters for updating hardware are complex, the process for operating hardware drivers is complex, the operation efficiency for managing hardware drivers is not high, and the hardware drivers cannot be quickly adapted to the expansion support of new hardware.
Disclosure of Invention
The invention provides a hardware operation management method, a system, a management subsystem, electronic equipment and a storage medium aiming at the problems of the existing products, hardware parameters are simply and conveniently updated, hardware drive is conveniently operated, the hardware drive is efficiently managed, and meanwhile, the expansion support of new hardware equipment can be quickly adapted.
The invention relates to a hardware operation management method, which comprises the following steps:
receiving hardware information of at least one hardware device;
retrieving from a hardware drive adaptation queue according to the hardware information and judging whether a corresponding drive adaptation module exists;
if the corresponding drive adaptation module does not exist, a new drive adaptation module is created according to the first mapping relation and added into the hardware drive adaptation queue;
if there is a corresponding drive adaptation module present,
and retrieving the required hardware driving parameters through a second mapping relation according to the hardware information by the driving adaptation module, and operating the hardware driving module according to the hardware driving parameters.
Preferably, the hardware driving parameter includes a driving command, which is a start parameter, an update parameter or a disable parameter, and may also include an operating environment.
Preferably, when the driving command is a start parameter, the driving adaptation module retrieves a required hardware driving parameter according to hardware information, and asynchronously operating the hardware driving module according to the hardware driving parameter includes the following steps:
the drive adaptation module retrieves the current hardware operating environment parameter from the hardware drive adaptation queue according to the hardware information, and initializes the operating environment of the hardware drive module according to the environment parameter;
the drive adaptation module retrieves the required starting parameters according to the hardware information;
asynchronously operating a starting hardware driving module according to the starting parameters;
and continuously detecting the running state of the hardware driving module in the running process, if the hardware driving module is abnormal or quits normally, starting the driving adaptation module again, and reporting the current state.
Preferably, when the driving command includes an update parameter, the method further includes the following steps:
the drive adaptation module retrieves the required update parameters according to the hardware information;
closing the hardware driving module according to the updating parameter; initializing the running environment of the hardware driving module, updating the hardware driving module according to the updating parameters, and restarting the hardware driving module.
Preferably, before initializing the operating environment of the hardware driver module, the method further includes the following steps: and the drive adaptation module retrieves the current hardware operating environment parameters according to the hardware information.
Preferably, when the driving command is a disable parameter, the driving adaptation module retrieves a required hardware driving parameter according to hardware information, and asynchronously operating the hardware driving module according to the hardware driving parameter includes the following steps:
the drive adaptation module retrieves the required forbidden parameters according to the hardware information;
and closing the hardware driving module according to the forbidden parameters, and removing the driving adaptation module from the hardware driving adaptation queue.
Preferably, when the hardware driver module is updated, the first mapping relationship or the second mapping relationship may be modified in a hardware configuration file manner.
Preferably, if there is no corresponding driver adaptation module, creating a new driver adaptation module according to the first mapping relationship, and adding the new driver adaptation module into the hardware driver adaptation queue, including the following steps:
if the corresponding drive adaptation module does not exist, retrieving and taking out the corresponding drive adaptation module from the hardware adapter buffer pool according to the hardware information, and putting the drive adaptation module into a hardware drive adaptation queue, wherein the hardware adapter buffer pool is used for temporarily storing the idle drive adaptation module.
Preferably, the hardware information includes a unique identification.
Preferably, the unique identification includes a hardware ID or a hardware type.
The invention relates to an electronic device, comprising a memory; and a program, wherein the program is stored in the memory and configured to be executed by the processor, the program comprising instructions for carrying out the method of any one of claims 1-10.
The invention relates to a computer-readable storage medium, on which a computer program is stored, which computer program is executed by a processor for performing the method.
The invention relates to a hardware management subsystem, which comprises a service layer and a drive adaptation layer; the service layer comprises a parameter service module and a drive service module; the parameter service module is a service node of all parameters and is used for managing all parameters and data; the drive service module is used for managing the starting of hardware; the drive adaptation layer comprises a plurality of drive adaptation modules.
Preferably, the service layer further includes a status monitoring module, and the status monitoring module is configured to monitor operation of the hardware.
Preferably, the service layer further includes a hardware adapter buffer pool, where the hardware adapter buffer pool is used to temporarily store idle driver adaptation modules, and the driver adaptation modules are generated according to a first mapping relationship preset, or are recovered from the hardware driver adaptation queue.
The invention relates to a hardware operation management system, which comprises a hardware driving subsystem and a hardware management subsystem, wherein the hardware driving subsystem comprises a plurality of extensible hardware driving modules.
After adopting the structure, compared with the prior art, the invention has the following advantages:
the invention solves the problem that the corresponding drive adaptation module can not be found when the hardware installs new hardware equipment, and the tie is not good, and the configuration environment and parameters of the updated hardware are very complicated. The invention adopts the first mapping relation and the second mapping relation, and can directly retrieve the corresponding drive adaptation module and the corresponding hardware drive parameter through the first mapping relation and the second mapping relation without manual modification one by one.
Meanwhile, the hardware driving subsystem comprises a plurality of extensible hardware driving modules, and the hardware driving modules are independently divided, so that the expansion support of the adaptive hardware equipment is more flexible and faster.
Drawings
FIG. 1 is a hardware operating system framework diagram of the present invention;
FIG. 2 is a hardware operating hierarchy of the present invention;
FIG. 3 is a hardware parameter framework diagram of the present invention;
FIG. 4 is a flow chart of hardware interaction of the present invention;
FIG. 5 is a hardware parameter map of the present invention;
FIG. 6 is a flow chart of the hardware operation of the present invention;
FIG. 7 is a block diagram of the driver service module and the hardware adapter buffer pool of the service layer of the present invention.
Detailed Description
The present invention will be further described with reference to the accompanying drawings and the detailed description, and it should be noted that any combination of the embodiments or technical features described below can be used to form a new embodiment without conflict.
In the robot industry, a robot is integrated with software and hardware, functions are divided, and the hardware or software functions can be modularized, aiming at the characteristics, the invention provides a robot hardware operation management method for managing software and hardware modules, as shown in figure 1, the robot hardware operation management method comprises a hardware management subsystem, a hardware configuration subsystem and a hardware driving subsystem, wherein a system is arranged at an equipment end, such as an equipment personnel computer, and the robot operation management system is arranged at a robot body; wherein the content of the first and second substances,
the hardware configuration subsystem is a front-end system used for displaying and updating hardware configuration parameters. The hardware management subsystem is a front-end interface of the hardware management subsystem, input end data come from hardware configuration parameters of the hardware operation management system, and output end data are hardware configuration update parameters of the hardware operation management system.
The hardware management subsystem is used for managing hardware operation and is a back-end system. The method mainly comprises the steps of setting a starting environment, running a hardware driver, monitoring hardware running, interacting hardware configuration parameters with a hardware configuration system, receiving a hardware configuration file, hardware memory parameters and the parameters of the hardware configuration system by an input end, and outputting the running hardware configuration parameters by an output end.
The invention relates to a hardware management subsystem, which comprises a service layer and a drive adaptation layer; the service layer comprises a parameter service module and a drive service module; the parameter service module is a service node of all parameters and is used for managing all parameters and data; the drive service module is used for managing the starting of hardware; the drive adaptation layer comprises a plurality of drive adaptation modules.
Preferably, the service layer further includes a status monitoring module, and the status monitoring module is configured to monitor operation of the hardware.
The invention relates to a hardware operation management system, which comprises a hardware driving subsystem and a hardware management subsystem, wherein the hardware driving subsystem comprises a plurality of extensible hardware driving modules.
The hardware driving subsystem is a driving set of hardware and is used for driving the normal operation of the hardware, and comprises a motor board, an IO board, a laser, a camera and the like, wherein the input end receives parameters of the hardware operation management system, and the output end outputs hardware data.
The hardware management subsystem, as shown in fig. 2, may be divided into a communication interface layer, a service layer, and a driver adaptation layer. The communication interface layer provides ROS communication, JRPC communication and extensible RPC communication, and a uniform interface layer is arranged below the communication interface layer and used for providing uniform interface data for the communication interface layer; the service layer comprises a parameter service module, a driving service module, a monitoring service module and the like; the drive adaptation layer is mainly used for providing hardware environment setting and hardware drive starting and comprises common nodes, ROS nodes and future extensible nodes, and the nodes uniformly use multi-process management; the driving layer is mainly used for driving robot hardware peripherals and comprises a motor board, an IO board, a laser, a camera, a carrier and the like.
The service layer mainly comprises a parameter service module, a drive service module and a state monitoring module; the parameter service module is a service node of all parameters and is used for managing all parameters and data; the drive service module is mainly used for managing the starting of hardware; the state monitoring module is mainly used for monitoring the operation of hardware.
The parameter service module adopts a target theme and observer mode, as shown in fig. 3, event change between the target theme and the observer mode is in a push-pull mode, when an event occurs, the target theme firstly traverses all current registered observers, and then notifies the registered observers of the event; when the observer changes, the change event is firstly notified to the target theme, the target theme traverses all current registered observers, and then whether the current change event is pushed to each registered observer is determined according to the state of each current observer; each observer receives the event change signal and then processes the event. The service can be more modularized, for example, the parameter transmission between the parameter service module and the driving service module is more timely.
Referring to fig. 3-4, the parameter service module includes a parameter service center sub-module, a parameter analysis sub-module, which is a target topic, and the parameter analysis sub-module and the hardware driving service module are both observers, and the notification event includes a parameter change event that first loads hardware parameter information from a configuration file, an update parameter calling interface of the hardware configuration system, and other externally provided update interfaces. After a program is started, a hardware parameter service module firstly reads current hardware parameters from a local configuration file, a hardware parameter analysis module is responsible for analyzing the current hardware parameters and converting configuration file information into available information inside a current hardware operation management system, then the hardware parameter service module pushes analyzed signals and hardware parameter information to other parameter calibration modules, the calibration parameter service module loads the current parameters into a parameter buffer server so that other people can directly use the parameters through an interface, meanwhile, the hardware parameter service module pushes current update change signals and updated information to a hardware driving service module again, the hardware driving service module pushes the current analyzed hardware parameters to a proper hardware adaptation module, and then hardware driving is started.
The following is the basic flow that the hardware runs, as shown in FIG. 6:
the parameter service module analyzes the hardware parameters and informs the drive service module, and the drive service module can manage the running of the hardware according to the hardware ID and the hardware type of the parameters, including the setting depending on the environment, the running of the hardware drive and the updating.
The invention relates to a hardware operation management method, which comprises the following steps:
receiving hardware information of at least one hardware device;
retrieving from a hardware drive adaptation queue according to the hardware information and judging whether a corresponding drive adaptation module exists;
if the corresponding driving adaptation module does not exist, a new driving adaptation module is created according to the first mapping relation; the first mapping relation is the mapping relation between the hardware information and the drive adaptation module.
If there is a corresponding drive adaptation module present,
and searching the required hardware driving parameters through a second mapping relation according to the hardware information by the driving adaptation module, and operating the hardware driving module according to the hardware driving parameters. The second mapping relationship is the mapping relationship between the hardware information and the hardware driving parameter.
The first mapping relation and the second mapping relation comprise mapping relations prestored in the program and mapping relations loaded into the program from a configuration file. The first mapping relationship and the second mapping relationship may exist in the same internal map.
Preferably, the hardware driving parameter includes a driving command, which is a start parameter, an update parameter or a disable parameter, and may also include an operating environment.
Preferably, when the driving command is a start parameter, the driving adaptation module retrieves a required hardware driving parameter according to hardware information, and asynchronously operating the hardware driving module according to the hardware driving parameter includes the following steps:
the drive adaptation module retrieves the current hardware operating environment parameter from the hardware drive adaptation queue according to the hardware information, and initializes the operating environment of the hardware drive module according to the environment parameter;
the drive adaptation module retrieves the required starting parameters according to the hardware information;
asynchronously operating a starting hardware driving module according to the starting parameters;
and continuously detecting the running state of the hardware driving module in the running process, if the hardware driving module is abnormal or quits normally, starting the driving adaptation module again, and reporting the current state.
Preferably, when the driving command includes an update parameter, the method further includes the following steps:
the drive adaptation module retrieves the required update parameters according to the hardware information;
closing the hardware driving module according to the updated parameters; initializing the running environment of the hardware driving module, updating the hardware driving module according to the updating parameters, and restarting the hardware driving module.
Preferably, before initializing the operating environment of the hardware driver module in the step, the method further includes the following steps: and the drive adaptation module retrieves the current hardware operating environment parameters according to the hardware information.
Preferably, when the driving command is a disable parameter, the driving adaptation module retrieves a required hardware driving parameter according to hardware information, and asynchronously operating the hardware driving module according to the hardware driving parameter includes the following steps:
the drive adaptation module retrieves the required forbidden parameters according to the hardware information;
and closing the hardware driving module according to the forbidden parameters, and removing the driving adaptation module from the hardware driving adaptation queue.
Preferably, when the hardware driver module is updated, the first mapping relationship or the second mapping relationship may be modified in a hardware configuration file manner.
Preferably, the hardware information includes a unique identification.
Preferably, the unique identification includes a hardware ID or a hardware type.
The invention relates to an electronic device, comprising a memory; and a program, wherein the program is stored in the memory and configured to be executed by the processor, the program comprising instructions for carrying out the method of any one of claims 1-10.
The invention relates to a computer-readable storage medium, on which a computer program is stored, which computer program is executed by a processor for performing the method.
The first embodiment is as follows:
the hardware operation management method relates to a specific hardware operation flow, for example, as shown in fig. 3, after a hardware parameter is pushed to a driver service module, the driver service module first searches whether a driver adaptation module exists according to a hardware ID; if the driver adaptation module does not exist, a new hardware adaptation module is created, the hardware adaptation module is created according to the hardware type, the hardware type comprises a main type and a sub type, an internal mapping table of a first mapping relation between the hardware type and the hardware adaptation module is buffered after a program is started, as shown in fig. 5, the hardware adaptation module is automatically matched according to the hardware type through the first mapping relation in the internal mapping table, and the hardware adaptation module is created. Firstly, environment parameters of current hardware operation are obtained according to hardware type retrieval, for example, a laser can automatically set a local network card IP (Internet protocol) connected with the current hardware, then required starting parameters (the name of the driving process and the driving operation) are retrieved from an internal mapping table with a second mapping relation according to the hardware type, then the hardware driving process is asynchronously started, the execution condition of a hardware driving process module can be continuously detected in the operation process, if abnormal or normal exit occurs, the driving adaptation module can try to start again, and the current state is reported;
if the driver adaptation module exists, the execution condition of the hardware driver adaptation module is determined according to the update state of the current hardware parameter: if the hardware driver is in the disabled or closed state, the operation of the current hardware driver module is closed firstly, and then the hardware driver module is removed from the hardware driver adaptation retrieval queue; if the hardware driving parameters are updated, the hardware driving module is closed, the hardware driving module is restarted after the parameters are updated, the running environment is initialized again before restarting, the hardware driving is run, and the execution state of the current hardware driving is continuously monitored.
In this embodiment, the first mapping relationship and the second mapping relationship exist in the same internal mapping table.
Example two:
after the hardware operation management system is started, firstly, analyzing local configuration parameters in a parameter service module, retrieving current hardware parameters from a local configuration file according to the parameter types, basically consistent with the hardware type shown in fig. 5, including the hardware type, the hardware attributes and the default configuration of hardware, after the retrieval is completed, the parameter service module completes parameter encapsulation, and transmits the parameters to a drive service module, the drive service module retrieves whether the current hardware adaptation module exists according to the current hardware type and the hardware ID, the processing flow is basically consistent with the embodiment, then the hardware parameters are transmitted to the corresponding drive adaptation module, then, the setting of a hardware environment is performed according to the transmitted parameters, the parameters set by the hardware environment are the same hardware parameters retrieved according to the local configuration file, then, according to the hardware type, the hardware configuration starting parameter file is read again from a local configuration directory, if the hardware configuration starting parameter is shown in fig. 5, if the common process node starting parameter is shown in fig. 6, then, the hardware driving adaptation module dynamically replaces the parameters of the hardware parameter service module into the current starting parameters, then, the hardware driving process is started again, if the hardware starting parameter is shown in fig. 5, if the hardware driving parameters are failed, the hardware driving process, the hardware driving module can attempt to be consistent with the current operation mode, and the hardware driving state code is not reported.
A robot hardware configuration system, as shown in fig. 5, is a front-end interface of the hardware operating system, which is used to display and update parameters of hardware configuration, and the hardware operating system is a back-end system; when the configuration of the back-end system is displayed, firstly, the hardware configuration data is requested from the hardware operation system, and the data is displayed on a front-end interface after being analyzed; when the hardware configuration parameters are modified, the hardware data to be modified are combined into a uniform format and then sent to the hardware operating system, and the hardware operating system receives the data and then analyzes the hardware parameters, and starts or updates the driver and other parameter configurations of the hardware.
The first embodiment of the combination:
under the condition that the number of the current hardware peripherals is more and more, the configuration parameters of the hardware are more and more, and the general people generally configure the hardware parameters by modifying the configuration files or solidifying the configuration parameters in the program in advance, so that the modification of the parameters is complicated work. The hardware configuration system is responsible for interfacing and visualizing the parameters of the hardware operation management system, non-professionals only need to open a front-end page of the hardware configuration system, when the hardware configuration parameters are displayed, hardware data can be displayed on the front-end interface only by requesting the hardware data from the hardware operation system, and the detailed configuration parameters of each hardware can be checked in time; when the hardware parameters are modified, the modification of the sub-item parameters can be completed only by finding the corresponding hardware on the front-end interface, so that the use convenience of non-developers is greatly simplified and facilitated.
The method comprises the steps that normal hardware drive runs, generally, a hardware running environment needs to be set manually, the hardware drive is started manually, people need to start again manually under an abnormal condition, and the hardware drive needs to be closed after the hardware drive is used, so that a complex work is realized for non-professionals, an internal parameter mapping table is used for correlating hardware types with required parameters of hardware running in the current program, an intelligent monitoring program runs, the manual operation of the non-professionals is not needed, the complex problems are simplified, the complex dependent environment and starting parameters do not need to be remembered, and the complex flow of the drive running is simplified, so that the use mode of the hardware drive is greatly simplified, and the current internal operation does not need to be concerned;
example combination two:
because of numerous hardware, managing numerous hardware operations often encounters various situations such as hardware addition, deletion, update, and driver suspension, termination, restart, and exception, in general, suspension, termination, and restart all require temporarily terminating the driver operations, and after the program is terminated, if the driver modules need to be started, the driver modules need to be operated again; if the driver module is abnormal, the whole driver program is crashed; therefore, the whole process of driving the hardware is long in time consumption and low in efficiency, and the following method provides a more efficient operation management mode:
preferably, if there is no corresponding driver adaptation module, creating a new driver adaptation module according to the first mapping relationship, and adding the new driver adaptation module into the hardware driver adaptation queue, including the following steps:
if the corresponding drive adaptation module does not exist, retrieving and taking out the corresponding drive adaptation module from the hardware adapter buffer pool according to the hardware information, and putting the drive adaptation module into a hardware drive adaptation queue, wherein the hardware adapter buffer pool is used for temporarily storing the idle drive adaptation module.
Preferably, the service layer further includes a hardware adapter buffer pool, where the hardware adapter buffer pool is used to temporarily store idle driver adaptation modules, and the driver adaptation modules are generated according to a first mapping relationship preset or recovered from the hardware driver adaptation queue.
When the hardware is newly added, if a drive adaptation module corresponding to the current hardware exists in the existing hardware adapter buffer pool, the drive adaptation module is directly taken out from the current hardware adapter buffer pool, then parameters are written into the drive adaptation module, the state of the current drive adaptation module is set to be a used mark, and then the current drive adaptation module is put into a hardware drive adapter queue; when the drive adaptation module does not exist in the drive adaptation module buffer pool, a new drive adaptation module is required to be created again, the state is directly set to be used, and the drive adaptation module is placed into a hardware drive adapter queue; when the driving adaptation module is removed, the content of the current driving adaptation module is only required to be emptied, the state is set to be an idle state, then the driving adaptation module is placed into a driving adaptation module buffer pool, and when the same module in the driving adaptation module buffer pool reaches a certain buffer quantity, for example, the buffer quantity is 4, when the buffer quantity reaches 4, the driving adaptation module is really removed from the driving adaptation module buffer pool;
the method comprises the steps that drive adaptation modules are placed in a hardware drive adapter queue, after the drive adaptation modules run, each drive adaptation module is processed in parallel, the running of each hardware is monitored constantly, when a program is paused, stopped and restarted, the running state of the hardware is set as a stop mark, then the hardware drive modules are temporarily forbidden, all initialization environments and parameters are reserved, and when the program needs to be started again, the current state is only required to be updated to be a start mark, so that the program can run again; when the program is abnormal, the program can automatically diagnose the current error information, but does not influence the operation of other parallel drive adaptation modules, and can be started again or initialized to restart the current hardware drive; when the hardware type of the current drive adaptation module is changed, if the hardware unique identifier is not changed and the current drive adaptation module belongs to the same drive adaptation module, the hardware information of the current module is reinitialized, the hardware drive is operated again, and the expenses for destroying and recreating the drive adaptation module are greatly reduced. The hardware operation management method does not need people to care about the state changes of the current hardware, such as pause, termination, restart and exception, and uses an efficient buffer queue and a retrieval mode, so that the current program operation efficiency can be greatly enhanced, the queue can be rapidly retrieved, and the hardware driving operation can greatly improve the efficiency without using an object immediate destruction mode.
Example three of the combination:
the hardware operation management method is characterized in that under the condition that more hardware peripherals are added, new drivers are developed for each new hardware addition, then a hardware operation management system is adapted to the hardware drivers, new hardware types, hardware starting environment parameters, hardware operation parameters, hardware adaptation modules and the like need to be added, then programs are compiled again, and the hardware operation management system is deployed on a hardware entity robot after the adaptation is completed; the second embodiment is a method of using a hardware configuration file, each module parameter is solidified into a configuration file, the configuration files are a configuration file 1 (parameter association file) and a configuration file 2 (startup parameter file), the parameter configuration file 1 is used for associating a hardware type with a hardware default parameter, a hardware startup environment and a hardware adaptation module, the hardware configuration 2 is a hardware startup parameter and is named as a hardware type name added to the parameter association file, when a new hardware driving module is added, a parameter associated with the hardware type, the hardware default parameter and the hardware startup environment is added to the configuration file 1, a new hardware configuration 2 is added at the same time, the name is the hardware type newly added in the configuration file 1 and is filled with a current hardware driving startup parameter, after the driving adaptation module operates, the introduced hardware operation environment is set, then the configuration file 2 is loaded into a memory variable, then the dynamic startup parameter is replaced into the memory variable loaded by the configuration file 2, then the hardware driving module can operate normally, and hardware addition of each time is not required to be modified, the hardware can be started only by adding a corresponding association item in the configuration file, the new hardware configuration file, and the expandability of the hardware driving module can be greatly improved.
The invention also discloses an electronic device, comprising:
a processor; a memory; and a program, wherein the program is stored in the memory and configured to be executed by the processor, the program comprising instructions for performing the human hardware operation management method.
The invention also discloses a computer readable storage medium, on which a computer program is stored, the computer program is executed by a processor to execute the robot hardware operation management method.
The invention discloses a robot hardware operation management method, which comprises a hardware configuration system and a hardware driving system;
the invention provides a robot hardware operation management method. The invention relates to an electronic device and a readable storage medium, which are used for executing a robot hardware operation management method. The invention comprises a hardware configuration system and a hardware driving system, and the hardware operation management method carries out the operation management of the hardware driving through hardware configuration parameters. Aiming at the problem that a user does not need to care how a specific hardware peripheral driver is executed, and only needs to give a specific hardware type and name, the hardware operation management system can uniformly manage the operation of all peripheral drivers, so that the work of non-working personnel is reduced.
The foregoing is merely a preferred embodiment of this invention and is not intended to limit the invention in any manner; those skilled in the art can readily practice the invention as shown and described in the drawings and detailed description herein; however, those skilled in the art should appreciate that they can readily use the disclosed conception and specific embodiments as a basis for designing or modifying other structures for carrying out the same purposes of the present invention without departing from the scope of the invention as defined by the appended claims; meanwhile, any equivalent changes, modifications and evolutions made to the above embodiments according to the substantial technology of the present invention are still within the protection scope of the technical solution of the present invention.
In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, the schematic representations of the terms used above do not necessarily refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.
While embodiments of the present invention have been illustrated and described above, it is not intended that they be construed as limiting the claims. The invention is not limited to the above embodiments, the specific construction of which allows variations, all of which are within the scope of the invention as defined in the independent claims.
Claims (17)
1. A hardware operation management method is characterized in that:
the method comprises the following steps:
receiving hardware information of at least one hardware device;
retrieving from a hardware drive adaptation queue according to the hardware information and judging whether a corresponding drive adaptation module exists;
if the corresponding drive adaptation module does not exist, a new drive adaptation module is created according to the first mapping relation and added into the hardware drive adaptation queue; retrieving the required hardware driving parameters through a second mapping relation according to the hardware information through the driving adaptation module, and operating the hardware driving module according to the hardware driving parameters;
and if the corresponding drive adaptation module exists, retrieving the required hardware drive parameter through a second mapping relation according to the hardware information by the drive adaptation module, and operating the hardware drive module according to the hardware drive parameter.
2. A hardware operation management method according to claim 1, characterized in that:
the hardware driving parameter comprises a driving command, or the hardware driving parameter comprises a driving command and an operating environment; the driving command is a starting parameter, an updating parameter or a disabling parameter.
3. A hardware operation management method according to claim 2, characterized in that:
when the driving command is a starting parameter, the driving adaptation module searches the required hardware driving parameter according to the hardware information, and the asynchronous operation of the hardware driving module according to the hardware driving parameter comprises the following steps:
the drive adaptation module retrieves the current environment parameters of hardware operation from the hardware drive adaptation queue according to the hardware information, and initializes the operation environment of the hardware drive module according to the environment parameters;
the drive adaptation module retrieves the required starting parameters according to the hardware information;
asynchronously operating and starting the hardware driving module according to the starting parameters;
and continuously detecting the running state of the hardware driving module in the running process, if the hardware driving module is abnormal or quits normally, starting the driving adaptation module again, and reporting the current state.
4. A hardware operation management method according to claim 3, wherein:
when the driving command comprises the updating parameter, the method also comprises the following steps:
the drive adaptation module retrieves the required update parameters according to the hardware information;
closing the hardware driving module according to the updating parameter; initializing the running environment of the hardware driving module, updating the hardware driving module according to the updating parameters, and restarting the hardware driving module.
5. The hardware operation management method according to claim 4, wherein:
before the step of initializing the operating environment of the hardware driver module, the method further comprises the following steps: and the drive adaptation module retrieves the current hardware operating environment parameters according to the hardware information.
6. A hardware operation management method according to claim 2, characterized in that:
when the driving command is a disabled parameter, the driving adaptation module retrieves the required hardware driving parameter according to the hardware information, and asynchronously operating the hardware driving module according to the hardware driving parameter comprises the following steps:
the drive adaptation module retrieves the required forbidden parameters according to the hardware information;
and closing the hardware driving module according to the forbidden parameters, and removing the driving adaptation module from the hardware driving adaptation queue.
7. A hardware operation management method according to claim 1, characterized in that:
when the hardware driving module is updated, the first mapping relation or the second mapping relation can be modified in a hardware configuration file mode.
8. A hardware operation management method according to claim 1, wherein:
if the corresponding drive adaptation module does not exist, a new drive adaptation module is created according to the first mapping relation and added into the hardware drive adaptation queue, and the method comprises the following steps:
if the corresponding drive adaptation module does not exist, the corresponding drive adaptation module is retrieved from the hardware adapter buffer pool and taken out according to the hardware information, when the drive adaptation module does not exist in the hardware adapter buffer pool, a new drive adaptation module is created according to a first mapping relation and is placed into a hardware drive adaptation queue, and the hardware adapter buffer pool is used for temporarily storing the idle drive adaptation module.
9. A hardware operation management method according to claim 1, wherein:
the hardware information comprises a unique identification mark.
10. A hardware operation management method according to claim 9, wherein:
the unique identification comprises a hardware ID or a hardware type.
11. An electronic device, characterized in that:
comprises a memory; and a program, wherein the program is stored in the memory and configured to be executed by the processor, the program comprising instructions for carrying out the method of any one of claims 1-10.
12. A computer-readable storage medium having stored thereon a computer program, characterized in that:
the computer program is executed by a processor for performing the method according to any of claims 1-10.
13. A hardware management subsystem, characterized by:
the system comprises a service layer and a drive adaptation layer;
the service layer comprises a parameter service module and a drive service module; the parameter service module is a service node of all parameters and is used for managing all parameters and data; the drive service module is used for managing the starting of hardware;
the driving adaptation layer comprises a plurality of driving adaptation modules;
wherein the content of the first and second substances,
the service layer is used for receiving hardware information of at least one hardware device, retrieving from a hardware drive adaptation queue according to the hardware information and judging whether a corresponding drive adaptation module exists in the drive adaptation layer;
if the corresponding drive adaptation module does not exist, a new drive adaptation module is created according to the first mapping relation and added into the hardware drive adaptation queue; retrieving the required hardware driving parameters through a second mapping relation according to the hardware information through the driving adaptation module, and operating the hardware driving module according to the hardware driving parameters;
if the corresponding drive adaptation module exists, retrieving the required hardware drive parameters through a second mapping relation according to the hardware information through the drive adaptation module; and operating the hardware driving module according to the hardware driving parameters.
14. A hardware management subsystem according to claim 13, wherein:
the service layer also comprises a state monitoring module, and the state monitoring module is used for monitoring the operation of hardware.
15. A hardware management subsystem according to claim 13, wherein:
the service layer further comprises a hardware adapter buffer pool, wherein the hardware adapter buffer pool is used for temporarily storing idle driving adaptation modules, and the driving adaptation modules are generated in advance according to the first mapping relation or recovered from the hardware driving adaptation queues.
16. A hardware operation management system, characterized by:
a hardware management subsystem as claimed in any one of claims 14 to 15 and comprising a hardware driver subsystem comprising a plurality of scalable hardware driver modules.
17. A hardware configuration system, characterized by: comprising a front-end interface for displaying and/or updating hardware configuration parameters of the hardware operation management system according to claim 16.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010000195 | 2020-01-02 | ||
| CN2020100001955 | 2020-01-02 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111414202A CN111414202A (en) | 2020-07-14 |
| CN111414202B true CN111414202B (en) | 2022-11-22 |
Family
ID=71491071
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010172580.8A Active CN111414202B (en) | 2020-01-02 | 2020-03-12 | Hardware operation management method, system, management subsystem, electronic device and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111414202B (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112000382B (en) * | 2020-08-26 | 2023-10-13 | 绿盟科技集团股份有限公司 | Linux system starting method and device and readable storage medium |
| CN112147914A (en) * | 2020-09-01 | 2020-12-29 | 上海机电工程研究所 | Distributed simulation data online monitoring method and system based on reflective memory network |
| CN112905123B (en) * | 2021-02-21 | 2024-06-28 | 珠海美佳音科技有限公司 | Storage controller and storage control method of environment parameter recording equipment |
| CN113225374A (en) * | 2021-03-23 | 2021-08-06 | 北京交大思源信息技术有限公司 | Modular software standardization method, device, medium and equipment for automatic ticket selling and checking equipment |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100479389C (en) * | 2006-10-10 | 2009-04-15 | 华为技术有限公司 | Module and method for realizing equipment access interface, equipment access system and method |
| US8132187B2 (en) * | 2007-08-31 | 2012-03-06 | Microsoft Corporation | Driver installer usable in plural environments |
| CN101382894B (en) * | 2007-09-05 | 2013-09-04 | 北京软通科技有限责任公司 | Method, device and system for downloading computer hardware device driver |
| CN101551752B (en) * | 2008-03-31 | 2011-11-02 | 联想(北京)有限公司 | Method and system for using the same operating system on different computers |
| CN102346737A (en) * | 2010-07-30 | 2012-02-08 | 腾讯科技（深圳）有限公司 | Sharing method and device for hardware equipment driving program |
| CN102479164A (en) * | 2010-11-30 | 2012-05-30 | 英业达股份有限公司 | Addressing method of new-generation peripheral component interconnect adapter card |
| CN102033751B (en) * | 2010-12-24 | 2013-06-19 | 青岛海信信芯科技有限公司 | Software adaptation method and system for OSD, and multimedia terminal |
| CN106375856B (en) * | 2016-08-30 | 2019-07-26 | 青岛海信宽带多媒体技术有限公司 | A kind of driving method and device of intelligent terminal |
| CN107015807B (en) * | 2017-04-06 | 2020-07-10 | 青岛海信宽带多媒体技术有限公司 | Device driver management method |
| CN107423095B (en) * | 2017-07-24 | 2020-10-02 | 百富计算机技术（深圳）有限公司 | Data processing method and device adaptive to hardware, storage medium and computer equipment |
| CN110543113B (en) * | 2019-07-17 | 2022-12-02 | 杭州迦智科技有限公司 | Robot hardware assembling and managing method, device, medium, system, front-end assembling client and robot body operation system |
-
2020
- 2020-03-12 CN CN202010172580.8A patent/CN111414202B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN111414202A (en) | 2020-07-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111414202B (en) | Hardware operation management method, system, management subsystem, electronic device and storage medium | |
| CN105357038B (en) | Monitor the method and system of cluster virtual machine | |
| US8560686B2 (en) | Communicating with an in-band management application through an out-of-band communications channel | |
| US20030088425A1 (en) | In-queue jobs information monitoring and filtering | |
| US20080294764A1 (en) | Storage medium bearing hba information provision program, hba information provision method and hba information provision apparatus | |
| EP2472402A1 (en) | Remote management systems and methods for mapping operating system and management controller located in a server | |
| CN106371932A (en) | Information configuration method and device based on zookeeper | |
| JPH10501907A (en) | Method and apparatus for monitoring and controlling programs in a network | |
| US7272712B1 (en) | Data structure and method for managing modules associated with a kernel | |
| CN113448686A (en) | Resource deployment method and device, electronic equipment and storage medium | |
| CN112214388A (en) | Memory monitoring method, device, equipment and computer readable storage medium | |
| US7546604B2 (en) | Program reactivation using triggering | |
| WO2022012305A1 (en) | Method and apparatus for managing model file in inference application | |
| CN111930561B (en) | Streaming task automatic monitoring alarm restarting system and method | |
| CN110881224A (en) | Network long connection method, device, equipment and storage medium | |
| CN114610446B (en) | Method, device and system for automatically injecting probe | |
| CN113595762B (en) | Network card configuration storage method and device | |
| CN110443910B (en) | Method, system, device and storage medium for monitoring state of unmanned device | |
| CN111858234A (en) | Task execution method, device, equipment and medium | |
| CN112486504A (en) | Interaction method, upper computer and computer readable storage medium | |
| CN110336693A (en) | Management method, device, equipment and the storage medium of network control techology | |
| CN113407504B (en) | Data processing method, user space file system and storage medium | |
| CN109639686B (en) | Distributed webpage filtering method and device, electronic equipment and storage medium | |
| JP2002236588A (en) | Data updating device and its control method | |
| CN117076120A (en) | Multitasking operation method, system, electronic equipment and medium based on Docker container |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |