BUILDING MANAGEMENT SYSTEM WITH SMART ENTITIES, TIMESERIES, NESTED STREAM GENERATION, CLOUD CONTROL,

AND ID MANAGEMENT AND ASSURANCE SERVICES

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of and priority to U.S. Provisional Patent Application No. 62/564,247 filed September 27, 2017, U.S. Provisional Patent Application No. 62/611,974 filed December 29, 2017, U.S. Provisional Patent Application No.

62/611,984 filed December 29, 2017, U.S. Provisional Patent Application No. 62/612,228 filed December 29, 2017, U.S. Provisional Patent Application No. 62/612,167 filed

December 29, 2017, and U.S. Provisional Patent Application No. 62/580,867 filed November 2, 2017. The entire disclosure of each of these patent applications is incorporated by reference herein.

BACKGROUND

[0002] The present disclosure relates generally to the field of a building management platform that is communicatively connected to one or more building management systems in a smart building environment. A building management system (BMS) is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. A BMS can include, for example, a HVAC system, a security system, a lighting system, a fire alerting system, any other system that is capable of managing building functions or devices, or any combination thereof.

[0003] A BMS can collect data from objects associated with a building, such as other BMSs, building subsystems, devices, sensors and other types of building equipment.

Building management platforms are utilized to register and manage the objects, gather and analyze data produced by the objects, and provide recommendations or results based on the collected data. As the number of buildings transitioning to a smart building environment increases, the amount of data being produced and collected has been increasing

exponentially. Accordingly, effective analysis of a plethora of collected data is desired. SUMMARY

Smart Entity

[0004] According to an aspect of an example embodiment, a building management cloud computing system for managing data relating to a plurality of objects associated with one or more buildings, the plurality of objects each representing a space, person, building subsystem, and/or device connected to one or more electronic communications networks, includes: one or more processors; and one or more computer-readable storage media communicably coupled to the one or more processors having instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to: generate a database of interconnected smart entities, the smart entities including object entities representing each of the plurality of objects and data entities representing data generated by the objects, the smart entities being interconnected by relational objects indicating relationships between the object entities and the data entities; receive data from a first object of the plurality of objects; determine a second object from a relational object for the first object based on the received data; and modify a data entity connected to an object entity of the second object within the database of smart entities based on the received data for the first object.

[0005] In an example embodiment, the first object may be a sensor and the second object may be a space within the building in which the sensor is located.

[0006] In an example embodiment, the sensor may be a temperature sensor and the data entity connected to the object entity representing the space may be configured to store an ambient temperature value of the space based on the received data from the temperature sensor.

[0007] In an example embodiment, the instructions may further cause the one or more processors to create a shadow entity to store historical values of the data entity connected to the object entity representing the space.

[0008] In an example embodiment, the instructions may further cause the one or more processors to calculate an average ambient temperature value from the historical values stored in the shadow entity. [0009] In an example embodiment, the instructions may further cause the one or more processors to calculate an abnormal ambient temperature value from the historical values stored in the shadow entity.

[0010] In an example embodiment, each of the object entities may include a static attribute to identify the object entity, a dynamic attribute to store a data point associated with the object entity that changes over time, and a behavioral attribute that defines an expected response of the object entity in response to an input.

[0011] In an example embodiment, the data entity connected to the object entity of the second object may be configured to store the dynamic attribute of the object entity.

[0012] In an example embodiment, a relational object may semantically define the connection between the data entity and the object entity of the second object.

[0013] In an example embodiment, the modifying of the data entity connected to the object entity of the second object may include: identifying a dynamic attribute in the data that is associated with the object entity of the second object; determining a relational object connecting the data entity to the object entity of the second object; and storing a value of the data corresponding to the dynamic attribute in the data entity.

[0014] In an example embodiment, the first object may be an access control device and the second object may be a person associated with the building in which the access control device is located.

[0015] In an example embodiment, the data entity connected to the object entity representing the person may be configured to store a location attribute of the person based on the received data from the access control device.

[0016] In an example embodiment, the instructions may further cause the one or more processors to create a shadow entity to store historical values of the received data from the access control device, and to calculate an average arrival time of the person from the historical values stored in the shadow entity.

[0017] According to an aspect of an example embodiment, a method for managing data relating to a plurality objects associated with one or more buildings, the plurality of objects each representing a space, person, building subsystem, and/or device connected to one or more electronic communications networks, includes: generating, by one or more processors, a database of interconnected smart entities, the smart entities including object entities representing each of the plurality of objects and data entities representing data generated by the objects, the smart entities being interconnected by relational objects indicating

relationships between the object entities and the data entities; receiving, by the one or more processors, data from a first object of the plurality of objects; determining, by the one or more processors, a second object from a relational object for the first object based on the received data; and modifying, by the one or more processors, a data entity connected to an object entity of the second object within the database of smart entities based on the received data for the first object.

[0018] In an example embodiment, the first object may be a sensor and the second object may be a space within the building in which the sensor is located.

[0019] In an example embodiment, the sensor may be a temperature sensor and the data entity connected to the object entity representing the space may be configured to store an ambient temperature value of the space based on the received data from the temperature sensor.

[0020] In an example embodiment, the method may further include creating, by the one or more processors, a shadow entity to store historical values of the data entity connected to the object entity representing the space.

[0021] In an example embodiment, the method may further include calculating, by the one or more processors, an average ambient temperature value from the historical values stored in the shadow entity.

[0022] In an example embodiment, the method may further include calculating, by the one or more processors, an abnormal ambient temperature value from the historical values stored in the shadow entity.

[0023] In an example embodiment, each of the object entities may include a static attribute to identify the object entity, a dynamic attribute to store a data point associated with the object entity that changes over time, and a behavioral attribute that defines an expected response of the object entity in response to an input. [0024] In an example embodiment, the data entity connected to the object entity of the second object may be configured to store the dynamic attribute of the object entity.

[0025] In an example embodiment, a relational object may semantically define the connection between the data entity and the object entity of the second object.

[0026] In an example embodiment, the modifying of the data entity connected to the object entity of the second object may include: identifying, by the one or more processors, a dynamic attribute in the data that is associated with the object entity of the second object; determining, by the one or more processors, a relational object connecting the data entity to the object entity of the second object; and storing, by the one or more processors, a value of the data corresponding to the dynamic attribute in the data entity.

[0027] In an example embodiment, the first object may be an access control device and the second object may be a person associated with the building in which the access control device is located.

[0028] In an example embodiment, the data entity connected to the object entity representing the person may be configured to store a location attribute of the person based on the received data from the access control device.

[0029] In an example embodiment, the method may further include: creating, by the one or more processors, a shadow entity to store historical values of the received data from the access control device, and calculating, by the one or more processors, an average arrival time of the person from the historical values stored in the shadow entity.

[0030] According to an aspect of an example embodiment, a non-transient computer readable medium is provided that contains program instructions for causing a computer to perform the method of: generating a database of interconnected smart entities, the smart entities including object entities representing each of a plurality of objects associated with one or more buildings and the plurality of objects each representing a space, person, building subsystem, and/or device, and data entities representing data generated by the objects, the smart entities being interconnected by relational objects indicating relationships between the object entities and the data entities; receiving data from a first object of the plurality of objects; determining a second object from a relational object for the first object based on the received data; and modifying a data entity connected to an object entity of the second object within the database of smart entities based on the received data for the first object.

[0031] In an example embodiment, the first object may be a sensor and the second object may be a space within the building in which the sensor is located.

[0032] In an example embodiment, the sensor may be a temperature sensor and the data entity connected to the object entity representing the space may be configured to store an ambient temperature value of the space based on the received data from the temperature sensor.

[0033] In an example embodiment, the program instructions may further cause the one or more processors to perform operations including creating a shadow entity to store historical values of the data entity connected to the object entity representing the space.

[0034] In an example embodiment, the program instructions may further cause the one or more processors to perform operations including calculating an average ambient temperature value from the historical values stored in the shadow entity.

[0035] In an example embodiment, the program instructions may further cause the one or more processors to perform operations including calculating an abnormal ambient temperature value from the historical values stored in the shadow entity.

[0036] In an example embodiment, each of the object entities may include a static attribute to identify the object entity, a dynamic attribute to store a data point associated with the object entity that changes over time, and a behavioral attribute that defines an expected response of the object entity in response to an input.

[0037] In an example embodiment, the data entity connected to the object entity of the second object may be configured to store the dynamic attribute of the object entity.

[0038] In an example embodiment, a relational object may semantically define the connection between the data entity and the object entity of the second object.

[0039] In an example embodiment, the modifying of the data entity connected to the object entity of the second object may include: identifying a dynamic attribute in the data that is associated with the object entity of the second object; determining a relational object connecting the data entity to the object entity of the second object; and storing a value of the data corresponding to the dynamic attribute in the data entity.

[0040] In an example embodiment, the first object may be an access control device and the second object may be a person associated with the building in which the access control device is located.

[0041] In an example embodiment, the data entity connected to the object entity representing the person may be configured to store a location attribute of the person based on the received data from the access control device.

[0042] In an example embodiment, the program instructions may further cause the one or more processors to perform operations including creating a shadow entity to store historical values of the received data from the access control device, and calculating an average arrival time of the person from the historical values stored in the shadow entity.

[0043] Another implementation of the present disclosure is a building management cloud computing system for managing data relating to a plurality of objects associated with one or more buildings, the plurality of objects each representing a space, person, building subsystem, and/or device connected to one or more electronic communications networks. The system includes one or more processors and one or more computer-readable storage media communicably coupled to the one or more processors having instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to generate a database of interconnected smart entities. The smart entities include object entities representing each of the plurality objects and data entities representing data generated by the objects, the smart entities being interconnected by relational objects indicating relationships between the object entities and the data entities. The instructions cause the one or more processors to receive new data from a first object of the plurality of objects;

determine whether the database includes a first object entity representing the first object; in response to a determination that the database includes the first object entity, determine whether the database includes a first data entity representing data received from the first object; and in response to a determination that the database includes the first data entity, update an attribute of the first data entity using the new data received from the first object.

[0044] In an example embodiment, in response to a determination that the database does not include the first data entity, the instructions further cause the one or more processors to create the first data entity, create a first relational object defining a relationship between the first object entity and the first data entity, and create an attribute of the first data entity and generate a value for the attribute of the first data entity using the new data received from the first object.

[0045] In an example embodiment, in response to a determination that the database does not include the first object entity, the instructions further cause the one or more processors to create the first object entity, create the first data entity, create a first relational object defining a relationship between the first object entity and the first data entity, and create an attribute of the first data entity and generate a value for the attribute of the first data entity using the new data received from the first object.

[0046] In an example embodiment, determining whether the database includes the first object entity includes reading one or more static attributes of the object entities and determining whether any of the static attributes identify the first object.

[0047] In an example embodiment, determining whether the database includes the first data entity includes reading a relational attribute of the first object entity and determining whether the relational attribute identifies the first data entity.

[0048] In an example embodiment, determining whether the database includes the first data entity includes identifying a first relational object defining a relationship between the first data entity and one or more of the data entities and determining whether the first relational object identifies the first data entity.

[0049] In an example embodiment, the first data entity includes a static attribute identifying the first data entity and a dynamic attribute comprising one or more dynamic values of the first data entity. Updating the attribute of the first data entity may include updating the one or more dynamic values of the dynamic attribute using the new data received from the first object.

[0050] In an example embodiment, one or more of the object entities includes a static attribute to identify the object entity, a dynamic attribute to store a data point associated with the object entity that changes over time, and a behavioral attribute that defines an expected response of the object entity in response to an input. [0051] In an example embodiment, the first object may be a temperature sensor located in the building.

[0052] In an example embodiment, the instructions may further cause the one or more processors to create a shadow entity to store historical values of the first data entity using historical data received from the temperature sensor.

[0053] In an example embodiment, the instructions may further cause the one or more processors to calculate an average temperature value from the historical values stored in the shadow entity.

[0054] In an example embodiment, the instructions may further cause the one or more processors to calculate an abnormal temperature value from the historical values stored in the shadow entity.

[0055] In an example embodiment, the first object may be an access control device located in the building, and the first data entity may be related to an access key card object relating to a person object.

[0056] In an example embodiment, the instructions may further cause the one or more processors to update a location attribute of the person object according to the new data received from the access control device.

[0057] Another implementation of the present disclosure is a method for managing data relating to a plurality of objects associated with one or more buildings, the plurality of objects each representing a space, person, building subsystem, and/or device connected to one or more electronic communications networks. The method includes generating a database of interconnected smart entities. The smart entities include object entities representing each of the plurality of objects and data entities representing data generated by the objects, the smart entities being interconnected by relational objects indicating relationships between the object entities and the data entities. The method includes receiving new data from a first object of the plurality of objects; determining whether the database includes a first object entity representing the first object; in response to a determination that the database includes the first object entity, determining whether the database includes a first data entity representing data received from the first object; and in response to a determination that the database includes the first data entity, updating an attribute of the first data entity using the new data received from the first object.

[0058] In an example embodiment, in response to a determination that the database does not include the first data entity, the method comprises creating the first data entity, creating a first relational object defining a relationship between the first object entity and the first data entity, and creating an attribute of the first data entity and generating a value for the attribute of the first data entity using the new data received from the first object.

[0059] In an example embodiment, in response to a determination that the database does not include the first object entity, the method comprises creating the first object entity, creating the first data entity, creating a first relational object defining a relationship between the first object entity and the first data entity, and creating an attribute of the first data entity and generating a value for the attribute of the first data entity using the new data received from the first object.

[0060] In an example embodiment, determining whether the database includes the first object entity includes reading one or more static attributes of the object entities and determining whether any of the static attributes identify the first object.

[0061] In an example embodiment, determining whether the database includes the first data entity includes reading a relational attribute of the first object entity and determining whether the relational attribute identifies the first data entity.

[0062] In an example embodiment, determining whether the database includes the first data entity includes identifying a first relational object defining a relationship between the first data entity and one or more of the data entities and determining whether the first relational object identifies the first data entity.

[0063] In an example embodiment, the first data entity includes a static attribute identifying the first data entity and a dynamic attribute comprising one or more dynamic values of the first data entity. Updating the attribute of the first data entity may include updating the one or more dynamic values of the dynamic attribute using the new data received from the first object. [0064] In an example embodiment, one or more of the object entities includes a static attribute to identify the object entity, a dynamic attribute to store a data point associated with the object entity that changes over time, and a behavioral attribute that defines an expected response of the object entity in response to an input.

[0065] In an example embodiment, the first object may be a temperature sensor located in the building.

[0066] In an example embodiment, the method may further include creating a shadow entity to store historical values of the first data entity using historical data received from the temperature sensor.

[0067] In an example embodiment, the method may further include calculating an average temperature value from the historical values stored in the shadow entity.

[0068] In an example embodiment, the method may further include calculating an abnormal temperature value from the historical values stored in the shadow entity.

[0069] In an example embodiment, the first object may be an access control device located in the building, and the first data entity may be related to an access key card object relating to a person object.

[0070] In an example embodiment, the method may further include updating a location attribute of the person object according to the new data received from the access control device.

[0071] Another implementation of the present disclosure is one or more non-transitory computer readable media containing program instructions that, when executed by one or more processors, cause the one or more processors to perform operations including generating a database of interconnected smart entities. The smart entities include object entities representing each of a plurality of objects associated with one or more buildings and the plurality of objects each representing a space, person, building subsystem, and/or device, and data entities representing data generated by the objects, the smart entities being interconnected by relational objects indicating relationships between the object entities and the data entities. The operations include receiving new data from a first object of the plurality of objects; determining whether the database includes a first object entity representing the first object; in response to a determination that the database includes the first object entity, determining whether the database includes a first data entity representing data received from the first object; and in response to a determination that the database includes the first data entity, updating an attribute of the first data entity using the new data received from the first object.

[0072] In an example embodiment, in response to a determination that the database does not include the first data entity, the instructions further cause the one or more processors to create the first data entity, create a first relational object defining a relationship between the first object entity and the first data entity, and create an attribute of the first data entity and generate a value for the attribute of the first data entity using the new data received from the first object.

[0073] In an example embodiment, in response to a determination that the database does not include the first object entity, the instructions further cause the one or more processors to create the first object entity, create the first data entity, create a first relational object defining a relationship between the first object entity and the first data entity, and create an attribute of the first data entity and generate a value for the attribute of the first data entity using the new data received from the first object.

[0074] In an example embodiment, determining whether the database includes the first object entity includes reading one or more static attributes of the object entities and determining whether any of the static attributes identify the first object.

[0075] In an example embodiment, determining whether the database includes the first data entity includes reading a relational attribute of the first object entity and determining whether the relational attribute identifies the first data entity.

[0076] In an example embodiment, determining whether the database includes the first data entity includes identifying a first relational object defining a relationship between the first data entity and one or more of the data entities and determining whether the first relational object identifies the first data entity.

[0077] In an example embodiment, the first data entity includes a static attribute identifying the first data entity and a dynamic attribute comprising one or more dynamic values of the first data entity. Updating the attribute of the first data entity may include updating the one or more dynamic values of the dynamic attribute using the new data received from the first object.

[0078] In an example embodiment, one or more of the object entities includes a static attribute to identify the object entity, a dynamic attribute to store a data point associated with the object entity that changes over time, and a behavioral attribute that defines an expected response of the object entity in response to an input.

[0079] In an example embodiment, the first object may be a temperature sensor located in the building.

[0080] In an example embodiment, the instructions may further cause the one or more processors to create a shadow entity to store historical values of the first data entity using historical data received from the temperature sensor.

[0081] In an example embodiment, the instructions may further cause the one or more processors to calculate an average temperature value from the historical values stored in the shadow entity.

[0082] In an example embodiment, the instructions may further cause the one or more processors to calculate an abnormal temperature value from the historical values stored in the shadow entity.

[0083] In an example embodiment, the first object may be an access control device located in the building, and the first data entity may be related to an access key card object relating to a person object.

[0084] In an example embodiment, the instructions may further cause the one or more processors to update a location attribute of the person object according to the new data received from the access control device.

Smart Entity With Timeseries

[0085] One implementation of the present disclosure is a building management cloud computing system for managing timeseries data relating to a plurality of objects associated with one or more buildings. The plurality of objects each represent a space, a person, building subsystem, and/or device. The plurality of objects are connected to one or more electronic communications networks. The system includes one or more processors and one or more computer-readable storage media. The one or more processors are communicably coupled to a database of interconnected smart entities, the smart entities including object entities representing each of the plurality of objects and data entities representing stored data, the smart entities being interconnected by relational objects indicating relationships between the object entities and the data entities. The one or more computer-readable store media are communicably coupled to the one or more processors and have instructions stored thereon. When executed by the one or more processors, the instructions cause the one or more processors to receive first raw data from a first object of the plurality of objects. The first raw data includes one or more first data points generated by the first object. The instructions when executed cause the one or more processors to generate first input timeseries according to the one or more data points, identify a first object entity representing the first object from a first identifier in the first input timeseries, identify a first data entity from a first relational object indicating a relationship between the first object entity and the first data entity, and store the first input timeseries in the first data entity.

[0086] In some embodiments, the relational objects may semantically define the

relationships between the object entities and the data entities.

[0087] In some embodiments, one or more of the object entities may include a static attribute to identify the object entity, a dynamic attribute to store data associated with the object entity that changes over time, and a behavioral attribute that defines an expected response of the object entity in response to an input.

[0088] In some embodiments, the first input timeseries may correspond to the dynamic attribute of the first object entity.

[0089] In some embodiments, at least one of the first data points in the first input timeseries may be stored in the dynamic attribute of the first object entity.

[0090] In some embodiments, the input timeseries may include the first identifier, a timestamp indicating a generation time of the one or more first data points, and a value of the one or more first data points.

[0091] In some embodiments, the instructions may further cause the one or more processors to identify a second object entity representing a second object from a second relational object indicating a relationship between the first object entity and the second object entity, and identify a second data entity from a third relational object indicating a relationship between the second object entity and the second data entity. The second data entity may store second input timeseries corresponding to one or more second data points associated with the second object.

[0092] In some embodiments, the instructions may further cause the one or more processors to identify one or more processing workflows that defines one or more processing operations to generate derived timeseries using the first and second input timeseries, execute the one or more processing workflows to generate the derived timeseries, identify a third data entity from a fourth relational object indicating a relationship between the second object entity and the third data entity, and store the derived timeseries in the third data entity.

[0093] In some embodiments, the first object may be an access control device and the second object may be an access key card associated with a person.

[0094] In some embodiments, the derived timeseries may include one or more virtual data points calculated according to the first and second input timeseries.

[0095] In some embodiments, the one or more virtual data points may include one or more location attributes of the person.

[0096] In some embodiments, the first object may be a temperature sensor and the second object may be a variable air volume unit (VAV).

[0097] In some embodiments, the derived timeseries may include an abnormal temperature attribute corresponding to a space in which the temperature sensor is located and which the VAV is configured to serve.

[0098] In some embodiments, at least one of the first or second objects may be a temperature sensor.

[0099] In some embodiments, the instructions may further cause the one or more processors to periodically receive temperature measurements from the temperature sensor, and update at least the derived timeseries in the third data entity each time a new temperature measurement from the temperature sensor is received. [0100] In some embodiments, the derived timeseries may include an average ambient temperature of a space in which the temperature sensor is located.

[0101] In some embodiments, the instructions may further cause the one or more processors to create a shadow entity to store historical values of the first raw data.

[0102] In some embodiments, the instructions may further cause the one or more processors to calculate a virtual data point from the historical values, and create a fourth data entity to store the virtual data point.

[0103] Another implementation of the present disclosure is a method for managing timeseries data relating to a plurality of objects associated with one or more buildings. The plurality of objects each represent a space, person, building system, and/or device. The plurality of objects are connected to one or more electronic communications networks. The method includes receiving first raw data from a first object of the plurality of objects. The first raw data includes one or more first data points generated by the first object. The method includes generating first input timeseries according to the one or more data points, and accessing a database of interconnected smart entities. The smart entities include object entities representing each of the plurality of objects and data entities representing stored data, the smart entities being interconnected by relational objects indicating relationships between the object entities and the data entities. The method includes identifying a first object entity representing the first object from a first identifier in the first input timeseries, identifying a first data entity from a first relational object indicating a relationship between the first object entity and the first data entity, and storing the first input timeseries in the first data entity.

[0104] In some embodiments, the relational objects may semantically define the

relationships between the object entities and the data entities.

[0105] In some embodiments, one or more of the object entities may include a static attribute to identify the object entity, a dynamic attribute to store data associated with the object entity that changes over time, and a behavioral attribute that defines an expected response of the object entity in response to an input.

[0106] In some embodiments, the first input timeseries may correspond to the dynamic attribute of the first object entity. [0107] In some embodiments, at least one of the first data points in the first input timeseries may be stored in the dynamic attribute of the first object entity.

[0108] In some embodiments, the input timeseries may include the first identifier, a timestamp indicating a generation time of the one or more first data points, and a value of the one or more first data points.

[0109] In some embodiments, the method may further include identifying a second object entity representing a second object from a second relational object indicating a relationship between the first object entity and the second object entity, and identifying a second data entity from a third relational object indicating a relationship between the second object entity and the second data entity. The second data entity may store second input timeseries corresponding to one or more second data points associated with the second object.

[0110] In some embodiments, the method may further include identifying one or more processing workflows that defines one or more processing operations to generate derived timeseries using the first and second input timeseries, executing the one or more processing workflows to generate the derived timeseries, identifying a third data entity from a fourth relational object indicating a relationship between the second object entity and the third data entity, and storing the derived timeseries in the third data entity.

[0111] In some embodiments, the first object may be an access control device and the second object may be an access key card associated with a person.

[0112] In some embodiments, the derived timeseries may include one or more virtual data points calculated according to the first and second input timeseries.

[0113] In some embodiments, the one or more virtual data points may include one or more location attributes of the person.

[0114] In some embodiments, the first object may be a temperature sensor and the second object may be a variable air volume unit (VAV).

[0115] In some embodiments, the derived timeseries may include an abnormal temperature attribute corresponding to a space in which the temperature sensor is located and which the VAV is configured to serve. [0116] In some embodiments, at least one of the first or second objects may be a temperature sensor.

[0117] In some embodiments, the method may further include periodically receiving temperature measurements from the temperature sensor, and updating at least the derived timeseries in the third data entity each time a new temperature measurement from the temperature sensor is received.

[0118] In some embodiments, the derived timeseries may include an average ambient temperature of a space in which the temperature sensor is located.

[0119] In some embodiments, the method may further include creating a shadow entity to store historical values of the first raw data.

[0120] In some embodiments, the method may further include calculating a virtual data point from the historical values, and creating a fourth data entity to store the virtual data point.

[0121] Another implementation of the present disclosure is one or more non-transitory computer readable media containing program instructions. When executed by one or more processors, the instructions cause the one or more processors to perform operations including receiving first raw data from a first object of a plurality of objects associated with one or more buildings. The plurality of objects each represent a space, person, building subsystem, and/or device. The first raw data includes one or more first data points generated by the first object. The method includes generating first input timeseries according to the one or more data points, and accessing a database of interconnected smart entities. The smart entities include object entities representing each of the plurality of objects and data entities representing stored data, the smart entities being interconnected by relational objects indicating relationships between the object entities and the data entities. The method includes identifying a first object entity representing the first object from a first identifier in the first input timeseries, identifying a first data entity from a first relational object indicating a relationship between the first object entity and the first data entity, and storing the first input timeseries in the first data entity.

[0122] In some embodiments, the relational objects may semantically define the

relationships between the object entities and the data entities. [0123] In some embodiments, one or more of the object entities may include a static attribute to identify the object entity, a dynamic attribute to store data associated with the object entity that changes over time, and a behavioral attribute that defines an expected response of the object entity in response to an input.

[0124] In some embodiments, the first input timeseries may correspond to the dynamic attribute of the first object entity.

[0125] In some embodiments, at least one of the first data points in the first input timeseries may be stored in the dynamic attribute of the first object entity.

[0126] In some embodiments, the input timeseries may include the first identifier, a timestamp indicating a generation time of the one or more first data points, and a value of the one or more first data points.

[0127] In some embodiments, the instructions may further cause the one or more processors to identify a second object entity representing a second object from a second relational object indicating a relationship between the first object entity and the second object entity, and identify a second data entity from a third relational object indicating a relationship between the second object entity and the second data entity. The second data entity may store second input timeseries corresponding to one or more second data points associated with the second object.

[0128] In some embodiments, the program instructions may further cause the one or more processors to identify one or more processing workflows that defines one or more processing operations to generate derived timeseries using the first and second input timeseries, execute the one or more processing workflows to generate the derived timeseries, identify a third data entity from a fourth relational object indicating a relationship between the second object entity and the third data entity, and store the derived timeseries in the third data entity.

[0129] In some embodiments, the first object may be an access control device and the second object may be an access key card associated with a person.

[0130] In some embodiments, the derived timeseries may include one or more virtual data points calculated according to the first and second input timeseries. [0131] In some embodiments, the one or more virtual data points may include one or more location attributes of the person.

[0132] In some embodiments, the first object may be a temperature sensor and the second object may be a variable air volume unit (VAV).

[0133] In some embodiments, the derived timeseries may include an abnormal temperature attribute corresponding to a space in which the temperature sensor is located and which the VAV is configured to serve.

[0134] In some embodiments, at least one of the first or second objects may be a temperature sensor.

[0135] In some embodiments, the instructions may cause the one or more processors to periodically receive temperature measurements from the temperature sensor, and update at least the derived timeseries in the third data entity each time a new temperature measurement from the temperature sensor is received.

[0136] In some embodiments, the derived timeseries may include an average ambient temperature of a space in which the temperature sensor is located.

[0137] In some embodiments, the instructions may further cause the one or more processors to create a shadow entity to store historical values of the first raw data.

[0138] In some embodiments, the instructions may further cause the one or more processors to calculate a virtual data point from the historical values, and create a fourth data entity to store the virtual data point.

Nested Stream Generation

[0139] One implementation of the present disclosure is a building management system (BMS). The BMS includes building equipment, a data collector, a timeseries service, and a timeseries storage interface. The building equipment are configured to provide samples of one or more data points in the building management system. The data collector is configured to collect the samples from the building equipment and generate one or more input timeseries including a plurality of the samples. The timeseries service is configured to identify a first timeseries processing workflow that uses the input timeseries as an input and defines one or more processing operations to be applied to the samples of the input timeseries, perform the one or more processing operations defined by the first timeseries processing workflow to generate a first derived timeseries including a first set of derived timeseries samples, identify a second timeseries processing workflow that uses the first derived timeseries as an input and defines one or more processing operations to be applied to the samples of the first derived timeseries, and perform the one or more processing operations defined by the second timeseries processing workflow to generate a second derived timeseries including a second set of derived timeseries samples. The timeseries storage interface is configured to store the input timeseries and the first and second derived timeseries in a timeseries database.

[0140] In some embodiments, the building equipment include at least one of sensors, HVAC equipment lighting equipment, access control equipment, or security equipment.

[0141] In some embodiments, generating the first derived timeseries includes transforming one or more samples of the input timeseries into one or more samples of the first set of derived timeseries samples by applying the one or more samples of the input timeseries as an input to the first timeseries processing workflow and assembling the first set of derived timeseries samples to form the first derived timeseries.

[0142] In some embodiments, generating the second derived timeseries includes transforming one or more samples of the first set of derived timeseries samples into one or more samples of the second set of derived timeseries samples by applying the one or more samples of the first set of derived timeseries samples as an input to the second timeseries processing workflow and assembling the second set of derived timeseries samples to form the second derived timeseries.

[0143] In some embodiments, the timeseries service is configured to identify one or more other timeseries to be used as inputs to the first timeseries processing workflow and generate an enriched timeseries processing workflow comprising the first timeseries processing workflow, the input timeseries, and the one or more other timeseries.

[0144] In some embodiments, the BMS includes the timeseries database. The timeseries database can store a plurality of timeseries. In some embodiments, the timeseries service includes a timeseries identifier configured to identify the input timeseries or the first derived timeseries from the plurality of timeseries stored in the timeseries database. [0145] In some embodiments, the BMS includes a directed acyclic graph (DAG) database storing a plurality of D AGs, each of the DAGs defining a timeseries processing workflow. In some embodiments, the timeseries service includes a DAG identifier configured to determine whether any of the DAGs stored in the DAG database use the input timeseries or the first derived timeseries as an input.

[0146] In some embodiments, upon generating a derived timeseries, the timeseries service is configured to (a) determine whether the derived timeseries is used as an input to any of a plurality of stored timeseries processing workflows and (b) in response to a determination that the derived timeseries is used as an input to at least one of the stored timeseries processing workflows, perform one or more processing operations defined by the timeseries processing workflows that use the derived timeseries as an input to generate another derived timeseries.

[0147] In some embodiments, the timeseries service is configured to iteratively repeat steps (a) and (b) until the derived timeseries generated in step (b) is not used as an input to any of the plurality of stored timeseries processing workflows.

[0148] In some embodiments, the timeseries database includes at least one of a local timeseries database within the building management system or a hosted timeseries database at a remote location relative to the building management system.

[0149] In some embodiments, the input timeseries is a timeseries of measurements obtained from a sensor and at least one of the first derived timeseries or the second derived timeseries is an abnormal event timeseries that indicates whether each of the measurements is normal or abnormal.

[0150] In some embodiments, the input timeseries is a timeseries of building access events obtained from a physical access control device associated with a building space and at least one of the first derived timeseries or the second derived timeseries is an abnormal event timeseries that indicates whether each of the access events is normal or abnormal.

[0151] Another implementation of the present disclosure is building management system (BMS) for managing timeseries data provided by building equipment. The BMS includes one or more computer-readable storage media having instructions stored thereon. When executed by one or more processors, the instructions cause the one or more processors to collect samples of the timeseries data from the building equipment and generate one or more input timeseries including a plurality of the samples, identify a first timeseries processing workflow that uses the input timeseries as an input and defines one or more processing operations to be applied to the samples of the input timeseries, perform the one or more processing operations defined by the first timeseries processing workflow to generate a first derived timeseries including a first set of derived timeseries samples, identify a second timeseries processing workflow that uses the first derived timeseries as an input and defines one or more processing operations to be applied to the samples of the first derived timeseries, perform the one or more processing operations defined by the second timeseries processing workflow to generate a second derived timeseries including a second set of derived timeseries samples, and store the input timeseries and the first and second derived timeseries in a timeseries database.

[0152] In some embodiments, the building equipment include at least one of sensors, HVAC equipment lighting equipment, access control equipment, or security equipment.

[0153] In some embodiments, generating the first derived timeseries includes transforming one or more samples of the input timeseries into one or more samples of the first set of derived timeseries samples by applying the one or more samples of the input timeseries as an input to the first timeseries processing workflow and assembling the first set of derived timeseries samples to form the first derived timeseries.

[0154] In some embodiments, generating the second derived timeseries includes transforming one or more samples of the first set of derived timeseries samples into one or more samples of the second set of derived timeseries samples by applying the one or more samples of the first set of derived timeseries samples as an input to the second timeseries processing workflow and assembling the second set of derived timeseries samples to form the second derived timeseries.

[0155] In some embodiments, the instructions cause the one or more processors to identify one or more other timeseries to be used as inputs to the first timeseries processing workflow and generate an enriched timeseries processing workflow comprising the first timeseries processing workflow, the input timeseries, and the one or more other timeseries.

[0156] In some embodiments, the BMS includes the timeseries database. The timeseries database can store a plurality of timeseries. In some embodiments, the instructions cause the one or more processors to identify the input timeseries or the first derived timeseries from the plurality of timeseries stored in the timeseries database.

[0157] In some embodiments, the BMS includes a directed acyclic graph (DAG) database storing a plurality of D AGs, each of the DAGs defining a timeseries processing workflow. In some embodiments, the instructions cause the one or more processors to determine whether any of the DAGs stored in the DAG database use the input timeseries or the first derived timeseries as an input.

[0158] In some embodiments, upon generating a derived timeseries, the instructions cause the one or more processors to (a) determine whether the derived timeseries is used as an input to any of a plurality of stored timeseries processing workflows and (b) in response to a determination that the derived timeseries is used as an input to at least one of the stored timeseries processing workflows, perform one or more processing operations defined by the timeseries processing workflows that use the derived timeseries as an input to generate another derived timeseries.

[0159] In some embodiments, the instructions cause the one or more processors to iteratively repeat steps (a) and (b) until the derived timeseries generated in step (b) is not used as an input to any of the plurality of stored timeseries processing workflows.

[0160] In some embodiments, the timeseries database includes at least one of a local timeseries database within the building management system or a hosted timeseries database at a remote location relative to the building management system.

[0161] In some embodiments, the input timeseries is a timeseries of measurements obtained from a sensor and at least one of the first derived timeseries or the second derived timeseries is an abnormal event timeseries that indicates whether each of the measurements is normal or abnormal.

[0162] In some embodiments, the input timeseries is a timeseries of building access events obtained from a physical access control device associated with a building space and at least one of the first derived timeseries or the second derived timeseries is an abnormal event timeseries that indicates whether each of the access events is normal or abnormal. [0163] Another implementation of the present disclosure is a method for managing timeseries data provided by building equipment. The method includes collecting samples of the timeseries data from the building equipment and generating one or more input timeseries comprising a plurality of the samples, identifying a first timeseries processing workflow that uses the input timeseries as an input and defines one or more processing operations to be applied to the samples of the input timeseries, performing the one or more processing operations defined by the first timeseries processing workflow to generate a first derived timeseries comprising a first set of derived timeseries samples, identifying a second timeseries processing workflow that uses the first derived timeseries as an input and defines one or more processing operations to be applied to the samples of the first derived timeseries, performing the one or more processing operations defined by the second timeseries processing workflow to generate a second derived timeseries comprising a second set of derived timeseries samples, and storing the input timeseries and the first and second derived timeseries in a timeseries database.

[0164] In some embodiments, the building equipment includes at least one of sensors, HVAC equipment lighting equipment, access control equipment, or security equipment.

[0165] In some embodiments, generating the first derived timeseries includes transforming one or more samples of the input timeseries into one or more samples of the first set of derived timeseries samples by applying the one or more samples of the input timeseries as an input to the first timeseries processing workflow and assembling the first set of derived timeseries samples to form the first derived timeseries.

[0166] In some embodiments, generating the second derived timeseries includes transforming one or more samples of the first set of derived timeseries samples into one or more samples of the second set of derived timeseries samples by applying the one or more samples of the first set of derived timeseries samples as an input to the second timeseries processing workflow and assembling the second set of derived timeseries samples to form the second derived timeseries.

[0167] In some embodiments, the method includes identifying one or more other timeseries to be used as inputs to the first timeseries processing workflow and generating an enriched timeseries processing workflow comprising the first timeseries processing workflow, the input timeseries, and the one or more other timeseries. [0168] In some embodiments, the timeseries database stores a plurality of timeseries. The method may include identifying the input timeseries or the first derived timeseries from the plurality of timeseries stored in the timeseries database.

[0169] In some embodiments, the method includes storing a plurality of directed acyclic graphs (DAG) in a DAG database, each of the DAGs defining a timeseries processing workflow. The method may include determining whether any of the DAGs stored in the DAG database use the input timeseries or the first derived timeseries as an input.

[0170] In some embodiments, the method includes, upon generating a derived timeseries (a) determining whether the derived timeseries is used as an input to any of a plurality of stored timeseries processing workflows and (b) in response to a determination that the derived timeseries is used as an input to at least one of the stored timeseries processing workflows, performing one or more processing operations defined by the timeseries processing workflows that use the derived timeseries as an input to generate another derived timeseries.

[0171] In some embodiments, the method includes iteratively repeating steps (a) and (b) until the derived timeseries generated in step (b) is not used as an input to any of the plurality of stored timeseries processing workflows.

[0172] In some embodiments, the timeseries database comprises at least one of a local timeseries database within the building management system or a hosted timeseries database at a remote location relative to the building management system.

[0173] In some embodiments, the input timeseries is a timeseries of measurements obtained from a sensor and at least one of the first derived timeseries or the second derived timeseries is an abnormal event timeseries that indicates whether each of the measurements is normal or abnormal.

[0174] In some embodiments, the input timeseries is a timeseries of building access events obtained from a physical access control device associated with a building space and at least one of the first derived timeseries or the second derived timeseries is an abnormal event timeseries that indicates whether each of the access events is normal or abnormal. Cloud-Based Feedback Control

[0175] One implementation of the present disclosure is a building management platform monitoring and controlling equipment of a building management system. The building management platform includes a data collector and a timeseries service. The data collector is configured to collect feedback samples provided by one or more sensors of a building management system and generate one or more feedback timeseries including a plurality of the feedback samples. The timeseries service is configured to identify a feedback control workflow that uses the feedback timeseries as an input and defines one or more processing operations to be applied to the feedback samples of the feedback timeseries, perform the one or more processing operations defined by the feedback control workflow to generate a control signal timeseries including a set of control signal samples, and provide a control signal including at least one of the control signal samples or the control signal timeseries as an output to controllable building equipment of the building management system that operate using the control signal as an input.

[0176] In some embodiments, the sensors include at least one of a temperature sensor, a humidity sensor, a lighting sensor, an air quality sensor, or an occupancy sensor configured to sense an environmental condition within a building space. In some embodiments, the sensors include at least one of a temperature sensor, a flow rate sensor, an enthalpy sensor, or a voltage sensor configured to sense an operating state or condition of central plant equipment within a central plant. In some embodiments, the data sources include internet of things (IoT) devices. In some embodiments, the controllable building equipment include at least one of HVAC equipment, security equipment, lighting equipment, or access control equipment installed within a building.

[0177] In some embodiments, generating the control signal timeseries includes

transforming one or more samples of the feedback timeseries into one or more samples of the control signal samples by applying the one or more samples of the feedback timeseries as an input to the feedback control workflow and assembling the control samples to form the control signal timeseries.

[0178] In some embodiments, the timeseries service is configured to identify one or more other timeseries required as inputs to the feedback control workflow and generate an enriched feedback control workflow including the feedback control workflow, the feedback timeseries, and the one or more other timeseries. In some embodiments, the one or more other timeseries include a setpoint timeseries including a plurality of setpoint samples, each of the setpoint samples defining a setpoint corresponding to one of the feedback samples.

[0179] In some embodiments, the building management platform includes a timeseries database that stores a plurality of timeseries. The timeseries service may include a timeseries identifier configured to identify the feedback timeseries from the plurality of timeseries stored in the timeseries database.

[0180] In some embodiments, the building management platform includes a directed acyclic graph (DAG) database storing a plurality of feedback DAGs. Each of the DAGs may define a feedback control workflow. In some embodiments, the timeseries service includes a DAG identifier configured to determine whether any of the feedback control DAGs stored in the DAG database use the feedback timeseries as an input.

[0181] In some embodiments, the timeseries service is distributed across multiple systems or devices.

[0182] In some embodiments, the feedback control workflow includes at least one of a state-based control workflow, an extremum seeking control (ESC) workflow, a proportional- integral (PI) control workflow, a proportional-integral-derivative (PID) control workflow, or a model predictive control (MPC) workflow that causes the timeseries service to transform the feedback timeseries into the control signal timeseries using a feedback control technique.

[0183] In some embodiments, the feedback control workflow comprises a proportional- integral-derivative (PID) control workflow that causes the timeseries service to generate an error timeseries that includes a plurality of error samples. Each of the error samples may indicate a difference between one or the feedback samples and a corresponding setpoint. The PID control workflow may cause the timeseries service to generate the control signal timeseries by applying a set of PID control operations to the error timeseries.

[0184] In some embodiments, applying the set of PID control operations to the error timeseries includes generating an integrated error timeseries based on a plurality of the error samples and generating a derivative error timeseries based on a change in value between consecutive samples of the error timeseries. [0185] In some embodiments, applying the set of PUD control operations to the error timeseries includes calculating a proportional gain component by multiplying the error timeseries by a proportional gain parameter, calculating an integral gain component by multiplying the integrated error timeseries by an integral gain parameter, calculating a derivative gain component by multiplying the derivative error timeseries by a derivative gain parameter, and combining the proportional gain component, the integral gain component, and the derivative gain component to generate the control signal timeseries.

[0186] Another implementation of the present disclosure is building management platform for monitoring and controlling equipment of a building management system. The building management platform includes one or more computer-readable storage media having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to collect feedback samples provided by one or more sensors of the building management system and generate one or more feedback timeseries including a plurality of the feedback samples, identify a feedback control workflow that uses the feedback timeseries as an input and defines one or more processing operations to be applied to the feedback samples of the feedback timeseries, perform the one or more processing operations defined by the feedback control workflow to generate a control signal timeseries including a set of control signal samples, and provide a control signal including at least one of the control signal samples or the control signal timeseries as an output to controllable building equipment of the building management system that operate using the control signal as an input.

[0187] In some embodiments, the sensors include at least one of a temperature sensor, a humidity sensor, a lighting sensor, an air quality sensor, or an occupancy sensor configured to sense an environmental condition within a building space. In some embodiments, the sensors include at least one of a temperature sensor, a flow rate sensor, an enthalpy sensor, or a voltage sensor configured to sense an operating state or condition of central plant equipment within a central plant. In some embodiments, the data sources include internet of things (IoT) devices. In some embodiments, the controllable building equipment include at least one of HVAC equipment, security equipment, lighting equipment, or access control equipment installed within a building.

[0188] In some embodiments, generating the control signal timeseries includes

transforming one or more samples of the feedback timeseries into one or more samples of the control signal samples by applying the one or more samples of the feedback timeseries as an input to the feedback control workflow and assembling the control samples to form the control signal timeseries.

[0189] In some embodiments, the instructions cause the one or more processors to identify one or more other timeseries required as inputs to the feedback control workflow and generate an enriched feedback control workflow including the feedback control workflow, the feedback timeseries, and the one or more other timeseries. In some embodiments, the one or more other timeseries include a setpoint timeseries including a plurality of setpoint samples, each of the setpoint samples defining a setpoint corresponding to one of the feedback samples.

[0190] In some embodiments, the building management platform includes a timeseries database that stores a plurality of timeseries. In some embodiments, the instructions cause the one or more processors to identify the feedback timeseries from the plurality of timeseries stored in the timeseries database.

[0191] In some embodiments, the building management platform includes a directed acyclic graph (DAG) database storing a plurality of feedback DAGs, each of the DAGs defining a feedback control workflow. In some embodiments, the instructions cause the one or more processors to determine whether any of the feedback control DAGs stored in the DAG database use the feedback timeseries as an input.

[0192] In some embodiments, the one or more processors are distributed across multiple systems or devices.

[0193] In some embodiments, the feedback control workflow includes at least one of a state-based control workflow, an extremum seeking control (ESC) workflow, a proportional- integral (PI) control workflow, a proportional-integral-derivative (PID) control workflow, or a model predictive control (MPC) workflow that causes the one or more processors to transform the feedback timeseries into the control signal timeseries using a feedback control technique.

[0194] In some embodiments, the feedback control workflow comprises a proportional- integral-derivative (PID) control workflow that causes the one or more processors to generate an error timeseries that includes a plurality of error samples. Each of the error samples may indicate a difference between one or the feedback samples and a corresponding setpoint. The PID control workflow may cause the one or more processors to generate the control signal timeseries by applying a set of PID control operations to the error timeseries.

[0195] In some embodiments, applying the set of PID control operations to the error timeseries includes generating an integrated error timeseries based on a plurality of the error samples and generating a derivative error timeseries based on a change in value between consecutive samples of the error timeseries.

[0196] In some embodiments, applying the set of PID control operations to the error timeseries includes calculating a proportional gain component by multiplying the error timeseries by a proportional gain parameter, calculating an integral gain component by multiplying the integrated error timeseries by an integral gain parameter, calculating a derivative gain component by multiplying the derivative error timeseries by a derivative gain parameter, and combining the proportional gain component, the integral gain component, and the derivative gain component to generate the control signal timeseries.

[0197] Another implementation of the present disclosure is a method for monitoring and controlling equipment of a building management system. The method includes collecting feedback samples provided by one or more sensors of the building management system and generating one or more feedback timeseries including a plurality of the feedback samples, identifying a feedback control workflow that uses the feedback timeseries as an input and defines one or more processing operations to be applied to the feedback samples of the feedback timeseries, performing the one or more processing operations defined by the feedback control workflow to generate a control signal timeseries including a set of control signal samples, and providing a control signal including at least one of the control signal samples or the control signal timeseries as an output to controllable building equipment of the building management system that operate using the control signal as an input.

[0198] In some embodiments, the sensors include at least one of a temperature sensor, a humidity sensor, a lighting sensor, an air quality sensor, or an occupancy sensor configured to sense an environmental condition within a building space. In some embodiments, the sensors include at least one of a temperature sensor, a flow rate sensor, an enthalpy sensor, or a voltage sensor configured to sense an operating state or condition of central plant equipment within a central plant. In some embodiments, the data sources include internet of things (IoT) devices. In some embodiments, the controllable building equipment include at least one of HVAC equipment, security equipment, lighting equipment, or access control equipment installed within a building.

[0199] In some embodiments, generating the control signal timeseries includes

transforming one or more samples of the feedback timeseries into one or more samples of the control signal samples by applying the one or more samples of the feedback timeseries as an input to the feedback control workflow and assembling the control samples to form the control signal timeseries and assembling the control samples to form the control signal timeseries.

[0200] In some embodiments, the method includes identifying one or more other timeseries required as inputs to the feedback control workflow and generating an enriched feedback control workflow including the feedback control workflow, the feedback timeseries, and the one or more other timeseries. In some embodiments, the one or more other timeseries include a setpoint timeseries including a plurality of setpoint samples, each of the setpoint samples defining a setpoint corresponding to one of the feedback samples.

[0201] In some embodiments, the method includes accessing a timeseries database that stores a plurality of timeseries and identifying the feedback timeseries from the plurality of timeseries stored in the timeseries database.

[0202] In some embodiments, the method includes accessing a directed acyclic graph (DAG) database that stores a plurality of feedback DAGs, each of the DAGs defining a feedback control workflow, and determining whether any of the feedback control DAGs stored in the DAG database use the feedback timeseries as an input.

[0203] In some embodiments, the one or more processing operations defined by the feedback control workflow are distributed across multiple systems or devices.

[0204] In some embodiments, the feedback control workflow includes at least one of a state-based control workflow, an extremum seeking control (ESC) workflow, a proportional- integral (PI) control workflow, a proportional-integral-derivative (PID) control workflow, or a model predictive control (MPC) workflow that causes the feedback timeseries to be transformed into the control signal timeseries using a feedback control technique. [0205] In some embodiments, the feedback control workflow comprises a proportional- integral-derivative (PID) control workflow. Performing the one or more processing operations defined by the feedback control workflow may include generating an error timeseries that includes a plurality of error samples. Each of the error samples may indicate a difference between one or the feedback samples and a corresponding setpoint. Performing the one or more processing operations defined by the feedback control workflow may include generating the control signal timeseries by applying a set of PID control operations to the error timeseries.

[0206] In some embodiments, applying the set of PID control operations to the error timeseries includes generating an integrated error timeseries based on a plurality of the error samples and generating a derivative error timeseries based on a change in value between consecutive samples of the error timeseries.

[0207] In some embodiments, applying the set of PID control operations to the error timeseries includes calculating a proportional gain component by multiplying the error timeseries by a proportional gain parameter, calculating an integral gain component by multiplying the integrated error timeseries by an integral gain parameter, calculating a derivative gain component by multiplying the derivative error timeseries by a derivative gain parameter, and combining the proportional gain component, the integral gain component, and the derivative gain component to generate the control signal timeseries.

Identity Management and Assurance Services

[0208] One implementation of the present disclosure is a building management system including an entity database and an identity management service. The entity database stores a plurality of interconnected smart entities. The smart entities include object entities representing a plurality of people or physical devices and data entities representing data associated with the people or physical devices. The smart entities are interconnected by relational objects indicating relationships between the object entities and the data entities. Each of the object entities includes a plurality of stored identity attributes. The identity management service is configured to receive a first identity attribute from a first device within a building, receive a second identity attribute from a second device within the building, compare the first and second identity attributes to the stored identity attributes of an object entity of the plurality of interconnected smart entities, and allow access to at least one of a building space, a device of building equipment, or a computer system in response to the first and second identity attributes matching the stored identity attributes of the object entity.

[0209] In some embodiments, the first device is an access card reader and the first identity attribute is a card ID attribute recorded by the access card reader. In some embodiments, the second device is a security camera and the second identity attribute is an image of a person captured by the security camera.

[0210] In some embodiments, the first device is an access card reader and the first identity attribute is a card ID attribute recorded by the access card reader. In some embodiments, the second device is a mobile device carried by a person and the second identity attribute is a mobile device ID attribute associated with the mobile device.

[0211] In some embodiments, the first device is a user interface device and the first identity attribute is a user identifier received from a user via the user interface device. In some embodiments, the second device is a security camera and the second identity attribute is an image of a person captured by the security camera.

[0212] In some embodiments, the first device is a user interface device and the first identity attribute is a user identifier received from a user via the user interface device. In some embodiments, the second device is a mobile device carried by a person and the second identity attribute is a mobile device ID attribute associated with the mobile device.

[0213] In some embodiments, the first device is one of a mobile device, an information technology (IT) device, an internet of things (IoT) sensor, a building equipment device, or a security device. In some embodiments, the second device is another of the mobile device, the IT device, the IoT sensor, the building equipment device, or the security device.

[0214] In some embodiments, the identity management service is configured to determine a location associated with the first device in response to the first device providing the first identity attribute, identify a building space in which the first device is located, and select the second device from a set of devices located in the same building space as the first device.

[0215] In some embodiments, the identity management service is configured to deny access to at least one of the building space, the device of building equipment, or the computer system in response to at least one of the first and second identity attributes not matching the stored identity attributes of the object entity.

[0216] Another implementation of the present disclosure is a method for controlling access to a building space, a device of building equipment, or a computer system in a building management system. The method includes storing a plurality of interconnected smart entities in an entity database. The smart entities include object entities representing a plurality of people or physical devices and data entities representing data associated with the people or physical devices. The smart entities are interconnected by relational objects indicating relationships between the object entities and the data entities. Each of the object entities includes a plurality of stored identity attributes. The method further includes receiving a first identity attribute from a first device within a building, receiving a second identity attribute from a second device within the building, comparing the first and second identity attributes to the stored identity attributes of an object entity of the plurality of interconnected smart entities, and allowing access to at least one of a building space, a device of building equipment, or a computer system in response to the first and second identity attributes matching the stored identity attributes of the object entity.

[0217] In some embodiments, the first device is an access card reader and the first identity attribute is a card ID attribute recorded by the access card reader. In some embodiments, the second device is at least one of a security camera or a mobile device carried by a person and the second identity attribute is at least one of an image of a person captured by the security camera or a mobile device ID attribute associated with the mobile device.

[0218] In some embodiments, the first device is a user interface device and the first identity attribute is a user identifier received from a user via the user interface device. In some embodiments, the second device is at least one of a security camera or a mobile device carried by a person and the second identity attribute is at least one of an image of a person captured by the security camera or a mobile device ID attribute associated with the mobile device.

[0219] In some embodiments, the method includes determining a location associated with the first device in response to the first device providing the first identity attribute, identifying a building space in which the first device is located, and selecting the second device from a set of devices located in the same building space as the first device. [0220] Another implementation of the present disclosure is a building management system including a plurality of devices of building equipment, an entity database, and an assurance service. The entity database stores a plurality of interconnected smart entities. The smart entities include object entities representing the plurality of devices of building equipment and data entities representing data associated with the plurality of devices of building equipment. The smart entities are interconnected by relational objects indicating relationships between the object entities and the data entities. Each object entity includes a stored attribute indicating a version of software installed on a device of the building equipment represented by the object entity. The assurance service is configured to automatically detect a version of software installed on each of the devices of building equipment by reading the stored attributes of the object entities and automatically update the software installed on one or more of the devices of building equipment in response to a determination that the version of software installed on the one or more of the devices of building equipment is not a latest version of the software.

[0221] In some embodiments, the assurance service includes an identity and security service configured to ensure that each device of the building equipment is able to access configuration backups.

[0222] In some embodiments, the assurance service includes a device management service configured to create a smart entity for each device of the building equipment and register each device of the building equipment with the corresponding smart entity.

[0223] In some embodiments, the assurance service includes a transportation and messaging service configured to facilitate bidirectional communications between the assurance service and the building equipment.

[0224] In some embodiments, the assurance service includes a device shadow/manifest service configured to synchronize at least one of configuration settings, parameters, or device-specific information between the building equipment and the assurance service.

[0225] In some embodiments, the assurance service includes a package service configured to create a compressed data object including a configuration of the building equipment and store the compressed data object as a backup of the configuration. [0226] In some embodiments, the assurance service includes an asset and backup service configured to generate and present a user interface that lists each device of the building equipment and indicates whether a backup configuration of each device has been stored at the assurance service.

[0227] In some embodiments, the assurance service includes a manual upload service configured to upload a backup configuration in response to a user request for the backup configuration.

[0228] Those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the devices and/or processes described herein, as defined solely by the claims, will become apparent in the detailed description set forth herein and taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0229] The above and other aspects and features of the present disclosure will become more apparent to those skilled in the art from the following detailed description of the example embodiments with reference to the accompanying drawings.

[0230] FIG. 1 is a block diagram of a smart building environment, according to some exemplary embodiments.

[0231] FIG. 2 is a perspective view of a smart building, according to some exemplary embodiments.

[0232] FIG. 3 is a block diagram of a waterside system, according to some exemplary embodiments.

[0233] FIG. 4 is a block diagram of an airside system, according to some exemplary embodiments.

[0234] FIG. 5 is a block diagram of a building management system, according to some exemplary embodiments.

[0235] FIG. 6 is a block diagram of another building management system, according to some exemplary embodiments. [0236] FIG. 7 is a block diagram illustrating an entity service of FIG. 6 in greater detail, according to some exemplary embodiments.

[0237] FIG. 8 in an example entity graph of entity data, according to some exemplary embodiments.

[0238] FIG. 9 is a block diagram illustrating timeseries service of FIG. 6 in greater detail, according to some exemplary embodiments.

[0239] FIG. 10 is a flow diagram of a process or method for updating/creating an attribute of a related entity based on data received from a device of a building management subsystem, according to some exemplary embodiments.

[0240] FIG. 11 is an example entity graph of entity data, according to some exemplary embodiments;.

[0241] FIG. 12 is a flow diagram of a process or method for analyzing data from a second related device based on data from a first device, according to some exemplary embodiments.

[0242] FIG. 13 is a flow diagram of a process or method for generating derived timeseries from data generated by a first device and a second device, according to some exemplary embodiments.

[0243] FIG. 14 is a block diagram illustrating an aggregation technique which can be used by the sample aggregator shown in FIG. 13 to aggregate raw data samples, according to some embodiments.

[0244] FIG. 15 is a data table which can be used to store raw data timeseries and a variety of derived data timeseries which can be generated by the timeseries service of FIG. 9, according to some embodiments.

[0245] FIG. 16 is a drawing of several timeseries illustrating the synchronization of data samples which can be performed by the sample aggregator shown in FIG. 9, according to some embodiments.

[0246] FIG. 17 is a flow diagram illustrating the creation and storage of a fault detection timeseries which can be performed by the fault detector shown in FIG. 9, according to some embodiments. [0247] FIG. 18 is a data table which can be used to store the raw data timeseries and the fault detection timeseries, according to some embodiments.

[0248] FIG. 19A is a data table which can be used to store states assigned to samples of a data timeseries, according to some embodiments.

[0249] FIG. 19B is a data table including various events generated based on the assigned states shown in the table of FIG. 19A, according to some embodiments.

[0250] FIG. 19C is a flowchart of a process for generating and updating events and eventseries, according to some embodiments.

[0251] FIG. 20A is a directed acyclic graph (DAG) which can be generated by the DAG generator of FIG. 9, according to some embodiments.

[0252] FIG. 20B is a code snippet which can be automatically generated by the DAG generator of FIG. 9 based on the DAG, according to some embodiments.

[0253] FIG. 21A is an entity graph illustrating relationships between an organization, a space, a system, a point, and a timeseries, which can be used by the data collector of FIG. 6, according to some embodiments.

[0254] FIG. 2 IB is an example of an entity graph for a particular system of devices, according to some embodiments.

[0255] FIG. 22 is an object relationship diagram illustrating relationships between an entity template, a point, a timeseries, and a data sample, which can be used by the data collector of FIG. 6 and the timeseries service of FIG. 9, according to some embodiments.

[0256] FIG. 23 A is a block diagram illustrating a timeseries processing workflow which can be performed by the timeseries service of FIG. 9, according to some embodiments.

[0257] FIG. 23B is a flowchart of a process which can be performed by the workflow manager of FIG. 23 A, according to some embodiments.

[0258] FIG. 24 is a block diagram of a system for processing streaming data, which may be implemented as part of the building management platform of FIG. 1, according to some embodiments. [0259] FIG. 25A is a block diagram illustrating an iterative timeseries processing technique used by the system of FIG. 24, according to some embodiments.

[0260] FIG. 25B is a flowchart of an iterative timeseries processing process which can be performed by the system of FIG. 24, according to some embodiments.

[0261] FIG. 26 is a block diagram of a cloud-based feedback control system including the building management platform of FIG.1, according to some embodiments.

[0262] FIG. 27 is a block diagram of an identity management system including an identity management service and an entity service, according to some embodiments.

[0263] FIG. 28 is a block diagram of an assurance service, according to some embodiments.

DETAILED DESCRIPTION

[0264] Hereinafter, example embodiments will be described in more detail with reference to the accompanying drawings.

[0265] FIG. 1 is a block diagram of a smart building environment 100, according to some exemplary embodiments. Smart building environment 100 is shown to include a building management platform 102. Building management platform 102 can be configured to collect data from a variety of different data sources. For example, building management platform 102 is shown collecting data from buildings 110, 120, 130, and 140. For example, the buildings may include a school 1 10, a hospital 120, a factory 130, an office building 140, and/or the like. However the present disclosure is not limited to the number or types of buildings 110, 120, 130, and 140 shown in FIG. 1. For example, in some embodiments, building management platform 102 may be configured to collect data from one or more buildings, and the one or more buildings may be the same type of building, or may include one or more different types of buildings than that shown in FIG. 1.

[0266] Building management platform 102 can be configured to collect data from a variety of devices 112-116, 122-126, 132-136, and 142-146, either directly (e.g., directly via network 104) or indirectly (e.g., via systems or applications in the buildings 110, 120, 130, 140). In some embodiments, devices 112-116, 122-126, 132-136, and 142-146 are internet of things (IoT) devices. IoT devices may include any of a variety of physical devices, sensors, actuators, electronics, vehicles, home appliances, and/or other items having network connectivity which enable IoT devices to communicate with building management platform 102. For example, IoT devices can include smart home hub devices, smart house devices, doorbell cameras, air quality sensors, smart switches, smart lights, smart appliances, garage door openers, smoke detectors, heart monitoring implants, biochip transponders, cameras streaming live feeds, automobiles with built-in sensors, DNA analysis devices, field operation devices, tracking devices for people/vehicles/equipment, networked sensors, wireless sensors, wearable sensors, environmental sensors, RFID gateways and readers, IoT gateway devices, robots and other robotic devices, GPS devices, smart watches, virtual/augmented reality devices, and/or other networked or networkable devices. While the devices described herein are generally referred to as IoT devices, it should be understood that, in various

embodiments, the devices referenced in the present disclosure could be any type of devices capable of communicating data over an electronic network.

[0267] In some embodiments, IoT devices may include sensors or sensor systems. For example, IoT devices may include acoustic sensors, sound sensors, vibration sensors, automotive or transportation sensors, chemical sensors, electric current sensors, electric voltage sensors, magnetic sensors, radio sensors, environment sensors, weather sensors, moisture sensors, humidity sensors, flow sensors, fluid velocity sensors, ionizing radiation sensors, subatomic particle sensors, navigation instruments, position sensors, angle sensors, displacement sensors, distance sensors, speed sensors, acceleration sensors, optical sensors, light sensors, imaging devices, photon sensors, pressure sensors, force sensors, density sensors, level sensors, thermal sensors, heat sensors, temperature sensors, proximity sensors, presence sensors, and/or any other type of sensors or sensing systems.

[0268] Examples of acoustic, sound, or vibration sensors include geophones, hydrophones, lace sensors, guitar pickups, microphones, and seismometers. Examples of automotive or transportation sensors include air flow meters, air-fuel ratio meters, AFR sensors, blind spot monitors, crankshaft position sensors, defect detectors, engine coolant temperature sensors, Hall effect sensors, knock sensors, map sensors, mass flow sensors, oxygen sensors, parking sensors, radar guns, speedometers, speed sensors, throttle position sensors, tire-pressure monitoring sensors, torque sensors, transmission fluid temperature sensors, turbine speed sensors, variable reluctance sensors, vehicle speed sensors, water sensors, and wheel speed sensors. [0269] Examples of chemical sensors include breathalyzers, carbon dioxide sensors, carbon monoxide detectors, catalytic bead sensors, chemical field-effect transistors, chemiresistors, electrochemical gas sensors, electronic noses, electrolyte-insulator-semiconductor sensors, fluorescent chloride sensors, holographic sensors, hydrocarbon dew point analyzers, hydrogen sensors, hydrogen sulfide sensors, infrared point sensors, ion-selective electrodes, nondispersive infrared sensors, microwave chemistry sensors, nitrogen oxide sensors, olfactometers, optodes, oxygen sensors, ozone monitors, pellistors, pH glass electrodes, potentiometric sensors, redox electrodes, smoke detectors, and zinc oxide nanorod sensors.

[0270] Examples of electromagnetic sensors include current sensors, Daly detectors, electroscopes, electron multipliers, Faraday cups, galvanometers, Hall effect sensors, Hall probes, magnetic anomaly detectors, magnetometers, magnetoresi stances, mems magnetic field sensors, metal detectors, planar hall sensors, radio direction finders, and voltage detectors.

[0271] Examples of environmental sensors include actinometers, air pollution sensors, bedwetting alarms, ceilometers, dew warnings, electrochemical gas sensors, fish counters, frequency domain sensors, gas detectors, hook gauge evaporimeters, humistors, hygrometers, leaf sensors, lysimeters, pyranometers, pyrgeometers, psychrometers, rain gauges, rain sensors, seismometers, SNOTEL sensors, snow gauges, soil moisture sensors, stream gauges, and tide gauges. Examples of flow and fluid velocity sensors include air flow meters, anemometers, flow sensors, gas meter, mass flow sensors, and water meters.

[0272] Examples of radiation and particle sensors include cloud chambers, Geiger counters, Geiger-Muller tubes, ionisation chambers, neutron detections, proportional counters, scintillation counters, semiconductor detectors, and thermoluminescent dosimeters.

Wexamples of navigation instruments include air speed indicators, altimeters, attitude indicators, depth gauges, fluxgate compasses, gyroscopes, inertial navigation systems, inertial reference nits, magnetic compasses, MHD sensors, ring laser gyroscopes, turn coordinators, tialinx sensors, variometers, vibrating structure gyroscopes, and yaw rate sensors.

[0273] Examples of position, angle, displacement, distance, speed, and acceleration sensors include auxanometers, capacitive displacement sensors, capacitive sensing devices, flex sensors, free fall sensors, gravimeters, gyroscopic sensors, impact sensors, inclinometers, integrated circuit piezoelectric sensors, laser rangefinders, laser surface velocimeters, LIDAR sensors, linear encoders, linear variable differential transformers (LVDT), liquid capacitive inclinometers odometers, photoelectric sensors, piezoelectric accelerometers, position sensors, position sensitive devices, angular rate sensors, rotary encoders, rotary variable differential transformers, selsyns, shock detectors, shock data loggers, tilt sensors, tachometers, ultrasonic thickness gauges, variable reluctance sensors, and velocity receivers.

[0274] Examples of optical, light, imaging, and photon sensors include charge-coupled devices, CMOS sensors, colorimeters, contact image sensors, electro-optical sensors, flame detectors, infra-red sensors, kinetic inductance detectors, led as light sensors, light- addressable potentiometric sensors, Nichols radiometers, fiber optic sensors, optical position sensors, thermopile laser sensors, photodetectors, photodiodes, photomultiplier tubes, phototransistors, photoelectric sensors, photoionization detectors, photomultipliers, photoresistors, photoswitches, phototubes, scintillometers, Shack-Hartmann sensors, single- photon avalanche diodes, superconducting nanowire single-photon detectors, transition edge sensors, visible light photon counters, and wavefront sensors.

[0275] Examples of pressure sensors include barographs, barometers, boost gauges, bourdon gauges, hot filament ionization gauges, ionization gauges, McLeod gauges, oscillating u-tubes, permanent downhole gauges, piezometers, pirani gauges, pressure sensors, pressure gauges, tactile sensors, and time pressure gauges. Examples of force, density, and level sensors include bhangmeters, hydrometers, force gauge and force sensors, level sensors, load cells, magnetic level gauges, nuclear density gauges, piezocapacitive pressure sensors, piezoelectric sensors, strain gauges, torque sensors, and viscometers.

[0276] Examples of thermal, heat, and temperature sensors include bolometers, bimetallic strips, calorimeters, exhaust gas temperature gauges, flame detections, Gardon gauges, Golay cells, heat flux sensors, infrared thermometers, microbolometers, microwave radiometers, net radiometers, quartz thermometers, resistance thermometers, silicon bandgap temperature sensors, special sensor microwave/imagers, temperature gauges, thermistors, thermocouples, thermometers, and pyrometers. Examples of proximity and presence sensors include alarm sensors, Doppler radars, motion detectors, occupancy sensors, proximity sensors, passive infrared sensors, reed switches, stud finders, triangulation sensors, touch switches, and wired gloves. [0277] In some embodiments, different sensors send measurements or other data to building management platform 102 using a variety of different communications protocols or data formats. Building management platform 102 can be configured to ingest sensor data received in any protocol or data format and translate the inbound sensor data into a common data format. Building management platform 102 can create a sensor object smart entity for each sensor that communicates with Building management platform 102. Each sensor object smart entity may include one or more static attributes that describe the corresponding sensor, one or more dynamic attributes that indicate the most recent values collected by the sensor, and/or one or more relational attributes that relate sensors object smart entities to each other and/or to other types of smart entities (e.g., space entities, system entities, data entities, etc.).

[0278] In some embodiments, building management platform 102 stores sensor data using data entities. Each data entity may correspond to a particular sensor and may include a timeseries of data values received from the corresponding sensor. In some embodiments, building management platform 102 stores relational objects that define relationships between sensor object entities and the corresponding data entity. For example, each relational object may identify a particular sensor object entity, a particular data entity, and may define a link between such entities.

[0279] Building management platform 102 can collect data from a variety of external systems or services. For example, building management platform 102 is shown receiving weather data from a weather service 152, news data from a news service 154, documents and other document-related data from a document service 156, and media (e.g., video, images, audio, social media, etc.) from a media service 158. In some embodiments, building management platform 102 generates data internally. For example, building management platform 102 may include a web advertising system, a website traffic monitoring system, a web sales system, or other types of platform services that generate data. The data generated by building management platform 102 can be collected, stored, and processed along with the data received from other data sources. Building management platform 102 can collect data directly from external systems or devices or via a network 104 (e.g., a WAN, the Internet, a cellular network, etc.). Building management platform 102 can process and transform collected data to generate timeseries data and entity data. Several features of building management platform 102 are described in more detail below.

Building HVAC Systems and Building Management Systems [0280] Referring now to FIGS. 2-5, several building management systems (BMS) and HVAC systems in which the systems and methods of the present disclosure can be implemented are shown, according to some embodiments. In brief overview, FIG. 2 shows a building 10 equipped with, for example, a HVAC system 200. Building 10 may be any of the buildings 210, 220, 230, and 140 as shown in FIG. 1, or may be any other suitable building that is communicatively connected to building management platform 202. FIG. 3 is a block diagram of a waterside system 300 which can be used to serve building 10. FIG. 4 is a block diagram of an airside system 400 which can be used to serve building 10. FIG. 5 is a block diagram of a building management system (BMS) which can be used to monitor and control building 10.

Building and HVAC System

[0281] Referring particularly to FIG. 2, a perspective view of a smart building 10 is shown. Building 10 is served by a BMS. A BMS is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. A BMS can include, for example, a HVAC system, a security system, a lighting system, a fire alerting system, any other system that is capable of managing building functions or devices, or any combination thereof. Further, each of the systems may include a plurality of sensors and other devices (e.g., IoT devices) for the proper operation, maintenance, monitoring, and the like of the respective systems.

[0282] The BMS that serves building 10 includes a HVAC system 200. HVAC system 200 can include a plurality of HVAC devices (e.g., heaters, chillers, air handling units, pumps, fans, thermal energy storage, etc.) configured to provide heating, cooling, ventilation, or other services for building 10. For example, HVAC system 200 is shown to include a waterside system 220 and an airside system 230. Waterside system 220 may provide a heated or chilled fluid to an air handling unit of airside system 230. Airside system 230 may use the heated or chilled fluid to heat or cool an airflow provided to building 10. An exemplary waterside system and airside system which can be used in HVAC system 200 are described in greater detail with reference to FIGS. 3 and 4.

[0283] HVAC system 200 is shown to include a chiller 202, a boiler 204, and a rooftop air handling unit (AHU) 206. Waterside system 220 may use boiler 204 and chiller 202 to heat or cool a working fluid (e.g., water, glycol, etc.) and may circulate the working fluid to AHU 206. In various embodiments, the HVAC devices of waterside system 220 can be located in or around building 10 (as shown in FIG. 2) or at an offsite location such as a central plant (e.g., a chiller plant, a steam plant, a heat plant, etc.). The working fluid can be heated in boiler 204 or cooled in chiller 202, depending on whether heating or cooling is required in building 10. Boiler 204 may add heat to the circulated fluid, for example, by burning a combustible material (e.g., natural gas) or using an electric heating element. Chiller 202 may place the circulated fluid in a heat exchange relationship with another fluid (e.g., a refrigerant) in a heat exchanger (e.g., an evaporator) to absorb heat from the circulated fluid. The working fluid from chiller 202 and/or boiler 204 can be transported to AHU 206 via piping 208.

[0284] AHU 206 may place the working fluid in a heat exchange relationship with an airflow passing through AHU 206 (e.g., via one or more stages of cooling coils and/or heating coils). The airflow can be, for example, outside air, return air from within building 10, or a combination of both. AHU 206 may transfer heat between the airflow and the working fluid to provide heating or cooling for the airflow. For example, AHU 206 can include one or more fans or blowers configured to pass the airflow over or through a heat exchanger containing the working fluid. The working fluid may then return to chiller 202 or boiler 204 via piping 210.

[0285] Airside system 230 may deliver the airflow supplied by AHU 206 (i.e., the supply airflow) to building 10 via air supply ducts 212 and may provide return air from building 10 to AHU 206 via air return ducts 214. In some embodiments, airside system 230 includes multiple variable air volume (VAV) units 216. For example, airside system 230 is shown to include a separate VAV unit 216 on each floor or zone of building 10. VAV units 216 can include dampers or other flow control elements that can be operated to control an amount of the supply airflow provided to individual zones of building 10. In other embodiments, airside system 230 delivers the supply airflow into one or more zones of building 10 (e.g., via supply ducts 212) without using intermediate VAV units 216 or other flow control elements. AHU 206 can include various sensors (e.g., temperature sensors, pressure sensors, etc.) configured to measure attributes of the supply airflow. AHU 206 may receive input from sensors located within AHU 206 and/or within the building zone and may adjust the flow rate, temperature, or other attributes of the supply airflow through AHU 206 to achieve setpoint conditions for the building zone. Waterside System

[0286] Referring now to FIG. 3, a block diagram of a waterside system 300 is shown, according to some embodiments. In various embodiments, waterside system 300 may supplement or replace waterside system 220 in HVAC system 200 or can be implemented separate from HVAC system 200. When implemented in HVAC system 200, waterside system 300 can include a subset of the HVAC devices in HVAC system 200 (e.g., boiler 204, chiller 202, pumps, valves, etc.) and may operate to supply a heated or chilled fluid to AHU 206. The HVAC devices of waterside system 300 can be located within building 10 (e.g., as components of waterside system 220) or at an offsite location such as a central plant.

[0287] In FIG. 3, waterside system 300 is shown as a central plant having a plurality of subplants 302-312. Subplants 302-312 are shown to include a heater subplant 302, a heat recovery chiller subplant 304, a chiller subplant 306, a cooling tower subplant 308, a hot thermal energy storage (TES) subplant 310, and a cold thermal energy storage (TES) subplant 312. Subplants 302-312 consume resources (e.g., water, natural gas, electricity, etc.) from utilities to serve thermal energy loads (e.g., hot water, cold water, heating, cooling, etc.) of a building or campus. For example, heater subplant 302 can be configured to heat water in a hot water loop 314 that circulates the hot water between heater subplant 302 and building 10. Chiller subplant 306 can be configured to chill water in a cold water loop 316 that circulates the cold water between chiller subplant 306 and building 10. Heat recovery chiller subplant 304 can be configured to transfer heat from cold water loop 316 to hot water loop 314 to provide additional heating for the hot water and additional cooling for the cold water.

Condenser water loop 318 may absorb heat from the cold water in chiller subplant 306 and reject the absorbed heat in cooling tower subplant 308 or transfer the absorbed heat to hot water loop 314. Hot TES subplant 310 and cold TES subplant 312 may store hot and cold thermal energy, respectively, for subsequent use.

[0288] Hot water loop 314 and cold water loop 316 may deliver the heated and/or chilled water to air handlers located on the rooftop of building 10 (e.g., AHU 206) or to individual floors or zones of building 10 (e.g., VAV units 216). The air handlers push air past heat exchangers (e.g., heating coils or cooling coils) through which the water flows to provide heating or cooling for the air. The heated or cooled air can be delivered to individual zones of building 10 to serve thermal energy loads of building 10. The water then returns to subplants 302-312 to receive further heating or cooling. [0289] Although subplants 302-312 are shown and described as heating and cooling water for circulation to a building, it is understood that any other type of working fluid (e.g., glycol, C02, etc.) can be used in place of or in addition to water to serve thermal energy loads. In other embodiments, subplants 302-312 may provide heating and/or cooling directly to the building or campus without requiring an intermediate heat transfer fluid. These and other variations to waterside system 300 are within the teachings of the present disclosure.

[0290] Each of subplants 302-312 can include a variety of equipment configured to facilitate the functions of the subplant. For example, heater subplant 302 is shown to include a plurality of heating elements 320 (e.g., boilers, electric heaters, etc.) configured to add heat to the hot water in hot water loop 314. Heater subplant 302 is also shown to include several pumps 322 and 324 configured to circulate the hot water in hot water loop 314 and to control the flow rate of the hot water through individual heating elements 320. Chiller subplant 306 is shown to include a plurality of chillers 332 configured to remove heat from the cold water in cold water loop 316. Chiller subplant 306 is also shown to include several pumps 334 and 336 configured to circulate the cold water in cold water loop 316 and to control the flow rate of the cold water through individual chillers 332.

[0291] Heat recovery chiller subplant 304 is shown to include a plurality of heat recovery heat exchangers 326 (e.g., refrigeration circuits) configured to transfer heat from cold water loop 316 to hot water loop 314. Heat recovery chiller subplant 304 is also shown to include several pumps 328 and 330 configured to circulate the hot water and/or cold water through heat recovery heat exchangers 326 and to control the flow rate of the water through individual heat recovery heat exchangers 326. Cooling tower subplant 308 is shown to include a plurality of cooling towers 338 configured to remove heat from the condenser water in condenser water loop 318. Cooling tower subplant 308 is also shown to include several pumps 340 configured to circulate the condenser water in condenser water loop 318 and to control the flow rate of the condenser water through individual cooling towers 338.

[0292] Hot TES subplant 310 is shown to include a hot TES tank 342 configured to store the hot water for later use. Hot TES subplant 310 may also include one or more pumps or valves configured to control the flow rate of the hot water into or out of hot TES tank 342. Cold TES subplant 312 is shown to include cold TES tanks 344 configured to store the cold water for later use. Cold TES subplant 312 may also include one or more pumps or valves configured to control the flow rate of the cold water into or out of cold TES tanks 344. [0293] In some embodiments, one or more of the pumps in waterside system 300 (e.g., pumps 322, 324, 328, 330, 334, 336, and/or 340) or pipelines in waterside system 300 include an isolation valve associated therewith. Isolation valves can be integrated with the pumps or positioned upstream or downstream of the pumps to control the fluid flows in waterside system 300. In various embodiments, waterside system 300 can include more, fewer, or different types of devices and/or subplants based on the particular configuration of waterside system 300 and the types of loads served by waterside system 300.

Airside System

[0294] Referring now to FIG. 4, a block diagram of an airside system 400 is shown, according to some embodiments. In various embodiments, airside system 400 may supplement or replace airside system 230 in HVAC system 200 or can be implemented separate from HVAC system 200. When implemented in HVAC system 200, airside system 400 can include a subset of the HVAC devices in HVAC system 200 (e.g., AHU 206, VAV units 216, ducts 212-214, fans, dampers, etc.) and can be located in or around building 10. Airside system 400 may operate to heat or cool an airflow provided to building 10 using a heated or chilled fluid provided by waterside system 300.

[0295] In FIG. 4, airside system 400 is shown to include an economizer-type air handling unit (AHU) 402. Economizer-type AHUs vary the amount of outside air and return air used by the air handling unit for heating or cooling. For example, AHU 402 may receive return air 404 from building zone 406 via return air duct 408 and may deliver supply air 410 to building zone 406 via supply air duct 412. In some embodiments, AHU 402 is a rooftop unit located on the roof of building 10 (e.g., AHU 206 as shown in FIG. 2) or otherwise positioned to receive both return air 404 and outside air 414. AHU 402 can be configured to operate exhaust air damper 416, mixing damper 418, and outside air damper 420 to control an amount of outside air 414 and return air 404 that combine to form supply air 410. Any return air 404 that does not pass through mixing damper 418 can be exhausted from AHU 402 through exhaust damper 416 as exhaust air 422.

[0296] Each of dampers 416-420 can be operated by an actuator. For example, exhaust air damper 416 can be operated by actuator 424, mixing damper 418 can be operated by actuator 426, and outside air damper 420 can be operated by actuator 428. Actuators 424-428 may communicate with an AHU controller 430 via a communications link 432. Actuators 424- 428 may receive control signals from AHU controller 430 and may provide feedback signals to AHU controller 430. Feedback signals can include, for example, an indication of a current actuator or damper position, an amount of torque or force exerted by the actuator, diagnostic information (e.g., results of diagnostic tests performed by actuators 424-428), status information, commissioning information, configuration settings, calibration data, and/or other types of information or data that can be collected, stored, or used by actuators 424-428. AHU controller 430 can be an economizer controller configured to use one or more control algorithms (e.g., state-based algorithms, extremum seeking control (ESC) algorithms, proportional-integral (PI) control algorithms, proportional-integral-derivative (PID) control algorithms, model predictive control (MPC) algorithms, feedback control algorithms, etc.) to control actuators 424-428.

[0297] Still referring to FIG. 4, AHU 304 is shown to include a cooling coil 434, a heating coil 436, and a fan 438 positioned within supply air duct 412. Fan 438 can be configured to force supply air 410 through cooling coil 434 and/or heating coil 436 and provide supply air 410 to building zone 406. AHU controller 430 may communicate with fan 438 via communications link 440 to control a flow rate of supply air 410. In some embodiments, AHU controller 430 controls an amount of heating or cooling applied to supply air 410 by modulating a speed of fan 438.

[0298] Cooling coil 434 may receive a chilled fluid from waterside system 300 (e.g., from cold water loop 316) via piping 442 and may return the chilled fluid to waterside system 300 via piping 444. Valve 446 can be positioned along piping 442 or piping 444 to control a flow rate of the chilled fluid through cooling coil 434. In some embodiments, cooling coil 434 includes multiple stages of cooling coils that can be independently activated and deactivated (e.g., by AHU controller 430, by BMS controller 466, etc.) to modulate an amount of cooling applied to supply air 410.

[0299] Heating coil 436 may receive a heated fluid from waterside system 300 (e.g., from hot water loop 314) via piping 448 and may return the heated fluid to waterside system 300 via piping 450. Valve 452 can be positioned along piping 448 or piping 450 to control a flow rate of the heated fluid through heating coil 436. In some embodiments, heating coil 436 includes multiple stages of heating coils that can be independently activated and deactivated (e.g., by AHU controller 430, by BMS controller 466, etc.) to modulate an amount of heating applied to supply air 410. [0300] Each of valves 446 and 452 can be controlled by an actuator. For example, valve 446 can be controlled by actuator 454 and valve 452 can be controlled by actuator 456.

Actuators 454-456 may communicate with AHU controller 430 via communications links 458-460. Actuators 454-456 may receive control signals from AHU controller 430 and may provide feedback signals to controller 430. In some embodiments, AHU controller 430 receives a measurement of the supply air temperature from a temperature sensor 462 positioned in supply air duct 412 (e.g., downstream of cooling coil 434 and/or heating coil 436). AHU controller 430 may also receive a measurement of the temperature of building zone 406 from a temperature sensor 464 located in building zone 406.

[0301] In some embodiments, AHU controller 430 operates valves 446 and 452 via actuators 454-456 to modulate an amount of heating or cooling provided to supply air 410 (e.g., to achieve a setpoint temperature for supply air 410 or to maintain the temperature of supply air 410 within a setpoint temperature range). The positions of valves 446 and 452 affect the amount of heating or cooling provided to supply air 410 by cooling coil 434 or heating coil 436 and may correlate with the amount of energy consumed to achieve a desired supply air temperature. AHU 430 may control the temperature of supply air 410 and/or building zone 406 by activating or deactivating coils 434-436, adjusting a speed of fan 438, or a combination of both.

[0302] Still referring to FIG. 4, airside system 400 is shown to include a building management system (BMS) controller 466 and a client device 468. BMS controller 466 can include one or more computer systems (e.g., servers, supervisory controllers, subsystem controllers, etc.) that serve as system level controllers, application or data servers, head nodes, or master controllers for airside system 400, waterside system 300, HVAC system 200, and/or other controllable systems that serve building 10. BMS controller 466 may communicate with multiple downstream building systems or subsystems (e.g., HVAC system 200, a security system, a lighting system, waterside system 300, etc.) via a communications link 470 according to like or disparate protocols (e.g., LON, BACnet, etc.). In various embodiments, AHU controller 430 and BMS controller 466 can be separate (as shown in FIG. 4) or integrated. In an integrated implementation, AHU controller 430 can be a software module configured for execution by a processor of BMS controller 466.

[0303] In some embodiments, AHU controller 430 receives information from BMS controller 466 (e.g., commands, setpoints, operating boundaries, etc.) and provides information to BMS controller 466 (e.g., temperature measurements, valve or actuator positions, operating statuses, diagnostics, etc.). For example, AHU controller 430 may provide BMS controller 466 with temperature measurements from temperature sensors 462- 464, equipment on/off states, equipment operating capacities, and/or any other information that can be used by BMS controller 466 to monitor or control a variable state or condition within building zone 406.

[0304] Client device 468 can include one or more human-machine interfaces or client interfaces (e.g., graphical user interfaces, reporting interfaces, text-based computer interfaces, client-facing web services, web servers that provide pages to web clients, etc.) for

controlling, viewing, or otherwise interacting with HVAC system 200, its subsystems, and/or devices. Client device 468 can be a computer workstation, a client terminal, a remote or local interface, or any other type of user interface device. Client device 468 can be a stationary terminal or a mobile device. For example, client device 468 can 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 468 may communicate with BMS controller 466 and/or AHU controller 430 via communications link 472.

Building Management System

[0305] Referring now to FIG. 5, a block diagram of a building management system (BMS) 500 is shown, according to some embodiments. BMS 500 can be implemented in building 10 to automatically monitor and control various building functions. BMS 500 is shown to include BMS controller 466 and a plurality of building subsystems 528. Building subsystems 528 are shown to include a building electrical subsystem 534, an information communication technology (ICT) subsystem 536, a security subsystem 538, a HVAC subsystem 540, a lighting subsystem 542, a lift/escalators subsystem 532, and a fire safety subsystem 530. In various embodiments, building subsystems 528 can include fewer, additional, or alternative subsystems. For example, building subsystems 528 may also or alternatively include a refrigeration subsystem, an advertising or signage subsystem, a cooking subsystem, a vending subsystem, a printer or copy service subsystem, or any other type of building subsystem that uses controllable equipment and/or sensors to monitor or control building 10. In some embodiments, building subsystems 528 include waterside system 300 and/or airside system 400, as described with reference to FIGS. 3-4. [0306] Each of building subsystems 528 can include any number of devices (e.g., IoT devices), sensors, controllers, and connections for completing its individual functions and control activities. HVAC subsystem 540 can include many of the same components as HVAC system 200, as described with reference to FIGS. 2-4. For example, HVAC subsystem 540 can include a chiller, a boiler, any number of air handling units, economizers, field controllers, supervisory controllers, actuators, temperature sensors, and other devices for controlling the temperature, humidity, airflow, or other variable conditions within building 10. Lighting subsystem 542 can include any number of light fixtures, ballasts, lighting sensors, dimmers, or other devices configured to controllably adjust the amount of light provided to a building space. Security subsystem 538 can include occupancy sensors, video surveillance cameras, digital video recorders, video processing servers, intrusion detection devices, access control devices and servers, or other security-related devices.

[0307] Still referring to FIG. 5, BMS controller 466 is shown to include a communications interface 507 and a BMS interface 509. Interface 507 may facilitate communications between BMS controller 466 and external applications (e.g., monitoring and reporting applications 522, enterprise control applications 526, remote systems and applications 544, applications residing on client devices 548, etc.) for allowing user control, monitoring, and adjustment to BMS controller 466 and/or subsystems 528. Interface 507 may also facilitate communications between BMS controller 466 and client devices 548. BMS interface 509 may facilitate communications between BMS controller 466 and building subsystems 528 (e.g., HVAC, lighting security, lifts, power distribution, business, etc.).

[0308] Interfaces 507, 509 can be or include wired or wireless communications interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals, etc.) for conducting data communications with building subsystems 528 or other external systems or devices. In various embodiments, communications via interfaces 507, 509 can be direct (e.g., local wired or wireless communications) or via a communications network 546 (e.g., a WAN, the Internet, a cellular network, etc.). For example, interfaces 507, 509 can include an Ethernet card and port for sending and receiving data via an Ethernet-based communications link or network. In another example, interfaces 507, 509 can include a Wi-Fi transceiver for communicating via a wireless communications network. In another example, one or both of interfaces 507, 509 can include cellular or mobile phone communications transceivers. In one embodiment, communications interface 507 is a power line communications interface and BMS interface 509 is an Ethernet interface. In other embodiments, both communications interface 507 and BMS interface 509 are Ethernet interfaces or are the same Ethernet interface.

[0309] Still referring to FIG. 5, BMS controller 466 is shown to include a processing circuit 504 including a processor 506 and memory 508. Processing circuit 504 can be

communicably connected to BMS interface 509 and/or communications interface 507 such that processing circuit 504 and the various components thereof can send and receive data via interfaces 507, 509. Processor 506 can be implemented as a general purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components.

[0310] Memory 508 (e.g., memory, memory unit, storage device, etc.) can include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage, etc.) for storing data and/or computer code for completing or facilitating the various processes, layers and modules described in the present application. Memory 508 can be or include volatile memory or nonvolatile memory. Memory 508 can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present application. According to some embodiments, memory 508 is communicably connected to processor 506 via processing circuit 504 and includes computer code for executing (e.g., by processing circuit 504 and/or processor 506) one or more processes described herein.

[0311] In some embodiments, BMS controller 466 is implemented within a single computer (e.g., one server, one housing, etc.). In various other embodiments BMS controller 466 can be distributed across multiple servers or computers (e.g., that can exist in distributed locations). Further, while FIG. 4 shows applications 522 and 526 as existing outside of BMS controller 466, in some embodiments, applications 522 and 526 can be hosted within BMS controller 466 (e.g., within memory 508).

[0312] Still referring to FIG. 5, memory 508 is shown to include an enterprise integration layer 510, an automated measurement and validation (AM&V) layer 512, a demand response (DR) layer 514, a fault detection and diagnostics (FDD) layer 516, an integrated control layer 518, and a building subsystem integration later 520. Layers 510-520 can be configured to receive inputs from building subsystems 528 and other data sources, determine optimal control actions for building subsystems 528 based on the inputs, generate control signals based on the optimal control actions, and provide the generated control signals to building subsystems 528. The following paragraphs describe some of the general functions performed by each of layers 510-520 in BMS 500.

[0313] Enterprise integration layer 510 can be configured to serve clients or local applications with information and services to support a variety of enterprise-level

applications. For example, enterprise control applications 526 can be configured to provide subsystem-spanning control to a graphical user interface (GUI) or to any number of enterprise-level business applications (e.g., accounting systems, user identification systems, etc.). Enterprise control applications 526 may also or alternatively be configured to provide configuration GUIs for configuring BMS controller 466. In yet other embodiments, enterprise control applications 526 can work with layers 510-520 to optimize building performance (e.g., efficiency, energy use, comfort, or safety) based on inputs received at interface 507 and/or BMS interface 509.

[0314] Building subsystem integration layer 520 can be configured to manage

communications between BMS controller 466 and building subsystems 528. For example, building subsystem integration layer 520 may receive sensor data and input signals from building subsystems 528 and provide output data and control signals to building subsystems 528. Building subsystem integration layer 520 may also be configured to manage communications between building subsystems 528. Building subsystem integration layer 520 translates communications (e.g., sensor data, input signals, output signals, etc.) across a plurality of multi-vendor/multi-protocol systems.

[0315] Demand response layer 514 can be configured to determine (e.g., optimize) resource usage (e.g., electricity use, natural gas use, water use, etc.) and/or the monetary cost of such resource usage to satisfy the demand of building 10. The resource usage determination can be based on time-of-use prices, curtailment signals, energy availability, or other data received from utility providers, distributed energy generation systems 524, energy storage 527 (e.g., hot TES 342, cold TES 344, etc.), or from other sources. Demand response layer 514 may receive inputs from other layers of BMS controller 466 (e.g., building subsystem integration layer 520, integrated control layer 518, etc.). The inputs received from other layers can include environmental or sensor inputs such as temperature, carbon dioxide levels, relative humidity levels, air quality sensor outputs, occupancy sensor outputs, room schedules, and the like. The inputs may also include inputs such as electrical use (e.g., expressed in kWh), thermal load measurements, pricing information, projected pricing, smoothed pricing, curtailment signals from utilities, and the like.

[0316] According to some embodiments, demand response layer 514 includes control logic for responding to the data and signals it receives. These responses can include

communicating with the control algorithms in integrated control layer 518, changing control strategies, changing setpoints, or activating/deactivating building equipment or subsystems in a controlled manner. Demand response layer 514 may also include control logic configured to determine when to utilize stored energy. For example, demand response layer 514 may determine to begin using energy from energy storage 527 just prior to the beginning of a peak use hour.

[0317] In some embodiments, demand response layer 514 includes a control module configured to actively initiate control actions (e.g., automatically changing setpoints) which reduce (e.g., minimize) energy costs based on one or more inputs representative of or based on demand (e.g., price, a curtailment signal, a demand level, etc.). In some embodiments, demand response layer 514 uses equipment models to determine an optimal set of control actions. The equipment models can include, for example, thermodynamic models describing the inputs, outputs, and/or functions performed by various sets of building equipment.

Equipment models may represent collections of building equipment (e.g., subplants, chiller arrays, etc.) or individual devices (e.g., individual chillers, heaters, pumps, etc.).

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

[0319] Integrated control layer 518 can be configured to use the data input or output of building subsystem integration layer 520 and/or demand response later 514 to make control decisions. Due to the subsystem integration provided by building subsystem integration layer 520, integrated control layer 518 can integrate control activities of the subsystems 528 such that the subsystems 528 behave as a single integrated supersystem. In some embodiments, integrated control layer 518 includes control logic that uses inputs and outputs from a plurality of building subsystems to provide greater comfort and energy savings relative to the comfort and energy savings that separate subsystems could provide alone. For example, integrated control layer 518 can be configured to use an input from a first subsystem to make an energy-saving control decision for a second subsystem. Results of these decisions can be communicated back to building subsystem integration layer 520.

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

[0321] Integrated control layer 518 can be configured to provide feedback to demand response layer 514 so that demand response layer 514 checks that constraints (e.g., temperature, lighting levels, etc.) are properly maintained even while demanded load shedding is in progress. The constraints may also include setpoint or sensed boundaries relating to safety, equipment operating limits and performance, comfort, fire codes, electrical codes, energy codes, and the like. Integrated control layer 518 is also logically below fault detection and diagnostics layer 516 and automated measurement and validation layer 512. Integrated control layer 518 can be configured to provide calculated inputs (e.g.,

aggregations) to these higher levels based on outputs from more than one building subsystem. [0322] Automated measurement and validation (AM&V) layer 512 can be configured to verify that control strategies commanded by integrated control layer 518 or demand response layer 514 are working properly (e.g., using data aggregated by AM&V layer 512, integrated control layer 518, building subsystem integration layer 520, FDD layer 516, or otherwise). The calculations made by AM&V layer 512 can be based on building system energy models and/or equipment models for individual BMS devices or subsystems. For example, AM&V layer 512 may compare a model -predicted output with an actual output from building subsystems 528 to determine an accuracy of the model.

[0323] Fault detection and diagnostics (FDD) layer 516 can be configured to provide ongoing fault detection for building subsystems 528, building subsystem devices (i.e., building equipment), and control algorithms used by demand response layer 514 and integrated control layer 518. FDD layer 516 may receive data inputs from integrated control layer 518, directly from one or more building subsystems or devices, or from another data source. FDD layer 516 may automatically diagnose and respond to detected faults. The responses to detected or diagnosed faults can include providing an alert message to a user, a maintenance scheduling system, or a control algorithm configured to attempt to repair the fault or to workaround the fault.

[0324] FDD layer 516 can be configured to output a specific identification of the faulty component or cause of the fault (e.g., loose damper linkage) using detailed subsystem inputs available at building subsystem integration layer 520. In other exemplary embodiments, FDD layer 516 is configured to provide "fault" events to integrated control layer 518 which executes control strategies and policies in response to the received fault events. According to some embodiments, FDD layer 516 (or a policy executed by an integrated control engine or business rules engine) may shut-down systems or direct control activities around faulty devices or systems to reduce energy waste, extend equipment life, or assure proper control response.

[0325] FDD layer 516 can be configured to store or access a variety of different system data stores (or data points for live data). FDD layer 516 may use some content of the data stores to identify faults at the equipment level (e.g., specific chiller, specific AHU, specific terminal unit, etc.) and other content to identify faults at component or subsystem levels. For example, building subsystems 528 may generate temporal (i.e., time-series) data indicating the performance of BMS 500 and the various components thereof. The data generated by building subsystems 528 can include measured or calculated values that exhibit statistical characteristics and provide information about how the corresponding system or process (e.g., a temperature control process, a flow control process, etc.) is performing in terms of error from its setpoint. These processes can be examined by FDD layer 516 to expose when the system begins to degrade in performance and alert a user to repair the fault before it becomes more severe.

Building Management System With Cloud Building Management Platform

[0326] Referring now to FIG. 6, a block diagram of another building management system (BMS) 600 is shown, according to some embodiments. BMS 600 can be configured to collect data samples from building subsystems 528 and provide the data samples to Cloud building management platform 620 to generate raw timeseries data, derived timeseries data, and/or entity data from the data samples. In some embodiments, Cloud building management platform 620 may supplement or replace building management platform 102 shown in FIG. 1 or can be implemented separate from building management platform 102. Cloud building management platform 620 can process and transform the raw timeseries data to generate derived timeseries data. Throughout this disclosure, the term "derived timeseries data" is used to describe the result or output of a transformation or other timeseries processing operation performed by various services of the building management platform 620 (e.g., data aggregation, data cleansing, virtual point calculation, etc.). The term "entity data" is used to describe the attributes of various smart entities (e.g., IoT systems, devices, components, sensors, and the like) and the relationships between the smart entities. The derived timeseries data can be provided to various applications 630 and/or stored in storage 614 (e.g., as materialized views of the raw timeseries data). In some embodiments, Cloud building management platform 620 separates data collection; data storage, retrieval, and analysis; and data visualization into three different layers. This allows Cloud building management platform 620 to support a variety of applications 630 that use the derived timeseries data and allows new applications 630 to reuse the existing infrastructure provided by Cloud building management platform 620.

[0327] It should be noted that the components of BMS 600 and/or Cloud building management platform 620 can be integrated within a single device (e.g., a supervisory controller, a BMS controller, etc.) or distributed across multiple separate systems or devices. In other embodiments, some or all of the components of BMS 600 and/or Cloud building management platform 620 can be implemented as part of a cloud-based computing system configured to receive and process data from one or more building management systems. In other embodiments, some or all of the components of BMS 600 and/or Cloud building management platform 620 can be components of a subsystem level controller (e.g., a HVAC controller), a subplant controller, a device controller (e.g., AHU controller 330, a chiller controller, etc.), a field controller, a computer workstation, a client device, or any other system or device that receives and processes data from building systems and equipment.

[0328] BMS 600 can include many of the same components as BMS 500, as described with reference to FIG. 5. For example, BMS 600 is shown to include a BMS interface 602 and a communications interface 604. Interfaces 602-604 can include wired or wireless

communications interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals, etc.) for conducting data communications with building subsystems 528 or other external systems or devices. Communications conducted via interfaces 602-604 can be direct (e.g., local wired or wireless communications) or via a communications network 546 (e.g., a WAN, the Internet, a cellular network, etc.).

[0329] Communications interface 604 can facilitate communications between BMS 600 and external applications (e.g., remote systems and applications 544) for allowing user control, monitoring, and adjustment to BMS 600. Communications interface 604 can also facilitate communications between BMS 600 and client devices 548. BMS interface 602 can facilitate communications between BMS 600 and building subsystems 528. BMS 600 can be configured to communicate with building subsystems 528 using any of a variety of building automation systems protocols (e.g., BACnet, Modbus, ADX, etc.). In some embodiments, BMS 600 receives data samples from building subsystems 528 and provides control signals to building subsystems 528 via BMS interface 602.

[0330] Building subsystems 528 can include building electrical subsystem 534, information communication technology (ICT) subsystem 536, security subsystem 538, HVAC subsystem 540, lighting subsystem 542, lift/escalators subsystem 532, and/or fire safety subsystem 530, as described with reference to FIG. 5. In various embodiments, building subsystems 528 can include fewer, additional, or alternative subsystems. For example, building subsystems 528 can also or alternatively include a refrigeration subsystem, an advertising or signage subsystem, a cooking subsystem, a vending subsystem, a printer or copy service subsystem, or any other type of building subsystem that uses controllable equipment and/or sensors to monitor or control building 10. In some embodiments, building subsystems 528 include waterside system 300 and/or airside system 400, as described with reference to FIGS. 3-4. Each of building subsystems 528 can include any number of devices, controllers, and connections for completing its individual functions and control activities. Building subsystems 528 can include building equipment (e.g., sensors, air handling units, chillers, pumps, valves, etc.) configured to monitor and control a building condition such as temperature, humidity, airflow, etc.

[0331] Still referring to FIG. 6, BMS 600 is shown to include a processing circuit 606 including a processor 608 and memory 610. Cloud building management platform may include one or more processing circuits including one or more processors and memory. Each of the processor can be a general purpose or specific purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable processing components. Each of the processors is configured to execute computer code or instructions stored in memory or received from other computer readable media (e.g., CDROM, network storage, a remote server, etc.).

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

[0333] Still referring to FIG. 6, Cloud building management platform 620 is shown to include a data collector 612. Data collector 612 is shown receiving data samples from building subsystems 528 via BMS interface 602. However, the present disclosure is not limited thereto, and the data collector 612 may receive the data samples directly from the building subsystems 528 (e.g., via network 546 or via any suitable method). In some embodiments, the data samples include data values for various data points. The data values can be measured or calculated values, depending on the type of data point. For example, a data point received from a temperature sensor can include a measured data value indicating a temperature measured by the temperature sensor. A data point received from a chiller controller can include a calculated data value indicating a calculated efficiency of the chiller. Data collector 612 can receive data samples from multiple different devices (e.g., IoT devices, sensors, etc.) within building subsystems 528.

[0334] The data samples can include one or more attributes that describe or characterize the corresponding data points. For example, the data samples can include a name attribute defining a point name or ID (e.g., "B 1F4R2.T-Z"), a device attribute indicating a type of device from which the data samples is received (e.g., temperature sensor, humidity sensor, chiller, etc.), a unit attribute defining a unit of measure associated with the data value (e.g., °F, °C, kPA, etc.), and/or any other attribute that describes the corresponding data point or provides contextual information regarding the data point. The types of attributes included in each data point can depend on the communications protocol used to send the data samples to BMS 600 and/or Cloud building management platform 620. For example, data samples received via the ADX protocol or B ACnet protocol can include a variety of descriptive attributes along with the data value, whereas data samples received via the Modbus protocol may include a lesser number of attributes (e.g., only the data value without any corresponding attributes).

[0335] In some embodiments, each data sample is received with a timestamp indicating a time at which the corresponding data value was measured or calculated. In other

embodiments, data collector 612 adds timestamps to the data samples based on the times at which the data samples are received. Data collector 612 can generate raw timeseries data for each of the data points for which data samples are received. Each timeseries can include a series of data values for the same data point and a timestamp for each of the data values. For example, a timeseries for a data point provided by a temperature sensor can include a series of temperature values measured by the temperature sensor and the corresponding times at which the temperature values were measured. An example of a timeseries which can be generated by data collector 612 is as follows:

[< key, timestamp^ value ₁ >, < key, timestamp ₂ , value ₂ >,

< key, timestamp ₃ , value ₃ >] where key is an identifier of the source of the raw data samples (e.g., timeseries ID, sensor ID, device ID, etc.), timestampi identifies the time at which the ith sample was collected, and value _t indicates the value of the tth sample.

[0336] Data collector 612 can add timestamps to the data samples or modify existing timestamps such that each data sample includes a local timestamp. Each local timestamp indicates the local time at which the corresponding data sample was measured or collected and can include an offset relative to universal time. The local timestamp indicates the local time at the location the data point was measured at the time of measurement. The offset indicates the difference between the local time and a universal time (e.g., the time at the international date line). For example, a data sample collected in a time zone that is six hours behind universal time can include a local timestamp (e.g.,

Timestamp = 2016-03-18Γ14: 10: 02) and an offset indicating that the local timestamp is six hours behind universal time (e.g., Offset =—6: 00). The offset can be adjusted (e.g., + 1: 00 or— 1: 00) depending on whether the time zone is in daylight savings time when the data sample is measured or collected.

[0337] The combination of the local timestamp and the offset provides a unique timestamp across daylight saving time boundaries. This allows an application using the timeseries data to display the timeseries data in local time without first converting from universal time. The combination of the local timestamp and the offset also provides enough information to convert the local timestamp to universal time without needing to look up a schedule of when daylight savings time occurs. For example, the offset can be subtracted from the local timestamp to generate a universal time value that corresponds to the local timestamp without referencing an external database and without requiring any other information.

[0338] In some embodiments, data collector 612 organizes the raw timeseries data. Data collector 612 can identify a system or device associated with each of the data points. For example, data collector 612 can associate a data point with a temperature sensor, an air handler, a chiller, or any other type of system or device. In some embodiments, a data entity may be created for the data point, in which case, the data collector 612 (e.g., via entity service) can associate the data point with the data entity. In various embodiments, data collector uses the name of the data point, a range of values of the data point, statistical characteristics of the data point, or other attributes of the data point to identify a particular system or device associated with the data point. Data collector 612 can then determine how that system or device relates to the other systems or devices in the building site from entity data. For example, data collector 612 can determine that the identified system or device is part of a larger system (e.g., a HVAC system) or serves a particular space (e.g., a particular building, a room or zone of the building, etc.) from the entity data. In some embodiments, data collector 512 uses or retrieves an entity graph (e.g., via entity service 626) when organizing the timeseries data.

[0339] Data collector 612 can provide the raw timeseries data to the services of Cloud building management platform 620 and/or store the raw timeseries data in storage 614.

Storage 614 may be internal storage or external storage. For example, storage 614 can be internal storage with relation to Cloud building management platform 620 and/or BMS 600, and/or may include a remote database, cloud-based data hosting, or other remote data storage. Storage 614 can be configured to store the raw timeseries data obtained by data collector 612, the derived timeseries data generated by Cloud building management platform 620, and/or directed acyclic graphs (DAGs) used by Cloud building management platform 620 to process the timeseries data.

[0340] Still referring to FIG. 5, Cloud building management platform 620 can receive the raw timeseries data from data collector 612 and/or retrieve the raw timeseries data from storage 614. Cloud building management platform 620 can include a variety of services configured to analyze, process, and transform the raw timeseries data. For example, Cloud building management platform 620 is shown to include a security service 622, an analytics service 624, an entity service 626, and a timeseries service 628. Security service 622 can assign security attributes to the raw timeseries data to ensure that the timeseries data are only accessible to authorized individuals, systems, or applications. Security service 622 may include a messaging layer to exchange secure messages with the entity service 626. In some embodiment, security service 622 may provide permission data to entity service 626 so that entity service 626 can determine the types of entity data that can be accessed by a particular entity or device. Entity service 624 can assign entity information (or entity data) to the timeseries data to associate data points with a particular system, device, or space. Timeseries service 628 and analytics service 624 can apply various transformations, operations, or other functions to the raw timeseries data to generate derived timeseries data.

[0341] In some embodiments, timeseries service 628 aggregates predefined intervals of the raw timeseries data (e.g., quarter-hourly intervals, hourly intervals, daily intervals, monthly intervals, etc.) to generate new derived timeseries of the aggregated values. These derived timeseries can be referred to as "data rollups" since they are condensed versions of the raw timeseries data. The data rollups generated by timeseries service 628 provide an efficient mechanism for applications 630 to query the timeseries data. For example, applications 630 can construct visualizations of the timeseries data (e.g., charts, graphs, etc.) using the pre- aggregated data rollups instead of the raw timeseries data. This allows applications 630 to simply retrieve and present the pre-aggregated data rollups without requiring applications 630 to perform an aggregation in response to the query. Since the data rollups are pre-aggregated, applications 630 can present the data rollups quickly and efficiently without requiring additional processing at query time to generate aggregated timeseries values.

[0342] In some embodiments, timeseries service 628 calculates virtual points based on the raw timeseries data and/or the derived timeseries data. Virtual points can be calculated by applying any of a variety of mathematical operations (e.g., addition, subtraction,

multiplication, division, etc.) or functions (e.g., average value, maximum value, minimum value, thermodynamic functions, linear functions, nonlinear functions, etc.) to the actual data points represented by the timeseries data. For example, timeseries service 628 can calculate a virtual data point (pointID ₃ ) by adding two or more actual data points (pointlD-L and pointID ₂ ) (e.g., pointID ₃ = pointlD-L + pointID ₂ ). As another example, timeseries service 628 can calculate an enthalpy data point (pointID ₄ ) based on a measured temperature data point (pointID ₅ ) and a measured pressure data point (pointID ₆ ) (e.g., pointID ₄ = enthalpy (point I D ₅ , pointID ₆ )). The virtual data points can be stored as derived timeseries data.

[0343] Applications 630 can access and use the virtual data points in the same manner as the actual data points. Applications 630 may not need to know whether a data point is an actual data point or a virtual data point since both types of data points can be stored as derived timeseries data and can be handled in the same manner by applications 630. In some embodiments, the derived timeseries are stored with attributes designating each data point as either a virtual data point or an actual data point. Such attributes allow applications 630 to identify whether a given timeseries represents a virtual data point or an actual data point, even though both types of data points can be handled in the same manner by applications 630. These and other features of timeseries service 628 are described in greater detail with reference to FIG. 9. [0344] In some embodiments, analytics service 624 analyzes the raw timeseries data and/or the derived timeseries data to detect faults. Analytics service 624 can apply a set of fault detection rules to the timeseries data to determine whether a fault is detected at each interval of the timeseries. Fault detections can be stored as derived timeseries data. For example, analytics service 624 can generate a new fault detection timeseries with data values that indicate whether a fault was detected at each interval of the timeseries. The fault detection timeseries can be stored as derived timeseries data along with the raw timeseries data in storage 614.

[0345] Still referring to FIG. 6, BMS 600 is shown to include several applications 630 including an energy management application 632, monitoring and reporting applications 634, and enterprise control applications 636. Although only a few applications 630 are shown, it is contemplated that applications 630 can include any of a variety of suitable applications configured to use the raw or derived timeseries generated by Cloud building management platform 620. In some embodiments, applications 630 exist as a separate layer of BMS 600 (e.g., a part of Cloud building management platform 620 and/or data collector 612). In other embodiments, applications 630 can exist as remote applications that run on remote systems or devices (e.g., remote systems and applications 544, client devices 548, and/or the like).

[0346] Applications 630 can use the derived timeseries data to perform a variety data visualization, monitoring, and/or control activities. For example, energy management application 632 and monitoring and reporting application 634 can use the derived timeseries data to generate user interfaces (e.g., charts, graphs, etc.) that present the derived timeseries data to a user. In some embodiments, the user interfaces present the raw timeseries data and the derived data rollups in a single chart or graph. For example, a dropdown selector can be provided to allow a user to select the raw timeseries data or any of the data rollups for a given data point.

[0347] Enterprise control application 636 can use the derived timeseries data to perform various control activities. For example, enterprise control application 636 can use the derived timeseries data as input to a control algorithm (e.g., a state-based algorithm, an extremum seeking control (ESC) algorithm, a proportional-integral (PI) control algorithm, a

proportional-integral-derivative (PID) control algorithm, a model predictive control (MPC) algorithm, a feedback control algorithm, etc.) to generate control signals for building subsystems 528. In some embodiments, building subsystems 528 use the control signals to operate building equipment. Operating the building equipment can affect the measured or calculated values of the data samples provided to BMS 600 and/or Cloud building

management platform 620. Accordingly, enterprise control application 636 can use the derived timesenes data as feedback to control the systems and devices of building subsystems 528.

Cloud Building Management Platform Entity Service

[0348] Referring now to FIG. 7, a block diagram illustrating entity service 626 in greater detail is shown, according to some embodiments. Entity service 626 registers and manages various buildings (e.g., 110-140), spaces, persons, subsystems (e.g., 428), devices (e.g., 112- 146), and other entities in the Cloud building management platform 620. According to various embodiments, an entity may be any person, place, or physical object, hereafter referred to as an object entity. Further, an entity may be any event, data point, or record structure, hereinafter referred to as data entity. In addition, relationships between entities may be defined by relational objects.

[0349] In some embodiments, an object entity may be defined as having at least three types of attributes. For example, an object entity may have a static attribute, a dynamic attribute, and a behavioral attribute. The static attribute may include any unique identifier of the object entity or characteristic of the object entity that either does not change over time or changes infrequently (e.g., a device ID, a person's name or social security number, a place's address or room number, and the like). The dynamic attribute may include a property of the object entity that changes over time (e.g., location, age, measurement, data point, and the like). In some embodiments, the dynamic attribute of an object entity may be linked to a data entity. In this case, the dynamic attribute of the object entity may simply refer to a location (e.g., data/network address) or static attribute (e.g., identifier) of the linked data entity, which may store the data (e.g., the value or information) of the dynamic attribute. Accordingly, in some such embodiments, when a new data point (e.g., timeseries data) is received for the object entity, only the linked data entity may be updated, while the object entity remains unchanged. Therefore, resources that would have been expended to update the object entity may be reduced.

[0350] However, the present disclosure is not limited thereto. For example, in some embodiments, there may also be some data that is updated (e.g., during predetermined intervals) in the dynamic attribute of the object entity itself. For example, the linked data entity may be configured to be updated each time a new data point is received, whereas the corresponding dynamic attribute of the object entity may be configured to be updated less often (e.g., at predetermined intervals less than the intervals during which the new data points are received). In some implementations, the dynamic attribute of the object entity may include both a link to the data entity and either a portion of the data from the data entity or data derived from the data of the data entity. For example, in an embodiment in which periodic temperature readings are received from a thermostat, an object entity corresponding to the thermostat could include the last temperature reading and a link to a data entity that stores a series of the last ten temperature readings received from the thermostat.

[0351] The behavioral attribute may define a function of the object entity, for example, based on inputs, capabilities, and/or permissions. For example, behavioral attributes may define the types of inputs that the object entity is configured to accept, how the object entity is expected to respond under certain conditions, the types of functions that the object entity is capable of performing, and the like. As a non-limiting example, if the object entity represents a person, the behavioral attribute of the person may be his/her job title or job duties, user permissions to access certain systems or locations, expected location or behavior given a time of day, tendencies or preferences based on connected activity data received by entity service 626 (e.g., social media activity), and the like. As another non-limiting example, if the object entity represents a device, the behavioral attributes may include the types of inputs that the device can receive, the types of outputs that the device can generate, the types of controls that the device is capable of, the types of software or versions that the device currently has, known responses of the device to certain types of input (e.g., behavior of the device defined by its programming), and the like.

[0352] In some embodiments, the data entity may be defined as having at least a static attribute and a dynamic attribute. The static attribute of the data entity may include a unique identifier or description of the data entity. For example, if the data entity is linked to a dynamic attribute of an object entity, the static attribute of the data entity may include an identifier that is used to link to the dynamic attribute of the object entity. In some

embodiments, the dynamic attribute of the data entity represents the data for the dynamic attribute of the linked object entity. In some embodiments, the dynamic attribute of the data entity may represent some other data that is derived, analyzed, inferred, calculated, or determined based on data from a plurality of data sources.

[0353] In some embodiments, the relational object may be defined as having at least a static attribute. The static attribute of the relational object may semantically define the type of relationship between two or more entities. For example, in a non-limiting embodiment, a relational object for a relationship that semantically defines that Entity A has a part of Entity B, or that Entity B is a part of Entity A may include: hasPart{ Entity A, Entity B} where the static attribute hasPart defines what the relationship is of the listed entities, and the order of the listed entities or data field of the relational object specifies which entity is the part of the other (e.g., Entity A→ hasPart→ Entity B).

[0354] In various embodiments, the relational object is an object-oriented construct with predefined fields that define the relationship between two or more entities, regardless of the type of entities. For example, Cloud building management platform 620 can provide a rich set of pre-built entity models with standardized relational objects that can be used to describe how any two or more entities are semantically related, as well as how data is exchanged and/or processed between the entities. Accordingly, a global change to a definition or relationship of a relational object at the system level can be effected at the object level, without having to manually change the entity relationships for each object or entity individually. Further, in some embodiments, a global change at the system level can be propagated through to third-party applications integrated with Cloud building management platform 620 such that the global change can be implemented across all of the third-party applications without requiring manual implementation of the change in each disparate application.

[0355] For example, referring to FIG. 8, an example entity graph of entity data is shown, according to some embodiments. The term "entity data" is used to describe the attributes of various entities and the relationships between the entities. For example, entity data may be represented in the form of an entity graph. In some embodiments, entity data includes any suitable predefined data models (e.g., as a table, JSON data, and/or the like), such as entity type or object, and further includes one or more relational objects that semantically define the relationships between the entities. The relational objects may help to semantically define, for example, hierarchical or directed relationships between the entities (e.g., entity X controls entity Y, entity A feeds entity B, entity 1 is located in entity 2, and the like). For example, an object entity (e.g., IoT device) may be represented by entity type or object, which generally describes how data corresponding to the entity will be structured and stored.

[0356] For example, an entity type (or object) "Thermostat" may be represented via the below schema:

Thermostat{

Type,

Model No,

Device Name,

Manufactured date,

Serial number,

MAC address,

Location,

Current air quality,

Current indoor temperature,

Current outdoor temperature,

Target indoor temperature,

Point schedule (e.g., BACnet schedule object)

} where various attributes are static attributes (e.g., "Type," "Model Number," "Device Name," etc.,), dynamic attributes (e.g., "Current air quality," "Current outdoor temperature," etc.), or behavioral attributes (e.g., "Target indoor temperature," etc.) for the object entity

"thermostat." In a relational database, the object "Thermostat" is a table name, and the attributes represents column names.

[0357] An example of an object entity data model for a person named John Smith in a relational database may be represented by the below table:

where various attributes are static attributes (e.g., "First Name," "Last Name," etc.,), dynamic attributes (e.g., "Age," "Location," etc.), or behavioral attributes (e.g., "Engineer") for the object entity "John Smith."

[0358] An example data entity for the data point "Current indoor temperature" for the "Thermostat" owned by John Smith in a relational database may be represented by the below table:

where various attributes are static attributes (e.g., "Description" and "Device Type") and dynamic attributes (e.g., "Present- Value").

[0359] While structuring the entities via entity type or object may help to define the data representation of the entities, these data models do not provide information on how the entities relate to each other. For example, a BMS, building subsystem, or device may need data from a plurality of sources as well as information on how the sources relate to each other in order to provide a proper decision, action, or recommendation. Accordingly, in various embodiments, the entity data further includes the relational objects to semantically define the relationships between the entities, which may help to increase speeds in analyzing data, as well as provide ease of navigation and browsing.

[0360] For example, still referring to FIG. 8, an entity graph 800 for the Thermostat object entity 802 includes various class entities (e.g., User, Address, SetPoint Command, and Temperature Object), object entities (e.g., John and Thermostat), relational objects (e.g., isAKindOf, Owns, isLinked, hasStorage, and hasOperation), and data entities (AI 201-01, TS ID 1, Daily Average 1, Abnormal indoor temp 1, AO 101-1, and Geo 301-01). The relational objects describe the relationships between the various class, object, and data entities in a semantic and syntactic manner, so that an application or user viewing the entity graph 800 can quickly determine the relationships and data process flow of the Thermostat object entity 802, without having to resort to a data base analyst or engineer to create, index, and/or manage the entities (e.g., using SQL or NoSQL). In some embodiments, each of the entities (e.g., class entity, object entity, and data entity) represents a node on the entity graph 800, and the relational objects define the relationships or connections between the entities (or nodes). [0361] For example, the entity graph 800 shows that a person named John (object entity) 804 isAKindOf (relational object) 806 User (class entity) 808. John 804 Owns (relational object) 810 the Thermostat (object entity) 802. The Thermostat 802 has a location attribute (dynamic attribute) 812 that isLinked (relational object) 814 to Geo 301-01 (data entity) 816, which isAKindOf (relational object) 818 an Address (class entity) 820. Accordingly, Geo 301-01 316 should have a data point corresponding to an address.

[0362] The Thermostat 802 further includes a "Current indoor temperature" attribute (dynamic attribute) 822 that isLinked (relational object) 824 to AI 201-01 (data entity) 826. AI 201-01 826 isAKindOf (relational object) 828 Temperature Object (class entity) 830. Thus, AI 201-01 826 should contain some sort of temperature related data. AI 201-01 826 hasStorage (relational object) 832 at TS ID 1 (data entity) 834, which may be raw or derived timeseries data for the temperature readings. AI 201-01 826 hasOperation (relational object) 836 of Daily Average 1 (data entity) 838, which isAKindOf (relational object) 840 Analytic Operator (class entity) 842. Thus, Daily Average 1 results from an analytic operation that calculates the daily average of the indoor temperature. AI 201-01 826 further hasOperation (relational object) 854 of Abnormal Indoor Temperature (data entity) 856, which isAKindOf (relational object) 858 Analytic Operator (class entity) 860. Accordingly, Abnormal Indoor Temperature results from an analytic operation to determine an abnormal temperature (e.g., exceeds or falls below a threshold value).

[0363] In this example, the data entity AI 201-01 526 may be represented by the following data model: point {

name: "AI 201-01";

type: "analog input";

value: 72;

unit: "Degree-F";

source: "Temperature Sensor 1"

} where "point" is an example of a data entity that may be created by Cloud building management platform 620 to hold the value for the linked "Current indoor temperature" 822 dynamic attribute of the Thermostat entity 802, and source is the sensor or device in the Thermostat device that provides the data to the linked "Current indoor temperature" 822 dynamic attribute.

[0364] The data entity TS Id 1 534 may be represented, for example, by the following data model: timeseries {

name: "TS Id 1";

type: "Daily Average";

values: "[68, 20666, 70, 69, 71];

unit: "Degree-F";

point: "AI 201-01";

source: "Daily Average 1"

} where the data entity Daily Average 1 838 represents a specific analytic operator used to create the data entity for the average daily timeseries TS Id 1 834 based on the values of the corresponding data entity for point AI 201-01 826. The relational object hasOperation shows that the AI 201-01 data entity 826 is used as an input to the specific logic/math operation represented by Daily Average 1 838. TS Id 1 834 might also include an attribute that identifies the analytic operator Daily Average 1 838 as the source of the data samples in the timeseries.

[0365] Still referring to FIG. 8, the entity graph 800 for Thermostat 802 shows that the "Target indoor temperature" attribute (dynamic attribute) 844 isLinked (relational attribute) 846 to the data entity AO 101-01 (data entity) 848. AO 101-01 data entity 848 isAKindOf (relational attribute) 850 SetPoint Command (class entity) 852. Thus, the data in data entity AO 101-01 848 may be set via a command by the user or other entity, and may be used to control the Thermostat object entity 802. Accordingly, in various embodiments, entity graph 800 provides a user friendly view of the various relationships between the entities and data processing flow, which provides for ease of navigation, browsing, and analysis of data.

[0366] In some embodiments, any two entities (or nodes) can be connected to each other via one or more relational objects that define different relationships between the two entities (or nodes). For example, still referring to FIG. 8, the object entity John 804 is shown to be connected to the object entity Thermostat 802 via one relational object Owns 810. However, in another embodiment, the object entity John 804 can be connected to the object entity Thermostat 802 via more than one relational object, such that, in addition to the relational object Owns 810, another relational object can define another relationship between the object entity John 804 and the object entity Activity Tracker 802. For example, another relational object such as isInZone or isNotlnZone can define whether or not John (or the entity object for John 804) is currently within the zone serviced by Thermostat 802 (e.g., via the relational object isInZone) or currently not within the zone serviced by Thermostat 802 (e.g., via the relational object isNotlnZone).

[0367] In this case, when the data entities associated with the thermostat object entity 802 indicates that John is within the zone serviced by thermostat (e.g., which may be determined from the location attribute 812 and location data for John 810), the relational object isInZone may be created between the object entity for John 610 and the object entity for thermostat 802. On the other hand, when the data entities associated with the thermostat object entity 802 indicates that John is not within the zone serviced by the thermostat (e.g., which may be determined when the location attribute 812 shows a different location from a known location of John), the relational object isNotlnZone can be created between the object entity for John 810 and the object entity for thermostat 802. For example, the relational object isNotlnZone can be created by modifying the relational object isInZone or deleting the relational object isInZone and creating the relational object isNotlnZone. Thus, in some embodiments, the relational objects can be dynamically created, modified, or deleted as needed or desired.

[0368] Referring again to FIG. 7, entity service 626 may transforms raw data samples and/or raw timeseries data into data corresponding to entity data. For example, as discussed above with reference to FIG. 8, entity service 626 can create data entities that use and/or represent data points in the timeseries data. Entity service 626 includes a web service 702, a registration service 704, a management service 706, a transformation service 708, a search service 710, and storage 712. In some embodiments, storage 712 may be internal storage or external storage. For example, storage 712 may be storage 614 (see FIG. 6), internal storage with relation to entity service 626, and/or may include a remote database, cloud-based data hosting, or other remote data storage.

[0369] Web service 702 can be configured to interact with web-based applications to send entity data and/or receive raw data (e.g., data samples, timeseries data, and the like). For example, web service 702 can provide an interface (e.g., API, UI/UX, and the like) to manage (e.g., register, create, edit, delete, and/or update) an entity (e.g., class entity, object entity, data entity, and/or the like) and the relational objects that define the relationships between the entities. In some embodiments, web service 702 provides entity data to web-based applications. For example, if one or more of applications 630 are web-based applications, web service 702 can provide entity data to the web-based applications. In some

embodiments, web service 702 receives raw data samples and/or raw timeseries data including device information from a web-based data collector, or a web-based security service to identify authorized entities and to exchange secured messages. For example, if data collector 612 is a web-based application, web service 702 can receive the raw data samples and/or timeseries data including a device attribute indicating a type of device (e.g., IoT device) from which the data samples and/or timeseries data are received from data collector 612. In some embodiments, web service 702 may message security service 622 to request authorization information and/or permission information of a particular user, building, BMS, building subsystem, device, application, or other entity. In some

embodiments, web service 702 receives derived timeseries data from timeseries service 628, and/or may provide entity data to timeseries service 628. In some embodiments, the entity service 626 processes and transforms the collected data to generate the entity data.

[0370] The registration service 704 can perform registration of devices and entities. For example, registration service 704 can communicate with building subsystems 528 and client devices 548 (e.g., via web service 702) to register each entity (e.g., building, BMS, building subsystems, devices, and the like) with Cloud building management platform 620. In some embodiments, registration service 704 registers a particular building subsystem 528 (or the devices therein) with a specific user and/or a specific set of permissions and/or entitlements. For example, a user may register a device key and/or a device ID associated with the device via a web portal (e.g., web service 702). In some embodiments, the device ID and the device key may be unique to the device. The device ID may be a unique number associated with the device such as a unique alphanumeric string, a serial number of the device, and/or any other static identifier. In various embodiments, the device is provisioned by a manufacturer and/or any other entity. In various embodiments, the device key and/or device ID are saved to the device or building subsystem 528 based on whether the device includes a trusted platform module (TPM). If the device includes a TPM, the device or building subsystem 528 may store the device key and/or device ID according to the protocols of the TPM. If the device does not include a TPM, the device or building subsystem 528 may store the device key and/or device ID in a file and/or file field which may be stored in a secure storage location. Further, in some embodiments, the device ID may be stored with BIOS software of the device. For example, a serial number of BIOS software may become and/or may be updated with the device ID.

[0371] In various embodiments, the device key and/or the device ID are uploaded to registration service 704 (e.g., an IoT hub such as AZURE® IoT Hub). In some

embodiments, registration service 704 is configured to store the device key and the device ID in secure permanent storage and/or may be stored by security service 622 (e.g., by a security API). In some embodiments, a manufacturer and/or any other individual may register the device key and the device ID with registration service 704 (e.g., via web service 702). In various embodiments, the device key and the device ID are linked to a particular profile associated with the building subsystem 528 or device and/or a particular user profile (e.g., a particular user). In this regard, a device (or building subsystem 528) can be associated with a particular user. In various embodiments, the device key and the device ID make up the profile for device. The profile may be registered as a device that has been manufactured and/or provisioned but has not yet been purchased by an end user.

[0372] In various embodiments, registration service 704 adds and/or updates a device in an building hub device registry. In various embodiments, registration service 704 may determine if the device is already registered, can set various authentication values (e.g., device ID, device key), and can update the building hub device registry. In a similar manner, registration service 704 can update a document database with the various device registration information.

[0373] In some embodiments, registration service 704 can be configured to create a virtual representation (e.g., "digital twins" or "shadow records") of each object entity (e.g., person, room, building subsystem, device, and the like) in the building within Cloud building management platform 620. In some embodiments, the virtual representations are smart entities that include attributes defining or characterizing the corresponding object and are associated to the corresponding object entity via relational objects defining the relationship of the object and the smart entity representation thereof. In some embodiments, the virtual representations maintain shadow copies of the object entities with versioning information so that entity service 626 can store not only the most recent update of an attribute (e.g., a dynamic attribute) associated with the object, but records of previous states of the attributes (e.g., dynamic attributes) and/or entities. For example, the shadow record may be created as a type of data entity that is related to a linked data entity corresponding to the dynamic attribute of the object entity (e.g., the person, room, building subsystem, device, and the like). For example, the shadow entity may be associated with the linked data entity via a relational object (e.g., isLinked, hasStorage, hasOperation, and the like ). In this case, the shadow entity may be used to determine additional analytics for the data point of the dynamic attribute. For example, the shadow entity may be used to determine an average value, an expected value, or an abnormal value of the data point from the dynamic attribute.

[0374] Management service 706 may create, modify, or update various attributes, data entities, and/or relational objects of the objects managed by entity service 626 for each entity rather than per class or type of entity. This allows for separate processing/analytics for each individual entity rather than only to a class or type of entity. Some attributes (or data entities) may correspond to, for example, the most recent value of a data point provided to BMS 600 or Cloud building management platform 620 via the raw data samples and/or timeseries data. For example, the "Current indoor temperature" dynamic attribute of the "Thermostat" object entity 802 in the example discussed above may be the most recent value of indoor

temperature provided by the Thermostat device. Management service 706 can use the relational objects of the entity data for Thermostat to determine where to update the data of the attribute.

[0375] For example, Management service 706 may determine that a data entity (e.g., AI 201-01) is linked to the "Current indoor temperature" dynamic attribute of Thermostat via an isLinked relational object. In this case, Management service 706 may automatically update the attribute data in the linked data entity. Further, if a linked data entity does not exist, Management service 706 can create a data entity (e.g., AI 201-01) and an instance of the isLinked relational object 824 to store and link the "Current indoor temperature" dynamic attribute of Thermostat therein. Accordingly, processing/analytics for Thermostat 802 may be automated. As another example, a "most recent view" attribute (or linked data entity) of a webpage object entity may indicate the most recent time at which the webpage was viewed. Management service 706 can use the entity data from a related click tracking system object entity or web server object entity to determine when the most recent view occurred and can automatically update the "most recent view" attribute (or linked data entity) of the webpage entity accordingly. [0376] Other data entities and/or attributes may be created and/or updated as a result of an analytic, transformation, calculation, or other processing operation based on the raw data and/or entity data. For example, Management service 706 can use the relational objects in entity data to identify a related access control device (e.g., a card reader, a keypad, etc.) at the entrance/exit of a building object entity. Management service 706 can use raw data received from the identified access control device to track the number of occupants entering and exiting the building object entity (e.g., via related card entities used by the occupants to enter and exit the building). Management service 706 can update a "number of occupants" attribute (or corresponding data entity) of the building object entity each time a person enters or exits the building using a related card object entity, such that the "number of occupants" attribute (or data entity) reflects the current number of occupants within the building (or related building object entity). As another example, a "total revenue" attribute associated with a product line object entity may be the summation of all the revenue generated from related point of sales entities. Management service 706 can use the raw data received from the related point of sales entities to determine when a sale of the product occurs, and can identify the amount of revenue generated by the sales. Management service 706 can then update the "total revenue" attribute (or related data entity) of the product line object entity by adding the most recent sales revenue from each of the related point of sales entities to the previous value of the attribute.

[0377] In some embodiments, management service 706 may use derived timeseries data generated from timeseries service 628 to update or create a data entity (e.g., Daily Average 1) that uses or stores the data points in the derived timeseries data. For example, the derived timeseries data may include a virtual data point corresponding to the daily average steps calculated by timeseries service 628, and management service 706 may update the data entity or entities that store or use the data corresponding to the virtual data point as determined via the relational objects. In some embodiments, if a data entity corresponding to the virtual data point does not exist, management service 706 may automatically create a corresponding data entity and one or more relational objects that describe the relationship between the corresponding data entity and other entities.

[0378] In some embodiments, management service 706 uses entity data and/or raw data from multiple different data sources to update the attributes (or corresponding data entities) of various object entities. For example, an object entity representing a person (e.g., a person's cellular device or other related object entity) may include a "risk" attribute that quantifies the person's level of risk attributable to various physical, environmental, or other conditions. Management service 706 can use relational objects of the person object entity to identify a related card device and/or a related card reader from a related building object entity (e.g., the building in which the person works) to determine the physical location of the person at any given time. Management service 706 can determine from raw data (e.g., time that the card device was scanned by the card reader) or derived timeseries data (e.g., average time of arrival) whether the person object is located in the building or may be in transit to the building. Management service 706 can use weather data from a weather service in the region in which the building object entity is located to determine whether any severe weather is approaching the person's location. Similarly, management service 706 can use building data from related building entities of the building object entity to determine whether the building in which the person is located is experiencing any emergency conditions (e.g., fire, building lockdown, etc.) or environmental hazards (e.g., detected air contaminants, pollutants, extreme temperatures, etc.) that could increase the person's level of risk. Management service 706 can use these and other types of data as inputs to a risk function that calculates the value of the person object's "risk" attribute and can update the person object (or related device entity of the person object) accordingly.

[0379] In some embodiments, management service 706 can be configured to synchronize configuration settings, parameters, and other device-specific or object-specific information between the entities and Cloud building management platform 620. In some embodiments, the synchronization occurs asynchronously. Management service 706 can be configured to manage device properties dynamically. The device properties, configuration settings, parameters, and other device-specific information can be synchronized between the smart entities created by and stored within Cloud building management platform 620.

[0380] In some embodiments, management service 706 is configured to manage a manifest for each of the building subsystems 528 (or devices therein). The manifest may include a set of relationships between the building subsystems 528 and various entities. Further, the manifest may indicate a set of entitlements for the building subsystems 528 and/or entitlements of the various entities and/or other entities. The set of entitlements may allow a BMS 600, building subsystem 528 and/or a user to perform certain actions within the building or (e.g., control, configure, monitor, and/or the like). [0381] Still referring to FIG. 7, transformation service 708 can provide data virtualization, and can transform various predefined standard data models for entities in a same class or type to have the same entity data structure, regardless of the object, device, or Thing that the entity represents. For example, each object entity under an object class may include a location attribute, regardless of whether or not the location attribute is used or even generated. Thus, if an application is later developed requiring that each object entity includes a location attribute, manual mapping of heterogenous data of different entities in the same class may be avoided. Accordingly, interoperability and scalability of applications may be improved.

[0382] In some embodiments, transformation service 708 can provide entity matching, cleansing, and correlation so that a unified cleansed view of the entity data including the entity related information (e.g., relational objects) can be provided. Transformation service 708 can support semantic and syntactic relationship description in the form of standardized relational objects between the various entities. This may simplify machine learning because the relational objects themselves provide all the relationship description between the entities. Accordingly, the rich set of pre-built entity models and standardized relational objects may provide for rapid application development and data analytics.

[0383] Still referring to FIG. 7, the search service 710 provides a unified view of product related information in the form of the entity graph, which correlates entity relationships (via relational objects) among multiple data sources (e.g., CRM, ERP, MRP and the like). In some embodiments, the search service 710 is based on a schema-less and graph based indexing architecture. For example, in some embodiments, the search service 710 provides the entity graph in which the entities are represented as nodes with relational objects defining the relationship between the entities (or nodes). The search service 710 facilitates simple queries without having to search multiple levels of the hierarchical tree of the entity graph. For example, search service 710 can return results based on searching of entity type, individual entities, attributes, or even relational objects without requiring other levels or entities of the hierarchy to be searched.

Timeseries Data Platform Service

[0384] Referring now to FIG. 9, a block diagram illustrating timeseries service 628 in greater detail is shown, according to some embodiments. Timeseries service 628 is shown to include a timeseries web service 902, an events service 903, a timeseries processing engine 904, and a timeseries storage interface 916. Timeseries web service 902 can be configured to interact with web-based applications to send and/or receive timeseries data. In some embodiments, timeseries web service 902 provides timeseries data to web-based applications. For example, if one or more of applications 630 are web-based applications, timeseries web service 902 can provide derived timeseries data and/or raw timeseries data to the web-based applications. In some embodiments, timeseries web service 902 receives raw timeseries data from a web-based data collector. For example, if data collector 612 is a web-based application, timeseries web service 902 can receive raw data samples or raw timeseries data from data collector 612. In some embodiments, timeseries web service 902 and entity service web service 702 may be integrated as parts of the same web service.

[0385] Timeseries storage interface 916 can be configured to store and read samples of various timeseries (e.g., raw timeseries data and derived timeseries data) and eventseries (described in greater detail below). Timeseries storage interface 916 can interact with storage 614. For example, timeseries storage interface 916 can retrieve timeseries data from a timeseries database 928 within storage 614. In some embodiments, timeseries storage interface 916 reads samples from a specified start time or start position in the timeseries to a specified stop time or a stop position in the timeseries. Similarly, timeseries storage interface 916 can retrieve eventseries data from an eventseries database 929 within storage 614.

Timeseries storage interface 916 can also store timeseries data in timeseries database 928 and can store eventseries data in eventseries database 929. Advantageously, timeseries storage interface 916 provides a consistent interface which enables logical data independence.

[0386] In some embodiments, timeseries storage interface 916 stores timeseries as lists of data samples, organized by time. For example, timeseries storage interface 916 can store timeseries in the following format:

[< key, timestamp-L, value >, < key, timestamp ₂ , value ₂ >,

< key, timestamp ₃ , value ₃ >] where key is an identifier of the source of the data samples (e.g., timeseries ID, sensor ID, device ID, etc.), timestampi identifies a time associated with the ith sample, and valuei indicates the value of the tth sample. [0387] In some embodiments, timeseries storage interface 916 stores eventseries as lists of events having a start time, an end time, and a state. For example, timeseries storage interface 916 can store eventseries in the following format:

[< eventl D _lt start Jimestamp^ end Jimestamp^ state-L >, ... ,

< eventl D _N , start _time stamp _N , end _time stamp _N , state _N >] where eventl D _t is an identifier of the tth event, sta.rt_timesta.mpi is the time at which the tth event started, endjimestampi is the time at which the tth event ended, state _t describes a state or condition associated with the tth event (e.g., cold, hot, warm, etc.), and N is the total number of events in the eventseries.

[0388] In some embodiments, timeseries storage interface 916 stores timeseries and eventseries in a tabular format. Timeseries storage interface 916 can store timeseries and eventseries in various tables having a column for each attribute of the timeseries/eventseries samples (e.g., key, timestamp, value). The timeseries tables can be stored in timeseries database 928, whereas the eventseries tables can be stored in eventseries database 929. In some embodiments, timeseries storage interface 916 caches older data to storage 614 but stores newer data in RAM. This may improve read performance when the newer data are requested for processing.

[0389] In some embodiments, timeseries storage interface 916 omits one or more of the attributes when storing the timeseries samples. For example, timeseries storage interface 916 may not need to repeatedly store the key or timeseries ID for each sample in the timeseries. In some embodiments, timeseries storage interface 916 omits timestamps from one or more of the samples. If samples of a particular timeseries have timestamps at regular intervals (e.g., one sample each minute), timeseries storage interface 916 can organize the samples by timestamps and store the values of the samples in a row. The timestamp of the first sample can be stored along with the interval between the timestamps. Timeseries storage interface 916 can determine the timestamp of any sample in the row based on the timestamp of the first sample and the position of the sample in the row.

[0390] In some embodiments, timeseries storage interface 916 stores one or more samples with an attribute indicating a change in value relative to the previous sample value. The change in value can replace the actual value of the sample when the sample is stored in timeseries database 928. This allows timeseries storage interface 916 to use fewer bits when storing samples and their corresponding values. Timeseries storage interface 916 can determine the value of any sample based on the value of the first sample and the change in value of each successive sample.

[0391] In some embodiments, timeseries storage interface 916 invokes entity service 626 to create data entities in which samples of timeseries data and/or eventseries data can be stored. The data entities can include JSON objects or other types of data objects to store one or more timeseries samples and/or eventseries samples. Timeseries storage interface 916 can be configured to add samples to the data entities and read samples from the data entities. For example, timeseries storage interface 916 can receive a set of samples from data collector 612, entity service 626, timeseries web service 902, events service 903, and/or timeseries processing engine 904. Timeseries storage interface 916 can add the set of samples to a data entity by sending the samples to entity service 626 to be stored in the data entity, for example, or may directly interface with the data entity to add/modify the sample to the data entity.

[0392] Timeseries storage interface 916 can use data entities when reading samples from storage 614. For example, timeseries storage interface 916 can retrieve a set of samples from storage 614 or from entity service 626, and add the samples to a data entity (e.g., directly or via entity service 626). In some embodiments, the set of samples include all samples within a specified time period (e.g., samples with timestamps in the specified time period) or eventseries samples having a specified state. Timeseries storage interface 916 can provide the samples in the data entity to timeseries web service 902, events service 903, timeseries processing engine 904, applications 630, and/or other components configured to use the timeseries/eventseries samples.

[0393] Still referring to FIG. 9, timeseries processing engine 904 is shown to include several timeseries operators 906. Timeseries operators 906 can be configured to apply various operations, transformations, or functions to one or more input timeseries to generate output timeseries and/or eventseries. The input timeseries can include raw timeseries data and/or derived timeseries data. Timeseries operators 906 can be configured to calculate aggregate values, averages, or apply other mathematical operations to the input timeseries. In some embodiments, timeseries operators 906 generate virtual point timeseries by combining two or more input timeseries (e.g., adding the timeseries together), creating multiple output timeseries from a single input timeseries, or applying mathematical operations to the input timeseries. In some embodiments, timeseries operators 906 perform data cleansing operations or deduplication operations on an input timeseries. In some embodiments, timeseries operators 906 use the input timeseries to generate eventseries based on the values of the timeseries samples. The output timeseries can be stored as derived timeseries data in storage 614 as one or more timeseries data entities. Similarly, the eventseries can be stored as eventseries data entities in storage 614.

[0394] In some embodiments, timeseries operators 906 do not change or replace the raw timeseries data, but rather generate various "views" of the raw timeseries data (e.g., as separate data entities) with corresponding relational objects defining the relationships between the raw timeseries data entity and the various views data entities. The views can be queried in the same manner as the raw timeseries data. For example, samples can be read from the raw timeseries data entity, transformed to create the view entity, and then provided as an output. Because the transformations used to create the views can be computationally expensive, the views can be stored as "materialized view" data entities in timeseries database 928. Instances of relational objects can be created to define the relationship between the raw timeseries data entity and the materialize view data entities. These materialized views are referred to as derived data timeseries throughout the present disclosure.

[0395] Timeseries operators 906 can be configured to run at query time (e.g., when a request for derived data timeseries is received) or prior to query time (e.g., when new raw data samples are received, in response to a defined event or trigger, etc.). This flexibility allows timeseries operators 906 to perform some or all of their operations ahead of time and/or in response to a request for specific derived data timeseries. For example, timeseries operators 906 can be configured to pre-process one or more timeseries that are read frequently to ensure that the timeseries are updated whenever new data samples are received, and the pre-processed timeseries may be stored in a corresponding data entity for retrieval. However, timeseries operators 906 can be configured to wait until query time to process one or more timeseries that are read infrequently to avoid performing unnecessary processing operations.

[0396] In some embodiments, timeseries operators 906 are triggered in a particular sequence defined by a directed acyclic graph (DAG). The DAG may define a workflow or sequence of operations or transformations to apply to one or more input timeseries. For example, the DAG for a raw data timeseries may include a data cleansing operation, an aggregation operation, and a summation operation (e.g., adding two raw data timeseries to create a virtual point timeseries). The DAGs can be stored in a DAG database 930 within storage 614, or internally within timeseries processing engine 904. DAGs can be retrieved by workflow manager 922 and used to determine how and when to process incoming data samples. Exemplary systems and methods for creating and using DAGs are described in greater detail below.

[0397] Timeseries operators 906 can perform aggregations for dashboards, cleansing operations, logical operations for rules and fault detection, machine learning predictions or classifications, call out to external services, or any of a variety of other operations which can be applied to timeseries data. The operations performed by timeseries operators 906 are not limited to timeseries data. Timeseries operators 906 can also operate on event data or function as a billing engine for a consumption or tariff-based billing system. Timeseries operators 906 are shown to include a sample aggregator 908, a virtual point calculator 910, a weather point calculator 912, a fault detector 914, and an eventseries generator 915.

[0398] Still referring to FIG. 9, timeseries processing engine 904 is shown to include a DAG optimizer 918. DAG optimizer 918 can be configured to combine multiple DAGs or multiple steps of a DAG to improve the efficiency of the operations performed by timeseries operators 906. For example, suppose that a DAG has one functional block which adds "Timeseries A" and "Timeseries B" to create "Timeseries C" (i.e., A + B = C) and another functional block which adds "Timeseries C" and "Timeseries D" to create "Timeseries E" (i.e., C + D = E). DAG optimizer 918 can combine these two functional blocks into a single functional block which computes "Timeseries E" directly from "Timeseries A," "Timeseries B," and "Timeseries D" (i.e., E = A + B + D). Alternatively, both "Timeseries C" and "Timeseries E" can be computed in the same functional block to reduce the number of independent operations required to process the DAG.

[0399] In some embodiments, DAG optimizer 918 combines DAGs or steps of a DAG in response to a determination that multiple DAGs or steps of a DAG will use similar or shared inputs (e.g., one or more of the same input timeseries). This allows the inputs to be retrieved and loaded once rather than performing two separate operations that both load the same inputs. In some embodiments, DAG optimizer 918 schedules timeseries operators 906 to nodes where data is resident in memory in order to further reduce the amount of data required to be loaded from the timeseries database 928. [0400] Timeseries processing engine 904 is shown to include a directed acyclic graph (DAG) generator 920. DAG generator 920 can be configured to generate one or more DAGs for each raw data timeseries. Each DAG may define a workflow or sequence of operations which can be performed by timeseries operators 906 on the raw data timeseries. When new samples of the raw data timeseries are received, workflow manager 922 can retrieve the corresponding DAG and use the DAG to determine how the raw data timeseries should be processed. In some embodiments, the DAGs are declarative views which represent the sequence of operations applied to each raw data timeseries. The DAGs may be designed for timeseries rather than structured query language (SQL).

[0401] In some embodiments, DAGs apply over windows of time. For example, the timeseries processing operations defined by a DAG may include a data aggregation operation that aggregates a plurality of raw data samples having timestamps within a given time window. The start time and end time of the time window may be defined by the DAG and the timeseries to which the DAG is applied. The DAG may define the duration of the time window over which the data aggregation operation will be performed. For example, the DAG may define the aggregation operation as an hourly aggregation (i.e., to produce an hourly data rollup timeseries), a daily aggregation (i.e., to produce a daily data rollup timeseries), a weekly aggregation (i.e., to produce a weekly data rollup timeseries), or any other aggregation duration. The position of the time window (e.g., a specific day, a specific week, etc.) over which the aggregation is performed may be defined by the timestamps of the data samples of timeseries provided as an input to the DAG.

[0402] In operation, sample aggregator 908 can use the DAG to identify the duration of the time window (e.g., an hour, a day, a week, etc.) over which the data aggregation operation will be performed. Sample aggregator 908 can use the timestamps of the data samples in the timeseries provided as an input to the DAG to identify the location of the time window (i.e., the start time and the end time). Sample aggregator 908 can set the start time and end time of the time window such that the time window has the identified duration and includes the timestamps of the data samples. In some embodiments, the time windows are fixed, having predefined start times and end times (e.g., the beginning and end of each hour, day, week, etc.). In other embodiments, the time windows may be sliding time windows, having start times and end times that depend on the timestamps of the data samples in the input timeseries. [0403] FIG. 10 shows a flow diagram of a process or method for updating/creating a data entity based on data received from a device of a building subsystem, according to some embodiments. Referring to FIG. 10, the process starts, and when timeseries data (e.g., raw or input timeseries data) that has been generated for a device of a building subsystem (e.g., by the data collector) is received, the transformation service 708 may determine an identifier of the device from the received timeseries data at block 1005. At block 1010, the

transformation service 708 may compare an identity static attribute from the data with identity static attributes of registered object entities to locate a data container for the device. If a match does not exist from the comparison at block 1015, the transformation service 708 may invoke the registration service to register the device at block 1020. If a match exists from the comparison at block 1015, the transformation service 708 may generate an entity graph or retrieve entity data for the device at block 1025. From the entity graph or entity data, transformation service 708 may determine if a corresponding data entity exists based on the relational objects (e.g., isLinked) for the device to update a dynamic attribute from the data at block 1025. If not, management service 706 may create a data entity for the dynamic attribute and an instance of a corresponding relational object (e.g., isLinked) to define the relationship between the dynamic attribute and created data entity at block 1040. If the corresponding data entity exists, management service 706 may update the data entity corresponding to the dynamic attribute from the data at block 1045. Then, transformation service 708 may update or regenerate the entity graph or entity data at block 1050, and the process may end.

[0404] FIG. 11 is an example entity graph of entity data according to an embodiment of the present disclosure. The example of FIG. 11 assumes that an HVAC fault detection application has detected an abnormal temperature measurement with respect to Temperature Sensor 1112. However, Temperature Sensor 1112 itself may be operating properly, but may rely on various factors, conditions, and other systems and devices to measure the temperature properly. Accordingly, for example, the HVAC fault detection application may need to know the room 1114 in which the Temperature Sensor 1112 is located, the corresponding temperature setpoint, the status of the VAV 1104 that supplies conditioned air to the room 1114, the status of the AHU 1102 that feeds the VAV 1104, the status of the vents in the HVAC zone 1110, etc., in order to pin point the cause of the abnormal measurement. Thus, the HVAC fault detection application may require additional information from various related subsystems and devices (e.g., entity objects), as well as the zones and rooms (e.g., entity objects) that the subsystems and devices are configured to serve, to properly determine or infer the cause of the abnormal measurement.

[0405] Referring to FIG. 11, entity graph 1100 represents each of the entities (e.g., Temperature Sensor 1112 and related entities) as nodes on the entity graph 1100, and shows the relationship between the nodes (e.g., Temperature Sensor 1112 and related entities) via relational objects (e.g., feeds, hasPoint, hasPart, Controls, etc.). For example, entity graph 1100 shows that Temperature Sensor 1112 provides temperature readings (e.g., hasPoint) to the VAV 1104 and the HVAC Zone 1110. An AHU 1102 provides (e.g., feeds) the VAV 1104 with chilled and/or heated air. The AHU 1102 receives/provides power readings (e.g., hasPoint) from/to a Power Meter 1108. The VAV 1104 provides (e.g., feeds) air to HVAC Zone 1110 using (e.g., hasPart) a Damper 1106. The HVAC Zone 1110 provides the air to Room 1114. Further, Rooms 1114 and 1120 are located in (e.g., hasPart) Lighting Zone 1118, which is controlled (e.g., controls) by Lighting Controller 1116.

[0406] Accordingly, in the example of FIG. 11, in response to receiving the faulty measurement from Temperature Sensor 1 112, the HVAC fault detection application and/or analytics service 624 can determine from the entity graph that the fault could be caused by some malfunction in one or more of the other related entities, and not necessarily a malfunction of the Temperature Sensor 1112. Thus, the HVAC fault detection application and/or the analytics service 624 can further investigate into the other related entities to determine or infer the most likely cause of the fault.

[0407] For example, FIG. 12 is a flow diagram of a process or method for analyzing data from a second related device based on data from a first device, according to some

embodiments. Referring to FIG. 12, the process starts and timeseries data (e.g., raw or input timeseries data generated by data collector) including an abnormal measurement from a first device is received at block 1205. Transformation service 708 determines an identifier of the first device from the received timeseries data at block 1210. Transformation service 708 identifies a second device that is related to the first device through relational objects associated with the first device at block 1215. The second device can be part of the same building subsystem as that of the first device or different building subsystem, and can be for a same building as that of the first device or different building. Transformation service 708 invokes web service 702 to retrieve measurement data from the second device at block 1220. Analytics service 624 analyzes the data from the first device and the second device at block 1225. Analytics service 624 provides a recommendation from the analysis of the data from each of the first device and the second device at block 1230, and the process ends.

[0408] FIG. 13 is a flow diagram of a process or method for generating derived timeseries from data generated by a first device and a second device, according to some embodiments. Referring to FIG. 13, the process starts and raw data is received from a first device of a building management subsystem at block 1305. The raw data may include one or more data points generated by the first device. For example, the data points may be measurement values generated by the first device. The data collector 612 generates raw (or input) timeseries from the raw data at block 1310. The raw timeseries may include an identifier of the first device, a timestamp (e.g., a local timestamp) of when the one or more data points were generated by the first device and an offset value, and a value of the one or more data points.

[0409] Transformation service 708 determines an identifier of the first device from the raw timeseries data, and identifies (e.g., using entity graph or data) a first object entity

representing the first device at block 1315. The raw timeseries data is stored in a

corresponding data entity that is related to the first object entity at block 1320. For example, transformation service 708 may identify the corresponding data entity from a relational object defining the relationship between the first object entity and the corresponding data entity.

[0410] Timeseries processing engine 904 identifies a processing workflow (e.g., a DAG processing workflow) to process the raw timeseries data at block 1325. In the example of FIG. 13, the processing workflow takes as input, the raw timeseries data for the first device, and data from a second device. The second device can be part of the same building subsystem as that of the first device or different building subsystem, and can be for a same building as that of the first device or different building. A second object entity for the second device is identified at block 1330. For example, the second object entity may be determined from a relational object indicating a relationship between the first object entity and the second object entity. A corresponding data entity storing raw or derived timeseries data for the second device is identified at block 1335. For example, the corresponding data entity may be determined from a relational descriptor indicating a relationship between the second object entity and the corresponding data entity. [0411] The processing workflow is executed to generate the derived timeseries at block 1340. For example, the derived timeseries may include a virtual data point that is calculated using data from the first device and the second device. For example, an arithmetic operation may be performed on the data of the first and second devices to calculate the virtual data point. A corresponding data entity is identified to store the derived timeseries. For example, the corresponding data entity may be identified through one or more relational objects indicating a relationship between the corresponding data entity and the first device and/or the corresponding data entity and the second device. The derived timeseries is stored in the corresponding data entity at block 1345, and the process ends.

Sample Aggregation

[0412] Referring now to FIGS. 14-15, a block diagram 1400 and a data table 1450 illustrating an aggregation technique which can be used by sample aggregator 908 is shown, according to some embodiments. In FIG. 14, a data point 1402 is shown. Data point 1402 is an example of a measured data point for which timeseries values can be obtained. For example, data point 1402 is shown as an outdoor air temperature point and has values which can be measured by a temperature sensor. Although a specific type of data point 1402 is shown in FIG. 14, it should be understood that data point 1402 can be any type of measured or calculated data point. Timeseries values of data point 1402 can be collected by data collector 612 and assembled into a raw data timeseries 1404.

[0413] As shown in FIG. 15, the raw data timeseries 1404 includes a timeseries of data samples, each of which is shown as a separate row in data table 1450. Each sample of raw data timeseries 1404 is shown to include a timestamp and a data value. The timestamps of raw data timeseries 1404 are ten minutes and one second apart, indicating that the sampling interval of raw data timeseries 1404 is ten minutes and one second. For example, the timestamp of the first data sample is shown as 2015-12-31Γ23: 10: 00 indicating that the first data sample of raw data timeseries 1404 was collected at 11 : 10:00 PM on December 31, 2015. The timestamp of the second data sample is shown as 2015-12-31Γ23: 20: 01 indicating that the second data sample of raw data timeseries 1404 was collected at 11 :20:01 PM on December 31, 2015. In some embodiments, the timestamps of raw data timeseries 1404 are stored along with an offset relative to universal time, as previously described. The values of raw data timeseries 1404 start at a value of 10 and increase by 10 with each sample. For example, the value of the second sample of raw data timeseries 1404 is 20, the value of the third sample of raw data timeseries 1404 is 30, etc.

[0414] In FIG. 14, several data rollup timeseries 1406-1414 are shown. Data rollup timeseries 1406-1414 can be generated by sample aggregator 908 and stored as derived timeseries data. The data rollup timeseries 1406-1414 include an average quarter-hour timeseries 1406, an average hourly timeseries 1408, an average daily timeseries 1410, an average monthly timeseries 1412, and an average yearly timeseries 1414. Each of the data rollup timeseries 1406-1414 is dependent upon a parent timeseries. In some embodiments, the parent timeseries for each of the data rollup timeseries 1406-1414 is the timeseries with the next shortest duration between consecutive timeseries values. For example, the parent timeseries for average quarter-hour timeseries 1406 is raw data timeseries 1404. Similarly, the parent timeseries for average hourly timeseries 1408 is average quarter-hour timeseries 1406; the parent timeseries for average daily timeseries 1410 is average hourly timeseries 1408; the parent timeseries for average monthly timeseries 1412 is average daily timeseries 1410; and the parent timeseries for average yearly timeseries 1414 is average monthly timeseries 1412.

[0415] Sample aggregator 908 can generate each of the data rollup timeseries 1406-1414 from the timeseries values of the corresponding parent timeseries. For example, sample aggregator 908 can generate average quarter-hour timeseries 1406 by aggregating all of the samples of data point 1402 in raw data timeseries 1404 that have timestamps within each quarter-hour. Similarly, sample aggregator 908 can generate average hourly timeseries 1408 by aggregating all of the timeseries values of average quarter-hour timeseries 1406 that have timestamps within each hour. Sample aggregator 908 can generate average daily timeseries 1410 by aggregating all of the time series values of average hourly timeseries 1408 that have timestamps within each day. Sample aggregator 908 can generate average monthly timeseries 1412 by aggregating all of the time series values of average daily timeseries 1410 that have timestamps within each month. Sample aggregator 908 can generate average yearly timeseries 1414 by aggregating all of the time series values of average monthly timeseries 1412 that have timestamps within each year.

[0416] In some embodiments, the timestamps for each sample in the data rollup timeseries 1406-1414 are the beginnings of the aggregation interval used to calculate the value of the sample. For example, the first data sample of average quarter-hour timeseries 1406 is shown to include the timestamp 2015-12-31Γ23: 00: 00. This timestamp indicates that the first data sample of average quarter-hour timeseries 1406 corresponds to an aggregation interval that begins at 11 :00:00 PM on December 31, 2015. Since only one data sample of raw data timeseries 1404 occurs during this interval, the value of the first data sample of average quarter-hour timeseries 1406 is the average of a single data value (i.e., average{ SS) = 10). The same is true for the second data sample of average quarter-hour timeseries 1406 (i.e., average (20) = 20).

[0417] The third data sample of average quarter-hour timeseries 1406 is shown to include the timestamp 2015-12-31Γ23: 30: 00. This timestamp indicates that the third data sample of average quarter-hour timeseries 1406 corresponds to an aggregation interval that begins at 11 :30:00 PM on December 31, 2015. Since each aggregation interval of average quarter- hour timeseries 1406 is a quarter-hour in duration, the end of the aggregation interval is 11 :45:00 PM on December 31, 2015. This aggregation interval includes two data samples of raw data timeseries 1404 (i.e., the third raw data sample having a value of 30 and the fourth raw data sample having a value of 40). Sample aggregator 908 can calculate the value of the third sample of average quarter-hour timeseries 1406 by averaging the values of the third raw data sample and the fourth raw data sample (i.e., average(30, 40) = 35). Accordingly, the third sample of average quarter-hour timeseries 1406 has a value of 35. Sample aggregator 908 can calculate the remaining values of average quarter-hour timeseries 1406 in a similar manner.

[0418] Still referring to FIG. 15, the first data sample of average hourly timeseries 1408 is shown to include the timestamp 2015-12-31Γ23: 00: 00. This timestamp indicates that the first data sample of average hourly timeseries 1408 corresponds to an aggregation interval that begins at 11 :00:00 PM on December 31, 2015. Since each aggregation interval of average hourly timeseries 1408 is an hour in duration, the end of the aggregation interval is 12:00:00 AM on January 1, 2016. This aggregation interval includes the first four samples of average quarter-hour timeseries 1406. Sample aggregator 908 can calculate the value of the first sample of average hourly timeseries 1408 by averaging the values of the first four values of average quarter-hour timeseries 1406 (i.e., average(10, 20, 35, 50) = 28.8).

Accordingly, the first sample of average hourly timeseries 1408 has a value of 28.8. Sample aggregator 908 can calculate the remaining values of average hourly timeseries 1408 in a similar manner. [0419] The first data sample of average daily timeseries 1410 is shown to include the timestamp 2015-12-31Γ00: 00: 00. This timestamp indicates that the first data sample of average daily timeseries 1410 corresponds to an aggregation interval that begins at 12:00:00 AM on December 31, 2015. Since each aggregation interval of the average daily timeseries 1410 is a day in duration, the end of the aggregation interval is 12:00:00 AM on January 1, 2016. Only one data sample of average hourly timeseries 1408 occurs during this interval. Accordingly, the value of the first data sample of average daily timeseries 1410 is the average of a single data value (i.e., average(28.8) = 28.8). The same is true for the second data sample of average daily timeseries 1410 (i.e., average(Ql .5) = 87.5).

[0420] In some embodiments, sample aggregator 908 stores each of the data rollup timeseries 1406-1414 in a single data table (e.g., data table 1450) along with raw data timeseries 1404. This allows applications 630 to retrieve all of the timeseries 1404-1414 quickly and efficiently by accessing a single data table. In other embodiments, sample aggregator 908 can store the various timeseries 1404-1414 in separate data tables which can be stored in the same data storage device (e.g., the same database) or distributed across multiple data storage devices. In some embodiments, sample aggregator 908 stores data timeseries 1404-1414 in a format other than a data table. For example, sample aggregator 908 can store timeseries 1404-1414 as vectors, as a matrix, as a list, or using any of a variety of other data storage formats.

[0421] In some embodiments, sample aggregator 908 automatically updates the data rollup timeseries 1406-1414 each time a new raw data sample is received. Updating the data rollup timeseries 1406-1414 can include recalculating the aggregated values based on the value and timestamp of the new raw data sample. When a new raw data sample is received, sample aggregator 908 can determine whether the timestamp of the new raw data sample is within any of the aggregation intervals for the samples of the data rollup timeseries 1406-1414. For example, if a new raw data sample is received with a timestamp of 2016-01-01Γ00: 52: 00, sample aggregator 908 can determine that the new raw data sample occurs within the aggregation interval beginning at timestamp 2016-01-01Γ00: 45: 00 for average quarter- hour timeseries 1406. Sample aggregator 908 can use the value of the new raw data point (e.g., value = 120) to update the aggregated value of the final data sample of average quarter-hour timeseries 1406 (i.e., aver age (110, 120) = 115). [0422] If the new raw data sample has a timestamp that does not occur within any of the previous aggregation intervals, sample aggregator 908 can create a new data sample in average quarter-hour timeseries 1406. The new data sample in average quarter-hour timeseries 1406 can have a new data timestamp defining the beginning of an aggregation interval that includes the timestamp of the new raw data sample. For example, if the new raw data sample has a timestamp of 2016-01-01Γ01: 00: 11, sample aggregator 908 can determine that the new raw data sample does not occur within any of the aggregation intervals previously established for average quarter-hour timeseries 1406. Sample aggregator 908 can generate a new data sample in average quarter-hour timeseries 1406 with the timestamp 2016-01-01Γ01: 00: 00 and can calculate the value of the new data sample in average quarter-hour timeseries 1406 based on the value of the new raw data sample, as previously described.

[0423] Sample aggregator 908 can update the values of the remaining data rollup timeseries 1408-414 in a similar manner. For example, sample aggregator 908 determine whether the timestamp of the updated data sample in average quarter-hour timeseries is within any of the aggregation intervals for the samples of average hourly timeseries 1408. Sample aggregator 908 can determine that the timestamp 2016-01-01Γ00: 45: 00 occurs within the aggregation interval beginning at timestamp 2016-01-01Γ00: 00: 00 for average hourly timeseries 1408. Sample aggregator 908 can use the updated value of the final data sample of average quarter- hour timeseries 1406 (e.g., value = 115) to update the value of the second sample of average hourly timeseries 1408 (i.e., average(6S, 80, 95, 115) = 88.75). Sample aggregator 908 can use the updated value of the final data sample of average hourly timeseries 1408 to update the final sample of average daily timeseries 1410 using the same technique.

[0424] In some embodiments, sample aggregator 908 updates the aggregated data values of data rollup timeseries 1406-1414 each time a new raw data sample is received. Updating each time a new raw data sample is received ensures that the data rollup timeseries 1406- 1414 always reflect the most recent data samples. In other embodiments, sample aggregator 908 updates the aggregated data values of data rollup timeseries 1406-1414 periodically at predetermined update intervals (e.g., hourly, daily, etc.) using a batch update technique. Updating periodically can be more efficient and require less data processing than updating each time a new data sample is received, but can result in aggregated data values that are not always updated to reflect the most recent data samples.

[0425] In some embodiments, sample aggregator 908 is configured to cleanse raw data timeseries 1404. Cleansing raw data timeseries 1404 can include discarding exceptionally high or low data. For example, sample aggregator 908 can identify a minimum expected data value and a maximum expected data value for raw data timeseries 1404. Sample aggregator 908 can discard data values outside this range as bad data. In some embodiments, the minimum and maximum expected values are based on attributes of the data point represented by the timeseries. For example, data point 1402 represents a measured outdoor air temperature and therefore has an expected value within a range of reasonable outdoor air temperature values for a given geographic location (e.g., between -20 °F and 110 °F). Sample aggregator 908 can discard a data value of 330 for data point 1402 since a temperature value of 330 °F is not reasonable for a measured outdoor air temperature.

[0426] In some embodiments, sample aggregator 908 identifies a maximum rate at which a data point can change between consecutive data samples. The maximum rate of change can be based on physical principles (e.g., heat transfer principles), weather patterns, or other parameters that limit the maximum rate of change of a particular data point. For example, data point 1402 represents a measured outdoor air temperature and therefore can be constrained to have a rate of change less than a maximum reasonable rate of change for outdoor temperature (e.g., five degrees per minute). If two consecutive data samples of the raw data timeseries 1404 have values that would require the outdoor air temperature to change at a rate in excess of the maximum expected rate of change, sample aggregator 908 can discard one or both of the data samples as bad data.

[0427] Sample aggregator 908 can perform any of a variety of data cleansing operations to identify and discard bad data samples. In some embodiments, sample aggregator 908 performs the data cleansing operations for raw data timeseries 1404 before generating the data rollup timeseries 1406-1414. This ensures that raw data timeseries 1404 used to generate data rollup timeseries 1406-1414 does not include any bad data samples.

Accordingly, the data rollup timeseries 1406-1414 do not need to be re-cleansed after the aggregation is performed. Virtual Points

[0428] Referring again to FIG. 9, timeseries operators 906 are shown to include a virtual point calculator 910. Virtual point calculator 910 is configured to create virtual data points and calculate timeseries values for the virtual data points. A virtual data point is a type of calculated data point derived from one or more actual data points. In some embodiments, actual data points are measured data points, whereas virtual data points are calculated data points. Virtual data points can be used as substitutes for 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, a virtual data point representing the enthalpy of a refrigerant can be calculated using actual data points measuring the temperature and pressure of the refrigerant. Virtual data points can also be used to provide timeseries values for calculated quantities such as efficiency, coefficient of performance, and other variables that cannot be directly measured.

[0429] Virtual point calculator 910 can calculate virtual data points by applying any of a variety of mathematical operations or functions to actual data points or other virtual data points. For example, virtual point calculator 910 can calculate a virtual data point (pointID ₃ ) by adding two or more actual data points (pointlD-L and pointID ₂ ) (e.g., pointID ₃ = pointlD-L + pointID ₂ ). As another example, virtual point calculator 910 can calculate an enthalpy data point (pointID ₄ ) based on a measured temperature data point (pointID ₅ ) and a measured pressure data point (pointID ₆ ) (e.g., pointID ₄ =

enthalpy (point I D ₅ , pointID ₆ )). In some instances, a virtual data point can be derived from a single actual data point. For example, virtual point calculator 910 can calculate a saturation temperature (pointID ₇ ) of a known refrigerant based on a measured refrigerant pressure (pointID ₈ ) (e.g., pointID ₇ = T _sat (pointID ₈ )). In general, virtual point calculator 910 can calculate the timeseries values of a virtual data point using the timeseries values of one or more actual data points and/or the timeseries values of one or more other virtual data points.

[0430] In some embodiments, virtual point calculator 910 uses a set of virtual point rules to calculate the virtual data points. The virtual point rules can define one or more input data points (e.g., actual or virtual data points) and the mathematical operations that should be applied to the input data point(s) to calculate each virtual data point. The virtual point rules can be provided by a user, received from an external system or device, and/or stored in memory 610. Virtual point calculator 910 can apply the set of virtual point rules to the timeseries values of the input data points to calculate timeseries values for the virtual data points. The timeseries values for the virtual data points can be stored as derived timeseries data in timeseries database 928.

[0431] Virtual point calculator 910 can calculate virtual data points using the values of raw data timeseries 1404 and/or the aggregated values of the data rollup timeseries 1406-1414. In some embodiments, the input data points used to calculate a virtual data point are collected at different sampling times and/or sampling rates. Accordingly, the samples of the input data points may not be synchronized with each other, which can lead to ambiguity in which samples of the input data points should be used to calculate the virtual data point. Using the data rollup timeseries 1406-1414 to calculate the virtual data points ensures that the timestamps of the input data points are synchronized and eliminates any ambiguity in which data samples should be used.

[0432] Referring now to FIG. 16, several timeseries 1600, 1620, 1640, and 1660 illustrating the synchronization of data samples resulting from aggregating the raw timeseries data are shown, according to some embodiments. Timeseries 1600 and 1620 are raw data timeseries. Raw data timeseries 1600 has several raw data samples 1602-1610. Raw data sample 1602 is collected at time t ; raw data sample 1604 is collected at time t ₂ ; raw data sample 1606 is collected at time t ₃ ; raw data sample 1608 is collected at time t ₄ ; raw data sample 1610 is collected at time t ₅ ; and raw data sample 1612 is collected at time t ₆ .

[0433] Raw data timeseries 1620 also has several raw data samples 1622, 1624, 1626, 1628, and 1630. However, raw data samples, 1622-1630 are not synchronized with raw data samples 1602-1612. For example, raw data sample 1622 is collected before time t ; raw data sample 1624 is collected between times t ₂ and t ₃ ; raw data sample 1626 is collected between times t ₃ and t ₄ ; raw data sample 1628 is collected between times t ₄ and t ₅ ; and raw data sample 1630 is collected between times t ₅ and t ₆ . The lack of synchronization between data samples 1602-1612 and raw data samples 1622-1630 can lead to ambiguity in which of the data samples should be used together to calculate a virtual data point.

[0434] Timeseries 1640 and 1660 are data rollup timeseries. Data rollup timeseries 1640 can be generated by sample aggregator 908 by aggregating raw data timeseries 1600.

Similarly, data rollup timeseries 1660 can be generated by sample aggregator 908 by aggregating raw data timeseries 1620. Both raw data timeseries 1600 and 1620 can be aggregated using the same aggregation interval. Accordingly, the resulting data rollup timeseries 1640 and 1660 have synchronized data samples. For example, aggregated data sample 1642 is synchronized with aggregated data sample 1662 at time t^ . Similarly, aggregated data sample 1644 is synchronized with aggregated data sample 1664 at time t ₂ '; aggregated data sample 1646 is synchronized with aggregated data sample 1666 at time t ₃ > and aggregated data sample 1648 is synchronized with aggregated data sample 1668 at time

[0435] The synchronization of data samples in data rollup timeseries 1640 and 1660 allows virtual point calculator 910 to readily identify which of the data samples should be used together to calculate a virtual point. For example, virtual point calculator 910 can identify which of the samples of data rollup timeseries 1640 and 1660 have the same timestamp (e.g., data samples 1642 and 1662, data samples 1644 and 1664, etc.). Virtual point calculator 910 can use two or more aggregated data samples with the same timestamp to calculate a timeseries value of the virtual data point. In some embodiments, virtual point calculator 910 assigns the shared timestamp of the input data samples to the timeseries value of the virtual data point calculated from the input data samples.

Weather Points

[0436] Referring again to FIG. 9, timeseries operators 906 are shown to include a weather point calculator 912. Weather point calculator 912 is configured to perform weather-based calculations using the timeseries data. In some embodiments, weather point calculator 912 creates virtual data points for weather-related variables such as cooling degree days (CDD), heating degree days (HDD), cooling energy days (CED), heating energy days (HED), and normalized energy consumption. The timeseries values of the virtual data points calculated by weather point calculator 912 can be stored as derived timeseries data in timeseries database 928.

[0437] Weather point calculator 912 can calculate CDD by integrating the positive temperature difference between the time-varying outdoor air temperature T _0A and the cooling balance point T _bc as shown in the following equation: where period is the integration period. In some embodiments, the outdoor air temperature T _0A is a measured data point, whereas the cooling balance point T _bc is a stored parameter. To calculate CDD for each sample of the outdoor air temperature T _0A , weather point calculator 912 can multiply the quantity max{0, (T _0A — T _bc )} by the sampling period At of the outdoor air temperature T _0A . Weather point calculator 912 can calculate CED in a similar manner using outdoor air enthalpy E _0A instead of outdoor air temperature T _0A . Outdoor air enthalpy E _0A can be a measured or virtual data point.

[0438] Weather point calculator 912 can calculate HDD by integrating the positive temperature difference between a heating balance point T _bH and the time-varying outdoor air temperature T _0A as shown in the following equation: where period is the integration period. In some embodiments, the outdoor air temperature T _0A is a measured data point, whereas the heating balance point T _bH is a stored parameter. To calculate HDD for each sample of the outdoor air temperature T _0A , weather point calculator 912 can multiply the quantity max{0, (T _bH — T _0A )} by the sampling period At of the outdoor air temperature T _0A . Weather point calculator 912 can calculate HED in a similar manner using outdoor air enthalpy E _0A instead of outdoor air temperature T _0A .

[0439] In some embodiments, both virtual point calculator 910 and weather point calculator 912 calculate timeseries values of virtual data points. Weather point calculator 912 can calculate timeseries values of virtual data points that depend on weather-related variables (e.g., outdoor air temperature, outdoor air enthalpy, outdoor air humidity, outdoor light intensity, precipitation, wind speed, etc.). Virtual point calculator 910 can calculate timeseries values of virtual data points that depend on other types of variables (e.g., non- weather-related variables). Although only a few weather-related variables are described in detail here, it is contemplated that weather point calculator 912 can calculate virtual data points for any weather-related variable. The weather-related data points used by weather point calculator 912 can be received as timeseries data from various weather sensors and/or from a weather service. Fault Detection

[0440] Still referring to FIG. 9, timeseries operators 906 are shown to include a fault detector 914. Fault detector 914 can be configured to detect faults in timeseries data. In some embodiments, fault detector 914 performs fault detection for timeseries data representing meter data (e.g., measurements from a sensor) and/or for other types of timeseries data. Fault detector 914 can detect faults in the raw timeseries data and/or the derived timeseries data. In some embodiments, fault detector 914 receives fault detection rules from analytics service 624. Fault detection rules can be defined by a user (e.g., via a rules editor) or received from an external system or device. In various embodiments, the fault detection rules can be stored within timeseries database 928. Fault detector 914 can retrieve the fault detection rules from timeseries database 928 and can use the fault detection rules to analyze the timeseries data.

[0441] In some embodiments, the fault detection rules provide criteria that can be evaluated by fault detector 914 to detect faults in the timeseries data. For example, the fault detection rules can define a fault as a data value above or below a threshold value. As another example, the fault detection rules can define a fault as a data value outside a predetermined range of values. The threshold value and predetermined range of values can be based on the type of timeseries data (e.g., meter data, calculated data, etc.), the type of variable represented by the timeseries data (e.g., temperature, humidity, energy consumption, etc.), the system or device that measures or provides the timeseries data (e.g., a sensor, an IoT device, etc.), and/or other attributes of the timeseries data.

[0442] Fault detector 914 can apply the fault detection rules to the timeseries data to determine whether each sample of the timeseries data qualifies as a fault. In some embodiments, fault detector 914 generates a fault detection timeseries containing the results of the fault detection. The fault detection timeseries can include a set of timeseries values, each of which corresponds to a data sample of the timeseries data evaluated by fault detector 914. In some embodiments, each timeseries value in the fault detection timeseries includes a timestamp and a fault detection value. The timestamp can be the same as the timestamp of the corresponding data sample of the data timeseries. The fault detection value can indicate whether the corresponding data sample of the data timeseries qualifies as a fault. For example, the fault detection value can have a value of "Fault" if a fault is detected and a value of "Not in Fault" if a fault is not detected in the corresponding data sample of the data timeseries. The fault detection timeseries can be stored in timeseries database 928 along with the raw timeseries data and the derived timeseries data.

[0443] Referring now to FIGS. 17-18, a block diagram and data table 1800 illustrating the fault detection timeseries is shown, according to some embodiments. In FIG. 17, fault detector 914 is shown receiving a data timeseries 1702 from timeseries database 928. Data timeseries 1702 can be a raw data timeseries or a derived data timeseries. In some embodiments, data timeseries 1702 is a timeseries of values of an actual data point (e.g., a measured temperature). In other embodiments, data timeseries 1702 is a timeseries of values of a virtual data point (e.g., a calculated efficiency). As shown in table 1800, data timeseries 1702 includes a set of data samples. Each data sample includes a timestamp and a value. Most of the data samples have values within the range of 65-66. However, three of the data samples have values of 42.

[0444] Fault detector 914 can evaluate data timeseries 1702 using a set of fault detection rules to detect faults in data timeseries 1702. In some embodiments, fault detector 914 determines that the data samples having values of 42 qualify as faults according to the fault detection rules. Fault detector 914 can generate a fault detection timeseries 1704 containing the results of the fault detection. As shown in table 1800, fault detection timeseries 1704 includes a set of data samples. Like data timeseries 1702, each data sample of fault detection timeseries 1704 includes a timestamp and a value. Most of the values of fault detection timeseries 1704 are shown as "Not in Fault," indicating that no fault was detected for the corresponding sample of data timeseries 1702 (i.e., the data sample with the same

timestamp). However, three of the data samples in fault detection timeseries 1704 have a value of "Fault," indicating that the corresponding sample of data timeseries 1702 qualifies as a fault. As shown in FIG. 17, fault detector 914 can store fault detection timeseries 1704 in timeseries database 928 along with the raw timeseries data and the derived timeseries data.

[0445] Fault detection timeseries 1704 can be used by building management platform 102 to perform various fault detection, diagnostic, and/or control processes. In some

embodiments, fault detection timeseries 1704 is further processed by timeseries processing engine 904 to generate new timeseries derived from fault detection timeseries 1704. For example, sample aggregator 908 can use fault detection timeseries 1704 to generate a fault duration timeseries. Sample aggregator 908 can aggregate multiple consecutive data samples of fault detection timeseries 1704 having the same data value into a single data sample. For example, sample aggregator 908 can aggregate the first two "Not in Fault" data samples of fault detection timeseries 1704 into a single data sample representing a time period during which no fault was detected. Similarly, sample aggregator 908 can aggregate the final two "Fault" data samples of fault detection timeseries 1704 into a single data sample representing a time period during which a fault was detected.

[0446] In some embodiments, each data sample in the fault duration timeseries has a fault occurrence time and a fault duration. The fault occurrence time can be indicated by the timestamp of the data sample in the fault duration timeseries. Sample aggregator 908 can set the timestamp of each data sample in the fault duration timeseries equal to the timestamp of the first data sample in the series of data samples in fault detection timeseries 1704 which were aggregated to form the aggregated data sample. For example, if sample aggregator 908 aggregates the first two "Not in Fault" data samples of fault detection timeseries 1704, sample aggregator 908 can set the timestamp of the aggregated data sample to

2015-12-31Γ23: 10: 00. Similarly, if sample aggregator 908 aggregates the final two "Fault" data samples of fault detection timeseries 1704, sample aggregator 908 can set the timestamp of the aggregated data sample to 2015-12-31Γ23: 50: 00.

[0447] The fault duration can be indicated by the value of the data sample in the fault duration timeseries. Sample aggregator 908 can set the value of each data sample in the fault duration timeseries equal to the duration spanned by the consecutive data samples in fault detection timeseries 1704 which were aggregated to form the aggregated data sample.

Sample aggregator 908 can calculate the duration spanned by multiple consecutive data samples by subtracting the timestamp of the first data sample of fault detection timeseries 1704 included in the aggregation from the timestamp of the next data sample of fault detection timeseries 1704 after the data samples included in the aggregation.

[0448] For example, if sample aggregator 908 aggregates the first two "Not in Fault" data samples of fault detection timeseries 1704, sample aggregator 908 can calculate the duration of the aggregated data sample by subtracting the timestamp 2015-12-31Γ23: 10: 00 (i.e., the timestamp of the first "Not in Fault" sample) from the timestamp 2015-12-31Γ23: 30: 00 (i.e., the timestamp of the first "Fault" sample after the consecutive "Not in Fault" samples) for an aggregated duration of twenty minutes. Similarly, if sample aggregator 908 aggregates the final two "Fault" data samples of fault detection timeseries 1704, sample aggregator 908 can calculate the duration of the aggregated data sample by subtracting the timestamp 2015-12-31 23: 50: 00 (i.e., the timestamp of the first "Fault" sample included in the aggregation) from the timestamp 2016-01-01Γ00: 10: 00 (i.e., the timestamp of the first "Not in Fault" sample after the consecutive "Fault" samples) for an aggregated duration of twenty minutes.

Eventseries

[0449] Referring again to FIG. 9, timeseries operators 906 are shown to include an eventseries generator 915. Eventseries generator 915 can be configured to generate eventseries based on the raw data timeseries and/or the derived data timeseries. Each eventseries may include a plurality of event samples that characterize various events and define the start times and end times of the events. In the context of eventseries, an "event" can be defined as a state or condition that occurs over a period of time. In other words, an event is not an instantaneous occurrence, but rather is a non-instantaneous state or condition observed over a time period having a non-zero duration (i.e., having both a start time and a subsequent stop time). The state or condition of the event can be based on the values of the timeseries samples used to generate the eventseries. In some embodiments, eventseries generator 915 assigns a state to each timeseries sample based on the value of the timeseries sample and then aggregates multiple consecutive samples having the same state to define the time period over which that state is observed.

[0450] Eventseries generator 915 can be configured to assign a state to each sample of an input timeseries (e.g., a raw data timeseries or a derived timeseries) by applying a set of rules to each sample. The process of assigning a state to each sample of the input timeseries can be described as an event-condition-action (ECA) process. ECA refers to the structure of active rules in event driven architecture and active database systems. For example, each rule in the set of rules may include an event, a condition, and an action. The event part of the rule may specify a signal that triggers invocation of the rule. The condition part of the rule may be a logical test (or series of logical tests) that, if satisfied or evaluates to true, causes the action to be carried out. The action part of the rule may specify one or more actions to be performed when the corresponding logical test is satisfied (e.g., assigning a particular state to a sample of the input timeseries). [0451] In some embodiments, the event part is the arrival of a new sample of an input timeseries. Different rules may apply to different input timeseries. For example, the arrival of a new sample of a first input timeseries may qualify as a first event, whereas the arrival of a new sample of a second input timeseries may qualify as a second event. Eventseries generator 915 can use the identity of the input timeseries to determine which event has occurred when a new sample of a particular input timeseries is received. In other words, eventseries generator 915 can select a particular rule to evaluate based on the identity of the input timeseries.

[0452] In some embodiments, the condition includes one or more mathematical checks or logic statements that are evaluated by eventseries generator 915. For example, evaluating the condition of a particular rule may include comparing the value of the sample of the input timeseries to a threshold value. The condition may be satisfied if the value of the sample is less than the threshold value, equal to the threshold value, or greater than the threshold value, depending on the particular logic statement specified by the condition. In some

embodiments, the condition includes a series of mathematical checks that are performed by eventseries generator 915 in a predetermined order. Each mathematical check may correspond to a different action to be performed if that mathematical check is satisfied. For example, the conditions and corresponding actions may be specified as follows:

// Value > Action = Action

Else If θ ₁ ≥ Value > θ ₂ , Action = Action ₂

Else If θ ₂ ≥ Value > θ ₃ , Action = Action ₃

Else If θ ₃ ≥ Value, Action = Action^ where Value is the value of the sample of the input timeseries, θ _χ — θ ₄ are thresholds for the value, and Action— Action^ are specific actions that are performed if the corresponding logic statement is satisfied. For example, Action-^ may be performed if the value of the sample is greater than θ ₁ .

[0453] In some embodiments, the actions include assigning various states to the sample of the input timeseries. For example, Action may include assigning a first state to the sample of the input timeseries, whereas Action ₂ may include assigning a second state to the sample of the input timeseries. Accordingly, different states can be assigned to the sample based on the value of the sample relative to the threshold values. Each time a new sample of an input timeseries is received, eventseries generator 915 can run through the set of rules, select the rules that apply to that specific input timeseries, apply them in a predetermined order, determine which condition is satisfied, and assign a particular state to the sample based on which condition is satisfied.

[0454] One example of an eventseries which can be generated by eventseries generator 915 is an outdoor air temperature (OAT) eventseries. The OAT eventseries may define one or more temperature states and may indicate the time periods during which each of the temperature states is observed. In some embodiments, the OAT eventseries is based on a timeseries of measurements of the OAT received as a raw data timeseries. Eventseries generator 915 can use a set of rules to assign a particular temperature state (e.g., hot, warm, cool, cold) to each of the timeseries OAT samples. For example, eventseries generator 915 can apply the following set of rules to the samples of an OAT timeseries:

// OAT > 100, State = Hot

Else If 100 > OAT > 80, State = Warm

Else If 80 > OAT > 50, State = Cool

Else If 50 > OAT, State = Cold where OAT is the value of a particular timeseries data sample. If the OAT is above 100, eventseries generator 915 can assign the timeseries sample to the "Hot" temperature state. If the OAT is less than or equal to 100 and greater than 80, eventseries generator 915 can assign the timeseries sample to the "Warm" temperature state. If the OAT is less than or equal to 80 and greater than 50, eventseries generator 915 can assign the timeseries sample to the "Cool" temperature state. If the OAT is less than or equal to 50, eventseries generator 915 can assign the timeseries sample to the "Cold" temperature state.

[0455] In some embodiments, eventseries generator 915 creates a new timeseries that includes the assigned states for each sample of the original input timeseries. The new timeseries may be referred to as a "state timeseries" because it indicates the state assigned to each timeseries sample. The state timeseries can be created by applying the set of rules to an input timeseries as previously described. In some embodiments, the state timeseries includes a state value and a timestamp for each sample of the state timeseries. An example of a state timeseries is as follows:

[{states timestamp^, (state ₂ , timestamp ₂ ), ... {state _N , timestamp _N )] where state _t is the state assigned to the ith sample of the input timeseries, timestampi is the timestamp of the tth sample of the input timeseries, and N is the total number of samples in the input timeseries. In some instances, two or more of the state values may be the same if the same state is assigned to multiple samples of the input timeseries.

[0456] In some embodiments, the state timeseries also includes the original value of each sample of the input timeseries. For example, each sample of the state timeseries may include a state value, a timestamp, and an input data value, as shown in the following equation:

[{states timestamp^ value^, ... (state _N , timestamp _N , value _N )] where value _t is the original value of the tth sample of the input timeseries. The state timeseries is a type of derived timeseries which can be stored and processed by timeseries service 628.

[0457] Referring now to FIG. 19 A, a table 1910 illustrating the result of assigning a temperature state to each timeseries sample is shown, according to some embodiments. Each timeseries sample is shown as a separate row of table 1910. The "Time" column of table 1910 indicates the timestamp associated with each sample, whereas the "OAT" column of table 1910 indicates the value of each timeseries sample. The "State" column of table 1910 indicates the state assigned to each timeseries sample by eventseries generator 915.

[0458] Referring now to FIG. 19B, a table 1920 illustrating a set of events generated by eventseries generator 915 is shown, according to some embodiments. Each event is shown as a separate row of table 1920. The "Event ID" column of table 1920 indicates the unique identifier for each event (e.g., Event 1, Event 2, etc.). The "Start Time" column of table 1920 indicates the time at which each event begins and the "End Time" column of table 1920 indicates the time at which event ends. The "State" column of table 1920 indicates the state associated with each event. [0459] Eventseries generator 915 can generate each event shown in table 1920 by identifying consecutive timeseries samples with the same assigned state and determining a time period that includes the identified samples. In some embodiments, the time period starts at the timestamp of the first sample having a given state and ends immediately before the timestamp of the next sample having a different state. For example, the first two timeseries samples shown in table 1910 both have the state "Cold," whereas the third sample in table 1910 has the state "Cool." Eventseries generator 915 can identify the first two samples as having the same state and can generate the time period 00:00 - 01 :59 which includes both of the identified samples. This time period begins at the timestamp of the first sample (i.e., 00:00) and ends immediately before the timestamp of the third sample (i.e., 02:00).

Eventseries generator 915 can create an event for each group of consecutive samples having the same state.

[0460] Eventseries generator 915 can perform a similar analysis for the remaining timeseries samples in table 1910 to generate each of the events shown in table 1920. In some instances, multiple events can have the same state associated therewith. For example, both Event 1 and Event 7 shown in table 1920 have the "Cold" state. Similarly, both Event 2 and Event 6 have the "Cool" state and both Event 3 and Event 5 have the "Warm" state. It should be noted that an event defines not only a particular state, but also a time period (i.e., a series of consecutive time samples) during which that state is observed. If the same state is observed during multiple non-consecutive time periods, multiple events having the same state can be generated to represent each of the non-consecutive time periods.

[0461] In some embodiments, eventseries generator 915 creates an eventseries for a set of events. An eventseries is conceptually similar to a timeseries in that both represent a series of occurrences. However, the samples of a timeseries correspond to instantaneous occurrences having a single timestamp, whereas the samples of an eventseries correspond to non- instantaneous events having both a start time and a stop time. For example, eventseries generator 915 may create the following eventseries for the set of events shown in table 1920: [(ID = 1, State = Cold, StartTime = 00: 00, EndTime

(ID = 2, State = Cool, StartTime = 02: 00, EndTime = 08; 59),

(ID = 3, State = Warm, StartTime = 09: 00, EndTime = 11; 59),

(ID = 4, State = Hot, StartTime = 12: 00, EndTime = 15; 59),

(ID = 5, State = Warm, StartTime = 16: 00, EndTime = 18; 59),

(ID = 6, State = Cool, StartTime = 19: 00, EndTime = 21; 59),

(ID = 7, State = Cold, StartTime : 22: 00, EndTime = 23; 59)] where each item within the bent brackets ( ) is an event having the attributes //), State, StartTime, and EndTime. Events can be stored in a tabular format (as shown in FIG. 9B), as a text string (as shown above), as a data object (e.g., a JSON object), in a container format, or any of a variety of formats.

Eventseries Process

[0462] Referring now to FIG. 19C, a flowchart of a process 1960 for creating and updating eventseries is shown, according to some embodiments. Process 1960 can be performed by eventseries generator 915, as described with reference to FIGS. 9 and 17-18. In some embodiments, process 1960 is performed to create an eventseries based on the samples of a data timeseries. Process 1960 can be performed after all of the samples of the data timeseries have been collected or can be performed each time a new sample of the data timeseries is collected.

[0463] Process 1960 is shown to include obtaining a new sample of a data timeseries (step 1962) and assigning a state to the sample using a set of rules (step 1964). In some embodiments, the sample is obtained from a sensor configured to measure a variable of interest. For example, the sample can be a sample of a raw data timeseries. In other embodiments, the sample is a sample of a derived data timeseries generated by sample aggregator 908, virtual point calculator 910, weather point calculator 912, or other timeseries operators 906. The sample can be obtained from a set of samples of a complete timeseries or can be received as the latest sample of an incoming data stream.

[0464] In some embodiments, step 1964 includes applying a set of rules to the sample of the data timeseries to determine which state to assign. The set of rules may define various ranges of values and a corresponding state for each range of values. Step 1964 can include assigning the sample to a particular state if the value of the value of the sample is within the corresponding range of values. For example, if the sample is a sample of outdoor air temperature (OAT), the set of rules may define various temperature ranges and a temperature state for each of the temperature ranges. One example of such a set of rules is as follows:

// OAT > 100, State = Hot

Else If 100 > OAT > 80, State = Warm

Else If 80 > OAT > 50, State = Cool

Else If 50 > OAT, State = Cold where OAT is the value of a particular timeseries data sample. If the OAT is above 100, the sample can be assigned to the "Hot" temperature state. If the OAT is less than or equal to 100 and greater than 80, the sample can be assigned to the "Warm" temperature state. If the OAT is less than or equal to 80 and greater than 50, the sample can be assigned to the "Cool" temperature state. If the OAT is less than or equal to 50, the sample can be assigned to the "Cold" temperature state.

[0465] Still referring to FIG. 19C, process 1960 is shown to include determining whether the sample is part of an existing event (step 1966). Step 1966 may include identifying all of the events in an existing eventseries and determining whether the sample belongs to any of the identified events. Each event may be defined by the combination of a particular state and a time period having both a start time and an end time. Step 1966 may include determining that the sample is part of an existing event if the sample is both (1) assigned to the same state as the existing event and (2) has a timestamp that is either (a) within the time period associated with the existing event or (b) consecutive with the time period associated with the existing event. However, step 1966 may include determining that the sample is not part of an existing event if the sample does not have the same state as the existing event or does not have a timestamp that that is either within the time period associated with the existing event or consecutive with the time period associated with the existing event.

[0466] In step 1966, a timestamp may be considered within the time period associated with an existing event if the timestamp is between the start time of the event and the end time of the event. A timestamp may be considered consecutive with the time period associated with an existing event if the timestamp is immediately before the start time or immediately after the end time of the event. For example, if a new sample has a timestamp before the start time of an event and no other samples have intervening timestamps between the timestamp of the new sample and the start time of the event, the timestamp may be considered consecutive with the time period associated with the existing event. Similarly, if a new sample has a timestamp after the end time of an event and no other samples have intervening timestamps between the end time of the event and the timestamp of the new sample, the timestamp may be considered consecutive with the time period associated with the existing event.

[0467] If the new sample is part of an existing event (i.e., the result of step 1966 is "yes"), process 1960 may proceed to determining whether the new sample extends the existing event (step 1968). Step 1968 may include determining whether the timestamp of the new sample is consecutive with the time period associated with the existing event (i.e., immediately before the start time of the event or immediately after the end time of the event). If the timestamp of the new sample is consecutive with the time period associated with the existing event, step 1968 may include determining that the sample extends the existing event. However, if the timestamp of the new sample is not consecutive with the time period associated with the existing event, step 1968 may include determining that the sample does not extend the existing event.

[0468] If the sample does not extend the existing event (i.e., the result of step 1968 is "no"), process 1960 may include determining that no update to the existing event is needed (step 1970). This situation may occur when the timestamp of the new sample is between the start time of the existing event and the end time of the existing event (i.e., within the time period associated with the existing event). Since the time period associated with the existing event already covers the timestamp of the new sample, it may be unnecessary to update the existing event to include the timestamp of the new sample.

[0469] However, if the sample extends the existing event (i.e., the result of step 1968 is "yes"), process 1960 may proceed to updating the start time or end time of the existing event based on the timestamp of the sample (step 1972). Step 1972 may include moving the start time of the event backward in time or moving the end time of the event forward in time such that the time period between the start time and the end time includes the timestamp of the new sample. For example, if the timestamp of the sample is before the start time of the event, step 1972 may include replacing the start time of the existing event with the timestamp of the sample. [0470] Similarly, if the timestamp of the sample is after the end time of the event, step 1972 may include replacing the end time of the existing event with a new end time that occurs after the timestamp of the sample. For example, if the existing event has an original end time of 04:59 and the new sample has a timestamp of 05:00, step 1972 may include updating the end time of the event to 05:59 (or any other time that occurs after 05:00) such that the adjusted time period associated with the event includes the timestamp of the new sample. If the original end time of the existing event is "Null" and the new sample extends the end time of the existing event, step 1972 may maintain the original end time of "Null."

[0471] Returning to step 1966, if the sample is not part of an existing event (i.e., the result of step 1966 is "no"), process 1960 may proceed to creating a new event based on the state and the timestamp of the new sample (step 1974). The new event may have a state that matches the state assigned to the new sample in step 1964. The new event may have a start time equal to the timestamp of the sample and an end time that occurs after the timestamp of the sample such that the time period associated with the new event includes the timestamp of the sample. The end time may have a value of "Null" if the new event is the last event in the eventseries or a non-null value of the new event is not the last event in the eventseries. For example, if the next event in the timeseries begins at timestamp 06:00, step 1974 may include setting the end time of the new event to 05:59.

[0472] After creating the new event in step 1974, process 1960 may perform steps 976-988 to update other events in the eventseries based on the new information provided by the new event. For example, if the new event is the last event in the eventseries (i.e., the result of step 1976 is "yes"), process 1960 may update the end time of the previous event (i.e., the event that occurs immediately before the new event) (step 1978). The update performed in step 1978 may include setting the end time of the previous event to a time immediately before the timestamp of the new sample. For example, if the new sample has a timestamp of 05:00, step 1978 may include updating the end time of the previous event to 04:59. If the new event is not the last event in the eventseries (i.e., the result of step 1976 is "no"), process 1960 may proceed to step 1980.

[0473] If the new event occurs between existing events in the eventseries (i.e., the result of step 1980 is "yes"), process 1960 may update the end time of the previous event (step 1982). The update performed in step 1982 may be the same as the update performed in step 1978. For example, the update performed in step 1982 may include setting the end time of the previous event to a time immediately before the timestamp of the new sample. If the new event does not occur between existing events in the eventseries (i.e., the result of step 1980 is "no"), process 1960 may proceed to step 1984.

[0474] If the new event splits an existing event in the eventseries (i.e., the result of step 1984 is "yes"), process 1960 may split the existing event into two events with the new event in between. In some embodiments, splitting the existing event into two events includes updating the end time of the existing event to end before the new event (step 1986) and creating a second new event beginning after the first new event and ending at the previous end time of the existing event (step 1988). For example, consider a situation in which the existing event has a start time of 04:00, an end time of 11 :59, and a state of "Warm." The new event added in step 1974 may have a start time of 08:00, an end time of 08:59, and a state of "Hot." Accordingly, step 1986 may include changing the end time of the existing event to 07:59 such that the existing event corresponds to a first "Warm" event and covers the time period from 04:00 to 07:59. The intervening "Hot" event may cover the time period from 08:00 to 08:59. The second new event created in step 1988 (i.e., the second "Warm" event) may have a start time of 09:00 and an end time of 11 :59. The state of the second new event may be the same as the state of the existing event.

Properties of Events and Eventseries

[0475] Similar to timeseries, an eventseries can be used in two ways. In some

embodiments, an event series is used for storage only. For example, events can be created by an external application and stored in an eventseries. In this scenario, the eventseries is used only as a storage container. In other embodiments, eventseries can be used for both storage and processing. For example, events can be created by eventseries generator 915 based on raw or derived timeseries by applying a set of rules, as previously described. In this scenario, the eventseries is both the storage container and the mechanism for creating the events.

[0476] In some embodiments, each eventseries includes the following properties or attributes: EventseriesID, OrgID, InputTimeseriesID, StateTimeseriesID, Rules, and Status. The EventseriesID property may be a unique ID generated by eventseries generator 915 when a new eventseries is created. The EventseriesID property can be used to uniquely identify the eventseries and distinguish the eventseries from other eventseries. The OrgID property may identify the organization (e.g., "ABC Corporation") to which the eventseries belongs. Similar to timeseries, each eventseries may belong to a particular organization, customer, facility, or other entity (described in greater detail with reference to FIGS. 11 A-l IB).

[0477] The InputTimeseriesID property may identify the timeseries used to create the eventseries. For example, if the eventseries is a series of outdoor air temperature (OAT) events, the InputTimeseriesID property may identify the OAT timeseries from which the OAT eventseries is generated. In some embodiments, the input timeseries has the following format:

[< key, timestamp^ value >, < key, timestamp ₂ , value ₂ >,

< key, timestamp ₃ , value ₃ >] where key is an identifier of the source of the data samples (e.g., timeseries ID, sensor ID, etc.), timestampi identifies a time associated with the ith sample, and valuei indicates the value of the ith sample.

[0478] The Rules property may identify a list of rules that are applied to the input timeseries to assign a particular state to each sample of the input timeseries. In some embodiments, the list of rules includes a plurality of rules that are applied in a particular order. The order may be defined by the logical structure of the rules. For example, the rules may include a set of "If ' and "Elself statements that are evaluated in the order in which the statements appear in the set of rules. An example of a set of rules is as follows:

// OAT > 100, State = Hot

Else If 100 > OAT > 80, State = Warm

Else If 80 > OAT > 50, State = Cool

Else If 50 > OAT, State = Cold

[0479] The State TimeseriesID property may identify the state timeseries in which the assigned states are stored. The state timeseries can be created by applying the set of rules to an input timeseries as previously described. In some embodiments, the state timeseries includes a state value and a timestamp for each sample of the state timeseries. An example of a state timeseries is as follows:

[(states timestamp^, (state ₂ , timestamp ₂ ), ... (state _N , timestamp _N )] where state _t is the state assigned to the ith sample of the input timeseries, timestampi is the timestamp of the tth sample of the input timeseries, and N is the total number of samples in the input timeseries.

[0480] The Status property may indicate whether the eventseries is active (i.e., Status = Active) or inactive (i.e., Status = Inactive). In some embodiments, an eventseries is active by default when the eventseries is created. An eventseries can be deactivated by events service 903. Events service 903 can change the Status property from active to inactive upon deactivating an eventseries.

[0481] Each eventseries may include a set of events. Each event may include the following properties: EventID, State, StartTimestamp, EndTimestamp,and EventseriesID. The EventID property may be a unique ID generated by eventseries generator 915 when a new event is created. The EventID property can be used to uniquely identify a particular event and distinguish the event from other events in the eventseries. The State property may be a text string that defines the state associated with the event. Each event may be uniquely associated with one state. The StartTimestamp property may indicate the start time of the event, whereas the EndTimestamp property may indicate the end time of the event. The

StartTimestamp and EndTimestamp properties may be timestamps in any of a variety of formats (e.g., 2017-01-01T00:00:00). The EventseriesID property may identify the eventseries which includes the event. The EventseriesID property may be the same unique identifier used to identify and distinguish eventseries from each other.

Event Service

[0482] Referring again to FIG. 9, timeseries service 628 is shown to include an event service 903. In some embodiments, event service 903 is part of timeseries service 628. In other embodiments, event service 903 is a separate service (i.e., separate from timeseries service 628) within cloud building management platform 620. Event service 903 can be configured to receive and process requests for information relating to various events and eventseries. Event service 903 can also create and update events and eventseries in response to a request from an application or a user. Several examples of how event service 903 can handle requests are described below. The following table identifies the types of actions event service 903 can perform with respect to events and eventseries: Resource GET (read) POST (create) PUT (update)

Retrieve list of Create one or more

/Eventseries N/A

Eventseries new Eventseries

Read a specific Create a specific

/Eventseries/ {eventseriesld}

Eventseries Eventseries

Retrieve a list of Create one or more

/Events N/A

Events new Events

Create a specific

/Events/ {eventld}

Event

[0483] Event service 903 can be configured to create a new eventseries in response to a request containing an OrgID attribute and a processing type attribute. For example, event service 903 can receive the following request:

Post {timeseriesV2}/eventseries/new {

"orgld": "Abe Inc",

"ProcessingType" : "none"

}

where "Abe Inc" is the ID of the organization to which the new eventseries will belong and no processing type is specified.

[0484] In response to this request, event service 903 can create a new eventseries (i.e., an empty eventseries container) and assign an EventseriesID to the eventseries. For example, event service 903 can respond to the request as follows:

{

"eventseriesld": "c7cl57e4-303f-4b25-bl82-ce7b0f8291d8",

"orgld": "Abe Inc",

"inputTimeseriesId": null,

"stateTimeseriesId": null,

"rules": null,

"status": "active",

"processingType": "stream" [0485] In some embodiments, event service 903 is configured to create a new eventseries in response to a request containing an OrgID attribute, an InputTimeseriesID attribute, a StateTimeseriesID attribute, and a Rules attribute. For example, event service 903 can receive the following request:

{

"orgld": "Abe Inc",

"inputTimeseriesId": "793cl56e4-303f-4b2e-bt82-ce7b0f829uj3",

"stateTimeseriesId": "uicl57e4-6r2f-4b25-b682-ct7b0f82917u",

"rules": [

{"compareOp": "Gt", "scalar": 100, "state": "Hot"},

{"compareOp": "Gt", "scalar": 80, "state": "Warm"},

{"compareOp": "Gt", "scalar": 50, "state": "Cool"},

{"compareOp": "Lte", "scalar": 50, "state": "Cold"}

]

}

where "793cl56e4-303f-4b2e-bt82-ce7b0f829uj3" is the ID of the input timeseries used to generate the eventseries, "uicl57e4-6r2f-4b25-b682-ct7b0f82917u" is the ID of the state timeseries containing the states assigned to each sample of the input timeseries, and the "rules" attribute contains a set of rules used to assign a state to each sample of the input timeseries.

[0486] In response to this request, event service 903 can create a new eventseries (i.e., an empty eventseries container) and assign an EventseriesID to the eventseries. For example, event service 903 can respond to the request as follows:

{

"eventseriesld": "c7cl57e4-303f-4b25-bl82-ce7b0f8291d8",

"orgld": "Abe Inc",

"inputTimeseriesId": "793cl56e4-303f-4b2e-bt82-ce7b0f829uj3", "stateTimeseriesId": "uicl57e4-6r2f-4b25-b682-ct7b0f82917u",

"rules": [

{"compareOp": "Gt", "scalar": 100, "state": "Hot"},

{"compareOp": "Gt", "scalar": 80, "state": "Warm"},

{"compareOp": "Gt", "scalar": 50, "state": "Cool"},

{"compareOp": "Lte", "scalar": 50, "state": "Cold"}

],

"status": "active",

"processingType": "stream"

}

[0487] In some embodiments, event service 903 is configured to add new events to an existing eventseries. For example, event service 903 can receive a request to add a new event to an eventseries. The request may specify the EventseriesID, the start time of the event, the end time of the event, and the state associated with the event, as shown in the following request:

Post {timeseriesV2}/eventseries/c7cl57e4-303f-4b25-bl82-ce7b0f829 1d8/events [

{

"eventseriesld": "c7cl57e4-303f-4b25-bl82-ce7b0f8291d8",

"startTimestamp": "2017-04-01 13 :48:23-05:00",

"endTimestamp": "2017-04-01 13 :54: 11-05:00",

"state": "High Pressure Alarm"

}

]

[0488] In response to this request, event service 903 can generate a new EventID for the new event and can add the new event to the eventseries designated by the EventseriesID "C7cl57e4-303f-4b25-bl82-ce7b0f8291d8." The new event may have the start time "2017- 04-01 13 :48:23-05:00," the end time "2017-04-01 13 :54: 11-05:00," and the state "High Pressure Alarm" as specified in the request. In some embodiments, event service 903 responds to the request by acknowledging that the new event has been added to the eventseries.

[0489] In some embodiments, event service 903 is configured to update existing events in an eventseries. For example, event service 903 can receive a request to add update one or more properties of an existing event in an eventseries. The request may specify the

EventseriesID, the updated start time of the event, the updated end time of the event, and/or the updated state associated with the event, as shown in the following request:

Put {timeseriesV2}/eventseries/c7cl57e4-303f-4b25-bl82-ce7b0f829 1d8/events/ c7cl57e4- 303f-4b25-bl82-ce7b0f8291d8

{

"eventseriesld": "c7cl57e4-303f-4b25-bl82-ce7b0f8291d8",

"startTimestamp": "2017-04-01 13 :48:23-05:00",

"endTimestamp": "2017-04-01 13 :54: 11-05:00",

"state": "High Pressure Alarm"

}

[0490] In response to this request, event service 903 can update the specified properties of the event designated by EventseriesID "c7cl57e4-303f-4b25-bl82-ce7b0f8291d8." The updated event may have the start time "2017-04-01 13 :48:23-05:00," the end time "2017-04- 01 13 :54: 11-05:00," and the state "High Pressure Alarm" as specified in the request. In some embodiments, event service 903 responds to the request by acknowledging that the event has been updated.

[0491] In some embodiments, event service 903 is configured to read the events of an eventseries. For example, event service 903 can receive a request to identify all of the events associated with an eventseries. The request may be specified as a get request as follows:

Get {timeseriesV2}/eventseries/c7cl57e4-303f-4b25-bl82-ce7b0f829 1d8/events

where "c7cl57e4-303f-4b25-bl82-ce7b0f8291d8" is the EventseriesID of a specific eventseries. [0492] In response to this request, event service 903 can search for all events of the specified eventseries and can return a list of the identified events. An example response which can be provided by event service 903 is as follows:

[

{

"eventid" : "g9cl 97e4-003f-4u25-b 182-se7b0f81945y",

"eventseriesld" : "c7c 157e4-303f-4b25-b 182-ce7b0f8291 d8", "startTimestamp": "2017-04-01 13 :48:23-05:00",

"endTimestamp": "2017-04-01 13 :54: 11-05:00",

"state": "High Pressure Alarm"

}

]

where "g9cl97e4-003f-4u25-bl82-se7b0f81945y" is the EventID of an identified event matching the search parameters. The response may specify the EventseriesID,

StartTimestamp, EndTimestamp, and State properties of each identified event.

[0493] In some embodiments, event service 903 is configured to search for the events of an eventseries that have a specific state. For example, event service 903 can receive a request to identify all of the events associated with a particular eventseries which have a specific state. The request may be specified as a get request as follows:

Get {timeseriesV2}/eventseries/c7cl57e4-303f-4b25-bl82-ce7b0f829 1d8/events?state=Hot where "c7cl57e4-303f-4b25-bl82-ce7b0f8291d8" is the EventseriesID of a particular eventseries and "state=Hot" specifies that the search should return only events of the eventseries that have the state "Hot." In response to this request, event service 903 may search for all matching events (i.e., events of the specified eventseries that have the specified state) and may return a list of events that match the search parameters.

[0494] In some embodiments, event service 903 is configured to search for the events of an eventseries that have a start time or end time matching a given value. For example, event service 903 can receive a request to identify all of the events of a particular eventseries that have a start time or end time that matches a specified timestamp. The request may be specified as a get request as follows:

Get {timeseriesV2}/eventseries/c7cl57e4-303f-4b25-bl82- ce7b0f8291 d8/events?startTime=2017-04-01 %2010:00: 00-05 :00&endTime=2017-04- 01%2010:00:00-05:00

where "c7cl57e4-303f-4b25-bl82-ce7b0f8291d8" is the EventseriesID of a particular eventseries and the "startTime" and "endTime" parameters specify the start time and end time of the event. In response to this request, event service 903 may search for all matching events (i.e., (startTimestamp of event < startTime and endTimestamp of event > endTime) and may return a list of events that match the search parameters.

[0495] In some embodiments, event service 903 is configured to search for the events of an eventseries that have a time range overlapping (at least partially) with a specified time range. For example, event service 903 can receive a request to identify all of the events of a particular eventseries that have (1) an event start time before a specified start time and an event end time after the specified start time or (2) an event start time before a specified end time and an event end time after the specified end time. The request may be specified as a get request as follows:

Get {timeseriesV2}/eventseries/c7cl57e4-303f-4b25-bl82- ce7b0f8291 d8/events?startTime=2017-04-01 %2010:00: 00-05 :00&endTime=2017-04- 01%2011 :59:00-05:00

where "c7cl57e4-303f-4b25-bl82-ce7b0f8291d8" is the EventseriesID of a particular eventseries and the "startTime" and "endTime" parameters specify the start time and end time of the event. In response to this request, event service 903 may search for all events that match the following criteria:

[(startTimestamp of event < startTime of query) AND (endTimestamp of event > startTime of query)] OR [(startTimestamp of event < endTime of query) AND (endTimestamp of event > endTime of query)]

and may return a list of events that match these criteria.

[0496] In some embodiments, event service 903 is configured to search for events of an eventseries that have a specific state and a time range that overlaps (at least partially) with a given time range. For example, event service 903 can receive a request to identify all of the events of a particular eventseries that have a particular state and either (1) an event start time before a specified start time and an event end time after the specified start time or (2) an event start time before a specified end time and an event end time after the specified end time. The request may be specified as a get request as follows:

Get {timeseriesV2}/eventseries/c7cl57e4-303f-4b25-bl82- ce7b0f8291 d8/events? state=Hot& startTime=2017-04-01 %2010 : 00 : 00- 05 :00&endTime=2017-04-01%201 1 :59:00-05:00

where "c7cl57e4-303f-4b25-bl82-ce7b0f8291d8" is the EventseriesID of a particular eventseries, the "state" parameter specifies a particular state, and the "startTime" and "endTime" parameters specify the start time and end time of the event. In response to this request, event service 903 may search for all events that match the following criteria:

State=Hot AND

[(startTimestamp of event < startTime of query) AND (endTimestamp of event > startTime of query)] OR [(startTimestamp of event < endTime of query) AND (endTimestamp of event > endTime of query)]

and may return a list of events that match these criteria. Directed Acyclic Graphs

[0497] Referring now to FIG. 20A, an example of a DAG 2000 which can be created by DAG generator 920 is shown, according to an exemplary embodiment. DAG 2000 is shown as a structured tree representing a graph of the dataflow rather than a formal scripting language. Blocks 2002 and 2004 represent the input timeseries which can be specified by timeseries ID (e.g., ID 123, ID 456, etc.). Blocks 2006 and 2008 are functional blocks representing data cleansing operations. Similarly, block 2010 is a functional block representing a weekly rollup aggregation and block 2012 is a functional block representing an addition operation. Blocks 2014 and 2016 represent storage operations indicating where the output of DAG 2000 should be stored (e.g., local storage, hosted storage, etc.).

[0498] In DAG 2000, the arrows connecting blocks 2002-2016 represent the flow of data and indicate the sequence in which the operations defined by the functional blocks should be performed. For example, the cleansing operation represented by block 2006 will be the first operation performed on the timeseries represented by block 2002. The output of the cleansing operation in block 2006 will then be provided as an input to both the aggregation operation represented by block 2010 and the addition operation represented by block 2012. Similarly, the cleansing operation represented by block 2008 will be the first operation performed on the timeseries represented by block 2004. The output of the cleansing operation in block 2008 will then be provided as an input to the addition operation represented by block 2012.

[0499] In some embodiments, DAG 2000 can reference other DAGs as inputs. Timeseries processing engine 904 can stitch the DAGs together into larger groups. DAG 2000 can support both scalar operators (e.g., run this function on this sample at this timestamp) and aggregate window operators (e.g., apply this function over all the values in the timeseries from this time window). The time windows can be arbitrary and are not limited to fixed aggregation windows. Logical operators can be used to express rules and implement fault detection algorithms. In some embodiments, DAG 2000 supports user-defined functions and user-defined aggregates.

[0500] In some embodiments, DAG 2000 is created based on user input. A user can drag- and-drop various input blocks 2002-2004, functional blocks 2006-2012, and output blocks 2014-2016 into DAG 2000 and connect them with arrows to define a sequence of operations. The user can edit the operations to define various parameters of the operations. For example, the user can define parameters such as upper and lower bounds for the data cleansing operations in blocks 2006-2008 and an aggregation interval for the aggregation operation in block 2010. DAG 2000 can be created and edited in a graphical drag-and-drop flow editor without requiring the user to write or edit any formal code. In some embodiments, DAG generator 920 is configured to automatically generate the formal code used by timeseries operators 906 based on DAG 2000.

[0501] Referring now to FIG. 20B, an example of code 2050 which can be generated by DAG generator 920 is shown, according to an exemplary embodiment. Code 2050 is shown as a collection of JSON objects 2052-2056 that represent the various operations defined by DAG 2000. Each JSON object corresponds to one of the functional blocks in DAG 2000 and specifies the inputs/sources, the computation, and the outputs of each block. For example, object 2052 corresponds to the cleansing operation represented by block 2006 and defines the input timeseries (i.e., "123_Raw"), the particular cleansing operation to be performed (i.e., "BoundsLimitingCleanseOP"), the parameters of the cleansing operation (i.e., "upperbound" and "lowerbound") and the outputs of the cleansing operation (i.e., "123_Cleanse" and "BLCleanseFlag"). [0502] Similarly, object 2054 corresponds to the aggregation operation represented by block 2010 and defines the input timeseries (i.e., " 123_Cleanse"), the aggregation operation to be performed (i.e., "AggregateOP"), the parameter of the aggregation operation (i.e., "interval": "week") and the output of the aggregation operation (i.e., "123_WeeklyRollup"). Object 2056 corresponds to the addition operation represented by block 2012 and defines the input timeseries (i.e., "123_Cleanse" and "456_Cleanse"), the addition operation to be performed (i.e., "AddOP"), and the output of the addition operation (i.e., " 123+456").

Although not specifically shown in FIG. 20B, code 2050 may include an object for each functional block in DAG 2000.

[0503] Advantageously, the declarative views defined by the DAGs provide a

comprehensive view of the operations applied to various input timeseries. This provides flexibility to run the workflow defined by a DAG at query time (e.g., when a request for derived timeseries data is received) or prior to query time (e.g., when new raw data samples are received, in response to a defined event or trigger, etc.). This flexibility allows timeseries processing engine 904 to perform some or all of their operations ahead of time and/or in response to a request for specific derived data timeseries.

Entity Graph

[0504] Referring now to FIG. 21 A, an entity graph 2100 is shown, according to some embodiments. In some embodiments, entity graph 2100 is generated or used by data collector 612, as described with reference to FIG. 6. Entity graph 2100 describes how collection of devices and spaces are organized and how the different devices and spaces relate to each other. For example, entity graph 2100 is shown to include an organization 2102, a space 2104, a system 2106, a point 2108, and a timeseries 2109. The arrows interconnecting organization 2102, space 2104, system 2106, point 2108, and timeseries 2109 identify the relationships between such entities. In some embodiments, the relationships are stored as attributes of the entity described by the attribute.

[0505] Organization 2102 is shown to include a contains descendants attribute 2110, a parent ancestors attribute 2122112, a contains attribute 2142114, a located in attribute 2162116, an occupied by ancestors attribute 2182118, and an occupies by attribute 2122. The contains descendants attribute 2110 identifies any descendant entities contained within organization 2102. The parent ancestors attribute 2122112 identifies any parent entities to organization 2102. The contains attribute 2142114 identifies any other organizations contained within organization 2102. The asterisk alongside the contains attribute 2142114 indicates that organization 2102 can contain any number of other organizations. The located in attribute 2162116 identifies another organization within which organization 2102 is located. The number 1 alongside the located in attribute 2162116 indicates that organization 2102 can be located in exactly one other organization. The occupies attribute 2122 identifies any spaces occupied by organization 2102. The asterisk alongside the occupies attribute 2122 indicates that organization 2102 can occupy any number of spaces.

[0506] Space 2104 is shown to include an occupied by attribute 2202120, an occupied by ancestors attribute 2182118, a contains space descendants attribute 2124, a located in ancestors attribute 2126, a contains spaces attribute 2128, a located in attribute 2130, a served by systems attribute 2138, and a served by system descendants attribute 2134. The occupied by attribute 2202120 identifies an organization occupied by space 2104. The number 1 alongside the occupied by attribute 2202120 indicates that space 2104 can be occupied by exactly one organization. The occupied by ancestors attribute 2182118 identifies one or more ancestors to organization 2102 that are occupied by space 2104. The asterisk alongside the occupied by ancestors attribute 2182118 indicates that space 2104 can be occupied by any number of ancestors.

[0507] The contains space descendants attribute 2124 identifies any descendants to space 2104 that are contained within space 2104. The located in ancestors attribute 2126 identifies any ancestors to space 2104 within which space 2104 is located. The contains spaces attribute 2128 identifies any other spaces contained within space 2104. The asterisk alongside the contains spaces attribute 2128 indicates that space 2104 can contain any number of other spaces. The located in attribute 2130 identifies another space within which space 2104 is located. The number 1 alongside the located in attribute 2130 indicates that space 2104 can be located in exactly one other space. The served by systems attribute 2138 identifies any systems that serve space 2104. The asterisk alongside the served by systems attribute 2138 indicates that space 2104 can be served by any number of systems. The served by system descendants attribute 2134 identifies any descendent systems that serve space 2104. The asterisk alongside the served by descendant systems attribute 2134 indicates that space 2104 can be served by any number of descendant systems. [0508] System 2106 is shown to include a serves spaces attribute 2136, a serves space ancestors attribute 2132, a subsystem descendants attribute 2140, a part of ancestors attribute 2142, a subsystems attribute 2144, a part of attribute 2146, and a points attribute 2150. The serves spaces attribute 2136 identifies any spaces that are served by system 2106. The asterisk alongside the serves spaces attribute 2136 indicates that system 2106 can serve any number of spaces. The serves space ancestors attribute 2132 identifies any ancestors to space 2104 that are served by system 2106. The asterisk alongside the serves ancestor spaces attribute 2132 indicates that system 2106 can serve any number of ancestor spaces.

[0509] The subsystem descendants attribute 2140 identifies any subsystem descendants of other systems contained within system 2106. The part of ancestors attribute 2142 identifies any ancestors to system 2106 that system 2106 is part of. The subsystems attribute 2144 identifies any subsystems contained within system 2106. The asterisk alongside the subsystems attribute 2144 indicates that system 2106 can contain any number of subsystems. The part of attribute 2146 identifies any other systems that system 2106 is part of. The number 1 alongside the part of attribute 2146 indicates that system 2106 can be part of exactly one other system. The points attribute 2150 identifies any data points that are associated with system 2106. The asterisk alongside the points attribute 2150 indicates that any number of data points can be associated with system 2106.

[0510] Point 2108 is shown to include a used by system attribute 2148. The asterisk alongside the used by system attribute 2148 indicates that point 2108 can be used by any number of systems. Point 2108 is also shown to include a used by timeseries attribute 2154. The asterisk alongside the used by timeseries attribute 2154 indicates that point 2108 can be used by any number of timeseries (e.g., raw data timeseries virtual point timeseries, data rollup timeseries, etc.). For example, multiple virtual point timeseries can be based on the same actual data point 2108. In some embodiments, the used by timeseries attribute 2154 is treated as a list of timeseries that subscribe to changes in value of data point 2108. When the value of point 2108 changes, the timeseries listed in the used by timeseries attribute 2154 can be identified and automatically updated to reflect the changed value of point 2108.

[0511] Timeseries 2109 is shown to include a uses point attribute 2152. The asterisk alongside the uses point attribute 2152 indicates that timeseries 2109 can use any number of actual data points. For example, a virtual point timeseries can be based on multiple actual data points. In some embodiments, the uses point attribute 2152 is treated as a list of points to monitor for changes in value. When any of the points identified by the uses point attribute 2152 are updated, timeseries 2109 can be automatically updated to reflect the changed value of the points used by timeseries 2109.

[0512] Timeseries 2109 is also shown to include a used by timeseries attribute 2156 and a uses timeseries attribute 2158. The asterisks alongside the used by timeseries attribute 2156 and the uses timeseries attribute 2158 indicate that timeseries 2109 can be used by any number of other timeseries and can use any number of other timeseries. For example, both a data rollup timeseries and a virtual point timeseries can be based on the same raw data timeseries. As another example, a single virtual point timeseries can be based on multiple other timeseries (e.g., multiple raw data timeseries). In some embodiments, the used by timeseries attribute 2156 is treated as a list of timeseries that subscribe to updates in timeseries 2109. When timeseries 2109 is updated, the timeseries listed in the used by timeseries attribute 2156 can be identified and automatically updated to reflect the change to timeseries 2109. Similarly, the uses timeseries attribute 2158 can be treated as a list of timeseries to monitor for updates. When any of the timeseries identified by the uses timeseries attribute 2158 are updated, timeseries 2109 can be automatically updated to reflect the updates to the other timeseries upon which timeseries 2109 is based.

[0513] Referring now to FIG. 2 IB, an example of an entity graph 2160 for a particular system of devices is shown, according to some embodiments. Entity graph 2160 is shown to include an organization 2161 ("ACME Corp"). Organization 2161 be a collection of people, a legal entity, a business, an agency, or other type of organization. Organization 2161 occupies space 2163 ("Milwaukee Campus"), as indicated by the occupies attribute 2164. Space 2163 is occupied by organization 2161, as indicated by the occupied by attribute 2162.

[0514] In some embodiments, space 2163 is a top level space in a hierarchy of spaces. For example, space 2163 can represent an entire campus (i.e., a collection of buildings). Space 2163 can contain various subspaces (e.g., individual buildings) such as space 2165 ("Building 1") and space 2173 ("Building 2"), as indicated by the contains attributes 2168 and 2180. Spaces 2165 and 2180 are located in space 2163, as indicated by the located in attribute 2166. Each of spaces 2165 and 2173 can contain lower level subspaces such as individual floors, zones, or rooms within each building. However, such subspaces are omitted from entity graph 2160 for simplicity. [0515] Space 2165 is served by system 2167 ("ElecMainMeterl") as indicated by the served by attribute 2172. System 2167 can be any system that serves space 2165 (e.g., a HVAC system, a lighting system, an electrical system, a security system, etc.). The serves attribute 2170 indicates that system 2167 serves space 2165. In entity graph 2160, system 2167 is shown as an electrical system having a subsystem 2169 ("LightingSubMeterl") and a subsystem 2171 ("PlugLoadSubMeter2") as indicated by the subsystem attributes 2176 and 2178. Subsystems 2169 and 2171 are part of system 2167, as indicated by the part of attribute 2174.

[0516] Space 2173 is served by system 2175 ("ElecMainMeter2") as indicated by the served by attribute 2184. System 2175 can be any system that serves space 2173 (e.g., a HVAC system, a lighting system, an electrical system, a security system, etc.). The serves attribute 2182 indicates that system 2175 serves space 2173. In entity graph 2160, system 2175 is shown as an electrical system having a subsystem 2177 ("LightingSubMeter3") as indicated by the subsystem attribute 2188. Subsystem 2177 is part of system 2175, as indicated by the part of attribute 2186.

[0517] In addition to the attributes shown in FIG. 2 IB, entity graph 2160 can include "ancestors" and "descendants" attributes on each entity in the hierarchy. The ancestors attribute can identify (e.g., in a flat list) all of the entities that are ancestors to a given entity. For example, the ancestors attribute for space 2165 may identify both space 2163 and organization 2161 as ancestors. Similarly, the descendants attribute can identify all (e.g., in a flat list) of the entities that are descendants of a given entity. For example, the descendants attribute for space 2165 may identify system 2167, subsystem 2169, and subsystem 2171 as descendants. This provides each entity with a complete listing of its ancestors and descendants, regardless of how many levels are included in the hierarchical tree. This is a form of transitive closure.

[0518] In some embodiments, the transitive closure provided by the descendants and ancestors attributes allows entity graph 2160 to facilitate 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 2163 :

/Systems?$filter=(systemType eq

Jci.Be.Data.SystemType'Meter') and

ancestorSpaces/any(a: a/name eq 'Milwaukee Campus') and can be answered using only the descendants attribute of the Milwaukee Campus space 2163. For example, the descendants attribute of space 2163 can identify all meters that are hierarchically below space 2163. The descendants attribute can be organized as a flat list and stored as an attribute of space 2163. This allows the query to be served by searching only the descendants attribute of space 2163 without requiring other levels or entities of the hierarchy to be searched.

[0519] Referring now to FIG. 22, an object relationship diagram 2200 is shown, according to some embodiments. Relationship diagram 2200 is shown to include an entity template 2202, a point 2204, a timeseries 2206, and a sample 2208. In some embodiments, entity template 2202, point 2204, timeseries 2206, and sample 2208 are stored as data objects within memory 610 or timeseries database 928. Relationship diagram 2200 illustrates the relationships between entity template 2202, point 2204, and timeseries 2206.

[0520] Entity template 2202 can include various attributes such as an ID attribute, a name attribute, a properties attribute, and a relationships attribute. The ID attribute can be provided as a text string and identifies a unique ID for entity template 2202. The name attribute can also be provided as a text string and identifies the name of entity template 2202. The properties attribute can be provided as a vector and identifies one or more properties of entity template 2202. The relationships attribute can also be provided as a vector and identifies one or more relationships of entity template 2202.

[0521] Point 2204 can include various attributes such as an ID attribute, an entity template ID attribute, a timeseries attribute, and a units ID attribute. The ID attribute can be provided as a text string and identifies a unique ID for point 2204. The entity template ID attribute can also be provided as a text string and identifies the entity template 2202 associated with point 2204 (e.g., by listing the ID attribute of entity template 2202). Any number of points 2204 can be associated with entity template 2202. However, in some embodiments, each point 2204 is associated with a single entity template 2202. The timeseries attribute can be provided as a text string and identifies any timeseries associated with point 2204 (e.g., by listing the ID string of any timeseries 2206 associated with point 2204). The units ID attribute can also be provided as a text string and identifies the units of the variable quantified by point 2204. [0522] Timeseries 2206 can include various attributes such as an ID attribute, a samples attribute, a transformation type attribute, and a units ID attribute. The ID attribute can be provided as a text string and identifies a unique ID for timeseries 2206. The unique ID of timeseries 2206 can be listed in the timeseries attribute of point 2204 to associate timeseries 2206 with point 2204. Any number of timeseries 2206 can be associated with point 2204. Each timeseries 2206 is associated with a single point 2204. The samples attribute can be provided as a vector and identifies one or more samples associated with timeseries 2206. The transformation type attribute identifies the type of transformation used to generate timeseries 2206 (e.g., average hourly, average daily, average monthly, etc.). The units ID attribute can also be provided as a text string and identifies the units of the variable quantified by timeseries 2206.

[0523] Sample 2208 can include a timestamp attribute and a value attribute. The timestamp attribute can be provided in local time and can include an offset relative to universal time. The value attribute can include a data value of sample 2208. In some instances, the value attribute is a numerical value (e.g., for measured variables). In other instances, the value attribute can be a text string such as "Fault" if sample 2208 is part of a fault detection timeseries.

Nested Stream Generation

[0524] Referring now to FIGS. 23A-25B, building management platform 102 can be configured to generate nested streams of timeseries data. Nested streams can include various types of derived timeseries created by processing DAGs. For example, nested streams can include data rollup timeseries, virtual point timeseries, weather point timeseries, fault detection timeseries, assigned state timeseries, abnormal event timeseries, and/or any other type of derived timeseries previously described. In some embodiments, the nested streams are created from input timeseries retrieved from timeseries database 928 (as described with reference to FIGS. 13A-13B). In other embodiments, the nested streams are created from streaming data received in real-time from IoT devices 2614 and/or other data sources (as described with reference to FIG. 14). In some embodiments, the nested streams are used as an intermediate timeseries in a timeseries processing workflow. For example, a first derived timeseries can be created by processing a first DAG and used as an input to a second DAG to create a second derived timeseries (as described with reference to FIGS. 25A-25B). Timeseries Processing Workflow

[0525] Referring particularly to FIG. 23 A, a block diagram illustrating a timeseries processing workflow 2300 is shown, according to an exemplary embodiment. Workflow 2300 may be performed by workflow manager 922 in combination with other components of timeseries service 628. Workflow 2300 is shown to include performing a read of the timeseries data (step 2302). Step 2302 may include reading raw data samples and/or the derived data samples provided by timeseries storage interface 916. The timeseries data may be stored in timeseries database 928. In some embodiments, timeseries database 928 includes on-site data storage (e.g., Redis, PostgreSQL, etc.) and/or cloud data storage (e.g., Azure Redis, DocDB, HBase, etc.).

[0526] Timeseries storage interface 916 can be configured to read and write a timeseries collection, a samples collection, and a post sample request (PSR) collection. Each of these collections can be stored in timeseries database 928. The timeseries collection may contain all the timeseries registered in workflow manager 922. The timeseries collection may also contain the DAG for each timeseries. The timeseries collection can be used by workflow manager 922 to accept only PSRs related to valid timeseries registered in workflow manager 922. The timeseries collection can also be used in steps 2314-2316 to lookup the DAG for a specific timeseries ID.

[0527] In some embodiments, the entire timeseries collection is loaded into local memory. The timeseries collection can be a regular collection or a partitioned collection (e.g., one partition for approximately every 100 timeseries). In some embodiments, the timeseries collection contains about 200,000 to 250,000 timeseries. The ID for each document in the timeseries collection may be the timeseries ID. The DAG for each timeseries may contain a set of operations and/or transformations that need to be performed to generate the derived timeseries data based on the timeseries. On registration of a new timeseries, the DAG for the timeseries can be selected from DAG templates. The DAG template may include a set of standard operations applicable to the timeseries. On definition of a new metric for a timeseries, the new metric and the list of operations to generate that metric can be added to the DAG.

[0528] The samples collection may contain all of the timeseries samples (e.g., raw samples, derived timeseries samples). The samples collection can be used for all GET requests for a specific timeseries ID. A portion of the samples collection can be stored in local memory (e.g., past 48 hours) whereas the remainder of the samples collection can be stored in timeseries database 928. The samples collection may act as a partitioned collection instead of a regular collection to improve efficiency and performance. In some embodiments, the samples collection is stored in a JSON format and partitioned on timeseries ID. The ID field may be unique for each partition and may have the form "Metric: Timestamp."

[0529] The PSR collection may contain all of the PSRs and can be used to provide status updates to the user for a PSR related to a specific timeseries ID. A portion of the PSR collection can be stored in local memory (e.g., past 48 hours) whereas the remainder of the PSR collection can be stored in timeseries database 928. The PSR collection can be partitioned on timeseries ID. In some embodiments, the ID for each document in the PSR collection has the form "TimeseriesID: Timestamp."

[0530] Still referring to FIG. 23 A, workflow 2300 is shown to include accepting a PSR (step 2304). Step 2304 may be performed by executing a PSR process. In some

embodiments, the PSR process receives a PSR and determines whether the PSR contains more than one timeseries ID. In response to a determination that the PSR contains more than one timeseries ID, the PSR process may break the PSR into multiple PSRs, each of which is limited to a single timeseries ID. The PSRs can be provided to PSR event hub 2306. PSR event hub 2306 can be configured to store PSR events. Each PSR event may include a PSR for one timeseries ID. In some embodiments, each PSR event is stored in the form

"TimeseriesID: Timestamp."

[0531] Workflow 2300 is shown to include deduplicating raw samples (step 2308). Step 2308 may be performed by executing a deduplication process. In some embodiments, the deduplication process includes accepting PSR events from PSR event hub 2306 and splitting each PSR into a list of samples. Step 2308 may include tagging each sample as a new sample, an updated sample, or a duplicate sample. New samples and updated samples can be sent to raw samples event hub 2310, whereas duplicate samples may be discarded. In some embodiments, step 2308 is deployed on Azure using Azure Worker Roles. Step 2308 can include checking for duplicate samples in timeseries database 928 as well as the samples that are currently in raw samples event hub 2310.

[0532] In some embodiments, the deduplication process in step 2308 removes all duplicate data samples such that only a single unique copy of each data sample remains. Removing all duplicate samples may ensure that aggregate operations produce accurate aggregate values. In other embodiments, the deduplication process in step 2308 is configured to remove most, but not all, duplicate samples. For example, the deduplication process can be implemented using a Bloom filter, which allows for the possibility of false positives but not false negatives. In step 2308, a false positive can be defined as a non-duplicate new or updated sample. Accordingly, some duplicates may be flagged as non-duplicate, which introduces the possibility that some duplicate samples may not be properly identified and removed. The deduplicated raw samples can be sent to raw samples event hub 2310.

[0533] Workflow 2300 is shown to include storing the raw samples (step 2312). Step 2312 can include accepting the raw samples from raw samples event hub 2310 and pushing the raw samples to persistent storage. In some embodiments, step 2312 is deployed on Azure using Azure Worker Roles. The worker role may generate requests at a rate based on X% of the capacity of the storage. For example, if the capacity of the storage is 10,000 storage units and X% is 20% (e.g., 20% of the storage throughput is reserved for sample writes), and each write takes 5 storage units, step 2312 may generate a total of 400 writes per second (i.e., ¹⁰ '°°» ^*20% ₌ 400).

[0534] Workflow 2300 is shown to include generating an event trigger DAG (step 2314). Step 2314 can be performed by executing an event trigger DAG process. Step 2314 may include accepting events (samples) from raw samples event hub 2310. For each sample event, step 2314 may include identifying the timeseries ID of the sample and accessing the timeseries collection to obtain the DAG for the corresponding timeseries. Step 2314 may include identifying each derived data timeseries generated by the DAG and each operation included in the DAG. In some embodiments, step 2314 tags each operation to indicate whether the operation should be sent to the C# engine 2332 or the Python engine 2334 for execution. Step 2314 may include identifying and fetching any additional data (e.g., samples, timeseries, parameters, etc.) which may be necessary to perform the operations defined by the DAG. Step 2314 may generate an enriched DAG which includes the original DAG along with all the data necessary to perform the operations defined by the DAG. The enriched DAG can be sent to the DAG event hub 2318.

[0535] In some embodiments, workflow 2300 includes generating a clock trigger DAG (step 2316). Step 2316 can be performed by executing a clock trigger DAG process. Step 2316 may be similar to step 2314. However, step 2316 may be performed in response to a clock trigger rather than in response to receiving a raw sample event. The clock trigger can periodically trigger step 2316 to perform batch queries (e.g., every hour). Step 2316 may include identifying a timeseries ID specified in the clock trigger and accessing the timeseries collection to obtain the DAG for the corresponding timeseries. Step 2316 may include identifying each derived data timeseries generated by the DAG and each operation included in the DAG. In some embodiments, step 2316 tags each operation to indicate whether the operation should be sent to the C# engine 2332 or the Python engine 2334 for execution. Step 2316 may include identifying and fetching any additional data (e.g., samples, timeseries, parameters, etc.) which may be necessary to perform the operations defined by the DAG. Step 2316 may generate an enriched DAG which includes the original DAG along with all the data necessary to perform the operations defined by the DAG. The enriched DAG can be sent to the DAG event hub 2318.

[0536] DAG event hub 2318 can be configured to store enriched DAG events. Each enriched DAG event can include an enriched DAG. The enriched DAG may include a DAG for a particular timeseries along with all the data necessary to perform the operations defined by the DAG. DAG event hub 2318 can provide the enriched DAG events to step 2320.

[0537] Still referring to FIG. 23 A, workflow 2300 is shown to include running the DAG (step 2320). Step 2320 can include accepting enriched DAG events from DAG event hub 2318 and running through the sequence of operations defined by the DAG. Workflow manager 922 can submit each operation in series to execution engines 2330 and wait for results before submitting the next operation. Execution engines 2330 may include a C# engine 2332, a Python engine 2334, or any other engine configured to perform the operations defined by the DAG. In some embodiments, execution engines 2330 include timeseries operators 906. When a given operation is complete, execution engines 2330 can provide the results of the operation to workflow manager 922. Workflow manager 922 can use the results of one or more operations as inputs for the next operation, along with any other inputs that are required to perform the operation. In some embodiments, the results of the operations are the derived timeseries samples. The derived timeseries samples can be provided to derived timeseries event hub 2322.

[0538] Derived timeseries event hub 2322 can be configured to store derived timeseries sample. Each derived timeseries sample may include a sample of a derived timeseries. The derived timeseries may include the results of the operations performed by execution engines 2330. Derived timeseries event hub 2322 can provide the derived timeseries samples to step 2324.

[0539] Workflow 2300 is shown to include storing the derived timeseries samples (step 2324). Step 2324 can include accepting derived timeseries samples from derived timeseries event hub 2322 and storing the derived timeseries samples in persistent storage (e.g., timeseries database 928). In some embodiments, step 2324 is deployed on Azure using Azure Worker Roles. The worker role may generate requests at a rate based on Y% of the capacity of the storage. For example, if the capacity of the storage is 10,000 storage units and Y% is 50% (e.g., 50% of the storage throughput is reserved for sample writes), and each write takes 5 storage units, step 2324 may generate a total of 1,000 writes per second (i.e.,

1000^50% _{= 1 000)}

[0540] Referring now to FIG. 23B, a flowchart of a process 2350 for obtaining and processing timeseries data is shown, according to an exemplary embodiment. Process 2350 can be performed by workflow manager 922 in combination with other components of timeseries service 628. Process 2350 is shown to include obtaining samples of a timeseries from timeseries storage (step 2352). Step 2352 may include obtaining raw data samples and/or derived data samples via timeseries storage interface 916. The samples of the timeseries may be obtained from timeseries database 928 or received in real-time from a sensor or other device that generates the samples. Step 2352 can include loading the entire timeseries or a subset of the samples of the timeseries into local memory. For example, some of the samples of the timeseries may be stored in local memory (e.g., past 48 hours) whereas the remainder of the samples of the timeseries can be stored in timeseries database 928.

[0541] Process 2350 is shown to include handling a post-sample request (PSR) associated with the timeseries (step 2354). The PSR may be obtained from a PSR collection via timeseries storage interface 916. The PSR can be used to provide status updates to the user for a specific timeseries ID. In some embodiments, step 2354 includes receiving a PSR and determining whether the PSR contains more than one timeseries ID. In response to a determination that the PSR contains more than one timeseries ID, step 2354 may include breaking the PSR into multiple PSRs, each of which is limited to a single timeseries ID. The PSRs can be provided to PSR event hub 2306 and stored as PSR events. Each PSR event may include a PSR for one timeseries ID. In some embodiments, each PSR event is stored in the form "TimeseriesID: Timestamp."

[0542] Process 2350 is shown to include deduplicating samples of the timeseries (step 2356). Step 2356 may be performed by executing a deduplication process. In some embodiments, the deduplication process includes accepting PSR events from PSR event hub 2306 and splitting each PSR into a list of samples. Step 2356 may include tagging each sample as a new sample, an updated sample, or a duplicate sample. New samples and updated samples can be sent to raw samples event hub 2310, whereas duplicate samples may be discarded. In some embodiments, step 2356 is deployed on Azure using Azure Worker Roles. Step 2356 can include checking for duplicate samples in timeseries database 928 as well as the samples that are currently in raw samples event hub 2310.

[0543] In some embodiments, the deduplication process in step 2356 removes all duplicate data samples such that only a single unique copy of each data sample remains. Removing all duplicate samples may ensure that aggregate operations produce accurate aggregate values. In other embodiments, the deduplication process in step 2356 is configured to remove most, but not all, duplicate samples. For example, the deduplication process can be implemented using a Bloom filter, which allows for the possibility of false positives but not false negatives. In step 2356, a false positive can be defined as a non-duplicate new or updated sample. Accordingly, some duplicates may be flagged as non-duplicate, which introduces the possibility that some duplicate samples may not be properly identified and removed. The deduplicated samples can be sent to raw samples event hub 2310.

[0544] Still referring to FIG. 23B, process 2350 is shown to include identifying one or more stored DAGs that use the timeseries as an input (step 2358). Step 2358 can include obtaining the stored DAGs via timeseries via timeseries storage interface 916 and identifying the required timeseries inputs of each DAG. For each DAG that uses the timeseries as an input, process 2350 can identify the timeseries processing operations defined by the DAG (step 2360). The timeseries processing operations can include data cleansing operations, data aggregation operations, timeseries adding operations, virtual point calculation operations, or any other type of operation that can be applied to one or more input timeseries.

[0545] Process 2350 is shown to include identifying and obtaining samples of any timeseries required to perform the timeseries processing operations (step 2362). The timeseries can be identified by inspecting the inputs required by each of the timesenes processing operations identified in step 2360. For example, DAG 2000 in FIG. 20A is shown to include both "Timeseries ID: 123" and "Timeseries ID: 456" as required inputs. Assuming that samples of the timeseries ID 123 are obtained in step 2352, DAG 2000 can be identified in step 2358 as a DAG that uses the timeseries ID 123 as an input. The timeseries identified in step 2362 can include timeseries ID 123, timeseries ID 456, or any other timeseries used as an input to DAG 2000. Step 2362 may include identifying and fetching any additional data (e.g., samples, timeseries, parameters, etc.) which may be necessary to perform the operations defined by the DAG.

[0546] In some embodiments, the samples obtained in step 2362 are based on the timeseries processing operations defined by the DAG, as well as the timestamps of the original samples obtained in step 2352. For example, the DAG may include a data aggregation operation that aggregates a plurality of data samples having timestamps within a given time window. The start time and end time of the time window may be defined by the DAG and the timeseries to which the DAG is applied. The DAG may define the duration of the time window over which the data aggregation operation will be performed. For example, the DAG may define the aggregation operation as an hourly aggregation (i.e., to produce an hourly data rollup timeseries), a daily aggregation (i.e., to produce a daily data rollup timeseries), a weekly aggregation (i.e., to produce a weekly data rollup timeseries), or any other aggregation duration. The position of the time window (e.g., a specific day, a specific week, etc.) over which the aggregation is performed may be defined by the timestamps of the samples obtained in step 2352.

[0547] Step 2362 can include using the DAG to identify the duration of the time window (e.g., an hour, a day, a week, etc.) over which the data aggregation operation will be performed. Step 2362 can include using the timestamps of the data samples obtained in step 2352 identify the location of the time window (i.e., the start time and the end time). Step 2362 can include setting the start time and end time of the time window such that the time window has the identified duration and includes the timestamps of the data samples obtained in step 2352. In some embodiments, the time windows are fixed, having predefined start times and end times (e.g., the beginning and end of each hour, day, week, etc.). In other embodiments, the time windows may be sliding time windows, having start times and end times that depend on the timestamps of the data samples in the input timeseries. Once the appropriate time window has been set and the other input timeseries are identified, step 2362 can obtain samples of any input timeseries to the DAG that have timestamps within the appropriate time window. The input timeseries can include the original timeseries identified in step 2352 and any other timeseries used as input to the DAG.

[0548] Process 2350 is shown to include generating an enriched DAG including the original DAG and all timeseries samples required to perform the timeseries processing operations (step 2364). The original DAG may be the DAG identified in step 2358. The timeseries samples required to perform the timeseries processing operations may include any of the timeseries samples obtained in step 2362. In some embodiments, step 2364 includes identifying each derived data timeseries generated by the DAG and each operation included in the DAG. In some embodiments, step 2364 tags each operation to indicate a particular execution engine (e.g., C# engine 2332, Python engine 2334, etc.) to which the processing operation should be sent for execution.

[0549] Process 2350 is shown to include executing the enriched DAG to generate one or more derived timeseries (step 2366). Step 2366 can include submitting each timeseries processing operation in series to execution engines 2330 and waiting for results before submitting the next operation. When a given operation is complete, execution engines 2330 can provide the results of the operation to workflow manager 922. Process 2350 can use the results of one or more operations as inputs for the next operation, along with any other inputs that are required to perform the operation. In some embodiments, the results of the operations are the derived timeseries samples.

[0550] Process 2350 is shown to include storing the derived timeseries in the timeseries storage (step 2368). The derived timeseries may include the results of the operations performed in step 2366. Step 2368 can include accepting derived timeseries samples from derived timeseries event hub 2322 and storing the derived timeseries samples in persistent storage (e.g., timeseries database 928). In some embodiments, step 2368 is deployed on Azure using Azure Worker Roles. The worker role may generate requests at a rate based on Y% of the capacity of the storage. For example, if the capacity of the storage is 10,000 storage units and Y% is 50% (e.g., 50% of the storage throughput is reserved for sample writes), and each write takes 5 storage units, step 2368 may generate a total of 1,000 writes

, .. 10,000*50% _m

per second (i.e., = 1,000). Streaming Data Processing

[0551] Referring now to FIG. 24, a system 2400 for processing streaming data is shown, according to an exemplary embodiment. System 2400 can be implemented as part of building management platform 102 and may include various systems or devices configured to collect and process timeseries data. For example, system 2400 is shown to include IoT devices 2614, timeseries service 628, a weather service 152, timeseries database 928.

[0552] IoT devices 2614 may include any of a variety of sensors 2404, physical devices or equipment 2406 (e.g., actuators, electronics, vehicles, home appliances, etc.) and/or other items having network connectivity which enable IoT devices 2614 to communicate with building management platform 102. For example, IoT devices 2614 can include smart home hub devices, smart house devices, doorbell cameras, air quality sensors, smart switches, smart lights, smart appliances, garage door openers, smoke detectors, heart monitoring implants, biochip transponders, cameras streaming live feeds, automobiles with built-in sensors, DNA analysis devices, field operation devices, tracking devices for people/vehicles/equipment, networked sensors, wireless sensors, wearable sensors, environmental sensors, RFID gateways and readers, IoT gateway devices, robots and other robotic devices, GPS devices, smart watches, virtual/augmented reality devices, and/or other networked or networkable devices. In some embodiments, IoT devices 2614 include some or all of devices 112-116, 122-126, 132-136, and 142-146, as described with reference to FIG. 1.

[0553] IoT devices 2614 are shown providing timeseries samples and event data to timeseries service 628. Timeseries samples can include measurements obtained by sensors 2404. For example, sensors 2404 can collect various types of measurements and send the measurements to timeseries service 628. In some embodiments, each measurement includes a measured value indicating a value of the measured variable and a timestamp indicating a time at which the variable was measured. Timeseries samples may also include monitored variables or states of equipment 2406. For example, IoT devices 2614 may store internal variables that represent equipment states (e.g., equipment on/off, door open/closed, equipment operating at 50% capacity, etc.). Each timeseries sample may include a values of a particular variable or state and a timestamp indicating a time at which the variable or state was observed.

[0554] Event data may include any type of data describing various events observed by IoT devices 2614. Each sample of event data may include a description or indication of the event and a timestamp indicating when the event occurred. For example, event data may include badge access events that occur when a person scans an ID badge at a card reader of equipment 2406 (e.g., a particular badge was scanned at a particular card reader at a particular time). Event data may include security events generated by security equipment (e.g., intruder detected at south entrance). Event data may include alarms or faults detected by equipment 2406 and/or other types of IoT devices 2614 (e.g., a particular fault occurred within a particular device of equipment 2406 at a particular time).

[0555] Weather service 152 is shown providing weather data to timeseries service 628. Weather data may include samples of various weather-related variables observed by weather service 152. For example, weather data can include temperature data, humidity data, precipitation data, wind speed data, cloud position data, atmospheric pressure data, and/or other types of weather-related variables. Weather data can include current values of the weather-related variables, past values of the weather-related variables (e.g., historical values), and/or future values of the weather-related variables (e.g., predicted or estimated values). Each sample of the weather data may include a value of a particular weather-related variable and a timestamp indicating a time at which the corresponding value was observed or a time for which the corresponding value is predicted.

[0556] Timeseries service 628 is shown to include a timeseries identifier 2414, a DAG identifier 2416, execution engines 2330, and a timeseries generator 2418. Timeseries identifier 2414 can receive the timeseries samples and event data from IoT devices 2614 and the weather data from weather service 152. Timeseries identifier 2414 can identify a timeseries associated with each incoming data sample. The identified timeseries for a particular data sample may be a raw data timeseries stored in timeseries database 928 that contains a series of values for the same variable or data source. For example, timeseries can be stored in the following format:

[< key, timestamp^ value _x >, < key, timestamp ₂ , value ₂ >, < key, timestamp ₃ , value ₃

>] where key is an identifier of the source of the data samples (e.g., timeseries ID, sensor ID, etc.), timestampi identifies a time associated with the ith sample, and value^ indicates the value of the ith sample. Timeseries identifier 2414 can use attributes of the incoming data samples (e.g., data source, sensor ID, variable ID, etc.) to identify a particular timeseries associated with each sample and can provide the identified timeseries ID to DAG identifier 2416.

[0557] DAG identifier 2416 can use the timeseries ID received from timeseries identifier 2414 to identify one or more DAGs that use the identified timeseries as an input. As described above, a DAG may be a predefined sequence of processing operations that transform one or more input timeseries into one or more output timeseries. Accordingly, each DAG may have one or more input timeseries associated therewith. In some

embodiments, the input timeseries for each DAG are stored as attributes of the DAG in DAG database 930. DAG identifier 2416 can read such information from DAG database 930 to determine which of the stored DAGs use the identified timeseries as an input. DAG identifier 2416 can then provide an indication of the identified DAGs to execution engines 2330 in the form of one or more DAG IDs.

[0558] As described above, execution engines 2330 can include a C# engine 2332, a Python engine 2334, or any other engine configured to perform the operations defined by a DAG. In some embodiments, execution engines 2330 include timeseries operators 906. Execution engines 2330 can receive the incoming data from IoT devices 2614 and weather service 152 (i.e., the timeseries samples, event data, and weather data), as well as the DAG IDs from DAG identifier 2416. Execution engines 2330 can execute the DAGs, using the incoming data as an input, to generate derived timeseries samples. Each derived timeseries sample may be the result of a timeseries processing operation that uses an incoming data sample as an input. In some embodiments, each derived timeseries sample includes a key (e.g., a timeseries ID), a timestamp, and a value.

[0559] One type of derived timeseries sample is a virtual point sample. Execution engines 2330 can calculate virtual data points by applying any of a variety of mathematical operations or functions to actual data points or other virtual data points. For example, execution engines 2330 can calculate a virtual data point (pointID ₃ ) by adding two or more actual data points (pointlD-L and pointID ₂ ) (e.g., pointID ₃ = pointlD-L + pointID ₂ ). As another example, execution engines 2330 can calculate an enthalpy data point (pointID ₄ ) based on a measured temperature data point (pointID ₅ ) and a measured pressure data point (pointID ₆ ) (e.g., pointID ₄ = enthalpy (pointl D ₅ , pointlD _e )). In some instances, a virtual data point can be derived from a single actual data point. For example, execution engines 2330 can calculate a saturation temperature (pointID ₇ ) of a known refrigerant based on a measured refrigerant pressure (pointID ₈ ) (e.g., pointID ₇ = T _sat (pointID ₈ )).

[0560] Another type of derived timeseries sample is a virtual weather point sample.

Execution engines 2330 can calculate values of virtual weather point samples by applying the timeseries processing operations defined by a DAG to the incoming weather data. For example, execution engines 2330 can perform weather-based calculations using the incoming weather data to generate values for weather-related variables such as cooling degree days (CDD), heating degree days (FIDD), cooling energy days (CED), heating energy days (FLED), and normalized energy consumption. These and other examples of weather-related derived timeseries samples are described in detail with reference to weather point calculator 912.

[0561] Another type of derived timeseries sample is a sample of a fault detection timeseries. Execution engines 2330 can evaluate fault detection rules defined by a DAG to detect faults in the incoming data. For example, execution engines 2330 can apply the fault detection rules to the input timeseries samples to determine whether each sample of the input timeseries qualifies as a fault. In some embodiments, each derived timeseries sample includes a timestamp and a fault detection value. The timestamp can be the same as the timestamp of the corresponding data sample of the input timeseries. The fault detection value can indicate whether the corresponding data sample of the data timeseries qualifies as a fault. For example, the fault detection value can have a value of "Fault" if a fault is detected and a value of "Not in Fault" if a fault is not detected in the corresponding data sample of the data timeseries.

[0562] Another type of derived timeseries sample is a sample of an abnormal event timeseries. Execution engines 2330 can evaluate abnormal event detection rules defined by a DAG to detect abnormal events in the event data. For example, execution engines 2330 can apply the abnormal event detection rules to the event data to determine whether each sample of the event data qualifies as an abnormal event. In some embodiments, each derived timeseries sample of an abnormal event timeseries includes a timestamp and an abnormal event value. The timestamp can be the same as the timestamp of the corresponding sample of the event data. The abnormal event value can indicate whether the corresponding sample of the event data is normal or abnormal. For example, the abnormal event value can have a value of "Abnormal" if the event meets the criteria for abnormal events and a value of "Normal" if the event does not meet the criteria for abnormal events. [0563] In some embodiments, an event is considered abnormal if it deviates significantly from other similar events (e.g., events associated with the same individual, the same space, the same equipment, etc.). For example, if the event data indicates that a particular person typically badges into a building between 8:30 AM and 9:00 AM every day, an event indicating that the person is badging into the building at 3 :00 AM may be considered abnormal. Similarly, if the weather data indicates that a particular building typically experiences outdoor air temperatures between 30 °F and 40 °F during a particular month, a temperature of 60 °F during that month may be considered abnormal.

[0564] Timeseries generator 2418 can use the derived timeseries samples to generate various derived timeseries. The derived timeseries can include data rollup timeseries, virtual point timeseries, weather point timeseries, fault detection timeseries, assigned state timeseries, abnormal event timeseries, and/or any other type of derived timeseries created by executing the identified DAGs. Timeseries generator 2418 can store the derived timeseries in timeseries database 928 or other persistent storage.

Iterative Timeseries Processing

[0565] Referring now to FIG. 25 A, system 2400 can be configured perform iterative timeseries processing. For example, timeseries identifier 2414 is shown receiving an input timeseries. The input timeseries can be a raw data timeseries, a derived timeseries, or a collection of timeseries samples received from IoT devices 2614 or weather service 152 in real-time (e.g., incoming streaming data). Timeseries identifier 2414 identify a timeseries ID associated with the input timeseries and can provide the timeseries ID to DAG identifier 2416.

[0566] DAG identifier 2416 can use the timeseries ID received from timeseries identifier 2414 to identify one or more DAGs that use the input timeseries as an input. As described above, a DAG may be a predefined sequence of processing operations that transform one or more input timeseries into one or more output timeseries. Accordingly, each DAG may have one or more input timeseries associated therewith. In some embodiments, the input timeseries for each DAG are stored as attributes of the DAG in DAG database 930. DAG identifier 2416 can read such information from DAG database 930 to determine which of the stored DAGs use the input timeseries as an input. DAG identifier 2416 can then provide an indication of the identified DAGs to execution engines 2330 in the form of one or more DAG IDs. [0567] Execution engines 2330 can execute the identified DAGs, using the input timeseries as an input, to generate derived timeseries samples. Timeseries generator 2418 can then assemble the derived timeseries samples into a first derived timeseries. The first derived timeseries can be stored in timeseries database 928. The first derived timeseries can also be provided as an input to timeseries identifier 2414.

[0568] Timeseries identifier 2414 can treat the first derived timeseries as an input and the entire process can be repeated. For example, timeseries identifier 2414 identify a timeseries ID associated with the first derived timeseries and can provide the timeseries ID to DAG identifier 2416. DAG identifier 2416 can use the timeseries ID received from timeseries identifier 2414 to identify one or more DAGs that use the first derived timeseries as an input. DAG identifier 2416 can then provide an indication of the identified DAGs to execution engines 2330 in the form of one or more DAG IDs. Execution engines 2330 can execute the identified DAGs, using the first derived timeseries as an input, to generate derived timeseries samples. Timeseries generator 2418 can then assemble the derived timeseries samples into a second derived timeseries. The second derived timeseries can be stored in timeseries database 928.

[0569] Referring now to FIG. 25B, a flowchart of an iterative timeseries processing process 2500 is shown, according to an exemplary embodiment. Process 2500 can be performed by one or more components of building management platform 102 or system 2400 as previously described. Process 2500 is shown to include obtaining an input timeseries (step 2502) and identifying a first DAG that uses the input timeseries as an input (step 2504). Process 2500 is shown to include performing timeseries processing operations defined by the DAG to generate a derived timeseries (step 2506). The derived timeseries can be stored in timeseries database 928.

[0570] The derived timeseries can then be treated as an input to timeseries service 628. For example, process 2500 is shown to include identifying another DAG that uses the derived timeseries as an input (step 2508) and performing timeseries processing operations defined by the other DAG to generate another derived timeseries (step 2510). In some embodiments, the DAG that uses the derived timeseries as an input is different from the first DAG that uses the input timeseries as an input. The derived timeseries created in step 2510 can be stored in timeseries database 928. [0571] The derived timeseries created in step 2510 can also be treated as another input to timeseries service 628. Steps 2508-2510 can be repeated iteratively until the timeseries created in the most recent iteration of step 2510 is not used as an input to any of the DAGs. Each iteration of steps 2508-2510 may generate another derived timeseries which can be stored in timeseries database 928.

Cloud-Based Feedback Control

[0572] Referring now to FIG. 26, a block diagram of a cloud-based feedback control system 2600 is shown, according to an exemplary embodiment. Conventional feedback control systems typically include an on-site feedback controller located nearby the controlled system or device. For example, control systems for building equipment typically include a controller located within in the same building or facility as the building equipment. The building equipment provide measurements or other feedback to the controller via a wired or wireless communications link (e.g., Ethernet, Wi-Fi, etc.) or local area network (LAN) within the building. The controller uses the feedback from the building equipment to generate an appropriate control signal, which is provided as a control input to the building equipment via the wired or wireless communications link or LAN.

[0573] Cloud-based feedback control system 2600 makes use of building management platform 102 to provide feedback control as a cloud-based platform service. For example, control system 2600 is shown to include building management platform 102, network 104, and campus 2602. In brief overview, campus 2602 provides feedback samples (e.g., measurements, samples of monitored variables, system states, values of points, etc.) to building management platform 102 via network 104. Building management platform 102 uses the feedback samples as an input to a cloud-based feedback control algorithm (e.g., PID, MPC, etc.) that uses the feedback samples to generate control signal samples. In some embodiments, building management platform 102 treats the feedback samples as samples of an input timeseries and processes the input timeseries using a feedback control DAG. The feedback control DAG converts the feedback samples into control signal samples, which are a type of derived timeseries samples. The control signal samples are then provided as a control signal back to campus 102 via network 104.

[0574] As described above, building management platform 102 can be distributed across multiple processing devices and can therefore make use of multiple processing devices to generate the control signals. The use of multiple processing devices provides several advantages relative to conventional on-site controllers that use only a single processing device. For example, the use of multiple remote processing devices reduces need for in- building processing devices or other on-site resources such as physical controllers located at the building site. The use of multiple remote processing devices also reduces processing latency relative to a single processing device by enabling parallel processing across multiple devices. For example, some portions of the feedback control DAG can be processed by a first processing device, whereas other portions of the feedback control DAG can be processed by other processing devices. This allows for faster execution and more responsive feedback control relative to conventional on-site controllers with a single processing device.

[0575] Campus 2602 is shown to include a building management system (BMS) 2604, a central plant 2606, and IoT devices 2614. A BMS is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. For example, BMS 2604 may include a HVAC system, a security system, a lighting system, a fire alerting system, any other system that is capable of managing building functions or devices, or any combination thereof. An example of a BMS which can be used as BMS 2604 is described in detail in U.S. Patent Application No. 14/717,593, titled

"Building Management System for Forecasting Time Series Values of Building Variables" and filed May 20, 2015, the entire disclosure of which is incorporated by reference herein.

[0576] BMS 2604 may include a variety of building subsystems including, for example, a building electrical subsystem, an information communication technology (ICT) subsystem, a security subsystem, a HVAC subsystem, a lighting subsystem, a lift/escalators subsystem, and a fire safety subsystem. In various embodiments, the building subsystems can include fewer, additional, or alternative subsystems. For example, the building subsystems can also or alternatively include a refrigeration subsystem, an advertising or signage subsystem, a cooking subsystem, a vending subsystem, a printer or copy service subsystem, or any other type of building subsystem that uses controllable equipment and/or sensors to monitor or control a variable state or condition of a building.

[0577] Each of the building subsystems can include any number of devices, controllers, and connections (referred to collectively as building equipment 2608) for completing its individual functions and control activities. Building equipment 2608 can include HVAC equipment such as chillers, boilers, air handling units, economizers, field controllers, supervisory controllers, actuators, sensors (e.g., temperature, humidity, flow rate, etc.), and other devices for controlling the temperature, humidity, airflow, or other variable conditions within a building. In some embodiments, building equipment 2608 includes lighting equipment such as light fixtures, ballasts, lighting sensors, dimmers, or other devices configured to controllably adjust the amount of light provided to a building space. In some embodiments, building equipment 2608 includes security equipment such as occupancy sensors, video surveillance cameras, digital video recorders, video processing servers, intrusion detection devices, access control devices and servers, or other security-related devices.

[0578] Central plant 2606 may include one or more subplants that consume resources from utilities (e.g., water, natural gas, electricity, etc.) to satisfy the loads of campus 2602. For example, central plant 2606 may include a heater subplant, a heat recovery chiller subplant, a chiller subplant, a cooling tower subplant, a hot thermal energy storage (TES) subplant, and a cold thermal energy storage (TES) subplant, a steam subplant, and/or any other type of subplant configured to serve campus 2602. Each of the subplants may include a variety of central plant equipment 2610 (e.g., boilers, chillers, heat recovery chillers, cooling towers, thermal energy storage tanks, batteries, etc.). The subplants may be configured to convert input resources (e.g., electricity, water, natural gas, etc.) into output resources (e.g., cold water, hot water, chilled air, heated air, etc.) that are provided to buildings of campus 2602. An exemplary central plant which may be used as central plant 2606 is described U.S. Patent Application No. 14/634,609, titled "High Level Central Plant Optimization" and filed February 27, 2015, the entire disclosure of which is incorporated by reference herein.

[0579] IoT devices 2614 may include any of a variety of sensors, physical devices or equipment (e.g., actuators, electronics, vehicles, home appliances, etc.), and/or other items having network connectivity which enable IoT devices 2614 to communicate with building management platform 102. For example, IoT devices 2614 can include smart home hub devices, smart house devices, doorbell cameras, air quality sensors, smart switches, smart lights, smart appliances, garage door openers, smoke detectors, heart monitoring implants, biochip transponders, cameras streaming live feeds, automobiles with built-in sensors, DNA analysis devices, field operation devices, tracking devices for people/vehicles/equipment, networked sensors, wireless sensors, wearable sensors, environmental sensors, RFID gateways and readers, IoT gateway devices, robots and other robotic devices, GPS devices, smart watches, virtual/augmented reality devices, and/or other networked or networkable devices. In some embodiments, IoT devices 2614 include some or all of devices 112-116, 122-126, 132-136, and 142-146, as described with reference to FIG. 1.

[0580] Campus 2602 is shown providing feedback samples to building management platform 102, specifically to timeseries service 628. The feedback samples can include measurements obtained by sensors of building equipment 2608, central plant equipment 2610, and/or IoT devices 2614. For example, the sensors can collect various types of measurements and send the measurements to timeseries service 628. In some embodiments, each measurement includes a measured value indicating a value of the measured variable and a timestamp indicating a time at which the variable was measured. Feedback samples may also include monitored variables or states of building equipment 2608, central plant equipment 2610, and/or IoT devices 2614. For example, building equipment 2608, central plant equipment 2610, and/or IoT devices 2614 may store internal variables that represent equipment states (e.g., equipment on/off, door open/closed, equipment operating at 50% capacity, etc.). Each feedback sample may include a value of a particular variable or state and a timestamp indicating a time at which the variable or state was observed.

[0581] Timeseries service 628 is shown to include a timeseries identifier 2414, a DAG identifier 2416, execution engines 2330, and a timeseries generator 2418. Timeseries identifier 2414 can receive the feedback samples from campus 2602 and can identify a timeseries associated with each incoming data sample. The identified timeseries for a particular feedback sample may be a feedback timeseries (i.e., a type of raw data timeseries) stored in timeseries database 928 that contains a series of values for the same variable or data source. For example, feedback timeseries can be stored in the following format:

[< key, timestamp^ value _x >, < key, timestamp ₂ , value ₂ >, < key, timestamp ₃ , value ₃

>] where key is an identifier of the source of the feedback samples (e.g., timeseries ID, sensor ID, etc.), timestampi identifies a time associated with the ith sample, and value _t indicates the value of the tth sample. Timeseries identifier 2414 can use attributes of the incoming feedback samples (e.g., data source, sensor ID, variable ID, etc.) to identify a particular feedback timeseries associated with each sample and can provide the identified timeseries ID to DAG identifier 2416. [0582] DAG identifier 2416 can use the timeseries ID received from timeseries identifier 2414 to identify one or more feedback control DAGs that use the identified feedback timeseries as an input. As described above, a DAG may be a predefined sequence of processing operations that transform one or more input timeseries into one or more output timeseries. Accordingly, each DAG may have one or more input timeseries associated therewith. A feedback control DAG is a type of DAG that defines a feedback control algorithm. For example, a feedback control DAG can accept the feedback samples as an input and can define a sequence of processing operations that transform the feedback samples into control signal samples using a feedback control technique. The processing operations defined by a feedback control DAG can implement any of a variety of feedback control techniques including, for example, state-based control, extremum seeking control (ESC), proportional-integral (PI) control, proportional-integral-derivative (PID) control, model predictive control (MPC), or any other type of feedback control technique.

[0583] One example of a feedback control DAG is a PID control DAG. A PID control DAG may cause execution engines 2330 to perform a set of processing operations typically performed by a PID controller. For example, the PID control DAG may cause execution engines 2330 to calculate a difference between the feedback timeseries and a setpoint timeseries. The calculated difference can be saved as an error timeseries. The PID control DAG may cause execution engines 2330 to apply a proportional gain to the error timeseries (e.g., multiplying the error timeseries by a proportional gain parameter) to generate a proportional gain component of the control signal.

[0584] The PID control DAG may cause execution engines 2330 to integrate the error timeseries over time to calculate an integrated error value for each sample of the error timeseries. The integrated error values may be summations (i.e., numerical integrals) of the most recent error sample and a predetermined number of previous error samples. In some embodiments, the integrated error values are saved as another derived timeseries (e.g., an integrated error timeseries). The PID control DAG may cause execution engines 2330 to apply an integral gain to the integrated error timeseries (e.g., multiplying the integrated error timeseries by an integral gain parameter) to generate an integral gain component of the control signal.

[0585] The PID control DAG may cause execution engines 2330 calculate a derivative error value for each sample of the error timeseries. The derivative error values may be the slope or rate-of-change of the error timeseries relative to the previous sample. In some embodiments, the derivative error values are saved as another derived timeseries (e.g., a derivative error timeseries). The PID control DAG may cause execution engines 2330 to apply a derivative gain to the derivative error timeseries (e.g., multiplying the derivative error timeseries by a derivative gain parameter) to generate a derivative gain component of the control signal. The PID control DAG may cause execution engines 2330 to combine (e.g., sum) the proportional gain component, the integral gain component, and the derivative gain component to generate a value for the next sample of the control signal timeseries.

[0586] In some embodiments, the feedback timeseries for each feedback control DAG are stored as attributes of the feedback control DAG in DAG database 930. DAG identifier 2416 can read such information from DAG database 930 to determine which of the stored feedback control DAGs use the identified feedback timeseries as an input. DAG identifier 2416 can then provide an indication of the identified feedback control DAGs to execution engines 2330 in the form of one or more DAG IDs.

[0587] In some embodiments, DAG identifier 2416 also identifies any other input timeseries that are required as inputs to the identified feedback control DAGs. For example, a feedback control DAG for controlling the temperature of a building space may have two inputs. The first input may be a feedback timeseries that includes temperature measurements collected from a temperature sensor within the building space. The second input may be a setpoint timeseries that defines the temperature setpoint for the building space at each of a plurality of times. DAG identifier 2416 can identify all of the timeseries that are required as inputs to the identified feedback control DAGs and can provide an indication of the identified timeseries to execution engines 2330 in the form of one or more timeseries IDs.

[0588] As described above, execution engines 2330 can include a C# engine 2332, a Python engine 2334, or any other engine configured to perform the operations defined by a DAG. In some embodiments, execution engines 2330 include timeseries operators 906. Execution engines 2330 can receive the incoming feedback samples from campus 2602, as well as the DAG IDs and timeseries IDs from DAG identifier 2416. Execution engines 2330 can retrieve the identified feedback control DAGs from DAG database 930 and can retrieve the identified timeseries from timeseries database 928 and execute the feedback control DAGs, using the feedback samples as an input, to generate control signal samples. Each control signal sample may be the result of a timeseries processing operation that uses the feedback samples (and possibly other timeseries samples) as an input. In some embodiments, each control signal sample includes a key (e.g., a timeseries ID), a timestamp, and a value.

[0589] The timeseries retrieved from timeseries database 928 may include samples of any of the input timeseries required by one or more of the feedback control DAGs, including (in some instances) previous samples of the feedback timeseries. For example, some types of feedback control such as PI control or PID control may require both the current value of a feedback signal (i.e., the most recent feedback sample) and one or more past values of the feedback signal (i.e., one or more previous samples of the same feedback timeseries) in order to generate a control signal sample (e.g., to evaluate an integrated error over time).

Accordingly, execution engines 2330 may retrieve one or more past samples of the feedback timeseries from timeseries database 928. Execution engines 2330 may use the past samples of the feedback timeseries in combination with the current sample of the feedback timeseries and any other input timeseries to execute the feedback control DAG, thereby generating control signal samples.

[0590] Timeseries generator 2418 can use the control signal samples to generate a control signal timeseries. The control signal timeseries can be stored in timeseries database 928 and/or provided as an output of building management platform 102. Timeseries generator 2418 is shown providing a control signal to network 104 and campus 2602. The control signal can include the value of the most recent control signal sample generated by executing the feedback control DAG and/or the control signal timeseries generated by timeseries generator 2418. Campus 2602 can use the control signal to operate building equipment 2608, central plant equipment 2610, and/or IoT devices 2614. For example, the control signal can be provided as an input to building equipment 2608 (e.g., via BMS 2604), central plant equipment 2610 (e.g., via central plant 2606), and/or IoT devices 2614.

[0591] Advantageously, the cloud-based feedback control provided by building

management platform 102 can replace local (e.g., on-site or in-building) control loops typically used by conventional feedback control systems. Instead of requiring a local feedback controller to receive feedback data and generate control signals, the feedback data are provided as an input to building management platform 102. Building management platform 102 identifies and executes feedback control DAGs that provide the functionality of a feedback controller. The output of the feedback control DAGs are control signal samples that can be provided back to campus 2602 and used to control the equipment of campus 2602. Identity Management Using Smart Entities

[0592] Referring now to FIG. 27, a block diagram of an identity management system 2700 is shown, according to an exemplary embodiment. Identity management system 2700 is shown to include an identity management service 2702 and an entity service 2730. In some embodiments, identity management service 2702 and entity service 2730 are types of cloud building management platform 620within cloud building management platform 620. In some embodiments, identity management service 2702 and entity service 2730 include some or all of the features and/or functionality of the data platform described in U.S. Provisional Patent Application No. 62/564,247 filed September 27, 2017, the entire disclosure of which is incorporated by reference herein. Identity management service 2702 can be configured to perform various identity management functions. For example, identity management service 2702 is shown to include an identity correlation module 2704, an identity recognition module 2706, an identity verification module 2708, an identity syndication module 2710, an identity consolidation module 2712, a real-time decision making module 2714, an identity analytics module 2716, and an identity learning module 2718. In various implementations, identity management service 2702 can include fewer, additional, or different modules than illustrated in FIG. 27.

[0593] Entity service 2730 may be the same as or similar to entity service 626 shown in FIG. 6. Entity service 2730 can be configured to generate and manage a plurality of interconnected smart entities and store the smart entities in entity database 2734. The smart entities may include object entities representing a plurality of people or physical devices and data entities representing data associated with the people or physical devices. The smart entities may be interconnected by relational objects indicating relationships between the object entities and the data entities. In some embodiments, each of the object entities includes a plurality of stored identity attributes. In some embodiments, entity service 2730 performs some or all of the smart entity creation and management functions described in detail in U.S. Provisional Patent Application No. 62/611,974 filed December 29, 2017, and U.S. Provisional Patent Application No. 62/611,984 filed December 29, 2017, the entire disclosures of which are incorporated by reference herein.

[0594] Modules 2704-2718 can be configured to receive and consolidate identity attributes to generate an entity representing a person (i.e., person entity 2732). In some embodiments, person entity 2732 is a type of object entity stored in entity database 2734. The identity attributes can be received from various systems or devices including, for example, a mobile device 2720, an information technology (IT) system 2722, internet of things (IoT) sensors 2724, building equipment 2726, and a security system 2728. Identity attributes from mobile device 2720 may include a mobile device ID (e.g., a MAC address, a Wi-Fi address, a device serial number, etc.), biometric attributes collected by mobile device 2720 (e.g., a fingerprint, a voice print, an iris scan, a face scan, etc.), data from mobile device 2720 uniquely identifying a user (e.g., a login identity to which the user has authenticated on the mobile device, such as a logged-in identity from an application or website/web portal), or other attributes uniquely identifying a particular mobile device or user associated with a mobile device. Identity attributes from IT system 2722 may include a person's username, password, access privileges, human resources ID, directory ID, telephone number, office location, role, authorized areas, or other attributes associated with a particular user profile managed by IT system 2722. Identity attributes from sensors such as IoT sensors 2724 may include images/video from cameras, data from biometric sensors, data collected by wearable devices (e.g., skin temperature, heartbeat, movement, etc.) or other attributes that are associated with a user and may be used, alone or in combination with other attributes, to confirm the identity of the user. Identity attributes from building equipment 2726 and security system 2728 may include a card ID, a fingerprint, a face scan, an iris scan, images/video from cameras, or other types of identifying information. In some embodiments, some or all of the attributes are stored in an encrypted form to prevent access of private attributes by unauthorized parties/systems. In some such embodiments, the system does not allow for access of the attributes by external systems, but rather receives queries including data to be compared with the stored attributes and responds to the queries with response messages (e.g., indicating whether or not the data received with the queries matches the stored data, whether access should be granted or denied, etc.).

[0595] Identity management service 2702 can consolidate and write identity attributes to person entity 2732 to create a single entity (e.g., a data object or object entity) that includes all of the identity attributes associated with a particular person. Person entity 2732 can be stored in an entity database 2734 and accessed by identity management service 2702 to perform various identity management functions such as identity recognition, real-time decision making (e.g., access control), identity analytics, and identity learning.

Advantageously, person entity 2732 is a smart entity that contains all of the identity attributes associated with a person regardless of the system or device from which the identity attributes were collected. This allows identity management service 2702 to perform a variety of different identity management functions using only the information contained within person entity 2732. Several examples of the functions performed by identity management service 2702 are described in detail below.

[0596] In some embodiments, identity management service 2702 uses person entity 2732 and the identity attributes contained therein to recognize, verify, and/or authenticate a person's identity. For example, security system 2728 can request authorization from identity management service 2702 in response to a person scanning an access card at a card reader of security system 2728. Security system 2728 can read a card ID from the access card and provide the card ID to identity management service 2702. Identity management service 2702 can use the card ID to identify a particular person entity 2732 that contains a card ID attribute matching the card ID received from security system 2728. Identity management service 2702 can read other attributes of person entity 2732 to identify the person's authorization, access privileges, role, and the like. If the person is authorized to access a particular space associated with the card reader, identity management service 2702 can send an "allow access" signal to security system 2728 to allow the person to access the building space.

Conversely, if the person is not authorized to access the space associated with the card reader, identity management service 2702 can send a "deny access" signal to security system 2728 to deny the person access to the building space.

[0597] In some embodiments, identity management service 2702 uses multiple identity attributes of person entity 2732 to perform multifactor authentication or identity verification. For example, identity management service 2702 can receive a first identity attribute from one of mobile device 2720, IT system 2722, IoT sensors 2724, building equipment 2726, or security system 2728. The first identity attribute can be any of the identity attributes stored in person entity 2732 (e.g., name, role, employee ID, card ID, username, password, etc.).

Identity management service 2702 can use the first identity attribute to identify a particular person entity 2732 that contains the first identity attribute. Identity management service 2702 can then read a second identity attribute from person entity 2732. The second identity attribute can be any of the identity attributes stored in person entity 2732 (other than the first identity attribute).

[0598] Identity management service 2702 can compare the second identity attribute with data obtained from one or more of mobile device 2720, IT system 2722, IoT sensors 2724, building equipment 2726, or security system 2728 to determine whether the second identity attribute is also satisfied. In various embodiments, the second identity attribute can be collected automatically or provided by the person in response a prompt from identity management service 2702. For example, if the first identity attribute is a card ID received from a card reader at a particular location within a building, the second identity attribute may be an image of a person collected by a camera at the same location as the card reader or a mobile device ID broadcast by a mobile device at the same location as the card reader. If the second identity attribute is also satisfied (i.e., the second identity attribute matches an identity attribute in the same person entity 2732 as the first identity attribute), identity management service 2702 may allow access or report a successful identity verification or authorization.

[0599] In some embodiments, identity management service 2702 uses the identity attributes stored in person entity 2732 to automatically grant a person access to a system, device, or space within a building without requiring the person to actively scan an ID card or enter a username or password. For example, identity management service 2702 can track the locations of people within a building using location data reported by mobile devices 2720 carried by the people, IoT sensor data provided by IoT sensors 2724, and/or camera data from security system 2728. Several examples of systems and methods for determining the locations of people within a building are described in detail in U.S. Patent Application No. 14/263,639 filed April 28, 2014, the entire disclosure of which is incorporated by reference herein.

[0600] Identity management service 2702 can use the identity attributes stored in person entity 2732 to determine the authorization of each person. For example, person entity 2732 may identify one or more building spaces (e.g., floors, rooms, zones, etc.), systems (e.g., HVAC systems, security systems, lighting systems, etc.), or devices (e.g., HVAC devices, lighting devices, card readers, etc.) that the person is authorized to access. In some embodiments, person entity 2732 identifies the person's role (e.g., service technician, office administrator, nurse, etc.) and identity management service 2702 automatically determines the person's authorization based on the identified role.

[0601] Identity management service 2702 can use the location information for a person in the building to determine whether the person is approaching an access point (e.g., a door, entrance, exit, etc.). If the identity attributes in the corresponding person entity 2732 for that person indicate that the person is authorized to pass through the access point, identity management service 2702 can automatically open or unlock the access point to allow the person access without requiring the person to scan an ID card or enter a key code at the access point. In some embodiments, identity management service 2702 automatically opens or unlocks the access point before the person reaches the access point (e.g., while the user is approaching the access point) to prevent any delay upon reaching the access point.

[0602] Similarly, identity management service 2702 can use the location information for a person in the building to determine whether the person is located at a computer workstation, IT system, a particular device of building equipment, or other IT access point. If the identity attributes in the corresponding person entity 2732 for that person indicate that the person is authorized to access a system or device via the IT access point, identity management service 2702 can automatically login the person or provide access to the building equipment to allow access without requiring the person to enter a username, password, or other login credential. In some embodiments, identity management service 2702 automatically logs the person into the IT access point before the person reaches the IT access point (e.g., while the user is approaching the IT access point) to prevent any delay upon reaching the IT access point.

[0603] In some embodiments, identity management service 2702 uses multifactor authentication to verify the person's identity before allowing access. For example, identity management service 2702 can collect two or more identity attributes from mobile device 2720, IT system 2722, IoT sensors 2724, building equipment 2726, or security system 2728 at the location of a person. If all of the identity attributes match the same person entity 2732, identity management service 2702 can confirm that the person's identity has been verified using multiple identity attributes. Identity management service 2702 can then automatically open or unlock a physical access point or provide access to an IT access point upon successful multifactor authentication or verification. In some embodiments, identity management service 2702 may utilize attributes from two separate systems to increase security (e.g., one data item from mobile device 2720 and another item from building equipment 2726 or security system 2728). This may help prevent against unauthorized access in the event the security of one of the devices is compromised.

Assurance Service

[0604] Referring now to FIG. 28, a block diagram of an assurance service 2800 is shown, according to an exemplary embodiment. In some embodiments, assurance service 2800 is cloud building management platform 620a service within cloud building management platform 620. In some embodiments, assurance service 2800 includes some or all of the features and/or functionality of the data platform described in U.S. Patent Application No. 62/564,247 filed September 27, 2017, the entire disclosure of which is incorporated by reference herein. Assurance service 2800 can be configured to perform device health monitoring and on-demand, offline, and online asset management through IoT technologies. Assurance service 2800 is shown to include an identity and security service 2802, a device management service 2804, a transportation and messaging service 2806, a device

shadow/manifest service 2808, a package service 2810, an asset and backup service 2812, a manual upload service 2814, assurance widgets 2816, and an assurance agent 2818.

[0605] Identity and security service 2802 can be configured to ensure that each device of building equipment 2726 and user has the ability to access configuration backups. For example, identity and security service 2802 can monitor identity and authorization attributes associated with each user and with each device of building equipment 2726 and can determine whether the set of identity and authorization attributes are sufficient to access configuration backups. Identity and security service 2802 can also ensure that each user has the ability to command building equipment 2726. In some embodiments, identity and security service 2802 includes some or all of the features or functionality of identity management service 2702, as described with reference to FIG. 27.

[0606] Device management service 2804 can perform secure device registration. For example, device management service 2804 can communicate with building equipment 2726 installed at a customer site to register each device of building equipment 2726 with cloud building management platform 620. In some embodiments, the device registration performed by device management service 2804 is the same as or similar to the device registration described in U.S. Patent Application No. 15/639,880 filed June 30, 2017, the entire disclosure of which is incorporated by reference herein. For example, device management service 2804 can be configured to create a virtual representation of each device of building equipment 2726 within cloud building management platform 620. In some embodiments, the virtual device representations are smart entities that include attributes characterizing the

corresponding physical devices of building equipment 2726. Device management service 2804 can associate each device of building equipment 2726 with a particular customer, department, and/or user. Device management service 2804 can send and request firmware updates on-demand when building equipment 2726 are connected.

[0607] Transportation and messaging service 2806 can be configured to facilitate bidirectional communications between assurance service and building equipment 2726 installed at a customer site. In some embodiments, transportation and messaging service 2806 provides real-time alarm and event messaging. For example, transportation and messaging service 2806 can provide alarms or events from building equipment 2726 to cloud building management platform 620 in real time. Transportation and messaging service 2806 can also provide real-time command and control functionality for building equipment 2726. For example, transportation and messaging service 2806 can provide commands and control signals from applications 630 or cloud building management platform 620 to building equipment 2726 in real-time. In some embodiments, transportation and messaging service 2806 is configured to discover building equipment 2726 and request firmware upgrades for building equipment 2726.

[0608] Device shadow/manifest service 2808 can be configured to synchronize

configuration settings, parameters, and other device-specific information between building equipment 2726 and cloud building management platform 620. In some embodiments, the synchronization occurs asynchronously. Device shadow/manifest service 2808 can be configured to manage device properties dynamically. The device properties, configuration settings, parameters, and other device-specific information can be synchronized between building equipment 2726 and the smart entities created by and stored within cloud building management platform 620. In some embodiments, device shadow/manifest service 2808 is configured to monitor the health of building equipment 2726 and perform on-demand, online, or offline asset management through IoT technologies.

[0609] In some embodiments, device shadow/manifest service 2808 is configured to manage a manifest for each device of building equipment 2726. The manifest may include a set of relationships between building equipment 2726 and various entities and/or the various entities and other entities. Further, the manifest may indicate a set of entitlements for the device of building equipment 2726 and/or entitlements of the various entities and/or other entities. The set of entitlements may allow a device of building equipment 2726 and/or a user of the device to perform certain actions with building equipment 2726 such as adjusting a temperature setpoint, turning a connected system on and/or off, running certain pieces of software, requesting software updates, etc. In some embodiments, the entity is at least one of a group (e.g., a technician group, a home residents group, a guest group, a building manager group, etc.), a user (e.g., Technician Bill, Dad, User A, User B, etc.), and a device (Mobile Device 1, Smartphone A, Computer 4, Actuator 9, etc.).

[0610] Package service 2810 can be configured to identify software releases published by a developer or vendor of building equipment 2726. For example, package service 2810 can monitor a remote system or server for new versions of software for building equipment 2726. When a new software version is available, package service 2810 may generate an alert or notification. In some embodiments, package service 2810 compares the installed version of software on building equipment 2726 with the version of software available at the remote system or server to determine whether the software version is new relative to the installed version. In some embodiments, package service 2810 can push the configurations of building equipment 2726 as a compressed data object that will be stored reliably and securely at cloud building management platform 620.

[0611] In some embodiments, package service 2810 is configured to install, backup, and restore device configurations, device parameters, device software, or other adjustable parameters of building equipment 2726. For example, package service 2810 can perform on- demand, offline, and online backups of device configurations and released software packages. Package service 2810 can perform remote provisioning of building equipment 2726 and can perform version control for backup configurations and software. Package service 2810 can handle ownership and replacement of each device of building equipment 2726 with new devices.

[0612] Asset and backup service 2812 can be configured to connect to applications 630 to facilitate communication between assurance service 2800 and applications 630. For example, asset and backup service 2812 can interface with monitoring and reporting application 634 to generate and present a user interface that lists all of the assets (i.e., devices of building equipment 2726) installed at a customer site or facility. In some embodiments, the user interface identifies each asset and indicates whether the configuration of the asset has been backed up at cloud building management platform 620.

[0613] Manual upload service 2814 can be configured to perform a manual backup of device configuration parameters, software, firmware, and other adjustable settings for building equipment 2726. The manual backup may be the same as or similar to the automatic backups performed by other components of assurance service 2800. However, the manual backups can be triggered on-demand by a service technician or other user. In some embodiments, manual upload service 2814 is configured to manually register a device of building equipment 2726 with cloud building management platform 620 and can upload various types of data associated with the registered device. For example, manual upload service 2814 can upload a heartbeat timeseries that indicates whether the device is online and communicating, logs collected by the device, and/or configuration settings for the device.

[0614] Assurance widgets 2816 can be configured to generate various user interface elements (i.e., widgets) that include information associated with devices of building equipment 2726 and/or assurance service 2800. The widgets may function as extensions or components of user interfaces generated by applications 630. For example, the widgets can include a list view of connected assets including asset details and an indication of whether a backup for each asset exists on cloud building management platform 620. Assurance widgets 2816 can remotely operate building equipment 2726. For example, assurance widgets 2816 can send a remote update request to building equipment 2726 and can send registered commands to building equipment 2726 securely. Assurance widgets 2816 can also display real-time alarm and event data from building equipment 2726.

[0615] Assurance agent 2818 can be configured to interface with services 2802-2814, assurance widgets 2816, and building equipment 2726. In some embodiments, assurance agent 2818 is configured to register building equipment 2726, backup software and configuration settings, and communicate status information to services 2802-2814 and assurance widgets 2816. Assurance agent 2818 can send a request to building equipment 2726 to perform a device discovery process to identify all of the devices of building equipment 2726 located at the customer site. An example of a device discovery process which can be triggered by assurance agent 2818 is described in detail in U.S. Patent

Application No. 15/179,894 filed June 10, 2016, the entire disclosure of which is

incorporated by reference herein. Assurance agent 2818 can also update the software of building equipment 2726 and restore the configuration settings of building equipment 2726. Assurance agent 2818 can send device heartbeat timeseries, send logs, send configuration settings, send alerts, and relay commands to and from building equipment 2726. [0616] In some embodiments, assurance agent 2818 uses the data stored in entity database 2734 to perform its various functions. As described above, entity database 2732 may store a plurality of interconnected smart entities. The smart entities may include object entities representing the plurality of devices of building equipment and data entities representing data associated with the plurality of devices of building equipment. The smart entities may be interconnected by relational objects indicating relationships between the object entities and the data entities. Each object entity may include a stored attribute indicating a version of software installed on a device of the building equipment represented by the object entity.

[0617] Assurance agent 2818 can be configured to automatically detect a version of software installed on each of the devices of building equipment by reading the stored attributes of the object entities in entity database 2734. Assurance agent 2818 can automatically update the software installed on one or more of the devices of building equipment in response to a determination that the version of software installed on the one or more of the devices of building equipment is not a latest version of the software.

Configuration of Exemplary Embodiments

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

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

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

[0621] The term "client or "server" include all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing. The apparatus may include special purpose logic circuitry, e.g., a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC). The apparatus may also include, in addition to hardware, code that creates an execution environment for the computer program in question (e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of them). The apparatus and execution environment may realize various different computing model infrastructures, such as web services, distributed computing and grid computing infrastructures. [0622] The systems and methods of the present disclosure may be completed by any computer program. A computer program (also known as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program may be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0623] The processes and logic flows described in this specification may be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows may also be performed by, and apparatus may also be implemented as, special purpose logic circuitry (e.g., an FPGA or an ASIC).

[0624] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data (e.g., magnetic, magneto-optical disks, or optical disks). However, a computer need not have such devices. Moreover, a computer may be embedded in another device (e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), etc.). Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD ROM and DVD-ROM disks). The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0625] In various implementations, the steps and operations described herein may be performed on one processor or in a combination of two or more processors. For example, in some implementations, the various operations could be performed in a central server or set of central servers configured to receive data from one or more devices (e.g., edge computing devices/controllers) and perform the operations. In some implementations, the operations may be performed by one or more local controllers or computing devices (e.g., edge devices), such as controllers dedicated to and/or located within a particular building or portion of a building. In some implementations, the operations may be performed by a combination of one or more central or offsite computing devices/servers and one or more local

controllers/computing devices. All such implementations are contemplated within the scope of the present disclosure. Further, unless otherwise indicated, when the present disclosure refers to one or more computer-readable storage media and/or one or more controllers, such computer-readable storage media and/or one or more controllers may be implemented as one or more central servers, one or more local controllers or computing devices (e.g., edge devices), any combination thereof, or any other combination of storage media and/or controllers regardless of the location of such devices.

[0626] To provide for interaction with a user, implementations of the subject matter described in this specification may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube), LCD (liquid crystal display), OLED (organic light emitting diode), TFT (thin-film transistor), or other flexible configuration, or any other monitor for displaying information to the user and a keyboard, a pointing device, e.g., a mouse, trackball, etc., or a touch screen, touch pad, etc.) by which the user may provide input to the computer. Other kinds of devices may be used to provide for interaction with a user as well; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback), and input from the user may be received in any form, including acoustic, speech, or tactile input. In addition, a computer may interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user's client device in response to requests received from the web browser.

[0627] Implementations of the subject matter described in this disclosure may be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a client computer) having a graphical user interface or a web browser through which a user may interact with an implementation of the subject matter described in this disclosure, or any combination of one or more such back end, middleware, or front end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a LAN and a WAN, an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0628] The present disclosure may be embodied in various different forms, and should not be construed as being limited to only the illustrated embodiments herein. Rather, these embodiments are provided as examples so that this disclosure will be thorough and complete, and will fully convey the aspects and features of the present disclosure to those skilled in the art. Accordingly, processes, elements, and techniques that are not necessary to those having ordinary skill in the art for a complete understanding of the aspects and features of the present disclosure may not be described. Unless otherwise noted, like reference numerals denote like elements throughout the attached drawings and the written description, and thus, descriptions thereof may not be repeated. Further, features or aspects within each example embodiment should typically be considered as available for other similar features or aspects in other example embodiments.

[0629] It will be understood that, although the terms "first," "second," "third," etc., may be used herein to describe various elements, components, regions, layers and/or sections, these elements, components, regions, layers and/or sections should not be limited by these terms. These terms are used to distinguish one element, component, region, layer or section from another element, component, region, layer or section. Thus, a first element, component, region, layer or section described below could be termed a second element, component, region, layer or section, without departing from the spirit and scope of the present disclosure. [0630] The terminology used herein is for the purpose of describing particular embodiments and is not intended to be limiting of the present disclosure. As used herein, the singular forms "a" and "an" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises," "comprising," "includes," and "including," "has, " "have, " and "having," when used in this specification, specify the presence of the stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items. Expressions such as "at least one of," when preceding a list of elements, modify the entire list of elements and do not modify the individual elements of the list.

[0631] As used herein, the term "substantially," "about," and similar terms are used as terms of approximation and not as terms of degree, and are intended to account for the inherent variations in measured or calculated values that would be recognized by those of ordinary skill in the art. Further, the use of "may" when describing embodiments of the present disclosure refers to "one or more embodiments of the present disclosure." As used herein, the terms "use," "using," and "used" may be considered synonymous with the terms "utilize," "utilizing," and "utilized," respectively. Also, the term "exemplary" is intended to refer to an example or illustration.

[0632] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.