Self-Learning Building Automation: What Took Us So Long?

Jim Sinopoli PE, RCDD, LEED AP Managing Principal, Smart Buildings LLC Contributing Editor

Articles

Interviews

Releases

New Products

Reviews

Editorial

Events

Sponsors

Site Search

Newsletters

Archives

Past Issues

Home

Editors

eDucation

Training

Links

Software

Subscribe

The early years of the 1900’s were the early days of aviation. While there may have been other self-learning systems in the early 1900’s, the first autopilot for airplanes was developed in 1912, and demonstrated in 1914. It was the most significant self-learning system at that time. In the first demonstration of the invention by the inventor Lawrence Sperry during flight, Sperry and his mechanic climbed out of the airplane’s cockpit and onto the wings, and the autopilot (a gyroscope-equipped stabilizer) immediately took over and corrected the attitudinal change of the wings. Imagine the mettle and confidence of those men for them to sit on the wings of a plane in flight to demonstrate that Sperry’s invention worked. It was the early years of the aviation industry that seemed to attract those that were daring, innovative and had vision.  

Probably one of the best examples of self-learning is some of the Distributed Antenna Systems (DAS).The advanced DAS systems can deploy a Self-Organizing Network (SON).  The SON capabilities are sophisticated. The network can automatically configure and integrate new equipment into the wireless network; something similar to plug and play; the DAS network discovers new components in a system without the need for a technician to manually configure the equipment. The SON can also automatically optimize the wireless network. It optimizes based on data from the system itself. An example of self-optimization is the automatic switch-off of a percent of base stations during the night hours which would reconfigure to cover a larger area or a significant increase in usage. Finally, the network can self-heal; the network can identify faults or failures in the network such as failing base stations, and automatically compensates and re-configures the wireless network to minimize the impact.

The DAS networks can now move cell capacity from one location to another and identify what radio spectrums and what uses are needed on-demand in real-time. The DAS can provide on-demand capacity wherever and whenever it is needed.

The origin of autopilots for airplanes is interesting and possibly instructive for buildings. The roadmap to advanced automated buildings involves several key issues the industry and building owners need to address:

Granular Data –Building-wide or system-wide data will not be sufficient for a highly automated building. The metrics are too broad and general. The spaces within most buildings are too different regarding their orientation, use, occupancy, needs, etc. Granular data provides for more precision in properly managing specific spaces within a building potentially resulting in squeezing out the smallest amount of excess energy consumption and improving occupant satisfaction. Going “granular” will mean more sensors, tailored controls for individual spaces, and a bit more investment, which expectantly would be returned in better and less costly building operations.

Detailed Policies and Logic – For a building to be fully automated it will require that the “logic” or the “policies” of the automation use an array of data, data sources, and predetermined rules. As buildings become more complex, the decisions on their performance become more complex because there are more variables in a decision. Defining the logic or policies will take extensive planning, sometimes a shortfall of typical facility management; an example being a dearth of detailed written alarm management plans. The policies will need to touch on every significant building situation or scenario affecting energy, operational costs and tenant comfort. Planning should involve diverse groups within a building’s ownership and management. It is really an exercise to develop the brains of the automation and in the process, deciding how the building should adapt to changes and how it should perform.

Much of the data used as a basis for “policies” will be near real time data from the building systems, but critical data and system-to-system communications are needed with the facility management systems, business systems, the utility grid and other external systems, such as weather or energy markets.

Maybe the development of “logic” and “policies” should start with fault detection. If you have a fault detection application, you already have rules or a process to identify a fault. What we now need is the “logic” or “rules” of an automated response to correct the fault, essentially the other “half of the loaf.” The first autopilot instrument, the “gyroscope stabilizer,” built 100 years ago, could both identify a condition and activate a mechanism to correct it. That’s what we need in our buildings today.

Data Analytics – If you are buying books or music from an internet site, it’s likely that the internet company analyzes your purchases, creates a profile of what type of books or music, authors or performers you like, and then proactively sends you email regarding other books or music you may be interested in purchasing. This is an example of an industry sector “mining data” to improve their business performance. Generally, facility management has not been one of those sectors.

Part of a high level of automation in a building must be analyzing data because it’s the data that will be the foundation of the logic or policies of the automation.  Call it data mining, business intelligence or predictive analytics, it comes down to analyzing the buildings data, finding trends in how the building is performing or being used,  inferring relationships between variables (the obvious example being energy consumption and occupancy or time of day), then using that information to predicted how the building perform under different scenarios. This is likely to bring new perspectives to the building and new ideas for how to operate the building. Lastly, the need for data analysis is one rationale for more integrated building management systems, which can provide for a unified database of building system data.

Vast Amounts of Sensors

Highly automated buildings will need additional sensors and metering for all the energy and sustainability systems: HVAC, lighting, plug load, water use, and water treatment and reclamation. Plug load, a significant use of energy, stands out as one system where not enough is being done.

A key metric is an occupancy, and it may be the most difficult building metric to obtain. It’s not because there is not a technical solution to measure occupancy, because in fact, a number of solutions exist, each with advantages and disadvantages.  Most lighting control system can accommodate an occupancy sensor into their system; some can estimate the path the occupant is taking, others use the lighting control occupancy sensor for control of the plug load with the room or space. Video cameras, access control systems, infrared sensors on door frames, RFID tags; sensing whether the spaces’ IT equipment is on, etc. are all ways to sense occupancy. Also, occupancy is different than people counting, where accurate numbers of people entering and exiting a space are needed. Finally occupancy sensing, depending on the technical method, can raise privacy concerns. Regardless, in a highly automated building occupancy data is critical to energy use and overall building performance.

Moving FM from a Reactive to a Proactive Operation – Things break, alarms and emergencies happen, and FM will always react to those events. But to deploy and develop the policies of advanced automation in buildings, FM will need to embrace planning and become much more proactive. A highly automated building will require numerous policies, control logic and sequences of operations, taking into account many variables. Each of those policies will need to be considered and established in detail.

Pushed by energy and financial concerns and technology advancements, the building industry has made great strides in building controls and automation.  However, despite the advancements, we’re not even close to the potential of automation to improve and optimize building performance. More automation, much more than anything currently deployed, would not only improve buildings’ performance but also support the facility management challenge of managing more complex buildings at a time when required skills sets and knowledge are constantly changing and in short supply. An example of where we are at and where we need to go, would be a software application such as fault detection and diagnostics, probably the most effective building analytic application on the market today, but still only “half a loaf.” What if we had an application that not only could automatically detect faults, but also automatically correct the faults? Maybe something similar to an autopilot.