Building automatic control system, method and equipment based on hardware interface virtual mapping

Abstract

The invention relates to a building automatic control system, method and equipment based on hardware interface virtual mapping. The system comprises field equipment, a field data acquisition module and a cloud server, wherein a virtual controller runs in the cloud server; the cloud server is used for virtualizing a hardware interface of the field data acquisition module to obtain a virtual hardware interface, and creating the virtual controller matched with the virtual hardware interface; the field data acquisition module is used for acquiring equipment data of the field equipment and reporting the equipment data to the cloud server; and the cloud server is also used for scheduling the virtual controller to carry out data processing based on the received equipment data to obtain a data processing result, and feeding back the data processing result to the field equipment through the virtual hardware interface. According to the invention, the problems of high hardware cost and limited data interaction of the building automatic control system in the prior art can be solved.

Description

Technical Field

[0001] The present invention relates to the technical field of smart buildings, and in particular to a building automatic control system, method and equipment based on hardware interface virtual mapping. Background Art

[0002] At present, with the development of cloud computing, edge computing and artificial intelligence technologies, building automation systems are moving towards integration, intelligence and greening, with low-cost construction, high-efficiency operation and sustainable operation becoming the core goals.

[0003] However, the traditional building automation system is based on independent data acquisition units, which requires the construction of multiple independent data acquisition units, resulting in high hardware costs. In addition, the independent data acquisition units are not interoperable, resulting in limited data interaction. Summary of the invention

[0004] In view of this, an object of the present invention is to provide a building automation system, method and device based on hardware interface virtual mapping to solve the problems of high hardware cost and limited data interaction of building automation systems in the prior art.

[0005] According to a first aspect of an embodiment of the present invention, there is provided a building automation system based on hardware interface virtual mapping, comprising: a field device, a field data acquisition module, and a cloud server; wherein a virtual controller runs in the cloud server;

[0006] The cloud server is used to virtualize the hardware interface of the field data acquisition module to obtain a virtual hardware interface, and create the virtual controller matching the virtual hardware interface;

[0007] The field data acquisition module is used to collect device data of the field devices and report the device data to the cloud server;

[0008] The cloud server is also used to schedule the virtual controller to perform data processing based on the received device data, obtain data processing results, and feed back the data processing results to the field device through the virtual hardware interface.

[0009] According to a second aspect of an embodiment of the present invention, a smart building control method based on hardware interface virtual mapping is provided, which is applied to a cloud server in a building automatic control system based on hardware interface virtual mapping as described in the first aspect of the embodiment of the present invention, wherein a virtual controller runs in the cloud server, and the method comprises:

[0010] Virtualizing the hardware interface of the field data acquisition module to obtain a virtual hardware interface, and creating the virtual controller matching the virtual hardware interface;

[0011] Receiving equipment data of the field equipment reported by the field data acquisition module;

[0012] Based on the received device data, the virtual controller is scheduled to perform data processing to obtain a data processing result, and the data processing result is fed back to the field device through the virtual hardware interface.

[0013] According to a third aspect of an embodiment of the present invention, an electronic device is provided for providing cloud computing services for the building automation system based on hardware interface virtual mapping described in the first aspect of the embodiment of the present invention.

[0014] The technical solution provided by the embodiments of the present invention may have the following beneficial effects:

[0015] A new building automation system architecture is formed by field equipment, field data acquisition modules and cloud servers. Virtual controllers are deployed in cloud servers, which can schedule virtual controllers in the cloud to process data from field equipment and interact with field equipment. Compared with the traditional method, which requires the setting of physical hardware controllers to process and control the data collected by the field data acquisition module, this solution deploys virtual controllers in the cloud and uniformly schedules data processing and control, which saves hardware costs and can realize data intercommunication between various field data acquisition modules and various virtual controllers, further improving the intelligence of building automation.

[0016] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0018] Figure 1 is a schematic architecture diagram of a building automation system according to an exemplary embodiment;

[0019] Figure 2 is a schematic diagram of a communication process between a field device and a field data acquisition device according to an exemplary embodiment;

[0020] Figure 3 is a schematic diagram of a communication process between a field data acquisition device and Ethernet according to an exemplary embodiment;

[0021] Figure 4 is a schematic diagram of a multi-controller logic scheduler workflow according to an exemplary embodiment;

[0022] Figure 5 is a schematic diagram of a virtual control logic execution flow according to an exemplary embodiment;

[0023] Figure 6 is another schematic diagram of a virtual control logic execution flow according to an exemplary embodiment;

[0024] Figure 7 It is a flow chart of a building automatic control method based on hardware interface virtual mapping according to an exemplary embodiment;

[0025] Figure 8 The diagram is a schematic diagram showing an internal control circuit of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION

[0026] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same 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 invention. Instead, they are merely examples of devices and methods consistent with some aspects of the present invention as detailed in the appended claims.

[0027] Figure 1 A building automation system based on hardware interface virtual mapping according to an exemplary embodiment includes: field equipment, a field data acquisition module, and a cloud server; wherein a virtual controller runs in the cloud server;

[0028] The cloud server is used to virtualize the hardware interface of the field data acquisition module to obtain a virtual hardware interface, and create the virtual controller matching the virtual hardware interface;

[0029] The field data acquisition module is used to collect device data of the field devices and report the device data to the cloud server;

[0030] The cloud server is also used to schedule the virtual controller to perform data processing based on the received device data, obtain data processing results, and feed back the data processing results to the field device through the virtual hardware interface.

[0031] Among them, field equipment refers to electromechanical equipment with communication interfaces, including digital or analog I / O, RS-485, CAN bus, etc. Electromechanical equipment includes intelligent sensors, variable frequency air conditioners, fan coil units and central air conditioning systems.

[0032] Among them, the field data acquisition module is a data acquisition device with I / O, RS-485, CAN and other communication capabilities. It can centrally collect and process the status data of a single field device or multiple field devices. It also has an Ethernet communication interface, which can upload the collected data to a remote server (cloud server) in the form of http or mqtt protocol.

[0033] Among them, deploying virtual controllers in the cloud server can schedule each virtual controller to perform control processing tasks through virtual controller logic control. Among them, traditional PLC (Programmable Logic Controller), DDC (Direct Digital Control) and other field controllers can be simulated through software technology to obtain various virtual controllers. Each virtual controller includes I / O, RS-485, CAN and other hardware interface virtualization modules and independent control logic operating environment. The control logic operating environments of different virtual controllers are independent of each other, and virtual controllers can exchange data through network IP and port numbers. By deploying multiple virtual controllers on the cloud server side and combining the multi-controller logic scheduler for the virtual controllers, the virtual controllers can be flexibly scheduled to perform corresponding data processing, and the device data uploaded by each field device through the field data acquisition module (such as Figure 1 The device topic message in the cloud server can realize the intelligent scheduling of data processing tasks, so that the relatively independent data processing flow in a single virtual controller can be maintained, and communication interaction between virtual controllers can be established when collaborative work is required. This architecture that deploys most of the operations on the cloud server can significantly reduce hardware costs, and the corresponding message scheduling, resource scheduling, and algorithm scheduling are performed in the cloud server to realize collaborative scheduling between virtual controllers, improve the scheduling and control flexibility of virtual controllers, and thus realize more flexible and intelligent building automation task processing.

[0034] As an optional implementation, the cloud server is specifically used to parse key data fields in the device data, and schedule the virtual controller to perform data processing based on a preset message routing table, the real-time resource information table of the virtual controller, and the real-time algorithm information table of the virtual controller; wherein the key data fields include at least the device unique identifier of the field device, the preset message routing table includes at least the mapping relationship between the device unique identifier and the virtual controller identifier, the real-time resource information table includes at least the mapping relationship between the virtual controller identifier and real-time resource usage information, and the real-time algorithm information table includes at least the mapping relationship between the virtual controller identifier and real-time running algorithm information.

[0035] In this embodiment, after receiving the device data, the cloud server can perform data analysis on the device data to obtain the key data fields therein, and perform scheduling control of the virtual controller through the multi-controller logic scheduler in combination with the key data fields. When performing scheduling control, the scheduling strategy can be determined in combination with the message routing table, the real-time resource information table of the virtual controller, and the real-time algorithm information table of the virtual controller. Since the message routing table contains the mapping relationship between the device unique identifier of the field device and the virtual controller identifier, the virtual controller identifier corresponding to the current device data can be determined based on the message routing table. The corresponding virtual controller identifier here can be a unique identifier or multiple identifiers. After that, it is further combined with the real-time resource information table of the virtual controller to determine whether the virtual controller to which the message needs to be routed has sufficient resources to process the message, and combined with the real-time algorithm information table to determine whether the message needs to be processed by a collaborative scheduling algorithm between multiple virtual controllers, and based on multi-dimensional judgment, the virtual controller to which the device data is finally routed is determined.

[0036] As an optional implementation manner, the cloud server is specifically used for:

[0037] Determining the virtual controller matching the device data through the preset message routing table;

[0038] Acquire the real-time resource table and read the real-time resource usage information of the virtual controller; wherein the real-time resource usage information at least includes resource usage rate;

[0039] If the resource usage rate is lower than a preset usage rate threshold, transmitting the device data to the virtual controller for data processing;

[0040] If the data processing category of the device data is a cross-algorithm processing category, data processing is performed in collaboration with the virtual controller based on the real-time algorithm information table.

[0041] In this embodiment, if the device data is a device topic message, the specific device topic expression form is, for example: server / id. Among them, id can be a unique number of the device in the system generated by UUID (Universally Unique Identifier), and the message body of the device topic message can be: {"uploadType":1, "data":xxx}, indicating that it is an upload data type, and the data to be uploaded is xxx. After the device data enters the cloud server, it will be parsed by the multi-controller logic scheduler in the cloud server, and the preset message routing table will be scheduled to determine the virtual controller identifier that matches the upload data type and the device unique identifier. For example, the mapping relationship between the device id, uploadType and virtual controller identifier (such as ip+port) can be recorded in the message routing table. Through the device id and uploadType contained in the current device data, the corresponding virtual controller identifier (such as ip+port) can be found in the message routing table. Afterwards, the real-time resource information table associated with the virtual controller identifier can be further retrieved to read the resource utilization rate (CPU utilization rate, memory utilization rate, and disk utilization rate of the virtual controller, etc.), and the resource utilization rate is compared with the corresponding threshold. If the resource utilization rate is lower than the preset utilization rate threshold, it means that the virtual controller has the processing capacity to process the current message, and the device data is transferred to the virtual controller for data processing. For example, when the resource utilization rate is lower than 30%, the message that is not assigned to the virtual controller in the message scheduler is assigned to the virtual controller. If the data processing category of the device data is a cross-algorithm processing category, the virtual controller corresponding to the algorithm to be called is determined based on the real-time algorithm information table, and the device data is processed using multiple algorithms based on the collaboration between virtual controllers.

[0042] As an optional implementation manner, the virtual controller has a corresponding virtual controller identifier, and the virtual controller identifier includes at least one of the following: a port number and an IP address.

[0043] As an optional implementation, the field data acquisition module is specifically used to generate a random unique number of an I / O signal as a point identifier for a field device of an I / O interface type;

[0044] For a field device of RS-485 interface type, generating the point identifier based on the device unique identifier and the randomly generated identifier of the field device;

[0045] For a field device of a CAN interface type, the point identifier is generated based on a unique device identifier and a randomly generated identifier of the field device on a CAN node;

[0046] Based on the point identifier and the interface type of the field device, a point status message is generated, and the point status message is reported to the cloud server.

[0047] In this embodiment, the I / O interface virtualization module can utilize the signal characteristics of the I / O interface and use the Docker containerization technology to realize the I / O interface virtualization in the Linux environment. By creating virtual devices and interfaces, developers can test and develop applications in an isolated environment without relying on real hardware, thereby improving development efficiency. The RS-485 interface virtualization module can utilize the data packets and signal characteristics of the RS-485 interface. Using containerization to virtualize the RS-485 interface can help developers develop and test without relying on actual hardware. Among them, RS-485 is a commonly used serial communication protocol widely used in industrial automation and data acquisition. The CAN (Controller Area Network, a communication protocol widely used in automotive and industrial automation systems) interface virtualization module can utilize the data packets and signal characteristics of the CAN interface, and virtualize the CAN interface through Docker, which can achieve rapid testing and development without relying on actual hardware.

[0048] When virtual controller A needs to request data from virtual controller B, it can connect to virtual controller B via TCP and transmit information in JSON data format. When virtual controller B receives the information, it parses the data and takes corresponding actions according to the agreed JSON format data definition.

[0049] Please also read Figure 2 , Figure 2 is a schematic diagram of a communication process between a field device and a field data acquisition device according to an exemplary embodiment. Figure 2 As shown in the figure, the current communication and interaction between field equipment and field data acquisition equipment can include I / O communication mechanism, RS-485 communication mechanism and CAN communication mechanism. Different types of communication mechanisms are connected to corresponding interface types respectively, and each interface type constructs corresponding point identification (pointId). Then, through the point list mapping storage method, the final point status message is integrated and reported to the cloud server through the Ethernet interface.

[0050] Specifically, for I / O interface type device access, when the field data acquisition device receives an I / O signal, it randomly generates a globally unique number in the system for the I / O signal as the point id. For RS-485 interface type device access, the field data acquisition device acts as a master station. When it receives the RS-485 signal from the slave device, it uses the slave device id and the randomly generated point id as the final point id. For CAN interface type device access, the field data acquisition device collects device data on other CAN nodes, and uses the node's device id and the randomly generated point id as the final point id. In addition, the field data acquisition device can also store the collected point data of I / O, RS-485, and CAN interface devices in a non-volatile memory for communication when the field data acquisition device is started.

[0051] Please also read Figure 3 , Figure 3 is a schematic diagram of a communication process between a field data acquisition device and Ethernet according to an exemplary embodiment. Figure 3 As shown in the figure, when the field data acquisition device collects the new device status, it actively sends the point status message to the MQTT server. The message subject includes the content: server / mac / io|rs485|can / pointId. In addition, the field data acquisition device can consume the downlink message published by the MQTT server according to its own mac address. The downlink consumption information subject is: client / mac / io|rs485|can / pointId.

[0052] As an optional implementation, the cloud server further includes a multi-controller logic scheduler;

[0053] The multi-controller logical scheduler is used to receive the point status message and determine the interface type that matches the point status message; schedule the target virtualization module in the virtual controller according to the interface type; wherein the target virtualization module includes at least one of the following: an I / O interface virtualization module, an RS-485 interface virtualization module, and a CAN interface virtualization module.

[0054] Among them, the multi-controller logical scheduler refers to an application running on the cloud server, which can open the network IP and application port number for remote access by the field data acquisition module. The message middleware and multi-controller logical scheduling application can be installed on the cloud server to analyze, process and distribute the network messages uploaded by the field data acquisition module.

[0055] Specifically, the multi-controller logical scheduler stores the MAC address information of the on-site data acquisition device that has published the message, and creates a virtual controller logical virtual operating environment in the virtual resource pool to match the data acquisition device. The multi-controller logical scheduler stores the corresponding information of the MAC address of the data acquisition device and the IP+port number of the virtual environment (virtual controller).

[0056] Please also read Figure 4 , Figure 4 is a schematic diagram of a multi-controller logic scheduler workflow according to an exemplary embodiment. Figure 4 As shown, the multi-controller logic scheduler can detect whether the field data acquisition module transmits a new MQTT message. If there is a new MQTT message, the mac address (device unique identifier) ​​of the field data acquisition device in the message is parsed, and it is determined whether the mac address already exists in the preset virtual mapping table (message routing table). If so, the message is forwarded to the virtual node (virtual controller) corresponding to the mac address for data processing. If the mac address does not exist in the preset virtual mapping table, a new mac mapping information is created, added to the virtual mapping table, and the virtual node (virtual controller) interface is called to synchronize the mac address to forward the message to the corresponding virtual node (virtual controller) for data processing.

[0057] As an optional implementation, the field data acquisition module is also used to receive a downlink message sent by the cloud server, and transmit the downlink message to the field device.

[0058] Please also read Figure 5 , Figure 5 is a schematic diagram of a virtual control logic execution flow according to an exemplary embodiment. Figure 5 As shown, when the MQTT message scheduling module listens to a message with a corresponding virtual logic operating environment, it automatically identifies the interface to which the message belongs according to the message subject, calls the corresponding interface virtualization module according to the corresponding interface data packet, and accesses the logic operating module to perform corresponding data processing.

[0059] Please also read Figure 6 , Figure 6 is another virtual control logic execution flow diagram according to an exemplary embodiment. Figure 6 As shown, the multi-controller logic scheduler can detect whether the field data acquisition module transmits a new MQTT message. If there is a new MQTT message, it will further determine whether it is an I / O interface message, an RS-485 interface message, or a CAN interface message, and construct a corresponding data packet, and call the corresponding virtual module to process the data packet.

[0060] A new building automation system architecture is formed by field equipment, field data acquisition modules and cloud servers. Virtual controllers are deployed in cloud servers, which can schedule virtual controllers in the cloud to process data from field equipment and interact with field equipment. Compared with the traditional method, which requires the setting of physical hardware controllers to process and control the data collected by the field data acquisition module, this solution deploys virtual controllers in the cloud and uniformly schedules data processing and control, which saves hardware costs and can realize data intercommunication between various field data acquisition modules and various virtual controllers, further improving the intelligence of building automation.

[0061] Based on the same inventive concept, Figure 7 The present invention is a flowchart of a smart building control method based on hardware interface virtual mapping. The method is applied to a cloud server in the building automatic control system based on hardware interface virtual mapping. A virtual controller is running in the cloud server, such as Figure 7 As shown, the method includes:

[0062] S71, virtualizing the hardware interface of the field data acquisition module to obtain a virtual hardware interface, and creating the virtual controller matching the virtual hardware interface;

[0063] S72, receiving the equipment data of the field equipment reported by the field data acquisition module;

[0064] S73, based on the received device data, scheduling the virtual controller to perform data processing, obtaining a data processing result, and feeding back the data processing result to the field device through the virtual hardware interface.

[0065] A new building automation system architecture is formed by field equipment, field data acquisition modules and cloud servers. Virtual controllers are deployed in cloud servers, which can schedule virtual controllers in the cloud to process data from field equipment and interact with field equipment. Compared with the traditional method, which requires the setting of physical hardware controllers to process and control the data collected by the field data acquisition module, this solution deploys virtual controllers in the cloud and uniformly schedules data processing and control, which saves hardware costs and can realize data intercommunication between various field data acquisition modules and various virtual controllers, further improving the intelligence of building automation.

[0066] Based on the same inventive concept, Figure 8 is a schematic diagram of an internal control circuit of an electronic device according to an exemplary embodiment. Figure 8 As shown, the electronic device comprises:

[0067] At least one processor 801, a communication interface 802; and

[0068] A memory 803 in communication with the at least one processor 801;

[0069] Among them, the processor 801, the communication interface 802 and the memory 803 communicate with each other through the communication bus 804; the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can provide cloud computing services for the above-mentioned building automatic control system based on hardware interface virtual mapping.

[0070] According to an exemplary embodiment, a non-transitory computer-readable storage medium storing computer instructions is shown, wherein the computer instructions are used to enable a computer to provide cloud computing services for the above-mentioned building automatic control system based on hardware interface virtual mapping.

[0071] The computer-readable storage medium disclosed in this embodiment includes, but is not limited to: electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or components, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or device.

[0072] It can be understood that the same or similar parts of the above embodiments can be referenced to each other, and the contents not described in detail in some embodiments can refer to the same or similar contents in other embodiments.

[0073] It should be noted that, in the description of the present invention, the terms "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying relative importance. In addition, in the description of the present invention, unless otherwise specified, the meaning of "plurality" refers to at least two.

[0074] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code that includes one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present invention includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present invention belong.

[0075] It should be understood that the various parts of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, a plurality of steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0076] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0077] In addition, each functional unit in each embodiment of the present invention may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0078] The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.

[0079] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0080] Although the embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and are not to be construed as limitations of the present invention. A person skilled in the art may change, modify, replace and vary the above embodiments within the scope of the present invention.

Claims

1. A building automation system based on hardware interface virtual mapping, characterized in that: include: Field equipment, field data acquisition module, and cloud server; wherein a virtual controller runs in the cloud server; The cloud server is used to virtualize the hardware interface of the field data acquisition module to obtain a virtual hardware interface, and create the virtual controller matching the virtual hardware interface; The field data acquisition module is used to collect device data of the field devices and report the device data to the cloud server; The cloud server is also used to schedule the virtual controller to perform data processing based on the received device data, obtain data processing results, and feed back the data processing results to the field device through the virtual hardware interface.

2. The system according to claim 1, characterized in that The cloud server is specifically used to parse the key data fields in the device data, and schedule the virtual controller to perform data processing based on a preset message routing table, the real-time resource information table of the virtual controller, and the real-time algorithm information table of the virtual controller; wherein the key data fields include at least the device unique identifier of the field device, the preset message routing table includes at least the mapping relationship between the device unique identifier and the virtual controller identifier, the real-time resource information table includes at least the mapping relationship between the virtual controller identifier and real-time resource usage information, and the real-time algorithm information table includes at least the mapping relationship between the virtual controller identifier and real-time running algorithm information.

3. The system according to claim 2, characterized in that The cloud server is specifically used for: Determining the virtual controller matching the device data through the preset message routing table; Acquire the real-time resource table and read the real-time resource usage information of the virtual controller; wherein the real-time resource usage information at least includes resource usage rate; If the resource usage rate is lower than a preset usage rate threshold, transmitting the device data to the virtual controller for data processing; If the data processing category of the device data is a cross-algorithm processing category, data processing is performed in collaboration with the virtual controller based on the real-time algorithm information table.

4. The system according to claim 1, characterized in that The virtual controller has a corresponding virtual controller identifier, and the virtual controller identifier includes at least one of the following: a port number and an IP address.

5. The system according to claim 1, characterized in that The field data acquisition module is specifically used to generate a random unique number of an I / O signal for a field device of an I / O interface type as a point identifier; For a field device of RS-485 interface type, generating the point identifier based on the device unique identifier and the randomly generated identifier of the field device; For a field device of a CAN interface type, the point identifier is generated based on a unique device identifier and a randomly generated identifier of the field device on a CAN node; Based on the point identifier and the interface type of the field device, a point status message is generated, and the point status message is reported to the cloud server.

6. The system according to claim 5, characterized in that The cloud server also includes a multi-controller logic scheduler; The multi-controller logical scheduler is used to receive the point status message and determine the interface type that matches the point status message; schedule the target virtualization module in the virtual controller according to the interface type; wherein the target virtualization module includes at least one of the following: an I / O interface virtualization module, an RS-485 interface virtualization module, and a CAN interface virtualization module.

7. The system according to claim 1, characterized in that The field data acquisition module is also used to receive the downlink message sent by the cloud server and transmit the downlink message to the field device.

8. A building automation method based on hardware interface virtual mapping, characterized in that: A cloud server in a building automation system based on hardware interface virtual mapping as claimed in any one of claims 1 to 7, wherein a virtual controller runs in the cloud server, and the method comprises: Virtualizing the hardware interface of the field data acquisition module to obtain a virtual hardware interface, and creating the virtual controller matching the virtual hardware interface; Receiving equipment data of the field equipment reported by the field data acquisition module; Based on the received device data, the virtual controller is scheduled to perform data processing to obtain a data processing result, and the data processing result is fed back to the field device through the virtual hardware interface.

9. The method according to claim 8, characterized in that Scheduling the virtual controller to process the data based on the received device data includes: Parsing key data fields in the device data; Based on a preset message routing table, a real-time resource information table of the virtual controller, and a real-time algorithm information table of the virtual controller, scheduling the virtual controller to perform data processing; Among them, the key data field includes at least the device unique identifier of the field device, the preset message routing table includes at least the mapping relationship between the device unique identifier and the virtual controller identifier, the real-time resource information table includes at least the mapping relationship between the virtual controller identifier and the real-time resource usage information, and the real-time algorithm information table includes at least the mapping relationship between the virtual controller identifier and the real-time running algorithm information.

10. An electronic device, characterized in that: Used to provide cloud computing services for the building automation system based on hardware interface virtual mapping as described in any one of claims 1-7.

Images