Home of Building Operating Management & Facility Maintenance Decisions
Insider Reports

FacilitiesNet eNewsletter
eNews Best Information Tool For Busy FMs
We will keep you updated with trends, education, strategies, insights & benchmarks to help drive your career & project success.
Sign up for eBook




« Back to Facilities Management Building Automation Category Home

Building Data: Bringing Together Diverse Devices




By Ken Sinclair

We understand that building data is our future, but the myriad of diverse devices all speak different dialects of an undocumented language. Cloud databases are becoming common ground but without preprocessing, data complexity exists. Is the solution an application program interface (API)? A set of functions and procedures allowing the creation of applications that access the features or data of an operating system, application, or other services?

Scott Cochrane, president, Cochrane Supply & Engineering and a contributing editor to AutomatedBuildings.com, shares his observations in this article: API = New Software & (Integrator) Capabilities x Infinity! 

“But… it’s just not that simple. As you can imagine, it brings new challenges for the integrators for normalizing data from these unique new IP systems so they can incorporate the new tech occupant experiences while still providing comfort, safety, and security for the buildings they serve. Frankly, BACnet IP just doesn’t cut it. Why? Because BACnet IP doesn’t have all of the information needed to properly integrate the application being served. BACnet is valuable for BAS data and will continue to be, but IP networks are super dynamic, always challenging, and never the same in two buildings. As a result, we will need more from IP controllers and devices to be able to deliver the next level occupant services and be in harmony with the networks we now live on. Enter the API. (Or Application Programming Interface.)  Devices that come with a documented rich APIs are the open solutions of the future.”

Cochrane follows with The Call Home Strategy: “As we continue to see cloud-based solutions deployed in buildings, we have stumbled upon what may be a future industry in itself.  How does the digital device/system share its data, commands, logic … from inside a building to an on/off-prem cloud?  We call this a product or system “call home strategy.” With more and more IP devices flooding the market, many are coming with remarkable cloud-based services that set the product capabilities on fire. There are way too many cloud advantages to hard line into an on-prem-only policy for all building control systems. Even the most secure systems in the most secure buildings need software updates to maintain their highest level of cybersecurity, which often requires a download from a cloud. In past years, we considered this remote access. But, with the advent of IP devices with attached cloud services (like a Wi-Fi stat for your house), this becomes much more complicated than just setting up a VPN into a remote network.

“So why do we need a call home strategy? It’s already here! We are already supporting all sorts of call home strategies for building control systems and new products, many of which are well tested and working great.  BAS is not the only industry engaged—life safety and security products are coming with these capabilities as well, which means it’s here to stay. The building owners are ready for this change in their industrial commercial properties, but they have complicated IT environments with way too many digital devices to control. As a result, the need for an adjustable, comprehensive, cyber secure, managed cloud connection is in demand and will forever change the landscape for controlling buildings.”

Benefits of Cloud Connected Buildings: "Adopters of cloud computing such as building owners or end users, however, may need to know what the cloud can do to improve building operation and occupant conditions." Insight is provided in this article by Zach Netsov product specialist, Contemporary Controls and a contributing editor for AutomatedBuildings.com: “The edge and the cloud complement each other. Building automation equipment can be connected to the cloud in several different ways. The most straightforward approach is to use edge controllers. Edge controllers communicate with the local operational network and supervisory stations using common protocols such as BACnet or Modbus. They are installed on the edge of the IP network (hence their name) behind a firewall to reduce network attack surface. Edge controllers usually have built-in I/O and a programmable or pre-programmed sequence of operation to control mechanical equipment at the site. By leveraging open IoT protocols such as MQTT, proven security mechanisms such as Transport Layer Security (TLS), and robust software as a service solutions (SaaS) such as Azure IoT Central, edge controllers can easily and securely connect to the cloud, effectively making any attached equipment a cloud connected asset.”

The Edge: The New Building Mindset by Marc Petock, chief marketing and communications officer, Lynxspring, Inc. and a contributing editor for AutomatedBuildings.com. “The edge is becoming an integral part of many organizations’ building operational strategies. Building owners and operators are looking for faster, real-time analysis of the massive volumes of data produced by equipment systems and devices to improve operational decision-making. It can now be said that the data produced from a device is more valuable than the cost of the device. We are connecting more devices and crunching more data more quickly than ever before. The edge is here, and it is here now.”

When we talk about connecting a variety of devices, the challenges of getting them all to communicate must be considered. Christopher Naismith of Audette.io and the SES Consulting research and development team told me: “There's a lot of discussion about having everything 'talking the same language' and while standardizing is important, diversity is part and parcel of innovation. Things spring up out of different places with different philosophies, some better than others but none necessarily the best. The way this is handled in the software-as-a-service space is that an application will have a documented API with a set of instructions that describe how to GET and POST data to that application. This allows developers to interface directly with the program in a predefined way.  Not being in computer science, I don't know of the drawbacks to this method, but it certainly makes development a lot faster and smoother. I don't have to use the same code or same software 'stack' as another application, but I can still access important bits of information from its database as needed. This also allows services like Zapier and IFTTT to act as the 'translation engine' between applications so as a consumer I don't have to petition developers of either application to develop anything.  I can connect my thermostat to my front door lock even though the apps don't have a native integration.”

I asked our contributing editor Brad White about open systems and he replied: “This definitely came up in our discussions on open systems last year as part of AHRExpo Atlanta. The group of us pretty much agreed that in the future, ‘open’ didn't necessarily mean fully open source or open protocols (though it could) but also extended to things like open APIs that allowed for interoperability. I'm sure like anything, APIs are not created equal, and standards are needed to ensure an appropriate level of interoperability, maybe this is where REST comes in, I'm not sure. I know that the APIs we already use on a daily basis have frustrating restrictions on what you can and cannot access via the API, and of course, that could change at any time. This is where true open-source proponents will say that because of this, you can't say that APIs are really open. Nevertheless, seems almost inevitable given that's how most web services already interact.”

Diverse Service Models Are the Key to Delivering the Benefits of Analytics by John Petze, C.E.M., partner, SkyFoundry. “Analytics is proven, and it can be very easy to get started. Start by asking, ‘what data do you already have available?’ – in other words, data that is available at low or no cost. Then take the next step to define a manageable project scope to apply analytics to that data to derive value from it. Data really is the new money if you know how to use it.”

IoT Meets Building Automation: Building IoT “is advancing building automation beyond mere optimizations. It's bringing systems together and adding new value, through innovations like demand control and the way it improves air quality. But we must remember that IoT-based analytics platforms work only because they connect people with technology—without humans at the helm, they’re of little value.”

Does the industry need a building data specification? Maybe similar to “mobility data specifications” (MDS). Can we use this, or do we need to modify it? MDS is “a platform initially developed by the Los Angeles Department of Transportation to help manage dockless micro-mobility programs (including shared dockless e-scooters).

“MDS is comprised of a set of application programming interfaces (APIs) that create standardized two-way communications for cities and private companies to share information about their operations, and that allow cities to collect data that can inform real-time traffic management and public policy decisions to enhance safety, equity, and quality of life. More than 50 cities across the United States — and dozens across the globe — already use MDS to manage micro-mobility services.”

The Open Mobility Foundation Principles

"Open-Source — Use open-source code and APIs to promote the formation

of an ecosystem of private companies and public agencies who come

together to build open-source code and APIs that can be used as the basis for

products that manage and use the public right-of-way.

"Competition — Encourage the creation of competitive markets for

commercial products and services based on the open-source projects

within the Open Mobility Foundation.

"Data and Privacy — Foster a community that enables public agencies to

generate data through the services they provide while also adhering to

world-class privacy and data security standards.

"• Compatibility — Create projects among all stakeholders that promote

interoperability across borders and avoid a patchwork of regulations.

"Sustainability — Promote business models that ensure sustainable

transportation networks for generations to come.

"Modularity — Create a flexible kit of parts and framework that public

agencies may designate to fit their needs."

We have the history of the hard work of Project Haystack and BACnet. Now we have the Brick Schema for building metadata. This post examines how Brick compares to other building metadata efforts like IFC, Project Haystack, and Linked Building Data.

Another initiative is the Building Energy Data Exchange Specification (BEDES).   BEDES (pronounced "beads") “is a dictionary of terms and definitions commonly used in tools and activities that help stakeholders make energy investment decisions, track building performance, and implement energy efficient policies and programs. An ecosystem of BEDES compliant applications will facilitate the exchange of information on building characteristics and energy use.”

More on BEDES: “The amount of building energy data available in digital form is increasing rapidly via programs such as city energy disclosure ordinances and audit mandates, the digitization of previously paper-based building transactions, as well as the Internet of Things (IoT). However, the use and utility of this data is not growing as rapidly. One of the core issues as a lack of standardization in terminology and vernacular for quantities as basic as floor area!

“The Building Energy Data Exchange Specification (BEDES, pronounced "beads" or /bi:ds/) is a dictionary of terms, definitions, and field formats that was created to help address this problem. BEDES is not a software tool, database or even a schema. It is a dictionary upon which interoperable schema, databases and software tools can be built.”

Please share your thoughts and any evolving standards you are aware of with me sinclair@automatedbuildings.com.

Would love to share your wisdom with our following at AHR Expo Orlando

Join our free 12 education sessions AHR Expo 2020.

We all are building data; let's make it as easy as we can.

Ken Sinclair is the founder, owner, and publisher of an online resource called AutomatedBuildings.com. He writes a monthly column for FacilitiesNet.com about what is new in the Internet of Things (IOT) for building automation.

 


Contact FacilitiesNet Editorial Staff »  


posted on 12/2/2019