Patent Publication Number: US-2023152765-A1

Title: Building data platform with schema extensibility for states of a digital twin

Description:
BACKGROUND 
     The present application relates generally to a building system with a digital twin. More specifically, the present application relates to the schema of the digital twin. 
     The building system can operate against a digital twin, for example, the digital twin may inform the building system of information pertaining to the building that the building system operates against. However, the schema that the digital twin is deployed in may be static, i.e., does not change. This may cause problems if the schema does not allow for a particular expression of information that would be useful for systems of the building to operate against. A significant amount of time may be wasted redeveloping schemas and redeploying systems in order to express information in the digital twin that is needed by other systems. 
     SUMMARY 
     Dynamic Property or Tag 
     A building system including one or more memory devices including instructions thereon that, when executed by one or more processors, cause the one or more processors to perform one or more first operations based on a digital twin of a building, the digital twin including representations of entities of the building and relationships between the entities. The instructions cause the one or more processors to update a schema of the digital twin by adding a property or tag to an entity class of the schema, add, based on the schema, one or more data elements representing the property or tag to the digital twin, the one or more data elements related to an entity of the entity class, the plurality of entities including the entity, and perform one or more second operations based on the one or more data elements representing the property or tag. 
     In some embodiments, the entities include at least one of a person, point, location, or event, wherein the schema defines entity classes for entity types of the entities. 
     In some embodiments, the entities are instances of entity classes defined by the schema. 
     In some embodiments, the property or the tag defines a characteristic of the entity. 
     In some embodiments, the instructions cause the one or more processors to update the schema of the digital twin while the digital twin is deployed without requiring the digital twin to be redeployed. 
     In some embodiments, the schema defines entity classes, the entity classes indicating properties, tags, and states for the entity classes. 
     In some embodiments, the instructions cause the one or more processors to identify entity nodes indicating entities in the entity class and add, based on the schema, the one or more nodes representing the property or tag to the digital twin for each of the entity nodes, the one or more nodes related to the entity nodes. 
     In some embodiments, the digital twin include nodes and edges between the nodes, the plurality of nodes representing the entities of the building and the edges indicating the relationships between the entities. In some embodiments, instructions cause the one or more processors to add, based on the schema, one or more nodes representing the property or tag to the digital twin, the one or more nodes related to a node representing the entity of the entity class by one or more edges. 
     In some embodiments, the instructions cause the one or more processors to receive an indication to add the property or tag to a first entity, identify the entity class of the first entity based on the schema, update the schema of the digital twin by adding the property or tag to the entity class of the schema responsive to identifying that a class of the first entity is the entity class, and add, based on the schema, the one or more nodes representing the property or tag to the digital twin, the one or more nodes related to the node representing the entity of the entity class, wherein the entity is a second entity different from the first entity. 
     In some embodiments, the instructions cause the one or more processors to receive user input from a user device, the user input defining the property or the tag to be added to the entity class of the schema and update, based on the user input, the schema of the digital twin by adding the property or tag to the entity class of the schema in responsive to receiving the user input. 
     In some embodiments, the instructions cause the one or more processors to identify an update to one or more particular nodes or one or more particular edges of the digital twin, the update indicating changes affecting the entity, determine that the update indicates a change to one or more characteristics of the entity, and update the schema of the digital twin by adding the property or tag to the entity class of the schema responsive to determining that the update indicates the change to the one or more characteristics of the entity. 
     Another implementation of the present disclosure is a method including performing, by one or more processing circuits, one or more first operations based on a digital twin of a building, the digital twin including representations of entities of the building and relationships between the entities. The method includes updating, by the one or more processing circuits, a schema of the digital twin by adding a property or tag to an entity class of the schema, adding, by the one or more processing circuits, based on the schema, one or more data elements representing the property or tag to the digital twin, the one or more data elements related to an entity of the entity class, the entities including the entity, and performing, by the one or more processing circuits, one or more second operations based on the one or more data elements representing the property or tag. 
     In some embodiments, the entities include at least one of a person, point, location, or event, wherein the schema defines entity classes for entity types of the entities. 
     In some embodiments, the property or the tag defines a characteristic of the entity. 
     In some embodiments, updating, by the one or more processing circuits, the schema of the digital twin while the digital twin is deployed without requiring the digital twin to be redeployed. 
     In some embodiments, the schema defines entity classes, the entity classes indicating properties, tags, and states for the entity classes. 
     In some embodiments, the digital twin includes a plurality of nodes and a plurality of edges between the plurality of nodes, the plurality of nodes representing the plurality of entities of the building and the plurality of edges indicating the relationships between the plurality of entities. In some embodiments, the method further includes adding, by the one or more processing circuits, based on the schema, one or more nodes representing the property or tag to the digital twin, the one or more nodes related to a node representing the entity of the entity class by one or more edges. 
     In some embodiments, the method includes identifying, by the one or more processing circuits, entity nodes indicating entities in the entity class and adding, by the one or more processing circuits, based on the schema, the one or more nodes representing the property or tag to the digital twin for each of the entity nodes, the one or more nodes related to the entity nodes. 
     In some embodiments, the method includes receiving, by the one or more processing circuits, an indication to add the property or tag to a first entity, identifying, by the one or more processing circuits, the entity class of the first entity based on the schema, updating, by the one or more processing circuits, the schema of the digital twin by adding the property or tag to the entity class of the schema responsive to identifying that a class of the first entity is the entity class, and adding, by the one or more processing circuits, based on the schema, the one or more nodes representing the property or tag to the digital twin, the one or more nodes related to the node representing the entity of the entity class, wherein the entity is a second entity different from the first entity. 
     In some embodiments, the method includes receiving, by the one or more processing circuits, user input from a user device, the user input defining the property or the tag to be added to the entity class of the schema and updating, by the one or more processing circuits, based on the user input, the schema of the digital twin by adding the property or tag to the entity class of the schema in responsive to receiving the user input. 
     In some embodiments, the method includes identifying, by the one or more processing circuits, an update to one or more particular nodes or one or more particular edges of the digital twin, the update indicating changes affecting the entity, determining, by the one or more processing circuits, that the update indicates a change to one or more characteristics of the entity and updating, by the one or more processing circuits, the schema of the digital twin by adding the property or tag to the entity class of the schema responsive to determining that the update indicates the change to the one or more characteristics of the entity. 
     Another implementation of the present disclosure is a building system including one or more memory devices including instructions thereon and one or more processors configured to execute the instructions causing the one or more processors to perform one or more first operations based on a digital twin of a building, the digital twin including representations of entities of the building and the edges indicating relationships between the entities. The instructions cause the one or more processors to update a schema of the digital twin by adding a property or tag to an entity class of the schema, add, based on the schema, one or more data elements representing the property or tag to the digital twin, the one or more data elements related to an entity of the entity class, the entities including the entity, and perform one or more second operations based on the one or more data elements representing the property or tag. 
     Dynamic State 
     One implementation of the present disclosure is a building system including one or more memory devices including instructions thereon that, when executed by one or more processors, cause the one or more processors to perform one or more first operations based on a digital twin of a building to derive a state for an entity of the digital twin, the digital twin including representations of entities of the building and relationships between the entities. The instructions cause the one or more processors to update a schema of the digital twin by adding a state type of the state to an entity class of the schema, add, based on the schema, one or more data elements representing the state to the digital twin, the one or more data elements related to the entity of the entity class, and perform one or more second operations based on the one or more data elements representing the state. 
     In some embodiments, the entities include at least one of a person, point, location, or event, wherein the schema defines entity classes for entity types of the entities. 
     In some embodiments, the entities are instances of entity classes defined by the schema. 
     In some embodiments, the instructions cause the one or more processors to update the schema of the digital twin while the digital twin is deployed without requiring the digital twin to be redeployed. 
     In some embodiments, the schema defines entity classes, the entity classes indicating properties, tags, and states for the entity classes. 
     In some embodiments, the instructions cause the one or more processors to perform the one or more first operations based on the digital twin of the building and external data collected from an external system, wherein the state is derived from the external data for the entity of the digital twin. 
     In some embodiments, the instructions cause the one or more processors to receive an indication to add the state to the entity, identify the entity class of the entity based on the schema, update the schema of the digital twin by adding the state type to the entity class of the schema responsive to identifying that a class of the entity is the entity class, and add based on the schema, the one or more nodes representing the state to the digital twin, the one or more nodes related to a second node representing a second entity of the entity class, wherein the entity is different from the second entity. 
     In some embodiments, an application begins operating to perform the one or more first operations based on the digital twin of the building to derive the state for the entity after the digital twin is deployed and before the schema of the digital twin is updated. 
     In some embodiments, the instructions are configured to receive an output from the application resulting from the one or more first operations, the output indicating the state, search the schema of the digital twin to determine whether the schema includes the state type indicated by the output of the one or more first operations, and update the schema of the digital twin by adding the state type of the state to the entity class of the schema responsive to identifying that the schema does not include the state type. 
     In some embodiments, the state defines a condition associated with the entity. 
     In some embodiments, the state is at least one of a fault state of a piece of equipment of the building or an occupancy level of a space of the building. 
     In some embodiments, the digital twin includes nodes and edges between the nodes, the nodes representing the entities of the building and the edges indicating the relationships between the entities. In some embodiments, the instructions cause the one or more processors to add, based on the schema, one or more nodes representing the state to the digital twin, the one or more nodes related to the entity of the entity class by one or more relationships. 
     Another implementation of the present disclosure is a method including performing, by one or more processing circuits, one or more first operations based on a digital twin of a building to derive a state for an entity of the digital twin, the digital twin including representations of entities of the building and relationships between the entities and updating, by one or more processing circuits, a schema of the digital twin by adding a state type of the state to an entity class of the schema. The method includes adding, by one or more processing circuits, based on the schema, one or more data elements representing the state to the digital twin, the one or more data elements related to a node representing the entity of the entity class and performing, by one or more processing circuits, one or more second operations based on the one or more data elements representing the state. 
     In some embodiments, the entities include at least one of a person, point, location, or event, wherein the schema defines entity classes for entity types of the entities. In some embodiments, the entities are instances of entity classes defined by the schema. 
     In some embodiments, the method includes updating, by one or more processing circuits, the schema of the digital twin while the digital twin is deployed without requiring the digital twin to be redeployed. 
     In some embodiments, the schema defines entity classes, the entity classes indicating properties, tags, and states for the entity classes. 
     In some embodiments, the method includes performing, by one or more processing circuits, the one or more first operations based on the digital twin of the building and external data collected from an external system, wherein the state is derived from the external data for the entity of the digital twin. 
     In some embodiments, the digital twin includes nodes and edges between the nodes, the nodes representing the entities of the building and the edges indicating the relationships between the entities. In some embodiments, the method includes adding, by the one or more processing circuits, based on the schema, one or more nodes representing the state to the digital twin, the one or more nodes related to the entity of the entity class by one or more relationships. 
     In some embodiments, the method includes receiving, by one or more processing circuits, an indication to add the state to the entity, identifying, by one or more processing circuits, the entity class of the entity based on the schema, updating, by one or more processing circuits, the schema of the digital twin by adding the state type to the entity class of the schema responsive to identifying that a class of the entity is the entity class, and adding, by one or more processing circuits, based on the schema, the one or more nodes representing the state to the digital twin, the one or more nodes related to a second node representing a second entity of the entity class, wherein the entity is different from the second entity. 
     In some embodiments, an application begins operating to perform the one or more first operations based on the digital twin of the building to derive the state for the entity after the digital twin is deployed and before the schema of the digital twin is updated. 
     In some embodiments, the method includes receiving, by one or more processing circuits, an output from the application resulting from the one or more first operations, the output indicating the state, searching, by one or more processing circuits, the schema of the digital twin to determine whether the schema includes the state type indicated by the output of the one or more first operations, and updating, by one or more processing circuits, the schema of the digital twin by adding the state type of the state to the entity class of the schema responsive to identifying that the schema does not include the state type. 
     Another implementation of the present disclosure is a building system including one or more memory devices including instructions thereon and one or more processors configured to execute the instructions causing the one or more processors to perform one or more first operations based on a digital twin of a building to derive a state for an entity of the digital twin, the digital twin including representations of entities of the building and relationships between the entities. The instructions cause the one or more processors to update a schema of the digital twin by adding a state type of the state to an entity class of the schema, add, based on the schema, one or more data elements representing the state to the digital twin, the one or more data elements related to the entity of the entity class, and perform one or more second operations based on the one or more data elements representing the state. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Various objects, aspects, features, and advantages of the disclosure will become more apparent and better understood by referring to the detailed description taken in conjunction with the accompanying drawings, in which like reference characters identify corresponding elements throughout. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. 
         FIG.  1    is a block diagram of a building data platform including an edge platform, a cloud platform, and a twin manager, according to an exemplary embodiment. 
         FIG.  2    is a graph projection of the twin manager of  FIG.  1    including application programming interface (API) data, capability data, policy data, and services, according to an exemplary embodiment. 
         FIG.  3    is another graph projection of the twin manager of  FIG.  1    including application programming interface (API) data, capability data, policy data, and services, according to an exemplary embodiment. 
         FIG.  4    is a graph projection of the twin manager of  FIG.  1    including equipment and capability data for the equipment, according to an exemplary embodiment. 
         FIG.  5    is a block diagram of an extensibility manager that extends a schema definition of a digital twin at runtime, according to an exemplary embodiment. 
         FIG.  6    is a block diagram of the twin manager of  FIG.  1    where an extensible property manager updates a digital twin to include new properties in the schema of the digital twin, according to an exemplary embodiment. 
         FIG.  7    is a flow diagram of a process where the extensible property manager of  FIG.  6    updates a digital twin to include new properties in the schema of the digital twin, according to an exemplary embodiment. 
         FIG.  8    is a block diagram of an extensible state manager updating the digital twin based on information received from a fault analysis agent, the update causing the digital twin to include new states indicating faults in the schema of the digital twin, according to an exemplary embodiment. 
         FIG.  9    is a block diagram of the extensible state manager updating the digital twin based on information received from a calendar agent, the update causing the digital twin to include new states indicating occupancy in the schema of the digital twin, according to an exemplary embodiment. 
         FIG.  10    is a flow diagram of a process of updating the digital twin based on information received from an agent, the update causing the digital twin to include new states indicating occupancy in the schema of the digital twin, according to an exemplary embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     Referring generally to the FIGURES, systems and methods for dynamic extensibility of properties, tags, and states in a schema of a digital twin is shown, according to various exemplary embodiments. A digital twin may provide a virtual representation of a building, e.g., both in terms of contextual information describing the building and telemetry data collected from equipment of the building. The digital twin may act as a replica illustrating the entities of the building (e.g., assets, people, points, locations, and events) and relationships between the various entities. The digital twin can, in some embodiments, be implemented in terms of a graph data structure. 
     In some embodiments, the entities and relationships between the entities can be defined in terms of a schema. The schema can define the entities, properties of the entities, tags of the entities, states of the entities, etc. in terms of a class structure where each entity includes specific corresponding properties, tags, or states. For example, any thermostat entity could include a temperature setpoint state, a current temperature state, a tag indicating when the equipment was last serviced, a property indicating that the thermostat includes a display device, properties indicating that the thermostat the types of inputs or outputs of the thermostat, etc. The schema could be a strongly typed schema such as BRICK, in some embodiments. BRICK is described in Brick: Towards a Unified Metadata Schema For Buildings by Balaji et al., which is incorporated by reference herein. 
     In some embodiments, a building system can extend the schema of the digital twin to accommodate for different properties, tags, and/or states. This extension can be performed at runtime such that the digital twin and/or the system running the digital twin can have changes made to the schema without requiring the digital twin and/or system running the digital twin to be redeployed and/or reconfigured (which would cause downtime). The digital twin schema can be extended dynamically by the building system, in some embodiments. For example, the building system can (during runtime) make determinations that new states, properties, or tags are needed that would increase the performance of the digital twin (e.g., allow for the digital twin to relate new important pieces of information to consuming systems). The building system can make these runtime updates to the schema of the digital twin. 
     In some embodiments, the updated schema of the digital twin, e.g., the new properties, tags, and/or states of the entities can be used by a system, application, and/or agent that operates against data of the digital twin. For example, such a system, application, and/or agent could search and filter the digital twin based on the new properties, tags, and/or states of the digital twin. The system, application, and/or agent could implement building temperature control, humidity control, air quality control, false alarm analysis, fault analysis, etc. based on the updated digital twin. 
     In some embodiments, a BIM viewer which may render BIM related information in a user interface based on the graph could operate based on the updated schema of the digital twin. BIM viewers are described with reference to U.S. Provisional Pat. Application No. 63/214,217 filed June 23 rd , 2021, U.S. Pat. Application No. 17/136,752 filed December 29 th , 2020, U.S. Pat. Application No. 17/136,768 filed December 29 th , 2020, and U.S. Pat. Application No. 17/136,785 filed December 29 th , 2020, the entirety of each of which is incorporated by reference herein. The BIM viewer may not operate in the exact schema of the digital twin. Therefore, updates can be made to the schema to account for various pieces of information needed for the BIM viewer to operate properly. The BIM viewer could then query a graph of the digital twin in the updated schema based on tags, properties, states, and/or any other value added to the schema that may not exist in the original schema. The updated schema can allow for values or other information to be queried from the digital twin at runtime without the need to update applications, models, rebuilding and/or redeploying systems, data migration, etc. 
     In some embodiments, the building system can update the schema of the digital twin to allow new event types to be ingested and stored by the digital twin. For example, the building system can, in some embodiments, receive new events and determine whether the event types of the new events are not present in the schema of the digital twin. The building system can add the new event type to the schema of the digital twin responsive to detecting that the event type does not exist allowing events of the new event type to be added to the digital twin. Allowing the digital twin to extend its schema to account for new event types to any entity in the digital twin is the driving feature which allows plug and play functionality and lowers the barrier to consuming and extending the functionality of the digital twin. 
     Examples of digital twins and adding schema information to a schema based on received data information is shown and described in U.S. Pat. Application No. 17/134,661 filed December 28 th , 2020, U.S. Pat. Application No. 17/134,664 filed December 28 th , 2020, U.S. Pat. Application No. 17/134,671 filed December 28 th , 2020, U.S. Pat. Application No. 17/134,659 filed December 28 th , 2020, U.S. Pat. Application No. 17/134,973 filed December 28 th , 2020, U.S. Pat. Application No. 17/134,999 filed December 28 th , 2020, U.S. Pat. Application No. 17/135,023 filed December 28 th , 2020, U.S. Pat. Application No. 17/134,691 filed December 28 th , 2020, U.S. Pat. Application No. 17/135,056 filed December 28 th , 2020, and U.S. Pat. Application No. 17/135,009 filed December 28 th , 2020, the entirety of each of these patent applications is incorporated by reference herein. 
     In some embodiments, adding a dynamic property or state to the schema may not necessarily cause the property or state to be propagated to other entities, e.g., it may not cause the creation of new properties or states for every entity of a schema class. For example, if an expected occupancy state is added for a “Conference Room ABC” entity, in some cases, a conference room schema class for the “Conference Room ABC” can be updated with the expected occupancy state (or a new schema for the “Conference Room ABC” could be created to handle the new state). The building system may not add the expected occupancy state to other conference room entities of the conference room schema class that exist (but may add the occupancy state to future entities of the conference room schema class as when the entities are created). 
     In some embodiments, the propagation of newly added properties and/or states across entities of a schema type can be controlled by a user. For example, a user could set a setting for the building system that the addition of a new property or state to a particular entity of a particular schema class causes the creation of a new schema class with the new property or state for the particular entity. This would stop the propagation of a new property to other entities. In some embodiments, a user could set a setting that the addition of a new property or state to a particular entity of a particular schema class cause the addition of the new property or state to all entities of the particular entity class. This would cause the propagation of the new property to other entities. 
     Referring now to  FIG.  1   , a building data platform  100  including an edge platform  102 , a cloud platform  106 , and a twin manager  108  are shown, according to an exemplary embodiment. The edge platform  102 , the cloud platform  106 , and the twin manager  108  can each be separate services deployed on the same or different computing systems. In some embodiments, the cloud platform  106  and the twin manager  108  are implemented in off premises computing systems, e.g., outside a building. The edge platform  102  can be implemented on-premises, e.g., within the building. However, any combination of on-premises and off-premises components of the building data platform  100  can be implemented. 
     The building data platform  100  includes applications  110 . The applications  110  can be various applications that operate to manage the building subsystems  122 . The applications  110   can be remote or on-premises applications (or a hybrid of both) that run on various computing systems. The applications  110  can include an alarm application  168  configured to manage alarms for the building subsystems  122 . The applications  110  include an assurance application  170  that implements assurance services for the building subsystems  122 . In some embodiments, the applications  110  include an energy application  172  configured to manage the energy usage of the building subsystems  122 . The applications  110  include a security application  174  configured to manage security systems of the building. 
     In some embodiments, the applications  110  and/or the cloud platform  106  interacts with a user device  176 . In some embodiments, a component or an entire application of the applications  110  runs on the user device  176 . The user device  176  may be a laptop computer, a desktop computer, a smartphone, a tablet, and/or any other device with an input interface (e.g., touch screen, mouse, keyboard, etc.) and an output interface (e.g., a speaker, a display, etc.). 
     The applications  110 , the twin manager  108 , the cloud platform  106 , and the edge platform  102  can be implemented on one or more computing systems, e.g., on processors and/or memory devices. For example, the edge platform  102  includes processor(s)  118  and memories  120 , the cloud platform  106  includes processor(s)  124  and memories  126 , the applications  110  include processor(s)  164  and memories  166 , and the twin manager  108  includes processor(s)  148  and memories  150 . 
     The processors can be a general purpose or specific purpose processors, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable processing components. The processors may be configured to execute computer code and/or instructions stored in the memories or received from other computer readable media (e.g., CDROM, network storage, a remote server, etc.). 
     The memories 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. The memories 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. The memories 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. The memories can be communicably connected to the processors and can include computer code for executing (e.g., by the processors) one or more processes described herein. 
     The edge platform  102  can be configured to provide connection to the building subsystems  122 . The edge platform  102  can receive messages from the building subsystems  122  and/or deliver messages to the building subsystems  122 . The edge platform  102  includes one or multiple gateways, e.g., the gateways  112 – 116 . The gateways  112 – 116  can act as a gateway between the cloud platform  106  and the building subsystems  122 . The gateways  112 – 116  can be the gateways described in U.S. Provisional Pat. Application No. 62/951,897 filed December 20 th , 2019, the entirety of which is incorporated by reference herein. In some embodiments, the applications  110  can be deployed on the edge platform  102 . In this regard, lower latency in management of the building subsystems  122  can be realized. 
     The edge platform  102  can be connected to the cloud platform  106  via a network  104 . The network  104  can communicatively couple the devices and systems of building data platform  100 . In some embodiments, the network  104  is at least one of and/or a combination of a Wi-Fi network, a wired Ethernet network, a ZigBee network, a Bluetooth network, and/or any other wireless network. The network  104  may be a local area network or a wide area network (e.g., the Internet, a building WAN, etc.) and may use a variety of communications protocols (e.g., BACnet, IP, LON, etc.). The network  104  may include routers, modems, servers, cell towers, satellites, and/or network switches. The network  104  may be a combination of wired and wireless networks. 
     The cloud platform  106  can be configured to facilitate communication and routing of messages between the applications  110 , the twin manager  108 , the edge platform  102 , and/or any other system. The cloud platform  106  can include a platform manager  128 , a messaging manager  140 , a command processor  136 , and an enrichment manager  138 . In some embodiments, the cloud platform  106  can facilitate messaging between the building data platform  100  via the network  104 . 
     The messaging manager  140  can be configured to operate as a transport service that controls communication with the building subsystems  122  and/or any other system, e.g., managing commands to devices (C2D), commands to connectors (C2C) for external systems, commands from the device to the cloud (D2C), and/or notifications. The messaging manager  140  can receive different types of data from the applications  110 , the twin manager  108 , and/or the edge platform  102 . The messaging manager  140  can receive change on value data  142 , e.g., data that indicates that a value of a point has changed. The messaging manager  140  can receive timeseries data  144 , e.g., a time correlated series of data entries each associated with a particular time stamp. Furthermore, the messaging manager  140  can receive command data  146 . All of the messages handled by the cloud platform  106  can be handled as an event, e.g., the data  142 – 146  can each be packaged as an event with a data value occurring at a particular time (e.g., a temperature measurement made at a particular time). 
     The cloud platform  106  includes a command processor  136 . The command processor  136  can be configured to receive commands to perform an action from the applications  110 , the building subsystems  122 , the user device  176 , etc. The command processor  136  can manage the commands, determine whether the commanding system is authorized to perform the particular commands, and communicate the commands to the commanded system, e.g., the building subsystems  122  and/or the applications  110 . The commands could be a command to change an operational setting that control environmental conditions of a building, a command to run analytics, etc. 
     The cloud platform  106  includes an enrichment manager  138 . The enrichment manager  138  can be configured to enrich the events received by the messaging manager  140 . The enrichment manager  138  can be configured to add contextual information to the events. The enrichment manager  138  can communicate with the twin manager  108  to retrieve the contextual information. In some embodiments, the contextual information is an indication of information related to the event. For example, if the event is a timeseries temperature measurement of a thermostat, contextual information such as the location of the thermostat (e.g., what room), the equipment controlled by the thermostat (e.g., what VAV), etc. can be added to the event. In this regard, when a consuming application, e.g., one of the applications  110  receives the event, the consuming application can operate based on the data of the event, the temperature measurement, and also the contextual information of the event. 
     The enrichment manager  138  can solve a problem that when a device produces a significant amount of information, the information may contain simple data without context. An example might include the data generated when a user scans a badge at a badge scanner of the building subsystems  122 . This physical event can generate an output event including such information as “DeviceBadgeScannerID,” “BadgeID,” and/or “Date/Time.” However, if a system sends this data to a consuming application, e.g., Consumer A and a Consumer B, each customer may need to call the building data platform knowledge service to query information with queries such as, “What space, build, floor is that badge scanner in?” or “What user is associated with that badge?” 
     By performing enrichment on the data feed, a system can be able to perform inferences on the data. A result of the enrichment may be transformation of the message “DeviceBadgeScannerId, BadgeId, Date/Time,” to “Region, Building, Floor, Asset, DeviceId, BadgeId, UserName, EmployeeId, Date/Time Scanned.” This can be a significant optimization, as a system can reduce the number of calls by 1/n, where n is the number of consumers of this data feed. 
     By using this enrichment, a system can also have the ability to filter out undesired events. If there are  100  building in a campus that receive 100,000 events per building each hour, but only 1 building is actually commissioned, only ⅒ of the events are enriched. By looking at what events are enriched and what events are not enriched, a system can do traffic shaping of forwarding of these events to reduce the cost of forwarding events that no consuming application wants or reads. 
     An example of an event received by the enrichment manager  138  may be:  
     
       
         
           
               
            
               
                 { 
               
               
                 “id”: “someguid”, 
               
               
                 “eventType”: “Device_Heartbeat”, 
               
               
                 “eventTime”: “2018-01-27T00:00:00+00:00” 
               
               
                 “eventValue”: 1, 
               
               
                 “deviceID”: “someguid” 
               
               
                 } 
               
            
           
         
       
     
     An example of an enriched event generated by the enrichment manager  138  may be:  
     
       
         
           
               
            
               
                 { 
               
               
                 “id”: “someguid”, 
               
               
                 “eventType”: “Device_Heartbeat”, 
               
               
                 “eventTime”: “2018-01-27T00:00:00+00:00” 
               
               
                 “eventValue”: 1, 
               
               
                 “deviceID”: “someguid”, 
               
               
                 “buildingName”: “Building-48”, 
               
               
                 “buildingID”: “SomeGuid”, 
               
               
                 “panelID”: “SomeGuid”, 
               
               
                 “panelName”: “Building-48-Panel-13”, 
               
               
                 “cityID”: 371, 
               
               
                 “cityName”: “Milwaukee”, 
               
               
                 “stateID”: 48, 
               
               
                 “stateName”: “Wisconsin (WI)”, 
               
               
                 “countryID”: 1, 
               
               
                 “countryName”: “United States” 
               
               
                 } 
               
            
           
         
       
     
     By receiving enriched events, an application of the applications  110  can be able to populate and/or filter what events are associated with what areas. Furthermore, user interface generating applications can generate user interfaces that include the contextual information based on the enriched events. 
     The cloud platform  106  includes a platform manager  128 . The platform manager  128  can be configured to manage the users and/or subscriptions of the cloud platform  106 . For example, what subscribing building, user, and/or tenant utilizes the cloud platform  106 . The platform manager  128  includes a provisioning service  130  configured to provision the cloud platform  106 , the edge platform  102 , and the twin manager  108 . The platform manager  128  includes a subscription service  132  configured to manage a subscription of the building, user, and/or tenant while the entitlement service  134  can track entitlements of the buildings, users, and/or tenants. 
     The twin manager  108  can be configured to manage and maintain a digital twin. The digital twin can be a digital representation of the physical environment, e.g., a building. The twin manager  108  can include a change feed generator  152 , a schema and ontology  154 , a projection manager  156 , a policy manager  158 , an entity, relationship, and event database  160 , and a graph projection database  162 . 
     The graph projection manager  156  can be configured to construct graph projections and store the graph projections in the graph projection database  162 . Examples of graph projections are shown in  FIGS.  11 - 13   . Entities, relationships, and events can be stored in the database  160 . The graph projection manager  156  can retrieve entities, relationships, and/or events from the database  160  and construct a graph projection based on the retrieved entities, relationships and/or events. In some embodiments, the database  160  includes an entity-relationship collection for multiple subscriptions. 
     In some embodiment, the graph projection manager  156  generates a graph projection for a particular user, application, subscription, and/or system. In this regard, the graph projection can be generated based on policies for the particular user, application, and/or system in addition to an ontology specific for that user, application, and/or system. In this regard, an entity could request a graph projection and the graph projection manager  156  can be configured to generate the graph projection for the entity based on policies and an ontology specific to the entity. The policies can indicate what entities, relationships, and/or events the entity has access to. The ontology can indicate what types of relationships between entities the requesting entity expects to see, e.g., floors within a building, devices within a floor, etc. Another requesting entity may have an ontology to see devices within a building and applications for the devices within the graph. 
     The graph projections generated by the graph projection manager  156  and stored in the graph projection database  162  can be a knowledge graph and is an integration point. For example, the graph projections can represent floor plans and systems associated with each floor. Furthermore, the graph projections can include events, e.g., telemetry data of the building subsystems  122 . The graph projections can show application services as nodes and API calls between the services as edges in the graph. The graph projections can illustrate the capabilities of spaces, users, and/or devices. The graph projections can include indications of the building subsystems  122 , e.g., thermostats, cameras, VAVs, etc. The graph projection database  162  can store graph projections that keep up a current state of a building. 
     The graph projections of the graph projection database  162  can be digital twins of a building. Digital twins can be digital replicas of physical entities that enable an in-depth analysis of data of the physical entities and provide the potential to monitor systems to mitigate risks, manage issues, and utilize simulations to test future solutions. Digital twins can play an important role in helping technicians find the root cause of issues and solve problems faster, in supporting safety and security protocols, and in supporting building managers in more efficient use of energy and other facilities resources. Digital twins can be used to enable and unify security systems, employee experience, facilities management, sustainability, etc. 
     In some embodiments the enrichment manager  138  can use a graph projection of the graph projection database  162  to enrich events. In some embodiments, the enrichment manager  138  can identify nodes and relationships that are associated with, and are pertinent to, the device that generated the event. For example, the enrichment manager  138  could identify a thermostat generating a temperature measurement event within the graph. The enrichment manager  138  can identify relationships between the thermostat and spaces, e.g., a zone that the thermostat is located in. The enrichment manager  138  can add an indication of the zone to the event. 
     Furthermore, the command processor  136  can be configured to utilize the graph projections to command the building subsystems  122 . The command processor  136  can identify a policy for a commanding entity within the graph projection to determine whether the commanding entity has the ability to make the command. For example, the command processor  136 , before allowing a user to make a command, determine, based on the graph projection database  162 , to determine that the user has a policy to be able to make the command. 
     In some embodiments, the policies can be conditional based policies. For example, the building data platform  100  can apply one or more conditional rules to determine whether a particular system has the ability to perform an action. In some embodiments, the rules analyze a behavioral based biometric. For example, a behavioral based biometric can indicate normal behavior and/or normal behavior rules for a system. In some embodiments, when the building data platform  100  determines, based on the one or more conditional rules, that an action requested by a system does not match a normal behavior, the building data platform  100  can deny the system the ability to perform the action and/or request approval from a higher level system. 
     For example, a behavior rule could indicate that a user has access to log into a system with a particular IP address between 8A.M. through 5 P.M. However, if the user logs in to the system at 7 P.M., the building data platform  100  may contact an administrator to determine whether to give the user permission to log in. 
     The change feed generator  152  can be configured to generate a feed of events that indicate changes to the digital twin, e.g., to the graph. The change feed generator  152  can track changes to the entities, relationships, and/or events of the graph. For example, the change feed generator  152  can detect an addition, deletion, and/or modification of a node or edge of the graph, e.g., changing the entities, relationships, and/or events within the database  160 . In response to detecting a change to the graph, the change feed generator  152  can generate an event summarizing the change. The event can indicate what nodes and/or edges have changed and how the nodes and edges have changed. The events can be posted to a topic by the change feed generator  152 . 
     The change feed generator  152  can implement a change feed of a knowledge graph. The building data platform  100  can implement a subscription to changes in the knowledge graph. When the change feed generator  152  posts events in the change feed, subscribing systems or applications can receive the change feed event. By generating a record of all changes that have happened, a system can stage data in different ways, and then replay the data back in whatever order the system wishes. This can include running the changes sequentially one by one and/or by jumping from one major change to the next. For example, to generate a graph at a particular time, all change feed events up to the particular time can be used to construct the graph. 
     The change feed can track the changes in each node in the graph and the relationships related to them, in some embodiments. If a user wants to subscribe to these changes and the user has proper access, the user can simply submit a web API call to have sequential notifications of each change that happens in the graph. A user and/or system can replay the changes one by one to reinstitute the graph at any given time slice. Even though the messages are “thin” and only include notification of change and the reference “id/seq id,” the change feed can keep a copy of every state of each node and/or relationship so that a user and/or system can retrieve those past states at any time for each node. Furthermore, a consumer of the change feed could also create dynamic “views” allowing different “snapshots” in time of what the graph looks like from a particular context. While the twin manager  108  may contain the history and the current state of the graph based upon schema evaluation, a consumer can retain a copy of that data, and thereby create dynamic views using the change feed. 
     The schema and ontology  154  can define the message schema and graph ontology of the twin manager  108 . The message schema can define what format messages received by the messaging manager  140  should have, e.g., what parameters, what formats, etc. The ontology can define graph projections, e.g., the ontology that a user wishes to view. For example, various systems, applications, and/or users can be associated with a graph ontology. Accordingly, when the graph projection manager  156  generates an graph projection for a user, system, or subscription, the graph projection manager  156  can generate a graph projection according to the ontology specific to the user. For example, the ontology can define what types of entities are related in what order in a graph, for example, for the ontology for a subscription of “Customer A,” the graph projection manager  156  can create relationships for a graph projection based on the rule: Region ←→ Building ←→ Floor ←→ Space Asset 
     For the ontology of a subscription of “Customer B,” the graph projection manager  156  can create relationships based on the rule: Building ←→ Floor Asset 
     The policy manager  158  can be configured to respond to requests from other applications and/or systems for policies. The policy manager  158  can consult a graph projection to determine what permissions different applications, users, and/or devices have. The graph projection can indicate various permissions that different types of entities have and the policy manager  158  can search the graph projection to identify the permissions of a particular entity. The policy manager  158  can facilitate fine grain access control with user permissions. The policy manager  158  can apply permissions across a graph, e.g., if “user can view all data associated with floor 1” then they see all subsystem data for that floor, e.g., surveillance cameras, HVAC devices, fire detection and response devices, etc. 
     The twin manager  108  includes a query manager  165  and a twin function manager  167 . The query manger  164  can be configured to handle queries received from a requesting system, e.g., the user device  176 , the applications  110 , and/or any other system. The query manager  165  can receive queries that include query parameters and context. The query manager  165  can query the graph projection database  162  with the query parameters to retrieve a result. The query manager  165  can then cause an event processor, e.g., a twin function, to operate based on the result and the context. In some embodiments, the query manager  165  can select the twin function based on the context and/or perform operates based on the context. In some embodiments, the query manager  165  is configured to perform the operations described with reference to  FIGS.  5 - 10   . 
     The twin function manager  167  can be configured to manage the execution of twin functions. The twin function manager  167  can receive an indication of a context query that identifies a particular data element and/or pattern in the graph projection database  162 . Responsive to the particular data element and/or pattern occurring in the graph projection database  162  (e.g., based on a new data event added to the graph projection database  162  and/or change to nodes or edges of the graph projection database  162 , the twin function manager  167  can cause a particular twin function to execute. The twin function can execute based on an event, context, and/or rules. The event can be data that the twin function executes against. The context can be information that provides a contextual description of the data, e.g., what device the event is associated with, what control point should be updated based on the event, etc. The twin function manager  167  can be configured to perform the operations of the  FIGS.  11 - 15   . 
     Referring now to  FIG.  2   , a graph projection  200  of the twin manager  108  including application programming interface (API) data, capability data, policy data, and services is shown, according to an exemplary embodiment. The graph projection  200  includes nodes  202 - 240  and edges  250 - 272 . The nodes  202 - 240  and the edges  250 - 272  are defined according to the key  201 . The nodes  202 - 240  represent different types of entities, devices, locations, points, persons, policies, and software services (e.g., API services). The edges  250 - 272  represent relationships between the nodes  202 - 240 , e.g., dependent calls, API calls, inferred relationships, and schema relationships (e.g., BRICK relationships). 
     The graph projection  200  includes a device hub  202  which may represent a software service that facilitates the communication of data and commands between the cloud platform  106   and a device of the building subsystems  122 , e.g., door actuator  214 . The device hub  202  is related to a connector  204 , an external system  206 , and a digital asset “Door Actuator”  208  by edge  250 , edge  252 , and edge  254 . 
     The cloud platform  106  can be configured to identify the device hub  202 , the connector  204 , the external system  206  related to the door actuator  214  by searching the graph projection  200  and identifying the edges  250 - 254  and edge  258 . The graph projection  200  includes a digital representation of the “Door Actuator,” node  208 . The digital asset “Door Actuator”  208  includes a “DeviceNameSpace” represented by node  207  and related to the digital asset “Door Actuator”  208  by the “Property of Object” edge  256 . 
     The “Door Actuator”  214  has points and timeseries. The “Door Actuator”  214  is related to “Point A”  216  by a “has_a” edge  260 . The “Door Actuator”  214  is related to “Point B”  218  by a “has_A” edge  258 . Furthermore, timeseries associated with the points A and B are represented by nodes “TS”  220  and “TS”  222 . The timeseries are related to the points A and B by “has_a” edge  264  and “has_a” edge  262 . The timeseries “TS”  220  has particular samples, sample  210  and  212  each related to “TS”  220  with edges  268  and  266  respectively. Each sample includes a time and a value. Each sample may be an event received from the door actuator that the cloud platform  106  ingests into the entity, relationship, and event database  160 , e.g., ingests into the graph projection  200 . 
     The graph projection  200  includes a building  234  representing a physical building. The building includes a floor represented by floor  232  related to the building  234  by the “has_a” edge from the building  234  to the floor  232 . The floor has a space indicated by the edge “has_a”  270  between the floor  232  and the space  230 . The space has particular capabilities, e.g., is a room that can be booked for a meeting, conference, private study time, etc. Furthermore, the booking can be canceled. The capabilities for the floor  232  are represented by capabilities  228  related to space  230  by edge  280 . The capabilities  228  are related to two different commands, command “book room”  224  and command “cancel booking”  226  related to capabilities  228  by edge  284  and edge  282  respectively. 
     If the cloud platform  106  receives a command to book the space represented by the node, space  230 , the cloud platform  106  can search the graph projection  200  for the capabilities for the  228  related to the space  230  to determine whether the cloud platform  106  can book the room. 
     In some embodiments, the cloud platform  106  could receive a request to book a room in a particular building, e.g., the building  234 . The cloud platform  106  could search the graph projection  200  to identify spaces that have the capabilities to be booked, e.g., identify the space  230  based on the capabilities  228  related to the space  230 . The cloud platform  106  can reply to the request with an indication of the space and allow the requesting entity to book the space  230 . 
     The graph projection  200  includes a policy  236  for the floor  232 . The policy  236  is related set for the floor  232  based on a “To Floor” edge  274  between the policy  236  and the floor  232 . The policy  236  is related to different roles for the floor  232 , read events  238  via edge  276  and send command  240  via edge  278 . The policy  236  is set for the entity  203  based on has edge  251  between the entity  203  and the policy  236 . 
     The twin manager  108  can identify policies for particular entities, e.g., users, software applications, systems, devices, etc. based on the policy  236 . For example, if the cloud platform  106  receives a command to book the space  230 . The cloud platform  106  can communicate with the twin manager  108  to verify that the entity requesting to book the space  230  has a policy to book the space. The twin manager  108  can identify the entity requesting to book the space as the entity  203  by searching the graph projection  200 . Furthermore, the twin manager  108  can further identify the edge has  251  between the entity  203  and the policy  236  and the edge  1178  between the policy  236  and the command  240 . 
     Furthermore, the twin manager  108  can identify that the entity  203  has the ability to command the space  230  based on the edge  1174  between the policy  236  and the edge  270  between the floor  232  and the space  230 . In response to identifying the entity  203  has the ability to book the space  230 , the twin manager  108  can provide an indication to the cloud platform  106 . 
     Furthermore, if the entity makes a request to read events for the space  230 , e.g., the sample  210  and the sample  212 , the twin manager  108  can identify the edge has  251  between the entity  203  and the policy  236 , the edge  1178  between the policy  236  and the read events  238 , the edge  1174  between the policy  236  and the floor  232 , the “has_a” edge  270  between the floor  232  and the space  230 , the edge  268  between the space  230  and the door actuator  214 , the edge  260  between the door actuator  214  and the point A  216 , the “has_a” edge  264  between the point A  216  and the TS  220 , and the edges  268  and  266  between the TS  220  and the samples  210  and  212  respectively. 
     Referring now to  FIG.  3   , a graph projection  300  of the twin manager  108  including application programming interface (API) data, capability data, policy data, and services is shown, according to an exemplary embodiment. The graph projection  300  includes the nodes and edges described in the graph projection  200  of  FIG.  2   . The graph projection  300  includes a connection broker  354  related to capabilities  228  by edge  398   a . The connection broker  354  can be a node representing a software application configured to facilitate a connection with another software application. In some embodiments, the cloud platform  106  can identify the system that implements the capabilities  228  by identifying the edge  398   a  between the capabilities  228  and the connection broker  354 . 
     The connection broker  354  is related to an agent that optimizes a space  356  via edge  398   b . The agent represented by the node  356  can book and cancel bookings for the space represented by the node  230  based on the edge  398   b  between the connection broker  354  and the node  356  and the edge  398   a  between the capabilities  228  and the connection broker  354 . 
     The connection broker  354  is related to a cluster  308  by edge  398   c . Cluster  308  is related to connector B  302  via edge  398   e  and connector A  306  via edge  398   d . The connector A  306  is related to an external subscription service  304 . A connection broker  310  is related to cluster  308  via an edge  311  representing a rest call that the connection broker represented by node  310  can make to the cluster represented by cluster  308 . 
     The connection broker  310  is related to a virtual meeting platform  312  by an edge  354 . The node  312  represents an external system that represents a virtual meeting platform. The connection broker represented by node  310  can represent a software component that facilitates a connection between the cloud platform  106  and the virtual meeting platform represented by node  312 . When the cloud platform  106  needs to communicate with the virtual meeting platform represented by the node  312 , the cloud platform  106  can identify the edge  354  between the connection broker  310  and the virtual meeting platform  312  and select the connection broker represented by the node  310  to facilitate communication with the virtual meeting platform represented by the node  312 . 
     A capabilities node  318  can be connected to the connection broker  310  via edge  360 . The capabilities  318  can be capabilities of the virtual meeting platform represented by the node  312  and can be related to the node  312  through the edge  360  to the connection broker  310  and the edge  354  between the connection broker  310  and the node  312 . The capabilities  318  can define capabilities of the virtual meeting platform represented by the node  312 . The node  320  is related to capabilities  318  via edge  362 . The capabilities may be an invite bob command represented by node  316  and an email bob command represented by node  314 . The capabilities  318  can be linked to a node  320  representing a user, Bob. The cloud platform  106  can facilitate email commands to send emails to the user Bob via the email service represented by the node  304 . The node  304  is related to the connect a node  306  via edge  398   f . Furthermore, the cloud platform  106  can facilitate sending an invite for a virtual meeting via the virtual meeting platform represented by the node  312  linked to the node  318  via the edge  358 . 
     The node  320  for the user Bob can be associated with the policy  236  via the “has” edge  364 . Furthermore, the node  320  can have a “check policy” edge  366  with a portal node  324 . The device API node  328  has a check policy edge  370  to the policy node  236 . The portal node  324  has an edge  368  to the policy node  236 . The portal node  324  has an edge  323  to a node  326  representing a user input manager (UIM). The portal node  324  is related to the UIM node  326  via an edge  323 . The UIM node  326  has an edge  323  to a device API node  328 . The UIM node  326  is related to the door actuator node  214  via edge  372 . The door actuator node  214  has an edge  374  to the device API node  328 . The door actuator  214  has an edge  335  to the connector virtual object  334 . The device hub  332  is related to the connector virtual object via edge  380 . The device API node  328  can be an API for the door actuator  214 . The connector virtual object  334  is related to the device API node  328  via the edge  331 . 
     The device API node  328  is related to a transport connection broker  330  via an edge  329 . The transport connection broker  330  is related to a device hub  332  via an edge  378 . The device hub represented by node  332  can be a software component that hands the communication of data and commands for the door actuator  214 . The cloud platform  106  can identify where to store data within the graph projection  300  received from the door actuator by identifying the nodes and edges between the points  216  and  218  and the device hub node  332 . Similarly, the cloud platform  308  can identify commands for the door actuator that can be facilitated by the device hub represented by the node  332 , e.g., by identifying edges between the device hub node  332  and an open door node  352  and an lock door node  350 . The door actuator  114  has an edge “has mapped an asset”  280  between the node  214  and a capabilities node  348 . The capabilities node  348  and the nodes  352  and  350  are linked by edges  396  and  394 . 
     The device hub  332  is linked to a cluster  336  via an edge  384 . The cluster  336  is linked to connector A  340  and connector B  338  by edges  386  and the edge  389 . The connector A  340  and the connector B  338  is linked to an external system  344  via edges  388  and  390 . The external system  344  is linked to a door actuator  342  via an edge  392 . 
     Referring now to  FIG.  4   , a graph projection  400  of the twin manager  108  including equipment and capability data for the equipment is shown, according to an exemplary embodiment. The graph projection  400  includes nodes  402 - 456  and edges  360 - 498   f . The cloud platform  106  can search the graph projection  400  to identify capabilities of different pieces of equipment. 
     A building node  404  represents a particular building that includes two floors. A floor 1 node  402  is linked to the building node  404  via edge  460  while a floor 2 node  406  is linked to the building node  404  via edge  462 . The floor 2 includes a particular room  2023  represented by edge  464  between floor 2 node  406  and room  2023  node  408 . Various pieces of equipment are included within the room  2023 . A light represented by light node  416 , a bedside lamp node  414 , a bedside lamp node  412 , and a hallway light node  410  are related to room  2023  node  408  via edge  466 , edge  472 , edge  470 , and edge  468 . 
     The light represented by light node  416  is related to a light connector  426  via edge  484 . The light connector  426  is related to multiple commands for the light represented by the light node  416  via edges  484 ,  486 , and  488 . The commands may be a brightness setpoint  424 , an on command  425 , and a hue setpoint  428 . The cloud platform  106  can receive a request to identify commands for the light represented by the light  416  and can identify the nodes  424 - 428  and provide an indication of the commands represented by the node  424 - 428  to the requesting entity. The requesting entity can then send commands for the commands represented by the nodes  424 - 428 . 
     The bedside lamp node  414  is linked to a bedside lamp connector  481  via an edge  413 . The connector  481  is related to commands for the bedside lamp represented by the bedside lamp node  414  via edges  492 ,  496 , and  494 . The command nodes are a brightness setpoint node  432 , an on command node  434 , and a color command  436 . The hallway light  410  is related to a hallway light connector  446  via an edge  498   d . The hallway light connector  446  is linked to multiple commands for the hallway light node  410  via edges  498   g ,  498   f , and  498   e . The commands are represented by an on command node  452 , a hue setpoint node  450 , and a light bulb activity node  448 . 
     The graph projection  400  includes a name space node  422  related to a server A node  418  and a server B node  420  via edges  474  and  476 . The name space node  422  is related to the bedside lamp connector  481 , the bedside lamp connector  444 , and the hallway light connector  446  via edges  482 ,  480 , and  478 . The bedside lamp connector  444  is related to commands, e.g., the color command node  440 , the hue setpoint command  438 , a brightness setpoint command  456 , and an on command  454  via edges  498   c ,  498   b ,  498   a , and  498 . 
     Referring generally to  FIG.  5   , an extensibility manager  502  that extends a schema definition  500  of a digital twin at runtime is shown, according to an exemplary embodiment. The schema definition  500  can be one particular definition of a larger schema. The schema definition  500  provides an example of a particular schema for a particular entity class  510 . The schema definition  500  includes various attributes for the entity class  510 , e.g., an entity property  512 , an entity property  514 , an entity tag  516 , and an entity state  518 . The schema definition  500  could be implemented in a digital twin, e.g., in the graphs described with reference to  FIGS.  1 - 4    or elsewhere herein. 
     The entity class  510  could be a thermostat class, a person class, a video camera class, a conference room class, etc. The entity class  510  can be a general category of an entity that describes all of the attributes of the entity through the properties, tags, and states defined in the schema definition  500 . When a new entity is generated in a digital twin all of the properties, tags, and/or states for said new entity can also be generated and linked to the new entity through relationships, based on the schema definition  500 . The schema definition  500  can be stored in a database, in some embodiments. 
     The entity properties, the entity property  512  and/or the entity property  514 , could be properties of the entity class  510 , e.g., inputs of a thermostat, outputs of the thermostat, computing resources of a computing system, capacity of a boiler, maximum air changes of an air handler, etc. The entity tag  516  can indicate a tag of the entity class  510 , e.g., indicating that at thermostat is part of a test group, indicating a date that maintenance should be performed on a pump system, indicating when a filter was last changed, etc. The entity state  518  could indicate a state of an entity, e.g., a temperature measured by a temperature sensor, a setpoint of a thermostat, an air quality measurement of an air quality sensor, an indication that a variable air volume (VAV) module is in a fault state, etc. 
     The extensibility manager  502  can be configured to extend the schema definition  500  by adding an extended schema  508  to the schema definition  500 . The extensibility manager  502  can perform the extension at runtime, while a building system running the digital twin is currently operating, without requiring any downtime, reconfiguration, recompilation, manual intervention, etc. The extensibility manager  502  includes an extensible property manager  504  and the extensible state manager  506 . 
     The extensible property manager  504  can be configured to add properties and/or tags to the schema definition  500 . For example, the manager  504  can add tags and/or properties, e.g., the extended entity tag  520  and/or the extended entity property  522 . The tag or property added to the extended schema  508  can be any of the tags or properties discussed herein. The manager  506  can add states to the extended schema  508 , e.g., the extended entity state  524 . The extended entity state can be any state described herein. The manager  502  can update a digital twin based on the extended schema  508 . For example, for each instance of the entity class  510 , the manager  502  can cause each instance of the entity class  510  to include new tags, new properties, and/or new states defined by the extended entity tag  520 , the extended entity property  522 , and/or the extended entity state  524 . In some embodiments, the tags, properties, and/or states are set to default values. 
     Referring now to  FIG.  6   , the twin manager  108  is shown wherein the extensible property or tag manager  504  updates a digital twin to include new properties or tags in the schema of the digital twin, according to an exemplary embodiment. In  FIG.  6   , the twin manager  108  includes a digital twin  608  which is updated to the digital twin  610  by the manager  504 . The manager  504  extends a schema used to define the entities in the digital twin  608  to add new properties and/or tags to the digital twin  606 . 
     The digital twin  608  includes nodes  612 – 628  which may be related to each other via edges. The nodes and edges of the digital twin  608  can form a graph, e.g., one of the graphs shown and/or described with reference to  FIGS.  1 - 4    or elsewhere herein. The digital twin  608  includes a building node  620  representing a building. The building node  620  is related by edges to a floor  616  node and a floor node  622 , indicating that the building has two separate floors. The floor node  616  is related to a space heater node  612  indicating that the floor has a space heater. The floor node  616  and the space heater  612  are related to a thermostat node  614  by edges indicating that the floor has a thermostat that operates the space heater. The thermostat node  614  is related to a temperature setpoint node  618  to indicate the temperature setpoint of the thermostat. 
     The floor node  622  is related to a space heater node  626  indicating that the floor has a space heater. The floor node  622  and the space heater  626  are related to a thermostat node  628  by edges indicating that the floor has a thermostat that operates the space heater. The thermostat node  628  is related to a temperature setpoint node  624  to indicate the temperature setpoint of the thermostat. 
     The manager  504  includes a user update detector  600 , a new node detector  602 , a new edge detector  604 , and a property or tag updater  606 . The user update detector  600  can be configured to receive information from the user device  176 . The information can be requests for new properties or tags be added to various entity classes. The detector  600  can analyze the data received from the user device  176  and identify which entity classes should have properties and/or tags added. The detector  600  can cause the property or tag updater  606  to add the new properties and/or tags to the entity class in the schema of the digital twin  608  and further cause corresponding nodes and/or edges to be added to the digital twin  608  to represent the new properties and/or tags. 
     The new node detector  602  can identify that a new node has been added to the digital twin  608 . New nodes being added to the digital twin  608  can indicate that new pieces of equipment have been installed in a building, new conference rooms have been formed in the building, new equipment has been discovered via a network, etc. For example, a central fan could be installed in the building, the central fan node  632  could be added to the digital twin  608  to indicate that the central fan operates for the building represented by the building  620 . The new node detector  602  could identify the new central fan node  632  and/or the new edge detector  604  could identify a new edge between the building  620  and the central fan  632 . The manager  504  could identify that the new nodes and/or edges indicate that new properties and/or tags should be added to the digital twin  608 , where the new properties and/or tags may update the schema of the digital twin  608 . 
     For example, if a central fan is added to the building, e.g., the central fan  632  and an edge between the node  632  and the building  620  is added, the manager  504  could identify that control devices of the building should be able to control the central fan, e.g., the control devices have the ability to control the central fan, e.g., because they are connected to the central fan (identified by detecting relationships between the central fan node  632  and a node representing the control devices). The manager  504  can add a fan control property node  630  and a fan control property node  634  to the digital twin  608 . These new fan control properties may extend the schema of the digital twin  608  to account for the fact that the thermostats represented by the nodes  614  and  628  can now control a central fan, i.e., represented by the central fan node  632 . The nodes  630  and  634  may be capabilities, in some embodiments. 
     The property or tag updater  606  can be configured to update properties and/or tags based on the detections, identifications, and/or determinations made by the detectors  600 - 604 . The updater  606  can be configured to update a schema that defines the digital twin  608  to generate an updated version of the digital twin  608 , the digital twin  610 . The updater  606  can cause updates to be made to the digital twin  608  based on the schema. For example, the updater  606  can consult the updated schema to update the properties and/or tags of existing entities of the digital twin  608 . Furthermore, when new entities of the updated entity class are added to the digital twin  608 , they can be added with the new properties and/or tags. The updater  606  can add nodes representing the new properties and/or tags and edges between the new nodes and the entity node representing a particular instance of the entity class. 
     Referring now to  FIG.  7   , a flow diagram of a process  700  where the extensible property manager of  FIG.  6    updates a digital twin to include new properties in the schema of the digital twin is shown, according to an exemplary embodiment. In some embodiments, the manager  504  can be configured to perform the process  700 . In some embodiments, any computing device described herein can be configured to perform the process  700 . 
     In step  702 , the building data platform  100  can be deployed. The building data platform  100  can be deployed to operate based on a digital twin, e.g., the digital twin  608  and/or any other digital twin and/or graph data structure described herein. For example, various pieces of software and/or systems (e.g., the applications  110 ) can run against the digital twin, e.g., making equipment control decisions for the building subsystems  122  (e.g., controlling temperature, humidity, lighting, etc.), determining alarms, reducing energy usage of the building subsystems  122 , etc. 
     In step  704 , the manager  504  receives an indication to add a property or tag to an entity class of a schema of the digital twin. The indication can, in some embodiments, be received from a user, e.g., via the user device  176 . In some embodiments, the manager  504  can derive an insight that the new property or tag should be added by identify changes to the digital twin, e.g., additions or subtractions of nodes and/or edges in the digital twin  608 . 
     In step  706 , the manager  504  operates to add the property or tag to entities of the digital twin where the entities are of the entity class. This extends the schema implemented in the digital twin. The extension of the schema, in addition to adding the properties or nodes to the digital twin, can be performed while the building data platform  100  is deployed without requiring reconfiguration and/or redeployment of the building data platform  100  and/or the digital twin. 
     Updating the schema with new properties or tag for an entity can involve adding nodes and/or edges to the graph for each instance of the entity class. For example, if a new tag is added for a thermostat, the manager  504  can cause a node for the new tag to be added for each thermostat node in the digital twin. The manager  504  can cause one or more edges to relate the new node for the tag and the node for the entity in the digital twin. In step  708 , the manager  504  performs one or more operations based on the one or more properties and/or nodes added to the digital twin, the new properties or nodes extending the schema of the digital twin. 
     Referring now to  FIG.  8   , an extensible state manager  506  updating the digital twin  608  based on information received from a fault analysis agent is shown, the update causing the digital twin  608  to include new states indicating faults in the schema of the digital twin  608 , according to an exemplary embodiment. In some embodiments, an agent, or any other type of application that consumes the digital twin  608  (or information of the digital twin  608 ) can add states to the digital twin  608 . For example, the fault analysis agent  808  can use a machine learning model to detect faults for pieces of equipment in the digital twin  608  (e.g., by analyzing data and/or operations made by the pieces of equipment). 
     However, the schema of the digital twin  608  may not have any mechanism for describing a particular device for having a fault or being operational. In this regard, the manager  506  can determine, based on determinations made by the agent  808 , to add a state to the schema of the digital twin  608  describing the thermostat fault state. The manager  506  can cause an entity class of thermostat to include a state that indicates whether the thermostat is in a fault state or not. The manager  506  can cause all thermostat instantiated based on the thermostat class to include a state indicating whether the thermostat is in a fault state or not. The manager  506  can cause the default value of the state to be an operational state indicating that no fault is present. However, if the agent  808  identifies a fault, the state can be set to a fault state. 
     For example, the manager  506  could add a state for each thermostat entity of the digital twin  608 . The manager  506  could search the digital twin  608  for all entities of a thermostat class and identify the thermostat node  614  and the thermostat node  628 . The manager  506  could cause the fault state node  804  to be generated for the thermostat node  614  and related to the thermostat node  614  via an edge, based on the update made to the schema for the thermostat entity class. The manager  506  can add the operational state node  806  to the digital twin  608  and an edge between the thermostat node  628  and the operational state  806 , based on the update made to the schema for the thermostat entity class. The fault state of node  804  can indicate that the thermostat represented by the thermostat node  614  is experiencing a fault. The operational state of node  806  can indicate that the thermostat represented by the thermostat node  628  is not experiencing a fault. 
     The agent  808  may make the fault determination for the thermostat represented by the thermostat node  614  (e.g., by consuming operational data associated with the thermostat, e.g., store din the digital twin  608 ). The manager  506  can assume, given no input from the agent  808  to the contrary, that the thermostat represented by the thermostat node  628  is in a operational state since the operational state may be the default state unless the agent  808  indicates otherwise. 
     Referring now to  FIG.  9   , the extensible state manager  506  is shown updating the digital twin  608  based on information received from an occupancy agent  904 , the update causing the digital twin  608  to include new states indicating occupancy in the schema of the digital twin, according to an exemplary embodiment. The calendar application  902  could be a system and/or software component that runs for an enterprise and/or building. The calendar application  902  can be configured to schedule and track meetings in various spaces of the building represented by the building node  620 . The calendar application  902  could be an OUTLOOK calendar, a GOOGLE calendar, MICROSOFT teams calendar, etc. 
     The occupancy agent  904  could be an agent that can spin up and down to run against the calendar data of the calendar application  902  to infer and/or determine occupancy levels for various areas of the building, e.g., rooms, conference rooms, meeting rooms, floors, the building itself, etc. The occupancy levels may, in some embodiments, be predicted occupancy levels that are predicted based on upcoming meetings scheduled for various spaces. The agent  904  can be a twin function, twin functions are described with reference to U.S. Pat. Application No. 17/354,436 filed June 22 nd , 2021 and U.S. Pat. Application No. 17/354,338 filed June 22 nd , 2021, the entireties of which is incorporated by reference herein. 
     The manager  506  can receive predicted occupancy levels for the floor represented by the floor node  616  and the floor represented by the floor node  622 . The manager  506  can review a schema of the digital twin  608  and identify that an occupancy state does not exist for floors and that an occupancy level has been predicted for the floors. The manager  506  can determine that an occupancy state should be added to the schema for a floor class based on the determinations made by the agent  904 . The manager  506  can operate to add the occupancy state as an attribute for a floor class, identify all floor entities of the floor class (e.g., the floor node  616  and the floor node  622 , add nodes to represent the occupancy level (e.g., the occupancy level node  902  and the occupancy level node  904 ), and relate the nodes  902  and  904  to the nodes  616  and  622  respectively by one or more edges. 
     The occupancy levels added to the schema of the digital twin for the floor class can be consumed by other applications. For example, the calendar application  902  could use the occupancy level data in the digital twin  900  to determine which rooms, floors, buildings, etc., are available or booked. Extending state definitions within the schema of the digital twin  608  allows for the digital twin  608  to adapt to new pieces of software that are running against the digital twin and enable plug-and-play capabilities and allow for state to be added to and queried against at runtime, without the need to update models, rebuild or redeploy any services, or do any data migration. For example, if a new application is deployed to run with the building data platform  100  and starts outputting a new state not currently in the schema of the digital twin  608 , the manager  608  can identify that the output of the application should be added to digital twin  608  and the schema of the digital twin  608  should be added. 
     Referring now to  FIG.  10   , a process  1000  of updating the digital twin  608  based on information received from an agent is shown, the update causing the digital twin to include new states indicating occupancy in the schema of the digital twin, according to an exemplary embodiment. In some embodiments, the manager  506  can be configured to perform the process  1000 . In some embodiments, any computing device described herein can be configured to perform the process  1000 . 
     In step  1002 , the building data platform  100  is deployed to operate based on a digital twin in a particular schema. The building data platform  100  can be deployed to operate based on a digital twin, e.g., the digital twin  608  and/or any other digital twin and/or graph data structure described herein. For example, various pieces of software and/or systems (e.g., the applications  110 ) can run against the digital twin, e.g., making equipment control decisions for the building subsystems  122  (e.g., controlling temperature, humidity, lighting, etc.), determining alarms, reducing energy usage of the building subsystems  122 , etc. 
     In step  1004 , the building data platform  100  can execute an agent to operate based on information of the digital twin  608 . In some embodiments, in addition to or instead of the agent, another application can run against the digital twin  608 , e.g., a fault detection application, a calendar application, an occupancy prediction application, an energy savings application, etc. In some embodiments, the agent (and/or the additional application) can run against data of the digital twin (and/or other information of the additional application) to determine new information. 
     In step  1006 , one or more states can be derived for an entity of an entity class in the schema of the digital twin  608  by the manager  506 . The manager  506  can review information determined by the agent and/or application to determine that a new state should be added to an entity class for the schema of the digital twin  608 . For example, if the agent outputs a fault indication, an occupancy indication, etc. for a particular entity that is not currently accounted for in the schema of the digital twin, the manager  506  can determine to add a new state type to the schema for the entity class. 
     In step  1008 , the manager  506  can add one or more states to entities of the entity class in the digital twin, thus extending the schema of the digital twin  608  while the building system is deployed to operate based on the digital twin. The manager  506  can add the states as nodes to the digital twin  608  with edges between the state nodes and nodes representing the entities. The manager  506  can search the digital twin  608  for each entity of the entity class and add the new state to each entity of the entity class. 
     In step  1010 , one or more operations can be performed based on the one or more new states of the digital twin  608 . The one or more operations can consume the new states of the digital twin  608  and make operational decisions based on the new states. For example, the predicted occupancy states could be used to determine appropriate temperature and/or humidity control operations of the building subsystems  122 . Similarly, fault states of the building subsystems  122  could be used by a maintenance system to schedule maintenance for the building subsystems  122 . 
     Configuration of Exemplary Embodiments 
     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 may be reversed or otherwise varied and the nature or number of discrete elements or positions may 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 may be varied or re-sequenced according to alternative embodiments. Other substitutions, modifications, changes, and omissions may be made in the design, operating conditions and arrangement of the exemplary embodiments without departing from the scope of the present disclosure. 
     The present disclosure contemplates methods, systems and program products on any machine-readable media for accomplishing various operations. The embodiments of the present disclosure may 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. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a machine, the machine properly views the connection as a machine-readable medium. Thus, any such connection is properly termed a machine-readable medium. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions. 
     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 may 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. 
     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.