CN110943968B

CN110943968B - Equipment access control method and equipment access assembly

Info

Publication number: CN110943968B
Application number: CN201811121108.0A
Authority: CN
Inventors: 张清文; 张伟; 王兆俊
Original assignee: Hangzhou Hikvision System Technology Co Ltd
Current assignee: Hangzhou Hikvision System Technology Co Ltd
Priority date: 2018-09-25
Filing date: 2018-09-25
Publication date: 2022-04-26
Anticipated expiration: 2038-09-25
Also published as: CN110943968A

Abstract

The application provides a device access control method and a device access assembly, wherein the device access assembly comprises a service module and a drive module, the service module and the drive module correspond to different processes, and the processes are independent; wherein: the service module is used for providing a service entrance for the upper application and managing the drive module according to the access request of the upper application; the driving module is used for accessing equipment through a driving example; wherein, different types of equipment correspond to different driving modules; and the service module is also used for creating a new drive instance in the drive module when the number of the created drive instances in the drive module, which have access to the equipment, reaches the preset maximum number of the single instance supporting equipment. The method can improve the stability of equipment access and improve the equipment access capability of a single equipment access assembly.

Description

Equipment access control method and equipment access assembly

Technical Field

The application relates to security monitoring technologies, in particular to a device access control method and a device access component.

Background

At present, a large number of equipment manufacturers exist in the security field, and access modes and supported control/transmission protocols of security equipment (such as a monitoring camera) produced by each equipment manufacturer are not completely the same, so that great challenges are brought to equipment access of a security management platform.

Disclosure of Invention

In view of this, the present application provides a device access control method and a device access component.

Specifically, the method is realized through the following technical scheme:

according to a first aspect of an embodiment of the present application, an equipment access component is provided, which includes a service module and a driver module, where the service module and the driver module correspond to different processes, and the processes are independent of each other; wherein:

the service module is used for providing a service entrance for the upper application and managing the drive module according to the access request of the upper application;

the driving module is used for accessing equipment through a driving example; wherein, different types of equipment correspond to different driving modules;

and the service module is also used for creating a new drive instance in the drive module when the number of the created drive instances in the drive module, which have access to the equipment, reaches the preset maximum number of the single instance supporting equipment.

Optionally, the driver module includes a driver and driver module description information;

wherein the driver module description information includes: the device comprises a drive identification, a drive version, a device series supporting access and the maximum number of devices supported by a single instance.

Optionally, the service module includes: the device comprises a protocol agent unit, a device resource management unit and a drive management unit; wherein:

the protocol agent unit is used for receiving the access request and identifying the type of the access request;

the protocol agent unit is also used for sending the equipment resource issuing request to the equipment resource management unit when the access request is the equipment resource issuing request;

the device resource management unit is used for storing the device resource carried in the device resource issuing request and sending the device resource to the drive management unit;

the drive management unit is used for matching the managed drive module according to the drive identifier and the drive version of the drive module carried in the equipment resource issuing request;

the drive management unit is further configured to, when matching is successful and a drive instance that does not reach a preset maximum number of single-instance supported devices exists in the matched first target drive module, issue a device resource to the drive instance, so that the drive instance performs device access processing according to the device resource; and when the matched first target driving module does not have a driving instance which does not reach the maximum number of the supported equipment of the preset single instance, creating a new driving instance in the first target driving module, and issuing equipment resources to the created driving instance so that the created driving instance performs equipment access processing according to the equipment resources.

Optionally, the protocol proxy unit is further configured to send the driver module management request to the driver management unit when the access request is the driver module management request;

the drive management unit is also used for managing the managed drive module according to the drive module management request;

wherein the managing the managed driver module may include one or more of:

the method comprises the steps of obtaining information of an existing drive module, upgrading the existing drive module, uninstalling the existing drive module and installing a new drive module.

Optionally, the protocol proxy unit is further configured to send the device access request to the drive management unit when the access request is a device access request;

the drive management unit is further configured to query a corresponding relationship between the device identifier stored in the device access request and the drive instance according to the device identifier carried in the device access request, so as to determine the drive instance corresponding to the device identifier; and forwarding the device access request to the driver instance, so that the driver instance forwards the device access request to the device corresponding to the device identifier.

Optionally, the protocol proxy unit is further configured to send the device resource deletion request to the device resource management unit when the access request is a device resource deletion request;

the device resource management unit is further configured to delete a device resource stored by the device resource management unit and corresponding to the device identifier carried in the device resource deletion request, and send the device resource deletion request to the drive management unit;

the drive management unit is further configured to query a corresponding relationship between the device identifier stored in the device resource deletion request and the drive instance according to the device identifier carried in the device resource deletion request, so as to determine the drive instance corresponding to the device identifier; and issuing a resource deletion request to the driving instance so that the driving instance deletes the equipment resource corresponding to the equipment identifier.

Optionally, the driver module includes a capability program set and driver module description information;

wherein the driver module description information includes: the method comprises the steps of driving identification, driving version, type of supported access equipment, mapping relation between capability identification and capability program, and maximum number of supported equipment of a single instance.

Optionally, the service module is specifically configured to receive an access request, and identify a type of the access request;

the service module is further specifically configured to, when the access request is an equipment resource issuing request, store a correspondence between an equipment resource number carried in the equipment resource issuing request and a drive identifier and a drive version of a drive module, and match the managed drive module according to the drive identifier and the drive version of the drive module;

the service module is further specifically configured to, when matching is successful and a driver instance that does not reach a preset maximum number of single-instance supported devices exists in the matched second target driver module, issue device resources to the driver instance, so that the driver instance performs device access processing according to the device resources; when the matched second target driving module does not have a driving instance which does not reach the maximum number of the supporting equipment of the preset single instance, a new driving instance is created in the second target driving module, and equipment resources are issued to the created driving instance, so that the created driving instance performs equipment access processing according to the equipment resources;

the driver instance comprises a capability program process corresponding to each capability program in a capability program set included in the second target driver module.

Optionally, the service module is further specifically configured to, when the access request is an apparatus capability calling request, query, according to an apparatus resource number carried in the apparatus capability calling request, a correspondence between the apparatus resource number and a drive identifier and a drive version of the drive module, so as to determine a drive identifier and a drive version of the third target drive module that are matched with each other;

the service module is further specifically configured to match the managed drive module according to the drive identifier and the drive version of the third target drive module, so as to determine the matched third target drive module;

the service module is further specifically configured to query the capability program process in the third target driver module according to the capability identifier carried in the device capability call request, to determine a matched target capability program process, and forward the device capability call request to the target capability program process.

According to a second aspect of the embodiments of the present application, there is provided a device access control method applied to the device access component, where the method includes:

the service module receives an access request;

when the access request is an equipment resource issuing request, the service module matches the managed drive module according to the drive identifier and the drive version of the drive module carried in the equipment resource issuing request;

and when the matching is successful but the matched target drive module does not have a drive instance which does not reach the maximum number of the preset single instance supported equipment, the service module creates a new drive instance in the target drive module and issues equipment resources to the created drive instance so that the created drive instance performs equipment access processing according to the equipment resources.

According to the equipment access assembly of the embodiment of the application, the equipment access assembly comprising the service module and the drive module is deployed in the security management platform, different drive modules are respectively arranged for different types of equipment and used for equipment access, the drive modules carry out equipment access through the drive instances, when the number of the equipment accessed by the drive instances established in the drive modules reaches the preset maximum number of single instance supporting equipment, the service module establishes a new drive instance in the drive modules for equipment access, and the service module and the drive modules correspond to different processes which are independent of each other, so that the equipment access stability is improved; in addition, the service module can realize equipment access by newly building a drive instance, so that the equipment access capability of the single equipment access assembly is improved.

Drawings

Fig. 1 is a schematic diagram illustrating an architecture of a device access control system according to an exemplary embodiment of the present application;

FIG. 2 is a block diagram of a device access component according to an exemplary embodiment of the present application;

FIG. 3 is a schematic diagram illustrating a service module according to an exemplary embodiment of the present application;

fig. 4 is a flowchart illustrating a method for controlling device access according to an exemplary embodiment of the present application;

FIG. 5 is an architectural diagram of an application scenario illustrated in an exemplary embodiment of the present application;

FIG. 6A is a block diagram illustrating a device access component according to an exemplary embodiment of the present application;

FIG. 6B is a schematic diagram of a drive module shown in an exemplary embodiment of the present application;

fig. 6C is a schematic flowchart illustrating a device resource issuing process according to an exemplary embodiment of the present application;

FIG. 6D is a flow diagram illustrating the creation of a driver instance in accordance with an exemplary embodiment of the present application;

FIG. 7A is a schematic diagram illustrating a device access component according to yet another exemplary embodiment of the present application;

FIG. 7B is a schematic view of a drive module shown in yet another exemplary embodiment of the present application;

FIG. 7C is a flow diagram illustrating a device capability call in accordance with an illustrative embodiment of the present application;

fig. 7D is a schematic flowchart illustrating a device resource issuing process according to an exemplary embodiment of the present application;

fig. 7E is a flowchart illustrating a new access device according to an exemplary embodiment of the present application.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

In order to make those skilled in the art better understand the technical solution provided by the embodiment of the present invention, a brief description is given below of a system architecture to which the embodiment of the present invention is applicable.

Referring to fig. 1, an architectural schematic view of a device access control system provided in an embodiment of the present application is shown, and as shown in fig. 1, the device access control system may include a security management platform and a security device, where a device access component is deployed in the security management platform, and the device access component may include a service module and a drive module. Wherein:

a user (such as an administrator) can log in the security management platform and send an access request to the security management platform.

When the security management platform receives the access request, the access request can be sent to the service module of the equipment access component.

When the service module of the device access component receives the access request, the type of the access request can be determined, and different response measures can be taken according to the type of the access request.

Based on the device access control system shown in fig. 1, an embodiment of the present application provides a device access component, please refer to fig. 2, which is a schematic structural diagram of the device access component provided in the embodiment of the present application, as shown in fig. 2, the device access component may include a service module 210 and a driver module 220, the service module 210 and the driver module 220 correspond to different processes, and the processes are independent of each other; wherein:

the service module 210 is configured to provide a service entry for an upper application, and manage the driver module 220 according to an access request of the upper application;

a driving module 220, configured to perform device access through a driving instance; wherein, different types of equipment correspond to different driving modules;

the service module 210 is further configured to create a new driver instance in the driver module 210 when the number of the devices that have been accessed to the driver instance and have been created in the driver module 210 all reaches the preset maximum number of supported devices.

In the embodiment of the present application, in order to improve the stability of device access, the service module 210 and the driver module 220 correspond to different processes, and the processes are independent of each other, so that the normal operation of the service module 210 is not affected by an exception of the driver module 220, and it is possible to avoid that the access of all devices is affected by an exception of the service module 210 due to an exception of a single driver module 220; different types of devices correspond to different driver modules 220, different driver modules 220 correspond to different processes, and the processes are independent of each other, so that mutual influence caused by some unstable factors (such as instability of a device SDK (Software Development Kit)) in the access process of the different types of devices is avoided.

In this embodiment, the upper layer application may issue an access request to the service module 210 through the security management platform.

The service module 210 may provide a service portal for the upper layer application and manage the driver module 220 according to an access request of the upper layer application.

In this embodiment of the application, in order to improve the scalability of the device access function and improve the device access capability of the device access component, the driver module 220 may perform device access through the driver instance. Wherein each driving instance is an independent process.

When the number of devices accessed to the driver instances created in the driver module 220 reaches the preset maximum number of supported devices, the service module 210 may create the driver instances in the driver module 220.

The preset maximum number of devices supported by a single instance (i.e., the maximum number of devices supported and accessed by a single drive instance) corresponding to the drive module may be set according to an actual scene and stored in the service module, or stored in the drive module as the description information of the drive module.

Optionally, the preset maximum number of supported devices of a single instance corresponding to different driving modules may be the same or different.

In one embodiment of the present application, the driver module 220 may include a driver and driver module description information;

In this embodiment, the driver module 220 may include a driver and driver module description information. The description information of the driving module may include a driving identifier, a driving version, a series of devices supporting access, a maximum number of devices supported by a single instance, and the like, and when the driving module 220 is newly added, the upper layer application and service module 210 may obtain the capability of the newly added driving module 220 by reading the description information of the driving module without any additional configuration, thereby further improving the expandability of the device access function.

As an implementation manner of this embodiment, as shown in fig. 3, the service module 210 may include: a protocol agent unit 211, a device resource management unit 212, and a drive management unit 213; wherein:

a protocol agent unit 211, configured to receive an access request and identify a type of the access request;

the protocol agent unit 211 is further configured to send the device resource issuing request to the device resource management unit 212 when the access request is the device resource issuing request;

the device resource management unit 212 is configured to store the device resource carried in the device resource issuing request, and send the device resource to the drive management unit 213;

the drive management unit 213 is configured to match the managed drive module 220 according to the drive identifier and the drive version of the drive module 220 carried in the device resource issuing request;

the driver management unit 213 is further configured to, when matching is successful and a driver instance that does not reach the preset maximum number of devices supported by a single instance exists in the matched first target driver module, issue a device resource to the driver instance, so that the driver instance performs device access processing according to the device resource; and when the matched first target driving module does not have a driving instance which does not reach the maximum supported equipment number of the preset single instance, creating a new driving instance in the first target driving module, and issuing equipment resources to the created driving instance so that the created driving instance performs equipment access processing according to the equipment resources.

In this embodiment, when a user (such as an administrator) needs to perform device access, a device resource issuing request may be sent to the device access component through the security management platform, where the device resource issuing request may carry a driver identifier and a driver version of a driver module that are matched with a device that requests access.

For example, when the security management platform detects a device access operation instruction, a device access operation interface may be presented, where the device access operation interface includes input boxes and/or options such as device description information (including but not limited to device identification, device manufacturer, series, version, and the like), device access information (including but not limited to access mode, IP address, user name, password, and the like).

When the security management platform receives a device access instruction input through the device access operation interface, the security management platform can determine a matched driving module according to information such as a device manufacturer, a series and a version carried in the device access instruction, and display a matched driving module list, wherein the driving module list comprises driving identifications and driving versions of one or more driving modules.

When the security management platform receives the adding and storing instruction, the security management platform can send an equipment resource issuing request to the equipment access component, wherein the equipment resource issuing request can carry equipment resources (including information such as the equipment description information and the equipment access information) and the drive identification and the drive version of the selected drive module.

In this embodiment, when the service module 210 of the device access component receives an access request, the protocol agent module 211 may identify a type of the access request, and send the device resource issue request to the device resource management unit 212 when the access request is a device resource issue request.

The device resource management unit 212 may store the device resource carried in the device resource issuing request, and send the device resource to the drive management unit 213.

The driving management unit 213 matches the driving module 220 managed by itself according to the driving identifier and the driving version of the driving module 220 carried in the device resource issuing request, so as to determine whether there is a driving module 220 (referred to as a first target driving module herein) matching the driving identifier and the driving version of the driving module.

When the driver management unit 213 successfully matches the driver module 220 managed by itself according to the driver identifier and the driver version of the driver module 220 carried in the received device resource issuing request, that is, when a first target driver module matching the driver identifier and the driver version of the driver module carried in the device resource issuing request exists in the driver module 220 managed by the service module 210, the driver management unit 213 may further determine whether a driver instance exists in the first target driver module.

When the drive management unit 213 determines that there is a drive instance in the first target drive module, the drive management unit 213 may further determine whether there is a drive instance that does not reach the preset single-instance maximum supported device number. If the device resource exists, the driving management unit 213 may issue the device resource carried in the device resource issue request to the driving instance (the driving instance that does not reach the maximum number of devices supported by the preset single instance), and the driving instance performs device access processing according to the received device resource.

It should be noted that, in this embodiment of the present application, after determining the driver instance of the issued device resource, the driver management unit 213 may further record a corresponding relationship between the device resource and the driver instance, such as a corresponding relationship between a device identifier and the driver instance, so that when performing device access in a subsequent process, the driver instance corresponding to the accessed device can be determined according to the recorded corresponding relationship between the device identifier and the driver instance.

In addition, in this embodiment of the application, when the drive management unit 213 fails to match the managed drive module according to the drive identifier and the drive version of the drive module 220 carried in the received device resource issuing request, that is, when a target drive module matching the drive identifier and the drive version of the drive module 220 does not exist in the drive module 220 managed by the drive management unit 213, the drive management unit 213 may reject to process the device resource issuing request, or process according to other policies, and specific implementation thereof is not described herein.

Further, in this embodiment, the protocol agent unit 211 is further configured to send the driver module management request to the driver management unit 213 when the access request is the driver module management request;

a drive management unit 213, further configured to manage the managed drive module according to the drive module management request;

wherein, managing the managed driving module may include one or more of:

In this embodiment, the security management platform may further manage the driver module in the device access component by sending a driver module management request, such as obtaining information of an existing driver module, upgrading the existing driver module, uninstalling the existing driver module, installing a new driver module, and the like.

When the security management platform sends a drive module management request to the device access component, an identification field for identifying the management operation type can be carried in the drive module management request.

For example, when the value of the identification field is 00, the management operation type corresponding to the management request of the drive module is to acquire the information of the existing drive module; when the value of the identification field is 01, the management operation type corresponding to the management request of the drive module is to upgrade the existing drive module; when the value of the identification field is 10, the management operation type corresponding to the management request of the drive module is to unload the existing drive module; and when the value of the identification field is 11, the management operation type corresponding to the management request of the drive module is installation of a new drive module.

In this embodiment, when the protocol agent unit 211 of the service module 210 receives the driver module management request, the driver module management request may be transmitted to the driver management unit 213.

The drive management unit 213 may identify a management operation type corresponding to the drive module management request.

When the management operation type is to acquire information of an existing driver module, the driver management unit 213 may acquire information of all managed driver modules, which includes but is not limited to a driver identifier, a driver version, an access-supported device series, a maximum number of devices supported by a single instance, whether a driver instance exists, a number of devices accessed by the driver instance, and the like, and return the acquired information of the driver module to the security management platform.

When the management operation type is to upgrade the existing drive module, the drive module management request can also carry a drive identifier and a drive version of the drive module to be upgraded and a version to which the drive module needs to be upgraded; the drive management unit 213 may determine the drive module to be upgraded according to the drive identifier and the drive version of the drive module to be upgraded carried therein, and upgrade the version of the drive module to the version to be upgraded.

The upgrade file required for the driver module upgrade may be carried in the driver module management request, or may be downloaded by the service module 210 after receiving the driver module management request.

When the management operation type is to unload the existing drive module, the drive module management request can also carry a drive identifier and a drive version of the drive module to be unloaded; the drive management unit 213 may determine a drive module that needs to be uninstalled according to the drive identifier and the drive version of the drive module that needs to be uninstalled and uninstall the drive module.

When the management operation type is that a new drive module is installed, the drive module management request can also carry an installation file of the drive module to be installed; the drive management unit 213 may perform drive module installation according to the installation file of the drive module to be installed carried therein.

Further, in this embodiment, the protocol proxy unit 211 is further configured to send the device access request to the drive management unit 213 when the access request is the device access request;

the drive management unit 213 is further configured to query, according to the device identifier carried in the device access request, a correspondence between the device identifier stored in the device management unit and the drive instance, so as to determine the drive instance corresponding to the device identifier; and forwarding the device access request to the driver instance, so that the driver instance forwards the device access request to the device corresponding to the device identifier.

In this embodiment, the service module 210 may store a corresponding relationship between a driver instance in each driver module 220 managed by itself and a device identifier of a device accessed to the driver management platform through the driver instance.

When the protocol agent unit 211 of the service module 210 receives the device access request, the device access request may be transmitted to the drive management unit 213.

The drive management unit 213 may query the correspondence between the device identifier stored in the device access request and the drive instance according to the device identifier (the device identifier of the device requesting access) carried in the device access request, so as to determine the drive instance accessed by the device requesting access.

After querying the driver instance accessed by the device requesting access, the driver management unit 213 may send the device access request to the driver instance; when receiving the device access request, the driver instance may forward the device access request to the corresponding device according to the device identifier carried therein, so as to implement device access.

Further, in this embodiment, the protocol proxy unit 211 is further configured to send a device resource deletion request to the device resource management unit 212 when the access request is the device resource deletion request;

the device resource management unit 212 is further configured to delete a device resource stored by the device resource management unit and corresponding to the device identifier carried in the device resource deletion request, and send the device resource deletion request to the drive management unit 213;

the drive management unit 213 is further configured to query, according to the device identifier carried in the device resource deletion request, a correspondence between the device identifier stored in the drive management unit and the drive instance, so as to determine the drive instance corresponding to the device identifier; and issuing a resource deletion request to the driving instance so as to enable the driving instance to delete the equipment resource corresponding to the equipment identifier.

When the device is removed from the security management system, the security management platform needs to delete the device resource of the relevant device.

In this embodiment, when the protocol agent unit 211 of the service module 210 receives the device resource deletion request, the device resource deletion request may be transmitted to the device resource management unit 212.

On one hand, the device resource management unit 212 may delete the device resource stored by itself and corresponding to the device identifier carried in the device resource deletion request, and the corresponding relationship between the device identifier and the driver instance.

On the other hand, the device resource management unit 212 may transmit a device resource deletion request to the drive management unit 213.

The drive management unit 213 may query the corresponding relationship between the device identifier stored in the device resource deletion request and the drive instance according to the device identifier carried in the device resource deletion request, so as to determine the drive instance to which the device requesting deletion is accessed.

After querying the driver instance accessed by the device requesting deletion, the driver management unit 213 may send a device resource deletion request to the driver instance; when receiving the device resource deletion request, the driver instance may delete the device resource corresponding to the device identifier carried therein.

In another embodiment of the present application, the driver module may include a capability program set and driver module description information;

wherein the driver module description information includes: the driving identification, the driving version, the type of the supported access equipment, and the mapping relation between the capability identification and the capability program.

In this embodiment, the device may be divided into capabilities, the work of accessing the device is decomposed into providing corresponding capability programs for the respective capabilities, and the devices with different capabilities may be divided into different types of devices.

The driver module may include a capability set (which may include one or more capability programs) and driver module description information, and the service module may identify the driver module and manage the capability set through the driver module description information, and the newly added driver module does not need to modify or additionally configure the service module.

The driving module is used for completing access of one type of equipment, wherein the capability programs run in an independent process mode, different capabilities of the same equipment are not influenced by each other, and access implementation of different equipment is not influenced by each other.

For example, the functions of the device may be classified and analyzed into different capabilities, and depending on whether the main reference function is complete and independent, stable or needs to be changed frequently, for example, the capabilities of the security monitoring device may include:

i. basic video monitoring capability: may include preview, playback, pan-tilt, basic events, etc.;

general parameter configuration capability: may include various video compression parameters, network parameter configurations, user account configurations, etc.;

smart event capability: the method can comprise intelligent rule configuration, intelligent event or alarm arming and disarming, event or alarm receiving and forwarding and the like;

alarm host capability: and the method can comprise alarm host parameter configuration, event arming and disarming, event or alarm receiving and forwarding and the like.

The capability program set is formed by one or more capability programs, and the drive module can realize equipment access through the capability program set.

For example, the driving module may include:

i. the basic video monitoring capability program, the general parameter configuration capability program and the description information of the corresponding driving module form a general video monitoring device driving module which is used for accessing the general video monitoring device;

the basic video monitoring capability program, the general parameter configuration capability program, the intelligent event capability program and the description information of the corresponding driver modules form an intelligent device driver module for accessing the intelligent device

And iii, forming a video alarm host driving module by the basic video monitoring capability program, the general parameter configuration capability program, the alarm host capability program and the description information of the corresponding driving module, wherein the video alarm host driving module is used for accessing video alarm host equipment.

As an implementation manner of this embodiment, the service module 210 is specifically configured to receive an access request, and identify a type of the access request;

the service module 210 is further specifically configured to, when the access request is an equipment resource issuing request, store a correspondence between an equipment resource number carried in the equipment resource issuing request and a drive identifier and a drive version of the drive module, and match the managed drive module 220 according to the drive identifier and the drive version of the drive module;

the service module 210 is further specifically configured to, when matching is successful and a driving instance that does not reach the preset maximum supported device number exists in the matched second target driving module, issue a device resource to the driving instance, so that the driving instance performs device access processing according to the device resource; when the matched second target driving module does not have a driving instance which does not reach the preset maximum supported equipment number, a new driving instance is created in the second target driving module, and equipment resources are issued to the created driving instance, so that the created driving instance performs equipment access processing according to the equipment resources;

the driver instance includes a capability program process corresponding to each capability program in a capability program set included in the second target driver module.

In the embodiment of the present application, when the service module 210 receives the access request, the type of the access request may be identified.

When the service module 210 determines that the received access request is an equipment resource issuing request, on one hand, the corresponding relationship between the equipment resource number carried in the equipment resource issuing request and the drive identifier and drive version of the drive module may be stored, and on the other hand, the managed drive module 220 may be matched according to the drive identifier and drive version of the drive module.

When the matching is successful, that is, a management module 220 (referred to as a second target driver module herein) matching the driver module identifier and the driver version carried in the device resource issuing request exists in the driver module 220 managed by the service module 210, the service module 210 may further determine whether a driver instance that does not reach the preset maximum supported device number exists in the second target driver module. If the device resource exists, the service module 210 may issue the device resource to the driver instance in the second target driver module that does not reach the preset maximum supported device number.

When a plurality of driver instances which do not reach the preset maximum number of supported devices exist in the second target driver module, the service module 210 may randomly or according to other policies select one of the driver instances which do not reach the preset maximum number of supported devices to issue device resources.

When receiving the device resource issued by the service module 210, the driver instance may perform device access according to the device resource.

In this embodiment, when there is no driving instance in the second target driving module that does not reach the preset maximum supported device number, the service module 210 may create a new driving instance in the second target driving module, issue a device resource to the created driving instance, and perform device access processing by the created driving instance according to the device resource.

As another implementation manner of this embodiment, the service module 210 is further specifically configured to, when the access request is an apparatus capability call request, query, according to an apparatus resource number carried in the apparatus capability call request, a corresponding relationship between the apparatus resource number and a drive identifier and a drive version of the drive module, so as to determine a drive identifier and a drive version of the matched third target drive module;

the service module 210 is further specifically configured to match the managed drive module according to the drive identifier and the drive version of the third target drive module, so as to determine the matched third target drive module;

the service module 210 is further specifically configured to query the capability program process in the third target driver module according to the capability identifier carried in the device capability calling request, to determine a matched target capability program process, and forward the device capability calling request to the target capability program process.

In this embodiment, when a user needs to invoke the capability of the device accessed by the device access component, for example, invoke the basic video monitoring capability of the general video monitoring device, an equipment capability invocation request may be issued to the device access component through the management platform, and the equipment resource number and the capability identifier may be carried in the equipment capability invocation request.

When receiving the device capability calling request, the service module 210 may query, according to the device resource number carried therein, a corresponding relationship between the device resource number and the drive identifier and the drive version of the drive module, to determine the drive identifier and the drive version of the drive module (referred to as a third target drive module herein) matching the device resource number carried in the device capability calling request, and match the managed drive module 220 according to the drive identifier and the drive version of the third target drive module, to determine the matched third target drive module.

After the service module 210 determines the third target driver module, it may query a capability program process in the third target driver module according to the capability identifier carried in the device capability invocation request to determine a capability program process (referred to as a target capability program process herein) matched with the capability identifier, and forward the device capability invocation request to the target capability program process to implement device capability invocation.

Based on the device access control system shown in fig. 1, an embodiment of the present application provides a device access control method, please refer to fig. 4, which is a flowchart illustrating the device access control method provided in the embodiment of the present application, where the device access control method may be applied to a device access component deployed in a security management platform, where the device access component includes a service module and a driver module, and as shown in fig. 4, the device access control method may include the following steps:

step S400, the service module receives the access request.

Step S410, when the access request is the equipment resource issuing request, the service module matches the managed drive module according to the drive identification and the drive version of the drive module carried in the equipment resource issuing request.

Step S420, when the matching is successful, but there is no driving instance in the matched target driving module that does not reach the preset maximum number of single-instance supported devices, the service module creates a new driving instance in the target driving module, and issues device resources to the created driving instance, so that the created driving instance performs device access processing according to the device resources.

In one embodiment of the present application, the driver module includes a driver and driver module description information;

In this embodiment, the type of the access request may include, but is not limited to, a device resource issuing request, a device resource deleting request, a driver module management request or a device access request, etc.

When a service module of a device access component receives an access request, the access request can be identified to determine a type of the access request.

In this embodiment, when a user (such as an administrator) needs to perform device access, a device resource issuing request may be sent to the device access component through the security management platform, where the device resource issuing request may carry a drive identifier and a drive version of a drive module that are matched with a device that requests access.

In an embodiment, when a service module of a device access component receives a device resource issuing request, the service module may match a driving module managed by the service module according to a driving identifier and a driving version of the driving module carried in the device resource issuing request, so as to determine whether a driving module (i.e., a target driving module, which is referred to as a first target driving module in this embodiment) matching the driving identifier and the driving version of the driving module exists.

In this embodiment, when the service module successfully matches the driver module managed by the service module itself according to the driver identifier and the driver version of the driver module carried in the received device resource issuing request, that is, when a target driver module matching the driver identifier and the driver version of the driver module carried in the device resource issuing request exists in the driver module managed by the service module, the service module may further determine whether a driver instance exists in the target driver module.

The driving module realizes equipment access through driving examples, and each driving example is an independent process.

In this embodiment, when the service module determines that a driver instance exists in the target driver module, the service module may further determine whether a driver instance that does not reach the preset maximum number of supported devices for a single instance exists.

And when the matched target drive module does not have a drive instance which does not reach the maximum number of the preset single-instance supporting equipment, the service module creates a new drive instance in the target drive module and issues equipment resources to the created drive instance so that the created drive instance performs equipment access processing according to the received equipment resources.

In this embodiment, when the service module determines that there is no driving instance in the first target driving module that does not reach the preset single-instance maximum supported device number, for example, there is no driving instance in the first target driving module, or there is a driving instance in the first target driving module but the driving instance has reached the preset single-instance maximum supported device number, the service module may create a new driving instance in the first target driving module, issue a device resource to the created driving instance, and perform device access processing by the created driving instance according to the received device resource.

In this embodiment, if there is a drive instance of the device that does not reach the maximum support of the preset single instance in the first target drive module, the service module may issue the device resource carried in the device resource issue request to the drive instance (the drive instance that does not reach the maximum support of the preset single instance), and the drive instance performs device access processing according to the received device resource.

When receiving the device resource issued by the service module, the driver instance may establish connection with the corresponding device according to the device access information included therein, so as to implement device access.

It should be noted that, in the embodiment of the present application, after the service module determines the driver instance of the issued device resource, the corresponding relationship between the device resource and the driver instance may also be recorded, for example, the corresponding relationship between the device identifier and the driver instance is recorded, so that when device access is performed in the subsequent process, the driver instance corresponding to the accessed device may be determined according to the recorded corresponding relationship between the device identifier and the driver instance.

In addition, in this embodiment of the application, when the service module fails to match the managed drive module according to the drive identifier and the drive version of the drive module carried in the received device resource issuing request, that is, when the drive module managed by the service module does not have a target drive module matching the drive identifier and the drive version of the drive module, the service module may refuse to process the device resource issuing request, or process according to other policies, which is not described herein in detail.

Further, in this embodiment, when the access request received by the service module is a driver module management request, the method may further include:

the service module manages the managed drive module according to the drive module management request;

the management of the managed driver module may include, but is not limited to, one or more of the following:

In this embodiment, when the service module receives the driver module management request, the service module may identify a management operation type corresponding to the driver module management request.

When the management operation type is to acquire the information of the existing drive module, the service module may acquire the information of all the managed drive modules, which includes but is not limited to a drive identifier, a drive version, a series of devices supporting access, a maximum number of devices supported by a single instance, whether a drive instance exists, a number of devices to which the drive instance has access, and the like, and return the acquired information of the drive module to the security management platform.

When the management operation type is to upgrade the existing drive module, the drive module management request can also carry a drive identifier and a drive version of the drive module to be upgraded and a version to which the drive module needs to be upgraded; the service module can determine the drive module needing to be upgraded according to the drive identifier and the drive version of the drive module needing to be upgraded carried in the service module, and upgrade the version of the drive module to the version needing to be upgraded.

The upgrade file required by the driver module upgrade can be carried in the driver module management request, or can be downloaded by the service module after receiving the driver module management request.

When the management operation type is to unload the existing drive module, the drive module management request can also carry a drive identifier and a drive version of the drive module to be unloaded; the service module can determine the driver module needing to be unloaded according to the driver identifier and the driver version of the driver module needing to be unloaded carried in the service module, and unload the driver module.

When the management operation type is that a new drive module is installed, the drive module management request can also carry an installation file of the drive module to be installed; the service module can install the drive module according to the installation file of the drive module which is carried in the service module and needs to be installed.

Further, in this embodiment, when the access request received by the service module is a device access request, the method may further include:

the service module inquires the corresponding relation between the equipment identification stored in the service module and the driving instance according to the equipment identification carried in the equipment access request so as to determine the driving instance corresponding to the equipment identification;

and the service module forwards the equipment access request to the determined driving instance so that the driving instance forwards the equipment access request to the equipment corresponding to the equipment identification.

In this embodiment, the service module may store a corresponding relationship between a driver instance in each driver module managed by the service module and a device identifier of a device accessed to the driver management platform through the driver instance.

When the service module receives the device access request, the service module may query a correspondence between the device identifier stored in the service module and the driver instance according to the device identifier (the device identifier of the device requesting access) carried in the device access request, so as to determine the driver instance to which the device requesting access is accessed.

After the service module inquires the driver instance accessed by the device requesting access, the service module can send the device access request to the driver instance; when receiving the device access request, the driver instance may forward the device access request to the corresponding device according to the device identifier carried therein, so as to implement device access.

Further, in this embodiment, when the access request received by the service module is a device resource deletion request, the method may further include:

the service module inquires the corresponding relation between the equipment identifier stored in the service module and the driving instance according to the equipment identifier carried in the equipment resource deleting request so as to determine the driving instance corresponding to the equipment identifier;

and the service module issues a resource deletion request to the driver instance so that the driver instance deletes the equipment resource corresponding to the equipment identifier.

In this embodiment, when a device is removed from the security management system, the security management platform needs to delete the device resource of the relevant device.

When the service module receives the device resource deletion request, the service module may query a correspondence between the device identifier stored in the service module and the driver instance according to the device identifier carried in the device resource deletion request, so as to determine the driver instance to which the device requesting deletion is accessed.

After the service module inquires the drive instance accessed by the equipment requesting to delete, the service module can send the equipment resource deletion request to the drive instance; when receiving the device resource deletion request, the driver instance may delete the device resource corresponding to the device identifier carried therein.

It should be noted that, in this embodiment, when the service module receives the device resource deletion request, it is further required to delete the device resource stored by the service module and corresponding to the device identifier carried in the device resource deletion request, and the corresponding relationship between the device identifier and the driver instance.

Further, in this embodiment, for any driver instance, when the service module monitors that the device resource corresponding to the driver instance is deleted, the service module deletes the driver instance.

For example, for any driver instance, the service module may delete the driver instance when it is monitored that the corresponding relationship between the driver instance and the device identifier stored in the service module is deleted.

In another embodiment of the present application, the driver module includes a capability program set and driver module description information;

In this embodiment, the specific implementation that the security management platform sends the device resource issuing request to the service module may refer to the related description in the above embodiment, and this embodiment of the present application is not described herein again.

In this embodiment, when the service module receives the device resource issuing request, on one hand, the corresponding relationship between the device resource number carried in the device resource issuing request and the drive identifier and the drive version of the drive module may be stored, and on the other hand, the managed drive module may be matched according to the drive identifier and the drive version of the drive module.

When the matching is successful, the service module may further determine whether there is a driver instance that does not reach the preset maximum number of supported devices of the single instance in the matched driver module (i.e., the target driver module, which is referred to as a second target driver module in this embodiment).

If not, the service module may create a new driver instance in the second target driver module, where the driver instance includes capability program processes corresponding to the capability programs in the capability program set included in the second target driver module.

After the service module creates a new driver instance in the second target driver module, the service module may issue device resources to the created driver instance; the created drive instance can perform device access processing according to the received device resources through the capability program process corresponding to each capability program in the capability program set.

In this embodiment, if there is a drive instance with a number of devices not reaching the maximum number of supported devices of the preset single instance in the second target drive module, the service module may issue the device resource to the drive instance with the number of devices not reaching the maximum number of supported devices of the preset single instance, and the drive instance may perform device access processing according to the received device resource through the capability program process corresponding to each capability program in the capability program set.

Further, in this embodiment, when the access request received by the service module is a device capability invocation request, the method may further include:

the service module inquires the corresponding relation between the equipment resource number and the driving identifier and the driving version of the driving module according to the equipment resource number carried in the equipment capacity calling request so as to determine the driving identifier and the driving version of the matched third target driving module;

the service module matches the managed drive module according to the drive identifier and the drive version of the third target drive module to determine the matched third target drive module;

and the service module inquires the capability program process in the third target drive module according to the capability identifier carried in the equipment capability calling request to determine the matched target capability program process, and forwards the equipment capability calling request to the target capability program process.

When the service module receives the device capability calling request, the service module may query, according to the device resource number carried in the device capability calling request, a corresponding relationship between the device resource number and the drive identifier and the drive version of the drive module, to determine the drive identifier and the drive version of the drive module (i.e., the third target drive module) matched with the device resource number carried in the device capability calling request, and match the managed drive module according to the drive identifier and the drive version of the third target drive module, to determine the matched third target drive module.

After the service module determines the third target driver module, the service module may query a capability program process in the third target driver module according to the capability identifier carried in the device capability calling request to determine a capability program process (i.e., a target capability program process) matched with the capability identifier, and forward the device capability calling request to the target capability program process to implement device capability calling.

In order to enable those skilled in the art to better understand the technical solutions provided in the embodiments of the present application, the following describes the technical solutions provided in the embodiments of the present application with reference to specific application scenarios.

Please refer to fig. 5, which is a schematic diagram of an architecture of a security management scenario provided in an embodiment of the present application, as shown in fig. 5, the security management scenario includes a client (including but not limited to a desktop client or a mobile application client in a user computer), a security management platform, and a security device, where the security management platform may include a background server of the security management platform, and a management center, a device access component, and other service components (such as a media component, an event component, a storage component, etc.) are deployed in the background server; the device access component may include a service module and a driver module.

In this embodiment, a user (e.g., an administrator) may log in to a management center of the security management platform through the client, and send an access request, such as an equipment resource issuing request, an equipment resource deleting request, a drive module management request, or an equipment access request, to the security management platform through the management center.

It should be noted that, in this embodiment of the application, the management center, the device access component, and the other service components may be deployed in the same backend server as shown in fig. 5, or may be deployed in different backend servers, for example, the management center and the other service components are deployed in one backend server, and the device access component is deployed in another backend server; alternatively, the management center, the device access component and other service components are respectively deployed in different backend servers (not shown in the figure).

Example one

As shown in fig. 6A, the service module in the device access component may include a protocol agent sub-module, a device resource management sub-module, and a driver management sub-module.

Different manufacturers correspond to different driver modules, for example, in fig. 6A, the device of manufacturer a and the device of manufacturer B are respectively accessed through different driver modules.

Different series of devices of the same manufacturer correspond to different driver modules, for example, x series devices and y series devices of manufacturer B in fig. 6A are respectively accessed through different driver modules.

Different versions of devices of the same manufacturer correspond to different driver modules, for example, in fig. 6A, a manufacturer x series 1.0 version device and a manufacturer x series 1.1 version device are respectively accessed through different driver modules, which not only ensures the stability of the device accessed by the driver module V1.0, but also can access and use new functions of a new version device through the driver module V1.1.

Wherein, different drive modules correspond to different processes and are independent of each other.

As shown in fig. 6B, in this embodiment, the driver module may include a driver and driver module description information;

wherein the driver module description information may include: the device comprises a drive identification, a drive version, a device series supporting access and the maximum number of devices supported by a single instance.

When a drive module is newly added, the upper layer application and service module can identify the drive module by reading the description information of the drive module without additional configuration.

In this embodiment, the main functions of the service module include, on the one hand, management of the driver module and the driver instance, for example, installation, uninstallation, and upgrade of the driver module, creation, deletion, and restart of the driver instance, and the like.

Another aspect includes providing a service portal to an upper layer application, addressing an access request of the upper layer application to a driver instance and forwarding a request broker to the driver instance.

It should be noted that, for an access request of an upper layer application, the service module only needs to specify and parse a field for implementing addressing of the driver instance, and other contents are not limited.

The main functions of each sub-module in the service module are explained below.

In this embodiment, the Protocol agent sub-module provides an HTTP (HyperText Transfer Protocol) service, and provides a service entry for an upper application.

The protocol agent submodule standardizes a URL (Uniform Resource Locator) and a request header of the access request; when the protocol agent submodule receives the access request, the type of the access request, such as an equipment resource issuing request, an equipment resource deleting request, a drive module management request or an equipment access request, can be identified according to the URL and the request head of the access request, and the access request is respectively forwarded to the drive management submodule and the equipment resource management submodule according to the type of the access request.

It should be noted that, in this embodiment, the protocol agent submodule may not limit the format of the message of the access request, for example, JSON (JavaScript Object Notation) format or XML (Extensible Markup Language) format may be adopted.

In this embodiment, when the device resource management sub-module receives the device resource issuing request, the device resource to be issued may be sent to the driver management sub-module, and the driver management sub-module issues the device resource to the driver instance of the corresponding driver module.

When the device resource management submodule receives the device resource deletion request, the device resource management submodule can delete the relevant device resources stored in the device resource management submodule, and send the device resource deletion request to the drive management submodule, and the drive management submodule indicates the drive instance of the corresponding drive module to delete the relevant device resources.

It should be noted that, in this embodiment, the device resource management submodule may perform full device resource synchronization with the management center when the service module is started, and may also perform device resource synchronization with the management center periodically, so as to ensure consistency between the device resources stored by the device resource management submodule and the device resources in the management center.

When the equipment resource management submodule and the management center carry out equipment resource information synchronization, the equipment resource management submodule can execute equipment resource issuing operation on equipment resources which do not exist in the equipment resource management submodule but exist in the management center; for the device resources that exist in the device resource management submodule but do not exist in the management center, the device resource management submodule may perform a device resource deletion operation.

In this embodiment, the access request received by the driver management submodule mainly includes a driver module management request, a device resource issuing request, a device resource deleting request, and a device access request. Wherein:

when the driver management sub-module receives the driver module management request, the driver management sub-module may perform management operations such as obtaining information of an existing driver module, upgrading the existing driver module, uninstalling the existing driver module, or installing a new driver module, according to the type of the management operations.

When the drive management submodule receives the equipment resource issuing request, the drive management submodule can match the drive module managed by the drive management submodule according to the drive identification and the drive version of the drive module carried in the request.

If the matching is successful, judging whether the matched driving module has a driving instance. If the driver instances do not reach the maximum equipment number supported by the single instance, issuing equipment resources to the driver instances; and if the driving examples do not exist or exist but all the driving examples reach the maximum equipment number supported by the single example, creating a new driving example and issuing equipment resources to the newly created driving example.

If the matching fails, the current flow is ended, and the schematic diagram thereof may be as shown in fig. 6C.

As shown in fig. 6D, the specific process of creating the driver instance by the driver management submodule is as follows:

the drive management submodule creates a process (namely a drive instance) and transmits parameters to the drive instance through a command line; the parameter may include, but is not limited to, a drive management submodule port.

And the drive instance acquires the command line parameters and initiates registration to the port of the drive management submodule.

The driver management submodule receives driver instance registration and adds the driver instance registration to a driver instance list.

In this embodiment, when the driver management submodule receives the device resource deletion request, the device resource deletion request is issued to the corresponding driver instance, so that the driver instance deletes the relevant device resource.

When the driver management sub-module receives the device access request, the driver management sub-module may query the corresponding relationship between the device identifier and the driver instance stored in the driver management sub-module according to the device identifier to determine the driver instance corresponding to the device requesting access, forward the device access request to the driver instance, and forward the device access request to the corresponding device by the driver instance.

It should be noted that, in this embodiment, the driver management submodule may also monitor the operation of the driver instance. Wherein:

when all the equipment resources in the drive instance are deleted and no equipment resource needing to be managed exists, the drive management submodule can delete the drive instance;

when the driving instance runs abnormally due to the factors such as the abnormal SDK of the equipment, the driving management submodule can restart the driving instance running abnormally.

Example two

As shown in fig. 7A, the driving modules of the device accessing component can access different types of devices respectively (divide the device types by function).

Different types of devices correspond to different driver modules, for example, the general video monitoring device, the alarm host device, and the intelligent device in fig. 7A are respectively accessed through different driver modules.

As shown in FIG. 7B, in this embodiment, the driver module may include capability sets and driver module description information;

wherein the driver module description information may include: the driving identification, the driving version, the type of the supported access equipment, and the mapping relation between the capability identification and the capability program.

In this embodiment, the maximum number of devices supported by a single instance of the driver module is not limited, that is, the driver module is assumed to have sufficient resources for device access.

In this embodiment, the service module provides HTTP services, providing a service portal for upper layer applications.

The service module block specifies a URL (Uniform Resource Locator) and a request header of the access request. For each access request, a device resource number and a capability identification need to be carried, the capability identification being described in an interface document (defined by the drive unit) as part of the interface.

It should be noted that, in this embodiment, the service module may not limit the format of the message of the access request, for example, a JSON format or an XML format may be adopted.

And when the service module receives the access request, analyzing the equipment resource number and the capability identification according to the URL and the request head of the access request.

The service module can query the corresponding relation between the device resource number stored in the service module and the drive identifier and the drive version according to the device resource number carried in the access request to determine the corresponding drive identifier and drive version, and further query the matched drive module according to the drive identifier and drive version.

After the matched driving module is inquired, the service module can inquire the matched capability program process in the driving module according to the capability identifier carried in the access request.

If the matched capability program process is inquired, forwarding the access request agent to the matched capability program process; if the matching capability program process is not queried, the capability program process matching the capability identifier is started, and the access request agent is forwarded to the matching capability program process, which may be shown in fig. 7C.

As shown in fig. 7D, in this embodiment, the flow of the service module issuing the device resource to the driver module is as follows:

adding equipment to the management platform, and selecting a driving module; the basis for selecting the driving module is the type of the supported access equipment included in the description information of the driving module.

The management platform can send a device resource issuing request to the service module through the interface of the service module, wherein the device resource issuing request carries a device resource number, a driving identifier and a driving version.

And when receiving the equipment resource issuing request, the service module stores the corresponding relation between the carried equipment resource number and the drive identifier and the drive version, and queries the drive module managed by the service module according to the carried drive identifier and the drive version.

And if the matched driving module exists, issuing the equipment resource.

And if the matched driving module does not exist, ending the current flow.

It should be noted that, in this embodiment, when the service module queries the matched driver module, before the device resource is issued, it may also query whether the capability program process corresponding to the driver module is started, and if so, directly issue the device resource to the corresponding capability program process to implement device access; if not, the corresponding capability program process is started first, and the device resource is issued to the newly started capability program process, so as to realize device access.

Further, in this embodiment, when a new device needs to be accessed, the capability of the new device may be analyzed and divided, and it may be determined whether an existing capability program meets the device access requirement.

If yes, judging whether the capabilities are completely matched; if the matching is complete, combining the required capability programs to obtain a capability program set, adding corresponding driver module description information, and combining to form a new driver module; if not, modifying based on the existing ability program, or expanding the new ability program, combining the needed ability programs to obtain an ability program set, adding the corresponding drive module description information, and combining to form a new drive module.

If not, a new capability program is developed, the required capability program obtains a capability program set, description information of the corresponding drive module is added, and a new drive module is combined, wherein a schematic diagram of the new drive module can be shown in fig. 7E.

In this embodiment, the video alarm host is analyzed according to the above process, the capabilities are divided into a basic video monitoring capability, a general parameter configuration capability, and an alarm host capability, capability programs corresponding to these capabilities all exist and are completely matched with each other, so that a description file is added to work required, and the capability programs required for combination are changed into a new driving module and put into the device access component, so that the access of the video alarm host device can be completed.

For the intelligent equipment with enhanced intelligent event capability, the capability is divided into basic video monitoring capability, general parameter configuration capability and intelligent event capability according to the process analysis, but the intelligent event capability is not completely matched, so that the intelligent event capability program is modified to generate a new intelligent event capability program or expand the new intelligent event capability program, the three capability programs are combined, the description file is added to form a new driving unit, and the new driving unit is placed into the equipment access assembly, so that the access of the intelligent equipment is completed.

It should be noted that, in this embodiment, an existing capability program may be binary-multiplexed, so that the original stability of the capability program can be maintained while the development efficiency is improved.

In the embodiment of the application, equipment access components comprising a service module and a drive module are deployed in a security management platform, different drive modules are respectively set for different types of equipment for equipment access, the drive modules perform equipment access through drive instances, when the number of the equipment accessed by the created drive instances in the drive modules reaches the preset maximum number of single-instance supporting equipment, the service module creates a new drive instance in the drive modules for equipment access, and the service module and the drive modules correspond to different processes which are independent of each other, so that the equipment access stability is improved; in addition, the service module can realize equipment access by newly building a drive instance, so that the equipment access capability of the single equipment access assembly is improved.

It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims

1. The equipment access assembly is characterized by comprising a service module and a drive module, wherein the service module and the drive module correspond to different processes, and the processes are independent; wherein:

the driving module is used for accessing equipment through a driving example; the different types of equipment correspond to different driving modules, and driving examples are mutually independent;

2. The device access component of claim 1, wherein the driver module comprises a driver and driver module description information;

3. The device access component of claim 2, wherein the service module comprises: the device comprises a protocol agent unit, a device resource management unit and a drive management unit; wherein:

4. The device access component of claim 3,

the protocol agent unit is further configured to send the driver module management request to the driver management unit when the access request is a driver module management request;

wherein the managing the managed driver module may include one or more of:

5. The device access component of claim 3,

the protocol agent unit is further configured to send the device access request to the drive management unit when the access request is a device access request;

6. The device access component of claim 3,

the protocol agent unit is further configured to send the device resource deletion request to the device resource management unit when the access request is a device resource deletion request;

7. The device access component of claim 1, wherein the driver module comprises a capability set and driver module description information;

8. The device access component of claim 7,

the service module is specifically used for receiving the access request and identifying the type of the access request;

9. The device access component of claim 7,

the service module is further specifically configured to, when the access request is an equipment capability calling request, query, according to an equipment resource number carried in the equipment capability calling request, a correspondence between the equipment resource number and a drive identifier and a drive version of a drive module, so as to determine a drive identifier and a drive version of a third target drive module that are matched with each other;

10. A device access control method applied to the device access component of any one of claims 1 to 9, the method comprising:

the service module receives an access request;

when the matching is successful but the matched target drive module does not have a drive instance which does not reach the maximum number of the preset single instance supported equipment, the service module creates a new drive instance in the target drive module and issues equipment resources to the created drive instance so that the created drive instance performs equipment access processing according to the equipment resources; wherein, the driving examples are independent from each other.