Division 25 “Integrated Automation”

Why are so few new projects utilizing a specification division that was developed 12 years ago? When I ask architects I generally get 1 of 3 answers: “the owner doesn’t want to pay extra for that”, “it didn’t come up in conceptual design discussions so why complicate the project”, or “what is Division 25?”. The first two are understandable (although after many years of progress, now incorrect). And the third; well…a result of many years of the first two.

The short answer to why Division 25 has not worked is that it was a traditional construction industry solution to a new kind of problem for the built environment. Buildings take 3 years or more from concept through planning, design, and construction. And they are often built to last 100 years or more. Integration is a software problem, and the software industry involves radical changes in means and methods every 18 months. But to arrive at a solution, we must first more fully understand the history of “building automation systems” (BAS).

When Warren Johnson invented the thermostat while teaching college in Whitewater Wisconsin, he simply wanted to automatically control his classroom temperature so that he could avoid the hourly interruptions of the janitor that was checking the room temperature for students. He later went on to hold more than 50 patents, and invented the pneumatic temperature control system. The BAS industry was born, and 125 years later his company is an industry powerhouse (Johnson Controls Inc.).

As Direct Digital Controls (DDC) and computers took over the role of pneumatics in the 1980’s, the mechanical engineer continued to design these “temperature controls systems”, and the mechanical contractor continued to install them (the trade that had been installing and piping the pneumatic tubing systems and the associated compressor system). This was paralleled in the lighting world as digital lighting controls began taking over older analog systems (designed and installed by electrical engineers and contractors). And the race of the BAS “protocols”, or which computer language would control particular components of a building, had begun. You’ve no doubt heard many acronyms (BACnet, Lon, Modbus, DSI, DALI, etc, etc.).

Fast forward to 2015. There is almost no piece of major equipment in the building that doesn’t have a computer embedded in it: the cooling (chillers) and heating (boilers) equipment, the backup power generation equipment, the elevators. And all of these computers speak their own language (proprietary manufacturer protocols) and sometimes “convert” to a common language (BACnet, Modbus, etc.). Increasingly much smaller components of the building now have “brains” such as light bulbs, door locks, window blinds, etc. And they all have means of communicating with the building computer network (wire, Ethernet cable, fiber, built-in WiFi, BlueTooth, and now LoRaWAN). It’s getting more complex by the day.

This brings me to a recent quote from the 2015 biography of inventor Elon Musk, “Elon Musk, Tesla, SpaceX and the Quest for a Fantastic Future” by Ashlee Vance. The quote is from Tesla employee and former Ford Motor Company R&D lab director, TJ Giuli. He stated that

“Inside of every Ford were dozens of computing systems made by different companies that all had to speak to each other and work as one. It was a mess of complexity that had evolved over time, and simplifying the situation would prove near impossible at this point, especially for a company like Ford, which needed to pump out hundreds of thousands of cars per year and could not afford to stop and reboot. Tesla, by contrast, got to start from scratch and make its own software the focus of the Model S. Software is in many ways the heart of the new vehicle experience. From the powertrain to the warning chimes in the car, you’re using software to create an expressive and pleasing environment. The level of integration that the software has into the rest of the Model S is really impressive.”

I probably do not have to elaborate any further on exactly how we got to this point in the commercial building industry; where we have the “pipe fitter and sheet metal contractor” purchasing the computers for the building. And this is no disrespect to any of our industry’s mechanical contractors; I used to work for one. Some mechanicals have in fact become very sophisticated and have created their own controls divisions and have been very successful in doing so. But this does not change the fact that 95% of buildings are left “un-integrated” because we now have a design & construction model that is “broken”. And anything done to “fix” the building technology web of complexity with Division 25 (the 5% of the time it’s attempted) is typically a band-aid approach. And it actually makes matters much worse (an additional computing system, more software to manage & update, more complexity making IT security even more difficult, etc), to simply to display disparate data onto a single screen.

What can you do to fix this problem? Much like Tesla, you must start from scratch when considering the software “operating system”. The technology already exists to integrate all building systems in a single operating environment, regardless of their specific “protocol”. And this “non-proprietary operating system standard” is not only more cyber-secure (with roots in “software” rather than HVAC or lighting), it is compatible with all earlier versions of all brands of BAS software, through API’s (application program interfaces). So no need to “replace all the controls on your campus”; simply spend your money more wisely going forward.

When selecting an expert, your technology consultant should certainly be someone experienced with collaborating with your other consultants (MEP, security, fire, elevator, etc.). But most importantly, this consultant’s core business should be software (a company that understands and can design IT infrastructure and networks, but is first a “software company”). This “software designer” must be involved in early conceptual design stages, to ensure the final user experience meets software industry standards on day 1 of occupancy and is ready for software maintenance & updates that do not involve expensive service agreements by proprietary hardware manufacturers or construction contractors.

And why bother “upsetting your industry paradigms”? Because single operating system buildings:

1. Cost less to build.
2. Cost MUCH less to operate and maintain.
3. Create more integrated occupant experiences.