Open, What Does It Really Mean? To make it happen, Smart Building controls vendors, developers, and integrators could follow the example of the smartphone to create new and truly open systems.

Fred Gordy Intelligent Buildings, LLC

Articles

Interviews

Releases

New Products

Reviews

Editorial

Events

Sponsors

Site Search

Newsletters

Archives

Past Issues

Home

Editors

eDucation

Training

Links

Software

Subscribe

The building controls industry has been driving towards open protocols, standard naming conventions, and universal control to deliver Smart Building technology.  But how close are we really?

Before we dig into the topic of “open” for Smart Building technology, let’s take a moment to look at the more prevalent technology of the smartphone.  Why? Because there may be a thing or two we can learn from these little devices.

Smartphones came on the scene in late 2007 to mid-2008 and introduced us to the concept of apps. Back then apps and app development were a radical way of thinking. Suddenly you no longer needed software libraries with code dependencies, as with other software development life cycles; now you could download an emulator and spend a much shorter amount of time in the development cycle. Then you just had to submit to Apple or Android, and you had yourself an app available for download by millions of people.

Now let’s stop and think… Why is this successful?  Apple and Google created an environment that allowed anyone to build useful apps with common tool sets.  Of course one could argue that there are still two disparate platforms, but if you really look it, the consumer only has to decide between two platforms.  Each offers a wide variety of app options and the developer community can produce the same app for each platform with a short life cycle to go to market.

Another interesting aspect is how cheap apps are.  You can buy (or get for free) an app that allows you to create presentations, assess your data, control your TV, control your lights, and even control your AC. Most would agree the smartphone is an indispensable, necessary tool that not only helps you personally, but is mandatory for doing business today.

And all of this happened in less than a decade…

Some could, or would, argue this is fine for phones, but we have too many legacy systems in buildings that are dependent on the established infrastructure and would be too costly to change.  However, if this would have been Apple’s thought process, we’d all still be using flip phones and landlines.  Consider this; according to the Pew Research Center in 2014, 43% of adult households are cellphone only – with no landlines. This means that in less than a decade, almost half the homes in the US became fully dependent on their cellphones.  Another Pew Research Center publication in late 2015 said this… “Fully 92% of American adults own a cell phone, including the 67% who own a smartphone. As cellphones and smartphones become more widely adopted and play a larger role in people’s daily communications, their owners often treat them like body appendages.”

Okay, so how does this apply to Smart Buildings?

Pandora’s box has been opened so to speak, because the people in the consumer market are the same people who design and run buildings. These people are beginning to ask, “I can use a smartphone app to get data from my car and my home; I can use an app to control my TV, lights, garage, and door locks, and I even use an app to check local traffic or tell me when a thunderstorm is coming… Why can’t I do at least some this with my Smart Building?”  Well, it’s time that we as an industry rethink what “open” means.

A few years ago it was believed we needed to all adopt LON, and now the push is for BACnet.  But maybe it’s time to think radically and follow the model of Windows, Mac, or Linux operating systems.  Or, maybe more appropriately, the model of IOS and Android in building platform-centric control systems with “self-aware” devices that can be implemented into one or more platforms.  In other words, follow the example of a NEST thermostat; when you power it up, it “phones home” and lets the cloud-based platform know it’s online and ready to control its environment and produce data.  The user has full control and has only a small amount of setup with a minimal learning curve.

A VAV controller should not require a subset of programming and then another layer of programming on top of that to get it into the system.  An air handler controller should present the user/owner a series of questions they could easily answer to bring it online and discover which VAVs, PIUs, etc. it’s connected to.  PIUs could talk to each other (even if they’re not in the same building) and compare notes, so to speak. If they’re the same type and have the same conditions, one that is not performing optimally could “look” at several others like it and adjust its PID loop, or notify the building engineer that it has a problem.  This could create self-aware fault detection without the need of analytics that can only be setup by a data scientist.

I posed this scenario in an article I posted on AutomatedBuildings last year – the user tells SIRI before he or she goes to bed, “Set my alarm for 6 AM, I’m going to the office”.  This simple command could set in motion the following:

The phone’s alarm clock sets for 6 AM, all the house lights turn off, the garage door closes (if it was open), the doors lock, the security alarm system engages and the thermostat sets itself to the desired sleeping temperature. Then the alarm goes off at 6 AM the next morning, and the coffee pot turns on and the thermostat switches to the desired morning setting. The phone tells the user what time they need to leave the house based on current traffic and weather conditions.  Once ready, the user heads through the house to the garage, with the lights coming on in the house along the path to the garage. The security alarm disengages, the car starts, the garage door unlocks and the garage door opens.  The user pulls out of the garage and the garage door closes, the doors lock, the lights go out, and the temperature for the AC is reset to an unoccupied setting.  The user gets a status of OK that all systems are correctly set.

At this point an app like Waze lets the building know what time this user and all other users will arrive at the building.  The building can then anticipate the load based on the arrival time of all the occupants, and adjust accordingly. The count of the users and their arrival time will control the building’s smart systems and how they respond, and a schedule would only be needed if the occupants’ arrival information is unavailable.  For example, if most occupants will arrive at 8 AM and work mainly on three or four floors, the lights and HVAC can be set to compensate.  The parking lot will know how many reserved spots are needed, the access control system will know who to expect, and the power system will know the expected consumption of power.  Only the needed elevators would be engaged, and the other elevators could be on standby to minimize power usage.

And this entire process started with just a few words to SIRI.

I know it still sounds like science fiction, but the reality is this technology already exists for our homes.  The Smart Building side needs just a little push to make this scenario our reality; and to make it happen, Smart Building controls vendors, developers, and integrators could follow the example of the smartphone to create new and truly open systems.
_________

IntelligentBuildings, LLC is a Smart Real Estate professional services company, providing planning and implementation management of next generation strategy for new building projects, existing portfolio optimization and smart community development.