How open is open? The term “open system” in the building automation world can mean a lot of different things. The presumption is that an open system is available for any building automation integrator to work on and make changes or additions to without hassle from the original provider. This was the original intent and is definitely possible, but all too often, manufacturers and system integrators promote open system technologies for marketing purposes and then lock them in a closed manner to keep a competitive advantage (and hold the client hostage).
The word “open” is typically interpreted as meaning ‘not blocked’ or ‘not obstructed in any way.’ An open door is easy to walk through, an open receiver in football is not covered, an open bar means free drinks, an open building automation system (BAS) on the other hand could use open technology, but be as closed as that cheap uncle’s cash bar party.
Here is a brief history of how the party started:
Back in the day, control systems were truly open. The backbone of the system was basically pneumatic tubing with 0-20psi air. For the most part, the industry had standardized the methodology of control through air pressure to measure variables, control actuators, enable/disable systems, etc. You could easily have a Robertshaw pneumatic thermostat controlling a Landis VAV box in one room, vice-versa in an adjacent room, and a Barber-Colman pneumatic controller set up to control the AHU’s serving these boxes. All of these different manufacturers were on the same pneumatic control system backbone without any proprietary barriers or manufacturer locks. The systems were truly open, and the competition was fierce, which meant vendors had to build strong relationships and deliver as promised to retain their clients.
A limitation with these older pneumatic control systems was that just about everything ran blind of the bigger picture, and there were limited opportunities for the various systems to communicate requirements up the energy delivery chain. The central plant didn’t care what the AHUs needed, and the AHUs weren’t aware of what the zone demand was. Each system worked independently except for an occasional reset by outside air temperature if there were any resets at all. Ah, the good old days when control systems were open without inconveniences.
Then the transistor was invented, electronics became cheap, and manufacturers realized the benefits and efficiencies of electronic controls, computer monitoring, and optimizing systems by having them work together. During the initial stages of digital controls, there were no standards – just innovations and advancements by the independently operating manufacturers.
Manufacturers quickly realized that once they got a control system into a building, it would be very difficult for competitors to compete on future work at that location; primarily due to first costs and preestablished end-user investments.
The manufacturers’ strategy then became to “buy” the first project at or below cost to get in with a customer, and then mark up the price (plus some, and then often plus some more) on the building’s future work. Owners started to realize that the first project was just a “foot in the door” for the manufacturer and that future projects would usually cost magnitudes more, even if identical.
This scenario became very problematic for end users to budget and manage. Ongoing maintenance and repairs would be significantly overpriced, and response times and customer service could be horrendous without much repercussion since they were stuck with limited options. The systems that were installed to save energy while keeping the building’s occupants comfortable and productive became a “black box” for the building operators. Meaning the installed systems could be viewed in terms of its inputs and outputs without any knowledge of its internal working. The lack of knowledge surrounding the systems required clients to rely heavily on the few people from the manufacturer that had the software tools and knowledge to work on them. Once the manufacturers had a significant investment installed at a site, they could leverage that installation, and it became very difficult for the end users to do anything about it.
After years of this “abuse,” many end users began to revolt and pushed for standards and open system technologies with more options. Around the same time, the operational and environmental benefits of control systems began making their way into government code, and the open system pneumatics were soon being edged out of new construction.
Initially, most of the major manufacturers claimed open systems were a bad idea because anyone could come in and “mess things up.” Eventually, manufacturers began to move toward open systems due to the end user pressure, but not immediately and not without a fight. After significant market pressure, they jumped on the bandwagon by developing and marketing “open” systems, but they included subtle hooks or loopholes to remain in control of the system/customer. The ingrained culture and legacy of ‘black box’ systems twisted the actual implementation of many initial open systems. The market became riddled with misconceptions, confusion, and overused buzzwords. Open systems were not living up to the intention or hype and sometimes even became an inconvenience due to misunderstandings and misrepresentations.
Today, mostly due to market pressure and external forces, end users can get the best of both worlds if they know how to navigate the jargon. The key is to be wary of buzzwords, understand some of the manufacturers’ hooks, and notice the subtle word manipulations. For example, dig deeper with terms like “the system is capable of…” which can usually be interpreted as “it is possible to add this feature with a lot more money/effort;” or “based on open system technology” but could be implemented in a closed and proprietary manner. For example, a controller could be based on BACnet technology but not use the standard naming conventions, objects, and properties required to be a truly open BACnet system. Meaning, they are capable of working together but will need further interpretations. Is that still considered an open system with seamless communication?
A system can be “capable” of integration, but is that system still “open” if it requires a special software tool that can only be procured through and operated by the manufacturer? These “based on open systems” and “capable” installations can be very difficult for end users to reap the benefits they thought they had purchased. An open system with proprietary programming tools and a single source of product, knowledge, and training can be very inconvenient to integrate, support, or supplement outside of the manufacturers grasp. This can defeat the intention of open systems.
The key is to work with control system vendors that are not tightly tied to a specific solution provided by one manufacturer. Seek to work with vendors that exhibit transparency, collaboration, integrity, and maintain a client-centric culture. All control systems should be viewed as long-term investments, not short-term fixes. It can be useful to ask some specific questions to get clarity such as:
- What standards will the system use and what other products/vendors use that same standard?
- Will I have access to the same factory level training and certifications as your technicians?
- Are the engineering tools included for my use as part of this project and how does the licensing work?
- Will I have the same level of programming access as you?
- Can I add new controllers to the network, replace controllers, and modify programs without your assistance?
- Ask what the process would look like if you wanted to buy a controller and add it to the network by yourself to get a feel for any blockages or additional requirements, etc.
End users may not want to perform the above functions (and in most cases, shouldn’t), but the responses to these questions will give a better idea of how open the system and vendor will actually be. There is a steep learning curve to make these systems sing, and integrators do this daily. They continually improve based on the wide variety of projects and issues they constantly run into and have access to resources that would be very difficult for an end user to “dabble in” when they have time. The idea should not be for an end user to self-perform, but to know that you can, or you can bring someone else in just in case (which keeps the honest people honest).
Also, leveraging open systems to “pit” integrators against each other can have negative results. No one wants to be in a race to the bottom; it stifles innovation and strangles customer service. Instead, evaluate options based on lifecycle costs, value, and research technologies and potential partners more thoroughly than specific products.
Overall, the ability to innovate and select the best breed of products allowed by open systems has begun to prevail. Unfortunately, many in this industry still relish the “good old days” of keeping clients captive through proprietary systems or exploitation of open system loopholes, but end users are becoming more educated about the misconceptions, and the advantages of open systems are beginning to win out. A truly open system, implemented correctly by a reputable integrator, will provide end users with the best life-cycle cost without hidden inconveniences. The ultimate goal should be to form a partnership with the integrator to get the best long-term results. Investing in truly open systems mean you can trust (and verify if required) and feel confident with a long-term control system partner who can create a mutually beneficial relationship. Keep open systems open and convenient as they were meant to be – open for your convenience.
Show Comments (0)