General technical architecture method and system based on building energy internet of things

Abstract

The invention discloses a general technical architecture method and system based on a building energy internet of things, and the method comprises the steps: selecting an access protocol according to the type of equipment, and enabling the basic operation related equipment of an energy system to be connected to an end side; a corresponding solution is matched according to the service function of the end side access equipment, and a communication protocol of the end side access equipment is converted into an MQTT protocol; constructing an Internet of Things data unified convergence layer, converting a communication protocol of a third-party system into an MQTT protocol, and converging data uploaded by an end side, a side side and the third-party system to the Internet of Things data unified convergence layer based on the MQTT protocol; and extracting the data converged by the Internet of Things data unified convergence layer to a data relay system for data relay through an internal data processing side of the cloud side, and storing the obtained relay data to a data storage layer through a service adaptation layer. According to the invention, the functions of wide access, simple analysis and efficient conversion of the data of the building energy scene can be realized.

Description

Technical Field

[0001] This invention relates to the field of cloud-edge data collaboration technology, specifically to a general technical architecture method and system based on the Internet of Things for building energy. Background Technology

[0002] Traditional energy management methods are simplistic, experience-based, and lack sufficient data support for operational analysis, making further automation and energy-saving optimization difficult. Based on this industry situation, major companies are actively working to achieve digital and intelligent operation of building energy systems. The primary need is to build an IoT foundation platform that supports various energy forms and IoT devices within buildings, as well as an IoT technology architecture tailored to data analysis, intelligent control, and intelligent operation requirements. Currently, IoT platform architectures are diverse, but the industry generally adopts two approaches: the first is the basic architecture implementation method, which uses a simple infrastructure to collect data and directly store it in a database, achieving rapid deployment; the second is the general IoT technology architecture method, which largely draws inspiration from the practices of major internet companies, including devices, products, product categories, and object models, while also implementing complex functionalities such as proximity access, cloud gateway capabilities, scene linkage, generalized protocols, and device authentication.

[0003] The shortcomings and deficiencies of existing technologies: While the two technical solutions mentioned above can address the access problem of IoT data in building energy scenarios to some extent, they still lead to the failure of IoT platform architecture design for building energy scenarios. The fundamental reason is: 1. Detached from business scenarios: Most designs reference general IoT platforms, resulting in a bloated overall architecture and extremely high development costs, making it difficult to truly implement them. 2. Ignoring the technical expertise: Most IoT platforms are designed by product managers who lack technical knowledge, which has significant limitations. They often fail to make good use of the characteristics of the technology for targeted design, and as business needs grow, the platform faces the embarrassing situation of being unable to meet those needs. 3. Design without a data platform: The design failed to consider the needs of intelligent building energy operation and was limited to the local needs of the Internet of Things. In the future, it will be necessary to connect to a big data platform or data middleware, which will increase the data governance costs significantly.

[0004] The above reasons ultimately result in an architecture that cannot meet business needs, directly leading to business failure, increased R&D costs, and wasted R&D resources. Summary of the Invention

[0005] In view of the above problems, the present invention provides a general technical architecture method and system based on building energy Internet of Things. While meeting the needs of continuous business expansion, it significantly reduces development costs and has extremely high scalability. It can meet the business needs of most building energy scenarios. At the same time, the architecture takes into account the needs of intelligent operation, reserves data models and interfaces, and can easily help enterprises achieve the technical capabilities of digital and intelligent operation goals.

[0006] To achieve the above objectives, the present invention provides the following technical solution: According to a first aspect of the present invention, a general technical architecture system based on the Internet of Things for Building Energy is provided, the general technical architecture system comprising: an edge side, an edge side, and a cloud side; the cloud side comprising an external data processing side and an internal data processing side; The terminal side is used to enable access to various energy system basic operation related equipment in building energy scenarios; The side converts the communication protocol of the end-side access device into the MQTT protocol, which is used to achieve standardized and unified management of the end-side access device before data aggregation; The external data processing side is used to build a unified IoT data aggregation layer before the data from the edge or device is uploaded to the cloud. The unified IoT data aggregation layer converts the communication protocols of third-party systems into the MQTT protocol. Based on the MQTT protocol specification, the data uploaded from the edge, device, and third-party systems is aggregated to the unified IoT data aggregation layer. The external data processing side is a technical architecture that connects third-party systems, IoT protocol converters, and cloud deployment. The internal data processing side is used to extract, transfer, adapt to business and store data from the data aggregated by the IoT data unified aggregation layer. The internal data processing side is a four-level data processing link architecture consisting of a high-efficiency streaming data processing middleware, a data transfer system, a business adaptation layer and a data storage layer. The technical architecture of the general technical architecture system is a three-level data system; the three-level data system includes a first data link, a second data link, and a third data link.

[0007] Furthermore, the terminal side is used to enable access to various energy system infrastructure-related equipment in building energy scenarios, including: The device type is determined on the end-side based on the device attributes of the equipment related to the basic operation of the energy system; the device type includes stand-alone networked devices, lower-level devices, upper-level devices, third-party system devices, and other customized devices; Based on the analysis of the device type, the corresponding access protocol is selected, and the energy system infrastructure-related devices are connected to the end side.

[0008] Furthermore, the edge is used to standardize and unify the management of end-side access devices before data aggregation, and to convert the communication protocol of the end-side access devices into the MQTT protocol, including: The edge-side solution is determined based on the service functions of the end-side access devices; the solution includes access schemes for hard gateways, hardware servers, and edge computing nodes. Based on the analysis of the service functions of the terminal access device, a corresponding solution is selected, and the communication protocol of the terminal access device is converted to the MQTT protocol according to the corresponding solution.

[0009] Furthermore, the high-efficiency streaming data processing middleware extracts data from MQTT through the MQTT-Kafka connection component and stores the obtained data into the data transfer system.

[0010] Furthermore, the data relay system uses Kafka as the basic technical support middleware. It uses the Kafka-Topic storage specification to relay data stored in the data relay system to obtain relayed data. The latest periodic data can also be extracted from the data relay system through the ETL service, and the periodic data can be put into a data warehouse or connected with other data forwarding sources.

[0011] Furthermore, the service adaptation layer is built using an IOT-HUB service adapter, and the relay data is adapted for service use through the service adaptation layer.

[0012] Furthermore, the data storage layer dynamically expands the service adapter to load data from multiple data sources in the relay data based on the service adaptation of the relay data.

[0013] Furthermore, the first data link is used to store real-time data, the second data link is used to store recent data, and the third data link is used to store all data.

[0014] Furthermore, the IoT data unified aggregation layer provides a data model; the data model includes an edge node model, an IoT device model, and a progressive data model; the progressive data model includes a basic data model, a standard data model, and a unified data model; The basic data model is used to parse the raw data; The standard data model introduces key attributes based on the basic data model for data protocol optimization; The unified data model incorporates business data based on the standard data for data isolation.

[0015] A second aspect of the present invention provides a general technical architecture method based on the Internet of Things for Building Energy, comprising: The device type is determined by the device attributes of the energy system infrastructure related equipment on the terminal side, and the corresponding access protocol is selected to connect the energy system infrastructure related equipment to the terminal side. By matching the corresponding solution based on the business functions of the terminal access device on the edge side, the communication protocol of the terminal access device is converted into the MQTT protocol, and the data generated by the terminal access device is uploaded to the external data processing side on the cloud side based on the MQTT protocol. Before data from the edge or terminal side is uploaded to the cloud via the external data processing side on the cloud side, an IoT data unified aggregation layer is constructed. In the IoT data unified aggregation layer, the communication protocol of the third-party system is converted into the MQTT protocol. Based on the protocol specification of the MQTT protocol, the data uploaded by the edge, terminal side and third-party system are aggregated to the IoT data unified aggregation layer. The data aggregated by the IoT data unified aggregation layer is extracted to the data transfer system through the efficient streaming data processing middleware on the cloud-side internal data processing side, and then the transferred data is stored in the data storage layer through the business adaptation layer.

[0016] This invention discloses a general technical architecture method and system based on the Internet of Things (IoT) for building energy. The method includes: selecting an access protocol according to the device type and connecting energy system infrastructure-related devices to the edge side; matching corresponding solutions according to the business functions of the edge-side access devices and converting the communication protocols of the edge-side access devices to the MQTT protocol; constructing an IoT unified data aggregation layer, converting the communication protocols of third-party systems to the MQTT protocol, and aggregating data uploaded from the edge side, edge side, and third-party systems to the IoT unified data aggregation layer based on the MQTT protocol; extracting the data aggregated by the IoT unified data aggregation layer to a data relay system for data relay through the cloud-side internal data processing side, and then storing the relayed data to the data storage layer through a business adaptation layer. This invention enables the widespread access, simple parsing, and efficient conversion of data for building energy scenarios. Attached Figure Description

[0017] To more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely exemplary, and those skilled in the art can derive other embodiments based on the provided drawings without creative effort.

[0018] The structures, proportions, sizes, etc. illustrated in this specification are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed herein, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0019] Figure 1 A schematic diagram of a general technical architecture system based on the Internet of Things for building energy provided by the present invention is shown; Figure 2 A flowchart of a general technical architecture method based on the Internet of Things for Building Energy provided by the present invention is shown; Figure 3 This paper presents a complete architectural diagram of a general technical architecture system based on the Internet of Things for Building Energy provided by the present invention. Figure 4 This invention illustrates a three-level data link diagram of a general technical architecture based on the Internet of Things for Building Energy. Figure 5 The diagram shows an IOT-HUB service adapter based on a general technical architecture of building energy Internet of Things provided by the present invention. Detailed Implementation

[0020] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Figure 1 The diagram shows a schematic of a general technical architecture system based on the Internet of Things for building energy provided by the present invention.

[0022] like Figure 1 As shown, this invention discloses a general technical architecture system based on the Internet of Things for Building Energy. The general technical architecture system includes: edge side, cloud side, and cloud side; the cloud side includes an external data processing side and an internal data processing side. The terminal side is used to enable access to various basic operation-related equipment of energy systems in building energy scenarios; The edge side converts the communication protocol of the end-side access device into the MQTT protocol, which is used to achieve standardized and unified management of the end-side access device before data aggregation; The external data processing side is used to build a unified IoT data aggregation layer before data from the edge or device is uploaded to the cloud. This layer converts the communication protocols of third-party systems into the MQTT protocol and aggregates the data uploaded from the edge, device, and third-party systems to the unified IoT data aggregation layer based on the MQTT protocol specifications. The external data processing side is the technical architecture for connecting third-party systems, IoT protocol converters, and cloud deployment. The internal data processing side is used to extract, transfer, adapt to business, and store data from the data aggregated by the IoT data unified aggregation layer. The internal data processing side is a four-level data processing link architecture consisting of a high-efficiency streaming data processing middleware, a data transfer system, a business adaptation layer, and a data storage layer. The technical architecture of the general technical architecture system is a three-level data system; the three-level data system includes the first data link, the second data link and the third data link.

[0023] It should be noted that the terminal side is configured with five types of equipment related to the basic operation of various energy systems in building energy scenarios. When equipment related to the basic operation of energy systems is connected, the connection is performed according to the corresponding protocol based on the equipment type.

[0024] The edge side determines three major categories of solutions based on different business functions; for the business functions of the end-side access devices, the corresponding solutions are matched, and the communication protocol is converted to the MQTT protocol to complete the standardization and unification before data aggregation.

[0025] To ensure consistency in subsequent data processing and the security of the IoT platform, the external data processing side constructs a unified IoT data aggregation layer for third-party systems (i.e., devices and services outside the cloud platform) before uploading data from the edge or device side to the cloud. This layer improves and standardizes the communication protocols of third-party systems, providing only a unified and unique data communication protocol: MQTT. Through an innovative data model design, this protocol enables the aggregation of data uploaded from the edge, device side, and third-party systems according to the MQTT protocol specification. This avoids processing too many protocols at this layer, thus preventing excessive protocol adaptation development work and instability issues caused by a surge in devices. Even after the data aggregation layer, significant adaptation work remains. The edge and device side data refers to data generated by edge access devices, while the third-party system data refers to data generated by cloud-to-cloud interconnection devices. Simultaneously, cloud-to-cloud interconnection support is provided on this side through a third-party system-IoT protocol converter design (SDK2MQTT)-unified IoT data aggregation technical architecture. This provides a scalable access solution to support more building energy data scenarios, better ensuring business sustainability.

[0026] The internal data processing side is hidden beneath the external data processing side. It has high reliability, high security, and high performance technical requirements. The internal processing side provides a four-level data processing link architecture to realize data processing on the data aggregated by the unified IoT data aggregation layer, including data extraction, data transfer, business adaptation, and data storage, fully meeting the technical standard requirements.

[0027] like Figure 3 The diagram shows a complete system architecture diagram of the general technical architecture of the Building Energy Internet of Things (IoT). First, devices are bound to the edge side, which includes five types of devices. Data generated by these devices is received. Standalone networked devices (such as electricity meters and weather stations) and third-party system devices (generally accessed via API) directly upload their data to the external data processing side on the cloud via the MQTT protocol. Lower-level devices (such as DDCs and PLCs, generally supporting Modbus, Mbus, and serial bus protocols), upper-level access devices (generally supporting OPC and BACnet protocols), and other customized devices (achieved through customized protocol integration) require matching corresponding solutions on the edge side to convert their non-MQTT protocols to MQTT, and then upload their data to the external data processing side on the cloud via MQTT. For third-party systems accessed via cloud-to-cloud integration, the external data processing side improves and standardizes the communication protocols of the third-party systems through the IoT data aggregation layer, providing only a unified and unique data communication protocol, MQTT. Data uploaded by the edge access devices and third-party systems is aggregated based on the MQTT protocol. Finally, on the internal data processing side, a four-level data processing link is used to extract, transfer, adapt to business, and store data from the unified IoT data aggregation layer. This completes the access of various energy system infrastructure-related devices in building energy scenarios, the conversion of communication protocols, and the storage of data uploaded by devices.

[0028] According to an embodiment of the present invention, the terminal side is used to enable access to various energy system infrastructure operation-related equipment in building energy scenarios, including: The device type is determined on the end side based on the device attributes of the equipment related to the basic operation of the energy system; the device types include stand-alone networked devices, lower-level devices, upper-level devices, third-party system devices, and other customized devices; Analyze the equipment type, select the corresponding access protocol, and connect the relevant equipment for the basic operation of the energy system to the end side.

[0029] It should be noted that the specific equipment types related to the basic operation of various energy systems in building energy scenarios are as follows: stand-alone networked devices (such as electricity meters, weather stations, etc.), lower-level devices (such as DDC, PLC, etc., generally supporting Modbus, Mbus, serial bus, etc.), upper-level access devices (generally supporting OPC, BACnet, etc.), third-party system devices (generally accessed via API), and other customized devices (these are implemented through customized protocol interfaces). By analyzing the device types and selecting the corresponding access protocols, the basic operation-related equipment of the energy system can be connected to the end side, which can effectively solve the various device access problems faced by building energy scenarios.

[0030] According to an embodiment of the present invention, the edge is used to implement standardized and unified management of the end-side access devices before data aggregation, and to convert the communication protocol of the end-side access devices into the MQTT protocol, including: Edge-side solutions are determined based on the service functions of end-side access devices; these solutions include access schemes for hard gateways, hardware servers, and edge computing nodes. Based on the analysis of the business functions of the end-side access devices, the corresponding solutions are selected, and the standardization of the end-side access devices is completed before data aggregation.

[0031] It should be noted that traditional IoT platform architectures tend to overlook edge design. Based on a deep understanding of IoT platforms and business analysis, we have innovatively proposed edge design standards, which define solutions at the edge to achieve broader access support. These solutions include access solutions for hard gateways (cloud gateways), access solutions for hardware servers (hosts, industrial control computers), and access solutions for edge computing nodes (edge ​​controllers). Through these solutions, we aim to achieve broader access support and efficient connection of end-side devices to complete data aggregation and standardization.

[0032] The edge-side design ensures good compatibility with various edge-side devices (not just smart gateways). The core design of the edge-side design is to uniformly use the MQTT protocol for transmission. During transmission, a protocol parsing adapter converts the data to the data exchange target. At the same time, for non-MQTT protocols, a software gateway is used to develop a protocol parser such as BacNET2MQTT to convert and normalize the data, thereby achieving standardized uniformity before the edge-side access devices complete data aggregation.

[0033] According to an embodiment of the present invention, the high-efficiency streaming data processing middleware extracts data from MQTT through the MQTT-Kafka connection component and stores the obtained data in the data transfer system.

[0034] It should be noted that MQTT refers to data uploaded by end-side access devices and third-party systems to the external data processing side and aggregated through the IoT data unified aggregation layer. The efficient streaming data processing middleware refers to the MQTT-Kafka connection component that efficiently extracts data from MQTT and stores it in the data transfer system, avoiding problems such as data backlog and blockage.

[0035] According to an embodiment of the present invention, the data transit system uses Kafka as the basic technical support middleware for the data transit system. The data stored in the data transit system is transited through the Kafka-Topic storage specification to obtain transit data. The latest periodic data can also be extracted from the data transit system through the ETL service, and the periodic data can be put into a data warehouse or connected with other data forwarding sources.

[0036] It should be noted that a data relay system refers to a system that uses Kafka as the underlying middleware for data relay. Through the Kafka-Topic storage specification, it completes data relay. When other systems experience interruptions, the data relay system can retain data; when other systems recover, data can be retrieved from the data relay system to achieve system-level recovery. Figure 3 As shown, the data transfer system has extremely high scalability. The latest periodic data can be extracted from the data transfer system and put into the data warehouse or connected with other data transfer sources through the ETL (Extraction Transformation Loading) service.

[0037] According to an embodiment of the present invention, the service adaptation layer is built using an IOT-HUB service adapter, and the relay data is adapted for service through the service adaptation layer.

[0038] It should be noted that, as Figure 5The diagram shows the IoT-HUB service adapter for the general technical architecture of the Building Energy Internet of Things (IoT). The IoT-HUB service adapter extracts data via Kafka consumption, performs protocol adaptation using a protocol parser and service adapter, and then uses a DB connector to manage IoT data according to rules. The service adaptation layer is built using the IoT-HUB service adapter, implementing core functions such as Kafka consumption, protocol parsing, service adaptation, and a rule engine. It efficiently extracts and assembles relay data from Kafka and loads it into a pre-defined data storage layer. For example, standalone networked devices and third-party system devices directly upload MQTT messages to the cloud via the MQTT protocol. The protocol data within the MQTT varies depending on the device type and manufacturer. When the relay data corresponding to this MQTT reaches the internal data processing side, the IoT-HUB service adapter parses the message body within the relay data corresponding to the MQTT, adapting it to various protocols based on business characteristics and protocol features. The IoT-HUB service adaptation layer adopts an adapter concept, providing greater scalability and supporting writing to multiple data sources.

[0039] According to an embodiment of the present invention, the data storage layer dynamically expands the service adapter to load data from multiple data sources in the relay data based on the service adaptation of the relay data.

[0040] It should be noted that the data storage layer is freely expandable, depending on business needs. Business adapters can be dynamically expanded to load data from more data sources, including various data storage units such as TDengine, Redis, and Kafka, achieving true on-demand storage and expansion with business needs.

[0041] According to an embodiment of the present invention, a first data link is used to store real-time data, a second data link is used to store recent data, and a third data link is used to store all data.

[0042] It should be noted that the conventional IoT technical architecture basically only includes a two-level data system: the first data link (real-time data) and the third data link (full data). The limitation of the conventional technical architecture is that it lacks the ability to cache and temporarily store recent data. When periodic data is needed, business logic needs to be redeveloped, which increases development costs significantly. At the same time, when the third-level data link fails, the data in the first link is prone to loss. Therefore, by building a second data link (recent data) between the two data links, a three-level link data architecture can be formed, which can solve the above problems very efficiently.

[0043] like Figure 4 The diagram shown is a three-level data link diagram of the general technical architecture of the building energy Internet of Things.

[0044] The first data link includes data uploaded via the edge or device side and data uploaded by the policy execution engine. The external data processing side provides a unified IoT data aggregation layer, which improves and unifies the protocols uploaded by the edge, device side, and policy execution engine into the MQTT protocol. The second data link is the data from the data relay system. The third data link is the data from the data storage layer.

[0045] The strategy execution engine is used to achieve more secure and reliable control of IoT devices: Conventional IoT architectures focus on data collection and neglect control, generally only implementing basic control, such as control commands - MQTT protocol - device. This basic architecture can meet basic business needs, but it is not reliable and secure enough when facing complex control, especially for smart building energy control scenarios. By designing a strategy execution engine service between control commands and the MQTT protocol, it can better meet business needs while meeting reliable and secure control.

[0046] According to an embodiment of the present invention, the IoT data unified aggregation layer provides a data model; the data model includes an edge node model, an IoT device model, and a progressive data model; the progressive data model includes a basic data model, a standard data model, and a unified data model; The basic data model is used to parse the raw data; The standard data model introduces key attributes based on the basic data model for data protocol optimization; The unified data model incorporates business data based on standard data for data isolation.

[0047] It should be noted that a data model is designed in the unified data aggregation layer of the Internet of Things (IoT). Various protocols and data are accessed according to the data model to achieve the goal of unification. The data model includes an edge node model, an IoT device model, and an incremental data model; the incremental data model includes a basic data model, a standard data model, and a unified data model.

[0048] The basic data model is generally limited by the default data constraints of the device itself or third-party devices or systems. This data model exhibits diverse variations, and the protocol adapter needs to effectively utilize the characteristics of the protocol to achieve step-by-step parsing and complete compatibility. Taking the protocol of a certain hardware gateway as an example, it contains a lot of redundant ver, pKey, sn, and other information, which needs to be simplified and optimized.

[0049] The standard data model is the process of standardizing the basic data model. Through in-depth analysis and refinement of the basic data model, the standard model layer retains highly universal and critical attributes to ensure that basic business needs are met. The standard data model introduces key attributes such as flag (identifier), msgId (message ID), and cid (field name), further optimizes the data protocol, retains important data, and performs pre-processing for subsequent data use and database storage.

[0050] The unified data model incorporates business data, including project IDs and data group IDs, to provide final processing for subsequent database storage and forwarding. With this business data, we can control the flow target and achieve business requirements such as physical data isolation based on this information.

[0051] The edge node model is constructed according to the following model specifications: {prefix} / {scene identifier} / {manufacturer agreement identifier} / {manufacturer agreement version code} / {project ID} / {data group ID} / {function identifier} / {function value}.

[0052] Model Explanation: {prefix}: defaults to Internet of Things: / iot.

[0053] {Scene Identifier}: Electricity scenario: electric Other scenarios: default.

[0054] {Manufacturer Agreement Marking}: Taking CEC as an example, the default is cet-mqtt, and the "-" in the middle represents a device directly connected to MQTT. The protocol encoding configured in the R&D and operations backend shall prevail.

[0055] {Manufacturer Agreement Version Code}: Taking CLP as an example, if their protocol uses two versions, such as v1.0 and v1.1, we define them as 1 and 2 respectively using the numbering system. If no version number is specified, the default value is 1. To lower the topic hierarchy, the two have been merged into one.

[0056] {Project ID}: Used to distinguish projects.

[0057] {Data Group ID}: Based on gateway data groups, it is recommended to use 2000 signals as a baseline. If the number exceeds this, for example, if the group ID is 10001, then... Integrated business functions can be grouped by subsystem.

[0058] {Load Balancing Flag}: When a Topic is overloaded with data, new projects can use an alternative consumption channel. The default value is 100.

[0059] {Function Identifier}: More function identifiers can be designed based on the Topic in the future. This time, only service is defined to represent service.

[0060] {Function Values}: The basic types are currently data reporting, status reporting, data distribution, and historical reporting.

[0061] Data reporting: upload Status reporting: status Data distribution: down Historical report: history Event reporting: event Heart rate reporting: keepalive Power loss alarm: power-loss-alarm.

[0062] The following is an example using a hardware gateway: Data reporting: / iot / electric / cet-mqtt-2 / 100003 / 10001 / 100 / service / u Status reporting: / iot / electric / cet-mqtt-2 / 100003 / 10001 / 101 / service / s Data distribution: / iot / electric / cet-mqtt-1 / 100003 / 10001 / 101 / service / d Historically reported: / iot / electric / cet-mqtt-2 / 100003 / 10001 / 101 / service / h.

[0063] The following is an example of a software gateway (using bacnet as an example): Data reporting: / iot / default / bacnet2mqtt-1 / 100003 / 10001 / 101 / service / u Status reporting: / iot / default / bacnet2mqtt-1 / 100003 / 10001 / 101 / service / s Data distribution: / iot / default / bacnet2mqtt-1 / 100003 / 10001 / 101 / service / d Historically reported: / iot / default / bacnet2mqtt-1 / 100003 / 10001 / 101 / service / h.

[0064] Regarding other special events: Heartbeat reporting: / iot / cet-mqtt / {sn} / service / k Power failure alarm: / iot / cet-mqtt / {sn} / service / p.

[0065] The IoT device model is constructed according to the following model specifications: {prefix} / {manufacturer agreement identifier} / {manufacturer agreement version code} / {project ID} / {data group ID} / {data type}.

[0066] Model Explanation: {prefix}: defaults to Huade Smart IoT: / iot.

[0067] {Manufacturer Protocol Identifier}: The default is sdk2mqtt. Taking Black Ant as an example, it means that the data is accessed from Black Ant's SDK and then converted into MQTT by default.

[0068] {Product Type Code}: According to the general object model architecture, there should be one table for each object model. However, the original design did not link them together, and our main scenario is based on the gateway. Some linked designs will optimize the use of data. For example, the indoor temperature and humidity sensor product is coded as temp_hr, which can also correspond to the product class identifier or code.

[0069] {Load balancing flag}: The default value is 100, and it can be extended to 101, etc. (load balancing can be achieved when there are too many devices connected to a single topic).

[0070] {Function Identifier}: More function identifiers can be designed based on the Topic in the future. This time, only service is defined to represent service.

[0071] {Function Values}: The basic types are currently data reporting, status reporting, heartbeat reporting, and data distribution.

[0072] Enter a specific table and gradually model it: The following is an example of an indoor temperature and humidity sensor: Data reporting: / iot / sdk2mqtt / temp_hr / 100 / service / u Status reporting: / iot / sdk2mqtt / temp_hr / 100 / service / u Heartbeat reporting: / iot / sdk2mqtt / temp_hr / 101 / service / u Data distribution: / iot / sdk2mqtt / temp_hr / 102 / service / u.

[0073] The following is an example using a weather station: Data reporting: / iot / sdk2mqtt / weather_station / 100 / service / u Status reporting: / iot / sdk2mqtt / weather_station / 100 / service / u Heartbeat reporting: / iot / sdk2mqtt / weather_station / 100 / service / u Data distribution: / iot / sdk2mqtt / weather_station / 100 / service / u.

[0074] The basic data model is constructed according to the following model specifications: { "ver": "2.x", "pKey": "", "sn": "NT001", "ts": 1726489531, "devs": [ { "dev": "11F General Lighting", "ts": 1726489531, "d": [ { "m": "1713177651031001", "ts": 1726489531, "v": 0.6 } ] } ] }

[0075] The standard data model is constructed according to the following model specifications: { "flag": "", "data": [ { "cid": "N1000001", "v": "66.6", "s": 1594281513, "dq": 1 }, { "cid": "N1000002", "v": "62.1", "s": 1594281513, "dq": 0 } ] }

[0076] The unified data model is constructed according to the following model specifications: Protocol parsing: {Start bit}{Device identifier}{Business scenario code}{Project ID}{Data group ID}{Load balancing flag}{Business identifier}{Action to be executed}.

[0077] Agreement content: { "data": [ { "cid": "G100020", "v": "123", "ts": 1726489531 }, { "cid": "G100020", "v": "123", "ts": 1726489531 } ] }

[0078] Figure 2 A flowchart of a general technical architecture method based on the Internet of Things for Building Energy provided by the present invention is shown.

[0079] like Figure 2 As shown, the second aspect of the present invention provides a general technical architecture method based on the Internet of Things for Building Energy, comprising: S21, the device type is determined by the end side based on the device attributes of the energy system infrastructure operation related equipment, and the corresponding access protocol is selected to connect the energy system infrastructure operation related equipment to the end side; S22, by matching the corresponding solution based on the business functions of the terminal access device on the edge side, converting the communication protocol of the terminal access device into the MQTT protocol, and uploading the data generated by the terminal access device to the external data processing side on the cloud side based on the MQTT protocol; S23, before the data from the edge or terminal side is uploaded to the cloud by the external data processing side on the cloud side, a unified IoT data aggregation layer is built. The communication protocol of the third-party system is converted into the MQTT protocol in the unified IoT data aggregation layer. Based on the protocol specification of the MQTT protocol, the data uploaded by the edge, terminal side and third-party system are aggregated to the unified IoT data aggregation layer. S24: The data aggregated by the IoT data unified aggregation layer is extracted to the data transfer system through the efficient streaming data processing middleware of the internal data processing side of the cloud. Then, the transferred data is stored in the data storage layer through the business adaptation layer.

[0080] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0081] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0082] In addition, in the various embodiments of the present invention, each functional unit can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0083] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0084] Alternatively, if the integrated units of this invention are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

Claims

1. A general technical architecture system based on building energy Internet of Things, characterized in that, The general technical architecture system comprises: an end side, a side side and a cloud side; the cloud side comprises an external data processing side and an internal data processing side; The end side is used for realizing access to various energy system basic operation related devices of a building energy scene; The side side is used for realizing standardized and unified management of the end side access devices before data aggregation, and converting the communication protocol of the end side access devices into an MQTT protocol; The external data processing side is used for constructing an Internet of Things data unified aggregation layer before clouding of data of the end side or the side side, converting the communication protocol of a third party system into an MQTT protocol in the Internet of Things data unified aggregation layer, and aggregating data uploaded by the end side, the side side and the third party system to the Internet of Things data unified aggregation layer based on the protocol specification of the MQTT protocol; the external data processing side is a technical architecture for third party system-Internet of Things protocol converter-cloud end deployment docking; The internal data processing side is used for data extraction, data transfer, business adaptation and data storage of data aggregated by the Internet of Things data unified aggregation layer; the internal data processing side is a four-level data processing link architecture composed of an efficient stream data processing middleware, a data transfer system, a business adaptation layer and a data storage layer. The technical architecture of the general technical architecture system is a three-level data system; the three-level data system comprises a first data link, a second data link and a third data link. 2.The general technical architecture system based on building energy internet of things according to claim 1, wherein, The end side is used for realizing access to various energy system basic operation related devices of a building energy scene, comprising: The end side determines a device type based on a device attribute of the energy system basic operation related device; the device type comprises a single independent networking device, a lower computer device, an upper computer access device, a third party system device and other customized devices; According to analysis of the device type, a corresponding access protocol is selected to access the energy system basic operation related device to the end side. 3.The general technical architecture system based on building energy internet of things according to claim 1, wherein, The side side is used for realizing standardized and unified management of the end side access devices before data aggregation, and converting the communication protocol of the end side access devices into an MQTT protocol, comprising: The side side determines a solution based on a business function of the end side access device; the solution comprises a hard gateway access solution, a hardware server access solution and an edge computing node access solution; According to analysis of the business function of the end side access device, a corresponding solution is selected to convert the communication protocol of the end side access device into an MQTT protocol. 4.The general technical architecture system based on building energy Internet of Things according to claim 1, wherein, The efficient stream data processing middleware extracts data from MQTT through an MQTT-Kafka connection component, and stores the obtained data into the data transfer system.

5. The general technical architecture system based on building energy internet of things according to claim 4, characterized in that, The data transfer system adopts Kafka as a basic technical support middleware of the data transfer system, performs data transfer on the data stored in the data transfer system through Kafka-Topic storage specification to obtain transferred data; the latest periodic data can also be extracted from the data transfer system through an ETL service, and the periodic data is put into a data warehouse or docked with other data forwarding sources. 6.The general technical architecture system based on building energy internet of things according to claim 5, wherein, The service adaptation layer is built using an IOT-HUB service adapter, and the transit data is adapted by the service adaptation layer. 7.The general technical architecture system based on building energy internet of things according to claim 6, wherein, The data storage layer dynamically extends the service adapter based on the service adaptation of the transit data to load data from multiple data sources in the transit data. 8.The general technical architecture system based on building energy internet of things according to claim 1, wherein, The first data link is used to store real-time data, the second data link is used to store recent data, and the third data link is used to store full-amount data. 9.The general technical architecture system based on building energy internet of things according to claim 1, wherein, The IOT data unified convergence layer provides a data model; the data model includes an edge node model, an IOT device model, and a progressive data model; the progressive data model includes a basic data model, a standard data model, and a unified data model; The basic data model is used to analyze raw data; The standard data model introduces key attributes based on the basic data model for data protocol optimization; The unified data model introduces business data based on the standard data for data isolation.

10. A general technical architecture method based on building energy internet of things, applying a general technical architecture system based on building energy internet of things as claimed in claims 1-9, characterized in that, It includes: By the end side, determine the device type according to the device attribute of the energy system basic operation related equipment, select the corresponding access protocol, and access the energy system basic operation related equipment to the end side; By the edge side, according to the business function matching of the end side access equipment, the communication protocol of the end side access equipment is converted into MQTT protocol, and the data generated by the end side access equipment is uploaded to the external data processing side of the cloud side based on the MQTT protocol; Through the external data processing side of the cloud side, before the data of the end side or the edge side is uploaded to the cloud, build an IOT data unified convergence layer, convert the communication protocol of the third party system into MQTT protocol in the IOT data unified convergence layer, and based on the protocol specification of MQTT protocol, the data uploaded by the end side, the edge side and the third party system is converged to the IOT data unified convergence layer; Through the efficient flow data processing middleware of the internal data processing side of the cloud side, the data converged by the IOT data unified convergence layer is extracted to the data transit system for data transit, and then the obtained transit data is stored to the data storage layer through the business adaptation layer.

Images