Virtual device management platform and bee colony control system thereof

Abstract

The invention relates to a virtual device management platform and a bee colony control system thereof, the virtual device management platform comprises a three-layer structure of an application layer, a system layer and a device layer, the performance functions of the application layer comprise a device registration function, a management function family of driving programs of different interface devices, and a registration and modification function of a device control strategy. The system layer comprises a driver manager and an interface driver set and is transparent to users; the equipment layer comprises a plurality of hardware interfaces; through the performance function provided by the application layer, a user applies for creating a drive program of a hardware interface shown by the equipment layer to the system layer, and the system layer creates an interface drive according to an interface type and creates a virtual equipment drive program for equipment physically connected to a corresponding interface according to an equipment ID provided when the performance function of the application layer is called. The supportable control system is not limited by the scale, and the universality is high; and the design and manufacturing cost is greatly reduced.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a virtual device management platform and a bee colony control system thereof. Background Art

[0002] At present, with the rapid development of technologies such as big data, the Internet of Things, and artificial intelligence, the breadth and depth of industrial control needs have been expanded. The actual control requirements of high intelligence, automation, and precision require more technical elements with high flexibility and strong compatibility to participate in project development. At present, the hardware systems of most enterprises in my country use programmable logic controllers (PLCs) as the core controller for industrial control tasks. However, due to the technical barriers and high prices of programmable logic controllers, it is difficult to quickly and effectively integrate with the latest technological achievements in the implementation of high-performance control project development, which increases the difficulty, cycle, and cost of project development to a certain extent. Therefore, this field urgently needs an industrial control system to replace the field control system with PLC as the core controller. Summary of the invention

[0003] The purpose of the present invention is to overcome the above-mentioned shortcomings and provide a virtual device management platform and its swarm control system, which allow users to freely select peripheral drivers and execution modules in the control system, thereby providing great flexibility for the design of the control system.

[0004] The object of the present invention is achieved in that:

[0005] A virtual device management platform, wherein the virtual device is a physical device and control node abstracted by the system, and the virtual device management platform includes a three-layer structure of an application layer, a system layer and a device layer. The function functions included in the application layer include a device registration function and a management function family of drivers of different interface devices, and a registration and modification function of a device control strategy. The system layer includes a driver manager and an interface driver set, which are transparent to users. The device layer includes a variety of hardware interfaces. Through the function functions provided by the application layer, the user applies to the system layer to create a driver for the hardware interface shown in the device layer. The system layer creates an interface driver according to the interface type, and creates a virtual device driver for the device physically connected to the corresponding interface according to the device ID provided when calling the application layer function function.

[0006] The interface driver of the system layer is created by the driver manager according to the application layer parameters. The interface driver set is a series of driver programs with different interface attributes created according to the registration information of the application layer. The virtual device issues a control request, and its corresponding interface driver listens to the demand signal of the virtual device and organizes it into a message element and sends it to the system scheduler. The system scheduler searches for the target driver and the target virtual device in the interface driver set according to the command code in the message element.

[0007] Furthermore, when a hardware device is added to the control system, the device is registered with the virtual management platform through the create_dev function. The prototype of the create_dev function is as follows:

[0008] sys_err create_dev(uint devId,uint drvId,uint dType,

[0009] ,

[0010] ;

[0011] The parameter devId is the device identifier set for the device, drvId is the driver identifier, indicating that the device is inserted into the specified driver chain, dType indicates the device type, SDEV_CMD_ITEM sets the command code and command execution strategy for the device, and initFunc provides further initialization functions for device creation.

[0012] Furthermore, the interface driver of the system layer is created by the driver manager according to the application layer parameters, and mainly completes the following contents:

[0013] a. Identify the driver interface type based on dType;

[0014] b. Create the resources required for driver operation and the synchronization mechanism related to resource sharing according to the driver type;

[0015] Multiple hardware devices of the same type are connected to a control interface. The driver provides a coordination and synchronization mechanism for device link anchor points and device sharing interfaces, so as to manage and operate multiple devices controlled by this interface driver.

[0016] c. Create an interface driver message element transceiver unit; the structure containing the control command code and control parameters is the message element, and the driver that generates the message element due to satisfying the control conditions or receiving the control event is the main control driver;

[0017] The interface driver is not allowed to autonomously control a device in its device chain to be put into operation. Instead, it needs to complete the corresponding control task according to the control command and control parameter instructions when a certain control condition is met or a control event is received.

[0018] Furthermore, the interface driver creation and management method of the interface driver set includes the following contents:

[0019] a. When the create_dev function is executed, the head node of type IType in the virtual device management platform is linked to the interface driver drvX. The device devM on the device anchor drv_dev_list, , its pCmd_set member points to the command set that the device can handle, command code drvX_devM_cmdY, The corresponding command strategy is func_devM_cmdY; the command field table drvX_cmd_field is linked to the drvCmdList anchor point of the head node through the member cmdList.

[0020] The above elements are initialized during the creation of the virtual management platform and are static elements of the virtual management platform.

[0021] b. When the master driver pActiveDrvM initiates a control request with the master command code drvX_devK_cmdM due to an external control request, the scheduler searches the head node command domain table of all registered interfaces according to drvX_devK_cmdM;

[0022] If drvX_devK_cmdM is satisfied , the target driver is determined to be drvX. After the target driver is determined, the scheduler will dynamically generate a message receipt for the request and link the message receipt to the corresponding anchor point of the head node unit where drvX is located.

[0023] Furthermore, the following fields in the receipt: the command code w_drvM_devX_cmdY that the master driver expects the target driver to respond to, the current master driver pointer, and the amount of data that the master expects the target driver to respond to are filled in by the scheduler; the target driver searches for the target driver on its device chain according to the master command code, and then executes the command strategy. After the target device meets the conditions specified in the command strategy, it submits the response information to the target driver. The target driver finds the message receipt linked to the head node unit where it is located, organizes the response message element according to the relevant information in the message receipt, and sends it back to the master driver.

[0024] Furthermore, the software system that can control the operation of modular sub-task hardware after tailoring is defined as a control node. As a virtual device, the control node has its own command set and is connected to the system hardware layer of the virtual device management platform, and is managed and controlled by the virtual device management platform of other control nodes. A control node can manage other control nodes, and the mutual management and control function between control nodes is realized through message elements.

[0025] Furthermore, the message element includes an internal message element and an external message element. The internal message element is located inside the control node, and the external message element exists between the control nodes and is used to transmit messages between different control nodes. The transceiver interface driver of the control node is responsible for converting the internal and external message elements.

[0026] Both the internal message element and the external message element include the following five types: M_READ message element, M_WRITE message element, RES_RED message element, RES_WRITE message element and RES_NO message element.

[0027] Furthermore, the life process of the M_READ type message element between two control nodes (X, K), activeDevn is the device on the master driver NXActiveDrv device chain of the control node X. When a read event t is listened to by NXActiveDrv, NXActiveDrv organizes the M_READ type message element to be sent to the scheduler NXDispatch. After the M_READ type message element arrives at the scheduler, it is dequeued and reassembled. Some fields are used to generate a message receipt and link it to the driver head node unit where the target driver is located, and some fields are reassembled into the M_READ type message element from the scheduler to the target driver.

[0028] Furthermore, the target driver NXDstDrv searches for the target device on its own device chain according to the command code in the message element, and calls the command strategy corresponding to the command code to perform specific operations on the target device; if the target device corresponds to a physical device, the target driver combines the monitored device response with part of the content in the message receipt linked to the head node unit, organizes it into a RES_READ type message element, and sends it to NXActiveDrv. NXActiveDrv will call the command strategy of activeDevn to execute the read response and complete the entire control process.

[0029] A bee colony control system, based on the above virtual device management platform, includes a hardware part and a software part. The hardware part uses an industrial single-chip microcomputer as a core control unit to form a relatively independent control node in the bee colony control system, and is interconnected with HMI, sensors, electromechanical drive mechanisms and other control nodes through an industrial bus to form a fully functional hardware control network structure; the software part is based on an embedded operating system, and constructs a virtual device management platform with a message element drive as the main mechanism as the core component unit of the bee colony control system;

[0030] The user registers the equipment and equipment control strategy to the swarm control system based on the hardware equipment actually required for the task, and the virtual management platform takes over to form specific message elements and message element propagation paths; the message element consists of two parts: the message code and the message parameters. The message code indicates the control content, and the message parameters indicate the control effect; the virtual management platform maintains the entire life cycle of the message element from its generation to its final absorption by the target device. The growth process of the message element is its flow process in the virtual management platform.

[0031] Compared with the prior art, the present invention has the following beneficial effects:

[0032] The present invention provides a virtual device management platform and a swarm control system thereof, which allows the user to combine the hardware characteristics in the control task and build an effective software control system in a simple and convenient way. The swarm control system of the present invention has a core hardware based on the arm series controller, which allows the user to freely select the peripheral drive and execution module in the control system, providing great flexibility for the design of the control system.

[0033] The control system supported by the present invention is not limited by scale and has strong versatility. Compared with the control system of the same scale realized by using the traditional PLC as the core controller, the present invention can greatly reduce the design and manufacturing costs, is beneficial to the project development process and promotes the rapid and effective integration with the latest technological achievements, which is beneficial to accelerate the vigorous development of my country's industrial control field. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 It is a schematic diagram of the interface structure of the virtual device management platform of the present invention.

[0035] Figure 2 This is an organizational chart of the interface driver set of the virtual device management platform of the present invention.

[0036] Figure 3 A schematic diagram of an associated network of control nodes of a virtual device management platform of the present invention.

[0037] Figure 4 The present invention is a schematic diagram of the process of processing and circulating the read message element of the virtual device management platform within the system. DETAILED DESCRIPTION

[0038] In order to better understand the technical solution of the present invention, the following will be described in detail in conjunction with the relevant illustrations. It should be understood that the following specific embodiments are not intended to limit the specific implementation of the technical solution of the present invention, and are only implementations that can be adopted by the technical solution of the present invention. It should be noted that the description of the positional relationship of each component in this article, such as component A being located above component B, is based on the description of the relative positions of the components in the illustration, and is not intended to limit the actual positional relationship of the components.

[0039] Embodiment 1:

[0040] See also Figure 1-Figure 4 , Figure 1 As shown in the figure, the virtual device management platform involved in this embodiment includes a three-layer structure of application layer, system layer and device layer, and is constructed based on the commonly used interfaces of current industrial control equipment.

[0041] 1. Application layer

[0042] The application layer includes functions such as device registration function, management function family of drivers of different interface devices, registration and modification functions of device control strategies, which are convenient for users to design and implement control objectives according to device characteristics and control requirements when building control systems, such as create_dev function and delete_dev function;

[0043] When adding a hardware device to the control system, you need to register the device with the virtual management platform through the create_dev function. The prototype of the create_dev function is as follows:

[0044] sys_err create_dev(uint devId,uint drvId,uint dType,

[0045] ,

[0046] ;

[0047] The parameter devId is the device identifier set for the device, drvId is the driver identifier, indicating that the device is inserted into the specified driver chain, dType indicates the device type, SDEV_CMD_ITEM sets the command code and command execution strategy for the device, and initFunc provides further initialization functions for device creation.

[0048] 2. System layer

[0049] The system layer includes a driver manager and an interface driver set, which is transparent to the user;

[0050] 2.1. The interface driver of the system layer is created by the driver manager according to the application layer parameters, and mainly completes the following contents:

[0051] 2.11. Identify the driver interface type according to dType;

[0052] dType is an 8-bit driver type identifier. Its structure and meaning of each segment are shown in Table 1 below:

[0053]

[0054] In Table 1 above, the control mode mainly refers to communication control and IO control, and the working mode depends on the control mode. If the control mode is communication control, the working modes are master-slave and multi-master; if the control mode is IO control, the working modes are digital control and analog control; similarly, the interface types are nested layer by layer, dynamically depending on the control mode and working mode. The management platform of this embodiment supports 12 types of interfaces, including 485, spi, iic, rj45, pwm, etc.

[0055] The protocol type indicates the control protocol used under a specific interface type, such as modbus-rtu or modbus-ascii for 485 interface, mqtt or http for wireless communication interface, etc. You can also customize the protocol;

[0056] The role identifier refers to the control identity under a specific protocol, such as the client or server under the http protocol. The driver manager provides a family of driver interface type identification and setting functions.

[0057] 2.12. Create the resources required for driver operation and the synchronization mechanism related to resource sharing according to the driver type;

[0058] Multiple hardware devices of the same type are connected to a control interface. The driver provides a coordination and synchronization mechanism for device link anchor points and device sharing interfaces to manage and operate multiple devices controlled by this interface driver.

[0059] 2.13. Create an interface-driven message element transceiver unit;

[0060] The interface driver is not allowed to autonomously control a device on its device chain to be put into operation, but needs to complete the corresponding control task according to the control command and control parameter instructions when a certain control condition is met or a control event is received; in this embodiment, the structure containing the control command code and control parameters is defined as a message element, and the driver that generates the message element due to meeting the control condition or receiving the control event is defined as the main control driver.

[0061] 2.2 Interface driver set

[0062] The interface driver set is a series of driver programs with different interface attributes created by the virtual device management platform of this embodiment according to the registration information of the application layer. The unified creation and management method of the interface driver is shown in Figure 2 ,in:

[0063] 2.21. The part outside the dotted box indicates the organization and association between the head node of type IType, the interface driver and its controlled device in the virtual device management platform after the create_dev function is executed;

[0064] Link to the interface driver drvX, The device devM on the device anchor drv_dev_list, , its pCmd_set member points to the command set that the device can handle, command code drvX_devM_cmdY, The corresponding command strategy is func_devM_cmdY; the command field table drvX_cmd_field is linked to the drvCmdList anchor point of the head node through the member cmdList, and its members drvX_min_cmd and drvX_max_cmd satisfy the following formula:

[0065]

[0066] The above elements are initialized during the creation of the virtual management platform and are static elements of the virtual management platform.

[0067] 2.22. The part in the dotted box indicates that when the master driver pActiveDrvM initiates a control request with the master command code drvX_devK_cmdM due to an external control request, the scheduler searches the head node command domain table of all registered interfaces according to drvX_devK_cmdM;

[0068] If drvX_devK_cmdM is satisfied , then the target driver is determined to be drvX. After determining the target driver, the scheduler will dynamically generate a message receipt for the request and link the message receipt to the corresponding anchor point of the head node unit where drvX is located; some fields in the receipt, such as the command code w_drvM_devX_cmdY that the master driver expects the target driver to respond to, the current master driver pointer, the amount of data that the master expects the target driver to respond to, and other information, are filled in by the scheduler; the target driver searches for the target driver on its device chain according to the master command code, and then executes the command strategy. After the target device meets the conditions specified by the command strategy, it will submit the response information to the target driver. The target driver finds the message receipt linked to the head node unit where it is located, organizes the response message element according to the relevant information in the message receipt, and sends it back to the master driver.

[0069] 2.3. The organization and forwarding framework of the message element of this virtual device management platform;

[0070] In this embodiment, the software system that can control the operation of modular industrial control subtask hardware after being tailored is defined as a control node. The control node can be used as a virtual device, has its own command set, and is connected to the system hardware layer of the virtual device management platform, and is managed and controlled by the virtual device management platform of other control nodes;

[0071] A control node can also control other control nodes. The mutual control function between control nodes is also realized through message elements. The industrial control system network composed of multiple control nodes can be seen in Figure 3 ,in:

[0072] Control node X, The control topology communicated through message elements, interface driver m, Device k on It may correspond to physical hardware or other control nodes;

[0073] In this embodiment, the physical devices and control nodes abstracted by the system are referred to as virtual devices. Generally, the control requirements of the industrial control system originate from a virtual device. The corresponding interface driver monitors the demand signals of these virtual devices and organizes them into message elements and sends them to the system scheduler. The system scheduler searches for the target driver and the target virtual device in the interface driver set according to the command code in the message element.

[0074] Message elements are divided into two categories according to their environment: internal message elements, which are located inside the control node, and external message elements, which exist between control nodes. The two types of message elements have different structures. External message elements are used to transmit messages between different control nodes. The control node's transceiver interface driver is responsible for converting internal and external message elements.

[0075] There are five types of internal and external message elements, namely M_READ, M_WRITE, RES_RED, RES_WRITE and RES_NO, see Table 2 below:

[0076] Message element type Function illustrate M_READ Active Reading Initiated by the master driver, requesting data from the target driver M_WRITE Active writing Initiated by the master driver, write data to the target driver RES_READ Read Response Target driver's read response to the master driver RES_WRITE Write Response Target driver writes response to master driver RES_NO No response required Initiated by the master driver to indicate to the target driver not to respond

[0077] Table 2 Message element types and descriptions

[0078] The five types of message elements given in Table 2 above have different specific contents and organizational structures due to their differences in functions and propagation directions. Message elements have four stages in the system: generation, development, propagation, and recycling, which are called the life cycle of message elements.

[0079] 2.4. Read the message element and process it in the system;

[0080] See also Figure 4 , Figure 4 The figure is a schematic diagram of the processing and turnover process of the read message element in the system. As shown in the figure, the survival process of the M_READ type message element between two control nodes (X, K), activeDevn is the device on the device chain of the master driver NXActiveDrv of the control node X, when a read event t is monitored by NXActiveDrv, NXActiveDrv organizes the active read message element to be sent to the scheduler NXDispatch, after the active read message element arrives at the scheduler, it is dequeued and reassembled, some fields are used to generate a message receipt and link to the driver head node unit where the target driver is located, and some fields are reassembled into the active read message element from the scheduler to the target driver.

[0081] The target driver NXDstDrv searches for the target device on its own device chain according to the command code in the message element, and calls the command strategy corresponding to the command code to perform specific operations on the target device. If the target device corresponds to a physical device, the target driver combines the monitored device response with part of the content in the message receipt linked to the head node unit, organizes it into a RES_READ type message element, and sends it to NXActiveDrv. NXActiveDrv will call the command strategy of activeDevn to execute the read response and complete the entire control process.

[0082] 3. The device layer includes 485 interface, CAN interface, digital interface, analog interface, UART interface and IIC interface, etc. Through the function functions provided by the application layer, the user can apply to the system layer to create a hardware interface driver as shown in the device layer. The system layer creates an interface driver according to the interface type, and creates a virtual device driver for the device physically connected to the corresponding interface according to the device ID provided when calling the application layer function function.

[0083] The embodiment involves a swarm control system, which takes the above-mentioned virtual device management platform as the core component unit. The hardware part uses the industrial single-chip computer as the core control unit to form a relatively independent control node in the swarm control system. It is interconnected with HMI, sensors, electromechanical drive mechanisms and other control nodes (bees) through common industrial buses such as 485, CAN, and NET to form a fully functional hardware control network structure. The software part is based on a general embedded operating system, and a virtual interface and device management platform (i.e., virtual device management platform) driven by message elements as the main mechanism is constructed as the core component unit of the swarm control system. Users can register devices and device control strategies to the swarm control system according to the hardware devices actually required for the task, and the virtual management platform will take over to form specific message elements and message element propagation paths; the message element includes two parts: a message code and a message parameter. The message code indicates the control content, and the message parameter indicates the control effect; the virtual management platform maintains the entire life cycle of the message element from its generation to its final absorption by the target device. The growth process of the message element is actually its flow process in the virtual management platform.

[0084] The virtual device management platform and its swarm control system provided in this embodiment avoid the problems of high manufacturing cost and difficulty in subsequent product upgrades caused by the use of traditional PLC controllers, and can be widely used in industrial water treatment systems in industries such as textiles, steel product processing, power transmission and distribution, and microelectronics, as well as in personalized, large-scale control systems such as thermometer marking and sorting devices based on machine vision, piano axle bending robots, and refractory brick distribution production lines.

[0085] The above are only specific application examples of the present invention and do not constitute any limitation on the protection scope of the present invention. Any technical solution formed by equivalent transformation or equivalent replacement shall fall within the protection scope of the present invention.

Claims

1. A virtual device management platform, where virtual devices are physical devices and control nodes abstracted by the system, characterized by: It includes three layers of structure: application layer, system layer and device layer. The application layer includes the function functions of device registration function and management function family of drivers of different interface devices, registration and modification function of device control strategy. The system layer includes driver manager and interface driver set, which are transparent to users. The device layer includes multiple hardware interfaces. Through the function functions provided by the application layer, the user applies to the system layer to create a driver for the hardware interface shown in the device layer. The system layer creates an interface driver according to the interface type, and creates a virtual device driver for the device physically connected to the corresponding interface according to the device ID provided when calling the application layer function function; The interface driver of the system layer is created by the driver manager according to the application layer parameters. The interface driver set is a series of driver programs with different interface attributes created according to the registration information of the application layer. The virtual device issues a control request, and its corresponding interface driver listens to the demand signal of the virtual device and organizes it into a message element and sends it to the system scheduler. The system scheduler searches for the target driver and the target virtual device in the interface driver set according to the command code in the message element.

2. A virtual device management platform according to claim 1, characterized in that: When adding a hardware device to the control system, register the device with the virtual management platform through the create_dev function. The prototype of the create_dev function is as follows: sys_err create_dev(uint devId,uint drvId,uint dType, ， ； The parameter devId is the device identifier set for the device, drvId is the driver identifier, indicating that the device is inserted into the specified driver chain, dType indicates the device type, SDEV_CMD_ITEM sets the command code and command execution strategy for the device, and initFunc provides further initialization functions for device creation.

3. A virtual device management platform according to claim 1, characterized in that: The interface driver of the system layer is created by the driver manager according to the application layer parameters, and mainly completes the following contents: a. Identify the driver interface type based on dType; b. Create the resources required for driver operation and the synchronization mechanism related to resource sharing according to the driver type; Multiple hardware devices of the same type are connected to a control interface. The driver provides a coordination and synchronization mechanism for device link anchor points and device sharing interfaces, so as to manage and operate multiple devices controlled by this interface driver. c. Create an interface driver message element transceiver unit; the structure containing the control command code and control parameters is the message element, and the driver that generates the message element due to satisfying the control conditions or receiving the control event is the main control driver; The interface driver is not allowed to autonomously control a device in its device chain to be put into operation. Instead, it needs to complete the corresponding control task according to the control command and control parameter instructions when a certain control condition is met or a control event is received.

4. A virtual device management platform according to claim 1, characterized in that: The interface driver creation and management methods of the interface driver set include the following: a. When the create_dev function is executed, the head node of type IType in the virtual device management platform is linked to the interface driver drvX. The device devM on the device anchor drv_dev_list, , its pCmd_set member points to the command set that the device can handle, command code drvX_devM_cmdY, The corresponding command strategy is func_devM_cmdY; the command field table drvX_cmd_field is linked to the drvCmdList anchor point of the head node through the member cmdList. The above elements are initialized during the creation of the virtual management platform and are static elements of the virtual management platform; b. When the master driver pActiveDrvM initiates a control request with the master command code drvX_devK_cmdM due to an external control request, the scheduler searches the head node command domain table of all registered interfaces according to drvX_devK_cmdM; If drvX_devK_cmdM is satisfied , the target driver is determined to be drvX. After determining the target driver, the scheduler will dynamically generate a message receipt for the request and link the message receipt to the corresponding anchor point of the head node unit where drvX is located.

5. A virtual device management platform according to claim 4, characterized in that: The following fields in the receipt: the command code w_drvM_devX_cmdY that the master driver expects the target driver to respond to, the current master driver pointer, and the amount of data that the master expects the target driver to respond to are filled in by the scheduler; the target driver searches for the target driver on its device chain according to the master command code, and then executes the command strategy. After the target device meets the conditions specified in the command strategy, it submits the response information to the target driver. The target driver finds the message receipt linked to the head node unit where it is located, organizes the response message element according to the relevant information in the message receipt, and sends it back to the master driver.

6. A virtual device management platform according to claim 1, characterized in that: The software system that can control the operation of modular subtask hardware after cutting is defined as a control node. As a virtual device, the control node has its own command set and is connected to the system hardware layer of the virtual device management platform. It is managed and controlled by the virtual device management platform of other control nodes. A control node can control other control nodes, and the mutual control function between control nodes is realized through message elements.

7. A virtual device management platform according to claim 1, characterized in that: Message elements include internal message elements and external message elements. Internal message elements are located inside the control node, and external message elements exist between control nodes and are used to transmit messages between different control nodes. The transceiver interface driver of the control node is responsible for converting internal and external message elements. Both the internal message element and the external message element include the following five types: M_READ message element, M_WRITE message element, RES_RED message element, RES_WRITE message element and RES_NO message element.

8. A virtual device management platform according to claim 7, characterized in that: The life process of M_READ type message element between two control nodes (X, K). activeDevn is the device on the master driver NXActiveDrv device chain of control node X. When a read event t is monitored by NXActiveDrv, NXActiveDrv organizes M_READ type message elements to be sent to the scheduler NXDispatch. After the M_READ type message element arrives at the scheduler, it is dequeued and reassembled. Some fields are used to generate a message receipt and link it to the driver head node unit where the target driver is located. Some fields are reassembled into M_READ type message elements from the scheduler to the target driver.

9. A virtual device management platform according to claim 8, characterized in that: The target driver NXDstDrv searches for the target device on its own device chain according to the command code in the message element, and calls the command strategy corresponding to the command code to perform specific operations on the target device; if the target device corresponds to a physical device, the target driver combines the monitored device response with part of the content in the message receipt linked to the head node unit, organizes it into a RES_READ type message element, and sends it to NXActiveDrv. NXActiveDrv will call the command strategy of activeDevn to execute the read response and complete the entire control process.

10. A swarm control system, based on a virtual device management platform according to claim 1, characterized in that: It includes hardware and software. The hardware part uses industrial single-chip microcomputer as the core control unit to form a relatively independent control node in the swarm control system. It is interconnected with HMI, sensors, electromechanical drive mechanisms and other control nodes through industrial buses to form a fully functional hardware control network structure. The software part is based on an embedded operating system and builds a virtual device management platform with message element drive as the main mechanism as the core component of the swarm control system. The user registers the equipment and equipment control strategy to the swarm control system based on the hardware equipment actually required for the task, and the virtual management platform takes over to form specific message elements and message element propagation paths; the message element consists of two parts: the message code and the message parameters. The message code indicates the control content, and the message parameters indicate the control effect; the virtual management platform maintains the entire life cycle of the message element from its generation to its final absorption by the target device. The growth process of the message element is its flow process in the virtual management platform.

Images