Standard Communications Protocol for Building Automation and
Control Systems: BACnete
Michael R. DeNamur and Mick Schwedler The Trane Co.
Buildings have become more sophisticated, utilizing micro-processor based controllers on a wide range of
equipment. The need to integrate standalone equipment into a coherent automation and control system has
become apparent. And building owners have identified a separate need to share essential information
between independent building systems through a process called interoperability. While the industry has
attempted many different solutions to meeting these requirements, a standard protocol adopted by all users
and manufacturers holds the most promise for a successful future.
This paper examines the issues created by a proliferation of proprietary building automation system protocols,
and focuses on how building owners, working under the auspices of ASHRAE, and with the cooperation
of industry and government, developed a standard protocol called BACnet (Building Automation and
Control Network). BACnet is an object based protocol that is supported over a wide range of physical
communication media. A cross section of vendors have participated in the development of the standard
and are committed to providing products which make use of it. A testing consortium sponsored by the
United States National Institute of Standards and Technology has offered an avenue for proving out
the standard.
The result of this process is a powerful standard that is being used today to provide an integration and
interoperability solution on over 200 project sites. It provides a single development path for manufacturers
and offers building owners future expansion capabilities with any vendor who supports the standard. BACnet
was approved as ASHRAE Standard 135-95 in June of 1995. A complimentary ANSI (American National
Standards Institute) standard followed, and BACnet will also be considered as an ISO (International Standards
Organization) Standard.
INTRODUCTION
It is safe to say that there is a significant amount of confusion
regarding the issue of communications and open, standard
and proprietary protocols in our industry today. While we’re
all familiar with terms like setpoint, space temperature,
Direct Digital Control (DDC) and the like, most of us are
not literate in the language of baud rates, routers, networks
and protocol stacks.
Like it or not, these words (and many more) are quickly
becoming an important part of business for manufacturers.
However, they should not have to be the business of building
owners and facility managers.
While technology can give us the tools to create better building control systems, it can also create roadblocks which keep
us from achieving our potential. Today, the proliferation of
many vendor-proprietary communications protocols has at
once created very intelligent building controllers and locked
them out from working together; in a sense creating many
brains, but no central nervous system for the building. But
before we can propose a solution or examine its merit, it is
helpful to review the circumstances which brought us to
this point.
BACKGROUND
Advances in technology have changed the world over the
past two decades, and the building controls industry is no
exception. Pneumatic control was the standard offering for
building HVAC systems in the 1970’s, and we were never
faced with questions of integration and interoperability since
pneumatic controls were based on the same 20 PSI Main
Air regardless of their manufacturer. In essence 0-20 PSI
was the standard for pneumatic controllers. A damper actuator from one manufacturer and a valve controller from
another could be used side by side on the same air handling
unit since they both used the same main air to provide control
of their outputs.
Even when the industry moved to electronic controls we did
not suffer the problems we typically see today. Sensors and
actuators still worked with physical quantities of resistance
and voltage which could be easily measured, and did not
Standard Communications Protocol for Building Automation and Control Systems: BACnete - 10.21
change from one manufacturer to another. Standard ranges
like 0-10VDC and 4-20mA were generally accepted, and a
sensor from one manufacturer could easily be used as an
input to a controller from another manufacturer.
However, with the dawn of the micro-computer age in the
early 1980’s building control system manufacturers were
able to incorporate a much higher degree of intelligence in
their systems. With that intelligence came the need for a
method of communications to share information with various
elements of the system architecture. Seemingly random collections of 0’s and 1’s packaged in the right format allowed
microprocessor controllers to send and receive building system information. Given no standard language for digital
communication appropriate for the purpose, each manufacturer created their own proprietary protocol (language) optimized to most effectively support their products.
Projects which included early implementations of microprocessor based control systems did not experience difficulty
attempting to share information from one independent system with another, since there was little information available
in the first place.
Today, micro-electronic controls have worked their way
from sophisticated centralized controllers to simple unit controls and sensors. Now even a variable speed drive is nearly
certain to include a microprocessor controller, mounted by
the manufacturer and using a proprietary protocol. While
there is an abundance of information available at the local
keypad and display of this unit, it is essentially locked out
from the rest of the system because it uses a proprietary
communications protocol. One of the fundamental issues
driving owners to seek refuge in standard protocols is integration. Integration can be defined as the ability to group
intelligent, standalone unit controllers into a cohesive building management system.
A second driver is the issue of interoperability. Many owners
have found themselves ‘‘captive’’ to one supplier, since it
is not practical to expand a building or campus with another
controls system which cannot communicate with the existing
one. Interoperability is defined as the ability to link multiple
standalone building systems from a variety of manufacturers
(such as those for HVAC, fire & life safety, lighting or access
control) into a comprehensive unit. Another example of interoperability might be the ability to tie dissimilar control systems in multiple buildings on a campus into a single campuswide system. This allows a single user workstation to provide
day-to-day monitoring and control functions for all buildings
and systems regardless of who supplied them.
In the same way that integration allows owners to easily
incorporate equipment from a large pool of vendors, interoperability assures owners that they can competitively bid
10.22 - DeNamur and Schwedler
system controls with the understanding that a common protocol will provide a method for their system supplier(s) of
choice to peacefully co-exist.
In a nutshell, integration allows users to pull large quantities
of dissimilar equipment under the umbrella of a single building management system, while interoperability offers the
same solution for dissimilar building systems.
CUSTOM INTERFACES, OPEN
PROTOCOLS, GATEWAYS AND
MORE
The commercial building control industry has made several
attempts to address the issues of interoperability and integration. Custom interfaces linking unique control systems have
offered a partial answer for many years. However, the need
to license protocols and write confidentiality agreements
creates a burden sometimes exceeding the value of the limited performance these custom protocol interfaces can offer.
While these solutions did offer some degree of success, they
did not represent a long term strategy. Enhancements to
system controls at either end of the interface may render it
useless, and problems at startup are not easily remediated
when both controls vendors are convinced that their end of
the interface is not at fault.
In an effort to remove some of the mystery surrounding
custom interfaces, some suppliers have elected to publish
their system or controller protocols, making them available
to interested members of the public. Anyone is welcome to
write a custom protocol translator to communicate with their
equipment. Again, while this eliminates some of the licensing expense and confidentiality agreements, it does not
change the relative effectiveness of interfaces completed
between two proprietary protocols.
Today gateways and integrators are popular offerings. These
devices package multiple custom interfaces as standard product offerings, and allow a variety of standalone equipment
controllers to be linked to a larger building automation system. The development expense to create and maintain these
protocol translators is staggering, and while they do provide
a relatively stable platform for integrating equipment, they
do not begin to address the needs of customers requiring
interoperability between independent control systems.
Until recently, the efforts of the industry have been largely
self serving, as manufacturers are more prone to protect their
strategic market share than they are to implement changes
which meet owners objectives but level the competitive playing field in the process. And while the technology exists
to allow dissimilar building systems to communicate more
freely (witness the marine electronics industry standard pro-
tocol, and to a lesser extent the industrial control market)
few things have changed to allow practical exchanges of
data which hold the potential for long term, cost effective
solutions to both integration and interoperability.
ASHRAE SPC-135P
ASHRAE undertook a plan to overcome this problem in
1987 when it formed a committee to study the issue and
propose a standard protocol which could be used by all
manufacturers. Special Project Committee (SPC) 135P has
been at work ever since defining a specification for BACnet
(Building Automation and Control Networks). As ASHRAE
is an accredited standards-writing body for the American
National Standards Institute (ANSI), the process of creating
an industry standard protocol was open to all interested
parties, and representatives from all of the major controls
companies were soon part of the working committee (see
Table 1).
The goal of SPC-135P was to ‘‘define data communications
services and protocol for computer equipment used for monitoring and control of HVAC & R and other building systems.’’ Over the course of several years SPC-135P created
a specification for a protocol which could be used as an
industry standard. In 1991 the committee published its initial
draft of the specification and the mandatory public review
generated over 500 comments. Appropriate changes were
made, and in 1994 SPC-135P offered draft two and received
roughly 200 comments. A third draft was made available in
March of 1995 and was met with fewer than 10 comments.
Table 1. SPC-135P Representative Membership
American Auto-Matrix
Johnson Controls
Andover Controls
Landis & Gyr Powers
Barber-Colman
Company
Siebe Environmental
Systems
Energyline Corporation
Staefa
Honeywell
The Trane Company
Cornell University
National Institute of
Standards &
Technology (NIST)
Carrier
McQuay
Delta Controls
Various Owners and
Engineers
The specification for BACnet was adopted as ASHRAE
Standard 135-95 in June of this year.
DEFINITION OF BACNET
PROTOCOL
In deference to existing standards, SPC-135P chose to define
the BACnet protocol using the existing OSI (Open Systems
Interconnection) model established by the ISO (International
Standards Organization). The OSI model consists of seven
layers which define the various functions of any protocol
(see Table 2). Several layers of the OSI model go well
beyond the expected uses of BACnet, and in its final form
BACnet employs only four layers. However, limited functions of other layers have been appended to the four layers
used by BACnet.
BACnet protocol defines new application and network layers
specific to the objectives of commercial building automation
systems, and makes use of existing standards for data link
and physical layers whenever possible. The presentation,
session and transport layers have been eliminated in the
collapsed BACnet architecture.
A brief overview of the characteristics of the remaining
layers of the BACnet protocol may help to aid in understanding its scope and intended use in commercial building environments.
Application Layer
The application layer includes functions and services specific
to BACnet. BACnet identifies several building blocks called
Objects which represent physical quantities, or standard elements of control systems such as files, or schedules (see
Table 2. Open System Interconnection Model
Basic Reference Model
Application Layer
BACnet Model
Application Layer
Presentation Layer
—
Session Layer
—
Transport Layer
—
Network Layer
Network Layer
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
Standard Communications Protocol for Building Automation and Control Systems: BACnete - 10.23
Table 3-1). In addition, the application layer includes many
standard Services which can be invoked to manage or control
Objects identified in the system (see Table 3-2). Simply put,
the application layer of the BACnet standard defines an
alphabet, words and the grammatical rules of a new building
control language.
A BACnet Device is a collection of Objects which might
describe a building or unit controller. Each Object is a collection of Properties that describe the details of the object and/
or its setup parameters.
Table 3-1. Standard BACnet Application Objects
Analog Input
Binary Input
Schedule
Analog Output
Binary Output
Program
Analog Value
Binary Value
Notification
Class
Calendar
Command
Device
Event Enrollment
File
Group
Loop
Multi-state
Output
Multistate Input
For example, a BACnet device might represent an air handling unit (AHU) controller. This controller would include
a number of BACnet objects to describe the operating conditions of the AHU: analog input objects for discharge air
temperature, damper and valve position, binary input objects
for filter and fan status, analog output objects to control
valves and actuators, and binary output objects to start the
fan or control a 2 position valve. Each BACnet object has
an associated list of standard BACnet properties which specifically describe its characteristics (see Table 3-3).
BACnet application services represent the tools to communicate information between objects, and to link objects into
useable systems. In a typical building example the chiller
may use the BACnet service ‘‘read property’’ to poll the
position of the chilled water valve on a number of AHUs.
The BACnet chiller device can then use this information to
reset the ‘‘present value’’ property of an analog output object
representing leaving water temperature setpoint for the
chiller.
Network Layer
BACnet supports several types of networks and physical
media as outlined in the description of the data link and
physical layers below. The network layer describes how
information is passed between devices connected to a variety
of networks comprising a BACnet ‘‘inter-network’’. For
example, an inter-network might include both an Ethernet
Table 3-2. Standard BACnet Application Services
AcknowledgeAlarm
ConfirmedEventNotification
GetAlarmSummary
GetEnrollmentSummary
SubscribeCOV
UnconfirmedCOVNotification
AtomicReadFile
AtomicWriteFile
AddListElement
RemoveListElement
CreateObject
DeleteObject
ReadProperty
ReadPropertyConditional
ReadPropertyMultiple
WriteProperty
WritePropertyMultiple
DeviceCommunicationControl
ConfirmedPrivateTransfer
UnconfirmedPrivateTransfer
ReinitializeDevice
ConfirmedTextMessage
UnconfirmedTextMessage
TimeSynchronization
Who-Has
I-Have
Who-Is
I-Am
VT-Open
VT-Close
VT-Data
Authenticate
RequestKey
10.24 - DeNamur and Schwedler
Table 3-3. Properties of an Analog Input Object
Object
Identifier
Object
Name
Object
Type
Present
Value
Device
Type
Status
Flags
Description
Reliability
Out
Of
Update
Units
Min
Pres
Resolution
COV
Increment
Interval
Service
Value
Max
Pres
Time
Delay
Class
High
Limit
Low
Limit
Deadband
Limit
Enable
Acked
Notify
Type
Value
Event
Enable
Event
State
States
and ARCNET LAN connected by a router. Among other
things, the network layer of BACnet filters communication
so that only messages directed at nodes on the remote LAN
are propagated.
Data Link Layer
The data link and physical layers of the BACnet protocol
stack define the actual packaging and delivery of BACnet
protocol messages. Just as you can pack oranges in a box
and deliver them from the grove to a grocery store via a
plane, train or tractor trailer, it is possible to send BACnet
messages via a variety of carriers. It was the intention of
the BACnet committee to make use of existing standards
where they were available; at the same time they wanted to
insure that they identified options which met users needs
for high performance as well as low cost solutions.
ARCNET and Ethernet were chosen as high performance
LAN implementations for the data link of BACnet. ARCNET (ANSI Standard 878.1) is a token passing, deterministic
method of data communications running at 2.5 megabytes
per second (Mbps). ARCNET passes a token from node to
node, and any given node may only communicate when it
has the token. ARCNET is widely used in industrial control
systems, and was chosen as a cost effective LAN topology.
Ethernet (ISO Standard 8802-3) is a collision detection mode
of LAN communications and runs at 10 Mbps. Since there
is no token associated with this LAN, nodes are free to send
messages whenever there is no other activity on the link.
Messages sent by two nodes at the same time will collide;
the message will be lost and the nodes will wait for a speci-
fied period of time before attempting to re-send. Using ARCNET and Ethernet to send BACnet messages is roughly
analogous to shipping oranges via airfreight, where the
oranges are BACnet messages, the orange crate represents
the ARCNET or Ethernet data link, and the airplane is equivalent to the physical layer.
Nearly all commercial building automation systems make
use of EIA-485 (formerly RS-485) as a physical link, typically for multi-drop or daisy-chained unit controller communications. While manufacturers have created their own flavors of EIA-485, there are no standards defined for it at the
data link layer. Since it is a very popular and cost effective
method of communication, the BACnet committee defined
its own rules for using this physical link. Master/Slave Token
Passing (MS/TP) allows for both master and slave nodes on
a link. Only masters may get the token and initiate communications on the link, slave nodes may only respond to a
request for data. It is optimized for very cost effective, but
lower performance applications typical of unit controller
communications. MS/TP typically operates at 9600 baud.
Using MS/TP for BACnet is similar to sending a box of
oranges via railroad car.
Echelon Corporation has defined a protocol of their own
design for use in commercial building control systems. LonTalke is a protocol which is closely associated with communication hardware (Neuron chips) also marketed under the
Echelon name. While the BACnet committee elected not to
endorse Echelon’s definition of a standard protocol, they
did allow for BACnet messages to be sent via Echelon’s
application of the data link layer. This is analogous to filling
Standard Communications Protocol for Building Automation and Control Systems: BACnete - 10.25
an empty grapefruit box with oranges and shipping them
by rail.
MOVING FORWARD WITH THE
BACNET STANDARD
Point to Point (PTP or Dial Up) is a communications mode
optimized for hardwired connections between two devices
or dial up communications. It is a non-LAN based topology
consisting of a single node on either end. Communication
rates are similar to MS/TP, and relatively speaking PTP is
a much simpler topology to implement than the LAN options
described above. PTP is another communications mode
defined by the BACnet committee as a standard to be used
with the EIA-232 physical link. In relation to the options
described above, PTP is roughly equivalent to shipping the
same box of oranges via tractor trailer.
Given that SPC-135P has defined a standard protocol with
sufficient flexibility to be used in many applications and
with several options for physical and data link connections,
we should now turn our attention to how BACnet might be
used, and how it can alleviate the problems of integration
and interoperability identified by building owners.
Physical Layer
This layer of the OSI model consists of the actual physical
interconnection between nodes, and the method of signaling
upon it. For example, coaxial cable, twisted pair, and optical
fiber are three different media associated with both ARCNET
and Ethernet. However the signaling methods (voltages and
timing) used by each are different. Therefore the definition
of the physical layer for ARCNET and Ethernet via coax
are different. EIA-485, EIA-232 and specifics for passing
information to an Echelon LonTalk data link layer are each
also described by a unique physical layer profile. Table 4
describes several options within the basic BACnet OSI
model.
The BACnet specification defines standard objects and services which can be used to share building control information
between devices located at any level of a building automation
system architecture (Figure 1). MS/TP is appropriate for
linking unit controllers to building controllers while ARCNET and Ethernet are best used at the building controller
to user workstation level of the architecture. Point to Point
is a valid method of monitoring remote field panels from a
Figure 1. BACnet identifies data link and physical layer
options appropriate for all levels of a building automation
system architecture.
A variety of cabling connections are possible for the specific
physical and data link layers supported by BACnet. As mentioned above, coax, twisted pair and optical fiber are all
possible for ARCNET and Ethernet. EIA-485 uses twisted
shielded pair, and multi-conductor cable is appropriate for
EIA-232. LonTalk supports transceivers for several other
connections, including powerline carrier, radio frequency
and infrared.
Table 4. Example BACnet Protocol Stacks
APPLICATION
BACnet Applications Layer
NETWORK
DATA LINK
PHYSICAL
10.26 - DeNamur and Schwedler
BACnet Network Layer
ARCNET
Ethernet
LonTalk
MS/TP
PTP
EIA-485
EIA-232
central PC. Routers direct communications from one network to another within the greater BACnet inter-network.
specific to a particular manufacturer’s unit or equipment
controller which is part of the multi-vendor system.
While the BACnet specification outlines communication at
all levels of the system architecture, it is probably better
applied at certain points than others. Some in the industry
have looked for BACnet to provide a ‘‘plug and play’’
solution for connecting a random selection of equipment,
controllers and workstations into a cohesive building management system. Plug and play is a very popular concept,
however even BACnet may not be able to fully address the
high expectations that customers have come to associate
with their visions of interoperability.
BACnet offers its greatest benefits when it is used to share
high level information between independent building control
systems. When a system or subsystem can be identified and
optimized for primary control, then BACnet can serve as a
common link allowing independent primary control systems
to share information for supervisory control and monitoring
applications in other systems of the building or campus
(Figure 2).
It’s true that the BACnet specification allows for a VAV
box from one vendor to communicate with an air handling
unit controller from another. And a building controller and
user workstation from still other suppliers might complete
the system. However, in practice it is unlikely that this would
provide the best solution for any building owner. Consider
the issues of commissioning, and the lack of any one supplier
who is responsible for the performance of the entire system.
(However, it is possible that this niche may be filled by a
new breed of contractor focused on integration services.)
BACnet does not exist to propagate exotic recipes for building control systems; rather it offers a convenient means
to exchange data between complimentary building systems
where none was possible before.
BACnet can serve the integration needs of customers by
providing a standard method of interface to such ancillary
devices as fume hoods, variable speed drives and computer
room units. These devices are largely standalone controllers
with many status and few control points. BACnet provides
the means to pull them under the umbrella of a larger building
automation system where a custom interface or gateway was
the only previous solution. Offering BACnet as a standard
communications protocol on standalone unit controllers like
these removes the burden of creating and maintaining custom
integrator interfaces and allows manufacturers to concentrate
their limited resources on creating control applications which
better manage indoor air quality, energy, and comfort.
Owners should be encouraged to look for system solutions
to HVAC, lighting, fire & life safety, access control, elevator
control, etc. and then use BACnet to coordinate them into
a comprehensive facility-wide system. In a similar manner,
BACnet allows large projects to expand and campuses to
add new buildings with an independent controls system of
choice. While the primary control might be supplied by a
different vendor on each project, BACnet can coordinate
the independent pieces into a high level system capable of
sharing pertinent data between system elements, and report
back to a single user workstation for day-to-day operations
such as monitoring, supervisory control and data management.
Consider a building which reads a tenants security badge
when they arrive at the front lobby after normal working
hours. The user’s badge information can be shared with the
elevator control system which brings a car to the lobby and
allows the tenant access only to their floor of the building.
When they arrive at their office, lights and HVAC are turned
Figure 2. BACnet protocol links multiple standalone building systems into a cohesive facility-wide system for day-today operation including supervisory control, monitoring, and
data management.
It is unlikely that manufacturers will ever be able to completely cast off their proprietary protocols in favor of a 100%
BACnet architecture. The synergy of a complete automation
system from a single supplier offers many functions and
services which go well beyond what can be identified in the
BACnet specification, which by its nature is a representation
of the ‘‘least common denominator’’ of all things possible
in the industry. For example, while BACnet facilitates the
free flow of information for monitoring and basic control
of a multi-vendor system, it might not represent the optimum
means to setup and configure necessary operating parameters
Standard Communications Protocol for Building Automation and Control Systems: BACnete - 10.27
on and the building management system has logged their
after-hour usage to generate a monthly bill. All of this is
possible by making independent system data available to
other building systems in the form of BACnet objects.
Similarly, owners of large, expanding projects and multiple
buildings benefit. A project might have been originally
installed using building control systems from vendor A.
When the next building or expansion is let, vendor B has a
more attractive price, better product or stronger relationship
with the owner. BACnet allows the owner to add an independent system from vendor B while still maintaining a means
to provide interoperability between the two.
WHAT’S NEXT?
BACnet was adopted as ASHRAE Standard 135-95 in June
of 1995. It is already being used by several manufacturers
in standard product, and there are more than 200 projects
in the United States which have successfully used BACnet
to link control systems and/or equipment from multiple vendors. All major controls suppliers and many key HVAC
equipment manufacturers are developing support for the
BACnet specification in their products. Several additional
BACnet projects are currently under way in Asia, Australia,
Canada and Brazil.
The United States National Institute of Standards and Technology (NIST) has sponsored a BACnet lab for members of
a Testing Consortium with favorable results. Manufacturers
have used the lab to test their products with other BACnet
compatible devices for over a year. NIST and ASHRAE
cooperated to sponsor a booth at the 1996 ASHRAE Exhibition including a working demonstration of products from
eleven manufacturers who are using BACnet to address customer requirements for integration and interoperability.
ASHRAE is instituting a standing committee to maintain and
further develop standard 135-1995. This committee began its
work at the summer ASHRAE meetings in San Antonio in
June. The focus of this committee will be to specify a standard method of testing BACnet products for compliance to
the standard. The committe will also address how to create
specifications which allow for competitive bidding yet
ensure workable, truly interoperable installations.
As the industry learns to apply BACnet, it is important to
understand that simply specifying equipment or controls be
‘‘BACnet compatible’’ is not sufficient to ensure an interoperable solution. The BACnet specification includes roughly
500 pages outlining a variety of objects and services which
may or may not be applicable to all products depending on
their intended use. In addition, there are many valid options
for connecting BACnet devices, and it is possible for unique
10.28 - DeNamur and Schwedler
elements of a system to support exclusive data link or physical layers making the devices incompatible without a BACnet router.
BACnet requires every BACnet device to include a Protocol
Implementation Conformance Statement (PICS). Among
other things, the device PICS describes who manufactures
the product, what it is, which BACnet services and objects
it supports, and which physical connections are available.
Reviewing the PICS for BACnet objects included in a design
will confirm whether the objects, services and physical connections supported will allow them to communicate.
BACnet also identifies six conformance classes and 13 functional groups which represent support for specific groupings
of BACnet services and functions. These are intended to
provide a convenient method to describe common system
characteristics that are supported. For example, the Event
Initiation and Event Response functional groups describe a
BACnet device’ ability to generate and/or log and acknowledge alarms.
SUMMARY
The issues of integration, interoperability and standard protocols are very dynamic. It’s tempting to let the constant
barrage of information lead one to believe that even a standard protocol document won’t provide a solution to many
of the issues that we face today. But, however clouded the
concept may seem at the moment, BACnet is still the strongest hope for providing a common communications protocol
for the commercial building market.
It is not surprising that there are some difficulties to be
resolved when the undertaking is so great; changing the
direction of an industry this size is a formidable task. On
the other hand, these growing pains are necessary to give
us the tools we need to concentrate on creating systems
which offer better solutions to our customers.
Through ASHRAE, the industry has defined a standard protocol which can help manufacturers address the issues which
are important to building owners and engineers. Manufacturers are beginning to make the necessary changes to support
BACnet, but end users must continue to voice what it is
they want from this open standard. Most manufacturers will
welcome input now, as they are beginning to formulate how
they will use BACnet to provide integration and interoperability.
While many vendors have made strides to use BACnet as
a solution for integration, only a few have begun to answer
customers needs for interoperability as well. Patience and
persistence on the part of building owners and managers
will pay off in the long run in systems which facilitate
competitive bidding and offer easy integration of equipment
and controls into a single, comprehensive facility automation system.
Elyashiv, T., November 1994. ‘‘Beneath the Surface: BACnet Data Link and Physical Layer Options’’. ASHRAE Journal. Vol. 36, No. 11, pp.32-36.
REFERENCES
Bushby, S., August 1993. ‘‘Back to the Basics About BACnet’’. The Trane Company, PL-ES-BAS-000-S-28.
ASHRAE, 1993. ‘‘BACnet—Data Communication Protocol
for Building Automation and Control Networks’’. Advanced
working draft 2. Atlanta, Georgia: ASHRAE SPC-135P—
029.
Shinn, K., April 1994. ‘‘A Specifier’s Guide to BACnet’’.
ASHRAE Journal. Vol. 36, No. 4, pp. 54–58.
ASHRAE, 1993. ‘‘BACnet—Data Communication Protocol
for Building Automation and Control Networks’’. Advanced
working draft 3. Atlanta, Georgia: ASHRAE SPC-135P—
031.
Bushby, S. and Newman, M., January, 1994. ‘‘BACnet:
A Technical Update’’. ASHRAE Journal. Vol. 36, No. 1,
pp.S72-S86.
Summa, J., September 1995. ‘‘The Ultimate Intelligent
Building’’. Engineer’s Digest. pp. 53–55.
Standard Communications Protocol for Building Automation and Control Systems: BACnete - 10.29