Yesterday I had the pleasure of a tour by Darrell Smith, Director of Microsoft Facilities & Energy, of the Redmond Operations Center (ROC). Facilities & Energy provides internal support; it is not a product line. The ROC applies Big Data to the operations of buildings on Microsoft’s home campus. In concept, the ROC is much like the Enterprise Building Management System (EBMS) at the University of North Carolina that I have written of. The results at Microsoft, though, are much more successful.
Darrell avoided the trap that we fell into at UNC, the trap that says that until the in-house enterprise system can control all the systems, it is a failure. In the Redmond Operations Center, Microsoft concentrated first on data mining and operational improvement. By Darrell’s definition, his system will be mature when it does control as well, and may never reach that level of maturity. In the meantime, he is finding wins every day by applying analytics to improve operations.
The center produces two kinds of analytics, alerts and reports. Each of them is focused on finding ways that Microsoft is wasting money every day, and fixing them.
Everybody who works with building systems is aware of the alarm spam that traditional systems send out. Turning off is an Alarm. Turing on is an Alarm, Catching on Fire is an alarm. Build alarms are events with almost no meaning. The Redmond system reads the low level protocols and harvests state information and alarms. The system also gathers other factors from a number of sources, including essential weather information.
To generate Alerts at the ROC, building engineers instead describe patterns. The system gathers a mass of information from each system and air handler tracked. The in-house engineers create queries that identify such issues as short cycling, or incomplete closing of dampers, which they name Faults. The engineer carefully examines the operation a single air handler, or a single building to find a problem. This problem is then described by means of a query that brings back this problem and similar faults in other buildings. For each fault, a cost is assigned by the system based on the size of the system, how much energy it uses, the system’s operating schedule, etc.
In the ROC, all active faults can be seen by building or by system, and can be sorted by cost or criticality. Generally, expensive ones are fixed first. Each work order is tagged with the cost that is being avoided by a timely fix.
Because Microsoft has a learning culture, this process reduces energy use even in the buildings not yet accessible to the ROC. Building mechanics fix problems early in monitored buildings and can see results. They share what they have learned with others in buildings not yet monitored, and the underlying faults are fixed in them, too.
Reports, as I understand them, look for more inchoate patterns. A report can describe many attributes of system or group of similar systems. Reports reveal operational outliers, i.e., the air handler that runs all night, or the system whose damper opens unexpectedly. A newly trained mechanical engineer may take a day or two to define a report. Once defined, it can be run again and again, including for other systems and for other buildings.
Think for a moment of the most powerful thing you have done with a spreadsheet pivot table. Now consider applying that task and that visualization to raw operating data from your buildings every day, and using the results to generate work orders. This is what the Facilities and Energy group has done in the Redmond Operations Center. They find real problems in operation and configuration of building systems every day, price them, and fix them. That is enough, even without control.
Microsoft is doing other things with their own facilities operations which I may write about later. But today, I am marveling at the data-based operation of facilities.