JP2019505907A - Building energy management system with energy analysis and ad hoc dashboard - Google Patents

Abstract

Building energy management includes building equipment, one or more data platform services, time series databases, and energy management applications. The building equipment operates to monitor and control the variable and provide a raw data sample of the data points associated with the variable. The time series database stores a plurality of time series associated with data points. The plurality of time series includes a time series of raw data samples and one or more optimized data time series generated by the data platform service based on the raw data time series. The energy management application generates an ad hoc dashboard that includes the widget and associates the widget with a data point. The widget displays a plurality of time series graphic visualizations associated with the data points and includes interactive user interface options for switching between the plurality of time series associated with the data points.

Description

Cross-reference to related patent applications This application is a U.S. provisional patent application 62 / 286,273 filed on January 22, 2016, U.S. patent application 15 / 182,579 filed June 14, 2016, and Claims the benefit and priority of US patent application Ser. No. 15 / 182,580, filed Jun. 14, 2016. The entire disclosure of each of these patent applications is incorporated herein by reference.

  The present disclosure relates generally to the field of building management systems. A building management system (BMS) is generally a system of devices configured to control, monitor and manage equipment in or around a building or building area. The BMS can include, for example, an HVAC system, a security system, a lighting system, a fire alarm system, any other system capable of managing building functions or devices, or any combination thereof.

  BMS can collect data from sensors and other types of building equipment. Data is collected over time and combined into a stream of time series data. Each sample of time series data can include a time stamp and a data value. Some BMSs store raw time series data in a relational database without significant organization or processing during data collection. Applications that use time series data typically retrieve raw time series data from a database and generate a view of the time series data that can be presented via a chart, graph, or other user interface. Responsible for that. These processing steps are typically performed in response to requests for time series data, which can significantly delay data presentation at query time.

US Patent Application Publication No. 2001/088798 (A1) Specification

  One implementation of the present disclosure is a building energy management system. The system includes building equipment, a data collector, an analysis service, a time series database, and an energy management application. The building equipment is operable to monitor and control one or more variables in the building energy management system and provide data samples of the one or more variables. The data collector is configured to collect data samples from the building equipment and generate a data time series that includes a plurality of data samples. The analysis service is configured to perform one or more analyzes using the data time series and generate a result time series that includes a plurality of result samples indicating the results of the analysis. The time series database is configured to store a data time series and a result time series. The energy management application is configured to retrieve a data time series and a result time series from a time series database in response to a request for time series data associated with one or more variables.

  In some embodiments, the analysis service includes a weather normalization module configured to generate a result time series by removing weather effects from the data time series. In some embodiments, the weather normalization module generates a regression model that defines a relationship between a data sample of the data time series and one or more weather related variables, and the one or more during the time associated with the data time series. Determine the value of one or more weather-related variables, apply one or more weather-related variable values as input to the regression model, estimate the weather normalized value of the data sample, and use the time normalized result of the data sample Is stored to exclude the influence of weather from the data time series.

  In some embodiments, the one or more weather related variables include at least one of a cooling degree day (CDD) variable and a heating degree day (HDD) variable. The regression model is an energy consumption model that defines energy consumption as a function of at least one of a CDD variable and an HDD variable.

  In some embodiments, the weather normalization module uses weather data relating to the baseline period and uses at least one of a cooling degree day (CDD) variable and a heating degree day (HDD) variable for each day during the baseline period. Calculate a value for one and determine at least one of a daily average of CDD variables for each time interval within the baseline period and a daily average of HDD variables for each time interval within the baseline period; Using the energy consumption data for the baseline period, the daily average energy consumption value is determined for each time interval within the baseline period, and the daily average energy consumption is calculated as the CDD variable daily average value and the HDD variable. Generate a regression model by generating a regression coefficient for the regression model by fitting to at least one of the daily averages of Configured.

  In some embodiments, the data time series is a resource consumption time series, and the data time series samples include at least one of a power consumption value, a water consumption value, and a natural gas consumption value. The analysis service may include an energy benchmarking module configured to use the data time series to calculate an energy usage metric for a building associated with the data time series. The energy usage criteria may include at least one of energy usage intensity (EUI) or energy density.

  In some embodiments, the energy benchmarking module identifies a total area of the building associated with the data time series and, based on a sample of the data time series, total building resources over the period associated with the data time series. It is configured to calculate an EUI for the building by determining consumption and calculating a resource consumption per unit area of the building using the total area of the building and the total resource consumption of the building.

  In some embodiments, the energy benchmarking module identifies the type of building associated with the data time series, and the energy usage criteria for the building and one or more benchmark energy usage criteria for other buildings of the identified type. And is configured to generate a plot containing a graphical representation of

  In some embodiments, the analysis service uses a sample of the data time series to calculate a daily night / day load ratio associated with the data time series, and calculates each calculated night / day load ratio. A night / day comparison module configured to generate a daily result sample associated with the data load time series for comparison with the threshold load ratio and store the plurality of result samples as a result time series. Each result sample may indicate whether the night / day load ratio for the corresponding day exceeds a threshold load ratio.

  In some embodiments, the analysis service uses a sample of the data time series to calculate the weekly weekend / weekday load ratio associated with the data time series, and the calculated weekend / weekday load ratio respectively. And a weekend / weekday comparison module configured to generate a weekly result sample associated with the data time series and store the plurality of result samples as a result time series. Each result sample may indicate whether the weekend / weekday load ratio for the corresponding week exceeds a threshold load ratio.

  Another implementation of the present disclosure is a building energy management system. The system includes building equipment, a data collector, one or more data platform services, a time series database, and an energy management application. The building equipment is operable to monitor and control a variable of the building energy management system and is configured to provide a raw data sample of data points associated with the variable. The data collector is configured to collect raw data samples from the building equipment and generate a raw data time series that includes a plurality of raw data samples. The data platform service is configured to generate one or more optimized data time series from the raw data time series. The time series database is configured to store a plurality of time series data associated with the data points. The plurality of time series includes a raw data time series and one or more optimized data time series. The energy management application is configured to generate an ad hoc dashboard that includes a widget and associate the widget with a data point. The widget is configured to display a plurality of time series graphic visualizations associated with the data points and includes an interactive user interface option for switching between the plurality of time series associated with the data points.

  In some embodiments, the data platform service automatically automates a data rollup time series that includes multiple aggregated data samples by aggregating the raw data samples when the raw data samples are collected from building equipment. A sample aggregator configured to store the data roll-up time series in a time series database as one of the generated and optimized data time series.

  In some embodiments, the data platform service creates virtual data points that represent unmeasured variables, calculates data values for multiple samples of virtual data points as a function of raw data samples, A virtual point calculator configured to generate a virtual point time series including samples and store the virtual point time series in a time series database as one of the optimized data time series;

  In some embodiments, the data platform service performs one or more analyzes using the raw data time series, generates a result time series that includes multiple result samples that indicate the results of the analysis, and is optimized An analysis service configured to store the result time series in a time series database as one of the data time series is included.

  In some embodiments, the ad hoc dashboard includes a widget creation interface that includes a plurality of selectable widget types. Each widget type may correspond to a different type of widget that the ad hoc dashboard is configured to create. The widget type includes at least one of a chart creation widget, a data visualization widget, a display widget, a date / time widget, and a weather information widget.

  In some embodiments, the widget is a charting widget configured to display a plurality of time series charts associated with a data point. The chart may include at least one of a line graph, an area chart, a columnar graph, a bar graph, a stacked graph, and a pie graph.

  In some embodiments, the time series database is configured to store a plurality of time series associated with a plurality of different data points. In some embodiments, the ad hoc dashboard is configured to associate a widget with each of a plurality of time series associated with a plurality of different data points. The widget may be configured to display a graphical visualization of each of a plurality of time series associated with the widget.

  In some embodiments, the widget is configured to determine a unit of measure for each of a plurality of time series associated with the widget and generate a line graph including the plurality of lines. Each of the plurality of lines may correspond to one or more time series associated with the widget. The widget may assign a common color to each of a plurality of lines corresponding to the time series in the same measurement unit, and may assign a different color to each of the plurality of lines corresponding to the time series in different measurement units.

  In some embodiments, the widget is configured to generate a heat map that includes a plurality of cells. Each cell may correspond to a different sample of data points associated with the widget. The widget may be configured to identify a numeric data value for each sample corresponding to a heat map cell, and assign a color to each cell in the heat map based on the corresponding sample numeric data value. is there.

  In some embodiments, the ad hoc dashboard displays a point list that includes multiple points detected by the building energy management system and receives user input to drag and drop one or more points from the point list to the widget. , In response to a user input dragging and dropping one or more of the points from the point list to the widget, the one or more points are configured to be associated with the widget.

  It should be appreciated by those skilled in the art that the above summary is merely exemplary and is not intended to be limiting in any way. For other aspects, inventive features, and advantages of the devices and / or processes described herein, as defined solely by the claims, read the detailed description set forth herein in conjunction with the accompanying drawings. It will be clear.

FIG. 1 is a diagram of a building with a building management system (BMS) and an HVAC system according to some embodiments. FIG. 2 is a schematic diagram of a waterside system that may be used as part of the HVAC system of FIG. 1 according to some embodiments. FIG. 2 is a block diagram of an airside system that can be used as part of the HVAC system of FIG. 1 according to some embodiments. FIG. 2 is a block diagram of a BMS that can be used in the building of FIG. 1 according to some embodiments. FIG. 2 is a block diagram of another BMS that can be used in the building of FIG. The BMS is shown to include a data collector, a data platform service, an application, and a dashboard layout generator, according to some embodiments. FIG. 6 is a block diagram of a time series service and an analysis service that can be implemented as some of the data platform services shown in FIG. 5 according to some embodiments. FIG. 7 is a block diagram illustrating an aggregation technique that can be used by the sample aggregator shown in FIG. 6 to aggregate raw data samples according to some embodiments. 7 is a data table that can be used to store a raw data time series and various optimized data time series that can be generated by the time series service of FIG. 6 according to some embodiments. FIG. 7 is a number of timeline diagrams illustrating synchronization of data samples that may be performed by the data aggregator shown in FIG. 6 according to some embodiments. 7 is a flow diagram illustrating the creation and storage of a fault detection time series that can be implemented by the job manager shown in FIG. 6 according to some embodiments. 4 is a data table that can be used to store raw data time series and fault detection time series, according to some embodiments. 6 is a flow diagram illustrating a method by which various time series can be generated, stored, and used by the data platform service of FIG. 5, according to some embodiments. FIG. 6 is an entity graph showing relationships between organizations, spaces, systems, points, and time series that can be used by the data collector of FIG. 5, according to some embodiments. FIG. 3 illustrates an example entity graph of a particular building management system according to some embodiments. FIG. 7 is an object relationship diagram illustrating relationships between entity templates, points, time series, and data samples that can be used by the data collector of FIG. 5 and the time series service of FIG. 6 according to some embodiments. 6 is a flow diagram illustrating the operation of the dashboard layout generator of FIG. 5, according to some embodiments. 6 is a grid illustrating a dashboard layout description that can be generated by the dashboard layout generator of FIG. 5, according to some embodiments. FIG. 6 illustrates an example of object code describing a dashboard layout that can be generated by the dashboard layout generator of FIG. 5, according to some embodiments. FIG. 15 illustrates a user interface illustrating a dashboard layout that can be generated from the dashboard layout description of FIG. 14 according to some embodiments. FIG. 6 illustrates another example of object code that describes another dashboard layout that can be generated by the dashboard layout generator of FIG. 5, according to some embodiments. FIG. 17 illustrates a user interface illustrating a dashboard layout that can be generated from the dashboard layout description of FIG. 16, according to some embodiments. FIG. 6 illustrates a login interface that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. FIG. 6 is a diagram of a summary dashboard that can be generated by the BMS of FIG. 5 according to some embodiments. 2 is a flow diagram of a process for configuring an energy management application, according to some embodiments. FIG. 6 is an illustration of an interface for configuring a space that can be generated by the BMS of FIG. 5, according to some embodiments. FIG. 6 is an illustration of an interface for configuring a space that can be generated by the BMS of FIG. 5, according to some embodiments. FIG. 6 is an illustration of an interface for configuring a space that can be generated by the BMS of FIG. 5, according to some embodiments. FIG. 6 is an illustration of an interface for configuring a space that can be generated by the BMS of FIG. 5, according to some embodiments. FIG. 6 is a diagram of an interface for configuring a data source that can be generated by the BMS of FIG. 5, according to some embodiments. FIG. 6 is a diagram of an interface for configuring a data source that can be generated by the BMS of FIG. 5, according to some embodiments. FIG. 6 is a diagram of an interface for configuring a data source that can be generated by the BMS of FIG. 5, according to some embodiments. FIG. 6 is a diagram of an interface for configuring a data source that can be generated by the BMS of FIG. 5, according to some embodiments. FIG. 6 is a diagram of an interface for configuring a data source that can be generated by the BMS of FIG. 5, according to some embodiments. FIG. 6 is a diagram of an interface for configuring a data source that can be generated by the BMS of FIG. 5, according to some embodiments. FIG. 6 illustrates an interface for configuring a meter that can be generated by the BMS of FIG. 5, according to some embodiments. FIG. 6 illustrates an interface for configuring a meter that can be generated by the BMS of FIG. 5, according to some embodiments. FIG. 6 illustrates an interface for configuring a meter that can be generated by the BMS of FIG. 5, according to some embodiments. FIG. 6 illustrates an interface for configuring a meter that can be generated by the BMS of FIG. 5, according to some embodiments. FIG. 35 is an additional view of the overview dashboard shown in FIGS. 19-34, according to some embodiments. FIG. 35 is an additional view of the overview dashboard shown in FIGS. 19-34, according to some embodiments. FIG. 7 is a block diagram illustrating the analysis service of FIG. 6 in more detail, according to some embodiments, a weather normalization module, an energy benchmarking module, a baseline comparison module, a night / day comparison module, and a weekend / weekday comparison module. FIG. FIG. 53 is a flow diagram of a process that may be performed by the weather normalization module of FIG. 52, according to some embodiments. FIG. 53 is a graph illustrating a regression model that can be generated by the weather normalization module of FIG. 52, according to some embodiments. FIG. 53 is a chart of energy usage intensity values that can be generated by the energy benchmarking module of FIG. 52, according to some embodiments. FIG. 53 is a chart of building energy consumption for a baseline that can be generated by the baseline comparison module of FIG. 52, according to some embodiments. FIG. 53 is a chart of building energy consumption that can be generated by the night / day comparison module of FIG. 52 highlighting days with a high night / day energy consumption ratio, according to some embodiments. FIG. 53 is a chart of building energy consumption that can be generated by the weekend / weekday comparison module of FIG. 52 highlighting weekends with a high weekend / weekday energy consumption ratio, according to some embodiments. FIG. 6 illustrates an ad hoc user interface that may be generated by the BMS of FIG. 5 according to some embodiments. FIG. 60 illustrates an interface for creating a widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating a widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for configuring widgets in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for configuring widgets in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 is a diagram illustrating an interface for aggregating and displaying time series data in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 is a diagram illustrating an interface for aggregating and displaying time series data in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 is a diagram illustrating an interface for aggregating and displaying time series data in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a heat map widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a heat map widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a heat map widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a text box widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a text box widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring an image widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring an image widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a data widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a data widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a clock widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a clock widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a clock widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a weather widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a weather widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a weather widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for sharing the ad hoc interface of FIG. 59 with other users or groups, according to some embodiments. FIG. 60 illustrates an interface for sharing the ad hoc interface of FIG. 59 with other users or groups, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a stacked graph widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a stacked graph widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a pie chart widget in the ad hoc interface of FIG. 59, according to some embodiments. FIG. 60 illustrates an interface for creating and configuring a pie chart widget in the ad hoc interface of FIG. 59, according to some embodiments. 2 is a point configuration interface with options for defining a stagnation point definition, according to some embodiments. FIG. 4 illustrates a pending fault interface that can be used to display detected faults to a user, according to some embodiments.

Overview

  Referring generally to the drawings, according to various embodiments, a building management system (BMS) having virtual data points, optimized data integration capabilities, and a dashboard that is independent of a framework is shown. . The BMS is configured to collect data samples from building equipment (eg, sensors, controllable equipment, building subsystems, etc.) and generate raw time series data from the data samples. BMS uses various data platform services to process raw time series data and optimize time series data (eg, data rollup time series data, virtual point time series data, fault detection time series data). Etc.) can be generated. Optimized time series data can be provided to various applications and / or stored in local or host storage. In some embodiments, the BMS includes three different layers that separate (1) data collection, (2) data storage, retrieval, and analysis, and (3) data visualization. This allows the BMS to support a variety of applications that use optimized time series data, and new applications can reuse the infrastructure provided by the data platform services.

  In some embodiments, the BMS includes a data collector configured to collect raw data samples from building equipment. The data collector can generate a raw data time series including a plurality of raw data samples and store the raw data time series in a time series database. In some embodiments, the data collector stores each raw data sample with a time stamp. The time stamp can include local time including the time when the raw data sample was collected, whatever the time zone the raw data sample was collected. The timestamp can also include a time difference that indicates the difference between local time and universal time. The combination of local time stamp and time difference provides a unique time stamp across daylight saving time boundaries. This allows applications that use time series data to display time series data in local time without first converting from universal time. The combination of the local time stamp and the time difference also provides enough information to convert the local time stamp to universal time without having to look into the daylight saving time schedule.

  In some embodiments, the data platform service includes a sample aggregator. The sample aggregator aggregates raw time-series data at predefined intervals (eg, 15 minute intervals, 1 hour intervals, 1 day intervals, 1 month intervals, etc.) and newly optimizes the aggregated values Generated time series can be generated. Since these optimized time series are compressed versions of raw time series data, they can be referred to as “data rollup”. The data rollup generated by the data aggregator provides an efficient mechanism for various applications to query time series data. For example, an application can build visualizations of time series data (eg, charts, graphs, etc.) using pre-aggregated data rollups rather than raw time series data. This allows the application to simply search for and present pre-aggregated data rollups, and the application does not need to perform the aggregation in response to the query. Because data rollups are pre-aggregated, applications can present data rollups quickly and efficiently without requiring additional processing at the time of the query to generate aggregated time series values. .

In some embodiments, the data platform service includes a virtual point calculator. The virtual point calculator can calculate virtual points based on raw time series data and / or optimized time series data. A virtual point can be a variety of mathematical operations (eg, addition, subtraction, multiplication, division, etc.) or functions (eg, average, maximum, minimum, thermodynamic functions, etc.) on real data points represented by time series data. Can be calculated by applying any of linear functions, nonlinear functions, etc.). For example, the virtual point calculator can calculate a virtual data point (pointID ₃ ) by adding two or more real data points (pointID ₁ and pointID ₂ ) (eg, pointID ₃ = pointID ₁ + pointID ₂ ) . As another example, the virtual point calculator can calculate an enthalpy data point (pointID ₄ ) based on the measured temperature data point (pointID ₅ ) and the measured pressure data point (pointID ₆ ) (eg, pointID ₄ = enthalpy). (PointID ₅ , pointID ₆ )). Virtual data points can be stored as optimized time series data.

  Applications can access and use virtual data points in the same way as real data points. The application does not need to know whether the data point is a real data point or a virtual data point. This is because both types of data points can be stored as optimized time series data and can be handled similarly by the application. In some embodiments, the optimized time series data is stored with attributes that designate each data point as either a virtual data point or a real data point. Such attributes allow an application to represent a given time series to represent a virtual data point or a real data point, even if both types of data points can be handled by that application as well. Can be identified.

  In some embodiments, the data platform service includes a scalable rules engine and / or an analysis service configured to analyze time series data to detect faults. Fault detection can be performed by applying a set of fault detection rules to time series data and determining whether a fault is detected in each section of the time series. Fault detection can be stored as optimized time series data. For example, a new time series can be generated together with a data value indicating whether or not a failure has been detected in each section of the time series. The time series of fault detection can be stored in local or host data storage along with raw time series data and / or optimized time series data.

  In some embodiments, the BMS includes a dashboard layout generator. The dashboard layout generator is configured to generate a layout for a user interface (ie, dashboard) that visualizes time series data. In some embodiments, the dashboard layout itself is not a user interface, but a description that can be used by an application to generate a user interface. In some embodiments, the dashboard layout is a schema that defines the relative positions of various widgets (eg, charts, graphs, etc.) that can be rendered and displayed as part of the user interface. The dashboard layout can be read by a variety of different frameworks and can be used by a variety of different rendering engines (eg, web browsers, pdf engines, etc.) or applications to generate a user interface.

  In some embodiments, the dashboard layout defines a grid having one or more rows and one or more columns located within each row. A dashboard layout can define the position of each widget at a particular position in the grid. A dashboard layout can define an array of objects (eg, JSON objects), where each object is itself an array. In some embodiments, the dashboard layout defines attributes or properties for each widget. For example, a dashboard layout can define the type of widget (eg, graph, plain text, image, etc.). If the widget is a graph, the dashboard layout can define additional properties such as the graph title, x-axis title, y-axis title, and time series data used in the graph. These and other features of the building management system are described in more detail below.

Building management system and HVAC system

  Referring now to FIGS. 1-4, exemplary building management systems (BMS) and HVAC systems in which the disclosed systems and methods may be implemented in accordance with exemplary embodiments are shown. With particular reference to FIG. 1, a perspective view of a building 10 is shown. The building 10 is serviced by BMS. A BMS is generally a system of devices configured to control, monitor and manage equipment inside or around a building or building area. The BMS can include, for example, an HVAC system, a security system, a lighting system, a fire alarm system, any other system capable of managing building functions or devices, or any combination thereof.

  The BMS serving the building 10 includes the HVAC system 100. The HVAC system 100 includes a plurality of HVAC devices (eg, heaters, coolers, air handling units, pumps, fans, heat, etc.) that are configured to provide heating, cooling, ventilation, or other services for the building 10. Energy storage devices, etc.). For example, the HVAC system 100 is shown as including a waterside system 120 and an airside system 130. The waterside system 120 may provide heated or cooled fluid to the air handling unit of the airside system 130. The airside system 130 may use heated or cooled fluid to heat or cool the airflow provided to the building 10. Exemplary waterside and airside systems that may be used with the HVAC system 100 are described in more detail with reference to FIGS.

  The HVAC system 100 is shown as including a cooler 102, a boiler 104, and a rooftop air handling unit (AHU) 106. The waterside system 120 can use the boiler 104 and the cooler 102 to heat or cool a working fluid (eg, water, glycol, etc.) and can circulate the working fluid to the AHU 106. In various embodiments, the HVAC device of the waterside system 120 may be located in or around the building 10 (as shown in FIG. 1) or a central plant (eg, a chiller plant, a steam plant, a heat plant). Etc.) may be located outside the field. The working fluid may be heated by the boiler 104 or cooled by the cooler 102 depending on whether the building 10 needs heating or cooling. The boiler 104 may apply heat to the circulated fluid, for example, by burning a combustible material (eg, natural gas) or by using an electrical heating element. The cooler 102 can absorb heat from the circulated fluid by placing the circulated fluid in a heat exchange relationship with another fluid (eg, a refrigerant) in a heat exchanger (eg, an evaporator). Working fluid from the cooler 102 and / or the boiler 104 may be transported to the AHU 106 through the piping 108.

  The AHU 106 may be in a heat exchange relationship between the airflow passing through the AHU 106 and the working fluid (eg, through one or more stages of a cooling coil and / or a heating coil). The airflow may be, for example, outside air, return air from inside the building 10, or a combination of both. AHU 106 may transfer heat between the air stream and the working fluid to heat or cool the air stream. For example, the AHU 106 may include one or more fans or blowers that are configured to flow air over or through a heat exchanger that includes a working fluid. The working fluid can then return to the cooler 102 or the boiler 104 through the piping 110.

  The airside system 130 may deliver airflow (ie, supply airflow) supplied by the AHU 106 to the building 10 through the supply air duct 112 and provide return air from the building 10 to the AHU 106 through the return air duct 114. In some embodiments, airside system 130 includes a plurality of variable air volume (VAV) units 116. For example, the airside system 130 is shown as including a separate VAV unit 116 on each floor or area of the building 10. VAV unit 116 may include dampers or other flow control elements that can be operated to control the amount of airflow provided to individual areas of building 10. In other embodiments, the airside system 130 delivers the air supply to one or more areas of the building 10 (eg, through the supply duct 112) without using the intermediate VAV unit 116 or other flow control elements. The AHU 106 may include various sensors (eg, temperature sensors, pressure sensors, etc.) configured to measure the attributes of the air supply. The AHU 106 can receive input from sensors located in the AHU 106 and / or in the building area, and adjusts the airflow flow rate, temperature, or other attributes through the AHU 106 to setpoint conditions for the building area. Can be realized.

  With reference now to FIG. 2, a block diagram of a waterside system 200 is depicted in accordance with an illustrative embodiment. In various embodiments, the waterside system 200 may assist or replace the waterside system 120 in the HVAC system 100, or may be implemented separately from the HVAC system 100. When implemented in the HVAC system 100, the waterside system 200 may include a subset of HVAC devices (eg, boiler 104, cooler 102, pumps, valves, etc.) within the HVAC system 100 to deliver heated or cooled fluid. Operate to supply to AHU 106. The HVAC device of the waterside system 200 may be located within the building 10 (eg, as a component of the waterside system 120) or at an off-site location such as a central plant.

  In FIG. 2, the waterside system 200 is shown as a central plant having a plurality of subplants 202-212. Subplants 202-212 include a heater subplant 202, a heat recovery cooler subplant 204, a cooler subplant 206, a cooling tower subplant 208, a high temperature thermal energy storage (TES) subplant 210, and a cold energy storage (TES). ) Is shown as including a subplant 212. Subplants 202-212 consume resources from utilities (eg, water, natural gas, electricity, etc.) and provide building or campus thermal energy loads (eg, hot water, cold water, heating, cooling, etc.). For example, the heater subplant 202 may be configured to heat water in a hot water loop 214 that circulates hot water between the heater subplant 202 and the building 10. The chiller subplant 206 may be configured to cool water in a chilled water loop 216 that circulates chilled water between the chiller subplant 206 and the building 10. The heat recovery cooler subplant 204 may be configured to transfer heat from the cold water loop 216 to the hot water loop 214 to allow additional heating for hot water and additional cooling for cold water. A condenser water loop 218 may absorb heat from the cold water in the cooler subplant 206 and either remove the absorbed heat into the cooling tower subplant 208 or transfer the absorbed heat to the hot water loop 214. . The high temperature TES sub-plant 210 and the low temperature TES sub-plant 212 may store high heat and low heat energy, respectively, for subsequent use.

  Hot water loop 214 and cold water loop 216 provide heated and / or cooled water to an air handler (eg, AHU 106) located on the roof of building 10 or to an individual floor or area of building 10 (eg, VAV unit 116). Can be sent. The air handler heats or cools air by pushing air through a heat exchanger (for example, a heating coil or a cooling coil) through which water flows. Heated or cooled air may be delivered to individual areas of the building 10 to provide the building 10 thermal energy load. The water then returns to subplants 202-212 and undergoes further heating or cooling.

  Subplants 202-212 are illustrated and described as heating and cooling water for circulation to the building, but are optional in place of or in addition to water to provide thermal energy load. It should be understood that other types of working fluids (eg, glycol, CO 2, etc.) may be used. In other embodiments, subplants 202-212 may provide heating and / or cooling directly to a building or campus without the need for intermediate heat transfer fluids. These and other variations on the waterside system 200 are within the teachings of the present invention.

  Each of the sub-plants 202-212 may include various devices configured to facilitate the sub-plant functions. For example, the heater sub-plant 202 is shown as including a plurality of heating elements 220 (eg, boilers, electric heaters, etc.) configured to apply heat to the hot water in the hot water loop 214. The heater subplant 202 is also shown as including a number of pumps 222 and 224 that circulate hot water within the hot water loop 214 and pass through individual heating elements 220. It is configured to control the flow rate of hot water. The chiller subplant 206 is shown as including a plurality of chillers 232 configured to remove heat from the chilled water in the chilled water loop 216. The cooler subplant 206 is also shown as including a number of pumps 234 and 236 that circulate chilled water within the chilled water loop 216 and pass chilled water through individual coolers 232. It is configured to control the flow rate.

  The heat recovery cooler subplant 204 is shown as including a plurality of heat recovery heat exchangers 226 (eg, refrigeration circuits) configured to transfer heat from the cold water loop 216 to the hot water loop 214. The heat recovery cooler subplant 204 is also shown as including several pumps 228 and 230 that circulate hot and / or cold water through the heat recovery heat exchanger 226 and individually The heat recovery heat exchanger 226 is configured to control the flow rate of water. The cooling tower subplant 208 is shown as including a plurality of cooling towers 238 configured to remove heat from the condenser water in the condenser water loop 218. The cooling tower subplant 208 is also shown as including a number of pumps 240 that circulate condenser water within the condenser water loop 218 and pass through individual cooling towers 238. Configured to control water flow rate.

  High temperature TES subplant 210 is shown as including a high temperature TES tank 242 configured to store hot water for later use. The high temperature TES sub-plant 210 may also include one or more pumps or valves that are configured to control the flow of hot water into and out of the high temperature TES tank 242. The low temperature TES subplant 212 is shown as including a low temperature TES tank 244 configured to store cold water for later use. The low temperature TES sub-plant 212 may also include one or more pumps or valves that are configured to control the flow of cold water into and out of the low temperature TES tank 244.

  In some embodiments, one or more pumps in the waterside system 200 (eg, pumps 222, 224, 228, 230, 234, 236, and / or 240) or one or more pipelines in the waterside system 200 are connected to them. Includes an associated isolation valve. The isolation valve may be integrated with the pump or positioned upstream or downstream of the pump to control fluid flow in the waterside system 200. In various embodiments, the waterside system 200 can be configured with more, fewer, or different types of devices based on the particular configuration of the waterside system 200 and the type of load provided by the waterside system 200. It may also contain sub-plants.

  With reference now to FIG. 3, a block diagram of an airside system 300 is depicted in accordance with an illustrative embodiment. In various embodiments, the airside system 300 may assist or replace the airside system 130 in the HVAC system 100 or may be implemented separately from the HVAC system 100. When implemented in the HVAC system 100, the airside system 300 may include a subset of HVAC devices (eg, AHU 106, VAV unit 116, ducts 112-114, fans, dampers, etc.) within the HVAC system 100 and within the building 10 Or it can be located in the vicinity. Airside system 300 may operate to heat or cool the airflow provided to building 10 using the heated or cooled fluid provided by waterside system 200.

  In FIG. 3, an airside system 300 is shown as including an economizer air handling unit (AHU) 302. The economizer AHU changes the amount of outside and return air used by the air handling unit for heating or cooling. For example, the AHU 302 may receive the return air 304 from the building area 306 through the return air duct 308 and may deliver the supply air 310 to the building area 306 through the air supply duct 312. In some embodiments, the AHU 302 is positioned on a rooftop unit (eg, AHU 106 shown in FIG. 1) located on the roof of the building 10 or elsewhere to receive both return air 304 and outside air 314. It is a rooftop unit. The AHU 302 may be configured to operate the exhaust damper 316, the mixing damper 318, and the outside air damper 320 to control the amount of outside air 314 and return air 304 that mix to produce the supply air 310. The return air 304 that does not pass through the mixing damper 318 can be exhausted from the AHU 302 through the exhaust damper 316 as exhaust 322.

  Each of the dampers 316 to 320 can be operated by an actuator. For example, the exhaust damper 316 can be operated by the actuator 324, the mixing damper 318 can be operated by the actuator 326, and the outside air damper 320 can be operated by the actuator 328. Actuators 324-328 may communicate with AHU controller 330 via communication link 332. Actuators 324-328 can receive control signals from AHU controller 330 and can provide feedback signals to AHU controller 330. The feedback signal includes, for example, an indication of the current actuator or damper position, the amount of torque or force exerted by the actuator, diagnostic information (eg, results of diagnostic tests performed by actuators 324-328), status information, commissioning information, configuration Settings, calibration data, and / or other types of information or data that may be collected, stored, or used by actuators 324-328 may be included. The AHU controller 330 includes one or more control algorithms (eg, state-based algorithm, extreme value search control (ESC) algorithm, proportional integral (PI) control algorithm, proportional integral derivative (PID) control algorithm, model predictive control (MPC)). An economizer control device configured to control the actuators 324 to 328 using an algorithm, a feedback control algorithm, or the like.

  With continued reference to FIG. 3, the AHU 302 is shown as including a cooling coil 334, a heating coil 336, and a fan 338 positioned within the air supply duct 312. The fan 338 may be configured to pass the supply air 310 through the cooling coil 334 and / or the heating coil 336 and further provide the supply air 310 to the building area 306. The AHU controller 330 may communicate with the fan 338 via the communication link 340 to control the flow rate of the supply air 310. In some embodiments, the AHU controller 330 controls the amount of heating or cooling applied to the supply air 310 by adjusting the speed of the fan 338.

  The cooling coil 334 can receive the cooled fluid from the waterside system 200 (eg, from the chilled water loop 216) through the piping 342, and can return the cooled fluid to the waterside system 200 through the piping 344. it can. Valve 346 may be positioned along line 342 or line 344 to control the flow rate of cooling fluid through cooling coil 334. In some embodiments, multiple cooling coils 334 may be activated and deactivated independently (eg, by AHU controller 330, BMS controller 366, etc.) to adjust the amount of cooling applied to supply air 310. Includes stage cooling coil.

  The heating coil 336 can receive heated fluid from the waterside system 200 (eg, from the hot water loop 214) through the piping 348, and can return heated fluid to the waterside system 200 through the piping 350. it can. A valve 352 can be positioned along line 348 or line 350 to control the flow of heated fluid through the heating coil 336. In some embodiments, the heating coil 336 can be activated and deactivated independently (eg, by the AHU controller 330, the BMS controller 366, etc.) to adjust the amount of heat applied to the supply air 310. Includes stage heating coil.

  Valves 346 and 352 can each be controlled by an actuator. For example, valve 346 may be controlled by actuator 354 and valve 352 may be controlled by actuator 356. Actuators 354-356 may communicate with AHU controller 330 via communication links 358-360. Actuators 354-356 can receive control signals from AHU controller 330 and can provide feedback signals to controller 330. In some embodiments, the AHU controller 330 receives a supply air temperature measurement from a temperature sensor 362 positioned in the supply air duct 312 (eg, downstream of the cooling coil 334 and / or the heating coil 336). The AHU controller 330 may also receive temperature measurements of the building area 306 from a temperature sensor 364 located within the building area 306.

  In some embodiments, AHU controller 330 operates valves 346 and 352 by actuators 354-356 to provide a supply air (eg, to achieve a setpoint temperature of supply 310 or within a setpoint temperature range). Adjust the amount of heating or cooling provided to the supply air 310 (to maintain the temperature of 310). The position of valves 346 and 352 affects the amount of heating or cooling provided to supply air 310 by cooling coil 334 or heating coil 336, and the amount of energy consumed to achieve the desired supply air temperature. Can be correlated. AHU controller 330 may control the temperature of supply air 310 and / or building area 306 by activating or deactivating coils 334-336, adjusting the speed of fan 338, or a combination of both.

  With continued reference to FIG. 3, the airside system 300 is shown as including a building management system (BMS) controller 366 and a client device 368. The BMS controller 366 may be a master control for one or more computer systems (eg, servers, supervisory controllers, subsystem controllers, etc.), application or data servers, head nodes, or airside systems 300 that act as system level controllers. The apparatus, waterside system 200, HVAC system 100, and / or other controllable systems that service the building 10 may be included. The BMS controller 366 communicates with multiple downstream building systems or subsystems (eg, HVAC system 100, security system, lighting system, waterside system 200, etc.) and communication links according to similar or different protocols (eg, LON, BACnet, etc.). 370 may communicate. In various embodiments, the AHU controller 330 and the BMS controller 366 may be separate (as shown in FIG. 3) or integrated. In an integrated implementation, the AHU controller 330 may be a software module configured to be executed by the processor of the BMS controller 366.

  In some embodiments, the AHU controller 330 receives information (eg, commands, settings, operating boundaries, etc.) from the BMS controller 366 and informs the BMS controller 366 (eg, temperature readings, valve or actuator position). Operating status, diagnostics, etc.). For example, the AHU controller 330 can provide the BMS controller 366 with temperature measurements from temperature sensors 362-364, device on / off status, device operating capability, and / or any other information. These information can then be used by the BMS controller 366 to monitor or control changing conditions or conditions within the building area 306.

  Client device 368 may include one or more human-machine interfaces or client interfaces (eg, graphical user interfaces, etc.) for controlling, viewing, or otherwise interacting with HVAC system 100, its subsystems, and / or devices. Reporting interfaces, text-based computer interfaces, client facing web services, web servers that provide pages to web clients, etc.). Client device 368 may be a computer workstation, client terminal, remote or local interface, or any other type of user interface device. Client device 368 may be a fixed terminal or a mobile device. For example, client device 368 may 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 device 368 may communicate with BMS controller 366 and / or AHU controller 330 via communication link 372.

  With reference now to FIG. 4, a block diagram of a building management system (BMS) 400 is depicted in accordance with an illustrative embodiment. BMS 400 may be implemented in building 10 to automatically monitor and control various building functions. BMS 400 is shown as including a BMS controller 366 and a plurality of building subsystems 428. Building subsystem 428 includes building electrical subsystem 434, information and communication technology (ICT) subsystem 436, security subsystem 438, HVAC subsystem 440, lighting subsystem 442, elevator / escalator subsystem 432, and fire safety subsystem 430. Is shown as including. In various embodiments, the building subsystem 428 can include fewer, additional, or alternative subsystems. For example, in addition or as an alternative, the building subsystem 428 may be controlled to monitor or control the refrigeration subsystem, the advertising or signing subsystem, the cooking subsystem, the sales subsystem, the printer or copy service subsystem, or the building 10. It may include any other type of building subsystem that uses possible equipment and / or sensors. In some embodiments, the building subsystem 428 includes a waterside system 200 and / or an airside system 300 as described with reference to FIGS.

  Each building subsystem 428 may include a number of devices, controllers, and connections for completing its individual functions and control activities. The HVAC subsystem 440 may include many of the same components as the HVAC system 100 as described with reference to FIGS. For example, the HVAC subsystem 440 may include a cooler, boiler, multiple air handling units, economizer, field controller, supervisory controller, actuator, temperature sensor, and temperature, humidity, airflow, or other variable within the building 10. Other devices for controlling conditions may be included. The lighting subsystem 442 may include a number of lighting fixtures, ballasts, lighting sensors, dimmers, or other devices configured to controllably adjust the amount of light provided to the building space. Security subsystem 438 may include motion sensors, video surveillance cameras, digital video recorders, video processing servers, intrusion detection devices, access control devices and servers, or other security-related devices.

  With continued reference to FIG. 4, the BMS controller 366 is shown as including a communication interface 407 and a BMS interface 409. Interface 407 facilitates communication between BMS controller 366 and external applications (eg, monitoring and reporting application 422, enterprise management application 426, remote system and application 444, application resident on client device 448, etc.) User control, monitoring, and adjustments to controller 366 and / or subsystem 428 may be enabled. Interface 407 may also facilitate communication between BMS controller 366 and client device 448. The BMS interface 409 may facilitate communication between the BMS controller 366 and the building subsystem 428 (eg, HVAC, lighting security, elevator, power distribution, business, etc.).

  Interfaces 407, 409 may also be wired or wireless communication interfaces (eg, jacks, antennas, transmitters, receivers, transceivers, wired terminals, etc.) for data communication with building subsystem 428 or other external systems or devices. Well, or you can include it. In various embodiments, communication via the interfaces 407, 409 may be direct (eg, local wired or wireless communication) or via a communication network 446 (eg, WAN, Internet, cellular network, etc.). For example, the interfaces 407, 409 can include Ethernet cards and ports for transmitting and receiving data over an Ethernet-based communication link or network. In another example, the interfaces 407, 409 can include Wi-Fi transceivers for communicating via a wireless communication network. In another example, one or both of interfaces 407, 409 may include a cellular or cellular telephone transceiver. In one embodiment, the communication interface 407 is a power line communication interface and the BMS interface 409 is an Ethernet interface. In other embodiments, the communication interface 407 and the BMS interface 409 are both Ethernet interfaces or the same Ethernet interface.

  With continued reference to FIG. 4, the BMS controller 366 is shown as including a processing circuit 404 including a processor 406 and a memory 408. The processing circuit 404 may be communicatively connected to the BMS interface 409 and / or the communication interface 407 so that the processing circuit 404 and its various components can send and receive data via the interfaces 407, 409. The processor 406 may be implemented as a general purpose processor, application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGA), a group of processing components, or other suitable electronic processing components.

  Memory 408 (eg, memory, memory unit, storage device, etc.) is one or more devices for storing data and / or computer code for completing or facilitating the various processes, layers, and modules described in this application. (Eg, RAM, ROM, flash memory, hard disk storage, etc.). Memory 408 may be or include volatile memory or non-volatile memory. Memory 408 may include database components, object code components, script components, or any other type of information structure to support various activities and information structures described in this application. According to an exemplary embodiment, memory 408 is communicatively coupled to processor 406 via processing circuit 404 and performs one or more processes described herein (eg, by processing circuit 404 and / or processor 406). Computer code to do.

  In some embodiments, the BMS controller 366 is implemented in a single computer (eg, one server, one housing, etc.). In various other embodiments, the BMS controller 366 may be distributed across multiple servers or computers (eg, which may reside in distributed locations). Further, although FIG. 4 shows applications 422 and 426 as being external to BMS controller 366, in some embodiments, applications 422 and 426 are within BMS controller 366 (eg, in memory 408). ).

  Still referring to FIG. 4, the memory 408 includes an enterprise integration layer 410, an automated measurement and verification (AM & V) layer 412, a request response (DR) layer 414, a failure detection and diagnosis (FDD) layer 416, an integrated control layer 418, and Illustrated as including a building subsystem integration layer 420. Layers 410-420 receive input from the building subsystem 428 and other data sources, determine an optimal control action for the building subsystem 428 based on the input, and generate control signals based on the optimal control action. Generated and configured to provide the generated control signal to the building subsystem 428. The following paragraphs describe some of the general functions performed by each layer 410-420 in BMS 400.

  Enterprise integration layer 410 may be configured to provide information or services to clients or local applications to support various enterprise level applications. For example, the enterprise management application 426 may be configured to provide subsystem spanning control to a graphical user interface (GUI) or a number of enterprise level business applications (eg, accounting systems, user identification systems, etc.). Enterprise management application 426 may additionally or alternatively be configured to provide a configuration GUI for configuring BMS controller 366. In yet other embodiments, enterprise management application 426 cooperates with layers 410-420 to build performance (eg, efficiency, energy usage, comfort, etc.) based on inputs received at interface 407 and / or BMS interface 409. Performance, or safety) can be optimized.

  Building subsystem integration layer 420 may be configured to manage communication between BMS controller 366 and building subsystem 428. For example, the building subsystem integration layer 420 may receive sensor data and input signals from the building subsystem 428 and provide output data and control signals to the building subsystem 428. The building subsystem integration layer 420 may be configured to manage communication between the building subsystems 428. The building subsystem integration layer 420 converts communications (eg, sensor data, input signals, output signals, etc.) across multiple multi-vendor / multi-protocol systems.

  The request response layer 414 is responsive to meeting the requirements of the building 10 for resource usage (e.g., electricity usage, natural gas usage, water usage, etc.) and / or money for such resource usage. Can be configured to optimize the cost. Optimization may include time-based prices, reduced signals, energy availability, or utilities, distributed energy generation systems 424, energy storage devices 427 (eg, high temperature TES 242 or low temperature TES 244), or other sources. Based on other data received from. The request response layer 414 may receive input from other layers of the BMS controller 366 (eg, the building subsystem integration layer 420, the integrated control layer 418, etc.). Input received from other layers may include environmental inputs such as temperature, carbon dioxide level, relative humidity level, air quality sensor output, human sensor output, room schedule, or sensor input. Inputs may also include inputs such as electricity usage from utilities (eg, expressed in units of kWh), thermal load measurements, price information, forecast prices, smoothed prices, reduction signals, and the like.

  According to an exemplary embodiment, request response layer 414 includes control logic for responding to received data and signals. These responses include communicating with the control algorithm in the integrated control layer 418, changing the control strategy, changing settings, or activating / deactivating building equipment or subsystems under control. be able to. The request response layer 414 may also include control logic configured to determine when to use the stored energy. For example, request response layer 414 may determine to begin using energy from energy storage device 427 just prior to the start of peak usage time.

  In some embodiments, the request response layer 414 minimizes energy costs (eg, automatic A control module configured to actively initiate a control action (which automatically changes a setpoint). In some embodiments, request response layer 414 uses an equipment model to determine an optimal set of control actions. Equipment models can include, for example, thermodynamic models that describe inputs, outputs, and / or functions performed by various sets of building equipment. An equipment model may represent a collection of building equipment (eg, subplants, cooler arrays, etc.) or individual devices (eg, individual coolers, heaters, pumps, etc.).

  Further, the request response layer 414 may include or utilize one or more request response policy definitions (eg, database, XML file, etc.). The policy definition can be edited or adjusted by the user (eg, via a graphical user interface) so that the control action initiated in response to the request input is tailored to the user's application and desired comfort It can be tailored to the level, to the particular building equipment, or based on other matters. For example, a request response policy definition can determine which devices can be turned on or off in response to specific request inputs, how long a system or device should be turned off, which settings can be changed, and acceptable settings How much is the adjustment range, how long to keep the high demand setpoint before returning to the planned setpoint as usual, how close to the capacity limit, which equipment mode to use, energy storage device (eg thermal Energy transfer speed to and from the storage tank, battery bank, etc. (eg maximum speed, alarm speed, other speed limit information, etc.) and on-site energy generation (eg via fuel cell, motor generator set, etc.) You can specify when to send.

  The integrated control layer 418 may be configured to make control decisions using the building subsystem integration layer 420 and / or the request response layer 414 data inputs or outputs. The integration of subsystems provided by the building subsystem integration layer 420 allows the integrated control layer 418 to integrate the control activities of the subsystem 428 so that the subsystem 428 is a single integrated super system. Behave. In the exemplary embodiment, integrated control layer 418 includes control logic that uses inputs and outputs from multiple building subsystems, which is greater than the comfort and energy savings that an individual subsystem can provide alone. Provides comfort and energy savings. For example, the integrated control layer 418 may be configured to make an energy saving control decision for the second subsystem using input from the first subsystem. The results of these decisions can be communicated back to the building subsystem integration layer 420.

  The unified control layer 418 is shown as being logically below the request response layer 414. The unified control layer 418 may be configured to increase the effectiveness of the request response layer 414 by allowing the building subsystem 428 and their respective control loops to be controlled jointly with the request response layer 414. This configuration can advantageously reduce destructive demand response behavior compared to conventional systems. For example, the integrated control layer 418 allows the upward correction based on the demand response to the setpoint of the temperature of the cooled water (or another component that directly or indirectly affects the temperature) to cool the fan energy (or space). Can be configured to ensure that it does not result in an increase in other energy used. Such an increase in fan energy will cause the total building energy usage to be greater than the energy stored in the cooler.

  The unified control layer 418 may be configured to provide feedback to the request response layer 414 so that the request response layer 414 is constrained even during the requested partial power outage. Check that the temperature (such as temperature and lighting level) is maintained properly. Constraints may include setpoints or detection boundaries related to safety, equipment operating limits and performance, comfort, fire codes, electrical codes, energy codes, and the like. The integrated control layer 418 is also logically below the fault detection and diagnosis layer 416 and the automatic measurement and verification layer 412. The integrated control layer 418 may be configured to provide calculated inputs (eg, aggregates) to these higher level layers based on outputs from multiple building subsystems.

  The automated measurement and verification (AM & V) layer 412 is a unified control layer (eg, using data aggregated by the AM & V layer 412, the integrated control layer 418, the building subsystem integration layer 420, the FDD layer 416, or other layers). It may be configured to verify that the control strategy commanded by 418 or request response layer 414 is functioning properly. The calculations performed by the AM & V layer 412 may be based on building system energy models and / or equipment models for individual BMS devices or subsystems. For example, the AM & V layer 412 may compare the predicted output based on the model with the actual output from the building subsystem 428 to determine the accuracy of the model.

  Fault detection and diagnosis (FDD) layer 416 provides continuous fault detection functionality for building subsystem 428 and building subsystem devices (ie, building equipment) and algorithms used by request response layer 414 and integrated control layer 418. Can be configured to control. The FDD layer 416 may receive data input from the integrated control layer 418, directly from one or more building subsystems or devices, or from another data source. The FDD layer 416 may automatically diagnose and respond to detected faults. The response to the detected or diagnosed fault may include providing an alert message to a user, a maintenance scheduling system, or a control algorithm configured to attempt to repair or address the fault.

  The FDD layer 416 uses the detailed subsystem inputs available in the building subsystem integration layer 420 to output a specific identification of the failing component or the cause of the failure (eg, loose damper linkage). Can be configured. In other exemplary embodiments, the FDD layer 416 is configured to provide a “failure” event to the integrated control layer 418, and the integrated control layer 418 provides control strategies and policies in response to the received failure event. Run. According to an exemplary embodiment, the FDD layer 416 (or a policy executed by the integrated control engine or business rules engine) shuts down the system or directs control activity around the failing device or system. Thus, energy waste can be reduced, instrument life can be extended, or proper control response can be ensured.

  The FDD layer 416 may be configured to store or access a variety of different system data stores (or data points for live data). The FDD layer 416 uses certain content in the data store to identify failures at the device level (eg, specific coolers, specific AHUs, specific terminal units, etc.) and configure other content Can be used to identify failures at the element or subsystem level. For example, the building subsystem 428 may generate temporal (ie, time series) data that indicates the performance of the BMS 400 and its various components. Data generated by the building subsystem 428 may include measured or calculated values that are indicative of statistical characteristics and correspond to a corresponding system or process (eg, temperature control process or flow control). Provides information on how the process, etc.) behaves in response to errors from its setpoint. These processes can be inspected by the FDD layer 416 to reveal when system performance has begun to degrade and alert the user to repair the fault before it becomes more serious.

Building management system with data platform services

  Referring to FIG. 5, a block diagram of another building management system (BMS) 500 according to some embodiments is shown. BMS 500 is configured to collect data samples from building subsystem 428 and generate raw time series data from those data samples. The BMS 500 can process raw time series data using various data platform services 520 to generate optimized time series data (eg, data rollup). Optimized time series data can be provided to various applications 530 and / or stored in local storage 514 or host storage 516. In some embodiments, the BMS 500 separates data collection; data storage, retrieval, and analysis; and data visualization into three different layers. This allows the BMS 500 to support a variety of applications 530 that use optimized time series data so that new applications 530 can reuse the existing infrastructure provided by the data platform service 520. become.

  Prior to discussing BMS 500 in more detail, the components of BMS 500 may be integrated within a single device (eg, supervisory controller, BMS controller, etc.) or distributed across multiple individual systems or devices. Please note that it is good. For example, the components of the BMS 500 are Johnson Controls Inc. Can be implemented as part of a METASYS® brand building automation system or METASYS® energy management system (MEMS) sold by In other embodiments, some or all of the components of BMS 500 may be implemented as part of a cloud-based computing system configured to receive and process data from one or more building management systems. it can. In other embodiments, some or all of the components of the BMS 500 may include subsystem level controllers (eg, HVAC controllers), subplant controllers, device controllers (eg, AHU controllers 330, cooler controllers, etc.) ), A field controller, a computer workstation, a client device, or any other system or device that receives and processes data from building equipment.

  The BMS 500 can include many of the same components as the BMS 400, as described with reference to FIG. For example, BMS 500 is shown to include a BMS interface 502 and a communication interface 504. Interfaces 502-504 are wired or wireless communication interfaces (eg, jacks, antennas, transmitters, receivers, transceivers, wired terminals, etc.) for data communication with building subsystem 428 or other external systems or devices. Can be included. Communication performed via the interfaces 502 to 504 may be direct (for example, local wired or wireless communication) or via a communication network 446 (for example, WAN, Internet, cellular network, etc.).

  Communication interface 504 may facilitate communication between BMS 500 and external applications (eg, remote systems and applications 444) to allow user control, monitoring, and coordination to BMS 500. Communication interface 504 may also facilitate communication between BMS 500 and client device 448. The BMS interface 502 can facilitate communication between the BMS 500 and the building subsystem 428. The BMS 500 is configured to communicate with the building subsystem 428 using any of a variety of building automation system protocols (eg, BACnet®, Modbus®, ADX®, etc.). be able to. In some embodiments, the BMS 500 receives data samples from the building subsystem 428 and provides control signals to the building subsystem 428 via the BMS interface 502.

  Building subsystem 428 includes building electrical subsystem 434, information and communication technology (ICT) subsystem 436, security subsystem 438, HVAC subsystem 440, lighting subsystem 442, elevator / sub-system, as described with reference to FIG. An escalator subsystem 432 and / or a fire safety subsystem 430 may be included. In various embodiments, the building subsystem 428 can include fewer, additional, or alternative subsystems. For example, building subsystem 428 may monitor or use a refrigeration subsystem, advertising or signing subsystem, cooking subsystem, sales subsystem, printer or copy service subsystem, or controllable equipment and / or sensors. Includes any other type of building subsystem to control. In some embodiments, the building subsystem 428 includes a waterside system 200 and / or an airside system 300 as described with reference to FIGS. Each of the building subsystems 428 may include any number of devices, controllers, and connection means for completing its individual functions and control activities. The building subsystem 428 can include building equipment (eg, sensors, air handling units, coolers, pumps, valves, etc.) configured to monitor and control building conditions such as temperature, humidity, and airflow. .

  Referring now to FIG. 5, BMS 500 is shown as including a processing circuit 506 that includes a processor 508 and a memory 510. The processor 508 may be a general purpose or special purpose processor, application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGA), a group of processing components, or other suitable processing components. The processor 508 is configured to execute computer code or instructions stored in the memory 510 or received from other computer readable media (eg, CDROM, network storage, remote server, etc.).

  The memory 510 includes one or more devices (eg, memory units, memory devices, storage devices, etc.) for storing data and / or computer code for completing and / or facilitating various processes described in this disclosure. obtain. Memory 510 is random access memory (RAM), read only memory (ROM), magnetic storage, temporary storage, non-volatile memory, flash memory, optical memory, or for storing software objects and / or computer instructions. Any other suitable memory may be included. Memory 510 may include database components, object code components, script components, or any other type of information structure to support various activities and information structures described in this disclosure. Memory 510 may be communicatively coupled to processor 508 via processing circuitry 506 and may include computer code for executing one or more processes described herein (eg, by processor 508). When processor 508 executes instructions stored in memory 510, processor 508 generally configures processing circuitry 506 to complete such activities.

  Still referring to FIG. 5, the BMS 500 is shown to include a data collector 512. Data collector 512 is shown to receive data samples from building subsystem 428 via BMS interface 502. In some embodiments, the data sample includes data values for various data points. The data value can be a measured value or a calculated value, depending on the type of data point. For example, a data point received from a temperature sensor can include a measured data value that indicates a temperature measured by the temperature sensor. Data points received from the chiller controller can include a calculated data value indicative of the calculated efficiency of the chiller. Data collector 512 can receive data samples from a plurality of different devices in building subsystem 428.

  A data sample can include one or more attributes that describe or characterize the corresponding data point. For example, the data sample has a name attribute that defines a point name or ID (eg, “B1F4R2.TZ”), a device attribute that indicates the type of device from which the data sample is received (eg, a temperature sensor, a humidity sensor, a cooler). Etc.), unit attributes that define the scale unit associated with the data value (eg, ° F, ° C, kPA, etc.), and / or any other that describes the corresponding data point or provides contextual information about the data point Attributes. The type of attribute included in each data point may depend on the communication protocol used to send the data samples to the BMS 500. For example, data samples received via the ADX protocol or BACnet protocol can include various descriptive attributes along with data values, and data samples received via the Modbus protocol can have fewer attributes (eg, corresponding May contain data values only).

  In some embodiments, each data sample is received with a timestamp indicating the time at which the corresponding data value was measured or calculated. In other embodiments, the data collector 512 adds a time stamp to the data sample based on the time at which the data sample was received. Data collector 512 can generate raw time series data for each data point at which a data sample is received. Each time series can include a series of data values for the same data point and a time stamp for each data value. For example, a time series for data points provided by a temperature sensor can include a series of temperature values measured by the temperature sensor and a corresponding time at which the temperature value was measured.

  Data collector 512 can add timestamps to the data samples or modify existing timestamps so that each data sample includes a local timestamp. Each local time stamp indicates the local time at which the corresponding data sample was measured or collected, and may include a time difference with respect to universal time. The local time stamp indicates the local time at the position where the data point was measured during measurement. The time difference indicates a difference between local time and universal time (for example, time on an international date change line). For example, a data sample collected in a time zone that is 6 hours behind the universal time includes a local time stamp (for example, time stamp = 2006-03-18T14: 10: 02) and a local time stamp of 6 hours from the universal time. A time difference indicating that the time is delayed (for example, time difference = −6: 00) can be included. The time difference can be adjusted depending on whether the time zone is daylight saving time when the data samples are measured or collected (eg, +1: 00 or -1: 00).

  The combination of local time stamp and time difference provides a unique time stamp across daylight saving time boundaries. This allows applications that use time series data to display time series data in local time without first converting from universal time. The combination of the local time stamp and the time difference also provides enough information to convert the local time stamp to universal time without having to look into the daylight saving time schedule. For example, a universal time value corresponding to the local time stamp can be generated by subtracting the time difference from the local time stamp without referring to an external database and without requiring other information.

  In some embodiments, the data collector 512 organizes raw time series data. Data collector 512 can identify a system or device associated with each data point. For example, the data collector 512 can associate data points with temperature sensors, air handling devices, coolers, or any other type of system or device. In various embodiments, the data collector uses a data point name, a range of data point values, a statistical characteristic of the data point, or other attributes of the data point, or a specific system associated with the data point or Identify the device. The data collector 512 can then determine how the system or device relates to other systems or devices in the building site. For example, the data collector 512 is part of a larger system (eg, an HVAC system) or the identified system or device serves a particular space (eg, a particular building, building room or area, etc.). It can be determined. In some embodiments, the data collector 512 uses or creates an entity graph when organizing time series data. An example of such an entity graph is described in more detail with reference to FIG. 10A.

  Data collector 512 can provide raw time series data to data platform service 520 and / or store raw time series data in local storage 514 or host storage 516. As shown in FIG. 5, the local storage device 514 may be a data storage device within the BMS 500 (eg, in the memory 510) or other local on-site data storage device in the building premises from which data samples are collected. . The host storage device 516 may include a remote database, cloud-based data hosting, or other remote data storage device. For example, the host storage device 516 can include a remote data storage device located outside a building site where data samples are collected.

  With further reference to FIG. 5, BMS 500 is shown to include a data platform service 520. Data platform service 520 may receive raw time series data from data collector 512 and / or retrieve raw time series data from local storage 514 or host storage 516. Data platform services 520 may include various services configured to analyze and process raw time series data. For example, the data platform service 520 is shown to include a security service 522, an analysis service 524, an entity service 526, and a time series service 528. The security service 522 can assign security attributes to raw time series data to ensure that only authorized individuals, systems, or applications can access the time series data. The entity service 526 can assign entity information to the time series data to associate the data points with a particular system, device, or space. The time series service 528 and the analysis service 524 can generate a new optimized time series from the raw time series data.

  In some embodiments, the time series service 528 aggregates raw time series data at predefined intervals (eg, 15 minute intervals, 1 hour intervals, 1 day intervals, 1 month intervals, etc.) Generate a new optimized time series of the aggregated values. Since these optimized time series are compressed versions of raw time series data, they can be referred to as “data rollup”. The data rollup generated by time series service 538 provides an efficient mechanism for application 530 to query time series data. For example, the application 530 can build visualizations of time series data (eg, charts, graphs, etc.) using pre-aggregated data rollups rather than raw time series data. As a result, the application 530 can simply search and present the data rollup that has been pre-aggregated, and the application 530 does not need to perform the aggregation in response to the query. Since the data rollup is pre-aggregated, the application 530 can present the data rollup quickly and efficiently without requiring additional processing at the time of the query to generate the aggregated time series values. it can.

In some embodiments, the time series service 528 calculates virtual points based on raw time series data and / or optimized time series data. A virtual point can be a variety of mathematical operations (eg, addition, subtraction, multiplication, division, etc.) or functions (eg, average, maximum, minimum, thermodynamic functions, etc.) on real data points represented by time series data. Can be calculated by applying any of linear functions, nonlinear functions, etc.). For example, the time series service 528 can calculate a virtual data point (pointID ₃ ) by adding two or more real data points (pointID ₁ and pointID ₂ ) (eg, pointID ₃ = pointID ₁ + pointID ₂ ). As another example, the time series service 528 can calculate an enthalpy data point (pointID ₄ ) based on the measured temperature data point (pointID ₅ ) and the measured pressure data point (pointID ₆ ) (eg, pointID ₄ = Enthalpy (pointID ₅ , pointID ₆ )). Virtual data points can be stored as optimized time series data.

  Application 530 can access and use virtual data points in the same way as real data points. Application 530 need not know whether the data point is a real data point or a virtual data point. This is because both types of data points can be stored as optimized time series data and can be handled similarly by the application 530. In some embodiments, the optimized time series data is stored with attributes that designate each data point as either a virtual data point or a real data point. Such attributes allow application 530 to treat both types of data points similarly by application 530, but to identify whether a given time series represents a virtual data point or a real data point. Will be able to.

  In some embodiments, the analysis service 524 analyzes raw time series data and / or optimized time series data to detect faults. The analytic service 524 can apply a set of fault detection rules to the time series data to determine whether a fault is detected in each section of the time series. Fault detection can be stored as optimized time series data. For example, a new time series can be generated together with a data value indicating whether or not a failure has been detected in each section of the time series. Fault detection time series can be stored in local storage 514 or host data storage 516 along with raw time series data and / or optimized time series data. These and other features of analysis service 524 and time series service 528 are described in more detail with reference to FIG.

  With further reference to FIG. 5, BMS 500 is shown to include a number of applications 530 including an energy management application 532, a monitoring and reporting application 534, and an enterprise control application 536. Although only a few applications 530 are shown, the applications 530 may include any of a variety of applications configured to use optimized time series data generated by the data platform service 520. It is thought that you can. In some embodiments, application 530 exists as a separate layer of BMS 500 (ie, separate from data platform service 520 and data collector 512). This makes it possible to separate the application 530 from the details of the method for generating optimized time series data. In other embodiments, application 530 can exist as a remote application running on a remote system or device (eg, remote system and application 444, client device 448).

  Application 530 may perform various data visualization, monitoring, and / or control activities using optimized time series data. For example, the energy management application 532 and the monitoring and reporting application 534 use the optimized time series data to present a user interface (eg, chart, graph, etc.) that presents the optimized time series data to the user. Can be generated. In some embodiments, the user interface presents raw time series data and optimized data rollup in a single chart or graph. For example, a drop-down selector may be provided to allow the user to select raw time series data or any data rollup for a given data point. Some examples of user interfaces that can be generated based on optimized time series data are shown in FIGS.

  The enterprise control application 536 can perform various control activities using the optimized time series data. For example, the enterprise control application 536 uses optimized time-series data as control algorithms (eg, state-based algorithms, extreme value search control (ESC) algorithms, proportional integral (PI) control algorithms, proportional integral derivative (PID) control algorithms). Can be used as an input to model predictive control (MPC) algorithms, feedback control algorithms, etc.) to generate control signals for the building subsystem 428. In some embodiments, the building subsystem 428 uses control signals to operate building equipment. The operation of the building equipment can affect the measured or calculated values of the data samples provided to the BMS 500. Accordingly, enterprise control application 536 can control the systems and devices of building subsystem 428 using the optimized time series data as feedback.

  With further reference to FIG. 5, BMS 500 is shown to include a dashboard layout generator 518. Dashboard layout generator 518 is configured to generate a layout for a user interface (ie, dashboard) that visualizes time series data. In some embodiments, the dashboard layout itself is not a user interface but a description that can be used by the application 530 to generate a user interface. In some embodiments, the dashboard layout is a schema that defines the relative positions of various widgets (eg, charts, graphs, etc.) that can be rendered and displayed as part of the user interface. The dashboard layout can be read by a variety of different frameworks and can be used by a variety of different rendering engines (eg, web browsers, pdf engines, etc.) or applications to generate a user interface.

  In some embodiments, the dashboard layout defines a grid having one or more rows and one or more columns located within each row. A dashboard layout can define the position of each widget at a particular position in the grid. A dashboard layout can define an array of objects (eg, JSON objects), where each object is itself an array. In some embodiments, the dashboard layout defines attributes or properties for each widget. For example, a dashboard layout can define the type of widget (eg, graph, plain text, image, etc.). If the widget is a graph, the dashboard layout can define additional properties such as the graph title, x-axis title, y-axis title, and time series data used in the graph. The dashboard layout generator 518 and the dashboard layout are described in more detail with reference to FIGS.

Time series and analysis data platform services

  Referring now to FIG. 6, a block diagram illustrating the time series service 528 and the analysis service 524 in more detail according to some embodiments is shown. The time series service 528 is shown to include a time series web service 602, a job manager 604, and a time series storage interface 616. The time series web service 602 is configured to interact with web based applications to send and / or receive time series data. In some embodiments, the time series web service 602 provides time series data to a web-based application. For example, if one or more applications 530 are web-based applications, the time-series web service 602 can provide optimized time-series data and raw time-series data to the web-based application. In some embodiments, the time series web service 602 receives raw time series data from a web-based data collector. For example, if the data collector 512 is a web-based application, the time series web service 602 can receive data samples or raw time series data from the data collector 512.

  The time series storage interface 616 is configured to interact with the local storage device 514 and / or the host storage device 516. For example, the time series storage interface 616 can retrieve raw time series data from the local time series database 628 in the local storage device 514 or the host time series database 636 in the host storage device 516. The time series storage interface 616 can also store the optimized time series data in the local time series database 628 or the host time series database 636. In some embodiments, the time series storage interface 616 is configured to retrieve jobs from the local job queue 630 in the local storage device 514 or the host job queue 638 in the host storage device 516. Time series storage interface 616 can also store jobs in local job queue 630 or host job queue 638. Jobs can be created and / or processed by job manager 604 to generate optimized time series data from raw time series data.

  Still referring to FIG. 6, the job manager 604 is shown to include a sample aggregator 608. Sample aggregator 608 is configured to generate an optimized data rollup from raw time series data. For each data point, the sample aggregator 608 aggregates a set of data values having time stamps within a predetermined time interval (eg, 15 minutes, 1 hour, 1 day, etc.) and aggregates for that predetermined time interval. Data values can be generated. For example, the raw time series data for a particular data point may have a relatively short interval (eg, 1 minute) between successive samples of the data point. The sample aggregator 608 adds a raw time series by aggregating all samples of data points with timestamps within a relatively long interval (eg, 15 minutes) into a single aggregated value representing the longer interval. Data rollups can be generated from the data.

  For some types of time series, the sample aggregator 608 performs the aggregation by averaging all samples of data points that have time stamps within a longer interval. Aggregation by means of averaging can be used to calculate aggregate values for time series of non-cumulative variables such as measurements. In other types of time series, the sample aggregator 608 performs the aggregation by adding all samples of data points that have a time stamp within a longer interval. Aggregation by addition can be used to calculate an aggregate value for a time series of cumulative variables, such as the number of faults detected since the previous sample.

  Referring now to FIGS. 7A-7B, a block diagram 700 and a data table 750 illustrating an aggregation technique that can be used by the sample aggregator 608 are shown according to some embodiments. In FIG. 7A, data points 702 are shown. The data point 702 is an example of a measurement data point from which a time series value can be obtained. For example, data point 702 is shown as an outside air temperature point and has a value that can be measured by a temperature sensor. Although a particular type of data point 702 is shown in FIG. 7A, it should be understood that the data point 702 may be any type of measured or calculated data point. The time series values of the data points 702 can be collected by the data collector 512 and collectively into the raw data time series 704.

  As shown in FIG. 7B, the raw data time series data 704 includes time series data of data samples, each sample shown as a separate row in the data table 750. Each sample of the raw data time series 704 is shown to include a time stamp and a data value. The time stamp of the raw data time series 704 is 10 minutes and 1 second. This indicates that the sampling interval of the raw data time series data 704 is 10 minutes 1 second. For example, the time stamp of the first data sample is shown as 2015-12-31T23: 10: 00, and the first data sample of the raw data time series 704 is 11:10 pm on December 31, 2015. Indicates that it was collected. The time stamp of the second data sample is shown as 2015-12-31T23: 20: 01, and the second data sample of the raw data time series 704 is 11:20:01 pm on December 31, 2015. Indicates that it was collected. In some embodiments, the timestamp of the raw data time series 704 is stored with the time difference with respect to universal time as described above. The value of the raw data time series 704 starts at the value 10 and increases by 10 for each sample. For example, the value of the second sample in the raw data time series 704 is 20, the value of the third sample in the raw data time series 704 is 30, and so on.

  In FIG. 7A, several data rollup time series 706-714 are shown. The data rollup time series 706-714 can be generated by the sample aggregator 608 and stored as optimized time series data. Data rollup time series 706-714 include a 15 minute average time series 706, an hour average time series 708, a daily average time series 710, a monthly average time series 712, and a year average average time series 714. Each of the data rollup time series data 706 to 714 depends on the parent time series data. In some embodiments, the parent time series for each of the data rollup time series 706-714 is time series data having the second shortest duration between successive time series values. For example, the parent time series for the 15 minute average time series 706 is the raw data time series 704. Similarly, the parent time series for the 1-hour average time series 708 is the 15-minute average time series 706, and the parent time series for the daily average time series 710 is the 1-hour average time series 708, which is the 1-month average time series. The parent time series for 712 is a daily average time series 710, and the parent time series for the one year average time series 714 is a monthly average time series 712.

  The sample aggregator 608 can generate the data rollup time series 706 to 714 from the corresponding time series values of the parent time series. For example, the sample aggregator 608 can generate a 15 minute average time series 706 by aggregating all samples of the data points 702 in the raw data time series 704 that have time stamps within 15 minutes each. Similarly, the sample aggregator 608 can generate the 1-hour average time series 708 by aggregating all the time series values of the 15-minute average time series 706 having time stamps within each hour. The sample aggregator 608 can generate an hourly average time series 710 by counting all the time series values of the hourly average time series 708 having time stamps within each day. The sample aggregator 608 can generate a monthly average time series 712 by aggregating all the time series values of the daily average time series 710 having time stamps within each month. The sample aggregator 608 can generate a one year average time series 714 by aggregating all the time series values of the one month average time series 712 having a time stamp within each year.

  In some embodiments, the time stamp for each sample in the data rollup time series 706-714 is the starting point of the aggregation interval used to calculate the value of the sample. For example, the first data sample of the 15-minute average time series 706 is shown to include a timestamp 2015-12-31T23: 00: 00: 00. This time stamp indicates that the first data sample of the 15-minute average time series 706 corresponds to the aggregation interval starting on December 31, 2015 at 11:00 pm. Since only one data sample of the raw data time series 704 occurs during this interval, the value of the first data sample of the 15 minute average time series 706 is the average of the single data values (ie, average (10) = 10 ). The same is true for the second data sample of the 15 minute average time series 706 (ie, average (20) = 20).

  The third data sample of the 15 minute average time series 706 is shown to include the timestamp 2015-12-31T23: 30. This time stamp indicates that the third data sample of the 15-minute average time series 706 corresponds to the counting interval beginning on December 31, 2015 at 11:30 pm. Since each aggregation interval of the 15-minute average time series 706 has a duration of 15 minutes, the termination of the aggregation interval is 11:45:00 on December 31, 2015. This tabulation interval includes two data samples of the raw data time series 704 (ie, a third raw data sample having a value 30 and a fourth raw data sample having a value 40). The sample aggregator 608 can calculate the value of the third sample of the 15-minute average time series 706 by averaging the values of the third raw data sample and the fourth raw data sample (ie, the average (30 40) = 35). Thus, the third sample of the 15 minute average time series 706 has a value of 35. The sample aggregator 608 can similarly calculate the remaining values of the 15 minute average time series 706.

  Still referring to FIG. 7B, the first data sample of the 1-hour average time series 708 is shown to include a timestamp 2015-12-31T23: 00. This time stamp indicates that the first data sample of the 1-hour average time series 708 corresponds to the counting interval starting on December 31, 2015 at 11:00 pm. Since each aggregation interval of the 1-hour average time series 708 has a duration of 1 hour, the aggregation interval ends at 12:00 am on January 1, 2016. This aggregation interval includes the first four samples of the 15 minute average time series 706. The sample aggregator 608 can calculate the value of the first sample of the 1-hour average time series 708 by averaging the first four values of the 15-minute average time series 706 (ie, average (10,20 , 35, 50) = 28.8). Thus, the first sample of the 1 hour average time series 708 has the value 28.8. The sample aggregator 608 can similarly calculate the remaining values of the 1 hour average time series 708.

  The first data sample of the daily average time series 710 is shown to include a timestamp 2015-12-31T00: 00: 00. This time stamp indicates that the first data sample of the daily average time series 710 corresponds to the counting interval starting on December 31, 2015 at 12:00 AM. Since each aggregation interval of the daily average time series 710 is a duration of one day, the aggregation interval ends at 12:00 am on January 1, 2016. During this interval, only one data sample of the 1 hour average time series 708 occurs. Thus, the value of the first data sample in the daily average time series 710 is the average of a single data value (ie, average (28.8) = 28.8). The same is true for the second data sample of the daily average time series 710 (ie, average (87.5) = 87.5).

  In some embodiments, the sample aggregator 608 stores each of the data rollup time series 706-714 in a single data table (eg, data table 750) along with the raw data time series 704. Thereby, the application 530 can search all the time series 704 to 714 quickly and efficiently by accessing a single data table. In other embodiments, the sample aggregator 608 can store various time series 704-714 in separate data tables, which are stored in the same data storage device (eg, the same database). Or distributed across multiple data storage devices. In some embodiments, the sample aggregator 608 stores the data time series 704-714 in a format other than a data table. For example, the sample aggregator 608 can store the time series 704-714 as a vector, as a matrix, as a list, or using any of a variety of other data storage formats.

  In some embodiments, the sample aggregator 608 automatically updates the data rollup time series 706-714 each time a new raw data sample is received. Updating the data rollup time series 706-714 can include recalculating the aggregate value based on the value of the new raw data sample and the time stamp. When a new raw data sample is received, the sample aggregator 608 determines whether the new raw data sample time stamp is within any aggregation interval for the samples in the data rollup time series 706-714. Can do. For example, if a new raw data sample is received with a time stamp of 2016-01-01T00: 52: 00, the sample aggregator 608 may have a time stamp of 16-01-01T00: 45: 00 with respect to a 15 minute average time series 706. It can be determined that a new raw data sample occurs within the starting aggregation interval. The sample aggregator 608 can update the aggregate value of the last data sample in the 15 minute average time series 706 using the new raw data point value (eg, average = 120) (ie, average (110 120) = 115).

  If the new raw data sample has a time stamp that does not occur at any of the previous aggregation intervals, the sample aggregator 608 can create a new data sample in the 15 minute average time series 706. A new data sample in the 15 minute average time series 706 may have a new data timestamp that defines the starting point of the aggregation interval that includes the timestamp of the new raw data sample. For example, if the new raw data sample has a time stamp of 2016-01-01T01: 01: 00, the sample aggregator 608 determines that the new raw data sample is the aggregation interval previously established for the 15 minute average time series 706. It can be determined that none of the above occurred. The sample aggregator 608 can generate a new data sample within the 15-minute average time series 706 at the time stamp 2016-01-01T01: 00: 00, and, as described above, sets the value of the new raw data sample to Based on this, the value of a new data sample within the 15 minute average time series 706 can be calculated.

  The sample aggregator 608 can similarly update the values of the remaining data rollup time series 708-714. For example, the sample aggregator 608 determines whether the timestamp of the updated data sample in the 15 minute average time series is within any aggregation interval for the samples in the 1 hour average time series 708. The sample aggregator 608 can determine that the time stamp 2016-01-01T00: 45: 00 occurs within an aggregation interval beginning with the time stamp 2016-01-01T00: 00: 00 for the 1 hour average time series 708. Sample aggregator 608 can use the updated value of the last data sample in 15-minute average time series 706 (ie, value = 115) to update the value of the second sample in 1-hour average time series 708. (Ie average (65,80,95,115) = 88.75). Using the same technique, the sample aggregator 608 can update the last sample of the daily average time series 710 using the updated value of the last data sample of the 1 hour average time series 708.

  In some embodiments, the sample aggregator 608 updates the aggregated data values of the data rollup time series 706-714 each time a new raw data sample is received. Updating each time a new raw data sample is received ensures that the data rollup time series 706-714 always reflects the latest data sample. In other embodiments, the sample aggregator 608 uses a batch update technique to periodically populate the data rollup time series 706-714 data values at predetermined update intervals (eg, 1 hour, 1 day, etc.). Update. It is more efficient to update periodically rather than every time a new data sample is received and may require less data processing, but the aggregate data values should reflect the latest data sample Sometimes it is not always updated.

  In some embodiments, the sample aggregator 608 is configured to cleanse the raw data time series 704. Cleansing the raw data time series 704 can include eliminating abnormally high or low data. For example, the sample aggregator 608 can identify the minimum expected data value and the maximum expected data value for the raw data time series 704. The sample aggregator 608 can exclude data values outside this range as defective data. In some embodiments, the minimum expected value and the maximum expected value are based on attributes of data points represented by a time series. For example, the data point 702 represents a measured outside air temperature, and therefore a reasonable outside air temperature value range (eg, −20 ° F. to 110 ° F. (−29 ° C. to 43 ° C.) for a given geographic location. ) With expected value. The sample aggregator 608 can eliminate the data value 330 for the data point 702 because the temperature value 330 ° F. (166 ° C.) is not valid for the measured outside air temperature.

  In some embodiments, the sample aggregator 608 identifies the maximum rate of change that a data point can change between consecutive data samples. The maximum rate of change can be based on physical principles (eg, heat transfer principles), weather patterns, or other parameters that limit the maximum rate of change for a particular data point. For example, the data point 702 represents a measured outside air temperature and can thus be constrained to have a rate of change that is less than a reasonable maximum rate of change (eg, 5 degrees per minute) for the outside air temperature. If two consecutive data samples in the raw data time series 704 have values that require the outside air temperature to change at a rate that exceeds the maximum expected rate of change, the sample aggregator 608 may fail one or both of the data samples. It can be excluded as data.

  Sample aggregator 608 can perform any of a variety of data cleansing operations to identify and reject bad data samples. Some examples of data cleansing operations that can be performed by the sample aggregator 608 are described in US patent application Ser. No. 13 / 631,301, filed Sep. 28, 2012, entitled “Systems and Methods for Data Quality Control and Cleaning”. The entire disclosure of which is incorporated herein by reference. In some embodiments, the sample aggregator 608 performs a data cleansing operation on the raw data time series 704 before generating the data rollup time series 706-714. This ensures that the raw data time series 704 used to generate the data rollup time series 706-714 does not contain bad data samples. Therefore, it is not necessary to cleanse the data rollup time series 706-714 again after the aggregation is performed.

  Referring again to FIG. 6, the job manager 604 is shown to include a virtual point calculator 610. The virtual point calculator 610 is configured to create virtual data points and calculate time series values for the virtual data points. A virtual data point is a type of computational data point derived from one or more real data points. In some embodiments, the actual data point is a measurement data point and the virtual data point is a calculated data point. Virtual data points can be used as an alternative to actual sensor data when the sensor data desired for a particular application does not exist, but can be calculated from one or more real data points. For example, virtual data points representing the enthalpy of the refrigerant can be calculated using real data points that measure the temperature and pressure of the refrigerant. Virtual data points can also be used to provide time series values for computational complexity such as efficiency, coefficient of performance, and other variables that cannot be directly measured.

Virtual point calculator 610 can calculate virtual data points by applying any of a variety of mathematical operations or functions to real data points or other virtual data points. For example, the virtual point calculator 610 can calculate a virtual data point (pointID ₃ ) by adding two or more real data points (pointID ₁ and pointID ₂ ) (eg, pointID ₃ = pointID ₁ + pointID ₂ ). As another example, the virtual point calculator 610 can calculate an enthalpy data point (pointID ₄ ) based on the measured temperature data point (pointID ₅ ) and the measured pressure data point (pointID ₆ ) (eg, pointID ₄ = Enthalpy (pointID ₅ , pointID ₆ )). In some cases, virtual data points can be derived from a single real data point. For example, the virtual point calculator 610 can calculate the saturation temperature (pointID ₇ ) of a known refrigerant based on the measured refrigerant pressure (pointID ₈ ) (eg, pointID ₇ = T _sat (pointID ₈ )). . In general, the virtual point calculator 610 may calculate time series values of virtual data points using time series values of one or more real data points and / or time series values of one or more other virtual data points. it can.

  In some embodiments, virtual point calculator 610 calculates a virtual data point using a set of virtual point rules. Virtual point rules can define one or more input data points (eg, actual or virtual data points) and mathematical operations that should be applied to the input data points to calculate each virtual data point. . Virtual point rules can be provided by a user, received from an external system or device, and / or stored in memory 510. The virtual point calculator 610 can calculate a time series value for the virtual data point by applying a set of virtual point rules to the time series value of the input data point. Time series values for virtual data points can be stored in the local time series database 628 and / or the host time series database 636 as optimized time series data.

  The virtual point calculator 610 can calculate virtual data points using the values of the raw data time series 704 and / or the aggregated values of the data rollup time series 706-714. In some embodiments, input data points used to calculate virtual data points are collected at different sampling times and / or sampling rates. Thus, samples of input data points may not be synchronized with each other, which may cause ambiguity about which samples of input data points should be used to calculate virtual data points. Using the data rollup time series 706-714 to calculate the virtual data points ensures that the time stamps of the input data points are synchronized and eliminates ambiguity as to which data samples should be used.

Referring now to FIG. 8, according to some embodiments, a number of time series 800, 820, 840, and 860 are illustrated that illustrate the synchronization of data samples obtained by aggregating raw time series data. ing. Time series 800 and 820 are raw data time series. The raw data time series 800 has several raw data samples 802-810. Raw data sample 802 is collected at time t ₁ . Raw data sample 804 is collected at the time _{t 2.} Raw data sample 806 is collected at the time _{t 3.} Raw data sample 808 is collected at the time _{t 4.} Raw data sample 810 is collected at the time _{t 5.} Raw data sample 812 is collected at the time _{t 6.}

The raw data time series 820 also has a number of raw data samples 822, 824, 826, 828, and 830. However, raw data samples 822-830 are not synchronized with raw data samples 802-812. For example, raw data sample 822 is collected before time t ₁ . Raw data sample 824 is collected between times t ₂ and t ₃ . Raw data sample 826 is collected between times t ₃ and t ₄ . Raw data sample 828 is collected between times t ₄ and t ₅ . Raw data sample 830 is collected between times t ₅ and t ₆ . The lack of synchronization between data samples 802-812 and raw data samples 822-830 can lead to ambiguity about which of the data samples should be used together to calculate virtual data points.

Time series 840 and 860 are data roll-up time series. The data rollup time series 840 can be generated by aggregating the raw data time series 800 by the sample data aggregator 608. Similarly, the data rollup time series 860 can be generated by aggregating the raw data time series 820 by the sample aggregator 608. Both raw data time series 800 and 820 can be aggregated using the same aggregation interval. Thus, the resulting data rollup time series 840 and 860 have synchronized data samples. For example, the aggregate data sample 842 is synchronized with the aggregate data sample 862 at time t ₁ ′. Similarly, the total data sample 844 is synchronized with the total data sample 864 at time t ₂ ′. The aggregate data sample 846 is synchronized with the aggregate data sample 866 at time t ₃ ′. The aggregate data sample 848 is synchronized with the aggregate data sample 868 at time t ₄ ′.

  The synchronization of data samples in the data rollup time series 840 and 860 allows the virtual point calculator 610 to easily identify which data samples should be used together to calculate the virtual points. For example, the virtual point calculator 610 may identify which of the data rollup time series 840 and 860 samples have the same time stamp (eg, data samples 842 and 862, data samples 844 and 864, etc.). it can. The virtual point calculator 610 can calculate time series values of virtual data points using two or more aggregated data samples having the same time stamp. In some embodiments, the virtual point calculator 610 assigns the shared time stamp of the input data sample to the time series value of the virtual data point calculated from the input data sample.

  Referring again to FIG. 6, the job manager 604 is shown to include a weather point calculator 612. The weather point calculator 612 is configured to perform weather-based calculations using time series data. In some embodiments, the weather point calculator 612 includes weather conditions such as cooling days (CDD), heating days (HDD), cooling energy days (CED), heating energy days (HED), and normalized energy consumption. Create virtual data points for related variables. The time series values of the virtual data points calculated by the weather point calculator 612 can be stored in the local time series database 628 and / or the host time series database 636 as optimized time series data.

ここで、ｐｅｒｉｏｄは積分期間である。いくつかの実施形態では、外気温Ｔ_ＯＡは測定データポイントであり、冷房バランス点Ｔ_ｂＣは、記憶されているパラメータである。外気温Ｔ_ＯＡの各サンプルに関するＣＤＤを計算するために、気象ポイント計算機６１２は、量ｍａｘ｛０，（Ｔ_ＯＡ−Ｔ_ｂＣ）｝に外気温Ｔ_ＯＡのサンプリング周期Δｔを乗算することができる。気象ポイント計算機６１２は、外気温Ｔ_ＯＡの代わりに外気エンタルピーＥ_ＯＡを使用して、同様にＣＥＤを計算することができる。外気エンタルピーＥ_ＯＡは、測定データポイントまたは仮想データポイントであり得る。 Meteorological point calculator 612, as indicated by the following equation, it is possible to calculate the CDD by integrating a positive temperature difference between the variations of the outside temperature T _OA and cooling balance point T _bC time related building.

Here, period is an integration period. In some embodiments, the outside air temperature T _OA is the measured data points, the cooling balance point T _bC is a stored parameter. To calculate the CDD for each sample of the outside air temperature _{T OA,} weather point calculator 612, the amount _{max {0, (T OA -T} bC)} may multiply the outside air temperature _{T OA} of the sampling period Δt to. Meteorological point calculator 612 may use the outside air enthalpy _{E OA} instead of the outside air temperature _{T OA,} likewise calculates the CED. The outside air enthalpy _EOA can be a measurement data point or a virtual data point.

ここで、ｐｅｒｉｏｄは積分期間である。いくつかの実施形態では、外気温Ｔ_ＯＡは測定データポイントであり、暖房バランス点Ｔ_ｂＨは、記憶されたパラメータである。外気温Ｔ_ＯＡの各サンプルに関するＨＤＤを計算するために、気象ポイント計算機６１２は、量ｍａｘ｛０，（Ｔ_ｂＨ−Ｔ_ＯＡ）｝に外気温Ｔ_ＯＡのサンプリング周期Δｔを乗算することができる。気象ポイント計算機６１２は、外気温Ｔ_ＯＡの代わりに外気エンタルピーＥ_ＯＡを使用して、同様にＨＥＤを計算することができる。 Meteorological point calculator 612, as indicated by the following equation, it is possible to calculate the HDD by integrating a positive temperature difference between the heating balance point T _bH and the time-varying ambient temperature T _OA related building.

Here, period is an integration period. In some embodiments, the outside air temperature _TOA is a measured data point, and the heating balance point _TbH is a stored parameter. To calculate the HDD for each sample of the outside air temperature _{T OA,} weather point calculator 612, the amount _{max {0, (T bH -T} OA)} may multiply the outside air temperature _{T OA} of the sampling period Δt to. Meteorological point calculator 612, instead of the outside air temperature _{T OA} using outside air enthalpy _{E OA,} likewise can be calculated HED.

  In some embodiments, both the virtual point calculator 610 and the weather point calculator 612 calculate time series values for virtual data points. The weather point calculator 612 can calculate time-series values of virtual data points that depend on weather-related variables (eg, outside air temperature, outside air enthalpy, outside air humidity, outdoor light intensity, precipitation, wind speed, etc.). Virtual point calculator 610 can calculate time series values of virtual data points that depend on other types of variables (eg, non-weather related variables). Although only a few weather related variables are described in detail here, it is believed that the weather point calculator 612 can calculate virtual data points for any weather related variable. Weather related data points used by the weather point calculator 612 may be received as time series data from various weather sensors and / or weather services.

  Still referring to FIG. 6, the job manager 604 is shown to include a meter fault detector 614 and a scalable rules engine 606. Meter fault detector 614 and scalable rule engine 606 are configured to detect faults in the time series data. In some embodiments, the meter fault detector 614 performs fault detection on time series data representing meter data (eg, measurements from sensors), and the scalable rules engine 606 uses other types of time series data. Perform fault detection for. The meter fault detector 614 and the scalable rule engine 606 can detect faults in raw time series data and / or optimized time series data.

  In some embodiments, meter fault detector 614 and scalable rule engine 606 receive fault detection rules 620 and / or reasons 622 from analysis service 618. Fault detection rules 620 can be defined by the user via the rules editor 624 or can be received from an external system or device via the analysis web service 618. In various embodiments, failure detection rules 620 and reason 622 are stored in rules database 632 and reason database 634 in local storage 514 and / or in rules database 640 and reason database 642 in host storage 516. Can do. The meter failure detector 614 and the scalable rule engine 606 can retrieve the failure detection rule 620 from the local storage device 514 or the host storage device and use the failure detection rule 620 to analyze the time series data.

  In some embodiments, fault detection rules 620 provide criteria that can be evaluated by meter fault detector 614 and scalable rules engine 606 to detect faults in the time series data. For example, the failure detection rule 620 can define a failure as a data value above or below a threshold. As another example, failure detection rule 620 can define a failure as a data value outside a predetermined value range. The threshold value and the predetermined value range are the time series data type (eg, meter data, calculated data, etc.), the type of variable represented by the time series data (eg, temperature, humidity, energy consumption, etc.), time series. It can be based on systems or devices that measure or provide data (eg, temperature sensors, humidity sensors, coolers, etc.) and / or other attributes of time series data.

  The meter fault detector 614 and the scalable rule engine 606 can apply the fault detection rules 620 to the time series data to determine whether each sample of time series data is identified as a fault. In some embodiments, meter fault detector 614 and scalable rule engine 606 generate a fault detection time series that includes the results of fault detection. The fault detection time series may include a set of time series values, each time series value corresponding to a data sample of time series data evaluated by the meter fault detector 614 and the scalable rule engine 606. In some embodiments, each time series value in the fault detection time series includes a time stamp and a fault detection value. The time stamp may be the same as the time stamp of the corresponding data sample in the data time series. The failure detection value can indicate whether the corresponding data sample in the data time series is identified as a failure. For example, the failure detection value has a value of “failure” when a failure is detected, and has a value of “no failure” when no failure is detected in the corresponding data sample of the data time series. Can do. The fault detection time series can be stored in the local time series database 628 and / or the host time series database 636 along with the raw time series data and the optimized time series data.

  Referring now to FIGS. 9A-9B, a block diagram illustrating a failure detection timeline and a data table 900 are shown in accordance with some embodiments. FIG. 9A shows a job manager 604 that receives a data time series 902 from a local storage device 514 or a host storage device 516. The data time series 902 may be a raw data time series or an optimized time series. In some embodiments, the data time series 902 is a time series of values of actual data points (eg, measured temperature). In other embodiments, the data time series 902 is a time series of values for virtual data points (eg, calculated efficiency). As shown in the data table 900, the data time series 902 includes a set of data samples. Each data sample includes a time stamp and a value. Most of the data samples have values in the range of 65-66. However, three of the data samples have the value 42.

  The job manager 604 can evaluate the data time series 902 using a set of fault detection rules 620 to detect faults in the data time series 902. In various embodiments, fault detection can be performed by meter fault detector 614 (eg, when data time series 902 is meter data) or (eg, data time series 902 is non-meter data). Can be implemented by the scalable rules engine 606. In some embodiments, the job manager 604 determines that the data sample having the value 42 is identified as a failure according to the failure detection rules 620.

  The job manager 604 can generate a failure detection time series 904 including the result of failure detection. As shown in the data table 900, the failure detection time series 904 includes a set of data samples. Similar to the data time series 902, each data sample of the fault detection time series 904 includes a time stamp and a value. Most of the values in the fault detection time series 904 are shown as “no fault”, indicating that no fault was detected for the corresponding sample in the data time series 902 (ie, data samples with the same time stamp). However, three of the data samples in the failure detection time series 904 have the value “failure”, indicating that the corresponding sample in the data time series 902 is identified as a failure. As shown in FIG. 9A, the job manager 604, along with the raw time series data and the optimized time series data, may have a local storage 514 (eg, local time series database 628) and / or a host storage 516 (eg, The host time series database 636).

  The fault detection time series 904 can be used by the BMS 500 to perform various fault detection, diagnosis, and / or control processes. In some embodiments, failure detection time series 904 is further processed by job manager 604 to generate new time series data derived from failure detection time series 904. For example, the sample aggregator 608 can use the fault detection time series 904 to generate a fault duration time series. The sample aggregator 608 can aggregate a plurality of consecutive data samples of the failure detection time series 904 having the same data value into a single data sample. For example, the sample aggregator 608 can aggregate the first two “no failures” data samples of the failure detection time series 904 into a single data sample that represents a period of time during which no failures were detected. Similarly, the sample aggregator 608 can aggregate the last two “fault” data samples of the fault detection time series 904 into a single data sample that represents the time period during which the fault was detected.

  In some embodiments, each data sample in the failure duration time series has a failure occurrence time and a failure duration. The failure occurrence time can be indicated by the time stamp of the data sample in the failure duration time series. The sample aggregator 608 is configured for each data sample in the fault duration time series equal to the time stamp of the first data sample in the series of data samples in the fault detection time series 904 aggregated to form an aggregate data sample. A time stamp can be set. For example, if the sample aggregator 608 aggregates the first two “no failure” data samples in the failure detection time series 904, the sample aggregator 608 sets the aggregated data sample time stamps 2015-12-31T23: 10: 00 can be set. Similarly, if the sample aggregator 608 aggregates the last two “failure” data samples of the failure detection time series 904, the sample aggregator 608 sets the aggregated data sample time stamps 2015-12-31T23: 50: 00 can be set.

  The fault duration can be indicated by the value of the data sample in the fault duration time series. The sample aggregator 608 may set a value for each data sample in the fault duration time series equal to the duration spanning successive data samples in the fault detection time series 904 aggregated to form an aggregate data sample. it can. The sample aggregator 608 calculates the time stamp of the first data sample of the failure detection time series 904 included in the aggregation from the time stamp of the next data sample of the failure detection time series 904 after the data samples are included in the aggregation. By subtracting, the duration over multiple consecutive data samples can be calculated.

  For example, if the sample aggregator 608 aggregates the first two “no failure” data samples of the failure detection time series 904, the timestamp 2015-12-31T23: 10: 00 (ie, the first “no failure” sample Time stamp) of 2015-12-31T23: 30 (ie, the time stamp of the first “failure” sample after successive “no failure” samples) The duration can be calculated. Similarly, when the sample aggregator 608 aggregates the first two “failure” data samples of the failure detection time series 904, the timestamp 2015-12-31T23: 50: 00 (ie, the first included in the aggregation) By subtracting the “failure” sample time stamp) from the time stamp 2016-01-01T00: 10: 00 (ie, the first “no failure” sample time stamp after successive “failure” samples). The duration of the recorded data sample can be calculated.

  Referring now to FIG. 9C, a flow diagram is shown that illustrates how various time series can be generated, stored, and used in the BMS 500, according to some embodiments. Data collector 512 is shown to receive data samples from building subsystem 428. In some embodiments, the data sample includes data values for various data points. The data value can be a measured value or a calculated value, depending on the type of data point. For example, a data point received from a temperature sensor can include a measured data value that indicates a temperature measured by the temperature sensor. Data points received from the chiller controller can include a calculated data value indicative of the calculated efficiency of the chiller. Data collector 512 can receive data samples from a plurality of different devices in building subsystem 428.

  In some embodiments, each data sample is received with a timestamp indicating the time at which the corresponding data value was measured or calculated. In other embodiments, the data collector 512 adds a time stamp to the data sample based on the time at which the data sample was received. Data collector 512 can generate raw time series data for each data point at which a data sample is received. Each time series can include a series of data values for the same data point and a time stamp for each data value. For example, a time series for data points provided by a temperature sensor can include a series of temperature values measured by the temperature sensor and a corresponding time at which the temperature value was measured.

  Data collector 512 can add timestamps to the data samples or modify existing timestamps so that each data sample includes a local timestamp. Each local time stamp indicates the local time at which the corresponding data sample was measured or collected, and may include a time difference with respect to universal time. The local time stamp indicates the local time at the position where the data point was measured during measurement. The time difference indicates a difference between local time and universal time (for example, time on an international date change line). For example, a data sample collected in a time zone that is 6 hours behind the universal time includes a local time stamp (for example, time stamp = 2006-03-18T14: 10: 02) and a local time stamp of 6 hours from the universal time. A time difference indicating that the time is delayed (for example, time difference = −6: 00) can be included. The time difference can be adjusted depending on whether the time zone is daylight saving time when the data samples are measured or collected (eg, +1: 00 or -1: 00). Data collector 512 can provide raw time series data to control application 536 and data cleanser 644 and / or to time series storage 515 (ie, local storage 514 and / or host storage 516). Raw time series data can be stored.

  The data cleanser 644 can retrieve the raw data time series from the time series storage device 515 and cleanse the raw data time series. Cleansing the raw data time series can eliminate exceptionally high or low data. For example, the data cleanser 644 can identify the minimum expected data value and the maximum expected data value for the raw data time series. The data cleanser 644 can exclude data values outside this range as defective data. In some embodiments, the minimum and maximum expected values are based on attributes of data points represented by a time series. For example, an outside air temperature data point may have an expected value within a reasonable outside air temperature value range (eg, −20 ° F. to 110 ° F. (−29 ° C. to 43 ° C.)) for a given geographic location. is there.

  In some embodiments, the data cleanser 644 identifies the maximum rate of change at which data points can change between consecutive data samples. The maximum rate of change can be based on physical principles (eg, heat transfer principles), weather patterns, or other parameters that limit the maximum rate of change for a particular data point. For example, the outside air temperature data point can be limited to have a rate of change that is less than the maximum reasonable rate of change (eg, 5 degrees per minute) for the outside temperature. If two consecutive data samples in the raw data time series have values that require the outside air temperature to change at a rate that exceeds the maximum expected rate of change, the data cleanser 644 will cause one or both of the data samples to fail. It can be excluded as data.

  Data cleanser 644 can perform any of a variety of data cleansing operations to identify and eliminate bad data samples. Some examples of data cleansing operations that can be performed by data cleanser 644 are described in US patent application Ser. No. 13/631, entitled “Systems and Methods for Data Quality Control and Cleaning,” filed Sep. 28, 2012. 301, the entire disclosure of which is incorporated herein by reference. In some embodiments, the data cleanser 644 performs a data cleansing operation for the raw data time series before the sample aggregator 608 generates the data rollup time series. This ensures that the raw data time series data used to generate the data rollup time series does not contain bad data samples. Therefore, there is no need to re-cleanse the data rollup time series after the aggregation is performed. Data cleanser 644 can provide cleansed time series data to control application 536 and sample aggregator 608 and / or store the cleansed time series data in time series storage 515.

  The sample aggregator 608 searches an arbitrary data time series from the time series storage device 515 (for example, raw data time series, cleansed data time series, data rollup time series, failure detection time series, etc.). A data rollup time series can be generated based on the data time series. For each data point, the sample aggregator 608 aggregates a set of data values with time stamps within a predetermined time interval (eg, 15 minutes, 1 hour, 1 day, etc.) and relates to that predetermined time interval. Generate aggregate data values. For example, raw time series data for a particular data point may have a relatively short interval (eg, 1 minute) between successive samples of the data point. The sample aggregator 608 sums all samples of data points that have time stamps within a relatively long interval (eg, 15 minutes) from the raw time series data by aggregating them into a single aggregated value that represents the longer interval. Data rollups can be generated.

  For some types of time series, the sample aggregator 608 performs the aggregation by averaging all samples of data points that have a time stamp within a longer interval. Aggregation by averaging can be used to calculate aggregate values for time series of non-cumulative variables such as measurements. For other types of time series, the sample aggregator 608 performs the aggregation by summing all samples of data points that have a time stamp within a longer interval. Aggregation by sum can be used to calculate aggregate values for a time series of cumulative variables, such as the number of failures detected from previous samples.

  Sample aggregator 608 can be any type of data rollup including, for example, a 15-minute average time series, an hourly average time series, a daily average time series, a monthly average time series, and a yearly average time series. A time series or any other type of data roll-up time series described with reference to FIGS. 6-8 can be generated. Each data rollup time series may depend on the parent time series. In some embodiments, the sample aggregator 608 updates the aggregated data values of the data rollup time series each time a new raw data sample is received and / or whenever the parent time series is updated. To do. The sample aggregator 608 can provide a data rollup time series to control the application 536, virtual point calculator 610, and / or store the data rollup time series in the time series storage 515.

  The virtual point computer 610 can search an arbitrary time series from the time series storage device 515 and generate a virtual point time series using the searched data time series. The virtual point calculator can create virtual data points and calculate time series values for the virtual data points. A virtual data point is a type of calculated data point derived from one or more real data points. In some embodiments, the actual data point is a measurement data point and the virtual data point is a calculated data point. A virtual data point can be used as an alternative to actual sensor data when the sensor data desired for a particular application does not exist, but can be calculated from one or more actual data points. For example, virtual data points representing the enthalpy of the refrigerant can be calculated using real data points that measure the temperature and pressure of the refrigerant. Virtual data points can also be used to provide time series values for calculated quantities such as efficiency and coefficient of performance, and for other variables that cannot be directly measured.

Virtual point calculator 610 can calculate virtual data points by applying any of various mathematical operations or functions to the real data points and / or other virtual data points. For example, the virtual point calculator 610 can calculate a virtual data point (pointID ₃ ) by adding two or more real data points (pointID ₁ and pointID ₂ ) (eg, pointID ₃ = pointID ₁ + pointID ₂ ). As another example, the virtual point calculator 610 can calculate an enthalpy data point (pointID ₄ ) based on the measured temperature data point (pointID ₅ ) and the measured pressure data point (pointID ₆ ) (eg, pointID ₄ = Enthalpy (pointID ₅ , pointID ₆ )).

In some examples, the virtual data points can be derived from a single real data point. For example, the virtual point calculator 610 can calculate a known refrigerant saturation temperature (pointID ₇ ) based on the measured refrigerant pressure (pointID ₈ ) (eg, pointID ₇ = T _sat (pointID ₈ )). In general, the virtual point calculator 610 may calculate time series values of virtual data points using time series values of one or more real data points and / or time series values of one or more other virtual data points. it can. In some embodiments, the virtual point calculator 610 automatically updates the value of the virtual point time series each time the source data used to calculate the virtual data point is updated. The virtual point calculator 610 provides a virtual point time series to control the application 536, the scalable rule engine 606, and / or stores the virtual point time series in the time series storage 515.

  The scalable rule engine 606 can search for an arbitrary time series from the time series storage device 515 and generate a fault detection time series using the searched data time series. The scalable rule engine 606 can apply a failure detection rule to the time series data to determine whether each sample of time series data is recognized as a failure. In some embodiments, the scalable rules engine 606 generates a fault detection time series that includes the results of fault detection, as described with reference to FIGS. 9A-9B. The fault detection time series can include a set of time series values, each time series value corresponding to a data sample of time series data evaluated by the scalable rule engine 606.

  In some embodiments, each time series value in the fault detection time series includes a time stamp and a fault detection value. The time stamp may be the same as the time stamp of the corresponding data sample in the data time series. The failure detection value can indicate whether the corresponding data sample in the data time series is identified as a failure. For example, the failure detection value has a value of “failure” when a failure is detected, and has a value of “no failure” when no failure is detected in the corresponding data sample of the data time series. Can do. In some embodiments, the scalable rules engine 606 uses the fault detection time series to generate a differential time series, such as a fault duration time series, as described with reference to FIGS. 9A-9B. The scalable rule engine 606 can provide a fault detection time series to control the application 536 and / or store the fault detection time series in the time series storage 515.

  Each data platform service 520 (eg, data cleanser 644, sample aggregator 608, virtual point calculator 610, scalable rule engine 606, etc.) reads an arbitrary data time series from the time series storage device 515, and creates a new data time series ( For example, a cleansed data time series, a data rollup time series, a virtual point time series, a failure detection time series, and the like can be generated, and the new data time series can be stored in the time series storage device 515. The new time series can be stored along with the original time series on which the new time series is based, so there is no need to update the original time series. As a result, a plurality of services can simultaneously read the same data time series from the time series storage device 515 without requiring a service for locking the time series.

  The time series stored in the time series storage device 515 can affect each other. For example, one or more first data time series values can affect one or more second data time series values based on the first data time series. The first and second data time series may be raw data time series, cleansed data time series, data rollup time series, virtual point time series, failure detection time series, or any data platform service 520 generated. Any of other time series may be used. When the first time series data is updated, the second time series data can be automatically updated by the data platform service 520. The update to the second time series can trigger an automatic update to one or more third data time series based on the second data time series. It is believed that any data time series can be based on any other data time series and can be automatically updated when the underlying data time series is updated.

  In operation, the raw data time series can be written by the data collector 512 to the time series storage 515 as data is collected or received from the building subsystem 428. Subsequent processing by the data cleanser 644, the sample aggregator 608, the virtual point calculator 610, and the scalable rule engine 606 can be performed in any order. For example, the data cleanser 644 can cleanse the raw data time series, the data rollup time series, the virtual point time series, and / or the failure detection time series. Similarly, the sample aggregator 608 may use a raw data time series, a cleansed data time series, another data rollup time series, a virtual point time series, and / or a fault detection time series to generate a data rollup time series. Can be generated. Virtual point calculator 610 generates a virtual point time series based on one or more raw data time series, cleansed data time series, data rollup time series, other virtual point time series, and / or fault detection time series can do. The scalable rule engine 606 uses one or more raw data time series, cleansed data time series, data rollup time series, virtual point time series, and / or other fault detection time series to detect fault detection time series. Can be generated.

  Referring again to FIG. 6, the analysis service 524 is shown to include an analysis web service 618, fault detection rules 620 and reasons 622, a rule editor 624, and an analysis storage interface 626. The analysis web service 618 is configured to interact with a web-based application to send and / or receive fault detection rules 620 and reasons 622 and results of data analysis. In some embodiments, analysis web service 618 receives fault detection rules 620 and reasons 622 from web-based rule editor 624. For example, if rules editor 624 is a web-based application, analysis web service 618 can receive rules 620 and reasons 622 from rules editor 624. In some embodiments, the analysis web service 618 provides the results of the analysis to a web-based application. For example, if one or more of the applications 530 are web-based applications, the analysis web service 618 can provide fault detection time for the web-based applications.

  The analysis storage interface 626 is configured to interact with the local storage device 514 and / or the host storage device 516. For example, analysis storage interface 626 may receive rules 620 from local rules database 632 in local storage 514 or from host rules database 640 in host storage 516. Similarly, the analysis storage interface 626 can retrieve the reason 622 from the local reason database 634 in the local storage device 514 or from the host reason database 642 in the host storage device 516. Analysis storage interface 626 may also store rules 620 and reason 622 in local storage 514 and / or host storage 516.

Entity graph

  Referring now to FIG. 10A, an entity graph 1000 is shown according to some embodiments. In some embodiments, the entity graph 1000 is generated or used by the data collector 512 as described with reference to FIG. The entity graph 1000 represents how the building is organized and how the various systems and spaces within the building are related to each other. For example, the entity graph 1000 is shown to include an organization 1002, a space 1004, a system 1006, points 1008, and a time series 1009. The arrows connecting the organization 1002, the space 1004, the system 1006, the point 1008, and the time series 1009 identify the relationship between such entities. In some embodiments, such a relationship is stored as an attribute of the entity represented by the attribute.

  The organization 1002 is shown to include an included descendant attribute 1010, a parent ancestor attribute 1012, an inclusion attribute 1014, an inclusion attribute 1016, an ancestor occupation attribute 1018, and an occupied attribute 1022. The contained descendant attribute 1010 identifies any descendent entity that is contained within the organization 1002. Parent ancestor attribute 1012 identifies any parent entity for organization 1002. Inclusion attribute 1014 identifies any other organization that is included within organization 1002. An asterisk attached to the inclusion attribute 1014 indicates that the organization 1002 can include any number of other organizations. Inclusion attribute 1016 identifies another tissue in which tissue 1002 is located. The number 1 attached to the inclusion attribute 1016 indicates that the tissue 1002 can be positioned exactly within one other tissue. The occupied attribute 1022 identifies an arbitrary space occupied by the tissue 1002. An asterisk attached to the occupied attribute 1022 indicates that the organization 1002 can occupy any number of spaces.

  The space 1004 is shown to include an occupied attribute 1020, an ancestor occupation attribute 1018, a space inclusion descendant attribute 1024, an inclusion ancestor attribute 1026, a space inclusion attribute 1028, an inclusion attribute 1030, a service system attribute 1038, and a service descendant system attribute 1034. ing. The occupied attribute 1020 identifies the organization occupied by the space 1004. The number 1 assigned to the occupied attribute 1020 indicates that the space 1004 can be occupied by exactly one organization. The ancestor occupation attribute 1018 identifies one or more ancestors of the organization 1002 that the space 1004 occupies. An asterisk attached to the ancestor occupation attribute indicates that an arbitrary number of ancestors can occupy the space 1004.

  The space inclusion descendant attribute 1024 identifies an arbitrary descendant of the space 1004 included in the space 1004. Contained ancestry attribute 1026 identifies any ancestor of space 1004 in which space 1004 is located. The space inclusion attribute 1028 identifies any other space included within the space 1004. An asterisk attached to the space inclusion attribute 1028 indicates that the space 1004 can include any number of other spaces. The inclusion attribute 1030 identifies another space in which the space 1004 is located. The number 1 attached to the inclusion attribute 1030 indicates that the space 1004 can be positioned exactly within one other space. Service system attribute 1038 identifies any system that serves space 1004. An asterisk attached to the service system attribute 1038 indicates that the space 1004 can be serviced by any number of systems. The service descendant system attribute 1034 identifies any descendent system that services the space 1004. An asterisk attached to the service descendant system attribute 1034 indicates that the space 1004 can be serviced by any number of descendant systems.

  The system 1006 is shown to include a spatial service attribute 1036, an ancestor spatial service attribute 1032, a descendent subsystem attribute 1040, an ancestor partial attribute 1042, a subsystem attribute 1044, a partial attribute 1046, and a point attribute 1050. Spatial service attribute 1036 identifies any space serviced by system 1006. An asterisk attached to the space service attribute 1036 indicates that the system 1006 can serve any number of spaces. The ancestor space service attribute 1032 identifies any ancestor for the space 1004 served by the system 1006. An asterisk attached to the ancestor space service attribute 1032 indicates that the system 1006 can service any number of ancestor spaces.

  The descendant subsystem attribute 1040 identifies any descendant subsystems of other systems included in the system 1006. The ancestor part attribute 1042 identifies any ancestor for the system 1006 of which the system 1006 is a part. Subsystem attribute 1044 identifies any subsystem included within system 1006. An asterisk attached to subsystem attribute 1044 indicates that system 1006 can include any number of subsystems. Partial attribute 1046 identifies any other system of which system 1006 is a part. The number 1 attached to the partial attribute 1046 indicates that the system 1006 can be part of exactly one other system. Point attribute 1050 identifies any data point associated with system 1006. An asterisk attached to the point attribute 1050 indicates that any number of data points can be associated with the system 1006.

  Point 1008 is shown to include a system usage attribute 1048. An asterisk attached to the system usage attribute 1048 indicates that any number of systems can use the point 1008. Also, the point 1008 is shown to include a time-series used attribute 1054. An asterisk attached to the time series used attribute 1054 indicates that an arbitrary number of time series (for example, raw data time series, virtual point time series, data rollup time series, etc.) can use the point 1008. Show. For example, multiple virtual point time-series data can be based on the same actual data point 1008. In some embodiments, the time series used attribute 1054 is treated as a list of time series that contributes to changes in the value of the data point 1008. When the value of the point 1008 changes, the time series listed in the time series used attribute 1054 can be identified and automatically updated to reflect the changed value of the point 1008.

  The time series 1009 is shown to include a point usage attribute 1052. An asterisk attached to the point use attribute 1052 indicates that the time series data 1009 can use any number of actual data points. For example, the virtual point time series can be based on a plurality of actual data points. In some embodiments, the point usage attribute 1052 is treated as a list of points for monitoring value changes. When any point identified by the point usage attribute 1052 is updated, the time series 1009 can be automatically updated to reflect the changed value of the points used by the time series 1009.

  Also, the time series 1009 is shown to use a time series used attribute 1056 and a time series used attribute 1058. The asterisks attached to the time series used attribute 1056 and the time series usage attribute 1058 indicate that the time series 1009 can be used by any number of other time series and that the time series 1009 can be used by any number of other time series. It shows that time series can be used. For example, both the data rollup time series and the virtual point time series can be based on the same raw data time series. As another example, a single virtual point time series can be based on multiple other time series (eg, multiple raw data time series). In some embodiments, the time series used attribute 1056 is treated as a list of time series that contributes to the update of the time series 1009. When the time series 1009 is updated, the time series listed in the time series used attribute 1056 can be identified and automatically updated to reflect the change to the time series 1009. Similarly, the time series use attribute 1058 can be handled as a time series list for monitoring updates. When any of the time series identified by the time series usage attribute 1058 is updated, the time series 1009 may be automatically updated to reflect updates to other time series on which the time series 1009 is based. it can.

  Referring now to FIG. 10B, an example entity graph 1060 for a particular building management system is shown according to some embodiments. Entity graph 1060 is shown to include an organization 1061 (“ACME Company”). The organization 1061 is a collection of individuals, corporations, businesses, agencies, or other types of organizations. Organization 1061 occupies space 1063 (“Milwaukee campus”), as indicated by occupancy attribute 1064. Space 1063 is occupied by tissue 1061 as indicated by occupied attribute 1062.

  In some embodiments, space 1063 is a top-level space within the hierarchy of spaces. For example, the space 1063 can represent the entire campus (ie, a collection of buildings). Space 1063 can include various subspaces (eg, individual buildings), such as space 1065 (“Building 1”) and space 1073 (“Building 2”), as indicated by inclusion attributes 1068 and 1080. . Spaces 1065 and 1080 are located within space 1063 as indicated by inclusion attribute 1066. Each of the spaces 1065 and 1073 can include lower level subspaces, such as individual floors, areas, or rooms within each building. However, such subspaces have been omitted from the entity graph 1060 for simplicity.

  Space 1065 is serviced by system 1067 (“ElecMainMeter1”) indicated by serviced attribute 1072. System 1067 can be any system that serves space 1065 (eg, an HVAC system, a lighting system, an electrical system, a security system, etc.). Service attribute 1070 indicates that system 1067 provides service to space 1065. In entity graph 1060, system 1067 is shown as an electrical system having subsystem 1069 (“LightingSubMeter1”) and subsystem 1071 (“PlugLoadSubMeter2”) indicated by subsystem attributes 1076 and 1078. Subsystems 1069 and 1071 are part of system 1067 as indicated by part attribute 1074.

  Space 1073 is serviced by system 1075 (“ElecMainMeter2”) indicated by serviced attribute 1084. System 1075 may be any system that serves space 1073 (eg, an HVAC system, a lighting system, an electrical system, a security system, etc.). Service attribute 1082 indicates that system 1075 provides service to space 1073. In entity graph 1060, system 1075 is shown as an electrical system having subsystem 1077 (“LightingSubMeter3”) indicated by subsystem attribute 1088. Subsystem 1077 is part of system 1075 as indicated by part attribute 1086.

  In addition to the attributes shown in FIG. 10, entity graph 1060 may include an “ancestor” attribute and a “descendant” attribute above each entity in the hierarchy. An ancestor attribute can identify all entities (eg, in a flat list) that are ancestors for a given entity. For example, an ancestor attribute for space 1065 can identify both space 1063 and tissue 1061 as ancestors. Similarly, the descendant attribute can identify all entities that are descendants of a given entity (eg, in a flat list). For example, the descendant attribute for space 1065 can identify system 1067, subsystem 1069, and subsystem 1071 as descendants. This provides each entity with a complete list of its ancestors and descendants, regardless of the number of levels contained in the hierarchical tree. This is a form of transitive closure.

In some embodiments, transitive closure provided by descendant and ancestor attributes allows the entity graph 1060 to easily perform simple queries without having to search multiple levels of the hierarchical tree. For example, the following query can be used to find all meters under the “Milwaukee Campus” space 1063.
/ Systems? $ Filter = (systemTypepeq
Jci. Be. Data. SystemType 'Meter') and
ancestorSpaces / any (a: a / nameeq 'MilwaukeeCampus')
Furthermore, it is possible to answer using only the descendant attributes of the “Milwaukee campus” space 1063. For example, the descendant attribute of space 1063 can identify all meters that are hierarchically below space 1063. The descendant attributes can be organized as a flat list and stored as attributes of the space 1063. This allows queries to be provided by searching only the descendant attributes of space 1063 without having to search other levels or entities of the hierarchy.

  Referring now to FIG. 11, an object relationship diagram 1100 is shown according to some embodiments. Relationship diagram 1100 is shown to include entity template 1102, point 1104, time series 1106, and sample 1108. In some embodiments, entity templates 1102, points 1104, time series 1106, and samples 1108 are stored as data objects in memory 510, local storage 514, and / or host storage 516. Relationship diagram 1100 shows the relationship between entity template 1102, point 1104, and timeline 1106.

  The entity template 1102 can include various attributes such as an ID attribute, a name attribute, a property attribute, and a relationship attribute. The ID attribute can be provided as a string and identifies a unique ID for the entity template 1102. The name attribute can be provided as a character string, and the name of the entity template 1102 can be identified. A property attribute can be provided as a vector and identifies one or more properties of the entity template 1102. The relationship attribute can also be provided as a vector and identifies one or more relationships of the entity template 1102.

  The point 1104 can include various attributes such as an ID attribute, an entity template ID attribute, a time series attribute, and a unit ID attribute. The ID attribute can be provided as a string and identifies a unique ID for point 1104. Also, the entity template ID attribute can be provided as a string, and the entity template 1102 associated with the point 1104 can be identified (eg, by listing the ID attributes of the entity template 1102). Any number of points 1104 can be associated with the entity template 1102. However, in some embodiments, each point 11104 is associated with a single entity template 1102. The time series attribute can be provided as a string and identifies any time series associated with the point 1104 (eg, by listing an ID string of any time series 1106 associated with the point 1104). . The unit ID attribute can also be provided as a character string and identifies the unit of the variable quantified by point 1104.

  The time series 1106 can include various attributes such as an ID attribute, a sample attribute, a conversion type attribute, and a unit ID attribute. The ID attribute can be provided as a string and identifies a unique ID for the time series 1106. The unique ID of the time series 1106 can be listed in the time series attribute of the point 1104 to associate the time series 1106 with the point 1104. Any number of time series 1106 can be associated with points 1104. Each time series 1106 is associated with a single point 1104. The sample attribute can be provided as a vector and identifies one or more samples associated with the time series 1106. The conversion type attribute identifies the type of conversion used to generate the time series 1106 (eg, 1 hour average, 1 day average, 1 month average). The unit ID attribute can also be provided as a character string and identifies the unit of the variable quantified by the time series 1106.

  Sample 1108 may include a timestamp attribute and a value attribute. The timestamp attribute can be provided in local time and can include a time difference with respect to universal time. The value attribute can include the data value of sample 1108. In some cases, the value attribute is a numeric value (eg, with respect to a measurement variable). In other cases, when the sample 1108 is part of the failure detection time series, the value attribute may be a character string such as “failure”.

Dashboard layout

  Referring now to FIG. 12, a block diagram illustrating the operation of the dashboard layout generator 518 is shown in accordance with some embodiments. Dashboard layout generator 518 is shown to receive points 1202, raw time series data 1204, and optimized time series data 1206. Points 1202 can include real data points (eg, measured data points), virtual data points (eg, calculated data points), or other types of data points for which sample data is received at BMS 500. Or calculated by the BMS 500. Point 1202 may include an instance of point 1104 as described with reference to FIG. For example, each point 1202 can include a point ID, an entity template ID, one or more time series indications associated with the point, and a unit ID. The live time series data 1204 can include live time series data collected or generated by the data collector 512. Optimized time series data 1206 may be generated or processed by data rollup time series, cleansed time series, virtual point time series, weather point time series, fault detection time series, and / or job manager 604. Other types of time series data can be included.

  A dashboard layout generator 518 that generates a dashboard layout description 1208 is shown. In some embodiments, the dashboard layout description 1208 is used to render a user interface (ie, a dashboard layout) by a variety of different rendering engines (eg, web browser, PDF engine, etc.) and / or framework. A framework-independent layout description that can be done. Dashboard layout description 1208 is not a user interface itself, but a schema that application 530 and other frameworks can use to generate a user interface. Many different frameworks and applications 530 can retrieve and use the dashboard layout description 1208 to generate a user interface according to the theme settings and size settings of the framework. In some embodiments, the dashboard layout description 1208 describes a dashboard layout using a grid of rows and columns.

  Referring now to FIG. 13, a grid 1300 showing a dashboard layout description 1208 is shown. Grid 1300 is shown as an m × n grid containing m rows and n columns. Row and column intersections define specific positions within the grid 1300 and widgets can be positioned at those positions. For example, the grid 1300 is shown to include a text widget 1302 at the intersection of a first row and a second column. The grid 1300 also includes a graph widget 1304 at the intersection of the second row and the second column. In some embodiments, the position of widgets 1302 and 1304 is defined by the row and column index of grid 1300. For example, the dashboard layout description 1208 can define the position of the text widget 1302 by specifying that the text widget 1302 is located at the intersection of the first row and second column of the grid 1300. Similarly, the dashboard layout description 1208 can define the position of the graph widget 1304 by specifying that the graph widget 1304 is located at the intersection of the second row and second column of the grid 1300. .

  In some embodiments, the dashboard layout description 1208 defines various properties for each widget. For example, widgets 1302 and 1304 can have widget type properties that define the type of widget (eg, text, graph, image, etc.). In some embodiments, widget 1302 has a text property that defines the text displayed by widget 1302. The widget 1304 can include graph properties that define various attributes of the graph (eg, graph title, x-axis title, y-axis title, etc.). In some embodiments, the graph widget 1304 includes properties that define one or more time series of data displayed in the widget 1304. The time series may be different time series of the same data points (eg, raw data time series, 1 hour average time series, 1 day average time series, etc.), or time series of different data points. In some embodiments, the graph widget 1304 includes a property that defines the widget name and a set of APIs (eg, service URL or database URL) that drive the widget 1304.

  In some embodiments, the dashboard layout description 1208 includes a top level dashboard element that includes properties that apply to the entire dashboard layout. Such properties can include, for example, the dashboard name, whether the widget is collapsible, whether the dashboard is editable, and the grid layout. A grid layout can be defined as an array of objects (eg, widgets), where each object is an array of properties. The dashboard layout may be static, dynamic, or user specific. A static layout can be used when the layout does not change. You can add more functionality to an existing dashboard using a dynamic layout. A user specified layout may be used to allow the user to adjust the dashboard (eg, by adding or removing widgets).

  The dashboard layout description 1208 can be used to drive various services. In some embodiments, the dashboard layout description 1208 allows a user interface to be provided as a service. In this scenario, the dashboard layout generator 518 can provide predefined widgets to the framework. The framework can read the dashboard layout description 1208 and render the user interface. By providing the user interface as a service, a new widget can be added to a predefined widget. In other embodiments, the dashboard layout description 1208 allows data visualization to be provided as a service.

  Referring now to FIGS. 14-15, an example dashboard layout description 1400 and an example dashboard layout 1500 that can be generated from the dashboard layout description 1400 are shown in accordance with some embodiments. With particular reference to FIG. 14, the dashboard layout description 1400 is shown to include a number of properties 1402 that apply to the entire dashboard layout 1500. Properties 1402 are shown to include the name of the dashboard layout 1500 and properties that define whether the dashboard layout 1500 is foldable, maximizable, and / or editable.

  In some embodiments, the dashboard layout description 1400 is written in JSON format. For example, the dashboard layout description 1400 is shown to include a row object 1404 and a column object 1406 contained within the row object 1404. Column object 1406 includes two elements. Accordingly, the dashboard layout description 1400 defines a layout that includes one row and two columns within the row. Each column contains a widget. For example, the first element of column object 1406 includes a first widget object 1408 and the second element of column object 1406 includes a second widget object 1410.

  The widget object 1408 includes a number of properties 1412 that define various attributes of the widget object 1408. For example, the widget object 1408 is shown to include properties that define the widget name (ie, MEMS meter), widget type (ie, spline), and widget configuration. The spline type indicates that the widget object 1408 defines a line graph. The widget configuration properties include a number of subproperties 1414 that define line graph attributes. A sub-property 1414 is a sample that defines a title, an x-axis label (ie date and time), a y-axis label (ie KW), a token API that defines the API that drives the widget object 1408, and another API that drives the widget object 1408. It is shown to include an API. Sub-property 1414 also includes point properties that define a number of time series that can be displayed in widget object 1408.

  Similarly, widget object 1410 includes a number of properties 1416 that define various attributes of widget object 1410. For example, widget object 1410 is shown to include a widget name (ie, MEMS meter), widget type (ie, column), and properties that define the widget configuration. The columnar type indicates that the widget object 1410 defines a bar graph. The widget configuration properties include a number of sub-properties 1418 that define bar chart attributes. A sub-property 1418 is a sample that defines a title, an x-axis label (ie date and time), a y-axis label (ie KWH), a token API that defines the API that drives the widget object 1410, and another API that drives the widget object 1410. It is shown to include an API. Sub-property 1418 also includes point properties that define a number of time series that can be displayed within widget object 1410.

  Referring now to FIG. 15, a dashboard layout 1500 is shown to include a title 1502, a first widget 1504, and a second widget 1506. The text of title 1502 is defined by property 1402, first widget 1504 is defined by widget object 1408, and second widget 1506 is defined by widget object 1410. Dashboard layout 1500 includes one row and two columns within the row. The first column includes a first widget 1504 and the second column includes a second widget 1506. The widget 1504 includes a title 1508 “MEMS meter” (defined by property 1412) and a drop-down selector 1512 that can be used to select any time series defined by sub-property 1414. It is shown. Similarly, widget 1506 has a title 1510 “MEMS meter” (defined by property 1416) and a drop-down selector 1514 that can be used to select any time series defined by sub-property 1418. Shown to include.

  Referring now to FIGS. 16-17, according to some embodiments, another example of a dashboard layout description 1600 and a dashboard layout 1700 that can be generated from the dashboard layout description 1600 is shown. Yes. With particular reference to FIG. 16, the dashboard layout description 1600 is shown to include a number of properties 1602 that apply to the entire dashboard layout 1700. Properties 1602 are shown to include the name of the dashboard layout 1700 and properties that define whether the dashboard layout 1700 is foldable, maximizable, and / or editable.

  In some embodiments, the dashboard layout description 1600 is written in JSON format. For example, the dashboard layout description 1600 is shown to include a line object 1604. Row object 1604 has two data elements, each data element defining a different row of dashboard layout 1700. The first element of row object 1604 includes a first column object 1606, and the second element of row object 1604 includes a second column object 1607. The column object 1606 has a single element that includes the first widget object 1608. However, the column object 1607 has two elements, each element including a widget object (ie, widget objects 1610 and 1620). Accordingly, the dashboard layout description 1600 defines a layout that includes a first row having one column and a second row having two columns. The first row includes a widget object 1608. The second row includes two widget objects 1610 and 1620 in adjacent columns.

  Widget object 1608 includes a number of properties 1612 that define various attributes of widget object 1608. For example, widget object 1608 is shown to include a widget name (ie, BTU meter), widget type (ie, spline), and properties that define the widget configuration. The spline type indicates that the widget object 1608 defines a line graph. The widget configuration properties include a number of subproperties 1614 that define the attributes of the line graph. Sub-properties 1614 are shown to include a title, x-axis label, y-axis label, a token API that defines the API that drives the widget object 1608, and a sample API that defines another API that drives the widget object 1608. Yes. Sub-property 1614 also includes point properties that define a number of time series that can be displayed in widget object 1608.

  Similarly, widget object 1610 includes a number of properties 1616 that define various attributes of widget object 1610. For example, widget object 1610 is shown to include a widget name (ie, meter 1), widget type (ie, spline), and properties that define the widget configuration. The spline type indicates that the widget object 1610 defines a line graph. The widget configuration properties include a number of sub-properties 1618 that define line graph attributes. Sub-properties 1618 are shown to include a title, x-axis label, y-axis label, a token API that defines the API that drives the widget object 1610, and a sample API that defines another API that drives the widget object 1610. Yes. Sub-property 1618 also includes point properties that define a number of time series that can be displayed within widget object 1610.

  The widget object 1620 includes a number of properties 1622 that define various attributes of the widget object 1620. For example, widget object 1620 is shown to include a widget name (ie meter 1), widget type (ie spline), and properties that define the widget configuration. The spline type indicates that the widget object 1620 defines a line graph. The widget configuration properties include a number of subproperties 1624 that define the attributes of the line graph. Sub-properties 1624 are shown to include a title, x-axis label, y-axis label, a token API that defines the API that drives the widget object 1620, and a sample API that defines another API that drives the widget object 1620. Yes. Sub-property 1624 also includes point properties that define a number of time series that can be displayed within widget object 1620.

  Referring now to FIG. 17, a dashboard layout 1700 is shown to include a title 1702, a first widget 1704, a second widget 1706, and a third widget 1707. The text of the title 1702 is defined by the property 1602. The content of the first widget 1704 is defined by the widget object 1608. The content of the second widget 1706 is defined by the widget object 1610. The content of the third widget 1707 is defined by the widget object 1620. Dashboard layout 1700 includes two rows. The first row includes one column and the second row includes two columns. The first row includes a first widget 1704, and the second row includes a second widget 1706 in a first column and a third widget 1707 in a second column.

  The widget 1704 includes a title 1708 “BTU meter” (defined by property 1612) and a drop-down selector 1712 that can be used to select any time series defined by sub-property 1614. It is shown. Similarly, widget 1706 has a title 1710 “Meter 1” (defined by property 1616) and a drop-down selector 1714 that can be used to select any time series defined by sub-property 1618. Shown to include. The widget 1707 includes a title 1711 “Meter 1” (defined by property 1622) and a drop-down selector 1715 that can be used to select any time series defined by sub-property 1624. It is shown.

Energy management system user interface

  Referring now to FIGS. 18-51, there are shown several user interfaces that the building management system 500 can generate according to an exemplary embodiment. In some embodiments, the user interface may be an energy management application 532, a monitoring and reporting application 534, an enterprise control application 536, or other application 530 that uses optimized time series data generated by the data platform service 520. Generated by. For example, the user interface can be generated by a building energy management system that includes an instance of the energy management application 532. An example of such a building energy management system is Johnson Controls Inc. By METASYS® Energy Management System (MEMS). The building energy management system is a cloud that communicates with the building management system 500 as part of the building management system 500 (eg, one of the applications 530) or via a communication network 446 (eg, Internet, LAN, cellular network, etc.). It can be implemented as a base application (eg, one of a remote system and application 444).

  Referring now to FIG. 18, a login interface 1800 is shown according to an exemplary embodiment. Login interface 1800 may be presented via a web browser and / or via an application running on a client device (eg, desktop computer, laptop computer, tablet, smartphone, etc.). A user can log in to energy management application 532 by entering access credentials via login interface 1800 (eg, username 1802 and password 1804). Access credentials entered via the login interface 1800 may be sent to an authentication server for authentication.

Overview dashboard

  Referring now to FIGS. 19-34, an overview dashboard 1900 for an energy management application 532 is shown, according to an illustrative embodiment. The overview dashboard 1900 may be presented after the user logs in and may be the first interface that the user sees after entering the access credentials 1802-1804. The overview dashboard 1900 is shown to include a navigation pane 1902 on the left side of the dashboard 1900. A handle bar 1904 to the right of the navigation pane 1902 (immediately to the right of the search box 1906) may allow the user to show or hide the navigation pane 1902. The overview dashboard 1900 may include a navigation tile 1908 shown in the upper right corner. When the navigation tile 1908 is selected (eg, clicked, put a pointer, etc.), a pop-up window 2000 may appear (shown in FIG. 20). Pop-up window 2000 includes a dashboard button 2002 that allows the user to navigate to dashboard 1900 and a settings button 2004 that allows the user to navigate to setup interface 3600 (described in more detail below). Is shown in

  As shown in FIG. 19, the navigation pane 1902 includes a portfolio tab 1910. Portfolio tab 1910 may include an overview or hierarchy of facilities that the user can view and manage. For example, the portfolio tab 1910 includes a portfolio level node 1912 that indicates the name of a portfolio or company managed by the energy management application 532 (ie, “ABC Company”), and facilities within the portfolio (ie, “Ace Facilities” and “Omega”). It is shown to include two facility level nodes 1914 and 1916 indicating facilities "). In some embodiments, a portfolio is a set of buildings associated with a company. When the portfolio level node 1912 is selected, the overview dashboard 1900 may display energy related information about the portfolio. For example, the overview dashboard 1900 is shown to display an energy usage intensity (EUI) chart 1918 of various facilities in the portfolio, an energy fact panel 1920 to the right of the chart 1918, and an energy consumption tracker 1922. Has been.

  The EUI chart 1918 may display a portfolio energy index depending on the size of each facility. The dependent variable (kWh / sqft) shown on the vertical axis 1924 can be calculated by summing the total energy usage for the facility and dividing by the size of the facility (eg, square feet). A low EUI for a facility can indicate that the facility has better energy performance, and a high EUI for the facility can indicate that the facility has worse energy performance. The total energy usage of the facility can be summed over a variety of different intervals by selecting different time intervals. For example, the user can click the button 1926 above the chart 1918 to select a time interval of one week, one month, three months, six months, one year, or a custom time interval (shown in FIG. 21). ) When the pointer is placed on the bar 1928 or 1930 on the chart 1918, a pop-up showing the value of the EUI and the name of the facility may be displayed. In some embodiments, the EUI chart 1918 includes an average portfolio EUI line 1932 showing the average EUI for all facilities. The average portfolio EUI line 1932 may allow the user to easily compare each facility's EUI to the portfolio average EUI.

  In some embodiments, the overview dashboard 1900 includes a chart of energy density for various facilities in the portfolio. Similar to the EUI, energy density is an energy usage criterion normalized to the area of the facility. However, energy density may be calculated based on changes in energy usage between successive samples, rather than cumulative energy usage over time intervals. In some embodiments, the energy density determines a change or delta in energy usage (eg, kWh) between successive samples of energy usage for the facility, and the change or delta is the size of the facility (eg, Calculated by dividing by square feet. For example, if the facility energy consumption at 1 pm is 50 kWh and the facility energy consumption at 2 pm is 70 kWh, the change in energy consumption or delta between 1 pm and 2 pm will be 20 kWh. . This delta (ie, 20 kWh) can be divided by the area of the facility to determine the energy density of the facility (eg, kWh / sqft) over the 1 pm and 2 pm period.

  Throughout this disclosure, the EUI is used as an example of an energy usage criterion for a facility. However, it should be understood that energy density can be used in addition to or in place of the EUI in any of the user interfaces, analyzes, or dashboards described herein. References to the EUI in this disclosure can be replaced / supplemented by energy density (or any other energy usage metric) without departing from the teachings of this disclosure.

  The energy fact panel 1920 may display the total amount of energy consumed by the portfolio during the time interval selected by the user. For example, the energy fact panel 1920 is shown to display an indication 1934 that the portfolio consumed 37152 kWh in the month of October 2015. In some embodiments, the energy fact panel 1920 displays a carbon footprint (ie, CO2 emissions) indication 1936 corresponding to total energy consumption. The energy management application 532 can automatically convert energy consumption into CO2 emissions and display the CO2 emissions via the energy fact panel 1920. Both the EUI chart 1918 and the energy fact panel 1920 may be automatically updated in response to a user selecting a different time interval via the EUI chart 1918.

  The energy consumption tracker 1922 divides the total energy consumption into various commodities such as electricity and natural gas. The energy consumption tracker 1922 may include a chart 1938 that shows the amount of each commodity consumed by each facility during a particular time interval. The time interval can be selected by the user using a button 1940 displayed above the chart in the energy consumption tracker 1922. Similar to the time interval selection provided by the EUI chart 1918, the user can select one week, one month, three months, six months, one year time interval, or a custom time interval.

  As shown in FIG. 22, selecting a bar 1942, 1944, 1946, or 1948 for a particular item in chart 1938 or placing the pointer on it will consume the item consumed by the corresponding facility during the time interval selected by the user A pop-up 2200 can be displayed showing the amount. For example, when the pointer is placed on the gas bar 1942 in the row 1950 of the Ace facility, the amount of gas consumed by the Ace facility within the time interval can be displayed. Similarly, when the pointer is put on the gas bar 1946 in the row 1952 of the Omega facility, the amount of gas consumed by the Omega facility during the time interval can be displayed. Gas consumption may be indicated in both energy units (eg, kWh) and volume units (eg, cubic feet). The energy management application 532 can automatically convert commodity-specific units (eg, cubic feet) provided by the energy utility into energy units (eg, kWh), thereby enabling energy consumption across various commodities. Amounts can be directly compared. The pop-up 2200 can also indicate a percentage of the total energy consumption corresponding to the selected item. For example, the pop-up 2200 in FIG. 22 indicates that the gas consumption accounted for 12% of the total energy consumption for the Ace facility.

  As shown in FIG. 23, by selecting a grid button 2302 to the right of the time interval button 1940, the energy consumption tracker 1922 can display energy consumption data 2304 in a grid format. By selecting an enlarge button 2306 (that is, an arrow in a diagonal direction) in the upper right corner of the energy consumption tracker 1922, the energy consumption tracker 1922 can be enlarged and spread over the screen. Similarly, the enlargement button 2308 in the upper right corner of the EUI panel 2310 allows the EUI chart 1918 to be enlarged to fill the screen. This may allow a user to easily view detailed data regarding a long list of facilities that may not all fit within a compressed widget (ie, EUI chart 1918 and energy consumption tracker 1922).

  As shown in FIGS. 24-25, widgets 2402 and 2404 shown on dashboard 1900 may include setting buttons 2406 and 2408 (shown as gear icons), respectively. Setting buttons 2406 and 2408 allow the user to select various theme colors 2410 (shown in FIG. 24) for the corresponding widget, and to change the data from widgets 2402 and 2404 to. svg,. png,. jpeg,. pdf,. It may be possible to screenshot / export in various formats 2502 such as csv (shown in FIG. 25).

  As shown in FIG. 26, by selecting a particular facility 1914 or 1916 via the portfolio tab 1910, the overview dashboard 1900 can display energy related data regarding the selected facility 1914 or 1916. The energy related data for facility 1914 or 1916 may be similar to the energy related data for portfolio 1912. However, instead of separating energy-related data by facility, the data can be separated by individual buildings within the selected facility. For example, the Ace facility 1914 is shown to include a single building 2602 entitled “Main Building”. Once building 2602 is selected, EUI chart 1918 and energy consumption tracker 1922 may display energy consumption data for the selected building 2602. If the selected facility 1914 includes additional buildings, energy related data regarding such buildings may also be displayed when the facility 1914 is selected.

  As shown in FIG. 27, by selecting a particular building 2602 via the portfolio tab 1910, the overview dashboard 1900 can display energy-related data for the selected building 2602. Dashboard 1900 is shown to include four widgets including energy consumption widget 2702, energy demand widget 2704, energy consumption tracker widget 2706, and building EUI widget 2708. The energy consumption widget 2702 can display the energy consumption 2718 of the selected building at various time intervals (eg, one week, one day, one month, etc.). Each widget 2702-2708 may include a time interval selector 2710, 2712, 2714, or 2716 that allows the user to select a particular data interval displayed on each widget 2702-2708. As with the other time selectors 1926 and 1940, the user can click a button in the time interval selectors 2710-2716 to select a one-week, one-month, three-month, six-month, one-year time interval, or a custom time interval. Can be selected. In some embodiments, a one month interval is selected by default.

  The energy demand widget 2704 can display an energy demand graph 2720 for the selected building at various time intervals. A bar 2722 displayed on the energy demand widget 2704 can indicate the current energy demand of the selected building. For example, FIG. 27 shows building energy demand divided by day, where the daily energy demand is represented by a bar 2722. In various embodiments, bar 2722 may represent average energy demand or peak energy demand. Dot 2724 displayed on energy demand widget 2704 represents the energy demand for the previous time interval preceding the time interval displayed on graph 2720. For example, the monthly graph 2720 uses the bar 2722 to display the current energy demand for each day of the current month, and uses the dot 2724 to display the previous energy demand for each day of the previous month. Sometimes. As a result, the user can easily compare the daily energy demand for two consecutive months. For other granularities, the energy demand graph 2720 may include one year energy demand (each bar 2722 corresponds to a specific month), one day energy demand (each bar 2722 corresponds to a specific time), etc. May be displayed.

  The energy consumption tracker widget 2706 may display a chart 2726 showing the amount of each commodity (eg, gas 2728 and power 2730) consumed by the selected building 2602. Selecting product 2728 or 2730 in chart 2726 or placing the pointer over it may display a pop-up showing the amount of product consumed by building 2602 during the user selected time interval. For example, when the pointer is placed on the gas bar 2728, the amount of gas consumed by the building 2602 within the time interval can be displayed. Gas consumption may be indicated in both energy units (eg, kWh) and volume units (eg, cubic feet). The energy management application 532 can automatically convert commodity-specific units (eg, cubic feet) provided by the energy utility into energy units (eg, kWh), thereby enabling energy consumption across various commodities. Amounts can be directly compared. The pop-up can also indicate a percentage of the total energy consumption corresponding to the selected item.

  The building EUI widget 2708 may include an EUI graph 2732 that shows the EUI of the building. Building EUI 2736 may be calculated by dividing the total energy consumption of building 2602 by the size of building 2602 (eg, square feet). The EUI graph 2732 may include an average facility EUI line 2734 representing an average EUI for the facility 1914 that includes the selected building 2602. Average facility EUI line 2734 may allow the user to easily compare the EUI of the selected building 2602 with the facility average EUI.

  As shown in FIG. 28, by selecting an enlarge button 2804 in the upper right corner of the widget 2802, each widget 2802 (for example, any one of the widgets 2702 to 2708) can be enlarged to fill the screen. The data shown in each widget 2802 can be displayed in a grid format by selecting the grid button 2806 to the right of the time interval selector 2808. Each widget 2802 may include a settings button 2810 (shown as a gear icon). The set button 2810 allows the user to select various theme colors for the corresponding widget 2802, as described above, and to change the data from the widget 2802 to. svg,. png,. jpeg,. pdf,. It may be possible to screenshot / export in various formats such as csv.

  In some embodiments, by selecting a bar 2812 or other graphic representing data from a particular time interval, the graph 2814 displays the selected data with a higher granularity. For example, FIG. 29 shows a bar graph 2902 showing the weekly energy consumption of the main building 2602, with each bar 2904, 2906, 2908, 2910, and 2912 representing the energy consumption for a particular day. By selecting one of the bars 2904-2912 in the chart 2902, the energy consumption for the selected day can be broken down by hour of the day (shown in FIG. 30). For example, FIG. 30 shows a bar graph 3002 having a bar 3004 every hour of the day. By selecting one of the bars 3004 in the chart 3002, the energy consumption for the selected time can be further decomposed within that time (eg, into 15-minute intervals, 5-minute intervals, etc.). 31). For example, FIG. 31 shows a bar graph 3102 with bars 3104, 3106, 3108, and 3110 every 15 minute intervals within the selected time. Energy consumption data can be displayed at any granularity, and users can move to different granularities by clicking on bars 2904-2912, 3004, and / or 3104-3110 in charts 2902, 3002, and 3102. It is contemplated that it can be done.

  As shown in FIGS. 32-33, the user can select a particular data range within each chart 3202 to zoom in on the selected data range 3204. For example, assume that the user wants to zoom in on data from October 5th to October 28th. The user can click in the chart 3202 and drag the mouse cursor to draw a box 3206 around the desired data range 3204 (shown in FIG. 32). Once the desired data range 3204 is selected, the chart 3202 is automatically updated to display only the data range 3204 selected by the user (shown in FIG. 33). By selecting the reset zoom button 3302, the chart 3202 can return to the previous view.

  In some embodiments, the overview dashboard 1900 is configured to allow a user to navigate to the portfolio of buildings 1910 without requiring the use of a navigation pane 1902. For example, the navigation pane 1902 can be collapsed (ie, hidden) by clicking the handle bar 1904 to the right of the search box 1906. When the navigation pane 1902 is hidden, the user clicks on the item of the hierarchical character string 3304 (that is, the character string “ABC company> Ace facility> main building” shown in FIG. 33) at the top of the overview tab 3306. And select the corresponding company, facility, or building. The hierarchy string 3304 may be updated to indicate the lowest level of the currently selected hierarchy and any higher level of the hierarchy that includes the selected lower level. For example, when the main building 2602 is selected, the hierarchical character string 3304 may include the entire character string “ABC company> Ace facility> main building”. However, when the Ace facility 1914 is selected, the hierarchical character string 3304 may be updated to indicate only “ABC company> Ace facility”.

  As shown in FIG. 34, the navigation pane 1902 includes a meter tab 3402. When the meter tab 3402 is selected, the user can expand the hierarchy 3404 shown in the navigation pane 1902 to show various energy meters 3406 and 3408 located within each building. For example, the main building 2602 is shown to include a floor 3410 (ie, floor 1) that includes a “main electricity meter” 3406 and a “main gas meter” 3408. By selecting any of the meters 3406-3408 in the meter tab 3402, the overview dashboard 1900 can display detailed meter data for the selected meter.

  The meter data is shown to include energy consumption data that can be displayed on the energy consumption widget 3412 and energy demand data that can be displayed on the energy demand widget 3414. Each widget 3412-3414 may include a time interval selector 3416 or 3418 that allows a user to select a particular data interval to be displayed within each widget 3412-3414. As with the other time selectors 1926, 1940, and 2710-2716, the user clicks a button in the time interval selectors 3414-3416 to time intervals of one week, one month, three months, six months, one year. Or a custom time interval can be selected. In some embodiments, a one month interval is selected by default.

  The energy consumption widget 3412 may display the energy consumption measured by the selected meter 3406 at various time intervals (eg, one week, one day, one month, etc.). The energy consumption widget 3412 is shown to include a current total energy consumption 3420 for the selected time interval 3424 and a previous total energy consumption 3422 for the previous time interval 3426. In some embodiments, the previous time interval 3426 is the same month of the previous year (or any other time interval longer than the selected time interval) (or any other selected by the time interval selector 3416). The duration). For example, the current time interval 3424 is shown as October 2015 and the previous time interval 3426 is shown as October 2014. The comparison is more meaningful because the change in energy consumption due to weather differences can be reduced by comparing the energy consumption of the same month in different years. The energy consumption widget 3412 may display an amount 3428 (eg, a percent change) that the energy consumption has increased or decreased from the previous time interval 3426 to the current time interval 3424.

  The energy demand widget 3414 can display the energy demand measured by the selected meter 3406 at various time intervals. The energy demand widget 3414 is shown to include a graph 3440. A bar 3430 displayed in the graph 3440 can indicate the current energy demand measured by the selected meter 3406. For example, FIG. 34 shows the energy demand of the building 2602 divided by day, and the energy demand of each day is represented by the bar 3430 of the graph 3440. FIG. In various embodiments, the bar 3430 may represent average energy demand or peak energy demand. Dot 3432 displayed in graph 3440 represents the energy demand for the corresponding period of the previous time interval preceding the time interval displayed in graph 3440. For example, the monthly graph 3440 uses the bar 3430 to display the current energy demand for each day of the current month, and uses the dot 3432 to display the previous energy demand for each day of the previous month. Sometimes. As a result, the user can easily compare the daily energy demand for two consecutive months. For other granularities, the energy demand graph 3440 may be a yearly energy demand (each bar 3430 and dot 3432 corresponds to a particular month) or a daily energy demand (each bar 3430 and dot 3432 is specific). Etc.) may be displayed.

  With reference now to FIG. 35, a flow diagram of a process 3500 for configuring an energy management application 532 is shown in accordance with an illustrative embodiment. Process 3500 includes defining a spatial tree (step 3502), defining a data source (step 3504), testing a connection to ADX (step 3506), and discovering data points (steps). 3508), mapping data points (step 3510), updating point attributes if necessary (step 3512), synchronizing with the data platform (step 3514), and for the selected data point Fetching historical data (step 3516) and mapping points to a spatial tree and displaying the data on a dashboard (step 3518) are shown.

Setup interface

  With reference now to FIGS. 36-49, a setup interface 3600 that may be generated by an energy management application 532 is shown in accordance with an illustrative embodiment. In some embodiments, the setup interface 3600 is displayed in response to the user selecting a settings button 2004 in the overview dashboard 1900 (shown in FIG. 20). The setup interface 3600 is shown to include various tiles 3602-3626 that correspond to different types of configurable settings. For example, the setup interface includes: spatial tile 3602, data source tile 3604, meter configuration tile 3606, tenant tile 3608, notification tile 3610, point tile 3612, baseline tile 3614, cooling / heating day tile 3616, obstacle tile 3618, fee Tile 3620, user tile 3622, schedule tile 3624, and information tile 3626 are shown. Before summary dashboard 1900 displays significant data, tiles 3602-3626 can be highlighted, marked, colored, or changed to indicate that the corresponding setting requires configuration. . For example, spatial tile 3602, data source tile 3604, and meter configuration tile 3606 are shown in FIG. 26 with mark 3628 and require further configuration of the space, data source, and meter used by energy management application 532. Indicates that there is.

  As shown in FIGS. 36-39, a spatial setup interface 3700 can be displayed by selecting a spatial tile 3602. The space setup interface 3700 is shown to include a space tree 3702. Spatial tree 3702 may include a hierarchy of space 3404 shown in navigation pane 1902 of dashboard 1900. The space can include, for example, portfolio 3704, facilities 3706-3708, buildings 3710-3712, floors 3714-3716, areas, rooms, or other types of spaces of any granularity. The user can add space to the space tree 3702 by selecting the plus button 3718 or remove space from the space tree 3702 by selecting the delete button 3720. A space can also be added by uploading a data file 3730 (for example, an Excel file) that defines the space tree 3702.

  Details of the selected space can be specified via the space setup interface 3700. For example, selecting portfolio 3704 “ABC Company” allows the user to enter details of portfolio 3704, such as portfolio name 3722, date format 3724, default unit 3726, and logo 3728 (shown in FIG. 36). Can be. By selecting facilities 3706-3708, the user can view facility details such as facility name 3732, address 3734, city 3736, state, country 3738, postal code 3740, latitude 3742, and longitude 3744 (shown in FIG. 37). Can be input. Selecting building 3802 may allow the user to enter details of building 3802, such as building name 3804, total floor area 3806, and occupancy number 3808 (shown in FIG. 38). Floor area 3806 may be used by energy management application 532 to calculate the EUI, as described above. Selecting floor 3902 may allow the user to enter details of floor 3902 such as floor name 3904 and floor area 3906 (shown in FIG. 39).

  As shown in FIG. 40, a data source setup interface 4000 can be displayed by selecting a data source tile 3604. Data source setup interface 4000 may be used to define various data sources 4004 used by energy management application 532. For example, the user can define a new data source by selecting a data source type (eg, BACnet, CSV, FX, METASYS, etc.) via the data source type drop down 4002. Other attributes of the data source can also be specified by the data source setup interface 4000. Such attributes may include, for example, data source name 4006, server IP 4008, database path 4010, time zone 4012, user name 4014, and password 4016. By selecting the enable box 4018, the data source can be enabled. By selecting an add button 4020, a data source can be added to the list of data sources shown in the chart 4030 at the bottom of the interface 4000. After the data source has been added, the test connection button 4022 can be selected to test whether the data source is online and properly configured.

  As shown in FIG. 41, the data source setup interface 4000 may include a data mapping tab 4102. Drop-down selector 4104 allows the user to select a particular data source (eg, “ADX Mumbai”). After selecting a data source, the user can click on the find button 4106 to aggregate the point tree 4108 for the data source. The aggregation of the point tree 4108 may be performed automatically by the energy management application 532. For example, the energy management application 532 can send a command to the ADX to fetch data points in response to the user clicking the find button 4106. The “All Meters” button 4110, “All Points” button 4112, and “Unmapped Points” button 4114 can be used to filter points by type, mapping status, and / or other attributes. Each button 4110-4114 can be toggled on / off to define a variety of different filters. For example, both the all meter button 4110 and the unmapped point button 4114 can be selected to view only unmapped meters. Similarly, all points button 4112 and unmapped point button 4114 can be selected to display all unmapped points.

  42-44, point mapping can be performed by dragging and dropping points from the point tree 4108 onto a window 4200 to the right of the point tree 4108. Any number of points can be mapped by simply dragging and dropping (shown in FIG. 42). An attribute 4302 of the map data point 4304 may be displayed (shown in FIG. 43). By checking the check box 4306 next to the map data point 4304 and selecting the “Delete Mapping” button 4308, the map data point 4304 can be individually selected and deleted. The attribute 4302 of the map data point 4304 can be edited by clicking on the data point 4304. For example, by selecting a data point 4304, a point configuration pop-up 4400 can be displayed (shown in FIG. 44) so that the user can select a data point 4304 such as unit, minimum value, maximum value, point name, etc. The attribute 4302 can be changed. After the data points 4304 are mapped, the user can click the “Synchronize” button 4310 (shown in FIG. 43) to synchronize the map data points 4304 with the data platform (eg, data platform service 520).

  As shown in FIG. 45, the data source setup interface 4000 may include a historical data tab 4502. The historical data tab 4502 allows the user to select a data source 4504 and request a list of data points 4508 mapped to that data source (eg, by clicking a request button 4506). The user can enter a time interval (eg, a date range) in the date field 4510 and click the send button 4512 to request historical data for the selected data point for the time interval specified by the user.

  As shown in FIG. 46, meter configuration interface 4600 can be displayed by selecting meter configuration tile 3606. The meter configuration interface 4600 is shown to include a point tree 4602, a meter distribution tree 4604, and a system details panel 4606. Point tree 4602 includes a drop-down selector 4608 that allows a user to specify a data source (eg, ADX Mumbai) and display a list of points 4610 associated with the data source. The list of points 4610 can be filtered to show only meters by selecting the “All Meters” button 4612 and / or all points by selecting the “All Points” button 4614. The meter distribution tree 4604 includes a space tree 4616 that allows the user to select a particular space. By selecting a space with the meter distribution tree 4604, the selected point can be associated with the space and the system details panel 4606 displayed.

  A system details panel 4606 allows the user to define a new meter. For example, the user can specify the type of system (eg, instrument, air handling unit, VAV box, cooler, boiler, heat exchanger, pump, fan, etc.). Selecting “Meter” from the system drop-down menu 4618 identifies the new item as a meter. The user can specify meter characteristics via the meter characteristics drop-down menu 4620. For example, the user can specify which of electricity, gas, steam, water, sewage, propane, fuel, diesel, coal, BTU, or other types of goods that can be measured by a meter. The user can specify the meter type (eg, online, virtual, baseline, calculated points, faults, etc.) via the meter type drop-down menu 4622. Finally, the user can enter a meter name in meter name box 4624. Information can be saved by clicking save button 4626.

  As shown in FIGS. 47-49, the selected space 4702 in the meter distribution tree 4604 shows the type of product 4704 measured by the meter 4706 (eg, “Electricity”) and the name of the meter 4706 that measures the product (eg, May be updated to include an “electric meter”). This may be done automatically in response to the user clicking save button 4626. Points 4802-4804 can be added to user specified meter 4706 by dragging and dropping from point tree 4602 to meter 4706 in meter distribution tree 4604 (shown in FIG. 48). An existing meter 4902 that measures a particular product is added to the meter distribution tree 4604 by dragging and dropping from the point tree 4602 to a product (eg, electricity 4904) in the meter distribution tree 4604 (shown in FIG. 49). be able to.

  Referring now to FIGS. 50-51, the overview dashboard 1900 may be automatically updated to display data from new spaces added and configured via the setup interface 3600. For example, portfolio 1910 is shown to include newly added facility 5002 “IEC Mumbai” in navigation pane 1902. Energy related data associated with the new facility 5002 is also shown in the EUI widget 2402 and the energy consumption tracker widget 2404 (shown in FIG. 50).

  As shown in FIG. 51, any meter 5102-5104 associated with the new space may also be displayed in the navigation pane 1902. Data provided by meters 5102-5104 may be shown in energy consumption widget 2702 and energy demand widget 2704, which may be the same as or similar to those described above. For example, the widgets 2702-2704 shown in FIG. 51 may be configured to display meter data for the current period 5106 and the previous period 5108. Current period 5106 may be aggregated using real-time data received from meters 5102-5104. The previous time period 5108 may not be aggregated until historical data is retrieved for meters 5102-5104 (as described with reference to FIG. 45). After the historical data is retrieved, the dashboard 1900 can be automatically updated to display the historical data along with the current data in the energy consumption widget 2702 and the energy demand widget 2704.

Energy analysis

  Referring now to FIG. 52, a block diagram illustrating the analysis service 524 in greater detail according to an exemplary embodiment is shown. The analysis service 524 may be one of the data platform services 520 within the BMS 500 (as described with reference to FIGS. 5-6), as a separate analysis system within the BMS 500, or remotely (eg, cloud-based) outside the BMS 500. It can be implemented as an analysis system. Analysis service 524 may receive input from components of BMS 500 (eg, local storage 514, host storage 516, meter 5204, etc.), as well as external systems and devices (eg, weather service 5202). For example, analysis service 524 uses time series data from local storage 514 and / or host storage 516 in combination with weather data from weather service 5202 and meter data from meter 5204 to perform various energy analyzes. Can be implemented. Analysis service 524 may provide the results of energy analysis as output to application 530, client device 448, and remote system and application 444. In some embodiments, analysis service 524 stores the analysis results as time series data in local storage 514 and / or host storage 516.

  Analysis service 524 is shown to include a weather normalization module 5208. The weather normalization module 5208 may be configured to normalize energy consumption data for a facility, building, or other space to remove weather effects. By normalizing the energy consumption data in this way, changes in the normalized energy consumption data may be due to factors other than weather (for example, occupation load, facility efficiency, etc.). The weather normalization module 5208 can determine the expected energy usage after removing the weather effects and can generate normalized energy usage statistics, for example, Differences between energy usage and expected energy usage, percentage changes, coefficient of variation of root mean square error (CVRME), and other energy usage statistics based on normalized energy usage data are included.

  In some embodiments, the weather normalization module 5208 receives historical meter data. The historical meter data can include historical values related to measurable resource consumption including, for example, power consumption (kWh), water consumption (gallons), and natural gas consumption (mmBTU). Historical meter data can be received as time series data from local storage 514 or host storage 516, collected from meter 5204 over time, or received from an energy utility (eg, as part of utility bills). . In some embodiments, the historical meter data includes historical meter data for more than one year. However, the historical meter data may include other time periods (eg, 6 months, 3 months, 1 month, etc.) in various other embodiments. The weather normalization module 5208 can also receive current meter data from the meter 5204.

In some embodiments, the weather normalization module 5208 receives weather data from the weather service 5202. Weather data may include outside air temperature measurements, humidity measurements, rainfall, wind speed, or other data indicative of weather conditions. In some embodiments, the weather data includes degree of cooling day (CDD) data and degree of heating day (HDD) data. The CDD data and HDD data can be provided as time series data having a CDD value and / or HDD value for each time series element. In some embodiments, the CDD and HDD are defined as follows:
CDD _i = max (0, _{TOA , i−} T _BalancePoint )
HDD _i = max (0, T _{BalancePoint -TOA , i} )
Here, _{TOA , i} is an outside air temperature at time step i, and T _BalancePoint is a temperature parameter (for example, 60 ° F. (16 ° C.)). T _BalancePoint can be set / adjusted by the user, or can be set / adjusted automatically based on the temperature setting for the building or space being controlled.

ここでＴ_{ＯＡ，ｉｊ}は、日ｉの時間ｊにおける時間毎の外気温であり、Ｔ_{ｈｉｇｈ，ｉ}は、日ｉの最高温度値であり、Ｔ_{ｌｏｗ，ｉ}は、日ｉの最低温度値である。いくつかの実施形態では、気象サービス５２０２によってＣＤＤおよびＨＤＤが時系列データとして提供される。他の実施形態では、気象サービス５２０２は、時系列データとしてＴ_ＯＡを提供し、気象正規化モジュール５２０８は、Ｔ_ＯＡの時系列値に基づいてＣＤＤ時系列およびＨＤＤ時系列を計算する。 In some embodiments, _{TOA, i} is the average daily outside temperature. _{TOA, i} can be calculated as the average of the temperature values for one hour or as the average of the high and low temperature values for the day. For example, _{TOA, i} can be calculated using any of the following equations:

Here, _{TOA, ij} is the outside air temperature for each hour at time j of day i, T _{high, i} is the highest temperature value of day i, and T _{low, i} is the lowest temperature value of day i. is there. In some embodiments, the weather service 5202 provides the CDD and HDD as time series data. In other embodiments, the weather service 5202, when providing _{T OA} as series data, weather normalization module 5208 _calculates the CDD time series and HDD time series on the basis of the time-series value of _{T OA.}

ここで、Ｕｓａｇｅ_{ａｃｔｕａｌ，ｉ}およびＵｓａｇｅ_{ｅｘｐｅｃｔｅｄ，ｉ}はそれぞれ、時間ステップｉにおける時系列値である。 In some embodiments, the weather normalization module 5208 uses weather data and meter data to predict energy usage for a building or space after removing weather effects. The weather normalization module 5208 compares the expected energy usage with the actual energy usage (as defined by the meter data), as shown in the following equation: The difference or delta from the quantity can be determined.
ΔUsage _i = Usage _{expected, i} −Usage _{actual, i}
Here, Usage _{expected, i} is the expected energy usage after removing the influence of the weather, and Usage _{actual, i} is the actual energy usage measured by the meter 5204. In some embodiments, the weather normalization module 5208 calculates a percentage change between actual usage and expected usage, as shown in the following equation:

Here, Usage _{actual, i} and Usage _{expected, i} are time series values at time step i, respectively.

ここで、

は、時間ステップｉにおける予測エネルギー使用量（すなわち、Ｕｓａｇｅ_{ｅｘｐｅｃｔｅｄ，ｉ}）であり、Ｙ_ｉは、時間ステップｉにおける実際のエネルギー使用量（すなわち、Ｕｓａｇｅ_{ａｃｔｕａｌ，ｉ}）であり、

は、時系列Ｙの平均である。 In some embodiments, the weather normalization module 5208 determines a mean square error coefficient of variation (CVRME) based on actual and expected energy usage values. CVRME is a measure of performance between actual and expected energy usage values. Assuming there is a time series of n values for each time series, the weather normalization module 5208 can calculate CVRME as follows.

here,

Is the predicted energy usage at time step i (ie Usage _{expected, i} ), Y _i is the actual energy usage at time step i (ie Usage _{actual, i} ),

Is the average of time series Y.

  Referring now to FIG. 53, a flow diagram of a process 5300 for normalizing energy consumption data to remove weather effects according to an exemplary embodiment is shown. Process 5300 may be performed by weather normalization module 5208 by normalizing energy consumption data for an installation, building, or other space to remove weather effects on energy consumption values.

ここで、

は、正規化されたＣＤＤ値（ＣＤＤ／日）であり、ＣＤＤは、その月のある日に関する１日のＣＤＤ値である。 Process 5300 is shown to include calculating normalized CDD, HDD, and energy consumption for each time interval in the baseline period (step 5302). In some embodiments, the baseline period is the previous year and each time interval in the baseline period is one month of the previous year. However, in various other embodiments, it is contemplated that the baseline period and time interval can have any duration. In some embodiments, the normalized CDD, HDD, and energy consumption values are average CDD, HDD, and energy consumption values per time interval. For example, the normalized CDD value for a month is obtained by dividing the total CDD for that month (ie, the sum of the daily CDD values for that month) by the number of days in that month, as shown in the following equation: Can be calculated.

here,

Is the normalized CDD value (CDD / day), where CDD is the daily CDD value for a day of the month.

ここで、

は、正規化されたＨＤＤ値（ＨＤＤ／日）であり、ＨＤＤは、その月のある日に関する１日のＨＤＤ値である。 Similarly, the normalized HDD value for a month is the total HDD for that month (ie, the sum of the daily HDD values for that month) divided by the number of days in that month, as shown in the following equation: Can be calculated by:

here,

Is a normalized HDD value (HDD / day), where HDD is the 1-day HDD value for a certain day of the month.

ここで、

は、正規化されたエネルギー消費量値（ｋＷｈ／日）であり、Ｕｓａｇｅは、その月のある日に関する１日のエネルギー消費量である。正規化された値

をそれぞれ、ベースライン期間（例えば前年）における時間間隔（例えば各月）毎に計算して、ベースライン期間に関する値（例えば、１ヶ月の値）の時系列を生成することができる。 The normalized energy consumption for a month can be calculated by dividing the total energy consumption for that month by the number of days in that month, as shown in the following equation.

here,

Is the normalized energy consumption value (kWh / day), and Usage is the daily energy consumption for a given day of the month. Normalized value

Can be calculated for each time interval (eg, each month) in the baseline period (eg, previous year) to generate a time series of values related to the baseline period (eg, one month value).

ここで、ｂ_０、ｂ_１、およびｂ_２の値は、

に関する値の時系列に回帰（例えば、加重最小二乗）を適用することによって決定される。ステップ５３０４において生成することができるエネルギー消費量モデルの一例が図５４に示されている。 Still referring to FIG. 53, process 5300 is shown to include generating an energy consumption model (step 5304) using the baseline CDD, HDD, and energy consumption values. In some embodiments, the energy consumption model has the following form:

Where the values of b ₀ , b ₁ , and b ₂ are

Determined by applying regression (eg, weighted least squares) to the time series of values for. An example of an energy consumption model that can be generated in step 5304 is shown in FIG.

（ｙ軸）に対する、正規化されたＣＤＤ値

（ｘ軸）の時系列を描いている。単純にするために、正規化された

値は省かれている。グラフ５４００での各ポイント５４０２は、正規化されたＣＤＤ値と対応する正規化されたエネルギー消費量値との対を表す。行５４０４は、変数

の関係を表す。以下の式を使用して、図５４に示される単純化されたモデルを表すことができる。

ここで、ｂ_０およびｂ_１の値は、

に関する値の時系列に回帰（例えば、加重最小二乗）を適用することによって決定される。例えば、回帰は、ｂ_０＝２０．１ｋＷｈ／日、およびｂ_１＝２００．１ＣＤＤ／日の値を生成することがあり、その結果、以下のような単純化されたモデルが得られる。

Referring to FIG. 54, a graph 5400 of time series values according to an exemplary embodiment is shown. Graph 5400 shows the corresponding energy consumption value

Normalized CDD value for (y-axis)

The time series of (x axis) is drawn. Normalized for simplicity

The value is omitted. Each point 5402 in graph 5400 represents a pair of a normalized CDD value and a corresponding normalized energy consumption value. Line 5404 shows the variable

Represents the relationship. The following equation can be used to represent the simplified model shown in FIG.

Where the values of b ₀ and b ₁ are

Determined by applying regression (eg, weighted least squares) to the time series of values for. For example, regression may produce values of b ₀ = 20.1 kWh / day and b ₁ = 200.1 CDD / day, resulting in a simplified model as follows:

  Referring again to FIG. 53, the process 5300 includes estimating a normalized energy consumption for the current period by applying the current CDD and HDD values to the energy consumption model (step 5306). Is shown in In some embodiments, the current period is the current month. The current CDD and HDD values can be received from the weather service 5202 or calculated by the weather normalization module 5208 based on current weather conditions, as described with reference to FIG. In some embodiments, the current CDD and HDD values are normalized CDD and HDD values for the current month, which can be calculated as described with reference to step 5302.

である場合、単純化されたモデルは以下のように解くことができる。

Step 5306 may include using the current CDD and HDD values as inputs to the energy consumption model and determining a solution for the energy consumption value. For example, if the current CDD value is

Then the simplified model can be solved as follows:

を３１倍して、当月に関する予想エネルギー消費量を決定することができる。以下の式は、ステップ５３０６で計算された正規化されたエネルギー消費量値を使用してステップ５３０８で実施される計算の一例を示す。

Process 5300 is shown to include multiplying the normalized energy consumption estimate by the duration of the current period to determine a total expected energy consumption during the current period (step 5308). For example, if the current period has a duration of 31 days, normalized energy consumption

Can be multiplied by 31 to determine the expected energy consumption for the current month. The following equation shows an example of the calculation performed at step 5308 using the normalized energy consumption value calculated at step 5306.

Process 5300 is shown to include generating energy consumption statistics (step 5310) based on expected and actual energy consumption during the current period. The expected energy consumption may be the value Usage _expected calculated at step 5308. The actual energy consumption may be the value Usage _current, which is measured by meter 5204, received from local storage 514 or host storage 516, obtained from a utility (eg, utility bill), or current It can be observed during the period.

The energy consumption statistic is, for example, the difference between the expected normalized energy usage Usage _exploited and the actual energy usage Usage _current or the delta (e.g., ΔUsage), the percentage of the actual usage Usage _current and the expected usage Usage _expected. CVRME based on changes, actual energy usage values and expected energy usage values, or other statistics derived from actual energy usage Usage _current and expected energy usage Usage _expected . These and other energy consumption statistics can be calculated by the weather normalization module 5208 as described above. The process 5300 may be repeated periodically (eg, monthly) to calculate energy consumption statistics for each period (eg, each month) when that period becomes the current period.

In some embodiments, the number of data points used to generate the energy consumption model is at least twice the number of parameters in the model. For example, for an energy consumption model with three parameters b ₀ , b ₁ , and b ₂ , a minimum of 6 data points (eg, 6 months of historical data) can be used to train the model. . In some embodiments, one year of data is used to train an energy consumption model. If less than one year of historical data is used, the weather normalization module 5208 may flag the resulting energy consumption model as potentially unreliable. Once the full year of data has been collected, the weather normalization module 5208 can remove the flag to indicate that the energy consumption model is no longer unreliable.

  In some embodiments, the weather normalization module 5208 trains the energy consumption model using up to 3 years of historical data. By using data for up to 3 years, the effects of abnormal years can be minimized, but the likelihood that the baseline model will change (unsteadiness) is reduced. In some embodiments, the weather normalization module 5208 recalculates the energy consumption model at the beginning of each month with all available data up to 3 years and not exceeding 3 years. In addition to automatically updating the energy consumption model periodically, a user-defined trigger can be used to force a recalculation of the baseline model. User-defined triggers are manual triggers that allow you to update the model when a known change occurs in the building (for example, adding a new zone, extending operating time, etc.) (for example, an option to update the model) The user selects).

  In some embodiments, historical data collected before the user-defined trigger is excluded when re-learning the energy consumption model in response to the user-defined trigger. Alternatively, user-defined triggers may require the user to specify a date to be used as a threshold, and before this threshold, all historical data is excluded when the model is relearned. If the user does not specify a date, the weather normalization module 5208 may use all available data by default. If the user specifies the current date, the weather normalization module 5208 may determine a predetermined amount of time (eg, 6 months) before re-learning the energy consumption model to ensure that sufficient data is collected. ) May wait. The predetermined amount of time may be the minimum amount of time required to collect the minimum number of data points (eg, twice the number of parameters in the model) required to ensure model reliability. During the waiting period, the weather normalization module 5208 may display a message indicating that an estimate cannot be generated until the waiting period ends.

  Referring again to FIG. 52, the analysis service 524 is shown to include an energy benchmarking module 5210. The energy benchmarking module 5210 can be configured to compare the energy consumption of a given building or facility with benchmark energy consumption values for similar types of buildings. The energy benchmarking module 5210 may also compare the energy consumption of a given building or facility to a typical building of similar types of baselines at different geographic locations.

  In some embodiments, the energy benchmarking module 5210 receives historical meter data. The historical meter data can include historical values for measurable resource consumption, including power consumption (kWh), water consumption (gallons), and natural gas consumption (mmBTU). Historical meter data can be received as time series data from local storage 514 or host storage 516, collected from meter 5204 over time, or received from an energy utility (eg, as part of utility bills). . In some embodiments, the historical meter data includes historical meter data for more than one year. However, the historical meter data may include other time periods (eg, 6 months, 3 months, 1 month, etc.) in various other embodiments. The energy benchmarking module 5210 can also receive current meter data from the meter 5204.

）にわたって単位面積当たりのビルディングのエネルギー消費量を定量化する正規化された規準である。同様に、エネルギー密度は、所与の期間（例えば、

）にわたる単位面積当たりのビルディングのエネルギー消費量の変化を定量化する正規化された規準である。また、ＥＵＩおよびエネルギー密度は、水消費や天然ガス消費などの他の商品に関して計算することもできる。 The energy benchmarking module 5210 may receive building parameters from the parameter database 5206. Building parameters include building area (eg, square feet), building type (eg, one of the listed types), building location, and building benchmarks for applicable building type and / or location, etc. May include various characteristics or attributes of the building. Building benchmarks can include benchmark energy consumption values for buildings. The benchmark may be an ASHRAE benchmark for building in the United States or other local standard for building in another country. In some embodiments, the benchmark specifies energy use intensity (EUI) values and / or energy density values for the building. The EUI is a given period (eg,

) Is a normalized criterion that quantifies building energy consumption per unit area. Similarly, energy density is given for a given period (eg,

Normalized criteria to quantify changes in building energy consumption per unit area. EUI and energy density can also be calculated for other commodities such as water consumption and natural gas consumption.

  The energy benchmarking module 5210 may use the historical meter data and building parameters to calculate EUI values and / or energy density values for the building. In some embodiments, the energy benchmarking module 5210 calculates EUI values and / or energy density values over a period of one year. This may allow the EUI value and / or energy density value to be directly compared to the ASHRAE standard defined by year. However, EUI and / or energy density is calculated over any period (eg, 1 month, 1 week, 1 day, 1 hour, etc.) to allow comparison with other standards or benchmarks that use different periods. It is considered possible.

  In some embodiments, the energy benchmarking module 5210 collects energy consumption data, energy density values, and / or EUI values for all buildings in the portfolio and separates the buildings by building type. The energy benchmarking module 5210 can draw all buildings of a single type on a single plot with benchmarks for that building type at different geographic locations (eg, different cities). An example of a plot 5500 that can be generated by the energy benchmarking module 5210 is shown in FIG. Plot 5500 shows all the buildings in the customer's portfolio whose building type is “Office Building”. These buildings include buildings A, B, C, and D. Plot 5500 shows EUI values for buildings A, B, C, and D, respectively. Also, plot 5500 shows typical or benchmark EUI values for typical buildings of the same type (ie office building) in various geographic locations (eg, Houston, Miami, Chicago, San Francisco, Kansas City, Fairbanks, Phoenix). Indicates. The visualization shown in plot 5500 allows customers to compare their buildings with similar buildings in their city or other cities with similar weather patterns. Although only the EUI is shown, it should be understood that in various embodiments, the plot 5500 can include energy density in addition to or instead of the EUI.

  Referring again to FIG. 52, the analysis service 524 is shown to include a baseline comparison module 5212. Baseline comparison module 5212 may be configured to compare various time series with a baseline. For example, the baseline comparison module 5212 can compare energy consumption, energy demand, EUI, energy density, or other time series characterizing building energy performance. Baseline comparison module 5212 can compare time series with any granularity. For example, the baseline comparison module 5212 can collect, store, or summarize an entire facility, a specific building, space, room, area, meter (both physical and virtual meters), or time series data. Time series for any other level can be compared.

  Baseline comparison module 5212 can compare time series data for any product (eg, electricity, natural gas, water, etc.) and any duration (eg, 1 year, 1 month, 1 day, 1 hour, etc.). . In some embodiments, the energy benchmarking module 5210 receives historical meter data. The historical meter data can include historical values related to measurable resource consumption including, for example, power consumption (kWh), water consumption (gallons), and natural gas consumption (mmBTU). Historical meter data can be received as time series data from local storage 514 or host storage 516, collected from meter 5204 over time, or received from an energy utility (eg, as part of utility bills). . In some embodiments, the baseline comparison module 5212 may include an EUI value and / or an energy density value generated by the energy benchmarking module 5210, an energy usage statistic generated by the weather normalization module 5208, or a building or other Receive other time series characterizing the energy performance of the space. As described with reference to energy benchmarking module 5210, various EUI calculations and / or energy density calculations can be used to generate EUI values and / or energy density values for various time periods.

  Baseline comparison module 5212 can compare the timeline to various baselines. The baseline may be a threshold that can be generated in any of a variety of ways. For example, some baselines may be defined or set by the user. Some baselines can be calculated from historical data (eg, average consumption, average demand, average EUI, average energy density, etc.) and other building parameters. Some baselines can be set by standards such as ASHRAE 90.1 (eg, for building level criteria). Baseline comparison module 5212 may receive building parameters from parameter database 5206. Building parameters may include various characteristics or attributes of the building, such as building area (eg, square feet), building type (eg, one of the listed types), building location, and the like. Baseline comparison module 5212 can use the building parameters to identify an appropriate benchmark that can compare time series.

  The baseline comparison module 5212 can output the baseline and the result of the baseline comparison. The results are an indication of whether the time series samples are above or below the baseline, fault triggers and timestamps, or other results that can be derived from baseline comparisons (eg, conformance or non-conformance to standards, fault indications, etc. ) Can be included. For example, the baseline comparison module 5212 may apply a failure detection rule that defines a failure for the baseline. In some embodiments, a disorder is defined as a predetermined number of samples above or below the baseline. Baseline comparison module 5212 may compare each sample in time series with the baseline to determine, for each sample, whether the sample is above or below the baseline. The threshold number of samples meets the criteria for fault detection rules (eg, 3 consecutive samples are above the baseline, 5 out of 10 consecutive samples are above the baseline, etc.) If so, the baseline comparison module 5212 can generate a fault indication. Fault indications can be stored as time series data in local storage 514 or host storage 516, or can be provided to application 530, client device 448, and / or remote system and application 444.

  In some embodiments, the baseline comparison module 5212 generates a plot or graph showing the results of the baseline comparison. An example of a graph 5600 that can be generated by the baseline comparison module 5212 is shown in FIG. Graph 5600 depicts building energy consumption time series 5602 values relative to baseline 5604. For each sample in time series 5602, baseline comparison module 5212 may compare the value of the sample with baseline 5604. Any sample that exceeds the baseline 5604 (ie, sample 5606) can be automatically highlighted, colored, or otherwise marked in the graph 5600 by the baseline comparison module 5212. This allows the user to easily identify and distinguish samples 5606 that exceed the baseline 5604.

  Referring again to FIG. 52, the analysis service 524 is shown to include a night / day comparison module 5214. The night / day comparison module 5214 may be configured to compare the nighttime building energy load with the daytime building energy load. Night / day comparisons can be made for energy consumption, energy demand, EUI, energy density, or other time series characterizing building energy performance. In some embodiments, the night / day comparison module 5214 calculates a ratio of minimum night load to peak day load and compares the calculated ratio to a threshold (eg, 0.5). If this ratio deviates from the threshold by a predetermined amount (eg, exceeds 1.2 times the threshold ratio), the night / day comparison module 5214 can generate a fault indication that indicates a high night load.

  In some embodiments, the night / day comparison module 5214 receives historical meter data. The historical meter data can include historical values related to measurable resource consumption including, for example, power consumption (kWh), water consumption (gallons), and natural gas consumption (mmBTU). Historical meter data can be received as time series data from local storage 514 or host storage 516, collected from meter 5204 over time, or received from an energy utility (eg, as part of utility bills). . In some embodiments, the historical meter data includes historical meter data for more than one year. However, the historical meter data may include other time periods (eg, 6 months, 3 months, 1 month, etc.) in various other embodiments. Night / day comparison module 5214 may also receive current meter data from meter 5204.

  In some embodiments, night / day comparison module 5214 receives time series data from local storage 514 and / or host storage 516. The time series data can include one or more time series of energy consumption, energy demand, EUI, energy density, or other time series characterizing the energy performance of the building. In some embodiments, the night / day comparison module 5214 receives a building schedule as input. The night / day comparison module 5214 uses the building schedule to convert the time series into a night part (eg, a time series sample with a night time stamp) and a day part (eg, a time series with a day time stamp). Sample). In some embodiments, the building schedule is an occupancy schedule. In other embodiments, the building schedule defines the sunrise and sunset times at the building's geographic location. The night / day comparison module 5214 can receive a building schedule as input or can automatically generate a building schedule. For example, the night / day comparison module 5214 can automatically determine the sunrise and sunset times for the building based on the date and the geographic location of the building (eg, zip code, latitude and longitude, etc.). .

ここで、Ｑ_ｍｉｎは夜間時間中の最小負荷、Ｑ_ｍａｘは日中時間中の最大負荷である。夜／昼比較モジュール５２１４は、時系列のサンプルを使用して、時系列毎に負荷比Ｑ_{ｒａｔｉｏ}を計算することができる。夜／昼比較モジュール５２１４は、各時系列の１日毎にＱ_{ｒａｔｉｏ}の値を生成することができる。いくつかの実施形態では、夜／昼比較モジュール５２１４は、Ｑ_{ｒａｔｉｏ}の１日の値を、新たな時系列としてローカル記憶装置５１４および／またはホスト記憶装置５１６に記憶する。新たな時系列の各要素は、特定の日に対応することがあり、その日に関するＱ_{ｒａｔｉｏ}の計算値を含むことがある。 The night / day comparison module 5214 can calculate the load ratio Q _ratio for one or more time series using the time series data. In some embodiments, the load ratio Q _ratio is a minimum load during night time (eg, the minimum of a time series sample designated as a night time sample) and a maximum load during day time (eg, day time). It is the ratio to the maximum value of the time-series samples specified as samples. For example, the night / day comparison module 5214 can calculate the load ratio for a given time series using the following equation:

Here, Q _min is the minimum load during night time, and Q _max is the maximum load during daytime. The night / day comparison module 5214 can calculate the load ratio Q _ratio for each time series using the time series samples. The night / day comparison module 5214 can generate a value of Q _ratio for each day of each time series. In some embodiments, the night / day comparison module 5214 stores the Q _ratio daily value in the local storage 514 and / or the host storage 516 as a new time series. Each element of the new time series may correspond to a particular day and may include a calculated value of Q _ratio for that day.

  Night / day comparison module 5214 may receive threshold parameters from parameter database 5206. The threshold parameter may be a threshold ratio between night load and day load. In some embodiments, the threshold ratio has a value of about T = 0.5. However, in various other embodiments, it is contemplated that the threshold ratio can have any value. The threshold ratio value can be defined / updated by the user, automatically calculated based on the history of previous night loads and day loads, or determined by the night / day comparison module 5214.

The night / day comparison module 5214 may compare the calculated load ratio Q _ratio with a threshold T (or some function of the threshold T). In some embodiments, the night / day comparison module 5214 determines whether the calculated load ratio Q _ratio exceeds a threshold T by a predetermined amount (eg, 20%). For example, the night / day comparison module 5214 can evaluate the following inequality to determine whether the calculated load ratio Q _ratio exceeds the threshold T by a predetermined amount θ.
Q _ratio ≧ θ * T
Here, the parameter θ indicates the amount or percentage that the ratio Q _ratio must exceed the threshold T in order to be recognized as a fault. For example, the value of theta = _{1.2, when Q ratio} has exceeded the threshold T 20% or higher, indicating that the ratio _{Q ratio} is recognized as failure.

The night / day comparison module 5214 can output the load ratio time series and the result of the threshold comparison. The result is an indication that the calculated load ratio Q _ratio is above or below the threshold T (or a function of the threshold T), fault trigger and timestamp, or other results that can be derived from a threshold comparison (eg, standard Compliance or non-conformity, fault indication, etc.). For example, the night / day comparison module 5214 may apply a fault detection rule that defines a fault associated with the threshold T. In some embodiments, the fault is defined as a predetermined number of samples of Q _ratio that satisfy the inequality Q _ratio ≧ θ * T. Fault indications can be stored as time series data in local storage 514 or host storage 516, or can be provided to application 530, client device 448, and / or remote system and application 444.

  In some embodiments, the night / day comparison module 5214 generates a plot or graph showing the results of the threshold comparison. An example of a graph 5700 that can be generated by the night / day comparison module 5214 is shown in FIG. Graph 5700 depicts a time series 5702 of building energy consumption over three days. For each day (eg, Day 1, Day 2, Day 3), night / day comparison module 5214 may identify all samples in time series 5702 that have time stamps for that day. The night / day comparison module 5214 can also classify each sample in the time series 5702 as either a nighttime sample or a daytime sample based on when the sample was recorded. Samples acquired during night time may be classified as night samples, and samples acquired during day time may be classified as day samples.

さらに、以下の不等式で示されるように、計算された比を閾値Ｔ（または閾値Ｔの関数）と比較することができる。
Ｑ_{ｒａｔｉｏ}≧θ＊Ｔ
ある日に関する比Ｑ_{ｒａｔｉｏ}が上記不等式を満たす場合、夜／昼比較モジュール５２１４は、グラフ５７００で、その日に関するサンプルを自動的にハイライト、色付け、または他の方法でマークすることができる。例えば、２日目に関するサンプル５７０４は、赤色にされることがあり、２日目に関する比Ｑ_{ｒａｔｉｏ}が閾値Ｔを量θ（例えば２０％）だけ超えていることが示される。 Every day, the night / day comparison module 5214 may identify the minimum of the nighttime sample for the day (ie, Q _min ) and the maximum value of the daytime sample for the day (ie, Q _max ). The night / day comparison module 5214 may calculate the daily ratio Q _ratio using the following equation:

Furthermore, the calculated ratio can be compared with a threshold T (or a function of threshold T), as shown by the following inequality.
Q _ratio ≧ θ * T
If the ratio Q _{ratio for a} day satisfies the above inequality, the night / day comparison module 5214 may automatically highlight, color, or otherwise mark the sample for that day in graph 5700. For example, the sample 5704 for the second day may be red, indicating that the ratio Q _ratio for the second day exceeds the threshold T by an amount θ (eg, 20%).

  Referring again to FIG. 52, the analysis service 524 is shown to include a weekend / weekday comparison module 5216. The weekend / weekday comparison module 5216 may be configured to compare weekend building energy loads with weekday building energy loads. Weekend / weekday comparisons can be made for energy consumption, energy demand, EUI, energy density, or other time series characterizing building energy performance. In some embodiments, the weekend / weekday comparison module 5216 calculates the ratio of weekend load to weekday load and compares the calculated ratio to a threshold (eg, 0.5). If this ratio deviates from the threshold by a predetermined amount (eg, exceeds 1.2 times the threshold ratio), the weekend / weekday comparison module 5216 may generate a fault indication that indicates high weekend load.

  In some embodiments, weekend / weekday comparison module 5216 receives historical meter data. The historical meter data can include historical values related to measurable resource consumption including, for example, power consumption (kWh), water consumption (gallons), and natural gas consumption (mmBTU). Historical meter data can be received as time series data from local storage 514 or host storage 516, collected from meter 5204 over time, or received from an energy utility (eg, as part of utility bills). . In some embodiments, the historical meter data includes historical meter data for more than one year. However, the historical meter data may include other time periods (eg, 6 months, 3 months, 1 month, etc.) in various other embodiments. Weekend / weekday comparison module 5216 may also receive current meter data from meter 5204. In some embodiments, weekend / weekday comparison module 5216 receives time series data from local storage 514 and / or host storage 516. The time series data can include one or more time series of energy consumption, energy demand, EUI, energy density, or other time series characterizing the energy performance of the building.

ここで、Ｑ_{ｗｅｅｋｅｎｄ}は週末中の平均負荷、Ｑ_{ｗｅｅｋｄａｙ}は平日中の平均負荷である。週末／平日比較モジュール５２１６は、時系列のサンプルを使用して、時系列毎に負荷比Ｑ_{ｒａｔｉｏ}を計算することができる。週末／平日比較モジュール５２１６は、各時系列の１週間毎のＱ_{ｒａｔｉｏ}の値を生成することができる。いくつかの実施形態では、週末／平日比較モジュール５２１６は、Ｑ_{ｒａｔｉｏ}の１日の値を、新たな時系列としてローカル記憶装置５１４および／またはホスト記憶装置５１６に記憶する。新たな時系列の各要素は、特定の曜日に対応することがあり、その曜日に関するＱ_{ｒａｔｉｏ}の計算値を含むことがある。 The weekend / weekday comparison module 5216 may use the time series data to calculate a load ratio Q _ratio for one or more time series. In some embodiments, the load ratio Q _ratio is the average load over the weekend (eg, the average of time series samples designated as weekend samples) and the average load during the weekday (eg, when designated as weekday samples). It is the ratio to the average of the series samples). For example, the weekend / weekday comparison module 5216 may calculate the load ratio for a given time series using the following formula:

Here, Q _weekend is the average load during the weekend, and Q _weekday is the average load during the _weekday . The weekend / weekday comparison module 5216 can calculate the load ratio Q _ratio for each time series using the time series samples. The weekend / weekday comparison module 5216 can generate a value of Q _ratio for each week of each time series. In some embodiments, the weekend / weekday comparison module 5216 stores the Q _ratio daily values in the local storage 514 and / or the host storage 516 as a new time series. Each element of the new time series may correspond to a particular day of the week and may include a calculated value of Q _ratio for that day of the week.

  Weekend / weekday comparison module 5216 may receive threshold parameters from parameter database 5206. The threshold parameter may be a threshold ratio between weekend load and weekday load. In some embodiments, the threshold ratio has a value of about T = 0.5. However, in various other embodiments, it is contemplated that the threshold ratio can have any value. The threshold ratio value may be defined / updated by the user, automatically calculated based on previous weekend load and weekday load history, or determined by the weekend / weekday comparison module 5216.

The weekend / weekday comparison module 5216 may compare the calculated load ratio Q _ratio with a threshold T (or some function of the threshold T). In some embodiments, the weekend / weekday comparison module 5216 determines whether the calculated load ratio Q _ratio exceeds a threshold T by a predetermined amount (eg, 20%). For example, the weekend / weekday comparison module 5216 can evaluate the following inequality to determine whether the calculated load ratio Q _ratio exceeds the threshold T by a predetermined amount θ.
Q _ratio ≧ θ * T
Here, the parameter θ indicates the amount or percentage that the ratio Q _ratio must exceed the threshold T in order to be recognized as a fault. For example, the value of theta = _{1.2, when Q ratio} has exceeded the threshold T 20% or higher, indicating that the ratio _{Q ratio} is recognized as failure.

The weekend / weekday comparison module 5216 can output the load ratio time series and the result of the threshold comparison. The result is an indication that the calculated load ratio Q _ratio is above or below the threshold T (or a function of the threshold T), fault trigger and timestamp, or other results that can be derived from a threshold comparison (eg, standard Compliance or non-conformity, fault indication, etc.). For example, weekend / weekday comparison module 5216 may apply a fault detection rule that defines a fault associated with threshold T. In some embodiments, the fault is defined as a predetermined number of samples of Q _ratio that satisfy the inequality Q _ratio ≧ θ * T. Fault indications can be stored as time series data in local storage 514 or host storage 516, or can be provided to application 530, client device 448, and / or remote system and application 444.

  In some embodiments, weekend / weekday comparison module 5216 generates a plot or graph showing the results of the threshold comparison. An example of a graph 5800 that can be generated by the weekend / weekday comparison module 5216 is shown in FIG. Graph 5800 depicts a time series 5802 of building energy consumption over a week. Every week, the weekend / weekday comparison module 5216 may identify all samples in the time series 5802 having time stamps for that week. The weekend / weekday comparison module 5216 may also classify each sample of the time series 5802 as either a weekend sample or a weekday sample based on when the sample was recorded. Samples acquired on weekends (ie, Saturday and Sunday) may be classified as weekend samples, and samples acquired on weekdays (ie, Monday-Friday) may be classified as weekday samples.

さらに、以下の不等式で示されるように、計算された比を閾値Ｔ（または閾値Ｔの関数）と比較することができる。
Ｑ_{ｒａｔｉｏ}≧θ＊Ｔ
ある日に関する比Ｑ_{ｒａｔｉｏ}が上記不等式を満たす場合、週末／平日比較モジュール５２１６は、グラフ５８００で、その週に関する週末サンプルを自動的にハイライト、色付け、または他の方法でマークすることができる。例えば、週末に関するサンプル５８０４は、赤色にされることがあり、比Ｑ_{ｒａｔｉｏ}が閾値Ｔを量θ（例えば２０％）だけ超えていることが示される。 For each week, the weekend / weekday comparison module 5216 may calculate the average of the weekday samples for the week (ie, Q _weekday ) and the average of the weekend samples for the week (ie, Q _weekend ). . The weekend / weekday comparison module 5216 may calculate the weekly ratio Q _ratio using the following formula:

Furthermore, the calculated ratio can be compared with a threshold T (or a function of threshold T), as shown by the following inequality.
Q _ratio ≧ θ * T
If the ratio Q _{ratio for a} day satisfies the above inequality, the weekend / weekday comparison module 5216 may automatically highlight, color, or otherwise mark the weekend sample for that week in graph 5800. For example, the sample 5804 for the weekend may be red, indicating that the ratio Q _ratio exceeds the threshold T by an amount θ (eg, 20%).

Ad hoc dashboard

  59-87, several user interfaces that can be generated by the building management system 500 according to an exemplary embodiment are shown. In some embodiments, the user interface may be an energy management application 532, a monitoring and reporting application 534, an enterprise control application 536, or other application 530 that uses optimized time series data generated by the data platform service 520. Generated by. For example, the user interface can be generated by a building energy management system that includes an instance of the energy management application 532. An example of such a building energy management system is Johnson Controls Inc. By METASYS® Energy Management System (MEMS). The building energy management system is a cloud that communicates with the building management system 500 as part of the building management system 500 (eg, one of the applications 530) or via a communication network 446 (eg, Internet, LAN, cellular network, etc.). It can be implemented as a base application (eg, one of a remote system and application 444).

  In some embodiments, the user interface is a component of the ad hoc dashboard 5900. The ad hoc dashboard 5900 may be displayed when the user clicks the ad hoc tab 5902 shown in FIG. The ad hoc dashboard 5900 can be customizable to allow a user to create and configure various types of widgets. The widget may be configured to visually present time series data from the local storage 514 or the host storage 516 and other types of information. For example, the ad hoc dashboard 5900 can be customized to include charting widgets, data visualization widgets, display widgets, date and time widgets, weather information widgets, and various other types of widgets. Some examples of user interfaces for creating and configuring widgets are described in detail below.

Creating a widget

  Referring now to FIGS. 60-61, a user interface 6000 for creating a widget is shown in accordance with an illustrative embodiment. The user interface 6000 may be displayed as a pop-up when the user clicks a “create widget” button 5904 on the ad hoc dashboard 5900. Interface 6000 may allow a user to enter a widget name 6002 (“Widget 1”) and select the type of widget to create. In some embodiments, the user selects a widget type by selecting an option presented via one of the drop-down menus 6004-6012.

  By selecting the data visualization drop-down menu 6004, a list of data visualization widgets that can be created can be displayed. In some embodiments, the data visualization widget includes a heat map widget, a radial gauge widget, a histogram widget, and an air diagram widget. A list of chart creation widgets that can be created can be displayed, which is good for selecting a chart creation drop-down menu 6006. In some embodiments, the chart widget includes a line graph widget, an area graph widget, a column graph widget, a bar graph widget, a stacked graph widget, and a pie graph widget. By selecting a date / time drop-down menu 6008, a list of date / time widgets that can be created can be displayed. In some embodiments, the date and time widget includes a date display widget, a digital clock widget, and an analog clock widget. By selecting a display drop-down menu 6010, a list of display widgets that can be created can be displayed. In some embodiments, display widgets include a data point widget, a data grid widget, a text box widget, and an image widget. By selecting a weather drop-down menu 6012, a list of weather widgets that can be created can be displayed. In some embodiments, the weather widget includes a current weather information widget and a weather forecast widget.

  The user can select a widget through one of the drop-down menus 6004-6012 and then click the save button 6014 to create an empty widget of the selected type. An example of an empty widget 6102 that can be created is shown in FIG. The empty widget 6102 may include a widget name 6002 and text 6104 indicating that no data is currently associated with the empty widget 6102. An empty widget 6102 can be associated with one or more time series via the widget configuration interface 6200.

Widget configuration

  Referring now to FIGS. 62-63, a widget configuration interface 6200 is shown according to an exemplary embodiment. The widget configuration interface 6200 allows a user to associate an empty widget 6102 with one or more time series or other types of data. For example, a point from the meter tree 6204 can be dragged and dropped onto an empty widget 6102 to associate the corresponding time series data with the empty widget 6102. Although only the meter tree 6204 is shown, points can be dragged and dropped from other types of trees, such as a device tree. When a point is dragged and dropped onto the empty widget 6102, a chart of time series data associated with the selected point may begin to aggregate. The empty widget 6102 can also be configured by selecting the option button 6202 and selecting “Widget Configuration” from the drop-down menu 6206. The drop down menu 6206 may also include an option for deleting or duplicating the selected widget. Widget replication may include any point mapped to the widget, as well as a widget size and theme replication.

  FIG. 63 shows a widget configuration pop-up 6300 that may be displayed in response to a user selecting a widget configuration option via a drop-down menu 6206. The widget configuration pop-up 6300 is an example of a configuration interface for a line graph widget. A line graph widget can be created by selecting the widget creation button 5904 on the ad hoc dashboard 5900 and selecting a line graph from the chart creation drop-down menu 6006. If the user drags and drops any point from the meter tree 6204, a line graph 6302 with a single line may appear. Line graph 6302 may depict a time series sample associated with the selected point. The x-axis of the line graph 6302 may be a unit of time, and the y-axis of the line graph 6302 may be a unit of measurement (UOM) (eg, kWh, kW, etc.) of the selected point. An axis label 6304 having a time series UOM may be displayed along the y-axis.

  If a second point with a different UOM is added to the line graph 6302 (eg, by dragging and dropping the second point), the line graph 6302 is automatically updated to relate to the second point. May include a second line depicting a time series sample. A different UOM may be displayed along the y-axis of the line graph 6302 on the opposite side (eg, the right side) of the first point UOM. An axis label 6306 with a second point UOM may be displayed along the y-axis of the line graph 6302. Any number of points can be added to the line graph 6302 regardless of whether the points have the same UOM or different UOMs.

  In some embodiments, time series with different units of measurement may be displayed in different colors in line graph 6302, and time series with the same units of measurement are in the same color but with different line types (eg, solid lines). , A broken line, etc.). Axis labels 6304, 6304, and 6308 along the y-axis of line graph 6302, and numeric values may have the same color as the time series plotted in the corresponding UOM. For example, the axis label 6304 and the corresponding numerical value along the left side of the line graph 6302 may be blue with any line (eg, kWh, energy) presenting data in that UOM. Axis labels 6306 and corresponding numerical values along the right side of line graph 6302 may be green with any line (eg, kW, energy) presenting data in that UOM. Different colors may be used for each axis label and time series associated with different UOMs.

  In some embodiments, the widget configuration pop-up 6300 displays a list 6310 of points mapped to the widget. Each point in the point list 6310 may identify a point name, the user edits the name of the mapped point, deletes one or more of the mapped points, and a fractional value for the mapped point value It may be possible to define the position and make other edits to the mapped points. The widget configuration pop-up 6300 may also allow the user to edit the widget title. A preview of chart 6302 may be displayed in widget configuration pop-up 6300, allowing the user to see changes in real time without closing widget configuration pop-up 6300.

  After the widget is created, the user can click save button 6208 to save the widget to ad hoc dashboard 5900. In some embodiments, different ad hoc dashboards 5900 can be created for each level of building space, meters, and equipment. A widget stored in a particular ad hoc dashboard 5900 may be displayed when the dashboard 5900 is refreshed (eg, by refreshing a web page on which the ad hoc dashboard 5900 is displayed).

Data aggregation widget

  Referring now to FIGS. 64-66, a data aggregation interface 6400 is shown according to an exemplary embodiment. The data aggregation interface 6400 allows a user to view time series data associated with specific data points having different granularities. For example, the interface 6400 is shown to include an energy consumption widget 6402 that displays time series data associated with an energy consumption time series. Depending on the time frame selected by the time frame selector 6410, different data aggregation options 6406 may be displayed. For example, if one year is selected via the time frame selector 6410, the data aggregation option 6406 may include one hour, one day, one week, and one month (default). If 6 months is selected via the time frame selector 6410, the data aggregation option 6406 may include 1 hour, 1 day, 1 week, and 1 month (default). If 3 months are selected via the time frame selector 6410, the data aggregation option 6406 may include 1 hour, 1 day, 1 week, and 1 month (default). If one month is selected via the time frame selector 6410, the data aggregation option 6406 may include one hour, one day (default), and one week. If a week is selected by the time frame selector 6410, the data aggregation option 6406 may include 15 minutes, 1 hour, and 1 day (default). Default values may be highlighted.

  Different data aggregation options 6406 may be displayed over a custom time period. For example, if a custom period of less than one week is selected by the time frame selector 6410, the data aggregation option 6406 may include 15 minutes, 1 hour, and 1 day. If a custom time period between one week and one month is selected by the time frame selector 6410, the data aggregation option 6406 may include 15 minutes, 1 hour, 1 day, and 1 week. If a custom period of one month or more is selected by the time frame selector 6410, the data aggregation option 6406 may include one hour, one day, one week, and one month.

  In some embodiments, the widget 6402 is automatically updated to display time series data associated with the selected aggregation option. For example, the widget 6402 may display an hourly data rollup timeline for that point if the hourly data aggregation option is selected via the aggregation option 6406. However, the widget 6402 may display a weekly data rollup timeline for that point when the weekly data aggregation option is selected via the aggregation option 6406. The x-axis of chart 6408 may be updated based on the selected data aggregation option. For example, the widget 6402 may include a chart 6408 having an x-axis scaled to a daily energy consumption value when the daily aggregation option is selected (shown in FIG. 64). However, the widget 6402 may include a chart 6602 having an x-axis scaled to a weekly energy consumption value when the weekly aggregation option is selected (shown in FIG. 66). In some embodiments, the widget 6402 includes a chart 6502 with the x-axis scaled to one data aggregation option (eg, one week), and the data presented in the chart 6502 is from a more granular time series. Can be used. For example, FIG. 65 shows a chart 6502 in which the x-axis is scaled to one week intervals and displays hourly values of energy consumption.

Heat map widget

  Referring now to FIGS. 67-69, an interface 6700 for creating and configuring a heat map widget 6702 is shown in accordance with an illustrative embodiment. The heat map widget 6702 can be created by selecting the widget creation button 5904 on the ad hoc dashboard 5900 and selecting a heat map from the data visualization drop-down menu 6004. If the user drags and drops any meter point from the meter tree 6204, a heat map 6706 may appear. In some embodiments, when the user drags and drops the second meter point from the meter tree 6204, the heat map 6706 is automatically overwritten. The interface 6700 may display a message indicating that the point mapping has been added or changed when the heat map 6706 is updated with the second meter point.

  The heat map 6706 may present time series data as a plurality of cells 6710. Each cell 6710 may correspond to one sample of the corresponding time series. For example, the heat map 6706 is shown to display hourly values of the energy consumption time series. Each row of the heat map 6706 corresponds to a particular day, and each column of the heat map 6706 corresponds to one hour of that day. A cell 6710 located at the intersection of a row and a column represents the hourly value of the energy consumption time series. In some embodiments, the hourly energy consumption value (or any other type of data presented via the heat map 6707) is indicated by the color or other attribute of the cell 6710. For example, the cell 6710 may have different colors that represent different energy consumption values. A key 6708 indicates a color representing a different numerical value of the energy consumption time series. As new time-series samples are collected, new cells 6710 may be added to the heat map 6706. Hovering over any of the cells 6710 may display the sample timestamp associated with the cell, the point name, and / or the numerical value of the sample associated with the cell.

  In some embodiments, the heat map widget 6702 includes an option button 6712. Selecting option button 6712 may display a widget configuration pop-up 6800 (shown in FIG. 68). The widget configuration pop-up 6800 allows the user to edit the widget title 6802, delete the mapped point, edit the name of the mapped point, define a decimal place for the value of the mapped point, heat map 6706 It may be possible to edit the minimum and maximum values of the color range for and to select a color palette for the heat map 6706. In some embodiments, widget configuration pop-up 6800 includes a preview of heat map 6706. The heat map widget 6702 may automatically update the heat map 6706 based on the selected time interval and custom filter. For example, selecting a time interval of one week may result in a heat map 6706 that includes hourly values for each hour of the selected week (shown in FIG. 67). However, when a time interval of one year is selected, a heat map 6902 that includes daily energy consumption values (eg, one hour, one day, etc.) for that year may be obtained.

Text box widget

  Referring now to FIGS. 70-71, an interface 7000 for creating and configuring a text box widget 7002 is shown in accordance with an illustrative embodiment. The text box widget 7002 can be created by selecting the widget creation button 5904 on the ad hoc dashboard 5900 and selecting a text box from the display drop-down menu 6010. Clicking anywhere in the text box widget 7002 displays a menu 7004 for adding or editing text. The user can change the font, size, color, or other attributes of the text via menu 7004. By clicking outside the text box widget 7002, the menu 7004 can be hidden. The text box widget 7002 can be moved, resized, duplicated, and deleted by selecting various options presented via the interface 7000.

Image widget

  Referring now to FIGS. 72-73, an interface 7200 for creating and configuring an image widget 7202 is shown in accordance with an illustrative embodiment. The image widget 7202 can be created by selecting the widget creation button 5904 on the ad hoc dashboard 5900 and selecting an image from the display drop-down menu 6010. The image widget 7202 may be blank when initially created, or may display text instructing the user how to upload the image 7204 to the widget 7202. Image 7204 can be selected via widget configuration pop-up 7300. The widget configuration pop-up 7300 may allow the user to edit the widget title 7302 and select an image via the image selector 7304. The selected image 7204 may occupy the entire area of the image widget 7202.

Date and time widget

  Referring now to FIGS. 74-78, an interface 7400 for creating and configuring a date and time widget is shown in accordance with an illustrative embodiment. Date and time widgets can include a date widget 7402 (shown in FIG. 74), a digital clock widget 7602 (shown in FIG. 76), and an analog clock widget 7702 (shown in FIG. 77). The date widget 7402 can be created by selecting the widget creation button 5904 in the ad hoc dashboard 5900 and selecting a date display from the date and time drop-down menu 6008. The date widget 7402 may include graphics or text 7404 that indicates the current date, day of the week, month, year, or other date information. The date widget 7402 can be edited via a widget configuration pop-up 7500 that allows the user to edit the widget title 7502, time zone 7504, and other information associated with the date widget 7402.

  The digital clock widget 7602 can be created by selecting the widget creation button 5904 in the ad hoc dashboard 5900 and selecting a digital clock from the date and time drop-down menu 6008. Similarly, the analog clock widget 7702 can be created by selecting the widget creation button 5904 in the ad hoc dashboard 5900 and selecting an analog clock from the date and time drop-down menu 6008. The digital clock widget 7602 may include a digital clock 7604 and the analog clock widget 7702 may include an analog clock 7704. Clock widgets 7602 and 7702 can be edited via widget configuration pop-up 7800, which allows the user to display widget title 7802, time zone 7804, and other information related to clock widgets 7602 and 7702. Make it editable.

Weather widget

  79-81, an interface 7900 for creating and configuring a weather widget is shown according to an exemplary embodiment. Weather widgets may include a current weather widget 7902 (shown in FIG. 79) and a weather forecast widget 8002 (shown in FIG. 80). The current weather widget 7902 can be created by selecting the widget creation button 5904 on the ad hoc dashboard 5900 and selecting the current weather from the weather drop-down menu 6012. The current weather widget 7902 may include graphics or text that indicates the geographic location 7904 and the current weather 7906 at the geographic location 7904.

  The weather forecast widget 8002 can be created by selecting the widget creation button 5904 on the ad hoc dashboard 5900 and selecting a weather forecast from the weather drop-down menu 6012. The weather forecast widget 8002 may include graphics or text that shows a forecast of the geographic location 8004, current weather 8006 at the geographic location 8004, and future weather 8008 at the geographic location 8004. Weather widgets 7902 and 8002 can be edited by a widget configuration pop-up 8100 that allows the user to edit widget title 8102, location 8104, date range 8106, and other information associated with weather widgets 7902 and 8002.

Dashboard sharing

  82-83, a dashboard sharing interface 8300 is shown according to an exemplary embodiment. In response to selection of share icon 8202 on ad hoc dashboard 5900, share interface 8300 may be displayed. Once the ad hoc dashboard 5900 is created, the sharing interface 8300 can be used to share an instance of the ad hoc dashboard 5900 with other users or groups. The sharing interface 8300 is shown to include a user tab 8310 and a group tab 8312. By selecting a user tab 8310, a list 8302 of users present in the system can be displayed along with a title 8304 and an email address 8306. Similarly, by selecting the group tab 8312, a list of groups existing in the system (eg, administrator, building owner, service technician, etc.) can be displayed. The sharing interface 8300 may allow one or more users or groups to be selected. The ad hoc dashboard 5900 can then be shared with the selected user or group by clicking on the share button 8314.

  In some embodiments, the sharing interface 8300 automatically checks whether a user or group is authorized to view the ad hoc dashboard 5900. This check may be performed prior to aggregating the list of users 8302 and groups, or in response to a user or group selection. For example, in some embodiments, only authorized users may be shown in the user list 8302. In other embodiments, all users and groups may be displayed in the shared interface 8300, but a warning message may be provided if an unauthorized user or group is selected. When the ad hoc dashboard 5900 is shared, another tab may be added to the interface provided to users sharing the ad hoc dashboard 5900. The user can select a new tab to display a shared instance of the ad hoc dashboard 5900.

Stacked graph widget

  Referring now to FIGS. 84-85, an interface 8400 for creating and configuring a stacked graph widget 8402 is shown in accordance with an illustrative embodiment. The stacked graph widget 8402 can be created by selecting the widget creation button 5904 in the ad hoc dashboard 5900 and selecting a stacked graph from the chart creation drop-down menu 6006. As points are dragged and dropped into the stacked graph widget 8402, a stacked graph 8404 of time series data related to the selected point may begin to aggregate. Any number of points can be added to the stacked graph widget 8402 as long as the points have the same unit of measure. In some embodiments, the interface 8400 is configured to display a notification that only points with the same unit of measurement are allowed when the user attempts to add a point with a different unit of measurement.

  Stacked graph 8404 is shown to include a set of columns 8412. Each column 8412 may correspond to a particular time and may be associated with one or more samples having a corresponding time stamp. If multiple points are added to the stacked graph 8404, each column 8412 may be divided into multiple portions. For example, each row 8412 is shown to include a first portion 8406, a second portion 8408, and a third portion 8410. Portions 8406-8410 may each correspond to a different time series or different points. Corresponding time series values may be represented by the size or height of each portion 8406-8410. In other embodiments, the stacked graph 8404 may include horizontal bars rather than vertical columns 8412. A key or legend 8414 may indicate the name of the point associated with each portion 8406-8410. In some embodiments, the point name is displayed in the format “meter / device name-point name”.

  In some embodiments, interface 8400 is configured to display a tooltip when the user hovers the pointer over any portion 8406-8410 of column 8412. The tooltip may display various attributes of meters, samples, or time series associated with the part. For example, by placing a pointer over the portion 8406, the tooltip will have a timestamp associated with the column 8412 where the portion 8406 is located, the name of the meter associated with the portion 8406 (eg, Meter1-kWh), the time associated with the portion 8406. The series value (for example, 134 kWh) and the ratio (for example, 13%) occupied by the portion 8406 in the total column 8412 can be displayed. For example, if the total energy consumption for a particular column 8412 (ie, the sum of portions 8406-8410) is 1000 kWh and the portion 8406 has a value of 130 kWh, then 130 kWh is 13% of the total 1000 kWh, so the tooltip A percentage of 13% may be displayed.

  Stacked graph widget 8402 can be edited via widget configuration pop-up 8500. The widget configuration pop-up 8500 allows the user to edit the widget title 8502, edit the name of the mapped point 8504, delete the mapped point 8504, define decimal places for the mapped point 8504, and roll up It may be possible to make other adjustments to the configuration of the graph widget 8402. In some embodiments, widget configuration pop-up 8500 includes a preview of stacked graph 8404. The preview of the stacked graph 8404 is automatically updated in real time as changes are made via the widget configuration pop-up 8500 to allow the user to view the effect of the changes before applying the changes to the stacked graph 8404. can do. The stacked graph widget 8402 may include options for resizing, maximizing, duplicating, deleting, moving, adjusting the theme, or editing the stacked graph widget 8402. In some embodiments, the stacked graph widget 8402 includes a data aggregation option (as described with reference to FIGS. 64-66) and a unit conversion option to support weather service points.

Pie chart widget

  With reference now to FIGS. 86-87, an interface 8600 for creating and configuring a pie chart widget 8602 is shown in accordance with an illustrative embodiment. Pie chart widget 8602 can be created by selecting widget creation button 5904 on ad hoc dashboard 5900 and selecting a pie chart from chart creation drop-down menu 6006. When a point is dragged and dropped onto the pie chart widget 8602, the pie chart 8604 of time series data associated with the selected point may start to be aggregated. Any number of points can be added to the pie chart widget 8602 as long as the points have the same unit of measure. In some embodiments, the interface 8600 is configured to display a notification that only points with the same unit of measurement are allowed when the user attempts to add a point with a different unit of measurement.

  When a plurality of points are added to the pie chart 8604, the pie chart 8604 may be divided into a plurality of parts. For example, the pie chart 8604 is shown to include a first portion 8606, a second portion 8608, and a third portion 8610. Each portion 8606-8610 may correspond to a different time series or different points. Corresponding time series values may be represented by the size or arc length of each portion 8606-8610. Key or legend 8614 may indicate the name of the point associated with each portion 8606-8610. In some embodiments, the point name is displayed in the format “meter / device name-point name”.

  In some embodiments, the interface 8600 is configured to display a tooltip when the user places the pointer over any portion 8606-8610 of the pie chart 8604. The tooltip may display various attributes of meters, samples, or time series associated with the part. For example, by placing a pointer over portion 8606, the tooltip is composed of the name of the meter associated with portion 8606 (eg, Meter1-kWh), the time series value associated with portion 8606 (eg, 134 kWh), and portion 8606. The ratio (for example, 13%) of the total circle graph 8604 to be displayed can be displayed. For example, if the total energy consumption represented by the pie chart 8604 (ie, the sum of the portions 8606-8610) is 1000 kWh and the portion 8606 has a value of 130 kWh, then 130 kWh is 13% of the total 1000 kWh. The chip may display a percentage of 13%.

  Pie chart widget 8602 can be edited via widget configuration pop-up 8700. The widget configuration pop-up 8700 allows the user to edit the widget title 8702, edit the name of the mapped point 8704, delete the mapped point 8704, define the decimal place for the mapped point 8704, and circle It may be possible to make other adjustments to the configuration of the graph widget 8602. In some embodiments, widget configuration pop-up 8700 includes a preview of pie chart 8604. The preview of the pie chart 8604 is automatically updated in real time as changes are made via the widget configuration pop-up 8700 to allow the user to view the effect of the changes before applying the changes to the pie chart 8604. can do. Pie chart widget 8602 may include options for resizing, maximizing, duplicating, deleting, moving, adjusting the theme, or editing pie chart widget 8602.

Stagnation point detection

  Referring now to FIG. 88, a point configuration interface 8800 is shown according to an exemplary embodiment. The interface 8800 may be a component of the data source setup interface 4000 as described with reference to FIGS. In some embodiments, the point configuration interface 8800 is displayed when the user selects the data source tile 3604 and the data point 4304 in the setup interface 4000. The point configuration interface 8800 allows the user to change various attributes 4302 of the data point 4304 such as unit, minimum value, maximum value, and point name.

  In some embodiments, the point configuration interface 8800 allows a user to define a stagnation point definition for the selected point 4304. The stagnation point definition can be treated as a failure detection rule that can be evaluated by the analysis service 524. For example, the point configuration interface 8800 is shown to include a detected stagnation point check box 8802. When the check box 8802 is selected, the analysis service 524 can begin monitoring the selected point 4304. Interface 8800 may allow a user to select a time period associated with a stagnation point definition. For example, the point configuration interface 8800 is shown to include a duration box 8804, which defines a time threshold amount (eg, 1 hour, 2 days, etc.) for the user to use in the stagnation point definition. It can be so.

  The analysis service 524 may monitor the value of the selected point 4304 and may determine whether the value is the same over an amount of time that exceeds the time threshold amount specified via the period box 8804. . If the value of the point has not changed over the amount of time that exceeds the threshold, the analysis service 524 may determine that the point is stagnant and generate a stagnant point failure indication 8902 (shown in FIG. 89). . The analysis service 524 can display a stagnation point fault indication 8902 in the pending fault window 8900 along with other fault indications.

Configuration of an exemplary embodiment

  The configurations and arrangements of the systems and methods as shown in the various exemplary embodiments are merely exemplary. Although only a few embodiments are described in detail in this disclosure, many variations are possible (e.g., various element sizes, dimensions, structures, shapes and widths, parameter values, mounting arrangements, Material use, color, orientation, etc.). For example, the position of the elements may be reversed or otherwise changed, and the nature or number or position of the individual elements may be changed or changed. Accordingly, all such modifications are intended to be included within the scope of this disclosure. The order or sequence of any process or method steps may be changed or rearranged according to alternative embodiments. Other substitutions, modifications, changes, and omissions may be made in the design, operating conditions, and arrangement of the exemplary embodiments without departing from the scope of this disclosure.

  The present disclosure contemplates methods, systems, and program products on any machine-readable medium for accomplishing various operations. Embodiments of the present disclosure may be implemented using an existing computer processor, implemented by a dedicated computer processor for this or another suitable system incorporated for this purpose, or implemented by a wired system. May be. Embodiments within the scope of this disclosure include a program product comprising a machine-readable medium for carrying or storing machine-executable instructions or data structures. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media includes RAM, ROM, EPROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage or other magnetic storage device, or any other medium. Such media can be used to carry or store the desired program code in the form of machine-executable instructions or data structures, and in addition, a general purpose or special purpose computer, or other equipped with a processor Can be accessed by machine. Thus, any such connection is properly referred to as a machine readable medium. Combinations of the above media are also included within the scope of machine-readable media. Machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.

  Although the drawings show a particular order of method steps, the order of steps may differ from that shown. Two or more steps may be performed in parallel or partially in parallel. Such variations depend on the software and hardware system selected and the choice of the designer. All such variations are within the scope of this disclosure. Similarly, software implementation can be accomplished by standard programming techniques with rule-based logic and other logic to accomplish various connection steps, processing steps, comparison steps, and decision steps.

Claims (20)

A building energy management system,
Building equipment operable to monitor and control one or more variables in the building energy management system and to provide data samples of the one or more variables;
A data collector configured to collect the data samples from the building equipment and generate a data time series including a plurality of the data samples;
An analysis service configured to perform one or more analyzes using the data time series and to generate a result time series including a plurality of result samples indicating the results of the analysis;
A time series database configured to store the data time series and the result time series;
Building energy management comprising: an energy management application configured to retrieve the data time series and the result time series from the time series database in response to a request for time series data associated with the one or more variables system. The building energy management system of claim 1, wherein the analysis service comprises a weather normalization module configured to generate the result time series by removing weather effects from the data time series. The weather normalization module is
Generating a regression model defining a relationship between the data samples of the data time series and one or more weather-related variables;
Determining a value of the one or more weather-related variables during a time associated with the data time series;
Applying the value of the one or more weather-related variables as an input to the regression model to estimate a weather normalized value of the data sample;
The building energy management system of claim 2, configured to exclude the weather effects from the data time series by storing the weather normalized values of the data samples as the result time series. The one or more weather related variables include at least one of a cooling degree day (CDD) variable and a heating degree day (HDD) variable;
The building energy management system according to claim 3, wherein the regression model is an energy consumption model that defines energy consumption as a function of at least one of the CDD variable and the HDD variable. The weather normalization module is
Calculating a value for at least one of a cooling degree day (CDD) variable and a heating degree day (HDD) variable for each day during the baseline period using meteorological data for the baseline period;
Determining at least one of a daily average value of the CDD variable for each time interval within the baseline period and a daily average value of the HDD variable for each time interval within the baseline period;
Using the energy consumption data for the baseline period to determine a daily average energy consumption value for each time interval within the baseline period;
Generating a regression coefficient for the regression model by applying the daily average energy consumption to at least one of the daily average value of the CDD variable and the daily average value of the HDD variable, 4. The building energy management system of claim 3, configured to generate a model. The data time series is a resource consumption time series,
The sample of the data time series includes at least one of a power consumption value, a water consumption value, and a natural gas consumption value;
The analysis service comprises an energy benchmarking module configured to use the data time series to calculate an energy usage criterion for a building associated with the data time series;
The building energy management system of claim 1, wherein the energy usage criteria includes at least one of energy usage intensity (EUI) or energy density. The energy benchmarking module is:
Identifying the total area of the building associated with the data time series;
Determining a total resource consumption of the building over a period associated with the data time series based on the samples of the data time series;
Using the total area of the building and the total resource consumption of the building to calculate the resource consumption per unit area of the building and calculating the EUI for the building The building energy management system of claim 6. The energy benchmarking module is:
Identifying the type of building associated with the data time series;
And generating a plot including a graphical representation of the energy usage criteria for the building and one or more benchmark energy usage criteria for other buildings of the identified type. Building energy management system. The analysis service is
Using the samples of the data time series to calculate a daily night / day load ratio associated with the data time series;
Comparing each of the calculated night / day load ratios with a threshold load ratio;
Generating daily result samples associated with the data time series, each indicating whether the night / day load ratio for the corresponding day exceeds the threshold load ratio;
The building energy management system of claim 1, comprising a night / day comparison module configured to store a plurality of the result samples as the result time series. The analysis service is
Using the samples of the data time series to calculate a weekly weekend / weekday load ratio associated with the data time series;
Comparing each of the calculated weekend / weekday load ratios with a threshold load ratio;
Generating weekly result samples associated with the data time series, each indicating whether the weekend / weekday load ratio for the corresponding week exceeds the threshold load ratio;
The building energy management system of claim 1, comprising a weekend / weekday comparison module configured to store a plurality of the result samples as the result time series. A building energy management system,
Building equipment operable to monitor and control a variable of the building energy management system and configured to provide a raw data sample of data points associated with the variable;
A data collector configured to collect the raw data samples from the building equipment and generate a raw data time series including a plurality of the raw data samples;
One or more data platform services configured to generate one or more optimized data time series from the raw data time series;
A time series database configured to store a plurality of time series data associated with the data points, wherein the plurality of time series are the raw data time series and the one or more optimized data times; A time series database, including series,
An energy management application configured to generate an ad hoc dashboard including a widget and associate the widget with the data point, wherein the widget is the plurality of time-series graphic visualizations associated with the data point. And an energy management application comprising an interactive user interface option for switching between the plurality of time series associated with the data point. The data platform service is:
Automatically generating a data roll-up time series including a plurality of aggregated data samples by aggregating the raw data samples when the raw data samples are collected from the building equipment;
12. The building energy management system of claim 11, comprising a sample aggregator configured to store the data rollup time series in the time series database as one of the optimized data time series. The data platform service is:
Creating virtual data points that represent unmeasured variables;
Calculating data values for a plurality of samples of the virtual data point as a function of the raw data samples;
Generating a virtual point time series including the plurality of samples of the virtual data points;
12. The building energy management system of claim 11, comprising a virtual point calculator configured to store the virtual point time series in the time series database as one of the optimized data time series. The data platform service is:
Performing one or more analyzes using the raw data time series;
Generating a result time series comprising a plurality of result samples indicating the results of the analysis;
12. The building energy management system of claim 11, comprising an analysis service configured to store the result time series in the time series database as one of the optimized data time series. The ad hoc dashboard includes a widget creation interface that includes a plurality of selectable widget types;
Each of the widget types corresponds to a different type of widget that the ad hoc dashboard is configured to create,
The widget type is
Chart creation widget,
Data visualization widget,
Display widget,
The building energy management system of claim 11, comprising at least one of a date and time widget and a weather information widget. The widget is a charting widget configured to display the plurality of time series charts associated with the data points;
The chart is
Line graph,
Area chart,
Column chart,
bar graph,
The building energy management system of claim 11, comprising at least one of a stacked graph and a pie chart. The time series database is configured to store a plurality of time series associated with a plurality of different data points;
The ad hoc dashboard is configured to associate the widget with each of the plurality of time series associated with the plurality of different data points;
The building energy management system of claim 11, wherein the widget is configured to display a graphical visualization of each of the plurality of time series associated with the widget. The widget is
Determining a unit of measure for each of the plurality of time series associated with the widget;
Generating a line graph including the plurality of lines respectively corresponding to the one or more time series associated with the widget;
Assigning a common color to each of the plurality of lines corresponding to a time series in the same measurement unit;
18. The building energy management system of claim 17, wherein the building energy management system is configured to assign a different color to each of the plurality of lines corresponding to a time series in different units of measurement. The widget is
Generating a heat map comprising a plurality of cells, each cell corresponding to a different sample of the data points associated with the widget;
Identifying numerical data values for each of the samples corresponding to the cells of the heat map;
12. The building energy management system of claim 11, wherein the building energy management system is configured to assign a color to each cell of the heat map based on the numerical data value of the corresponding sample. The ad hoc dashboard is
Displaying a point list including a plurality of points detected by the building energy management system;
Receiving user input to drag and drop one or more points from the point list to the widget;
12. The building of claim 11, wherein the building is configured to respond to the user input dragging and dropping the one or more points from the point list to the widget and associating the one or more points with the widget. Energy management system.

Images