Babel Buster Network Gateways: Big Features. Small Price.
So, you have an intelligent building. Congratulations. Web-enabled. Operational systems connected on a shared IP backbone. All the coolest technologies—Web services, SOAP/XML, etc. You can sit on your couch, connect wirelessly to your control systems and… accomplish nothing that you couldn’t before.
What? Everything is connected—it has to be better.
Your building might be “intelligent,” but all too often it has nothing to say.
It’s Not About Technology
In all the discussion about Building-IT convergence, it seems that everyone forgot about the “I” and focused on the “T.” After all, get a bunch of technologists together and the conversation is bound to become about technology. Only problem is, the buyers (building owners, facilities executives, CEOs, CFOs) don’t really care. They care about business value—operational and financial information, productivity, verifiable savings, accountability—not technology standards.
The IT world has repeatedly demonstrated, through both its successes and failures, that technology without clear business purposes is a complete waste. The buildings world needs to heed that lesson, not repeat the mistakes.
Let’s take the focus off IP, except as an enabling technology and implementation standard. IP itself is not the answer, at least not to any question a CEO ever asked (John Chambers excluded, of course).
Value is in the Information
The business value of Building-IT convergence comes from information. More specifically, from being able to extract actionable information from operational data. No data, no information—no information, no business value. All the technology infrastructure in the world won’t change that. IP connectivity without data is like a superhighway without on ramps.
If you’re thinking to yourself, “I can get any data I want out of my building automation system—what’s the big deal?” then start considering these questions:
Can you collect all the data, simultaneously, from every point in your building systems, or from just a few dozen (or perhaps a few hundred) points?
Could you view the operational data for the past year, for any piece of equipment in a building or the physical plant, if you needed it right now?
Is the data from all operational systems (BASs, meters, utility data, fire and safety, etc.) available in one place, time synchronized for easy comparisons?
Is the operational data integrated with other business systems, such as space planning systems and CMMS?
Does everyone who could benefit from the information—inside and outside facilities—have access, and is it organized to meet each user’s individual needs?
Are the IT applications (designed for the business of running a facility) in place to achieve the productivity gains, cost savings, and other business benefits possible?
If you answer “no” to most of these, you’re not alone. After talking to well over 300 facilities people in the past two years, less than two percent are doing anything to address the need for data. But those two percent are reaping the rewards.
Massive Productivity Gains
It is often said that if you can raise the productivity of the entire workforce by just one percent that the benefits far outweigh energy/operational costs to make that happen. While conceptually interesting, these arguments typically have enough holes in them to vent a boiler room. Not what we’re talking about.
Instead let’s look at making dozens of people across facilities and maintenance organizations more productive by 70, 80, even 90%. Take a senior engineer for example…
A Web-based interface to the control system means the engineer can operate from anywhere. What’s the value? Well, it means they can override a setpoint from their living room while watching “24” and wondering why Chloe has schematics to every facility in existence, but they still can’t get “as built” drawings for their latest building. Convenient? Yes. Did it change what they could do, or their productivity? Only a little—there is some value to not having to return to the control room for everything.
What did that same engineer do all day? They spent four hours trying to collect data from various sources to do some analysis. They took spotty data from control systems, data loggers, and threw in some estimates, combining six spreadsheets so that the timestamps matched and they could finally do the analysis. Then they did 20 minutes of actual engineering. This, unfortunately, is the norm.
Stop Wasting Time
Whether it’s internal staff or a contracted engineering firm, engineers spend 4 – 12 minutes collecting data for every minute of actual engineering. It is such an accepted way of life that organizations don’t even realize how much time is wasted. If the building had something to say, it reverses that ratio, improving our engineer’s productivity by as much as 90%.
That’s just the tip of the iceberg. There are dozens of commonly performed tasks, ranging from simple equipment information requests and performance measures to complex financial analysis and energy audits, where the productivity gains can be multiple orders of magnitude in scope when all the data is available.
New Value from Old Data
A permanent record of facilities operations is an asset, just as the physical structures are. Its value is not just in having history, but in how it can be used. When all the data is available, the building has a lot to tell about past, present, and future operations.
First, a simple case. For diagnostic purposes, the data values at the time of equipment malfunction, or after the hot/cold call came in, is of minimal value. The historical data leading to the problem is where the information lives to identify and fix the root cause. The old data delivers new value by way of solving today’s operational problems.
But there is more that you can do. One great thing about collecting building data into an IT application is that you can do things with it without interfering with ongoing operations. You’re not limited to just mining the data, you can add to it. You can build calculations on top of the raw data. Instead of building models based on engineering assumptions and design specs, run those same equations against actual operational data. Want to change the model? Go ahead and run it again. Compare the two results. Manage cost, consumption, comfort. Normalize for weather or inflation. The beauty of having a complete operational record in a data warehouse is that you’re not limited to analysis or modeling going forward, but you can also apply them to the past. With the data, buildings have an endless supply of information to tell you.
Ensuring Your Buildings have
Something to Say
Unfortunately, it is still hard and/or expensive to get data out of the underlying building systems and accessible through IT applications. There are proprietary systems still shipping today. Concepts like “proprietary BACnet” exist. Remember, the data belongs to the building owner, not the systems vendor.
Even open systems don’t necessarily allow an IT application to collect all building system data. Architectures were developed for control, not information access (a reasonable decision given that control is the system’s primary function), which sometimes results in the case where you can collect data from any point, but not from all points. Don’t forget, most existing buildings aren’t equipped with the latest open technologies; they have systems that are a decade old.
Read that last paragraph again—the distinction between access to any data and actually having all the data is critical. It’s the difference between a control system-based building and an information-based building. In fact, it’s important enough that we’re writing a follow-on article for next month on just this subject.
While overall this situation is slowly getting better, there are vendors doing the open systems Moonwalk—taking steps with the illusion of going forward while actually moving backwards, making data harder to collect. To cover up their shortcomings, some manufacturers will question why you need the data or disparage the cost of collecting and storing data (today’s cost of storage is insignificant). Don’t be fooled.
Let’s assume you’ve solved the problem of collecting data. Will your buildings become downright chatty? Not so fast. Another lesson the IT world has learned over the past 30 years is that architecture matters. Just because you’ve put a boatload of operational data into a database doesn’t mean you have a usable information source. The database architecture itself must reflect the business requirements for both getting the data in and getting information out. A bad IT architecture leads to a building that only mumbles and is too hard to understand.
And finally, even with data and a good data warehouse architecture, there is still the application layer that must extract information from the data, and enable the business to realize the value in the information. A good IT application is defined around the business requirements and applies technology to deliver the goods.
Don’t leave this to amateurs. Unfortunately, most controls vendors and engineering firms are not information technology wizards, and most IT players don’t understand the business problems. (No one said this was easy.) There are companies that understand both—find them.
How can a building be intelligent if it has nothing to say? It can’t.
How does this happen, that buildings thought to be intelligent sit there quietly, saying nothing? By focusing solely on the technology. By forgetting that it’s the information that provides business value. By assuming that the data is always available.
Intelligent buildings must talk. The business value is only achieved when they share what they know, communicating between building systems and with their owners. They do this through data. Without the data you limit the building’s intelligence and you limit what you can accomplish. Technology infrastructure doesn’t change that.
Architects say that form follows function. The IT equivalent is that technology follows business function. Otherwise, you get technology in search of an actual problem to solve. This has happened many times in the past and unfortunately, is doomed to repeat itself. In the end, it’s always the same result—no business value equals eventual failure.
See you at BuilConn.
About the Authors
Bill Gnerre is the CEO and cofounder of IDS. With over 20 years of information technology entrepreneurial experience, he has an exemplary record of bringing enterprise software applications to market and dealing with user adoption of new technology. In addition to facilities operations and enterprise energy management, his background includes experience with CAD/CAM, engineering document management, PDA data collection, and other customized enterprise applications. Bill provides leadership and strategy for IDS and works closely with clients to ensure their success. He can be reached at firstname.lastname@example.org.
Kevin Fuller is responsible for marketing and product development for IDS. He brings over 20 years of technical and marketing experience in database, data warehouse, OLAP, and enterprise applications to his role as executive vice president. Kevin has a strong appreciation of how businesses use data to their advantage, and focuses on how to apply technology to solve real business problems. He can be reached at email@example.com.
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]