UNIFIED BUILDING MANAGEMENT SYSTEM WITH MECHANICAL ROOM CONTROLS

Abstract

A building management system including building equipment operable to affect a variable state or condition of a building and a control system including a processing circuit. The processing circuit is configured to receive asset data relating to operation of the building equipment. The processing circuit is configured to identify a building device of the building equipment in a fault state based on the asset data. The processing circuit is configured to generate a work order in response to identifying the building device in the fault state. The work order indicates a required maintenance action and a maintenance time window. The processing circuit is configured to automatically populate fields of the work order based on the fault state. The processing circuit is configured to provide the work order to a user device.

Description

CROSS-REFERENCE TO RELATED PATENT APPLICATION

This application claims the benefit of and priority to U.S. Provisional Patent Application No. 62/746,939 filed Oct. 17, 2018, incorporated herein by reference in its entirety.

BACKGROUND

The present disclosure relates generally to building domain systems (BDSs), and in particular building domain systems that may be present in a mechanical room of a building. A BDS is, in general, a system configured to control, monitor, and manage devices in or around a building or building area. As used herein, “devices” includes any building equipment, devices, apparatuses, sensors, etc. that provide measurements or data relating to a space or that can be controlled to change the condition of a space (e.g., light level, locked/unlocked, temperature, humidity). Accordingly, as used herein “devices” includes HVAC equipment (e.g., air handling units, chillers), thermostats, light fixtures, locks, sensors (detectors for smoke, heat, gas, flames, carbon monoxide, glass breaks, motion, and light; sensor that measure temperature, humidity, carbon dioxide, ambient light, and occupancy; presence/identity sensors (e.g., card readers, RFID receivers); cameras (e.g., video capture, image capture) and microphones), and other apparatuses (e.g., sound systems, blinds, appliances, garage doors, beds, televisions). Devices may also be referred to herein as environmental control assets.

Conventionally, a BDS is a domain-specific system that manages equipment of a particular building domain, for example a HVAC system, a security system, a lighting system, or a fire alerting system. Although in some cases multiple domain-specific systems have been placed in communication with one another as discussed below, such integrated systems do not capture the full potential of interoperability, functionality, and interdependence between building devices.

Furthermore, conventional BDS are focused on particular domains and types of devices, rather than the missions and functions of a place (e.g., a building, a campus) or a space (e.g., a floor, room, hallway, etc. included in a place) or the events occurring at such spaces and places. A disconnect therefore exists in conventional systems between the way occupants think about and utilize spaces and places and the way BDS are operated and controlled. Additionally, the collection of data from sensors and other data sources in conventional BDS places substantial limits and restrictions on the usefulness of that data, which may prevent users from acquiring the information needed for successful energy management, maintenance, or other building management and planning decision-making.

SUMMARY

One implementation of the present disclosure is a building management system, according to some embodiments. The building management system includes building equipment operable to affect a variable state or condition of a building, according to some embodiments. The building management system includes a control system including a processing circuit, according to some embodiments. The processing circuit is configured to receive asset data relating to operation of the building equipment, according to some embodiments. The processing circuit is configured to identify a building device of the building equipment in a fault state based on the asset data, according to some embodiments. The processing circuit is configured to generate a work order in response to identifying the building device in the fault state, according to some embodiments. The work order indicates a required maintenance action and a maintenance time window, according to some embodiments. The processing circuit is configured to automatically populate fields of the work order based on the fault state, according to some embodiments. The processing circuit is configured to provide the work order to a user device, according to some embodiments.

In some embodiments, the processing circuit is further configured to schedule access permissions for a technician based on the work order.

In some embodiments, the processing circuit is further configured to retrieve troubleshooting instructions related to the building device. The processing circuit further configured to provide the troubleshooting instructions to the user device, according to some embodiments. The work order is generated responsive to an indication that a user is unable to fix the fault state based on the troubleshooting instructions, according to some embodiments.

In some embodiments, the fault state is identified based on a determination that the building is not achieving a mode. The mode corresponds to at least one of an operational mission for the building, a job-to-be-done in the building, or an event occurring in the building, according to some embodiments.

In some embodiments, the processing circuit is further configured to generate a maintenance alert indicating the fault state. The processing circuit is further configured to provide the maintenance alert to the user device, according to some embodiments.

In some embodiments, at least a portion of the work order is automatically populated based on the asset data.

In some embodiments, the processing circuit is further configured to log maintenance information provided by a technician. The maintenance information describes an operating state of the building device, according to some embodiments. The processing circuit is further configured to predict a change in a mode of the building based on the maintenance information, according to some embodiments.

Another implementation of the present disclosure is a method for maintaining building equipment, according to some embodiments. The method includes receiving asset data relating to operation of the building equipment, according to some embodiments. The building equipment is operable to affect a variable state or condition of a building, according to some embodiments. The method includes identifying a building device of the building equipment in a fault state based on the asset data, according to some embodiments. The method includes generating a work order in response to identifying the building device in the fault state, according to some embodiments. The work order indicates a required maintenance action and a maintenance time window, according to some embodiments. The method includes automatically populating fields of the work order based on the fault state, according to some embodiments. The method includes providing the work order to a user device, according to some embodiments.

In some embodiments, the method includes scheduling access permissions for a technician based on the work order.

In some embodiments, the method includes retrieving troubleshooting instructions related to the building device. The method includes providing the troubleshooting instructions to the user device, according to some embodiments. The work order is generated responsive to an indication that a user is unable to fix the fault state based on the troubleshooting instructions, according to some embodiments.

In some embodiments, the fault state is identified based on a determination that the building is not achieving a mode. The mode corresponds to at least one of an operational mission for the building, a job-to-be-done in the building, or an event occurring in the building, according to some embodiments.

In some embodiments, the method includes generating a maintenance alert indicating the fault state. The method includes providing the maintenance alert to the user device, according to some embodiments.

In some embodiments, at least a portion of the work order is automatically populated based on the asset data.

In some embodiments, the method includes logging maintenance information provided by a technician. The maintenance information describes an operating state of the building device, according to some embodiments. The method includes predicting a change in a mode of the building based on the maintenance information, according to some embodiments.

Another implementation of the present disclosure is a building management system, according to some embodiments. The building management system includes building equipment operable to affect a variable state or condition of a building, according to some embodiments. The building management system includes a control system including a processing circuit, according to some embodiments. The processing circuit is configured to obtain a work order for the building equipment, according to some embodiments. The work order identifies a location of the building equipment and a time at which maintenance is to be performed on the building equipment, according to some embodiments. The processing circuit is configured to schedule access permissions for a service technician based on the work order, according to some embodiments. The access permissions authorize the service technician to access the location of the building equipment at the time at which the maintenance is to be performed, according to some embodiments.

In some embodiments, the processing circuit is further configured to generate the work order in response identifying the building equipment is in a fault state.

In some embodiments, the processing circuit is further configured to obtain information related to the building equipment from a knowledge base. The processing circuit is further configured to identify the service technician at the location during the time at which the maintenance is to be performed, according to some embodiments. The processing circuit is further configured to provide the information related to the building equipment to the service technician in response to identifying the service technician, according to some embodiments.

In some embodiments, the processing circuit is further configured to generate wayfinding information to facilitate guidance of the service technician to the building equipment. The processing circuit is further configured to provide the wayfinding information to a second user device of the service technician, according to some embodiments.

In some embodiments, the processing circuit is further configured to perform a pre-maintenance action based on the work order. The pre-maintenance action includes at least one of scheduling lighting equipment to be operated during the time at which the maintenance is to be performed or scheduling heating, ventilation, or air conditioning (HVAC) equipment to operate during the time at which the maintenance is to be performed, according to some embodiments.

In some embodiments, the processing circuit is further configured to predict how the maintenance will affect a mode of the building. The mode corresponds to at least one of an operational mission for the building, a job-to-be-done in the building, or an event occurring in the building, according to some embodiments.

This summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the devices or processes described herein will become apparent in the detailed description set forth herein, taken in conjunction with the accompanying figures, wherein like reference numerals refer to like elements.

BRIEF DESCRIPTION OF THE DRAWINGS

Various objects, aspects, features, and advantages of the disclosure will become more apparent and better understood by referring to the detailed description taken in conjunction with the accompanying drawings, in which like reference characters identify corresponding elements throughout. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements.

FIG. 1 is a drawing of a building equipped with a HVAC system, according to some embodiments.

FIG. 2 is a block diagram of a waterside system which can be used to serve the heating or cooling loads of the building of FIG. 1, according to some embodiments.

FIG. 3 is a block diagram of an airside system which can be used to serve the heating or cooling loads of the building of FIG. 1, according to some embodiments.

FIG. 4A is a diagram illustrating the concepts of occupants, spaces, places, and devices, according to some embodiments.

FIG. 4B is a visualization of spaces and places, according to some embodiments.

FIG. 4C is an example of a conventional collection of building domain systems for a building, according to some embodiments.

FIG. 5A is a block diagram of a conventional set of building domain systems.

FIG. 5B is a block diagram of a conventional integration system for use with the building domain systems of FIG. 5A.

FIG. 6 is a diagram of a unified building management system with space control, according to some embodiments.

FIG. 7A is a block diagram of a unified control architecture for building equipment including a unified control engine, according to some embodiments.

FIG. 7B is a block diagram of the unified control engine of FIG. 7A in greater detail and including a maintenance module, according to some embodiments.

FIG. 7C is a block diagram of the maintenance module of FIG. 7B in greater detail, according to some embodiments.

FIG. 8A is an illustration of an overview view in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 8B is an illustration detailing the illustration of FIG. 8A in further detail, according to some embodiments.

FIG. 9 is an illustration of a technician access view in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 10 is an illustration of an edit contact view in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 11 is an illustration of a permissions menus screen in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 12 is an illustration of a mobile application features screen in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 13 is an illustration of a locations permissions screen in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 14 is an illustration of an access type screen in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 15 is an illustration of a history view in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 16 is an illustration of a schedule view in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 17 is an illustration of an equipment view in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 18A is an illustration of an expanded equipment card in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 18B is an illustration of the expanded equipment card of FIG. 18A in greater detail, according to some embodiments.

FIG. 19 is an illustration of a knowledge base view in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 20 is an illustration of a live knowledge base view in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 21 is an illustration of a video stream view in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 22 is an illustration of an alert view in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 23 is an illustration of a troubleshooting view in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 24 is an illustration of a work order request view in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 25 is an illustration of a work order view in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 26 is an illustration of a notes view in a mobile application for use with the UBMS of FIGS. 6-7C, according to some embodiments.

FIG. 27 is a flowchart of an example process of servicing devices of building equipment using the mobile application of FIGS. 8-26, according to some embodiments.

DETAILED DESCRIPTION

Introduction

People experience the spaces and places with which they engage in many ways: they work in spaces and places, reside in spaces and places, entertain themselves in spaces and places, shop in spaces and places, heal in spaces and places, dine in spaces and places, etc., experiencing all aspects of life in spaces and places. People think about spaces and places from the perspective of these experiences: a space or a place is somewhere an event occurs, a job must be done, a mission is supported, or some other experience plays out. In the ideal scenario, spaces, places, and the devices that serve the spaces and places would seamlessly and intuitively support the goals, missions, needs, desires, and perspectives of the people experiencing those spaces and places.

However, a disconnect exists between conventional building domain systems and the way people see spaces and places. Conventional devices, and systems of conventional devices, are often designed, chosen, and operated to focus primarily on the needs of the devices or systems themselves. A space or place is typically served by many devices across many domains, for example HVAC, fire, access, security, lighting, etc. The devices of the various domains are typically independent of one another, with devices and systems for each domain designed, chosen, and installed with the focus on the particular domain. Each of the various building domain systems may be operated independently, achieving a limited impact on the way a person experiences a space or place. Interactions with each domain are often limited to terms familiar to that domain (e.g., HVAC systems are set to temperature setpoints, lighting systems turn on and off lights, access systems lock and unlock doors), rather than in terms of what missions, goals, tasks, or events that an occupant desires a space or place to support. This results in disjointed, time-consuming, and unfulfilling experiences for people attempting to use a space or place.

The systems and methods described herein provide an innovative space- and place-centric approach that seamlessly aligns the way that people think about and experience spaces and places with the way that devices are controlled to support those experiences. The space- and place-centric approach may eliminate the barriers between the way people conceive of the missions of spaces and places, the jobs people need to complete in spaces and places, events that occur in spaces and places, etc. and the way that the devices that support those missions, jobs, events, etc. are chosen, designed, and controlled. The way that data is collected and processed relating to spaces and places, for example utilization metrics about spaces and places, may be similarly aligned with the missions and purposes of the spaces and places.

These advantages may be supported across any of the extensive variety of types of spaces and places with which people engage, tuned precisely to the missions and purposes of each particular space or place. For example, offices, office buildings, retail stores, warehouses, hospitals, patient rooms, operating rooms, waiting rooms, movie theaters, stadiums, arenas, malls, restaurants, hotels, apartments, factories, gymnasiums, classrooms, libraries, and/or any other type of space or place experienced by people may have its own purposes, missions, and jobs and events to support. The systems and methods described herein may contemplate all such spaces and places and may allow for efficient installation, updates, data collection and controls of devices well-suited for all such spaces and places and any combination of spaces and places.

Several features, summarized here and described in detail below with reference to the FIGURES, facilitate this space- and place-centric approach. To start, the sensors, networks, controllers, and other systems in the space- and place-centric approach may be domain-agnostic. That is, the systems and methods disclosed herein may eliminate the barriers between domain-specific systems, unifying all domains into a unified control system. Although the space- and place-centric approach may be implemented by integrating or otherwise facilitating communication between building domain systems, in some embodiments the approach is implemented using a unified building management system (UBMS). A UBMS may place all devices, sensors, etc. in a single system, eliminating barriers between domains and facilitating the exchange of data, controls, resources, etc. across all components of the UBMS. All sensors and devices that can be used to influence the way a person experiences a space or place may be unified in the UBMS. Thus, the UBMS may allow all devices serving a space or place to be controlled as a unified group that supports a mission, purpose, job, or event for the space or place.

Next, space profiles for the spaces and place profiles for the places can be used to facilitate the space- and place-centric approach. Each space or place profile may define many aspects of how the space or place is designed, controlled, perceived, and used, and may include all or substantially all of the information needed to control the space or place across domains and to collect and analyze data relating to the space or place. Space and place profiles can be designed and created based on how people experience each space and place, including the jobs people need to accomplish in a space or place, the missions the space or place supports, the purpose of a space or place, and/or events that may occur in the space or place. Different types of spaces and places may have different space or place profiles specific to that type of space or place, such that each space or place profile reflects the needs of that particular space or place.

Space and place profiles can be easily loaded onto control systems for spaces and places (e.g., onto a DBMS) to easily and efficiently align systems and devices with the purposes, missions, goals, etc. of the spaces and places represented by the profiles. Further, space and place profiles can be easily updated or switched to respond to changes to the space or place. For example, when a place is remodeled or reimagined such that a space that was formerly used as one type of space (e.g., an office) is reimagined as another type of space (e.g., a conference room), the space profile for that space can be easily switched from an “office” space profile to a “conference room” space profile. Space-centric control can thus be immediately aligned with the new purposes, missions, functions, and goals of the space. Space and place profiles thereby provide efficient and adaptable support for the space- and place-centric control approach described herein.

Each of the space profiles that can be assigned to a given space may be associated with a particular type of space or use of the space (e.g., office, conference room, cafeteria, etc.) and may include settings that facilitate a function or purpose of that type of space or use of the space. The settings provided by a given space profile may include settings for various types of equipment that serve the space across multiple equipment domains (e.g., settings for HVAC equipment, settings for lighting equipment, settings for A/V equipment, etc.). For example, the “office” space profile may include a first set of settings for HVAC equipment, lighting equipment, A/V equipment, and/or other types of equipment that serve the space that cause the equipment to be controlled in a manner that facilitates usage of the space as an office. Conversely, the “conference room” space profile may include a second set of settings for the HVAC equipment, lighting equipment, A/V equipment, and/or other types of equipment that serve the space that cause the equipment to be controlled in a manner that facilitates usage of the space as a conference room.

Each space profile for a given space may include a different set of settings for some or all of the equipment that serve that space. For example, the HVAC settings defined by an “office” space profile may cause HVAC equipment that serve the space provide sufficient airflow and/or heating or cooling for a relatively small number of people occupying the space (e.g., one person or a small group of people), whereas the HVAC settings defined by a “conference room” space profile may cause the same HVAC equipment to provide a relatively greater amount of airflow or heating or cooling for a greater number of people occupying the space (e.g., 2-10 people or a larger group of people). Similarly, the lighting settings defined by the “office” space profile may cause lighting equipment that light the space to provide constant lighting for the space, whereas the lighting settings defined by the “conference room” space profile may cause the lighting equipment to light the space only when the space is occupied. As another example, the occupancy settings defined by the “office” space profile may provide a first occupancy threshold for evaluating whether the space is fully occupied (e.g., one person may fully occupy an office), whereas the occupancy settings defined by the “conference room” space profile may provide a second occupancy threshold for evaluating whether the space is fully occupied (e.g., 10 people may fully occupy a conference room).

In response to switching from the “office” space profile to the “conference room” space profile, the settings provided by the “office” space profile may be replaced with the settings provided by the “conference room” space profile. For example, a space controller may distribute the settings associated with the “conference room” space profile to some or all of the equipment that serve the space, causing the equipment to operate in accordance with the settings defined by the “conference room” space profile. The settings can be distributed to any type of equipment that serve the space, even if the equipment operate across multiple different equipment domains (e.g., HVAC, lighting, A/V, security, IT, etc.).

Next, the space- and place-centric approach allows for control of devices based on modes for the spaces and places. In some embodiments, each mode corresponds to an operational mission for the space or place, a job-to-be-done in the space or place, or an event occurring in the space or place. Each mode may correspond to settings or other commands for the devices in a space or place that control those devices to support the operational mission, the job to be done, or the event. The modes for a space or place may be predefined (e.g., by a user, automatically by a system, etc.) and stored in the space or place profile for the space or place profile, and, like the space or place profile, can be updated, supplemented, altered, or otherwise easily changed as needed to adapt to new uses of a space or place. Mode changes may be triggered based on input from various sensors, specialty systems, user inputs, detected events, etc. to allow for efficient transition between modes precisely as needed by occupants of a space or place. Accordingly, spaces and places, and all devices across all domains, can be controlled to enable people to use the spaces and places in many different ways.

Furthermore, spaces and places may be composable (i.e., a place may be made up of spaces, a space may include spaces, and a place may include places), and the profiles and the modes for the spaces and places can be tuned to take these interrelationships into account. For example, as described in detail herein, a change in mode in one space may be communicated to related spaces and places to allow those spaces and places to adjust as needed to the change. Spaces, places, sensors, devices, and other systems contemplated herein may be coordinated in an amorphous web such that everything works seamlessly together to support people's use of all spaces and places.

Another feature of the space- and place-centric approach described herein is the unification of sensors that serve spaces and places. In traditional systems, each building domain system includes domain-specific sensors that provide data that can only be used by devices of the corresponding domain. To achieve functionality in a second domain that could benefit from the same information captured by that data, additional sensors specific to the second domain traditionally must be installed to serve the second domain. Further, in traditional systems, data from the domains is siloed and cannot be easily combined to verify measurements, generate cross-domain metrics, and provide controls that allow a person to view the space in terms of the purposes or missions of the space.

In the space- and place-centric approach described herein, sensors may be domain-agnostic and may provide data as needed by the space or place regardless of the domain traditionally associated with any sensor or any type of data provided by that sensor. All sensors can be combined in a unified sensor network that provides the data needed by any device, and all devices can use data from any sensor. The devices can be controlled using aggregated data in a way that is agnostic of the source of the data. The sensors best suited for any given space may be used in that space, and different types of sensors can be used within a space or across multiple spaces and places to provide similar data attributes that are used by the devices. Data provided across spaces, including data from a variety of types of sensors, can also be used to enable place-level features like wayfinding or asset tracking. Sensor data from sensor traditionally associated with different domains can be unified into single data points or data series, for example by using one sensor to verify the accuracy of a measurement from another sensor. New sensors can be installed in a plug-and-play manner that allows them to automatically be included in any data calculations, control logic, or application that would benefit from the data from the new sensors. The unification of domain-agnostic sensors described herein thereby greatly enhances and supports the space- and place-centric approach.

In addition to the sources of data being tuned to the needs of each space, the metrics generated for each space may also be chosen to best capture the way people think about particular spaces and places. For example, the space- and place-based approach may facilitate the generation of actual-usage-based space utilization metrics. Different types of spaces can be utilized in different ways, such that the utilization of each space can be quantified in a way that aligns with the way people think about usage of that space. For example, usage of a warehouse may be conceptualized by users based on the volume of the space taken up by stored goods, usage of a restroom may be conceptualized based on the resources (e.g., water, soap, paper towels, toilet paper) consumed by people in the space, and usage of a conference room may be conceptualized based on how many people are in the space, among other possibilities. By aggregating data from across any sensors or other data sources for a space or place and applying that data as suitable for calculating a utilization metric that aligns with how people conceptualize usage of a space, the space- and place-centric approach facilitates the calculation of actual-usage-based utilization metrics. These actual-usage-based utilization metrics can then support improved resource management, energy management, maintenance/restocking/etc. planning, or developing other building management strategies.

Furthermore, as described in detail below, the systems and methods described herein may provide a graphical user interface on a user device (e.g., smartphone, tablet) that allows a user to view and leverage data in the UBMS across various devices. As described in detail below, one embodiment of such a graphical user interface is a mobile application for use by maintenance technicians tasked with monitoring and servicing mechanical rooms in buildings. The combination of the UBMS, a space-centric approach, and the mobile application features described in detail here provide a uniquely-powerful tool for use in monitoring and servicing building equipment in mechanical rooms.

Together, these and other features may seamlessly align the way people think about and experience spaces and places with the way that devices are controlled to support those experiences and the way data is collected relating to those thoughts and experiences. Space- and place-centric control of spaces and places may eliminate translation barriers between the way people conceive of the missions of spaces and places, the jobs people need to complete in spaces and places, events that occur in spaces and places, etc. and the way that devices that support those missions, jobs, events, etc. are chosen, designed, and controlled. The systems and methods described herein can thereby enable intuitive, efficient, and fulfilling interactions between people and spaces and places. Many such features are described in detail in U.S. patent application Ser. No. 15/952,173, filed Apr. 12, 2018, incorporated by reference herein in its entirety, and U.S. patent application Ser. No. 16/132,045, filed Sep. 14, 2018, incorporated by reference herein in its entirety.

Building and HVAC System

Referring now to FIG. 1, a perspective view of a building 10 is shown. Building 10 is served by a BMS. A BMS is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. A BMS can include, for example, a HVAC system, a security system, a lighting system, a fire alerting system, and/or any other system that is capable of managing building functions or devices, or any combination thereof.

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

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

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

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

Waterside System

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

In FIG. 2, waterside system 200 is shown as a central plant having a plurality of subplants 202-212. Subplants 202-212 are shown to include a heater subplant 202, a heat recovery chiller subplant 204, a chiller subplant 206, a cooling tower subplant 208, a hot thermal energy storage (TES) subplant 210, and a cold thermal energy storage (TES) subplant 212. Subplants 202-212 consume resources (e.g., water, natural gas, electricity, etc.) from utilities to serve thermal energy loads (e.g., hot water, cold water, heating, cooling, etc.) of a building or campus. For example, heater subplant 202 can be configured to heat water in a hot water loop 214 that circulates the hot water between heater subplant 202 and building 10. Chiller subplant 206 can be configured to chill water in a cold water loop 216 that circulates the cold water between chiller subplant 206 building 10. Heat recovery chiller subplant 204 can be configured to transfer heat from cold water loop 216 to hot water loop 214 to provide additional heating for the hot water and additional cooling for the cold water. Condenser water loop 218 may absorb heat from the cold water in chiller subplant 206 and reject the absorbed heat in cooling tower subplant 208 or transfer the absorbed heat to hot water loop 214. Hot TES subplant 210 and cold TES subplant 212 may store hot and cold thermal energy, respectively, for subsequent use.

Hot water loop 214 and cold water loop 216 may deliver the heated and/or chilled water to air handlers located on the rooftop of building 10 (e.g., AHU 106) or to individual floors or zones of building 10 (e.g., VAV units 116). The air handlers push air past heat exchangers (e.g., heating coils or cooling coils) through which the water flows to provide heating or cooling for the air. The heated or cooled air can be delivered to individual zones of building 10 to serve thermal energy loads of building 10. The water then returns to subplants 202-212 to receive further heating or cooling.

Although subplants 202-212 are shown and described as heating and cooling water for circulation to a building, it is understood that any other type of working fluid (e.g., glycol, CO2, etc.) can be used in place of or in addition to water to serve thermal energy loads. In other embodiments, subplants 202-212 may provide heating and/or cooling directly to the building or campus without requiring an intermediate heat transfer fluid. These and other variations to waterside system 200 are within the teachings of the present disclosure.

Each of subplants 202-212 can include a variety of equipment configured to facilitate the functions of the subplant. For example, heater subplant 202 is shown to include a plurality of heating elements 220 (e.g., boilers, electric heaters, etc.) configured to add heat to the hot water in hot water loop 214. Heater subplant 202 is also shown to include several pumps 222 and 224 configured to circulate the hot water in hot water loop 214 and to control the flow rate of the hot water through individual heating elements 220. Chiller subplant 206 is shown to include a plurality of chillers 232 configured to remove heat from the cold water in cold water loop 216. Chiller subplant 206 is also shown to include several pumps 234 and 236 configured to circulate the cold water in cold water loop 216 and to control the flow rate of the cold water through individual chillers 232.

Heat recovery chiller subplant 204 is shown to include a plurality of heat recovery heat exchangers 226 (e.g., refrigeration circuits) configured to transfer heat from cold water loop 216 to hot water loop 214. Heat recovery chiller subplant 204 is also shown to include several pumps 228 and 230 configured to circulate the hot water and/or cold water through heat recovery heat exchangers 226 and to control the flow rate of the water through individual heat recovery heat exchangers 226. Cooling tower subplant 208 is shown to include a plurality of cooling towers 238 configured to remove heat from the condenser water in condenser water loop 218. Cooling tower subplant 208 is also shown to include several pumps 240 configured to circulate the condenser water in condenser water loop 218 and to control the flow rate of the condenser water through individual cooling towers 238.

Hot TES subplant 210 is shown to include a hot TES tank 242 configured to store the hot water for later use. Hot TES subplant 210 may also include one or more pumps or valves configured to control the flow rate of the hot water into or out of hot TES tank 242. Cold TES subplant 212 is shown to include cold TES tanks 244 configured to store the cold water for later use. Cold TES subplant 212 may also include one or more pumps or valves configured to control the flow rate of the cold water into or out of cold TES tanks 244.

In some embodiments, one or more of the pumps in waterside system 200 (e.g., pumps 222, 224, 228, 230, 234, 236, and/or 240) or pipelines in waterside system 200 include an isolation valve associated therewith. Isolation valves can be integrated with the pumps or positioned upstream or downstream of the pumps to control the fluid flows in waterside system 200. In various embodiments, waterside system 200 can include more, fewer, or different types of devices and/or subplants based on the particular configuration of waterside system 200 and the types of loads served by waterside system 200.

Airside System

Referring now to FIG. 3, a block diagram of an airside system 300 is shown, according to some embodiments. In various embodiments, airside system 300 may supplement or replace airside system 130 in HVAC system 100 or can be implemented separate from HVAC system 100. When implemented in HVAC system 100, airside system 300 can include a subset of the HVAC devices in HVAC system 100 (e.g., AHU 106, VAV units 116, ducts 112-114, fans, dampers, etc.) and can be located in or around building 10. Airside system 300 may operate to heat or cool an airflow provided to building 10 using a heated or chilled fluid provided by waterside system 200.

In FIG. 3, airside system 300 is shown to include an economizer-type air handling unit (AHU) 302. 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 302 may receive return air 304 from building zone 306 via return air duct 308 and may deliver supply air 310 to building zone 306 via supply air duct 312. In some embodiments, AHU 302 is a rooftop unit located on the roof of building 10 (e.g., AHU 106 as shown in FIG. 1) or otherwise positioned to receive both return air 304 and outside air 314. AHU 302 can be configured to operate exhaust air damper 316, mixing damper 318, and outside air damper 320 to control an amount of outside air 314 and return air 304 that combine to form supply air 310. Any return air 304 that does not pass through mixing damper 318 can be exhausted from AHU 302 through exhaust damper 316 as exhaust air 322.

Each of dampers 316-320 can be operated by an actuator. For example, exhaust air damper 316 can be operated by actuator 324, mixing damper 318 can be operated by actuator 326, and outside air damper 320 can be operated by actuator 328. Actuators 324-328 may communicate with an AHU controller 330 via a communications link 332. Actuators 324-328 may receive control signals from AHU controller 330 and may provide feedback signals to AHU controller 330. 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 324-328), 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 324-328. AHU controller 330 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 324-328.

Still referring to FIG. 3, AHU 302 is shown to include a cooling coil 334, a heating coil 336, and a fan 338 positioned within supply air duct 312. Fan 338 can be configured to force supply air 310 through cooling coil 334 and/or heating coil 336 and provide supply air 310 to building zone 306. AHU controller 330 may communicate with fan 338 via communications link 340 to control a flow rate of supply air 310. In some embodiments, AHU controller 330 controls an amount of heating or cooling applied to supply air 310 by modulating a speed of fan 338.

Cooling coil 334 may receive a chilled fluid from waterside system 200 (e.g., from cold water loop 216) via piping 342 and may return the chilled fluid to waterside system 200 via piping 344. Valve 346 can be positioned along piping 342 or piping 344 to control a flow rate of the chilled fluid through cooling coil 334. In some embodiments, cooling coil 334 includes multiple stages of cooling coils that can be independently activated and deactivated (e.g., by AHU controller 330, by BMS controller 366, etc.) to modulate an amount of cooling applied to supply air 310.

Heating coil 336 may receive a heated fluid from waterside system 200 (e.g., from hot water loop 214) via piping 348 and may return the heated fluid to waterside system 200 via piping 350. Valve 352 can be positioned along piping 348 or piping 350 to control a flow rate of the heated fluid through heating coil 336. In some embodiments, heating coil 336 includes multiple stages of heating coils that can be independently activated and deactivated (e.g., by AHU controller 330, by BMS controller 366, etc.) to modulate an amount of heating applied to supply air 310.

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

In some embodiments, AHU controller 330 operates valves 346 and 352 via actuators 354-356 to modulate an amount of heating or cooling provided to supply air 310 (e.g., to achieve a setpoint temperature for supply air 310 or to maintain the temperature of supply air 310 within a setpoint temperature range). The positions of valves 346 and 352 affect the amount of heating or cooling provided to supply air 310 by cooling coil 334 or heating coil 336 and may correlate with the amount of energy consumed to achieve a desired supply air temperature. AHU 330 may control the temperature of supply air 310 and/or building zone 306 by activating or deactivating coils 334-336, adjusting a speed of fan 338, or a combination of both.

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

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

Client device 368 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 100, its subsystems, and/or devices. Client device 368 can be a computer workstation, a client terminal, a remote or local interface, or any other type of user interface device. Client device 368 can be a stationary terminal or a mobile device. For example, client device 368 can be a desktop computer, a computer server with a user interface, a laptop computer, a tablet, a smartphone, a PDA, or any other type of mobile or non-mobile device. Client device 368 may communicate with BMS controller 366 and/or AHU controller 330 via communications link 372.

Spaces & Places

Referring now to FIG. 4A, a conceptual diagram 400 of some core elements of the space- and place-centric systems and methods described herein is shown, according to some embodiments. In FIG. 4A, occupants 402 are shown to occupy place 408. Occupants 402 may be any person who is in the place 408 and is not limited to individuals who operate the place 408, maintain the place 408, live in the place 408, work in the place 408, etc. Occupants 402 may occupy various spaces 404 within a place. The various spaces 404 of the building may be spaces such as an office space, a gym space, a café space, a lab space, patient rooms, nurses stations, waiting rooms, a classroom space, parking garage, and any other kinds of spaces that may be present in or around a place. The occupants 402 use the various spaces 404 in the place 408 for various uses, purposes, missions, tasks, jobs, situations, etc. The space- and place-centric systems and methods of the present disclosure align control of spaces and places with occupant's purposes and missions in utilizing the spaces and places.

Each physical space may have its own devices 406 and/or may share devices 406 with other spaces in the place 408. Devices 406 include devices across various domains, such as HVAC devices, security devices, lighting devices, access devices, fire devices, etc. The devices 406 may work together to achieve various outcomes in a place, as described in detail below. In general, devices 406 are controlled based on space profiles and place profiles. The place profiles may be a particular data structure that includes properties such as spaces profile for spaces 404 in the place 408, modes and mode logic for controlling devices 406 in the place, and other applications that enable uses for the place. Space profiles include indication of the type of space, modes for that type of space, and attributes of the space, among other features as described in detail below. As described in detail herein, place- and space-profiles can facilitate place- and space-based aggregation of sensor data and control of devices 406.

Referring now to FIG. 4B, a visualization of the concept of spaces and places is shown, according to some embodiments. A campus 410 is shown with seven buildings 412. In the nomenclature used herein, each building 412 can be considered a “place.” The campus 410, made up of multiple places, may also be referred to as a “place”. Each of the seven buildings 412 (“Building 1”, “Building 2”, etc.) include a variety of rooms, floors, or other divisions. As one example, FIG. 4B includes an expanded view 1604 of “Building 1” 412. The expanded view 1604 shows a variety of “spaces” (i.e., floors, areas, rooms, etc.) of “Building 1” 412. As illustrated by space E 414, spaces may be broken up into subspaces (in this example, subspace E1 416 and subspace E2 418 make up space E 414). These subspaces may be referred to as “spaces” herein.

A place is generally made up of spaces. The place may be referred to as a “parent” of a space if the space is in that place. That space is then a “child” of that place. For example space E 414 is a child of place “Building 1” 412, and “Building 1” 412 is the parent of space E 414. Because a space (e.g., space E) may be made up of spaces (e.g., spaces E1 416 and E2 418) and a place (e.g., campus 410) may be made up of places, a space may have a child and/or parent space and a place may have a child and/or parent place.

As used herein, the term “space or place” refers to any space or place where a system, component, method, etc. applies to either spaces or places. Spaces or places are typically fixed locations/areas (e.g., with an address, GPS coordinate, etc.) but may also include mobile spaces or places (e.g., a ship and rooms aboard the ship). Furthermore, while “space” or “place” may be used in describing the embodiments described herein, it should be understood that in many concepts described herein with reference to a space may also be applicable to a place.

Conventional Building Domain Systems and Control Architectures

Referring now to FIG. 4C a diagram of five independently-operating conventional BDSs for a place 420 (e.g., a building and surrounding outdoor areas) is shown for the sake of background. More particularly, place 420 may include an HVAC system, a lighting system, an access system, a video system, and a fire system. In conventional BDSs, the systems mentioned above operate independently, resulting in widespread complexity. Each of the HVAC system, the lighting system, the access system, the video system, and the fire system have separate networks and cabling, controllers and servers, and user interfaces. For example, in the HVAC system, HVAC devices 421 are connected by HVAC cabling 422, while lighting devices 424 are connected by lighting cabling 425, video devices 426 are connected by video cabling 428, access devices 430 are connected by access cabling 432, and fire devices 434 are connected by fire cabling 436 in the respective systems. Even if wireless networks are used instead of physical cabling, the wireless networks supporting each building system are generally separate. Furthermore, different network protocols may be used by the various systems, for example LonWorks, MSTP, BACnet, ONVIF, etc., inhibiting interconnectivity. In sum, the systems of place 420 are implemented and installed as physically and electronically isolated systems in FIG. 4C. Limitations of such siloed systems are described with references to the following two figures.

Referring now to FIGS. 5A and 5B, existing control architectures are shown for the sake of comparison to the systems and methods described herein. FIG. 5A shows isolated (“siloed”) control and equipment for each of three building domains in an isolated architecture 500. In a lighting system 514, lighting equipment 504 is controlled by lighting controller 502. In the HVAC system 516, HVAC equipment 508 is controlled by the HVAC controller 506. In the access system 518, access equipment 512 is controlled by an access controller 510. The lighting system 514, the HVAC system 516, and the access system 518 are entirely independent of one another. Thus, in the isolated architecture 500 of FIG. 5A, each building domain (i.e., each type of functionality provided to the building), is siloed and operates independently. Creating a desired condition in a space or place using the isolated architecture 500 requires separate interactions with each domain (i.e., lighting, HVAC, access).

FIG. 5B shows an integration architecture 550 that attempts to integrate the separate systems 514-518. An integration system 552 includes and integrated controller 554, a lighting integrator 556, an HVAC integrator 558, and an access integrator 560. The lighting integrator 556 translates data, control signals, etc. between a data model used by the integrated controller 554 and a lighting data model used by the lighting system 514. The HVAC integrator 558 translates data, control signals, etc. between a data model used by the integrated controller 554 and an HVAC data model used by the HVAC system 516. The access integrator 560 translates data, control signals, etc. between a data model used by the integrated controller 554 and an access data model used by the access system 518. The integration system 552 thereby relies on fragile translations, interfaces, integrations, etc. to provide some amount of interaction across building domains. However, the integration system 552 is prone to errors and breakdowns, for example caused by software updates in one system 514-518. Further, integration adds complexity, computation expenses, etc. to the operation of a building management system. The integration architecture 550 may therefore by unsatisfactory for users.

Unified Building Management System

Referring now to FIG. 6, a unified building management system (UBMS) 600 is shown for a place. The UBMS 600 includes HVAC devices 602, lighting devices 604, access devices 606, video devices 608, and fire devices 610 that serve multiple spaces in place 420. The HVAC devices 602, lighting devices 604, access devices 606, and video devices 608 are connected via a common network (e.g., common cabling, shared wireless network). Fire devices 610 may also be connected to the common network and/or may have a separate network 614 as shown to provide extra reliability or redundancy for safety-critical functions and/or to comply with regulatory requirements. The devices 602-610 are communicable using a common protocol (e.g., BACnet, MSTP, LonWorks, TCP/IP) and are connected to a common server 601. The common network 612 saves costs, materials, time etc. in installation, operation, and maintenance as compared to the multitude of networks used for the combination of BDSs shown in FIG. 4C. The common network 612 and the common protocol also facilitate other beneficial interconnectivity, interdependence, redundancy, etc. for the UBMS 600, as described in detail below.

In the UBMS 600, devices 602-610 are primarily associated with spaces in place 420 that the devices serve. Place 420 in the example of FIG. 6 is a medical facility that includes the following spaces: patient rooms 613, data center room 615, nurses' station 616, waiting room 617, outdoor area 618, and doctor's office 619. As opposed to dealing with what domain a device belongs to, the UBMS 600 focuses on spaces, the mission of a space, and the people that use those spaces. For example, patient rooms 613 are shown with missions “heal, treat, care,” as well as with an HVAC device 602 and lighting device 604 for each, while the outdoor area 618 has the mission “park” and is served by a video device 608. The UBMS 600 manages and controls the devices that serve each space (e.g., each patient room 213) in order to fulfill the mission of the space. Facilitated by the removal of complexities and barriers found in simultaneous use of multiple BDSs, the UBMS 600 coordinates devices independent of domain to align devices, people, spaces, places, and missions. Further details and advantages of this approach are discussed in U.S. Provisional Patent Application No. 62/485,282 filed Apr. 13, 2017, and U.S. Provisional Patent Application No. 62/560,567 filed Sep. 19, 2017. The entire disclosures of both these patent applications are incorporated by reference herein.

Each of the physical spaces of place 420 is shown to include its own group of devices. Each group of devices may communicate via their own network. In this regard, each group of devices may independently service the particular space that they are in. Each group of devices may communicate via the common network. However, if one of the groups loses connection with the common network and/or common server 601 goes offline, that group of devices may be self-sufficient and may operate without connection to the server 601 and the rest of UBMS 600.

Server 601 may be any computing system, server, controller, laptop computer, desktop computer, and/or other computing device or system that communicates with the device groups of the physical spaces (e.g., patient rooms 613) of place 420. Since each device group includes access systems, security systems, and HVAC systems, server 601 may communicate with and/or control each of the systems with no integration between various controllers and/or discrete systems. Further, there may be a single operating interface 652 that can run on a user device, server 601, and/or communicate with server 601. Similarly, there may also be a single configuration interface 650 that may run on a user device, server 601, and/or communicate with server 601. Operating interface 652 may be the same as configuration interface 650. Since the device groups of place 420 include a plurality of systems, operating interface 652 and/or configuration interface 650 may be a unification of devices across domains and allow a user to operate and/or configure the plurality of devices (e.g., devices for HVAC, security, access, video, lighting, fire etc.).

The devices (e.g., HVAC, fire, security, lighting, access, fire etc.) of UBMS 600 may be part of a single unified product offering. Further, the system may be module and the installation of UBMS 600 may be a single module installation. UBMS 600 may be integrated with partner systems and may include “deep” integrations between the systems of place 420 and partner systems. Further, the UBMS 600 may include standard open protocols and APIs that allow for third party systems to be integrated with UBMS 600.

Unified Control Architecture with Spaces and Places

Referring now to FIG. 7A, a block diagram of a unified control architecture 700 is shown, according to some embodiments. The unified control architecture 700 includes a unified control engine 702 that controls environmental control assets 704. The unified control engine 702 may be implemented on server 601 of FIG. 6, may be implemented a space- or place-controller, may be implemented in the cloud, may be distributed among multiple computing resources (e.g., including a user device 716), or may be implemented in some other way. The unified control architecture 700 overcomes the shortcomings of the isolated architecture 500 and the integration architecture 550.

The unified control architecture 700 is also shown to include a user device 716. The user device 716 may be one or more personal computing devices associated with a user or occupant of a space or place, for example a maintenance technician tasked to monitor and service one or more environmental control assets 704 in a space. User device 716 may include any wearable or non-wearable device. Wearable devices can refer to any type of device that an individual wears including, but not limited to, a watch (e.g., a smart watch), glasses (e.g., smart glasses), bracelet (e.g., a smart bracelet), etc. User device 716 may also include any type of mobile device including, but not limited to, a phone (e.g., smart phone), a tablet, a personal digital assistant, etc. In some embodiments, user device 716 includes other computing devices such as a desktop computer, a laptop computer, etc. The user device 716 is configured to display a graphical user interface to a user and receive user input to the graphical user interface. In preferred embodiments, the user device 716 includes a touchscreen. The user device 716 is communicable with the unified control engine 702 (e.g., with the server 601) via a network, for example a WiFi network, a Bluetooth network, a cellular network, etc.

The environmental control assets 704 can include various equipment, devices, sensors, actuator, etc. across multiple building domains that are operable to modify environmental conditions at a space or place or to collect data about the environmental conditions at the space or place. Environmental conditions include, but are not limited to, lighting levels, temperature, humidity, noise, locked/unlocked doors, blinds open/closed, windows open/closed, air pressure, and building alarms. Accordingly, FIG. 7A shows that the environmental control assets 704 include lighting equipment 706, HVAC equipment 708, access equipment 710, and other equipment 712 (e.g., security equipment, fire detection and alarm devices, power systems, blinds).

To facilitate unified control in the unified control engine 702, the environmental control assets 704 are controlled using a common data model. The common data model ensures that controls and data can be communicated amongst the environmental control assets 704 and between the environmental control assets 704 and the unified control engine 702 without the need for integrators/integration as in FIG. 5B.

The unified control engine 702 is structured to control the environmental control assets 704 using a space- and place-based approach. That is, the unified control engine 702 follows a control approach, described in detail below, using “modes” for the spaces or places. As used below, a mode is a state of a space or place (i.e., a state of the environmental control assets 704 associated with that space or place) that corresponds to a purpose, mission, or function of the space or place as viewed by users. In general, modes may be associated with an operational mission of the space or place, a job to be done by a user in the space or place, or a situation triggered by an event. Modes are defined in profiles for the spaces or places (i.e., space profiles and place profiles), which are designed based on the purposes and missions that occupants have for the spaces or places. The spaces or places are thereby used as the unifying concept for control. The unified control engine 702 is described in further detail in U.S. patent application Ser. No. 15/952,173, filed Apr. 12, 2018, incorporated by reference herein in its entirety.

To facilitate this space- and place-centric control, the unified control engine 702 is shown in unified control architecture 700 as communicably coupled to a profiles repository 714. In some embodiments, profiles repository 714 is a component of unified control engine 702. The profiles repository 714 stores space or place profiles that include the data, applications, modes, logic, etc. used by the unified control engine 702 in providing unified control. More particularly, space and place profiles are provided for each of a variety of spaces and places. In setting up the unified control engine 702, space or place profiles are loaded onto the unified control engine from the profiles repository 714 and customized to meet the needs of particular spaces or places. The unified control engine 702 can thereby be quickly and easily configured to provide unified control features. Profiles repository 714 is described in further detail in U.S. patent application Ser. No. 15/952,173, filed Apr. 12, 2018, incorporated by reference herein in its entirety.

Referring now to FIG. 7B, a block diagram of unified control engine 702 in greater detail is shown, according to some embodiments. Unified control engine 702 can operate various building equipment and/or other assets based on a unified control scheme. In particular, unified control engine 702 can utilize data received from environmental control assets 704 to generate control signals, graphical user interfaces, etc. based on the data. Advantageously, information related to assets outputted and received by unified control engine 702 can adhere to the common data model, as described above with reference to FIG. 7A, to ensure integrators are not needed to communicate with specific assets (building devices) of environmental control assets 704. It should be noted that the terms “assets” and “building devices” may be used interchangeably herein.

Unified control engine 702 is shown to include a communications interface 758 and a processing circuit 752. Communications interface 758 may include wired or wireless interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals, etc.) for conducting data communications with various systems, devices, or networks. For example, communications interface 758 may include an Ethernet card and port for sending and receiving data via an Ethernet-based communications network and/or a Wi-Fi transceiver for communicating via a wireless communications network. Communications interface 758 may be configured to communicate via local area networks or wide area networks (e.g., the Internet, a building WAN, etc.) and may use a variety of communications protocols (e.g., BACnet, IP, LON, etc.).

Communications interface 758 may be a network interface configured to facilitate electronic data communications between unified control engine 702 and various external systems or devices (e.g., user device 716). For example, unified control engine 702 may provide graphical user interfaces to user device 716 via communications interface 758.

Processing circuit 752 is shown to include a processor 754 and memory 756. Processor 754 may 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 754 may be configured to execute computer code or instructions stored in memory 756 or received from other computer readable media (e.g., CDROM, network storage, a remote server, etc.).

Memory 756 may 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 756 may 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 756 may 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 756 may be communicably connected to processor 754 via processing circuit 752 and may include computer code for executing (e.g., by processor 754) one or more processes described herein. In some embodiments, one or more components of memory 756 are part of a singular component. However, each component of memory 756 is shown independently for ease of explanation.

Memory 756 is shown to include a data collector 760. Data collector 760 can receive/obtain data from a variety of sources. For example, data collector 760 may receive user inputs from user device 716, profiles from profiles repository 714, and/or asset data from environmental control assets 704. User inputs received from user device 716 may include instructions, selections, etc. inputted by a user to user device 716. In some embodiments, the user utilizes a mobile application to interact with unified control engine 702. The mobile application, as described in greater detail below with reference to FIGS. 8-26, can facilitate monitoring and maintenance of building equipment and devices (e.g., environmental control assets 704) in an equipment room (mechanical room) of a building for the user. Via the mobile application, the user may be able to instruct unified control engine 702 to perform various tasks. For example, the user may instruct unified control engine 702 to schedule maintenance to be performed on a building device of environmental control assets 704. As another example, user device 716 may provide a user input indicating a request for consolidated information regarding one or more building devices of environmental control assets 704. As should be appreciated, user inputs provided by user device 716 can include any various instruction inputted by a user via user device 716. Further, it should be appreciated that the mobile application is provided for sake of example. User device 716 may display graphical user interfaces (GUIs) to the user through various formats. For example, user device 716 may allow the user to interact with unified control engine 702 via a website, a desktop application, a wearable device-based application, etc.

Data collector 760 can also receive profiles from profiles repository 714. As described above with reference to FIG. 7A, profiles repository 714 can provide space and place profiles that include the data, applications, modes, logic, etc. that can be used by the unified control engine 702 in providing unified control. More particularly, space and place profiles are provided for each of a variety of spaces and places that may be managed by unified control engine 702.

Data collector 760 can also receive asset data from environmental control assets 704. The asset data can include various information describing operation of assets of environmental control assets 704. The data received from environmental control assets 704 can adhere to the common data model to ensure uniformity across assets. The asset data may include information such as, for example, equipment statuses, operating setpoints, scheduled operations to be performed, device/model numbers, locations of assets in a building, resource consumption rates, time-series data, etc.

Based on information received, data collector 760 can provide the collected data to an asset information database 768. Asset information database 768 can store any and/or all information associated with assets. This may include instructions regarding assets received from a user (e.g., as indicated by user inputs received from user device 716), asset statuses, maintenance logs, a historical record of maintenance, access permissions, work orders, knowledge base information, video and/or audio recordings, space and place profile information, etc. In some embodiments, profiles repository 714 is a component of asset information database 768. In some embodiments, asset information database 768 is hosted externally from unified control engine 702. For example, asset information database 768 may be hosted by a cloud service provider. In this case, unified control engine 702 may be configured to communicate with the cloud service provider to store and retrieve data stored in asset information database 768. However, asset information database 768 is shown as a component of unified control engine 702 for ease of explanation.

In some embodiments, data collector 760 provides some and/or all collected data directly to some and/or all of memory components 762-766. In this case, data collector 760 may provide collected data to different components of memory separately and/or in addition to providing collected data to asset information database 768. For example, data collector 760 may provide profiles received from profiles repository 714 directly to a control signal generator 762 for operating environmental control assets 704 and may or may not store the profiles in asset information database 768.

Still referring to FIG. 7B, memory 756 is shown to include control signal generator 762. Control signal generator 762 can generate control signals for operating assets of environmental control assets 704. Based on received space and/or place profiles, control signal generator 762 can determine various control actions that operate various assets of environmental control assets 704 to fulfill a mode for a particular space or place. Specifically, control signal generator 762 can generate control signals to fulfill an operational mission, a job to be done, or an event for a particular space or place. Advantageously, the control signals generated by control signal generator 762 can adhere to the common data model such that the control signals reflect operation of environmental control assets 704 collectively rather than individually based on equipment type.

The control signals generated by control signal generator 762 may include setpoints for assets to operate based on, operational schedules (e.g., when to operate, how to operate, etc.), or any other appropriate controls for assets. In some embodiments, control signal generator 762 includes functionality to verify identities of individuals. For example, if a technician is scheduled to perform maintenance on building equipment, control signal generator 762 may verify the technician's identity and can generate control signals to provide the technician access (e.g., via access equipment 710) to an appropriate space/place.

Memory 756 is also shown to include a graphical user interface (GUI) generator 764. GUI generator 764 can generate GUIs to provide to user device 716 such that the GUIs can be displayed to a user. The GUIs generated by GUI generator 764 can provide users with a holistic view of information applicable to a space or place. For example, GUI generator 764 may generate GUIs for users that displays information regarding knowledge of certain building devices, video streams of ERs, consolidated information views describing some and/or all assets in an ER, work order generation views, etc.

GUI generator 764 can utilize information stored in asset information database 768 for obtaining information related to environmental control assets 704. For example, if a user indicates they want information regarding a specific building device, GUI generator 764 can obtain information regarding the building device from asset information database 768. As another example, GUI generator 764 may obtain profiles from asset information database 768 along with asset data to display comprehensive GUIs that inform a user regarding how environmental control assets 704 are operating to achieve a particular mode of a space or place.

Memory 756 is also shown to include a maintenance module 766. Maintenance module 766 can manage maintenance needs across spaces and places along as well as environmental control assets 704. Specifically, maintenance module 766 can monitor, schedule, and/or otherwise manage maintenance of environmental control assets 704. Maintenance of assets, as described herein, may include various operations that can be performed on assets such as updating assets, replacing components of assets, replacing entire assets, repairing assets, and/or any other action that can be performed to improve an operating state of assets. Maintenance module 766 is described in greater detail below with reference to FIG. 7C.

In some embodiments, maintenance module 766 provides information to GUI generator 764 such that GUI generator 764 can generate maintenance-based GUIs to provide to user device 716. For example, maintenance module 766 may automatically generate a work order as a result of detecting a fault status of a device of environmental control assets 704. Based on the work order, GUI generator 764 can generate a GUI including information of the work order to provide to user device 716 for approval to distribute the work order (e.g., to a technician/contractor). As another example, maintenance module 766 may generate and provide a maintenance alert to GUI generator 764 such that GUI generator 764 can generate a GUI indicating a problem to user device 716. In this case, a user (e.g., a building manager) can be automatically notified of the problem and can get immediate feedback on what the problem is, where the problem is, how the problem is affecting a mode of an associated space or place, etc. As yet another example, maintenance module 766 may provide location information (e.g., a map of a space or place) indicating where a technician should go to perform maintenance on a particular device. In this case, GUI generator 764 can generate a GUI indicating the location information and provide the GUI to a user device 716 associated with the technician.

Additional features and components that may be incorporated in unified control engine 702 are described in further detail in U.S. patent application Ser. No. 15/952,173, filed Apr. 12, 2018, incorporated by reference herein in its entirety.

Referring now to FIG. 7C, a block diagram of maintenance module 766 in greater detail is shown, according to some embodiments. Maintenance module 766 is shown to include a required maintenance identifier 770. Required maintenance identifier 770 can identify what (if any) assets of environmental control assets 704 require maintenance to be performed. Based on received asset data, required maintenance identifier 770 can monitor statuses of assets to determine if any assets are operating in a fault state, have an efficiency rating lower than a minimum threshold efficiency, are consuming more resources (e.g., electricity, water, gas, etc.) than an acceptable amount, etc. In effect, required maintenance identifier 770 can utilize asset data to identify assets that may require maintenance. In some embodiments, required maintenance identifier 770 further determines a recommended maintenance activity to be performed on assets identified as requiring maintenance. For example, if required maintenance identifier 770 identifies a light of lighting equipment 706 is in a fault state, required maintenance identifier 770 may determine that the light should be replaced with a new light to resolve the fault state.

In some embodiments, required maintenance identifier 770 utilizes space or place profiles to identify assets requiring maintenance. In this case, required maintenance identifier 770 may determine if a mode for a particular space or place is being achieved. If the mode is being achieved, required maintenance identifier 770 may determine that no assets require maintenance. However, if the mode is not being achieved, required maintenance identifier 770 may determine that some asset requires maintenance, that some assets should be added and/or removed from the space or place, etc. In this way, required maintenance identifier 770 can view a system (e.g., a space or place) holistically.

If required maintenance identifier 770 identifies a particular building device requires maintenance, required maintenance identifier 770 can perform various actions. For example, required maintenance identifier 770 may provide a notification to maintenance alert generator 772 to generate and provide an alert indicating the required maintenance to a user. As another example, required maintenance identifier 770 may notify work order generator 774 that a work order should be generated. In this example, required maintenance identifier 770 may provide information regarding a fault state of the building device requiring maintenance to work order generator 774. In this way, work order generator 774, as described in detail below, can dynamically update and/or automatically populate a work order based on the fault state.

Maintenance module 766 is shown to include a maintenance alert generator 772. Based on a maintenance need identified by required maintenance identifier 770, maintenance alert generator 772 can generate a maintenance alert that can be provided to users. The maintenance alert may include information related to the required maintenance such as, for example, what maintenance is required, why the maintenance is required (e.g., a mode not being achieved), and/or other information that may be useful to a user to discern information related to the required maintenance. In some embodiments, maintenance alert generator 772 estimates a level of urgency of the required maintenance. The level of urgency can be included in the maintenance alert to provide valuable insight regarding how urgent the required maintenance is to resolve. In some embodiments, maintenance alert generator 772 retrieves troubleshooting instructions (e.g., from asset information database 768) and includes the troubleshooting instructions in the alert. In this way, the user can be provided with troubleshooting instructions before a work order is generated (e.g., by work order generator 774) and may be able to fix a problem themselves without needing to hire a technician (thereby saving money for the user). However, if the user indicates they cannot fix the problem based on the troubleshooting instructions (e.g., as indicated by a selection on a GUI provided to user device 716), the work order can be generated responsive to the indication.

In some embodiments, maintenance alerts generated by maintenance alert generator 772 are provided to GUI generator 764 as described with reference to FIG. 7B. In this way, GUI generator 764 can generate and provide a GUI associated with the maintenance alert to provide to a user. In this way, the user can be automatically notified of the required maintenance and can take appropriate action based on a severity of the required maintenance.

Still referring to FIG. 7B, maintenance module 766 is shown to include a work order generator 774. Work order generator 774 can automatically generate work orders based on required maintenance activities identified by required maintenance identifier 770. Advantageously, work order generator 774 can automatically populate work orders based on asset data, information stored in asset information database 768, fault states indicated by required maintenance identifier 770, and/or various other information sources that can provide device information. For example, work order generator 774 may retrieve information such as a list of certified technicians for addressing the required maintenance, knowledge base information describing knowledge related to an asset requiring maintenance, a model/serial number of the asset requiring maintenance, information related to previous maintenance activities performed on the asset, video/audio recordings of the asset, a physical location of the asset in a space or place, a priority of the required maintenance, etc. from asset information database 768, asset data provided by environmental control assets 704, and/or from some other source. In this way, based on identification of a required maintenance, a work order can automatically be generated.

As a more specific example, required maintenance identifier 770 may monitor asset data of a chiller and determine the chiller is in a fault state. Based on the determination that the chiller is in the fault state, required maintenance identifier 770 can notify work order generator 774 that a work order should be generated and can indicate the fault state the chiller is in. Based on the notification, work order generator 774 can generate and automatically populate one or more fields of a work order for the chiller. In some embodiments, work order generator 774 populates fields based on the asset data provided by the chiller (e.g., a device/model number of the chiller, a location of the chiller, etc.). In some embodiments, work order generator 774 populates fields based on a fault state indicated by required maintenance identifier 770. In this case, the fault state may indicate a type of fault occurring and other information associated with the fault. In some embodiments, work order generator 774 retrieves information describing the chiller from asset information database 768 for field population. In some embodiments, work order generator 774 retrieves information from other sources such as from cloud databases, directly from users, other systems/databases, etc. for field population. For example, work order generator 774 may obtain warranty information for the chiller from a computing system of a warranty provider. Based on the warranty information, work order generator 774 can populate one or more fields of the work order indicating whether a warranty for the chiller is active, what date the warranty expires, etc.

As should be appreciated, work order generator 774 can gather information applicable to work orders from multiple systems, devices, databases, etc. As data applicable to work orders may be stored in different locations (e.g., different systems/databases), work order generator 774 can communicate with each location to obtain information to automatically populate fields of the work order. For example, a make and model of a building device may be stored in a first location, warranty information for the building device may be stored in a second location, indications of specific problems with the building device may be stored in a third location, etc. Even though the data for the work order is stored in multiple locations (e.g., multiple databases), work order generator 774 can automatically retrieve all relevant information for the work order from each location and can automatically populate the work order such that a person viewing the work order has as much relevant information available as possible. Automatic information retrieval and population of work orders can performed by work order generator 774 can significantly reduce and/or eliminate manual effort required by users in generating work orders for building devices.

In some embodiments, work order generator 774 dynamically generates and automatically populates work orders based on fault states of building equipment identified by required maintenance identifier 770. Dynamic generation of a work order can refer to including specific fields in a given work order based on a fault state. For example, a fault state identified by required maintenance identifier 770 may indicate that a building device is leaking water. Based on the indication that the building device is leaking water, work order generator 774 may dynamically generate a work order that includes fields specifically associated with the building device and/or the water leakage. In this way, work order generator 774 can generate different types of work orders that encompass specific types of building devices, building faults, etc. This can be helpful in ensuring that work orders include the most relevant information fields and exclude fields that may not be applicable to a certain fault. For example, work order generator 774 may generate a work order with different fields for a chiller in a fault state as opposed to a work order for a boiler in a fault state. In this way, each work order generated by work order generator 774 may be dynamically generated based on a fault state of a particular building device.

Once a work order is dynamically (or otherwise) generated, work order generator 774 can automatically populate fields of the work order based on the fault status. For example, in the water leakage example above, work order generator 774 may automatically populate fields of the work order indicating an incident type is water damage, a priority level of the work order is high due to possible water damage, a location of the building device, etc. Advantageously, work order generator 774 may be able to gather information required to populate fields of the work order from a variety of different locations (e.g., different databases) and can consolidate all the information into a single work order. Further, work order generator 774 may be able to extrapolate/predict information based on fault states and can populate fields based on the extrapolations/predictions. In the above example, the field of the work order indicating a high priority level may be determined by work order generator 774 based on the fact that a water leakage is occurring. In other words, work order generator 774 may determine performing maintenance on the building device is of high priority to prevent water damage. As should be appreciated, work order generator 774 can retrieve information from various locations to automatically populate fields and may be able to determine additional information based on fault states of building devices.

In some embodiments, work orders automatically generated by work order generator 774 are automatically approved and provided to a technician. In this way, the required maintenance can be addressed sooner. In this case, the work order may nonetheless be provided to the user via a GUI generated by GUI generator 764 such that the user can be made aware of the work order. In some embodiments, however, unified control engine 702 requires that work orders are approved by users. In this case, work order generator 774 can provide the work order to GUI generator 764 such that GUI generator 764 can generate a GUI with the work order to provide to user device 716. After being provided to user device 716, a user can approve or deny the work order. If the user approves the work order, the work order can be transmitted to a technician and the service can be scheduled. If the user denies the work order, other corrective actions (e.g., generation of a modified work order, disabling of the asset at fault, continuing standard operation, etc.) can be performed.

In some embodiments, work orders are automatically approved or are sent to users for approval based on various conditions. For example, if an estimated cost of a work order is higher than a predetermined threshold, the work order may be provided to a user for approval. However, if the estimated cost is below the predetermined threshold, the work order may be automatically approved and distributed to a technician. As another example, if an estimated severity of the required maintenance is high, the work order may be automatically approved to reduce an amount of time assets in fault states. However, if the estimated severity is low, the work order may be provided to the user for approval.

Maintenance module 766 is also shown to include an asset scheduler 776. Based on an identified maintenance need, asset scheduler 776 can generate an operational schedule for one or more assets of environmental control assets 704. As such, asset scheduler 776 (and thereby maintenance module 766) may include some and/or all of the functionality of control signal generator 762.

An operational schedule for an asset can include various actions for the asset to take at various times. In some embodiments, operational schedules are generated with respect to work orders generated by work order generator 774. For example, if a work order for an HVAC device in an equipment room is generated and provided to a technician, asset scheduler 776 may generate an operational schedule for various assets associated with the ER to streamline the maintenance. In this case, asset scheduler 776 may schedule access equipment 710 for the ER to be unlocked or otherwise accessible by the technician during a maintenance time window indicated by the work order. As such, the ER can be accessible to the technician during the maintenance time window. However, outside of the maintenance time window, the ER may be inaccessible to the technician to maintain security of the ER. In this example, asset scheduler 776 may also schedule lighting equipment 706 in the ER to be operated during the maintenance time window such that the technician can navigate the ER more easily.

Automatically scheduling access permissions based on work orders can significantly reduce an amount of time required to successfully complete the work orders. Based on the work order, asset scheduler 776 can determine information such as what technician is servicing a building device, when the technician is scheduled to service the building device (e.g., based on a maintenance time window), where the technician requires access (e.g., based on a location of the building device), etc. In this way, asset scheduler 776 can schedule permissions for the technician such that the technician can be automatically provided access to perform any required maintenance. Further, asset scheduler 776 can ensure the technician only has access to locations that the technician should have access to in order to perform the maintenance. In particular, the technician may only be provided access to a location of the building device requiring maintenance and no other locations. By automatically scheduling access permissions, asset scheduler 776 can improve security for a building. For example, automatic scheduling of access permissions can reduce a risk that a technician convinces security personnel to provide the technician access to restricted areas. In this example, access permissions of the technician are automatically set based on a work order such that it is clear to the security personnel where the technician needs access. Further, automatically scheduling access permissions based on work orders can reduce an amount of time required by humans to manually schedule access permissions.

Operational schedules generated by asset scheduler 776 can adhere to the common data model described above. In this way, asset scheduler 776 can generate similar operational schedules for various assets of environmental control assets 704 without having to account for separate data models utilized by various equipment. Utilizing the common data model can increase processing efficiency of unified control engine 702 by eliminating integrators and/or integrator functionality from being required to control environmental control assets 704.

Maintenance module 766 is also shown to include a maintenance report logger 778. Maintenance report logger 778 can receive report logs such as journals, notes, records, etc. provided by a technician regarding a maintenance. In other words, maintenance report logger 778 may receive maintenance information (i.e., report logs) from the technician describing an operating state of an ER. The maintenance information can include various information such as, for example, building devices that require further attention, times when maintenance is performed, parts repaired/replaced on building devices, what technician performed maintenance, contact information of the technician, steps taken in performing maintenance, etc. In some embodiments, the maintenance information (maintenance data) is received directly from assets of environmental control assets 704. In this case, building devices may be configured to provide data related to maintenance such as, for example, detections old components being replaced by new components, changes in operating states (e.g., changes in resource consumption) before and after maintenance, what changes were detected during maintenance, etc. If combined with maintenance data provided by technicians, comparisons can be performed by maintenance report logger 778 and/or by a user to ensure maintenance logs provided by technicians accurately reflect what was detected by building devices undergoing maintenance.

In some embodiments, maintenance report logger 778 can parse through the report logs extract additional information regarding environmental control assets 704 and/or associated spaces or places. For example, a technician may provide a log indicating that maintenance was successfully performed on one asset, but another asset may require maintenance in the near future. In this case, maintenance report logger 778 can save the log in asset information database 768 and can extrapolate information based on the log. For example, maintenance report logger 778 may project/predict how a mode of a space or place may be affected if the asset noted by the technician as possibly requiring maintenance in the near future were to fail. As another example, maintenance report logger 778 may project/predict how maintenance performed by the technician may change operation of building equipment over time. Improved operations may include reduced resource consumption, a higher reliability state, improved safety ratings, etc. Maintenance report logger 778 can further log projections and may notify a user (e.g., via a GUI) about the projections.

As should be appreciated, maintenance report logger 778 may include various models for language processing, generating predictions, etc. In some embodiments, maintenance report logger 778 includes artificial intelligence models that incorporate deep learning and neural network principles to parse through logs provided by technicians and generate predictions based on said logs.

In some embodiments, maintenance module 766 includes fewer, different, and/or additional components than as shown in FIG. 7C. In other words, the components of maintenance module 766 as shown in FIG. 7C are provided purely for sake of example. Maintenance module 766 can include any appropriate component for managing maintenance of environmental control assets 704 and for ensuring modes of spaces or places are achieved.

Equipment Room UBMS Application Graphical User Interfaces

Referring generally to FIGS. 8-26, various views in a graphical user interface generated by the unified control engine 702 and displayed on the user device 716 are shown, according to some embodiments. More particularly, various views in a mobile application configured to facilitate monitoring and maintenance of building equipment and devices (e.g., environmental control assets 704) in an equipment room (mechanical room) of a building are shown. Buildings typically include one or more equipment rooms that house the main equipment required to run a facility, for example air handling units, chillers, pumps, boilers, and/or various additional electrical and mechanical subsystems and devices across various building domains. For example, an office building may include one equipment room per floor, in addition to a larger equipment space in a basement or lower level that houses larger equipment such as chillers and boilers.

A space may be designated as an equipment room to characterize its important role in a building, for example by associating an equipment room space profile with the equipment room space. An equipment room may be a particularly important space from a building systems perspective, as the equipment operated therein may impact conditions in many other spaces. A unified mobile application as shown in FIGS. 8-26 may be provided to facilitate monitoring, maintenance, scheduling, data tracking, history viewing, user management, etc. relating to an equipment room across all domains and specialty systems associated with a building, as described in detail below. The user device 716 and the unified control engine 702 may include various circuits configured to execute the processes described herein and provide the graphical user interface views shown in the FIGS. 8-26 as described in detail above with reference to FIGS. 7B and 7C.

An equipment room may be visited frequently by various people. In existing systems, communication challenges between people, spaces, and equipment may create loss of information or lack of knowledge for people engaging with a space. Accordingly, a need exists for systems and methods that provide information relating to who has visited a space, what people have done in a space, who is scheduled to be in a space, who has access to a space, what equipment is in the space, where is the equipment in the space, what equipment requires maintenance/service/repair, where is up-to-date information and documentation for the equipment in the space, etc. FIGS. 8-26 illustrate various views in a graphical user interface that provides a full-immersion experience software application where a smart space proxies as a digital assistant to help the occupant complete a task and finish a job in the most efficient manner, while collecting and presenting all relevant information in a user-friendly manner.

In some embodiments, some and/or all of the GUIs described below in FIGS. 8-26 can be automatically populated with information identified by unified control engine 702. For example, if unified control engine 702 identifies a certain building device has being in a fault status, unified control engine 702 may automatically generate a work order and display the work order to the user via GUI. Based on the work order, unified control engine 702 may set other settings (e.g., access permissions) that can be reflected to users via GUIs displayed on user device 716. This automatic data transferring and population can significantly reduce manual effort required by users in performing various actions such as settings access permissions (e.g., for technicians), generating work orders, etc.

User inputs to GUIs displayed by user device 716 can be provided back to unified control engine 702 for processing. Based on user inputs, unified control engine 702 can operate components therein to respond accordingly to the user input. For example, if a user presses a button to approve a work order automatically generated by unified control engine 702, unified control engine 702 can notify a user device of a technician regarding the work order. As another example, if a user inputs a request for troubleshooting information for a building device, unified control engine 702 can retrieve troubleshooting information stored by asset information database 768, generate a GUI including the troubleshooting information, and provide the GUI to user device 716 to fulfill the request. In effect, unified control engine 702 can ensure interactions between the user and GUIs displayed by user device 716 are handled appropriately.

Referring now to FIGS. 8A and 8B, an overview view 800 and an overview view 850 in an equipment room graphical user interface is shown, according to some embodiments. In this case, overview view 850 of FIG. 8B is a continuation of overview view 800 of FIG. 8A. As such, overview views 800 and 850 may be displayed in a single overview view on user device 716. The overview views 800 and 850 may be displayed on the user device 716. The overview views 800 and 850 includes an electrical usage widget 802, a schedule widget 804, a suggested maintenance widget 806, and a historical activity widget 808.

The overview views 800 and 850 provide a daily overview of what is happening in a particular equipment room. The electrical usage widget 802 shows a snapshot of energy usage, for example by showing a comparison of today's electrical usage and yesterday's electrical usage (e.g., compared to an average energy usage). The schedule widget 804 shows a list of activities scheduled to occur in the equipment room in a day, including a time, a name of the activity, and a person associated with the activity (e.g., a person responsible for executing a job). The scheduling information may be pulled from a calendaring system included with or communicable with the DBMS. The historical activity widget 808 shows a list of events that occurred at the equipment room in the past 24 hours. Various other time spans may be used in various embodiments. The historical activity widget 808 may identify a person associated with each event, a name of the event, and a time of the event. The historical activity widget 808 may also display an ongoing activity when an activity is ongoing. The electrical usage widget 802, the schedule widget 804, the suggested maintenance widget 806, and the historical activity widget 808 may be simultaneously visible on the user device 716 or may be viewed in series by scrolling or swiping through the overview views 800 and 850.

FIGS. 9-16 show various views available to a facilities manager that allow management of technicians tasked with servicing equipment at a facility. In many cases, a space profile for the equipment room may identify that the equipment room serves multiple types of people, including service technicians, facility managers, and building operators, in addition to occupants of the building. Equipment rooms may be visited frequently by these various people, each of whom has various jobs to accomplish at/with the space. FIG. 9 shows a user access view 900, according to some embodiments. The user access view 900 is configured to allow a facility manager to manage who has access to an equipment room, systems therein, and various data or mobile application features relating to the equipment room.

As shown in FIG. 9, the user access view 900 allows a user to view and search a list of a list of user profiles. Each profile may identify a technician by name, company, specialty, etc. Each profile may also identify the last time the technician worked at a particular building or equipment room. Each profile may also provide contact information for the identified technician. The user access view 900 includes a search feature configured to allow a user to search for a technician.

Each profile includes an edit icon. The edit icon is selectable by a user to launch an edit contact view 1000 shown in FIG. 10. As illustrated in FIG. 10, the edit contact view 1000 is configured to allow a user to edit various information about a technician, for example the technician's name, company, position, phone number, or email address. A save button is included in the edit contact view 1000 and is selectable to save any changes to the information shown in the edit contact view 1000.

As shown in FIG. 10, various tabs are included in the graphical user interface, including a permissions tab, a history tab, and a schedule tab for a particular technician. A user may select the permissions tab to navigate to the permissions view 1100 shown in FIGS. 11-14, the history tab to navigate to the history view 1500 of FIG. 15, and the schedule tab to navigate to the schedule view 1600 shown in FIG. 16.

FIGS. 11-14 show various screens in a permissions view 1100 for display on the user device 716, according to some embodiments. FIG. 11 shows a permissions menu screen 1102 showing a menu of selectable options that may be selected to view other screens in the permissions view 1100.

For example, a mobile application features entry on the menu of selectable options is selectable to navigate to a mobile application features screen 1200 as shown in FIG. 12. The mobile application features screen 1200 allows a user (e.g., a facility manager) to alter what features of a mobile application that the technician has access to (i.e., is able to use). The mobile application features screen 1200 includes a list of mobile app features, with each entry on the list accompanied by an on/off toggle selectable by a user to turn a technician's access to a corresponding feature on or off. The features available to each technician is thereby highly customizable by a facility manager.

As another example, a locations entry on the menu of selectable options on the permissions menu screen 1102 of FIG. 11 is selectable to navigate to a locations permissions screen 1300 as shown in FIG. 13 according to some embodiments. The locations permissions screen 1300 of FIG. 13 is configured to allow a facility manager to select which spaces in a place a technician has physical access to (e.g., which equipment rooms in a building a technician has access to). As shown in FIG. 13, the locations permissions screen 1300 includes a list of spaces (e.g., a list of equipment rooms). Each entry on the list of spaces is accompanied by a corresponding on/off toggle selectable by a user to toggle between giving a technician permission to access the corresponding space and denying the technician permission to access the corresponding space. Changes to technician access on the locations permissions screen 1300 may be communicated to an access control circuit in the UBMS configured to control locks and other access control devices in a place. Door locks and other access control devices may thereby be controlled via the locations permissions screen 1300 on the user device 716. In some embodiments, initial permissions are generated by unified control engine 702 such that the on/off toggles are initially set. For example, if a work order is generated such that a technician requires access to a specific equipment room, locations permissions screen 1300 may reflect said access. Of course, a user can adjust any pre-generated permission settings manually by toggling the on/off toggles displayed in locations permissions screen 1300.

As another example, an access type entry on the menu of selectable options on the permissions menu screen 1102 of FIG. 11 is selectable to navigate to an access type screen 1400 as shown in FIG. 14, according to some embodiments. The access type screen 1400 allows a facility manager to customize various aspects of a technician's access to a space or to various features of a mobile application. For example, as shown in FIG. 14, the access type screen 1400 includes a start date field, a start time field, an end date field, and an end time field that allow a user to define a time period during which a technician has access (e.g., access as designated via the locations permissions screen 1300 and the mobile application features screen 1200). A scrollable date picker may be included to facilitate selection of dates and/or times for entry in the start date field, start time field, end date field, and/or end time field.

The history tab of FIG. 10 is selectable to navigate to a history view 1500 as shown in FIG. 15, according to some embodiments. The history view 1500 includes a timeline of a technician's activities at a place. Activities shown on the timeline may include check-ins to a space (i.e., an indication of when a technician entered a space), check-outs from a space (i.e., an indication of when a technician left a space), maintenance activities carried out on various equipment, etc. The timeline may include a location, activity type, and time for each activity shown on the timeline. The timeline may be color-coded and/or include other graphical indicators that provide an at-a-glance overview of a technician's historical activities at a place.

The schedule tab of FIG. 10 is selectable to navigate to a schedule view 1600 as shown in FIG. 16, according to some embodiments. The schedule view 1600 includes daily schedules of jobs to be accomplished by a technician. The schedule view 1600 may include an indication of the type of job, the location of the job, the equipment relating to the job (e.g., the equipment to be serviced), and a time and date of the job. The schedule view 1600 may be alterable by a facilities manager to organize and deploy technicians as needed. The user interface views of FIG. 9-16 thereby facilitate a facilities manager in managing technicians across various types of information, various jobs, and various building domains.

Referring now to FIG. 17, an equipment view 1700 configured for display on the user device 716 is shown, according to some embodiments. The equipment view 1700 provides information relating to all of the equipment contained in a particular equipment room. As shown in FIG. 17, the equipment view 1700 includes multiple equipment cards. Each equipment card corresponds to a particular unit of equipment, for example a chiller. Each equipment card identifies a name, model, serial number, location (i.e., an area of the equipment room such as Southwest Corner, Norwest Corner, etc.), and last service date and technician for the corresponding equipment. Other information may be included in various embodiments. An add button is included in the equipment view 1700 and selectable by a user to add more equipment to the equipment room.

Each equipment card may include an expansion button selectable to cause the equipment card to expand to show more information about the corresponding equipment, for example as shown in FIGS. 18A and 18B. FIG. 18A shows an expanded equipment card 1800, according to some embodiments. FIG. 18B shows an expanded equipment card 1850 continuing based on expanded equipment card 1800 of FIG. 18A, according to some embodiments. The expanded equipment cards 1800 and 1850 are shown to include an alarms widget, a potential problems widget, a scheduled maintenance widget, a service contract widget, a service history widget, a warranty widget, and a related equipment widget. The alarms widget is configured to track and display alarms (e.g., faults) for the corresponding equipment for a time period (e.g., one month). The alarm widget may display a time, date, and description of an alarm and an indication of who acknowledged the alarm. The potential problems widget may identify predicted issues, available software or firmware updates, recalls, etc. relating to the equipment. The scheduled maintenance widget may identify a time and date of upcoming scheduled maintenance of the equipment and the name of the technician assigned to perform the maintenance. The service contract widget may provide information relating to a current service contract for the equipment. The service history widget may provide a history of service/maintenance/repairs/etc. completed for the equipment, include a note describing the service, a date and time of the service, and the name of a technician who completed the service. The warranty widget may provide up-to-date warranty information for the equipment, for example identifying an amount of time before expiration of a warranty. The related equipment widget may identify related equipment, for example equipment that receive resources from or provide resources to the equipment associated with the expanded equipment cards 1800 and 1850.

As should be appreciated, equipment view 1700 and expanded equipment cards 1800 and 1850 as shown in FIGS. 17, 18A, and 18B can provide valuable information to a user. Specifically, equipment view 1700 and expanded equipment cards 1800 and 1850 can consolidate data regarding equipment, required maintenance, warranties, service histories, etc. into comprehensive GUIs. Equipment view 1700 and expanded equipment cards 1800 and 1850 can further ensure accountability for various interactions with building equipment is clear. For example, if a technician recently performed maintenance on a building device and the building device is experiencing additional faults, the technician accountable for the maintenance can be made clear to a user. Equipment view 1700 and expanded equipment cards 1800 and 1850 also provide insights regarding equipment within a single system. Rather than having to search through multiple application, data sources, physical files, etc. as in current systems, equipment view 1700 and expanded equipment cards 1800 and 1850 can present any applicable information to building equipment in easy to navigate views for a user. For example, if the user desires to learn more about a specific device, information from a knowledge base can be accessed from equipment view 1700 and/or expanded equipment cards 1800 and 1850 such that the user does not need to access another source (e.g., the Internet, physical files detailing the equipment, etc.) to retrieve the information.

Referring now to FIG. 19, a knowledge base view 1900 of a graphical user interface on the user device 716 is shown, according to some embodiments. The knowledge base view 1900 is configured to allow a user to search for information relating to equipment, for example relating to a troubleshooting or maintenance question. The knowledge base view 1900 may be configured to allow a user to type a question or search query into a search field. In some embodiments, the user device 716 includes a microphone and voice recognition capabilities such that a user may speak a question or search query to cause the question or search query to be transcribed into the search field. The knowledge base view 1900 then presents search results relating to the question or search query. A knowledge base may be maintained at a server, cloud-service, on a user device 716, on the Internet, etc. and accessible by the user device 716 in response to a prompt to conduct a search for knowledge. A user may thereby be provided with a user-friendly way to acquire knowledge relating to a maintenance task assigned to the user.

Referring now to FIG. 20, a live knowledge base view 2000 is shown, according to some embodiments. Various imagery, illustrations, video, information, augmented reality, etc. may be shown in the live knowledge base view 2000 in various cases to present a live feed of knowledge to a user to assist a user in completing a job in a space. The knowledge presented on the live knowledge base view 200 may include equipment literature, service part information (e.g., belt sizes, air filter IDs), electrical diagrams, access to programmable controls with application notes, contact information for parts suppliers or experts, QR codes or other links to ordering information for parts, and/or various other useful information.

Referring now to FIG. 21, a video stream view 2100 is shown, according to some embodiments. The video stream view 2100 may allow a user to view a live video feed showing a real-time, current view of various areas of an equipment room, and/or may allow a user to view recorded video of an equipment room at a previous time. The video stream view 2100 may assist a user in conducting remote troubleshooting and/or reviewing past events in a space. The video feed in video stream view 2100 can be captured by cameras in an ER. In some embodiments, each camera is aimed at a different area of the equipment room such that different visual information about the ER may be captured. For example, each camera may be directed to a particular building device to capture a view of the building device. In this way, visual information can be provided by video stream view 2100 for analysis by a user.

Referring now to FIG. 22, an alert view 2200 is shown, according to some embodiments. The alert view 2200 is configured to notify a user of an alert (e.g., fault, error, etc.) relating to building equipment and/or relating to an equipment room. As shown in FIG. 22, the alert view 2200 includes a video feed of an equipment room (e.g., showing a view of an incident in the equipment room) and information relating to the fault/incident (e.g., location, time, type, last service, etc.). The alert view 2200 may be pushed to a user device 716, for example in a text message or push notification. In some embodiments, the alert view 2200 is automatically brought to the “front” of a screen on the user device 716, e.g., to hide any other applications or views to ensure that a user sees the alert view 2200.

The alert view 2200 may include a troubleshooting icon selectable to navigate to a troubleshooting view 2300 as shown in FIG. 23 according to some embodiments. The troubleshooting view 2300 includes an augmented video feed showing the affected equipment augmented with one or more indicators highlighting problematic areas for a user to focus on and/or indicating the location of controls or other inputs manipulable by a user to react to the fault/incident. The troubleshooting view 2300 may also provide a series of steps that a user may follow to troubleshoot and/or fix the problem that triggered the alert. Advantageously, troubleshooting view 2300 can provide troubleshooting steps before requiring a work order. In this way, a user (e.g., a building operator) may be able to attempt to fix equipment faults prior to requiring a technician to come and inspect/repair the equipment which may be expensive for the user.

The alert view 2200 and the troubleshooting view 2300 are each shown to include an add work order request button and a dismiss button. The dismiss button is selectable to close the alert view 2200 or the troubleshooting view 2300 and return to a previous view in a graphical user interface on the user device 716. The add work order request button is selectable to navigate to a work order request view 2400 as shown in FIG. 24. In some embodiments, by pressing the add work order request button in alert view 2200 and/or troubleshooting view 2300, information related to the affected equipment can be automatically populated in the work order. In particular, information such as the location, time reported, incident type, location last serviced, etc. as displayed in alert view 2200 can be automatically populated in the work order. In this way, the user does not need to manually fill out all the information related to the affected equipment to generate the work order.

Referring now to FIG. 24, a work order request view 2400 is shown, according to some embodiments. The work order request view 2400 is configured to allow a user to create a work order, i.e., create instructions to perform maintenance/repairs/etc. The work order request view 2400 may include various fields, drop-down menus, etc. that allow a user to input information relating to the work order, including a location, an incident type, a priority, a description, etc. The work order request view 2400 may allow a user to attach one or more photos, videos, or audio recordings to a work order request and/or voice-transcribe a description for inclusion with the work order request. Further, work order request view 2400 can allow users to easily switch between dictation and text entry in describing information applicable to the work order.

As described above, work order request view 2400 can be automatically populated based on information regarding a required maintenance/repair/etc. Information regarding a required maintenance (e.g., as stored in asset information database 768) can be populated in work order request view 2400 to reduce manual entry requirements from the user. In particular, responsive to a user selection of the add work order request button of alert view 2200 and/or troubleshooting view 2300, information related to the specific equipment fault can be automatically populated in work order request view 2400. It should be appreciated that automatic population of fields can reduce an amount of time spent by users to enter information related to a work order.

In some embodiments, work order request view 2400 is dynamically generated based on fault states indicated in alert view 2200 and/or troubleshooting view 2300. In this case, fields included in work order request view 2400 may change depending on a type of fault indicated. For example, work order request view 2400 may only including a create description section requiring some recordation of the fault state (e.g., video recordings, pictures, manual dictation, etc.) due to a fact that the work order of work order request view 2400 is related to water damage (i.e., a high priority fault). If the fault is less critical (e.g., a building device is consuming 10% more electricity than in standard operating conditions), work order request view 2400 may not require recordation of the fault state. Further, fields of work order request view 2400 can be automatically populated based on the fault states indicated in alert view 2200 and/or troubleshooting view 2300. For example, the location and incident type fields of work order request view 2400 may be generated based on the fault states. Further, the priority field may be automatically determined based on the fault state. In this case, work order request view 2400 may determine the priority level to be “water detected” (i.e., high priority) based on the fault state.

Referring now to FIG. 25, a work order view 2500 is shown, according to some embodiments. The work order view 2500 includes an indication of the number of in progress, unresolved, and recently completed work orders. The work order view 2500 may also include a list of work orders and search feature configured to allow a user to search for work orders (e.g., to identify work orders relating to a particular type of equipment or equipment room). The work order view 2500 also includes a work order request button selectable to navigate to the work order request view 2400 as shown in FIG. 24.

Referring now to FIG. 26, a notes view 2600 is shown, according to some embodiments. The notes view 2600 shows various notes relating to maintenance of a building, building equipment, equipment room, etc. and allows a user to edit existing notes, delete existing notes, and/or add new notes. Multiple users may have access to shared notes to allow users to share notes and communications via the notes view 2600. Various users may have various permissions to edit, add, or delete various notes (e.g., a manager may be allowed to post new notes while others may only be allowed to comment on existing notes). The notes view 2600 thereby allows users to input, save, and share personal knowledge relating to service tasks.

The graphical user interface shown in FIGS. 8-26 thereby provides and comprehensive and unified application that allows users to manage and interact with various technicians, maintenance tasks, work orders, histories, alerts, and knowledge to facilitate service and maintenance of equipment in a UBMS in a seamless, intuitive, and user-friendly way. Various other features may be provided in various embodiments, including high-precision wayfinding within an equipment room to direct a user precisely to a device, a component of a unit of building equipment, a control panel, etc. and/or the ability to push troubleshooting commands to equipment from the user device 716.

Workflow Using Equipment Room UBMS Application

Referring now to FIG. 27, a flowchart of an example workflow process 2700 for service of building equipment facilitated by the equipment room UBMS application of FIGS. 8-26 is shown, according to some embodiments. Process 2700 can illustrate how the user device 716 may be used in a UBMS to facilitate service of building equipment facilitated by the views of FIGS. 8-26. Further, process 2700 can illustrate how unified control engine 702 can operate to automatically perform various operations to streamline efficiency of servicing of building equipment. It should be noted that interactions between the technician and systems may be facilitated by GUIs provided to user device 716. In this way, a technician can receive encompassing information indicating relevant information about the building equipment to be serviced. It should be understood that process 2700 is included as an illustrative example and that many workflows using the mobile application (or other type of application) described herein are contemplated by the present disclosure. In some embodiments, some and/or all steps of process 2700 are performed by unified control engine 702 and/or components therein as described with reference to FIGS. 7A-7C.

Process 2700 is shown to include generating a work order for an equipment room (ER) of a place responsive to a detection of a building equipment fault (step 2702). In the example of process 2700, the place may refer to a building. Detection of the building equipment fault can be based on various measurements that can be taken with regards to the ER. For example, the building equipment fault may be based on a detection that a building device is consuming an amount of resources (e.g., electricity, water, gas, etc.) exceeding a threshold amount, the building device is not responding to control signals and/or is not providing asset data describing operation of the building device, the building device was marked by a previous technician or other user as requiring maintenance, etc. In some embodiments, the detection is made based on a determination that a space of the place (or the place itself) is not achieving a mode for the space or place. In this case, the ER may require building equipment to have maintenance (e.g., repairs, replacement, new building equipment added to the ER, etc.) performed to shift the conditions in the space or place to achieve the mode. The work order can indicate information regarding what maintenance is required. For example, the work order may include information regarding what technician is to perform the maintenance, what building device(s) requires maintenance, when the maintenance is to be performed, a location of the building device(s) of interest, knowledge base information regarding the building device(s), etc. In some embodiments, step 2702 can be performed by required maintenance identifier 770 and/or work order generator 774.

Process 2700 is shown to include providing the work order to a technician (step 2704). In some embodiments, step 2704 includes generating a GUI to provide to a user device of the technician. The GUI can be constructed as to include information relevant to the technician regarding the work order. In some embodiments, the GUI provides a way for the technician to approve or deny the work order (e.g., via “approve work order” and “deny work order” buttons). It should be noted that if the technician denies the work order, process 2700 may include regenerating the work order and providing the new work order to a separate contractor, regenerating the work order to include a different service time, or any other appropriate action that can ensure the building equipment fault is addressed. In some embodiments, step 2704 is performed by GUI generator 764.

Process 2700 is shown to include initiating a pre-maintenance process to prepare for maintenance of the building equipment (step 2706). The pre-maintenance process can include a variety of pre-maintenance actions that can be performed to ensure the building, the ER, and/or other relevant spaces or places are prepared for arrival of the technician such that the maintenance can be efficiently performed. In some embodiments, the pre-maintenance process includes performing asset scheduling. In step 2706, asset scheduling may include, for example, setting access permissions for the technician at maintenance times and for spaces/places designated by the work order, scheduling lighting equipment to be activated in the ER during the maintenance times, scheduling HVAC equipment to be operated during the maintenance times to ensure the ER is comfortable for the technician, etc. Step 2706 may also include alerting security, building managers, and/or other personnel of the building/ER regarding the work order to be completed. In this way, building personnel can have knowledge regarding who to expect to perform the maintenance, when the maintenance will be performed, access permissions of the technicians (e.g., so they are not allowed into spaces/places they should not be allowed into), etc. In this case, building personnel may receive GUIs to user devices used by the building personnel indicating the information regarding the work order. In some embodiments, step 2706 is performed by maintenance module 766 and/or GUI generator 764.

Process 2700 is shown to include verifying access of the technician at arrival to the place (step 2708). As mentioned above, the place may, in this example, be a building to which the technician is scheduled to perform maintenance within. After receiving the work order in step 2704, the technician may review the work order and information related to a maintenance schedule to be performed. When the technician arrives at the building/place, the technician may sign-in or otherwise gain access to the building (e.g., via a RFID badge, via mobile application, using a key, via facial recognition, etc.) and then proceed to the correct equipment room. As should be appreciated, the ability for the user to automatically sign in may be a result of the pre-maintenance process performed in step 2706. In this way, the technician can have the ability to access the building immediately upon arrival. In some embodiments, the mobile application (or other application) may provide wayfinding features to facilitate guidance of the technician to the equipment room. Said wayfinding functionality can be provided via GUI on a user device of the technician. In some embodiments, step 2708 is performed by control signal generator 762 and/or another component of unified control engine 702.

Process 2700 is shown to include identifying the technician at arrival to the ER (step 2710). As an example, a wall-mounted stationary tablet positioned outside of the equipment room door can determine the identity of the technician (e.g., using service schedule information, using facial recognition, etc.). In this case, the identity of the technician effectively indicates their access permissions as set in step 2706 (and vice versa). It should be noted that in process 2700, access permissions of the technician are effectively confirmed twice (i.e., to the building and to the ER). A number of times the identity of the user is verified can be configurable and customizable dependent on a desired level of security. Confirming access permissions of the technician (or other users) multiple times can provide additional security to the building such that the technician cannot access spaces/places they normally do not have access to. In some embodiments, however, the identity of the technician may be verified only once (e.g., at arrival to the building). In some embodiments, step 2710 is performed by control signal generator 762 and/or another component of unified control engine 702.

Process 2700 is shown to include providing the technician with access to the ER and with information related to the ER responsive to identifying an identity of the technician (step 2712). If the technician has permission to access the equipment room (e.g., as entered by a facility manager in the locations permissions screen 1300 of FIG. 13 or as automatically provisioned after generation of a work order) as determined in step 2710, a door (or other barrier) to the equipment room may be automatically unlocked to allow the technician to enter the equipment room. In this way, the technician can be provided with automatic access to the equipment room with little effort for the technician. If the technician does not have permission to access the ER, the door (or other barrier) may stay locked. In some embodiments, if the technician is attempting to access the ER without appropriate permissions, security of the building may be alerted as to a possible hostile takeover of the ER.

If the identity of the technician is verified, the technician can be provided with information related to the ER. Said information may include, for example, a current operating status of the ER, what building devices are associated with fault statuses, how long the technician has access to the ER to perform maintenance, who the technician can contact in case of an emergency (e.g., a building supervisor), technical specifications regarding building equipment in the ER, etc. Other information provided to the technician may include, for example, space information relevant to the technician (e.g., work order history, critical alarms, space layout, relevant equipment locations, etc.). In some embodiments, the technician is provided wayfinding information generated in step 2712 such that the technician can be guided to the equipment that requires service from the technician. Any and/or all information provided to the technician in step 2712 can be provided via GUIs transmitted to the user device of the technician to be displayed (e.g., via the mobile application) on the user device. In this way, the technician can be provided with relevant and critical information regarding the building equipment and ER overall. In some embodiments, step 2712 is performed by maintenance module 766 and/or GUI generator 764.

Process 2700 is shown to include receiving an indication from the technician regarding a status of the ER (step 2714). In step 2714, the user may (e.g., via the user device of the technician) provide feedback regarding an analysis of the ER. The analysis may include information regarding, for example, if the required maintenance can be completed in the maintenance time window, if any additional unscheduled maintenance is required, etc. In particular, if the technician encounters unscheduled problems in the equipment room that require immediate repairs, the technician may enter such information into the user device of the technician. In effect, step 2714 can include information regarding a state of the ER based on analysis of the technician. In some embodiments, step 2714 includes logging the information provided by the technician in a database. In some embodiments, step 2714 is performed by data collector 760 and/or asset information database 768.

Process 2700 is shown to include determining if any unscheduled maintenance is required (step 2716). Based on the indication describing the status of the ER received in step 2714, a determination can be made regarding whether any unscheduled maintenance is required. If the technician indicates unscheduled maintenance is required (step 2716, “YES”), process 2700 may proceed to step 2718. If no unscheduled maintenance is required (step 2716, “NO”), process 2700 may proceed to step 2720. In some embodiments, if unscheduled maintenance is required but cannot be completed by the technician during a current visit, a new iteration of process 2700 may be performed with regards to the unscheduled maintenance. In some embodiments, step 2716 is performed by unified control engine 702.

Process 2700 is shown to include recording the unscheduled maintenance and providing the technician with additional information applicable to the unscheduled repair (step 2718). As described above, if the technician encounters unscheduled problems in the equipment room that require immediate repairs, the technician may enter such information into the user device and receive various diagnostic information, data, troubleshooting instructions, service manuals, wiring diagrams, replacement part orders/stocking info, programmable controls, point override capabilities, etc. via the user device in response. The technician may then conduct the immediate repairs before moving on to the scheduled service. Advantageously, the technician can be automatically provided with relevant information regarding the unscheduled repair even though said information may not have been prepared during generation of the work order. In other words, the system providing the information to the technician (e.g., unified control engine 702) can dynamically respond to unscheduled maintenance by recording (logging) information regarding the unscheduled maintenance and gathering information that can be used by the technician to complete the unscheduled maintenance. In some embodiments, step 2718 is performed by various components of unified control engine 702.

Process 2700 is shown to include recording information related to scheduled repairs of the work order (step 2720). Step 2720 may be performed whether or not unscheduled maintenance is needed. In step 2720, the technician may perform the scheduled service of the building equipment and make notes to account for the scheduled service. The technician may be provided with various knowledge from a knowledge base relating to the schedule service. The technician may input various notes, photographs, etc. to the mobile application to create a record of the service and/or to flag any issues that may require follow-up. In some embodiments, if the scheduled maintenance is not completed within an allotted timeframe or if the technician notes anything that may necessitate further inspection, a new work order may be automatically generated such that process 2700 can be performed again for the new work order. In some embodiments, the technician manually generates a new work order for additional maintenance that should be performed (e.g., via GUIs provided by the user device of the technician). The technician may also use the user device running the mobile application to close the work order and provide any other relevant information (e.g., time spent, parts used, costs, etc.). A service job may thereby be completed with assistance from the user device. In some embodiments, step 2720 is performed by data collector 760 and/or asset information database 768.

Process 2700 is shown to include receiving and logging a report from the technician summarizing information about maintenance and other information about the ER (step 2722). In some embodiments, step 2722 is integrated with step 2718 and/or step 2720. In essence, step 2722 can gather additional information regarding the ER as reported by the technician. Said information may include a report of all activities performed, when the technician entered and left the ER, updates to warranties of building devices, etc. In this way, information that may be useful to future technicians, building managers, and/or other users may be accessible for later use. In some embodiments, step 2722 is performed by data collector 760 and/or asset information database 768.

In some embodiments, the systems and methods described herein are associated with one or more unified building management systems as described in greater detail in U.S. patent application Ser. No. 16/261,301 filed Jan. 29, 2019, U.S. patent application Ser. No. 16/132,045 filed Sep. 14, 2019, U.S. patent application Ser. No. 16/287,773 filed Feb. 27, 2019, U.S. patent application Ser. No. 16/186,302 filed Nov. 9, 2018, and U.S. patent application Ser. No. 16/186,230 filed Nov. 9, 2018, each of which are incorporated by reference herein in their entirety. In some embodiments, the systems and methods described herein can be implemented in any of the unified building management systems described in the incorporated patent applications.

Configuration of Exemplary Embodiments

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

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

As used herein, the terms “circuit” and “control engine” used herein may include hardware structured to execute the functions described herein. In some embodiments, each respective “circuit” may include machine-readable media for configuring the hardware to execute the functions described herein. The circuit may be embodied as one or more circuitry components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc. In some embodiments, a circuit may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOCs) circuits, etc.), telecommunication circuits, hybrid circuits, and any other type of “circuit.” In this regard, the “circuit” may include any type of component for accomplishing or facilitating achievement of the operations described herein. For example, a circuit as described herein may include one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR, etc.), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and so on).

The “circuit” or “control engine” may also include one or more processors communicably coupled to one or more memory or memory devices. In this regard, the one or more processors may execute instructions stored in the memory or may execute instructions otherwise accessible to the one or more processors. In some embodiments, the one or more processors may be embodied in various ways. The one or more processors may be constructed in a manner sufficient to perform at least the operations described herein. In some embodiments, the one or more processors may be shared by multiple circuits (e.g., circuit A and circuit B may comprise or otherwise share the same processor which, in some example embodiments, may execute instructions stored, or otherwise accessed, via different areas of memory). Alternatively or additionally, the one or more processors may be structured to perform or otherwise execute certain operations independent of one or more co-processors. In other example embodiments, two or more processors may be coupled via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. Each processor may be implemented as one or more general-purpose processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), or other suitable electronic data processing components structured to execute instructions provided by memory. The one or more processors may take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, quad core processor, etc.), microprocessor, etc. In some embodiments, the one or more processors may be external to the apparatus, for example the one or more processors may be a remote processor (e.g., a cloud based processor). Alternatively or additionally, the one or more processors may be internal and/or local to the apparatus. In this regard, a given circuit or components thereof may be disposed locally (e.g., as part of a local server, a local computing system, etc.) or remotely (e.g., as part of a remote server such as a cloud based server). To that end, a “circuit” as described herein may include components that are distributed across one or more locations. The present disclosure contemplates methods, systems and program products on any machine-readable media for accomplishing various operations. The embodiments of the present disclosure can be implemented using existing computer processors, or by a special purpose computer processor for an appropriate system, incorporated for this or another purpose, or by a hardwired system. Embodiments within the scope of the present disclosure include program products comprising machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.

Claims

1. A building management system comprising:

building equipment operable to affect a variable state or condition of a building;

a control system comprising a processing circuit configured to: receive asset data relating to operation of the building equipment; identify a building device of the building equipment in a fault state based on the asset data; generate a work order in response to identifying the building device in the fault state, the work order indicating a required maintenance action and a maintenance time window; automatically populate a plurality of fields of the work order based on the fault state; and provide the work order to a user device.

2. The building management system of claim 1, the processing circuit further configured to schedule access permissions for a technician based on the work order.

3. The building management system of claim 1, the processing circuit further configured to:

retrieve troubleshooting instructions related to the building device; and

provide the troubleshooting instructions to the user device;

wherein the work order is generated responsive to an indication that a user is unable to fix the fault state based on the troubleshooting instructions.

4. The building management system of claim 1, wherein the fault state is identified based on a determination that the building is not achieving a mode, the mode corresponding to at least one of:

an operational mission for the building;

a job-to-be-done in the building; or

an event occurring in the building.

5. The building management system of claim 1, the processing circuit further configured to:

generate a maintenance alert indicating the fault state; and

provide the maintenance alert to the user device.

6. The building management system of claim 1, wherein at least a portion of the work order is automatically populated based on the asset data.

7. The building management system of claim 1, the processing circuit further configured to:

log maintenance information provided by a technician, the maintenance information describing an operating state of the building device; and

predict a change in a mode of the building based on the maintenance information.

8. A method for maintaining building equipment, the method comprising:

receiving asset data relating to operation of the building equipment, the building equipment operable to affect a variable state or condition of a building;

identifying a building device of the building equipment in a fault state based on the asset data;

generating a work order in response to identifying the building device in the fault state, the work order indicating a required maintenance action and a maintenance time window;

automatically populating a plurality of fields of the work order based on the fault state and

providing the work order to a user device.

9. The method of claim 8, further comprising scheduling access permissions for a technician based on the work order.

10. The method of claim 8, further comprising:

retrieving troubleshooting instructions related to the building device; and

providing the troubleshooting instructions to the user device;

wherein the work order is generated responsive to an indication that a user is unable to fix the fault state based on the troubleshooting instructions.

11. The method of claim 8, wherein the fault state is identified based on a determination that the building is not achieving a mode, the mode corresponding to at least one of:

an operational mission for the building;

a job-to-be-done in the building; or

an event occurring in the building.

12. The method of claim 8, further comprising:

generating a maintenance alert indicating the fault state; and

providing the maintenance alert to the user device.

13. The method of claim 8, wherein at least a portion of the work order is automatically populated based on the asset data.

14. The method of claim 8, further comprising:

logging maintenance information provided by a technician, the maintenance information describing an operating state of the building device; and

predicting a change in a mode of the building based on the maintenance information.

15. A building management system comprising:

building equipment operable to affect a variable state or condition of a building;

a control system comprising a processing circuit configured to: obtain a work order for the building equipment, the work order identifying a location of the building equipment and a time at which maintenance is to be performed on the building equipment; schedule access permissions for a service technician based on the work order, the access permissions authorizing the service technician to access the location of the building equipment at the time at which the maintenance is to be performed.

16. The building management system of claim 15, the processing circuit further configured to generate the work order in response identifying the building equipment is in a fault state.

17. The building management system of claim 15, the processing circuit further configured to:

obtain information related to the building equipment from a knowledge base;

identify the service technician at the location during the time at which the maintenance is to be performed; and

provide the information related to the building equipment to the service technician in response to identifying the service technician.

18. The building management system of claim 15, the processing circuit further configured to:

generate wayfinding information to facilitate guidance of the service technician to the building equipment; and

provide the wayfinding information to a second user device of the service technician.

19. The building management system of claim 15, the processing circuit further configured to perform a pre-maintenance action based on the work order, the pre-maintenance action comprising at least one of:

scheduling lighting equipment to be operated during the time at which the maintenance is to be performed; or

scheduling heating, ventilation, or air conditioning (HVAC) equipment to operate during the time at which the maintenance is to be performed.

20. The building management system of claim 15, the processing circuit further configured to predict how the maintenance will affect a mode of the building, the mode corresponding to at least one of:

an operational mission for the building;

a job-to-be-done in the building; or

an event occurring in the building.