Building management system with linked thermodynamic models for HVAC equipment

A building management system (BMS) includes one or more sensors that measure a variable state or condition in the BMS and a plurality of BMS devices that operate to affect the variable state or condition measured by the one or more sensors. Each of the BMS devices stores a thermodynamic block that models the BMS device. Each of the thermodynamic blocks includes a list of connections and a list of stats. The connections define one or more inputs to the thermodynamic block and one or more outputs from the thermodynamic block. The stats define one or more relationships between the inputs and the outputs. Each of the BMS devices includes a solver configured to perform calculations using the stats and connections defined by the thermodynamic block stored within the BMS device.

BACKGROUND

The present invention relates generally to building management systems. The present invention relates more particularly to a building management system which uses thermodynamic models for HVAC equipment.

A building management system (BMS) is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. A BMS can include a heating, ventilation, or air conditioning (HVAC) system, a security system, a lighting system, a fire alerting system, another system that is capable of managing building functions or devices, or any combination thereof.

Typical BMSs use point-based models to represent data captured and stored by the BMS. Point-based models represent a facility as a collection of points and often require considerable commissioning time to properly define and configure each of the points. Some point-based models use look-up tables to store definitions for the data points and often lack sufficient definition to provide meaning to the data points. The architecture of conventional point-based models typically provides minimal extractable information upon which advanced control strategies can be based. Additionally, some point-based models require closed control loops to function properly and have a high capital cost with minimal scalability. It would be desirable to provide a BMS with a different type of data model to overcome these and other drawbacks of conventional point-based models.

SUMMARY

One implementation of the present disclosure is a building management system (BMS) including one or more sensors that measure a variable state or condition in the building management system and a plurality of BMS devices that operate to affect the variable state or condition measured by the one or more sensors. Each of the BMS devices stores a thermodynamic block that models the BMS device. Each of the thermodynamic blocks includes a list of connections and a list of stats. The connections define one or more inputs to the thermodynamic block and one or more outputs from the thermodynamic block. The stats define one or more relationships between the inputs and the outputs. Each of the BMS devices includes a solver configured to perform calculations using the stats and connections defined by the thermodynamic block stored within the BMS device.

In some embodiments, the plurality of BMS devices include a plurality of atomic BMS devices including lowest level equipment in the building management system. The plurality of BMS devices may further include a controller that operates to control a subsystem including the plurality of atomic BMS devices.

In some embodiments, each of the atomic BMS devices stores an atomic thermodynamic block that represents the atomic BMS device and models a performance of the atomic BMS device. In some embodiments, the controller stores a non-atomic thermodynamic block that represents the subsystem including the plurality of atomic BMS devices and models a performance of the subsystem.

In some embodiments, the non-atomic thermodynamic block encompasses each of the atomic thermodynamic blocks. The controller may be configured to calculate an output from the non-atomic thermodynamic block by summing one or more outputs from the atomic thermodynamic blocks.

In some embodiments, the controller is configured to request the atomic thermodynamic blocks from the plurality of atomic BMS devices. The plurality of atomic BMS devices may be configured to send the atomic thermodynamic blocks to the controller in response to the request. The controller may be configured to update the non-atomic thermodynamic block stored within the controller using the atomic thermodynamic blocks received from the plurality of atomic BMS devices.

In some embodiments, wherein the solver is configured to access the list of connections and the list of stats provided by a thermodynamic block and identify one or more time series data inputs defined by the list of connections. The time series data inputs may be measured by the one or more sensors. The solver may identify one or more functions, defined by the list of stats, that use the identified time series data inputs. In some embodiments, the solver calculates one or more virtual data points not measured by the one or more sensors by applying the identified functions to the identified time series data inputs.

In some embodiments, the solver is configured to access the list of connections and the list of stats provided by a thermodynamic block and identify one or more data inputs defined by the list of connections. The identified data inputs may be projected future data inputs. The solver may identify one or more functions, defined by the list of stats, that use the projected future data inputs. In some embodiments, the solver simulates a future performance of the building management system by applying the identified functions to projected future data inputs.

In some embodiments, the solver is configured to identify one or more sub-blocks encompassed by a non-atomic thermodynamic block. The solver may retrieve, from the one or more identified sub-blocks, the connections and the stats provided by the one or more identified sub-blocks. The solver may generate a system of equations using the retrieved connections and stats. In some embodiments, the solver solves the system of equations to calculate one or more unknown values not measured by the one or more sensors.

In some embodiments, the solver is configured to identify the connections and the stats provided by one or more of the thermodynamic blocks and generate a system of equations using the identified connections and stats. The system of equations may include a plurality of variables. The solver may determine, for each of the plurality of variables with an unknown value, whether the unknown value can be calculated using the system of equations based on one or more of the plurality of variables with a known value. In response to a determination that the unknown value cannot be calculated using the system of equations, the solver may determine one or more additional constraints required to calculate the unknown value.

In some embodiments, the solver is configured to generate a user interface including the one or more additional constraints required to calculate the unknown value and a recommended action to establish the one or more additional constraints. In some embodiments, the recommended action includes at least one of installing a new sensor to measure a variable with an unknown value or defining a new connection between thermodynamic blocks.

Another implementation of the present disclosure is a building management system (BMS) including one or more sensors that measure a variable state or condition in the building management system. The BMS includes a plurality of atomic BMS devices that operate to affect the variable state or condition measured by the one or more sensors. Each of the atomic BMS devices stores an atomic thermodynamic model that represents the atomic BMS device and models a performance of the atomic BMS device. The BMS further includes a controller that operates to control a subsystem including the plurality of atomic BMS devices. The controller stores a non-atomic thermodynamic model that represents the subsystem and models a performance of the subsystem. Each of the thermodynamic models includes a list of connections that define one or more connections to other thermodynamic models and a list of stats that define one or more calculations based on the connections.

In some embodiments, the thermodynamic models include a first thermodynamic model representing a first thermodynamic system and a second thermodynamic model representing a second thermodynamic system. The connections to other thermodynamic models may represent an output from the first thermodynamic system that is provided as an input to the second thermodynamic system.

In some embodiments, the BMS includes a connections database that stores a plurality of connection objects. Each of the connection objects may correspond to a connection listed in at least one of the thermodynamic models and may define attributes of the corresponding connection. In some embodiments, the BMS includes a stats database that stores a plurality of stat objects. Each of the stat objects may correspond to a stat listed in at least one of the thermodynamic models and may define functional relationships between inputs and outputs of the thermodynamic model. In some embodiments, the connections define one or more inputs to the thermodynamic model and one or more outputs of the thermodynamic model. The stats may define one or more relationships between the inputs and the outputs.

In some embodiments, the controller is configured to request the atomic thermodynamic models from the plurality of atomic BMS devices. The plurality of atomic BMS devices may be configured to send the atomic thermodynamic models to the controller in response to the request. The controller may be configured to update the non-atomic thermodynamic model stored within the controller using the atomic thermodynamic models received from the plurality of atomic BMS devices.

In some embodiments, each of the BMS devices includes a solver configured to perform calculations using the stats and connections defined by the thermodynamic model stored within the BMS device.

In some embodiments, the solver is configured to access the list of connections and the list of stats provided by a thermodynamic model and identify one or more time series data inputs defined by the list of connections. The time series data inputs may be measured by the one or more sensors. The solver may identify one or more functions, defined by the list of stats, that use the identified time series data inputs. In some embodiments, the solver calculates one or more virtual data points not measured by the one or more sensors by applying the identified functions to the identified time series data inputs.

In some embodiments, the solver is configured to identify the connections and the stats provided by one or more of the thermodynamic models and generate a system of equations using the identified connections and stats. The system of equations may include a plurality of variables. The solver may determine, for each of the plurality of variables with an unknown value, whether the unknown value can be calculated using the system of equations based on one or more of the plurality of variables with a known value. In response to a determination that the unknown value cannot be calculated using the system of equations, the solver may determine one or more additional constraints required to calculate the unknown value. The solver may generate a report for presentation to a user via a user interface of the building management system. The report may include a recommended action to establish the one or more additional constraints.

DETAILED DESCRIPTION

Referring generally to the FIGURES, a building management system with linked thermodynamic models for HVAC equipment is shown, according to various exemplary embodiments. A building management system (BMS) is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. A BMS can include a heating, ventilation, or air conditioning (HVAC) system, a security system, a lighting system, a fire alerting system, another system that is capable of managing building functions or devices, or any combination thereof. The BMS described herein uses a linked thermodynamic data model to collect, organize, process, compute, distribute, and manage information in the BMS. The thermodynamic data model may be capable of mapping all of the information collected by the BMS (e.g., sensor data, setpoint data, equipment performance data, etc.) into a single well-defined language that can be applied at any level within the BMS.

In some embodiments, the thermodynamic data model is based on the concept of an atomic thermodynamic system (i.e., the smallest thermodynamic system capable of being modeled). For example, each of the lowest level components of the BMS (e.g., individual chillers, pumps, cooling towers, etc.) may be modeled as atomic thermodynamic systems. Each atomic thermodynamic system may be defined by a set of inputs, outputs, and internal system dynamics. Atomic thermodynamic systems can be linked (e.g., connecting the outputs of one system to the inputs of another system), combined into assemblies, nested within higher level thermodynamic systems, or otherwise placed in relation to each other to define the architecture of the BMS.

In some embodiments, each instance of the thermodynamic data model is referred to as a thermodynamic block. Some thermodynamic blocks may be assemblies containing two or more atomic thermodynamic systems, whereas other thermodynamic blocks may be atomic (i.e., lowest level) thermodynamic systems. Advantageously, the arrangement of thermodynamic blocks relative to each other may provide the architecture of the BMS and the ability to calculate various performance metrics such as power usage and loads. Each BMS device may be capable of calculating its own performance metrics using the thermodynamic block stored within the device and may provide the results of such calculations to higher level devices (e.g., controllers, supervisory systems, etc.).

The use of thermodynamic blocks facilitates the disassembly and reassembly of the thermodynamic model at any junction. This allows the architecture of the thermodynamic model to be distributed across multiple BMS devices (e.g., building equipment, servers, controllers, etc.) for storage and/or computation. Each BMS device may store a thermodynamic block modeling the BMS device or a system controlled by the BMS device within the local memory of the BMS device. For example, a chiller or pump may store an atomic thermodynamic block modeling the chiller or pump, whereas a controller may store a non-atomic thermodynamic block modeling a system or subsystem controlled by the controller. Processing components within the BMS device (e.g., a processor, a processing circuit, etc.) may perform the calculations provided by the stored thermodynamic block. If the thermodynamic data model is distributed across multiple devices, the thermodynamic model can be collected (e.g., transmitted to a central controller or computer system), assembled, processed, and dispatched back with results of the calculations.

Solver modules within each BMS device may be configured to use one or more of the thermodynamic blocks to calculate or estimate data points that are not sampled by the BMS. The solvers may be configured to perform real time calculations and/or batch calculations. Real time calculations may include using time series data from sensors in conjunction with functional relationships defined by various thermodynamic blocks to calculate results. Batch calculations may include solving a system of equations defined by the connections between thermodynamic blocks and/or the functional relationships within each thermodynamic block. For example, the solver modules may be configured to solve the pressure loops within a HVAC system based on one or more known pressure measurements and/or run an advance simulation to predict the future performance of the HVAC system. If one or more required data points are missing, the solver modules may report that insufficient data points are available. In some embodiments, the solver modules are configured to identify and report the missing data points to a user along with recommended actions that can be taken to enhance the thermodynamic model (e.g., installing an additional sensor, defining relationships between thermodynamic blocks, etc.). These and other feature features of the present invention are described in greater detail below.

Referring now toFIG. 1, a perspective view of a building10is shown, according to an exemplary embodiment. Building10is serviced by a building management system including a HVAC system100. HVAC system100may include a plurality of HVAC devices (e.g., heaters, chillers, air handling units, pumps, fans, thermal energy storage, etc.) configured to provide heating, cooling, ventilation, or other services for building10. For example, HVAC system100is shown to include a waterside system120and an airside system130. Waterside system120may provide a heated or cooled fluid to an air handling unit of airside system130. Airside system130may use the heated or cooled fluid to heat or cool an airflow provided to building10. An exemplary waterside system and airside system are described in greater detail with reference toFIGS. 2-3.

Referring now toFIG. 2, a block diagram of a waterside system200is shown, according to an exemplary embodiment. In various embodiments, waterside system200may supplement or replace waterside system120in HVAC system100or may be implemented separate from HVAC system100. When implemented in HVAC system100, waterside system200may include a subset of the HVAC devices in HVAC system100(e.g., boiler104, chiller102, pumps, valves, etc.) and may operate to supply a heated or chilled fluid to AHU106. The HVAC devices of waterside system200may be located within building10(e.g., as components of waterside system120) or at an offsite location such as a central plant.

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

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

Each of dampers316-320may be operated by an actuator. For example, exhaust air damper316may be operated by actuator324, mixing damper318may be operated by actuator326, and outside air damper320may be operated by actuator328. Actuators324-328may communicate with an AHU controller330via a communications link332. Actuators324-328may receive control signals from AHU controller330and may provide feedback signals to AHU controller330. Feedback signals may include, for example, an indication of a 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 actuators324-328), status information, commissioning information, configuration settings, calibration data, and/or other types of information or data that may be collected, stored, or used by actuators324-328. AHU controller330may be an economizer controller configured to use one or more control algorithms (e.g., state-based algorithms, ESC algorithms, PID control algorithms, model predictive control algorithms, feedback control algorithms, etc.) to control actuators324-328.

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

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

Client device368may include one or more human-machine interfaces or client interfaces (e.g., graphical user interfaces, reporting interfaces, text-based computer interfaces, client-facing web services, web servers that provide pages to web clients, etc.) for controlling, viewing, or otherwise interacting with HVAC system100, its subsystems, and/or devices. Client device368may be a computer workstation, a client terminal, a remote or local interface, or any other type of user interface device. Client device368may be a stationary terminal or a mobile device. For example, client device368may be a desktop computer, a computer server with a user interface, a laptop computer, a tablet, a smartphone, a PDA, or any other type of mobile or non-mobile device. Client device368may communicate with BMS controller366and/or AHU controller330via communications link372.

Referring now toFIG. 4, a block diagram of a building management system (BMS)400is shown, according to an exemplary embodiment. BMS400may be implemented in building10to automatically monitor and control various building functions. BMS400is shown to include BMS controller366and a plurality of building subsystems428. Building subsystems428are shown to include a building electrical subsystem434, an information communication technology (ICT) subsystem436, a security subsystem438, a HVAC subsystem440, a lighting subsystem442, a lift/escalators subsystem432, and a fire safety subsystem430. In various embodiments, building subsystems428can include fewer, additional, or alternative subsystems. For example, building subsystems428may also or alternatively include a refrigeration subsystem, an advertising or signage subsystem, a cooking subsystem, a vending subsystem, a printer or copy service subsystem, or any other type of building subsystem that uses controllable equipment and/or sensors to monitor or control building10.

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

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

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

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

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

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

In some embodiments, demand response layer414includes a control module configured to actively initiate control actions (e.g., automatically changing setpoints) which minimize energy costs based on one or more inputs representative of or based on demand (e.g., price, a curtailment signal, a demand level, etc.). In some embodiments, demand response layer414uses equipment models to determine an optimal set of control actions. The equipment models may include, for example, thermodynamic models describing the inputs, outputs, and/or functions performed by various sets of building equipment. Equipment models may represent collections of building equipment (e.g., subplants, chiller arrays, etc.) or individual devices of the building equipment. In some embodiments, each device stores its own equipment model in memory and provides the equipment model to higher level devices (e.g., plant controllers, AHU controllers, subsystem controllers, etc.) in response to a request for the equipment models from the higher level devices.

Demand response layer414may further include or draw upon one or more demand response policy definitions (e.g., databases, XML files, etc.). The policy definitions may be edited or adjusted by a user (e.g., via a graphical user interface) so that the control actions initiated in response to demand inputs may be tailored for the user's application, desired comfort level, particular building equipment, or based on other concerns. For example, the demand response policy definitions can specify which equipment may be turned on or off in response to particular demand inputs, how long a system or piece of equipment should be turned off, what setpoints can be changed, what the allowable set point adjustment range is, how long to hold a high demand setpoint before returning to a normally scheduled setpoint, how close to approach capacity limits, which equipment modes to utilize, the energy transfer rates (e.g., the maximum rate, an alarm rate, other rate boundary information, etc.) into and out of energy storage devices (e.g., thermal storage tanks, battery banks, etc.), and when to dispatch on-site generation of energy (e.g., via fuel cells, a motor generator set, etc.).

Referring now toFIGS. 5-18, a linked thermodynamic data model for HVAC equipment is shown, according to an exemplary embodiment. The thermodynamic data model described herein may be used to collect, organize, process, compute, distribute, and manage information in BMS400. The thermodynamic data model may be capable of mapping all of the information collected by BMS400(e.g., sensor data, setpoint data, equipment performance data, etc.) into a single well-defined language that can be applied at any level within BMS400. In some embodiments, the thermodynamic data model is based on the concept of an atomic thermodynamic system (i.e., the smallest thermodynamic system capable of being modeled). For example, each of the lowest level components of BMS400(e.g., individual chillers, pumps, cooling towers, etc.) may be modeled as atomic thermodynamic systems. Each atomic thermodynamic system may be defined by a set of inputs, outputs, and internal system dynamics. Atomic thermodynamic systems can be linked (e.g., connecting the outputs of one system to the inputs of another system), combined into assemblies, nested within higher level thermodynamic systems, or otherwise placed in relation to each other to define the architecture of BMS400.

In some embodiments, each instance of the thermodynamic data model is referred to as a thermodynamic block. Some thermodynamic blocks may be assemblies containing two or more atomic thermodynamic systems, whereas other thermodynamic blocks may be atomic (i.e., lowest level) thermodynamic systems. Advantageously, the arrangement of thermodynamic blocks relative to each other may provide the architecture of the HVAC system and the ability to calculate various performance metrics such as power usage and loads. Each thermodynamic block may be capable of calculating its own performance metrics and providing the results to higher level assemblies. For example, if an assembly has multiple thermodynamic blocks within it, the overall power consumption of the assembly may be a sum of the individual power consumptions for each thermodynamic block within the assembly.

Additionally, the use of thermodynamic blocks facilitates the disassembly and reassembly of the thermodynamic data model at any junction. This allows the architecture of the data model to be distributed across multiple HVAC devices (e.g., building equipment, servers, controllers, etc.) for storage and/or computation. Each HVAC device may store a thermodynamic block modeling the HVAC device or a system controlled by the HVAC device within the local memory of the HVAC device. For example, a chiller or pump may store an atomic thermodynamic block modeling the chiller or pump, whereas a controller may store a non-atomic thermodynamic block modeling a system or subsystem controlled by the controller. Processing components within the HVAC device (e.g., a processor, a processing circuit, etc.) may perform the calculations provided by the stored thermodynamic block. If the thermodynamic data model is distributed across multiple devices, the data model can be collected (e.g., transmitted to a central controller or computer system), assembled, processed, and dispatched back with results of the calculations.

Referring particularly toFIG. 5, an atomic thermodynamic block500is shown, according to an exemplary embodiment. Thermodynamic block500represents an arbitrary thermodynamic system502and includes a boundary506which separates system502from its surroundings504. The first law of thermodynamics ensures that thermodynamic system502will conserve energy and mass through its inputs, outputs, and interactions with other thermodynamic systems. The second law of thermodynamics provides that this energy is expected to deteriorate in quality over time due to the increasing entropy of system502. Multiple instances of thermodynamic block500can be used to represent each of the lowest level devices within BMS400(e.g., chillers, pumps, heaters, controllers, etc.).

Referring now toFIG. 6, another atomic thermodynamic block600is shown, according to an exemplary embodiment. Thermodynamic block600represents an arbitrary thermodynamic system602and includes a boundary606which separates system602from its surroundings604. In thermodynamic block600, boundary606is assumed to be adiabatic and impermeable such that the only transfer of mass, energy, or information into system602is through connections610,612,614, and616. Connections610-616link system602to surroundings604. Connections610-616may include fluid connections (e.g., pipes, vents, ductwork, etc.) through which mass and energy can transfer through boundary606, solid connections (e.g., walls, housings, etc.) through which heat and other types energy can transfer through boundary606, data connections (e.g., wires, cables, etc.) through which control signals and other types of information can transfer through boundary606, and/or any other type of connection that links system602to surroundings604.

In some embodiments, all of the flows of mass, energy, and information into system602or out of system602are represented by various types of connections610-616in thermodynamic block600. As the number of connections610-616increases, thermodynamic block600more closely models a real-world thermodynamic system and provides a more accurate representation of how system602interacts with its surroundings604. The use of connections610-616to model various transfers through boundary6106appeals to Fourier series and facilitates more accurate representations of system602as mode coefficients are supplied.

Advantageously, thermodynamic block600can be used to represent a real-world thermodynamic system with any level of detail. For example, a lesser number of connections610-616can be used to roughly approximate a thermodynamic system whereas a greater number of connections610-616can be used to model the thermodynamic system in greater detail. The performance of the thermodynamic data model can be scaled based on how much detail is provided in its configuration. For example, more connections610-616can be defined to improve the performance of the thermodynamic data model.

Thermodynamic block600may be used as a building block to model any arbitrarily complex thermodynamic system provided that connections610-616are well-defined. The internal dynamics of system602may be defined according to the properties of system602, various thermodynamic relationships, and/or functions that system602performs to translate inputs into outputs. For example, if system602represents a chiller, the internal dynamics may define the cooling load provided by the chiller (i.e., an output from system602) as a function of the power consumption and/or water consumption of the chiller (i.e., inputs to system602). In this way, the outputs from system602can be defined based on the particular inputs provided to system602and the internal dynamics of system602. Each thermodynamic block in the thermodynamic data model may store various equations, equipment models, or other relationships that define its internal dynamics.

Thermodynamic block600stores internal system dynamics but does not contain any other nested thermodynamic blocks. Therefore, thermodynamic block600is an atomic (i.e., lowest level) thermodynamic block. As described above, atomic thermodynamic blocks may represent lowest level building equipment such as chillers, pumps, etc. Atomic thermodynamic blocks may also represent pipes. An atomic thermodynamic block representing a pipe may have one connection representing fluid flow into the pipe and another connection representing fluid flow out of the pipe. An atomic thermodynamic block representing a pipe may store properties of the pipe such as diameter, material, and length. The atomic thermodynamic block may also store one or more equations which can be used to compute the total resistance between the two fluid flow connections. This provides the ability to calculate the amount of pressure lost within the pipe. A more complex thermodynamic block representing a pipe may include heat transfer connections and may store one or more equations which can be used to calculate the amount of heat transfer through the walls of the pipe.

Referring now toFIG. 7, another thermodynamic block700is shown, according to an exemplary embodiment. Thermodynamic block700represents an assembly of two thermodynamic systems702and703. Systems702and703are separated from surroundings704by boundaries706and705, respectively. Connections710-712represent mass, energy, or information transfers between system702and surroundings704. Similarly, connections714-716represent mass, energy, or information transfers between system703and surroundings704. Systems702-703are separated from each other by a shared boundary707and linked by a connection718through boundary707. Boundaries705-707may be assumed to be adiabatic and impermeable such that all of the mass, energy, and/or information transfers through boundaries705-707occur via connections710-718.

In some embodiments, the dynamics of thermodynamic block700are defined by the dynamics of the systems that thermodynamic block700encapsulates (i.e., systems702-703). Each of systems702-703may be modeled using an atomic thermodynamic block (e.g., thermodynamic block600) and may be defined by specifying the connections and internal system dynamics of each atomic thermodynamic block, as described with reference toFIG. 6. In some embodiments, only the atomic thermodynamic blocks are fully defined with system dynamics in the thermodynamic data model. Higher level assemblies such as thermodynamic block700may inherit the combined dynamics of the atomic thermodynamic blocks that the assembly encapsulates. This structure can be used to develop a tree of relationships where the only fully-defined level of the thermodynamic data model is the lowest level consisting of atomic thermodynamic blocks. Any thermodynamic blocks above the lowest level (i.e., thermodynamic blocks that contain one or more atomic thermodynamic blocks) may have properties and/or dynamics that are computationally inferred from the atomic thermodynamic blocks contained therein.

Referring now toFIG. 8, a diagram of a HVAC system model800based on thermodynamic blocks is shown, according to an exemplary embodiment. Model800represents a chiller plant802, which may be the same or similar to chiller subplant206, as described with reference toFIG. 2. Model800is shown to a variety of linked thermodynamic blocks. The blocks in model800that do not encapsulate any other blocks are atomic thermodynamic blocks which model lowest level building equipment (e.g., individual pumps, individual towers, individual chillers, etc.) in chiller plant802. The other blocks in model800are higher level (i.e., non-atomic) thermodynamic blocks which model subsystems containing one or more atomic thermodynamic blocks. Each of the atomic thermodynamic blocks shown inFIG. 8may be a unique instantiation of the thermodynamic data model in the digital domain. The structure and features of the thermodynamic data model used to create the thermodynamic blocks is described in greater detail with reference toFIGS. 9-14.

Still referring toFIG. 8, the highest level of HVAC system model800is shown to include a primary pumps block804, a chillers and towers block806, and a secondary pumps block808. Each of blocks804-808models a portion of chiller plant802and includes several lower level blocks contained therein. For example, primary pumps block804models a collection of primary pumps and contains several lower level primary pump blocks812,814, and816. Each of primary pump blocks812-816models one of the primary pumps in chiller plant802and is an atomic thermodynamic block. Similarly, secondary pumps block808models a collection of secondary pumps and contains several lower level secondary pump blocks822,824, and826. Each of secondary pump blocks822-826models one of the secondary pumps in chiller plant802and is an atomic thermodynamic block.

Chillers and towers block806models a collection of chillers and a collection of towers in chiller plant802. The collection of chillers is modeled by chiller blocks818and820, which are shown as atomic thermodynamic blocks within chillers and towers block806. The collection of towers is modeled by towers block810, which is shown as a non-atomic thermodynamic block within chillers and towers block806. Towers block810contains several lower level tower blocks828,830, and832and several lower level tower pump blocks834,836, and838. Each of tower blocks828-832models one of the cooling towers in chiller plant802and is an atomic thermodynamic block. Similarly, each of tower pump blocks834-838models one of the tower pumps in chiller plant802and is an atomic thermodynamic block.

As shown inFIG. 8, thermodynamic blocks can exist at any level within HVAC system model800. Some thermodynamic blocks are non-atomic blocks (e.g., primary pumps block804, chillers and towers block806, secondary pumps block808, towers block810, etc.) which model higher level systems, subsystems, and/or collections of equipment within chiller plant802. Other thermodynamic blocks are atomic thermodynamic blocks (e.g., primary pumps blocks812-816, chiller blocks818-820, secondary pumps blocks822-826, towers blocks828-832, tower pump blocks834-838, etc.) which model lowest level equipment in chiller plant802. Non-atomic blocks may contain one or more lower level blocks. The one or more lower level blocks contained within a non-atomic block may be atomic blocks or other non-atomic blocks. For example, chillers and towers block806is shown as a non-atomic block which contains two atomic thermodynamic blocks818-820and a non-atomic thermodynamic block810.

The arrows inFIG. 8represent the inputs and outputs of each thermodynamic block. Arrows connecting thermodynamic blocks indicate that an output from one of the thermodynamic blocks is provided as an input to another of the thermodynamic blocks. For example, arrow840indicates that the output from primary pumps block804is provided as an input to chillers and towers block806. Each of the atomic thermodynamic blocks may store one or more equipment models and/or thermodynamic relationships that can be used to compute the outputs of the atomic thermodynamic block as a function of the inputs. The outputs of a non-atomic thermodynamic block may be computed by summing the output of one or more atomic thermodynamic blocks contained therein. For example, the output from primary pumps block804may be computed by summing the outputs from each of primary pump blocks812-814. In some embodiments, the data model used to construct the thermodynamic blocks is capable of infinite recursion by nesting various lower level thermodynamic blocks within higher level thermodynamic blocks. As long as the outputs and system dynamics of the atomic thermodynamic blocks are defined and calculable, the outputs and system dynamics of any higher level thermodynamic blocks can be determined (i.e., by combining the outputs of the atomic blocks, as previously described).

Advantageously, the calculations defined by each of the thermodynamic blocks may be based solely on the inputs to the thermodynamic block, the internal system dynamics of the thermodynamic block, and the outputs of any lower level blocks contained therein. For example, chillers and towers block806may define calculations based solely on the input from primary pumps block804and the outputs of chiller blocks818-820and towers block810without considering that towers block810includes several lower level blocks828-838. This feature provides a level of abstraction which allows higher level computations to be performed (e.g., by chillers and towers block806) without requiring lower level data to be processed or communicated outside of the lower level blocks (e.g., outside of towers block810).

In some embodiments, HVAC system model800uses the same data structure in both atomic blocks and non-atomic blocks. For example, each of the thermodynamic blocks shown inFIG. 8may be based on the same template or model data structure. In some embodiments, the template data structure used to construct each of thermodynamic blocks804-838includes an attribute which allows lower level blocks to be defined within the thermodynamic block. A thermodynamic block may be classified as a non-atomic block if one or more lower level blocks are defined within the thermodynamic block. Conversely, a thermodynamic block may be classified as an atomic block if no lower level blocks are defined within the thermodynamic block. A template data model which may be used to construct thermodynamic blocks804-838is described in greater detail with reference toFIGS. 9-14.

Referring now toFIG. 9, a template thermodynamic block900is shown, according to an exemplary embodiment. Thermodynamic block900illustrates a template data model which may be used to construct thermodynamic blocks804-838in HVAC system model800. Thermodynamic block900may be used to construct both atomic thermodynamic blocks and non-atomic thermodynamic blocks and may be instantiated to define each component of the HVAC system the digital domain. Relationships between HVAC devices (e.g., fluid flow, physical connections, data communications, entity relationships, etc.) may be modeled by the connections918defined within each instance of thermodynamic block900.

In some embodiments, an instance of thermodynamic block900is stored within the local memory of one or more devices in the HVAC system. Each HVAC device may store an instance of thermodynamic block900which models the HVAC device or a system controlled by the HVAC device. For example, a chiller or pump may store an instance of thermodynamic block900which models the chiller or pump, whereas a controller may store an instance of thermodynamic block900which models a system or subsystem controlled by the controller. In some embodiments, processing components within each HVAC device (e.g., a processor, a processing circuit, etc.) perform calculations defined by thermodynamic block900in order to model the performance of the HVAC device and/or a system or subsystem controlled by the HVAC device.

The calculations performed by a HVAC device may be defined by stats920stored within thermodynamic block900. Stats920may identify formulas or equations that model the performance of the HVAC device and/or define relationships between inputs and outputs for the HVAC device. For example, stats920for a chiller may include an equipment model that defines the cooling load provided by the chiller as a function of the chiller's resource consumption (e.g., electricity, water, etc.). In various embodiments, stats920stores the formulas/equations within thermodynamic block900or within a separate stat object (e.g., stat object1100shown inFIG. 11). The results of such calculations may propagate to higher level HVAC devices such as subsystem controllers and/or BMS controllers. If thermodynamic block900includes any sub-blocks, the stats defined by the sub-block may be processed by the HVAC device in order to propagate information to higher level devices.

In some embodiments, thermodynamic block900defines one or more data points which represent lowest level information available to thermodynamic block900. Data points may include, for example, time series data (e.g., measured or calculated data values), design parameters, control parameters, device setpoints, or other data values which may be used in the identified stats920to perform the various calculations defined by thermodynamic block900. These and other features of thermodynamic block900are described in greater detail below.

Still referring toFIG. 9, thermodynamic block900is shown to include model structure data902, connections and internals904, and plant side information906. Model structure data902may include data specific to a particular instance of thermodynamic block900and the data model. In some embodiments, model structure data902is used to identify, store, or persist the hierarchical structure of the data model. Model structure data902is shown to include a name908, a key910, a grounded indicator912, a sub-blocks attribute914, and a type attribute916. Name908may define a name for thermodynamic block900. The name may be provided by a user or automatically generated and may be stored as a text string. Key910may define a unique GUID used for storage and mapping to outside sources. Grounded indicator912may be used to flag thermodynamic block900as a type of ground when thermodynamic block900is used to solve for unknown values in the HVAC system. Sub-blocks attribute914may define any other thermodynamic blocks that are nested within thermodynamic block900. The information provided by sub-blocks attribute914may be used to construct or reconstruct a hierarchy for the HVAC system. Type attribute916may define a type of thermodynamic block900and may reduce or eliminate polymorphism.

Connections and internals904may define the inputs, outputs, and internal system dynamics of the system or device represented by thermodynamic block900. Connections and internals904is shown to include connections918, stats920, and internals922. Connections918may store a list of connections that define the inputs and outputs of thermodynamic block900. Each of the listed connections may identify a connection object that provides detailed information about the connection. An exemplary connection object is described in greater detail with reference toFIG. 10. Stats920may store a list of stats that define calculations based on connections918. In some embodiments, stats920propagate up to higher level blocks. Each of the listed stats may identify a stat object that provides detailed information about the stat. An exemplary stat object is described in greater detail with reference toFIG. 11. Internals922may store a list of data points that are used internal to the system. For example, internals922may define a design parameter for the modeled HVAC device. Each of the listed data points may identify a data point object that provides detailed information about the data point. An exemplary data point object is described in greater detail with reference toFIG. 12.

Plant side information906may store site-related information within thermodynamic block900. Plant side information906may include values that are common to many types of thermodynamic blocks within the same system or subsystem. Plant side information906is shown to include an out of service attribute924. Out of service attribute924may store a list of times (e.g., ranges of times or dates) that the HVAC equipment represented by thermodynamic block900will be out of service.

Referring now toFIG. 10, a connection object1000is shown, according to an exemplary embodiment. Connection object1000may provide detailed information about one of the connections listed in connections918and may be used to define various types of connections between instances of thermodynamic block900. Connection object1000may be instantiated such that each of the connections listed in connections918corresponds to a unique connection object1000. In various instances, connection object1000may define an energy flow, a mass flow, or an information flow into or out of the thermodynamic system. Information flows may include, for example, command or control data, utility rates, weather data, measured or calculated values from other HVAC components (e.g., sensors, controllers, etc.), or any other type of information which may be generated or used by thermodynamic block900and/or the HVAC component modeled by thermodynamic block900. Connection object1000may be stored within the local memory of the HVAC device that stores thermodynamic block900, retrieved from an external database, or obtained from any other data source.

Connection object1000is shown to include a name1002, a node ID1004, a key1006, a net list1008, net descriptions1010, and all connections1012. Name1002may define a name for connection object1000. The name may be provided by a user or automatically generated and may be stored as a text string. Node ID1004may store an integer value that defines the ID of the connection. In some embodiments, each connection has a unique node ID. Key1006may define a unique GUID used for storage and mapping to outside sources.

Net list1008may store a list defining how the various thermodynamic blocks in the data model are interconnected. For example, net list1008may list each of the thermodynamic blocks in the data model and indicate which connections apply to each thermodynamic block. Connections may be listed by their node IDs in net list1008. For example, net list1008may indicate that a particular thermodynamic block (e.g., “Chiller”) has connections with node IDs1004of “1,” “4,” “2,” “7” and “5.” An exemplary net list is described in greater detail with reference toFIG. 16.

Net descriptions1010may store a list of descriptions for the various connections identified in net list1008. Net descriptions1010may provide a name for each connection and indicate the directionality of the connection with respect to the thermodynamic objects to which the connection applies. For example, net descriptions1010may indicate that the thermodynamic block “Chiller” has connections “ElecIn, “EvapIn,” “EvapOut,” “CondIn,” and “CondOut.” The number of descriptions for each thermodynamic block in net descriptions1010may match the number of listed connections for the thermodynamic block in net list1008. The order in which the descriptions are listed in net descriptions1010may correspond to the order in which the connections are listed in net list1008. For example, the information provided by net list1008and net descriptions1010for “Chiller” indicates that connection “1” is an electrical connection into the chiller, connection “4” is an evaporator connection into the chiller, connection “2” is an evaporator connection out of the chiller, connection “7” is a condenser connection into the chiller, and connection “5” is a condenser connection out of the chiller. Exemplary net descriptions are described in greater detail with reference toFIG. 17.

All connections1012may store a list of references to all of the connections in the thermodynamic model. In some embodiments, the list is a static list stored in a single memory location for all of the connections. All connections1012may index the list by the node ID1004of the connection and provide a name for each of the connections. An exemplary all connections list is described in greater detail with reference toFIG. 18.

In some embodiments, the directionality of each connection is identified by the manner in which the connection is applied to the thermodynamic objects. For example, a connection to the input side of a thermodynamic object may identify the connection as an input connection relative to the thermodynamic object, whereas a connection to the output side of the thermodynamic object may identify the connection as an output connection relative to the thermodynamic object. If a condition occurs where the flow is the opposite of the direction indicated by the connection, a negative value can be assigned to the flow rate to indicate that the flow is opposite the indicated direction. In other embodiments, the directionality of the connection is specified in net descriptions1010.

Still referring toFIG. 10, connection object1000is shown to include fluid attributes1014, utility attributes1016, and information attributes1018. Attributes1014-1018may be provided for certain types of connections to provide a clear indication of what the connection represents. For example, fluid attributes1014may be included in connection objects that describe fluid connections. Fluid attributes1014may characterize the fluid flow between thermodynamic blocks and may include attributes such as temperature, pressure, flow rate, enthalpy, or any other attribute of the fluid flow. Fluid attributes1014may also describe the type of fluid and its various properties (e.g., heat capacity, density, fluid name, etc.).

Utility attributes1016may be included in connection objects that describe utility connections. Utility attributes1016may characterize a flow of a particular utility (e.g., electricity, water, natural gas, etc.) into or out of the system. In some embodiments, utility attributes1016include the usage of the utility, the type of utility, the rate of the utility, and/or the cost of the utility. The type of utility may be specified as a text string, whereas the other utility attributes1016and fluid attributes1014may be specified as time series data.

Information attributes1018may be included in connection objects that describe the flow of information between thermodynamic blocks. Information attributes1018may include, for example, type attributes characterizing the type of information (e.g., setpoint, measured value, calculated value, etc.), units for the information if the information is a numerical value, and/or any other attribute or property that can be used to describe or classify various types of information communicated between devices in BMS400.

Referring now toFIG. 11, a stat object1100is shown, according to an exemplary embodiment. Stat object1100may provide detailed information about one of the stats listed in stats920. In some embodiments, stat object1100is instantiated such that each of the stats listed in stats920corresponds to a unique stat object1100. Stat object1100may define one or more of the calculations associated with thermodynamic block900. For example, stat object1100may include equations, formulas, or other relationships that facilitate calculating the outputs from thermodynamic block900as a function of one or more inputs or other values.

Stat object1100may define a set of connections918and/or other values that are required as inputs to a particular formula to calculate a desired data value. If the required inputs to the formula are available within thermodynamic block900(e.g., received via connections918, stored in internals922, etc.), stat object1100may produce a value. Otherwise, stat object1100may remain null and indicate which values are missing. In some embodiments, stat object1100is identified by the stats920in atomic thermodynamic blocks and inherited by higher level thermodynamic blocks which contain the atomic thermodynamic block.

Stat object1100is shown to include a name1102, a data list1004, stats1106, constants1108, a stat type1110, a result1112, an override1114, a key1116, and compute methods1118. Name1102may define a name for stat object1100. The name may be provided by a user or automatically generated and may be stored as a text string. Data list1104may store a list of inputs to a particular calculation defined by stat object1100. The inputs in data list1104may come from connections918and may be time series data. Stats1106may store a list of previously created stats. The stats listed in stats1106may identify other stat objects which may be used to calculate other values. Constants1108may store a list of quantities that are provided as constants to the calculation defined by stat object1100. Constants1108may be hardcoded or provided from a thermodynamic block's internal data. Type916defines the type of stat object1100and identifies a particular formula or equation used by stat object1100. In various embodiments, the equations or formulas may be stored within stat object1100or retrieved from an external data source. Result1112may store a result of the calculation as a time series data value. Override1114may store a forced override which replaces result1112. Override1114may be used, for example, if a sensor can sample the value calculated by stat object1100or if another component of BMS400has already calculated result1112. Key1116may define a unique GUID used for storage and mapping to outside sources. Compute methods1118may store a method used to gather all of the data and to call the calculation used to compute result1112.

Stat object1100may function similar to how units are managed in the data model. For example, when result1112is requested, stat object1100may determine whether to recalculate result1112. Determining whether to recalculate result1112may include determining whether any changes have occurred to the inputs upon which result1112is based (e.g., data1104, constants1108, etc.). If one or more of the inputs have changed, stat object1100may recalculate and update result1112. However, if none of the inputs have changed, stat object1100may provide the previously cached value of result1112in response to the request.

Advantageously, stat object1100provides a simple and effective method for storing lambda functions for various simple memoryless calculations. The formulas used by stat object1100may be of the form y=f(x, y, z), where x, y, and z are arrays of doubles used for data1104, stats1106, and constants1108respectively. The formula may be called once for each time stamp from the time series except the constant, which acts as a constant at any time stamp.

Referring now toFIG. 12, a data point object1200is shown, according to an exemplary embodiment. Data point object1200may provide detailed information about one of the data points listed in internals922. In some embodiments, data point object1200is instantiated such that each of the data points listed in internals922corresponds to a unique data point object1200. Data point object1200may represent a point-driven aspect of the data model and may contain information that that is used by the HVAC equipment to determine an appropriate set of control actions.

Data point object1200is shown to include a name1202, units1204, a key1206, and a persist attribute1208. Name1202may define a name for data point object1200. The name may be provided by a user or automatically generated and may be stored as a text string. Units1204may identify the units that the data point represents (e.g., ° C., ° F., kPa, Joules, BTUs, etc.). In some embodiments, thermodynamic block900checks user preferences for units and compares them against the current units of the data point specified in units1204. If the data point differs in units to the preferences, the data point may be converted to the desired units, saved, and/or provided in the converted units. Key1206may define a unique GUID used for storage and mapping to outside sources. Persist attribute1208may identify whether the value of the data point can be read and/or written to a database. The persist attribute1208may define whether the data point is persisted through the database.

Referring now toFIG. 13, a time series object1300is shown, according to an exemplary embodiment. Time series object1300may be used to capture and persist time series data in BMS400and may include any number of data-time pairs. Time series object1300may store time series data for any type of data having a time series attribute. For example, time series object1300may store time series data for stats data1104, result1112, override1114, or any other data point that can change over time. In some embodiments, time series object1300is instantiated such that each of the time series listed in data1104corresponds to a unique instance of time series object1300. Time series object1300may provide the data values used to perform the various calculations defined by stat object1100.

Time series object1300is shown to include three primary categories of data: field data1326, model data1314, and supervisory requests1320. Field data1326may include data samples provided by BMS400or various components thereof. For example, field data1326may include data values that are measured by sensors or calculated based on measured values. Field data1326may also include data values that are received from an external data source (e.g., time-varying energy prices, weather data, etc.). Field data1326is shown to include a sample data module1328and inner sample data1330. Sample data module1328may identify the get and set access for inner sample data1330. Sample data module1328may be configured to check the units of inner sample data1330in response to a request for inner sample data1330and convert inner sample data1330to different units if necessary. Sample data module1328may also indicate whether inner sample data1330has changed since the last time inner sample data1330was requested. If inner sample data1330has not changed, the stats based on inner sample data1330may not require updating. Inner sample data1330stores the actual values of the data samples in field data1326.

Model data1314may include data samples that are produced by the mathematics of the data model. For example, model data1314may include result1112calculated using stat object1100. Model data1314is shown to include a data module1316and inner data1318. Data module1316may identify the get and set access for inner data1318. Data module1316may be configured to check the units of inner data1318in response to a request for inner data1318and convert inner data1318to different units if necessary. Data module1316may also indicate whether inner data1318has changed since the last time inner data1318was requested. If inner data1318has not changed, the stats based on inner data1318may not require updating Inner data1318stores the actual values of the data samples in model data1314.

Supervisory requests1320may include outputs from various control that interact with the data model. For example, supervisory requests1320may include a setpoint or control output from a supervisory controller. Supervisory requests1320may indicate that the supervisory controller would like to change the value of model data1314and/or field data1326to the value specified in supervisory requests1328. Supervisory requests1320is shown to include a requested data module1322and inner requested data1324. Requested data module1322may identify the get and set access for inner requested data1324. Requested data module1322may be configured to check the units of inner requested data1324in response to a request for inner requested data1324and convert inner requested data1324to different units if necessary. Requested data module1322may also indicate whether inner requested data1324has changed since the last time inner requested data1324was requested. If inner requested data1324has not changed, the stats based on inner requested data1324may not require updating. Inner requested data1324stores the actual values of the data samples in supervisory requests1320.

Still referring toFIG. 13, time series object1300is shown to include shared attributes1302. Shared attributes1302may apply to any type of time series data that can be stored in time series object1300(e.g., field data1326, model data1314, and/or supervisory requests1320). Shared attributes1302are shown to include times1304, default value1306, priority1308, reliability1310, and a date range1312. Times1304may store an array of times that are present in the system. In some embodiments, times1304stores a time for each data sample in the time series data. Default value1306may provide a default value for the time series data if no other values of the time series data are available. Priority1308may store a priority from BMS400used to write or read the time series data. Reliability1310may store a reliability indicator from BMS400used to identify whether the time series data was reliable at the time of sampling. Date range1312may store a static variable used to define the range of data collected by time series object1300.

Referring now toFIG. 14, a quantity object1400is shown, according to an exemplary embodiment. Quantity object1400may store non-time series data used by thermodynamic block900and/or stat object1000. For example, quantity object1400may store configuration data, model parameters, constant values, or other types of data that do not vary as a function of time. In some embodiments, quantity object1400provides detailed information about one of the constants listed in constants1108. Quantity object1400may be instantiated such that each of the constants listed in constants1108corresponds to a unique instance of quantity object1400.

Quantity object1400is shown to include a data module1402and inner data1404. Data module1402may identify the get and set access for inner data1404. Data module1402may be configured to check the units of inner data1404in response to a request for inner data1404and convert inner data1404to different units if necessary. Data module1402may also indicate whether inner data1404has changed since the last time inner data1404was requested. If inner data1404has not changed, the stats based on inner data1404may not require updating. Inner data1404stores the actual values of the data in constants object1400.

Referring now toFIGS. 15-18, a sample implementation of the thermodynamic data model described with reference toFIGS. 9-14is shown, according to an exemplary embodiment. Referring particularly toFIG. 15, a block diagram illustrating a thermodynamic data model1500of a chiller plant is shown. Data model1500is shown to include several thermodynamic blocks1502-1518. Each of blocks1502-1518may be an instance of thermodynamic block900, as described with reference toFIG. 9. The blocks in model1500that do not encapsulate any other blocks are atomic thermodynamic blocks which model lowest level building equipment and other low level objects. The other blocks in model1500are higher level (i.e., non-atomic) thermodynamic blocks which model systems or subsystems containing one or more atomic thermodynamic blocks.

The atomic thermodynamic blocks are shown to include an electricity supply block1506, an atmosphere block1508, a chiller block1510, a cooling tower block1512, a first pump block1514, a second pump block1516, and a load block1518. Some of atomic thermodynamic blocks1506-1518model individual HVAC devices. For example, chiller block1510may model a chiller, tower block1512may model a cooling tower, and pump blocks1514-1516may model fluid pumps. Other atomic thermodynamic blocks model entities that interact with one or more of thermodynamic blocks1502-1518. For example, electricity supply block1506may model an electric utility provider that supplies electricity to the chiller, cooling tower, and pumps. Atmosphere block1508may model the ambient environment (e.g., weather, temperature, humidity, etc.) surrounding the cooling tower. Load block1518may model a building or other entity to which chiller plant delivers a chilled fluid. For each of atomic thermodynamic blocks1506-1518, the sub-blocks attribute914may be empty since none of the atomic thermodynamic blocks1506-1518contain any sub-blocks.

The non-atomic thermodynamic blocks are shown to include a chiller plant block1504and a global model block1502. Chiller plant block1504contains chiller block1510, tower block1512, and pump blocks1514-1516. Therefore, the sub-blocks attribute914for chiller plant block1504may list chiller block1510, tower block1512, and pump blocks1514-1516. Global model block1502contains chiller plant block1504, electricity supply block1506, atmosphere block1508, and load block1518. Therefore, the sub-blocks attribute914for global model block1502may list chiller plant block1504, electricity supply block1506, atmosphere block1508, and load block1518.

Referring now toFIG. 16, a net list1600defining the connections1-8shown in data model1500is shown, according to an exemplary embodiment. Net list1600is shown as a data table including a key column1602and a value column1604. Key column1602may identify each of the thermodynamic blocks in data model1500that are connected to other thermodynamic blocks. For example, key column1602is shown listing electricity supply block1506, atmosphere block1508, chiller block1510, cooling tower block1512, first pump block1514, second pump block1516, load block1518, and chiller plant block1504. However, key column1602may not list global model block1502since no connections pass through the boundary of global model block1502. Value column1604indicates which of connections1-8apply to each of the thermodynamic blocks listed in key column1604. For example, value column1604specifies that electricity supply block1506has connection1, atmosphere block1508has connection8, etc.

Referring now toFIG. 17, a net descriptions table1700describing the connections1-8defined in net list1600is shown, according to an exemplary embodiment. Net descriptions table1600is shown as a data table including a key column1702and a value column1704. Key column1702may identify each of the thermodynamic blocks in data model1500that are connected to other thermodynamic blocks. Value column1704may provide a description for each of the connections defined in net list1600.

The listing of descriptions in value column1704may be arranged in the same order as the listing of connections in value column1604such that a direct mapping can be applied. For example, value column1604indicates that chiller block1510has connections “1,” “4,” “2,” “7” and “5.” Value column1704indicates that chiller block1510has connections “ElecIn, “EvapIn,” “EvapOut,” “CondIn,” and “CondOut.” This indicates that connection “1” is an electrical connection into chiller block1510, connection “4” is an evaporator connection into chiller block1510, connection “2” is an evaporator connection out of chiller block1510, connection “7” is a condenser connection into chiller block1510, and connection “5” is a condenser connection out of chiller block1510.

In some embodiments, each of the descriptions in value column1704includes an indication of whether the connection is an inbound connection or an outbound connection relative to the associated thermodynamic block. Directionality indications may be provided by a text string in the description value (e.g., “in” or “out”), by another column that explicitly lists the directionality of the connection, or by any other indication that can be provided in net descriptions table1700. In other embodiments, the directionality of each connection is indicated by the side of the thermodynamic block to which the connection is attached (e.g., to the inbound side or outbound side of the thermodynamic block).

Referring now toFIG. 18, an all connections table1800is shown, according to an exemplary embodiment. All connections table1800is shown as a data table having an ID column1802and a name column1804. ID column1802may specify the node ID1004for each of the connections1-8shown in data model1500. Name column1804may include text strings that assign a name to each of the node IDs. The names may be the same or different from the text strings describing each connection in net descriptions table1700. In some embodiments, all connections table1800lists all of the connections in data model1500in a form that can be easily parsed by a user to understand what each of the connections signifies (e.g., whether the connection is an electric connection, a fluid connection, a data connection, etc.).

Advantageously, the graphical representation of the data model shown inFIG. 15and tables1600-1800may provide all of the information required to construct data model1500. The attributes of each thermodynamic block in data model1500can also be used to independently construct data model1500. For example, the sub-block attributes914and connection attributes918of each thermodynamic block can be used to construct data model1500or a portion thereof. In some embodiments, data model1500is distributed across multiple HVAC devices with each HVAC device storing one or more of the thermodynamic blocks relevant to the HVAC device. For example, a chiller may store chiller block1510, whereas controller for the chiller plant may store chiller plant block1504. The controller may request chiller block1510from the chiller if the information contained in chiller block1510is needed for a calculation performed by the controller. This functionality is described in greater detail with reference toFIG. 19.

Referring now toFIG. 19, a block diagram of a building management system (BMS)1900configured to use the thermodynamic data model described with reference toFIGS. 9-18is shown, according to an exemplary embodiment. Although only a few BMS devices are shown inFIG. 19, it is understood that BMS1900may include any number and/or type of BMS devices. For example, BMS1900may be the same or similar to BMS400, as described with reference toFIG. 4. BMS1900is shown to include a BMS controller1910, a HVAC controller1930, a chiller1950, and a pump1970. BMS controller1910may be a top level controller for BMS1900and may be configured to monitor and control a plurality of building subsystems (e.g., a fire safety system, a lift/escalator system, an electrical system, a security system, a HVAC system, a lighting system, etc.), as described with reference toFIG. 4. HVAC controller1930may be a system or subsystem level controller and may be configured to control a HVAC system within BMS1900. Chiller1950and pump1970may be lowest level devices within the HVAC system and may be controlled by HVAC controller1930.

Each of BMS devices1910,1930,1950, and1970is shown to include a communications interface (i.e., communications interfaces1912,1932,1952, and1972) and a processing circuit (i.e., processing circuits1914,1934,1954, and1974). Communications interfaces1912,1932,1952, and1972may be the same or similar to interfaces407and/or409(as described with reference toFIG. 4) and may be configured to facilitate electronic data communications between the components of BMS1900and/or external systems or devices. In various embodiments, the communications may be direct (e.g., local wired or wireless communications) or via a communications network1902(e.g., a WAN, the Internet, a cellular network, etc.). Each communications interface may be communicably connected to the processing circuit of the corresponding BMS device such that the processing circuit and the various components thereof can send and receive data via the communications interface.

Each of processing circuits1914,1934,1954, and1974is shown to include a processor (i.e., processors1916,1936,1956, and1976) and memory (i.e., memory1918,1938,1958, and1978). Processors1916,1936,1956, and1976can be implemented as general purpose processors, application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components. Memory1918,1938,1958, and1978(e.g., memory, memory unit, storage device, etc.) may include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage, etc.) for storing data and/or computer code for completing or facilitating the various processes, layers and modules described in the present application. Memory1918,1938,1958, and1978may be or include volatile memory, non-volatile memory, database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present application. According to an exemplary embodiment, each memory1918,1938,1958, and1978is communicably connected to the processor of the corresponding BMS device via the processing circuit and includes computer code for executing (e.g., by the processing circuit and/or the processor) one or more processes described herein.

As shown inFIG. 19, the thermodynamic data model may be distributed across multiple BMS devices. For example, chiller1950is shown storing a chiller model1960within the local memory1958of chiller1950and pump1970is shown storing a pump model1980within the local memory1978of pump1970. Chiller model1960and pump model1980may be instances of thermodynamic block900representing chiller1950and pump1970, respectively. For example, chiller model1960may be an atomic thermodynamic block (e.g., chiller block1510) modeling chiller1950, whereas pump model1980may be an atomic thermodynamic block (e.g., pump block1514) modeling pump1970. Each of the lowest level devices in BMS1900may store an instance of thermodynamic block900representing the device.

In some embodiments, one or more higher level devices in BMS1900also store a portion of the thermodynamic data model. For example, HVAC controller1930is shown storing a HVAC system model1940within the local memory1930of HVAC controller1930. HVAC system model1940may be an instance of thermodynamic block900representing a HVAC system or portion thereof (e.g., chiller plant block1504) and may list both chiller block1510and pump block1514as sub-blocks914. BMS controller1910is shown storing a global model1920within the local memory1918of BMS controller1910. Global model1920may be an instance of thermodynamic block900representing the entirety of BMS1900(e.g., global model block1502) and may list chiller plant block1504as a sub-block914.

In some embodiments, the devices in BMS1900are configured to transmit their stored thermodynamic blocks to higher level devices in response to a request from the higher level devices. For example, HVAC controller1930may request chiller model1960from chiller1950and/or pump model1980from pump1970. In response to a request from HVAC controller1930, chiller1950may transmit chiller model1960to HVAC controller1930and pump1970may transmit pump model1980to HVAC controller1930. HVAC controller1930may use chiller model1960and pump model1980to update HVAC system model1940. Similarly, BMS controller1910may request HVAC system model1940from HVAC controller1930. In response to a request from BMS controller1910, HVAC controller1930may transmit HVAC system model1940to BMS controller1910. BMS controller1910may use HVAC system model1940to update global model1920.

One benefit of the distributed thermodynamic data model shown inFIG. 19is that each BMS device can perform calculations relating to its own operation and/or performance using local processing hardware. For example, chiller1950may use processing circuit1954and chiller model1960to perform calculations relating to the operation or performance of chiller1950. Similarly, pump1970may use processing circuit1974and pump model1980to perform calculations relating to the operation or performance of pump1970. The calculations may be performed by multiple BMS devices in parallel and may use data locally available to the device. For example, the calculations performed by a particular BMS device may use the thermodynamic block stored within the local memory of the device and/or data points sampled or calculated locally. Advantageously, this distributed processing framework allows for high local data sample rates and fast local control loops without exhausting network communications resources.

In some embodiments, the calculations performed by each BMS device in BMS1900are based on the stats920defined by the instance of thermodynamic block900stored within the memory of the BMS device. For example, the calculations performed by chiller1950may be based on the stats920defined by chiller model1960, whereas the calculations performed by pump1970may be based on the stats920defined by pump model1980. The stats920may be stored locally (e.g., within the local memory of the BMS device) or retrieved from a stats database1994. For example, stats database1994may store a plurality of stat objects1000that define each of the listed stats920.

In various embodiments, the results of the calculations may be stored locally, stored as results1112in stats database1994, and/or provided directly to other BMS devices. This feature allows higher level BMS devices to obtain the results of a lower level calculation and to use such results in a higher level model without requiring the higher level BMS device to be aware of the details of the lower level model or the stat920used to perform the lower level calculation. For example, HVAC controller1930can obtain the result of a calculation performed by chiller1950and apply the result to HVAC system model1940without requiring HVAC controller1930to be aware of the details of chiller model1960and/or the stat920used by chiller1950to calculate the result.

In some embodiments, slower sample rates and slower control loops with more complex control algorithms are executed on higher level BMS devices such as HVAC controller1930and/or BMS controller1910. Controllers1910and1930may be configured to communicate efficiently with lower level BMS devices. For example, chiller1950and pump1970may be configured to cache data and send large blocks of data to higher level devices until the data reaches the highest level of the data model and the entire model is reassembled. This type of communication allows for robust fault detection and diagnostics within BMS1900at the highest level of the data model.

In some embodiments, the time series data1104used by the stats920listed in each thermodynamic block are replicated or stored in a time series database1998(e.g., as time series objects1300) and made available to all of the devices of BMS1900. Similarly, the data points listed in each of the thermodynamic blocks as internals922may be stored in a data points database1996(e.g., as data point objects1200) and the connections listed in each of the thermodynamic blocks as connections918may be stored in a connections database1992(e.g., as connection objects1000). Each of databases1992-1998may be accessible via network1902such that the data stored in databases1992-1998are available to all of the devices of BMS1900.

Still referring toFIG. 19, each of BMS devices1910,1930,1950, and1970is shown to include a solver (i.e., solvers1922,1942,1962, and1982). Each solver may be configured to use one or more thermodynamic blocks of the data model to calculate or estimate data points that are not sampled in BAS1900. Solvers1922,1942,1962, and1982may be configured to perform real time calculations and/or batch calculations. Real time calculations may include using the stats920defined by various thermodynamic blocks to calculate results1112. For example, solver1942within HVAC controller1930may use the stats920defined by HVAC system model1940to calculate results1112of stats920. Solver1942may calculate results1112in real time based on time series data1104available to solver1942. Batch calculations may include solving the pressure loops within the HVAC system or running an advance algorithm inside BMS controller1910. Each of solvers1922,1942,1962, and1982may operate in a similar manner to calculate results1112for each of the stats920defined by various thermodynamic blocks of data model.

In some embodiments, one or more of solvers1922,1942,1962, and1982includes a real time solver. The real time solver may use real-world data samples (e.g., time series data) in conjunction with defined thermodynamic blocks to solve for unknown values in BMS1900. For example, if a thermodynamic block models fluid flow through a length of pipe and the data samples obtained from BMS1900provide the input and output temperatures and pressures of the fluid flow, the real time solver can solve for the loss of heat and/or pressure loss in the pipe. As another example, a collection of thermodynamic blocks and connections may model fluid flow from an evaporator to an air handling unit in a HVAC system. If the state of the fluid at the output of the evaporator is known and state of the input fluid to the air handling unit is known, the real time solver can solve the system to determine where, if any, temperature or pressure was lost.

The results of the calculations performed by the real time solver can be provided as a “virtual sensor,” stored along with the measured values, and/or provided as a data output to a user. In some embodiments, the real time solver uses fully-defined thermodynamic blocks to solve for unknown values. If a thermodynamic block is not fully defined, the real time solver may output an indication that additional definition and/or inputs are required to solve for the desired values. In other embodiments, the real time solver uses system identification (e.g., regression of a system model from empirical data) to generate a model for the system and define the thermodynamic block.

In some embodiments, one or more of solvers1922,1942,1962, and1982includes a batch solver. The batch solver may be configured to perform batch calculations using one or more thermodynamic blocks of the thermodynamic data model. For example, the batch solver may be configured to solve a pressure loop for the HVAC system. Solving a pressure loop may include identifying a known pressure in the HVAC system (e.g., a pressure ground) and traversing from the known pressure through a network of defined connections within the thermodynamic data model until all of the pressures in the HVAC system have been solved. If too few pressure samples or constraints are provided in the data model, the batch solver may output a notification that the pressure loop cannot be solved based on the provided information. The batch solver may identify one or more data points that, if measured, would allow the batch solver to solve the pressure loop and present such data points to a user as suggested measurements or system improvements.

As another example, the batch solver may be configured to run a simulation using the thermodynamic data model. If the thermodynamic data model represents a plant, the batch solver may use the data model to simulate how the plant would operate into the future. Inputs to the batch solver may include an indication of a desired performance attribute (e.g., energy consumption, temperature, cooling load, etc.) and one or more time series variables that are relevant to the desired performance attribute (e.g., weather, building loads, energy prices, etc.). Using the batch solver to run simulations allows a user to define real or hypothetical scenarios and simulate the effects of each scenario. For example, a user can define a hypothetical scenario which simulates the impact of adding an additional chiller or new piping to an existing plant.

The operations performed by solvers1922,1942,1962, and1982may be similar when used as a real time solver or a batch solver. For example, solvers1922,1942,1962, and1982may receive, as an input, a system model (e.g., model800, model1500) including one or more linked thermodynamic blocks900. Solvers1922,1942,1962, and1982may identify connections918, sub-blocks914, stats920, data points (e.g., time series data1104), and/or internals922listed within each of the thermodynamic blocks. Connections918and sub-blocks914may impose constraints on the solver (e.g., constraining the input to one block to the output of another block). Stats920may define the data points that are required to solve for the desired variable. If one or more required data points are missing, solvers1922,1942,1962, and1982may report that insufficient data points are available. In some embodiments, solvers1922,1942,1962, and1982identify and report the missing data points to a user.

Advantageously, the thermodynamic data model described herein can be used to model a wide variety of thermodynamic systems, regardless of the inputs to the system model. For example, the system model can be constructed without considering the actual sensors and/or data points measured in the actual thermodynamic system. This allows the system model to be developed independent from the collection of data (e.g., via sensor placement) in the actual thermodynamic system. For a system model with very few sensors and connections between thermodynamic blocks, most of the variables that could potentially be modeled may be undefined (e.g., unconstrained by the model) and the predictive capabilities of the model may be limited. As more sensors and/or connections are added to the system model, an increasing number of variables may become fully defined (e.g., constrained) and can be predicted by the model.

In some embodiments, solvers1922,1942,1962, and1982are configured to identify one or more data points or connections that, if defined, would provide additional functionality to the system model. Defining a data point may include installing a sensor to measure the data point or defining a stat to calculate the data point. Defining a connection may include establishing or fully defining a link between two or more thermodynamic blocks in the model. In some embodiments, solvers1922,1942,1962, and1982provide the user with a cost-benefit analysis of adding additional complexity to the model. For example, solvers1922,1942,1962, and1982may present the user with a list of sensors that could be added and/or connections that could be defined to provide additional functionality to the system model. The list may include an estimated cost of each sensor and/or connection that could be added. Advantageously, solvers1922,1942,1962, and1982can report the costs and benefits of various actions that would add more definition to the system model. For example, solvers1922,1942,1962, and1982may report that if the user spends X more dollars adding a sensor or further configuring the data model, the model will then be capable of providing feature Y. This allows the user to pick and choose features in a plug-and-play manner by assessing the costs and benefits of additional model definition.

Referring now toFIGS. 20-21, a user interface2000for configuring the thermodynamic data model described with reference toFIGS. 5-19is shown, according to an exemplary embodiment. Configuration of the thermodynamic data model may be accomplished by dragging and dropping template thermodynamic blocks2002from a palette2010into a global model2020(e.g., via a user input device). Each of thermodynamic blocks2002may be an instance of thermodynamic block900, as described with reference toFIG. 9. Palette2010may include any number and/or types of atomic thermodynamic blocks or non-atomic thermodynamic blocks (e.g., assemblies) that can be used to represent various systems or devices in the global model2020. For example, palette is shown to include thermodynamic blocks2002representing pumps, chillers, towers, pipes, etc. Connections between thermodynamic blocks2002may be defined by drawing lines connecting thermodynamic blocks2002in global model2020. The various attributes of each thermodynamic block2002(e.g., name908, key910, stats920, internals922, etc.) can also be defined via user interface2000.

Referring particularly toFIG. 2100, an interface2100for defining the inputs and outputs of thermodynamic blocks2002in global model2020is shown, according to an exemplary embodiment. Interface2100shows a chiller block2102, which may be one of thermodynamic blocks2002in global model2020. Once chiller block2102has been placed in global model2020, connections can be defined by drawing lines between chiller block2102and other thermodynamic blocks2002in global model2020. Inputs to chiller block2102may be specified by attaching the connection to the input side2104of chiller block2102, whereas outputs from chiller block2102may be specified by attaching the connection to the output side2106of chiller block2102. Once the global model2020has been created and the connections have been defined, BMS controller1910may automatically generate a net list1600, a net descriptions table1700, and/or an all connections table1800describing global model2020. Global model2020may be stored within the local memory of BMS controller1900and/or distributed to various components of BMS1900, as described with reference toFIG. 19.

Referring now toFIGS. 22-25, several flowcharts illustrating processes2200-2500that use the thermodynamic data models described with reference toFIGS. 5-21are shown, according to an exemplary embodiment. Processes2200-2500may be performed by a solver module of a BMS device (e.g., solvers1922,1942,1962, and1982) to calculate values that are not sampled by BMS equipment to provide more optimal control. In various embodiments, processes2200-2500may be performed by atomic BMS devices (e.g., pumps, chillers, etc.) or higher level BMS devices (e.g., field controllers, supervisory controllers, etc.).

Referring particularly toFIG. 22, a process2200for calculating virtual data points based on measured time series data is shown, according to an exemplary embodiment. Advantageously, process2200may be used to determine values for one or more data points that are not measured by the building management system. Process2200is shown to include accessing a list of connections and a list of stats provided by a thermodynamic block (step2202). The list of connections may be provided as a connections attribute918of the thermodynamic block (e.g., thermodynamic block900) and the list of stats may be provided as a stats attribute920of the thermodynamic block.

Process2200is shown to include identifying one or more time series data inputs defined by the list of connections (step2204) and identifying one or more functions that use the identified time series data inputs (step2206). The time series data inputs may be real time data inputs measured by one or more sensors of the building management system. The functions that use the identified time series data inputs may be defined by the list of stats provided by the thermodynamic block.

Process2200is shown to include calculating one or more virtual data points by applying the identified functions to the identified time series data inputs (step2208). Step2208may include using a stat object (e.g., stat object1100) to map each of the time series data inputs to a particular variable in the identified function. The function can then be solved using the equations provided by the stat object to calculate a result. The result may be stored as an attribute of the stat object (e.g., as result1112) and/or provided to other systems or devices for use in other calculations or reporting to a user.

Referring now toFIG. 23, a process2300for simulating the future performance of a building management system using thermodynamic data models is shown, according to an exemplary embodiment. Process2300is shown to include accessing a list of connections and a list of stats provided by a thermodynamic block (step2302). The list of connections may be provided as a connections attribute918of the thermodynamic block (e.g., thermodynamic block900) and the list of stats may be provided as a stats attribute920of the thermodynamic block.

Process2300is shown to include identifying one or more projected future data inputs defined by the list of connections (step2304) and identifying one or more functions that use projected future data inputs (step2306). The projected future data inputs may be estimated values for external variables such as weather conditions, energy prices, building load, etc. The functions that use the identified projected future inputs may be defined by the list of stats provided by the thermodynamic block.

Process2300is shown to include simulating a future performance of the building management system by applying the identified functions to the projected future data inputs (step2308). Step2308may include using a stat object (e.g., stat object1100) to map each of the projected future data inputs to a particular variable in the identified function. The function can then be solved using the equations provided by the stat object to calculate a result. The result may be stored as an attribute of the stat object (e.g., as result1112) and/or provided to other systems or devices for use in other calculations or reporting to a user.

Referring now toFIG. 24, a process2400for generating and solving a system of equations using thermodynamic data models is shown, according to an exemplary embodiment. In some embodiments, process2400is performed by a controller or supervisory device in the building management system using a plurality of thermodynamic data models. Process2400is shown to include identifying one or more sub-blocks encompassed by a non-atomic thermodynamic block (step2402). The encompassed sub-blocks may be identified by the sub-blocks attribute914of the thermodynamic block.

Process2400is shown to include retrieving, from the identified sub-blocks, connections and stats provided by the sub-blocks (step2404). Step2404may include requesting the identified sub-blocks (or a portion of the sub-blocks) from one or more lower level BMS devices in which the sub-blocks are stored. The lower level BMS devices may respond to the request by sending a copy of their stored thermodynamic blocks to the higher level device requesting the thermodynamic blocks. In some embodiments, step2404includes retrieving one or more stat objects1100and/or one or more connection objects1000from an external database (e.g., stats database1994, connections database1992).

Process2400is shown to include generating a system of equations using the retrieved connections and stats (step2406). The system of equations may include equations that define relationships between thermodynamic blocks based on the connections. The system of equations may also include equations that define relationships between the inputs and outputs of a thermodynamic block based on the stats. Some of the variables in the system of equations may have known values. For example, some of the variables may be measured by a sensor, specified as a constant parameter, and/or provided as an internal data point. Other variables in the system of equations may have unknown values.

Process2400is shown to include solving the system of equations to calculate one or more unknown values (step2408). The unknown values may include values that are not measured by sensors or otherwise provided as known parameters. Any of a variety of computational techniques may be used to solve the system of equations (e.g., matrix calculations, linear algebra, etc.). In some embodiments, step2408is performed in real time by a processing circuit of a controller in the building management system (e.g., based on real time sensor data) and iteratively repeated each time new data is received.

Referring now toFIG. 25, a flowchart of a process2500for analyzing and recommending improvements to a thermodynamic model is shown, according to an exemplary embodiment. Process2500may be performed by a controller or other supervisory device in a building management system to identify one or more improvements that could be made to the thermodynamic model to enhance the capabilities of the model. Process2500is shown to include identifying connections and stats provided by one or more thermodynamic blocks (step2502). The connections and stats identified in step2502may be defined as attributes of a thermodynamic block (e.g., connections918and stats920) and/or as attributes of a sub-block encompassed by the thermodynamic block.

Process2500is shown to include generating a system of equations using the identified stats and connections (step2504). The system of equations may include equations that define relationships between thermodynamic blocks based on the connections. The system of equations may also include equations that define relationships between the inputs and outputs of a thermodynamic block based on the stats. Some of the variables in the system of equations may have known values. For example, some of the variables may be measured by a sensor, specified as a constant parameter, and/or provided as an internal data point. Other variables in the system of equations may have unknown values.

Process2500is shown to include determining whether an unknown variable can be calculated using the system of equations (step2506). Step2506may include determining whether sufficient constraints exist within the thermodynamic model to limit the unknown variable to a particular calculable value (e.g., based on one or more known values). Constraints may include the stats and connections that define relationships between variables in the system of equations generated in step2504. If sufficient constraints exist, the unknown variable can be calculated as described with reference to process2400. However, if the unknown variable cannot be calculated using the system of equations (i.e., the unknown variable is not fully constrained), process2500may proceed to step2508.

Process2500is shown to include determining one or more additional constraints required to calculate the unknown variable (step2508). Step2508may be performed in response to a determination in step2506that additional constraints are necessary to fully constrain the unknown variable to a particular value. In some embodiments, step2508includes identifying one or more unknown variables that, if known (e.g., measured, specified, etc.), would allow the unknown variable to be calculated. In some embodiments, step2508includes identifying one or more potential connections between thermodynamic blocks that, if formed, would constrain the unknown variable to a particular value.

Process2500is shown to include reporting recommended actions to establish the additional constraints via a user interface (step2510). In some embodiments, the recommended actions include actions that could be performed by a user to provide the additional definition needed to solve for the unknown variable (e.g., defining a data point, defining a connection, etc.). Defining a data point may include installing a sensor to measure the data point or defining a stat to calculate the data point. Defining a connection may include establishing or fully defining a link between two or more thermodynamic blocks in the model.

In some embodiments, step2510includes generating and/or providing the user with a cost-benefit analysis of adding additional complexity to the model. For example, step2510may include presenting the user with a list of sensors that could be added and/or connections that could be defined to provide additional functionality to the system model. The list may include an estimated cost of each sensor and/or connection that could be added. Step2510may include reporting the costs and benefits of various actions that would add more definition to the system model. For example, step2510may include reporting that if the user spends X more dollars adding a sensor or further configuring the data model, the model will then be capable of providing feature Y. This allows the user to pick and choose features in a plug-and-play manner by assessing the costs and benefits of additional model definition.