Systems and methods of enabling blockchain-based building automation systems

A system includes a plurality of first building components, a private local blockchain, a second building component, and a client device. The private local blockchain includes a device ledger indicating each first building component, a transaction ledger maintaining a plurality of blocks corresponding to a transaction between at least two first building components and including at least one first unique identifier of the corresponding first building component and a timestamp of the transaction, a transaction processor that generates at least one block by executing a predetermined hash function using a previous block, and a local rule engine defining rules to evaluate a transaction. The second building component has at least one second unique identifier. The client device provides the at least one second unique identifier to the private local blockchain. The private local blockchain determines whether to add the second building component to the device ledger.

BACKGROUND

Commercial buildings typically using large building control systems such as fire detection systems, heating, ventilation, and air conditioning (HVAC) systems, access control systems, and video surveillance systems.

SUMMARY

One implementation of the present disclosure is a system. The system includes a plurality of first building components, a private local blockchain, a second building component, and a client device. Each first building component has at least one first unique identifier. The private local blockchain is implemented by the plurality of first building components and includes a device ledger that maintains a data structure indicating each first building component, a transaction ledger that maintains a plurality of blocks, each block corresponding to a transaction between at least two first building components of the plurality of first building components, each block including the at least one first unique identifier of the corresponding first building component and a timestamp of the corresponding transaction, a transaction processor that generates at least one block by executing a predetermined hash function using a previous block, and a local rule engine defining one or more rules used to evaluate the transaction of one or more blocks. The second building component has at least one second unique identifier. The client device identifies the at least one second unique identifier of the second building component and provides the at least one second unique identifier to the private local blockchain. The private local blockchain uses the at least one second unique identifier and the local rule engine to determine to add the second building component to the device ledger.

Another implementation of the present disclosure is a method. The method includes maintaining, by a device ledger of a private local blockchain, a data structure indicating a plurality of building components of the private local blockchain, each first building component having at least one first unique identifier; maintaining, by a transaction ledger of the private local blockchain, a plurality of blocks, each block corresponding to a transaction between at least two first building components of the plurality of first building components, each block including the at least one first unique identifier of the corresponding first building component and a timestamp of the corresponding transaction; generating, by a transaction processor of the private local blockchain, at least one block by executing a predetermined hash function using a previous block; identifying, by a client device, at least one second unique identifier of a second building component; providing, by the client device, the at least one second unique identifier to the private local blockchain; and determining to add, by the private local blockchain using the at least one second unique identifier and the local rule engine, the second building component to the device ledger.

DETAILED DESCRIPTION

Overview

The present disclosure relates generally to the field of HVAC systems, and more particularly to systems and methods of enabling blockchain-based HVAC systems. Referring generally to the Figures, in some embodiments, a system includes a plurality of first building components, a private local blockchain, a second building component, and a client device. Each first building component has at least one first unique identifier. The private local blockchain is implemented by the plurality of first building components and includes a device ledger that maintains a data structure indicating each first building component, a transaction ledger that maintains a plurality of blocks, each block corresponding to a transaction between at least two first building components of the plurality of first building components, each block including the at least one first unique identifier of the corresponding first building component and a timestamp of the corresponding transaction, a transaction processor that generates at least one block by executing a predetermined hash function using a previous block, and a local rule engine defining one or more rules used to evaluate the transaction of one or more blocks. The second building component has at least one second unique identifier. The client device identifies the at least one second unique identifier of the second building component and provides the at least one second unique identifier to the private local blockchain. The private local blockchain uses the at least one second unique identifier and the local rule engine to determine to add the second building component to the device ledger.

Existing devices and systems, such as HVAC systems, sensors, smart devices (e.g., devices that may have a local processing circuit and communications hardware for communicating data to/from remote devices), and other systems that operate in an Internet-of-Things (IoT) paradigm, may have significant challenges associated with security, including electronically communicating data that is used to properly operate devices in the system while maintaining security of private or sensitive data maintained by the devices, and connectivity, including. For example, devices may not have a clear authentication standard to follow. Critical infrastructure can be compromised if devices are compromised. Device incompatibility may result from devices from disparate manufacturers being expected to operate together in a common infrastructure, such as home automation systems and building management systems.

The present solution can implement blockchain technologies in electronic sensor, controls, and security systems, including HVAC systems, to improve data security, equipment monitoring, device authentication, standardization, energy efficiency, and system robustness. The present solution can enable a distributed architecture implemented using blockchain to address technical, security, and trust challenges, such as a dual layer, private/public blockchain. For example, the present solution can enable a verifiable, secure, and tamper-proof system that stores and shares data provided by HVAC equipment, smart devices, and sensors. In some embodiments, the present solution enables a common, integrated platform that can be used to manage disparate devices on the platform. As such, systems and methods in accordance with the present disclosure can use of several types of automation, allow devices and equipment to work together more efficiently, monitor and save energy, and use preventative maintenance to protect equipment; the increased automation capabilities can reduce the risk of equipment failure that can lead to critical infrastructure being down.

In some embodiments, the present solution uses a distributed ledger to enable devices to be identifying and verified with less overhead and greater security. The distributed ledger may increase system robustness by eliminating a single point of failure. In some embodiments, the present solution implements a blockchain to collect and accurately track sensor data to ensure no duplication of entries and assure that there is no malicious data input. In some embodiments, the present solution enables devices to communicate data using the blockchain. The present solution can implement smart contracts to enable device autonomy, guaranteeing integrity of data and facilitating peer to peer communication. In some embodiments, the present solution maintains a history of all connected devices, facilitating troubleshooting and maintenance. The present solution can allow multiple tiers of authorized agents for a particular building (e.g., building managers and tenants of respective areas of the building) to automate maintenance, efficiency, security, and local preferences (e.g., building managers can control top level rules, while enabling non-administrative users to control lower level functions).

Building Management System and HVAC System

InFIG. 2, waterside system200is depicted as a central plant having a plurality of subplants202-212. Subplants202-212are shown to include a heater subplant202, a heat recovery chiller subplant204, a chiller subplant206, a cooling tower subplant208, a hot thermal energy storage (TES) subplant210, and a cold thermal energy storage (TES) subplant212. Subplants202-212consume resources (e.g., water, natural gas, electricity, etc.) from utilities to serve the thermal energy loads (e.g., hot water, cold water, heating, cooling, etc.) of a building or campus. For example, heater subplant202can heat water in a hot water loop214that circulates the hot water between heater subplant202and building10. Chiller subplant206can chill water in a cold water loop216that circulates the cold water between chiller subplant206building10. Heat recovery chiller subplant204can transfer heat from cold water loop216to hot water loop214to provide additional heating for the hot water and additional cooling for the cold water. Condenser water loop218can absorb heat from the cold water in chiller subplant206and reject the absorbed heat in cooling tower subplant208or transfer the absorbed heat to hot water loop214. Hot TES subplant210and cold TES subplant212can store hot and cold thermal energy, respectively, for subsequent use.

Although subplants202-212are shown and described as heating and cooling water for circulation to a building, it is understood that any other type of working fluid (e.g., glycol, CO2, etc.) can be used in place of or in addition to water to serve the thermal energy loads. In some embodiments, subplants202-212can provide heating and/or cooling directly to the building or campus without requiring an intermediate heat transfer fluid. These and other variations to waterside system200are within the teachings of the present invention.

Each of subplants202-212can include a variety of equipment that can facilitate the functions of the subplant. For example, heater subplant202is shown to include a plurality of heating elements220(e.g., boilers, electric heaters, etc.) that add heat to the hot water in hot water loop214. Heater subplant202is also shown to include several pumps222and224that circulate the hot water in hot water loop214and to control the flow rate of the hot water through individual heating elements220. Chiller subplant206is shown to include a plurality of chillers232that remove heat from the cold water in cold water loop216. Chiller subplant206is also shown to include several pumps234and236that circulate the cold water in cold water loop216and control the flow rate of the cold water through individual chillers232.

Heat recovery chiller subplant204is shown to include a plurality of heat recovery heat exchangers226(e.g., refrigeration circuits) that can transfer heat from cold water loop216to hot water loop214. Heat recovery chiller subplant204is also shown to include several pumps228and230that can circulate the hot water and/or cold water through heat recovery heat exchangers226and to control the flow rate of the water through individual heat recovery heat exchangers226. Cooling tower subplant208is shown to include a plurality of cooling towers238that can remove heat from the condenser water in condenser water loop218. Cooling tower subplant208is also shown to include several pumps240that can circulate the condenser water in condenser water loop218and to control the flow rate of the condenser water through individual cooling towers238.

Hot TES subplant210is shown to include a hot TES tank242that can store the hot water for later use. Hot TES subplant210can also include one or more pumps or valves that can control the flow rate of the hot water into or out of hot TES tank242. Cold TES subplant212is shown to include cold TES tanks244that can store the cold water for later use. Cold TES subplant212can also include one or more pumps or valves that can control the flow rate of the cold water into or out of cold TES tanks244.

Cooling coil334can receive a chilled fluid from waterside system200(e.g., from cold water loop216) via piping342and can return the chilled fluid to waterside system200via piping344. Valve346can be positioned along piping342or piping344to control a flow rate of the chilled fluid through cooling coil334. In some embodiments, cooling coil334includes multiple stages of cooling coils that can be independently activated and deactivated (e.g., by AHU controller330, by BMS controller366, etc.) to modulate an amount of cooling applied to supply air310.

Each of valves346and352can be controlled by an actuator. For example, valve346can be controlled by actuator354and valve352can be controlled by actuator356. Actuators354-356can communicate with AHU controller330via communications links358-360. Actuators354-356can receive control signals from AHU controller330and can provide feedback signals to controller330. In some embodiments, AHU controller330receives a measurement of the supply air temperature from a temperature sensor362positioned in supply air duct312(e.g., downstream of cooling coil334and/or heating coil336). AHU controller330can also receive a measurement of the temperature of building zone306from a temperature sensor364located in building zone306.

Referring now toFIG. 4, a block diagram of a building management system (BMS)400is depicted. BMS400can be implemented in building10to automatically monitor and control various building functions. BMS400is shown to include BMS controller366and a plurality of building subsystems428. Building subsystems428are shown to include a building electrical subsystem434, an information communication technology (ICT) subsystem436, a security subsystem438, a HVAC subsystem440, a lighting subsystem442, a lift/escalators subsystem432, and a fire safety subsystem430. Building subsystems428can include a refrigeration subsystem, an advertising or signage subsystem, a cooking subsystem, a vending subsystem, a printer or copy service subsystem, or any other type of building subsystem that uses controllable equipment and/or sensors to monitor or control building10. In some embodiments, building subsystems428include waterside system200and/or airside system300, as described with reference toFIGS. 2-3.

Each of building subsystems428can include any number of devices, controllers, and connections for completing its individual functions and control activities. HVAC subsystem440can include many of the same components as HVAC system100, as described with reference toFIGS. 1-3. For example, HVAC subsystem440can include a chiller, a boiler, any number of air handling units, economizers, field controllers, supervisory controllers, actuators, temperature sensors, and other devices for controlling the temperature, humidity, airflow, or other variable conditions within building10. Lighting subsystem442can include any number of light fixtures, ballasts, lighting sensors, dimmers, or other devices that can controllably adjust the amount of light provided to a building space. Security subsystem438can include occupancy sensors, video surveillance cameras, digital video recorders, video processing servers, intrusion detection devices, access control devices and servers, or other security-related devices.

Still referring toFIG. 4, BMS controller366is shown to include a communications interface407and a BMS interface409. Interface407can facilitate communications between BMS controller366and external applications (e.g., monitoring and reporting applications422, enterprise control applications426, remote systems and applications444, applications residing on client devices448, etc.) for allowing user control, monitoring, and adjustment to BMS controller366and/or subsystems428. Interface407can also facilitate communications between BMS controller366and client devices448. BMS interface409can facilitate communications between BMS controller366and building subsystems428(e.g., HVAC, lighting security, lifts, power distribution, business, etc.).

Memory408(e.g., memory, memory unit, storage device, etc.) can include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage, etc.) for storing data and/or computer code for completing or facilitating the various processes, layers and modules described in the present application. Memory408can be or include volatile memory or non-volatile memory. Memory408can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present application. According to an exemplary embodiment, memory408is communicably connected to processor406via processing circuit404and includes computer code for executing (e.g., by processing circuit404and/or processor406) one or more processes described herein.

In some embodiments, BMS controller366is implemented within a single computer (e.g., one server, one housing, etc.). In various embodiments BMS controller366can be distributed across multiple servers or computers (e.g., that can exist in distributed locations). Further, whileFIG. 4shows applications422and426as existing outside of BMS controller366, in some embodiments, applications422and426can be hosted within BMS controller366(e.g., within memory408).

Enterprise integration layer410can be serve clients or local applications with information and services to support a variety of enterprise-level applications. For example, enterprise control applications426can provide subsystem-spanning control to a graphical user interface (GUI) or to any number of enterprise-level business applications (e.g., accounting systems, user identification systems, etc.). Enterprise control applications426can provide configuration GUIs for configuring BMS controller366. In some embodiments, enterprise control applications426can work with layers410-420to optimize building performance (e.g., efficiency, energy use, comfort, or safety) based on inputs received at interface407and/or BMS interface409.

Building subsystem integration layer420can be manage communications between BMS controller366and building subsystems428. For example, building subsystem integration layer420can receive sensor data and input signals from building subsystems428and provide output data and control signals to building subsystems428. Building subsystem integration layer420can also manage communications between building subsystems428. Building subsystem integration layer420translate communications (e.g., sensor data, input signals, output signals, etc.) across a plurality of multi-vendor/multi-protocol systems.

Integrated control layer418is shown to be logically below demand response layer414. Integrated control layer418can enhance the effectiveness of demand response layer414by enabling building subsystems428and their respective control loops to be controlled in coordination with demand response layer414. This configuration can reduce disruptive demand response behavior relative to conventional systems. For example, integrated control layer418can assure that a demand response-driven upward adjustment to the setpoint for chilled water temperature (or another component that directly or indirectly affects temperature) does not result in an increase in fan energy (or other energy used to cool a space) that would result in greater total building energy use than was saved at the chiller.

Integrated control layer418can provide feedback to demand response layer414so that demand response layer414checks that constraints (e.g., temperature, lighting levels, etc.) are properly maintained even while demanded load shedding is in progress. The constraints can also include setpoint or sensed boundaries relating to safety, equipment operating limits and performance, comfort, fire codes, electrical codes, energy codes, and the like. Integrated control layer418is also logically below fault detection and diagnostics layer416and automated measurement and validation layer412. Integrated control layer418can provide calculated inputs (e.g., aggregations) to these higher levels based on outputs from more than one building subsystem.

Fault detection and diagnostics (FDD) layer416can provide on-going fault detection for building subsystems428, building subsystem devices (i.e., building equipment), and control algorithms used by demand response layer414and integrated control layer418. FDD layer416can receive data inputs from integrated control layer418, directly from one or more building subsystems or devices, or from another data source. FDD layer416can automatically diagnose and respond to detected faults. The responses to detected or diagnosed faults can include providing an alert message to a user, a maintenance scheduling system, or a control algorithm that can attempt to repair the fault or to work-around the fault.

Systems and Methods of Enabling Blockchain-Based Building Automation Systems

Referring now toFIG. 5, a distributed building system (DBS)500is depicted. The DBS500can be implemented using various systems described herein, including the BMS400, for various facilities including homes and buildings.

The DBS500includes a plurality of building components504. The plurality of building components504can include smart devices such as sensors, actuators, controllers, HVAC components, and switches. Each building component504can include a processing circuit508and a communications circuit520.

The processing circuit508can include a processor and memory. The processor can be a general purpose or specific purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable processing components. The processor can execute computer code or instructions stored in memory or received from other computer readable media (e.g., CDROM, network storage, a remote server, etc.). The memory can include one or more devices (e.g., memory units, memory devices, storage devices, etc.) for storing data and/or computer code for completing and/or facilitating the various processes described in the present disclosure. Memory can include random access memory (RAM), read-only memory (ROM), hard drive storage, temporary storage, non-volatile memory, flash memory, optical memory, or any other suitable memory for storing software objects and/or computer instructions. Memory can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present disclosure. Memory can be communicably connected to the processor via processing circuit508and may include computer code for executing (e.g., by processor) one or more processes described herein. When processor executes instructions stored in memory, processor generally configures the processing circuit508to complete such activities.

The communications circuit520can be used to transmit data to and from the processing circuit508. The communications circuit520can include wired or wireless interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals) for conducting data communications with various systems, devices, or networks. For example, the communications circuit520can include an Ethernet card and port for sending and receiving data via an Ethernet-based communications network. The communications circuit520can include a WiFi transceiver for communicating via a wireless communications network. The communications circuit520can communicate via local area networks (e.g., a building LAN), wide area networks (e.g., the Internet, a cellular network), and/or conduct direct communications (e.g., NFC, Bluetooth). In some embodiments, the communications circuit520can conduct wired and/or wireless communications.

The processing circuit508and/or communications circuit520can be encrypted. For example, building component504may request an encryption key when receiving data access requests that are not provided via the private local blockchain540. As such, the DBS500can maintain a level of security associated with direct access of the building components504, and also use the private local blockchain540to improve the security of data shared by the building components504.

The processing circuit508can execute one or more functions of the private local blockchain540described below. For example, the processing circuit508can maintain an instance of the transaction ledger556, enabling the private local blockchain540to be distributed.

The DBS500can include a client device524. The client device524includes processing circuit528and communications circuit532, which may be respectively similar to the processing circuit508and communications circuit520of the building component504. The client device425includes a user interface536. The user interface536can receive user input and present information regarding operation of the client device524. The user interface536may include one or more user input devices, such as buttons, dials, sliders, or keys, to receive input from a user. The user interface536may include one or more display devices (e.g., OLED, LED, LCD, CRT displays), speakers, tactile feedback devices, or other output devices to provide information to a user. The user interface536may execute a distributed application to receive user preference data.

Private Local Blockchain

Each building component504can be connected to a private local blockchain540. The private local blockchain540enables secure data access control amongst the building components504, as well as with client device(s)524. The private local blockchain540can be distributed amongst various components, including building components504that are added to the private local blockchain540and network nodes552, as described further herein. The private local blockchain540can maintain data exchanges amongst the building components504in a confidential, immutable manner, reducing the computational resources required for each building component504to provide such functionality.

The private local blockchain540can maintain a device ledger544indicating each building component504that is on the private local blockchain540, such as being authorized to communicate amongst devices of the private local blockchain540. The private local blockchain540can add each building component504to the private local blockchain540. In some embodiments, the private local blockchain network540adds the building component504to the private local blockchain network540by adding a device identifier of the building component504to the device ledger544. The private local blockchain network540can similarly remove the building component504by removing the device identifier of the building component504from the device ledger544. After each building component504is added to the private local blockchain540, the building component504can use the private local blockchain540to execute various actions, data retrieval, and communications, including access control, stored user preferences, home automation, system and equipment monitoring, energy management, and equipment troubleshooting and warranty.

The device identifier may include a unique identifier and a public identifier. For example, the unique identifier may be an identifier specific to the building component504, while the public identifier may indicate a make/model of the building component504. As such, when the private local blockchain540outputs blocks to a public blockchain as described below, the private local blockchain540can excise the unique identifier while maintaining an association between the public identifier and any data associated with the building component504.

In some embodiments, the private local blockchain540receives the device identifier via an application executed by the client device524. The client device524can receive the device identifier based on the device identifier being provided to the client device524. For example, the user interface536can receive the device identifier as a user input.

The client device524can use an image capture device, such as a camera, to detect a representation of the device identifier. For example, the building component504may include an image-based identifier, such as a QR code. The application executing on the client device524can cause the image capture device to detect the QR code, extract the device identifier from the QR code, and transmit the device identifier to the private local blockchain540.

Local Rule Engine

The private local blockchain540can maintain a local rule engine548. The local rule engine548can maintain rules, including policies and heuristics, that can be executed to verify transactions and other information regarding the private local blockchain540. The local rule engine548can maintain predefined preferences regarding data communication policies, such as user defined preferences received via the application executing on the client device524. The local rule engine548may maintain rules regarding transactions performed amongst building components504, such as conditions under which a first building component504may transmit data via the private local blockchain540responsive to receiving a data access request from a second building component504.

In some embodiments, the local rule engine548monitors transactions. The local rule engine548can retrieve transactions from the transaction ledger556described below, and execute one or more rules to monitor information such as whether a data requesting component504is authorized to request particular data, whether a data providing component504is authorized to provide the requested particular data, and whether either component504is authorized to perform a particular action using the requested particular data. Responsive to the transaction not satisfying the one or more rules, the local rule engine548can output an alert.

Network Nodes

The private local blockchain540can include a plurality of network nodes552. In some embodiments, one or more network nodes552are implemented using at least one of the building components504that are on the private local blockchain540. In some embodiments, one or more network nodes552are implemented by devices distinct from the building components504that are on the private local blockchain540. The network nodes552may include oracle nodes.

In some embodiments, the plurality of network nodes552can provide data external to the private local blockchain540to the private local blockchain540, such as to enable the private local blockchain540to execute smart contracts responsive to the external data. As described herein, the private local blockchain540can require building components504(and client devices524) to be authenticated in order to communicate with other devices on the private local blockchain540, which may limit the ability of the private local blockchain540to perform actions (e.g., execute smart contracts) that use data not locally maintained by devices of the private local blockchain540themselves. The plurality of network nodes552may be trustless nodes that provide external data based on an incentive to provide verifiable, accurate data. The plurality of network nodes552may provide external data such as weather data, price data (e.g., electricity prices), and traffic data.

Transaction Ledgering and Processing

The private local blockchain540can maintain a transaction ledger556. The transaction ledger556can maintain a data structure corresponding to each transaction requested and/or executed by the building components504. The transaction ledger556can represent a transparent, indelible record of each transaction executed by the building components504. For example, each data structure corresponding to each transaction can indicate an identifier of each device involved in the transaction (e.g., a data requesting device and a data providing device), the action(s) that took place in the transaction (e.g., the data transmitted, the physical action performed, a type of the transaction) and a timestamp of the action(s). The transaction ledger556can represent all facility-level transactions that occur.

In some embodiments, the transaction ledger556maintains the data structure as a block. Each block can represent a transaction, and can include a representation of at least one previous transaction executed by the building components504on the private local blockchain540. The transaction ledger556can use a device identifier of a particular building component504associated with a plurality of transactions performed by a same device to generate a chain of transactions corresponding to the particular building component504. Each block can maintain a rules ledger (e.g., based on rules of the local rule engine548), enabling each device that access the transaction ledger556to execute the rules of the private local blockchain540.

In some embodiments, each block includes a block header including a hash of a previous block to provide the representation of the at least one previous transaction. The hash of the previous block can be generated by executing a predetermined hash function, such as a cryptographic hash function, on data of the previous block. As such, the transaction ledger556can be immutable, as each network node552and/or building component504can verify that the blocks of the transaction ledger556have not been compromised by executing the predetermined hash function on the blocks of the transaction ledger556. In some embodiments, the predetermined hash function is less computationally intensive than typical blockchain hashing functions, which can reduce the computational burden on devices of the private local blockchain540in verifying the transaction ledger556.

The private local blockchain540includes a transaction processor560. The transaction processor560can execute the predetermined hash function on each transaction to generate each block. In some embodiments, the transaction processor560includes a special purpose processor used to perform cryptographic hashing and/or blockchain mining, such as a graphics processing unit (GPU). In some embodiments, the transaction processor560includes a network gateway. The transaction processor560may reduce the computational burden on other devices of the private local blockchain540, such as building components504, by executing a greater share of the hashing functionality performed by the private local blockchain540. At the same time, because the private local blockchain540is a distributed network, each building component504and/or network node552can verify the transaction ledger556as desired by arbitrarily executing the predetermined hash function on blocks of the transaction ledger556.

In some embodiments, a first building component504transmits, to a second building component504, a request to access data of the second building component504. The request can be generated as a network token. The second building component504can receive the request, and responsive to the request satisfying one or more data access rules, the second building component504can authorize the request by signing the network token. The first building component504and/or the second building component can transmit the network token to one or more network nodes552. The one or more network nodes552can evaluate the network token using the local rule engine548. Responsive to the network token satisfying the evaluation, the one or more network nodes552can authorize the first building component504to retrieve the requested data from the second building component504, and maintain the retrieval as a transaction in the transaction ledger556. The first building component504can transmit the requested data to additional building components504, which may be useful for equipment troubleshooting and home automation applications.

In some embodiments, the second building component504enforces the one or more data access rules to selectively provide access to the first building component504. For example, if the first building component504is a thermostat and the second building component504includes a temperature-based control point, the second building component504can compare a current temperature to one or more threshold temperatures, and permit the first building component504to control the temperature-based control point responsive to the current temperature satisfying the one or more thresholds.

Referring now toFIG. 6, the private local blockchain540can selectively communicate data with a public blockchain600. As depicted inFIG. 6, the transaction ledger556of the private local blockchain540maintains, for each block604, at least one unique identifier608. The at least one unique identifier608can include an identifier of each building component504or other device involved in the transaction represented by the block604. The at least one unique identifier608may include an identifier of a user of the private local blockchain (e.g., homeowner, facility manager). The at least one unique identifier608can include identifying characteristics such as a location of the building in which the building components504are located. While the transaction data represented in the block604may be useful for further processing, including aggregation across multiple facilities and building components504, the block604may not be able to be transmitted outside of the private local blockchain540without compromising the privacy of the data represented by the at least one unique identifier608.

The private local blockchain540can generate one or more network packets612representing a block616that include at least one public identifier620corresponding to the at least one unique identifier608, rather than the at least one unique identifier608itself. The private local blockchain540can generate the at least one public identifier620by converting the at least one unique identifier608to an anonymous value. The block616may include other transaction data, such as an action performed by the building components504involved in the transaction represented by the block604, that is not anonymized. In some embodiments, the private local blockchain540encrypts the one or more network packets612using a public key corresponding to a private key that the public blockchain600uses.

The public blockchain600includes a public transaction ledger624that receives the one or more network packets612and adds the block616to the public transaction ledger624. In some embodiments, the public blockchain600decrypts the one or more network packets612to retrieve the block616from the one or more network packets612. The public transaction ledger624can be similar to the transaction ledger556described with reference toFIG. 5. The public transaction ledger624can consolidate data from various building components504and private local blockchains540.

The public blockchain600includes a public rules engine628. The public rules engine628can be similar to the local rule engine548described with reference toFIG. 5, and can manage requests from devices outside of the private local blockchain540to perform transactions with building components504on the private local blockchain540. In some embodiments, the public rules engine628generates a special key that can be used by a device to connect to the private local blockchain540. The private local blockchain540can maintain records of transaction requests from the public blockchain600in the transaction ledger556.

Storage and Analytics Layers

In some embodiments, a storage layer632receives data from the public transaction ledger624. The storage layer632may convert the data from the public transaction ledger624from a blockchain-based data structure to a database structure. The storage layer632may obviate the need for a system to integrate multiple, disparate application programming interfaces (APIs) in order to perform computations on the data of the storage layer632.

In some embodiments, an analytics layer636executes computations based on data of the storage layer632(e.g., data received from the public transaction ledger624). The analytics layer636can generate models indicative of behavior of the building components504, and use the models to predict performance of each individual building component504. For example, the analytics layer636can use the data of the storage layer632to estimate a likelihood of failure of a particular building component504as a function of time, and generate a transaction request to perform a service/maintenance action on the particular building component504based on the estimated likelihood. The analytics layer636can predict energy usage by building components504.

Smart Contracts

Referring further toFIG. 5, the private local blockchain540can execute a plurality of smart contracts. Each smart contract can be a data structure including one or more inputs, one or more conditions, one or more states, and one or more outputs. The private local blockchain540can evaluate the one or more conditions based on the one or more inputs to set the state of the contract. Responsive to a state change, the smart contract can generate a corresponding contract.

For example, the private local blockchain540can use a smart contract to automate a warranty claim. The smart contract can receive sensor data associated with a particular building component504as an input. The smart contract can evaluate one or more conditions, such as whether the building component504is performing according to appropriate performances parameters, using the sensor data. Responsive to the building component504not performing according to the performance parameters, the smart contract can change to a warranty request state (e.g., a failure state), and generate a warranty request as an output. The smart contract can record the failure along with important data points that led up to, or occurred after the malfunction. In some embodiments, the smart contract maintains a service record and provides the service record with the warranty request. The private local blockchain540can maintain the warranty request as a transaction in the transaction ledger556.

By automating the smart contract process, the private local blockchain540can cause electronic funds transactions to occur with greater certainty. In existing building management systems, there may be administrative costs and/or electronic overhead associated with generating warranty and servicing requests. Existing solutions may address these issues by using a single trusted entity, but such solutions may still require manual intervention. The present solution uses smart contracts that are self-executing based on a set of instructions, conditions, and outcomes. This can be used to define the ways money is transferred, and actually facilitate the transfer when all conditions are met. The private local blockchain540enables trusted storage, and the smart contract enable distribution of various types of transactions based on trustworthy computations.

The present solution can enable improved proof of origin associated with supply chains for manufacturing and distribution of the building components504. For example, a supply chain blockchain similar to the private local blockchain540can use smart contracts to automate purchasing of components or materials, receiving and paying for components and materials, and track storage and use. As such, the supply chain blockchain can maintain a transparent supply chain record that can be verified to confirm appropriate sourcing and process life cycle. For example, there may be an effort to track the reduction of hazardous materials, and make sure raw materials are not being procured from conflict areas. However, delivery and compliance tracking of these components and raw materials are costly to facilitate. The supply chain blockchain can be used to generate a unique quality certificate for raw materials and components. The test results of the quality and/or lab tests can be executed based on established specifications loaded directly on the supply chain blockchain, with the certificates and test documents. The supply chain blockchain can maintain record of the results of the batches, reporting the values back in digital values, images, or both. The supply chain blockchain can use a smart contract to verify the test results are not used to verify another batch. The supply chain blockchain can release payment to the vendor responsive to the test results satisfying the smart contract.

Referring further toFIG. 5, the private local blockchain540can automate workflows amongst building components504while reducing a risk of compromise of the data security associated with the building components504by enabling trusted communications amongst the building components504via the private local blockchain540. For example, in a home implementation, an access control device (e.g., door lock) may detect an access request from an access device (e.g., keyfob). The access control device can unlock the door responsive to the access request satisfying one or more access control rules (e.g., a code provided by the access device is authenticated). The access control device can transmit a notification to other components that the door has been unlocked, such as a motion detector (which can verify the presence of the user, cause a lighting system to activate, and cause an HVAC system to adjust a temperature setpoint to a predetermined value). The access control device can automatically lock the door responsive to a period of time expiring subsequent to unlocking the door. The lighting system can automatically activate outdoor lights responsive to receiving an indication (e.g., from network nodes552) of a time corresponding to sundown occurring. Unlike in existing home automation systems, in which compromise of one of the building components504could enable an external agent to access various other building components504, such as to identify patterns of behavior of users of the building components504. Because the present solution validates each transaction (e.g., each data communication) on the private local blockchain540, the risk of unauthorized access and other data compromise can be reduced.

Referring now toFIG. 7, a process flow700of a smart contract is depicted. The process flow700can be executed using the DBS500and public blockchain600described with reference toFIGS. 5-6. Each action depicted inFIG. 7may be maintained as a block representing the action in a transaction ledger.

As depicted inFIG. 7, a building component704enters a failure state. For example, the building component704may be an HVAC component that fails to achieve a desired setpoint of a performance variable, such as temperature of fluid flow rate. A sensor may detect the failure state.

Responsive to receiving an indication of the building component704entering the failure state from the building component704and/or the sensor, a first smart contract708evaluates one or more service conditions associated with operation of the building component704. Based on the evaluation, the first smart contract708can determine to generate a service request712, and transmit the service request712to one or more second smart contracts716. Each second smart contract716may evaluate one or more service provision conditions based on the service request (e.g., determine if the service provider is obligated to fulfill the service request712). Responsive to determining the service request712to satisfying the service provision condition(s), the second smart contract716can indicate to a corresponding service provider720to dispatch service724, such as to repair the building component704.

The first smart contract708can monitor the state of the building component704, and detect that the building component704is fixed based on the monitoring of the state. The first smart contract708can evaluate one or more conditions associated with repairing of the building component704to determine whether to release payment728to the second smart contract716. For example, responsive to determining that the building component704is operating in a nominal state within a predetermined period of time of transmitting the service request712, the first smart contract704can authorize release of payment728.

Referring now toFIG. 8, a method800of operating a private local blockchain is depicted. The method800can be performed using various systems described herein, including the DBS500and public blockchain600described with reference toFIGS. 5-6.

At805, a device ledger of a private local blockchain maintains a data structure indicating a plurality of first building components of the private local blockchain. Each building component can include a smart device, such as a sensor, actuator, controller, HVAC component, and/or switch. Each building component can include a processing circuit and a communications circuit. The private local blockchain can execute on the plurality of first building components and/or a plurality of network nodes. The data structure can include a list of each first building component and a first unique identifier of each first building component.

At810, a transaction ledger of the private local blockchain maintains a plurality of blocks. Each block can correspond to a transaction between at least two first building components of the plurality of first building components. Each block can include the at least one first unique identifier of the corresponding first building component, data associated with the transaction (e.g., the data transmitted, the physical action performed, a type of the transaction), and a timestamp of the transaction.

At815, a transaction processor of the private local blockchain generates at least one block by executing a predetermined hash function using a previous block. The previous block may have been entered in the transaction ledger prior to the at least one block based on a timestamp of the previous block. In some embodiments, the transaction processor is specifically configured for hashing/blockchain mining operations, such as by including a specially designed processor (e.g., a GPU). In some embodiments, building components and/or network nodes can validate the transaction ledger by executing the predetermined hash function on the one or more blocks.

At820, a client device identifies at least one second unique identifier of a second building component. The client device may receive the at least one second unique identifier as a user input. The client device may use an image capture device to detect an image-based encoding of the at least one second unique identifier, such as a QR code.

At825, the client device provides the at least one second unique identifier to the private local blockchain. The client device may decode the image-based representation to provide the at least one second unique identifier. The client device may provide the image-based representation for the private local blockchain to decode.

At830, the private local blockchain determines to add the second building component to the device ledger using the at least one second unique identifier and the rules engine. For example, the private local blockchain can determine that the second building component is a trusted component.

In some embodiments, the method800includes providing an anonymized version of the block(s) of the transaction ledger to a public blockchain to be maintained by a public transaction ledger of the public blockchain. For example, the private local blockchain can generate one or more packets including an output block of the plurality of blocks of the transaction ledger, the output block including a public identifier corresponding to the at least one first unique identifier of the block from which the output block is generated. The private local blockchain can provide the one or more packets to the public blockchain. The public blockchain can add the output block to the public transaction ledger.

In some embodiments, the method800includes using an analytics layer to generate models representative of building component performance using the anonymized data of the public blockchain. The analytics layer can receive the blocks from the public blockchain, and extract data corresponding to the transactions represented by the blocks. The analytics layer can generate a predictive model representing behavior of building components based on the extracted data.

The method800can include using a plurality of network nodes, such as oracles, to provide external data to the private local blockchain. The private local blockchain can execute smart contracts by using the external data as an input that the smart contract uses to evaluate one or more conditions, and change a state of the smart contract based on the evaluation. The external data can include weather data, price data, and/or traffic data.