Building Data

And then Scott follows with The Call Home Strategy - yes, Another Building Data Story:

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, everything???? 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. 

In this article Benefits of Cloud-Connected Buildings by Zach Netsov Product Specialist, Contemporary Controls (and contributing editor, AutomatedBuildings.com) Zach discusses some aspects of cloud computing end users need to know:

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 the 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.
 
In this article, The Edge, The New Buildings Mindset, Marc Petock, Chief Marketing & Communications Officer, Lynxspring, discusses how 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 now 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.

Christopher Naismith of  Audette and SES Consulting's research and development team provides these thoughts:

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. 

Contributing editor Brad White provides the following insight:

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. 

John Petze, C.E.M., Partner, SkyFoundry discusses in this article how Diverse Service Models are the Key to Delivering the Benefits of Analytics.

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.

This article, IoT Meets Building Automation, by Michael Davies writing on the IoT for All web site (www.iotforall.com) gives us an important reminder:

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)  championed by the Open Mobility Foundation.  

Can we use this “straight out of the box” or do we need to modify it? From the foundation’s web site:

MDS was initially developed by the Los Angeles Department of Transportation (LADOT) 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 sustainably
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 the Project Haystack Organization and BACnet International, plus now the Brick Schema (which you can read about in this interview, Exploring the Brick Schema for Building Metadata   between myself, Gabe Fierro, a Ph.D. candidate in the Computer Science department at the University of California, Berkeley and Jason Koh is a Ph.D. candidate in Computer Science and Engineering at the University of California, San Diego). How does Brick compare to other building metadata efforts like IFC, Project Haystack and Linked Building Data?

Are these movements of use?

The Building Energy Data Exchange Specification (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.

As outlined here the Department of Energy web site:

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 [email protected] — or if you’d like to meet up in person, I’ll be attending CoRE Tech in November. From their web site:

The 10th anniversary of CoRE Tech will be held in Silicon Valley at the San Jose Convention Center on November 13 – 15, 2019. This unique event attracts the most proactive, visionary and innovative Corporate Real Estate and Facilities executives and thought leaders under one roof. They gather to learn about the latest groundbreaking automation, explore more efficient ways to manage, maintain and operate their space, and to discuss technology strategies that will help their organizations achieve their real estate goals. CoRE Tech features Industry Speakers from around the globe, an innovative, comprehensive Education Program, Executive Briefings and Project Tours in Silicon Valley, and a Smart Building and Campus Best Practice Case Study Showcase featuring leading Tech Solutions.

And of course, we would love to share your wisdom with our following at AHRExpo Orlando:

Join our free 12 Education Sessions AHRExpo 2020

We all are Building Data—let’s make it as easy as we can.