Building automation + integration = efficiency
- Compare various protocols that govern the building automation system (BAS).
- Demonstrate how to integrate all systems into a “smart building” for the most effective integrated design of automation and control systems.
- Apply a BAS to improve energy efficiency within a building.
With the influx of the Smart Grid and smart mobile applications, the building automation system (BAS) landscape has developed much faster than mechanical, electrical, plumbing (MEP), and fire protection products over the past decade. It is the driving force for optimized operations, improved reliability, and energy savings through the integration of building systems critical to the functionality of a facility.
Through the years, occupancy, comfort, safety, reliability, and efficiency have been key factors in the development of the technologies. However, as the global conscience has changed with regard to the impact of humans on the environment, and global demand for and access to energy has risen, a new driving imperative has been placed on facility professionals, engineers, and building occupants. To put it another way, humanity’s goal is to reduce our energy consumption in a manner that significantly decreases the negative impacts the consumption has on our environment, and thereby on all of nature.
According to the Center for Climate and Energy Solutions, commercial and residential building space represents 39% of total energy consumption in the United States—more than any other sector—of which 70% is associated with HVAC systems, depending on location and environment (see Figure 1). Up to 30% is plug load and lighting. It stands to reason that integration and operation of these buildings to reduce energy consumption is a top priority. This can only be done through integration of the system with the use of technologies such as energy management and BAS, and by doing it in a manner that ensures the efficient operation of a facility. Combine this with the integration of a variety of devices via the Internet (the Internet of Things, or IoT) and software available as a monthly or annual service that does not require it be loaded on a local PC or server (the “cloud”). Engineers and designers have the ability to create more efficient buildings that use current technologies to decrease consumption. This can all be done while giving access to analytical tools designed to help pinpoint outlying operation and energy issues before they become a problem.
The evolution of BAS
In the 1970s and ‘80s—due to increased energy prices—the demand for a more cost-effective building sent the BAS industry into a whirl of development to make buildings smarter. Taglines like “smart building solutions” started dotting the competitive landscape as building-automation companies were able to leverage cheapening computer technologies and bring them into the building space. This was a golden age for the BAS industry. During this peak demand to reduce consumption, BAS manufacturers globally created new and relevant technologies related to controlling a building. Competition increased and the direct digital-control solution became the standard expectation in buildings everywhere. However, most systems were disparate and only designed to control specific operations of a building, with other key components not being visible or integrated through the controlling mechanisms.
Over the next decade, the building automation landscape moved forward with larger leaps as technologies evolved at an almost exponential rate. During this time, energy prices inevitably fell and the larger cost-driven model for energy reduction began to wane as the economy strengthened. The pressure was off and, therefore, the pain soon forgotten. However, the building automation industry was still hard at work developing solutions relevant to the building market and energy reduction. The end user was beginning to ask for disparate systems that link together to allow for competitive selection of products as well as service providers.
Open protocols became an increasingly common topic of discussion as users realized the power of integration. During this time, our world was just beginning to understand the impact our energy consumption was having on the planet. However, we were still developing the solutions to dramatically reduce our environmental impact: open protocols for fully integrated systems. This was the beginning of the BACnet Project Standards Committee in 1987 (introduced as an ANSI/ASHRAE standard in 1995), and the introduction of LonTalk (now collectively referred to as LonWorks) protocol in 1990 by Echelon Corp. (It was submitted and accepted as an ANSI standard in 1999).
Today, the majority of buildings are designed with direct digital BAS. Through the evolution of protocols and technologies, the BAS has become a key component to ensuring the effective function of an entire building. In a perfect world, this would mean all buildings could take advantage of a “plug-and-play” system. However, it is not as easy due to market forces of constructing low-cost buildings and passing energy cost to leasing tenants in commercial buildings. Factors such as first cost, disparate manufacturers, legacy control systems, Internet security, and age of the building all come into play when considering the integration.
In addition, the ever-expanding cloud and the IoT has opened a whole new world of interconnectivity, allowing smart mobile devices and applications to be applied to these complex systems. Web browsers, software as a service (Internet-based software platforms, also known as SaaS), and mobile applications can be used to create a dynamic system where data-storage capacities are virtually limitless and access and control are just a touch away. With all this, the opportunity for efficiency is greater than ever. However, it is only through successful integration that this efficiency is achieved.
Integration and protocols
A successful integration of building systems relies first on understanding the circumstances of the MasterFormat Division 25 specification. Obviously, a retrofit scenario versus a new-construction model changes the dynamics of the integration. In new construction, devices can be specified to integrate natively with other solutions through protocols like BACnet, LonWorks, and Modbus, or by specifying an all-encompassing proprietary solution from a single vendor.
However, in building-retrofit projects, engineers may be dealing with legacy systems that are not changed out while newer systems are brought in to be “bolted” together with those legacy systems. In this case, it is important to begin the process of identifying where things can be integrated and where they may not. The good news in these situations is that many manufacturers are now starting to make native or gateway devices that allow disparate systems to be brought together. In many cases, this can either be accomplished with the manufacturers’ current product offerings or with third-party devices that manage the connection of the legacy protocol. A popular solution is to tie the legacy or proprietary protocol into a device that converts the protocol to BACnet or LonTalk. This allows other systems using these common protocols access to the system data and control points for modulation, switching, etc. While integration of these protocols is not always simple, a little understanding by systems integrators can go a long way.
BACnet: This protocol has gained significant momentum in the past decade to become arguably the most specified and most used open protocol in the market today. This is largely due to the fact that manufacturers collectively create the outcome of the protocol for integration through working groups, while the protocol is validated through the BACnet Testing Laboratories (BTL), an independent testing group that tests products to the specific functionality according to the current ANSI/ASHRAE standard. Each product that is tested must meet the guidelines for its type of functionality. For example, a BACnet building controller has a different testing standard than an advanced operator workstation. If the product has the BTL logo, this means it has been tested to the standard at some point in its product lifecycle.
According to www.bacnet.org, BACnet currently has 825 vendor IDs (registered manufacturers of BACnet products). So far, 661 active products from 112 distinct manufacturers carry the BTL mark. This includes products for HVAC, lighting, fire and life safety, energy metering, and a wealth of others, such as security and access control.
BACnet most popularly comes in two flavors: master slave/token pass (MS/TP) and Internet protocol (IP). Both data communication layers have their merits. MS/TP is commonly used for lower-level controller devices designed for the control of equipment, and uses a twisted, shielded pair for wiring with EIA-485 as the physical layer. This comes in handy during retrofit situations where buildings may already have existing wiring in place for control systems. However, caution must be taken as baud rates do vary depending on the revision of the standard the controller was designed to meet. This baud rate can be verified by checking the protocol implementation conformance (PIC) statement for a device.
With the BACnet IP data communication layer, CAT5e or greater (Ethernet) wiring or wireless protocol is used to transfer data over the IP layer between devices and to centralized interface mechanisms. This is a faster means of communication—and a more convenient way if existing IP infrastructure is already in place. BACnet IP networks typically reside separate from the standard information technology (IT) backbone as broadcast messaging can slow general communications. In most cases, a BACnet network will consist of both BACnet MS/TP and IP devices mainly through the use of routers (devices that can move data of one network type to another), bridges (devices that move data of the same network type), and repeaters (devices that retransmit data signals at a higher level to accommodate for signal degradation) to bring disparate BACnet networks together to tie into the centralized server for data display, monitoring, and control. This does not mean that a building must have access to the outside world to take advantage of IP or MS/TP. These layers can sit internally on an intranet structure (a local restricted communications network using Internet technology).
When specifying BACnet products for integration it is important to understand that there are multiple variations and revisions of the BACnet protocol. Therefore, all BACnet is not created equal and may not be able to communicate if certain qualifications or standards are not met. This is why BACnet tests to various device types and to only specific types of communication layers. For example, BACnet over MS/TP is a tested standard but BACnet over ARCnet is not.
LonWorks: This protocol was developed by Echelon Corp. and is largely considered to be the competitor to BACnet. Its foundation is based on the LonTalk protocol and the use of embedded Neuron chips in devices created by competitive manufacturers. This single-source model has, at times, created the question of whether LonWorks is a truly “open” protocol. However, the use of this methodology does create a stricter standard of interoperability, as it is controlled more tightly due to the nature of its development. This is because the protocol is placed in a stack that each controller is required to have, and not developed independently by individual competitors.
LonWorks gives the ability for both twisted, shielded pair communication bus and IP-enabled (Ethernet) technologies through varying methods. Intended to reside on an intranet or Internet environment, its protocol can be accessed on a multitude of devices manufactured by various companies. However, unlike BACnet, it is not expanding into certain markets needed for pure interoperability between systems. Echelon, along with a number of control manufacturers, offer devices that can bring LonTalk onto a network that is using other protocols and can be converted to BACnet. This means products competitively more suited for an application using the LonWorks protocol can be used in a building system to create pure interoperability and efficiency.
Modbus: This open protocol is commonly used in some packaged control applications and sensor topologies. It consists of both a remote terminal unit (RTU, an EIA-485, twisted shielded pair network) and TCP/IP (Ethernet, CAT 5E, etc.) communication options and also is designed to exist in an intranet or Internet environment. Typical Modbus applications are more popular in the industrial market and include energy measurement, motor drives, and automation routines. Integration of this protocol is not necessarily an issue with most devices and can be pulled in through the majority of manufactured systems today or through gateways, which are devices designed to transfer one communication protocol to another, i.e., LonWorks to BACnet.
Proprietary protocols: A wealth of these protocols exist in buildings today. While the industry is abuzz with open protocols, these protocols should not be left out of consideration for a fully functional building. Costs to integrate to existing systems can be high with third-party devices, and there is always the issue of disparity between integrators knowing the products they represent and possibly not knowing the other systems with which they are integrating. While integrators might know their devices inside and out, the lower-level systems may require additional, competitive service teams be available.
A careful eye should be placed in the market for manufacturers who support their legacy systems through backward compatibility to their newest and most market-relevant solutions. Many of these companies offer ways to bring a legacy product into the modern world through interoperability to their protocols. In addition, many of these manufacturers are producing cost-effective ways to bring in open devices one piece at a time to give users a more efficient building while maintaining lower installation and integration costs. With these systems, facilities get the more modern tools they need while still maintaining a BAS that is familiar to the current staff, thereby limiting larger learning curves and enabling expansion or replacement of localized systems at a pace suited to their needs.
Although there are good legacy integration solutions in the market today, this is not to say all of them are created equal. Limited support due to lack of installer familiarity or intentional obsolescence of former products can create scenarios where end-users may need to upgrade quicker than a normal budget cycle will allow, or be stuck with a system that is no longer supported. It is important companies and their products, services, and market history are researched to ensure optimal integration as well as longevity.
The Internet of Things
We are all becoming more connected to products, services, devices as the Internet continues to integrate into almost every aspect of our lives. A more connected and accessible building can make for a more efficient building.
A wealth of newly developed applications are progressing in the building space. Certain companies are leveraging this by taking integration protocols like BACnet, Modbus, and LonWorks and tying them into larger, Internet-enabled services that allow for more streamlined access and analytical tools for a building. These services work on simplifying the interaction of the BAS, so the end user can control the building space without having to understand the complexities of the BAS. This is accomplished through integration with IT services already available to these facilities.
For example, certain BAS can now tie into prominent calendaring tools like Microsoft Outlook, Google Calendar, and Apple iCal. This means zones can be scheduled automatically to turn on and off based on a user’s schedule set right from their desktop, tablet, or phone just by booking the space. It reduces the chance of forgotten temperature overrides, or missed chances to change a setting because of a scheduling conflict (e.g., if the meeting is canceled in the executive conference room through the calendar interface, the BAS uses the local calendar and knows not to turn on the lights or cool or heat the zone. No one needs to directly interface with the BAS scheduling software, or local thermostat). Other examples include smart-device applications that allow for local control of temperature, and native interfaces that allow users to troubleshoot their system, acknowledge alarms, and view trends all from a mobile device.
In addition to BAS systems taking advantage of our Internet-enabled world, many services are emerging that leverage the cloud to promote energy savings and relay important energy, carbon, and financial data to facility professionals, green teams, consumers, and financial managers. These services offer tools that can track energy usage and automatically convert it to carbon footprint data. They can create historical energy analyses and use degree days or other conditions to normalize information and get accurate representations of performance. These tools also can create targets based on driving factors related to energy consumption and create predictive models that create alarms when something is performing out of range. With these features, and a wealth of others, energy and comfort conditions can be effectively monitored and managed and therefore optimized. With the almost limitless storage capacity of the cloud, this data can be stored securely and redundantly. The stored data can be used over a building’s lifecycle to effectively track and analyze energy performance, maintenance performance, and savings measures—all for a fraction of the cost associated with embedded systems.
As the history of BAS has advanced to tackle problems of high energy costs, interoperability, and integration, a larger imperative has arisen that can leverage this progression and our now interconnected world.
Using the cloud
With smartphones and the Internet, BAS and other software/IT companies are launching smart-building management platforms and marketing SaaS. SaaS is any software application that you run that is not located on the premise being managed. It is a full-blown application, not a component part of something else. It is not a way to build applications. It is not a plug-in to other applications. Instead of having the application running on servers and data storage on building servers, it is running in the vendor’s data center.
The way SaaS applications are licensed is different from on-premise applications. Instead of buying the license to use the application, and then paying for software maintenance to support it and keep it current, you “rent” the software over a period of time—usually monthly or yearly. Instead of buying and installing infrastructure and then paying ongoing operating and maintenance costs, the vendor runs the application on their infrastructure. The cost of the SaaS application covers the costs of the software itself and the ongoing operations and infrastructure costs.
When you run an SaaS application, you generally log into your vendor’s website and you are on. You can say that SaaS applications are running “in the cloud,” and you would be correct. But SaaS applications are not the cloud.
Cloud computing provides computing resources that are not tied to any specific user location, but rather hosted, monitored, backed up, and serviced from servers in various locations globally. Cloud computing basically consists of:
- Virtual computers/servers
- Data storage capacity
- Communications and messaging capacity
- Network capacity
- Development environments.
Cloud computing is for software developers, application vendors, savvy computer users, and corporate IT departments, not for people who use computer applications (see Figure 3).
Anil Ahuja is president of CCJM, a multidisciplinary engineering firm providing smart city and smart building designs, including urban development strategies, major water and wastewater system engineering, and bridge and highway design and rehabilitation. He is a member of the Consulting-Specifying Engineer editorial advisory board. Rocky Moore is regional sales manager-Midwest with American Auto-Matrix. He has more than 11 yr of commercial and industrial HVAC experience, and has been a contributing member of the BACnet International marketing committee for 8 yr.