Hvac device registration in a distributed building management system

Abstract

A method for registering an HVAC device in a distributed building management system (BMS). The method includes requesting a token. The token is configured for authorizing registration of the HVAC device. The method further includes receiving the token at a registration service and receiving a unique ID associated with the HVAC device at the registration service. The method also includes registering the device into a file database of the registration service and generating a device shadow associated with the HVAC device. The method also includes storing the device shadow in the distributed BMS.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit and priority of U.S. Provisional Patent Application No. 62 / 316,468, filed March 31, 2016, the entire contents of which are incorporated herein by reference. Background Technology

[0003] This disclosure generally pertains to the field of building management systems. A building management system (BMS) is typically a system configured to control, monitor, and manage equipment in or around a building or building area. For example, a BMS may include HVAC systems, security systems, lighting systems, fire alarm systems, any other system capable of managing building functions or installations, or any combination thereof.

[0004] In some BMS (Browser Management System) environments, devices can be smart devices capable of communicating via internet connectivity. This can be referred to as BMS-based Internet of Things (IoT). In BMS-based IoT, devices can be added over time. However, adding a device requires registering it with the IoT environment. Because devices are connected to the internet, newly added devices should be registered and verified to ensure appropriate security precautions are taken. Furthermore, proper registration is necessary to ensure that the added device can be integrated into the IoT environment, allowing it to operate alongside other devices within the IoT environment. Attached Figure Description

[0005] Figure 1 This is an illustration of a building equipped with an HVAC system according to some embodiments.

[0006] Figure 2 According to some embodiments, it can be used as Figure 1 A block diagram of the water-side system, which is part of an HVAC system.

[0007] Figure 3 According to some embodiments, it can be used as Figure 1 A block diagram of the air-side system, which is part of an HVAC system.

[0008] Figure 4 This is a block diagram of a system of a Smart Connected HVAC Device and Monitoring and Service Provider Recommendation (MSPR) platform according to some embodiments, the MSPR platform utilizing data from smart connected HVAC devices to provide service provider recommendations.

[0009] Figure 5 This is a block diagram illustrating the MSPR platform, according to some embodiments, for direct communication with people, smart connected devices, buildings, and services.

[0010] Figure 6 is a block diagram illustrating a smart connected device in communication with a building infrastructure, a building owner, an MSPR platform, a device manufacturer, a facility manager, a contractor, and other connected devices / controllers, in accordance with some embodiments.

[0011] Figure 7 is a flow diagram illustrating a plurality of stages for implementing an MSPR platform including connected devices, connected buildings, and connected businesses, in accordance with some embodiments.

[0012] Figure 8 is a block diagram illustrating a traditional customer relationship in the HVAC industry, in accordance with some embodiments.

[0013] Figure 9 is a block diagram illustrating a manufacturer-centric customer relationship that can be implemented through an MSPR platform, in accordance with some embodiments.

[0014] Figure 10 is a block diagram illustrating a process for providing a contractor with a temporary access credential for accessing a smart connected device in order to obtain data from the device and perform remote diagnostics, in accordance with some embodiments.

[0015] Figure 11 is a block diagram illustrating components of an ecosystem in which an MSPR platform can be implemented, in accordance with some embodiments.

[0016] Figure 12 is a block diagram illustrating a device-to-cloud connection layout, in accordance with some embodiments.

[0017] Figure 13 is a block diagram illustrating a complex event processing map, in accordance with some embodiments.

[0018] Figure 14 is a block diagram of a data platform, in accordance with some embodiments.

[0019] Figure 15 is an entity graph illustrating relationships between organizations, spaces, systems, points, time series, and data sources, in accordance with some embodiments.

[0020] Figure 16 is a flow diagram illustrating a device registration process, in accordance with some embodiments.

[0021] Figure 17 is a flow diagram illustrating data flow associated with a device registration process, in accordance with some embodiments.

[0022] Figure 18 is a block diagram illustrating a distributed BMS device, in accordance with some embodiments. SUMMARY

[0023] One embodiment of the present disclosure is a method for registering an HVAC device in a distributed building management system (BMS). The method includes requesting a token. The token is configured for authorizing registration of the HVAC device. The method further includes receiving the token at a registration service and receiving a unique ID associated with the HVAC device at the registration service. The method also includes registering the device into a file database of the registration service and generating a device shadow associated with the HVAC device. The method also includes storing the device shadow in a memory of the distributed BMS.

[0024] Another embodiment of the present disclosure is a distributed building management system. The system includes an HVAC device and a distributed BMS device. The distributed BMS device includes a processor. The processor is configured for requesting a token, the token configured for authorizing registration of the HVAC device. The processor is further configured for receiving the token at a registration service and receiving a unique ID associated with the HVAC device. The processor is also configured for registering the device into a file database of the registration service and generating a device shadow associated with the HVAC device within a data platform of the distributed BMS.

[0025] Another embodiment of the present disclosure is a method for registering an Internet of Things (IoT) HVAC device in a distributed building management system. The method includes requesting a token, the token configured for authorizing registration of the IoT HVAC device. The method further includes receiving the token at a registration service and receiving a unique ID associated with the IoT HVAC device. The method further includes registering the device into a file database of the registration service and generating a device shadow associated with the IoT HVAC device within a data platform of the distributed BMS. The method further includes declaring the IoT HVAC device. Declaring the IoT HVAC device provides secure communication between the IoT HVAC device and the distributed building management system. DETAILED DESCRIPTION

[0026] SUMMARY

[0027] Advances in several technology spaces such as big data processing, machine learning, and network communications, as well as the rapid convergence of many technologies, have facilitated new possibilities for the "Internet of Things" (IoT). The IPv6 communications protocol has exponentially expanded the number of IP addresses available for devices to be connected to the Internet, and it also enables new capabilities around network security, network allocation and routing, transmission to multiple destinations, router simplification processing, and others. Advances in wireless communications and protocols can allow devices to be inexpensively and easily connected. New protocols such as MQTT and ZeroMQ provide lightweight data transfer between devices and networks. Big data capabilities around parallel storage and data processing allow the massive data deluge resulting from this unprecedented connection of devices and data to be processed in meaningful ways. The IoT can provide opportunities for creating new economic benefits and business models. An IoT framework can be used for a building management system (BMS) to allow for easier integration and control of smart devices to meet the demand for smart buildings and related connected systems.

[0028] Building with HVAC equipment

[0029] Referring now to Figure 1 A perspective view of a building 10 is shown. The building 10 includes an HVAC system 100. The HVAC system 100 can include a plurality of HVAC devices (e.g., heaters, chillers, air handling units, pumps, fans, thermal energy storage devices, etc.) configured to provide heating, cooling, ventilation, or other services for the building 10. For example, the HVAC system 100 is shown to include a waterside system 120 and an airside system 130. The waterside system 120 can provide heated or cooled fluid to air handling units of the airside system 130. The airside system 130 can use the heated or cooled fluid to heat or cool airflow provided to the building 10. Referring to Figure 2 and Figure 3 Example waterside and airside systems that can be used in the HVAC system 100 are described in more detail.

[0030] The HVAC system 100 is shown to include a chiller 102, a boiler 104, and a rooftop air handling unit (AHU) 106. The waterside system 120 can use the boiler 104 and the chiller 102 to heat or cool a working fluid (e.g., water, glycol, etc.) and can circulate the working fluid to the AHU 106. In embodiments, HVAC devices of the waterside system 120 can be located within or around the building 10 (as shown) or in other locations (e.g., in a central plant, etc.). The airside system 130 can include one or more AHUs 106, which can be located within or around the building 10 (as shown) or in other locations (e.g., in a central plant, etc.). The AHUs 106 can be configured to heat or cool airflow provided to the building 10. The AHUs 106 can be connected to the waterside system 120 to receive heated or cooled working fluid from the waterside system 120. The AHUs 106 can be connected to the airside system 130 to provide heated or cooled airflow to the airside system 130. Figure 1The working fluid can be heated in a boiler 104 (as shown in FIG. 1) or cooled in a chiller 102 (as shown in FIG. 2) located at an on-site location (e.g., at the building 10) or at an off-site location (e.g., at a central facility, such as a chiller plant, a steam plant, a heating plant, etc.). The working fluid can be heated in the boiler 104 or cooled in the chiller 102 depending on whether heating or cooling is required in the building 10. The boiler 104 can add heat to the circulating fluid, for example, by burning a combustible material (e.g., natural gas) or using electric heating elements. The chiller 102 can place the circulating fluid in heat exchange relationship with another fluid (e.g., a refrigerant) in a heat exchanger (e.g., an evaporator) to absorb heat from the circulating fluid. The working fluid from the chiller 102 and / or the boiler 104 can be delivered to the AHU 106 via a conduit 108.

[0031] The AHU 106 can place the working fluid in heat exchange relationship with an air stream passing through the AHU 106 (e.g., via one or more stages of cooling coils and / or heating coils). The air stream can be, for example, outdoor air, return air from within the building 10, or a combination of both. The AHU 106 can transfer heat between the air stream and the working fluid, thereby providing heating or cooling to the air stream. For example, the AHU 106 can include one or more fans or blowers configured to pass or draw the air stream through a heat exchanger containing the working fluid. The working fluid can then be returned to the chiller 102 or the boiler 104 via a conduit 110.

[0032] The air-side system 130 can deliver the air stream supplied by the AHU 106 (i.e., the supply air stream) to the building 10 via a supply air duct 112 and can provide return air from the building 10 to the AHU 106 via a return air duct 114. In some embodiments, the air-side system 130 includes a plurality of variable air volume (VAV) units 116. For example, the air-side system 130 is shown as including a separate VAV unit 116 on each floor or zone of the building 10. The VAV units 116 can include dampers or other flow control elements that can be operated to control the supply air flow provided to individual zones of the building 10. In other embodiments, the air-side system 130 delivers the supply air stream to one or more zones of the building 10 (e.g., via the supply duct 112) without using intermediate VAV units 116 or other flow control elements. The AHU 106 can include various sensors (e.g., temperature sensors, pressure sensors, etc.) configured to measure properties of the supply air stream. The AHU 106 can receive inputs from sensors located within the AHU 106 and / or within the building zones and can adjust the flow rate, temperature, or other properties of the supply air stream passing through the AHU 106 to achieve a setpoint condition for the building zones.

[0033] Referring now to Figure 2According to exemplary embodiments, a block diagram of a waterside system 200 is shown. In various embodiments, waterside system 200 can supplement or replace waterside system 120 in HVAC system 100, or can be implemented separately from HVAC system 100. When implemented in HVAC system 100, waterside system 200 can include a subset of the HVAC devices in HVAC system 100 (e.g., boiler 104, chiller 102, pumps, valves, etc.) and can operate to provide heated or cooled fluid to AHU 106. The HVAC devices of waterside system 200 can be located within building 10 (e.g., as components of waterside system 120) or at an off-site location, such as a central facility.

[0034] In Figure 2 waterside system 200 is shown as a central facility having multiple subfacilities 202-212. Subfacilities 202-212 are shown as including a heater subfacility 202, a heat recovery chiller subfacility 204, a chiller subfacility 206, a cooling tower subfacility 208, a hot thermal energy storage (TES) subfacility 210, and a cold thermal energy storage (TES) subfacility 212. Subfacilities 202-212 consume resources (e.g., water, natural gas, electricity, etc.) from a utility to service thermal energy loads (e.g., hot water, cold water, heating, cooling, etc.) for a building or campus. For example, heater subfacility 202 can be configured to heat water in a hot water loop 214 that circulates hot water between heater subfacility 202 and building 10. For example, chiller subfacility 206 can be configured to cool water in a cold water loop 216 that circulates cold water between chiller subfacility 206 and building 10. Heat recovery chiller subfacility 204 can be configured to transfer heat from cold water loop 216 to hot water loop 214 to provide additional heating of hot water and additional cooling of cold water. A condenser water loop 218 can absorb heat from cold water in chiller subfacility 206 and reject the absorbed heat in cooling tower subfacility 208 or transfer the absorbed heat to hot water loop 214. Hot TES subfacility 210 and cold TES subfacility 212 can store hot and cold thermal energy, respectively, for later use.

[0035] The hot water circuit 214 and the cold water circuit 216 can deliver heated and / or cooled water to air handlers (e.g., AHUs 106) located on the roof of the building 10 or to individual floors or zones of the building 10 (e.g., VAV units 116). The air handlers push air over heat exchangers (e.g., heating coils or cooling coils) through which water flows to provide heating or cooling of the air. The heated or cooled air can be delivered to individual zones of the building 10 to service thermal energy loads of the building 10. The water then returns to the subfacilities 202-212 to receive further heating or cooling.

[0036] Although the subfacilities 202-212 are shown and described as heating and cooling water for circulation to the building loop, it should be 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 service thermal energy loads. In other embodiments, the subfacilities 202-212 can provide heating and / or cooling directly to the building or campus without the need for an intermediate heat transfer fluid. These and other variations to the water-side system 200 are within the teachings of the present disclosure.

[0037] Each of the subfacilities 202-212 can include various equipment configured to facilitate the function of the subfacility. For example, the heater subfacility 202 is shown as including a plurality of heating elements 220 (e.g., boilers, electric heaters, etc.) configured to add heat to hot water in the hot water circuit 214. The heater subfacility 202 is also shown as including a number of pumps 222 and 224 configured to circulate the hot water in the hot water circuit 214 and control the flow rate of the hot water through the individual heating elements 220. The chiller subfacility 206 is shown as including a plurality of chillers 232 configured to remove heat from cold water in the cold water circuit 216. The chiller subfacility 206 is also shown as including a number of pumps 234 and 236 configured to circulate the cold water in the cold water circuit 216 and control the flow rate of the cold water through the individual chillers 232.

[0038] The heat recovery chiller sub-facility 204 is shown to include a plurality of heat recovery heat exchangers 226 (e.g., refrigerant circuits) configured to transfer heat from the chilled water loop 216 to the heated water loop 214. The heat recovery chiller sub-facility 204 is also shown to include a number of pumps 228 and 230 configured to circulate the heated and / or chilled water through the heat recovery heat exchangers 226 and control the flow rate of the water through the individual heat recovery heat exchangers 226. The cooling tower sub-facility 208 is shown to include a plurality of cooling towers 238 configured to remove heat from the condenser water in the condenser water loop 218. The cooling tower sub-facility 208 is also shown to include a number of pumps 240 configured to circulate the condenser water in the condenser water loop 218 and control the flow rate of the condenser water through the individual cooling towers 238.

[0039] The heated TES sub-facility 210 is shown to include a heated TES tank 242 configured to store heated water for later use. The heated TES sub-facility 210 can also include one or more pumps or valves configured to control the flow rate of the heated water into or out of the heated TES tank 242. The cooled TES sub-facility 212 is shown to include a cooled TES tank 244 configured to store cooled water for later use. The cooled TES sub-facility 212 can also include one or more pumps or valves configured to control the flow rate of the cooled water into or out of the cooled TES tank 244.

[0040] In some embodiments, one or more pumps in the waterside system 200 (e.g., pumps 222, 224, 228, 230, 234, 236, and / or 240) or the lines in the waterside system 200 include an isolation valve associated therewith. The isolation valve can be integrated with the pump or positioned upstream or downstream of the pump to control fluid flow in the waterside system 200. In embodiments, the waterside system 200 can include more, fewer, or different types of devices and / or sub-facilities based on the particular configuration of the waterside system 200 and the type of loads served by the waterside system 200.

[0041] Referring now to Figure 3 , a block diagram of an airside system 300 is shown, in accordance with example embodiments. In embodiments, the airside system 300 can supplement or replace the airside system 130 in the HVAC system 100 or can be implemented separately from the HVAC system 100. When implemented in the HVAC system 100, the airside system 300 can include a subset of the HVAC devices in the HVAC system 100 (e.g., the AHU 106, the VAV units 116, the ducts 112-114, fans, dampers, etc.) and can be located in or around the building 10. The airside system 300 can operate to heat or cool the airflow provided to the building 10 using the heated or cooled fluid provided by the waterside system 200.

[0042] In Figure 3 In some embodiments, air-side system 300 is shown as including an economizer-type air handling unit (AHU) 302. Economizer-type AHUs vary the amount of outside air and return air used by the air handling unit for heating or cooling. For example, AHU 302 can receive return air 304 from building zone 306 via return air duct 308 and can deliver supply air 310 to building zone 306 via supply air duct 312. In some embodiments, AHU 302 is a rooftop unit located on the roof of building 10 (e.g., AHU 106 shown in Figure 1 In some embodiments, AHU 302 is a rooftop unit located on the roof of building 10 (e.g., AHU 106 shown in

[0043] Each of dampers 316-320 can be operated by an actuator. For example, exhaust damper 316 can be operated by actuator 324, mixed air damper 318 can be operated by actuator 326, and outside air damper 320 can be operated by actuator 328. Actuators 324-328 can communicate with AHU controller 330 via communication link 332. Actuators 324-328 can receive control signals from AHU controller 330 and can provide feedback signals to AHU controller 330. Feedback signals can include, for example, an indication of the current actuator or damper position, an amount of torque or force exerted by the actuator, diagnostic information (e.g., results of diagnostic tests performed by actuators 324-328), status information, commissioning information, configuration settings, calibration data, and / or other types of information or data that can be collected, stored, or used by actuators 324-328. AHU controller 330 can be an economizer controller configured to control actuators 324-328 using one or more control algorithms (e.g., a state-based algorithm, an extremum seeking control (ESC) algorithm, a proportional-integral (PI) control algorithm, a proportional-integral-derivative (PID) control algorithm, a model predictive control (MPC) algorithm, a feedback control algorithm, etc.).

[0044] Still referring to Figure 3AHU 302 is shown to include a cooling coil 334, a heating coil 336, and a fan 338 located within the supply air duct 312. The fan 338 can be configured to push the supply air 310 through the cooling coil 334 and / or the heating coil 336 and provide the supply air 310 to the building zone 306. The AHU controller 330 can communicate with the fan 338 via a communication link 340 to control a flow rate of the supply air 310. In some embodiments, the AHU controller 330 controls an amount of heating or cooling applied to the supply air 310 by adjusting a speed of the fan 338.

[0045] The cooling coil 334 can receive cooled fluid from the waterside system 200 (e.g., from the chilled water loop 216) via a line 342 and can return the cooled fluid to the waterside system 200 via a line 344. A valve 346 can be positioned along the line 342 or the line 344 to control a flow rate of the cooled fluid through the cooling coil 334. In some embodiments, the cooling coil 334 includes multiple stages of cooling coils that can be independently activated and deactivated (e.g., by the AHU controller 330) to adjust an amount of cooling applied to the supply air 310.

[0046] The heating coil 336 can receive heated fluid from the waterside system 200 (e.g., from the hot water loop 214) via a line 348 and can return the heated fluid to the waterside system 200 via a line 350. A valve 352 can be positioned along the line 348 or the line 350 to control a flow rate of the heated fluid through the heating coil 336. In some embodiments, the heating coil 336 includes multiple stages of heating coils that can be independently activated and deactivated (e.g., by the AHU controller 330) to adjust an amount of heating applied to the supply air 310.

[0047] Each of the valves 346 and 352 can be controlled by an actuator. For example, the valve 346 can be controlled by an actuator 354, and the valve 352 can be controlled by an actuator 356. The actuators 354-356 can communicate with the AHU controller 330 via communication links 358-360. The actuators 354-356 can receive control signals from the AHU controller 330 and can provide feedback signals to the controller 330. In some embodiments, the AHU controller 330 receives measurements of a supply air temperature from a temperature sensor 362 positioned in the supply air duct 312 (e.g., downstream of the cooling coil 334 and / or the heating coil 336). The AHU controller 330 can also receive temperature measurements of the building zone 306 from a temperature sensor 364 located in the building zone 306.

[0048] In some embodiments, the AHU controller 330 operates the valves 346 and 352 via actuators 354-356 to adjust the amount of heating or cooling provided to the supply air 310 (e.g., to reach a setpoint temperature of the supply air 310 or to maintain the temperature of the supply air 310 within a setpoint temperature range). The position of the valves 346 and 352 affects the amount of heating or cooling provided to the supply air 310 by the cooling coil 334 or the heating coil 336 and can be related to the amount of energy consumed to reach the desired supply air temperature. The AHU controller 330 can control the temperature of the supply air 310 and / or the building zone 306 by activating or deactivating the coils 334-336, adjusting the speed of the fan 338, or a combination of both.

[0049] Intelligently networked HVAC equipment

[0050] Referring now to Figure 4 According to exemplary embodiments, a system 400 is shown that includes a monitoring and service provider recommendation (MSPR) platform 402, a network 404, a gateway 406, and a plurality of intelligently networked HVAC equipment 408. The intelligently networked HVAC equipment 408 can include actuators 410, dampers 412, chillers 414, heaters 416, rooftop units (RTUs) 418, air handling units (AHUs) 420, and / or any other type of equipment or device that can be installed within a building 10 (e.g., fans, pumps, valves, etc.). Although the present disclosure is primarily described with reference to HVAC equipment, it should be understood that the systems and methods described herein can be applied to a wide variety of building equipment and other types of networked devices with embedded intelligence and communication capabilities (e.g., HVAC equipment, LED lights, mobile phones, elevators, fire safety systems, smart street lights, automobiles, televisions, etc.).

[0051] The intelligently networked HVAC equipment 408 can be configured for communication with each other and with remote services (e.g., remote monitoring and analytics services, cloud-based control services, etc.). In some embodiments, the intelligently networked HVAC equipment 408 has a presence everywhere connection (i.e., always-on connection) and has its own processing power and analytics capabilities. The intelligently networked HVAC equipment 408 can be managed in the cloud through various software applications and analytics models built to control the software applications. As such, a field / supervisory controller or building automation system can not be needed. For example, a smart actuator with built-in position feedback, computing power, and a communication network can provide a cost-effective solution that can make local decisions. A series of smart actuators and dampers working together can provide fully autonomous manipulation of a building and / or BMS.

[0052] The smartly networked HVAC devices 408 can use any of a variety of communication protocols to communicate with one another. In some embodiments, the smartly networked HVAC devices 408 communicate wirelessly with one another using a wireless communication protocol (e.g., Wi-Fi, Bluetooth, 3G / 4G, 802.15.4, ZigBee, etc.). The particular communication protocol used by the smartly networked HVAC devices 408 can depend on the power requirements, bandwidth requirements, and / or existing infrastructure within the building in which the smartly networked HVAC devices 408 are installed. In some embodiments, the smartly networked HVAC devices 408 communicate with one another using a proprietary building equipment protocol (e.g., BACNet, ZigBee, Modbus, etc.) to move data between the various devices of the smartly networked HVAC devices 408. To build applications on top of these protocols, these protocols can be translated into an Internet Protocol (IP). In some embodiments, the communication gateway 406 is used for this translation.

[0053] In some embodiments, only a few of the smartly networked HVAC devices 408 communicate with the external network 404 (e.g., a cellular network, a WAN, the Internet, etc.). However, in other embodiments, a majority (e.g., more than 75%) of the smartly networked HVAC devices 408 can communicate with the external network 404. Data can be exchanged between the smartly networked HVAC devices 408 and then transmitted to the external network 404 by a subset of the smartly networked HVAC devices 408. The types of data transmitted by the smartly networked HVAC devices 408 can include, for example, measurements recorded by sensors integrated with the smartly networked HVAC devices 408, device status information, diagnostic information, configuration information, device identity information, software versions, hardware versions, or any other information related to the smartly networked HVAC devices 408 or their operation. To enable the data to be consumed by various software applications, a context protocol (e.g., RESTful API, CoAP, HTTP, AMQP, MQTT) can be used to provide context information about the data. APIs can be used to share data with the outside world using clear abstract concepts.

[0054] Still referring to Figure 4The system 400 is shown to include a communication gateway 406 and a network 404. The gateway 406 can be used to connect legacy devices and new devices (e.g., temperature sensors, actuators, cooling or heating devices, industrial robots, personal health monitoring devices, etc.) to obtain data from these devices and, in return, control these devices based on instructions or analysis results from a remote service. The gateway 406 can provide network security, access control, and unique addresses for legacy device endpoints for remote access and protocol mediation services. In some embodiments, the gateway 406 is a general gateway solution made by any one of various hardware manufacturers (e.g., Intel, FreeScale, Dell, Texas Instrument, etc.). In other embodiments, the gateway 406 is a network control engine (NCE) mobile access portal (MAP) gateway that is specifically designed for connecting building automation systems and smart devices. The gateway 406 can use various internet-based protocols (e.g., CoAP, XMPP, AMQP, MQTT, etc.) and web-based public data exchange (e.g., HTTP RESTful API) to convert communications from building automation system protocols to internet protocols.

[0055] The network 404 can include the internet and / or other types of data networks, such as a local area network (LAN), a wide area network (WAN), a cellular network, a satellite network, a radio network, or any other type of data network or combination thereof. The network 404 can include any number of computing devices (e.g., computers, servers, routers, network switches, etc.) configured for transmitting, receiving, or relaying data. The network 404 can further include any number of hardwired and / or wireless connections. For example, the smartly networked HVAC device 408 can communicate wirelessly (e.g., using Wi-Fi, Bluetooth®, or cellular radios, etc.) with a transceiver of a computing device of the network 404 that is hardwired (e.g., via fiber optic cable, CAT5 cable, etc.) to the network 404.

[0056] The network 404 can include services that facilitate managing fixed or wireless communications with the smartly networked HVAC device 408. Network providers can include, for example, cellular telecommunication providers (e.g., Verizon, T-Mobile, AT&T, etc.) as well as internet service providers. Communications via the network 404 can leverage enterprise contracts and partnerships to optimize the cost of data transmission. Many network carriers provide secure connection options as part of premium services. However, a similar degree of network security can be achieved by employing a trusted platform chip in the smartly networked HVAC device 408 and using encrypted messaging, such as AMQP, via internet-based secure transport.

[0057] Still referring to Figure 4, the system 400 is shown to include a monitoring and service provider recommendation (MSPR) platform 402. The MSPR platform 402 can operate as a remote system that receives and processes data provided by the smartly networked HVAC equipment 408 from many different buildings. The MSPR platform 402 can utilize the data provided by the smartly networked HVAC equipment 408 to provide various services. The services provided by the MSPR platform 402 can include, for example, device management, data routing and real-time analytics, data management services, and bulk analytics. Additionally, the MSPR platform 402 can include a monitoring and reporting application, a networked chiller application, a fault detection and diagnostics (FDD) application, data analytics, and automatic service provider recommendations. For example, a networked chiller (i.e., a type of smartly networked HVAC equipment 408) can communicate with the MSPR platform 402. The networked chiller application can integrate industry-leading remote monitoring and analytics tools with scheduled service agreements and warranties. This allows the MSPR platform 402 to provide enhanced responsiveness and expertise to one of the most critical pieces of equipment in a facility.

[0058] Referring now to Figure 5 , the MSPR platform 402 is shown to be a central system that connects smartly networked devices 504 (e.g., HVAC equipment and / or any other devices, the smartly networked HVAC equipment 408), buildings 506, people 502, and businesses 508. For example, the smartly networked devices 504 can provide their current status, analysis results, fault detections, measurements, identity information, device models representing the smartly networked devices 504, and / or other information associated with the smartly networked devices 504 to the MSPR platform 402. The MSPR platform 402 can perform analysis on the data provided by the smartly networked devices 504. The analysis can be used to facilitate various services provided by the MSPR platform 402. For example, the MSPR platform 402 can build statistical models that use data from the smartly networked devices 504 to infer patterns, perform comparisons, perform trend analysis and predictions, or even teach the smartly networked devices 504 to self-correct (e.g., by providing the smartly networked devices 504 with adjusted operating parameters).

[0059] The MSPR platform 402 can use data from the smart connected devices 504 to determine how the smart connected devices 504 are being used, broaden the value proposition beyond the physical device, include valuable data and value-added services, and form closer relationships with customers. The MSPR platform 402 can create usage reports for sales, marketing, and product development to improve quality and create better pricing and product positioning. The MSPR platform 402 can provide usage reports to various people 502 (e.g., building owners, facility managers, etc.) to provide insights on how the smart connected devices 504 are being used. In some embodiments, the MSPR platform 402 leverages external data (e.g., weather data, utility data, meter data, building occupancy, etc.) to augment data from the smart connected devices 504 to provide additional information to make better decisions.

[0060] Benefits provided by the MSPR platform 402 include increased uptime of the smart connected HVAC equipment 408, reduced future repair costs, extended asset life, use of service experts with operational and trending data to assist in troubleshooting, and higher service updates. The MSPR platform 402 can be configured to implement condition-based maintenance procedures to shorten repair time via remote diagnostics and optimized logistics when parts are ordered and tools are rented. Possible outcomes of the services provided by the MSPR platform 402 include reduced number of unscheduled repairs, optimized daily maintenance intervals, and reduced daily maintenance.

[0061] Referring now to Figure 6 The smart connected devices 602 can be connected to the building infrastructure 606, the owner 608, the MSPR platform 402, the manufacturer 610, the facility manager 612, the contractor 614, and / or other smart connected devices and controllers 604. The smart connected devices 602 can transmit their current status, analytics results, fault detection, measurements, their identity, device models representing the smart connected devices 602, and / or other information to the various entities to which the smart connected devices 602 are connected. For example, a smart connected roof can interact directly with the owner 608, the occupants, the OEM, and the contractor. A roof failure or fault symptom can be sent to the MSPR platform 402 to coordinate a replacement or initiate a maintenance project. The MSPR platform 402 can send an alert to the building owner 608, as well as a list of local service providers. As a result, certified contractors 614 that subscribe to the MSPR platform 402 can have a higher chance of winning service contracts. The service provider referral feature of the MSPR platform 402 will be described in more detail below.

[0062] Automated monitoring and diagnostics to improve products and services

[0063] The MSPR platform 402 can use the data provided by the smart connected HVAC equipment 408 to develop improved products and / or services. Developing improved products and services can include improving existing products and services as well as developing new products and services. For example, the MSPR platform 402 can determine how to improve the operation of the smart connected HVAC equipment 408 (e.g., optimize energy consumption in a building, maintain uptime of the equipment, etc.). The MSPR platform 402 can use remote diagnostics and repair to reduce downtime and unscheduled maintenance. In some embodiments, the MSPR platform 402 creates a continuous feedback loop of how customers use the smart connected HVAC equipment 408 in order to inform design, engineering, and manufacturing decisions to make the equipment better. The MSPR platform 402 can also send automatic software updates to the smart connected HVAC equipment 408 to add features and improve the performance of the equipment without any physical intervention.

[0064] In some embodiments, the MSPR platform 402 uses the data provided by the smart connected HVAC equipment 408 to help customers operate the equipment better and enable service technicians to service the equipment better. The connectivity provided by the smart connected HVAC equipment 408 allows the MSPR platform 402 to monitor critical alerts of the equipment and notify service technicians if any issues arise. As the amount of data collected increases, the analytical models used by the MSPR platform 402 continue to learn and improve over time. The analytical models can use information from the smart connected HVAC equipment 408 to identify opportunities for creating new physical products or even new information products. For example, the MSPR platform 402 can identify opportunities to combine the functionality of two or more existing products (e.g., a camera inside an LED light bulb) to develop a new and improved product. The new and improved product can include, for example, a sensor or controller that can perform diagnostics and self-troubleshooting and / or other types of functionality that can eliminate the need for other products.

[0065] Advantageously, the connectivity provided by the smart connected HVAC equipment 408 can facilitate ubiquitous connectivity of various types of equipment within a building. The machine learning provided by the MSPR platform 402 can use the information provided by the smart connected HVAC equipment 408 to develop a comprehensive view of control in a building environment. In some embodiments, the MSPR platform 402 provides building operators with a visually clear and intuitive view of building operations as well as the ability to solve problems in real-time. As more information is collected about how a building works and under what environmental and parametric conditions it works, people outside of the manufacturing and construction industries can use this information to improve products and services that impact buildings.

[0066] The MSPR platform 402 can allow HVAC equipment 408 and related service providers to sell more of their products and services. For example, the MSPR platform 402 can generate usage information that can be used to better understand the life cycle and usage of the HVAC equipment 408. This information can also enable service providers to proactively sell more services. For example, the MSPR platform 402 can use life cycle information for a particular type of HVAC equipment 408 to determine when the HVAC equipment 408 is expected to need maintenance or replacement. The MSPR platform 402 can then recommend preventative maintenance and / or replacement before a failure occurs. Such information can also allow equipment providers to optimize sales channels to sell more equipment and parts.

[0067] The MSPR platform 402 can reduce service operation costs and increase efficiency. For example, the advanced diagnostic capabilities and remote monitoring capabilities provided by the MSPR platform 402 can reduce the time required for service technicians to resolve issues. This can reduce the time spent performing service calls and can increase productivity.

[0068] The MSPR platform 402 can enhance the value of installed equipment. For example, the MSPR platform 402 can analyze usage information from the smart connected HVAC equipment 408 to provide insights to customers and optimize the performance of the HVAC equipment 408. Building owners or operators can interact with the MSPR platform 402 (e.g., via a monitoring and control interface) to obtain current status information, control parameters, diagnostic information, and other types of information related to installed equipment (e.g., equipment manuals, warranty information, etc.). The control functionality provided by the MSPR platform 402 can make control seamless and transparent to building owners and operators.

[0069] The MSPR platform 402 can create more value for customers with minimal physical contact with the smart connected HVAC equipment 408. For example, the MSPR platform 402 can automatically send updates to the smart connected HVAC equipment 408 to enhance features and fix bugs. The analysis provided by the MSPR platform 402 can provide customers with information (e.g., via an interface of a mobile device) to act on potential failures in their equipment or buildings.

[0070] The MSPR platform 402 can allow equipment / service providers to increase their customer base with better differentiated products and services. For example, the MSPR platform 402 can recommend particular types of equipment and / or services that will provide value to customers based on usage information collected from the customers' equipment. Additionally, the MSPR platform 402 as a whole can be offered as a service to new customers and existing customers.

[0071] The MSPR platform 402 can create new business models and opportunities. For example, the MSPR platform 402 can allow contractors to increase the number and margins of service contracts. Usage information from the smart connected HVAC equipment 408 can also be provided to insurance providers. The insurance providers can use the usage information to determine the appropriate risk level of a building, which allows the insurance providers to set more accurate insurance premiums. The proactive repair and replacement recommendations provided by the MSPR platform 402 can reduce the number of failures (e.g., by repairing or replacing equipment before a failure occurs), which reduces insurance claims and improves the margins of insurance contracts.

[0072] Referring now to Figure 7 According to example embodiments, a process 700 for implementing the MSPR platform 402 is shown. The process 700 is shown as including three stages: connected equipment 702, connected buildings 704, and connected businesses 706. Each of these stages can be implemented through changes to sensors, data collection, and business models. Changes to sensors can include changes made to physical devices and equipment. Each device or manufactured part becomes a sensor of the environment it is actuating. Changes to data collection can include changes made to the system collection, management, and analysis of data collected from sensors (i.e., the smart connected HVAC equipment 408). Changes to business models can include changes that can be made to monetize the features provided by the MSPR platform 402.

[0073] In the connected equipment stage 702, ubiquitous connectivity of the smart connected HVAC equipment 408 can be provided in a building. The MSPR platform 402 can use data analytics to analyze the information provided by the smart connected HVAC equipment 408. Such data analytics can include, for example, modeling, mapping, and extrapolating the information provided by the smart connected HVAC equipment 408. Data analytics can further include real-time data analytics and machine learning.

[0074] Changes to the business model can include improving existing businesses (e.g., making them more efficient) and improving existing products. The MSPR platform 402 can provide data analytics products as a service (e.g., through monthly billing) to allow building operators to obtain a clear and holistic view of data associated with their buildings from mobile devices. Service technicians can also have access to a clear and holistic view of data associated with a building in order to easily and more efficiently diagnose and repair problems. Existing products can be provided as a service rather than product ownership. For example, a building owner or operator can subscribe to the MSPR platform 402 (e.g., pay a subscription fee monthly), which provides access to information provided by the MSPR platform 402, including alerts when recommended services and / or repairs. Usage data from the smart connected HVAC equipment 408 can be used to reactively improve manufacturing by detecting and addressing problems with equipment parts.

[0075] In the connected building stage 704, information from the smart connected HVAC equipment 408 can be aggregated across buildings to improve the capabilities and efficiency of the smart connected HVAC equipment 408 (e.g., to improve autonomous control decisions made by the HVAC equipment 408). The MSPR platform 402 can develop richer and more flexible models to integrate data from different buildings (e.g., richer scenarios). The MSPR platform 402 can also develop richer analytical models (e.g., graphical and probabilistic models) to handle data heterogeneity and increased complexity of modeling across buildings (e.g., using other data to increase context, such as local / national laws and environment / weather related operational considerations).

[0076] Changes to the business model can include expanding services from the connected equipment stage 702. Predictive analytics can be used to predict future electricity bills for a building based on historical data from other buildings in the area. Manufacturers, distributors, or service providers can use information provided by the MSPR platform 402 to guarantee uptime (e.g., 95% uptime) or indoor temperature for equipment. The MSPR platform 402 can monetize such information by charging a service fee on a monthly / yearly basis or by saving a certain percentage of costs.

[0077] Changes to the business model can further include changing customer relationships and value chains. For example, customer relationships can change from one-time purchase and service to more of a continuous consultative sales relationship, increasing the lifetime value of customers. The MSPR platform 402 can establish a direct relationship with customers (e.g., building owners) by providing customers with access to monitoring information generated by the MSPR platform 402 and service provider recommendations.

[0078] In the connected commercial phase 706, the smart connected HVAC equipment 408 can be augmented with its own computing power and control capabilities. New features can be added to the data analysis, monitoring, reporting, and service provider recommendations generated by the MSPR platform 402.

[0079] Changes to the business model can use data as a form of currency. For example, data collected from the smart connected HVAC equipment 408 can be monetized in HVAC related products, services, and markets (e.g., by selling more equipment, service, etc.) as well as in other industries. The MSPR platform 402 can aggregate relevant data and models across components, equipment, and people across multiple different buildings. Data can be segmented by different regions, building types, ages, sizes, and other factors. In some embodiments, the MSPR platform 402 provides data to insurance companies that can use the data to refine their actuarial models and create pricing based on real usage and occupancy behavior. The MSPR platform 402 can also provide data from water leak detection sensors integrated with some types of smart connected HVAC equipment 408 (e.g., connected rooftop units) to provide early warning of potential water damage to the insurance companies.

[0080] In some embodiments, the MSPR platform 402 provides data to public utilities that can use the data to understand the energy usage profile of buildings and help them better manage the power grid and infrastructure they need to build. In some embodiments, the MSPR platform 402 provides data to government agencies (e.g., cities, states, countries, etc.) that can use the data to better plan and allocate resources. In some embodiments, the MSPR platform 402 provides data to energy storage companies that can use the data to estimate the amount of energy generated by a building. The MSPR platform 402 can help building owners optimize equipment performance and connect them with contractors to address issues.

[0081] Manufacturer-centric customer relationships

[0082] Referring now to Figure 8, a block diagram 800 illustrating a traditional customer relationship in the HVAC industry is shown. In the traditional customer relationship, a device manufacturer 802 provides HVAC devices to a distributor 804. The distributor 804 receives purchase orders from contractors 806 (e.g., agents or service providers) and provides the HVAC devices to the contractors 806. The contractors 806 then install the HVAC devices in a building owned by an owner or end user 808. The manufacturer 802 only interacts with the distributor 804 and does not have contact with the building owner or end user 808 of the HVAC devices. Once the HVAC devices are installed, the owner or end user 808 only interacts with the contractors 806 if the HVAC devices need service or replacement.

[0083] Referring now to Figure 9 , a block diagram 900 illustrating a manufacturer-centric customer relationship that can be implemented by the MSPR platform 402 is shown. In the manufacturer-centric customer relationship, the manufacturer 802 uses the MSPR platform 402 to directly interact with the distributor 804, the contractors 806, and the building owner or end user 808. The smart connected HVAC devices 408 within the building of the owner or end user 808 communicate with the MSPR platform 402, which can be owned or operated by the manufacturer 802. For example, the smart connected HVAC devices 408 can transmit their current status, analytics results, fault detections, measurements, their identity, a device model representing the smart connected HVAC devices 408, software versions, hardware versions, and / or other information to the MSPR platform 402. The MSPR platform 402 can use the data from the smart connected HVAC devices 408 to automatically detect and diagnose faults and determine appropriate replacement or service actions for the smart connected HVAC devices 408. The MSPR platform 402 can send an alert to the building owner 808, as well as a list of local contractors 806 (e.g., service providers). The building owner 808 can then select one of the contractors 806 to service the HVAC devices.

[0084] The manufacturer-centric customer relationship represents a fundamental shift in how customer relationships are managed in the HVAC industry. This relationship change can result in a weaker dependency on the distributor 804 and the contractors 806. The manufacturer 802 now has the opportunity to capture more profit from the entire value chain. In addition, the manufacturer 802 can use the data received from the smart connected HVAC devices 408 to understand how to access and leverage its products and features.

[0085] The detected faults represent repair or replacement opportunities for the smart connected HVAC equipment 408, which become revenue for the contractor 806 and part of the sales opportunity for the distributor 804. The MSPR platform 402 can present these opportunities to both the contractor 806 and the distributor 804 to acquire business in near real-time. Given an informed fault (e.g., a fault accompanied by diagnostic information), the contractor 806 can prepare a service cost estimate based on service part availability and diagnostic results. The contractor 806 can submit a bid to the MSPR platform 402, which provides the bid along with bids from other contractors to the building owner 808. The building owner 808 can select the contractor 806 based on the bid information and service proposal. Once the contractor 806 is selected, the MSPR platform 402 can notify the selected contractor 806 that it has won the service contract.

[0086] Access to smart connected HVAC equipment

[0087] Referring now to Figure 10 According to exemplary embodiments, a block diagram 1000 is shown that illustrates the type of information provided between a smart connected device 1002, a building owner 1006, the MSPR platform 402, and a contractor 1004. When the smart connected device 1002 is installed, the building owner 1006 can register the smart connected device 1002 with the MSPR platform 402. In some embodiments, the smart connected device 1002 is provided in such a way that only the building owner 1006 (and possibly the MSPR platform 402) can access the smart connected device 1002. The smart connected device 1002 sends device information (e.g., status, identity, diagnostic results, measurements, etc.) to the MSPR platform 402.

[0088] When a repair or replacement opportunity is identified by the MSPR platform 402, the MSPR platform 402 can provide a temporary access credential to the contractor 1004. The contractor 1004 can use the temporary access credential to access the smart connected device 1002 and obtain detailed status and diagnostic information from the smart connected device 1002. The temporary access credential can expire after a defined period of time or upon completion of a defined action (e.g., completion of service on the smart connected device 1002), which prevents the contractor 1004 from accessing the smart connected device 1002 after the service contract is completed.

[0089] Internet of Things framework

[0090] Referring now to Figure 11, according to exemplary embodiments, a block diagram is shown that illustrates components of an ecosystem 1100 in which the MSPR platform 402 can be implemented. The ecosystem 1100 is shown to include an Internet of Things (IoT) platform 1140, which can be the same as or similar to the MSPR platform 402 described previously. The ecosystem 1100 can allow the IoT platform 1140 to facilitate a self-aware building that includes smart connected devices and / or appliances (e.g., smart connected HVAC equipment 408, etc.). Many different types of partnerships can be used to facilitate the self-aware building. Examples of such partnerships include regional partnerships, global partnerships, channel partnerships, industry organizations, and technology partners. In Figure 11 each vertical column 1102-1118 represents a technology component that can be installed in a self-aware building, provided by the IoT platform 1140, or sourced or co-developed with a vendor or partner.

[0091] The IoT platform 1140 of the ecosystem 1100 can include a network of physical objects or "things" that are embedded with electronics, software, sensors, and / or network connectivity, enabling these objects to collect and exchange data. The IoT platform 1140 can facilitate a link between the physical and digital worlds by allowing remote sensing and control of devices across new and / or previously existing communication infrastructure. The IoT platform 1140 represents components and technologies that can provide end-to-end solutions for IoT-enabled products and services. The IoT platform 1140 can also include various processes and applications that can be further used to create and maintain the IoT ecosystem 1100.

[0092] The IoT platform 1140 is shown to include vertical columns (e.g., technology concepts) such as smart connected devices 1102, smart gateways 1104, network services 1106, device management 1108, data routing and real-time data analytics, data services platform 1112, analytics 1114, delivery 1116, and business / operations support 1118. Each of these technology components will be described in more detail below.

[0093] The smart connected devices 1102 can include one or more devices within the BMS, and in particular, "smart devices" such as the smart HVAC equipment 408 described above. As Figure 11As shown, the smart devices can include sensors 1120, actuators 1122, smart appliances 1124, smart buildings 1126, etc. According to one embodiment, the smart connected devices 1102 include any device that has communication capabilities, computing capabilities, and is able to make decisions at a local level (e.g., in a limited context, etc.). Communication with the smart connected devices 1102 can be through any wireless or wired communication protocol. Computing capabilities can be enabled through a microprocessor with an embedded operating system (e.g., Linux, Android, iOS, RTOS, Windows 10, etc.). Computing capabilities can be used locally to store data from the devices (e.g., temporarily, etc.) and / or perform predetermined operations (e.g., decision trees, etc.). The predetermined operations can include fault isolation detection, device diagnostics, and / or other operations. The smart devices can additionally have fault response capabilities to allow the smart devices to be able to adapt and respond to changing environmental and / or operating conditions (e.g., weather, load, etc.). In some embodiments, the ecosystem 1100 includes devices that are not smart connected devices 1102 but can connect to the IoT platform 1140 via a device acting as a proxy or on-site gateway to facilitate communication between non-smart devices and the IoT platform 1140 over public and / or private networks (e.g., using fully secure, defendable server platforms with high-capability hardware, etc.). Such connections are described more fully herein.

[0094] The smart connected devices 1102 can include actuators, dampers, chillers, heaters, rooftop units (RTUs), air handling units (AHUs), and / or any other type of equipment or device that can be installed within a building (e.g., fans, pumps, valves, etc.). Although the present disclosure is described primarily with reference to HVAC equipment, it should be understood that the systems and methods described herein can be applied to a wide variety of building equipment and other types of connected devices with embedded intelligence capabilities and communication capabilities (e.g., HVAC equipment, LED lights, mobile phones, tablet computers, computers, elevators, fire safety systems, smart street lights, automobiles, televisions, security systems, refrigerators, music systems, printers, washing machines, dishwashers, coffee machines, etc.).

[0095] The ecosystem 1100 is shown to include a smart gateway 1104 technology component. The smart gateway technology component can include a smart gateway 1128. The gateway 1128 can be used to connect legacy devices and new devices (e.g., temperature sensors, actuators, cooling or heating devices, industrial robots, personal health monitoring devices, etc.) to obtain data from these devices and, in return, control these devices based on instructions or analysis results from remote services. The gateway 1128 can provide network security, access control, and unique addresses for legacy device endpoints for remote access and protocol mediation services. In some embodiments, the gateway 1128 is a general gateway solution made by any one of various hardware manufacturers (e.g., Intel, FreeScale, Dell, Texas Instruments, etc.). In other embodiments, the gateway 1128 is a NCE or MAP gateway that is specifically designed to connect building automation systems and smart devices. The gateway 1128 can use various internet-based protocols (e.g., CoAP, XMPP, AMQP, MQTT, etc.) and web-based public data exchange (e.g., HTTP RESTful API) to convert communications from building automation system protocols to internet protocols. For example, the gateway 1128 can provide protocol conversion that enables access to legacy non-IP supported devices through modern web / IP protocols (e.g., converting BACnet Serial to CoAP, MQTT, or AMQP).

[0096] The gateway 1128 can include soft components and / or physical devices with embedded components that perform various functions. For example, the gateway 1128 can optimize the cost of communication between networked devices (e.g., smart devices, smart networked devices 1102, non-smart networked things, etc.) and the rest of the digital world. In another example, the gateway 1128 can identify resources contained in networked devices. In yet another example, the gateway 1128 can perform semantic mediation of data received from networked devices (e.g., naming the conversion of data obtained from devices for global consumption in a standardized way).

[0097] In one embodiment, the gateway 1128 allows one or more smart, networked devices 1102 to connect outbound to public or private, cloud-based servers for further storage and processing by components of the ecosystem 1100. For network security considerations, inbound connections are typically not allowed; however, in some instances, secure and controlled inbound messaging is used to drive actions at the device level that can be facilitated by the IoT platform 1140. In one example, the gateway 1128 can utilize an organization’s internal technology infrastructure and / or public telemetry infrastructure to provide a secure and controlled inbound messaging scheme. In further embodiments, the gateway 1128 is configured to provide protocol conversion services, network address translation services, containers for messages, applications for understanding different protocols such as Bluetooth, ZigBee, Z-wave, BACNet, and / or any other user-installed applications.

[0098] In one embodiment, the gateway 1128 includes a number of field gateway aspects that interface primarily with devices and cloud-based servers. The field gateway aspects can enable the gateway 1128 to perform high-scale telemetry ingestion, device identification, device management, and cloud-to-device commands (e.g., when permitted). For example, in a home, several smart devices such as a security system, a television, a refrigerator, a music system, a printer, a computer, a washing machine, a dishwasher, a coffee maker, a garage door, etc. can have field gateways built into elements thereof and can use one home automation device to act as a cloud gateway. In another example, in a manufacturing or process facility, individual line machines can have field gateways built into them and connect via some common cloud gateway organized by line, process, and / or area. In yet another example, in an office building with an HVAC system (e.g., smart, networked HVAC equipment 408, etc.), there can be dozens of devices and hundreds of sensors with smart field gateway capabilities connected through a common cloud gateway.

[0099] The network service 1106 can include the Internet and / or other types of data networks, such as a local area network (LAN), a wide area network (WAN), an Internet area network (IAN), a home area network (HAN), a body area network (BAN), a cellular network, a satellite network, a radio network, or any other type of data network or combination thereof. The network service 1106 is shown to include a firewall / proxy 1130, one or more transport protocols 1132 (e.g., WLAN / LAN, ZigBee, wired / wireless, PAN / BAN / powerline, BTLE, HAN), one or more protocol handlers 1134, a message handler 1136, and a message cache 1138. The protocol handlers 1134 can facilitate conversion of data received over a variety of communication protocols into a uniform, understandable, and / or usable format. The message handler 1136 can facilitate the transport of messages (e.g., between the smartly networked device 1102 and the cloud, etc.). The message cache 1138 can improve the speed of data retrieval. The firewall / proxy 1130 can be configured to drive security and privacy policies.

[0100] The network service 1106 can include any number of computing devices (e.g., computers, servers, routers, network switches, etc.) configured to transmit, receive, or relay data (e.g., from the smartly networked device 1102 to a public or private cloud-based server, etc.). The network service 1106 can further include any number of hardwired and / or wireless connections. For example, the smartly networked HVAC equipment 408 and / or the smartly networked device 1102 can communicate wirelessly (e.g., using Wi-Fi, Bluetooth, EnOcean, near-field communication (NFC), LoRA, ZigBee, cellular radio, etc.) with a transceiver of a computing device of the network service 1106 that is hardwired (e.g., via fiber optic cable, CAT5 cable, etc.) to the network service 1106. The network service 1106 can include services that facilitate the management of wired and / or wireless communication with the smartly networked HVAC equipment 408 and / or the smartly networked device 1102. Network providers can include, for example, cellular telecommunication providers (e.g., Verizon, T-Mobile, AT&T, etc.) and Internet service providers. Communication via the network service 1106 can leverage corporate contracts and partnerships to optimize the cost of data transmission. Many network carriers offer secure connection options as part of premium services. However, a similar degree of network security can be achieved by employing a trusted platform chip in the smartly networked HVAC equipment 408 and / or the smartly networked device 1102 and using encrypted messaging, such as AMQP, via Internet-based secure transport.

[0101] Referring to Figure 12According to one embodiment, a device-to-cloud connectivity layout 1200 is illustrated (e.g., a smart-connected device 1102, a smart-connected HVAC device 408, etc.). According to some embodiments, the device-to-cloud connectivity layout 1200 utilizes devices, gateways, and network services to connect devices to the cloud. Figure 12 As shown, the device-to-cloud connectivity layout 1200 includes multiple dedicated devices, shown as dedicated devices 1202. Dedicated devices 1202 may include sensors, valves, servo devices, switches, etc. Dedicated devices 1202 may be communicatively coupled to one or more smart devices, shown as smart devices 1204. Smart devices 1204 may include a processor with an embedded operating system (e.g., Linux, Android, iOS, RTOS, Windows 10, etc.). Dedicated devices 1202 may communicate with smart devices 1204 via wired and / or wireless communication protocols (e.g., Wi-Fi, Bluetooth, NFC, ZigBee, etc.). In some embodiments, smart devices 1204 are included within dedicated devices 1202.

[0102] Smart device 1204 can be communicatively coupled to a network device (e.g., NAT, firewall, router, etc.) shown as network device 1206. Network device 1206 can communicate with smart device 1204 via wired and / or wireless communication protocols (e.g., Wi-Fi, Bluetooth, NFC, ZigBee, cellular, etc.). According to one embodiment, dedicated device 1202, smart device 1204, and network device 1206 form an internal network. In some embodiments, the connection between smart device 1204 and network device 1206 is initiated and transmitted by smart device 1204. In some embodiments, network device 1206 is capable of initiating a connection with smart device 1204 to provide commands and / or updates (e.g., from a remote server, cloud, etc.). Network device 1206 can be communicatively coupled to a gateway shown as field gateway 1208. In one embodiment, field gateway 1208 may have a public IP address but can function as a fully secure and well-defended server platform. In other embodiments, field gateway 1208 may have a private IP address. The field gateway 1208 can be communicatively coupled to a cloud-based server, such as cloud-based server 1210. Cloud-based server 1210 can monitor dedicated device 1202 and / or smart device 1204. In some embodiments, cloud-based server 1210 is used to send updates and / or commands to dedicated device 1202 and / or smart device 1204.

[0103] Return to reference Figure 11The device management technology concept 1108 is shown to include a device identity and access management module 1142, and a device management module 1144. According to one example embodiment, management of the smart, connected devices 1102 by the device management technology concept 1108 of the IoT platform 1140 from the perspective of identity and access management includes four aspects, including: (i) device provisioning; (ii) device registration; (iii) telemetry ingestion; and (iv) command and control. Device provisioning can include setting up devices to establish a secure, trusted relationship with the digital world. The device management technology concept 1108 can generate secure keys to be distributed to corresponding devices to enable the devices to interact with the rest of the IoT platform 1140. With respect to device registration, the device management technology concept 1108 can register each device and maintain a list of provisioned devices and associated metadata. Device registration is described in more detail below. With respect to telemetry ingestion, the device management technology concept 1108 can provide a simple, secure path for receiving data from connected devices. With respect to command and control, the device management technology concept 1108 can provide functionality for securely sending data to devices (e.g., using existing outbound connections, etc.).

[0104] The device management technology concept 1108 can also facilitate complete lifecycle management of devices. In some embodiments, the device management technology concept 1108 facilitates tracking devices from manufacturing to installation. In some embodiments, the device management technology concept 1108 facilitates distributing and licensing software contained by devices, including remote updates for new features, security, and other maintenance-type activities. In some embodiments, the device management technology concept 1108 facilitates monitoring the recycling and decommissioning of devices that are no longer usable after their useful life. In some embodiments, the device management technology concept 1108 facilitates monitoring the health of devices. In some embodiments, the device management technology concept 1108 facilitates monitoring customer usage patterns, release levels, and maintenance protocols to extract additional business value. The device management technology concept 1108 can provide secure end-to-end connectivity, ease of integration into embedded products, simple registration workflow, ease of diagnosing and remedying connectivity issues, remote user access to operations (with the ability to override on a LAN), fast and reliable software updates, time series data push, automated remote write-back to devices, device location tracking, device time synchronization (accounting for time zones and automatic changes in time zones as in daylight savings situations), licensing of devices and features within devices, rule engine / scheduling of device actions from the cloud, and application program interfaces (APIs) for extending the capabilities of devices and the cloud.

[0105] Data routing and real-time data analytics technology concepts 1110 can act as a backend distributed infrastructure for IoT platform 1140. In one embodiment, data routing and real-time data analytics technology concepts 1110 can be third party systems such as Kafka, Storm, Event Hub, etc. By way of example, distributed message routing module 1148 of data routing and real-time data analytics technology concepts 1110 can be configured to send messages and data elements generated from devices to the correct data platform storage location. The storage location (or application) can use a listener application to receive and process the messages. Distributed message routing 1148 can also act as a front door for event ingestion and sometimes as a bidirectional control action pipeline to the devices or systems from which the messages events are received.

[0106] Complex event processing (CEP) module 1146 (e.g., hot path analytics, etc.) can be configured to identify meaningful events and facilitate responding to such events quickly. An anomaly or other pattern can trigger an event in the system such that CEP module 1146 initiates additional processing or implements additional control logic in response to the event. Referring now to Figure 13 CEP involves multiple steps as shown by CEP map 1300. As shown by CEP map 1300, CEP includes multiple steps including event generation 1302 (e.g., via applications, devices, sensors, web and social, etc.), data collection 1304 (e.g., via cloud gateways, on-premise gateways, etc.), event queuing 1306 (e.g., via event hubs, Kafka, RabbitMQ, ActiveMQ, etc.), event transformation 1308 (e.g., via stream processing, storage adapters, etc.), preparation and actual long-term storage 1310, and multi-format presentation of analyzed events 1312 (e.g., via dashboards, search and query, spreadsheet data analysis, on smart devices, etc.) for reporting and / or other further actions.

[0107] In traditional data management and enterprise systems, message routing and event processing type activities are sequential and spaced apart by more detailed classification, cleaning, storage, and analysis steps. Referring back to Figure 11 IoT platform 1140 of the present disclosure facilitates receiving simultaneous or near simultaneous events, thereby taking remedial action immediately with early insights from time series data. Distributed message routing module 1148 can be capable of processing millions of events per second in real time and in different computing environments to meet the need for real-time analytics. Distributed message routing 1148 can also involve ingesting, processing, and putting back millions of messages in a message dispatcher for multiple listener applications to extract. In some embodiments, distributed message routing module 1148 performs data transformation and validation.

[0108] The data services platform technology concept 1112 can be configured to manage large amounts of structured, unstructured, and streaming data. The big data processing module 1150 can include a Hadoop Distributed File System (HDFS) configured to perform distributed parallel storage using (i) a name node to track placement of physical data across various Hadoop instances and (ii) data nodes to physically store the data. The HDFS can allow multiple computing devices (e.g., simple consumer grade computing devices, etc.) to be virtually organized to store large amounts of data. The big data processing module 1150 can also include a Map Reduce function to process large data transactions (e.g., structured, unstructured, and streaming). The Map Reduce function can use a parallel distributed algorithm to orchestrate a cluster needed for storage and processing of data.

[0109] Large amounts of data can contain different values for different analytics and insights (e.g., the data can have different meanings, etc.). This can require abstracting the data into multiple meanings through a collection of key and value pairs of the data, which can be implemented through an associative array. The big data processing module 1150 can include storing keys for managing such associative arrays through dictionaries and hashes. The dictionaries can include a collection of objects and / or records that have multiple different fields within the dictionary, each containing data. Such objects and / or records can be stored and retrieved using a key that uniquely identifies the object and / or record, such that the key can be used to quickly locate data within a database.

[0110] The big data processing module 1150 can additionally or alternatively include a graph database or graph store that stores data using a graph structure for semantic queries with nodes (e.g., entities, etc.), properties (e.g., information about entities, etc.), and edges (e.g., connections between nodes and properties, etc.). The big data processing module 1150 can additionally or alternatively include Spark. According to some embodiments, Spark is an open source cluster computing framework built for multi-level memory data processing. Spark can speed up processing performance by orders of magnitude and can complement machine learning of the IoT platform 1140.

[0111] The data services platform technology concept 1112 can further include a relational database management system (RDBMS) 1152, which can be used to store data associated with applications that have low latency data retrieval needs, as RDBMS 1152 has inherent low latency. For example, consumer-facing or front-end applications traditionally have low latency data retrieval needs. Accordingly, data associated with such applications can be stored in RDBMS 1152, rather than by the big data processing module 1150. Data stored in RDBMS 1152 can be parsed, transformed, and / or enriched prior to being stored in RDBMS 1152.

[0112] The data integration module 1154 facilitates connecting with and collecting data (e.g., structured data, unstructured data, streaming data, etc.) from almost any type of device (e.g., smart, networked devices 1102, smart, networked HVAC equipment 408, etc.). The format of the collected data can vary significantly from device to device. The data integration module 1154 is configured to process the collected data so that the data is stored in a native state or substantially as collected (e.g., as the native state can be used and analyzed differently later, etc.). The data integration module 1154 can use asynchronous communication to collect data (e.g., to make integration of the data simpler, etc.). An abstraction layer can be used during any processing or further storage. The data integration module 1154 can additionally provide ease of semantic mediation of the collected data (e.g., so that the IoT platform 1140 can use the data in a meaningful way, etc.). According to one embodiment, the data integration module 1154 includes a plurality of microservices that form an integration fabric. In some embodiments, the data integration module 1154 is independent of other components of the data services platform 1112.

[0113] The analytics technology concept 1114 can include a massively parallel data analytics module 1158. The massively parallel data analytics module 1158 can include a plurality of processors configured to run analytics processing. The massively parallel data analytics module 1158 can divide a large data set into smaller segments that are analyzed (e.g., operated on, etc.) by a particular assigned processor (e.g., having its own operating system and memory, etc.). A message passing interface can aggregate results after analysis by each processor. Such a system can allow for improved processing and flexible scalability.

[0114] The IoT platform 1140 improves the ability to collect real-time operational and / or performance data from devices and / or machines (e.g., very frequent intervals, continuously, etc.). A time series analysis module 1164 within the analytics technology concept 1114 can be configured to receive large amounts of streaming time series data for analysis. The time series analysis module 1164 can analyze time series data in the time domain and / or frequency domain. The time series analysis module 1164 can use such analysis to predict future events and / or identify trends. The time series analysis module 1164 can combine multiple parameters from time series data, as well as environmental and / or influence data, for fault detection and diagnosis (FDD). Due to the large availability of data that can be received, stored, and processed by various components of the IoT platform 1140, the IoT platform 1140 can facilitate the use of automated FDD. FDD analysis can include rule-based FDD analysis, model-based FDD analysis, and / or case-based FDD analysis, among other possibilities. Rule-based FDD analysis can use boundary conditions of observed data to detect and isolate faults (e.g., using simple or complex if / then / else / so logic blocks or structures, etc.). Model-based FDD analysis can use different types of statistical models in more applied analysis. Case-based FDD analysis can use past case-solution examples to adapt to new and / or similar cases, such that new behaviors are learned over time by modifying analysis parameters (e.g., adaptive learning, etc.).

[0115] The analytics technology concept 1114 can further include a machine learning module 1166. The machine learning module 1166 can be configured to use data mining techniques and / or other learning algorithms to build models to explain various data received from various devices or components (e.g., smart devices, smart connected devices 1102, smart connected HVAC devices 408, etc.) in order to detect, classify, and / or predict future outcomes. Such learning algorithms can be associated with rule learning, artificial neural networks, inductive logic programming, and / or clustering and Bayesian networks. The machine learning module 1166 can solve complex problems, predict previously un-modeled scenarios, and / or develop new insights by using statistical methods to identify algorithms for analysis and correlation by itself. The machine learning module 1166 can be executed by custom programming and / or using standard or open source tools (e.g., machine learning such as SicKit, Spark, etc.).

[0116] The analytics technology concept 1114 can further include an advanced data mining module 1162. The advanced data mining module 1162 can use statistical data analysis and other algorithmic methods to find patterns within data. The statistical data analysis can include statistical methods involving regression analysis, neural networks, and / or decision trees. The advanced data mining module 1162 can apply certain techniques to solve special problems, including association rules for initial data exploration, fuzzy data mining methods, rough set models, support vector machines, and genetic algorithms. The advanced data mining module 1162 can be used to solve many complex problems and / or generate insights in a wide range of industries that involve the interaction of multiple different data types / categories that can not have obvious connections. The advanced data mining module 1162 can apply methods including the Cross-Industry Standard Process for Data Mining (CRISP-DM) and / or Sample-Explore-Modify-Model-Assess (SEMMA) for data mining. Such methods can be applied by the advanced data mining 1162 in iterative cycles to provide better analysis.

[0117] The analytics technology concept 1114 can further include a business intelligence module 1160. The business intelligence module 1160 can be configured to enable easy creation and access to dashboards and analytics across multiple data sources and types. The business intelligence module 1160 can be further configured to facilitate the creation of content packages (e.g., data, analytics, etc.) for distribution to other users (e.g., in the same organization, in the same industry, for crowd visualizations, etc.). Such distribution can allow others to independently analyze the content and / or create independent dashboards and / or reports. The content can be delivered through multiple channels including desktops, mobiles, and / or web.

[0118] Still referring to Figure 11 The ecosystem 1100 is shown to include a delivery technology concept 1116. The delivery technology concept 1116 relates to channels and distribution strategies, and is shown to include a delivery application module 1168, a data visualization module 1170, a product distribution module 1172, an application service API module 1174, and integration to enterprise application modules 1176. The product distribution module 1172 can include offline distribution of IoT-related products, services, and online distribution of solutions for specific customers and / or markets (e.g., the delivery application module 1168). The application service API module 1174 can be provided to app developers to deliver information products. The data visualization module 1170 and exploration tools can be used for quick delivery. The delivery technology concept 1116 can include integration to one or more enterprise application modules 1176.

[0119] The ecosystem 1100 is shown to further include business / operations support technology concepts 1118. The business / operations support technology concepts 1118 can facilitate the integration and optimization of devices to bring related applications together. The business / operations support technology concepts 1118 can provide capabilities for customer management, managing partners that are contributors to the IoT platform 1140, managing business transactions, business reporting, and financial reporting. For example, if the IoT platform 1140 includes financial transaction services, CRM, ERP, and / or financial payment service integration can be used. The business / operations support technology concepts 1118 can further include business applications such as a customer management application module 1178 (e.g., CRM, etc.), a partner management application module 1180, a billing module 1182, a reporting application module 1184, and an ERP module 1186. The reporting application module 1184 can be configured to facilitate providing data from the IoT platform 1140 to external businesses that can be interested in the data (e.g., insurance companies, utility providers, government agencies, etc.). The business / operations support technology concepts 1118 can allow manufacturers to leverage IoT-enabled product-related data such as installation base information, operational performance data, maintenance history, etc. to attract new service providers (e.g., which can be middlemen, etc.).

[0120] The ecosystem 1100 is further shown to include security, privacy, access control, and compliance management technology concepts 1190. Multi-layered and multi-dimensional intrusion detection and prevention mechanisms can provide security at the device level, data level, network level, and / or application level. The same intelligence that enables devices to perform their tasks can also enable these devices to recognize and counter threats. This does not require evolutionary approaches, but rather the evolution of measures that have proven successful in IT networks to the limitations of IoT-challenged and networked devices. At any given point in time, the IoT platform 1140 can support multiple users and stakeholders, including building owners, building operators, tenants, service technicians, manufacturers, etc. The remote accessibility of networked products can involve complex identity management through a unified sign-in and product management experience. For example, a single sign-in can allow a customer to sign into all networked products and services associated with the IoT platform 1140.

[0121] Security, privacy, access control, and compliance management technology concepts 1190 can provide encryption for data and connections at some or all stages. Each device and / or each data transaction associated with IoT platform 1140 can have a unique identity that can provide ease of traceability and enable authentication. Security, privacy, access control, and compliance management technology concepts 1190 can provide perimeter protection, intrusion detection and / or response, and audit tracking (e.g., in real-time speed, etc.). Security, privacy, access control, and compliance management technology concepts 1190 can be able to isolate any non-secure devices and / or connections, and / or have a mechanism to accept such non-secure devices and / or connections with a calculated risk. Security, privacy, access control, and compliance management technology concepts 1190 can have a mechanism to detect pattern anomalies in device connections, network traffic, and / or data communications (e.g., immediate indicators of possible intrusion, etc.). Security, privacy, access control, and compliance management technology concepts 1190 can comply with various standards, including but not limited to ISO / IEC 27001, NIST 800-82v2, RFC 2196, and / or ISA / IEC-62443.

[0122] There can be many different actors or roles involved with IoT platform 1140 with different data access needs, including the devices and sensors themselves, manufacturers of such devices and sensors, installers, owners, users, maintenance personnel, application service providers, technology platform providers, cloud hosting providers, etc. Security, privacy, access control, and compliance management technology concepts 1190 can provide different action permissions for data to each of these actors (e.g., who can access what data, what actions can be taken on generated data, etc.).

[0123] Referring now to Figure 14 , according to one embodiment, a data platform 1400 (e.g., for IoT platform 1140, etc.) is shown. As Figure 14 indicated, data platform 1400 includes a device 1402 (e.g., a local device, a smart, networked device 1102, an HVAC appliance 408, etc.) communicably coupled to a device reverse proxy 1404 and a mobile / web reverse proxy 1408. Device reverse proxy 1404 and mobile / web reverse proxy 1408 can be further communicably coupled to a mobile / web device 1406 (e.g., an outdoor device, etc.). Additionally, device reverse proxy 1404 and mobile / web reverse proxy 1408 can also be communicably coupled to one or more components and / or application program interfaces (APIs) of data platform 1400, respectively. As Figure 14As shown, the one or more components and / or APIs of the data platform 1400 include an identity management (IDM) component 1410, an IoT hub 1420, one or more message processors 1430 (e.g., a status processor 1432, a feedback processor 1434, a device information processor 1436, a telemetry processor 1438), a security API 1440, an identity API 1450, and an application API 1460, a weather API 1470, a time series API 1474, an entity API 1478, a notification API 1484, and an email API 1488.

[0124] As an overview, the data platform 1400 can be a collection of services that collect and provide building objects and time series data. A point in the entity API 1478 can contain a time series object that includes an ID and a sample URL. The ID and sample URL in the time series object can be used to query the time series API 1474. A portion of the time series API 1474 can allow users to query by space or system. In this case, the time series API 1474 can look up the corresponding time series object in the entity API 1478. To use the time series API 1474 and / or the entity API 1478, an action token can need to be acquired (e.g., from the IDM component 1410) for authentication and authorization. Various HTTP verbs including GET, POST, PUT, PATCH, and DELETE can be used with the data platform 1400 to perform various actions. GET can be used to read from an API. POST can be used to create an item or perform an action. PUT can be used to update an item, or create an item if it does not exist. PATCH can be used to update specific properties of an item. DELETE can be used to delete a single item (or a cascading delete when a point is deleted, as the associated time series can also be deleted).

[0125] As an overview, the data platform 1400 can be a collection of services that collect and provide building objects and time series data. A point in the entity API 1478 can contain a time series object that includes an ID and a sample URL. The ID and sample URL in the time series object can be used to query the time series API 1474. A portion of the time series API 1474 can allow users to query by space or system. In this case, the time series API 1474 can look up the corresponding time series object in the entity API 1478. To use the time series API 1474 and / or the entity API 1478, an action token can need to be acquired (e.g., from the IDM component 1410) for authentication and authorization. Various HTTP verbs including GET, POST, PUT, PATCH, and DELETE can be used with the data platform 1400 to perform various actions. GET can be used to read from an API. POST can be used to create an item or perform an action. PUT can be used to update an item, or create an item if it does not exist. PATCH can be used to update specific properties of an item. DELETE can be used to delete a single item (or a cascading delete when a point is deleted, as the associated time series can also be deleted). Figure 14As shown, the IDM component 1410 includes an identity management system (IMS) 1411, a client management system (CMS) 1412, a user management system (UMS) 1413, a token support module 1414 (e.g., for OpenID Connect, etc.), an external user support module 1415 (e.g., Microsoft, Facebook, etc.), and a local user support module 1416 (e.g., registration, forgot password, etc.). According to an example embodiment, the IMS 1411 is configured to implement the OpenID Connect protocol, which is an identity layer on top of the OAuth 2.0 protocol. The OpenID Connect protocol allows clients to verify the identity of an end-user based on authentication performed by an authorization server, and to obtain basic profile information about the end-user in a interoperable and other similar ways. The OpenID Connect protocol allows all types of clients, including web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID providers, and session management. The OAuth 2.0 protocol focuses on simplicity, while providing explicit authorization flows for web, desktop, and mobile apps. The IMS 1411 can implement the protocol using IdentityServer 3 (e.g., a.NET / Katana-based framework and hostable component).

[0126] The IMS 1411 can be configured to restrict web services for unauthenticated users and applications. Such restrictions can be based on tokens for users. A token can represent a set of claims that can be used to restrict the permissions of a client when using IMS-secured endpoints (e.g., such as HTTP APIs, etc.). A client can request a token from the IMS 1411. The client can send the token to any IMS-secured endpoint (e.g., bearer authorization in the HTTP authorization header for HTTP-based APIs). The token can be valid for a predetermined duration (e.g., one hour, thirty minutes, two hours, etc.).

[0127] As Figure 14As shown, the security API 1440 includes a user / role storage 1441, a permissions storage 1442, a group storage 1443, a client / scope storage 1444, a token storage 1445, and a device storage 1446. The security API 1440 can also communicate with an identity API 1450. The identity API 1450 can include a claim device module 1452, a get claims device module 1454, a command device 1456, and a get device information module 1458. The application API 1460 can include a check update module 1462 and a device registry backdoor module 1464. According to one embodiment, the security API 1440 is configured to manage users, roles, groups, devices, and / or relationships therebetween. In some embodiments, a PostgreSQL database is used to store such data (e.g., in an on-premise scenario). In some embodiments, a variety of technologies are used, including but not limited to Azure Active Directory, Azure IoT Hub, Azure DocumentDB, and / or Azure Table (e.g., in a cloud scenario).

[0128] The user / role storage module 1441 can be configured to store data and / or information related to users and / or roles. A user can effectively represent an individual identity available in the data platform 1400. An example of information stored in the user / role storage module 1441 related to users is shown in Table 1. A role can effectively represent a set of permissions for a user or a group. Each API in the data platform 1400 can have a different interpretation of a role. An example of information stored in the user / role storage module 1441 related to roles is shown in Table 2. The group storage 1443 can be configured to store data and / or information related to groups. A group can effectively represent a set of users and / or devices in the data platform 1400. An example of information stored in the group storage 1443 related to groups is shown in Table 3. The device storage 1446 can be configured to store data and / or information related to devices. A device can facilitate interaction with the IoT hub 1420, such that metadata and commands can be defined for the device. An example of information stored in the device storage 1446 related to devices is shown in Table 4.

[0129] Table 1: Users

[0130]

[0131] Table 2: Roles

[0132]

[0133] Table 3: Groups

[0134]

[0135] Table 4: Devices

[0136]

[0137] The weather API 1470 is configured for communication with one or more external weather providers 1472 (e.g., Aeris Weather, etc.). Such communication can facilitate the integration of weather information (e.g., current weather data based on a location such as a country, state, and / or zip code, weather forecasts, historical data) into web and / or mobile applications. The weather API 1470 can automatically attach the correct security credentials using IMS token claims.

[0138] The entity API 1478 (e.g., with hierarchical navigation 1480) includes entities including organizations, spaces, systems, points, time series, and data sources. According to an example embodiment, entities are open types such that each entity supports dynamic properties. Entities have the properties shown in Table 5.

[0139] Table 5: Entities

[0140]

[0141] Entities can have associated entity templates. Entity templates indicate the "type" of the entity and can also have additional metadata. Entity templates can have all of the properties of an entity (see Table 5) as well as the properties shown in Tables 6-8.

[0142] Table 6: Entity Templates

[0143]

[0144] Table 7: Property Metadata

[0145]

[0146] Table 8: Relationship Metadata

[0147]

[0148] Organizations can include companies, tenants, and / or another group of people that occupy and / or own a space. Organizations can have all of the properties of an entity (see Table 5) as well as the properties shown in Table 9.

[0149] Table 9: Organizations

[0150]

[0151]

[0152] A space can include a venue, a building, and / or a building area. A space can have all the properties of an entity (see Table 5), as well as the properties shown in Table 10.

[0153] Table 10: Space

[0154]

[0155]

[0156]

[0157] A system can include an energy, HVAC, and / or other control system. Systems can be nested. For example, a master meter can have a subsystem that is a submeter. A system can have all the properties of an entity (see Table 5), as well as the properties shown in Table 11.

[0158] Table 11: System

[0159]

[0160]

[0161] A point can identify a single value being monitored in a building automation system (BAS). These points can have a native reference that is a BAS identifier. The origin of a point is defined as online, offline, or virtual. An online point can receive data for the online point from the BAS. An offline point can obtain data for the offline point through a user interface (UI). A virtual point can be dynamically calculated. Online and offline points can have a time series of raw transform type. Virtual points can have a time series of custom expression transform type. Each point can have one time series of a corresponding transform type. A point can have all the properties of an entity (see Table 5), as well as the properties shown in Table 12.

[0162] Table 12: Point

[0163]

[0164]

[0165] A time series can have all the properties of an entity (see Table 5), as well as the properties shown in Table 13.

[0166] Table 13: Time Series

[0167]

[0168]

[0169] When the transform type property is set to "custom expression" on a time series entity, the custom transform expression property can hold an expression that is evaluated each time a new source sample is added to the time series API 1474. For example, the custom expression 'dot("ID1") + dot("ID2")' can add the sample values of point ID1 and point ID2 when a new sample is added to the time series API 1474 at any point. The result of this calculation is then stored with the time series id that holds the custom expression in the time series.

[0170] A data source is a BAS or other source that the entity is configured from. The drivers in the data collector can be Metasys, FX, and BACnet data sources from Johnson Controls, Inc. The data source can have all of the properties of an entity (see Table 5) as well as the properties shown in Table 14.

[0171] Table 14: Data Source

[0172]

[0173] A unit endpoint can list the units of measure. The unit can have all of the properties of an entity (see Table 5) as well as the properties shown in Table 15.

[0174] Table 15: Unit

[0175]

[0176]

[0177] Referring now to Figure 15 , according to some embodiments, an entity graph 1500 is shown. In some embodiments, the entity graph 1000 is generated or used by the entity API 1478, as described with reference to Figure 14 The entity graph 1500 describes how a building is organized and how different systems and spaces within the building relate to each other. For example, the entity graph 1500 is shown to include an organization 1502, spaces 1504, systems 1506, points 1508, time series 1510, and data sources 1512. The arrows interconnecting the organization 1502, spaces 1504, systems 1506, points 1508, time series 1510, and data sources 1512 identify the relationships between such entities. In some embodiments, the relationships are stored as properties of the entities described by properties.

[0178] Organization 1502 is shown to include a contains descendants attribute 1514, a parent ancestors attribute 1516, a contains attribute 1518, a parent attribute 1520, an occupies attribute 1524, an owns attribute 1530, a uses system attribute 1548, and a data source attribute 1580. Contains descendants attribute 1514 identifies any descendant entities contained within organization 1502. Parent ancestors attribute 1516 identifies any parent entities of organization 1502. Contains attribute 1518 identifies any other organizations contained within organization 1502. The asterisk next to contains attribute 1518 indicates that organization 1502 can contain any number of other organizations. Parent attribute 1520 identifies the parent organization within which organization 1502 is associated. The number 1 next to parent attribute 1520 indicates that organization 1502 can be associated with exactly one other parent organization. Occupies attribute 1526 identifies any space occupied by organization 1502. The asterisk next to occupies attribute 1526 indicates that organization 1502 can occupy any number of spaces. Owns attribute 1530 identifies any spaces owned by organization 1502. The asterisk next to owns attribute 1530 indicates that organization 1502 can own any number of spaces. Uses system attribute 1548 identifies any systems used by organization 1502. Data source attribute 1580 identifies any data sources associated with organization 1502. The asterisk next to data source attribute 1580 indicates that any number of data sources can be associated with organization 1502.

[0179] Space 1504 is shown to include occupied by ancestors attribute 1522, occupied by attribute 1524, owned by ancestors attribute 1526, owned by attribute 1528, contains space descendants attribute 1532, located in ancestors attribute 1534, contains spaces attribute 1536, located in attribute 1538, served by system descendants attribute 1540, served by systems attribute 1546, and points attribute 1560. Occupied by ancestors attribute 1522 identifies one or more ancestors of organization 1502 that are occupied by space 1504. The asterisk next to occupied by ancestors attribute 1522 indicates that space 1504 can be occupied by any number of ancestors. Occupied by attribute 1524 identifies the organization that is occupied by space 1504. The number 1 next to occupied by attribute 1524 indicates that space 1504 can be occupied by exactly one organization. Owned by ancestors attribute 1526 identifies one or more ancestors of organization 1502 that own space 1504. The asterisk next to owned by ancestors attribute 1526 indicates that space 1504 can be owned by any number of ancestors. Owned by attribute 1528 identifies the organization that owns space 1504. The number 1 next to owned by attribute 1528 indicates that space 1504 can be owned by exactly one organization.

[0180] The contains space descendants attribute 1532 identifies any descendants of the space 1504 that are contained within the space 1504. The located in ancestors attribute 1534 identifies any ancestors of the space 1504 within which the space 1504 is located. The contains spaces attribute 1536 identifies any other spaces contained within the space 1504. The asterisk next to the contains spaces attribute 1536 indicates that the space 1504 can contain any number of other spaces. The located in attribute 1538 identifies another space within which the space 1504 is located. The number 1 next to the located in attribute 1538 indicates that the space 1504 can be located in exactly one other space. The served by system descendants attribute 1540 identifies any descendant systems that serve the space 1504. The asterisk next to the served by system descendants attribute 1540 indicates that the space 1504 can be served by any number of descendant systems. The served by system attribute 1546 identifies any systems that serve the space 1504. The asterisk next to the served by system attribute 1546 indicates that the space 1504 can be served by any number of systems. The points attribute 1560 identifies any data points associated with the space 1504. The asterisk next to the points attribute 1560 indicates that any number of data points can be associated with the space 1504.

[0181] The system 1006 is shown to include a serves space ancestors attribute 1542, a serves spaces attribute 1544, a subsystem descendants attribute 1550, a part of ancestors attribute 1552, a subsystems attribute 1554, a part of attribute 1556, a used by organization attribute 1582, a points attribute 1564, and a data source attribute 1572. The serves space ancestors attribute 1542 identifies any ancestors of the space 1504 that are served by the system 1506. The asterisk next to the serves space ancestors attribute 1542 indicates that the system 1506 can serve any number of ancestor spaces. The serves spaces attribute 1544 identifies any spaces served by the system 1506. The asterisk next to the serves spaces attribute 1544 indicates that the system 1506 can serve any number of spaces. The used by organization attribute 1582 identifies systems used by the organization 1502. The asterisk next to the used by organization attribute 1582 indicates that the system 1506 can be used by any number of organizations.

[0182] Subsystem descendant attribute 1550 identifies any subsystem descendants of the system 1506 that are contained within the system 1506. The partial ancestor attribute 1552 identifies any ancestors of the system 1506 that the system 1506 is a part of. The subsystem attribute 1554 identifies any subsystems contained within the system 1506. The asterisk next to the subsystem attribute 1554 indicates that the system 1506 can contain any number of subsystems. The part attribute 1556 identifies any other systems that the system 1506 is a part of. The number 1 next to the part attribute 1556 indicates that the system 1506 can be exactly one part of another system. The point attribute 1564 identifies any data points associated with the system 1506. The asterisk next to the point attribute 1564 indicates that any number of data points can be associated with the system 1506. The data source attribute 1572 identifies any data sources associated with the system 1506. The asterisk next to the data source attribute 1572 indicates that any number of data sources can be associated with the system 1506.

[0183] The time series 1510 is shown as including the point attribute 1568. The point attribute 1568 identifies a point associated with the time series 1510. The number 1 next to the point attribute 1568 indicates that exactly one point is associated with the time series 1510.

[0184] The point 1508 is shown as including the by-space-use attribute 1558, the by-system-use attribute 1562, the time series attribute 1566, and the data source attribute 1576. The by-space-use attribute 1558 identifies a data point used by the space 1504. The asterisk next to the by-space-use attribute 1558 indicates that the point 1008 can be used by any number of spaces. The by-system-use attribute 1562 identifies a data point used by the system 1506. The asterisk next to the by-system-use attribute 1562 indicates that the point 1008 can be used by any number of systems. The time series attribute 1566 identifies a data point associated with the time series 1510. The asterisk next to the time series attribute 1566 indicates that the point 1008 can be associated with any number of time series. The data source attribute 1576 identifies a data point associated with the data source 1512. The asterisk next to the data source attribute 1576 indicates that the point 1008 can be associated with any number of data sources.

[0185] The data source 1512 is shown to include system attributes 1570, point attributes 1574, and organization attributes 1578. The system attributes 1570 identify the systems associated with the data source 1512. The asterisk next to the system attributes 1570 indicates that any number of systems can be associated with the data source 1512. The point attributes 1574 identify any data points associated with the data source 1512. The asterisk next to the point attributes 1574 indicates that any number of data points can be associated with the data source 1512. The data source attributes 1580 identify the organizations associated with the data source 1512. The number 1 next to the organization attributes 1578 indicates that one organization can be associated with the data source 1512.

[0186] Referring back to Figure 14 The time series API 1474 (e.g., with queryable streams 1476) is configured to display files for points, time series, samples, messages, and / or job endpoints. The time series API 1474 can facilitate displaying samples for a single point and / or multiple points. A point can have an original time series with an initial sample. Other time series on the point can be rollups calculated based on the original time series. Sum, average, and delta parameters (e.g., every quarter hour, every hour, every day, every month, every year, etc.) can be used to select time series. Uniform resource identifier (URI) parameters for one or more points are shown in Table 15.

[0187] Table 15: URI parameters - points

[0188]

[0189] The time series API 1474 can facilitate displaying, deleting, and / or receiving statistics for samples of one or more time series. URI parameters for one or more time series are shown in Table 16.

[0190] Table 16: URI parameters - time series

[0191]

[0192]

[0193] The time series API 1474 can also facilitate determining which samples have been cleaned. For example, when a point is created, a time series is created for the point (e.g., with a transform type of "cleaned"). The "cleaned" time series stores a sample at a timestamp when the sample triggers a cleaner to modify its data. The "cleaned" time series is queried like any other time series object and returns different values based on the cleaner running on this sample. Cleaners can include a boundary limit cleaner, an instantaneous consumption cleaner, an interpolated gap filler, and / or a data spike cleaner.

[0194] A job endpoint of the time series API 1474 can be used to interact with a job manager. According to example embodiments, the job manager is a background process in the time series API 1474 used to schedule jobs (e.g., repeatable jobs, etc.). A job can be an activity that interacts with time series data, such as collecting weather data, detecting faults, etc. When a job runs, the time series API 1474 is configured to create one or more tasks to perform the work. A job can include the parameters shown in Table 17. A user can use the time series API 1474 to return a list of registered job types, create a new job, get scheduled jobs, delete scheduled jobs, get job history (e.g., scheduled jobs, running jobs, completed tasks, etc.), and get and set job manager settings (see Table 18).

[0195] Table 17: Job Parameters

[0196]

[0197] Table 18: Job Manager Settings

[0198]

[0199] By way of example, the time series API 1474 can run a job to collect weather-related data from a service provider (e.g., accessed through the weather API 1470, etc.). The time series API 1474 can store the weather-related data so that it can be queried. To activate this process, a weather station system can be added to a space through the entity API 1478. Before creating the weather station system, a weather-related point and a space to which the weather station is to be associated can be identified and created. For example, the process can include (i) creating a space that the weather station can use, (ii) creating a weather point to store the data, and (iii) creating the weather station and connecting the weather point to the space.

[0200] After creating the weather station system, a weather collector job can be added to the job manager to initiate the data collection process. When the weather collector job runs for the first time, it attempts to determine the weather station's weather ID by looking up the most recent weather ID using the associated latitude and longitude. Each subsequent run of the weather job attempts to collect data lost since its last run (e.g., timestamps based on outdoor temperature points). In some embodiments, if no data is found within a predetermined time frame (e.g., the last three years), the job creates a task for each month within that time frame to fill in the missing data. Weather reports can then be generated on a desired, recurring basis (e.g., hourly, daily, etc.), and weather-related data can be queried like any other point (e.g., an operator can receive information related to the current temperature at a desired location, etc.).

[0201] Still refer to Figure 14 The IoT hub 1420 can facilitate bidirectional communication between the cloud and devices in a secure, reliable, and unified manner. For example... Figure 14 As shown, the IoT hub 1420 includes a device registry module 1422, a metadata API 1424 (e.g., including device status, command feedback, etc.), an egress API 1426, and an ingress API 1428. The device registry module 1422 is configured to maintain a set of credentials for devices (e.g., device 1402, web / mobile device 1406, etc.) that can be used to communicate with the IoT hub 1420. Each device may have two available keys (e.g., a security key, an authorization key, etc.) that can be alternated as needed. In some embodiments, credentials (e.g., keys, etc.) are created at manufacturing time and shared with the device. In some embodiments, a device registry backdoor 1464 of the security API 1440 allows registration (e.g., credential / key allocation, etc.) after manufacturing.

[0202] Export API 1426 is configured to facilitate the transmission of messages (e.g., command messages, etc.) from IoT hub 1420. These messages can be used to issue commands to devices (e.g., device 1402, web / mobile device 1406, etc.) to take certain actions. After receiving and processing the command, the device can respond with a message indicating whether the action is completed, rejected, or abandoned.

[0203] The ingress API 1428 is configured to facilitate receiving messages from devices (e.g., the device 1402, the web / mobile device 1406, etc.). The messages received from the devices can include device information messages, telemetry messages, or yet another message. The device information messages can be used to define and / or update properties of the devices and / or supported commands. The telemetry messages can be used to log telemetry data for later retrieval and use. The telemetry data can be stored in the time series API 1474.

[0204] Still referring to Figure 14 The notification API 1484 can be configured to communicate with an external notification service 1486 (e.g., Azure Notification Hubs, etc.). Such communication can facilitate providing notifications to devices (e.g., the device 1402, the web / mobile device 1406, etc.). The email API 1488 can be configured to communicate with an external email service 1490 (e.g., SendGrid, etc.). Such communication can facilitate providing emails to devices (e.g., the device 1402, the web / mobile device 1406, etc.).

[0205] Device registration

[0206] When a new device is introduced into an IoT environment, such as the IoT environment 1100 described above, the device needs to be registered within the IoT environment to ensure proper security and operation of the device within the IoT environment. As described above, devices incorporated into an IoT environment can include the HVAC device 408, the smart connected device 1102, etc. Turning now to Figure 16 According to some embodiments, a process 1600 for registering a device within an IoT environment is shown. In one embodiment, the process 1600 can be associated with the device management techniques concept 1108 described above. At process block 1602, a firmware token for a device to be registered is obtained. The firmware token can be used to authorize a request to register the device. The firmware token can further represent an identity of the device to be registered. For example, the firmware token can establish what permissions the device has in the system. The firmware token can further establish one or more access levels of the device. In one embodiment, the firmware token can be stored in the token storage 1445 of the security API 1440.

[0207] In one embodiment, the firmware token represents a set of claims that can be used to restrict permissions of a client (e.g., HVAC device 408, smartly connected device 1102, etc.) when using a secure system. For example, the firmware token can restrict permissions of a client when using an IMS secure endpoint, such as an HTTP API. As described above, using a firmware token for a security model can also be referred to as a claims-based security model. The firmware token needs to include various claims, but the firmware token can generally include any string of data as a claim. For example, an object claim can be a consistent user ID. This claim can be used for all firmware tokens that are not non-user tokens. In some embodiments, a client can request a firmware token from an IMS, and then the client can send the firmware token to an IMS secure endpoint. In one embodiment, the firmware token can be sent to an IMS secure endpoint using bearer authorization in an HTTP authorization header for an HTTP-based API. In some embodiments, the firmware token can be time-limited. For example, a firmware token can be valid for one hour, but some firmware tokens can be available for more than one hour or less than one hour. In some embodiments, the firmware token is a JSON Web Token (JWT). A JWT uses open standards to encode claims as JSON objects. The firmware token can provide abstraction through different authorization constructs of a single token that alternative resources understand (e.g., username and password, assertions, etc.). This abstraction can enable issuance of firmware tokens that are valid for a short period of time.

[0208] At process block 1604, a new device can be registered with the IoT environment. In one embodiment, an API is used to register the device. For example, the application API 1460 can register the device. The application API 1460 can need the firmware token obtained at process block 1602. The application API 1460 can further need to provide a unique device ID associated with the new device to be registered. In one embodiment, the unique device ID is provided by the device manufacturer. For example, the unique device ID can be located on the device itself for reference. In one embodiment, the unique device ID is a media access control (MAC) address. In other embodiments, the unique device ID can be a device serial number, a device ID code, or other unique identifier. Once the appropriate authentication has been provided (e.g., the firmware token and the unique device ID), the device is registered in a file database of the IoT environment associated with the security API 1440, such as via the device storage 1446. The file database can contain a list of all devices registered in the IoT environment. In one embodiment, the file database is from the ​The security API can further generate a primary key and a secondary key at the time of registering the device. The primary key can be used to claim the device, as described below.

[0209] Once the device is registered, a device shadow is generated at process block 1606. The device shadow can be a virtual representation of the physical device being registered. In one embodiment, the device shadow is a JSON blob representing the physical device. The device shadow can allow other devices (real or virtual) within the IoT environment to read one or more data points associated with the device shadow. For example, the physical device can pass data point values to the device shadow to allow the data point values to be readable by other devices in the IoT environment. In some embodiments, other devices within the IoT environment can be able to write values to the device shadow. These values can then be passed from the device shadow to the physical device to allow parameters to be changed in the physical device. In one embodiment, the device shadow is created based on a template associated with the particular device. For example, where the device is a sensor, a virtual device can be generated to have data points associated with the sensor, such as a temperature data point where the sensor is a temperature sensor. In some embodiments, the template can be a standard template stored within the IoT environment. In other embodiments, the template can be provided by a manufacturer associated with the physical device. For example, once the unique device ID is known, the IoT environment can query a database associated with the manufacturer of the physical device for a template associated with the physical device for use in generating the shadow device.

[0210] At process block 1608, the device shadow is updated. Updating the device shadow can include including additional data points that can not be included in the template used to generate the device shadow. For example, where the IoT environment generates the device shadow using a pre-existing template, certain attributes and data points can not be included in the template, depending on the particular extent of the template. As a more particular example, if the physical device being registered is a temperature sensor, the IoT environment can select a template associated with a standard temperature sensor. However, if the temperature sensor includes additional functionality, such as the ability to provide humidity data, this additional functionality can be communicated to the IoT environment and the device shadow can be updated to reflect the additional data points. Thus, the pre-existing template can be compared to the attributes and data points of the physical device. In some embodiments, the attributes and data points associated with the physical device can be provided by a user. However, in some examples, the physical device can broadcast particular attributes and data points to the data platform 1400, such as to the application API 1460.

[0211] Finally, at process block 1610, the physical device is declared. Declaring the physical device allows the data collected by the physical device to be provided to a user view. Declaring the physical device can further allow secure communication from the cloud-based server to the physical device. Declaring the device can further provide the user with the ability to link other services (such as if a cloud (IFTTT) service) to communicate with the physical device on behalf of the user. In one embodiment, the security API 1440 uses the unique ID and the primary key generated at process block 1604 to declare the device. In some embodiments, the security API 1440 can require the unique ID, the primary key, and a firmware token for registering the device. In some embodiments, the device is declared via a declare device module 1452 within the identity API 1450.

[0212] Turning now to Figure 17 , a flow diagram illustrating data flow 1700 during the physical device registration process 1600 is shown in detail. In some embodiments, the data flow 1700 is performed by the security, privacy, access control, and compliance management technology concepts 1190, or via the data platform 1400 as described above. At process block 1702, a create device command is provided. The create device command can generate an add device instruction 1704 within a security logic API 1706. In some embodiments, the security logic API 1706 can be part of the security API 1440 described above. The security logic API 1706 can then issue a register device command at process block 1708. The register device command can cause an initialize device command to be generated by the security logic API 1706 at process block 1710. The initialize device command can provide a signal to the physical device to instruct the device to perform the necessary initialization process. The initialization process can configure the physical device for full communication on one or more communication networks. Initializing the physical device can also include instructing the physical device to provide certain information to the IoT environment 1100 and / or the security logic API 1706. Once the device has been initialized, a random key can be created for the device at process block 1712, as described above. In one embodiment, a primary key and a secondary key can be generated at process block 1712. In other embodiments, the register device command can initiate an overwrite process at process block 1714, where the physical device being registered was previously registered within the IoT environment 1100 and / or the data platform 1400. The overwrite process can replace the data currently associated with the previously registered physical device with the newly registered physical device. In some embodiments, the user can be asked if they want to overwrite the previously registered physical device.

[0213] The register device command can further generate an add device command that is provided to the device repository 1716 (e.g., the device storage 1446 of the data platform 1400) at process block 1718. Further, at process block 1718, the device repository 1716 can determine whether the new physical device is currently present in the repository. If the device is currently present, the associated shadow device can be read at process block 1720. In one embodiment, the data points associated with the shadow device are read at process block 1722. Additionally, if it is determined at process block 1718 that the device is currently present, the file repository 1730 can read the shadow device at process block 1721. In further embodiments, the data points associated with the shadow device are read by the file repository 1730 at process block 1721. If it is determined at process block 1718 that the device is not present, the add device command is provided to the device repository 1716 at process block 1722. At process block 1724, a set authentication command can be issued to establish one or more authentication parameters associated with the physical device being registered. At process block 1726, the manager client registry can be read. The manager client registry can include relationships associated with one or more devices within the IoT environment 1100. Thus, the device repository 1716 can determine the relationships (if any) associated with the new physical device. Once the manager client registry has been read, the device repository 1716 can provide an add device asynchronous command to the device registry module 1422 within the IoT hub 1420 at process block 1728. The add device asynchronous command can register the device within the IoT hub 1420, and by extension, within the IoT environment 1100. At process block 1727, the device can be declared.

[0214] The file repository 1730 can also receive an add device command at process block 1732. In some examples, the file repository receives the add device command when it is determined at process block 1718 that the device is currently present. In one embodiment, the file repository 1730 can be associated with the security API 1440. At process block 1738, a read client command is generated. The client command can read the clients within the IoT environment that can be associated with the new physical device. At process block 1742, a file associated with the new physical device can be created in the file database 1740. The file database 1740 can contain a list of all devices registered within the IoT environment. In one embodiment, the file database 1740 is in a database from

[0215] ​​At process block 1744, an update device command can be received by the data platform 1400. The update device command can update a registered physical device in the IoT environment 1100 with one or more device attributes 1746. The one or more device attributes can include a device ID 1748, a device status 1750, a build quality 1752, a product version 1754, or other attributes associated with the physical device. Then, at process block 1756, the attributes of the registered physical device can be updated within the security logic API 1706. Finally, the registered physical device can then be updated within the device registry module 1422 at process block 1758.

[0216] Turning now to Figure 18 According to some embodiments, a block diagram illustrating a distributed BMS device 1800 is shown. The distributed BMS device 1800 can be the smart, networked device 1102 or the HVAC equipment 408 as described above. The distributed BMS device 1800 can further be the gateway 1128. In some embodiments, the distributed BMS device 1800 can be a virtual device on a cloud-based server (e.g., the cloud-based server 1210). In other embodiments, the distributed BMS device 1800 can be a service provided by a cloud-based server. The distributed BMS device 1800 can include a processing circuit 1802 and a network interface 1804.

[0217] The network interface 1804 can allow the distributed BMS device 1800 to communicate with an IP network 1806. In some embodiments, the network interface 1804 can communicate with the IP network 1806 as well as one or more other non-IP networks (e.g., BACnet). The network interface 1804 can be or include a wired or wireless communication interface (e.g., a socket, an antenna, a transmitter, a receiver, a transceiver, a wire terminal, etc.) for data communication with the IP network 1806. In embodiments, communication via the network interface 1804 can be direct (e.g., local wired or wireless communication) or via a communication network (e.g., a WAN, the Internet, a cellular network, etc.). For example, the network interface 1804 can include an Ethernet card and port for sending and receiving data via an Ethernet-based communication link or network. In another example, the network interface 1804 can include a Wi-Fi transceiver for communication via a wireless communication network. In another example, the network interface 1804 can include a cellular or mobile phone communication transceiver. In one embodiment, the network interface 1804 is a power line communication interface. In other embodiments, the network interface 1804 is an Ethernet interface. As described above, the network interface 1804 can allow the distributed BMS device 1800 to communicate with the device 1402.

[0218] The processing circuit 1802 is shown including a processor 1808 and a memory 1810. The processor 1808 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 1808 can be configured to execute computer code or instructions stored in memory 1810 or received from other computer readable media (e.g., CDROM, network storage devices, remote servers, etc.).

[0219] The memory 1810 can include one or more devices (e.g., memory units, memory device, storage devices, etc.) for storing data and / or computer code for completing and / or facilitating the various processes described in the present disclosure. The memory 1810 can include random access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, temporary storage devices, non-volatile memory, flash memory, optical memory, or any other suitable memory for storing software objects and / or computer instructions. The memory 1810 can include database components, object code components, script components, or any other types of information structures for supporting various activities and information structures described in the present disclosure. The memory 1810 can be communicably connected to the processor 1808 via the processing circuit 1802 and can include computer code for executing (e.g., by the processor 1808) one or more processes described herein. For example, the memory 1810 can contain executable code for the device registration process 1600 described above.

[0220] The memory 1810 can include an IoT hub, such as the IoT hub 1420. The IoT hub 1420 can include a device registry module 1422. The device registry module 1422 can perform the device registration process 1600 described above. As described above, the device registry module 1422 can function as a device registration service for registering devices in a distributed BMS system. In one embodiment, the device registry module 1422 can communicate with the security API 1440 to access one or more modules associated with the security API 1440, such as the device store 1446 and the token store 1445, for the purpose of performing the device registration process 1600. The memory 1810 can further include a device shadow module 1812. The device shadow module 1812 can store one or more device shadows associated with HVAC devices in a distributed BMS, such as the device 1402. While not shown, it is contemplated that the memory 1810 can include some or all of the elements of the data platform 1400 described above. In some embodiments, there can be multiple distributed BMS devices in a distributed BMS, and the elements of the data platform 1400 can be distributed among several BMS devices, such as the system 408, in the distributed BMS. For the purposes of this disclosure, the terms distributed BMS and IoT environment should be understood to be interchangeable.

[0221] Configuration of example embodiments

[0222] The construction and arrangement of the systems and methods as shown in the various example embodiments is illustrative only. Although only a few embodiments have been described in detail, many modifications are possible (e.g., variations in sizes, dimensions, structures, shapes and proportions of the various elements, values of parameters, mounting arrangements, use of materials, colors, orientations, etc.). For example, the position of elements can be reversed or otherwise varied and the nature or number of discrete elements or positions can be altered or varied. Accordingly, all such modifications are intended to be included within the scope of the present disclosure. The order or sequence of any process or method steps can be varied or re-sequenced without departing from the generality of the claims. Other substitutions, modifications, changes, and omissions can be made in the design, operating

[0223] The present disclosure contemplates methods, systems, and program products on any machine-readable media for accomplishing various operations. The embodiments of the present disclosure can be implemented using existing computer processors or by a special purpose computer processor for an appropriate system, or by a hardwired system. Embodiments within the scope of the present disclosure include program products comprising machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media can include RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, etc., or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a machine, the machine properly views the connection as a machine-readable medium. Thus, any such connection is properly termed a machine-readable medium. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.

[0224] Although the figures illustrate the method steps in a specific order, the order of steps can differ from what is depicted. Two or more steps can be performed concurrently or with partial concurrence. Such variation would depend on the software and hardware systems chosen and on designer choice. All such variations are within the scope of the disclosure. Likewise, software implementation could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various connection steps, processing steps, comparison steps and decision steps.

Claims

1. A method for registering HVAC devices in a building management system (BMS), the method comprising: Obtain a firmware token for the HVAC device from the registration service, wherein the firmware token establishes one or more licenses for the HVAC device; The registration of the HVAC device is authorized using the firmware token; The HVAC device is registered to the registration service's database using a unique device identifier; Based on the one or more licenses for the HVAC device established by the firmware token, credentials associated with the HVAC device are determined in the database of the registration service; The credentials are provided to the HVAC unit for the HVAC unit to operate in accordance with the one or more licenses; A device shadow is generated based on a device template, the device template including one or more data points associated with the HVAC device, wherein the device shadow provides a virtual representation of the HVAC device within the BMS; as well as At least one of the following: (i) reading the value of the one or more data points from the device shadow via the second device of the BMS, or (ii) writing the value of the one or more data points to the device shadow via the second device of the BMS.

2. The method of claim 1, wherein the device template is associated with the unique device identifier.

3. The method as described in claim 1, wherein, The registration service is implemented using one or more cloud-based servers.

4. The method of claim 1, further comprising: The device shadow is updated by comparing one or more data points of the device template with one or more data points of the HVAC device, and by using at least one data point of the HVAC device that is different from the data points of the device template.

5. The method of claim 1, wherein, The firmware token is only valid for a limited time period.

6. The method of claim 1, further comprising: The user declares the HVAC device, wherein the declaration of the HVAC device allows the user to manage the HVAC device within the BMS.

7. The method of claim 1, wherein, The one or more licenses for the HVAC device include one or more features that the HVAC device can access.

8. The method of claim 1, wherein, The HVAC device is configured to transmit time-series data to the BMS after the HVAC device is registered.

9. A building management system (BMS), the system comprising: A distributed BMS device, the distributed BMS device including a processor, the processor being configured to: Obtain a firmware token for the HVAC device from the registration service, wherein the firmware token establishes one or more licenses for the HVAC device; The HVAC device is registered to the registration service's database using a unique device identifier; Based on the one or more licenses for the HVAC device established by the firmware token, credentials associated with the HVAC device are determined in the database of the registration service; The credentials are provided to the HVAC unit for the HVAC unit to operate in accordance with the one or more licenses; A device shadow is generated based on a device template, the device template including one or more data points associated with the HVAC device, and the device shadow provides a virtual representation of the HVAC device within the BMS; as well as At least one of the following: (i) reading the value of the one or more data points from the device shadow via the second device of the BMS, or (ii) writing the value of the one or more data points to the device shadow via the second device of the BMS.

10. The system of claim 9, wherein, The device template is associated with the unique device identifier.

11. The system of claim 10, wherein, The device template is based on the device type of the HVAC device determined using the unique device identifier.

12. The system of claim 9, wherein, The processor is further configured to compare data points of the device shadow with one or more data points of the HVAC device.

13. The system of claim 12, wherein, The processor is further configured to update the device shadow using the data points of the HVAC device that are different from the data points of the device shadow.

14. The system of claim 9, wherein, The HVAC device is declared by the user, and the declaration of the HVAC device allows the user to manage the HVAC device within the BMS.

15. The system of claim 9, wherein, The one or more licenses for the HVAC device include one or more features that the HVAC device can access.

16. The system of claim 9, wherein, The unique device identifier is one of the media access control address and serial number of the HVAC device, and the HVAC device is configured to transmit time-series data to the BMS after the HVAC device is registered.

17. The system of claim 9, wherein, The distributed BMS device is one of a controller and a cloud-based server.

18. A method for registering Internet of Things (IoT) HVAC devices in a building management system (BMS), the method comprising: Obtain a firmware token for the IoT HVAC device from the registration service, wherein the firmware token establishes one or more licenses for the IoT HVAC device; The registration of the IoT HVAC device is authorized using the firmware token; The IoT HVAC device is registered to the registration service's database using a unique device identifier; Based on the one or more licenses for the IoT HVAC device established by the firmware token, credentials associated with the IoT HVAC device are determined in the database of the registration service; The credentials are provided to the IoT HVAC device for the IoT HVAC device to operate in accordance with the one or more licenses; as well as The IoT HVAC device is declared by the user, wherein the declaration of the IoT HVAC device allows the user to manage the IoT HVAC device within the BMS; A device shadow is generated based on a device template, the device template including one or more data points associated with the IoT HVAC device, wherein the device shadow provides a virtual representation of the IoT HVAC device within the BMS; and The values ​​of one or more data points are transmitted from the device shadow to the IoT HVAC device to change one or more parameters within the IoT HVAC device.

19. The method of claim 18, wherein the device template is associated with the unique device identifier.

20. The method of claim 18, further comprising: The data points of the device shadow are compared with one or more data points of the IoT HVAC device; as well as The device shadow is updated using the data points of the IoT HVAC device that are different from the data points of the device shadow.

21. A method for registering HVAC devices in a distributed building management system (BMS), the method comprising: A request token, configured to authorize the registration of the HVAC unit; Receive the token at the registration service; Receive a unique ID associated with the HVAC device at the registration service; Register the HVAC device to the file database of the registration service; Generate a device shadow associated with the HVAC unit; The device shadow is stored in the memory of the distributed BMS; as well as At least one of the following: (i) reading the value of one or more data points from the device shadow via the second device of the BMS, or (ii) writing the value of the one or more data points to the device shadow via the second device of the BMS; Generating the device shadow includes: creating a category device shadow based on a device template, wherein the device template includes one or more data points associated with the HVAC device; and The token establishes what permissions the HVAC device has in the distributed building management system (BMS).

22. The method of claim 21, wherein, The device template is based on the device type of the HVAC device.

23. The method of claim 21, further comprising: The data points of the device template are compared with one or more data points of the HVAC device.

24. The method of claim 23, further comprising: The device shadow is updated using the data points of the HVAC device that are different from the data points of the device template.

25. The method of claim 21, further comprising: The HVAC device is declared to provide secure communication between the HVAC device and the distributed building management system.

26. The method of claim 21, wherein, The token determines one or more permissions for the HVAC device and further establishes one or more access levels for the HVAC device.

27. The method of claim 21, wherein, The unique ID is one of the media access control address and serial number of the HVAC device.

28. A distributed building management system, the system comprising: HVAC equipment; as well as A distributed BMS device includes a processor, wherein the processor is configured to: A request token, configured to authorize the registration of the HVAC unit; Receive the token at the registration service; Receive a unique ID associated with the HVAC device; Register the HVAC device to the file database of the registration service; Within the data platform of the distributed BMS, a device shadow associated with the HVAC unit is generated; and At least one of the following: (i) reading the value of one or more data points from the device shadow via the second device of the BMS, or (ii) writing the value of the one or more data points to the device shadow via the second device of the BMS; Generating the device shadow includes: creating a category device shadow based on a device template, wherein the device template includes one or more data points associated with the HVAC device; and The token establishes what permissions the HVAC device has in the distributed BMS.

29. The system of claim 28, wherein, The device template is based on the device type of the HVAC device.

30. The system of claim 28, wherein, The processor is further configured to compare the data points of the device template with one or more data points of the HVAC device.

31. The system of claim 30, wherein, The processor is further configured to update the device shadow using the data points of the HVAC device that are different from the data points of the device template.

32. The system of claim 28, wherein, The processor is further configured to declare the HVAC device, wherein the declaration of the HVAC device provides secure communication between the HVAC device and the distributed building management system.

33. The system of claim 28, wherein, The token determines one or more permissions for the HVAC device and further establishes one or more access levels for the HVAC device.

34. The system of claim 28, wherein, The unique ID is one of the media access control address and serial number of the HVAC device.

35. The system of claim 28, wherein, The distributed BMS device is one of an HVAC unit, a BMS controller, and a cloud-based server.

36. A method for registering Internet of Things (IoT) HVAC devices in a distributed building management system (BMS), the method comprising: A request token, configured to authorize the registration of an IoT HVAC device; Receive the token at the registration service; Receive a unique ID associated with the IoT HVAC device; Register the IoT HVAC device to the file database of the registration service; Within the data platform of the distributed BMS, a device shadow associated with the IoT HVAC device is generated; The statement declares the IoT HVAC device, wherein the statement declares the IoT HVAC device to provide secure communication between the IoT HVAC device and the distributed building management system; and The device shadow transmits the values ​​of one or more data points to the IoT HVAC device to change one or more parameters within the IoT HVAC device; Generating the device shadow includes: creating a category device shadow based on a device template, wherein the device template includes one or more data points associated with the IoT HVAC device and is based on the device type of the IoT HVAC device; and The token establishes what permissions the IoT HVAC device has in the distributed building management system (BMS).

37. The method of claim 36, wherein the token further establishes one or more access levels for the IoT HVAC device.

38. The method of claim 37, further comprising: The data points of the device template are compared with one or more data points of the IoT HVAC device; as well as The device shadow is updated using the data points of the IoT HVAC device that are different from the data points of the device template.

Images