Building management system with alarm generation, cloud storage, and visualization

CROSS-REFERENCE TO RELATED PATENT APPLICATION

0001This application claims the benefit of and priority to U.S. Provisional Patent Application No. 62/569,306 filed Oct. 6, 2017, the entire disclosure of which is incorporated by reference herein.

BACKGROUND

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

SUMMARY

0003One implementation of the present disclosure is a building management system including building equipment operable to affect a physical state or condition of a building, a system manager coupled to the building equipment via a system bus, and a cloud-based data platform. The system manager is configured to obtain alarm data from the building equipment and generate a timeseries sample that includes the alarm data. The cloud-based data platform includes a timeseries service configured to receive the timeseries sample from the system manager, extract the alarm data from the timeseries sample, and store the alarm data as a sample of an alarm timeseries.

0004In some embodiments, the system manager is configured to send a request for an alarm timeseries identifier to the timeseries service. In some embodiments, the timeseries service is configured to create the alarm timeseries in response to the request and send the alarm timeseries identifier to the system manager.

0005In some embodiments, the system manager is configured to generate a reported network tree listing the building equipment and store the alarm timeseries identifier as an attribute of the reported network tree.

0006In some embodiments, the system manager is configured to send the alarm timeseries identifier to the cloud-based data platform as an attribute of the timeseries sample comprising the alarm data.

0007In some embodiments, the timeseries service is configured to use the alarm timeseries identifier to identify the alarm timeseries and store the alarm data as the sample of the identified alarm timeseries.

0008In some embodiments, the system manager is configured to monitor an event list including a plurality of alarm events reported by the building equipment, generate a full alarm list report including all of the plurality of alarm events in the event list, transmit the full alarm list report to the cloud-based data platform, identify a change in the plurality of alarm events in the event list, and generate the alarm data such that the alarm data in the timeseries sample includes an indication of the change in the plurality of alarm events.

0009In some embodiments, the timeseries sample includes an alarm priority attribute indicating a priority associated with the alarm data. In some embodiments, the timeseries sample comprises an enumerated set attribute and an enumerated value attribute.

0010In some embodiments, the cloud-based data platform includes a dictionary service configured translate the enumerated set attribute and the enumerated value attribute into a text string describing the alarm.

0011In some embodiments, the cloud-based data platform includes a cloud application configured to generate a cause message describing a cause of the alarm based on at least one of the text string or the enumerated set attribute and the enumerated value attribute.

0012In some embodiments, the cloud-based data platform includes a cloud application configured to generate a resolution message describing a resolution of the alarm based on at least one of (a) the text string or (b) the enumerated set attribute and the enumerated value attribute.

0013Another implementation of the present disclosure is a method for monitoring and controlling building equipment in a building management system. The method includes operating building equipment to affect a physical state or condition of a building, obtaining alarm data from the building equipment at a system manager coupled to the building equipment via a system bus, generating a timeseries sample that includes the alarm data at the system manager, and transmitting the timeseries sample from the system manager to a timeseries service of a cloud-based data platform. The method includes extracting, by the timeseries service, the alarm data from the timeseries sample and storing, by the timeseries service, the alarm data as a sample of an alarm timeseries.

0014In some embodiments, the method includes the system manager sending a request for an alarm timeseries identifier to the timeseries service. In some embodiments, the method includes the timeseries service creating the alarm timeseries in response to the request and sending the alarm timeseries identifier to the system manager.

0015In some embodiments, the method includes the system manager generating a reported network tree listing the building equipment and storing the alarm timeseries identifier as an attribute of the reported network tree.

0016In some embodiments, the method includes the system manager sending the alarm timeseries identifier to the cloud-based data platform as an attribute of the timeseries sample that includes the alarm data.

0017In some embodiments, the method includes the timeseries service using the alarm timeseries identifier to identify the alarm timeseries and store the alarm data as the sample of the identified alarm timeseries.

0018In some embodiments, the timeseries sample includes an alarm priority attribute indicating a priority associated with the alarm data. In some embodiments, the timeseries sample includes an enumerated set attribute and an enumerated value attribute.

0019In some embodiments, the method includes monitoring an event list including a plurality of alarm events reported by the building equipment, generating a full alarm list report including all of the plurality of alarm events in the event list, transmitting the full alarm list report to the cloud-based data platform, identifying a change in the plurality of alarm events in the event list, and generating the alarm data such that the alarm data in the timeseries sample includes an indication of the change in the plurality of alarm events.

0020In some embodiments, the method includes translating the enumerated set attribute and the enumerated value attribute into a text string describing the alarm at a dictionary service of the cloud-based data platform.

0021In some embodiments, the method includes generating a cause message describing a cause of the alarm based on at least one of the text string or the enumerated set attribute and the enumerated value attribute at a cloud application of the cloud-based data platform.

0022In some embodiments, the method includes generating a resolution message describing a resolution of the alarm at a cloud application of the cloud-based data platform, wherein the resolution message is generated based on at least one of (a) the text string (b) the enumerated set attribute and the enumerated value attribute.

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

BRIEF DESCRIPTION OF THE DRAWINGS

0024<figref idref="DRAWINGS">FIG. 1</figref> is drawing of a building equipped with a heating, ventilating, and air conditioning (HVAC) system, according to some embodiments.

0025<figref idref="DRAWINGS">FIG. 2A</figref> is a block diagram of a building management system (BMS) which can be used to monitor and control the building and HVAC system of <figref idref="DRAWINGS">FIGS. 1-2</figref>, according to some embodiments.

0026<figref idref="DRAWINGS">FIG. 2B</figref> is a block diagram illustrating a system manager, zone coordinator, and zone controller of the BMS of <figref idref="DRAWINGS">FIG. 2A</figref> in greater detail, according to some embodiments.

0027<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram of an airside system which can be used in the HVAC system of <figref idref="DRAWINGS">FIG. 1</figref>, according to some embodiments.

0028<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram illustrating the system manager of <figref idref="DRAWINGS">FIG. 2B</figref> in greater detail, according to some embodiments.

0029<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram illustrating the zone coordinator of <figref idref="DRAWINGS">FIG. 2B</figref> in greater detail, according to some embodiments.

0030<figref idref="DRAWINGS">FIG. 6</figref> is a flow diagram illustrating a technique which can be used by the BMS of <figref idref="DRAWINGS">FIGS. 2A-2B</figref> to automatically discover and interact with BMS equipment, according to some embodiments.

0031<figref idref="DRAWINGS">FIG. 7</figref> is a flow diagram illustrating a technique which can be used by the BMS of <figref idref="DRAWINGS">FIGS. 2A-2B</figref> to create and use equipment models for system bus devices, according to some embodiments.

0032<figref idref="DRAWINGS">FIG. 8</figref> is a flow diagram illustrating a technique which can be used by the BMS of <figref idref="DRAWINGS">FIGS. 2A-2B</figref> to create and use equipment models for zone bus devices, according to some embodiments.

0033<figref idref="DRAWINGS">FIG. 9</figref> is a block diagram of another BMS including a system manager and a cloud platform, according to some embodiments.

0034<figref idref="DRAWINGS">FIG. 10</figref> is a block diagram illustrating select components of the system manager and cloud platform of <figref idref="DRAWINGS">FIG. 9</figref> in greater detail, according to some embodiments.

0035<figref idref="DRAWINGS">FIG. 11</figref> is a block diagram of a data model which can be used by the system manager of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0036<figref idref="DRAWINGS">FIG. 12</figref> is a block diagram illustrating an example of a reported network tree which can be generated by the system manager of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0037<figref idref="DRAWINGS">FIG. 13</figref> is another block diagram illustrating a portion of the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0038<figref idref="DRAWINGS">FIG. 14</figref> is a block diagram illustrating the cloud platform and data platform of <figref idref="DRAWINGS">FIG. 9</figref> in greater detail, according to some embodiments.

0039<figref idref="DRAWINGS">FIG. 15</figref> is a sequence diagram illustrating a timeseries processing process which can be performed by the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0040<figref idref="DRAWINGS">FIG. 16</figref> is a sequence diagram illustrating an alarm process which can be performed by the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0041<figref idref="DRAWINGS">FIG. 17</figref> is a sequence diagram illustrating a command process which can be performed by the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0042<figref idref="DRAWINGS">FIG. 18</figref> is a block diagram illustrating a schedule synchronization process which can be performed by the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0043<figref idref="DRAWINGS">FIG. 19</figref> is a sequence diagram illustrating a schedule configuration process for equipment schedules in the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0044<figref idref="DRAWINGS">FIG. 20</figref> is a sequence diagram illustrating a schedule configuration process for a sync schedule in the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0045<figref idref="DRAWINGS">FIG. 21</figref> is a flowchart of a process illustrating the life cycle of the system manager of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0046<figref idref="DRAWINGS">FIG. 22</figref> is a sequence diagram illustrating a startup process for the system manager of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0047<figref idref="DRAWINGS">FIGS. 23-24</figref> are user interfaces illustrating a device management portal which can be used by the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0048<figref idref="DRAWINGS">FIGS. 25-26</figref> are block diagrams illustrating a high level process flow performed by the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0049<figref idref="DRAWINGS">FIG. 27</figref> is a sequence diagram illustrating an initial provisioning process which can be performed by the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0050<figref idref="DRAWINGS">FIGS. 28A-28C</figref> are a sequence diagram illustrating a new device initiation process which can be performed by the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0051<figref idref="DRAWINGS">FIG. 29</figref> is a sequence diagram illustrating a timeseries data process which can be performed by the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0052<figref idref="DRAWINGS">FIG. 30</figref> is a sequence diagram illustrating an alarm process which can be performed by the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0053<figref idref="DRAWINGS">FIG. 31</figref> is a sequence diagram illustrating a warranty process which can be performed by the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0054<figref idref="DRAWINGS">FIG. 32</figref> is a sequence diagram illustrating a process for adding new systems/equipment to the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0055<figref idref="DRAWINGS">FIG. 33</figref> is a sequence diagram illustrating a process for changing a setpoint in the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0056<figref idref="DRAWINGS">FIG. 34</figref> is a sequence diagram illustrating a process for requesting information in the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0057<figref idref="DRAWINGS">FIG. 35</figref> is a sequence diagram illustrating a process for updating bound points in the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0058<figref idref="DRAWINGS">FIG. 36</figref> is an example of a user interface for selecting bound points in the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0059<figref idref="DRAWINGS">FIG. 37</figref> is a sequence diagram illustrating a process for updating the software or firmware of the system manager of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0060<figref idref="DRAWINGS">FIG. 38</figref> is a sequence diagram illustrating a process for synchronizing schedules in the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0061<figref idref="DRAWINGS">FIG. 39</figref> is a sequence diagram illustrating a process for updating a device schedule via cloud applications in the BMS of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

0062<figref idref="DRAWINGS">FIG. 40</figref> is a sequence diagram illustrating a process for backing up and restoring the configuration of the system manager of <figref idref="DRAWINGS">FIG. 9</figref>, according to some embodiments.

DETAILED DESCRIPTION

0063Referring generally to the FIGURES, a building management system (BMS) with automatic equipment discovery and equipment model distribution is shown, according to some embodiments. A BMS is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. A BMS can include, for example, a HVAC system, a security system, a lighting system, a fire alerting system, any other system that is capable of managing building functions or devices, or any combination thereof.

0064In brief overview, the BMS described herein provides a system architecture that facilitates automatic equipment discovery and equipment model distribution. Equipment discovery can occur on multiple levels of the BMS across multiple different communications busses (e.g., a system bus, zone buses, a sensor/actuator bus, etc.) and across multiple different communications protocols. In some embodiments, equipment discovery is accomplished using active node tables, which provide status information for devices connected to each communications bus. For example, each communications bus can be monitored for new devices by monitoring the corresponding active node table for new nodes. When a new device is detected, the BMS can begin interacting with the new device (e.g., sending control signals, using data from the device) without user interaction.

0065Some devices in the BMS present themselves to the network using equipment models. An equipment model defines equipment object attributes, view definitions, schedules, trends, and the associated BACnet value objects (e.g., analog value, binary value, multistate value, etc.) that are used for integration with other systems. Some devices in the BMS store their own equipment models. Other devices in the BMS have equipment models stored externally (e.g., within other devices). For example, a zone coordinator can store the equipment model for a bypass damper. In some embodiments, the zone coordinator automatically creates the equipment model for the bypass damper and/or other devices on the zone bus. Other zone coordinators can also create equipment models for devices connected to their zone busses. The equipment model for a device can be created automatically based on the types of data points exposed by the device on the zone bus, device type, and/or other device attributes. Several examples of automatic equipment discovery and equipment model distribution are discussed in greater detail below. Throughout this disclosure, the terms “equipment model,” “equipment model template,” and “equipment template” are used interchangeably.

Building and HVAC System

0066Referring now to <figref idref="DRAWINGS">FIG. 1</figref>, an exemplary building and HVAC system in which the systems and methods of the present invention can be implemented are shown, according to an exemplary embodiment. In <figref idref="DRAWINGS">FIG. 1</figref>, a perspective view of a building <b>10</b> is shown. Building <b>10</b> is served by a HVAC system <b>100</b>. HVAC system <b>100</b> can include a plurality of HVAC devices (e.g., heaters, chillers, air handling units, pumps, fans, thermal energy storage, etc.) configured to provide heating, cooling, ventilation, or other services for building <b>10</b>. For example, HVAC system <b>100</b> is shown to include a waterside system <b>120</b> and an airside system <b>130</b>. Waterside system <b>120</b> can provide a heated or chilled fluid to an air handling unit of airside system <b>130</b>. Airside system <b>130</b> can use the heated or chilled fluid to heat or cool an airflow provided to building <b>10</b>. An exemplary airside system which can be used in HVAC system <b>100</b> are described in greater detail with reference to <figref idref="DRAWINGS">FIG. 3</figref>.

0067HVAC system <b>100</b> is shown to include a chiller <b>102</b>, a boiler <b>104</b>, and a rooftop air handling unit (AHU) <b>106</b>. Waterside system <b>120</b> can use boiler <b>104</b> and chiller <b>102</b> to heat or cool a working fluid (e.g., water, glycol, etc.) and can circulate the working fluid to AHU <b>106</b>. In various embodiments, the HVAC devices of waterside system <b>120</b> can be located in or around building <b>10</b> (as shown in <figref idref="DRAWINGS">FIG. 1</figref>) or at an offsite location such as a central plant (e.g., a chiller plant, a steam plant, a heat plant, etc.). The working fluid can be heated in boiler <b>104</b> or cooled in chiller <b>102</b>, depending on whether heating or cooling is required in building <b>10</b>. Boiler <b>104</b> can add heat to the circulated fluid, for example, by burning a combustible material (e.g., natural gas) or using an electric heating element. Chiller <b>102</b> can place the circulated fluid in a heat exchange relationship with another fluid (e.g., a refrigerant) in a heat exchanger (e.g., an evaporator) to absorb heat from the circulated fluid. The working fluid from chiller <b>102</b> and/or boiler <b>104</b> can be transported to AHU <b>106</b> via piping <b>108</b>.

0068AHU <b>106</b> can place the working fluid in a heat exchange relationship with an airflow passing through AHU <b>106</b> (e.g., via one or more stages of cooling coils and/or heating coils). The airflow can be, for example, outside air, return air from within building <b>10</b>, or a combination of both. AHU <b>106</b> can transfer heat between the airflow and the working fluid to provide heating or cooling for the airflow. For example, AHU <b>106</b> can include one or more fans or blowers configured to pass the airflow over or through a heat exchanger containing the working fluid. The working fluid can then return to chiller <b>102</b> or boiler <b>104</b> via piping <b>110</b>.

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

Building Management System

0070Referring now to <figref idref="DRAWINGS">FIG. 2A</figref>, a block diagram of a building management system (BMS) <b>300</b> is shown, according to an exemplary embodiment. A BMS is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. A BMS can include, for example, a HVAC system, a security system, a lighting system, a fire alerting system, any other system that is capable of managing building functions or devices, or any combination thereof. BMS <b>300</b> can be used to monitor and control the devices of HVAC system <b>100</b> and/or airside system <b>200</b> (e.g., HVAC equipment) as well as other types of BMS devices (e.g., lighting equipment, security equipment, etc.).

0071In brief overview, BMS <b>300</b> provides a system architecture that facilitates automatic equipment discovery and equipment model distribution. Equipment discovery can occur on multiple levels of BMS <b>300</b> across multiple different communications busses (e.g., a system bus <b>354</b>, zone buses <b>356</b>-<b>360</b> and <b>364</b>, sensor/actuator bus <b>366</b>, etc.) and across multiple different communications protocols. In some embodiments, equipment discovery is accomplished using active node tables, which provide status information for devices connected to each communications bus. For example, each communications bus can be monitored for new devices by monitoring the corresponding active node table for new nodes. When a new device is detected, BMS <b>300</b> can begin interacting with the new device (e.g., sending control signals, using data from the device) without user interaction.

0072Some devices in BMS <b>300</b> present themselves to the network using equipment models. An equipment model defines equipment object attributes, view definitions, schedules, trends, and the associated BACnet value objects (e.g., analog value, binary value, multistate value, etc.) that are used for integration with other systems. An equipment model for a device can include a collection of point objects that provide information about the device (e.g., device name, network address, model number, device type, etc.) and store present values of variables or parameters used by the device. For example, the equipment model can include point objects (e.g., standard BACnet point objects) that store the values of input variables accepted by the device (e.g., setpoint, control parameters, etc.), output variables provided by the device (e.g., temperature measurement, feedback signal, etc.), configuration parameters used by the device (e.g., operating mode, actuator stroke length, damper position, tuning parameters, etc.). The point objects in the equipment model can be mapped to variables or parameters stored within the device to expose those variables or parameters to external systems or devices.

0073Some devices in BMS <b>300</b> store their own equipment models. Other devices in BMS <b>300</b> have equipment models stored externally (e.g., within other devices). For example, a zone coordinator <b>308</b> can store the equipment model for a bypass damper <b>328</b>. In some embodiments, zone coordinator <b>308</b> automatically creates the equipment model for bypass damper <b>328</b> or other devices on zone bus <b>358</b>. Other zone coordinators can also create equipment models for devices connected to their zone busses. The equipment model for a device can be created automatically based on the types of data points exposed by the device on the zone bus, device type, and/or other device attributes. Several examples of automatic equipment discovery and equipment model distribution are discussed in greater detail below.

0074Still referring to <figref idref="DRAWINGS">FIG. 2A</figref>, BMS <b>300</b> is shown to include a system manager <b>302</b> (i.e., a smart building hub); several zone coordinators <b>306</b>, <b>308</b>, <b>310</b> and <b>318</b>; and several zone controllers <b>324</b>, <b>330</b>, <b>332</b>, <b>336</b>, <b>348</b>, and <b>350</b>. System manager <b>302</b> can communicate with client devices <b>304</b> (e.g., user devices, desktop computers, laptop computers, mobile devices, etc.) via a data communications link <b>374</b> (e.g., BACnet IP, Ethernet, wired or wireless communications, etc.). System manager <b>302</b> can provide a user interface to client devices <b>304</b> via data communications link <b>374</b>. The user interface may allow users to monitor and/or control BMS <b>300</b> via client devices <b>304</b>.

0075In some embodiments, system manager <b>302</b> is connected with zone coordinators <b>306</b>-<b>310</b> and <b>318</b> via a system bus <b>354</b>. System bus <b>354</b> can include any of a variety of communications hardware (e.g., wire, optical fiber, terminals, etc.) configured to facilitate communications between system manager and other devices connected to system bus <b>354</b>. Throughout this disclosure, the devices connected to system bus <b>354</b> are referred to as system bus devices. System manager <b>302</b> can be configured to communicate with zone coordinators <b>306</b>-<b>310</b> and <b>318</b> via system bus <b>354</b> using a master-slave token passing (MSTP) protocol or any other communications protocol. System bus <b>354</b> can also connect system manager <b>302</b> with other devices such as a constant volume (CV) rooftop unit (RTU) <b>312</b>, an input/output module (IOM) <b>314</b>, a thermostat controller <b>316</b> (e.g., a TEC3000 series thermostat controller), and a network automation engine (NAE) or third-party controller <b>320</b>. RTU <b>312</b> can be configured to communicate directly with system manager <b>302</b> and can be connected directly to system bus <b>354</b>. Other RTUs can communicate with system manager <b>302</b> via an intermediate device. For example, a wired input <b>362</b> can connect a third-party RTU <b>342</b> to thermostat controller <b>316</b>, which connects to system bus <b>354</b>.

0076System manager <b>302</b> can provide a user interface for any device containing an equipment model. Devices such as zone coordinators <b>306</b>-<b>310</b> and <b>318</b> and thermostat controller <b>316</b> can provide their equipment models to system manager <b>302</b> via system bus <b>354</b>. In some embodiments, system manager <b>302</b> automatically creates equipment models for connected devices that do not contain an equipment model (e.g., IOM <b>314</b>, third party controller <b>320</b>, etc.). For example, system manager <b>302</b> can create an equipment model for any device that responds to a device tree request. The equipment models created by system manager <b>302</b> can be stored within system manager <b>302</b>. System manager <b>302</b> can then provide a user interface for devices that do not contain their own equipment models using the equipment models created by system manager <b>302</b>. In some embodiments, system manager <b>302</b> stores a view definition for each type of equipment connected via system bus <b>354</b> and uses the stored view definition to generate a user interface for the equipment.

0077Each zone coordinator <b>306</b>-<b>310</b> and <b>318</b> can be connected with one or more of zone controllers <b>324</b>, <b>330</b>-<b>332</b>, <b>336</b>, and <b>348</b>-<b>350</b> via zone buses <b>356</b>, <b>358</b>, <b>360</b>, and <b>364</b>. Zone busses <b>356</b>, <b>358</b>, <b>360</b>, and <b>364</b> can include any of a variety of communications hardware (e.g., wire, optical fiber, terminals, etc.) configured to facilitate communications between a zone coordinator and other devices connected to the corresponding zone bus. Throughout this disclosure, the devices connected to zone busses <b>356</b>, <b>358</b>, <b>360</b>, and <b>364</b> are referred to as zone bus devices. Zone coordinators <b>306</b>-<b>310</b> and <b>318</b> can communicate with zone controllers <b>324</b>, <b>330</b>-<b>332</b>, <b>336</b>, and <b>348</b>-<b>350</b> via zone busses <b>356</b>-<b>360</b> and <b>364</b> using a MSTP protocol or any other communications protocol. Zone busses <b>356</b>-<b>360</b> and <b>364</b> can also connect zone coordinators <b>306</b>-<b>310</b> and <b>318</b> with other types of devices such as variable air volume (VAV) RTUs <b>322</b> and <b>340</b>, changeover bypass (COBP) RTUs <b>326</b> and <b>352</b>, bypass dampers <b>328</b> and <b>346</b>, and PEAK controllers <b>334</b> and <b>344</b>.

0078Zone coordinators <b>306</b>-<b>310</b> and <b>318</b> can be configured to monitor and command various zoning systems. In some embodiments, each zone coordinator <b>306</b>-<b>310</b> and <b>318</b> monitors and commands a separate zoning system and is connected to the zoning system via a separate zone bus. For example, zone coordinator <b>306</b> can be connected to VAV RTU <b>322</b> and zone controller <b>324</b> via zone bus <b>356</b>. Zone coordinator <b>308</b> can be connected to COBP RTU <b>326</b>, bypass damper <b>328</b>, COBP zone controller <b>330</b>, and VAV zone controller <b>332</b> via zone bus <b>358</b>. Zone coordinator <b>310</b> can be connected to PEAK controller <b>334</b> and VAV zone controller <b>336</b> via zone bus <b>360</b>. Zone coordinator <b>318</b> can be connected to PEAK controller <b>344</b>, bypass damper <b>346</b>, COBP zone controller <b>348</b>, and VAV zone controller <b>350</b> via zone bus <b>364</b>.

0079A single model of zone coordinator <b>306</b>-<b>310</b> and <b>318</b> can be configured to handle multiple different types of zoning systems (e.g., a VAV zoning system, a COBP zoning system, etc.). Each zoning system can include a RTU, one or more zone controllers, and/or a bypass damper. For example, zone coordinators <b>306</b> and <b>310</b> are shown as Verasys VAV engines (VVEs) connected to VAV RTUs <b>322</b> and <b>340</b>, respectively. Zone coordinator <b>306</b> is connected directly to VAV RTU <b>322</b> via zone bus <b>356</b>, whereas zone coordinator <b>310</b> is connected to a third-party VAV RTU <b>340</b> via a wired input <b>368</b> provided to PEAK controller <b>334</b>. Zone coordinators <b>308</b> and <b>318</b> are shown as Verasys COBP engines (VCEs) connected to COBP RTUs <b>326</b> and <b>352</b>, respectively. Zone coordinator <b>308</b> is connected directly to COBP RTU <b>326</b> via zone bus <b>358</b>, whereas zone coordinator <b>318</b> is connected to a third-party COBP RTU <b>352</b> via a wired input <b>370</b> provided to PEAK controller <b>344</b>.

0080Zone controllers <b>324</b>, <b>330</b>-<b>332</b>, <b>336</b>, and <b>348</b>-<b>350</b> can communicate with individual BMS devices (e.g., sensors, actuators, etc.) via sensor/actuator (SA) busses. For example, VAV zone controller <b>336</b> is shown connected to networked sensors <b>338</b> via SA bus <b>366</b>. Networked sensors <b>338</b> can include, for example, temperature sensors, humidity sensors, pressure sensors, lighting sensors, security sensors, or any other type of device configured to measure and/or provide an input to zone controller <b>336</b>. Zone controller <b>336</b> can communicate with networked sensors <b>338</b> using a MSTP protocol or any other communications protocol. Although only one SA bus <b>366</b> is shown in <figref idref="DRAWINGS">FIG. 2A</figref>, it should be understood that each zone controller <b>324</b>, <b>330</b>-<b>332</b>, <b>336</b>, and <b>348</b>-<b>350</b> can be connected to a different SA bus. Each SA bus can connect a zone controller with various sensors (e.g., temperature sensors, humidity sensors, pressure sensors, light sensors, occupancy sensors, etc.), actuators (e.g., damper actuators, valve actuators, etc.) and/or other types of controllable equipment (e.g., chillers, heaters, fans, pumps, etc.).

0081Each zone controller <b>324</b>, <b>330</b>-<b>332</b>, <b>336</b>, and <b>348</b>-<b>350</b> can be configured to monitor and control a different building zone. Zone controllers <b>324</b>, <b>330</b>-<b>332</b>, <b>336</b>, and <b>348</b>-<b>350</b> can use the inputs and outputs provided via their SA busses to monitor and control various building zones. For example, a zone controller <b>336</b> can use a temperature input received from networked sensors <b>338</b> via SA bus <b>366</b> (e.g., a measured temperature of a building zone) as feedback in a temperature control algorithm. Zone controllers <b>324</b>, <b>330</b>-<b>332</b>, <b>336</b>, and <b>348</b>-<b>350</b> can use various types of control algorithms (e.g., state-based algorithms, extremum seeking control (ESC) algorithms, proportional-integral (PI) control algorithms, proportional-integral-derivative (PID) control algorithms, model predictive control (MPC) algorithms, feedback control algorithms, etc.) to control a variable state or condition (e.g., temperature, humidity, airflow, lighting, etc.) in or around building <b>10</b>.

0082Referring now to <figref idref="DRAWINGS">FIG. 2B</figref>, a block diagram illustrating a portion of BMS <b>300</b> in greater detail is shown, according to an exemplary embodiment. BMS <b>300</b> is shown to include system manager <b>302</b>, a zone coordinator <b>402</b>, and a zone controller <b>506</b>. Zone coordinator <b>402</b> can be any of zone coordinators <b>306</b>-<b>310</b> or <b>318</b>. Zone controller <b>506</b> can be any of zone controllers <b>324</b>, <b>330</b>, <b>332</b>, <b>336</b>, <b>348</b>, or <b>350</b>. Zone coordinator <b>402</b> can be connected with system manager via system bus <b>354</b>. For example, system bus <b>354</b> is shown connecting a first system bus datalink <b>412</b> within system manager <b>302</b> with a second system bus datalink <b>514</b> within zone coordinator <b>402</b>. Zone coordinator <b>402</b> can connected with zone controller <b>506</b> via a zone bus <b>430</b>. For example, zone bus <b>430</b> is shown connecting a first zone bus datalink <b>510</b> within zone coordinator <b>402</b> with a second zone bus datalink <b>511</b> within zone controller <b>506</b>. Zone bus <b>430</b> can be any of zone busses <b>356</b>-<b>360</b> or <b>364</b>. Zone controller <b>506</b> is connected with networked sensors <b>338</b> and actuators <b>339</b> via a SA bus <b>366</b>.

0083BMS <b>300</b> can automatically discover new equipment connected to any of system bus <b>354</b>, zone bus <b>430</b>, and SA bus <b>366</b>. Advantageously, the equipment discovery can occur automatically (e.g., without user action) without requiring the equipment to be placed in discovery mode and without sending a discovery command to the equipment. In some embodiments, the automatic equipment discovery is based on active node tables for system bus <b>354</b>, zone bus <b>430</b>, and SA bus <b>366</b>. Each active node table can provide status information for the devices communicating on a particular bus. For example, the active node table <b>414</b> for system bus <b>354</b> can indicate which MSTP devices are participating in the token ring used to exchange information via system bus <b>354</b>. Active node table <b>414</b> can identify the devices communicating on system bus <b>354</b> by MAC address or other device identifier. Devices that do not participate in the token ring (e.g., MSTP slave devices) can be automatically discovered using a net sensor plug and play (described in greater detail below).

0084The active node table for each communications bus can be stored within one or more devices connected to the bus. For example, active node table <b>414</b> can be stored within system manager <b>302</b>. In some embodiments, active node table <b>414</b> is part of a system bus datalink <b>412</b> (e.g., a MSTP datalink) used by system manager <b>302</b> to communicate via system bus <b>354</b>. System manager <b>302</b> can subscribe to changes in value of active node table <b>414</b> and can receive a notification (e.g., from system bus datalink <b>412</b>) when a change in active node table <b>414</b>. In response to a notification that a change in active node table <b>414</b> has occurred, system manager <b>302</b> can read active node table <b>414</b> to detect and identify the devices connected to system bus <b>354</b>.

0085In some embodiments, a device list generator <b>428</b> within system manager <b>302</b> generates a list of the devices connected to system bus <b>354</b> (i.e., a device list) based on active node table <b>414</b> and stores the device list within system manager <b>302</b>. The device list generated by system manager <b>302</b> can include information about each device connected to system bus <b>354</b> (e.g., device type, device model, device ID, MAC address, device attributes, etc.). When a new device is detected on system bus <b>354</b>, system manager <b>302</b> can automatically retrieve the equipment model from the device if the device stores its own equipment model. If the device does not store its own equipment model, system manager <b>302</b> can retrieve a list of point values provided by the device. System manager <b>302</b> can then use the equipment model and/or list of point values to present information about the connected system bus devices to a user.

0086The active node tables for each zone bus can be stored within the zone coordinator connected to the zone bus. For example, the active node table <b>512</b> for zone bus <b>430</b> can be stored within zone coordinator <b>402</b>. In some embodiments, active node table <b>512</b> is part of a zone bus datalink <b>510</b> (e.g., a MSTP datalink) used by the zone coordinator <b>402</b> to communicate via zone bus <b>430</b>. Zone coordinator <b>402</b> can subscribe to changes in value of active node table <b>512</b> and can receive a notification (e.g., from zone bus datalink <b>510</b>) when a change in active node table <b>512</b> occurs. In response to a notification that a change to active node table <b>512</b> has occurred, zone coordinator <b>402</b> can read active node table <b>512</b> to identify the devices connected to zone bus <b>430</b>.

0087In some embodiments, a detector object <b>522</b> of zone coordinator <b>402</b> generates a list of the devices communicating on zone bus <b>430</b> (i.e., a device list) based on active node table <b>512</b> and stores the device list within zone coordinator <b>402</b>. Each zone coordinator in BMS <b>300</b> can generate a list of devices on the connected zone bus. The device list generated by each zone coordinator <b>402</b> can include information about each device connected to zone bus <b>430</b> (e.g., device type, device model, device ID, MAC address, device attributes, etc.). When a new device is detected on zone bus <b>430</b>, the connected zone coordinator <b>402</b> can automatically retrieve the equipment model from the device if the device stores its own equipment model. If the device does not store its own equipment model, the connected zone coordinator <b>402</b> can retrieve a list of point values provided by the device.

0088Zone coordinator <b>402</b> can incorporate the new zone bus device into the zoning logic and can inform system manager <b>302</b> that a new zone bus device has been added. For example, zone coordinator <b>402</b> is shown providing a field device list to system manager <b>302</b>. The field device list can include a list of devices connected to zone bus <b>430</b> and/or SA bus <b>366</b>. System manager <b>302</b> can use the field device list and the list of system bus devices to generate a device tree including all of the devices in BMS <b>300</b>. In some embodiments, zone coordinator <b>402</b> provides an equipment model for a connected zone bus device to system manager <b>302</b>. System manager <b>302</b> can then use the equipment model and/or list of point values for the new zone bus device to present information about the new zone bus device to a user.

0089In some embodiments, the device list generated by each zone coordinator <b>402</b> indicates whether system manager <b>302</b> should communicate directly with the listed zone bus device (e.g., VAV RTU <b>322</b>, VAV zone controller <b>324</b>, etc.) or whether system manager <b>302</b> should communicate with the intermediate zone coordinator <b>402</b> on behalf of the zone bus device. In some embodiments, system manager <b>302</b> communicates directly with zone bus devices that provide their own equipment models, but communicates with the intermediate zone coordinator <b>402</b> for zone bus devices that do not provide their own equipment model. As discussed above, the equipment models for zone bus devices that do not provide their own equipment model can be generated by the connected zone coordinator <b>402</b> and stored within the zone coordinator <b>402</b>. Accordingly, system manager <b>302</b> may communicate directly with the device that stores the equipment model for a connected zone bus device (i.e., the zone bus device itself or the connected zone coordinator <b>402</b>).

0090The active node table <b>544</b> for SA bus <b>366</b> can be stored within zone controller <b>506</b>. In some embodiments, active node table <b>544</b> is part of the SA bus datalink <b>542</b> (e.g., a MSTP datalink) used by zone controller <b>506</b> to communicate via SA bus <b>366</b>. Zone controller <b>506</b> can subscribe to changes in value of the active node table <b>544</b> and can receive a notification (e.g., from SA bus datalink <b>542</b>) when a change in active node table <b>544</b> occurs. In response to a notification that a change to active node table <b>544</b> has occurred, zone controller <b>506</b> can read active node table <b>544</b> to identify some or all of the devices connected to SA bus <b>366</b>. In some embodiments, active node table <b>544</b> identifies only the SA bus devices participating in the token passing ring via SA bus <b>366</b> (e.g., MSTP master devices). Zone controller <b>506</b> can include an additional net sensor plug and play (NsPnP) <b>547</b> configured to detect SA bus devices that do not participate in the token passing ring (e.g., MSTP slave devices).

0091In some embodiments, NsPnP <b>547</b> is configured to actively search for devices connected to SA bus <b>366</b> (e.g., networked sensors <b>338</b>, actuators <b>339</b>, lighting controllers <b>341</b>, etc.). For example, NsPnP <b>547</b> can send a “ping” to a preconfigured list of MSTP slave MAC addresses. For each SA bus device that is discovered (i.e. responds to the ping), NsPnP <b>547</b> can dynamically bring it online. NsPnP <b>547</b> can bring a device online by creating and storing an instance of a SA bus device object representing the discovered SA bus device. NsPnP <b>547</b> can automatically populate the SA bus device object with all child point objects needed to collect and store point data (e.g., sensor data) from the newly-discovered SA bus device. In some embodiments, NsPnP <b>547</b> automatically maps the child point objects of the SA bus device object to attributes of the equipment model for zone controller <b>506</b>. Accordingly, the data points provided by the SA bus devices can be exposed to zone coordinator <b>402</b> and other devices in BMS <b>300</b> as attributes of the equipment model for zone controller <b>506</b>.

0092In some embodiments, a detector object <b>546</b> of zone controller <b>506</b> generates a list of the devices connected to SA bus <b>366</b> (i.e., a device list) based on active node table <b>544</b> and stores the device list within zone controller <b>506</b>. NsPnP <b>547</b> can update the device list to include any SA bus devices discovered by NsPnP <b>547</b>. The device list generated by zone controller <b>506</b> can include information about each device connected to SA bus <b>366</b> (e.g., device type, device model, device ID, MAC address, device attributes, etc.). When a new device is detected on SA bus <b>366</b>, zone controller <b>506</b> can automatically retrieve the equipment model from the device if the device stores its own equipment model. If the device does not store its own equipment model, zone controller <b>506</b> can retrieve a list of point values provided by the device.

0093Zone controller <b>506</b> can incorporate the new SA bus device into the zone control logic and can inform zone coordinator <b>402</b> that a new SA bus device has been added. Zone coordinator <b>402</b> can then inform system manager <b>302</b> that a new SA bus device has been added. For example, zone controller <b>506</b> is shown providing a SA device list to zone coordinator <b>402</b>. The SA device list can include a list of devices connected to SA bus <b>366</b>. Zone coordinator <b>402</b> can use the SA device list and the detected zone bus devices to generate the field device list provided to system manager <b>302</b>. In some embodiments, zone controller <b>506</b> provides an equipment model for a connected SA bus device to zone coordinator <b>402</b>, which can be forwarded to system manager <b>302</b>. System manager <b>302</b> can then use the equipment model and/or list of point values for the new SA bus device to present information about the new SA bus device to a user. In some embodiments, data points provided by the SA bus device are shown as attributes of the zone controller <b>506</b> to which the SA bus device is connected.

Airside System

0094Referring now to <figref idref="DRAWINGS">FIG. 3</figref>, a block diagram of an airside system <b>200</b> is shown, according to an exemplary embodiment. In various embodiments, airside system <b>200</b> can supplement or replace airside system <b>130</b> in HVAC system <b>100</b> or can be implemented separate from HVAC system <b>100</b>. When implemented in HVAC system <b>100</b>, airside system <b>200</b> can include a subset of the HVAC devices in HVAC system <b>100</b> (e.g., AHU <b>106</b>, VAV units <b>116</b>, ducts <b>112</b>-<b>114</b>, fans, dampers, etc.) and can be located in or around building <b>10</b>. In some embodiments, airside system <b>200</b> can be used in BMS <b>300</b> as a VAV rooftop unit <b>322</b> or <b>340</b> and/or as a COBP rooftop unit <b>326</b> or <b>352</b>. Airside system <b>200</b> can operate to heat or cool an airflow provided to building <b>10</b>.

0095Airside system <b>200</b> is shown to include an economizer-type air handling unit (AHU) <b>202</b>. Economizer-type AHUs vary the amount of outside air and return air used by the air handling unit for heating or cooling. For example, AHU <b>202</b> can receive return air <b>204</b> from building zone <b>206</b> via return air duct <b>208</b> and can deliver supply air <b>210</b> to building zone <b>206</b> via supply air duct <b>212</b>. In some embodiments, AHU <b>202</b> is a rooftop unit located on the roof of building <b>10</b> (e.g., AHU <b>106</b> as shown in <figref idref="DRAWINGS">FIG. 1</figref>) or otherwise positioned to receive both return air <b>204</b> and outside air <b>214</b>. AHU <b>202</b> can be configured to operate exhaust air damper <b>216</b>, mixing damper <b>218</b>, and outside air damper <b>220</b> to control an amount of outside air <b>214</b> and return air <b>204</b> that combine to form supply air <b>210</b>. Any return air <b>204</b> that does not pass through mixing damper <b>218</b> can be exhausted from AHU <b>202</b> through exhaust damper <b>216</b> as exhaust air <b>222</b>.

0096Each of dampers <b>216</b>-<b>220</b> can be operated by an actuator. For example, exhaust air damper <b>216</b> can be operated by actuator <b>224</b>, mixing damper <b>218</b> can be operated by actuator <b>226</b>, and outside air damper <b>220</b> can be operated by actuator <b>228</b>. Actuators <b>224</b>-<b>228</b> can communicate with an AHU controller <b>230</b> via a sensor/actuator (SA) bus <b>232</b>. Actuators <b>224</b>-<b>228</b> can receive control signals from AHU controller <b>230</b> and can provide feedback signals to AHU controller <b>230</b>. Feedback signals can include, for example, an indication of a current actuator or damper position, an amount of torque or force exerted by the actuator, diagnostic information (e.g., results of diagnostic tests performed by actuators <b>224</b>-<b>228</b>), status information, commissioning information, configuration settings, calibration data, and/or other types of information or data that can be collected, stored, or used by actuators <b>224</b>-<b>228</b>. AHU controller <b>230</b> can be an economizer controller configured to use one or more control algorithms (e.g., state-based algorithms, extremum seeking control (ESC) algorithms, proportional-integral (PI) control algorithms, proportional-integral-derivative (PID) control algorithms, model predictive control (MPC) algorithms, feedback control algorithms, etc.) to control actuators <b>224</b>-<b>228</b>.

0097Still referring to <figref idref="DRAWINGS">FIG. 3</figref>, AHU <b>202</b> is shown to include a cooling coil <b>234</b>, a heating coil <b>236</b>, and a fan <b>238</b> positioned within supply air duct <b>212</b>. Fan <b>238</b> can be configured to force supply air <b>210</b> through cooling coil <b>234</b> and/or heating coil <b>236</b> and provide supply air <b>210</b> to building zone <b>206</b>. AHU controller <b>230</b> can communicate with fan <b>238</b> via SA bus <b>232</b> to control a flow rate of supply air <b>210</b>. In some embodiments, AHU controller <b>230</b> controls an amount of heating or cooling applied to supply air <b>210</b> by modulating a speed of fan <b>238</b>.

0098Cooling coil <b>234</b> can receive a chilled fluid from waterside system <b>120</b> via piping <b>242</b> and can return the chilled fluid to waterside system <b>120</b> via piping <b>244</b>. Valve <b>246</b> can be positioned along piping <b>242</b> or piping <b>244</b> to control a flow rate of the chilled fluid through cooling coil <b>234</b>. In some embodiments, cooling coil <b>234</b> includes multiple stages of cooling coils that can be independently activated and deactivated (e.g., by AHU controller <b>230</b>) to modulate an amount of cooling applied to supply air <b>210</b>.

0099Heating coil <b>236</b> may receive a heated fluid from waterside system <b>120</b> via piping <b>248</b> and can return the heated fluid to waterside system <b>120</b> via piping <b>250</b>. Valve <b>252</b> can be positioned along piping <b>248</b> or piping <b>250</b> to control a flow rate of the heated fluid through heating coil <b>236</b>. In some embodiments, heating coil <b>236</b> includes multiple stages of heating coils that can be independently activated and deactivated (e.g., by AHU controller <b>230</b>) to modulate an amount of heating applied to supply air <b>210</b>.

0100Each of valves <b>246</b> and <b>252</b> can be controlled by an actuator. For example, valve <b>246</b> can be controlled by actuator <b>254</b> and valve <b>252</b> can be controlled by actuator <b>256</b>. Actuators <b>254</b>-<b>256</b> can communicate with AHU controller <b>230</b> via SA bus <b>232</b>. Actuators <b>254</b>-<b>256</b> can receive control signals from AHU controller <b>230</b> and can provide feedback signals to AHU controller <b>230</b>. In some embodiments, AHU controller <b>230</b> receives a measurement of the supply air temperature from a temperature sensor <b>262</b> positioned in supply air duct <b>212</b> (e.g., downstream of cooling coil <b>234</b> and/or heating coil <b>236</b>).

0101In some embodiments, AHU controller <b>230</b> operates valves <b>246</b> and <b>252</b> via actuators <b>254</b>-<b>256</b> to modulate an amount of heating or cooling provided to supply air <b>210</b> (e.g., to achieve a setpoint temperature for supply air <b>210</b> or to maintain the temperature of supply air <b>210</b> within a setpoint temperature range). The positions of valves <b>246</b> and <b>252</b> affect the amount of heating or cooling provided to supply air <b>210</b> by cooling coil <b>234</b> or heating coil <b>236</b> and may correlate with the amount of energy consumed to achieve a desired supply air temperature. In some embodiments, AHU controller <b>230</b> receives a measurement of the zone temperature from a temperature sensor <b>264</b> positioned within building zone <b>206</b>. AHU controller <b>230</b> can control the temperature of supply air <b>210</b> and/or building zone <b>206</b> by activating or deactivating coils <b>234</b>-<b>236</b>, adjusting a speed of fan <b>238</b>, or a combination of both.

0102Still referring to <figref idref="DRAWINGS">FIG. 3</figref>, AHU controller <b>230</b> can be connected to zone coordinator <b>402</b> via zone bus <b>430</b> (e.g., a MSTP communications bus). Similarly, zone coordinator <b>402</b> can be connected to system manager <b>302</b> via system bus <b>354</b> (e.g., another MSTP communications bus). Zone bus <b>430</b> and system bus <b>354</b> can include any of a variety of communications hardware (e.g., wires, optical fiber, terminals, etc.) and/or communications software configured to facilitate communications between AHU controller <b>230</b>, zone coordinator <b>402</b>, and system manager <b>302</b>. System manager <b>302</b> can communicate with client device <b>304</b> via data communications link <b>374</b> (e.g., BACnet IP, Ethernet, wired or wireless communications, etc.).

0103Client device <b>304</b> can include one or more human-machine interfaces or client interfaces (e.g., graphical user interfaces, reporting interfaces, text-based computer interfaces, client-facing web services, web servers that provide pages to web clients, etc.) for controlling, viewing, or otherwise interacting with HVAC system <b>100</b>, airside system <b>200</b>, BMS <b>300</b>, and/or the various subsystems, and devices thereof. Client device <b>304</b> can be a computer workstation, a client terminal, a remote or local interface, or any other type of user interface device. Client device <b>304</b> can be a stationary terminal or a mobile device. For example, client device <b>304</b> can be a desktop computer, a computer server with a user interface, a laptop computer, a tablet, a smartphone, a PDA, or any other type of mobile or non-mobile device.

System Manager

0104Referring now to <figref idref="DRAWINGS">FIG. 4</figref>, a block diagram illustrating system manager <b>302</b> in greater detail is shown, according to an exemplary embodiment. System manager <b>302</b> is shown to include a system bus datalink <b>412</b>, a communications interface <b>404</b>, and a processing circuit <b>406</b>. System bus datalink <b>412</b> connects to system bus <b>354</b> and can be used by system manager <b>302</b> to communicate with various other devices connected to system bus <b>354</b>. For example, system bus datalink <b>412</b> can be used to communicate with zone coordinator <b>402</b> (i.e., any of zone coordinators <b>306</b>-<b>310</b> and <b>318</b>), CVRTU <b>312</b>, IOM <b>314</b>, and/or thermostat controller <b>316</b>.

0105System bus datalink <b>412</b> is shown to include an active node table <b>414</b>. Active node table <b>414</b> provides status information for the devices connected to system bus <b>354</b>. For example, active node table <b>414</b> can indicate which MSTP devices are participating in the token ring used to exchange information via system bus <b>354</b>. In some embodiments, active node table <b>414</b> is a table in the form of an array of bytes. The location of each byte in active node table <b>414</b> may represent the token ring participation status of a particular node or device connected to system bus <b>354</b>. Devices connected to system bus <b>354</b> can be identified by MAC address (or any other device identifier) in active node table <b>414</b>. Advantageously, active node table <b>414</b> can list the MAC addresses of the devices connected to system bus <b>354</b> without requiring the devices to be placed in discovery mode.

0106In some embodiments, active node table <b>414</b> includes a change counter attribute. Each time a change to active node table <b>414</b> occurs (e.g., a new device begins communicating on system bus <b>354</b>), the change counter attribute can be incremented by system bus datalink <b>412</b>. Other objects or devices interested in the status of active node table <b>414</b> can subscribe to a change of value (COV) of the change counter attribute. When the change counter attribute is incremented, system bus datalink <b>412</b> can report the COV to any object or device that has subscribed to the COV. For example, device list generator <b>428</b> can subscribe to the COV of the change counter attribute and can be automatically notified of the COV when a change to active node table <b>414</b> occurs. In response to receiving the COV notification, device list generator <b>428</b> can read active node table <b>414</b>. Device list generator <b>428</b> can use the information from active node table <b>414</b> to generate a list of devices connected to system bus <b>354</b>. Device list generator <b>428</b> is described in greater detail below.

0107Communications interface <b>404</b> can facilitate communications between system manager <b>302</b> and external systems, devices, or applications. For example, communications interface <b>404</b> can be used by system manager <b>302</b> to communicate with client device <b>304</b> (e.g., a tablet, a laptop computer, a smartphone, a desktop computer, a computer workstation, etc.), monitoring and reporting applications, enterprise control applications, remote systems and applications, and/or other external systems or devices for allowing user control, monitoring, and adjustment to BMS <b>300</b> and/or system manager <b>302</b>.

0108Communications interface <b>404</b> can include wired or wireless communications interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals, etc.) for conducting data communications with client device <b>304</b> or other external systems or devices. In various embodiments, communications conducted via interface <b>404</b> can be direct (e.g., local wired or wireless communications) or via a communications network (e.g., a WAN, the Internet, a cellular network, etc.). For example, communications interface <b>404</b> can include an Ethernet card and port for sending and receiving data via an Ethernet-based communications link or network. In another example, communications interface <b>404</b> can include a WiFi transceiver for communicating via a wireless communications network. In another example, communications interface <b>404</b> can include cellular or mobile phone communications transceivers. In one embodiment, communications interface <b>404</b> is a power line communications interface and/or an Ethernet interface.

0109Processing circuit <b>406</b> is shown to include a processor <b>408</b> and memory <b>410</b>. Processor <b>408</b> can be a general purpose or specific purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable processing components. Processor <b>408</b> is configured to execute computer code or instructions stored in memory <b>410</b> or received from other computer readable media (e.g., CDROM, network storage, a remote server, etc.).

0110Memory <b>410</b> can include one or more devices (e.g., memory units, memory devices, storage devices, etc.) for storing data and/or computer code for completing and/or facilitating the various processes described in the present disclosure. Memory <b>410</b> can include random access memory (RAM), read-only memory (ROM), hard drive storage, temporary storage, non-volatile memory, flash memory, optical memory, or any other suitable memory for storing software objects and/or computer instructions. Memory <b>410</b> can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present disclosure. Memory <b>410</b> can be communicably connected to processor <b>408</b> via processing circuit <b>406</b> and can include computer code for executing (e.g., by processor <b>408</b>) one or more processes described herein. When processor <b>408</b> executes instructions stored in memory <b>410</b>, processor <b>408</b> generally configures system manager <b>302</b> (and more particularly processing circuit <b>406</b>) to complete such activities.

0111Still referring to <figref idref="DRAWINGS">FIG. 4</figref>, system manager <b>302</b> is shown to include a device list generator <b>428</b> and a field device mapper <b>426</b>. Device list generator <b>428</b> can sign up or subscribe to a change in value (COV) of the change counter attribute of active node table <b>414</b>. When a change to active node table <b>414</b> occurs, system bus datalink <b>412</b> can provide a COV notification to device list generator <b>428</b>. In response to receiving the COV notification, device list generator <b>428</b> can read active node table <b>414</b>. Device list generator <b>428</b> can use the information from active node table <b>414</b> to generate a list of devices connected to system bus <b>354</b>. The system bus device list can be stored in device list storage <b>424</b> and/or provided to filed device mapper <b>426</b>.

0112Field device mapper <b>426</b> can sign up or subscribe to a COV of a field device list maintained by zone coordinator <b>402</b>. Field devices can include any device connected to zone bus <b>430</b> (i.e., one of zone busses <b>356</b>-<b>360</b> or <b>364</b>) either directly or via an intermediate device such as a PEAK controller or zone controller. Zone coordinator <b>402</b> can maintain a list of the field devices connected to zone bus <b>430</b> in the same way that system manager <b>302</b> maintains the list of system bus devices connected to system bus <b>354</b>. In some embodiments, the list of field devices maintained by zone coordinator <b>402</b> includes a change counter attribute. When a change to the list of field bus devices occurs, zone coordinator <b>402</b> can provide a COV notification to field device mapper <b>426</b>. In response to receiving the COV notification, field device mapper <b>426</b> can read the list of field devices maintained by zone coordinator <b>402</b> to identify the field devices connected to zone bus <b>430</b>.

0113Field device mapper <b>426</b> can use the list of devices from zone coordinator <b>402</b> to generate a device tree including both the devices connected to system bus <b>354</b> and the field devices connected to zone bus <b>430</b>. The device tree can be a hierarchy of devices in BMS <b>300</b>. For example, the list of system bus devices can be updated to include the list of field devices associated with each zone coordinator hierarchically below the associated zone coordinator in the system bus device list. In this way, the list of devices can be updated to include hierarchical information with system bus devices at a first level of the hierarchy and zone bus devices at a lower level of the hierarchy (e.g., hierarchically below each zone coordinator in the list of system bus devices). In some embodiments, device list storage <b>424</b> includes a device list change counter attribute. The change counter attribute can be incremented each time an update to the stored device lists occurs.

0114Still referring to <figref idref="DRAWINGS">FIG. 4</figref>, system manager <b>302</b> is shown to include a messaging engine <b>420</b>. Messaging engine <b>420</b> can sign up or subscribe to a COV in the device list stored in device list storage <b>424</b>. When a change to the stored device list occurs, device list storage <b>424</b> can provide a COV notification to messaging engine <b>420</b>. In response to receiving the COV notification, messaging engine <b>420</b> can read the device list stored in device list storage <b>424</b> to identify all of the devices connected to system bus <b>354</b>, any of zone busses <b>356</b>-<b>360</b> or <b>364</b>, and/or SA bus <b>366</b>. In some embodiments, messaging engine <b>420</b> translates the list of devices into format which can be presented to a user. For example, messaging engine <b>420</b> can translate the list of devices into a JavaScript object notation, HTML format, or any other format that facilitates presentation to a user. Messaging engine <b>420</b> can provide the updated and translated device list to web server <b>416</b>.

0115In some embodiments, messaging engine <b>420</b> receives a request for a view definition from web server <b>416</b>. The view definition may identify a set of attributes for a particular device that are core to the functionality of the device. Each device or type of device in BMS <b>300</b> may have a different view definition. For example, the view definition for a chiller controller may identify the chiller outlet temperature as an important data point; however, the view definition for a valve controller may not identify such a data point as important to the operation of the valve. In some embodiments, the view definition for a device identifies a subset of the data objects defined by the equipment model for the device. Web server <b>416</b> may use the view definition to dynamically select a subset of the stored data objects for inclusion in a web interface (e.g., a webpage) generated by web server <b>416</b>.

0116In some embodiments, view definitions for all the devices in BMS <b>300</b> are stored in view definition storage <b>422</b> within system manager <b>302</b>. In other embodiments, view definitions can be stored in the devices themselves (e.g., within zone coordinators, VAV zone controllers, RTUs, etc.). In some embodiments, the view definition for a device is a component of the device's equipment model and is provided to system manager <b>302</b> by connected devices along with the equipment models. For example, the devices connected to system bus <b>354</b> and/or zone busses <b>356</b>-<b>360</b> and <b>364</b> can provide their own view definitions to system manager <b>302</b>.

0117If a device does not provide its own view definition, system manager <b>302</b> can create or store view definitions for the device. If the view definition provided by a particular device is different from an existing view definition for the device stored in system manager <b>302</b>, the system manager's view definition may override or supersede the view definition provided by the device. In some embodiments, the view definition for a device includes the device's user name and description. Accordingly, the web interface generated by web server <b>416</b> can include the device's user name and description when the web interface is generated according to the view definition.

0118Still referring to <figref idref="DRAWINGS">FIG. 4</figref>, system manager <b>302</b> is shown to include a web server <b>416</b> and a user interface (UI) client <b>418</b>. Web server <b>416</b> can receive a request for a device list from UI client <b>418</b> and can generate a web interface that includes the requested device list. In some embodiments, web server <b>416</b> uses the updated device list from messaging engine <b>420</b> (i.e., the device tree) to generate the web interface. Web server <b>416</b> can use the view definition for each device in the device list to determine which attributes of the devices to include in the web interface. In some embodiments, web server <b>416</b> generates a home page for each type of equipment based on a home page view definition for the equipment type. The home page view definition can be stored in system manager <b>302</b> (e.g., in view definition storage). Other view definitions can be stored in system manager <b>302</b> or received from the equipment at runtime.

0119The view definition file may identify a subset of the data objects listed in the equipment model (e.g., equipment attributes, data points, etc.). The data objects listed in the view definition may be included in the web interface generated by web server <b>416</b> and provided to client device <b>304</b>. The view definition may group the data objects differently than the equipment model. For example, the view definition may group the data objects in a manner that is intuitive for a user attempting to commission, monitor, or control the device via the web interface. Web server <b>416</b> may use the view definition to dynamically select a subset of the stored data objects for inclusion in the web interface generated by web server <b>416</b>.

0120In some embodiments, web server <b>416</b> is a modified Unison HTTP server. Web server <b>416</b> may include SSL support for secure connections and the ability for CGI scripts to define their own HTTP status codes. Web server <b>416</b> may include support for HTTP authentication (e.g., using a Unison security/login module) as well as support for HTTP 0.9, 1.0, and 1.1. Web server <b>416</b> may support dynamic content via CGI scripts (e.g., written in C or any other scripting language) and may support multiple and simultaneous connections by clients.

0121Web server <b>416</b> may be configured to interface with the other components of system manager <b>302</b> (e.g., natively or via CGI scripts). For example, web server <b>416</b> may be configured to read data objects from messaging engine <b>420</b>, device list storage <b>424</b>, and/or view definition storage <b>422</b> and use the data to generate the web interface provided to client device <b>304</b>. Web server <b>416</b> may be configured to receive data from client device <b>304</b> and write data to the data objects based on the input received from client device <b>304</b>. Web server <b>416</b> may be configured to access the equipment model and/or the view definition to determine which of the data objects to include in the generated web interface. Web server <b>416</b> may dynamically generate the web interface based on the information provided in the equipment model and/or the view definition.

0122In some embodiments, web server <b>416</b> uses Common Gateway Interface (CGI) scripts to perform some or all of the functions described herein. The CGI scripts may be stored within the memory of system manager <b>302</b> and provided to client device <b>304</b> in conjunction with the web interface generated by the web server <b>416</b>. In some embodiments, web server <b>416</b> integrates the CGI scripts with the web interface and provides the integrated web interface (e.g., with embedded CGI scripts) to client device <b>304</b>. A web browser running on client device <b>304</b> may run the CGI scripts to request various types of data from system manager <b>302</b> via web server <b>416</b>.

0123UI client <b>418</b> receives the web interface from web server <b>418</b> and provides the web interface as a user interface to client device <b>304</b>. In some embodiments, the web interface includes the updated list of devices received from messaging engine <b>420</b>. The web interface can include attributes or data points associated with each listed device. For example, the web interface can include analog inputs or outputs, binary inputs or outputs, enumerated value inputs or outputs, multistate inputs or outputs, string inputs or outputs, or any other type of or value associated with a particular device (e.g., device name, measured values, operating mode, etc.).

0124In some embodiments, the web interface is interactive and allows a user to modify or write various object attributes. The modified object attributes can be provided to system manager <b>302</b> via user interface client <b>418</b> and used by system manager <b>302</b> to update attributes in the equipment models for the listed devices. If the equipment models are stored within zone coordinator <b>402</b> or other devices in BMS <b>300</b>, the updated attribute values can be distributed to such devices via system bus <b>354</b> and used to update the equipment models stored in such devices. An example of an interactive web interface that can be generated by web server <b>416</b> based on a stored view definition and/or device list is described in detail in U.S. patent application Ser. No. 15/146,660 titled “HVAC Equipment Providing a Dynamic Web Interface Systems and Methods” and filed May 4, 2016, the entire disclosure of which is incorporated by reference herein.

Zone Coordinator

0125Referring now to <figref idref="DRAWINGS">FIG. 5</figref>, a block diagram illustrating zone coordinator <b>402</b> in greater detail is shown, according to an exemplary embodiment. Zone coordinator <b>402</b> can be any zone coordinator in BMS <b>300</b> (e.g., one of zone coordinators <b>306</b>-<b>310</b> or <b>318</b>). In <figref idref="DRAWINGS">FIG. 5</figref>, zone coordinator <b>402</b> is shown as a Verasys COBP engine (VCE) connected with a COBP zoning system via a zone bus <b>430</b>. The COBP zoning system is shown to include a COBP RTU <b>502</b>, a bypass damper <b>504</b>, and a zone controller <b>506</b>. However, zone coordinator <b>402</b> can also function as a Verasys VAV engine (VVE) if connected with a VVE zoning system via zone bus <b>430</b>. For example, COBP RTU <b>502</b> can be replaced with a VAV RTU and bypass damper <b>504</b> can be removed to allow zone coordinator <b>402</b> to function as a VVE. A single model of zone coordinator <b>402</b> can be configured to handle multiple different types of zoning systems (e.g., a VAV zoning system, a COBP zoning system, etc.).

0126Zone coordinator <b>402</b> is shown to include a system bus datalink <b>514</b>, a zone bus datalink <b>510</b>, and a processing circuit <b>518</b>. System bus datalink <b>514</b> may be the same or similar to system bus datalink <b>412</b>, as described with reference to <figref idref="DRAWINGS">FIG. 4</figref>. For example, system bus datalink <b>514</b> can be used to communicate with system manager <b>302</b>, NAE <b>320</b>, and/or any other system or device connected to system bus <b>354</b> (e.g., CVRTU <b>312</b>, IOM <b>314</b>, thermostat controller <b>316</b>, etc.). System bus datalink <b>514</b> is shown to include an active node table <b>516</b>. Active node table <b>516</b> provides status information for the devices connected to system bus <b>354</b>. For example, active node table <b>516</b> can indicate which MSTP devices are participating in the token ring used to exchange information via system bus <b>354</b>.

0127Similarly, zone bus datalink <b>510</b> can be used to communicate with COBP RTU <b>502</b>, bypass damper <b>504</b>, zone controller <b>506</b>, and/or any other devices connected to zone bus <b>430</b>. Zone bus datalink <b>510</b> is shown to include an active node table <b>512</b>. Active node table <b>512</b> provides status information for the devices connected to zone bus <b>430</b>. For example, active node table <b>512</b> can indicate which MSTP devices are participating in the token ring used to exchange information via zone bus <b>430</b>. In some embodiments, active node table <b>512</b> is a table in the form of an array of bytes. The location of each byte in active node table <b>512</b> may represent the token ring participation status of a particular node or device connected to zone bus <b>430</b>. Devices connected to zone bus <b>430</b> can be identified by MAC address (or any other device identifier) in active node table <b>512</b>. Advantageously, active node table <b>512</b> can list the MAC addresses of the devices connected to zone bus <b>430</b> without requiring the devices to be placed in discovery mode.

0128In some embodiments, active node table <b>512</b> includes a change counter attribute. Each time a change to active node table <b>512</b> occurs (e.g., a new device begins communicating on zone bus <b>430</b>), the change counter attribute can be incremented by zone bus datalink <b>510</b>. Other objects or devices interested in the status of active node table <b>512</b> can subscribe to a change of value (COV) of the change counter attribute. When the change counter attribute is incremented, zone bus datalink <b>510</b> can report the COV to any object or device that has subscribed to the COV. For example, detector object <b>522</b> can subscribe to the COV of the change counter attribute and can be automatically notified of the COV when a change to active node table <b>512</b> occurs. In response to receiving the COV notification, detector object <b>522</b> can read active node table <b>512</b>. Detector object <b>522</b> can use the information from active node table <b>512</b> to generate a list of devices connected to zone bus <b>430</b>. Detector object <b>522</b> is described in greater detail below.

0129Still referring to <figref idref="DRAWINGS">FIG. 5</figref>, processing circuit <b>518</b> is shown to include a processor <b>520</b> and memory <b>508</b>. Processor <b>520</b> can be a general purpose or specific purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable processing components. Processor <b>520</b> is configured to execute computer code or instructions stored in memory <b>508</b> or received from other computer readable media (e.g., CDROM, network storage, a remote server, etc.).

0130Memory <b>508</b> can include one or more devices (e.g., memory units, memory devices, storage devices, etc.) for storing data and/or computer code for completing and/or facilitating the various processes described in the present disclosure. Memory <b>508</b> can include random access memory (RAM), read-only memory (ROM), hard drive storage, temporary storage, non-volatile memory, flash memory, optical memory, or any other suitable memory for storing software objects and/or computer instructions. Memory <b>508</b> can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present disclosure. Memory <b>508</b> can be communicably connected to processor <b>520</b> via processing circuit <b>518</b> and can include computer code for executing (e.g., by processor <b>520</b>) one or more processes described herein. When processor <b>520</b> executes instructions stored in memory <b>508</b>, processor <b>520</b> generally configures zone coordinator <b>402</b> (and more particularly processing circuit <b>518</b>) to complete such activities.

0131Still referring to <figref idref="DRAWINGS">FIG. 5</figref>, zone coordinator <b>402</b> is shown to include a detector object <b>522</b>. Detector object <b>522</b> is configured to detect equipment connected to zone bus <b>430</b>. In some embodiments, detector object <b>522</b> maintains a device list <b>524</b> that system manager <b>302</b> uses to construct a device tree. Detector objet <b>522</b> can generate the device list using information from active node table <b>512</b>. For example, detector object <b>522</b> can sign up or subscribe to a change in value (COV) of the change counter attribute of active node table <b>512</b>. When a change to active node table <b>512</b> occurs, zone bus datalink <b>510</b> can provide a COV notification to detector object <b>522</b>. In response to receiving the COV notification, detector object <b>522</b> can read active node table <b>512</b>. Detector object <b>522</b> can use the information from active node table <b>512</b> to generate a list of devices connected to zone bus <b>430</b>. Zone bus device list <b>524</b> can be stored in zone coordinator <b>402</b>.

0132Zone bus device list <b>524</b> can provide information about each of the devices that are currently connected to zone bus <b>430</b>. In some embodiments, zone bus device list <b>524</b> specifies whether system manager <b>302</b> should talk directly to each connected zone bus device, or whether system manager <b>302</b> should communicate with zone coordinator <b>402</b> to interact with the zone bus device. In some embodiments, zone bus device list <b>524</b> specifies that system manager <b>302</b> should communicate directly with devices that store their own equipment model, but should communicate with zone coordinator <b>402</b> to interact with devices having equipment models stored within zone coordinator <b>402</b>. In some embodiments, zone bus device list <b>524</b> stores detailed information for devices that have equipment models stored within zone coordinator <b>402</b>. For example, zone bus device list <b>524</b> can store a user name, description, MAC address, online/offline status, number of active critical alarms, an equipment view version, a top level equipment model, a view definition, and/or model attributes for one or more connected zone bus devices.

0133Zone bus device list <b>524</b> can specify the network address of each connected zone bus device. In some embodiments, the zone bus device list stores a null network address (e.g., network address=0) for a connected zone bus device if the equipment model for the zone bus device is stored within zone coordinator <b>402</b>. However, if the zone bus device stores its own equipment model, the actual network address of the zone bus device can be provided in zone bus device list <b>524</b>. System manager <b>302</b> can read zone bus device list <b>524</b> and use the network address obtained from zone bus device list <b>524</b> to communicate directly with connected zone bus devices.

0134Detector object <b>522</b> can communicate with connected zoning system devices in response to a determination that a change to active node table <b>512</b> has occurred (e.g., a COV notification from zone bus datalink <b>510</b>). Upon receiving the COV notification from zone bus datalink <b>510</b>, detector object <b>522</b> can read model attributes of the various zoning system devices coordinated by zone coordinator <b>402</b>. Such devices can include zone bus devices connected to zone bus <b>430</b>. For example, detector object <b>522</b> can read model attributes from a wired zone controller <b>506</b>, bypass damper <b>504</b>, COBP RTU <b>502</b>, and/or any other device connected to zone bus <b>430</b>. Detector object <b>522</b> can also read model attributes from other zoning system devices, which can be connected to zone coordinator <b>402</b> via a wired or wireless communications link. For example, detector object <b>522</b> can read model attributes from a Zigbee coordinator device, a wireless zone controller, or any other zoning system device. Detector object <b>522</b> can use the model attributes to populate the information stored in zone bus device list <b>524</b>.

0135In some embodiments, detector object <b>522</b> is configured to provide COV notifications to system manager <b>302</b> when zone bus device list <b>524</b> is updated. For example, system manager <b>302</b> can subscribe to changes in zone bus device list <b>524</b> maintained by detector object <b>522</b>. When zone bus device list <b>524</b> changes, detector object <b>522</b> can notify system manager <b>302</b> of the change. In response to receiving a COV notification from detector object <b>522</b>, system manager <b>302</b> can read zone bus device list <b>524</b> from zone coordinator <b>402</b>. System manager <b>302</b> can then use the updated zone bus device list <b>524</b> to update the master device list stored in system manager <b>302</b> (e.g., in device list storage <b>424</b>).

0136In some embodiments, detector object <b>522</b> compares the updated zone bus device list <b>524</b> with a previous version of zone bus device list <b>524</b> when an update to zone bus device list <b>524</b> occurs. If a MAC address was added to zone bus device list <b>524</b>, detector object <b>522</b> can create or update an equipment object corresponding to the MAC address (e.g., a zone controller equipment object <b>582</b>, a bypass damper equipment object <b>572</b>, etc.). If a MAC address was deleted from zone bus device list <b>524</b>, detector object <b>522</b> can remove the corresponding equipment object or can take no action. If an equipment model has changed for an existing MAC address in zone bus device list <b>524</b>, detector object can delete and re-add the associated equipment object. Detector object <b>522</b> can merge the updates to zone bus device list <b>524</b> into the previous version of zone bus device list <b>524</b> and can update the online/offline status for each zone bus device. In some embodiments, detector object <b>522</b> deletes offline devices in response to receiving a relearn command from system manager <b>302</b>.

0137Still referring to <figref idref="DRAWINGS">FIG. 5</figref>, zone coordinator <b>402</b> is shown to include a zone coordinator equipment model <b>550</b> having a zone coordinator equipment object <b>552</b>. Zone coordinator equipment object <b>552</b> can configure connected zone bus devices. For example, when zone coordinator <b>402</b> receives an update to a time zone parameter or unit set parameter, zone coordinator equipment object <b>552</b> can pass the updated values to each of the zone bus devices. In some embodiments, zone coordinator equipment object <b>552</b> receives an updated value for the RTU type attribute of COBP RTU <b>502</b>. The updated value can be received from a user or read from the model attributes of COBP RTU <b>502</b>. Zone coordinator equipment object <b>552</b> can determine whether the updated RTU type is compatible with zone controller <b>506</b>. If the RTU type is not compatible, zone coordinator equipment object <b>552</b> can remove details from zone controller equipment model <b>580</b> so that minimal details are shown via the web interface. In some embodiments, zone coordinator equipment object <b>552</b> receives a relearn command from system manager <b>302</b> and commands detector object <b>522</b> to delete offline system bus devices in response to receiving the relearn command.

0138Zone coordinator <b>402</b> is shown to include a bypass damper equipment model <b>570</b> and a zone controller equipment model <b>580</b>. Bypass damper equipment model <b>570</b> and zone controller equipment model <b>580</b> represent bypass damper <b>504</b> and zone controller <b>506</b>, respectively. Although only one zone controller equipment model <b>580</b> is shown in <figref idref="DRAWINGS">FIG. 5</figref>, it should be understood that any number of zone controller equipment objects can be included, based on the number of zone controllers connected to zone coordinator <b>402</b> via zone bus <b>430</b>. For example, if two zone controllers are connected to zone bus <b>430</b>, zone coordinator <b>402</b> can include two zone controller equipment models (i.e., one zone controller equipment model for each zone controller).

0139Equipment models <b>570</b> and <b>580</b> can include a set of data points or attributes that define bypass damper <b>504</b> and zone controller <b>506</b>. Zone coordinator <b>402</b> can interact with bypass damper <b>504</b> and zone controller <b>506</b> by reading and writing values to equipment models <b>570</b> and <b>580</b>. In some embodiments, equipment models <b>570</b> and <b>580</b> are created automatically by zone coordinator <b>402</b>. For example, zone controller equipment model <b>580</b> can be created or deleted by detector object <b>522</b> when zone controller <b>506</b> is added or removed from the network.

0140Bypass damper equipment model <b>570</b> is shown to include a damper equipment object <b>572</b>. Similarly, zone controller equipment model <b>580</b> is shown to include a controller equipment object <b>582</b>. Equipment objects <b>572</b> and <b>582</b> can communicate with bypass damper <b>504</b> and zone controller <b>506</b> via zone bus <b>430</b>. For example, damper equipment object <b>572</b> can receive data from bypass damper <b>504</b> and update bypass damper equipment model <b>570</b> with the data values from bypass damper <b>504</b>. Similarly, zone controller equipment object <b>582</b> can receive data from zone controller <b>506</b> and can update zone controller equipment model <b>580</b> with the data values from zone controller <b>506</b>. Equipment objects <b>572</b> and <b>582</b> can also send data to bypass damper <b>504</b> and zone controller <b>506</b> based on the data values stored in equipment models <b>570</b> and <b>580</b>.

0141Equipment objects <b>572</b> and <b>582</b> can create BACnet objects for damper <b>504</b> and zone controller <b>506</b>. For example, equipment objects <b>572</b> and <b>582</b> can create BACnet analog value (AV) objects <b>532</b>, BACnet binary value (BV) objects <b>534</b>, and/or BACnet multistate value (MV) objects <b>536</b> representing various data points defined by equipment models <b>570</b> and <b>580</b>. The BACnet objects <b>532</b>-<b>536</b> created by equipment objects <b>572</b> and <b>582</b> can be stored in BACnet layer <b>530</b> and exposed to system bus devices (e.g., system manager <b>302</b>) via system bus <b>354</b>. System manager <b>302</b> can interact with bypass damper <b>504</b> and zone controller <b>506</b> by reading and writing data values to BACnet objects <b>532</b>-<b>536</b>. Equipment objects <b>572</b> and <b>582</b> can be configured to synchronize BACnet objects <b>532</b>-<b>536</b> with the data values stored in equipment models <b>570</b> and <b>580</b> to bridge communications between system manager <b>302</b> and zone bus devices such as bypass damper <b>504</b> and zone controller <b>506</b>.

0142In some embodiments, zone controller equipment object <b>582</b> can sign up or subscribe to a COV of a SA device list maintained by zone controller <b>506</b>. SA devices can include any device connected to zone controller <b>506</b> via a sensor/actuator (SA) bus (e.g., SA bus <b>366</b>). Zone controller <b>506</b> can maintain a list of the SA devices connected to the SA bus in the same way that zone coordinator <b>402</b> maintains the list of zone bus devices connected to zone bus <b>430</b>. In some embodiments, the list of SA bus devices maintained by zone controller <b>506</b> includes a change counter attribute. When a change to the list of SA bus devices occurs, zone controller <b>506</b> can provide a COV notification to zone controller equipment object <b>582</b>. In response to receiving the COV notification, zone controller equipment object <b>582</b> can read the list of SA bus devices maintained by zone controller <b>506</b> to identify the devices connected to zone controller <b>506</b> via the SA bus.

0143Zone controller equipment object <b>582</b> can use the list of SA bus devices to update zone bus device list <b>524</b>. For example, zone bus device list <b>524</b> can be updated to include the list of SA bus devices associated with each zone controller in the zone bus device list. As described above, system manager <b>302</b> can use the zone bus device list <b>524</b> to update the list of devices in BMS <b>300</b>. In this way, the list of devices can be updated to include hierarchical information with system bus devices at a first level of the hierarchy, zone bus devices at a second level of the hierarchy (e.g., hierarchically below each zone coordinator in the list of system bus devices), and SA bus devices at a third level of the hierarchy (e.g., hierarchically below each zone controller in the list of system bus devices).

0144Still referring to <figref idref="DRAWINGS">FIG. 5</figref>, zone coordinator <b>402</b> is shown to include an RTU object <b>560</b>. RTU object <b>560</b> represents COBP RTU <b>502</b>. In some embodiments, RTU <b>502</b> stores its own equipment model within RTU <b>502</b>. Accordingly, RTU object <b>560</b> may not include an equipment model for RTU <b>502</b>. However, RTU object <b>560</b> can behave like an equipment object. For example, RTU object <b>560</b> can create a set of BACnet objects for RTU <b>502</b>. The set of BACnet objects created by RTU object <b>560</b> can be a subset of the BACnet objects exposed directly by RTU <b>502</b> on zone bus <b>430</b> and can be stored in BACnet layer <b>530</b>. The BACnet objects created by RTU object <b>560</b> provides a local representation of RTU <b>502</b> within zone coordinator <b>402</b>. The BACnet objects created by RTU object <b>560</b> can be exposed to system manager <b>302</b> and other system bus devices via system bus <b>354</b>.

0145In some embodiments, zone coordinator equipment model <b>550</b>, bypass damper equipment model <b>570</b>, and zone controller equipment model <b>580</b> include trend logs <b>554</b>, <b>574</b>, and <b>584</b>. Trend logs <b>554</b>, <b>574</b>, and <b>584</b> can store trend data for various data points associated with zone coordinator equipment object <b>552</b>, bypass damper equipment object <b>572</b>, and zone controller equipment object <b>582</b>. Similarly, RTU object <b>560</b> can cache data from RTU <b>502</b> for use by other objects within zone coordinator <b>402</b>.

0146In some embodiments, zone controller equipment object <b>582</b> and trend logs <b>554</b>, <b>574</b>, and <b>584</b> are created/deleted at runtime and may not be part of the provisioned archive. For example, zone controller equipment object <b>582</b> can be created in response to a determination by detector object <b>522</b> that a new zone controller <b>506</b> is connected to zone bus <b>430</b>. Zone controller equipment object <b>582</b> can be deleted by detector object <b>522</b> is the corresponding zone controller is offline or disconnected when a relearn command is received by the zone coordinator <b>402</b>.

0147In some embodiments, zone controller equipment object <b>582</b> and trend logs <b>554</b>, <b>574</b>, and <b>584</b> are archived at runtime in a separate archive file. Detector object <b>522</b> can initiate the archive process when a zone is added or deleted. In some embodiments, the archive process only archives zone objects and trend log objects. During subsequent startups, this separate archive can be loaded immediately after the provisioned archive is loaded. Persisted values and trend samples from the separate archive can be retrieved and applied during normal operation. In some embodiments, the provisioning manager <b>526</b> does not delete or replace the separate archive during provisioning.

0148Still referring to <figref idref="DRAWINGS">FIG. 5</figref>, zone coordinator <b>402</b> is shown to include logic objects <b>538</b> and a group object <b>540</b>. Group object <b>540</b> can maintain a list of the zones managed by zone coordinator <b>402</b>. In some embodiments, the zone list is automatically updated when zones are added or deleted. For example, zone controller equipment object <b>582</b> can be configured to automatically add a zone to the zone list when zone controller equipment model <b>580</b> is created. In some embodiments, group object <b>540</b> distributes commands or data to the listed zones. For example, group object <b>540</b> can receive an occupancy command or occupancy data (e.g., from logic objects <b>538</b>) and can distribute the occupancy command or occupancy data to the various zone controllers connected to zone bus <b>430</b>.

0149Logic objects <b>538</b> can interact with the collection of zones and the zoning system. Logic objects <b>538</b> can retrieve the zone list from group object <b>540</b> and perform logic on the collection. Each logic object <b>538</b> can have different functionality. For example, logic objects <b>538</b> can be configured to perform zone control (e.g. zoning system balancing, mode selection, shutdown determination, system mode determination, etc.), reset control (e.g., discharge air temperature setpoint reset, duct pressure setpoint reset, etc.), occupancy determination, data processing (e.g., data tagging, outlier detection, etc.), fault detection, or other logic-based functions.

0150In some embodiments, logic objects <b>538</b> are configured to perform weighted voting for the zones listed by group object <b>540</b>. Different building zones can have different conditions (e.g., different air temperatures, different setpoints, etc.) and therefore may require different control actions to be performed. For example, one building zone may require heating, whereas another building zone may require cooling. If multiple building zones are served by a single RTU, zone coordinator <b>402</b> can determine whether the RTU should operate in a heating mode (e.g., providing warm air) or a cooling mode (e.g., providing chilled air) to serve the connected building zones. Zone coordinator <b>402</b> can determine which control action to provide based on votes provided by each zone controller.

0151Each zone's vote can have an associated weight (e.g., from zero to three) that reflects the zone's importance. For example if a zone has a weight of three, it can vote three times, whereas a zone with a weight of one can only vote one time. A weight of zero may indicate that the zone does not vote. Zone controller equipment model <b>580</b> can include the weight associated with the zone controlled by zone controller <b>506</b>. Other zone controller equipment models stored within zone coordinator <b>402</b> can include weights for other zones managed by zone coordinator <b>402</b> (e.g., if multiple zone controllers are connected to zone bus <b>430</b>). A user can modify the zone weights through system manager <b>302</b>. Zone coordinator <b>402</b> can use the weights and the votes provided by each zone controller to determine how to best operate the RTU that serves the building zones.

Automatic Equipment Discovery and Equipment Model Distribution

0152Referring now to <figref idref="DRAWINGS">FIG. 6</figref>, a flowchart of a process <b>600</b> for automatically discovering and interacting with equipment in a building management system is shown, according to an exemplary embodiment. Process <b>600</b> can be performed by one or more components of BMS <b>300</b>. In some embodiments, process <b>600</b> is be performed by system manager <b>302</b> and/or zone coordinator <b>402</b> as described with reference to <figref idref="DRAWINGS">FIGS. 3-5</figref>. Process <b>600</b> can be used to automatically discover devices communicating on system bus <b>354</b>, any of zone busses <b>356</b>-<b>360</b> and <b>364</b>, and/or SA bus <b>366</b>. Once the devices have been discovered, process <b>600</b> can be used to generate a user interface (e.g., a web interface) which provides information about the devices and allows a user to monitor and control the devices.

0153Process <b>600</b> is shown to include monitoring an active node table for new nodes (step <b>602</b>). In some embodiments, step <b>602</b> is performed by system manager <b>302</b>. For example, system manager <b>302</b> can monitor active node table <b>414</b> for new nodes. Each node in active node table <b>414</b> can represent a device communicating on system bus <b>354</b>. In some embodiments, system manager <b>302</b> monitors active node table <b>414</b> for new nodes by subscribing to a change of value (COV) of a change counter attribute for active node table <b>414</b>. Each time a change to active node table <b>414</b> occurs (e.g., a new device begins communicating on system bus <b>354</b>), the change counter attribute can be incremented by system bus datalink <b>412</b>. When the change counter attribute is incremented, system bus datalink <b>412</b> can report the COV to device list generator <b>428</b>.

0154In some embodiments, step <b>602</b> is performed by zone coordinator <b>402</b>. For example, zone coordinator <b>402</b> can monitor active node table <b>512</b> for new nodes. Each node in active node table <b>512</b> can represent a device communicating on zone bus <b>430</b>. In some embodiments, zone coordinator <b>402</b> monitors active node table <b>512</b> for new nodes by subscribing to COV of a change counter attribute for active node table <b>512</b>. Each time a change to active node table <b>512</b> occurs (e.g., a new device begins communicating on zone bus <b>430</b>), the change counter attribute can be incremented by zone bus datalink <b>510</b>. When the change counter attribute is incremented, zone bus datalink <b>510</b> can report the COV to detector object <b>522</b>.

0155In some embodiments, step <b>602</b> is performed by a zone controller (e.g., zone controller <b>506</b>). For example, zone controller <b>506</b> can monitor an active node table within a SA bus datalink for new nodes. The SA bus datalink can be used by zone controller <b>506</b> to communicate on a SA bus (e.g., SA bus <b>366</b>). Each node in the active node table for the SA bus datalink can represent a device communicating on the SA bus. In some embodiments, zone controller <b>506</b> monitors the active node table for new nodes by subscribing to COV of a change counter attribute for the active node table. Each time a change to the active node table occurs (e.g., a new device begins communicating on the SA bus), the change counter attribute can be incremented by the SA bus datalink. When the change counter attribute is incremented, the SA bus datalink can report the COV to zone controller <b>506</b>.

0156In some embodiments, system manager <b>302</b> monitors the active node table <b>414</b> within system bus datalink <b>412</b> for new nodes. However, system manager <b>302</b> can also monitor the active node table <b>512</b> within zone bus datalink <b>510</b> and/or the active node table within the SA bus datalink for new nodes. For example, zone bus datalink <b>510</b> can send COV notifications to system manager <b>302</b> when a change to active node table <b>512</b> occurs. Similarly, zone controller <b>506</b> can send COV notifications to system manager <b>302</b> when a change to the active node table for the SA bus occurs. In this way, system manager <b>302</b> can monitor not only the active node table <b>414</b> within system bus datalink <b>412</b>, but also the active node tables within zone bus datalink <b>510</b> and the SA bus datalink.

0157Still referring to <figref idref="DRAWINGS">FIG. 6</figref>, process <b>600</b> is shown to include determining whether a new node is detected (step <b>604</b>). In some embodiments, step <b>604</b> is performed by system manager <b>302</b>. For example, device list generator <b>428</b> can read active node table <b>414</b> in response to receiving a COV notification indicating that active node table <b>414</b> has been updated. Device list generator <b>428</b> can compare the data from active node table <b>414</b> to a previous (e.g., cached) version of active node table <b>414</b> to determine whether any new nodes have been added. If a new node has been added to active node table <b>414</b>, device list generator <b>428</b> can determine that a new node is detected (i.e., the result of step <b>604</b> is “yes”) and process <b>600</b> can proceed to step <b>606</b>. If a new node has not been added, process <b>600</b> can return to step <b>602</b>.

0158In some embodiments, step <b>604</b> is performed by zone coordinator <b>402</b>. For example, detector object <b>522</b> can read active node table <b>512</b> in response to receiving a COV notification indicating that active node table <b>512</b> has been updated. Detector object <b>522</b> can compare the data from active node table <b>512</b> to a previous (e.g., cached) version of active node table <b>512</b> to determine whether any new nodes have been added. If a new node has been added to active node table <b>512</b>, detector object <b>522</b> can determine that a new node is detected (i.e., the result of step <b>604</b> is “yes”) and process <b>600</b> can proceed to step <b>606</b>. If a new node has not been added, process <b>600</b> can return to step <b>602</b>.

0159In some embodiments, step <b>604</b> is performed by zone controller <b>506</b>. For example, zone controller <b>506</b> can read the active node table for the SA bus in response to receiving a COV notification indicating that the active node table for the SA bus has been updated. Zone controller <b>506</b> can compare the data from the active node table to a previous (e.g., cached) version of the active node table to determine whether any new nodes have been added. If a new node has been added to the active node table for the SA bus, zone controller <b>506</b> can determine that a new node is detected (i.e., the result of step <b>604</b> is “yes”) and process <b>600</b> can proceed to step <b>606</b>. If a new node has not been added, process <b>600</b> can return to step <b>602</b>.

0160Still referring to <figref idref="DRAWINGS">FIG. 6</figref>, process <b>600</b> is shown to include using information from the active node table to identify the new device (step <b>606</b>). In some embodiments, step <b>606</b> is performed by system manager <b>302</b>. For example, device list generator <b>428</b> can use address information (e.g., MAC addresses, network addresses, etc.) from active node table <b>414</b> to send a request for information to a new system bus device. The request can include a request for an equipment model stored within the new system bus device and/or a request for point values provided by the new system bus device (e.g., a get device tree request). In response to the request, the new system bus device may provide information that can be used to identify the device (e.g., device type, model number, types of data points, etc.). System manager <b>302</b> can identify the new system bus device based on such information.

0161In some embodiments, step <b>606</b> is performed by zone coordinator <b>402</b>. For example, detector object <b>522</b> can use address information (e.g., MAC addresses, network addresses, etc.) from active node table <b>512</b> to send a request for information to a new zone bus device. The request can include a request for an equipment model stored within the new zone bus device and/or a request for point values provided by the new zone bus device (e.g., a get device tree request). In response to the request, the new zone bus device may provide information that can be used to identify the device (e.g., device type, model number, types of data points, etc.). Zone coordinator <b>402</b> can identify the new zone bus device based on such information.

0162In some embodiments, step <b>606</b> is performed by zone controller <b>506</b>. For example, zone controller <b>506</b> can use address information (e.g., MAC addresses, network addresses, etc.) from the active node table for the SA bus to send a request for information to a new SA bus device. The request can include a request for an equipment model stored within the new SA bus device and/or a request for point values provided by the new SA bus device (e.g., a get device tree request). In response to the request, the new SA bus device may provide information that can be used to identify the device (e.g., device type, model number, types of data points, etc.). Zone controller <b>506</b> can identify the new SA bus device based on such information.

0163Still referring to <figref idref="DRAWINGS">FIG. 6</figref>, process <b>600</b> is shown to include generating a list of devices communicating on the system bus (step <b>608</b>) and generating a list of devices communicating on each zone bus (step <b>610</b>). Step <b>608</b> can be performed by device list generator <b>428</b> using information obtained from active node table <b>414</b> and/or information received from identified system bus devices. Similarly, step <b>610</b> can be performed by each zone coordinator <b>402</b> using information obtained from active node table <b>512</b> and/or information received from identified zone bus devices. In some embodiments, step <b>610</b> includes providing the lists of zone bus devices from each zone coordinator <b>402</b> to system manager <b>302</b>.

0164Process <b>600</b> is shown to include generating a device identifying devices communicating on the system bus and devices communicating on each zone bus (step <b>612</b>). In some embodiments, step <b>612</b> is performed by system manager <b>302</b>. For example, system manager <b>302</b> can use the lists of zone bus devices from each zone coordinator <b>402</b> to construct the device tree. The device tree can be a hierarchy of devices in BMS <b>300</b>. For example, the list of system bus devices can be updated to include the list of field devices associated with each zone coordinator hierarchically below the associated zone coordinator in the system bus device list. In this way, the combined list of devices (i.e., the device tree) can include hierarchical information with system bus devices at a first level of the hierarchy and zone bus devices at a lower level of the hierarchy (e.g., hierarchically below the corresponding zone coordinator in the list of system bus devices).

0165Process <b>600</b> is shown to include providing a user interface including the device tree (step <b>614</b>). In some embodiments, step <b>614</b> is performed by web server <b>416</b> and/or user interface client <b>418</b> of system manager <b>302</b>. For example, web server <b>416</b> can use the device tree generated in step <b>612</b> to build a web interface. In some embodiments, web server <b>416</b> uses a view definition for each device in the device list to determine which attributes of the devices to include in the web interface. In some embodiments, web server <b>416</b> generates a home page for each type of equipment based on a home page view definition for the equipment type. The home page view definition can be stored in system manager <b>302</b> (e.g., in view definition storage). Other view definitions can be stored in system manager <b>302</b> or received from other devices at runtime.

0166Process <b>600</b> is shown to include interacting with the system bus devices and the zone bus devices via the user interface (step <b>616</b>). Step <b>616</b> can include accessing the equipment models for the system bus devices and the zone bus devices to obtain data values for display in the user interface. In some embodiments, step <b>616</b> includes receiving input from a user via the user interface. The user input can change an attribute of a device (e.g., device name, setpoint, device type, etc.) presented in the user interface. System manager <b>302</b> can use the updated value of the device attribute to update the value in the equipment model for the device and/or to provide a control signal to the device. In some embodiments, step <b>616</b> includes providing the updated value to zone coordinator <b>402</b> and/or zone controller <b>506</b> (e.g., if the equipment model for the device is stored in zone coordinator <b>402</b> or zone controller <b>506</b>).

0167Referring now to <figref idref="DRAWINGS">FIG. 7</figref>, a flowchart of a process <b>700</b> for automatically creating and using equipment models for system bus devices is shown, according to an exemplary embodiment. Process <b>700</b> can be performed by one or more components of system manager <b>302</b>, as described with reference to <figref idref="DRAWINGS">FIGS. 3-4</figref>. In some embodiments, process <b>700</b> is performed by system manager <b>302</b> when a new system device is detected.

0168Process <b>700</b> is shown to include identifying a new device communicating on the system bus (step <b>702</b>). Step <b>702</b> can be the same or similar to step <b>606</b> of process <b>600</b>. For example, step <b>702</b> can include using address information (e.g., MAC addresses, network addresses, etc.) from active node table <b>414</b> to send a request for information to a new system bus device. The request can include a request for an equipment model stored within the new system bus device and/or a request for point values provided by the new system bus device (e.g., a get device tree request). In response to the request, the new system bus device may provide information that can be used to identify the device (e.g., device type, model number, types of data points, etc.). System manager <b>302</b> can identify the new system bus device based on such information.

0169Process <b>700</b> is shown to include determining whether the new system bus device includes an equipment model (step <b>704</b>). Some devices in BMS <b>300</b> present themselves to system manager <b>302</b> using equipment models. An equipment model can define equipment object attributes, view definitions, schedules, trends, and the associated BACnet value objects (e.g., analog value, binary value, multistate value, etc.) that are used for integration with other systems. Some system bus devices store their own equipment models (e.g., zone coordinators <b>306</b>-<b>310</b> and <b>318</b>, CVRTU <b>312</b>, thermostat controller <b>316</b>). Other devices in BMS <b>300</b> do not store their own equipment models (e.g., IOM <b>314</b>, third party controller <b>320</b>, etc.). Step <b>704</b> can include sending a request for an equipment model to the new system bus device or reading a list of point values provided by the new system bus device. If the new system bus device includes an equipment model, the system bus device may present an equipment model to system manager <b>302</b> in response to the request.

0170If the system bus device includes an equipment model (i.e., the result of step <b>704</b> is “yes”), system manager <b>302</b> can read the equipment model from the system bus device (step <b>706</b>). Since the equipment model is already stored within the system bus device, the equipment model can be retained within the system bus device (step <b>708</b>). However, if the system bus device does not include an equipment model (i.e., the result of step <b>704</b> is “no”), system manager <b>302</b> can automatically generate a new equipment model for the system bus device (step <b>710</b>). In some embodiments, system manager <b>302</b> retrieves a list of point values provided by the device and uses the list of point values to create a new equipment model for the device. The new equipment model can be stored within system manager <b>302</b> (step <b>712</b>).

0171Process <b>700</b> is shown to include interacting with the system bus device via the equipment model (step <b>714</b>). Step <b>714</b> can include reading data values from the equipment model and writing data values to the equipment model. If the equipment model is stored in the system bus device, step <b>714</b> can include interacting directly with the system bus device. However, if the equipment model is stored in system manager <b>302</b>, step <b>714</b> can include interacting with system manager <b>302</b>. System manager <b>302</b> can then interact with the system bus device. System manager <b>302</b> can provide a user interface for any system bus device using the equipment models stored within the system bus devices and/or the equipment models created by system manager <b>302</b>. In some embodiments, system manager <b>302</b> stores a view definition for each type of equipment connected via system bus <b>354</b> and uses the stored view definition to generate a user interface for the equipment.

0172Referring now to <figref idref="DRAWINGS">FIG. 8</figref>, a flowchart of a process <b>800</b> for automatically creating and using equipment models for zone bus devices is shown, according to an exemplary embodiment. Process <b>800</b> can be performed by one or more components of zone coordinator <b>402</b>, as described with reference to <figref idref="DRAWINGS">FIGS. 3-5</figref>. In some embodiments, process <b>800</b> is performed by zone coordinator <b>402</b> when a new zone bus device is detected.

0173Process <b>800</b> is shown to include identifying a new device communicating on the zone bus (step <b>802</b>). Step <b>802</b> can be the same or similar to step <b>606</b> of process <b>600</b>. For example, step <b>802</b> can include using address information (e.g., MAC addresses, network addresses, etc.) from active node table <b>512</b> to send a request for information to a new zone bus device. The request can include a request for an equipment model stored within the new zone bus device and/or a request for point values provided by the new zone bus device (e.g., a get device tree request). In response to the request, the new zone bus device may provide information that can be used to identify the device (e.g., device type, model number, types of data points, etc.). Zone coordinator <b>402</b> can identify the new zone bus device based on such information.

0174Process <b>800</b> is shown to include determining whether the new zone bus device includes an equipment model (step <b>804</b>). Some devices in BMS <b>300</b> present themselves to zone coordinator <b>402</b> using equipment models. An equipment model can define equipment object attributes, view definitions, schedules, trends, and the associated BACnet value objects (e.g., analog value, binary value, multistate value, etc.) that are used for integration with other systems. Some zone bus devices store their own equipment models (e.g., supported RTUs). Other zone bus devices do not store their own equipment models (e.g., bypass damper <b>504</b>, zone controller <b>506</b>). Step <b>804</b> can include sending a request for an equipment model to the new zone bus device or reading a list of point values provided by the new zone bus device. If the new zone bus device includes an equipment model, the zone bus device may present an equipment model to zone coordinator <b>402</b> in response to the request.

0175If the zone bus device includes an equipment model (i.e., the result of step <b>804</b> is “yes”), zone coordinator <b>402</b> can read the equipment model from the zone bus device (step <b>806</b>). Since the equipment model is already stored within the zone bus device, the equipment model can be retained within the zone bus device (step <b>808</b>). However, if the zone bus device does not include an equipment model (i.e., the result of step <b>804</b> is “no”), zone coordinator <b>402</b> can automatically generate a new equipment model for the zone bus device (step <b>810</b>). In some embodiments, zone coordinator <b>402</b> retrieves a list of point values provided by the device and uses the list of point values to create a new equipment model for the device. The new equipment model can be stored within zone coordinator <b>402</b> (step <b>812</b>).

0176Process <b>800</b> is shown to include interacting with the zone bus device via the equipment model (step <b>814</b>). Step <b>814</b> can include reading data values from the equipment model and writing data values to the equipment model. If the equipment model is stored in the zone bus device, step <b>814</b> can include interacting directly with the zone bus device. For example, system manager <b>302</b> can communicate directly with a zone bus device that stores its own equipment model. However, if the equipment model is stored in zone coordinator <b>402</b>, step <b>814</b> can include interacting with zone coordinator <b>402</b>. Zone coordinator <b>402</b> can then interact with the zone bus device.

0000Building Management System with Cloud-Based Monitoring and Control

0177Referring now to <figref idref="DRAWINGS">FIG. 9</figref>, a block diagram of another building management system (BMS) <b>900</b> is shown, according to an exemplary embodiment. BMS <b>900</b> may include some or all of the features of BMS <b>300</b>, as described with reference to <figref idref="DRAWINGS">FIGS. 2A-8</figref>. For example, BMS <b>900</b> is shown to include system manager <b>302</b> (i.e., a smart building hub), a zone coordinator <b>912</b>, and a zone controller <b>920</b>. System manager <b>302</b> can communicate with client devices <b>304</b> (e.g., user devices, desktop computers, laptop computers, mobile devices, etc.) via a data communications link <b>928</b> (e.g., BACnet IP, Ethernet, wired or wireless communications, etc.). System manager <b>302</b> can provide a user interface to client devices <b>304</b> via data communications link <b>928</b>. The user interface may allow users to monitor and/or control BMS <b>900</b> via client devices <b>304</b>.

0178In some embodiments, system manager <b>302</b> is connected with zone coordinator <b>912</b> via a system bus <b>926</b>. System bus <b>926</b> can include any of a variety of communications hardware (e.g., wire, optical fiber, terminals, etc.) configured to facilitate communications between system manager <b>302</b> and other devices connected to system bus <b>926</b>. Throughout this disclosure, the devices connected to system bus <b>926</b> are referred to as system bus devices. System manager <b>302</b> can be configured to communicate with zone coordinator <b>912</b> via system bus <b>926</b> using a master-slave token passing (MSTP) protocol or any other communications protocol. System bus <b>926</b> can also connect system manager <b>302</b> with other devices such as an input/output module (TOM) <b>902</b>, a thermostat controller <b>904</b> (e.g., a TEC3000 series thermostat controller), a constant volume (CV) rooftop unit (RTU) <b>906</b>, a field and equipment controller (FAC) <b>908</b>, a terminal unit controller <b>910</b>, a generic IO controller <b>914</b>, and a PEAK controller <b>916</b>. RTU <b>906</b> can be configured to communicate directly with system manager <b>302</b> and can be connected directly to system bus <b>926</b>. Other RTUs can communicate with system manager <b>302</b> via an intermediate device. For example, a zone bus <b>918</b> can connect RTU <b>924</b> to zone coordinator <b>912</b>, which connects to system bus <b>926</b>.

0179Zone coordinator <b>912</b> can be connected with zone controller <b>920</b> via zone bus <b>918</b>. Zone bus <b>918</b> can include any of a variety of communications hardware (e.g., wire, optical fiber, terminals, etc.) configured to facilitate communications between a zone coordinator and other devices connected to the corresponding zone bus. Throughout this disclosure, the devices connected to zone bus <b>918</b> are referred to as zone bus devices. Zone coordinator <b>912</b> can communicate with zone controller <b>920</b> via zone bus <b>918</b> using a MSTP protocol or any other communications protocol. Zone bus <b>918</b> can also connect zone coordinator <b>912</b> with other types of devices such a bypass damper <b>922</b> and a rooftop unit <b>924</b>. Zone coordinator <b>912</b> can include some or all of the features or functionality of the zone coordinators previously described with reference to <figref idref="DRAWINGS">FIGS. 2A-8</figref> (e.g., zone coordinators <b>306</b>-<b>310</b>, <b>318</b>, and <b>402</b>).

0180Still referring to <figref idref="DRAWINGS">FIG. 9</figref>, system manager <b>302</b> can be configured to communicate with a cloud platform <b>901</b> via an Internet communications link <b>932</b>. As previously described, system manager <b>302</b> can be configured to automatically discover equipment in BMS <b>900</b> and automatically generate or obtain equipment models for the discovered equipment. System manager <b>302</b> can include various features (e.g., interlock, schedule sync, etc.) that use hard-coded references to known equipment models. System manager <b>302</b> can also be configured to gather more data from the equipment (e.g., equipment model templates), and to use the equipment model templates to drive features of system manager <b>302</b> features (instead of hard-coding references). These enhancements provide support for PEAK controllers with varying applications and other new equipment (e.g., a refrigeration controller). System manager <b>302</b> can be configured to send equipment data to cloud platform <b>901</b> for use by cloud applications.

0181Cloud platform <b>901</b> can include a variety of cloud-based services and/or applications configured to store, process, analyze, or otherwise consume the data collected from system manager <b>302</b>. Cloud platform <b>901</b> may be accessed by various users (e.g., enterprise users, mechanical contractors, cloud application users, etc.). Some users can access and interact with system manager <b>302</b> directly via client devices <b>304</b> (e.g., via a UI provided by system manager <b>302</b>), whereas other users can interact with cloud platform <b>901</b> (e.g., via a UI provided by cloud platform <b>901</b>). The features of cloud platform <b>901</b> and system manager <b>302</b> are described in greater detail below.

Infrastructure Components

0182Referring now to <figref idref="DRAWINGS">FIG. 10</figref>, a block diagram illustrating select components of system manager <b>302</b> and cloud platform <b>901</b> in greater detail is shown, according to an exemplary embodiment. System manager <b>302</b> is shown to include a data collector <b>1004</b>, a capability provider <b>1006</b>, a cloud connector <b>1008</b>, a cloud client <b>1010</b>, a UI server <b>1012</b>, several databases (e.g., audit log <b>1014</b>, template database <b>1016</b>, view definition database <b>1018</b>, and user database <b>1020</b>), and operating system (OS) settings <b>1022</b>. In some embodiments, these components of system manager <b>302</b> are components of processing circuit <b>406</b>, as described with reference to <figref idref="DRAWINGS">FIG. 4</figref>. For example, databases <b>1014</b>-<b>1020</b> and OS settings <b>1022</b> can be stored in memory <b>410</b>. Similarly, data collector <b>1004</b>, capability provider <b>1006</b>, cloud connector <b>1008</b>, cloud client <b>1010</b>, and UI server <b>1012</b> can be functional modules stored in memory <b>410</b> and executable by processor <b>408</b> to accomplish the functions of each module.

0183Data collector <b>1004</b> can be configured to perform the equipment detection and data gathering operations described with reference to <figref idref="DRAWINGS">FIGS. 2A-8</figref>. For example, data collector <b>1004</b> can be configured to identify equipment <b>1002</b> in BMS <b>900</b> and generate or obtain equipment models for equipment <b>1002</b>. Data collector <b>1004</b> can also discover data points provided by equipment <b>1002</b> and obtain values for the data points from equipment <b>1002</b>. Data collector <b>1004</b> can provide the collected data to capability provider <b>1006</b> for use in presenting the data to a user (e.g., via UI server <b>1012</b>) or pushing the data to cloud platform <b>901</b> (e.g., via cloud connector <b>1008</b> and cloud client <b>1010</b>).

0184Capability provider <b>1006</b> can be configured to function as a feature server for system manager <b>302</b>. Capability provider <b>1006</b> can be connected to data collector <b>1004</b>, cloud connector <b>1008</b>, and UI server <b>1012</b> and can process the inputs and outputs of system manager <b>302</b> (e.g., both device- and user-oriented). Capability provider <b>1006</b> can interact with cloud platform <b>901</b> to serve various features of cloud platform <b>901</b> to system manager <b>302</b>. Features of cloud platform <b>901</b> served by capability provider <b>1006</b> can include, for example, time series, alarms, schedules, write property, data model, system settings, and software update. Other features of cloud platform <b>901</b> served by capability provider <b>1006</b> may include interlock, data share, audit, and fault detection and diagnostics (FDD). The features and functionality of cloud platform <b>901</b> are described in greater detail below.

0185Cloud connector <b>1008</b> can be configured to interact with both capability provider <b>1006</b> and cloud client <b>1010</b>. Cloud connector <b>1008</b> can translate system manager concepts (e.g., Verasys concepts) into cloud concepts to allow system manager <b>302</b> to communicate with cloud platform <b>901</b>. Cloud connector <b>1008</b> can also translate cloud concepts into system manager concepts to allow data from cloud platform <b>901</b> to be received and processed by system manager <b>302</b>.

0186Cloud client <b>1010</b> can be configured to interact with cloud platform <b>901</b>. In some embodiments, cloud client <b>1010</b> includes a library that encapsulates an internet-of-things (IoT) hub SDK with a data platform wrapper. Cloud client <b>1010</b> can be configured to understand the endpoints, APIs, and other services provided by data platform <b>1030</b> and can be configured to communicate with data platform <b>1030</b>. In some embodiments, cloud client <b>1010</b> is configured to exchange messages with data platform <b>1030</b> using the native messaging format of data platform <b>1030</b> (e.g., JSON).

Data Model

0187Referring now to <figref idref="DRAWINGS">FIG. 11</figref>, a block diagram of a data model <b>1100</b> which can be used by system manager <b>302</b> is shown, according to an exemplary embodiment. Data model <b>1100</b> can be used by various components of system manager <b>302</b> to report data to cloud platform <b>901</b>. Data model <b>1100</b> defines the relationships between various entities in BMS <b>900</b>. For example, data model <b>1100</b> may define a customer <b>1102</b> (e.g., ABC Corporation), a site <b>1104</b> (e.g., Milwaukee Facility), a space <b>1106</b> (e.g. Conference Room A), a network <b>1108</b> (e.g., system bus), a device <b>1110</b> (e.g., UCB, SC-Equip), equipment <b>1112</b> (e.g., RTU, zone coordinator, zone controller, thermostat controller), an alarm list <b>1114</b>, a template <b>1116</b>, a property <b>1118</b> (e.g., an attribute or data point), a trend log <b>1120</b> for the property <b>1118</b>, and a schedule <b>1122</b> for the property <b>1118</b>.

0188Each customer <b>1102</b> may be associated with one or more sites <b>1104</b>. This is denoted in data model <b>1100</b> by the “1” and “*” symbols on the connection between customer <b>1102</b> and site <b>1104</b>. The “1” symbol denotes a single customer <b>1102</b> and the “*” symbol denotes one or more sites <b>1104</b>. Similarly, each site <b>1104</b> can be associated with one or more networks <b>1108</b>, and each network <b>1108</b> can be associated with one or more device <b>1110</b>. Each device <b>1110</b> can be associated with zero or more equipment <b>1112</b>, as denoted by the symbols “1” and “0 . . . *” on the connection between device <b>1110</b> and equipment <b>1112</b>. Similarly, each equipment <b>1112</b> can be associated with zero or more alarm lists <b>1114</b>. Each equipment <b>1112</b> can also be associated with one or more properties <b>1118</b> (e.g., data points or attributes) and a template <b>1116</b> for that equipment. Template <b>1116</b> may define a list of all the possible properties <b>1118</b> for the given equipment <b>1112</b>. Each property <b>1118</b> can be associated with a trend log <b>1120</b> and a schedule <b>1122</b> for that property <b>1118</b>.

0189In some embodiments, data model <b>1100</b> identifies data using a URL that includes a fully qualified reference (FQR) and an attribute ID (e.g., URL=FQR:AttrID). In some embodiments, the attribute ID is only needed when property <b>1118</b> needs to be specified. For example, system manager <b>302</b> may report or use only the FQR portion of the URL when reporting alarms to cloud platform <b>901</b> since each alarm <b>1114</b> is associated with equipment <b>1112</b> in general and not a specific property <b>1118</b> of that equipment <b>1112</b>. However, system manager <b>302</b> may use both the FQR and the attribute ID when reporting timeseries data values to cloud platform <b>901</b> since each timeseries is fully defined by both a FQR and the property <b>1118</b> (e.g., data point) being reported.

Reported Network Tree and Equipment Model Templates

0190Referring now to <figref idref="DRAWINGS">FIG. 12</figref>, a block diagram illustrating an example of a reported network tree <b>1200</b> is shown, according to an exemplary embodiment. System manager <b>302</b> can be configured to generate and report a network tree to cloud platform <b>901</b>. Reported network tree <b>1200</b> may list all of the equipment <b>1002</b> connected with system manager <b>302</b> either directly (e.g., via system bus <b>926</b>) or indirectly (e.g., via zone coordinator <b>912</b> and zone bus <b>918</b>). Reported network tree <b>1200</b> may also list the device that contains each of piece of equipment <b>1002</b>. For example, a chiller device may contain a compressor, a fan, multiple sensors, and/or other items of equipment <b>1002</b>. Reported network tree <b>1200</b> is shown to include an office zoning system <b>1206</b>, a conference room zoning system <b>1208</b>, a gym <b>1210</b>, a lobby <b>1212</b>, and a showcase <b>1214</b>. Each of devices <b>1206</b>-<b>1214</b> may contain one or more pieces of equipment <b>1002</b>, which may be identified by reported network tree <b>1200</b>.

0191In some embodiments, system manager <b>302</b> reports network tree <b>1200</b> to cloud platform <b>901</b> in the form of a data object. An example of a data object representing a reported network tree is as follows:

0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Reported Network Tree {</entry></row><row><entry> Schedules { [ Schedule (Name, FQR ID, Schedule Config Ref) ] }</entry></row><row><entry> Networks {</entry></row><row><entry>  [ Network (FQR ID),</entry></row><row><entry>   [ Device (Name, FQR ID, Model),</entry></row><row><entry>    [ Equipment / Control System (Name, FQR ID, Template,</entry></row><row><entry>    Alarm Time Series ID),</entry></row><row><entry>     [ Schedule (FQR ID, Schedule Config Ref ]</entry></row><row><entry>    ] ] ] }</entry></row><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> where the schedule configuration can reference an equipment specific schedule (e.g., office schedule <b>1202</b>) or a global schedule (e.g., common area schedule <b>1204</b>). A detailed example of a reported network tree is provided in Appendix A.

0192System manager <b>302</b> may report network tree <b>1200</b> to cloud platform <b>901</b> along with a set of equipment model templates <b>1116</b> for the equipment <b>1002</b> identified in the reported network tree <b>1200</b>. Each equipment model template <b>1116</b> may define a set of properties <b>1118</b> associated with a given piece of equipment <b>1002</b>. An example of a equipment model template is provided in Appendix C. Accordingly, the full list of points under system manager <b>302</b> can be derived from the combination of the reported network tree and the equipment model templates <b>1116</b>. In some embodiments, properties <b>1118</b> are not included in reported network tree <b>1200</b>. Instead, properties <b>1118</b> are defined by the template <b>1116</b> for each piece of equipment <b>1112</b> identified in the reported network tree <b>1200</b>.

Cloud Platform

0193Referring again to <figref idref="DRAWINGS">FIG. 10</figref>, cloud platform <b>901</b> is shown to include a dictionary service <b>1024</b>, a data adaptor <b>1026</b>, cloud applications <b>1028</b>, and a data platform <b>1030</b>. Dictionary service <b>1024</b> can be configured to store or retrieve dictionary data that defines various strings and values used by system manager <b>302</b> and/or cloud platform <b>901</b>. For example, dictionary service <b>1024</b> can be configured to lookup text strings that correspond to enumerated values. Enumerated values can be included in status messages received from system manager <b>302</b> and may be specified as a combination of an enumerated set and an enumerated value. Dictionary service <b>1024</b> can use the set and value combination to retrieve a string message that corresponds to the set and value combination.

0194Data adaptor <b>1026</b> can be configured to receive and translate the incoming data messages provided by system manager <b>302</b>. In some embodiments, data adaptor <b>1026</b> performs various data transformations and other functions specific to system manager <b>302</b>. For example, data adaptor <b>1026</b> can be configured to create entities for data platform <b>1030</b> based on the reported network tree and equipment model templates provided by system manager <b>302</b>. Data adaptor <b>1026</b> can provide plug &amp; play functionality for data platform <b>1030</b> by automatically determining which values need timeseries data. Data adaptor <b>1026</b> can automatically update the “shadow” for system manager <b>302</b> (described in greater detail below) to request values for these timeseries data. Data adaptor <b>1026</b> can translate between FQRs and entity identifiers. In some embodiments, data adaptor <b>1026</b> uses dictionary service <b>1024</b> to translate enumerated values into text strings.

0195Data adaptor <b>1026</b> can store the reported network tree sent by system manager <b>302</b>. In some embodiments, data adaptor <b>1026</b> uses the reported network tree and equipment model templates provided by system manager <b>302</b> to extract system information, points, and create a device-system-point hierarchy. Data adaptor <b>1026</b> can store such data in cloud platform <b>901</b>. Data adaptor <b>1026</b> can create reported points and get bound points for the connected systems and can update bound points in the device's shadow. Data adaptor <b>1026</b> can generate a point ID, system ID, timeseries ID, point FQR mapping for points, and system FQR mapping for systems and can store such data within cloud platform <b>901</b>. Data adaptor <b>1026</b> can extract schedule information and create/update device-system-point-schedule information. Data adaptor <b>1026</b> can extract and store a system ID to alarm timeseries ID mapping.

0196In some embodiments, data adaptor <b>1026</b> is configured to store equipment model files received from system manager <b>302</b>. If an equipment model for a new device is not found, data adaptor <b>1026</b> can request the equipment model from system manager <b>302</b> and store the received equipment model file. In some embodiments, data adaptor <b>1026</b> can manage the schedule configuration file per device in cloud platform <b>901</b>. Data adaptor <b>1026</b> can store a backup file for system manager <b>302</b> so that system manager <b>302</b> can download the latest backup and restore in the event of data loss.

0197Cloud applications <b>1028</b> may include any of a variety of applications configured to use the data provided to cloud platform <b>901</b> by system manager <b>302</b>. For example, cloud applications <b>1028</b> can include an energy management application, monitoring and reporting applications, an enterprise control application, or other cloud-based applications. In some embodiments, cloud applications <b>1028</b> exist as a separate layer of cloud platform <b>901</b> (i.e., separate from data platform <b>1030</b>). This allows cloud applications <b>1028</b> to be isolated from the details of how the data from system manager <b>302</b> are collected. In other embodiments, cloud applications <b>1028</b> can exist as remote applications that run on remote systems or devices.

0198Cloud applications <b>1028</b> can use the data provided by system manager <b>302</b> to perform a variety data visualization, monitoring, and/or control activities. For example, cloud applications <b>1028</b> can include an energy management application and/or a monitoring and reporting application configured to generate user interfaces (e.g., charts, graphs, etc.) that present the data to a user. In some embodiments, the user interfaces present timeseries data at a variety of different levels of granularity (e.g., hourly, weekly, monthly, etc.) in a single chart or graph. For example, a dropdown selector can be provided to allow a user to select a particular level of granularity for a particular timeseries. Several examples of user interfaces that can be generated based on timeseries data are described in U.S. patent application Ser. No. 15/182,579 filed Jun. 14, 2016, and U.S. Provisional Patent Application No. 62/446,284 filed Jan. 13, 2017. The entire disclosures of both these patent applications are incorporated by reference herein.

0199In some embodiments, cloud applications <b>1028</b> include an enterprise control application configured to use the data provided by system manager <b>302</b> to perform various control activities. For example, the enterprise control application can use timeseries data as input to a control algorithm (e.g., a state-based algorithm, an extremum seeking control (ESC) algorithm, a proportional-integral (PI) control algorithm, a proportional-integral-derivative (PID) control algorithm, a model predictive control (MPC) algorithm, a feedback control algorithm, etc.) to generate control signals for system manager <b>302</b>. In some embodiments, system manager <b>302</b> uses the control signals to operate building equipment <b>1002</b>. Operating the building equipment can affect the measured or calculated values of the data samples provided by system manager <b>302</b>. Accordingly, the enterprise control application can use the timeseries data as feedback to control the equipment of BMS <b>900</b>.

0200Data platform <b>1030</b> can include a variety of services (e.g., APIs) configured to process, store, analyze, and perform other operations on the data provided by system manager <b>302</b>. For example, data platform <b>1030</b> can include an identity management service, a security service, a timeseries service, an analytics service, a command and control service, a time synchronization service, an asset service, an entity service and/or other types of data platform services. Several examples of a data platform which can be used as data platform <b>1030</b> are described in detail in U.S. Provisional Patent Application No. 62/564,247 filed Sep. 27, 2017, U.S. Provisional Patent Application No. 62/457,654 filed Feb. 10, 2017, U.S. patent application Ser. No. 15/644,519 filed Jul. 7, 2017, U.S. patent application Ser. No. 15/644,560 filed Jul. 7, 2017, and U.S. patent application Ser. No. 15/644,581 filed Jul. 7, 2017. The entire disclosure of each of these patent applications is incorporated by reference herein.

0201Referring now to <figref idref="DRAWINGS">FIG. 13</figref>, another block diagram illustrating BMS <b>900</b> is shown, according to an exemplary embodiment. As shown in <figref idref="DRAWINGS">FIG. 13</figref>, cloud platform <b>901</b> can communicate with multiple instances of system manager <b>302</b>, each of which is installed at a different building site. For example, cloud platform <b>901</b> is shown receiving data from a system manager <b>302</b><i>a </i>installed at building site A, system manager <b>302</b><i>b </i>installed at building site B, system manager <b>302</b><i>c </i>installed at building site C, and system manager <b>302</b><i>d </i>installed at building site D. Each of system managers <b>302</b><i>a</i>-<i>d </i>may be an instance of system manager <b>302</b>. In some embodiments, system manager <b>302</b> exchanges data with cloud platform <b>901</b> in a JSON format, whereas communications between cloud platform <b>901</b> and client devices <b>304</b> may use the HTTP(s) protocol. In some embodiments, cloud platform <b>901</b> includes a proxy <b>1301</b> which relays communications between system manager <b>302</b> and data platform <b>1030</b>.

Data Platform

0202Referring now to <figref idref="DRAWINGS">FIG. 14</figref>, a block diagram illustrating cloud platform <b>901</b> and data platform <b>1030</b> in greater detail is shown, according to an exemplary embodiment. In some embodiments, cloud platform <b>901</b> is implemented using the Microsoft Azure Cloud. Cloud platform <b>901</b> is shown to include an event hub <b>1302</b>, web jobs <b>1303</b>, an Internet-of-Things (IoT) hub <b>1304</b>, a document database <b>1306</b>, a Verasys database <b>1308</b>, data platform <b>1030</b>, and cloud applications <b>1028</b>.

0203IoT hub <b>1304</b> can be configured to collect data from data platform <b>1030</b> and store the collected data in document database <b>1306</b>. In some embodiments, IoT hub <b>1304</b> is a fully managed service that enables reliable and secure bidirectional communications between millions of IoT devices and a solution backend. IoT hub <b>1304</b> may provide reliable device-to-cloud and cloud-to-device messaging at scale. IoT hub <b>1304</b> may enable secure communications using per-device security credentials and access control. In some embodiments, IoT hub <b>1304</b> provides extensive monitoring for device connectivity and device identity management events. IoT hub <b>1304</b> may include device libraries for the most popular languages and platforms.

0204Web jobs <b>1303</b> can run programs or scripts in aa web-based application on demand, continuously, or on a schedule. Event hub <b>1302</b> may include an event processing service that provides event and telemetry ingress to cloud platform <b>901</b> at massive scale, with low latency and high reliability. Document database <b>1306</b> may include a NoSQL document database service designed from to natively support JSON directly inside the database engine.

0205System manager <b>302</b> can interact with cloud applications <b>1028</b> via data platform <b>1030</b>. As described above, data platform <b>1030</b> may include a collection of services (e.g., platform APIs) which collect and serve up building objects and time series data. For example, data platform <b>1030</b> is shown to include an identity management service <b>1310</b>, a security service <b>1312</b>, a time synchronization service <b>1314</b>, a timeseries service <b>1316</b>, and a command service <b>1318</b>. In addition to the services shown in <figref idref="DRAWINGS">FIG. 14</figref>, data platform <b>1030</b> can include any of a variety of services configured to process, store, analyze, and perform other operations on the data provided by system manager <b>302</b>. For example, data platform <b>1030</b> can include an asset service, an entity service, an analytics service, and/or other types of data platform services.

0206Identity service <b>1310</b> can be configured to restrict web services to authorized users and applications. In some embodiments, identity service <b>1310</b> implements the Open ID Connect protocol, which is an identity layer on top of the OAuth 2.0 protocol. Identity service <b>1310</b> can be configured to execute a variety of “Get” commands, “Post” commands, “Update” commands, “Post” commands, and other operations on stored data. For example, identity service <b>1310</b> can retrieve one or more users, groups, device associations for a group, or users associated with a group. Identity service <b>1310</b> can update user information, update group information, add users to a group, remove users from a group, and/or create a new group. Identity service <b>1310</b> can post a get user token and/or a get API token.

0207Security service <b>1312</b> can be configured to manage users, roles, groups, devices, and relationships between a variety of sub-services or sub-APIs. The sub-services or sub-APIs managed by security service <b>1312</b> may include an application API, a device API, a group API, an identity API, a role API, and/or a user API. The application API can be configured to perform operations based on a client_id token claim (e.g., managing application updates). The device API can be configured to interact with devices in IoT hub <b>1304</b> and/or document database <b>1306</b>. The group API can be configured to interact with groups of users or devices. The identity API can be configured to perform operations based on a sub-token claim (e.g., getting a user's devices). The role API can be configured to interact with user roles. The user API can be configured to interact with users.

0208Time synchronization service <b>1314</b> can be configured to provide system manager <b>302</b> with the latest time in UTC format. When a device connects to time synchronization service <b>1314</b>, time synchronization service <b>1314</b> may return the current UTC time in ISO 8901 format. In some embodiments, no access tokens are necessary to get the time from time synchronization service <b>1314</b>.

0209Timeseries service <b>1316</b> can be configured to perform a variety of timeseries processing operations. In some embodiments, timeseries service <b>1316</b> is configured to perform some or all of the timeseries processing operations described in U.S. patent application Ser. No. 15/644,519 filed Jul. 7, 2017, U.S. patent application Ser. No. 15/644,560 filed Jul. 7, 2017, and U.S. patent application Ser. No. 15/644,581 filed Jul. 7, 2017. The entire disclosure of each of these patent applications is incorporated by reference herein.

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

0211In some embodiments, timeseries service <b>1316</b> calculates virtual points based on the raw timeseries data and/or the derived timeseries data. Virtual points can be calculated by applying any of a variety of mathematical operations (e.g., addition, subtraction, multiplication, division, etc.) or functions (e.g., average value, maximum value, minimum value, thermodynamic functions, linear functions, nonlinear functions, etc.) to the actual data points represented by the timeseries data. For example, timeseries service <b>1316</b> can calculate a virtual data point (pointID₃) by adding two or more actual data points (pointID₁and pointID₂) (e.g., pointID₃=pointID₁+pointID₂). As another example, timeseries service <b>1316</b> can calculate an enthalpy data point (pointID₄) based on a measured temperature data point (pointID₅) and a measured pressure data point (pointID₆) (e.g., pointID₄=pointID₅+pointID₆). The virtual data points can be stored as derived timeseries data.

0212Command service <b>1318</b> can be configured to perform a variety of command and control operations. In some embodiments, command service <b>1318</b> is configured to send commands and control signals to system manager <b>302</b>. The commands and control signals can then be used by system manager <b>302</b> to control equipment <b>1002</b> of BMS <b>900</b>. In some embodiments, command service <b>1318</b> sends command messages as strings, gets response messages as strings, and stores the responses.

0213In some embodiments, command service <b>1318</b> allows a user to command and control the equipment <b>1002</b> of BMS <b>900</b> by writing data values to system manager <b>302</b>. It should be noted that a local user of system manager <b>302</b> can command and control BMS <b>900</b> via a local user interface generated by system manager <b>302</b>. However, remote users (e.g., technical support, a store manager, an enterprise user, etc.) and cloud applications <b>1028</b> can command and control BMS <b>900</b> via an enterprise UI via command service <b>1318</b>. Command service <b>1318</b> can be configured to change any data values including setpoints, configuration parameters, schedules, and other types of data used by system manager <b>302</b> and/or equipment <b>1002</b>. For example, cloud applications <b>1028</b> can use command service <b>1318</b> to change the value of any property that is defined as writable in the equipment's equipment model template.

0214In some embodiments, data platform <b>1030</b> includes an asset service. The asset service can be configured to store equipment (i.e., asset) information for various systems and devices in BMS <b>900</b>. Information stored by the asset service may include, for example, an asset ID (i.e., a unique ID for the asset), an entity ID (e.g., a system ID to map to source system), a serial number of the asset, an asset name (e.g., Chiller 1, Chiller 2, Heat Pump 1, Heat Pump 2, etc.), an asset description, an asset type (e.g., HVAC Chiller, VAV box, etc.), an asset category (e.g., vapor compression chiller, electric chiller, etc.), an asset make or manufacturer, an asset model ID, an asset model name, an asset source system ID, an asset status (e.g., active or inactive), a customer ID, an asset installed date, an asset manufacture date, and/or other types of information describing equipment in BMS <b>900</b>. In some embodiments, the asset service stores warranty information for various assets. A single asset can have different warranties from different warranty providers. Warranty information stored by the asset service may include a warranty ID, a warranty company, a warranty type, a warranty start date, a warranty expiration date, a warranty status, a contact name, and/or a contact phone number.

0215In some embodiments, data platform <b>1030</b> includes an entity service. The entity service can be configured to assign entity information to various timeseries or data points to associate the timeseries or data points with a particular system, device, or space. The entity service can be configured to traverse an entity tree or diagram (e.g., data model <b>1100</b>) to identify relationships between various types of entities. Entities can include, for example, devices, systems, spaces, assets, schedules, warranties, users, groups of users, buildings, or other representations of equipment, spaces, or users.

0216In some embodiments, data platform <b>1030</b> includes a weather service. The weather service can be configured to communicate with external weather providers (e.g., Aeris Weather, Open Weather Map, etc.) to obtain and store weather data as timeseries. In some embodiments, the weather service runs to collect current weather-related data from a service provider and store it in timeseries service <b>1316</b> so that weather data can be queried like any other timeseries data. The weather service can retrieve historical weather data, current weather data, and/or forecast weather data.

0217In some embodiments, data platform <b>1030</b> is configured to generate and maintain a “shadow” for each system manager <b>302</b> that sends data to data platform <b>1030</b>. The shadow may be similar to an IoT hub's device twin and may function as a virtual service-side representation of a physical system manager <b>302</b>. For example, the shadow for a given system manager <b>302</b> may be a data object (e.g., a JSON object) that contains attributes indicating the state of system manager <b>302</b>. An example of a shadow for a system manager <b>302</b> is as follows:

0000<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row><row><entry /><entry>  “Reported”: [ ],</entry></row><row><entry /><entry>  “Bound”: [ ],</entry></row><row><entry /><entry>  “Revision”: “1”,</entry></row><row><entry /><entry>  “Hash”: “abc”</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0218System manager <b>302</b> can be configured to fill in the “Reported” field of the shadow with information describing system manager <b>302</b> (e.g., BAS units, time zone, etc.). It should be noted that the “Reported” field is different from the reported network tree, which is a separate file. An example of the information which can be specified in the “Reported” field is as follows:

0000<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>“SBH Settings”: {</entry></row><row><entry /><entry>“BAS Units Setting”: “IP”,</entry></row><row><entry /><entry>“Time Zone Setting”: “Central”</entry></row><row><entry /><entry>“Heartbeat Time Series ID”: “HB-TS”</entry></row><row><entry /><entry> “Software Version”: 3.0</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0219The “Bound” field of the shadow can be filled in by a cloud application <b>1028</b> to indicate the properties for which the cloud application <b>1028</b> wants timeseries data. The “Bound” field can include the following information:

0220Bound: {[FQR ID, Time Series ID]}

0221Organization ID

0000where the organization ID is used by cloud applications <b>1028</b> to identify the customer associated with system manager <b>302</b>. An example of a bound list is provided in Appendix B. If certain points in the “Bound: field are not physically present, the system manager <b>302</b> can send the “Non-Existent” points list data adaptor <b>1026</b>, which can delete the non-existent points from the shadow.

0222The “Revision” field of the shadow may be incremented each time the shadow is modified by either cloud application <b>1028</b> or by system manager <b>302</b>. Both system manager <b>302</b> and cloud application <b>1028</b> can update the “Revision” field of the shadow each time a change is made. Both system manager <b>302</b> and cloud application <b>1028</b> can also synchronize with the shadow to ensure that each has the most recent version of the information provided by the shadow. For example, system manager <b>302</b> and cloud application <b>1028</b> can periodically read the shadow and copy the information contained in the shadow if the version of the shadow is more recent than the local version of the information.

0223In some embodiments, data platform <b>1030</b> is configured to maintain a manifest for each instance of system manager <b>302</b> that sends data to data platform <b>1030</b>. The manifest may indicate the most recent available version of software for system manager <b>302</b>, the installed version of software for system manager <b>302</b>, a retrieval URL for the most recent version of software for system manager <b>302</b>, and a list of endpoint URLs that define the location of data platform <b>1030</b>. The endpoint URLs may be helpful in the event that system manager <b>302</b> is deployed in a country that requires data to be kept within the country for legal reasons. Accordingly, the URL may be different for each country. If the endpoint URL is left empty, system manager <b>302</b> may not send data to data platform <b>1030</b>. In some embodiments, the manifest also include licensing information for cloud applications <b>1028</b> associated with system manager <b>302</b>.

0224Data platform <b>1030</b> may use a variety of endpoints for communicating with services <b>1310</b>-<b>1318</b> and other components of cloud platform <b>901</b>. Each endpoint may function as a virtual IP address for system manager <b>302</b> to communicate with services <b>1310</b>-<b>1318</b>. For example, data platform <b>1030</b> may use a timeseries endpoint for system manager <b>302</b> to communicate with timeseries service <b>1316</b>. Similarly, data platform <b>1030</b> may use a security endpoint for system manager <b>302</b> to communicate with security service <b>1312</b>, an entity endpoint for system manager <b>302</b> to communicate with an entity service, and an IMS endpoint for system manager <b>302</b> to communicate with identity service <b>1310</b>.

Timeseries Process

0225Referring now to <figref idref="DRAWINGS">FIG. 15</figref>, a sequence diagram illustrating a timeseries processing process <b>1500</b> is shown, according to an exemplary embodiment. Process <b>1500</b> can be performed by one or more components of BMS <b>900</b> to collect and send timeseries data to cloud platform <b>901</b>. For example, process <b>1500</b> can be performed by equipment <b>1002</b>, system manager <b>302</b>, and/or various components of cloud platform <b>901</b> (e.g., security service <b>1312</b>, timeseries service <b>1316</b>, data adaptor <b>1026</b>, etc.).

0226Process <b>1500</b> is shown to include system manager <b>302</b> discovering equipment <b>1002</b> (step <b>1502</b>) and posting a reported network tree to data adaptor <b>1026</b> (step <b>1504</b>). The reported network tree may identify all of the equipment <b>1002</b> connected with system manager <b>302</b>, either directly or indirectly. Data adaptor <b>1026</b> can use the reported network tree in combination with equipment model templates for the identified equipment <b>1002</b> to determine which properties (i.e., data points, attributes, etc.) of equipment to bind (step <b>1506</b>). Data adaptor <b>1026</b> can then create timeseries for the identified properties with timeseries service <b>1316</b> (step <b>1508</b>) and update the shadow bound list with security service <b>1312</b> (step <b>1510</b>). The timeseries may initially be empty, but can be updated as data samples are collected from system manager <b>302</b> and/or equipment <b>1002</b>. In some embodiments, data adaptor <b>1026</b> updates the shadow bound list to identify all of the properties that data adaptor <b>1026</b> is interested in receiving change-of-value (COV) updates from system manager <b>302</b> and/or equipment <b>1002</b>.

0227Security service <b>1312</b> can converge with system manager <b>302</b> (step <b>1512</b>) and system manager <b>302</b> can get the shadow from security service <b>1312</b> (step <b>1514</b>). System manager <b>302</b> can evaluate the shadow bound list (step <b>1516</b>) to identify one or more properties specified by the shadow. System manager <b>302</b> can then subscribe to COV updates for any properties specified by the shadow (step <b>1518</b>) and unsubscribe from COB updates for any properties not specified by the shadow (step <b>1520</b>). When a COV for a subscribed property occurs, equipment <b>1002</b> can send a COV notification to system manager <b>302</b> (step <b>1522</b>). The COV notification may identify the property for which a COV has occurred and may include the current value of the property.

0228In some embodiments, equipment <b>1002</b> provides system manager <b>302</b> with a response that indicates whether a given subscribed property is present in equipment <b>1002</b> (i.e., whether equipment <b>1002</b> has that data point) and/or whether that property is reliable (e.g., whether equipment <b>1002</b> is online or offline). If a subscribed property is present and reliable, system manager <b>302</b> may post a sample of the property to timeseries service <b>1316</b> (step <b>1524</b>). However, if a subscribed property is not present in equipment <b>1002</b>, system manager <b>302</b> can notify data adaptor <b>1026</b> that the bound property is not present (step <b>1526</b>). Data adaptor <b>1026</b> can then update the shadow with security service <b>1312</b> (step <b>1528</b>) to remove the property that is not present. If a subscribed property is not reliable (e.g., equipment <b>1002</b> is offline), system manager <b>302</b> can remove the offline device from the reported network tree (step <b>1530</b>) and post the updated reported network tree to data adaptor <b>1026</b> (step <b>1532</b>). Data adaptor <b>1026</b> can then update the shadow with security service <b>1312</b> (step <b>1534</b>) to remove any properties associated with the offline device.

Alarm Process

0229Referring now to <figref idref="DRAWINGS">FIG. 16</figref>, a sequence diagram illustrating an alarm process <b>1600</b> is shown, according to an exemplary embodiment. Process <b>1600</b> can be performed by one or more components of BMS <b>900</b> to generate alarms when a problem or event occurs within a piece of equipment. For example, process <b>1600</b> can be performed by equipment <b>1002</b>, system manager <b>302</b>, and/or various components of cloud platform <b>901</b> (e.g., timeseries service <b>1316</b>, data adaptor <b>1026</b>, etc.). An alarm may include an indication of whether the alarm is active (e.g., true/false), a time at which the alarm became active, a time at which the alarm became inactive, and/or an indication or alarm severity (e.g., critical, service priority, service, etc.). An alarm may include an alarm active name (e.g., an enumerated set and ID translated to a string) and an alarm inactive name (e.g., an enumerated set and ID translated to a string). In some embodiments, an alarm includes alarm text.

0230Equipment <b>1002</b> may store a list of currently active alarms and a log of historical alarms. System manager <b>302</b> can provide a full list of the currently active alarms in the system when system manager <b>302</b> starts up. After startup, system manager <b>302</b> can send alarm list updates for new alarms on a continuous basis for all equipment <b>1002</b> within the system. In some embodiments, cloud platform <b>901</b> does not need to initiate alarm notification and does not need to select equipment. System manager <b>302</b> can send alarms to timeseries service <b>1316</b>. When new equipment is discovered, system manager <b>302</b> can create a timeseries for the equipment and can add an alarm timeseries ID to the reported network tree sent to data adaptor <b>1026</b>.

0231Process <b>1600</b> is shown to include system manager <b>302</b> discovering equipment <b>1002</b> (step <b>1602</b>). System manager <b>302</b> can request an alarm timeseries from timeseries service <b>1316</b> for the discovered equipment (step <b>1604</b>). Timeseries service <b>1316</b> may reply to system manager <b>302</b> with the timeseries ID for the alarm timeseries associated with each piece of equipment <b>1002</b> (step <b>1606</b>). System manager <b>302</b> can then store the alarm timeseries ID in the reported network tree (step <b>1608</b>).

0232System manager <b>302</b> can subscribe to event list changes with equipment <b>1002</b> (step <b>1610</b>) and can be notified by equipment <b>1002</b> when the event list has changed (step <b>1612</b>). In some embodiments, the event list identifies a set of events that have been recorded by equipment <b>1002</b>, including fault events and/or alarm events. In response to a notification that the event list has changed, system manager <b>302</b> can read the event list (step <b>1614</b>) and can post the full list of alarms to timeseries service <b>1316</b> (step <b>1616</b>). System manager <b>302</b> can also post the reported network tree, including the alarm timeseries ID, to data adaptor <b>1026</b> (step <b>1618</b>).

0233In some embodiments, system manager <b>302</b> receives a COV notification from equipment <b>1002</b> indicating that the event list has changed (step <b>1620</b>). In response to the COV notification, system manager <b>302</b> can read the event list (step <b>1622</b>) and identify any changes to the event list (step <b>1624</b>). System manager <b>302</b> can post any alarms in the event list changes to timeseries service <b>1316</b> (step <b>1626</b>). In some embodiments, system manager <b>302</b> removes any offline devices from the reported network tree (step <b>1628</b>) and posts the updated reported network tree to timeseries service <b>1316</b> (step <b>1630</b>).

Command Process

0234Referring now to <figref idref="DRAWINGS">FIG. 17</figref>, a sequence diagram illustrating a command process <b>1700</b> is shown, according to an exemplary embodiment. Process <b>1700</b> can be performed by one or more components of BMS <b>900</b> to command and control equipment <b>1002</b> of BMS <b>900</b>. For example, process <b>1700</b> can be performed by equipment <b>1002</b>, system manager <b>302</b>, and/or various components of cloud platform <b>901</b> (e.g., command service <b>1318</b>, etc.). Command service <b>1318</b> can be configured to change any data values including setpoints, configuration parameters, schedules, and other types of data used by system manager <b>302</b> and/or equipment <b>1002</b>. For example, cloud applications <b>1028</b> can use command service <b>1318</b> to change the value of any property that is defined as writable in the equipment's equipment model template.

0235Process <b>1700</b> is shown to include command service <b>1318</b> sending a command to system manager <b>302</b> (step <b>1702</b>). The command may be provided by a remote user of data platform <b>1030</b>, cloud applications <b>1028</b>, or any other system or device. In response to the command, system manager <b>302</b> can write the value of a property to equipment <b>1002</b> (step <b>1704</b>). Writing the value of a property may include updating a setpoint, updating a control signal, changing a configuration parameter, changing a schedule, or changing another parameter used by equipment <b>1002</b>. Equipment <b>1002</b> can write a response to the command back to system manager <b>302</b> (step <b>1706</b>). System manager <b>302</b> can then send a command response to command service <b>1318</b> (step <b>1708</b>). The command response may include a unique message ID, a response (e.g., complete), and a command result (e.g., write successful). Several examples of commands are provided in Appendix D.

0236In some embodiments, command service <b>1318</b> is configured to provide read property commands to system manager <b>302</b>. A read property command can be used to retrieve point names for IOM-200 devices. This command may also be used to retrieve the value of other properties in the future. The read property command may follow the same pattern as the write property command described with reference to <figref idref="DRAWINGS">FIG. 17</figref>. However, the value parameter of a read property command may be included in the response instead of the request.

Schedule Synchronization and Configuration

0237Referring now to <figref idref="DRAWINGS">FIG. 18</figref>, a block diagram illustrating a schedule synchronization operation which can be performed by BMS <b>900</b> is shown, according to an exemplary embodiment. System manager <b>302</b> can contain equipment schedules and sync/global schedules. Equipment schedules may reside in the equipment, whereas sync schedules may reside in system manager <b>302</b> and can be used to synchronize their configuration with multiple equipment schedules. This allows multiple equipment schedules to be configured simultaneously. Global schedules may reside in system manager <b>302</b> and can send commands to the list of property references.

0238In some embodiments, schedule logic is executed within equipment <b>1002</b>. For example, equipment <b>1002</b> can evaluate the schedule for a day periodically, and issue a write to the scheduled properties according to daily schedule. Equipment schedules can be synchronized with a schedule configuration in system manager <b>302</b>. <figref idref="DRAWINGS">FIG. 18</figref> shows that the configuration for sync schedule 1 is pushed down to the schedule in RTU<b>1</b> and RTU<b>2</b>. Sync schedule 1's configuration overwrites any configuration of RTU<b>1</b>'s schedule and RTU<b>2</b>'s schedule. Accordingly, cloud applications <b>1028</b> can edit sync schedule 1 to affect the schedule in RTU<b>1</b> and RTU<b>2</b>, rather than editing RTU<b>1</b>'s schedule or RTU<b>2</b>'s schedule directly.

0239In some embodiments, system manager <b>302</b> lists each schedule on the site, along with a reference to its schedule configuration in the reported network tree. The schedule configuration can define the type of schedule (e.g., global, sync, equipment, etc.). Weekly schedules may contain seven entries, one for each day of the week. Each entry may contain a list of the times and corresponding values for the schedule to write to the scheduled properties. Exceptions to the weekly schedule may override the times in this weekly schedule. The schedule configuration may define the scheduled properties (i.e., a list of properties to be written at the scheduled times), synchronized devices (i.e., a list of devices that share a schedule configuration with the sync schedule), and exceptions to the weekly schedule. Each schedule object may include its own schedule configuration file in data adaptor <b>1026</b>. An example of a schedule configuration is provided in Appendix E.

0240Referring now to <figref idref="DRAWINGS">FIG. 19</figref>, a sequence diagram illustrating a schedule configuration process <b>1900</b> for equipment schedules is shown, according to an exemplary embodiment. Process <b>1900</b> can be performed by one or more components of BMS <b>900</b> to configure and synchronize schedules for equipment <b>1002</b>. For example, process <b>1900</b> can be performed by equipment <b>1002</b>, system manager <b>302</b>, a user <b>1901</b>, and/or various components of cloud platform <b>901</b> (e.g., command service <b>1318</b>, data adaptor <b>1026</b> etc.).

0241Process <b>1900</b> is shown to include system manager <b>302</b> discovering equipment <b>1002</b> (step <b>1902</b>) and creating a schedule configuration for the discovered equipment <b>1002</b> (step <b>1904</b>). System manager <b>302</b> can subscribe to a refresh for one or more schedule objects associated with equipment <b>1002</b> (step <b>1906</b>) and can read a response from equipment <b>1002</b> indicating a schedule refresh (step <b>1908</b>). In response to being notified that the schedule object has refreshed, system manager <b>302</b> can read the weekly schedule and properties scheduled for equipment <b>1002</b> (step <b>1910</b>) and can post the schedule configuration to data adaptor <b>1026</b> (step <b>1912</b>). System manager <b>302</b> can also post the reported network tree to data adaptor <b>1026</b> (step <b>1914</b>).

0242A user <b>1902</b> can edit the schedule for equipment <b>1002</b> (step <b>1916</b>). In response, equipment <b>1002</b> may provide a COV notification to system manager <b>302</b> (step <b>1918</b>). Upon receiving the COV notification, system manager <b>302</b> can read the weekly schedule and properties scheduled for equipment <b>1002</b> (step <b>1928</b>) and can post the schedule configuration to data adaptor <b>1026</b> (step <b>1922</b>).

0243Command service <b>1318</b> can also modify the schedule for equipment <b>1002</b> (step <b>1924</b>). In response, system manager <b>302</b> may write the weekly schedule, including the modified properties, to equipment <b>1002</b> (step <b>1926</b>). System manager <b>302</b> may receive a COV notification from equipment <b>1002</b> indicating a change to the schedule (step <b>1928</b>). In response to receiving the COV notification, system manager <b>302</b> can read the weekly schedule for equipment <b>1002</b> and the list of property references (step <b>1930</b>) and can post the schedule configuration to data adaptor <b>1026</b> (step <b>1932</b>). In some embodiments, system manager <b>302</b> removes offline devices from the reported network tree (step <b>1934</b>) and posts the reported network tree to data adaptor <b>1026</b> (step <b>1936</b>).

0244Referring now to <figref idref="DRAWINGS">FIG. 20</figref>, a sequence diagram illustrating a schedule configuration process <b>2000</b> for a sync schedule is shown, according to an exemplary embodiment. Process <b>2000</b> can be performed by one or more components of BMS <b>900</b> to configure and synchronize schedules for equipment <b>1002</b>. For example, process <b>2000</b> can be performed by a user <b>1902</b>, system manager <b>302</b>, and/or various components of cloud platform <b>901</b> (e.g., command service <b>1318</b>, data adaptor <b>1026</b> etc.).

0245Process <b>2000</b> is shown to include a user <b>1901</b> creating a sync schedule and associating devices with the sync schedule (step <b>2002</b>). In some embodiments, step <b>2002</b> is performed via a local user interface of system manager <b>302</b>. In response to user <b>1901</b> creating the sync schedule, system manager <b>302</b> can create a schedule configuration (step <b>2004</b>) and post the schedule configuration to data adaptor <b>1026</b> (step <b>2006</b>). System manager <b>302</b> can also post the reported network tree to data adaptor <b>1026</b> (step <b>2008</b>).

0246The sync schedule can be edited by a user <b>1901</b> (step <b>2010</b>) via a local user interface of system manager <b>302</b>. In response to user <b>1901</b> editing the sync schedule, system manager <b>302</b> can post the schedule configuration to data adaptor <b>1026</b> (step <b>2012</b>). System manager <b>302</b> can also post the reported network tree to data adaptor <b>1026</b> (step <b>2014</b>). If the sync schedule is deleted by a user (step <b>2020</b>), system manager <b>302</b> can report the network tree to data adaptor <b>1026</b> (step <b>2022</b>).

0247The sync schedule can be modified by command service <b>1318</b> by sending a modify schedule command to system manager <b>302</b> (step <b>2016</b>). The modify schedule command may include a command ID (e.g., modify schedule), and a command parameter (e.g., the schedules FQR ID, a schedule configuration, etc.). In response to command service <b>1318</b> modifying the sync schedule, system manager <b>302</b> can post the schedule configuration to data adaptor <b>1026</b> (step <b>2018</b>).

System Manager Life Cycle

0248Referring now to <figref idref="DRAWINGS">FIG. 21</figref>, a flowchart of a process <b>2100</b> illustrating the life cycle of system manager <b>302</b> is shown, according to an exemplary embodiment. Process <b>2100</b> can be performed by the factory that builds system manager <b>302</b>, by the installer or contractor that installs system manager <b>302</b>, and/or by one or more components of system manager <b>302</b>.

0249Process <b>2100</b> is shown to include the factory building system manager <b>302</b> (step <b>2102</b>). The factory can generate a device ID for system manager <b>302</b> and print the device ID on the label for system manager <b>302</b> (step <b>2104</b>). The factory can use data platform <b>1030</b> and a device management portal to register system manager <b>302</b> using the device ID and get a device key pair (step <b>2106</b>). The factory can then program the device keys into system manager <b>302</b> and ship system manager <b>302</b> to an installer or distributor (step <b>2108</b>). The distributor may distribute system manager <b>302</b> to a contractor for installation.

0250The installer or contractor can install system manager <b>302</b> (steps <b>2110</b> and <b>2112</b>) and configure and troubleshoot the connection between system manager <b>302</b> and cloud platform <b>901</b> (step <b>2114</b>). In some embodiments, the human interaction needed for cloud connectivity includes accepting the end user license agreement (EULA), entering the network information needed for an internet connection via the UI of system manager <b>302</b> (customer-specific information), setting the time zone and opting in to send data to cloud platform <b>901</b> via the UI of system manager <b>302</b>, logging in to the device management portal to report that system manager <b>302</b> is installed at a customer site (the web site URL may be provided via the UI of system manager <b>302</b>), and initiating the restore of a replacement system manager's configuration via the UI of system manager <b>302</b>. All other configuration may be automatic. The contractor or installer may use the device management portal to associate the device ID of system manager <b>302</b> with a particular customer and site location (step <b>2116</b>).

0251System manager <b>302</b> may begin sending data to cloud platform <b>901</b> as soon as the cloud connection has been established (if the customer opts in to sending data to cloud platform <b>901</b>). Cloud platform <b>901</b> can associate any existing data with a customer/site when the customer is associated with system manager <b>302</b>. System manager <b>302</b> can periodically check for software updates, periodically send data to cloud platform <b>901</b>, send alarms and telemetry data to cloud platform <b>901</b>, and check for commands from cloud platform <b>901</b> (step <b>2118</b>).

0252If system manager <b>302</b> is not being replaced (i.e., the result of step <b>2120</b> is “no”), the installation of system manager <b>302</b> is complete (step <b>2124</b>). If system manager <b>302</b> is being replaced (i.e., the result of step <b>2120</b> is “yes”), the installer or contractor can use the device management portal to perform device replacement. The configuration of system manager <b>302</b> can be restored to the new system manager <b>302</b> from a backup store at cloud platform <b>901</b> (step <b>2122</b>) and the installation of system manager <b>302</b> is complete (step <b>2124</b>).

Startup Process

0253Referring now to <figref idref="DRAWINGS">FIG. 22</figref>, a sequence diagram illustrating a startup process <b>2200</b> for system manager <b>302</b> is shown, according to an exemplary embodiment. Process <b>2200</b> can be performed by one or more components of BMS <b>900</b>. For example, process <b>2200</b> can be performed by equipment <b>1002</b>, system manager <b>302</b>, a user <b>1901</b>, and/or various components of cloud platform <b>901</b> (e.g., security service <b>1312</b>, timeseries service <b>1316</b>, time sync service <b>1314</b>, data adaptor <b>1026</b>, etc.).

0254Process <b>2200</b> is shown to include a user <b>1901</b> setting a time zone with system manager <b>302</b> (step <b>2202</b>) and setting system manager <b>302</b> to send data to cloud platform <b>901</b> (step <b>2204</b>). System manager <b>302</b> can get the current time from time sync service <b>1314</b> (step <b>2206</b>) and can synchronize the time with equipment <b>1002</b> (step <b>2208</b>). In some embodiments, system manager <b>302</b> sets a timer to synchronize the time periodically. System manager <b>302</b> can get a token and shadow from security service <b>1312</b> (step <b>2210</b>) and can store a local copy of the shadow within system manager <b>302</b>. System manager <b>302</b> can use the bound list of the shadow to determine which properties to send to cloud platform <b>901</b>. If the settings of system manager <b>302</b> are different from the shadow obtained from security service <b>1312</b>, system manager <b>302</b> can update the shadow (step <b>2216</b>).

0255In some embodiments, system manager <b>302</b> requests a heartbeat timeseries from timeseries service <b>1316</b> (step <b>2212</b>). Timeseries service <b>1316</b> may reply with a heartbeat timeseries ID (step <b>2214</b>). System manager <b>302</b> can use the heartbeat timeseries ID to post a heartbeat to timeseries service <b>1316</b> (step <b>2218</b>). In some embodiments, system manager <b>302</b> sets a timer to periodically post a heartbeat to timeseries service <b>1316</b> at regular intervals.

0256System manager <b>302</b> may obtain a manifest from security service <b>1312</b> (step <b>2220</b>). In some embodiments, system manager <b>302</b> sets a timer to obtain the manifest from security service <b>1312</b> periodically (e.g., every 24 hours). In some embodiments, the manifest contains the URL of a software repository that stores software for system manager <b>302</b>. System manager <b>302</b> can check whether the installed version of software on system manager <b>302</b> is different from the most recent version stored at the software repository. If an updated version of software is available at the software repository, system manager <b>302</b> can download a software update from the software repository (step <b>2224</b>) and notify user <b>1901</b> that a software update is available (step <b>2226</b>).

0257In some embodiments, system manager <b>302</b> posts a backup file to data adaptor <b>1026</b> (step <b>2228</b>). System manager <b>302</b> can set a timer to post a backup file to data adaptor <b>1026</b> periodically, according to a configurable backup frequency (e.g., every 24 hours, once per week, once per month, etc.).

0258In some embodiments, system manager <b>302</b> is configured to perform a discovery process at startup. After discovering all of the equipment connected with system manager <b>302</b>, system manager <b>302</b> can generate a reported network tree which identifies all of the discovered equipment. System manager <b>302</b> can sent the reported network tree to data adaptor <b>1026</b>. In some embodiments, the reported network tree identifies a equipment model template for each item of equipment in the reported network tree. The equipment model template may define all of the points associated with the corresponding item of equipment. If data platform <b>1030</b> does not yet have the identified equipment model templates, data platform <b>1030</b> may send a command/request for the missing equipment model templates to system manager <b>302</b>. In response to the command, system manager <b>302</b> may post the requested equipment model templates to data adaptor <b>1026</b>. An example of a command which can be used is provided in Appendix D.

0259At startup, system manager <b>302</b> may send an updated reported network tree to data adaptor <b>1026</b> when new device is detected on system bus <b>926</b>, a device is removed from system bus <b>926</b>, a sync schedule is created or deleted within system manager <b>302</b>, and/or a device on system bus <b>926</b> is rediscovered due to changes that affect the reported network tree. In some embodiments, system manager <b>302</b> includes a data model manager that provides a list of devices and each device's equipment to data platform <b>1030</b>. Schedule information can also be retrieved and added to the reported network tree. Adding schedule information may include getting a device list, getting top level equipment objects, reading the view definition and inserting the schedules, getting a schedule sync summary, and updating the schedules if needed.

Device Management Portal

0260Referring now to <figref idref="DRAWINGS">FIGS. 23-24</figref>, user interfaces <b>2300</b> and <b>2400</b> illustrating a device management portal are shown, according to an exemplary embodiment. In some embodiments, the device management portal is generated by data platform <b>1030</b> and presented to a user via a web interface. The device management portal may allow a customer to create a user and may allow contractors to log in to the portal. The device management portal can be used to associate device IDs to a particular customer and facilitate replacement of system manager <b>302</b> (i.e., replace an old system manager <b>302</b> having a device ID with a new system manager <b>302</b> having a different device ID).

0261Interface <b>2300</b> is an interface for adding devices. When a device ID is added in the “Enter Device ID” field, data platform <b>1030</b> may validate that the device ID is available in the database and is not associated with any customers. If the device ID is not already in use, data platform <b>1030</b> may associate the device ID with the customer.

0262Interface <b>2400</b> is an interface for replacing an old device with a new device. When an old device ID is Entered in the “Enter Old Device” field, data platform <b>1030</b> may validate the device ID to ensure it is a live system. When a new device is entered in the “Enter New Device” field, data platform <b>1030</b> may validate that the device is available in the database and is not associated with any customers. When the save button is selected, the shadow of the old device may be copied into the new device ID shadow so that the shadow becomes the new device's shadow. The device backup file from the old device may also be copied into the backup file in the cloud and can be used as the backup file for the new device. All systems and points attached to the old device can be moved to the new device ID. The device management portal may be configurable to update data adaptor <b>1026</b> and send update messages to other applications

High Level Process Flow

0263Referring now to <figref idref="DRAWINGS">FIGS. 25-26</figref>, block diagrams <b>2500</b> and <b>2600</b> illustrating a high level process flow performed by BMS <b>900</b> is shown, according to an exemplary embodiment. A manufacturer can log into a manufacturer portal and enter the device ID and get a device key auto-generated from the portal. Once a device ID is created, a device shadow gets automatically be created in cloud platform <b>901</b> with blank reported and bound points and with a version 0. The manufacturer can embed the device ID and device key into system manager <b>302</b> and can ship system manager <b>302</b> to a customer or supplier. The customer admin can log into an enterprise application (e.g., one of cloud applications <b>1028</b>) and create a user with the role of installation technician. The customer admin can provide credentials to an installation technician to allow the installation technician to install system manager <b>302</b> at the customer site. To install system manager <b>302</b>, the installation technician can log into the enterprise application and adds the device ID to the customer record. The installation technician can then log into the UI of system manager <b>302</b> and setup the local time zone for system manager <b>302</b>.

0264Once connected to the internet, system manager <b>302</b> may initiate a time synchronization with time sync service to get the current time in UTC Format and will store it. All future data transmissions will be based on the time and the time zone of system manager <b>302</b>. System manager <b>302</b> can get the shadow version from cloud platform <b>901</b> and store it locally. System manager <b>302</b> may request a timeseries ID for device status/heartbeat messages from timeseries service <b>1316</b>. The timeseries ID can be stored locally in system manager <b>302</b> and in the shadow for system manager <b>302</b>. System manager <b>302</b> can be configured to send out “status” messages at a regular frequency (e.g., every 15 mins) to timeseries service <b>1316</b> using the status/heartbeat timeseries ID. These messages can be stored for device connection status monitoring and for audit purposes.

0265System manager <b>302</b> can discover the system and equipment connected to it. System manager <b>302</b> can request and create timeseries containers from timeseries service <b>1316</b> for alarms for the individual connected system/equipment. System manager <b>302</b> can store the alarm timeseries IDs locally. System manager <b>302</b> can generate a reported network tree from the discovered systems along with the alarm timeseries ID of each system. System manager <b>302</b> can sent the reported network tree to data adaptor <b>1026</b>.

0266Data adaptor <b>1026</b> can use equipment model files and the reported network tree to create a reported points list. Data adaptor <b>1026</b> can create a device-system-point hierarchy and store the hierarchy in cloud platform <b>901</b>. Data adaptor <b>1026</b> can generate a list of bound points from a default bound list for each system/equipment. For the bound points, timeseries service <b>1316</b> can create timeseries IDs. The point ID to timeseries ID mapping can be stored in cloud platform <b>901</b>. The bound points along with their timeseries IDs can also be stored in the devices cloud shadow and can be updated when changes of value occur. System manager <b>302</b> can synchronize with the shadow by downloading and storing a list of the bound points in local memory. System manager <b>302</b> may transmit timeseries data for only the points listed in the bound points list.

0267When additional systems/equipment are connected to system manager <b>302</b>, system manager <b>302</b> can discover the new systems/equipment and can update the reported network tree. System manager <b>302</b> can send the updated reported network tree to data adaptor <b>1026</b>. Data adaptor <b>1026</b> can use the updated reported network tree to generate an updated reported points list. Data adaptor <b>1026</b> can generate bound point and timeseries IDs for any new points and can update the device's shadow to be synchronized by system manager <b>302</b>.

0268System manager <b>302</b> can be configured to transmit telemetry/timeseries data for the points identified in the bound points list. Such data can be sent to timeseries service <b>1316</b> along with the timestamp. If the telemetry data contains an enumerated set and an enumerated value, system manager <b>302</b> can store the enumerated values as JSON formatted data strings and pass the strings to timeseries service <b>1316</b> with the timestamp.

0269System manager <b>302</b> can generate alarm notifications and send the alarm notifications to designated recipients. The alarm notifications can be stored in cloud platform <b>901</b> for audit purposes. Alarm messages sent from equipment/systems can be sent to timeseries service <b>1316</b>. The alarm messages can be stored as JSON formatted enumerated set and enumerated values as string messages. In some embodiments, cloud applications <b>1028</b> can send notifications based on the alarm messages to enterprise users.

0270Command and control messages can be initiated from an enterprise portal and routed to system manager <b>302</b> by data platform <b>1030</b>. At a scheduled time, system manager <b>302</b> can log into cloud platform <b>901</b> and get the latest firmware information for system manager <b>302</b>. If the latest firmware information doesn't match the installed firmware version at system manager <b>302</b>, system manager <b>302</b> can download the latest firmware from the URL available in the message.

0271Personnel can log into the enterprise portal and manually enter the serial number of systems and/or equipment. For some equipment, cloud platform <b>901</b> can automatically fetch warranty information from a web service and update the warranty information stored in data platform <b>1030</b>. Equipment schedules can be pushed by system manager <b>302</b> and stored in cloud platform <b>901</b>. The schedules can be updated in the cloud via the enterprise portal and pushed back to system manager <b>302</b>. Setpoint changes for the system's bound points can be initiated from the enterprise portal. When a user makes a setpoint change to an item of equipment, the information can be directed to system manager <b>302</b> and a response can be stored in cloud platform <b>901</b>.

0272In some embodiments, system manager <b>302</b> includes a device ID and a hashed key for secure communication. The device ID, key, and/or other password can be encoded to generate a SAS token, which can be transmitted over the network during communications with data platform <b>1030</b>. For example, the SAS token can be transmitted during timeseries data transmission, equipment alarms transmission, schedule synchronization between system manager <b>302</b> and cloud platform <b>901</b>, and/or modifying setpoints and configuration parameters.

New Device Initial Provisioning

0273Referring now to <figref idref="DRAWINGS">FIG. 27</figref>, a sequence diagram illustrating an initial provisioning process <b>2700</b> is shown, according to an exemplary embodiment. Process <b>2700</b> can be performed by a manufacturer, a supplier, and/or one or more components of BMS <b>900</b> (e.g., system manager <b>302</b>, data platform <b>1030</b>, etc.) to provision system manager <b>302</b>.

0274In some embodiments, process <b>2700</b> includes device registration. Device registration may include entering the device ID of system manager <b>302</b> using a configuration application. The device ID may include a serial number of system manager <b>302</b>. Data platform <b>1030</b> registers the new device with the device ID and generates a key pair. A device shadow can be automatically created in data platform <b>1030</b> for system manager <b>302</b> (by device ID).

0275Process <b>2700</b> may include device provisioning by a manufacturer. The manufacturer can embed the device key into system manager <b>302</b>. In data platform <b>1030</b>, system manager <b>302</b> then shows up as manufactured but not associated with a customer. The device ID may be equivalent to the serial ID and may function as a unique identifier that will identify a particular instance of system manager <b>302</b>. Data platform <b>1030</b> can create a device shadow for system manager <b>302</b> and store the device shadow in data platform <b>1030</b>. System manager <b>302</b> can then be shipped to a supplier.

0276At the customer site, the customer logs into cloud applications <b>1028</b> and creates a user account for the installation technician. The technician installs system manager <b>302</b> device at the site. The technician logs into cloud applications <b>1028</b> with the customer provided credential, enters the device ID of system manager <b>302</b>, and saves the record. This associates system manager <b>302</b> with the customer. The installation technician can log into a user interface provided by system manager <b>302</b> to setup the device time zone.

0277New Device Initiation

0278Referring now to <figref idref="DRAWINGS">FIGS. 28A-28C</figref>, a sequence diagram illustrating a new device initiation process <b>2800</b> is shown, according to an exemplary embodiment. Process <b>2800</b> can be performed by one or more components of BMS <b>900</b> (e.g., system manager <b>302</b>, time sync service <b>1314</b>, identity service <b>1310</b>, security service <b>1312</b>, data adaptor <b>1026</b>, timeseries service <b>1316</b>, cloud applications <b>1028</b>, etc.) to initiate system manager <b>302</b> and begin reporting data to cloud platform <b>901</b>.

0279Once system manager <b>302</b> is installed on a new customer site and connected to the Internet, system manager <b>302</b> will request and get the current time from time sync service <b>1314</b> and store the time. The time may be returned in ISO 8901 time format. System manager <b>302</b> can get an access token using the device ID and device key from identity service <b>1310</b>. System manager <b>302</b> can request and get the latest firmware information from security service <b>1312</b>. If a later version is available, system manager <b>302</b> can download the firmware and install it. System manager <b>302</b> can request and sync the latest version of the device shadow from security service <b>1312</b>.

0280System manager <b>302</b> can request a timeseries ID for a status message from timeseries service <b>1316</b>. Timeseries service <b>1316</b> may return a timeseries ID. The timeseries ID can be stored locally on system manager <b>302</b> to send a status timeseries. System manager <b>302</b> can update the device shadow with the status timeseries ID. When system manager <b>302</b> sends status messages to timeseries service <b>1316</b>, it sends the timeseries data to the above timeseries IDs

0281In some embodiments, process <b>2800</b> includes reported point generation and mapping. Equipment can have thousands of points (i.e., reported points) but cloud applications <b>1028</b> may only need a portion of the points (i.e., bound points) for data collection and reporting to cloud platform <b>901</b>. Once system manager <b>302</b> identifies all the systems connected to it, system manager <b>302</b> can request timeseries containers for each system for reporting alarms and can store the timeseries ID per system locally. System manager <b>302</b> can generate a reported network tree with the status ID for each device and alarm IDs per system. The reported network tree can then be sent to data adaptor <b>1026</b>.

0282Once data adaptor <b>1026</b> receives the reported network tree with FQR and relevant data, data adaptor <b>1026</b> can create system information with system ID, timeseries ID and system FQR. Data adaptor <b>1026</b> can create reported points with point ID and point FQRs from the system's equipment model. Data adaptor <b>1026</b> can map the alarm timeseries IDs per system and store them in cloud platform <b>901</b>. Data adaptor <b>1026</b> can also create and store a device-system-point hierarchy in cloud platform <b>901</b>.

0283In some embodiments, process <b>2800</b> includes bound points creation. Once all the reported network tree values are sent to data adaptor <b>1026</b>, data adaptor <b>1026</b> can create bound points for the systems and equipment identified in the reported network tree. Data adaptor <b>1026</b> can create timeseries IDs for the bound points and can update the bound points in the device's cloud shadow with the point FQRs and timeseries IDs. System manager <b>302</b> can find that there is a more recent version of the shadow in cloud platform <b>901</b> and can download the bound points to update its memory.

0284In some embodiments, process <b>2800</b> includes removal of non-existent bound points. Once a system/equipment is live, there will be some points that are assigned as default bound points but are not used in the system. The points not used in the system can be removed so that they do not show up as missing data. To remove non-existent bound points, system manager <b>302</b> can get a list of all non-existent bound points. System manager <b>302</b> can get an access token from identity service <b>1310</b> and send the list of non-existent bound points to data adaptor <b>1026</b>. In some embodiments, system manager <b>302</b> sends data adaptor <b>1026</b> the point ID, point FQR, system ID, and/or device ID for any non-existent bound points. Data adaptor <b>1026</b> can update the bound point list in cloud applications <b>1028</b> by removing the non-existent bound points. Data adaptor <b>1026</b> can store the updated bound point list by system and device. Data adaptor <b>1026</b> can also update the device's shadow with the updated bound point list. The updated bound point list can then be downloaded by system manager <b>302</b> from the device shadow and stored locally.

Timeseries Data Process

0285Referring now to <figref idref="DRAWINGS">FIG. 29</figref>, a sequence diagram illustrating a timeseries data process <b>2900</b> is shown, according to an exemplary embodiment. Process <b>2900</b> can be performed by one or more components of BMS <b>900</b> to collect and send timeseries data to cloud platform <b>901</b>. For example, process <b>2900</b> can be performed by system manager <b>302</b>, and/or various components of cloud platform <b>901</b> (e.g., identity service <b>1310</b>, dictionary service <b>1024</b>, timeseries service <b>1316</b>, etc.).

0286When a point in the bound point list generates telemetry data, system manager <b>302</b> can receive the timeseries data and send a request for an access token to identity service <b>1310</b>. System manager <b>302</b> can send timeseries service a timeseries ID, the value of the bound point, and a timestamp. Telemetry data can include an enumerated set and an enumerated value pair (e.g., strings). System manager <b>302</b> can send the enumerated set and enumerated value dictionary service <b>1024</b>. Dictionary service <b>1024</b> may respond with an enumerated string value. System manager <b>302</b> can then send the timeseries data to timeseries service <b>1316</b>. The timeseries data may include a timeseries ID, a value as a string (e.g., the enumerated string), and a timestamp. Timeseries service <b>1316</b> may respond to system manager <b>302</b> acknowledging receipt of the timeseries data.

0287In some embodiments, system manager <b>302</b> sends a heartbeat timeseries message to timeseries service <b>1316</b> every 15 minutes along with the timestamp. System manager <b>302</b> may obtain an access token from identity service <b>1310</b> and may send a timeseries message to timeseries service <b>1316</b>. The timeseries message may include a timestamp, a value, and a status timeseries ID. Timeseries service <b>1316</b> may respond with an acknowledgement. The heartbeat timeseries message can be stored as a separate timeseries (i.e., a status timeseries) and can be used to determine whether system manager <b>302</b> is online. In some embodiments, cloud applications <b>1028</b> use the status timeseries to identify system manager <b>302</b> is properly connected to cloud platform <b>901</b>.

Alarm Process

0288Referring now to <figref idref="DRAWINGS">FIG. 30</figref>, a sequence diagram illustrating an alarm process <b>3000</b> is shown, according to an exemplary embodiment. Process <b>3000</b> can be performed by one or more components of BMS <b>900</b> to provide alarms to cloud platform <b>901</b> when a problem or event occurs within a piece of equipment.

0289A system or equipment can generate alarm data that is sent to system manager <b>302</b>. When an alarm is triggered by a system/equipment, system manager <b>302</b> can send an alarm notification to the customer as configured in system manager <b>302</b>. System manager <b>302</b> can get an alarm timeseries ID for the system/equipment and can obtain an access token from identity service <b>1310</b>. System manager <b>302</b> can send the alarm to timeseries service <b>1316</b> along with the alarm timeseries ID and attributes of the alarm. Such attributes may include, for example, alarm priority (e.g., critical, service, service-priority), an enumerated set and enumerated value from dictionary service <b>1024</b>, and a timestamp. The alarm can be stored as timeseries data by timeseries service <b>1316</b>. In some embodiments, timeseries service <b>1316</b> responds to the alarm message by acknowledging receipt. The alarm data can be viewed by cloud applications <b>1028</b>.

Warranty Process

0290Referring now to <figref idref="DRAWINGS">FIG. 31</figref>, a sequence diagram illustrating a warranty process <b>3100</b> is shown, according to an exemplary embodiment. Process <b>3100</b> can be performed by one or more components of BMS <b>900</b> to obtain warranty information for equipment in BMS <b>900</b>. For example, process <b>3100</b> can be performed by system manager <b>302</b>, identity service <b>1310</b>, data platform <b>1030</b>, cloud applications <b>1028</b>, an asset service, and/or a warranty service.

0291When equipment (e.g., a RTU) is connected to system manager <b>302</b>, a user can log into cloud applications <b>1028</b>, select the RTU system, and enter a serial number of the RTU. Once a new serial number is saved, data adaptor <b>1026</b> can send the system/equipment information to the asset service. At a set schedule (e.g., once per day), the asset service can look for any RTUs from no warranty information. If any records are found, the asset service can connect to a warranty service and retrieve the asset and warranty information of the RTU. The warranty information is then stored in cloud platform <b>901</b>.

Adding New Systems/Equipment

0292Referring now to <figref idref="DRAWINGS">FIG. 32</figref>, a sequence diagram illustrating a process <b>3200</b> for adding new systems/equipment to BMS <b>900</b> is shown, according to an exemplary embodiment. Process <b>3200</b> can be performed by one or more components of BMS <b>900</b>. For example, process <b>3200</b> can be performed by system manager <b>302</b>, identity service <b>1310</b>, security service <b>1312</b>, timeseries service <b>1316</b>, data adaptor <b>1026</b>, and/or cloud applications <b>1028</b>.

0293When new systems/equipment are connected to system manager <b>302</b>, system manager <b>302</b> can discover the newly added systems/equipment. System manager <b>302</b> can get a timeseries (container) ID for the newly added systems/equipment to send alarms and can store the system-alarm timeseries ID locally. System manager <b>302</b> can obtain an access token from identity service <b>1310</b> and can send the newly discovered system/equipment information to data adaptor <b>1026</b> (e.g., as an updated reported network tree).

0294From the equipment model for the newly added system/equipment, data adaptor <b>1026</b> can create a set of reported points for the newly added system/equipment. Data adaptor <b>1026</b> can update the device-system-point hierarchy and store it locally. Data adaptor <b>1026</b> can then obtain the relevant bound points for the new system/equipment from cloud applications <b>1028</b>. Data adaptor <b>1026</b> can create the necessary points and timeseries data for the bound point list and can generate a timeseries ID-point ID-FQR mapping for any new bound points. Data adaptor <b>1026</b> can update the shadow in cloud platform <b>901</b> with point FQRs and timeseries ID mapping. System manager <b>302</b> can be notified of the updated shadow and can download the latest shadow from security service <b>1312</b>. System manager <b>302</b> can then update the local set of bound points to configure which points are sent to timeseries service <b>1316</b>.

Setpoint Change Command Process

0295Referring now to <figref idref="DRAWINGS">FIG. 33</figref>, a sequence diagram illustrating a process <b>3300</b> for changing a setpoint in BMS <b>900</b> is shown, according to an exemplary embodiment. Process <b>3300</b> can be performed by one or more components of BMS <b>900</b>. For example, process <b>3300</b> can be performed by cloud applications <b>1028</b>, command service <b>1318</b>, and/or system manager <b>302</b>.

0296When a setpoint change is initiated by cloud applications <b>1028</b>, cloud applications <b>1028</b> can create a command string message. In some embodiments, the message is formatted in JSON data format. The message may contain a unique ID for the message, a FQR of equipment/point to which the setpoint change is intended, a unit for the setpoint change, and the changed setpoint value. Cloud applications <b>1028</b> can send the command message along with the device ID to command service <b>1318</b>. Command service <b>1318</b> can forward the command message to system manager <b>302</b> based on the device ID.

0297System manager <b>302</b> can download the message, parse the information, and send it to the appropriate equipment using the FQR. System manager <b>302</b> can respond to command service <b>1318</b> with a “complete,” “reject,” or “abandon” message along with a reply message. The response message may include the unique ID, the response (e.g., complete, reject, abandon, etc.), and a status message. Command service <b>1318</b> can store the reply message, which indicates the status of the command. Cloud applications <b>1028</b> can read the reply message to determine whether the command was successful.

Request Information Command Process

0298Referring now to <figref idref="DRAWINGS">FIG. 34</figref>, a sequence diagram illustrating a process <b>3400</b> for requesting information in BMS <b>900</b> is shown, according to an exemplary embodiment. Process <b>3400</b> can be performed by one or more components of BMS <b>900</b>. For example, process <b>3400</b> can be performed by data adaptor <b>1026</b>, command service <b>1318</b>, and/or system manager <b>302</b>. In some embodiments, process <b>3400</b> is performed when data platform <b>1030</b> needs an equipment template that does not already exist in data adaptor <b>1026</b>.

0299Data adaptor <b>1026</b> can create a command message to get information from system manager <b>302</b>. The command message may contain a unique ID, a request command message, and a system to which the message is intended (e.g., a FQR). Data adaptor <b>1026</b> can send the command message to command service <b>1318</b> along with the device ID. System manager <b>302</b> can receive the message, parse the message to identify the equipment information requested, and send the message to the appropriate equipment. System manager <b>302</b> can respond to command service <b>1318</b> with a “complete,” “reject,” or “abandon” message along with a reply message. Command service <b>1318</b> can store the reply message. In some embodiments, the reply message includes the equipment template in JSON format.

Update Bound Points Process

0300Referring now to <figref idref="DRAWINGS">FIG. 35</figref>, a sequence diagram illustrating a process <b>3500</b> for updating bound points in BMS <b>900</b> is shown, according to an exemplary embodiment. Process <b>3500</b> can be performed by one or more components of BMS <b>900</b>. For example, process <b>3500</b> can be performed by an enterprise user, cloud applications <b>1028</b>, security service <b>1312</b>, and/or system manager <b>302</b>.

0301When system manager <b>302</b> sends a reported network tree to data adaptor <b>1026</b>, data adaptor <b>1026</b> can store the reported points and generate a list of bound points based on a predetermined (e.g., default) set of bound points per system/equipment. The bound points define the set of points for which system manager <b>302</b> will transmit timeseries data to cloud platform <b>901</b>. A user can log into cloud applications <b>1028</b>, select the system, and update the default bound points for a given system/equipment.

0302As shown in <figref idref="DRAWINGS">FIG. 35</figref>, an enterprise user logs into cloud applications <b>1028</b> and selects the system to view the list of reported points and bound points. The enterprise user can change the bound points list. If the bound points selected do not exist in the database, new points and timeseries can be created for new bound points. For bound points that are unselected, timeseries data may be retained (i.e., not deleted) in cloud platform <b>901</b>. Cloud applications <b>1028</b> can update the bound points in the shadow of system manager <b>302</b> stored within security service <b>1312</b>. The shadow version gets updated and a converge message is sent to system manager <b>302</b>. System manager <b>302</b> downloads the updated shadow and updates the local list of bound points to match the bound point list in the shadow.

0303Referring now to <figref idref="DRAWINGS">FIG. 36</figref>, an example of a user interface <b>3600</b> for selecting bound points is shown, according to an exemplary embodiment. The enterprise user can select and deselect points via user interface <b>3600</b> to define which points are included in the bound point list. The selections made via user interface <b>3600</b> can be sent to security service <b>1312</b> to update the shadow for system manager <b>302</b>.

Software Update Process

0304Referring now to <figref idref="DRAWINGS">FIG. 37</figref>, a sequence diagram illustrating a process <b>3700</b> for updating the software or firmware of system manager <b>302</b> is shown, according to an exemplary embodiment. Process <b>3700</b> can be performed by one or more components of BMS <b>900</b>. For example, process <b>3700</b> can be performed by system manager <b>302</b> and/or security service <b>1312</b>.

0305To check for the latest firmware, system manager <b>302</b> can obtain an access token from identity service <b>1310</b>. In some embodiments, the access token is obtained at a preset schedule. System manager <b>302</b> can obtain the latest firmware/software version information from security service <b>1312</b>. If the most recent firmware/software version does not match the version installed on system manager <b>302</b>, system manager <b>302</b> can download the firmware/software file from a URL specified by security service <b>1312</b> and can install it. System manager <b>302</b> can then update the internal firmware/software version number to match the installed version.

Schedule Synchronization Process

0306Referring now to <figref idref="DRAWINGS">FIG. 38</figref>, a sequence diagram illustrating a process <b>3800</b> for synchronizing schedules in BMS <b>900</b> is shown, according to an exemplary embodiment. Process <b>3800</b> can be performed by one or more components of BMS <b>900</b>. For example, process <b>3800</b> can be performed by system manager <b>302</b>, security service <b>1312</b>, and or data adaptor <b>1026</b>.

0307System manager <b>302</b> can obtain schedule information from all attached systems/equipment that contains a synchronized schedule and can store the schedule information in a configuration file. Each schedule in the schedule configuration is identified by a schedule ID. The schedule configuration file can be sent to data adaptor <b>1026</b>. Data adaptor <b>1026</b> can store the schedule configuration file in a blob and update the device shadow's reported section with a timestamp.

0308System manager <b>302</b> can create a system-schedule ID mapping and can create or update a reported point list containing a schedule reference ID (e.g., “Synced with schedule ID:3”). The reported point list generated by system manager <b>302</b> can be sent to data adaptor <b>1026</b>. Data adaptor <b>1026</b> can use the reported point list's schedule ID to map device, system, point, and schedule ID and can store the mapping locally.

Device Schedule Update Process

0309Referring now to <figref idref="DRAWINGS">FIG. 39</figref>, a sequence diagram illustrating a process <b>3900</b> for updating a device schedule via cloud applications <b>1028</b> is shown, according to an exemplary embodiment. Process <b>3900</b> can be performed by one or more components of BMS <b>900</b>. For example, process <b>3900</b> can be performed by an enterprise user, cloud applications <b>1028</b>, command service <b>1318</b>, data adaptor <b>1026</b>, and/or system manager <b>302</b>.

0310When an enterprise user logs into cloud applications <b>1028</b> and pulls up the system/equipment per site, the user will be able to view the schedule. The schedule may be generated by the system's schedule ID and the schedule configuration information. When a schedule gets updated by a user via cloud applications <b>1028</b>, cloud applications <b>1028</b> may create a schedule configuration file and send the schedule configuration file to command service <b>1318</b> as a command message along with the device ID. Command service <b>1318</b> can send the command message to system manager <b>302</b> based on the device ID. System manager <b>302</b> can store the schedule configuration file internally and send the schedule configuration file to data adaptor <b>1026</b>. Data adaptor <b>1026</b> can store the schedule configuration file in cloud platform <b>901</b> and can update the cloud shadow's configuration file reference.

0311When the system-schedule ID reference is modified via cloud applications <b>1028</b>, a command message can be created by cloud applications <b>1028</b> with the schedule ID and system information. The command message can be sent to command service <b>1318</b> along with the device ID. System manager <b>302</b> can store and process the updated schedule ID-system information. System manager <b>302</b> can send an updated reported point list with the new system-schedule ID mapping to data adaptor <b>1026</b>. Data adaptor <b>1026</b> can then update system manager <b>302</b> with its new system-schedule ID mappings.

Device Backup and Restore Process

0312Referring now to <figref idref="DRAWINGS">FIG. 40</figref>, a sequence diagram illustrating a process <b>4000</b> for backing up and restoring the configuration of system manager <b>302</b> is shown, according to an exemplary embodiment. A user can create a device backup for system manager <b>302</b> and store it in cloud platform <b>901</b>. The cloud backup can then be used to restore the configuration of system manager <b>302</b> when needed. Process <b>4000</b> can be performed by one or more components of BMS <b>900</b>. For example, process <b>4000</b> can be performed by system manager <b>302</b>, a device API, and data adaptor <b>1026</b>.

0313A user can initiate a backup of system manager <b>302</b>, which causes system manager <b>302</b> to create a backup file. System manager <b>302</b> can send the backup file to data adaptor <b>1026</b>. Data adaptor <b>1026</b> then stores the backup file and updates the device shadow with a reference timestamp. When the user initiates a restoration of system manager <b>302</b>, system manager <b>302</b> downloads the latest backup file from data adaptor <b>1026</b> and installs the backup.

0000<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="287pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">APPENDIX A</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Reported Network Tree Example</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="287pt" align="left" /><tbody valign="top"><row><entry>{</entry></row><row><entry> ″Reported Network Tree″: {</entry></row><row><entry> ″Sync Schedules″: [{</entry></row><row><entry>  ″Sync Schedule Name″: ″Office Schedule″,</entry></row><row><entry>  ″Sync Schedule FQR ID″: “SyncSched7”,</entry></row><row><entry>  ″Schedule Config Ref″: “SchedConfig1”</entry></row><row><entry> }, {</entry></row><row><entry>  ″Sync Schedule Name″: ″Common Area Schedule″,</entry></row><row><entry>  ″Sync Schedule FQR ID″: “SyncSched3”,</entry></row><row><entry>  ″Schedule Config Ref″: “SchedConfig2”</entry></row><row><entry> }],</entry></row><row><entry> ″Network Tree″: [{</entry></row><row><entry>  ″Network FQR ID”: ″Local MSTP Field Bus″,</entry></row><row><entry>  ″Devices″: [{</entry></row><row><entry>  ″Device Name″: ″Office Zoning System″,</entry></row><row><entry>  ″Device FQR ID”: ″Local MSTP Field Bus.JCI-5″,</entry></row><row><entry>  ″Device Model″: ″VZC100″,</entry></row><row><entry>  ″Equipment and Control Systems″: [{</entry></row><row><entry>   ″Control System Name″: ″Verasys Zoning System″,</entry></row><row><entry>   ″Control System FQR ID″: ″Local MSTP Field Bus.JCI-5.Verasys Zone Coordinator″,</entry></row><row><entry>   ″Control System Template″: ″Equipment_Verasys_Zone_Coordinator_v1_1.0.0.1003″,</entry></row><row><entry>   ″Control System Alarm TS ID”: “Alarm-TS-1”,</entry></row><row><entry>   ″Schedules″: [{</entry></row><row><entry>    ″Schedule FQR ID”: ″Local MSTP Field Bus.JCI-5.Schedule″,</entry></row><row><entry>    ″Schedule Config Ref″: “SchedConfig1”</entry></row><row><entry>   }] },</entry></row><row><entry>   {</entry></row><row><entry>   ″Equipment Name″: ″Sheldons Office″,</entry></row><row><entry>   ″Equipment FQR ID”: ″Local MSTP Field Bus.JCI-5.Zone-1″,</entry></row><row><entry>   ″Equipment Template″: ″Equipment_Verasys_Zone_v1_1.0.0.4023″,</entry></row><row><entry>   “Equipment Alarm TS ID”: “Alarm-TS-2”</entry></row><row><entry>   }, {</entry></row><row><entry>   ″Equipment Name″: ″Office Area RTU″,</entry></row><row><entry>   ″Equipment FQR ID”: ″Local MSTP Field Bus.JCI-5.York RTU″,</entry></row><row><entry>   ″Equipment Template″: ″Equipment_York_RTU_v1_2.0.0.2042″,</entry></row><row><entry>   “Equipment Alarm TS ID”: “Alarm-TS-3”</entry></row><row><entry>   }, {</entry></row><row><entry>   ″Equipment Name″: ″Pennys Office″,</entry></row><row><entry>   ″Equipment FQR ID”: ″Local MSTP Field Bus.JCI-5.Zone-2″,</entry></row><row><entry>   ″Equipment Template″: ″Equipment_Verasys_Zone_v1_1.0.0.4023″,</entry></row><row><entry>   “Equipment Alarm TS ID”: “Alarm-TS-4”</entry></row><row><entry>   } ] }, {</entry></row><row><entry>  ″Device Name″: ″Conference Room Zoning System″,</entry></row><row><entry>  ″Device FQR ID”: ″Local MSTP Field Bus.JCI-6″,</entry></row><row><entry>  ″Device Model″: ″VZC100″,</entry></row><row><entry>  ″Equipment and Control Systems″: [{</entry></row><row><entry>   ″Control System Name″: ″Verasys Zoning System″,</entry></row><row><entry>   ″Control System FQR ID”: ″Local MSTP Field Bus.JCI-6.Verasys Zone Coordinator″,</entry></row><row><entry>   ″Control System Template″: ″Equipment_Verasys_Zone_Coordinator_v1_1.0.0.1003″,</entry></row><row><entry>   ″Control System Alarm TS ID”: “Alarm-TS-5”,</entry></row><row><entry>   ″Schedules″: [{</entry></row><row><entry>   ″Schedule FQR ID”: ″Local MSTP Field Bus.JCI-6.Schedule″,</entry></row><row><entry>   ″Schedule Config Ref″: “SchedConfig3”</entry></row><row><entry>   }] }, {</entry></row><row><entry>   ″Equipment Name″: ″B7F3 N Conf″,</entry></row><row><entry>   ″Equipment FQR ID”: ″Local MSTP Field Bus.JCI-6.Zone-1″,</entry></row><row><entry>   ″Equipment Template″: ″Equipment_Verasys_Zone_v1_1.0.0.4023″,</entry></row><row><entry>   ″Equipment Alarm TS ID”: “Alarm-TS-6”</entry></row><row><entry>  }, {</entry></row><row><entry>   “Equipment Name”: “B7F4 N Conf”,</entry></row><row><entry>   “Equipment FQR ID”: “Local MSTP Field Bus.JCI-6.Zone-2”,</entry></row><row><entry>   “Equipment Template”: “Equipment_Verasys_Zone_v1_1.0.0.4023”,</entry></row><row><entry>   “Equipment Alarm TS ID”: “Alarm-TS-7”</entry></row><row><entry>   }, {</entry></row><row><entry>   ″Equipment Name″: ″Conference Room RTU″,</entry></row><row><entry>   ″Equipment FQR ID”: ″Local MSTP Field Bus.JCI-6.York RTU″,</entry></row><row><entry>   ″Equipment Template″: ″Equipment_York_RTU_v1_2.0.0.2042″,</entry></row><row><entry>   ″Equipment Alarm TS ID”: “Alarm-TS-8”</entry></row><row><entry>   }]</entry></row><row><entry>  }, {</entry></row><row><entry>   ″Device Name″: ″Gym″,</entry></row><row><entry>   ″Device FQR ID”: ″Local MSTP Field Bus.JCI-8″,</entry></row><row><entry>   ″Device Model″: ″SE_SPU1001″,</entry></row><row><entry>   ″Equipment and Control Systems″: [{</entry></row><row><entry>   ″Equipment Name″: ″Gym RTU″,</entry></row><row><entry>   ″Equipment FQR ID”: ″Local MSTP Field Bus.JCI-8.York RTU″,</entry></row><row><entry>   ″Equipment Template″: ″Equipment_York_RTU_v1_2.0.0.2042″,</entry></row><row><entry>   ″Equipment Alarm TS ID”: “Alarm-TS-9”,</entry></row><row><entry>   ″Schedules″: [{</entry></row><row><entry>    ″Schedule FQR ID”: ″Local MSTP Field Bus.JCI-8.Schedule″,</entry></row><row><entry>    ″Schedule Config Ref″: “SchedConfig1”</entry></row><row><entry>   }] }] }, {</entry></row><row><entry>   ″Device Name″: ″Lobby″,</entry></row><row><entry>   ″Device FQR ID”: ″Local MSTP Field Bus.JCI-9″,</entry></row><row><entry>   ″Device Model″: ″PEAK18″,</entry></row><row><entry>   ″Equipment and Control Systems″: [{</entry></row><row><entry>   ″Equipment Name″: ″Lobby Occupied Lighting″,</entry></row><row><entry>   ″Equipment FQR ID”: ″Local MSTP Field Bus.JCI-9.Lighting Zone 1″,</entry></row><row><entry>   ″Equipment Template″: ″Equipment_Lighting_Controller_v1_1.0.0.1073″,</entry></row><row><entry>   ″Equipment Alarm TS ID”: “Alarm-TS-10”,</entry></row><row><entry>   ″Schedules″: [{</entry></row><row><entry>   ″Schedule FQR ID”: ″Local MSTP Field Bus.JCI-9.Schedule 1″,</entry></row><row><entry>   ″Schedule Config Ref″: “SchedConfig2”</entry></row><row><entry>   }, {</entry></row><row><entry>   ″Schedule FQR ID”: ″Local MSTP Field Bus.JCI-9.Schedule 2″,</entry></row><row><entry>   ″Schedule Config Ref″: ″SchedConfig4″</entry></row><row><entry>   }] }, {</entry></row><row><entry>   ″Equipment Name″: ″Lobby After Hours Lighting″,</entry></row><row><entry>   ″Equipment FQR ID”: ″Local MSTP Field Bus.JCI-9.Lighting Zone 2″,</entry></row><row><entry>   ″Equipment Template″: ″Equipment_Lighting_Controller_v1_1.0.0.1073″</entry></row><row><entry>   ″Equipment Alarm TS ID”: “Alarm-TS-11”</entry></row><row><entry>  }, {</entry></row><row><entry>   ″Equipment Name″: ″Lobby Weekend Lighting″,</entry></row><row><entry>   ″Equipment FQR ID”: ″Local MSTP Field Bus.JCI-9.Lighting Zone 3″,</entry></row><row><entry>   ″Equipment Template″: ″Equipment_Lighting_Controller_v1_1.0.0.1073″</entry></row><row><entry>   ″Equipment Alarm TS ID”: “Alarm-TS-12”</entry></row><row><entry>  }] }, {</entry></row><row><entry>  ″Device Name″: ″Showcase″,</entry></row><row><entry>  ″Device FQR ID”: ″Local MSTP Field Bus.JCI-10″,</entry></row><row><entry>  ″Device Model″: ″SE-TEC3000-0″,</entry></row><row><entry>  ″Equipment and Control Systems″: [{</entry></row><row><entry>   ″Equipment Name″: ″Showcase Thermostat″,</entry></row><row><entry>   ″Equipment FQR ID”: ″Local MSTP Field Bus.JCI-10.TEC″,</entry></row><row><entry>   ″Equipment Template″: ″Equipment_Advanced_Control_Status_v1_3.0.0.1017_TEC″,</entry></row><row><entry>   ″Equipment Alarm TS ID”: “Alarm-TS-13”,</entry></row><row><entry>   ″Schedules″: [{</entry></row><row><entry>   ″Schedule FQR ID”: ″Local MSTP Field Bus.JCI-10.Schedule″,</entry></row><row><entry>   ″Schedule Config Ref″: “SchedConfig2”</entry></row><row><entry>   }] }] }] }] } }</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">APPENDIX B</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Bound List Example</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>{</entry></row><row><entry> “Bound”: [</entry></row><row><entry>   {“FQR ID”: “Local MSTP Field Bus.JCI-5.Zone-1:7021”, “Time</entry></row><row><entry>Series ID”: “Bound-TS-1”},</entry></row><row><entry>   {“FQR ID ”: “Local MSTP Field Bus.JCI-5.Zone-2:7021”, “Time</entry></row><row><entry>Series ID”: “Bound-TS-2”},</entry></row><row><entry>   {“FQR ID ”: “Local MSTP Field Bus.JCI-8.York RTU.HVAC</entry></row><row><entry>Zone:8888”, “Time Series ID”: “Bound-TS-3”}</entry></row><row><entry>   ]</entry></row><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0314Below is a portion of a equipment model template for a thermostat controller. Property <b>7000</b> is of Float data type, and Property <b>7004</b> is of Enum data type.

0000<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">APPENDIX C</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Equipment Model Template Example</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry>{</entry></row><row><entry /><entry> “Version”: “3.0.0.1017_TEC”,</entry></row><row><entry /><entry> “Template”: [</entry></row><row><entry /><entry> {</entry></row><row><entry /><entry>  “-type”: 0,</entry></row><row><entry /><entry>  “-subtype”: 38,</entry></row><row><entry /><entry>  “-dictionary”: “1.0.0.1664”,</entry></row><row><entry /><entry>  “-name”: “Advanced Control Status”,</entry></row><row><entry /><entry>  “-description”: “Advanced Control Status Template”,</entry></row><row><entry /><entry>  “-ID”: “Equipment_Advanced_Control_Status_v1”,</entry></row><row><entry /><entry>  “-presentValueAttributeId”: 7000,</entry></row><row><entry /><entry>  “-PropertyList”: {</entry></row><row><entry /><entry>  “-Property”: [</entry></row><row><entry /><entry>   {</entry></row><row><entry /><entry>   “-ID”: 7000,</entry></row><row><entry /><entry>   “-Required”: 1,</entry></row><row><entry /><entry>   “-WritableFlag”: 0,</entry></row><row><entry /><entry>   “-Name”: {</entry></row><row><entry /><entry>    “-setId”: 1675,</entry></row><row><entry /><entry>    “-value”: 574</entry></row><row><entry /><entry>   },</entry></row><row><entry /><entry>   “-DataType”: 4,</entry></row><row><entry /><entry>   “-IPUnits”: {</entry></row><row><entry /><entry>    “-setId”: 507,</entry></row><row><entry /><entry>    “-value”: 98</entry></row><row><entry /><entry>   },</entry></row><row><entry /><entry>   “-SIUnits”: {</entry></row><row><entry /><entry>    “-setId”: 507,</entry></row><row><entry /><entry>    “-value”: 98</entry></row><row><entry /><entry>   },</entry></row><row><entry /><entry>   “-IPDisplayPrecision”: 6,</entry></row><row><entry /><entry>   “-SIDisplayPrecision”: 6</entry></row><row><entry /><entry>   },</entry></row><row><entry /><entry>   {</entry></row><row><entry /><entry>   “-ID”: 7004,</entry></row><row><entry /><entry>   “-Required”: 1,</entry></row><row><entry /><entry>   “-WritableFlag”: 0,</entry></row><row><entry /><entry>   “-Name”: {</entry></row><row><entry /><entry>    “-setId”: 1675,</entry></row><row><entry /><entry>    “-value”: 582</entry></row><row><entry /><entry>   },</entry></row><row><entry /><entry>   “-DataType”: 9,</entry></row><row><entry /><entry>   “-StringsetId”: 854</entry></row><row><entry /><entry>   },</entry></row><row><entry /><entry>...</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">APPENDIX D</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Command Example</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>Write Property Command - Float Data Type</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry> “commandRef”: <someUniqueMessageId>,</entry></row><row><entry /><entry> “commandName”: “writeProperty”,</entry></row><row><entry /><entry> “commandParameters”: {</entry></row><row><entry /><entry> “propertyToWrite”: {</entry></row><row><entry /><entry>  “networkReference”: “LocalFieldBus”,</entry></row><row><entry /><entry>  “deviceReference”: “JCI-12”,</entry></row><row><entry /><entry>  “objectReference”: “TEC.Setpoints”,</entry></row><row><entry /><entry>  “propertyId”: 7000 },</entry></row><row><entry /><entry> “valueToWrite”: 73.3,</entry></row><row><entry /><entry> “dataType”: 4,</entry></row><row><entry /><entry> “units”: 64</entry></row><row><entry /><entry> }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>Write Property Command - Enum Data Type</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry> “commandRef”: <someUniqueMessageId>,</entry></row><row><entry /><entry> “commandName”: “writeProperty”,</entry></row><row><entry /><entry> “commandParameters”: {</entry></row><row><entry /><entry> “propertyToWrite”: {</entry></row><row><entry /><entry>  “networkReference”: “LocalFieldBus”,</entry></row><row><entry /><entry>  “deviceReference”: “JCI-17”,</entry></row><row><entry /><entry>  “objectReference”: “TEC.Equipment Setup”,</entry></row><row><entry /><entry>  “propertyId”: 8012 },</entry></row><row><entry /><entry> “valueToWrite”: 1,</entry></row><row><entry /><entry> “dataType”: 9,</entry></row><row><entry /><entry> “enumSet”: 1684</entry></row><row><entry /><entry> }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>Get Equipment Model Template Command</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry> “commandRef”: <someUniqueMessageId>,</entry></row><row><entry /><entry> “commandName”: “getDataModelTemplate”,</entry></row><row><entry /><entry> “commandParameters”: { “TemplateID”:</entry></row><row><entry /><entry> “Equipment_York_RTU_v1_2.0.0.2042” }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>Schedule Config Change Command</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry> “commandRef”: <someUniqueMessageId>,</entry></row><row><entry /><entry> “commandName”: “scheduleConfigChange”,</entry></row><row><entry /><entry> “commandParameters”: {</entry></row><row><entry /><entry> “scheduleConfigRef”: <someGUID>,</entry></row><row><entry /><entry> “weeklySchedule”: { <weekly schedule in same json schema as</entry></row><row><entry /><entry> schedule config> }</entry></row><row><entry /><entry> }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0315The first schedule configuration is for a sync schedule, and the second schedule configuration is for an equipment schedule (i.e., schedule that resides in equipment <b>1002</b> and is not synchronized with the schedule sync of system manager <b>302</b>).

0000<tables id="TABLE-US-00008" num="00008"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">APPENDIX D</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Schedule Configuration Example</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>Sync Schedule</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry> “type”: “Sync”,</entry></row><row><entry /><entry> “synchronized schedules”: [</entry></row><row><entry /><entry>  { “networkReference”: “LocalFieldBus”,</entry></row><row><entry /><entry>   “deviceReference”: “JCI-4”,</entry></row><row><entry /><entry>   “objectReference”: “Schedule 1” } ],</entry></row><row><entry /><entry> “weekly schedule”: {</entry></row><row><entry /><entry>  { “sunday”: [</entry></row><row><entry /><entry>   { “time”: {“hour”: 8, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 12, “minute”: 0}, “value”: 1 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 13, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 17, “minute”: 0}, “value”: 1 }</entry></row><row><entry /><entry>   ] },</entry></row><row><entry /><entry>  { “monday”: [</entry></row><row><entry /><entry>   { “time”: {“hour”: 8, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 17, “minute”: 0}, “value”: 1 }</entry></row><row><entry /><entry>   ] },</entry></row><row><entry /><entry>  { “tuesday”: [</entry></row><row><entry /><entry>   { “time”: {“hour”: 8, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 17, “minute”: 0}, “value”: 1 }</entry></row><row><entry /><entry>   ] },</entry></row><row><entry /><entry>  { “wednesday”: [</entry></row><row><entry /><entry>   { “time”: {“hour”: 8, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 17, “minute”: 0}, “value”: 1 }</entry></row><row><entry /><entry>   ] },</entry></row><row><entry /><entry>  { “thursday”: [</entry></row><row><entry /><entry>   { “time”: {“hour”: 8, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 17, “minute”: 0}, “value”: 1 }</entry></row><row><entry /><entry>   ] },</entry></row><row><entry /><entry>  { “friday”: [</entry></row><row><entry /><entry>   { “time”: {“hour”: 8, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 17, “minute”: 0}, “value”: 1 }</entry></row><row><entry /><entry>   ] },</entry></row><row><entry /><entry>  { “saturday”: [</entry></row><row><entry /><entry>   { “time”: {“hour”: 10, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 15, “minute”: 0}, “value”: 1 }</entry></row><row><entry /><entry>   ] }</entry></row><row><entry /><entry> }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>Equipment Schedule</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry> “type”: “Equipment”,</entry></row><row><entry /><entry> “properties scheduled”: [</entry></row><row><entry /><entry>  { “networkReference”: “LocalFieldBus”,</entry></row><row><entry /><entry>   “deviceReference”: “JCI-4”,</entry></row><row><entry /><entry>   “objectReference”: “York RTU.HVAC Zone”,</entry></row><row><entry /><entry>   “propertyId”: 7001 } ],</entry></row><row><entry /><entry> “weekly schedule”: {</entry></row><row><entry /><entry>  { “sunday”: [</entry></row><row><entry /><entry>   { “time”: {“hour”: 8, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 12, “minute”: 0}, “value”: 1 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 13, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 17, “minute”: 0}, “value”: 1 }</entry></row><row><entry /><entry>   ] },</entry></row><row><entry /><entry>  { “monday”: [</entry></row><row><entry /><entry>   { “time”: {“hour”: 8, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 17, “minute”: 0}, “value”: 1 }</entry></row><row><entry /><entry>   ] },</entry></row><row><entry /><entry>  { “tuesday”: [</entry></row><row><entry /><entry>   { “time”: {“hour”: 8, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 17, “minute”: 0}, “value”: 1 }</entry></row><row><entry /><entry>   ] },</entry></row><row><entry /><entry>  { “wednesday”: [</entry></row><row><entry /><entry>   { “time”: {“hour”: 8, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 17, “minute”: 0}, “value”: 1 }</entry></row><row><entry /><entry>   ] },</entry></row><row><entry /><entry>  { “thursday”: [</entry></row><row><entry /><entry>   { “time”: {“hour”: 8, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 17, “minute”: 0}, “value”: 1 }</entry></row><row><entry /><entry>   ] },</entry></row><row><entry /><entry>  { “friday”: [</entry></row><row><entry /><entry>   { “time”: {“hour”: 8, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 17, “minute”: 0}, “value”: 1 }</entry></row><row><entry /><entry>   ] },</entry></row><row><entry /><entry>  { “saturday”: [</entry></row><row><entry /><entry>   { “time”: {“hour”: 10, “minute”: 0}, “value”: 0 },</entry></row><row><entry /><entry>   { “time”: {“hour”: 15, “minute”: 0}, “value”: 1 }</entry></row><row><entry /><entry>   ] }</entry></row><row><entry /><entry> }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Configuration of Exemplary Embodiments

0316The 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.

0317The 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. 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.

0318Although 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.

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