Lighting & Building Automation Technologies

Those of us who attended this year’s Light and Building show in Frankfurt, may have noticed that there were nearly three full pavilions of building automation solutions on display. Many of them were new companies as well as some large, established companies not traditionally associated with the Lighting industry taking large amounts of booth space at the show. So clearly, the building automation industry is rapidly growing.

However, much like the LED market of 6 years ago, the controls market is now the “Wild, Wild West”. Multiple competing protocols exist (many of them proprietary), there is a lack of interoperability and standardization, and an over-proliferation of acronyms (DALI, KNX, BACnet, POE, etc.) assault the casual user. As is the case with any new market technology, various claims of capability and reliability are circulating, waiting to be proven in the marketplace. For the brave first-implementers, the savings can be considerable but so can the risks.

Introduction

Commercial building owners can save an average of 15% on energy usage by implementing a full-function Building Automation System (BAS). By full-function, we are referring to systems that monitor and control all major functions including heating, ventilation and air conditioning (HVAC), lighting, security, access control, metering, IT and communications. Tying all these systems together and allowing information transfer from one system to the other to inform automated control across all platforms is becoming the state-of-the-art. The benefits of this high level of control are enticing but the complicated maze of systems and protocols needed to do it is often too daunting for the building owner to understand.

At the top level you have the primary bus, sometimes referred to as the “backbone” bus. That bus usually requires a high-level, high-information density language to communicate between the human interface and the network of systems being controlled. Some examples of the more robust protocols would be BACnet, KNX or even a web-based IP protocol. Below that you have different systems being controlled by different, more product-specific protocols. You may have a lighting system controlled by KNX protocol, a metering system using M-bus and a security access/intrusion system using a proprietary security protocol from a specific manufacturer. Each of those systems consists of devices that hang on a secondary bus which is then routed to a controller module. The controller transmits and receives messages from the primary bus, and acts as a gateway/translation device that then transmits and receives commands and information to and from the attached devices in the secondary network.

Most levels and protocols are incapable of communicating with other levels or protocols without translation, which is why a primary or backbone bus is needed to carry translated messages back and forth to the user interface.

Naturally, these systems grew up when the industries worked independently and there was little impetus to interconnect, so the lower level languages are mostly industry-specific. Let’s take a quick look at that.

Figure 1: A typical BAS configuration for a medium size commercial building such as a small factory, school or office building. Note: There are several network communication levels, each with its own protocol or language

Building Automation System Protocols

The alphabet soup of BAS protocols consists of systems such as BACnet, LON, KNX, MODBUS, EnOcean, DALI, TCP/IP, DMX512, ABB Ego-n, Excomfort, Open-therm, M-Bus, SMI and many others (Figure 2). The best way to understand these protocols is to see how they are categorized.

Figure 2: Some logos of the most important BAS protocols. Each of these systems uses its own unique protocol

Proprietary or open
Systems are either proprietary or open depending on the choices of the manufacturer or controlling organization. Open systems are available for public use and sometimes modification but may require a licensing or royalty fee. BACnet, LON, KNX, EnOcean, DALI, TCP/IP and Opentherm are all open systems. Open systems are available for any manufacturer to implement, however they may require the payment of a royalty or usage fee. Proprietary or closed systems are usually restricted to the products of a single manufacturer, such as ABB Ego-n. The advantage of these proprietary systems is that they can be economically programmed to work efficiently and in many cases are most easily commissioned upon installation as all network devices are known to the system. The disadvantages are obvious – expansion of the system to include products beyond those of the system manufacturer may be difficult or impossible.

Complex or simple
Simple protocols, such as DALI and Opentherm are designed for and limited to a single application. DALI, for example, is a lighting control protocol and cannot be used for HVAC control or other applications. Opentherm was designed for heating and cooling applications only. SMI is limited to motor control (such as motorized window shades), and M-Bus is primarily a metering protocol. Complex protocols, such as BACnet, LON, KNX and TCP/IP are capable of higher level control and communication, and can be used for a wider range of applications. It will be discussed exactly what is meant by a higher level of control later in this article.

Topology
Networks can be connected into different types of connection topologies, but for simplicity we will consider them as being either centralized (as in a star network) and distributed (such as a mesh or ring network). In a centralized or star configuration, all network devices must connect to a centralized hub. The hub generally contains most or all of the intelligence and it controls the various devices connected to the sub-network. There is a cost advantage to centralizing most of the processing power, however this type of system is vulnerable to a failure of the hub unit that can result in the loss of operation of the entire sub-network. In a distributed system, each device has some intelligence and can connect and communicate with other devices in the system without a centralized hub connection. This configuration is far less vulnerable to centralized system failure, however it will likely be more expensive to build intelligence into all the peripheral devices. Some protocols such as DALI, can work in both central and distributed configurations.

Wireless protocols
Zigbee and Z-Wave are two protocols that were developed specifically for wireless applications. Z-Wave is a proprietary wireless RF-based communications technology designed for control and status reading applications in residential and light commercial environments. Target applications for Z-Wave are home entertainment, lighting and appliances control, HVAC systems and security. Similarly, ZigBee Home Automation offers a global standard for interoperable products, but is non-proprietary.

A full comparison of the two wireless solutions is beyond the scope of this article, however for various reasons, Z-Wave is more often used for commercial applications.

Figure 3: Star and mesh topologies are both very common in BAS

History

It all started in the boiler room. - The first building automation systems were HVAC controls. Specifically, building managers needed to have the building reach and hold temperature prior to the start of the work day, and turn off or adjust to a lower energy state at the appropriate time at the end of the day. A simple thermostat did not provide enough control to adequately regulate the operation of boilers and chillers – large, high-energy usage systems with slow state changes and lots of overshoot. Those systems needed to be fired up prior to the building occupancy period so they would have enough time to reach and maintain the appropriate ambient building temperature. Additional control intelligence beyond just on/off (such as feedback monitoring) was added to control temperature swings associated with thermostat operation.

Note that these systems did not need to convey large amounts of information, nor did they need to react quickly. The level of communication necessary to control HVAC loads could be kept somewhat simple and low cost. Very low baud rates could be used for busing information, and inexpensive chipsets could be used for processing simple commands. However, sending a series of multiple commands through this type of HVAC network might result in a system response time of several minutes. Not a problem for heating and cooling, but imagine if you sent a command through a controller to turn the lights on in an area and the lights came on 2 minutes later? Obviously lighting controls require a different solution.

New Requirements - Security Systems

When automated security systems came along, new levels of control were needed. Multiple camera systems, door and window sensors, remote-control door locks and other access controls, alarms and cameras were tied together and two-way communications were centralized in security stations that allowed full-premises control from a single area. In this case, the system communications needed to be much more sophisticated, and they needed a high level of protection against hacking or tampering. The objects being controlled by these systems were not all simple on/off state devices. The controller needed to know what kind of device was connected – was it a camera transmitting images, a sensor monitoring open/closed, an alarm that dialed out to a monitoring service? The system needed the capability to set command priority levels. If an access point is instructed to be closed, but a fire alarm goes off, the fire alarm response system must be able to override the access control to allow people to enter or exit an area – thus fire alarm commands were given a higher priority level than access control commands, etc. The processors needed to know whether a failure of the control system should result in a device being left in the “off” state or the “on” state. For example, a control failure should leave all hallway, stairway and exit lights on, but should turn off systems that could become dangerous if they are not controlled, such as boilers or escalators.

The Last Missing Brick - Lighting

Until relatively recently, the lighting industry was the least “connected” from a full-building automation point of view. When energy was cheap, lighting control at the facility level was economically unsupportable in all but the largest installations. Dimming had esthetic and economic advantages, but there were barriers. Different types of lighting in the installed space required different types of control – incandescent lights used phase control (triac) dimming while fluorescent systems generally used 1-10 V controls to dim ballasts. Additional wiring often needed to be run to facilitate dimming control and fluorescent dimming ballasts were far more expensive than standard ballasts. As energy prices began to rise and energy efficiency became more of a trend, things started to move but implementation tended to remain at the local or sub-system level. Occupancy sensors became popular, but usually were not networked at the facility level. Next came “daylight harvesting” in which ambient light levels are monitored with sensors, and interior lighting levels adjusted automatically in response to maintain a desired amount of light using the least amount of energy. These systems can be implemented at the local level also. However, facility managers are now interested in controlling the total amount of energy being delivered into lighting systems. Larger spaces such as parking lots and gymnasiums started being centrally connected and controlled through large dimming panels. Those panels were linked to the BAS via a high level protocol such as BACnet or KNX. Today, as dimming capability is being pushed out to the fixture level, large dimming panel type controllers are being replaced by small DIN-rail mounted controllers. Both light and heat can be further managed by giving the building control systems the ability to automatically raise and lower the window coverings.

Since many buildings are now moving to LED lighting as means of reducing their energy loads, it makes sense to add the controls while the new fixtures are being installed. Also, building codes are beginning to require occupancy, dimming and daylight harvesting controls for new installation.

Metering and Demand Response

Finally, knowing that you can’t really save what you don’t measure, one can now see the advent of intelligent sub-metering and demand response systems entering the market. Sub-metering allows the facilities manager to monitor and control energy usage at the sub-system level. Lighting circuits can be isolated from power outlet loads, and both can be metered and reported per floor, or even per room. Tenant energy billing can be automated and broken down to the individual tenant level. Machine loads can be monitored and sequenced to avoid utility penalty charges for exceeding maximum peak power levels. Power factor problems can be identified and corrected saving thousands in energy costs. Sophisticated software products are available that can present energy data in multiple visual formats – graphs and charts can be generated, measurements can be provided at intervals down to the second and alarms can be set as prescribed by the user.

Demand response systems are automation controls that can be tied directly to the energy utility supplying power to the facility. Demand response control is intended to give the utility the capability of lowering energy usage by a small percentage across a large number of buildings, thus avoiding the possibility of rolling blackouts or brownouts due to excessive energy demands at peak periods.

New Technologies

Hundreds of new applications are on the horizon. Video based occupancy/ vacancy sensors can now distinguish between human and non-human movement. Intelligent video systems can measure traffic patterns of people or vehicles. They can be used to assess the effectiveness of store displays or calculate usage rates for conference rooms, parking lots and other building spaces. Web services are being used to import HVAC and energy usage data into accounting systems for tenant billing purposes. Virtual thermostats can be used to give users control over their office environments. Overall building performance can be calculated and compared to similar buildings in an area and time frame to identify performance levels and possibilities for improvement. Other projects under consideration include using weather forecasts to optimize ice storage (chiller) systems. Universities are exploring the possibility of using their central classroom scheduling computer to automatically schedule HVAC, lighting and other classroom services. The possibilities are endless.

The Chance for a Single Unified Standard

So why not use a high level, complex, multi-topology protocol, such as web services, for all of the many control applications? In other words, why not just control all lower level devices through a single, high-level bus using one unified protocol? Web services have become the standard for business to business communications, it seems reasonable to assume they could replace BACnet, KNX, and/or all of the sub-languages and protocols that currently exist, creating a single tier network configuration that uses a common language throughout.

This may not happen right away for several reasons. First, no one has developed a set of web services that covers all the functions needed by a BAS. Message prioritizing, synchronization, system backup and restore, broadcasts and alarms and so many other functions would need to be integrated. This can be done, but it would likely just become another BAS protocol fighting for acceptance in the marketplace. Its suitability could be called into question because web services require much more processing power than most BAS controllers can provide, so existing systems would need to be upgraded. However, as processing power continues to become cheaper, and the incentive to connect back to utilities for smart grid applications and to outside entities for cross-comparison and data collection becomes stronger, TCP/IP or similar web based protocols may ultimately become the unifying factor. In the home, dimmers, sensors, surveillance cameras, thermostats, door locks and even lighting fixtures and appliances may all eventually become part of “the internet of things” with built-in intelligence and communication portals. In the meantime for commercial building applications, it is still most economical today to use lower level programming for the various sub-systems and connect them in an upwards configuration to BACnet and other complex protocol platforms for system integration.

This should all be familiar territory to the lighting expert. Just like in the LED markets with its non-standardized driver and dimming protocols, non-standardized component geometries, mounting and interconnection methods, the building automation industry is quickly being flooded with many new players all offering their own solutions. New technologies are being introduced every year, costs are dropping, and no one really knows what the ultimate standardization platforms will be. Just as it is for LED lighting, the dilemma that faces the building owner is how to weigh the cost of not implementing an automation system against the risks of implementing a system that could become obsolete overnight, or have problems when it comes time to upgrade, expand or interconnect.

Figure 4: Different interfaces are available to control BAS. Apps for lighting controls, HAVAC and many other tasks are available for smart phones and tablets using Android or iOS

Conclusion

The takeaway for lighting designers is that control is the order of the day. Successful fixtures and lighting systems of the future will be those that are most easily configured for control protocol versatility, and with a minimum of setup or difficulty in commissioning.