BACnet Application Guide for Consulting Engineers

(1)

BACnet Application Guide

for Consulting Engineers

(2)

(3)

BACnet

®

Application Guide for Consulting Engineers

(4)

for any errors that may appear in this document.

All software described in this document is furnished under a license and may be used or copied only in accordance with the terms of such license.

WARNING

This equipment generates, uses, and can radiate radio frequency energy and if not installed and used in accordance with the instructions manual, may cause interference to radio communications. It has been tested and found to comply with the limits for a Class A digital device, pursuant to Part 15 of the FCC rules. These limits are designed to provide reasonable protection against such interference when operated in a commercial environment. Operation of this equipment in a residential area is likely to cause interference in which case users at their own expense will be required to take whatever measures may be required to correct the interference.

SERVICE STATEMENT

Control devices are combined to make a system. Each control device is mechanical in nature and all mechanical components must be regularly serviced to optimize their operation. All Siemens Building Technologies, Inc.branch offices and authorized distributors offer Technical Support Programs that will ensure your continuous, trouble-free system performance.

TO THE READER

Your feedback is important to us. If you have comments about this manual, please submit them to: [email protected]

APOGEE is a registered trademark of Siemens Building Technologies, Inc. Tracer Summit is a trademark of The Trane Company

BACnet is a registered trademark of American Society of Heating, Refrigeration and Air Conditioning Engineers (ASHRAE)

Insight for Minicomputers is a registered trademark of Siemens Building Technologies, Inc. Insight for Personal Computers is a registered trademark of Siemens Building Technologies, Inc.

(5)

About this Application Guide

This section discusses the following topics:  Purpose of this guide.

 How this guide is organized.

 Suggested reference materials and Web sites.

It also provides information on symbols used, how to access help, and where to direct comments about this guide.

Purpose of this Guide

This application guide discusses the Building Automation and Control networks (BACnet®) standard data communication protocol and gives details about the implementation of the Insight BACnet Option and the APOGEE BACnet Field Panels. This guide is intended to supplement all of the other APOGEE BACnet system documentation (online help, Getting Started, User Guides, etc.) by providing information not contained in those documents. It is assumed that the reader is technically capable of understanding the concepts of building automation and database management. It also assumes that they are familiar with APOGEE concepts and understand its operations.

This application guide should help Branch and customer personnel understand how BACnet has been implemented in the APOGEE Building Automation System.

How this Guide is Organized

This application guide contains the following chapters:

 Chapter 1, Introduction to BACnet, describes BACnet in general terms and how it relates to the APOGEE Building Automation System.

 Chapter 2, BACnet Objects and Services, describes BACnet Objects and Services theory, and how the Insight application and the BACnet Browser are used to access objects and their properties.

 Chapter 3,BACnet Interoperability, describes the ability of APOGEE BACnet devices to integrate with BACnet products made by different manufacturers into a single system.

 Chapter 4,BACnet Communications, describes BACnet communication theory in relation to the Insight application.

 Chapter 5,BACnet Field Panel, describes the features and functions of the APOGEE BACnet field panel as well as the firmware used to operate it.

(14)

 Chapter 6,Insight BACnet Option, describes the Insight BACnet Option and the changes to the Insight application since Revision 3.2

 Chapter 7,BACnet Scheduling, describes BACnet scheduling theory as it relates to scheduling in the APOGEE Building Automation System.

 Chapter 8,BACnet Alarming, describes BACnet alarming theory, how it relates to the APOGEE Building Automation System, and how to set up alarming in an APOGEE Building Automation System.

 Chapter 9,BACnet Trending, describes BACnet trending theory and trending in an APOGEE Building Automation System.

 Chapter 10,BACnet Tools, describes tools for analyzing BACnet communications in an APOGEE Building Automation System.

 The Glossary describes various terms and acronyms used in this application guide.  The Index helps you locate information presented in this guide.

Suggested Reference Materials

In addition to this application guide, you may also want to become familiar with the following reference materials:

 ANSI/ASHRAE Standard 135-2004 available at: www.ashrae.org.  BACnet Web site: www.BACnet.org

 BACnet International (BI) Web site: www.bacnetinternational.org

 See the Glossary for other references.

Symbols

The following table lists the symbols used in this guide to draw your attention to important information.

Notation Symbol Meaning

CAUTION: Indicates that equipment damage, or loss of data may occur if the user does not follow a procedure as specified.

Note Provides additional information or helpful hints that need to be brought to the reader's attention.

Tip Suggests alternative methods or shortcuts that may not be obvious, but can help the user better understand the capabilities of the product.

(15)

Table of Contents

Getting Help

For more information about regulated facilities, contact your local Siemens representative.

Where to Send Comments

Your feedback is important to us. If you have comments about this guide, please submit them to: [email protected]

(16)

(17)

Chapter 1–Introduction to BACnet

Chapter 1 describes BACnet in general terms and how it relates to the APOGEE Building Automation System. It includes the following topics:

 What is BACnet?

 Why BACnet was Developed  How BACnet was Developed  Certification

 BACnet Implementation within the APOGEE Automation System

What is BACnet?

BACnet is an acronym for Building Automation and Control networks. It is the name for an ASHRAE and ANSI standard data communication protocol, which is a set of rules governing the exchange of data over a computer network. The rules govern hardware (for example, cable types, system topology) and software (for example, formation of request or command messages). The rules are in a published specification (ANSI/ASHRAE Standard 135-2004) that defines what is required to conform to the protocol.

Figure 1. The BACnet Logo.

The BACnet specification also defines the BACnet components: the object and services model, the network layer protocol, and a selection of various network transport technologies. (See Table 1.) As a result, the BACnet specification can govern the design of workstations, controllers, gateways, routers, and diagnostic tools.

Table 1. Components of BACnet.

BACnet Components Description

Objects Methods of Representing Information

Services Methods of Making Requests and Interoperating LANs and Internetworking Transport Systems

(18)

BACnet was designed specifically for all building automation applications:  HVAC control

 Fire detection and alarm  Lighting control  Security

 Elevator interface  Utility company interface

To achieve these capabilities, BACnet specifies nearly all of the common building control and monitoring functions, for example: analog and binary inputs, outputs, and values; control loops; schedules, etc.

One of the strengths of BACnet is in accommodating future building automation applications. A vendor can easily add to the existing objects and services. This is not only expected, it is encouraged. Of course, for proprietary features to interoperate, vendor cooperation is required.

Thousands BACnet sites are already operating both in the USA and in various countries around the world.

Why BACnet was Developed

The idea for BACnet was fostered by building automation system (BAS) users within ASHRAE. They believed that BAS technology had progressed sufficiently that standards could be established such that products from different manufacturers could all work together. In other words, BACnet could enable control product interoperability.

The benefits of interoperability to BAS users are:

 One workstation can work with remote panels and controls from different manufacturers

 More competitive bidding on expansions and additions

 Freedom to select the manufacturer(s) that best meet the requirements of the project at the best price

 Allows the addition of technologies and services as they become available, regardless of manufacturer

 A higher likelihood that a current system can be expanded without having to replace it entirely–thus protecting the control system investment

The benefits of BACnet to controls system manufacturers and suppliers are:

(19)

How BACnet was Developed

 It is designed specifically for building control.

 It is designed to be implemented in devices of all sizes.  It is designed to be readily enhanced and improved.  Its design is not tied to present technologies.

How BACnet was Developed

To develop BACnet, ASHRAE established a Standard Project Committee (SPC-135). The original BACnet standard was published in 1995. To help ensure acceptance, the standard had been thoroughly reviewed, studied and analyzed by the industry. The participants in the original testing became the National Institute of Standards and Technology (NIST) BACnet Interoperability Testing Consortium.

BACnet was introduced at the ASHRAE Winter Meeting in January, 1996. In the BACnet booth at the show, equipment from ten different vendors running various types of computers, operating systems, and LAN types were successfully interconnected.

In 2001, the BACnet standard was updated with five addenda. In January 2003, the BACnet standard was approved as ISO Standard 16484-5 and as a European standard within the Committee for European Standardization (CEN).

The BACnet specification is maintained by ASHRAE Standing Standard Project Committee (SSPC) 135. This committee works on refining and expanding the standard.

Certification

Conformance of a product to the BACnet standard is the responsibility of an independent organization called the BACnet Testing Labs (BTL). The BTL develops testing tools and scripts to certify and list devices that conform to device profiles. The BTL consists of a core group sponsored by the BACnet International (BI) and individual manufacturer participation.

BACnet Implementation within APOGEE

The goals of Siemens Building Technologies’ implementation of BACnet are:

 Support ANSI/ASHRAE standard BACnet IP throughout field panel and workstation architecture.

 Meet BTL requirements for the field panel and the workstation.

 Meet the global strategic BACnet requirements of Siemens Building Technologies, Inc.

 Maintain/Enhance APOGEE Automation System features, functionality, performance, look and feel.

(20)

 Maintain support for LonWorks Floor Level Network (FLN), P1 FLN, OP Drivers, Insight options, and InfoCenter.

This is accomplished by the introduction of a BACnet MEC and MBC, and an enhanced Insight BACnet Client and Server Option along with Navigator Support (Commissioning Tool/Design Tool) and appropriate training, documentation, and rollout.

(21)

Chapter 2–BACnet Objects and Services

Chapter 2 describes BACnet Objects and Services, and how the Insight application and the BACnet Browser are used to access objects and their properties. It includes the following topics:

 Objects Theory  Services Theory

Proprietary building automation systems from different manufacturers almost always have different functionality and different communication schemes. BACnet devices, however, all share a common communication standard regardless of manufacturer and the functionality within the device. This is accomplished through the use of objects to represent data and control, and services to convey requests, data, and information. The result is that each device

looks the same on the communication medium.

Objects Theory

To standardize different systems from multiple of manufacturers, BACnet uses objects. An object is a collection of information about a particular function that is uniquely identified and is accessed over the communication medium in a standardized way.

All information in a BACnet system is represented using objects. Standardized objects make all of the devices within a BACnet system look alike. Examples of objects are analog and binary inputs and outputs, schedules, control loops, alarms, logical groupings of points that perform a specific function, software calculations, and software processes.

Of course, a specific object can only exist for a manufacturers’ product if the product has that function that the object represents. For example, you cannot write to the schedule object of a BACnet device if the device has no schedule function.

(22)

Properties of Objects

All BACnet objects have a set of properties that are used to either get information from the object, or give information and commands to the object. An object’s properties are often represented as a table with two columns. On the left is the name or identifier for the property, and on the right is the property’s value.

Some properties are read only meaning that you can look at the property value, but cannot change it. Some properties can be changed (written).

Standard objects can have both required properties and optional properties. Vendors can also create non-standard objects and/or properties.

In the APOGEE Automation System, if a property exists in a BACnet field panel, then the property may be accessed in one of three ways:

 Through the field panel MMI.

 Through the BACnet Object Browser–an Insight application feature in which the properties are listed in tabular form where they can be read or written (if applicable).  Through the Insight application’s windows and dialog boxes–if the property needs to

be read, written, or commanded for the application being used. Some properties may be renamed. For example, the Object_Identifier property is called the Instance Number in the Insight application.

A property of every BACnet object that is responsible for identifying the object is called the

Object_Identifier. It is a numerical value that must be unique within the BACnet device in which it resides. (Property names appear with underbars in the BACnet specification.) Each BACnet object also has an Object_Name property. This is a string of printable characters that also must be unique within the BACnet device in which it resides.

To further assist a user in identifying and managing objects within a BACnet device, each BACnet object has a Description property. It is a string of printable characters, but does not have to be unique in the BACnet device.

Figure 3. BACnet Analog Input Representation of a Temperature Sensor. Figure 3 is an example of a temperature sensor that might be represented as a BACnet Analog Input object. The example shows a few of the properties that might be available with this object. In practice there would be many more properties than those shown.

(23)

Objects Theory

The Object_Name property has the value of SPACE TEMP and Object_Type property has the value of ANALOG INPUT. The Present_Value property is the temperature that the sensor is currently reading (72.3). The remaining properties represent other information about the sensor object, such as whether it is functioning normally, and the values of the High and Low Limits for alarming purposes.

The OBJECT_TYPE Property

Another property of all BACnet objects is called the Object_Type. In BACnet, 23 standard object types have been established to contain much of the information that can be associated with a building automation system. Table 2 lists these object types in seven categories.

Table 2. BACnet Standard Object Types.

Object Type Point-like

Binary Input Binary Output Binary Value

Analog Input Analog Output Analog Value

Multi-state Input Multi-state Output Multi-state Value

Event Reporting

Event Enrollment Notification Class

Scheduling/Logging

Schedule Calendar Trend Log

Control

Program Loop Averaging

Life Safety

Life Safety Point Life Safety Zone

Grouping

Group Command

Device Level

Device File Each occurrence of an object within a device is marked by the Instance Number. For

example, if there are three Notification Class objects in a device, they will carry Instance Numbers 1, 2 and 3, respectively. Some objects have the Instance Number as a property. For example, in the Notification Class object, the value of its Notification_Class property is its Instance Number. The Instance Number is part of what makes up an object’s

Object_Identifier property. The relationship is:

(24)

Command Priority Properties

BACnet has an application-controlled prioritization mechanism, the Command Priority Array, that determines which application is commanding an object property. The Command Priority Array is similar to the Point Command Priority in the APOGEE Automation System.

The BACnet properties that implement the command priority array are Priority_Array and

Relinquish_Default. Every commandable object property supports a 16-slot Priority_Array plus a Relinquish_Default value that serves as a default if no applications are controlling the object value when all 16 slots are empty. Figure 4 shows the standard priorities within the 16 slots along with BACnet’s recommended applications for these priorities. The unused slots are available for other priorities.

Figure 4. BACnet Standard Priorities.

When multiple applications, each with a different priority, have active commands to the object, the object decides which to accept based on the relative priorities of the applications. As commands are set and released, the object will continuously re-evaluate which command to use. Each commanding application must stay in its own priority slot and not interfere with commands from other applications. If all commands are released, the object will default to the value held in the mandatory Relinquish_Default object property. Figure 5 shows an example of how the Command Priority Array operates.

(25)

Objects Theory

Figure 5. Example of the BACnet Command Priority Array Operation.

Command Priority Array vs. APOGEE

The BACnet Command Priority Array, which is similar to APOGEE’s Point Command Priority, manages the Present_Value property. Each Insight application that commands points has a configurable default priority that is used for point commands and releases.

Table 3 shows the Command Priority Array, along with the default mapping to APOGEE priorities. If desired, any of the six defaults can be changed by the user. For OPERATOR, the value in the table is used as the highest priority slot available for commanding. For example, the user can command at this priority and lower.

Table 3. BACnet Command Priority Array Mapped to APOGEE Priorities.

Slot BACnet Names APOGEE Priority

1 Manual Life Safety 2 Automatic Life Safety 3 Available 4 Available

5 Critical Equipment Control 6 Minimum On/Off 7 Available

8 Manual Operator OPERATOR

9 Available

10 Available SMOKE

11 Available

12 Available EMERGENCY

(26)

Slot BACnet Names APOGEE Priority

14 Available PDL

15 Available

16 Available SCHEDULING, PPCL, NONE,

TEC TOOL

Relinquish Default TEC APPLICATION

BACnet commands do not provide enough information for CFR-11 logging. As a result, the CFR-11 feature is not available in the BACnet field panel.

Modifying the Priority Array

The BACnet Priority Array can be modified from the System menu in the Insight System Profile application (Figure 6).

Figure 6. Accessing Priority Array from System Profile.

The BACnet Command Priority Array dialog box (Figure 7) displays the current Text and

(27)

Objects Theory

Figure 7. Command Priority Array Dialog Box.

The Edit button allows modification of the Priority Text and Abbreviated Text via the Modify Priority Text dialog box (Figure 8).

Figure 8. Modify Priority Text Dialog Box.

After clicking OK in both dialog boxes, the BACnet Command Priority Array dialog displays the updated priority text (Figure 9).

(28)

Figure 9. BACnet Command Priority Array after Modification.

Operation

The BACnet priority array operation can cause different operation at times when compared to the current APOGEE Automation System. The following scenario illustrates the change:

APOGEE Automation System:

1) The Scheduler application turns the lights off at the end of the workday. 2) A maintenance technician uses the Insight workstation to command the lights ON. 3) After performing service, the maintenance technician releases the command. 4) The end result is that the lights remain ON all night.

BACnet:

1) The equipment scheduler turns the lights off at the end of the workday. 2) A maintenance technician uses the Insight workstation to command the lights ON. 3) After performing service, the maintenance technician releases the command, returning control of the lights to the scheduler application, which turns the light OFF. 4) The lights remain OFF until

commanded ON by the scheduler the next morning.

Another difference is that with BACnet, unlike the current APOGEE Automation System, commands cannot be dropped if the priority of the command is lower than the existing priority. The lower priority command must be properly entered into the command priority table for implementation whenever the higher priority command is released.

Another difference is that input points can be commanded when the object is out of service. The APOGEE Automation System selectively restricts input commanding for local points, but allows it for TEC subpoints. In BACnet, any point that is out of service can be commanded. Conversely, a physical point must be out of service to be commanded.

(29)

Objects Theory

Impact to MMI

The MMI must show which priority array entry is currently controlling the object. The MMI must also allow configuration of the highest priority allowed, such that priority levels used for life safety may be intentionally prohibited or allowed. See Point Objects for exact details.

Impact to PPCL

PPCL, like all of the other BACnet APOGEE applications that commands points, has a configurable default priority that is used for point commands and releases. Upon saving a new PPCL program in the Program Editor application, the Save As dialog box prompts the user to choose a priority level (Figure 10). The choices are established in the user’s account. PPCL programs will use the PPCL default priority level for point commands and releases if a priority is not specified in the statement. If a PPCL Command Priority (default priority) is not selected when a new program is saved, the PPCL value in the table (for example, BACnet priority level 16 if Table 3 were to apply) is used as the default priority level for the whole program.

Figure 10. PPCL Command Priority Setting.

A BACnet field panel positively acknowledges a command without changing the value if the value is under the control of higher priority. This is a change in operation from non-BACnet field panels, in which the PPCL interpreter would continuously re-command the point if the value didn’t change. Additionally, in a BACnet field panel, the RELEASE statement releases only the one priority level that is designated after the @ symbol. If no @ priority is defined, RELEASE will default to releasing level 16. Therefore, when using existing PPCL programs that use @Priority and Release, check if they have to be re-written to operate correctly. When using the @<Priority> statements in BACnet field panels, only the top four APOGEE priorities (with their BACnet priority equivalents) can be used. For example. if Table 3 were the BACnet to APOGEE priority mapping for a field panel, then only OPERATOR, SMOKE, EMER and PDL can be used in the @<Priority> statements.

(30)

Impact to TEC Subpoints

In a BACnet field panel, commanding a TEC point will cause it to unbundle and use additional field panel memory. Like with any other point, the Present_Value will be set to the highest priority level.

When a TEC point is browsed, the Relinquish_Default property will contain the current Present_Value of the point, and the Priority_Array property will initially display as empty. EEPROM points can only be written by commands with a priority higher (smaller priority number) than OPERATOR. Therefore, EEPROM points cannot be commanded by PPCL. If a remote third-party device commands an EEPROM point and the command has a priority higher than OPERATOR, the command will be blocked. The point’s Reliability property will display Unreliable because the Present Value and the Relinquish_Default disagree.

BACnet Device

A BACnet Device is a collection of objects that represent the functions actually present in a given real device. Figure 11 shows one example of how a group of objects make up a field panel type of BACnet device. Although only one instance of each kind of object is shown, a more typical field panel type of BACnet device might have 16 DI and DO objects, two or three Schedule objects, etc.

Figure 11. Example BACnet Device.

Note that a BACnet Device contains something called a Device object. The properties of this object are where information about the BACnet device resides. The properties include the device’s manufacturer and model number.

There is only one Device object in a BACnet Device. The Device object’s Object_Identifier property uniquely identifies the BACnet device on the communications network. Therefore, the Object_Identifier number must be unique on the network. The Device object also has an Object_Name property, which also must be unique on the network. Table 4 shows the

(31)

Objects Theory

Table 4. Device Object Properties.

Property_Identifier Support Access Notes

Object_Identifier Yes Range is 0 to 4 MB. Configured in IP Settings.

Object_Name Yes Field Panel Name, limited to 30 characters, Configured in IP Settings.

Object_Type Yes Encoded name component “BACDev”

System_Status Yes OPERATIONAL status used to set Ready status Vendor_Name Yes "Siemens BAU"

Vendor_Identifier Yes All Siemens ISA devices = 7 Model_Name Yes "Siemens BACnet EMEC"

Firmware_Revision Yes Firmware Rev String that is, "BCE V3.0 APOGEE” Application_Software_Version Yes Firmware Rev String that is, "BCE3001”

Location Yes Limited to 40 characters, Configured in IP Settings. Description Yes Limited to 40 characters, Configured in IP Settings. Protocol_Version Yes 1

Protocol_Revision Yes 4

Protocol_Services_Supported Yes See Table 14 for a listing of supported services. Protocol_Object_Types

_Supported

Yes See the Object Summary table in Chapter 5–BACnet Field Panels.

Object_List Yes List of object Ids for all points in this field panel. Max_APDU_Length_Accepted Yes 1497

Segmentation_Supported Yes BACNET_SEGMENTATION_TYPE_BOTH Max_Segments_Supported Yes 32

VT_Classes_Supported No Active_VT_Sessions No

Local_Time Yes Field Panel Time

Local_Date Yes Field Panel Date

UTC_Offset No The number of minutes between the local time and UTC time. Daylight_Savings_Status Yes APDU_Segment_Timeout Yes 3000 APDU_Timeout Yes 3000 Number_Of_APDU_Retries Yes 3 List_Of_Session_Keys No Time_Sync_Recipients No Max_Master No Max_Info_Frames No

(32)

Property_Identifier Support Access Notes

Device_Address_Binding Yes

Database_Revision Yes Logical revision number for the database, incremented when objects are created and/or deleted, an object's name is changed, or a database restore is performed. Configuration_Files Yes List of files to be backed up. Valid only during the backup

procedure.

Last_Restore_Time Yes Time of last file download. Applies only to BACnet file transfer services.

Backup_Failure_Timeout Yes Writable How long to wait before aborting a backup or restore operation.

Active_COV_Subscriptions Yes A list of active subscriptions. Applies to the server side. Slave_Proxy_Table No Manual_Slave_Address_Binding No Auto_Slave_Discovery No Slave_Address_Binding No Profile_Name No

Point-Like Objects

Table 2 lists the BACnet objects that resemble points in a building automation system. As with all BACnet objects, point-like objects are just representations of a BACnet device’s points to other BACnet devices on the network. The points’ structure inside of the

manufacturer’s device may be entirely different–perhaps representing the manufacturer’s proprietary and/or legacy software architecture.

The following are some of the highlights of the point-like objects.

Analog Input Object

The Analog Input Object is a representation of a physical analog input point in the BACnet device. Table 5 shows the properties of the Analog Input object along with information about how they interface to the APOGEE Automation System.

Table 5. Analog Input Object Properties.

Property_Identifier Support Access Notes

Object_Identifier Yes Range is 0 to 4 MB. Automatically assigned by default. Object_Name Yes System Name, limited to 30 characters.

Object_Type Yes Encoded name component “AI”. Present_Value Yes Writable REAL

(33)

Objects Theory

Device_Type Yes Text corresponding to the APOGEE LAI sensor type is as follows: "current" "voltage" "pneumatic" "100k Thermistor" "1K Platinum RTD" "LType" "custom"

Status_Flags Yes IN_ALARM = true if point is in alarm, else false. FAULT = true if point is failed, else false.

OVERRIDDEN = true if point is in hand mode, else false. OUT_OF_SERVICE = false.

Event_State Yes If point is in alarm, then Event_State = OFFNORMAL, else if point is failed, then Event_State = FAULT, else Event_State = NORMAL.

Reliability Yes If point is in trouble, then Reliability = OPEN_LOOP,

else if point is failed, then Reliability = UNRELIABLE_OTHER, else Reliability = NO_FAULT_DETECTED.

Out_Of_Service Yes Writable Must be set to override Present_Value. Update_Interval No

Units Yes Writable Uses BACnet enumeration corresponding to fixed engineering units

strings. Min_Pres_Value No

Max_Pres_Value No Resolution Yes Slope

COV_Increment Yes Writable COV Limit

Time_Delay Alarm Always equals zero. Notification Class Alarm Writable

High_Limit Alarm Writable High Limit

Low_Limit Alarm Writable Low Limit

Deadband Alarm Always equals zero.

Limit_Enable Alarm If alarming enabled, then low_limit and high_limit both enabled. Event_Enable Alarm Writable If alarming enabled, then to-offnormal, to-fault, and to-normal all set

to TRUE.

Acked_Transitions Alarm Indicates which of the transitions have been acknowledged, TO_OFFNORMAL, TO_FAULT, TO_NORMAL.

Notify_Type Alarm Always = “Alarm”

Event_Time_Stamps Alarm Timestamps of the following event transitions, TO_OFFNORMAL, TO_FAULT, TO_NORMAL. Profile_Name No

The Present_Value property is the current value of the point. Note that the Out_Of_Service property must be TRUE, before you can write a value into the Present_Value property.

(34)

Analog Output Object

The Analog Output Object is a representation of a physical analog output point in the BACnet device. Table 6 shows the properties of the Analog Output object along with information about how they interface to the APOGEE Automation System.

Table 6. Analog Output Object Properties.

Object_Type Yes Encoded name component “AO”. Present_Value Yes Writable REAL

Description Yes Writable Limited to 16 characters. Device_Type Yes Associated APOGEE Point type.

Reliability Yes if point is in trouble, then Reliability = OPEN_LOOP,

Out_Of_Service Yes Always FALSE

Units Yes Uses BACnet enumeration corresponding to fixed engineering units strings.

Min_Pres_Value No Max_Pres_Value No Resolution Yes Slope

Priority_Array Yes For commanding the present value.

Relinquish_default Yes For releasing the present value when the Priority Array is empty. COV_Increment Yes Writable COV Limit

Deadband Alarm Always equals zero.

(35)

Objects Theory

Property_Identifier Support Access Notes

Notify_Type Alarm Always equals Alarm.

Event_Time_Stamps Alarm Timestamps of the following event transitions, TO_OFFNORMAL, TO_FAULT, TO_NORMAL.

Profile_Name No

The Present_Value property is the current value of the point. Since this is an output, its Present_Value property is always writeable.

Analog Value Object

The Analog Value Object is a representation of a virtual analog output point or a software parameter in the BACnet device. Table 7 shows the properties of the Analog Value object along with information about how they interface to the APOGEE Automation System.

Table 7. Analog Value Object Properties.

Object_Type Yes Encoded name component “AV” Present_Value Yes Writable REAL

Description Yes Writable Limited to 16 characters.

Out_Of_Service Yes Always FALSE.

Units Yes Uses BACnet enumeration corresponding to fixed engineering units

strings.

Relinquish_default Yes For releasing the present value when the Priority Array is empty. COV_Increment Yes Writable COV Limit

(36)

Property_Identifier Support Access Notes

Deadband Alarm Always equal zero.

Limit_Enable Alarm If alarming enabled, then low_limit and high_limit both enabled. Event_Enable Alarm Writable If alarming enabled, then to-offnormal, to-fault, and to-normal all set

to TRUE.

The Present_Value property is the current value of the point. Note that it should be writeable if it is commandable or if Out_Of_Service is TRUE.

Binary Input Object

The Binary Input Object is a representation of a physical binary or digital input point in the BACnet device. Table 8 shows the properties of the Binary Input object along with information about how they interface to the APOGEE Automation System.

Table 8. Binary Input Object Properties.

Object_Type Yes Encoded name component “BI”. Present_Value Yes Writable Binary Value

Description Yes Writable Limited to 16 characters. Device_Type Yes Associated APOGEE Point type

(37)

Objects Theory

Property_Identifier Support Access Notes

Polarity Yes Normally Closed

Inactive_Text Yes Correspond with first entry in the points State Text Table. Active_Text Yes Correspond with second entry in the points State Text Table. Change_Of_State_Time No

Change_Of_State_Count No Time_Of_

State_Count_Reset

No

Elapsed_Active_Time Yes Writable Totalization

Time_Of_

Active_Time_Reset

Yes Totalization_Reset_Time

Alarm_Value Alarm Specifies what the Present_Value is when the point is in Alarm.

Event_Enable Alarm Writable If alarming enabled, then to-offnormal, to-fault, and to-normal all set to TRUE.

Notify_Type Alarm Always equals Alarms

The Present_Value property is the current value of the point. Note that the Out_Of_Service property must be TRUE for the Present_Value to be writeable. The Polarity property indicates the relationship of the physical state of the input to the logical state represented by the Present_Value property.

Binary Output Object

The Binary Output Object is a representation of a physical Binary output point in the BACnet device. Table 9 shows the properties of the Binary Output object along with information about how they interface to the APOGEE Automation System.

Table 9. Binary Output Object Properties.

Object_Type Yes Encoded name component “BO”. Present_Value Yes Writable Binary Value

(38)

Device_Type Yes Associated APOGEE Point type

Out_Of_Service Yes Always FALSE. Polarity Yes Inverted

State_Count_Reset

No

Time_Of_

Active_Time_Reset

Minimum_Off_time No Minimum_On_time No

Relinquish_default Yes For releasing the present value when the Priority Array is empty. Time_Delay Alarm Proof Delay

Notification Class Alarm Writable

Feedback_Value Alarm Current value of the proof point for APOGEE proof points, set equal to the Present_Value for points without proofing.

(39)

Objects Theory

Binary Value Object

The Binary Value Object is a representation of a virtual Binary output point or a software parameter in the BACnet device. Table 10 shows the properties of the Binary Value object along with information about how they interface to the APOGEE Automation System.

Table 10. Binary Value Object Properties.

Object_Type Yes Encoded name component “BV”. Present_Value Yes Writable Binary Value

Out_Of_Service Yes Always FALSE.

State_Count_Reset

No

Time_Of_

Active_Time_Reset

Minimum_Off_time No Minimum_On_time No

Relinquish_default Yes For releasing the present value when the Priority Array is empty. Time_Delay Alarm Proof Delay

(40)

Property_Identifier Support Access Notes

Multi-State Input Object

The Multi-state Input Object has not analogy in the APOGEE BACnet field panel and is not supported

Multi-State Output Object

The Multi-state Output Object is a representation of a physical Multi-state output point in the BACnet device. This point supports L2SL, L2SP, LOOAL, LOOAP, LFSSL, and LFSSP points in APOGEE field panels. Table 11 shows the properties of the Multi-State Output object along with information about how they interface to the APOGEE Automation System.

Table 11. Multi-state Output Object Properties.

Object_Type Yes Encoded name component “MO”. Present_Value Yes Writable Unsigned

Description Yes Writable Limited to 16 characters. Device_Type Yes Associated APOGEE Point type

(41)

Objects Theory

Property_Identifier Support Access Notes

Number_Of_States Yes Correspond to size of State Text Table. State_Text Yes Corresponds with State Text Table. Priority_Array Yes For commanding the present value.

Relinquish_default Yes For releasing the Present_Value when the Priority Array is empty. Time_Delay Alarm Proof Delay

Feedback_Value Alarm Current value of the proof point for APOGEE proof points, set equal to the Present_Value for points without proofing.

The Present_Value property is the current value of the point. Since this is an output, its Present_Value property has a Conformance Code of W meaning that it is always writeable.

Multi-State Value Object

The Multi-state Value Object is a representation of a virtual Multi-state output point or a software parameter in the BACnet device. This point is the equivalent of the LENUM point in the APOGEE field panel. Table 12 shows the properties of the Multi-state Value object along with information about how they interface to the APOGEE Automation System.

Table 12. Multi-state Value Object Properties.

Object_Type Yes Encoded name component “MV”. Present_Value Yes Writable Unsigned

(42)

Property_Identifier Support Access Notes

Out_Of_Service Yes Writable

Number_Of_States Yes Correspond to size of State Text Table. State_Text Yes Corresponds with State Text Table. Priority_Array Yes For commanding the present value.

Relinquish_default Yes For releasing the Present_Value when the Priority Array is empty. Time_Delay Alarm Always equals zero.

Alarm_Values Alarm Fault_Values Alarm Event_Enable Alarm Writable

Other Objects Supported by APOGEE BACnet Field Panels

Other BACnet objects that are supported by APOGEE BACnet Field Panels are:  Calendar Object

 Command Object  File Object

 Notification Class Object  Schedule Object  Trend Log Object

Calendar Object

(43)

Objects Theory

Command Object

See Chapter 7-BACnet Scheduling for details.

File Object

This object is involved with the database uploads and downloads of an APOGEE field panel. Table 13 shows the properties of the File object along with information about how they interface to the APOGEE Automation System.

Table 13. File Object Properties.

Property_Identifier Support Access Notes

Object_Type Yes Encoded name component “FI”. Description Yes Limited to 16 characters. File_Type Yes

File_Size Yes Writable Modification_Date Yes Archive Yes Writable Read_only Yes File_Access_Method Yes Record_Count No

Profile_Name No

Notification Class Object

See Chapter 8-BACnet Alarming for details.

Schedule Object

See Chapter 7-BACnet Scheduling for details.

Trend Log Object

See Chapter 9-BACnet Trending for details.

Viewing with the BACnet Browser

BACnet objects and their properties can be viewed using the BACnet Object Browser. The Object Browser is accessed from the Tools menu in System Profile. A Building Level Network (BLN) must first be chosen to un-gray the BACnet Object Browser.

(44)

Figure 12. Accessing the BACnet Object Browser.

Then the navigation pane in the browser can be used to choose the desired BACnet device (field panel). Choosing a BACnet device will cause its objects to display in the navigation panel and the properties of that device to display on the right side of the screen (assuming you select View Device Properties from the View selection). See Figure 13.

(45)

Services Theory

Figure 13. BACnet Object Browser Screen.

Services Theory

This section is included to provide a greater understanding of how BACnet operates. Most of the operation of BACnet services is behind the scenes and not visible to the user.

BACnet services are the messages that the BACnet devices send to each other. Services are the means by which one BACnet device acquires information from another device,

commands another device to perform some actions, or announces to one or more devices that some event has taken place.

BACnet is based on a Client-Server communications model, and these messages are carried out by the server at the request of the client. Therefore, BACnet messages are service requests. A client computer sends a service request to a server computer that then performs the service and reports the result back to the client. Each service request issued and service acknowledgment (reply) returned becomes a message packet transferred over the network from the sending to the receiving device.

The BACnet message-passing and object access services are divided into five groups or classes of Application Services:

 Object Access Services–Provide the means to read, modify and write properties, as well as add and delete objects.

(46)

 Alarm and Event Services–Deal with changes in conditions seen by a BACnet device such as problems, error conditions, sensors reading out of normal range or alarms returning to normal operation. Also included are Changes-Of-Values or COVs.  File Access Services–Used to read and manipulate files in BACnet devices. In

BACnet, files represent groups of data of arbitrary length and meaning; they do not necessarily relate to any kind of mass storage device. Every BACnet-accessible file has a File Object associated with it.

 Remote Device Management Services–Provide a number of assorted functions, including operator control, specialized message transfer, addressing/auto-configuring functions, discovery of devices and objects, device control, time synchronization file access, reading, and writing.

 Virtual Terminal Services–Used by an operator to establish a bi-directional text-based connection with an application program executing in a remote device. In effect, for the duration of a VT session established with the remote device, the operator's device looks like a terminal connected to the remote application program.

Service requests are issued or processed by application program software running on the BACnet device. In the case of an operator workstation, the software might maintain a display of several sensor inputs and would periodically issue service requests to the appropriate objects in the target devices to obtain the latest values of the inputs. In the monitored device, the service request would be processed in its application program and the reply containing the requested data returned (Figure 14).

Figure 14. Example Service Request and Reply.

Services are categorized as Confirmed in which a reply, typically with data, is expected, or

Unconfirmed in which no reply is expected. BACnet devices are not required to implement every single Service. Just one Service, ReadProperty, is required to be processed by all BACnet devices. Depending upon the function and complexity of the device, additional Services may be initiated or executed.

(47)

Services Theory

Services Supported

The APOGEE BACnet solution only supports the services listed in Table 14. Table 14. Services Supported.

Service Name ACKNOWLEDGE_ALARM ADD_LIST_ELEMENT ATOMIC_READ_FILE ATOMIC_WRITE_FILE CONFIRMED_COV_NOTIFICATION CONFIRMED_EVENT_NOTIFICATION CONFIRMED_PRIVATE_TRANSFER CONFIRMED_TEXT_MESSAGE CREATE_OBJECT DELETE_OBJECT DEVICE_COMMUNICATION_CONTROL GET_ALARM_SUMMARY GET_ENROLLMENT_SUMMARY GET_EVENT_INFORMATION I_AM I_HAVE READ_PROPERTY READ_PROPERTY_MULTIPLE READ_RANGE REINITIALIZE_DEVICE REMOVE_LIST_ELEMENT SUBSCRIBE_COV TIME_SYNCHRONIZATION UNCONFIRMED_COV_NOTIFICATION UNCONFIRMED_EVENT_NOTIFICATION UNCONFIRMED_TEXT_MESSAGE WHO_HAS WHO_IS WRITE_PROPERTY WRITE_PROPERTY_MULTIPLE

(48)

Services Not Supported

The APOGEE BACnet solution does not support the services listed in Table 15. Table 15. Services Not Support.

Service Name AUTHENTICATE LIFE_SAFETY_OPERATION READ_PROPERTY_CONDITIONAL REQUEST_KEY SUBSCRIBE_COV_PROPERTY UNCONFIRMED_PRIVATE_TRANSFER UTC_TIME_SYNCHRONIZATION VT_CLOSE VT_DATA VT_OPEN

(49)

Chapter 3–BACnet Interoperability

Chapter 3 describes the ability of APOGEE BACnet devices to integrate with BACnet products made by different manufacturers into a single system. It includes the following topics:

 Interoperability  Interoperability  Certification

 BACnet Device Profiles

 APOGEE BACnet Field Panel Interoperability  Insight Interoperability

Interoperability

BACnet Interoperability is the ability to integrate BACnet products made by different manufacturers into a single system. Interoperability does not mean that installations must have multiple vendors, just that the site can have multiple BACnet vendors if desired. Many automation system users prefer the benefits of dealing with a single vendor, and a system using the BACnet protocol in no way prevents this.

Note that Interoperability is not plug-and-play. You still have to make choices about what functionality is needed. Also, BACnet interoperability does not address:

 Configuration

 Programming (programming language)  User interface (look and feel)

Some obstacles to interoperability are:  Many properties are optional.

 Manufacturers may interpret the specification differently and make different design assumptions.

(50)

Certification

BACnet is a registered trademark of ASHRAE. ASHRAE does not endorse, approve, or test products for BACnet compliance. That is the responsibility of BACnet International (formerly the BACnet Manufacturers Association and the BACnet Interest Group - North America). To test manufacturers’ BACnet devices for interoperability and certify the results, BACnet International (BI) established the BACnet Testing Laboratories (BTL). The BTL logo is a trademark of BI. Products that have been successfully tested by the BTL are eligible to display the BTL logo as part of the listing process.

The main functions of the BTL are to:

 Sponsor an annual BACnet Interoperability Workshop.

 Develop testing procedures and rules to certify that BACnet devices conform to the BACnet standard so that the devices may carry the BTL certification mark (Figure 15).

Figure 15. BACnet Testing Laboratories Certification Mark.

The APOGEE BACnet Field Panels are BACnet Testing Laboratories (BTL) certified and listed BACnet Building Controllers (B-BC). They carry the BTL certification mark and can meet specifications calling for native BACnet field panels. They provide interoperability with third-party BACnet workstations.

The Insight Revision 3.7 workstation with the BACnet Option can be considered a native BACnet workstation. It has been developed to conform to the anticipated B-OWS test specification. The B-OWS test specification is not complete or approved, but the ANSI/ASHRAE Standard135-2004 includes a B-OWS profile that Siemens Building Technologies has followed.

Specifying BACnet

Specifying BACnet is challenging because the protocol purposely defines more functionality than any particular device will likely implement, and devices can vary greatly in their

implementation of BACnet and BACnet functionality. A document called a Protocol Implementation and Conformance Statement (PICS) was devised to disclose BACnet information such that vendors, customers, and consulting engineers can understand the functionality implemented in a given device. From this information they can determine realistic expectations for interoperability between any given BACnet devices.

(51)

Interoperability

BACnet Interoperability Building Blocks (BIBBs) are defined in part of PICS. BIBBs are sets and groupings of functionality that can be easily mapped from device-to-device, to determine the functionality that is likely interoperable between devices.

Protocol Implementation and Conformance Statement

Protocol Implementation and Conformance Statement (PICS) is a BACnet specification sheet containing a list of a device's BACnet capabilities. Written in a standard format specified by ASHRAE, the PICS contains a general product description, a product's BACnet capabilities, available LAN options, and other items relating to character sets and special functionality.

Every BACnet device must have a PICS. Chapter 12–Appendix in BACnet Modular Equipment Controller (MEC) and Point Expansion Module (PXM) Start-up Procedures (145-025) contains the PICS for the APOGEE BACnet MEC.

Consulting engineers, vendors, and customers can use a PICS to determine what capabilities a BACnet device might have. The PICS may be used to determine what functionality devices are capable of supporting and what functionality is interoperable with other devices.

The PICS provides the following information about a BACnet device:  Product name, version, and description

 Device profile (Annex L) to which the device conforms  B-OWS (BACnet Operator Workstation)

 B-BC (BACnet Building Controller)

 B-AAC (BACnet Advanced Application Controller)  B-ASC (BACnet Application Specific Controller)  B-SS (BACnet Smart Sensor)

 B-SA (BACnet Smart Actuator)  BIBBs supported by t

BACnet Application Guide for Consulting Engineers