Stability index for connected equipment

A method for determining a stability of a building device includes receiving time series data from building equipment regarding a first operational parameter of the building equipment, determining, for one or more time steps of the time series data, a deviation between a setpoint and a recorded value of the first operational parameter, calculating, for the one or more time steps, a trapezoidal area based on an absolute value of the deviation and a length of a time step, calculating a stability index value for the building equipment by summing the trapezoidal areas for a subset of the one or more time steps over a time horizon, and initiating an automated response based on the stability index value.

BACKGROUND

The present disclosure relates generally to a building management system (BMS), and more particularly, to determining a stability index for building equipment. A 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, for example, a HVAC system, a security system, a lighting system, a fire safety system, any other system that is capable of managing building functions or devices, or any combination thereof. Operational data from equipment or devices in a BMS may be monitored to detect and/or prevent problems, and to determine whether the equipment is running as efficiently as possible.

In some cases, a large number of data points or parameters may be required to accurately determine when equipment is experiencing a problem or is running inefficiently. Additionally, some methods for identifying problems or inefficiencies are very specific to a particular type of equipment. In this regard, these methods may need to be modified in order to be applied to other, different types of equipment. Thus, it may be desirable to determine the stability of building equipment using systems and methods that do not require a large number of parameters, and that can be applied to various types of equipment.

SUMMARY

One embodiment of the present disclosure is a method for determining a stability of building equipment. The method includes receiving time series data from the building equipment regarding a first operational parameter of the building equipment, determining, for one or more time steps of the time series data, a deviation between a setpoint and a recorded value of the first operational parameter, calculating, for the one or more time steps, a trapezoidal area based on an absolute value of the deviation and a length of a time step, calculating a stability index value for the building equipment by summing trapezoidal areas for a subset of the one or more time steps over a time horizon, and initiating an automated response based on the stability index value.

In some embodiments, the automated response includes generating a user interface to present a graphical representation of the stability index value.

In some embodiments, the automated response includes flagging the building equipment for maintenance based on a determination that the stability index value is outside of a threshold.

In some embodiments, the method further includes determining a scale factor, wherein calculating the stability index value further includes multiplying the summation of the trapezoidal areas by the scale factor.

In some embodiments, the method further includes determining, for the one or more time steps, whether a value of a second operational parameter relating to energy consumption of the building equipment is below a threshold based on the time series data and filtering the time series data by setting the deviation to zero for any time steps where the value of the second operational parameter is below the threshold.

In some embodiments, the second operational parameter is a motor current.

In some embodiments, first operational parameter includes a chilled fluid temperature corresponding to an outlet of the building equipment.

In some embodiments, the building equipment is a chiller.

Another embodiment of the present disclosure is a building management system. The building management system includes one or more memory devices having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to perform operations. The operations include receiving, from a building device, time series data regarding a first operational parameter of the building device, determining, for one or more time steps of the time series data, a deviation between a setpoint and a recorded value of the first operational parameter, calculating, for the one or more time steps, a trapezoidal area based on an absolute value of the deviation and a length of a time step, calculating a stability index value for the building equipment by summing trapezoidal areas for a subset of the one or more time steps over a time horizon, and initiating an automated response based on the stability index value.

In some embodiments, the automated response includes generating a user interface to present a graphical representation of the stability index value.

In some embodiments, the automated response includes flagging the building device for maintenance based on a determination that the stability index value is outside of a threshold.

In some embodiments, the operations further include determining a scale factor, wherein calculating the stability index value further includes multiplying the summation of the trapezoidal areas by the scale factor.

In some embodiments, the operations further include determining, for the one or more time steps, whether a value of a second operational parameter relating to energy consumption of the building device is below a threshold based on the time series data and filtering the time series data by setting the deviation to zero for any time steps where the value of the second operational parameter is below the threshold.

In some embodiments, the second operational parameter is a motor current.

In some embodiments, the first operational parameter includes a chilled fluid temperature corresponding to an outlet of the building equipment.

In some embodiments, the building device is a chiller.

Yet another embodiment of the present disclosure is a non-transitory computer-readable storage media having computer-executable instructions stored thereon that, when executed by one or more processors, cause the processors to perform operations. The operations include retrieving, from a database, time series data related to a first operational parameter of a building device, filtering the time series data based on a second operational parameter, determining, for a plurality of steps of the time series data, a deviation between a setpoint and a recorded value of the first operational parameter, calculating, for the plurality of steps, a trapezoidal area based on an absolute value of the deviation and a length of the plurality of steps, and calculating a stability index value for the building device by summing trapezoidal areas for a subset of the plurality of steps over a time horizon.

In some embodiments, the operations further include dynamically generating a user interface to present a graphical representation of the stability index value.

In some embodiments, the operations further include flagging the building device for maintenance based on a determination that the stability index value is below a threshold.

In some embodiments, the first operational parameter is a chilled water supply temperature and the second operational parameter is an energy consumption for the building device.

DETAILED DESCRIPTION

Overview

Referring generally to the FIGURES, a stability analysis system is shown, according to some embodiments. At a high level, the stability analysis system may be configured to monitor operational data from building equipment and generate a stability index value that indicates how closely the building equipment is maintaining setpoints. The stability index value may be a quantitative indicator of equipment performance, and in some cases can be utilized to diagnose problems with the building equipment and/or to determine the overall equipment health. The stability index may also indicate that the building equipment requires maintenance or service in order to correct or prevent problems, which may lead to unnecessary equipment down time, costly repairs, equipment failure, etc.

The stability analysis system can include a controller or other central processing unit that monitors and/or receives operational data from building equipment and/or a database. The operational data can be applied to an algorithm or a model that calculates the stability index. Based on the stability index, any number of automated responses may be initiated. For example, if the stability index indicates a problem with the building equipment, maintenance or service can be automatically scheduled for the affected equipment. The stability index may also be used to determine the health of the equipment or system, and can be used to generate a health dashboard (i.e., graphical user interface).

Building with Building Systems

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. These and other variations to waterside system200are within the teachings of the present invention.

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, extremum seeking control (ESC) algorithms, proportional-integral (PI) control algorithms, proportional-integral-derivative (PID) control algorithms, model predictive control (MPC) 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.

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 some embodiments, BMS controller366is implemented within a single computer (e.g., one server, one housing, etc.). In various other embodiments BMS controller366may 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.

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.).

Stability Analysis System

Referring now toFIG.5A, a block diagram of BMS400is shown that illustrates network446in greater detail, according to some embodiments.FIG.5Ashows, in particular, a stability analysis system500communicably coupled to network446. System500may be one of the remote systems and applications444discussed above with respect toFIG.4, for example. In some embodiments, system500is hosted (e.g., implemented) by a dedicated server, computer, controller, or other processing device. In other embodiments, system500may be hosted or implemented by one of client devices448, or may be a subsystem of BMS controller366. In this regard, the functionality of system500, as described herein, may be implemented by any suitable remote device and/or BMS controller366, or by a combination of a remote device and BMS controller366. Accordingly, it will be appreciated by those in the art that the particular layout of the components shown inFIG.5Ais one example of the implementation of system500, and is not intended to be limiting.

BMS controller366may be communicably coupled to any number of devices (e.g., building equipment), shown as devices502-506. Devices502-506can include any of the equipment described above with respect to building subsystems428, including but not limited to electrical equipment, ICT equipment, security equipment, HVAC equipment, lighting equipment, lift/escalators equipment, and fire safety equipment. System500may receive operational data from devices502-506via BMS controller366(e.g., collected by BMS controller366) and/or network446. In some embodiments, devices502-506may also be communicably coupled directly to network446. In such embodiments, remote systems such as system500may be able to receive operational data directly from device502-506.

Referring now toFIG.5B, a block diagram of stability analysis system500is shown, according to some embodiments. In general, system500functions by processing operational data received from a variety of building equipment (e.g., devices502-506) to determine a stability index for the building equipment. As briefly discussed above, the stability index is a metric that indicates the stability, and thereby the overall health and efficiency, of building equipment. In this regard, the stability index may be useful in determining whether equipment is running optimally (e.g., efficiently), or whether the equipment is experiencing issues or problems that may lead to excessive wear, inefficiency, failure, etc., if left unaddressed. The stability index may be a useful metric for monitoring system operations and, in some cases, may allow for the early diagnosis and repair of equipment issues.

System500is shown to include a processing circuit510that includes a processor512and a memory520. It will be appreciated that these components can be implemented using a variety of different types and quantities of processors and memory. For example, processor512can be a general purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components. Processor512can be communicatively coupled to memory520. While processing circuit510is shown as including one processor512and one memory520, it should be understood that, as discussed herein, a processing circuit and/or memory may be implemented using multiple processors and/or memories in various embodiments. All such implementations are contemplated within the scope of the present disclosure.

Memory520can include one or more devices (e.g., memory units, memory devices, storage devices, etc.) for storing data and/or computer code for completing and/or facilitating the various processes described in the present disclosure. Memory520can include random access memory (RAM), read-only memory (ROM), hard drive storage, temporary storage, non-volatile memory, flash memory, optical memory, or any other suitable memory for storing software objects and/or computer instructions. Memory520can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present disclosure. Memory520can be communicably connected to processor512via processing circuit510and can include computer code for executing (e.g., by processor512) one or more processes described herein.

Memory520is shown to include a data manager522. Data manager522is generally configured to perform a variety of functions using operational data received from equipment532and/or sensors534via a communications interface530, described in detail below. Upon receiving said operational data, data manager522can be configured to preprocess and/or store the operational data in a database528. Subsequently, data manager522can retrieve stored data from database528for further processing (e.g., by another component of system500). In this manner, data manager522may also be configured to “direct” the flow of data between components of system500.

Operational data, as discussed herein, can generally include any sort of data or signal regarding the operations of equipment532. Operational data may include any equipment parameters, measurements, or metrics such as temperature, pressure, status, speed, load, etc. In one example, operational data for a chiller can include fluid outlet and/or inlet temperatures and pressures, compressor speed and energy consumption, compressor oil level and pressure, fan motor energy consumption, etc. In another example, operational data for an AHU could include discharge air temperature, fan motor current, etc. In some embodiments, operational data is received directly from equipment532(e.g., from internal or embedded sensors). In other embodiments, operational data is received from sensors534or from any combination of equipment532and sensors534.

Equipment532may include any number of devices (i.e., equipment) associated with any of building subsystems428, as described above, such as HVAC equipment (e.g., ducts, VAVs, AHUs, etc.), security equipment (e.g., cameras, card readers, etc.), fire safety equipment (e.g., alarms, sprinklers, etc.), etc. Likewise, sensors534may include any number and type of suitable sensors for measuring operational parameters associated with the equipment of BMS400. For example, sensors534can include temperature sensors, pressure sensors, smoke detectors, access control readers, security cameras, etc. In various embodiments, sensors534may be coupled to, embedded in, or collocated with equipment532. In other words, sensors534may be stand-alone (i.e., external or remote) sensors, or may be embedded within equipment532.

In some embodiments, data manager522preprocesses operational data received from equipment532and/or sensors534prior to storage (e.g., in database528) and/or prior to further manipulation by other components of system500. In such embodiments, preprocessing can include formatting, normalizing, or otherwise modifying or altering the data such that the data is in an appropriate format for storage and/or further manipulation. In one example, data manager522receives data in a first format or unit of measure and converts the data to a second format or unit of measure. In some embodiments, preprocessing may include time stamping the data based on a time of receipt, before the data is stored in database528.

In some embodiments, data manager522stores data that is not formatted, normalized, or otherwise modified (i.e., raw data) in database528. In such embodiments, data manager522may retrieve the data at later time (e.g., prior to routing the data to another component of memory520) for preprocessing. In such embodiments, data manager522may format, normalize, or otherwise modify the data upon retrieval of the data from database528. For example, raw operational data stored in database528may be retrieved at a regular time interval for further analysis, in response to a user request for a particular report, to generate or update a user interface, etc. In some cases, preprocess the retrieved data may include backfilling or forward-filling datasets, as discussed in further detail below with respect to step602of process600.

It will be appreciated that, as described herein, database528can be implemented as a single database or multiple separate databases working together. Database528can be configured to maintain a wide variety of data and data types associated with system500. For example, database528can generally maintain raw and/or preprocessed equipment operating data, along with other historical data relating to the operations of equipment532. It will also be appreciated that, while shown as an internal component of system500, database528could also be implemented at least partially by one or more external databases (e.g., hosted by one or more remote devices).

Still referring toFIG.5, memory520is also shown to include an equipment stability analyzer524. In general, equipment stability analyzer524may receive operational data (e.g., raw or preprocessed) from data manager522and, in some cases, may retrieve stored data directly from database528. Equipment stability analyzer524is generally configured to perform various analyses, using current or historical operational data, in order to determine a stability index for a building device (e.g., equipment532). As described above, the stability index may provide an indication of the health and/or efficiency of a building device, allowing for improved and preemptive maintenance of failing or problematic equipment, thereby leading to decreased downtime and repair costs.

As described below in greater detail with respect toFIG.6, equipment stability analyzer524may apply the operational data to a stability index model. In some embodiments, the stability index model includes a series of algorithms used to calculate a stability index value from the operational data. In some embodiments, equipment stability analyzer524utilizes machine learning algorithms or neural networks to train and improve the stability index calculation. Based on the stability index, equipment stability analyzer524may determine one or more automated (i.e., automatic) responses. In some cases, equipment stability analyzer524may cause a user interface (UI) generator526to generate a graphical user interface based on the stability index. In other cases, equipment stability analyzer524may determine and transmit (e.g., via data manager522and/or communications interface530) one or more control decisions to equipment532, causing one or more devices of equipment532to cease operations, adjust operating parameters, etc. In yet other cases (e.g., where the stability index is below a threshold), equipment stability analyzer524may automatically determine and/or schedule an appropriate maintenance or service request to correct problems with equipment stability analyzer524.

UI generator526may be configured to dynamically generate graphical user interfaces for presenting a wide variety of information regarding system500. As an example, UI generator526may generate a graphical user interface to present the stability index value(s) calculated by equipment stability analyzer524. In another example, UI generator526can generate a graphical user interface that includes a “health dashboard,” presenting an overview of the stability and/or health of a plurality of equipment or devices. UI generator526may be implemented as a webserver that can store, process, and deliver web pages (e.g., HTML documents) to a web browser of a user device546, or as an application on a user device546(e.g., desktop application, mobile application), for example, although it will be appreciated that UI generator526can be implement in any other suitable manner as well. UI generator526may generally receive inputs (e.g., HTTP requests) from one or more of client devices448, thereby providing an interface for a user to interact with system500.

Still referring toFIG.5B, system500is also shown to include communications interface530configured to exchange data with a plurality of remote systems and/or devices. In particular, communications interface530may allow system500to exchange data via network446, as previously described. In this manner, system500may transmit and/or receive data from any of the components of BMS400via communications interface530. In some embodiments, communications interface530may also facilitate the conversion and/or translation of various data or communication types or formats, to allow system500to interface with a wide variety of external systems and devices.

In some embodiments, system500may communicate directly with one or more client devices448via communications interface530. In other embodiments, system500may communicate with client devices448via network446. As described above, client devices448may include any electronic device that allows a user to interact with system500and/or BMS400through a user interface. Examples of user devices include, but are not limited to, mobile phones, electronic tablets, laptops, desktop computers, workstations, and other types of electronic devices. One or more of client devices448may present (i.e., display) a plurality of user interfaces generated by system500including, in some cases, an interface that presents the stability index for one or more devices.

In some embodiments, system500may also exchange data directly with equipment532and/or sensors534via communications interface530. In some such embodiments, communications interface530may include a wired and/or wireless BACnet interface in addition to other types of communications interfaces (e.g., Modbus, LonWorks, DeviceNet, XML, etc.) to facilitate communication with equipment532and/or sensors534. In other embodiments, system500may exchange data with equipment532and sensors534via network446, as described above with respect toFIG.5A. In such embodiments, data from equipment532and/or sensors534may be received and otherwise manipulated by BMS controller366, before being transmitted to system500via network446. Accordingly, it will be appreciated that equipment532, sensors534, and/or client devices448may be communicably coupled to system500in any suitable manner, and that the particular configuration shown inFIG.5Bis not intended to be limiting.

Referring now toFIG.6, an example process600for determining a stability index for building equipment (e.g., equipment532) is shown, according to some embodiments. In some embodiments, process600is implemented by system500. It will be appreciated that certain steps of process600may be optional and, in some embodiments, process600may be implemented using less than all of the steps and/or different steps than are shown inFIG.6. As described below, process600may include steps for determining a stability index for a building device (e.g., a chiller, a cooling tower, a boiler, an AHU, etc.) that provides a heated or cooled fluid (e.g., water, coolant, air, etc.), but it will be appreciated that process600may also be used to calculate a stability index for other building equipment.

In one example, where process600is implemented to determine a stability index for a chiller (e.g., chiller102), the stability index may indicate how efficiently the chiller is operating, and thereby how stable the chiller is. A chiller's primary goal is to provide chilled water for building cooling. To meet the chilled water requirements, a chiller must deliver chilled water that is at a temperature typically between 38 to 46° F. While the dynamics of chiller operations can be complex, and chillers can be affected by many different issue, most problems will affect the chillers ability to maintain chilled water setpoint and, accordingly, may cause a loss of chilled water stability. The stability index described herein may provide an indicator of these chiller instabilities. In other embodiments, the stability index may likewise indicate an efficiency of other building equipment such as a boiler, cooling tower, AHU, etc.

At step602, time series data regarding at least one operational parameter of a building device or equipment (i.e., equipment532) is received. Time series data, as described herein, is generally a data set that includes a series of data points indexed in time order. In some embodiments, operational data (e.g., data regarding at least one operational parameter of a device) is collected in a series of discrete, equally-spaced points in time (i.e., time steps). In other words, the operational data for building equipment, as described above with respect toFIG.5B, is typically discrete-time data that is collected and/or recorded at a series of time periods.

In some embodiments, such time series operational data is received directly from building equipment (e.g., from internal or embedded sensors of equipment532). In other embodiments, operational data is received from one or more external or remote sensors, or from a combination of internal and external sensors. In some such embodiments, where operational data is received from building equipment and/or sensors, the data may be time stamped with a time of receipt. In some cases, time stamped operational data is stored in a database (e.g., database528) for later retrieval and manipulation. Accordingly, in some embodiments, the time series operational data is retrieved from a database (e.g., database528), having previously been received and stored (e.g., by data manager522).

In some embodiments, the first operational parameter is an outlet fluid temperature for building equipment that provides heated or cooled fluid (e.g., water, air, coolant, oil, etc.). In particular, the first operational parameter may be a chilled water supply temperature for a chiller, cooling tower, or other device, a heated water supply temperature for a boiler or other similar device, or even a discharge air temperature for an AHU or rooftop unit. Accordingly, the time series data received at step602may include fluid supply/discharge temperatures recorded at an outlet of the chiller, cooling tower, boiler, AHU, etc. The time series data may also include a setpoint for the outlet fluid temperature. In the example of a chiller, the time series data may include both a chilled water supply temperature and chilled water supply temperature setpoint.

At step604, a time delta is calculated for one or more time steps of the time series data. A time delta may indicate the length of an individual time step, based on a difference between a first and a second time step. In some embodiments, the time steps of the time series data are represented as a series of tifrom t1. . . tn, where n is the total number of samples in the data set. Generally, the time delta for an individual time step is calculated as:
TDi=ti−ti−1
where TDiis the time delta at step i, and tiand ti−1are a first and second time step. In this case, ti−1represents the time step immediately before ti, and the difference between these times steps is the time delta. The calculation of a time delta for each time step is illustrated inFIG.7, which is described in detail below.

In some embodiments, the time delta is calculated only after the operational data has been preprocessed, although it will be appreciated that preprocessing is not always required. Preprocessing can include formatting, normalizing, or otherwise modifying or altering the data such that the data is in an appropriate format for storage and/or further manipulation. In various embodiments, operational data is received in a first format or unit of measure and converted to a second format or unit of measure. In some embodiments, preprocessing includes forward- or back-filling a data set. In some cases, for example, data may only be recorded when an operational parameter changes, or it may be desirable to limit the number of data points of a time series data set. In such example cases, certain data points may be removed or added to the time series data during preprocessing.

At step606, an absolute deviation between a setpoint and a recorded value is calculated for the one or more time steps. The absolute deviation may indicate how closely a recorded value (i.e., measurement) for an operational parameter is tracking the desired setpoint. The absolute deviation is calculated taking the absolute value of the difference between a measured or recorded value for a first operational parameter and a setpoint for the first operational parameter. Mathematically, this is represented as:
ABDi=|FSTi−FSTspi|
where ABAirepresents the absolute deviation at step i, FSTirepresents the measured or recorded value (i.e., data point) for the first operational parameter (e.g., fluid supply temperature) at step i, and FSTspirepresents the setpoint for the first operational parameter at step i. Hence, the calculated absolute values form a series ABA1. . . ABAnfor a data set that includes a plurality of time steps. The calculation of an absolute deviation for each time step is illustrated inFIG.7, which is described in detail below.

To continue the previous example regarding a chiller, the absolute value (ABA) at a time step may indicate how close the chilled water supply temperature is tracking to a setpoint. While a certain amount of fluctuation between the measured temperature and the setpoint is to be expected, large discrepancies between the measured temperature and setpoint can indicate inefficiencies with the chiller, particularly if the chiller fails to track the setpoint over a long period of time. In some cases, deviations between a fluid supply temperature and a setpoint can even indicate a chiller that is experiencing a malfunction or a failure, or that the chiller may fail in the near future.

At step608, a trapezoidal area is calculated for one or more time steps. Generally, the trapezoidal areas area calculated based on the time deltas calculated for the one or more time steps at step604and the absolute deviations calculated at step606. The trapezoidal area may indicate how closely the setpoint was tracked over the time step, where smaller trapezoidal areas indicate that the measured or recorded operational data was more closely tracking the setpoint. A trapezoidal area is calculated as:

Are⁢ai=(ABDi+ABDi+1)×(T⁢Di2)
where Areaiis the trapezoidal area for a time step i, ABDiis the absolute deviation at time step i and ABDi+1is the absolute deviation calculated at the time step immediately following time step i. The calculation of a trapezoidal areas is illustrated inFIG.7, which is described in detail below.

At step610, the calculated trapezoidal areas are filtered to exclude time steps where a second operational parameter is below a threshold. In some embodiments, the areas are filtered by setting the absolute deviation (ABA) to zero for time steps where the second operational parameter is below a threshold. In other embodiments, trapezoidal areas corresponding to a time step where the second operational parameter is below a threshold are simply not included in the summation at step612, described below.

In some embodiments (e.g., for a chiller), the second operational parameter is a current for a motor (e.g., the compressor motor) of the chiller, typically presented as a percentage of full load amperage. In one example, if the full load amperage is below a threshold at a particular time step, such as 5% of maximum full load amperage, then it may be assumed that the compressor, and thereby the chiller, was not turned on (i.e., operating). Accordingly, any data recorded during this time step may be ignored.

At step612, the trapezoidal areas are summed for a subset of the one or more time steps over a time horizon. The time horizon may be any suitable amount of time (e.g., a day, a month, an hour, etc.). The summation of the trapezoidal areas may be represented as a unit area (UAREA). The UAREA is calculated as:
Uareaj=Σi∈UjAreaj
where Ujis unit time j. It will be appreciated that j can be any suitable amount of time, such as minutes, hours, days, etc., and may include a plurality of smaller time steps. In one example, j is an hour and includes a plurality of time steps each corresponding to a one minute interval.

At step614, a stability index is calculated for the building equipment based on the summation of trapezoidal areas (e.g., UAREA) calculated at step612. The stability index for unit time j is calculated as:
SIj=100−(λ×Uareaj)
where λ is an optional scale factor. In some embodiments, the scale factor is adjustable and can be tuned (e.g., based on the type of building equipment). The scale factor acts as a penalty for the UAREA value calculated at step612. In this regard, a larger scale factor will more heavily penalize the UAREA. For example, calculating the stability index for a chiller using a scale factor of 10 will cause a penalty of 10 to the stability index for an average deviation of 1° F. from a setpoint. In some embodiments, a scale factor of 30 is used for a chiller.

At step616, an automatic response is initiated based on the stability index. In some embodiments, the automatic response includes the generation of a graphical user interface. The graphical user interface may be presented via one or more client devices448, and may include a graphical or textual representation of the stability index, as show inFIG.8below. Additionally, the graphical user interface may include other visual elements that present information relating to the first or second operational parameters, as described above. In some embodiments, the graphical user interface may include a “health dashboard” that provides an overview of the health or stability of multiple building devices in a single interface.

In some embodiments, such as when the stability index is below a threshold, the automatic response process may include generating a work order or a ticket, and/or automatically scheduling maintenance or service for a building device. In such embodiments, the threshold may be previously defined by a user (e.g., a system administrator). In some embodiments, building equipment with a stability index below a threshold may be flagged, such that a user may quickly identify the equipment and may determine additional action (e.g., scheduling maintenance). In some embodiments, the automatic response also includes generating a message or alert, and transmitting the message or alert to a remote device (e.g., client devices448). For example, system500may automatically generate a text message or email, and may transmit the text message or email to a user device associated with a maintenance technician, system administrator, etc.

Referring now toFIG.7, an example graph of a plurality of trapezoidal areas over a plurality of time periods is shown, according to some embodiments. As mentioned above,FIG.7may provide a visual representation of various steps of process600. As shown, for example, the graph includes six time periods, with five of the six periods having a trapezoidal area. A first time period on the far left ofFIG.7illustrates various variables described above with respect toFIG.6. For example, the trapezoidal area for this first time period is shown to be calculated from an absolute deviation ABDiat a first time step tiand absolute deviation ABA-pi at a second time step ti+1. Here, the time delta TDiis shown as the different between time tiand ti+1. Also shown inFIG.7is a particular time period where a trapezoidal area is not calculated. As discussed above, this particular time period may have been filtered between a second operational parameter fell outside of a threshold.

Referring now toFIG.8, an example interface800for presenting a stability index and various other operational data associated with building equipment is shown, according to some embodiments. In some embodiments, interface800is an interface generated by UI generator526and presented via one or more client devices448, as described above. In general, interface800presents the stability index and any additional operational data via a trend line, or other suitable graphic, over time. Accordingly, interface800provides, in a single interface, an overview and/or history of device performance and stability.

It will be appreciated that the elements of interface800may include any suitable graphical or textual elements for presenting operating data over time. However, in the example shown, interface800includes a plurality of graphs802-806, which include trend lines corresponding to various operating parameters of a device. Graph802, for example, includes a trend line corresponding to a calculated hourly area for a device. In other words, graph802indicates the area from the summation of a plurality of trapezoidal areas, as previous described, over a one-hour period. Graphs804and806include trend lines for a stability index value and full load amps for the device, also previous described. In this case, the x-axis of each of graphs802-806is a number of hours (i.e., time). The number of hours may indicate, for example, a total number of operating hours, or a number of hours since a first data point was recorded.

In a non-limiting example, interface800may present trend data for a chiller (e.g., chiller102), as described above. In this example, graph802would include a trend line corresponding to the summation of trapezoidal areas calculated at each of a plurality of time intervals based on a deviation between a setpoint and a recorded value for an outlet water temperature of the chiller. Graph804may present a trend line corresponding to a stability index for the chiller, also calculated at each of a plurality of time intervals. As shown, the stability index value trend line is generally inversely proportional to the area trend line of graph802. Graph806may include a trend line corresponding to the measured full load amperage (FLA) of a pump or compressor associated with the chiller. In this case, the FLA appears to stay just below 50% of a maximum value.

Referring now toFIG.9, an example interface900for presenting chilled water temperatures over time is shown, according to some embodiments. Interface900may be an interface generated by UI generator526and presented via one or more client devices448, for example. Like interface800described above, interface900also presents operational data for a device or equipment over time. In this case, interface900provides a graphical representation of recorded values and setpoints for a first operational parameter of a device, thereby indicating how closely the device is following the setpoints.

In the example shown, interface900provides a graphical representation of chilled water temperature measurements (“CHWST”) and chilled water temperature setpoints (“CHWST SP”) over a time period of eight days, from August 28thto September 6th. Chilled water temperature measurements, in this case, are represented by a solid black line while chilled water temperature setpoints are represented by a white line. Here, the chilled water temperature setpoint was set at roughly 43° F., with a slight deviation on September 2nd. The recorded chiller water temperatures are shown to fluctuate around the setpoint value, typically by about ±3° F. At certain time periods on September 2nd, 3rd, and 4th, the recorded chilled water temperature is shown to fluctuate as much as +14° F.

Configuration of Exemplary Embodiments