Fire
To take on that daunting task, ASHRAE established a broad-based committee, SPC 135. Consisting of industry suppliers, consultants and end users, the Committee was charged with creating and defining the BACnet ( Building Automation and Control Network) technology.
As the process evolved, the Committee's extended the reach of its work even further: ultimately, it sought to develop a multifaceted communications technology that would facilitate interoperability at all levels in a building management system. And in June 1995 – after years of industry input, a number of functional compromises and multiple reviews – ASHRAE adopted BACnet as a new standard for the industry.
A true non-proprietary open communications standard, BACnet has turned out to be a major advance for the industry – and a welcome development for building owners. The 500-page protocol specification provides a detailed description of how a BACnet system is to function. It identifies all the rules for the sharing of data among system components – how that's to be done and the communications media that can be used. It also specifies how the information is to be interpreted. In short, BACnet sets practical ground rules for various systems – regardless of the manufacturer – to openly communicate with each other.
The End User Plea: Keep it Simple and Economical
When it comes to building systems, end users today want pretty much what they've always wanted: a simple and economical answer to their building automation control needs. They also want – more than ever – a safeguard to protect against getting "locked in" to a proprietary system from any manufacturer. That all too common practice usually leaves a building owner with multiple control systems – each from a different manufacturer and each with a separate headend. It also leaves the owner with two other difficult challenges: training – making sure staff know how to use the systems – and maintenance.
The age-old conflict described above – the owner's desire for simplicity and cost efficiency versus a manufacturer's desire to sell its system – is further compounded by the modern networking and economical environments of today. More and more, the owner's goal is to go beyond a single building – to expand into the realm of campus, regional, national and global systems.
Here's my assessment of what building owners are looking for under each of those scenarios:
Single building: the owner wants freedom in choosing the required control systems for the building. The owner also wants a simplified headend that provides a consistent view of the building and a consistent user interface – and that simplifies the training of personnel. From the end user perspective, it doesn't matter which systems the headend talks to. The owner simply wants "Best of Breed" capability – on everything in the building.
Campus and Regional: the owner wants consistent reporting and report generation capabilities. The collection of data for the reporting should be invisible to the end user. the owner wants consistent reporting and report generation capabilities. The collection of data for the reporting should be invisible to the end user.
Global: With the increasingly widespread use – primarily by large corporations – of single site operations, the need for global (world) data transfers becomes more critical. In single site applications, the owner wants information about what is happening and why – how it gets delivered is of little interest.
Building Systems "Cooperation"
In each of the applications described above, the owner has very specific needs and desires. And as I see it, BACnet is a key to fulfilling those needs – because it promotes the kind of building systems cooperation that's necessary to give owners the freedom and the functionality they want. Notice that I use the term cooperation rather than integration. That's because integration means so many different things to so many different people. And what's more, I don't think integration is the desired outcome. I see cooperation being the real goal. To support that contention, we can look to Webster's Dictionary.
It defines "integrate" as follows: to form, coordinate, or blend into a functioning or unified whole.
"Cooperate," on the other hand, is defined as follows: to act or work with another or others, to work together.
To better understand the concept, you can think of cooperation in terms of your own networked computer at work. The computers on the network are not integrated per se, they simply use a common protocol to allow them to cooperate. That same analogy can be extended to building control systems. In a building, the HVAC system does not handle fire operations. And the lighting control system does not get involved in HVAC. So it seems to me that cooperation is the most accurate and appropriate term to describe how those systems relate to one another.
Data and Control: The Major Elements of Cooperation
In my view of building systems, there are two major components of cooperation: data and control. In my view of building systems, there are two major components of cooperation: data and control.
Let's examine data first. "Data" is the ability to gain knowledge about the state or value of something in the system. And data is unquestionably a critical element of effective building system cooperation. Why? Because ultimately, data can be processed into information. And that information can then be used in a variety of ways: in real time as well as in more strategic applications. Data can be used to determine better ways to engineer a system – and to come up with better ways to use various system components. Data can also be used to generate integrated reports to help correlate various activities occurring in a building.
Naturally, many of those activities relate to life safety. The fire system is one of the major control systems in a building. And it's a unique system – because of its life safety responsibilities and the numerous supervision tasks it must perform to guarantee proper operation in the event of a problem. For those reasons, the system must be constantly tested and checked – beyond the normal supervision tasks it automatically runs.
Let's now address "data" from a fire system perspective. A critical component of any fire system interface is the capability to isolate the connection. That isolation, achieved through a data only interface, is needed to make sure other systems – because of the special fire-related codes and requirements referenced above – do not interact with the fire system.
At Simplex, we've developed a new self-contained panel that brings the BACnet data communications protocol to our fire products – while protecting the integrity of the fire alarm system. The BACpacO portal we're introducing will provide "read only" capabilities. That means building control and security personnel will be able to view fire system data – but prevented from taking any action related to the fire alarm system.
Think of a data only interface as being similar to an intelligent DACT interface. On one side of the interface is the fire system and its control programs. On the other side of the interface are the other control systems. The interface is "engineered" to allow point (object) information to be passed to the outside systems. What is done with that information has little impact on the fire system. The fire system can also accept data from an outside system – and that data may allow, just as an example, for enhanced notification operations.
The interface can also be used to collect and process, at a headend, data that allows the "user" to determine what's happening – and then to react. This would allow a user to collect data from a number of sources and correlate it in real time. The headend system can do most of the work for the user – and provide one consistent view of the situation.
From a technical standpoint, there are many specific contributions that data only interfaces can make in relation to the management and operation of building systems. Here are just a few examples:
Sensor Reuse
In today's applications, sensors are placed at multiple locations in a building. Each sensor collects information for the control system to which it's connected. But think of how useful it would be to engineer a building in such a way that each sensor sends data to multiple control systems. For example, lighting sensors could be used by fire systems to determine occupancy – and that information could in turn be relayed to life safety personnel.
With the engineering flexibility and capability that comes from data only interfaces, many other sensor reuse applications are possible. The important thing to remember is that fire systems must meet rigid sensor monitoring requirements. Therefore, sensors sending information to the fire system will have to be associated with ancillary type functions. However, the fire system will be able to send information to any other system.
With data interfaces, a user will be able to coordinate and report on all of the control systems in a building or on a campus – from one location. This information can then be collected – and better control algorithms can be generated overall for that individual property.
As the world goes global and companies look for more effective ways to manage their environments, the ability to share data and information with a large number of sites becomes increasingly critical. Global access allows for the introduction of whole new concepts in how control systems are used and in how information is passed and accessed.
BACnet: A Common Language Brings Multiple Benefits
In order to gain all the benefits of data only interfaces, a common "language" is needed. And that's where BACnet comes in. It standardizes communications involving building automation equipment, so that even products from different manufacturers can work together easily. What's inside each system – and how specific operations are performed – is not critical. The key is that the systems can share data and distribute control as envisioned by the owner and by appropriate authorities – rather than by the manufacturer.
Here are just some of the benefits that result from BACnet:
- It puts the power of design in the hands of the owner, not the manufacturer. BACnet encourages good system design and allows owners to decide how much systems share or how much control is distributed. Owners can design systems that make their application the most effective.
- An end user can use a variety of manufacturers for the various control systems. The owner can choose the "best of breed" in all building control systems ¡V and not feel locked in to buying from one manufacturer.
- It allows access to information as designed by the owner -- and in accord with how the organization works.
- Develop a single headend to the system. This means that an operator can use one interface, and not worry about how to interface with the other systems.
- Maximize use of staff and reduce training costs.
- Use existing networking infrastructure to transport data.
- Correlate data from different systems.
- Gain access from multiple locations on a network.
- Maintain well defined responsibilities for control.
- Have systems engineered to allow for the interaction of various systems into one virtual system.
When the issue of control enters the equation, it will take a more rigorous effort to implement the system correctly and get the desired results. When the issue of control enters the equation, it will take a more rigorous effort to implement the system correctly and get the desired results.
Allowing control between systems is tantamount to creating one large virtual system. This means that other control systems may have to inherit some of the fire requirements – such as supervision and recovery. But control can be divided into levels – and the level of control can be engineered. The key is to be careful about the level of control that is passed – and about the level of interaction that is required.
As an example, let's look at the control of fans and dampers. When a fire event occurs, the dampers and fans must be controlled in order to clear smoke or to pressurize the building. With cooperating systems there are a few ways in which to engineer this capability. In fact, with BACnet it can be engineered in much the same manner in which control is handled today with relays.
Always remember: it's critically important to fully understand what each system is responsible for – and what new requirements the system is taking on in order to meet those control requirements. Clear lines of responsibility need to be drawn – and engineered into the system. The good news is that with a protocol like BACnet, that job will becomes much clearer. Because it's a standard being implemented by most suppliers, common control templates will be able to be generated in the future. And building owners will be able to reuse those control schemes.
There's another important point that needs to be made about control. You'll need to be absolutely sure the fire alarm panel being controlled has historical logging capabilities – so that there's a fail-safe means of recording alarm events. Historical logging will provide a clear record of the sequence of fire alarm operations – and that will prove invaluable if a question ever arises about the location or silencing of an event.
Important Questions for Splitting Control
When control is split, there are a number of critical questions that need to be answered:
- Who is liable?
- Who has direct control over the equipment?
- Who is in charge?
- Whose controller will issue the orders and when?
- How will feedback be accomplished?
- Is the system rated for the specific control action?
- Can the fire system record the location from which a command originated?
- What is system performance on life safety actions?
Control can be broken down into various categories.
Basic Control Operations: From a fire perspective, basic control is the ability to ACK, Silence and Reset the system. With these basic operations, the commands to take the actions would not necessarily come from the front panel. Rather, they would come from the building network, probably initiated at the single headend. From a fire perspective, basic control is the ability to ACK, Silence and Reset the system. With these basic operations, the commands to take the actions would not necessarily come from the front panel. Rather, they would come from the building network, probably initiated at the single headend.
Point Disabling: This is one of those basic control functions that can have major impact on the operation of the fire system. It's a control function which may require special processing in the headend to accommodate fire requirements – or special processing in the fire system in order to have this action initiated by an outside system.
Division of Responsibility: This refers to actions such as control of specific system components (dampers, AHU, fans) by other than the control owner of the system component. Achieving division of responsibility will take good engineering and a well thought out Concept of Building Operations (CBO). The CBO will be critical to making control between systems work properly – and to allowing fire systems to be an integral part of building systems cooperation. This refers to actions such as control of specific system components (dampers, AHU, fans) by other than the control owner of the system component. Achieving division of responsibility will take good engineering and a well thought out Concept of Building Operations (CBO). The CBO will be critical to making control between systems work properly – and to allowing fire systems to be an integral part of building systems cooperation.
The major benefit of allowing control between systems is the ability to create flexible designs to meet the owner's specific needs. Along with that comes the ability to implement enhanced control algorithms, which could become generic and thus used by multiple systems to operate a building in a superior manner.
BACnet and Cooperative Systems = Better Engineering and Control
BACnet continues to gain acceptance in the building systems industry. And from my perspective, that's welcome news – for manufacturers and, more importantly, for end users. I truly believe that BACnet offers owners a more effective and cost efficient means of operating and controlling building functions. Here's why.
Right now, an owner mainly gets control of a building through diverse systems that control entities and do not communicate. From a building perspective, the owner basically just gets control – and nothing more. There's very little information made available to aid in operating the building. With BACnet and cooperative systems, that all will change. Owners will start to get access to real time information that will result in better building engineering and better control. They'll also get new capabilities for information distribution and information correlation.
And the benefits will build on themselves as time progresses. The advances made possible by BACnet will start to provide good building-oriented strategic information. That in turn will lead to better real time information collection and better definition of how to do building control. The owner will then be able to take advantage of well derived algorithms to run a building. Those algorithms will be able to be tailored in real time to allow for optimum control of a building. Ultimately, BACnet and cooperative systems will provide two things that everyone values – knowledge and savings.
