The Path to Interoperable Systems and Building Controls Excellence

It’s 2020, and we are still not there. EMCS, BMS, BAS, whatever you want to call it is only a small fraction of what it could be. We have not achieved our full potential.

I am only a contractor. I started in this industry in 2010, and a lot has changed in the past decade. We have gone from enterprises that were largely single-vendor and single-dealer to controls contractors changing their product lines and services to more offer “open” controls. The term “System Integrator” became a much better way to advertise your company’s skillset. Anyone remember this great video from 2011 explaining what a system integrator does? Integrated multiple-manufacturer controlled facilities have gained much wider acceptance in these past years, but we are still missing some big pieces of the puzzle.

Integrators and building operators are still saddled with many hardware and software interoperability limitations that have continued to persist throughout the last decade. I believe that the lack of progress in certain key areas is holding the controls industry back, keeping us as a niche market, when, in reality, we should be the ones spearheading the IoT movement.

The installer and integrator, the people who actually deploy and commission all this great stuff we are talking about, are still struggling. We need products that are easier to use with improved workflows. We need products that are consistent and streamlined. We cannot get to all this fancy high-level stuff until some of the low-level interoperability issues have been resolved.

Below are six different categories that attempt to describe the layers of products and software that make up our business. The first two deal with hardware and the rest with software. The functionality of each layer depends on the integrity, consistency, and flexibility of the ones beneath it. Without a solid foundation to build on, all of these high-level products and services will be difficult to realize and manage, performing only marginally at best.

This category connects the physical world to the virtual one. These items are anything that you might tether to a controller. An Energy Valve, for instance, is a shining example of a modern advanced field device. It is both an actuator, sensor, and intelligent communicating energy-optimization device. The sensors and actuators category is one that is pretty much solid. Not much progress needs to occur here. There are tons of choices of great products that are available to all. The quality and affordability of these items are excellent and for the most part, they are completely interoperable and interchangeable between manufacturers. In many cases, these sensors and actuators are more technologically sophisticated than the controller they are attached to. For this reason, there is not much more that can be done to make this category much better. Perhaps one topic that could use some attention; The development or adoption of an industry-standard bus for local power and serial communications, similar to Belimo’s MP-Bus or Honeywell’s Sylk.

The field or edge controller is a category that, in my personal opinion, is particularly lacking. It’s really just because of one or two small things. Unlike devices that are only configurable, these are employed where equipment requires site-specific custom programming. This is where the configurable-only device may not be enough. Sometimes the configurable controller ends up being used in places where it shouldn’t be. An example of this might be a large air handler. Increasingly such units are being purchased with factory configurable-only controls. For some facilities, this is fine; for others this can create difficult integration scenarios. Factory control devices usually cannot have their sequences adjusted; only setpoints may be changed. But from the view of the Mechanical Contractor, fully programmable third party controls are more expensive, more of a hassle to install, and most importantly, they fail to differentiate themselves due to their proprietary nature. In many mechanical contractor’s views, “Controls are Controls.”

We have now hit a peak with unitary controller performance. These little boxes have more processing capability than will ever be needed for the foreseeable future. Increasing the performance of these devices now will only lead to excessive power consumption. In the future, low power usage will be favored over performance, especially when you have thousands of these deployed across a facility. Ten years ago, a 100 Watt incandescent lightbulb was commonplace. Now that same task is performed by an LED that uses only 12. We cannot have energy management devices that use more power than the equipment they are managing.

What we really need is a reusable controller platform. Basically, a low-power, 24-volt personal computer with I/O, which is what many of these newer devices actually are. The difference is that the owner should have access to the device’s low-level firmware. Replacement of the entire software stack down to the bootloader should be an option.

The reason for this is maintainability. Often these devices get removed and replaced long before they fail electrically or mechanically. Sometimes they are in pristine condition and are only being taken out of commission because they are software-incompatible with the new front end system. Or perhaps the original vendor no longer offers or supports the device. In many cases, the original vendor may no longer exist! Only a small group of people from that company may have the ability to support obsolete controllers. Manufacturers cannot support the firmware of legacy devices indefinitely, nor should they be expected to.

Facilities owners are well aware of these hardware limitations, and it’s becoming a huge problem for us. They are largely unmoved by the fact that these new boxes now come with IP, WiFi, pretty thermostats or some other wondrous feature. New and fancy features are becoming less and less compelling. We are now at the point that if the device is not interoperable, open, and maintainable, it’s just another proprietary plastic box.

An industry-standard DDC framework has yet to be accepted between even two vendors. A few years ago, this might have been difficult, but this is no longer the case. Control applications should be portable across devices and completely transparent to the automation front end. (At the very least this should be true for products from the same vendor) This is not always the situation. Since we are now integrators rather than dealers, our technicians now must support multiple coding environments. The experienced technician that can do it all is a valuable asset and is also a rare bird. Often there are only a handful of these individuals in an organization. Our industry cannot expect every new technician to learn all of the nuances of these various proprietary brands.

Solutions to this problem have been around for over a decade now but have been largely ignored. There are only a few instances where some keen startups have used open-source code to become extremely successful and turn themselves into well-recognized industry names. In some cases, these open frameworks have started to gain in popularity only to be reeled back in by their originators. Perhaps those organizations realized it’s “too open.” Many have also used open-source code quietly and in such a way that has rendered it virtually-proprietary. There are really no more technical hurdles standing in the way of open-source standardized DDC; all of the roadblocks are now completely artificial.

When you hit the discovery button on your favorite integration software tool, devices and points just start piling in. This was a great new capability for an integrator to have and greatly expedited the process of integrating a facility. We need to push the automatic site discovery concept even further. More information is needed than just point data to do this. We need standardized metadata and site-specific, self-documenting data structures to answer the following questions in an automated fashion:

We can always visit an unfamiliar facility and determine these arrangements manually. A machine cannot do this, however. For example, when we see the four phrases “VAV-21”, “Discharge,” “Air,” and “Temperature” we know what that means, and what those terms mean to each other. So far, that combination of words means nothing to any software program.

Luckily for us, there are already initiatives long underway, such as Haystack and Brick Schema to solve these problems. However, these will only become solutions through widespread implementation. It’s important that when these databases are being generated that they are done so in a self-documenting fashion. Any future enterprise software tool should generate this structural data automatically as the site is being created and the controllers programmed. This data could then be served directly from the edge devices themselves as has been demonstrated in Project Sandstar.

A lot of good choices here. Most enterprise solutions are proprietary, which is fine. Notice, however, that the most successful and prolific one, the one that we all know, also happens to be the one that is the most flexible, extensible, and interoperable. It would make the enterprise software developer’s job a lot easier if site data and metadata, as well as DDC, conformed to the various standards addressed in the topics mentioned previously. The idea with standardizing and streamlining these frameworks and data is to prepare it for easy and automated consumption by front ends and other software tools.

6) Analytics, Optimization, Energy Savings, Occupant Satisfaction and Engagement

[an error occurred while processing this directive]This is the destination that we are all trying to reach and where all the true value is. I’m really not sure what is in store for us at this level, but we will never be able to reach these heights by continuing to build on shaky foundations.

Not particularly at this moment, but from time to time in my short controls career, I’ve been in front of customers with existing controls who were asking for a replacement or alternative to their system. Almost 100% of the time they want software and hardware that is the most interoperable and open. The word “open” seems to be this carrot that we dangle in front of people, and “proprietary” is the smear we use against our competitors.

A lot of these facilities owners know what they want, they just don’t know what exactly to ask for. Many times we are not very helpful in delivering the correct answers to them. Some facilities owners do not care for the controls industry very much anymore. In their view, we are overcharging them for systems with built-in obsolescence. Is selling people what they don’t want a business model that will last another decade?

I’ve heard people say, “This is just how it is” and “The market has spoken.” The market has not spoken; the market has yet to exist. It would be like saying, “The market has spoken, people just want to buy stuff at a store.” before Amazon existed.

But I could be totally wrong…. If you disagree, and are completely satisfied with the state of our industry, please ask yourself these questions:

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

Events	Want Ads
Our Sponsors	Resources