CN111447103B

CN111447103B - Virtual device management system, electronic device, virtual device management method, and medium

Info

Publication number: CN111447103B
Application number: CN202010158939.6A
Authority: CN
Inventors: 曲彤晖
Original assignee: Hangzhou Hikvision System Technology Co Ltd
Current assignee: Hangzhou Hikvision System Technology Co Ltd
Priority date: 2020-03-09
Filing date: 2020-03-09
Publication date: 2022-01-28
Anticipated expiration: 2040-03-09
Also published as: CN111447103A

Abstract

The application provides a management system and method of virtual equipment, electronic equipment and a medium.A client responds to the virtual equipment creating operation of a user and sends a virtual equipment creating request to a virtual service father node; the virtual equipment creating request comprises a virtual equipment model identifier and a target number; the virtual service father node queries a model base according to the virtual equipment model identification to obtain corresponding model information; determining at least one target virtual service sub-node according to the target number, wherein each target virtual service sub-node corresponds to one distribution number, and sending the model information and the distribution number to the corresponding target virtual service sub-node; and the target virtual service child node creates and distributes a plurality of virtual devices according to the received model information. By the method and the device, the virtual equipment meeting the requirements of the user can be created, the requirements of different users in different scenes can be met, and the related test cost can be greatly reduced.

Description

Virtual device management system, electronic device, virtual device management method, and medium

Technical Field

The present application relates to the field of virtual device technologies, and in particular, to a system and a method for managing a virtual device, an electronic device, and a computer-readable medium.

Background

As the application of the ONVIF (Open Network Video Interface Forum) standard specification in the international range is more and more extensive and deep, the access requirement of the ONVIF device is also increasing. In the process of accessing the ONVIF device, not only the standardization of the protocol and compatibility are considered, but also the improvement of the access performance is of considerable importance.

However, in general, there are only a few devices in a laboratory environment, and there is no way to build hundreds, even thousands, of ONVIF device environments by using a large amount of manpower and material resources. Meanwhile, with the development of emerging technologies such as internet of things, cloud services and big data, the number of devices in an actual project will be more and more, a large number of millions of devices exist at present, and products directly deployed in the actual project can expose various performance problems, so that project use and customer evaluation are seriously affected.

Further, with the construction of more and more internet of things (or cloud services, or big data) capability open platforms, third-party partners or individuals prefer to complete the whole development life cycle through an online integrated persistent integrated development operation and maintenance (DevOps) environment, as it can greatly improve software development efficiency and engineering capability. As the most critical test link of software development, the key link can be completed through online test. Before automation, an online test environment often cannot apply for too many real devices as test resources of various software, and particularly cannot verify the performance test of software services in a targeted manner.

Disclosure of Invention

The application aims to provide a management system and a management method of a virtual device, an electronic device and a computer readable medium.

A first aspect of the present application provides a management system for virtual devices, including:

the client is used for responding to the virtual equipment creating operation of the user and sending a virtual equipment creating request to the virtual service father node; the virtual equipment creating request comprises virtual equipment model identification and target quantity;

the virtual service father node is used for inquiring a model base according to the virtual equipment model identification to obtain corresponding model information; determining at least one target virtual service sub-node according to the target number, distributing the target number to the at least one target virtual service sub-node, wherein each target virtual service sub-node corresponds to one distribution number, and sending the model information and the distribution number to the corresponding target virtual service sub-node;

and each target virtual service sub-node in the at least one target virtual service sub-node is used for creating and distributing a number of virtual devices according to the received model information.

A second aspect of the present application provides a management system for a virtual device, including:

the virtual service father node is used for receiving a virtual device creating request, and the virtual device creating request comprises a virtual device model identifier and a target number; determining at least one target virtual service sub-node according to the target data, distributing the target number to the at least one target virtual service sub-node, wherein each target virtual service sub-node corresponds to one distribution number, and sending the virtual equipment model identification and the distribution number to the corresponding target virtual service sub-node;

each target virtual service sub-node in the at least one target virtual service sub-node is used for inquiring a model base according to the virtual equipment model identification to obtain corresponding model information; and creating and distributing a number of virtual devices according to the model information.

A third aspect of the present application provides a method for managing virtual devices, which is applied to a virtual service parent node, and includes:

receiving a virtual device creating request, wherein the virtual device creating request comprises a virtual device model identifier and a target number;

inquiring a model base according to the virtual equipment creating request to obtain model information corresponding to the virtual equipment model identification; determining at least one target virtual service sub-node according to the target number, distributing the target number to the at least one target virtual service sub-node, wherein each target virtual service sub-node corresponds to one distribution number, and sending the model information and the distribution number to the corresponding target virtual service sub-node, so that each target virtual service sub-node in the at least one target virtual service sub-node creates the virtual equipment with the distribution number according to the model information.

A fourth aspect of the present application provides a method for managing virtual devices, which is applied to a virtual service child node, and includes:

receiving model information and distribution quantity sent by a virtual service father node, and creating virtual equipment with the distribution quantity according to the model information;

or the like, or, alternatively,

receiving virtual equipment model identification and distribution quantity sent by a virtual service father node, inquiring a model base according to the virtual equipment model identification to obtain corresponding model information, and establishing the distribution quantity of virtual equipment according to the model information.

A fifth aspect of the present application provides an electronic device, comprising: a memory, a processor and a computer program stored on the memory and executable on the processor, the processor executing when executing the computer program to implement the method of the third or fourth aspect of the present application.

A sixth aspect of the present application provides a computer readable medium having computer readable instructions stored thereon which are executable by a processor to implement the method of the third or fourth aspect of the present application.

Compared with the prior art, according to the management system and method for the virtual device, the electronic device and the medium, the client responds to the virtual device creation operation of the user and sends the virtual device creation request to the virtual service father node; the virtual equipment creating request comprises a virtual equipment model identifier and a target number; the virtual service father node queries a model base according to the virtual equipment model identification to obtain corresponding model information; determining at least one target virtual service sub-node according to the target number, wherein each target virtual service sub-node corresponds to one distribution number, and sending the model information and the distribution number to the corresponding target virtual service sub-node; and the target virtual service child node creates and distributes a plurality of virtual devices according to the received model information. According to the scheme, the virtual equipment meeting the requirements of the user can be created according to the virtual equipment model, so that the user can construct a required test environment based on a sufficient number of virtual equipment, therefore, the system can meet the requirements of different users in different scenes, and the related test cost can be greatly reduced.

Drawings

Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the application. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:

fig. 1 illustrates a block diagram of a management system for virtual devices provided in some embodiments of the present application;

FIG. 2 illustrates a block diagram of another virtual device management system provided in some embodiments of the present application;

FIG. 3 illustrates an interaction diagram of modules in a management system for virtual devices according to some embodiments of the present disclosure;

FIG. 4 is a block diagram illustrating a virtual service child node composition architecture provided in some embodiments of the present application;

FIG. 5 illustrates a virtual service parent node composition architecture diagram provided in some embodiments of the present application;

FIG. 6 illustrates a model management service module composition architecture diagram provided in some embodiments of the present application;

FIG. 7 illustrates a client component block diagram as provided by some embodiments of the present application;

FIG. 8 illustrates an exemplary diagram of a model description file and its hierarchical relationships provided in some embodiments of the present application;

FIG. 9 illustrates a flow chart of a virtual service child node provided in some embodiments of the present application;

FIG. 10A illustrates a flow chart of a method for managing virtual appliances provided by some embodiments of the present application;

FIG. 10B is a flowchart illustrating a method for managing virtual appliances according to further embodiments of the present application;

FIG. 10C is a flowchart illustrating a method for managing virtual appliances according to further embodiments of the present application;

FIG. 11 illustrates a schematic diagram of an electronic device provided by some embodiments of the present application;

FIG. 12 illustrates a schematic diagram of a computer-readable medium provided by some embodiments of the present application.

Detailed Description

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

It is to be noted that, unless otherwise specified, technical or scientific terms used herein shall have the ordinary meaning as understood by those skilled in the art to which this application belongs.

In addition, the terms "first" and "second", etc. are used to distinguish different objects, rather than to describe a particular order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements listed, but may alternatively include other steps or elements not listed, or inherent to such process, method, article, or apparatus.

The embodiments of the present application provide a management system and method for a virtual device, an electronic device, and a computer-readable medium, which are described below with reference to the accompanying drawings.

Referring to fig. 1, which shows a block diagram of a management system of a virtual device according to some embodiments of the present application, as shown, the management system 10 (or may also be referred to as a virtual laboratory platform) of the virtual device may include:

a client 110 for transmitting a virtual device creation request to a virtual service parent node 120 in response to a virtual device creation operation by a user; the virtual appliance creation request includes a virtual appliance model identification and a target quantity. For example, the number of objects corresponding to the virtual device model identifier 001 is 200, and the number of objects corresponding to the virtual device model identifier 002 is 500.

The virtual service parent node 120 is configured to query the model library 140 according to the virtual device model identifier to obtain corresponding model information. The model library 140 includes identifications of virtual device models and corresponding model information.

The virtual service parent node 120 is further configured to determine at least one target virtual service child node 130 according to the target number, allocate the target number to the at least one target virtual service child node 130, where each target virtual service child node 130 corresponds to an allocation number, and send the model information and the allocation number to the corresponding target virtual service child node 130.

Specifically, the target virtual service child node may be a virtual service child node newly created by the virtual service parent node, or may be a virtual service child node created previously, and both of the target virtual service child node and the virtual service child node may be used to create the virtual device this time. It can be understood that if the virtual service child node which is created before can meet the user requirement, the virtual service child node can be used for creating the virtual device this time without consuming resources to create newly. And if the previously created virtual service child node cannot meet the user requirement, the virtual service parent node is required to create a new virtual service child node.

Each target virtual service sub-node 130 of the at least one target virtual service sub-node is configured to create a distributed number of virtual devices according to the received model information.

In some embodiments of the present application, the virtual service parent node 120 may further be configured to:

and regularly collecting various running state information of the virtual service sub-nodes, and managing the virtual service sub-nodes according to the running state information. In addition, the virtual service parent node 120 may perform registration management, heartbeat interaction, state monitoring, guard and the like on all the virtual service child nodes, so as to ensure that the management system of the entire virtual device can continuously and stably operate.

and receiving a virtual equipment management instruction sent by the client, and managing the virtual equipment created by the virtual service child node according to the virtual equipment management instruction, wherein the management operations comprise dynamic start-stop, addition and deletion and the like.

Referring to fig. 2, which illustrates a structural diagram of another management system for a virtual device according to some embodiments of the present application, as shown in the figure, the management system 10 for a virtual device further includes:

the modeling module 150 is configured to obtain modeling data of a device to be modeled, establish a virtual device model according to the modeling data, and output an identifier of the virtual device model and corresponding model information to the model library 140.

The model repository 140 and modeling module 150 may constitute a model management service module as a management service node for models that is independent of virtual service child nodes and unaffected by cluster scheduling.

In some embodiments of the present application, the modeling module 150 may obtain modeling data for a device to be modeled according to the following:

the first method is as follows: accessing physical equipment corresponding to the equipment to be modeled, acquiring basic parameters of the physical equipment, and extracting modeling data of the equipment to be modeled according to the basic parameters. Specifically, the modeling module 150 may actively connect to the physical device, obtain basic parameters of the physical device, and extract modeling data of the physical device according to the basic parameters.

The second method comprises the following steps: and importing an interactive data packet corresponding to the equipment to be modeled, and extracting modeling data of the equipment to be modeled according to the interactive data packet. Specifically, in the modeling module 150, the interactive data package may be imported through the client 110, or may be imported through a storage medium such as a usb disk.

The third method comprises the following steps: and receiving configuration data of the equipment to be modeled, which is sent by a user through the client, and extracting modeling data of the equipment to be modeled according to the configuration data.

In some embodiments of the present application, the virtual service parent node, the virtual service child node, the modeling module, and the model library may be integrated into a whole, or may be a server alone, or may be a cloud server cluster.

According to the management system of the virtual equipment, the virtual equipment meeting the requirements of the user can be established according to the virtual equipment model, so that the user can construct a required test environment based on a sufficient number of virtual equipment, therefore, the requirements of different users in different scenes can be met through the system, and the related test cost can be greatly reduced.

Another embodiment of the present application provides a management system for virtual devices, including:

the virtual service father node is used for receiving a virtual device creating request, and the virtual device creating request comprises a virtual device model identifier and a target number; and determining at least one target virtual service sub-node according to the target data, distributing the target number to the at least one target virtual service sub-node, wherein each target virtual service sub-node corresponds to one distribution number, and sending the virtual equipment model identification and the distribution number to the corresponding target virtual service sub-node.

The difference between this embodiment and the management system for virtual devices in the previous embodiment is that the target virtual service child node queries the model base according to the virtual device model identifier to obtain the corresponding model information, whereas the previous embodiment is that the virtual service parent node queries the model base according to the virtual device model identifier to obtain the corresponding model information. The rest parts are the same and are not described in detail herein.

For better understanding of the foregoing embodiments of the present application, please refer to fig. 3, which illustrates an interaction schematic diagram of modules in a management system of a virtual device according to some embodiments of the present application, where the virtual device supports, but is not limited to, an ONVIF protocol, and the following mainly takes constructing a virtual ONVIF device as an example.

The functions of the modules in the figure are described first:

1. virtual service child node:

as shown in fig. 4, the virtual service child node is mainly composed of a protocol agent module, a protocol analysis module, a service scheduling module, a resource management module, a cluster management module, and the like.

1) A protocol agent module: according to the capability of the ONVIF protocol, the communication proxy layer supports UDP protocol, TCP protocol, HTTP protocol, RTSP protocol and the like, and simultaneously can be expanded to support HTTPS, WEBSOCKET communication and the like, and the protocol proxy layer actually completes the encapsulation of the communication proxy. The standard based on the ONVIF protocol, for example, the ONVIF signaling protocol adopts the HTTP protocol, and the subsequent standard also supports HTTPs, webscoket, and the like. Similarly, the code stream transmission control protocol, that is, the signaling adopts the RTSP protocol, and the code stream may actually support RTSP OVER UDP, RTSP OVER TCP, RTSP OVER HTTP (S)/webscoke, and the like. Therefore, the protocol agent module can be subdivided into a TCP protocol agent sub-module, a UDP protocol agent sub-module, an HTTP protocol agent sub-module, an RTSP protocol agent sub-module, and the like. The method mainly completes interaction with a virtual service parent node and provides the ONVIF communication service for the ONVIF device client.

2) A protocol analysis module: the system mainly comprises an RTP stream protocol analysis submodule, an RTSP protocol analysis submodule, an ONVIF protocol stack and the like. The method is mainly responsible for analyzing and assembling the messages of the code stream transmission protocol, the real-time stream transmission control protocol and the ONVIF protocol. In practical implementations, the protocol parsing module will be directly forwarded by the model data. And quickly routing to required model data according to the model mapping relation, and providing protocol service. The model data comprises an ONVIF signaling model, an RTSP signaling model, a code stream data model and the like.

3) A service scheduling module: the system mainly comprises a media forwarding sub-module, an equipment management scheduler and an event factory.

The media forwarding sub-module is used for managing and completing forwarding and distribution of the code stream data model.

And the equipment scheduling manager dynamically creates equipment instances with the distributed quantity in the thread pool based on the virtual equipment creating request of the virtual service father node.

And the event factory provides external ONVIF event capability based on the model, creates different event producers according to the model and provides external services through the protocol agent module.

4) A resource management module: the system mainly comprises a media resource management submodule, a data persistence submodule, an equipment resource management submodule and a model management submodule.

The media resource management sub-module is mainly responsible for inquiring the code stream data model according to the model number from the model management service, caching and supporting change.

And the equipment resource management submodule is mainly responsible for caching and managing (batch) equipment instances created based on the equipment model, and is equivalent to an equipment resource memory bank, and running state data of the equipment instances are also stored in the equipment resource memory bank. The method mainly comprises the equipment instance number, the equipment IP address and the port number, the equipment instance online state, the equipment instance user number and the like.

The model management submodule is mainly responsible for managing the model which the virtual service sub-node is responsible for, generally speaking, one virtual service sub-node can manage more than one equipment model, and different virtual equipment groups are created according to different models. The model management submodule mainly caches the model information.

And the data persistence sub-module is mainly responsible for completing the local storage of the device model, the code stream data model, the event model and the like managed by the virtual service sub-node, and when the virtual service sub-node (after a fault or in a conventional way) is restarted, the model and the model mapping relation can be inquired from the virtual service father node or the model management service according to the model number, the self-calibration is executed, and the stability is enhanced. The model may be a model identification and/or model information.

5) The cluster management module: the method is mainly responsible for registering with a virtual service father node, maintaining heartbeat, processing cluster management information and the like, and simultaneously supports functions of single-point failure, dynamic load balancing and the like.

2. Virtual service parent node: as shown in fig. 5, the virtual service parent node is composed of a plurality of processes, and mainly includes a cluster daemon service, a model scheduling service, an equipment scheduling service, a data persistence service, and the like.

1) Cluster daemon service: the system is mainly responsible for monitoring and guarding the running state of each service module of the virtual service father node, and simultaneously performing registration management, heartbeat interaction, state monitoring and guarding and the like on all virtual service child nodes. And ensuring that all programs of the whole virtual laboratory can continuously and stably run.

2) Model scheduling service: the method is mainly responsible for scheduling the model and dynamically distributing the model to the dynamically created virtual service child nodes.

3) The equipment scheduling service: the system is mainly responsible for providing services for dynamically establishing an equipment pool for equipment application of a virtual laboratory client, and simultaneously supports monitoring and control of equipment in the equipment pool, wherein the monitoring comprises monitoring of running state data, and the control comprises dynamic start-stop, addition and deletion and the like.

4) Data persistence service: the method is mainly responsible for caching and persistently storing the mapping relation between the virtual service sub-nodes and the model, the mapping relation between the virtual service sub-nodes and the equipment, the mapping relation between the model and the equipment, the information of all the virtual service sub-nodes and the like.

3. Model management service node: as shown in fig. 6, mainly includes a modeling service, a model library, and the like.

1) Modeling service: the modeling method mainly supports access or data import or self-definition of equipment to be modeled, then carries out dynamic analysis and modeling based on the accessed data or the imported or self-defined data of the equipment, and finally outputs a model to a model base.

2) Model library: the method is mainly responsible for caching and persistence of model data and supports interfaces of model addition, deletion, modification, check and the like.

4. Virtual laboratory platform client: as shown in fig. 7, the system mainly includes a communication module, a protocol module, a model management module, an equipment management module, a human-computer interaction module, and the like.

1) A communication module: the method is mainly responsible for completing communication with virtual service child nodes, virtual service father nodes and model management services.

2) A protocol module: the method is mainly used for processing and assembling and analyzing the interactive messages among the virtual service child nodes, the virtual service father nodes and the model management service modules.

3) A model management module: the system mainly comprises a modeling submodule, a model library management submodule, a model square and the like.

A modeling submodule: and modeling the virtual equipment in a mode of equipment access or data import or self-definition.

A model library management submodule: the method is used for adding, modifying, deleting and exporting the model and can support batch.

Model square: sharing of models to other users may be supported, with models associated with user IDs.

4) A device management module: the management of (batch) device instances is mainly responsible, and comprises starting and stopping, adding and deleting, monitoring the running state of the device and the like.

5) A human-computer interaction module: the interface interaction module is mainly used for realizing all the functions, and the realization of the interface and the realization of the service function are decoupled.

As shown in fig. 3, the key process of interaction between modules in the management system (i.e. virtual laboratory platform) of the virtual device is as follows:

1) modeling: the method can be divided into at least 3 modes according to the input mode of data, namely access type modeling, lead-in type modeling and self-defined modeling.

Modeling by an access mode: namely, by accessing real equipment (namely, physical equipment), equipment data is automatically extracted for analysis and modeling. The process is as follows: the user adds a real device to be analyzed on the virtual laboratory platform, for example, adds an ONVIF device a, enters a real user name and password, and selects a capability set to be modeled, for example, a device management Service (device management), a Media Service (Media Service), a Media2 Service, and an Event Service (Event Service). At this time, the client notifies a modeling module of the model management service node, and the modeling module will go to the real device to automatically acquire the service data with 4 capabilities, including signaling messages, code stream data and the like. These data are then abstracted and extracted and modeled as a description file, which is exemplified by XML. The code stream data can be subjected to documentation. Model description files and their hierarchical relationships are shown in FIG. 8, where a model data set (e.g., model. ID0000001 or model. ID0000002) is generally referred to as a model.

Leading-in modeling: namely, when other platforms are connected to a certain device, the data interaction with the device is subjected to real-time packet capturing. The real-time packet capture requirement at least should contain more data interacting with the equipment, otherwise the model finally created according to the packet capture analysis may lack part of key data. Of course, when some part of the key data is missing in the modeling process, the modeling service of the model management service will issue an alarm, prompt the user on the virtual laboratory platform for "model calibration", and the details will contain a description of the missing key capability source data. At this point, the user should replenish the missing critical capacity scratch packets. For example, if the source data of the device management Service (device management Service) is absent, the user should grab the package of the device management Service to import the package, and the modeling Service will re-analyze the data, calculate the model, and finally complete the "model calibration" operation. The final output model is the same as the phi example.

And (3) custom modeling: that is, the user name, password, serial number, port number, and supported capability set checking are directly set on the virtual laboratory platform client page through manual configuration and device selection (further, checking and configuration of more detailed function items in the capability set can be supported, such as the number of analog channels, the number of digital channels, the number of alarm input channels, and the like in the device management service, and the video sampling rate, resolution, and the like in the media service). And meanwhile, event customization, namely the customization of event services, including event types, event intervals and event cycle modes (single song cycle, list cycle and list random), is also supported. The client sends the modeling request to the modeling service, and the modeling service performs modeling according to the user-defined model.

2) Model library: the model library supports management of the models, including model import, model modification, model deletion and model query. The model base is composed of a relational database and a data file set. The mapping relation between the model ID and the user ID, the mapping relation between the model ID and the model data file set and the like are stored in a relational database; the model description file and the stream data model are stored in the data file set.

Model introduction: and the model after the modeling service calculation is completed is imported into a model library in a file sharing or protocol communication mode. Meanwhile, the model can be imported from the virtual laboratory platform client, and the model data set can be directly imported into the model library.

Modifying the model: i.e. to modify the models in the model library. A user can check the details of the model on a client page of the virtual laboratory platform, and meanwhile, the user can edit and modify the relevant information of the model.

Model query: and providing a full model ID query interface, querying a single model according to the model ID, and querying interfaces such as batch models according to the batch model ID.

Deleting the model: deleting a model, and permanently removing the model library.

3) An equipment pool: the equipment is managed and scheduled based on the model, resources are utilized to the maximum extent, and the method has high performance and stability. The main process is as follows:

firstly, a user selects a certain model on a virtual laboratory platform, and after self-defined information such as target number (also called equipment number), initial port value, initial serial number value, user name and password of application equipment is filled in at the same time, model ID, equipment number, initial port value, initial serial number value, user name and password are sent to a virtual Service father node, and if the model also supports the capability of Event Service (Event Service), key information such as Event production interval, Event cycle mode and the like is carried at the same time.

And secondly, after the virtual service father node receives the virtual equipment creating request, the equipment scheduling service creates an equipment pool based on the request information of the client. The device pool caches index information of all device objects. The index information of one device object stores the mapping relationship between the device object and the model ID, the mapping relationship between the device object and the virtual service child node, and the like. The device scheduling service creates virtual service sub-nodes according to the number of devices, one virtual service sub-node is 1 process, a thread pool is created in the process, and multithreading concurrency is achieved. Assume a virtualThe maximum value of the number of the virtual equipment instances which can be created by the service child node is S_maxThe number of the devices applied by the user is xL_uThen, the calculation formula of the number f (x) of at least virtual service child nodes that the device scheduling management service should create is:

at this time, the minimum number of virtual service child nodes to be created is calculated, when

When not divided, the number of the virtual service child nodes (rounded) is

At this time, according to the load balancing strategy, the number S of the actual device instances on each virtual service child node_rIs composed of

Finally, the device objects generated by the model-based and load balancing strategies are generated in the device pool, and the mapping relation is already distributed. I.e. how many virtual service children need to be created, which device instances need to be allocated to which virtual service children.

When the virtual service child node is created by the virtual service father node, the information such as the IP address and the port of the virtual service father node, the IP address and the port number of the model management service, the child node number, the maximum thread number of the thread pool and the like can be transmitted in a command line or event mode. At this time, whether the port pool on the server is enough or not is checked, the mapping relation between the server and the port pool is maintained in the device pool, and the virtual service father node can manage a plurality of servers so as to deal with the problem of upper limit of the port (port range) of a single server0 to 65535). If the port pool on the server is enough, for example, the number nS of the device instances required for creating n (n is a positive integer) child nodes is satisfied_rAnd if the number of the ports is one, continuing to create n virtual service sub-nodes, otherwise, loading the ports to another 1 server with enough port pools to create the virtual service sub-nodes. Further, in order to improve resource utilization, a port pool above each server is monitored, and used ports are marked as unavailable, otherwise, the used ports are marked as available ports. When an allocation creates a device instance, the device instance is dynamically allocated according to the port availability status in the port pool on each server. For example, if the port pool of the server a is full, but the number of virtual devices requested by the user remains 100 and is not created, the 100 device instances will be allocated to the server B, 1 new virtual service child node will be dynamically created on the server B, and the 100 device instances will be allocated to the new virtual service child node.

And fourthly, further, the process of the virtual service child node is created and completed. The node initiates registration to a virtual service father node, and the registration is maintained through heartbeat after the registration is successful. At this time, the cluster daemon service of the virtual service father node can regularly acquire various running state information of the virtual service child nodes, including basic state information of programs such as running CPUs, memories, thread numbers, handle numbers, hard disk spaces and the like, when monitoring that the virtual service child nodes are abnormal, self-repairing is carried out in a child node restarting mode, if self-repairing is tried for a certain number of times and is invalid, the device instances distributed on the virtual service child nodes are transferred to another relatively idle virtual service child node through dynamic load balancing, and if the self-repairing is not tried for a certain number of times, 1 virtual service child node is dynamically created.

4) Virtual service child node: as the most important module, the virtual service sub-node carries the service for finally providing (batch) simulation equipment to the user, that is, the final use effect verification of the user is directly interacted with the virtual service sub-node. The specific structure of the virtual service child node is described above, and reference may be made to fig. 4. The working principle of the virtual service child node is explained in detail herein.

And (3) connecting with the nodes (3) to (iv), wherein the virtual service child node normally operates and is monitored. If the virtual service father node has the requirement of creating the virtual equipment, a request message is sent to the virtual service child node, and the message carries the model information to be created and the required quantity. For example, after a user selects a certain model on a client and submits a request for 3000 ONVIF devices, and then clicks the loading model, the virtual service parent node sends the request message to the child node.

And secondly, after receiving the model, the virtual service child node caches the model locally.

And thirdly, the user clicks the starting equipment on the client, at the moment, the father node sends a starting equipment request to the child node, the child node dynamically creates the required number of virtual equipment after receiving the virtual equipment request, and the equipment scheduling service of the father node monitors the running states of all the equipment at regular time.

And fourthly, the running equipment instance can be observed on the virtual laboratory platform by a user, and the user can manually click to control the off-line of the equipment instance. At this time, the device scheduling service of the parent node sends a device offline request, where the request carries a specific device ID. And after receiving the ID, the child node inquires the virtual equipment of the equipment ID and stops the running of the equipment instance. By analogy, if the user can delete a device, the device instance will be destroyed. And if the user can add a new virtual device on the basis of the model, the father node informs the child node to create a device instance again.

After the device instance is created, all the virtual devices have the capability of providing services to the outside. Services are provided according to capabilities possessed by the model data set. For example, virtual device Z is created by the model model.id0000001 mentioned above, and its model data set is as shown in fig. 8. When it is to be accessed to a VMS (video integrated management platform), the VMS acts as an ONVIF client and acquires an ONVIF service to the virtual device Z. For example, the IP address of the virtual device Z is 10.13.68.61, and the port number is 15801. When the VMS initiates a request (GetCapabilitysreq) for acquiring the device capability set, at this time, the virtual device Z firstly searches the device management service development in the model through the HTTP service address HTTP://10.13.68.61:15801/onvif/device _ service initiated by the VMS according to the model description. And then, GetCapabilites XML is searched through a key value of GetCaabilities, and the virtual service child node can directly return the XML as a response to the VMS according to the model.

Sixthly, in the fifth step, generally, the safety of the VMS needs to be checked. At this time, security authentication is performed on the ONVIF client request initiated by the VMS in a wsse security authentication manner. The principle implemented in the virtual device Z is an irreversible algorithm. Sending a parameter Username in a request Header to a client, wherein the parameter Username is unchanged when Created, and performing Base64 decoding after a received Nonce value, and marking the result as Nonce ori; the Password of the device, the virtual device Z itself, is known, and the plaintext Password is used here; subsequently, the calculation result is compared with < wsse: Password > in the message by operating 4 values of Usename, NonceOri, Created and device Password (Password) according to the formula Password digest ═ Base64((SHA1(Nonce + Create + Password))). If the comparison is consistent, the authentication is passed; otherwise, the security authentication fails.

FIG. 9 shows a flow chart of the virtual service sub-node. The device scheduling manager is used for matching the model, and the protocol analysis submodule is used for assembling the response information in the model into a response message and then sending the response message to the client through the protocol agent submodule.

If the virtual device Z supports Media Service at the same time, when the ONVIF client side takes the stream, firstly, based on the model, the RTSP signaling interaction is completed according to the signaling flow. After the completion, the media port is used for code stream transmission. Therefore, a code stream port (rtsp server port, rtsp client port) is also necessary in each device model. And meanwhile, the dynamic load balancing system is also a dynamic resource, and in a dynamic load balancing strategy, the dynamic load balancing system also occupies a part of a port pool of a server.

Ninthly, if the virtual equipment Z simultaneously supports the Event Service (Event Service), an Event factory needs to be realized. The module is mainly used for managing the life cycle of events and links from production to consumption. Multiple clients may subscribe, and the module needs to manage subscribers and consumers while supporting custom events.

The event generator inputs an event generation interval (unit: second), an event type (motion detection, IO alarm, video occlusion and the like), and a generation mode (single song cycle/list random/list cycle) according to user requirements to define a producer.

The event factory comprises at least three submodules, a subscription manager, a consumption manager and a production manager.

A subscription manager: it is responsible for managing the subscriber address (Subscription Uri) when each client initiates a Subscription.

The consumption manager: and the Consumer address (Consumer Uri) which is returned to each client after the successful subscription management is carried out.

A production manager: and the client is responsible for managing and generating events and forwarding the events to each subscribed client through an ONVIF protocol stack and an HTTP protocol proxy.

Basic notification interface mode for one of the event modes in the ONVIF protocol:

a. when the client requests subscription to the Event Service of the virtual device Z, a Consumer Uri is returned, and the Consumer Uri is a unique identifier generated by the device scheduling manager and is managed.

b. At this time, the Event Service starts to produce the Event and notifies the Notify to the client, the client receives the Event, and the Subscription Uri of the Event is the only value produced when the client subscribes and should be associated with each client.

c. Since each subscription has a time to live, the client needs to periodically initiate a renewal to the subscription manager of the event factory.

d. The subscription manager may receive a Renew request from a different subscriber Uri, and respond successfully according to the corresponding client.

e. When receiving a request to unsubscribe, the subscription manager should notify the event producer that the event is no longer generated, and at the same time, remove the Consumer Uri and do not manage any more.

In the above, the key implementation principle of the management system of the virtual device is that the detailed parts of the key implementation principle are the same, but different implementation methods are available, and all the implementation methods are protected by the present application. For example, the present application may be combined with cloud computing technology to provide cloud services, and the like. Also for example, the ONVIF protocol in the example may be replaced with other protocols.

In the above embodiments, a management system of virtual devices is provided, and correspondingly, the present application also provides three management methods of virtual devices, please refer to fig. 10A, 10B, and 10C. The method embodiments described below are merely illustrative.

As shown in fig. 10A, the method for managing a virtual device, applied to a virtual service parent node, may include:

step S101: receiving a virtual device creating request, wherein the virtual device creating request comprises a virtual device model identifier and a target number;

step S102: inquiring a model base according to the virtual equipment creating request to obtain model information corresponding to the virtual equipment model identification; determining at least one target virtual service sub-node according to the target number, distributing the target number to the at least one target virtual service sub-node, wherein each target virtual service sub-node corresponds to one distribution number, and sending the model information and the distribution number to the corresponding target virtual service sub-node, so that each target virtual service sub-node in the at least one target virtual service sub-node creates the virtual equipment with the distribution number according to the model information.

In some implementations of embodiments of the present application, the method further comprises:

collecting all running state information of the virtual service sub-nodes at regular time, and managing the virtual service sub-nodes according to the running state information;

and/or the presence of a gas in the gas,

and receiving a virtual equipment management instruction sent by a user through a client, and managing the virtual equipment created by the virtual service child node according to the virtual equipment management instruction.

As shown in fig. 10B, the method for managing virtual devices, applied to a modeling module, may include:

step S201: obtaining modeling data of equipment to be modeled;

step S202: establishing a virtual equipment model according to the modeling data;

step S203: and constructing a model library according to the identification of the virtual equipment model and the corresponding model information.

In some implementations of embodiments of the present application, the obtaining modeling data of a device to be modeled includes:

accessing physical equipment corresponding to equipment to be modeled, acquiring basic parameters of the physical equipment, and extracting modeling data of the equipment to be modeled according to the basic parameters;

or, importing an interactive data packet corresponding to the equipment to be modeled, and extracting modeling data of the equipment to be modeled according to the interactive data packet;

or receiving configuration data of the equipment to be modeled sent by a user through a client, and extracting modeling data of the equipment to be modeled according to the configuration data.

As shown in fig. 10C, the method for managing a virtual device, applied to a virtual service child node, may include:

step S301: receiving the model information and the distribution quantity sent by the virtual service father node, or receiving the virtual equipment model identification and the distribution quantity sent by the virtual service father node, and inquiring a model base according to the virtual equipment model identification to obtain the corresponding model information.

Step S302: and creating the distributed number of virtual devices according to the model information.

In some implementations of the embodiments of the present application, the number of the model information is multiple, and each model information corresponds to one allocation number. Specifically, one virtual service child node may manage more than one device model, and create different virtual device groups according to different models.

after the virtual service child node is restarted, inquiring node information of the virtual service parent node to carry out self calibration;

the node information comprises a mapping relation between a virtual equipment model identifier corresponding to the virtual service child node and virtual equipment.

The management method of each virtual device provided in the embodiment of the present application and the management system of the virtual device provided in the foregoing embodiment of the present application have the same inventive concept and the same beneficial effects.

The embodiment of the present application further provides an electronic device corresponding to the management method of a virtual device provided in the foregoing embodiment, where the electronic device may be an electronic device for a client, such as a mobile phone, a notebook computer, a tablet computer, a desktop computer, and the like, so as to execute the application recommendation method.

Please refer to fig. 11, which illustrates a schematic diagram of an electronic device according to some embodiments of the present application. As shown in fig. 11, the electronic device 20 includes: the system comprises a processor 200, a memory 201, a bus 202 and a communication interface 203, wherein the processor 200, the communication interface 203 and the memory 201 are connected through the bus 202; the memory 201 stores a computer program that can be executed on the processor 200, and the processor 200 executes the management method of the virtual device provided in any of the foregoing embodiments when executing the computer program.

The Memory 201 may include a high-speed Random Access Memory (RAM) and may further include a non-volatile Memory (non-volatile Memory), such as at least one disk Memory. The communication connection between the network element of the system and at least one other network element is realized through at least one communication interface 203 (which may be wired or wireless), and the internet, a wide area network, a local network, a metropolitan area network, and the like can be used.

Bus 202 can be an ISA bus, PCI bus, EISA bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. The memory 201 is used for storing a program, and the processor 200 executes the program after receiving an execution instruction, and the management method for a virtual device disclosed in any embodiment of the present application may be applied to the processor 200, or implemented by the processor 200.

The processor 200 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware or instructions in the form of software in the processor 200. The Processor 200 may be a general-purpose Processor, and includes a Central Processing Unit (CPU), a Network Processor (NP), and the like; but may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in the memory 201, and the processor 200 reads the information in the memory 201 and completes the steps of the method in combination with the hardware thereof.

The electronic device provided by the embodiment of the present application and the management method of the virtual device provided by the embodiment of the present application have the same inventive concept and have the same beneficial effects as the method adopted, operated or implemented by the electronic device.

Referring to fig. 12, a computer-readable storage medium is shown as an optical disc 30, on which a computer program (i.e., a program product) is stored, where the computer program is executed by a processor to perform the virtual device management method according to any of the foregoing embodiments.

It should be noted that examples of the computer-readable storage medium may also include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory, or other optical and magnetic storage media, which are not described in detail herein.

The computer-readable storage medium provided by the above-mentioned embodiment of the present application and the management method of the virtual device provided by the embodiment of the present application have the same beneficial effects as the method adopted, run, or implemented by the application program stored in the computer-readable storage medium.

It should be noted that the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the systems, systems and units described above may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system and method may be implemented in other ways. The above-described system embodiments are merely illustrative, and for example, the division of the units is only one logical functional division, and there may be other divisions in actual implementation, and for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of systems or units through some communication interfaces, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed 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 can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute 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), a magnetic disk or an optical disk, and other various media capable of storing program codes.

Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; such modifications and substitutions do not depart from the spirit and scope of the present disclosure, and the present disclosure should be construed as being covered by the claims and the specification.

Claims

1. A management system for a virtual device, comprising:

each target virtual service sub-node in the at least one target virtual service sub-node is used for creating and distributing a number of virtual devices according to the received model information;

wherein the virtual device is a virtual ONVIF device.

2. The system of claim 1, further comprising:

and the modeling module is used for acquiring modeling data of the equipment to be modeled, establishing a virtual equipment model according to the modeling data, and outputting the identification of the virtual equipment model and corresponding model information to the model base.

3. The system of claim 2, wherein the modeling module obtains modeling data for a device to be modeled according to:

the first method is as follows: accessing physical equipment corresponding to equipment to be modeled, acquiring basic parameters of the physical equipment, and extracting modeling data of the equipment to be modeled according to the basic parameters;

the second method comprises the following steps: importing an interactive data packet corresponding to equipment to be modeled, and extracting modeling data of the equipment to be modeled according to the interactive data packet;

the third method comprises the following steps: and receiving configuration data of the equipment to be modeled, which is sent by the client, and extracting modeling data of the equipment to be modeled according to the configuration data.

4. The system of claim 1, wherein the virtual service parent node is further configured to:

and/or the presence of a gas in the gas,

and receiving a virtual equipment management instruction sent by the client, and managing the virtual equipment created by the virtual service child node according to the virtual equipment management instruction.

5. A management system for a virtual device, comprising:

the virtual service father node is used for receiving a virtual device creating request, and the virtual device creating request comprises a virtual device model identifier and a target number; determining at least one target virtual service sub-node according to the target quantity, distributing the target quantity to the at least one target virtual service sub-node, wherein each target virtual service sub-node corresponds to one distribution quantity, and sending the virtual equipment model identification and the distribution quantity to the corresponding target virtual service sub-node;

each target virtual service sub-node in the at least one target virtual service sub-node is used for inquiring a model base according to the virtual equipment model identification to obtain corresponding model information; creating a distributed number of virtual devices according to the model information;

wherein the virtual device is a virtual ONVIF device.

6. A management method of a virtual device is applied to a virtual service father node, and is characterized by comprising the following steps:

inquiring a model base according to the virtual equipment creating request to obtain model information corresponding to the virtual equipment model identification; determining at least one target virtual service sub-node according to the target number, distributing the target number to the at least one target virtual service sub-node, wherein each target virtual service sub-node corresponds to one distribution number, and sending the model information and the distribution number to the corresponding target virtual service sub-node, so that each target virtual service sub-node in the at least one target virtual service sub-node creates the virtual equipment with the distribution number according to the model information;

wherein the virtual device is a virtual ONVIF device.

7. The method of claim 6, further comprising:

and/or the presence of a gas in the gas,

8. A management method of virtual equipment is applied to a virtual service child node, and is characterized by comprising the following steps:

or the like, or, alternatively,

receiving virtual equipment model identification and distribution quantity sent by a virtual service father node, inquiring a model base according to the virtual equipment model identification to obtain corresponding model information, and establishing the distribution quantity of virtual equipment according to the model information;

wherein the virtual device is a virtual ONVIF device.

9. The method of claim 8, further comprising:

10. An electronic device, comprising: memory, processor and computer program stored on the memory and executable on the processor, characterized in that the processor executes when executing the computer program to implement the method according to any of claims 6 to 9.

11. A computer readable medium having computer readable instructions stored thereon which are executable by a processor to implement the method of any one of claims 6 to 9.