Tweet

November 2019
Review
AutomatedBuildings.com

[an error occurred while processing this directive]
(Click Message to Learn More)


Building Data

We understand that building data is our future but the myriad of diverse devices all speak different dialects of an undocumented language.

Ken Sinclair
Founder, Owner, Publisher AutomatedBuildings.com

Articles
Interviews
Releases
New Products
Reviews
[an error occurred while processing this directive]
Editorial
Events
Sponsors
Site Search
Newsletters
[an error occurred while processing this directive]
Archives
Past Issues
Home
Editors
eDucation
[an error occurred while processing this directive]
Training
Links
Software
Subscribe
[an error occurred while processing this directive]


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 and CEO Cochrane Supply & Engineering Contributing Editor shares his observations in this article:

APIAPI = 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 the 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

And then 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.

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. our Contributing Editor

The Edge and the Cloud complement each other. Building automation equipment can be connected to the cloud in several different ways. The most straight-forward 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 - Marc Petock, Chief Marketing & Communications Officer, Lynxspring, Inc. Contributing Editor

Marc adds 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  http://www.audette.io/ and  http://sesconsulting.com/ 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. 

Our contributing editor Brad White    provides the following thoughts,

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 - John Petze, C.E.M., Partner, SkyFoundry

John writes 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
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) https://www.openmobilityfoundation.org/ 

Can we use this or do we need to modify it? https://www.openmobilityfoundation.org/ 

Based on a platform called “Mobility Data Specifications” (MDS) that 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 use 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 https://project-haystack.org/  https://www.bacnetinternational.org/  plus now

Exploring the Brick Schema for Building Metadata   How does Brick compare to other building metadata efforts like IFC, Project Haystack and Linked Building Data?
 

Are these movements of use?

https://bedes.lbl.gov/  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.

https://www.energy.gov/eere/buildings/building-energy-data-exchange-specification-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 AHRExpo Orlando

Join our free 12 Education Sessions AHRExpo 2020


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








footer


[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]

Events

Want Ads

Our Sponsors

Resources