NISTIR 6392 GSA Guide to Specifying Interoperable … · NISTIR 6392 GSA Guide to Specifying Interoperable Building Automation and Control Systems Using ANSI/ASHRAE Standard 135-1995,

NISTIR 6392

GSA Guide to Specifying InteroperableBuilding Automation and Control SystemsUsing ANSI/ASHRAE Standard 135-1995,

BACnet

Steven T. BushbyBuilding and Fire Research LaboratoryGaithersburg, MD

H. Michael NewmanCornell UniversityIthaca, NY

Martin A. ApplebaumESS Engineering, Inc.Tempe, AZ

United States Department of CommerceTechnology AdministrationNational Institute of Standards and TechnologyGaithersburg, MD 20899

NISTIR 6392

GSA Guide to Specifying InteroperableBuilding Automation and Control SystemsUsing ANSI/ASHRAE Standard 135-1995,

BACnet

Steven T. Bushby November, 1999Building and Fire Research LaboratoryGaithersburg, MD

H. Michael NewmanCornell UniversityIthaca, NY

Martin A. ApplebaumESS Engineering, Inc.Tempe, AZ

U.S. Department of Commerce Prepared for:William M. Daley, Secretary U.S. General Services AdministrationTechnology Administration David J. Barram, AdministratorCheryl L. Shavers, Under Secretary for TechnologyNational Institute of Standards and TechnologyRaymond G. Kammer, Director

Abstract

This guide is intended for use by General Services Administration staff or design consultants whenpreparing specifications for interoperable building control systems using BACnet technology. Itexplains the issues that need to be considered when specifying the communication details and makessome recommendations for the choices involved. It is not a sample specification and it does notaddress all issues important for a good control system specification. The focus is on specific issuesrelated to the interconnection and interoperation of building automation systems and devices usingBACnet. It is intended to complement more general guidelines for direct digital control systems forbuilding automation applications.

Key words: BACnet, building automation and control, direct digital control, energy managementsystems, communication protocol, ANSI/ASHRAE Standard 135

Acknowledgments

The authors wish to acknowledge the significant contributions to this guide made by the members ofASHRAE SSPC 135, the "BACnet Committee." Many of the ideas presented had their genesis indiscussions with committee members about ways to make it easier to specify BACnet systems.

Table of Contents1 PURPOSE OF THIS GUIDE.............................................................................................................................1

2 SPECIFYING INTEROPERABLE BACNET SYSTEMS................................................................................1

3 INTEROPERABILITY AREAS........................................................................................................................2

3.1 DATA SHARING ...................................................................................................................................................33.1.1 Data Sharing - Specification Issues and Recommendations.........................................................................3

3.2 ALARM AND EVENT MANAGEMENT......................................................................................................................53.2.1 Alarm and Event Management - Specification Issues and Recommendations...............................................5

3.3 SCHEDULING .......................................................................................................................................................63.3.1 Scheduling - Specification Issues and Recommendations ............................................................................7

3.4 TRENDING ...........................................................................................................................................................73.4.1 Trending - Specification Issues and Recommendations ...............................................................................7

3.5 DEVICE AND NETWORK MANAGEMENT ................................................................................................................93.5.1 Device and Network Management - Specification Issues and Recommendations .........................................9

4 USE OF BACNET OBJECTS..........................................................................................................................10

4.1 NAMING CONVENTIONS .....................................................................................................................................114.2 COMMISSIONING / DIAGNOSTIC MODE................................................................................................................124.3 USING OBJECT DESCRIPTIONS ............................................................................................................................124.4 ISSUES RELATED TO SPECIFIC BACNET OBJECT TYPES .......................................................................................13

4.4.1 Analog Input, Output, and Value..............................................................................................................134.4.2 Binary Input ............................................................................................................................................134.4.3 Binary Output..........................................................................................................................................134.4.4 Binary Value ...........................................................................................................................................144.4.5 Calendar .................................................................................................................................................144.4.6 Loop........................................................................................................................................................154.4.7 Multi-state Input, Output, and Value ........................................................................................................154.4.8 Schedule..................................................................................................................................................15

4.5 DYNAMIC OBJECT CREATION .............................................................................................................................16

5 USE OF BACNET SERVICES........................................................................................................................16

5.1 INTEROPERABLE COMMANDS .............................................................................................................................165.2 ALARM CONSIDERATIONS ..................................................................................................................................17

5.2.1 Assigning Alarm Priorities.......................................................................................................................175.2.2 Setting up Notification Classes.................................................................................................................175.2.3 Event Notification Message Texts.............................................................................................................18

5.3 ASSIGNING LEVELS OF AUTHORITY TO CERTAIN OPERATORS ..............................................................................185.4 CHANGE OF VALUE PROCESSING ........................................................................................................................19

5.4.1 Subscribed COV Notifications..................................................................................................................195.4.2 Unsubscribed COV Notifications .............................................................................................................19

5.5 TIME SYNCHRONIZATION ...................................................................................................................................19

6 SPECIFYING SYSTEM/NETWORK ARCHITECTURES...........................................................................20

6.1 SYSTEM ARCHITECTURES...................................................................................................................................206.2 LOCAL AREA NETWORK SELECTION...................................................................................................................21

6.2.1 ISO 8802-3, Ethernet ...............................................................................................................................226.2.2 ANSI/ATA 878.1, ARCNET ......................................................................................................................236.2.3 Master-Slave/Token-Passing, MS/TP .......................................................................................................246.2.4 EIA-709.1, LonTalk .................................................................................................................................256.2.5 Point-to-Point, PTP .................................................................................................................................26

6.3 SPECIFYING MAC ADDRESSES IN A CONSISTENT MANNER..................................................................................26

6.3.1 Ethernet MAC Addresses .........................................................................................................................276.3.2 ARCNET MAC addresses.........................................................................................................................276.3.3 MS/TP MAC addresses ............................................................................................................................286.3.4 LonTalk MAC addresses ..........................................................................................................................28

6.4 NETWORK NUMBERING CONVENTIONS ...............................................................................................................296.5 DEVICE OBJECT IDENTIFIER CONVENTIONS ........................................................................................................306.6 USE OF BACNET WITH THE INTERNET PROTOCOLS..............................................................................................31

6.6.1 Annex H Tunneling Routers .....................................................................................................................316.6.2 Addendum 135a, BACnet/IP.....................................................................................................................32

6.7 ROUTERS - INTERCONNECTING MULTIPLE BACNET NETWORKS .........................................................................346.8 MESSAGE SEGMENTATION .................................................................................................................................346.9 GATEWAYS - CONNECTING TO LEGACY SYSTEMS ...............................................................................................35

7 PRACTICAL CONSIDERATIONS IN THE CONSTRUCTION OF BACNET SYSTEMS.........................37

7.1 PROCUREMENT PHASE .......................................................................................................................................377.2 CONSTRUCTION PHASE ......................................................................................................................................38

7.2.1 Protocol Implementation Conformance Statements (PICS) .......................................................................387.2.2 Points Lists..............................................................................................................................................397.2.3 Coordination ...........................................................................................................................................39

7.3 COMMISSIONING PHASE .....................................................................................................................................407.4 OPERATION AND MAINTENANCE PHASE..............................................................................................................40

7.4.1 Record Documentation ............................................................................................................................407.4.2 Operator Training ...................................................................................................................................41

ANNEX A. BACNET INTEROPERABILITY BUILDING BLOCKS (BIBBS) .......................................................42

A.1 DATA SHARING .................................................................................................................................................42A.1.1 Data Sharing-ReadProperty-A (DS-RP-A) ...............................................................................................42A.1.2 BIBB Data Sharing-ReadProperty-B (DS-RP-B) .....................................................................................42A.1.3 BIBB Data Sharing-ReadPropertyMultiple-A (DS-RPM-A) .....................................................................42A.1.4 BIBB Data Sharing-ReadPropertyMultiple-B (DS-RPM-B) .....................................................................42A.1.5 BIBB Data Sharing-ReadPropertyConditional-A (DS-RPC-A).................................................................43A.1.6 BIBB Data Sharing-ReadPropertyConditional-B (DS-RPC-B).................................................................43A.1.7 BIBB Data Sharing-WriteProperty-A (DS-WP-A) ....................................................................................43A.1.8 BIBB Data Sharing-WriteProperty-B (DS-WP-B) ....................................................................................43A.1.9 BIBB Data Sharing-WritePropertyMultiple-A (DS-WPM-A) ....................................................................43A.1.10 BIBB Data Sharing-WritePropertyMultiple-B (DS-WPM-B) ...................................................................44A.1.11 BIBB Data Sharing-COV-A (DS-COV-A) ...............................................................................................44A.1.12 BIBB Data Sharing-COV-B (DS-COV-B) ...............................................................................................44A.1.13 BIBB Data Sharing-COV-Unsubscribed-A (DS-COVU-A) ......................................................................44A.1.14 BIBB Data Sharing-COV-Unsubscribed-B (DS-COVU-B) ......................................................................44

A.2 ALARM AND EVENT MANAGEMENT BIBBS ........................................................................................................45A.2.1 BIBB Alarm and Event Notification-A (AE-N-A)......................................................................................45A.2.2 BIBB Alarm and Event Notification-B (AE-N-B)......................................................................................45A.2.3 BIBB Alarm and Event ACK-A (AE-ACK-A)............................................................................................45A.2.4 BIBB Alarm and Event ACK-B (AE-ACK-B)............................................................................................45A.2.5 BIBB Alarm and Event Summary-A (AE-ASUM-A) ..................................................................................46A.2.6 BIBB Alarm and Event Summary-B (AE-ASUM-B) ..................................................................................46A.2.7 BIBB Event Summary-A (AE-ESUM-A) ...................................................................................................46A.2.8 BIBB Event Summary-B (AE-ESUM-B) ...................................................................................................46

A.3 SCHEDULING BIBBS ..........................................................................................................................................46A.3.1 BIBB Scheduling-A (SCHED-A)..............................................................................................................46A.3.2 BIBB Scheduling-B (SCHED-B)..............................................................................................................47

A.4 TRENDING BIBBS..............................................................................................................................................47A.4.1 BIBB Vewing and Modifying Trends-A (T-VMT-A) ..................................................................................47A.4.2 BIBB Vewing and Modifying Trends-B (T-VMT-B) ..................................................................................47

A.4.3 BIBB Automated Trend Retrieval-A (T-ATR-A).........................................................................................48A.4.4 BIBB Automated Trend Retrieval-B (T-ATR-B).........................................................................................48

A.5 DEVICE MANAGEMENT BIBBS...........................................................................................................................48A.5.1 BIBB Device Management - Dynamic Device Binding-A (DM-DDB-A) ....................................................48A.5.2 BIBB Device Management - Dynamic Device Binding-B (DM-DDB-B) ....................................................49A.5.3 BIBB Device Management - Dynamic Object Binding-A (DM-DOB-A).....................................................49A.5.4 BIBB Device Management - Dynamic Object Binding-B (DM-DOB-B).....................................................49A.5.5 BIBB Device Management - DeviceCommunicationControl-A (DM-DCC-A) ............................................49A.5.6 BIBB Device Management - DeviceCommunicationControl-B (DM-DCC-B) ............................................49A.5.7 BIBB Device Management - PrivateTransfer-A (DM-PT-A)......................................................................50A.5.8 BIBB Device Management - PrivateTransfer-B (DM-PT-B)......................................................................50A.5.9 BIBB Device Management - Text Message-A (DM-TM-A) ........................................................................50A.5.10 BIBB Device Management - Text Message-B (DM-TM-B) .......................................................................50A.5.11 BIBB Device Management - TimeSynchronization-A (DM-TS-A) .............................................................50A.5.12 BIBB Device Management - TimeSynchronization-B (DM-TS-B) .............................................................51A.5.13 BIBB Device Management - UTCTimeSynchronization-A (DM-UTC-A) ..................................................51A.5.14 BIBB Device Management - UTCTimeSynchronization-B (DM-UTC-B) ..................................................51A.5.15 BIBB Device Management - ReinitializeDevice-A (DM-RD-A).................................................................51A.5.16 BIBB Device Management - ReinitializeDevice-B (DM-RD-B).................................................................52A.5.17 BIBB Device Management - Backup and Restore-A (DM-BR-A) ..............................................................52A.5.18 BIBB Device Management - Backup and Restore-B (DM-BR-B) ..............................................................52A.5.19 BIBB Device Management - List Manipulation-A (DM-LM-A).................................................................52A.5.20 BIBB Device Management - List Manipulation-B (DM-LM-B).................................................................53A.5.21 BIBB Device Management - Object Creation and Deletion -A (DM-OCD-A) ...........................................53A.5.22 BIBB Device Management - Object Creation and Deletion -B (DM-OCD-B) ...........................................53

A.6 NETWORK MANAGEMENT BIBBS.......................................................................................................................53A.6.1 BIBB Network Management - Connection Establishment -A (NM-CE-A)...................................................53A.6.2 BIBB Network Management - Connection Establishment -B (NM-CE-B)...................................................54A.6.3 BIBB Network Management - Router Configuration -A (NM-CE-A)..........................................................54

A.7 VIRTUAL TERMINAL BIBBS ...............................................................................................................................54A.7.1 BIBB Virtual Terminal -A (VT-A) .............................................................................................................54A.7.2 BIBB Virtual Terminal -A (VT-B) .............................................................................................................55

ANNEX B. DESCRIPTIONS AND PROFILES OF STANDARDIZED BACNET DEVICES...............................56

B.1 BACENT OPERATOR WORKSTATION (B-OWS)...................................................................................................56B.1 BACNET BUILDING CONTROLLER (B-BC) ..........................................................................................................57B.3 BACNET ADVANCED APPLICATION CONTROLLER (B-AAC) ...............................................................................58B.4 BACNET APPLICATION SPECIFIC CONTROLLER (B-ASC) ....................................................................................58B.5 BACNET SMART ACTUATOR (B-SA) ..................................................................................................................59B.6 BACNET SMART SENSOR (B-SS)........................................................................................................................59B.7 BACNET GATEWAY (B-GW) .............................................................................................................................60B.8 PROFILES OF THE STANDARD BACNET DEVICES .................................................................................................61

ANNEX C. GSA BACNET IMPLEMENTATION CHECKLIST ...........................................................................62

1

1 Purpose of this Guide

This document has been produced for the General Services Administration (GSA) to foster abroad-based understanding and consistent application of ASHRAE/ANSI Standard 135-1995(BACnet™) for automation systems in Federal buildings – in both new and retrofit construction.As such, GSA personnel and GSA’s selected design consultants should utilize this document as aguide in planning, designing, procuring and managing projects involving Building AutomationSystem (BAS) installations, upgrades, or expansions.

As used in this guide, a BAS is a network of microprocessor-based devices that are configured toperform energy management and monitoring, heating, ventilating and air-conditioning (HVAC)control, fire protection, security, and/or related building automation functions. It is the GSA’sgoal to competitively procure BAS solutions that cost-effectively meet the design objectives ofeach project while incorporating a common BAS communication protocol to the greatest extentpracticable. This then provides a foundation for non-proprietary future enhancements andexpansion at each building – as well as regional/national intercommunications and informationsharing across the GSA building stock. As such, all BAS projects – to some reasonable minimumdegree – must comply with the BACnet standard.

It must be stressed that this guide is focused on the BACnet protocol itself, considerations for itsinclusion in a BAS design, and some practical recommendations to follow in the various steps ofa project that includes BAS technology. This guide is not intended to provide the details of howto specify automation systems for a particular building, HVAC applications, or other project-specific functions. Details concerning sensors, actuators, wiring, piping, sequences of operation,and general design practice are outside the scope of this document. This guide focuses on thespecific issues related to the interconnection and interoperation of BAS installations and system-level devices using BACnet.

For information on general BAS design issues, the reader is referred to ASHRAE Guideline 13P,Guideline to Specifying DDC Systems1. In addition, any BAS design should be prepared incompliance with applicable GSA guides for design and specification of temperature controlsystems (e.g., Chapter 5 of PBS-PQ100.1 “Facilities Standards” and “U.S. Courts DesignGuide”).

2 Specifying Interoperable BACnet Systems

BACnet, ASHRAE's Building Automation and Control Networking protocol, was designed toprovide a single, uniform standard for building control systems. The ultimate goal of thisstandardization effort was "interoperability." Interoperability means the ability of disparatecontrol system devices to work together toward a common objective through the digitalexchange of relevant information. Although interoperability is often thought of in terms ofinterconnecting equipment from multiple manufacturers, it is also possible to contemplateinteroperating systems from a single vendor, possibly equipment of different vintages. Thus,while BACnet enables multivendor interoperability, it in no way requires it.

1 Available from the American Society of Heating, Refrigerating & Air-Conditioning Engineers, Inc., Atlanta, GA.

2

BACnet also provides a rich variety of tools to accomplish its communication objectives.Because of this, interoperability depends on the common selection of choices where multipletechniques are provided to accomplish a particular function. One of this guide's primary goals isto provide GSA specifiers with the information needed to understand and make the appropriatechoices.

The basic strategy for specifying interoperable systems based on BACnet may be summarized inthe following steps.

1. Specify the desired building automation and control system functionality. Specify the featuresdescribed in the Interoperability Areas defined below as appropriate to the project.

2. Specify the desired workstation functionality. Specify the features described in theInteroperability Areas defined below as appropriate to the project.

3. Specify the desired local or wide area network technology as appropriate to the project.

4. Specify that all networks shall make use of the BACnet protocol and that all devices suppliedshall implement the BACnet functionality enumerated in the device profiles in Annex B ofthis document.

5. Specify any additional BACnet functionality as recommended for specific requirements in thisdocument.

3 Interoperability Areas

"Interoperability areas" (IAs) are intended to describe the functionality that is important inpractical automation and control systems to achieve specific operational objectives. The five IAsare: data sharing, alarm and event management, scheduling, trending, and device and networkmanagement. Each IA implies a set of capabilities. Each capability, in turn, requires that specificelements of BACnet be implemented in a particular device to enable interoperability in a knownand predictable manner with a minimum of field engineering. The selection of which BACnetelements are required for a particular type of device - workstation, building controller, orapplication specific controller - is indicated in the recommended device profiles presented inAnnex B. This section describes the specific capabilities associated with each IA and thespecification issues that should be considered for each IA.

Note that the original BACnet standard (ANSI/ASHRAE 135-1995) contained a clause thatattempted to facilitate the specification of BACnet systems by defining "Conformance Classes"and "Functional Groups." Conformance Classes were a numerical hierarchy (1 to 6) thatprescribed an increasingly complex set of BACnet capabilities intended to correspond toincreasingly sophisticated control system devices. Functional Groups were additional collectionsof BACnet capabilities thought to be required to carry out a particular task. The idea was that adevice would be designed to fall within a particular conformance class but that functional groupcapabilities could be added as deemed necessary for practical application. These concepts, whilewell-intentioned, were flawed in that the combined conformance classes and functional groupsdid not correspond particularly well to real-world devices in the marketplace. The scheme alsorequired an undue amount of knowledge about the details of the BACnet specification on the part

3

of the building control system design community. For these reasons, a new approach, thedefinition of broad areas in which interoperability is desired, has been undertaken and will formthe basis of this guide.

This new approach attempts to decouple the task of the specifying engineer from that of thecontrol system manufacturer. From the perspective of the specifying engineer, a BACnet systemis described in terms of the desired building control system functions without regard for, or aneed to know about, the underlying BACnet capabilities needed to carry them out. Thesefunctions, in turn, imply a set of BACnet capabilities that manufacturers can then embed in eachof their devices of a particular type. The specification of these minimum requirements is thesubject of ongoing work within the ASHRAE BACnet committee. The mechanism is called"BACnet Interoperability Building Blocks" (BIBBs). These are presented in Annex A.

3.1 Data Sharing

"Data sharing" is the exchange of information between BACnet devices. It may be uni-directional or bi-directional. Interoperability in this area permits the collection of data forarchival storage, graphics, and reports, the sharing of common sensor or calculated valuesbetween devices, carrying out interlocked control strategies, and the modification of setpoints orother operational parameters of BACnet objects.

3.1.1 Data Sharing - Specification Issues and Recommendations

Point list

In order for suppliers to size their systems correctly in terms of their data sharingcapabilities, a list of each desired data point should be provided.

• Specify as part of the fundamental system design each analog and binary input,output, and value which is to be accessed over the network.

Presentation of data

Most data are presented in the form of tabular reports, real-time graphics, or plots of datavalues versus time.

• Specify the desired format of all tabular reports. Indicate which point values, orsets of point values, should be available in a single report.

• Specify which building systems should be available as graphic displays. Specifythe desired update interval for data on the graphics. Consider values of 1s to 5s.

• Specify that any data value from any networked device should be available forplotting in real-time. (For the long-term archival storage of values, see thediscussion of trending in 3.4) It should be possible to plot binary and analogdata concurrently as well as multiple instances of each datatype on the samescreen. Specify the desired sampling interval. Fast processes, such as steamvalve operation, should allow rapid sampling (1s to 5s intervals), while slow

4

processes, such as space temperature monitoring, can be sampled infrequently(30s to 60s intervals). Alternatively, if the data reside in devices that supportchange of value reporting (see 5.4) this mechanism could be specified in lieu ofa specific sampling interval.

Monitoring of any property of any BACnet object type

It should be possible to monitor any property of any standard or proprietary BACnetobject type.

• Specify that it must be possible to read and display the value of any property,including all required properties, supported optional properties, and proprietaryextensions of every object of every networked device.

Global objects

Some objects represent globally significant data. Examples are shared sensors, such asused to monitor the outside air temperature, or common binary information such aswhether night setback is in effect.

• Specify which data are to be shared and with which devices or systems. Foreach piece of global information, specify the frequency of the sharing, e.g., oncea minute, once an hour, once a day, or upon change of value. If change of valuenotifications are desired, specify the amount of change required before a newnotification is transmitted.

Setpoint and parameter modification

An operator with sufficient privilege should be able to change or "write" any desiredsetpoint or parameter in any networked device. Since some devices may be pre-configured and their operating parameters stored in non-volatile, non-writable memory itis prudent to indicate which setpoints and parameters must be adjustable over thenetwork.

• Specify which operating setpoints and parameters, at a minimum, must beavailable for modification via BACnet services (as opposed to proprietaryvendor-specific means).

• Specify the desired means of making the modifications, e.g., via a graphical userinterface (GUI) (as opposed to having to make a command line entry ordownloading a configuration file).

Peer-to-Peer data exchange

BACnet provides the capability for information to be exchanged between networkeddevices without operator involvement. However, it is important to describe the requiredfunctionality clearly.

5

• Specify any required data dependencies (interlocks, shared setpoints, schedules,and so on) that must be implemented via the network.

3.2 Alarm and Event Management

"Alarm and event management" is the exchange of data between BACnet devices related to theoccurrence of a predefined condition that meets specific criteria. Such conditions are called"events" and may be the basis for the initiation of a particular control action in response or thesimple logging of the event's occurrence. The event may also be deemed to represent a conditionwhich constitutes an "alarm" requiring human acknowledgment and intervention. Interoperabilityin this area permits the annunciation and acknowledgment of alarms; the display of dataindicating the basis for the alarm annunciation; the sharing of events for the purpose of loggingor distributed control applications; modification of alarm limits and routing; and the productionof summaries of the occurrence of such alarms and events.

BACnet defines two different mechanisms for generating alarms and events. One is called"intrinsic reporting" because it relies on the use of properties that are part of or "intrinsic" to theobject that is being monitored for alarms or events. The other mechanism is called "algorithmicchange reporting." Algorithmic change reporting is more general but is also requires theoverhead of an additional object called the Event Enrollment object. The intrinsic reportingmethod is preferred under circumstances where it meets the objectives of the intendedapplication.

3.2.1 Alarm and Event Management - Specification Issues and Recommendations

Alarm lists, operator notification and presentation of event information

The nature of each desired alarm condition and the way in which operators are notifiedabout alarms and events should be clearly described.

• Specify all desired alarms on a system-by-system basis, including alarm limits,interlocks to avoid "nuisance" alarms (e.g., no temperature alarms when fansystem is not running or during start-up or shut-down transitions), and desiredresponse time from the occurrence of an event until a notification is provided.

• Specify how alarms are to be categorized and distributed. This will be discussedmore fully below.

• Specify how alarms are to appear at the operator workstation.

• Specify that intrinsic reporting shall be used when it is sufficient to meet thefunctional requirements.

Alarm acknowledgment

It may be important to know which operator acknowledged an alarm and when.

6

• Specify that alarm acknowledgment capability be provided and that a log bemaintained that records when an alarm notification was received, when it wasacknowledged, and by whom.

Alarm summarization

It should be possible, at any time, to determine the status of all defined alarms.

• Specify that it shall be possible for an operator to receive, at any time, asummary of all alarms that are currently in effect and whether or not they havebeen acknowledged.

• Specify that is shall also be possible to receive a summary of all alarmsregardless of acknowledgment status; for which a particular recipient is enrolledfor notification; based on current event state; based on the particular BACnetevent algorithm (e.g., change of value, change of state, out of range, and so on);alarm priority; and notification class. These concepts will be discussed morefully below.

Alarm parameter adjustment

It should be possible for an operator to modify the alarm limits, in those cases where analarm is based on a value exceeding some predefined limit value, or other parametersused in computing that an alarm has occurred.

• Specify that operators shall be provided the capability to dynamically modifythe alarm parameters for all standard BACnet event types.

Alarm routing adjustment

BACnet provides the capability to direct alarms to different destinations based on thetype and priority of the alarm, the day of week, the time of day, and so on.

• Specify that operators shall have the ability to change alarm routing for eachalarm including the destination for each type of alarm and alarm priority, theday of week and time of day, and the type of transition involved (TO-OFFNORMAL, TO-NORMAL and so on).

3.3 Scheduling

"Scheduling" is the exchange of data between BACnet devices related to the establishment andmaintenance of dates and times at which specified output actions are to be taken. Interoperabilityin this area permits the use of date and time schedules for starting and stopping equipment andchanging control setpoints as well as other analog or binary parameters.

7

3.3.1 Scheduling - Specification Issues and Recommendations

Schedule list

In order for suppliers to size their systems correctly in terms of their schedulingcapabilities, a list of scheduled activities should be provided.

• Specify each action that should take place based on the date and time of day.This should include each start/stop operation and each change of operatingsetpoints and parameters based on operating mode, e.g., night set-back, vacationand holiday operation, special event operation, and so on.

Display of start and stop times of scheduled devices

BACnet provides the capability to implement control actions based on dates and times.These actions can cause devices to start and stop or setpoints or other analog parametersto be modified. It is important for an operator to be able to ascertain what actions arescheduled for any given date and time.

• Specify that an operator shall be able to inspect the content of any schedule anddetermine the specific control actions that will occur at any time, on any date.Additionally, for any particular device or system parameter that is the subject ofa schedule an operator shall be able to determine the schedule of actions relatedto that device or parameter.

Modification of schedules

Although BACnet defines the operation of calendars and schedules, it does not requirethat they be modifiable in all cases over the network. If this is needed, it should bedefinitively specified.

• Specify that certain, or all, calendar entries and schedules shall be modifiablefrom an operator workstation.

3.4 Trending

"Trending" is the accumulation of (time, value) pairs at specified rates for a specified duration.The values are those of a specific property of a specific object. "Trending" is distinguished fromthe real-time plotting of data (see 3.1.1) in that the data are usually destined for long-term storageand the sampling intervals are usually longer. Interoperability in this area permits theestablishment of trending parameters and the subsequent retrieval and storage of trend data.

3.4.1 Trending - Specification Issues and Recommendations

Archival storage of data

It should be possible to archive data values from any networked device but the supplierneeds to be able to calculate the required disk storage.

8

• Specify the maximum number of data points for which archival storage is likelyto be desired. A distinction should be made between points with true historicalvalue, e.g., energy use, and those that only need to be trended for a short periodof time such as points used to verify system operation following a repair orretrofit.

• Specify the minimum sampling interval required. For long-term trending, a rateof 5-6 samples per hour will often suffice.

• Specify the duration of time for which the archived information must beavailable for on-line retrieval. One to two years will often be adequate.

• Specify the means for archiving older data. A reliable tape system or writableCD would be appropriate.

Trend list

In order for suppliers to size their systems correctly in terms of their trending capabilities,a list of initially required trend logs should be provided.

• Specify the initial requirements for trending in terms of which data points are tobe trended, the sampling rate, the duration of each trend log, and the length oftime it is desired to keep the resulting logs available on-line. Alternatively,specify the approximate number of desired trend logs along with otherparameters.

Display and archive of trend data

BACnet provides the capability for field devices to collect data and then notify aworkstation or storage device that a trend log is available for retrieval.

• Specify that an operator will be able to retrieve and display trend logs, accessthe underlying numerical data in spreadsheet format, and output the data toprinters or other files.

Modification of trend log parameters

Operators with sufficient privilege should be able to modify the trend log parameters on-line from any BACnet workstation.

• Specify that the data points to be logged, the sampling rate, and duration oftrend logs shall be modifiable by an authorized operator from a systemworkstation.

9

3.5 Device and Network Management

"Device and network management" is the exchange of data between BACnet devices concerningthe operation and status of specific devices. Interoperability in this area permits determiningwhich devices are present on a given network and some of their operational capabilities,including which objects they maintain; the ability to start up and shut down communication froma particular device; the ability to synchronize the time in those devices that maintain clocks; theability to reinitialize the operation of a device's computer; the ability to establish connections asneeded; and the ability to change the connection configuration.

3.5.1 Device and Network Management - Specification Issues and Recommendations

Display of information about device status

An operator should be able to query the status of any device on the internetwork.

• Specify that an operator shall be able to display at any time the operationalstatus of any device on the BACnet internetwork.

Display of information about any BACnet object

An operator should be able to display information about any BACnet object or group ofBACnet objects.

• Specify that an operator shall be able to display at any time any property of anyBACnet object.

• Specify that an operator shall also be able to display property values of objectsgrouped by object type, object location, building system, and so on.

Ability to silence a device on the network that is transmitting erroneous data

If a sensor malfunction should occur, an operator should be able to quiesce the offendingdevice until repairs can be effected.

• Specify that an operator shall be able to direct a field device to stop transmittingevent or alarm notifications until a subsequent command to resumetransmissions is received.

Ability to synchronize the time in devices across the BACnet inter-network

It should be possible for an operator to issue time synchronization commands to one ormore devices as needed. This capability is independent of the existence of a "timemaster" on the network that carries out time synchronizations automatically.

• Specify that an operator shall be able to set the time and date in any device onthe network that supports time-of-day functionality. This capability should be

10

provided for both individual devices or groups of devices, including all devicessimultaneously.

Ability to cause a remote device to reinitialize itself

BACnet provides the capability to issue a command that will cause a remote device to"reinitialize" itself. This usually amounts to restarting or rebooting the computer itselfand starting any control activities "from scratch."

• Specify that an operator shall have the ability to issue reinitialization commandsto any device that supports remote reinitialization.

Ability to backup and restore the configuration of other devices

BACnet provides the ability for devices to be backed up and restored over the network.Although not all devices support this capability (e.g., because the operating software isROM-based), it is still important to have this ability if available.

• Specify that an operator shall have the ability to backup and restore all BACnetdevices on the network that support this capability.

Ability to command half-routers to establish and terminate connections

BACnet "half-routers" are used to provide connectivity to remote sites, usually on atemporary basis, using dial-up telephone technology.

• Specify that an operator shall have the ability to issue a command for theestablishment or termination of a connection to a remote BACnet network.

Ability to query and change the configuration of half-routers and routers

Operators should have the ability to change the database entries that half-routers androuters use to establish communications with remote BACnet networks.

• Specify that an operator shall have the ability to display and modify the routingtable entries in all provided BACnet half-routers and routers.

4 Use of BACnet Objects

BACnet objects form the basis for representing the functionality of building automation andcontrol equipment in a standard, network-visible way. The original BACnet standard defined 18object types and 3 more are in the final approval stage. While the use of the InteroperabilityAreas described above in conjunction with the device profiles of Annex A should result indevices being provided with a known set of BACnet capabilities, the number and type ofBACnet objects that will be provided depends on the specificity of the desired control sequencesof operation and other functional requirements of a particular installation, such as the number ofalarms, trending logs, schedules, metering points, and so on. In this section a number ofspecification issues will be presented that are specific to BACnet objects.

11

4.1 Naming Conventions

BACnet objects are uniquely identified within a particular BACnet device by a 32-bit numeric"object identifier." While this expedites access over the network and allows implementers toknow, in advance, how much storage to allocate for these identifiers, their use by humanoperators would be highly impractical. Therefore, BACnet also allows each object to bereferenced by an "object name." The standard, however, only specifies a minimum length of oneprintable character for the object name and does not even require that it be writable, i.e.,modifiable, once a device is commissioned. This was done to accommodate very simple devices,such as might be employed as unitary or application specific controllers.Both object identifiers and object names are required to be unique within the device that containsthem. There is an additional constraint on the Device object that its name and object identifier beunique within the entire BACnet internetwork including any temporary dial-up connections.Except for the Device object, manufacturers can freely configure object identifiers with noadverse impact on interoperability or the expandability of the system. The special case of Deviceobject identifiers is discussed in 6.5. Object names should be assigned according to a conventionestablished by the facility manager and not left for the manufacturer to arbitrarily decide.

The use of object names typically comes up in two very different contexts. The first is in theprogramming of BACnet devices for a particular purpose where an object is referred to in theprogram. The second is in referring to the object from a workstation where an operator may wantto view properties of a particular object or insert a property in a graphic or in a tabular report. Inthe latter case, the workstation will generally retain a mapping of the workstation name to theobject identifier (or object name) used in the remote device.

The basic principle to follow in setting up site-wide object (and device) naming conventions isthat the names should be as meaningful as possible given the name length available. Thus,"AHU1.STEMP" would be preferable to a more cryptic name like "A1ZXC5". An often usedconvention is to construct a name from a set of components, each of which relates to the buildingsystem installation. In this scheme the compound name is constructed from the building orfacility in which the system is located, the name of the building system itself, and, finally, thename of the desired point. An example of this FACILITY.SYSTEM.POINT (FSP) namingmethod is "BLDG226.AHU1.MA_TEMP". The facility is Building 226, the system is AirHandler Unit 1, and the point is the mixed air temperature. The convention may be easilyextended to accommodate areas within the facility, and subsystems within a system. Forexample, "BLDG226.BASEMENT_MER.AHU1.CW.STEMP" would refer to the supplytemperature of the chilled water subsystem of the air handler located in the basement mechanicalequipment room.

• Specify a set of abbreviations for common building systems, subsystems, and pointsthat are to be used by all vendors.

• Specify that object name properties, in those devices where the object name isconfigurable, shall be at least 50 characters long and shall, to the extent possible makeuse of a system and point nomenclature using the abbreviations specified above.

• Specify that BACnet object names used in workstations may be up to 50 characterslong and shall consist of a string made up of components indicating, as appropriate, the

12

location, system, subsystem, and point of the object. These object names shall be usedin workstation applications such as graphics, reports, and alarms wherever an objectname is appropriate in lieu of the object name property in the remote device. Moreover,an operator may display at any time the mapping between the object name used on theworkstation and the object name property used in the remote BACnet device.

4.2 Commissioning / Diagnostic Mode

A powerful feature of the BACnet object model is the ability to verify controller performance bymanipulating properties of certain objects and observing the resulting device operation. Forexample, the Present_Value property of an Analog Value object could be set to a value above theHigh_Limit and the execution of a programmed response to this condition could then be verified.This capability is of particular value during commissioning or for diagnosing problemssubsequent to installation and acceptance.

In order to be able to decouple the Present_Value of an object from its underlying process andforce it to take on a different value, the object must first be taken "out of service" by causing itsOut_Of_Service property to be TRUE. The Out_Of_Service property is provided for the Loop,Program and all of the Analog, Binary, and Multi-state object types. In order to accommodate therequirements of very simple devices, however, BACnet does not require that the Out_Of_Serviceproperty be writable. In such devices Out_Of_Service may possibly be accessed and altered bynon-BACnet means such as proprietary configuration devices or protocols. In order to be able toconduct commissioning and diagnostics using the BACnet network, it should be requested thatthe Out_Of_Service property be writable.

• Specify that the Out_Of_Service property shall be adjustable (writable) using BACnetservices for all Analog, Binary, Multi-state, Loop and Program objects.

4.3 Using Object Descriptions

All BACnet object types have an optional character string Description property whose length andcontent are not defined or limited. The idea was to provide a mechanism to allow an operator ortechnician to obtain useful information about the purpose or application of a particular object inany BACnet device. The Description property is optional because text takes up a relatively largeamount of memory and may exceed the resources of simple devices. Also, descriptive objectinformation may be stored in a database external to the device in which the object resides, e.g., ina workstation, thus conserving resources in a device with limited storage.

Nonetheless, the availability of a Description property in certain objects is highly desirable. Thisis particularly true for the Device object. Its description can convey its location, purpose, or othersignificant data.

• Specify that each Device object shall have a Description property and that the lengthavailable for the Description properties of other implemented object types shall beprovided in the "Property Range Restrictions" portion of the device's PICS.

13

4.4 Issues Related to Specific BACnet Object Types

The specification should provide direction to suppliers for the values to be assigned to certainproperties of BACnet objects that need to be coordinated and made consistent in the case wherethere may be multiple suppliers on a job. In BACnet, the values of these properties are referredto as "local matters," a term meaning that the value depends on the local circumstances.

4.4.1 Analog Input, Output, and Value

The analog object types have the ability to announce changes of value using the COVreporting method.

• Specify that all analog objects (Input, Output, and Value) shall have thecapability of using the Change of Value reporting mechanism and that theCOV_Increment property shall be writable using BACnet services.

4.4.2 Binary Input

Binary inputs have two properties, Inactive_Text and Active_Text, whose values shouldbe specified.

• Specify, for each Binary Input object, the text to be used for the Inactive_Textand Active_Text properties. For example, "On", "Off"; "Running", "Stopped","Open", "Closed", and so on.

4.4.3 Binary Output

In addition to Inactive_Text and Active_Text, Binary Output objects may need to havevalues specified for the Feedback_Value, Minimum_On_Time, and Minimum_Off_Timeproperties.

Binary Output objects have optional properties that are used to keep track of how manytimes the state has changed and to accumulate the total run time. If either of thesefeatures is appropriate for the application, support for these properties must be specified.

• Specify, for each Binary Input object, the text to be used for the Inactive_Textand Active_Text properties. In addition, if appropriate for the application, alsospecify appropriate values for the Feedback_Value, Minimum_On_Time, andMinimum_Off_Time properties.

• Specify support for the Change_Of_State_Time, Change_Of_State_Count, andTime_Of_State_Count_Reset if counting state changes is appropriate for theapplication. Also specify that Change_Of_State_Count be writable so that thecount can be reset.

• Specify support for the Elapsed_Active_Time andTime_Of_Active_Time_Reset properties if accumulating run time is appropriate

14

for the application. Also specify that Elapsed_Active_Time be writable so thatthe run time can be reset.

4.4.4 Binary Value

In addition to Inactive_Text and Active_Text, Binary Value objects may need to havevalues specified for the Minimum_On_Time, and Minimum_Off_Time properties.

Binary Value objects have optional properties that are used to keep track of how manytimes the state has changed and to accumulate the total run time. If either of thesefeatures is appropriate for the application support for these properties must be specified.

• Specify, for each Binary Value object, the text to be used for the Inactive_Textand Active_Text properties. In addition, if appropriate for the application, alsospecify appropriate values for the Minimum_On_Time, andMinimum_Off_Time properties.

• Specify support for the Change_Of_State_Time, Change_Of_State_Count, andTime_Of_State_Count_Reset if counting state changes is appropriate for theapplication. Also specify that Change_Of_State_Count be writable so that thecount can be reset.

• Specify support for the Elapsed_Active_Time andTime_Of_Active_Time_Reset properties if accumulating run time is appropriatefor the application. Also specify that Elapsed_Active_Time be writable so thatthe run time can be reset.

4.4.5 Calendar

Calendar objects store lists of dates, date ranges, or month/week/day combinations likethe "first Tuesday of every month." The most typical use of a Calendar object would beto store a list of holidays, vacation periods, or special events that would be referenced bya Schedule object. BACnet does not specify how many Calendar objects should beprovided, how many entries each Calendar must allow, or even that the entries bemodifiable over the network.

• Specify that devices that provide scheduling capability shall also provide at leastone Calendar object with a capacity of at least 10 entries. It shall be possible toview the Calendar object and make modifications from any BACnet workstationon the network.

• Specify, if the Calendar's Date_List property is writable using BACnet services,that all calendar entry datatypes must be supported. These are individual dates,date ranges, and specific weeks and days within a month.

15

4.4.6 Loop

Loop objects provide a network visible representation of control loops includingproportional-integral-derivative (PID) control loops. If it is anticipated that buildingengineers will want to tune such control loops from a BACnet workstation (as opposed tousing proprietary tuning methods), i.e., make adjustment to the various gain, bias, andsampling parameters, then the use of Loop objects should be required.

• Specify that the desired PID control loops shall be represented by Loop objectsand that the tuning constant properties shall be writable. These include theUpdate_Interval, Setpoint, Proportional_Constant, Integral_Constant,Derivative_Constant, and Bias. Specify writability of other Loop properties asappropriate to the application.

• Specify that all Loop objects shall have the capability of using the Change ofValue reporting mechanism and that the COV_Increment property shall bewritable using BACnet services.

4.4.7 Multi-state Input, Output, and Value

The Multi-state object types have State_Text properties that describe each of the possiblestates that the Present_Value of the object may take on. In addition, Multi-state Outputobjects may have a Feedback_Value.

• Specify, for each Multi-state Input, Output, and Value object, the text to be usedfor each state that the object can represent. In addition, if appropriate for theapplication, also specify how the Feedback_Value is to be determined.

• Specify that all Multi-state Input, Output, and Value objects shall have thecapability of using the Change of Value reporting mechanism and that theCOV_Increment property shall be writable using BACnet services.

4.4.8 Schedule

Schedule objects provide a way to alter binary or analog values based upon date and time.These values will typically be associated with physical outputs or with operationalparameters such as setpoints. A single schedule may be applied to multiple data points,each of which are subject to the same value being applied at the same time, e.g., multiplefan systems, all of which are turned on at 7 A.M. and off at 6 P.M. during the work week.However, BACnet does not specify how many Schedule objects should be provided, orthat any of their properties must be modifiable over the network.

• Specify each building system that is to be subjected to date and time schedulingand specify that it shall be possible to modify schedule entries from a BACnetworkstation.

16

4.5 Dynamic Object Creation

BACnet provides the ability to create new objects dynamically, i.e., after a device has beenconfigured initially. While, in theory, new instances of any object type could be created, theprimary use of this capability is the creation of Averaging, Calendar, Event Enrollment, Group,Notification Class, Schedule, and Trend Log objects.

• Specify, if required by the application, that it shall be possible to dynamically createinstances of the Averaging, Calendar, Event Enrollment, Group, Notification Class,Schedule, and Trend Log objects.

5 Use of BACnet Services

The following sections discuss specific issues related to the use of BACnet "services," the client-server messages that are exchanged between BACnet devices.

5.1 Interoperable Commands

One of the most significant aspects of BACnet is the implementation of a "command priority"scheme. This makes possible the "prioritization" of commands from various control processes,e.g., start-stop commands or setpoint changes, so that it is predictable which command will becarried out. This is implemented by assigning "command priority levels" to the variousprocesses. BACnet prescribes a set of standard priority levels as shown in Table 1:

Table 1. Standard Command Priorities

PriorityLevel

Application PriorityLevel

Application

1 Manual-Life Safety 9 Available

2 Automatic-Life Safety 10 Available

3 Available 11 Available


5 Critical Equipment Control 13 Available

6 Minimum On/Off 14 Available


8 Manual Operator 16 Available

Note that priority levels 3, 4, 7, and 9-16 are available for assignment. Thus the task for thedesigner becomes 1) deciding what processes need to be included in the prioritization schemeand 2) what relative importance, i.e., command priority level each should be assigned to.Examples of processes that should be considered for prioritization are: peak demand limiting,

17

night set-back, night cooling, and optimum start-stop. Interoperable command priorities must beapplied uniformly throughout the entire internetwork.

• Specify the processes that are to be prioritized and the command priority levels assignedto each if they do not fall into the pre-assigned levels shown in Table 1. For each pointsubject to the command priority scheme, specify a default status, position, or value forthe point to take on in the absence of a prioritized command.

5.2 Alarm Considerations

This section describes design considerations relating to alarm management in BACnet systems.

5.2.1 Assigning Alarm Priorities

BACnet provides the ability to assign a numeric priority to each event transition for whichnotification is desired. The transitions are TO-OFFNORMAL, TO-FAULT, and TO-NORMAL.The meaning of each transition depends on the algorithm used to process the alarm inputs. Themost common algorithms have been standardized and are precisely defined in BACnet. They areChange of Bitstring, Change of State, Change of Value, Command Failure, Floating Limit, andOut of Range alarms.

Priority values range from 0 to 255 with 0 being the highest priority and 255 the lowest. Typicalinstallations will use only a small number of discrete values such as "255, 128, 0" for "low,medium, high" but the values to be used need to be conveyed to the installers. Events of typeAlarm are generated in BACnet by objects that support "intrinsic reporting" or by EventEnrollment objects. Object types that support intrinsic reporting are the Analog Input, Output,and Value; Binary Input, Output, and Value; Multi-state Input, Output, and Value; and Loop.Intrinsic reporting is tightly prescribed in that it pertains only to an object's Present_Value orStatus_Flags properties. Event Enrollment objects can apply the standard algorithm types to anyproperty of any object.

In general, alarm distribution is managed by the use of "notification classes" which are describedin next section. One of the parameters conveyed in the alarm notification is the priority valuewhich is a property of the associated Notification Class object or the Event Enrollment object.The use to which the priority is put is not dictated by BACnet.

The task of the designer is to assign priority values to the alarms that are to be implemented andto specify the actions to be taken by recipients upon receipt. These could include directing thenotification to a printer; sounding an audible or visual signal; generating a report with alarms ofthe same priority collected together; and so on.

• Specify the priority values to be assigned for each alarm in the system. For eachpriority value, or range of values, specify the actions to be taken upon receipt.

5.2.2 Setting up Notification Classes

As mentioned in the preceding section, BACnet provides the ability to direct alarms to differentdestinations based on the type of the alarm transition, the day of week, and the time of day. The

18

mechanism for achieving this is to create and configure Notification Class objects, each of whichis referenced by other processes as a simple integer known as the "notification class."

In the most elementary situation, there would be a single notification class, perhaps staticallyconfigured as a default, that would be valid 24 hours a day and would direct all messages to asingle recipient. In the more general case, there might be multiple recipients who should onlyreceive specific types of alarms and, perhaps, only at certain hours of the day. A buildingmanager, for instance, might receive all alarms at all times, but only critical alarms would be sentvia a pager or to the night shift operator between midnight and 8 A.M.

• Specify how alarms should be distributed by specifying the recipients of each type andpriority of alarm. If desired, specify the valid days of the week and times of the day foreach.

5.2.3 Event Notification Message Texts

The occurrence of alarms and events in BACnet is signaled by the transmission of "EventNotification" messages. These messages convey most of the information that is important aboutthe occurrence including the "what, when, and where." There is also an optional parameter called'Message Text'. While many current systems use workstation software to translate an alarmidentifier into text meaningful to an operator, the text message may also be composed bysoftware resident in a field device and sent along with the other alarm data. Either way, it isuseful to specify the desired content and format of the alarm messages that will be seen by anoperator. Apart from the alarm details, the messages can also be used to indicate any necessaryactions to be taken. The messages might contain, for example, the name of a particular mechanic,service contractor, or phone number to be called, or indicate that certain other data points shouldbe inspected to verify the validity of the alarm condition.

• Specify the content and format of the alarm messages that will be delivered tooperators.

5.3 Assigning Levels of Authority to Certain Operators

Tracking the acknowledgment of alarms is one important aspect of facility management. BACnetdevices can be configured to accept alarm acknowledgments only from specific personnel. Thebroader issue is the assignment, if deemed appropriate, of differing levels of operationalauthority to different personnel. While this is mainly an administrative issue relating to theconfiguration of workstation software, several BACnet services have optional passwordprotection. They are the remote device management services, DeviceCommunicationControl andReinitializeDevice. The first allows an operator to "quiesce" a device that is generating speciousmessages due, for example, to a defective sensor, and the second forces a remote device to gothrough a restart process. In each case, the passwords are character strings of up to twentycharacters that are programmed into the remote devices.

• Specify, if desired, the number of authorization levels and the operator accounts to beassigned to each. If password protection for remote device management services isneeded, specify the passwords to be configured. Alternatively, specify that there shall

19

be a method provided for dynamically assigning passwords for remote devicemanagement functions after installation.

5.4 Change of Value Processing

A powerful BACnet capability is that of "change of value" (COV) reporting. In essence, certainstandard object types can be configured to generate a notification when their present valueschange by a prescribed amount or their status flags (the bits that indicate an object's in-alarm,fault, overridden, and out-of-service status) change at all. The object types that possess thisoptional capability are the Analog, Binary, and Multi-state Input, Output, and Value, and theLoop. This type of COV notification can be useful for efficiently updating real-time graphicdisplays and, in terms of limiting unnecessary network traffic, is preferable to continuouslyreading the value of a point to detect a change of value.

5.4.1 Subscribed COV Notifications

In order to receive COV notifications, a subscription request must be sent to the device whichcontains the objects in question.

• Specify workstation software shall have the capability of subscribing to COVnotifications for all object types that support it.

5.4.2 Unsubscribed COV Notifications

A new feature of BACnet that is currently under public review is the use of theUnconfirmedCOVNotification service as a means of distributing COV notifications for changesthat have not been subscribed to. This mechanism is intended to be used for distributing shared,globally significant, values, e.g., a common outside air temperature or a binary value indicatingwhether a building is "occupied" or not.

• Specify that changes of value of globally shared data shall be distributed by means ofUnconfirmedCOVNotifications.

5.5 Time Synchronization

It may be desirable to provide a standardized time reference for a single building system or groupof systems. In BACnet, Time synchronization is achieved by defining a computer to serve as a"Time Master." Depending on the scope of a particular project, i.e., whether it is localized orspans time zones, it may be desirable to use "Coordinated Universal Time" (UTC) as thereference rather than local time.

• Specify that a time master shall be provided and the format of the time synchronizationmessages, either local time or UTC.

20

6 Specifying System/Network Architectures

BACnet provides considerable flexibility in the selection of network types and interconnectionsbetween them. This section discusses the issues involved with deciding which network types touse and how to interconnect them.

6.1 System Architectures

The term "system architecture" refers to the arrangement of networks that make up an"internetwork." See Figure 6-1. Note that in BACnet, each network in an internetwork, isidentified by a unique "network number." The assignment of network numbers is furtherdiscussed in 6.4.

Figure 6-1. An Example of a BACnet Internetwork

R R R

B R

1/2RTRT

Physical Segment Physical Segment Physical Segment Physical Segment

Physical Segment Physical Segment

Segment 1

Segment 2

Net

wor

k 1

BSegment 3 Segment 4

Physical SegmentPhysical Segment

Net

wor

k 2

R RPhysical Segment Physical Segment Physical Segment

Segment 5

Net

wor

k 3

BACnet Internetwork

B = Bridge R = Repeater RT = Router 1/2RT = Half Router

1/2RT

PTP

Con

nect

ion

RT

21

The simplest configuration is a network comprised of a single physical segment with all devicesdirectly attached to it. The issue is then which local area network (LAN) type to select. This isdiscussed in 6.2. Since all LANs have some distance limitation, multiple physical segments mayhave to be joined by repeaters or bridges which selectively forward traffic based on knowledgeof where specific devices are located. If several networks need to be interconnected, BACnetrouters are available that can join networks using the same, or different, LAN technology. A keypoint is that slower networks should not be used to interconnect faster ones. Also, BACnetshould be used throughout unless there are existing "legacy" networks to which a connectionmust be made. Such connections require the use of translators or "gateways" which almostinevitably affect performance, throughput, and functionality in a negative way. See 6.8.

• Specify that BACnet shall be used throughout the building automation and controlinternetwork at all levels.

• Specify that the internetwork shall be configured such that, if three or more networksare involved with different performance characteristics, the faster networks shall beused to interconnect the slower ones.

6.2 Local Area Network Selection

BACnet provides a great deal of flexibility in configuring different LAN technologies foroptimal price vs. performance tradeoffs to meet the particular needs of a facility. The ability touse multiple LAN technologies also permits BACnet systems to accommodate new networktechnologies in the future while maintaining backward compatibility with installed systemcomponents.

BACnet currently supports four different LAN technologies, each one having particular pros andcons. Figure 6-2 illustrates the range of options presently in BACnet. Each technology is shownas a bubble. This reflects the fact that even within one LAN technology there are choices ofmedia, topology, and in some cases speed that effect the price and performance.

Sections 6.2.1 - 6.2.5 explain in more detail the important features that should be consideredwhen deciding on the appropriate LAN technologies to use.

22

Figure 6-2. Cost vs. Performance for BACnet LAN Options

6.2.1 ISO 8802-3, Ethernet

ISO 8802-3 is commonly known by the name "Ethernet." This is probably the most widely usedLAN technology in the world today, primarily because of its ubiquitous presence in office andbusiness networks. It is the fastest LAN technology used in BACnet. Most building controlcompanies offer Ethernet as an option for connecting high-end controllers with each other andwith workstations. The key features of Ethernet are summarized in Table 6-1.

Table 6-1. Features of ISO-8802-3, EthernetPros Cons• international standard • relatively high cost• already used in most buildings • distance limitations• variety of media (UTP, coax, fiber optic) • non-deterministic• very fast (10 Mbps or 100 Mbps)• easy to interface with PCs• the protocol is implemented in a chip• no special development tools

Each of the media options has different cost, different length limitations, and differentsusceptibility to electrical interference. Coaxial cables are the lowest cost and they are restrictedto a bus topology. Unshielded twisted pair (UTP) wiring is done in a star configuration andrequires the use of hubs. This is a very robust architecture and offers maximum flexibility withrespect to the physical location of the connected devices but it costs more because of the hubs.Fiber optic cables have the most immunity to electrical interference, can span longer distances,and are the most expensive option. It is possible to mix the various media in a single system.

EthernetEthernet

ARCNETARCNET

MS/TPMS/TP

LonTalkLonTalk

Performance

Cost

Higher

Faster

23

The 10 Mbps Ethernet technology is sufficient to meet the needs of most building controlapplications. Under some circumstances it may be desirable to use an existing 100 Mbps LANfor a portion of the control system, a workstation for example. It is possible to connect 10 Mbpssegments to 100 Mbps segments by using special hubs.

Although Ethernet is the fastest LAN option in BACnet it is non-deterministic. This means that itis not possible to guarantee that a device will be able to transmit a message within a specificamount of time. This is a consequence of the fact that Ethernet uses a contention-based schemeto regulate access to the transmission medium. A device can transmit a message anytime thenetwork is quiet. If two devices decide to transmit at the same time a collision occurs. Collisionsonly become a problem in networks with high traffic volumes. If the network is properlydesigned and maintained this difficulty can be avoided. In this context, "proper design" mayinvolve, among other things, distributing nodes likely to generate high traffic volume onto morethan one Ethernet segment and using bridges between segments that isolate "local" traffic so thatit is not propagated to all nodes.

Specifying Ethernet LANs

Because of its cost, an Ethernet LAN is generally used as a backbone network connectingworkstations and supervisory controllers together. The various options available make itnecessary to indicate which ones are acceptable.

• Specify which devices in the control system should reside on the Ethernet LAN.

• Specify the transmission medium option that is to be used. If more than one willbe used, indicate which one is to be used where, and the devices that are to beconnected. If hubs are needed, specify the number of ports and the kind ofmedium for each port.

• Specify whether 10 Mbps Ethernet or 100 Mbps Ethernet is to be used.

6.2.2 ANSI/ATA 878.1, ARCNET

ARCNET (ANSI/ATA 878.1) is a LAN technology that is slower than Ethernet but it isdeterministic, meaning that it is possible to determine the maximum delay before a device will beable to transmit a message. ARCNET has been popular in some building control product lines asa relatively high-speed network for connecting high-end controllers together and withworkstations. Ethernet has gradually been diminishing ARCNET's popularity for thisapplication.

The newest generation of ARCNET chips has a scaleable speed and can be used with EIA-485signaling. This is becoming a popular option for use with unitary controllers. The key features ofARCNET are summarized in Table 6-2.

24

Table 6-1. Features of ARCNETPros Cons• ANSI standard • single source chip• deterministic response • distance limitations• variety of media (UTP, coax, fiber optic) • too costly for low-end controllers• fast (150Kbps - 7.5Mbps)• high performance for medium cost• the protocol is implemented in a chip• no special development tools

Specifying ARCNET LANs

If ARCNET is being used as a LAN for unitary controller networks there may be severalof them in the control system. The specifications need to be clear for each one.

• Specify which devices in the control system should reside on the ARCNETLAN.

• Specify the transmission medium option that is to be used. If more than one willbe used, indicate which one is to be used where and the devices that are to beconnected. If hubs are needed, specify the number of ports and the kind ofmedium for each port.

• Specify how ARCNET addresses are to be assigned (see 6.3.1).

6.2.3 Master-Slave/Token-Passing, MS/TP

The Master-Slave/Token Passing protocol (MS/TP) was created by ASHRAE to meet the needsof low-cost building controllers and is unique to BACnet. The MS/TP protocol is implementedusing EIA-485 signaling. MS/TP can be used in a master-slave mode, a peer-to-peer tokenpassing mode, or a combination of the two. As a practical matter the speed is limited to about 76Kbps. Higher speeds are theoretically possible but they would require a dedicated chip forreliable operation. The added complexity and cost would make LonTalk or ARCNET betterchoices at higher speeds.

MS/TP is the lowest cost LAN option in BACnet. It is designed for implementation on standardsingle-chip microprocessors without the addition of outboard hardware for timing andtransceiver interfaces. The key features of MS/TP are summarized in Table 6-3.

25

Table 6-3. Features of MS/TPPros Cons• ANSI standard • single media• low cost • limited speed (9.6Kbps - 76Kbps)• can be implemented in single chip microprocessors• deterministic response• no special development tools

Specifying MS/TP LANs

MS/TP LANs will generally be used for unitary controller networks so there may beseveral of them in the control system. The specifications need to be clear for each one.

• Specify which devices in the control system should reside on the MS/TP LAN.

• Specify the baud rate to be used.

• Specify how MS/TP addresses are to be assigned and if slave devices will beused how the address space is to be divided between slaves and masters (see6.3.2).

6.2.4 EIA-709.1, LonTalk

LonTalk is a technology developed by the Echelon Corporation2. It has recently been adopted asan EIA standard for home automation networks. Like Ethernet and ARCNET, LonTalk isimplemented in a special chip. LonTalk provides the most flexibility in terms of media options.Transceivers are available for traditional wired LANs (UTP, coax, fiber optic) as well as wirelesscommunication (radio frequency (RF) and infrared (IR) ).

LonTalk allows scaleable speeds up to 1.25 Mbps. It is comparable to MS/TP at the low end,though the hardware is more costly in most cases, and ARCNET at the higher end (above 150Kbps). As the speed scales upward from 150 Kbps, ARCNET is somewhat more attractive interms of hardware cost.

LonTalk has the unique distinction of being the only BACnet LAN technology that requiresspecial development tools. These tools are only available from Echelon Corporation.

The LonTalk protocol is often confused with LonMark. They are totally different things. Devicesusing the LonTalk protocol do not interoperate unless some additional constraints are added thatare specific to the intended application of the device. The BACnet application layer protocol

2 Certain trade names and company products are mentioned in the text or identified in an illustration in order toadequately specify the equipment used. In no case does such an identification imply recommendation orendorsement by the National Institute of Standards and Technology, nor does it imply that the products arenecessarily the best available for the purpose.

26

defines these constraints. In BACnet, LonTalk is no different than any other LAN technology inthat it is simply used to convey BACnet messages between devices.

LonMark is the name given to a set of implementer's agreements that make use of applicationfeatures of the LonTalk protocol to achieve the same goal of interoperability. LonMark productsare not compatible with BACnet. In order to mix BACnet devices and LonMark devices in thesame control system, a gateway is required. It is no different than combining BACnet deviceswith devices using any proprietary communication protocol. Gateway issues are discussed insection 6.8. The key features of LonTalk are summarized in Table 6-4.

Table 6-4. Features of LonTalkPros Cons• variety of media (UTP, coax, RF, IR,fiberoptic)

• non-deterministic

• scaleable speed (32K to 1.25 Mbps) • distance limitations• special development tools required• application size limited

Specifying LonTalk LANs

LonTalk LANs will generally be used for unitary controller networks so there may beseveral of them in the control system. The specifications need to be clear for each one.

• Specify which devices in the control system should reside on the LonTalk LAN.

• Specify the media, speed and topology to be used.

• Specify how LonTalk addresses are to be assigned (see 6.3.3).

6.2.5 Point-to-Point, PTP

The BACnet Point-to-Point protocol offers a way to interconnect individual devices or networksusing serial asynchronous connections such as provided by dial-up modem-to-modem links. Thedevices on either end of the PTP connection act as "half-routers" and, once the connection isestablished, appear as routers to devices on their respective networks. See Figure 6-1. If it isdesired to remotely access a BACnet network via a dial-up connection, PTP should be specified.

• Specify that PTP shall be used as the means to attach to a BACnet LAN via a dial-upconnection. Also specify that the optional password protection shall be provided.

6.3 Specifying MAC Addresses in a Consistent Manner

Every device in a BACnet system has a media access control (MAC) address. The MAC addressis combined with the network number to uniquely identify each device for the purpose ofdelivering a message. This is similar to the way a street address is combined with a city and stateto address a letter. For Ethernet networks a unique MAC address is assigned when thecommunication chip is manufactured. No special address configuration is necessary for BACnet

27

devices using Ethernet. For other BACnet LANs, MAC addresses must be configuredspecifically for each installation.

In a multi-vendor environment it is important to manage the assignment of these addresses toensure that there are no duplicates on the same network. There is no problem with duplicateMAC addresses on different networks, just like there is no problem with having more than one123 Main Street as long as they are in different cities. A site-specific plan for assigning MACaddresses should be developed and vendors should be required to follow it. Guidance on how todo this for each of the relevant BACnet LANs is given below. It is also important to documentthe assigned addresses so that future changes to the system do not cause conflicts.

• Specify that MAC addresses shall be assigned as designated by the owner.

• Specify that a list of all assigned MAC addresses be included in the systemdocumentation.

6.3.1 Ethernet MAC Addresses

For Ethernet networks a unique MAC address is assigned when the communication chip ismanufactured. No special address configuration is necessary for BACnet devices using Ethernet.

6.3.2 ARCNET MAC addresses

The valid MAC addresses for BACnet devices using ARCNET are 1-255 (0 is reserved forbroadcasts). Thus there can be at most 255 ARCNET devices on the same network. If theARCNET LAN is part of an internetwork, meaning that there are two or more networks in thesystem, then there must be one or more routers. It is a good convention to reserve particularaddresses to be used for ARCNET routers. If the ARCNET LAN is directly connected to onlyone other network then a single address is sufficient. If the ARCNET LAN is a backbonenetwork then a range of addresses will be needed. Using the same router addresses on everyARCNET LAN in the system makes it easier to identify routers when troubleshooting problems.It may also make it easier to program controllers that need to know the router's address.

• The site addressing plan should reserve an address or a range of addresses to be used byARCNET routers. For the case where one router per ARCNET network is sufficient, thevalue 255 is recommended. For the case where more than one router per network will bepresent, assigning addresses in decreasing order beginning with 255 is recommended.

If more than one vendor will be providing ARCNET devices that will reside on the samenetwork or if that may be the case in the future, it is important to ensure that duplicate addressesare not accidentally assigned. One way to do this is to assign a range of addresses to each vendor.The vendors can select any address within the assigned range but cannot use addresses outside oftheir assigned range. All addresses used must be documented so that future changes can bemanaged.

• The site addressing plan should reserve a range of addresses for each vendor. It isrecommended that ranges begin with the smallest address that is not in a previouslyassigned range.

28

6.3.3 MS/TP MAC addresses

The valid MAC addresses for BACnet devices using MS/TP are 0-254 (255 is reserved forbroadcasts). Thus there can be at most 255 MS/TP devices on the same network. There is anadditional constraint because the address space is divided between master devices and slavedevices. Addresses 128-254 are reserved for slaves. Addresses 0-127 are valid for both mastersand slaves. The portion of the address space that is actually used for masters in a particularinstallation is determined by the value of the Max_Master property of the Device object.

The MS/TP LAN was designed for connecting low-cost controllers typically used for unitary orapplication specific controllers. It should not be used as a backbone LAN so that there should beat most one router to other LANs in the system. A router must be a master. It is recommendedthat MAC address 0 be reserved for use by the MS/TP router.

• The site addressing plan should reserve the address 0 for use with MS/TP routers.

If more than one vendor will be providing MS/TP devices that will reside on the same networkor if that may be the case in the future, it is important to ensure that duplicate address are notaccidentally assigned. One way to do this is to assign a range of addresses to each vendor. Thisapplies to both master addresses and slave addresses. The vendor can select any address withinthe assigned range but cannot use addresses outside of their assigned range. All addresses usedmust be documented so that future changes can be managed.

• The site addressing plan should reserve a range of master addresses and slave addressesfor each vendor as appropriate. It is recommended that ranges begin with the smallestaddress that is not in a previously assigned range.

The address space in the range 0 - 127 should be apportioned between masters and slavesaccording to the needs of the system. If Max_Master is writable using BACnet services, there isan advantage to assigning the smaller addresses first and configuring Max_Master to the highestaddress actually used instead of using the default value of 127. This it true even if none of theaddress space will be used for slave devices. This approach will reduce the amount of time usedto search for new stations that have entered the network and increase the bandwidth available fornormal communication. If more master devices are added to the network at a later time it wouldbe necessary to update the value of Max_Master in each of the master devices.

6.3.4 LonTalk MAC addresses

Like Ethernet, LonTalk neuron chips are manufactured with a unique address or Neuron_ID.Other addressing schemes can also be used that are based on (domain, subnet, node)configurations or (domain, group, member) configurations. If the Neuron_ID is to be used as thesole means of addressing for these devices no additional configuration is necessary. If one of theother addressing schemes is to be used then the owner needs to create and impose constraints toensure that addresses are not duplicated.

29

6.4 Network Numbering Conventions

A BACnet control system can contain up to 65,535 interconnected networks. This provides greatflexibility for integrating the control systems in separate buildings. The ability to interconnectbuildings provides opportunities for aggregating and managing utility loads in a deregulatedutility environment, remote maintenance support, and centralized collection of energyperformance data.

BACnet requires that each network in a system be assigned a unique network number. Thismeans that if separate buildings are to be connected the assignment of network numbers must bemanaged so that no duplicate numbers occur. A GSA-wide plan for assigning network numbersshould be developed and vendors should be required to follow it.

• Specify that network numbers shall be assigned as designated by the owner.

The recommended approach for assigning network numbers is to allow each region to use theentire network number domain within that region. The region would assign a range of numbersto each building. The people directly responsible for the building would subdivide this range in amanner appropriate to the building. For example, the division could be by network technology,by floor, or by wing. An example may make this idea clearer.

Consider a region where there are no more than 655 buildings. The network number domaincould be divided as follows:

BBBFFwhere: BBB = a number between 1 and 655 assigned to each building

FF = 00 for the building backbone networkFF = 1-35 indicating the floors or separate systems in the

building

Note that the network numbers in the range where BBB = 000 are not assigned. These networknumbers might be reserved for special purposes, such as temporary dial-up connections.

If a region has more than 655 buildings or has buildings with more than 35 floors then it mightbe necessary to sub-divide the region and use an entire network number domain for each sub-region.

The consequence of these separate domains is that it will not be possible to integrate buildingsthat are in separate domains without using some additional mechanism to make the networknumbers unique. This could be done if the central management site uses BACnet/IP to connect toeach domain. By assigning each domain to a separate IP port it would become possible todistinguish otherwise identical network numbers. This would allow a central facility tocommunicate with all of the buildings but each building would only be able to communicatedirectly with devices that are within the same domain.

GSA already maintains a nation-wide database of buildings that includes a numbering system touniquely identify each building. This numbering system has a range that is too large be useddirectly for assigning BACnet network numbers. For each region or sub-region that has a

30

separate BACnet network domain, a mapping should be created to link the GSA building numberwith the range of BACnet network numbers that are assigned to that building.

It is important to note that any network number management approach that guarantees eachnetwork has a unique number meets the requirements of BACnet.

6.5 Device Object Identifier Conventions

A BACnet control system can contain up to 4,194,305 devices. This constraint comes from thefact that each device must have a unique value for the Object_Identifier property of the Deviceobject. This uniqueness is the basis for BACnet services that permit dynamic location ofinformation and binding of addresses (the process of determining how to address a message inorder to communicate with a particular device).

In a multi-vendor and/or multi-building environment the assignment of the DeviceObject_Identifier value for each device must be managed so that no duplicate numbers occur. AGSA-wide plan for assigning Device Object_Identifier values should be developed and vendorsshould be required to follow it.

• Specify that Device Object_Identifier properties shall be assigned values as designated bythe owner.

The recommended approach for assigning Device Object_Identifier values is to make use of theunique building numbers used to manage network numbers (the BBB field in the exampleabove). In a given building the object identifier would end with the assigned building number.The remainder of the identifier number space would be divided in a manner appropriate to thebuilding. An example of how this might work is as follows:

XXFFBBBwhere: XX = a number in the range 00 - 40

FF = 00 for the building backbone networkFF = 1-35 indicating the floors or separate systems in the

buildingBBB = a number between 1 and 655 assigned to each building

For ARCNET and MS/TP networks the XX field could also be used to assign the MAC address.See 6.3.

This management approach has the advantage of providing a great deal of information tosomeone troubleshooting communication problems because the physical location of the devicecan be deduced from the Object_Identifier property of the Device object. It also makes manyvalid Object_Identifier values unusable because they don't fit into the template. In this example,at most 41 devices could be present on each network for a total of 1,476 in the entire building. Ifthe building does not use, and will never use all 36 networks, then the number space for unusednetworks can be added to existing networks to get around the limitation of 41 devices pernetwork.

31

This would work fine for many buildings but may be too restrictive for very large buildings. Ifthe XX and FF fields were combined into one range that was assigned serially as devices wereinstalled, the total number of possible BACnet devices increases to 4,195 and they could bearbitrarily assigned to different networks. These kinds of decisions can be made on a building-by-building basis. The critical factor is that the range of possible values be restricted to a set thatwill never conflict with assignments made in other buildings in the same network domain.

6.6 Use of BACnet with the Internet Protocols

BACnet provides two distinct ways that messages can be conveyed across internets that use IP,the Internet Protocol. By means of these techniques, wide area BACnet internetworks can becreated that span the country or the globe.

6.6.1 Annex H Tunneling Routers

BACnet Tunneling Routers (BTR) are devices that appear as traditional routers to the devicesthat are on the same LAN as the BTR but use IP to communicate with peer BTRs on distantLANs. This is accomplished by configuring routing tables in each BTR that consist of (BACnetNetwork Number, IP Address) pairs. The mechanism is illustrated in Figure 6-3.

The use of BTRs is relatively inexpensive and has the advantage that the individual BACnetdevices need not themselves be "IP literate." In other words, BTRs can be used with existingBACnet networks that also have a connection to an IP internet, intranet, or the Internet with acapital "I".

32

Figure 6-3. An IP Connection using Annex H Tunneling Routers

6.6.2 Addendum 135a, BACnet/IP

In the case of BACnet/IP, the addendum to BACnet adopted in January 1999, the individualBACnet devices themselves are IP-capable. Thus no tunneling routers are needed and the devicescan communicate among themselves directly. A problem arises, however, when it is necessary toconvey broadcast messages from one IP subnet to another since most IP routers do not pass suchmessages. To get around this, BACnet/IP specifies the use of a device called a "BACnetBroadcast Management Device" (BBMD). A BBMD acts essentially like a BTR but only for

Annex HRouter

BACnetDevice

IPRouter

Internet

Annex HRouter

BACnetDevice

IPRouter

A

B

BACnetDevice

BACnetDevice

BACnetDevice

BACnetDevice

Net 1

Net 2

33

broadcast messages. BACnet/IP also specifies how IP multicasting can be used to propagatebroadcasts if the IP routers support it. Multicasting eliminates the need for BBMDs.

A

Figure 6-4. BACnet/IP Devices Communicate with Each Other Directly

Note in Figure 6-4 devices A and B are on the same BACnet network even though they are ondifferent IP subnets. Thus multiple IP subnets can be combined to form a single BACnetnetwork. BACnet/IP also allows "foreign devices," i.e., devices not on the same subnet with anyof the other BACnet devices, to "join" the BACnet internet. This capability will prove useful forworkstations that have internet access but are remote from the site where the BACnet devices arelocated.

BBMDBACnetDevice

IPRouter

Internet

BBMDBACnetDevice

IPRouter

B

BACnetDevice

BACnetDevice

BACnetDevice

BACnetDevice

34

• Specify, if existing BACnet non-IP devices are to be interconnected via an IP network,that BACnet Tunneling Routers conforming to Annex H shall be provided.

• Specify, for new networks which need IP connectivity, that devices shall be providedthat conform to Addendum 135a, BACnet/IP. For broadcast distribution, BBMDs shallalso be provided or appropriate arrangements made for the use of IP multicasting.

6.7 Routers - Interconnecting Multiple BACnet Networks

Routers in BACnet are used for two distinct purposes. The first is to join together networks thatuse different LAN technologies, e.g., a BACnet Ethernet LAN to a BACnet MS/TP LAN. Thesecond is to join together networks that use the same technology but have exhausted their supplyof MAC addresses. An example of this would be a router that connects two ARCNET LANs,each of which can have at most only 255 devices. Several items should be specified.

• Specify that it shall be the contractor's responsibility to configure each router using thenetwork numbering scheme agreed to for the project.

• Specify that each router shall be configured such that all network layer error messagesshall be directed to a specific workstation using the BACnet ConfirmedTextMessageservice.

• Specify that it shall be the contractor's responsibility to initially configure each routerwith routing tables containing all network numbers that are part of the project's internet.

• Specify that the router shall be able to receive messages at each port of any length thatis valid for the LAN technology connected to that port, and to forward the message toany directly-connected network that can convey a message of that size.

6.8 Message Segmentation

Message traffic data collected from operating BACnet systems indicate that the most commonlyused BACnet messages are small. However, it is sometimes desirable to be able to exchangelarge messages. For example, uploading and downloading a device's database and programs mayrequire the exchange of considerable information.

A manufacturer may choose to restrict the message buffer size in a device as a way to optimizememory resources. Under these circumstances it may become necessary to support messagesegmentation in order to exchange large messages. LAN technologies also impose constraints onmaximum message sizes. A consistent policy on message sizes and segmentation is needed toinsure interoperability in multi-vendor systems.

• Specify that all BACnet devices shall support the reception of messages up to thelargest size permitted by the LAN technology or support reception of segmentedmessages.

35

• Specify that all BACnet devices shall support the transmission of messages up to thelargest size permitted by the LAN technology or support transmission of segmentedmessages.

• Specify that all workstations shall support both segmented message transmission andsegmented message reception.

• Specify that all BACnet Building Controllers (see B.2) shall support both segmentedmessage transmission and segmented message reception.

6.9 Gateways - Connecting to Legacy Systems

In some retrofit projects it is not economically viable, or necessary, to replace the entire buildingcontrol system at one time. Expansion or replacement of the system may take place in stages.Under these circumstances it is necessary to find a way to connect the remaining legacycontrollers with the new BACnet controllers. This is accomplished by using a device called a"gateway." A gateway is a device that translates between BACnet and the non-BACnetcommunication protocol.

Computers require precise, rigidly defined rules or protocols for communication. Protocoltranslation, like language translation, is an imperfect art. Concepts that are easy to express in onelanguage or protocol may be difficult or even impossible to translate into another. Gatewaysusually provide access to only a subset of the information that is available in the non-BACnetsystem. Complicated tasks such as scheduling and alarm processing may not be possible at all.For these reasons gateways should be avoided when possible and when they are necessary theircapabilities and performance must be clearly specified.

Which devices can communicate with each other?

Gateways do not necessarily permit any arbitrary pair of devices to communicate witheach other. For example, a workstation could be capable of connecting to a BACnet LANand also to a non-BACnet LAN and provide the operator with access to information fromboth systems. This approach may not allow communication between the BACnetcontrollers and the non-BACnet controllers.

• Specify that the operator workstation shall display information from both theBACnet and non-BACnet devices. If appropriate, specify which other devicesshould also be able to communicate through the gateway.

Uni-directional or bi-directional communication?

Gateways may be uni-directional, meaning that a BACnet device can access informationfrom a non-BACnet device but the non-BACnet devices cannot access information fromBACnet devices. The reverse is also possible where a non-BACnet device can accessinformation from BACnet devices but BACnet devices cannot access information fromthe non-BACnet devices. Gateways may also be bi-directional.

36

• Specify which way information must flow through the gateway or that thegateway should provide bi-directional communication.

Which points are readable?

Gateways have a limited capacity. Not all information contained in the systems beinginterconnected is necessarily accessible through the gateway.

• Specify which non-BACnet points are to be readable from the BACnet side ofthe gateway and which BACnet objects are to be readable from the non-BACnetside of the gateway.

Which points are changeable?

The ability to view information through the gateway does not imply an ability to makechanges or to command actions through the gateway.

• Specify which non-BACnet points are to be modifiable from the BACnet side ofthe gateway and which BACnet objects are to be modifiable from the non-BACnet side of the gateway.

Expansion

Control systems tend to change over time. A gateway needs to be able to accommodateforeseeable control system changes.

• Specify how much expansion capacity is required in the gateway.

Archiving controller programs and configuration databases

Many control systems provide a way to archive control programs and configurationdatabases by uploading the pertinent files from the controller. These archives can be usedto restore the controller to a known configuration in the event of an equipment failure.Gateways may not be capable of transferring this kind of information.

• Specify how controller program and configuration database archives are to becreated and maintained.

Trending

The collection of trend data is handled in many different ways in proprietary controlsystems. A gateway may permit a workstation to access the points that need to be trendedbut may not be able to transfer trend log files that are created by a controller. It isimportant to understand the trending capabilities of the legacy system and to ensure thatthe gateway has the necessary capability to support the trending needs of the application.For additional information about trending see 3.4.

37

• Specify any gateway features that will be needed to support collection of trenddata.

Scheduling

The methods used to schedule control system actions are handled in many different waysin proprietary control systems. If the scheduling needs of the facility require passingschedule information through the gateway, this capability must be specified. For moreinformation about scheduling see 3.3.

• Specify any gateway features that will be needed to support scheduling.

Alarm and Event Handling

The detection, notification, and acknowledgment of alarms and other events are handledin many different ways in proprietary control systems. It is important to understand thealarm and event handling capabilities of the legacy system and to ensure that the gatewayhas the necessary capability to support any needed alarm and event processing in theintegrated system.

• Specify any gateway features that will be needed to support the detection,notification, and acknowledgment of alarms and other significant events.

7 Practical Considerations in the Construction of BACnet Systems

Several key issues directly affect the successful implementation and operation of a BACnet-based building automation system. These issues can be classified according to the phases of anyconstruction project - from procurement through construction and ongoing operations andmaintenance. In the sections that follow, some general guidelines and recommendations areoffered to assist the BAS project team in the procurement, construction, commissioning, andoperation/maintenance phases of a BAS project.

7.1 Procurement Phase

A successful BAS implementation requires a careful vendor procurement process. The endproduct of a control system design should be a complete set of construction documents. Theconstruction documents referred to here include the Request for Proposal (RFP) and the project’sTechnical Specifications.

The RFP document serves as the vendor's overview of the project, a set of instructions forbidding the project, and the specifying engineer's tool to evaluate competing BAS solutions.Therefore, there are several items that must be included in this document in order to ensureinteroperability via BACnet, and to avoid misunderstandings and future implementationproblems.

As previously stated, BACnet enables multi-vendor interoperability but in and of itself, does notrequire that multiple vendors participate in any given BAS project. If the project requires a multi-vendor environment, special attention should be made in the RFP to clearly define each scope of

38

work along with its respective deliverables. In the process of this definition, the overall systemdesign should be referenced to ensure that all system components (hardware and software) areaccounted for within the individual scopes and to ensure that there is no overlap.

In order to ensure interoperability, the RFP should require the controls vendor to submit adescription of the proposed system. This description should define the system architecture andexplicitly identify “where and how” BACnet is to be implemented. At a minimum, the RFPshould require that the description include the following items:

• Narrative providing an overview of the BAS system, primary components, workstation(s),and LAN architecture

• Identification of any clarifications or exceptions to the project specifications

• A listing and quantification of all microprocessor-based BAS equipment to be supplied andassociated information “cut-sheets” for each

• A listing of references, as appropriate, for projects of a similar nature to the proposed BAS

• The option of requesting a formal BAS demonstration at either the vendor’s local offices orcustomer location

In addition to the system description, a completed "Vendor Qualifications Form" should bedeveloped. As part of this form, the vendor should be required to provide information on localoffice staffing, spare parts inventory, and the number of locally installed BACnet systems withreferences.

With the above information, the specifying engineer can ensure the vendor understands therequirements of the project, has sufficient experience, and has proposed a system that adheres tothe Technical Specifications. If alternative approaches are provided in one or more exceptions tothe specifications they must be carefully reviewed to determine whether or not they meet theproject needs.

7.2 Construction Phase

After the controls vendor(s) are selected and the project is awarded, the submittals phase ofconstruction begins. As part of the submittal review process, the control vendor(s) should berequired by the Technical Specification to submit several key items to ensure interoperability.These items include a Protocol Implementation Conformance Statement (PICS) and detailedpoints lists. Coordination issues between the vendor(s) and Owner also require specialconsideration.

7.2.1 Protocol Implementation Conformance Statements (PICS)

As part of the vendor's submittal package, a PICS should be submitted for each BACnet devicein the system. At a minimum, the PICS should demonstrate the device's BACnet capability bylisting the following items:

39

1. BACnet Standard Application Services Supported - This table confirms the BACnet servicessupported by the device. Refer to Annex A for detailed descriptions of these services.

2. Standard Object Types Supported - This table lists the device's supported object types aslisted in Section 4.2. It also indicates if the object is dynamically creatable, dynamicallydeletable, optional supported properties, and writable properties.

3. Data Link Layer Options - Describes the network types supported for communications, e.g.,Ethernet, ARCNET, or MS/TP.

4. Special Functionality - Describes any special exceptions the device may have to the BACnetprotocol in order to perform any specific function.

5. Property Range Restrictions - Indicates, among other things, the number of charactersallowed for the various text properties, such as Object_Name and Description.

The BACnet requirements of the Technical Specifications should act as the submittal reviewcriteria. The information provided by the PICS should be compared to the TechnicalSpecifications to ensure the device will function in the system as intended by the design.

7.2.2 Points Lists

The controls vendor(s) should also provide a detailed points lists for the system. In addition tostandard I/O information, these points lists should contain the following items to ensure BACnetinteroperability:

• Proposed I/O Names - An I/O point naming convention should be specified in the TechnicalSpecifications in order to identify clearly system points. Verification of the vendor'sproposed naming schemes should be performed.

• BACnet Object Description - This description includes the Object ID and Device ID for eachI/O point. In a multi-vendor environment, special care should be taken to ensure that nodevice ID's are duplicated. Also, non-standard BACnet objects and properties should bedocumented including their structure and data types.

7.2.3 Coordination

Successful BACnet interoperability also depends on the interaction between vendors, in a multi-vendor environment, and between the vendor(s) and owner. To ensure this process takes placeboth effectively and proactively, the vendor should produce a coordination action-list thatidentifies all BACnet-related information requirements (e.g., each BAS vendor involved, HVACequipment interfaces, owner LAN/WAN coordination, etc.), responsible parties, contact names,and critical dates. This action-list should be reviewed and updated at all BAS-related progressmeetings.

40

7.3 Commissioning Phase

During the commissioning phase, each control sequence should be verified along with thefunctionality of each workstation component including graphics, reports, trend logs, and so on.In order to verify the operation of the BACnet communications, insofar as it relates to functionsabove, it may prove useful to make use of a "protocol analyzer" to observe the message flow andcontent on the network. A protocol analyzer is a computer that can intercept messages on thecommunication medium and display their contents in an easy-to-understand format. Obviouslyknowledge of the BACnet protocol is a prerequisite to interpreting the captured network traffic.BACnet protocol analyzers are available from NIST in the form of "Visual Test Shell" softwareand also from at least one commercial vendor. The analyzer software can be installed on aportable laptop computer or on a system workstation, whichever is most convenient.

With a protocol analyzer an operator can verify that alarm messages are being directed to theproper recipients; that change-of-value notifications are being correctly produced; that timesynchronizations are sent at the correct intervals; and so on. Also, if there is a particular problemthat needs to be fixed, the protocol analyzer can be set to "trigger" its data capture based on aspecific message, source device, destination device, time of day, or other defined condition.Likewise, the captured data can be filtered to eliminate messages that are not relevant toresolving the problem at hand. Experience has shown that most operational problems relate toimproper device configuration or programming. In such cases, the use of a protocol analyzer canoften pinpoint the cause of a problem within minutes.

When a project involves the expansion of an existing BACnet system, it is important to note thatthe vendor providing the new equipment may not be the same vendor that provided the operatorworkstation. It is important to have someone present during commissioning who understands thedetails of the workstation set-up and configuration.

7.4 Operation and Maintenance Phase

After commissioning and acceptance, ownership of the system is transferred from the controlsvendor(s) to the owner. There are several Operation and Maintenance (O & M) issues that mustbe addressed before this transfer occurs and as an on-going process throughout the life of thesystem that will effect future expansion and interoperability of the system.

7.4.1 Record Documentation

Before system acceptance occurs (and release of final retainage), the owner should be inpossession of a complete set of record documentation including the following:

• "As-built" record drawings - Schematic drawings that represent the final system architecture,configuration, and input/output (I/O) points.

• I/O Points List - The I/O listings should include the name/description, display units, alarmlimit(s)/definition, and BACnet object description, including Object ID and Device ID, foreach I/O point.

41

• Non-Standard BACnet Objects - Documentation for any non-standard BACnet objects,properties, or enumerations utilized detailing their structure, data types, and any associatedlists or enumerated values.

• Program records - Complete program descriptions of all control and application software perthe system installation. This should include English narratives of control/applicationprograms, flowcharts and actual source code/files.

As hardware and/or software modifications are made to the system, these records must beupdated to reflect the current operating conditions of the system. As future expansion needsarise, the owner will be able to competitively bid out the work to controls vendors and providethem with the record documentation in order to ensure that the expansion will operate with theexisting system.

7.4.2 Operator Training

Operator training becomes an integral part of BACnet interoperability when considering theexpansion of an existing BACnet system. This process begins at the design phase when trainingrequirements are specified in the Technical Specifications. The specifying engineer shouldinclude the following items in order to ensure that the operating personnel receive completesystem training and are fully capable of operating and maintaining the system.

• Minimum Training Hours - Specify the minimum number of hours required by the controlsvendor(s) for training of operator personnel. This should include on-site (hand-on) training aswell as off-site (factory) training.

• Course Content - Specify the minimum course content requirements. In addition to basicsystem training, the content should also include an overview of the BACnet protocol andsystem network. Also included in the content should be skills to enable the operator to add,delete, and/or modify I/O points and create or edit system tabular reports and graphicdisplays at the Operator Workstation (OWS).

The owner and/or a representative should attend the training sessions to ensure that these trainingrequirements are fulfilled. Such training could potentially decrease the owner's future systemexpansion costs by limiting the controls vendor(s) to only installing and commissioning fielddevices while the owner's operating personnel add and/or modify the system reports and graphicsat the OWS and map the desired newly installed I/O points as provided by the controls vendor(s).

42

Annex A. BACnet Interoperability Building Blocks (BIBBs)

BACnet Interoperability Building Blocks (BIBBs) are collections of one or more BACnetservices. These are prescribed in terms of an "A" and a "B" device. Both of these devices arenodes on a BACnet inter-network. In most cases the “A” device will act as the user of data andthe “B” device will be the provider of this data. In addition, certain BIBBs may also bepredicated on the support of certain, otherwise optional, BACnet objects or properties and mayplace constraints on the allowable values of specific properties or service parameters.

A.1 Data Sharing BIBBs

These BIBBs prescribe the BACnet capabilities required to interoperably perform the datasharing functions enumerated in 3.1 for the BACnet devices defined therein.

A.1.1 BIBB - Data Sharing-ReadProperty-A (DS-RP-A)

The A device is a user of data from device B.

BACnet Service Initiate ExecuteReadProperty x

A.1.2 BIBB - Data Sharing-ReadProperty-B (DS-RP-B)

The B device is a provider of data to device A.

BACnet Service Initiate ExecuteReadProperty x

A.1.3 BIBB - Data Sharing-ReadPropertyMultiple-A (DS-RPM-A)

The A device is a user of data from device B and requests multiple values at one time.

BACnet Service Initiate ExecuteReadPropertyMultiple x

A.1.4 BIBB - Data Sharing-ReadPropertyMultiple-B (DS-RPM-B)

The B device is a provider of data to device A and returns multiple values at one time.

BACnet Service Initiate ExecuteReadPropertyMultiple x

43

A.1.5 BIBB - Data Sharing-ReadPropertyConditional-A (DS-RPC-A)

The A device is a user of data from device B and requests that values be returned based uponspecific criteria that are contained in the message.

BACnet Service Initiate ExecuteReadPropertyConditional x

A.1.6 BIBB - Data Sharing-ReadPropertyConditional-B (DS-RPC-B) )

The B device is a provider of data to device A based, conditionally, upon the selection criteria inthe request from device A.

BACnet Service Initiate ExecuteReadPropertyConditional x

A.1.7 BIBB - Data Sharing-WriteProperty-A (DS-WP-A) )

The A device sets a value in device B.

BACnet Service Initiate ExecuteWriteProperty x

A.1.8 BIBB - Data Sharing-WriteProperty-B (DS-WP-B)

The B device allows a value to be changed by device A.

BACnet Service Initiate ExecuteWriteProperty x

A.1.9 BIBB - Data Sharing-WritePropertyMultiple-A (DS-WPM-A)

The A device sets multiple values in device B at one time.

BACnet Service Initiate ExecuteWritePropertyMultiple x

44

A.1.10 BIBB - Data Sharing-WritePropertyMultiple-B (DS-WPM-B)

The B device allows multiple values to be changed by device A at one time.

BACnet Service Initiate ExecuteWritePropertyMultiple x

A.1.11 BIBB - Data Sharing-COV-A (DS-COV-A)

The A device is a user of COV data from device B.

BACnet Service Initiate ExecuteSubscribeCOV xConfirmedCOVNotification xUnconfirmedCOVNotification x

A.1.12 BIBB - Data Sharing-COV-B (DS-COV-B)

The B device is a provider of COV data to device A.

BACnet Service Initiate ExecuteSubscribeCOV xConfirmedCOVNotification xUnconfirmedCOVNotification x

Devices claiming conformance to DS-COV-B shall support a minimum of 5 simultaneoussubscriptions.

A.1.13 BIBB - Data Sharing-COV-Unsubscribed-A (DS-COVU-A)

The A device processes unsolicited COV data from device B.

BACnet Service Initiate ExecuteUnconfirmedCOVNotification x

A.1.14 BIBB - Data Sharing-COV-Unsubscribed-B (DS-COVU-B)

The B device generates unsolicited COV notifications.

BACnet Service Initiate ExecuteUnconfirmedCOVNotification x

45

A.2 Alarm and Event Management BIBBs

These BIBBs prescribe the BACnet capabilities required to interoperably perform the alarm andevent management functions enumerated in 3.2 for the BACnet devices defined therein.

A.2.1 BIBB - Alarm and Event-Notification-A (AE-N-A)

The A device processes notifications about alarms and other events.

BACnet Service Initiate ExecuteConfirmedEventNotification xUnconfirmedEventNotification x

A.2.2 BIBB - Alarm and Event-Notification-B (AE-N-B)

Device B generates notifications about alarms and other events.

BACnet Service Initiate ExecuteConfirmedEventNotification xUnconfirmedEventNotification x

Devices claiming conformance to AE-N-B shall also support either Intrinsic or Algorithmicreporting.

A.2.3 BIBB - Alarm and Event-ACK-A (AE-ACK-A)

Device A acknowledges alarm/event notifications.

BACnet Service Initiate ExecuteAcknowledgeAlarm x

A.2.4 BIBB - Alarm and Event-ACK-B (AE-ACK-B)

Device B processes acknowledgments of previously transmitted alarm/event notifications.

BACnet Service Initiate ExecuteAcknowledgeAlarm x

In order to support this BIBB the device must also support acknowledgeable alarms.

46

A.2.5 BIBB - Alarm and Event-Summary-A (AE-ASUM-A)

Device A requests summaries of alarms from device B.

BACnet Service Initiate ExecuteGetAlarmSummary x

A.2.6 BIBB - Alarm and Event-Summary-B (AE-ASUM-B)

Device B provides summaries of alarms device A.

BACnet Service Initiate ExecuteGetAlarmSummary x

A.2.7 BIBB - Event-Summary-A (AE-ESUM-A)

Device A requests event enrollments from device B.

BACnet Service Initiate ExecuteGetEnrollmentSummary x

A.2.8 BIBB - Event-Summary-B (AE-ESUM-B) )

Device B provides event enrollments to device A.

BACnet Service Initiate ExecuteGetEnrollmentSummary x

A.3 Scheduling BIBBs

These BIBBs prescribe the BACnet capabilities required to interoperably perform the schedulingfunctions enumerated in 3.3 for the BACnet devices defined therein.

A.3.1 BIBB - Scheduling - A (SCHED-A)

The A device manipulates schedules and calendars on the B device. The A device must supportthe DS-RP-A and DS-WP-A BIBBs.

47

A.3.2 BIBB - Scheduling - B (SCHED-B)

The B device provides date and time scheduling of the values of specific properties of specificobjects. In addition to supporting the DS-RP-B and DS-WP-B BIBBs, each device claimingconformance to SCHED-B must also possess at least one Calendar, one Schedule object, andone Command object. The Command object is required for scheduling actions in other devices.

The Schedule object must support at least 6 entries per day and at least one entry in theList_of_Object_Property_Reference property. The Schedule object must support a non-emptyException_Schedule property.

The Command object must be capable of writing to objects in other devices. ThePriority_For_Writing property in the Command object must be writable.

A.4 Trending BIBBs

These BIBBs prescribe the BACnet capabilities required to interoperably perform the trendingfunctions enumerated in 3.4 for the BACnet devices defined therein.

A.4.1 BIBB – Viewing and Modifying Trends – A (T-VMT-A)

The A device displays trend data from the B device and manipulates trend log collectionparameters in the B device.

BACnet Service Initiate ExecuteReadRange x

A.4.2 BIBB – Viewing and Modifying Trends – B (T-VMT-B)

The B device collects the trend log data records in an internal buffer. Each device claimingconformance to T-VMT-B must be able to support at least one Trend Log object.

BACnet Service Initiate ExecuteReadRange x

48

A.4.3 BIBB – Trending – Automated Trend Retrieval – A (T-ATR-A)

The A device notifies the B device that a trending buffer has acquired a predetermined number ofdata samples.

BACnet Service Initiate ExecuteConfirmedEventNotification xReadRange x

Devices claiming conformance to T-ATR-A must support the Trend Log object.

A.4.4 BIBB – Trending – Automated Trend Retrieval – B (T-ATR-B)

The B device responds to a notification that a trend log is ready with new data and acquires thenew data from the log.

BACnet Service Initiate ExecuteConfirmedEventNotification xReadRange x

A.5 Device Management BIBBs

These BIBBs prescribe the BACnet capabilities required to interoperably perform the devicemanagement functions enumerated in 3.5 for the BACnet devices defined therein.

A.5.1 BIBB - Device Management - Dynamic Device Binding - A (DM-DDB-A)

The A device seeks information about device attributes of other devices and interprets deviceannouncements.

BACnet Service Initiate ExecuteWho-Is xI-Am x

49

A.5.2 BIBB - Device Management - Dynamic Device Binding - B (DM-DDB-B)

The B device provides information about it’s device attributes and responds to requests toidentify itself.

BACnet Service Initiate ExecuteWho-Is xI-Am x

A.5.3 BIBB - Device Management - Dynamic Object Binding - A (DM-DOB-A)

The A device seeks address information about objects.

BACnet Service Initiate ExecuteWho-Has xI-Have x

A.5.4 BIBB - Device Management - Dynamic Object Binding - B (DM-DOB-B) )

The B device provides address information about its objects upon request.

BACnet Service Initiate ExecuteWho-Has xI-Have x

A.5.5 BIBB - Device Management - DeviceCommunicationControl - A (DM-DCC-A)

The A device exercises communication control over the B device.

BACnet Service Initiate ExecuteDeviceCommunicationControl x

A.5.6 BIBB - Device Management - DeviceCommunicationControl - B (DM-DCC-B) )

The B device responds to communication control exercised by the A device.

BACnet Service Initiate ExecuteDeviceCommunicationControl x

50

A.5.7 BIBB - Device Management - PrivateTransfer - A (DM-PT-A) )

The A device initiates the transmission of non-BACnet data within a BACnet service request.The interpretation of the data is a local matter.

BACnet Service Initiate ExecuteConfirmedPrivateTransfer xUnconfirmedPrivateTransfer x

A.5.8 BIBB - Device Management - PrivateTransfer - B (DM-PT-B) )

The B device processes the non-BACnet data contained in the BACnet service request.

BACnet Service Initiate ExecuteConfirmedPrivateTransfer xUnconfirmedPrivateTransfer x

A.5.9 BIBB - Device Management - Text Message - A (DM-TM-A) )

The A device initiates the transmission of text messages. The interpretation and subsequentprocessing of the messages is a local matter.

BACnet Service Initiate ExecuteConfirmedTextMessage xUnconfirmedTextMessage x

A.5.10 BIBB - Device Management - Text Message - B (DM-TM-B)

The B device processes the text messages.

BACnet Service Initiate ExecuteConfirmedTextMessage xUnconfirmedTextMessage x

A.5.11 BIBB - Device Management - TimeSynchronization - A (DM-TS-A)

The A device provides time synchronization to B devices. The time parameter contained in theservice request contains the date and time as determined by the clock in the device issuing theservice request. Normally this will be "local time," i.e., the time in the local time zone correctedfor daylight savings time as appropriate.

BACnet Service Initiate ExecuteTimeSynchronization x

Devices claiming conformance to DM-TS-A must support the Time_Synchronization_Recipientsproperty of the Device object.

51

A.5.12 BIBB - Device Management - TimeSynchronization - B (DM-TS-B) )

The B device interprets time synchronization messages from the A device.

BACnet Service Initiate ExecuteTimeSynchronization x

Devices claiming conformance to DM-TS-B must support the Local_Time and Local_Dateproperties of their Device objects.

A.5.13 BIBB - Device Management - UTCTimeSynchronization - A (DM-UTC-A) )

The A device provides time synchronization to B devices. The time parameter contained in theservice request contains "Coordinated Universal Time" (UTC). For all practical purposes, UTCis synonymous with Greenwich Mean Time, the time at the zero or Greenwich meridian.

BACnet Service Initiate ExecuteUTCTimeSynchronization x

Devices claiming conformance to DM-TS-A must support the Time_Synchronization_Recipientsproperty of the Device object.

A.5.14 BIBB - Device Management - UTCTimeSynchronization - B (DM-UTC-B) )

The B device interprets time synchronization messages from the A device.

BACnet Service Initiate ExecuteUTCTimeSynchronization x

Devices claiming conformance to DM-TS-B must support the Local_Time, Local_Date,UTC_Offset, and Daylight_Savings_Status properties of the Device object.

A.5.15 BIBB - Device Management - ReinitializeDevice - A (DM-RD-A) )

The A device is authorized to reinitialize the B device.

BACnet Service Initiate ExecuteReinitializeDevice x

Devices claiming conformance to DM-RD-A shall be able to initiate ReinitializeDevice requestscontaining the Password parameter. This shall be both for warm and cold start.

52

A.5.16 BIBB - Device Management - ReinitializeDevice - B (DM-RD-B)

The B device performs reinitialization requests from the A device. The optional password fieldshall be supported.

BACnet Service Initiate ExecuteReinitializeDevice x

A.5.17 BIBB - Device Management - Backup and Restore - A (DM-BR-A)

The A device uploads a file which contains the configuration of the B device and downloads thatfile to the B device should it need to be restored to its previously backed-up state.

BACnet Service Initiate ExecuteAtomicReadFile xAtomicWriteFile x

Devices claiming conformance to DM-BR-A must write the value TRUE to the Archive propertyof the File object which represents the configuration file in the B device following a backupoperation. Configuration file uploads and downloads shall be performed using stream-orientedfile access.

A.5.18 BIBB - Device Management - Backup and Restore - B (DM-BR-B) )

The B device provides its configuration file to the A device and allows the A device to downloadthis file to recover its configuration in the event of a failure.

BACnet Service Initiate ExecuteAtomicReadFile xAtomicWriteFile x

In devices claiming conformance to DM-BR-B, the Read_Only property of File objects whichrepresent configuration files shall contain the value FALSE, the File_Type property shall containthe value CONFIGURATION, and the File_Size property shall be writable. Configuration fileuploads and downloads shall be performed using stream-oriented file access.

A.5.19 BIBB - Device Management - List Manipulation - A (DM-LM-A)

Many BACnet object types have properties that are lists of a particular datatype. The A devicecan add and remove list elements in properties of objects in the B device.

BACnet Service Initiate ExecuteAddListElement xRemoveListElement x

53

A.5.20 BIBB - Device Management - List Manipulation - B (DM-LM-B)

The B device responds to requests to add or remove list elements.

BACnet Service Initiate ExecuteAddListElement xRemoveListElement x

A.5.21 BIBB - Device Management - Object Creation and Deletion - A (DM-OCD-A)

BACnet allows object instances to be dynamically created and deleted. The A device maydynamically create and delete the object types supported by the B device.

BACnet Service Initiate ExecuteCreateObject xDeleteObject x

A.5.22 BIBB - Device Management - Object Creation and Deletion - B (DM-OCD-B)

The B device creates and deletes object instances based on requests from the A device. Theobject types whose dynamic creation and deletion is supported shall be enumerated in the Bdevice's PICS.

BACnet Service Initiate ExecuteCreateObject xDeleteObject x

A.6 Network Management BIBBs

These BIBBs prescribe the BACnet capabilities required to interoperably perform the networkmanagement functions enumerated in 3.5 for the BACnet devices defined therein.

A.6.1 BIBB - Network Management - Connection Establishment - A (NM-CE-A)

The A device commands a half-router to establish and terminate connections as needed forcommunication with other devices.

BACnet Network Layer Message Initiate ExecuteEstablish-Connection-To-Network xDisconnect-Connection-To-Network x

54

A.6.2 BIBB - Network Management - Connection Establishment - B (NM-CE-B)

The B device executes commands to establish and terminate connections as needed.

BACnet Network Layer Message Initiate ExecuteEstablish-Connection-To-Network xDisconnect-Connection-To-Network x

A.6.3 BIBB - Network Management - Router Configuration - A (NM-RC-A)

The A device may query and change the configuration of routers and half-routers. Note that thecapabilities of routers and half-routers are defined in BACnet Clause 6. Thus no explicit BIBBsare required.

BACnet Network Layer Message Initiate ExecuteWho-Is-Router-To-Network xI-Am-Router-To-Network xI-Could-Be-Router-To-Network xInitialize-Routing-Table xInitialize-Routing-Table-Ack x

A.7 Virtual Terminal BIBBs

Virtual terminal services permit "remote console" access of field devices from across a BACnetLAN. The effect is to enable access to proprietary configuration and diagnostic routines from aworkstation as if the workstation were directly connected to the field device in the mechanicalroom.

A.7.1 BIBB - Virtual Terminal - A (VT-A)

The A device initiates a virtual terminal session and exchanges data with the B device.

BACnet Service Initiate ExecuteVT-Open xVT-Close x xVT-Data x x

55

A.7.2 BIBB - Virtual Terminal - B (VT-B) )

The B devices permits the establishment of a virtual terminal session and exchanges data withthe A device.

BACnet Service Initiate ExecuteVT-Open xVT-Close x xVT-Data x x

56

Annex B. Descriptions and Profiles of Standardized BACnet Devices

This clause provides descriptions of five "standardized" types of BACnet devices. Any devicethat implements all the required BACnet capabilities for a particular device type andinteroperability area may claim to be a device of that particular type. Devices may also provideadditional capabilities and shall indicate these capabilities in their PICS. The devices definedherein are: BACnet Operator Workstation, BACnet Building Controller, BACnet AdvancedApplication Controller, BACnet Application Specific Controller, BACnet Smart Actuator, andBACnet Smart Sensor.

B.1 BACnet Operator Workstation (B-OWS)

The B-OWS is the operator's window into a BACnet system. While it is primarily used for theoperation of a system, it may be used for configuration activities that are beyond the scope of thisstandard. It is not intended to perform direct digital control. It enables the specification of thefollowing:

Data Sharing• Archival storage of data• Presentation of data (i.e., reports and graphics)• The ability to monitor the value of all BACnet object types, including all required and

optional properties• The ability to modify setpoints and parameters

Alarm and Event Management• Operator notification and presentation of event information• Alarm acknowledgment by operators• Alarm summarization• Adjustment of alarm limits• Adjustment of alarm routing

Scheduling

• Modification of schedules• Display of the start and stop times (schedule) of scheduled devices

Trending• Modification of the parameters of a trend log• Display and archive of trend data

57

Device and Network Management• Display of information about the status of any device on the BACnet inter-network• Display of information about any object in the BACnet inter-network• Ability to silence a device on the network that is transmitting erroneous data• Ability to synchronize the time in devices across the BACnet inter-network• Ability to cause a remote device to reinitialize itself• Ability to backup and restore the configuration of other devices• Ability to command half-routers to establish and terminate connections• Ability to query and change the configuration of half-routers and routers

B.2 BACnet Building Controller (B-BC)

A B-BC is a general purpose, field programmable device capable of carrying out a variety ofbuilding automation and control tasks. It enables the specification of the following:

Data Sharing• Ability to provide the values of any of its BACnet objects• Ability to retrieve the values of BACnet objects from other devices• Ability to allow modification of some or all of its BACnet objects by another device

Alarm and Event Management• Generation of alarm / event notifications and the ability to direct them to recipients• Maintain a list of unacknowledged alarms / events• Notifying other recipients that the acknowledgment has been received• Adjustment of alarm / event parameters

Scheduling• Ability to schedule output actions, both in the local device and in other devices, both binary

and analog, based on date and time

Trending• Collection and delivery of (time, value) pairs.

Device and Network Management• Ability to respond to information about its status• Ability to respond to requests for information about any of its objects• Ability to respond to communication control messages• Ability to synchronize its internal clock upon request• Ability to perform re-initialization upon request• Ability to upload its configuration and allow it to be subsequently restored• Ability to command half-routers to establish and terminate connections

58

B.3 BACnet Advanced Application Controller (B-AAC)

A B-AAC is a control device with limited resources relative to a B-BC. It may be intended forspecific applications and supports some degree of programmability.

Data Sharing:• Ability to provide values for any of its BACnet objects upon request• Ability to allow modification of some or all of its BACnet objects by another BACnet device

Alarm and Event Management• Generation of limited alarm and event notifications and the ability to direct them to recipients• Tracking acknowledgements of alarms from human operators• Adjustment of alarm parameters

Scheduling• Ability to schedule actions in the local device based on date and time

Trending• No requirement

Device and Network Management• Ability to respond to queries about its status• Ability to respond to requests for information about any of its objects• Ability to respond to communication control messages• Ability to synchronize its internal clock upon request• Ability to perform re-initialization upon request

B.4 BACnet Application Specific Controller (B-ASC)

A B-ASC is a controller with limited resources relative to a B-AAC. It is intended for use in aspecific application and supports limited programmability. It enables specification of thefollowing:

Data Sharing• Ability to provide the values of any of its BACnet objects• Ability to allow modification of some or all of its BACnet objects by another device

Alarm and Event Management• None

Scheduling• None

Trending• None

59

Device and Network Management• Ability to respond to information about its status

B.5 BACnet Smart Actuator (B-SA)

A B-SA is a simple control device with limited resources, intended for specific applications.

Data Sharing:• Ability to provide values for any of its BACnet objects upon request• Ability to allow modification of some or all of its BACnet objects by another device

Alarm and Event Management• No requirement

Scheduling• No requirement


Device and Network Management• No requirement

B.6 BACnet Smart Sensor (B-SS)

An SS is a simple sensing device with very limited resources.

Data Sharing:• Ability to provide values for any of its BACnet objects upon request

Alarm and Event Management• No requirement

Scheduling• No requirement


Device and Network Management• No requirement

60

B.7 BACnet Gateway (B-GW)

A B-GW is a device that provides bi-directional translation of data and information betweenBACnet devices and devices that communicate using a non-BACnet communication protocol. Itenables specification of the following:

Data Sharing:• Ability to provide values for any point on the non-BACnet side of the gateway to BACnet

devices as if the values were originating from BACnet objects• Ability to allow BACnet devices to modify some or all of the point values on the non-BACnet

side of the gateway by using standard BACnet write services

Alarm and Event Management• Generation of alarm / event notifications and the ability to direct them to recipients• Maintenance of a list of unacknowledged alarms / events• Notification of other recipients that an acknowledgment has been received• Adjustment of alarm / event parameters

Scheduling• Ability to schedule output actions, both in the local device and in other devices, both binary

and analog, based on date and time

Trending• Collection and delivery of (time, value) pairs

Device and Network Management• Ability to respond to information about its status• Ability to respond to requests for information about any of its objects• Ability to respond to communication control messages• Ability to synchronize its internal clock upon request• Ability to perform re-initialization upon request

61

B.8 Profiles of the Standard BACnet Devices

The following tables indicate which BIBBs must be supported by each device type for eachinteroperability area.

B-OWS B-BC B-AAC B-ASC B-SA B-SS B-GWData Sharing DS-RP-A,B DS-RP-A,B DS-RP-B DS-RP-B DS-RP-B DS-RP-B DS-RP-B

DS-RPM-A DS-RPM-A,B DS-RPM-B DS-WP-B DS-WP-B DS-RPM-BDS-WP-A DS-WP-A,B DS-WP-B DS-WP-B

DS-WPM-A DS-WPM-B DS-WPM-B DS-WPM-BDS-COVU-A,B

B-OWS B-BC B-AAC B-ASC B-SA B-SS B-GWAlarm & Event AE-N-A AE-N-B AE-N-B AE-N-B

Mgmt AE-ACK-A AE-ACK-B AE-ACK-B AE-ACK-BAE-ASUM-A A-ASUM-B AE-ASUM-B A-ASUM-BAE-ESUM-A AE-ESUM-B AE-ESUM-B

B-OWS B-BC B-AAC B-ASC B-SA B-SS B-GWScheduling SCHED-A SCHED-B SCHED-B SCHED-B

B-OWS B-BC B-AAC B-ASC B-SA B-SS B-GWTrending T-VMT-A * T-VMT-B * T-VMT-B*

T-ATR-A* T-ATR-B* T-ATR-B*

B-OWS B-BC B-AAC B-ASC B-SA B-SS B-GWDevice & DM-DDB-A,B DM-DDB-A,B DM-DDB-B DM-DDB-B DM-DDB-B

Network Mgmt DM-DOB-A,B DM-DOB-A,B DM-DOB-B DM-DOB-B DM-DOB-BDM-DCC-A DM-DCC-B DM-DCC-B DM-DCC-B DM-DCC-BDM-TS-A DM-TS-B

orDM-UTC-B*

DM-TS-Bor

DM-UTC-B*

DM-TS-Bor

DM-UTC-B*

DM-UTC-A*

DM-RD-A DM-RD-B DM-RD-B DM-RD-BDM-BR-A DM-BR-BNM-CE-A NM-CE-A

* At the time of publication of this guide the BACnet services required to implement these BIBBs have notcompleted the public review process for becoming part of the BACnet standard.

62

Annex C. GSA BACnet Implementation ChecklistThe purpose of this Annex is to provide a simple checklist to ensure that the most importantelements of a successful BACnet building automation and control system have been consideredand specified as needed.

General

¨ Have the functional requirements of the job, including all sequences of operation, beenthoroughly specified?

¨ Have all the desired workstation capabilities, features, and characteristics been specifiedincluding:

¨ Graphics¨ Tabular reports¨ Trend logs¨ Operator tools¨ Security levels and privileges

¨ Have the desired local or wide area network technologies been specified? If communicationvia an IP internet is required, has the use of BACnet Tunneling Routers or BACnet/IP beenspecified?

¨ Has BACnet been specified for all levels of the control system hierarchy using devicesconforming to the profiles in Annex B?

Data Sharing (3.1)

Point list

¨ Have point lists been compiled showing each sensor, actuator, setpoint, and other parametersthat are to be accessible over the network?

Presentation of data

¨ Has the format and desired content of each tabular report been specified?

¨ Have the desired graphic displays been defined along with the maximum allowable updateinterval?

¨ Has it been specified that all points in the system must be available for real-time plotting atuser-definable update intervals and that multiple analog and binary values may be plotted onthe same axes?

63

Monitoring of any property of any BACnet object type

¨ Has it been specified that it must be possible to read and display the value of any property ofany object in the system?

Global objects

¨ Have all shared global data points been specified?

Setpoint and parameter modification

¨ Has it been specified which operating setpoints and parameters must be available formodification via BACnet services (as opposed to proprietary vendor-specific means)?

¨ Have the desired means of making the modifications, e.g., via a graphical user interface(GUI), been specified?

Peer-to-Peer data exchange

¨ Have any required data dependencies (interlocks, shared setpoints, schedules, and so on) thatmust be implemented via the network been defined?

Alarm and Event Management (3.2)

Alarm lists, operator notification and presentation of event information

¨ Have all desired alarms, including alarm limits, interlocks to avoid "nuisance" alarms, anddesired response time from the occurrence of an event until a notification is provided beenspecified?

¨ Has it been specified how alarms are to be categorized and distributed, i.e., which alarms gowhere and when?

¨ Has it been specified how alarms are to appear at the operator workstation?

¨ Has it been specified that "intrinsic reporting" shall be used when it is sufficient to meet thefunctional requirements?

Alarm acknowledgment

¨ Has it been specified that alarm acknowledgment capability be provided and that a log bemaintained that records when an alarm notification was received, when it was acknowledged,and by whom?

64

Alarm summarization

¨ Has it been specified that it shall be possible for an operator to receive, at any time, asummary of all alarms that are currently in effect and whether or not they have beenacknowledged?

¨ Has it been specified that is shall be possible to receive a summary of all alarms regardless ofacknowledgment status; for which a particular recipient is enrolled for notification; based oncurrent event state; based on the particular BACnet event algorithm (e.g., change of value,change of state, out of range, and so on); alarm priority; and notification class?

Alarm parameter adjustment

¨ Has it been specified that operators shall be provided the capability to dynamically modifythe alarm parameters for all standard BACnet event types?

Alarm routing adjustment

¨ Has it been specified that operators shall have the ability to change alarm routing for eachalarm including the destination for each type of alarm and alarm priority, the day of weekand time of day, and the type of transition involved (TO-OFFNORMAL, TO-NORMAL andso on)?

Scheduling (3.3)

Schedule list

¨ Has each action that should take place based on the date and time of day been specified?

Display of start and stop times of scheduled devices

¨ Has it been specified that an operator shall be able to inspect the content of any schedule anddetermine the specific control actions that will occur at any time, on any date? Additionally,for any particular device or system parameter that is the subject of a schedule, has it beenspecified that an operator shall be able to determine the schedule of actions related to thatdevice or parameter?

Modification of schedules

¨ Has it been specified that certain, or all, calendar entries and schedules shall be modifiablefrom an operator workstation?

Trending (3.4)

Archival storage of data

¨ Has the maximum number of data points for which archival storage is needed, along with theminimum sampling interval been specified?

65

¨ Has the duration of time for which the archived information must be available for on-lineretrieval been specified?

¨ Has the means for archiving older data, e.g., tape or CD-R, been specified?

Trend list

¨ Have the initial requirements for trending in terms of which data points are to be trended, thesampling rate, the duration of each trend log, and the length of time it is desired to keep theresulting logs available on-line been specified? Alternatively, have the approximate numberof desired trend logs been specified?

Display and archive of trend data

¨ Has it been specified that an operator will be able to retrieve and display trend logs, accessthe underlying numerical data in spreadsheet format, and output the data to printers or otherfiles?

Modification of trend log parameters

¨ Has it been specified that the data points to be logged, the sampling rate, and duration oftrend logs shall be modifiable by an authorized operator from a system workstation?

Device and Network Management (3.5)

Display of information about device status

¨ Has it been specified that an operator shall be able to display at any time the operationalstatus of any device on the BACnet internetwork?

Display of information about any BACnet object

¨ Has it been specified that an operator shall be able to display at any time any property of anyBACnet object?

¨ Has it been specified that an operator shall also be able to display property values of objectsgrouped by object type, object location, and building system?

Ability to silence a device on the network that is transmitting erroneous data

¨ Has it been specified that an operator shall be able to direct a field device to stop transmittingevent or alarm notifications until a subsequent command to resume transmissions isreceived?

66

Ability to synchronize the time in devices across the BACnet inter-network

¨ Has it been specified that an operator shall be able to set the time and date in any device onthe network that supports time-of-day functionality? This capability should be required forboth individual devices or groups of devices, including all devices simultaneously.

Ability to cause a remote device to reinitialize itself

¨ Has it been specified that an operator shall have the ability to issue reinitialization commandsto any device that supports remote reinitialization?

Ability to backup and restore the configuration of other devices

¨ Has it been specified that an operator shall have the ability to backup and restore all BACnetdevices on the network that support this capability?

Ability to command half-routers to establish and terminate connections

¨ Has it been specified that an operator shall have the ability to issue a command for theestablishment or termination of a connection to a remote BACnet network?

Ability to query and change the configuration of half-routers and routers

¨ Has it been specified that an operator shall have the ability to display and modify the routingtable entries in all provided BACnet half-routers and routers?

Use of BACnet Objects (4)

Naming Conventions (4.1)

¨ Has a set of abbreviations for common building systems, subsystems, and points that are tobe used by all vendors been specified?

¨ Has it been specified that object name properties, in those devices where the object name isconfigurable, shall be at least 50 characters long and shall, to the extent possible make use ofa system and point nomenclature using the abbreviations specified above?

¨ Has it been specified that BACnet object names used in workstations may be up to 50characters long and shall consist of a string made up of components indicating, asappropriate, the location, system, subsystem, and point of the object? Also, that these objectnames shall be used in workstation applications such as graphics, reports, and alarmswherever an object name is appropriate in lieu of the object name property in the remotedevice? Also, that an operator may display at any time the mapping between the object nameused on the workstation and the object name property used in the remote BACnet device?

67

Commissioning/Diagnostic Mode (4.2)

¨ Has it been specified that the Out_Of_Service property shall be adjustable (writable) usingBACnet services for all Analog, Binary, Multi-state, Loop and Program objects?

Using Object Descriptions (4.3)

¨ Has it been specified that each Device object shall have a Description property and that thelength available for the Description properties of other implemented object types shall beprovided in the "Property Range Restrictions" portion of the device's PICS?

Issues Related to Specific BACnet Object Types (4.4)

Analog Input, Output, and Value (4.4.1)

¨ Has it been specified that all analog objects (Input, Output, and Value) shall have thecapability of using the Change of Value reporting mechanism and that the COV_Incrementproperty shall be writable using BACnet services?

Binary Input (4.4.2)

¨ Has it been specified, for each Binary Input object, the text to be used for the Inactive_Textand Active_Text properties?

Binary Output (4.4.3)

¨ Has it been specified, for each Binary Input object, the text to be used for the Inactive_Textand Active_Text properties? In addition, if appropriate for the application, have appropriatevalues for the Feedback_Value, Minimum_On_Time, and Minimum_Off_Time propertiesbeen specified?

¨ Has support for the Change_Of_State_Time, Change_Of_State_Count, andTime_Of_State_Count_Reset been specified if counting state changes is appropriate for theapplication? If so, has it also been specified that Change_Of_State_Count be writable so thatthe count can be reset?

¨ Has support for the Elapsed_Active_Time and Time_Of_Active_Time_Reset properties beenspecified if accumulating run time is appropriate for the application? If so, has it also beenspecified that Elapsed_Active_Time be writable so that the run time can be reset?

Binary Value (4.4.4)

¨ Has it been specified, for each Binary Value object, the text to be used for the Inactive_Textand Active_Text properties? In addition, if appropriate for the application, have appropriatevalues for the Minimum_On_Time, and Minimum_Off_Time properties been specified?

68

¨ Has support for the Change_Of_State_Time, Change_Of_State_Count, andTime_Of_State_Count_Reset been specified if counting state changes is appropriate for theapplication? If so, has it also been specified that Change_Of_State_Count be writable so thatthe count can be reset?

¨ Has support for the Elapsed_Active_Time and Time_Of_Active_Time_Reset properties beenspecified if accumulating run time is appropriate for the application? If so, has it also beenspecified that Elapsed_Active_Time be writable so that the run time can be reset?

Calendar (4.4.5)

¨ Has it been specified that devices that provide scheduling capability shall also provide atleast one Calendar object with a capacity of at least 10 entries and that it shall be possible toview the Calendar object and make modifications from any BACnet workstation on thenetwork?

¨ Has it been specified, if the Calendar's Date_List property is writable using BACnet services,that all calendar entry datatypes must be supported?

Loop (4.4.6)

¨ Has it been specified that the desired PID control loops shall be represented by Loop objectsand that the tuning constant properties shall be writable? Has writability of other Loopproperties been specified as appropriate to the application?

¨ Has it been specified that all Loop objects shall have the capability of using the Change ofValue reporting mechanism and that the COV_Increment property shall be writable usingBACnet services?

Multi-state Input, Output, and Value (4.4.7)

¨ Has it been specified, for each Multi-state Input, Output, and Value object, the text to be usedfor each state that the object can represent? In addition, if appropriate for the application, hasit also been specified how the Feedback_Value is to be determined?

¨ Has it been specified that all Multi-state Input, Output, and Value objects shall have thecapability of using the Change of Value reporting mechanism and that the COV_Incrementproperty shall be writable using BACnet services?

Schedule (4.4.8)

¨ Has each building system that is to be subjected to date and time scheduling been specifiedand that it shall be possible to modify schedule entries from a BACnet workstation?

Dynamic Object Creation (4.5)

¨ Has it been specified, if required by the application, that it shall be possible to dynamicallycreate instances of the Averaging, Calendar, Event Enrollment, Group, Notification Class,Schedule, and Trend Log objects?

69

Use of BACnet Services (5)

Interoperable Commands (5.1)¨ Have the processes that are to be prioritized and the command priority levels assigned to

each if they do not fall into the pre-assigned levels shown in Table 1 been specified? Foreach point subject to the command priority scheme, has a default status, position, or value forthe point to take on in the absence of a prioritized command been specified?

Assigning Alarm Priorities (5.2.1)

¨ Have the priority values to be assigned for each alarm in the system been specified? For eachpriority value, or range of values, have the actions to be taken upon receipt been specified?

Setting up Notification Classes (5.2.2)

¨ Has it been specified how alarms should be distributed by specifying the recipients of eachtype and priority of alarm? If desired, have the valid days of the week and times of the dayfor each been specified?

Event Notification Message Texts (5.2.3)_

¨ Have the content and format of the alarm messages that will be delivered to operators beenspecified?

Assigning Levels of Authority to Certain Operators (5.3)

¨ Has it been specified, if desired, the number of authorization levels and the operator accountsto be assigned to each? If password protection for remote device management services isneeded, have the passwords to be configured been specified? Alternatively, has it beenspecified that there shall be a method provided for dynamically assigning passwords forremote device management functions after installation?

Subscribed COV Notifications (5.4.1)

¨ Has it been specified that workstation software shall be provided that has the capability ofsubscribing to COV notifications for all object types that support it?

Unsubscribed COV Notifications (5.4.2)

¨ Has it been specified that changes of value of globally shared data shall be distributed bymeans of UnconfirmedCOVNotifications?

Time Synchronization (5.5)

¨ Has it been specified that a time master shall be provided along with the format of the timesynchronization messages, either local time or UTC?

70

Specifying System/Network Architecture (6)

System Architectures (6.1)

¨ Has it been specified that BACnet shall be used throughout the building automation andcontrol internetwork at all levels, i.e., that the system shall be "native" BACnet?

¨ Has it been specified that the internetwork shall be configured such that, if three or morenetworks are involved with different performance characteristics, the faster networks shall beused to interconnect the slower ones?

Local Area Network Selection (6.2)

ISO 8802-3, Ethernet (6.2.1)

¨ Has it been specified which devices in the control system should reside on the EthernetLAN?

¨ Has the transmission medium option that is to be used been specified? If more than one willbe used, has it been specified which one is to be used where, and the devices that are to beconnected? If hubs will be needed, have the number of ports and the kind of medium for eachport been specified?

¨ Has the Ethernet speed (10 Mbps or 100 Mbps) been specified?

ANSI/ATA 878.1, ARCNET (6.2.2)

¨ Has it been specified which devices in the control system should reside on the ARCNETLAN?

¨ Has the transmission medium option that is to be used been specified? If more than one willbe used, has it been specified which one is to be used where and the devices that are to beconnected? If hubs will be needed, have the number of ports and the kind of medium for eachport been specified?

¨ Has it been specified how ARCNET addresses are to be assigned?

Master-Slave/Token-Passing, MS/TP (6.2.3)

¨ Has it been specified which devices in the control system should reside on the MS/TP LAN?

¨ Has the baud rate to be used been specified?

¨ Has it been specified how MS/TP addresses are to be assigned and, if slave devices will beused, how the address space is to be divided between slaves and masters?

71

EIA-709.1, LonTalk (6.2.4)

¨ Has it been specified which devices in the control system should reside on the LonTalkLAN?

¨ Have the media, speed and topology to be used been specified?

¨ Has it been specified how LonTalk addresses are to be assigned?

Point-to-Point, PTP (6.2.5)

¨ Has it been specified that PTP shall be used as the means to attach to a BACnet LAN via adial-up connection and that the optional password protection shall be provided?

Specifying MAC Addresses in a Consistent Manner (6.3)

¨ Has the GSA, the design engineer, or the system integrator determined how MAC addressesare to be assigned for each network in the proposed BACnet internetwork using therecommendations in 6.3?

Network Numbering Conventions (6.4)

¨ Has the GSA, the design engineer, or the system integrator determined how network numbersare to be assigned for each network in the proposed BACnet internetwork using therecommendations in 6.4?

Device Object Identifier Conventions (6.5)

¨ Has the GSA, the design engineer, or the system integrator determined how device objectidentifiers are to be assigned for each device in the proposed BACnet internetwork using therecommendations in 6.5?

Use of BACnet with the Internet Protocols (6.6)

¨ Has it been specified, if existing BACnet non-IP devices are to be interconnected via an IPnetwork, that BACnet Tunneling Routers conforming to Annex H shall be provided?

¨ Has it been specified, for new networks which need IP connectivity, that devices shall beprovided that conform to Addendum 135a, BACnet/IP and that, for broadcast distribution,BBMDs shall be provided or appropriate arrangements made for the use of IP multicasting?

Routers - Interconnecting Multiple BACnet Networks (6.7)

¨ Has it been specified that it shall be the contractor's responsibility to configure each routerusing the network numbering scheme agreed to for the project?

¨ Has it been specified that each router shall be configured such that all network layer errormessages shall be directed to a specific workstation using the BACnet

72

ConfirmedTextMessage service? Has the GSA, the design engineer, or the system integratordetermined which workstation that shall be?

¨ Has it been specified that it shall be the contractor's responsibility to initially configure eachrouter with routing tables containing all network numbers that are part of the project'sinternet?

¨ Has it been specified that the router shall be able to receive messages at each port of anylength that is valid for the LAN technology connected to that port, and to forward themessage to any directly-connected network that can convey a message of that size?

Message Segmentation (6.8)

¨ Has it been specified that all BACnet devices shall support the reception of messages up tothe largest size permitted by the LAN technology or support reception of segmentedmessages?

¨ Has it been specified that all BACnet devices shall support the transmission of messages upto the largest size permitted by the LAN technology or support transmission of segmentedmessages?

¨ Has it been specified that all workstations shall support both segmented messagetransmission and segmented message reception?

¨ Has it been specified that all BACnet Building Controllers (see B.2) shall support bothsegmented message transmission and segmented message reception?

Gateways - Connecting to Legacy Systems (6.9)

¨ Has it been specified that the operator workstation shall display information from both theBACnet and non-BACnet devices? If appropriate, has it been specified which other devicesshould also be able to communicate through the gateway?

¨ Has it been specified which way information must flow through the gateway or that thegateway should provide bi-directional communication?

¨ Has it been specified which non-BACnet points are to be readable from the BACnet side ofthe gateway and which BACnet objects are to be readable from the non-BACnet side of thegateway?

¨ Has it been specified which non-BACnet points are to be modifiable from the BACnet sideof the gateway and which BACnet objects are to be modifiable from the non-BACnet side ofthe gateway?

¨ Has it been specified how much expansion capacity is required in the gateway?

¨ Has it been specified how controller program and configuration database archives are to becreated and maintained?

73

¨ Have any gateway features that will be needed to support collection of trend data beenspecified?

¨ Have any gateway features that will be needed to support scheduling been specified?

¨ Have any gateway features that will be needed to support alarm and event handling beenspecified?

Practical Considerations in the Construction of BACnet Systems (7)

Procurement Phase (7.1)

If an RFP is to used, does it require the prospective controls vendor to provide a description ofthe proposed system containing:

¨ Narrative providing an overview of the BAS system, primary components, workstation(s),and LAN architecture?

¨ Identification of any clarifications or exceptions to the project specifications?

¨ A listing and quantification of all microprocessor-based BAS equipment to be supplied andassociated information “cut-sheets” for each?

¨ A listing of references, as appropriate, for projects of a similar nature to the proposed BAS?

¨ The option of requesting a formal BAS demonstration at either the vendor’s local offices orcustomer location?

Construction Phase (7.2)

PICS (7.2.1)

Has a PICS been provided containing at least:

¨ BACnet Standard Application Services Supported?

¨ Standard Object Types Supported?

¨ Data Link Layer Options?

¨ Special Functionality?

¨ Property Range Restrictions?

74

Points Lists (7.2.2)

Have Points Lists been provided containing at least:

¨ Hardware I/O information?

¨ Proposed I/O Names?

¨ BACnet Object Description?

Record Documentation (7.4.1)

Before system acceptance, does the GSA have in its possession:

¨ "As-built" record drawings?

¨ I/O Points Lists?

¨ Documentation for any non-standard BACnet objects, properties, or enumerations?

¨ Complete program descriptions of all control and application software per the systeminstallation including English narratives of control/application programs, flowcharts andactual source code/files?

Operator Training (7.4.2)

¨ Have the minimum number of training hours and course content been specified?

Documents

NISTIR 6392 GSA Guide to Specifying Interoperable … · NISTIR 6392 GSA Guide to Specifying Interoperable Building Automation and Control Systems Using ANSI/ASHRAE Standard 135-1995,