Today’s Smart Building Data Exhaust May Be Tomorrow’s Machine-Learning Gold Smart Building Owners should remain vigilant in the battle against vendor lock-in of their building data.

Alper Üzmezler, BASSG LLC. & Therese Sullivan, Principal, BuildingContext Ltd Contributing Editor

“Take back the Internet!” is the Net Neutrality movement’s rallying cry against big telecom and cable companies. “Take back your life!“ say digital privacy advocates in warning against the online advertising industry. “Take back your enterprise!” is how the Open Source software movement positioned itself vis-a-vis big-brand business software.  And, “Take back your building!” is how the open-protocol building automation community has framed its alternative to protocol lock-in by big OEMs.

None of these battles started yesterday, and none of them will end tomorrow. Caveat Emptor, a principle of business so infernal and eternal that you have to say it in Latin, applies: If the people using data and investing in data tools don’t get educated, vendors are going to act in their own self-interest. The battle against building data lock-in could be moving to a new arena, from serial cabling protocols to the Application Program Interfaces (APIs) defined by Cloud-hosted applications. Let’s not let that happen.

Yesterday’s BMS Protocol Wars

The history of the building controls industry is marked by stages of vendor lock-in. When the buildings industry was first going digital decades ago, BMS manufacturers wrote their own protocols to transport data over serial cable. They made these proprietary, providing keys only to technicians within their sales channel with the result that they had a near monopoly when future service and upgrading was required. These service revenue streams were more valuable than the original price of the systems. It then became a practice to price low during the initial bidding process, with the intention of charging captive customers more later. This led to complacent, slow-to-innovate vendors and unhappy customers who felt they were being milked with every service call. These are all good lessons that no one wants to relearn.

BACnet and other open communications standards were meant to put an end to this syndrome and bring back market forces. With open standards, controls contractors could work on equipment from multiple brands and customers could again run competitive bids for their business. The lock-in practice died slowly though, as Darren Wright, a Director at Arup explains here.  For a while, OEMs could say they were BACnet-compliant, but still maintain proprietary protocols at the BMS controller-level.The era of the Internet of Things is expected to finally bring the serial cable protocol wars to their conclusion. But, a similar approach to vendor lock-in, or even worse, could happen with closed APIs within cloud services.

An Open Future Demands Open SDKs

In the interest of Caveat Emptor, any project teams evaluating cloud solutions should ask vendors “Will near-realtime and historical trend data be available to us when we want it?” If the answer is “We have APIs.”— red flag. APIs are not enough!  If any company is holding your building’s HVAC, lighting, power meter or other operational data in their cloud, the chance that you will be able to access it in a practical way via their APIs is quite slim. What you want to be asking cloud service vendors is “Do you supply free Software Developer Kits (SDKs) in open source languages?” If you opt for only cloud services that provide this assurance, your data won’t be held for ransom when the inevitable day comes that you need it for your company’s own internal purposes or to supply as data streams to other vendors. Here are a few more guidelines:

• Ask about SDKs for the cloud server side as well as for the client or edge device side.
• The SDKs should be available in JAVA C++  for client javascript and any other popular open languages for the particular service.
• The file format should not be cryptic. Definitions to open source files are needed, even if the file format is open source. File format definitions are widely available; for example, there is open source for yaml and json.
  
• If the cloud application is using custom-file-format source code to parse and compile, this file format should be supplied in all languages in the SDKs.
• Ask if any other company is using the particular cloud vendor’s APIs, and confer with the references provided.

The Project Haystack open source community provides a good example of the type of Software Development Kit support needed to ease data interoperability in a full range of use cases:

Predictive Value in Data Exhaust

As more and more sensors and digital devices are introduced into buildings, digitizing more physical processes at tighter intervals, it is a natural impulse to look for ways to hand-off the burden of managing all that data. Except for the tip-of-the-iceberg analytics results, new data just seems like new problems—so much data exhaust with no real value. But, when a cloud service takes your data and starts observing operations and applying algorithms, new value is being created. The vendor has a right to its portion of that value, but the newly calculated data should also be readily accessible to the customer, i.e. the building owner. Software companies may be a step ahead of facilities managers and building owners about machine learning and artificial intelligence concepts; however, customers too want to get all the predictive value possible from their buildings’ digital streams. As we covered in our September article, it is imperative that building owner takes the reins of their operational data strategy today. This is how they can position for success as we move into an era of more autonomous buildings.

[an error occurred while processing this directive]Deciding among platforms for energy management and building operations management is challenging. There are so many. But, the lessons that the buildings industry has learned from the past should inform next steps. The general software industry offers its lessons as well. All the critical plumbing components in enterprise business stacks have moved toward open source software.

The home automation industry offers its own parable illustrating why you shouldn’t entrust your building data to a single vendor with closed APIs and data feeds. When Google Nest shut down, or ‘bricked,’ the Revolv home hub in April 2016 it rattled the tech industry at large and the emerging IoT industry particularly.  It’s notable that Google parent company Alphabet’s next step was to open source the Thread protocol that Nest uses for communications.

The takeaway lessons are, don't be lured into a walled garden by a shiny interface, a low initial cost, and promises that your data will be well taken care of by a cloud vendor. Ask questions to ensure your data will be open to your future uses. Weigh the pro’s and con’s of on-premise, in-the-cloud, and at-the-edge computing and storage, and negotiate a fair price for keeping as much of the resulting data as is practical and affordable. It may be the cache you need for machine-learning training in the future. The motivations of your in-house IT department and/or professional hosting services are more aligned with your own regarding how your building data is best stored and secured.

The IoT era promises a new beginning and faster innovation cycles, but not necessarily simplicity — at least not in this early transition time. The buildings industry should arm itself with the right people and resources to navigate the complexity and not fall prey again to vendor lock-in as it did in the early 1990s.